From capwap-admin@frascone.com Wed Jun 1 04:28:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05095 for ; Wed, 1 Jun 2005 04:28:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5BD542056A; Wed, 1 Jun 2005 04:28:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7CF6A20565; Wed, 1 Jun 2005 04:28:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5C8522047B for ; Wed, 1 Jun 2005 04:27:20 -0400 (EDT) Received: from smtp2.mei.co.jp (smtp2.mei.co.jp [133.183.129.27]) by mail.frascone.com (Postfix) with ESMTP id 94D5520565 for ; Wed, 1 Jun 2005 04:27:17 -0400 (EDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id j518RFFg024927 for ; Wed, 1 Jun 2005 17:27:15 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j518RF218354 for ; Wed, 1 Jun 2005 17:27:16 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with ESMTP id j518RG502499 for ; Wed, 1 Jun 2005 17:27:16 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <5F09D220B62F79418461A978CA0921BD273202@pslexc01.psl.local> Thread-Topic: IEEE Review - proposed changes Thread-Index: AcVmg2DRFgSqsffnRJ6wkGu9lE4uUA== From: "Saravanan Govindan" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] IEEE Review - proposed changes Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Jun 2005 16:24:50 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable All, Please consider the proposed changes (in subsequent posts) to the CAPWAP Objectives based on the IEEE Review.=20 Saravanan _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 1 04:31:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05239 for ; Wed, 1 Jun 2005 04:31:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 79CE72056D; Wed, 1 Jun 2005 04:31:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2743A20566; Wed, 1 Jun 2005 04:31:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1168720566 for ; Wed, 1 Jun 2005 04:30:50 -0400 (EDT) Received: from smtp2.mei.co.jp (smtp2.mei.co.jp [133.183.129.27]) by mail.frascone.com (Postfix) with ESMTP id 0910D2047B for ; Wed, 1 Jun 2005 04:30:48 -0400 (EDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id j518UkM3011796 for ; Wed, 1 Jun 2005 17:30:46 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id j518UlJ02706 for ; Wed, 1 Jun 2005 17:30:48 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/indians) with ESMTP id j518UmF15208 for ; Wed, 1 Jun 2005 17:30:48 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <5F09D220B62F79418461A978CA0921BD273206@pslexc01.psl.local> Thread-Topic: IEEE Review 1 - Centralized WLAN definition Thread-Index: AcVmg9vsPRsqp4anTnGrg71ySMR7bQ== From: "Saravanan Govindan" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] IEEE Review 1 - Centralized WLAN definition Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Jun 2005 16:28:16 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Section 2 - Terminology Comment: Centralized WLAN" is not defined Proposed Change: "Centralized WLAN: A WLAN based on the centralized WLAN Architecture [Architecture Taxonomy]."=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 1 04:33:05 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05345 for ; Wed, 1 Jun 2005 04:33:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EFC5820576; Wed, 1 Jun 2005 04:33:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0BBA720568; Wed, 1 Jun 2005 04:33:02 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0F2A020568 for ; Wed, 1 Jun 2005 04:32:43 -0400 (EDT) Received: from smtp2.mei.co.jp (smtp2.mei.co.jp [133.183.129.27]) by mail.frascone.com (Postfix) with ESMTP id F056120566 for ; Wed, 1 Jun 2005 04:32:41 -0400 (EDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id j518WdM3013535 for ; Wed, 1 Jun 2005 17:32:39 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j518We220917 for ; Wed, 1 Jun 2005 17:32:40 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with ESMTP id j518Wec14689 for ; Wed, 1 Jun 2005 17:32:40 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <5F09D220B62F79418461A978CA0921BD273209@pslexc01.psl.local> Thread-Topic: IEEE Review 2 - Large scale deployments Thread-Index: AcVmhCG1hd0xmvUhQiijD/7MXUz9pA== From: "Saravanan Govindan" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] IEEE Review 2 - Large scale deployments Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Jun 2005 16:30:13 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Section 2 - Introduction (Paragraph 3) Comment: Remove "that the current majority of large-scale deployments follow" Existing Text: The Architecture Taxonomy identified that the current majority of large-scale deployments follow the centralized WLAN architecture in which portions of the wireless medium access control (MAC) operations are centralized in a WLAN controller. Proposed Text: "The Architecture Taxonomy identified the centralized WLAN architecture as one in which portions of the wireless medium access control (MAC) operations being centralized in a WLAN controller." _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 1 04:49:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06131 for ; Wed, 1 Jun 2005 04:49:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8DBF620582; Wed, 1 Jun 2005 04:49:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C009420572; Wed, 1 Jun 2005 04:49:02 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1413420572 for ; Wed, 1 Jun 2005 04:48:52 -0400 (EDT) Received: from smtp2.mei.co.jp (smtp2.mei.co.jp [133.183.129.27]) by mail.frascone.com (Postfix) with ESMTP id 943622056E for ; Wed, 1 Jun 2005 04:48:50 -0400 (EDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id j518mnFg015307 for ; Wed, 1 Jun 2005 17:48:49 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j518mn227806 for ; Wed, 1 Jun 2005 17:48:49 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/astros) with ESMTP id j518mnX21201 for ; Wed, 1 Jun 2005 17:48:49 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <5F09D220B62F79418461A978CA0921BD273213@pslexc01.psl.local> Thread-Topic: IEEE Review 3 - Rejected Objectives Thread-Index: AcVmhmTQPaW6XMbDQ1Wra+N3o2+BnA== From: "Saravanan Govindan" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] IEEE Review 3 - Rejected Objectives Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Jun 2005 16:46:25 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Comment: 'Rejected Objectives' to be referred to as 'Non-objectives' Proposed change: Change 'Rejected Objectives' to 'Non-objectives' _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 1 04:51:06 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06242 for ; Wed, 1 Jun 2005 04:51:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 036F320584; Wed, 1 Jun 2005 04:51:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 15AF42057C; Wed, 1 Jun 2005 04:51:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E06DA2057C for ; Wed, 1 Jun 2005 04:50:50 -0400 (EDT) Received: from smtp2.mei.co.jp (smtp2.mei.co.jp [133.183.129.27]) by mail.frascone.com (Postfix) with ESMTP id E443D20576 for ; Wed, 1 Jun 2005 04:50:48 -0400 (EDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id j518olFg016866 for ; Wed, 1 Jun 2005 17:50:47 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id j518olX28694 for ; Wed, 1 Jun 2005 17:50:47 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/redsox) with ESMTP id j518olD29933 for ; Wed, 1 Jun 2005 17:50:47 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <5F09D220B62F79418461A978CA0921BD273216@pslexc01.psl.local> Thread-Topic: IEEE Review 4 - Logical groups definition Thread-Index: AcVmhqdo7WxQU6JXQj+hwfnMafP7ZQ== From: "Saravanan Govindan" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] IEEE Review 4 - Logical groups definition Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Jun 2005 16:48:17 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Section 5.1.1 - Logical Groups (Description), paragraph 3=20 Comment:=20 Clarify the term, and specify which types of "logical groups must be supported." Proposed Change: Add definition of logical groups in Section 2 - Terminology. "Logical Group: A logical separation of a physical WTP is termed logical group. Each BSSID and constituent wireless terminals are denoted as distinct logical groups of a physical WTP. Virtual APs of alternative types are also classified as logical groups." _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 1 04:54:05 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06643 for ; Wed, 1 Jun 2005 04:54:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8FA9D20593; Wed, 1 Jun 2005 04:54:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1F6552057C; Wed, 1 Jun 2005 04:54:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8B5022057C for ; Wed, 1 Jun 2005 04:53:06 -0400 (EDT) Received: from smtp2.mei.co.jp (smtp2.mei.co.jp [133.183.129.27]) by mail.frascone.com (Postfix) with ESMTP id 8976C20576 for ; Wed, 1 Jun 2005 04:53:04 -0400 (EDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id j518r2M7015811 for ; Wed, 1 Jun 2005 17:53:02 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id j518r3J12080 for ; Wed, 1 Jun 2005 17:53:03 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/indians) with ESMTP id j518r3F00314 for ; Wed, 1 Jun 2005 17:53:04 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <5F09D220B62F79418461A978CA0921BD273217@pslexc01.psl.local> Thread-Topic: IEEE Review 5 - Logical groups requirement Thread-Index: AcVmhvp1iPn67a0FTCqUvSPm8hWccA== From: "Saravanan Govindan" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] IEEE Review 5 - Logical groups requirement Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Jun 2005 16:50:36 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Section 5.1.1 - Logical Groups (Protocol Requirement) Comment: Make requirement consistent with RFC 2119 Existing text: WLAN deployment trends require the CAPWAP protocol to be capable of controlling and managing physical WTPs in terms of logical groups. Proposed Change: "The CAPWAP protocol MUST be capable of controlling and managing physical WTPs in terms of logical groups including BSSID-based groups." _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 1 05:01:22 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07350 for ; Wed, 1 Jun 2005 05:01:22 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 20B40205C4; Wed, 1 Jun 2005 05:01:17 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6DF0D205BF; Wed, 1 Jun 2005 05:01:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 079F8205B0 for ; Wed, 1 Jun 2005 05:00:19 -0400 (EDT) Received: from smtp2.mei.co.jp (smtp2.mei.co.jp [133.183.129.27]) by mail.frascone.com (Postfix) with ESMTP id 579F0205A0 for ; Wed, 1 Jun 2005 05:00:09 -0400 (EDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id j51907M7021432 for ; Wed, 1 Jun 2005 18:00:07 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id j51908J14537 for ; Wed, 1 Jun 2005 18:00:08 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with ESMTP id j51907I10517 for ; Wed, 1 Jun 2005 18:00:07 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <5F09D220B62F79418461A978CA0921BD27321C@pslexc01.psl.local> Thread-Topic: IEEE Review 6 - Traffic Separation Thread-Index: AcVmh/hjWTIDX2f4S66z6LT7LQxBPA== From: "Saravanan Govindan" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] IEEE Review 6 - Traffic Separation Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Jun 2005 16:57:42 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Section 5.1.2 - Support for Traffic Separation (Description), paragraph 2 Comment: Clarify use of "logical group" Existing text: In particular, given the likelihood of different logical groups being managed by different administrators, separation of control and data is a first step towards individually containing and securing the logical groups. Proposed change: "In particular, given the likelihood of different logical groups, such as BSSIDs, being managed by different administrators, separation of control and data is a first step towards individually containing and securing the logical groups. " =20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 1 05:02:33 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07416 for ; Wed, 1 Jun 2005 05:02:32 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8D2D0205C6; Wed, 1 Jun 2005 05:02:29 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5DAFB205E0; Wed, 1 Jun 2005 05:02:08 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5C139205BD for ; Wed, 1 Jun 2005 05:01:38 -0400 (EDT) Received: from smtp2.mei.co.jp (smtp2.mei.co.jp [133.183.129.27]) by mail.frascone.com (Postfix) with ESMTP id 66DBE205CA for ; Wed, 1 Jun 2005 05:01:17 -0400 (EDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id j5191FM3009899 for ; Wed, 1 Jun 2005 18:01:15 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j5191H202290 for ; Wed, 1 Jun 2005 18:01:17 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with ESMTP id j5191Hc18766 for ; Wed, 1 Jun 2005 18:01:17 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <5F09D220B62F79418461A978CA0921BD27321D@pslexc01.psl.local> Thread-Topic: IEEE Review 7 - Traffic separation requirement Thread-Index: AcVmiCETL+EkIXKQTjKaL9LVZY3umA== From: "Saravanan Govindan" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] IEEE Review 7 - Traffic separation requirement Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Jun 2005 16:58:50 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Section 5.1.2 - Support for Traffic Separation (Protocol Requirement) Comment:=20 Make requirement consistent with RFC 2119=09 Existing text: In order to maintain the separation of control and data traffic, the CAPWAP protocol is required to define control messages such that they do not involve piggybacking or other combination with data traffic.=09 Proposed change: "The CAPWAP Protocol MUST define transport control messages such that the transport of control messages is separate from the transport of data messages." _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 1 05:10:22 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08041 for ; Wed, 1 Jun 2005 05:10:21 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7A30F2045F; Wed, 1 Jun 2005 05:10:22 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EECD3205B0; Wed, 1 Jun 2005 05:10:08 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0807D20614 for ; Wed, 1 Jun 2005 05:09:36 -0400 (EDT) Received: from smtp2.mei.co.jp (smtp2.mei.co.jp [133.183.129.27]) by mail.frascone.com (Postfix) with ESMTP id 899092061E for ; Wed, 1 Jun 2005 05:09:27 -0400 (EDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id j5199QM7000138 for ; Wed, 1 Jun 2005 18:09:26 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id j5199RX05763 for ; Wed, 1 Jun 2005 18:09:27 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/phillies) with ESMTP id j5199QA11452 for ; Wed, 1 Jun 2005 18:09:26 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <5F09D220B62F79418461A978CA0921BD273226@pslexc01.psl.local> Thread-Topic: IEEE Review 8 - Traffic separation edit Thread-Index: AcVmiUVRiXggZPpES9qWkf3BzCUtdw== From: "Saravanan Govindan" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] IEEE Review 8 - Traffic separation edit Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Jun 2005 17:07:00 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Section 5.1.2 - Support for Traffic Separation (Motivation), paragraph 2 Comment: Edit redundancy Existing text: Furthermore, in the context of shared WLAN deployments, the mutual separation of control and data also addresses security concerns. In particular, given the likelihood of different logical groups being managed by different administrators, separation of control and data is a first step towards individually containing and securing the logical groups. It is also important to ensure that traffic from each logical group be mutually separated to maintain the integrity and independence of the logical groups. Proposed change: "Furthermore, this requirement will help remotely located WTPs to handle data traffic in alternative ways without the need for forwarding them across a wide network to the WLAN controller. Separation of WTP control and data also aids in the secure realization of shared WLAN deployments." _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From diameter-admin@frascone.com Wed Jun 1 05:16:20 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08461 for ; Wed, 1 Jun 2005 05:16:20 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 593622065B for ; Wed, 1 Jun 2005 05:16:19 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9B3E1205B0 for ; Wed, 1 Jun 2005 05:16:12 -0400 (EDT) Date: Wed, 01 Jun 2005 05:16:12 -0400 Message-ID: <20050601091612.2481.53.Mailman@xavier> Subject: frascone.com mailing list memberships reminder From: mailman-owner@wolverine.cnri.reston.va.us To: capwap-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: diameter-admin@frascone.com Errors-To: diameter-admin@frascone.com X-BeenThere: diameter@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a reminder, sent out once a month, about your frascone.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, capwap-request@frascone.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@wolverine. Thanks! Passwords for capwap-archive@lists.ietf.org: List Password // URL ---- -------- capwap@frascone.com xakour http://mail.frascone.com/mailman/options/capwap/capwap-archive%40lists.ietf.org From capwap-admin@frascone.com Wed Jun 1 05:34:05 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11138 for ; Wed, 1 Jun 2005 05:34:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A757520674; Wed, 1 Jun 2005 05:34:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3AE8520660; Wed, 1 Jun 2005 05:34:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 74CD620660 for ; Wed, 1 Jun 2005 05:33:59 -0400 (EDT) Received: from smtp2.mei.co.jp (smtp2.mei.co.jp [133.183.129.27]) by mail.frascone.com (Postfix) with ESMTP id 478612063C for ; Wed, 1 Jun 2005 05:33:57 -0400 (EDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id j519XrM7022193 for ; Wed, 1 Jun 2005 18:33:53 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id j519XuJ27695 for ; Wed, 1 Jun 2005 18:33:56 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with ESMTP id j519Xtc09059 for ; Wed, 1 Jun 2005 18:33:56 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <5F09D220B62F79418461A978CA0921BD27323C@pslexc01.psl.local> Thread-Topic: IEEE Review 9 - Terminal transparency requirement Thread-Index: AcVmjLDa6O1VofBoRX+DOX/I4kV19A== From: "Saravanan Govindan" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] IEEE Review 9 - Terminal transparency requirement Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Jun 2005 17:31:29 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Section 5.1.3 - Wireless Terminal Transparency (Requirement) Comment:=20 Make requirement consistent with RFC 2119=09 Existing text: Wireless terminals should not be required to recognize or be aware of the CAPWAP protocol.=09 Proposed change: "Wireless terminals MUST NOT be required to recognize or be aware of the CAPWAP protocol." _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 1 05:37:05 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11572 for ; Wed, 1 Jun 2005 05:37:04 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 11D3720632; Wed, 1 Jun 2005 05:37:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C57BC205C9; Wed, 1 Jun 2005 05:37:02 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EBF28205BF for ; Wed, 1 Jun 2005 05:36:12 -0400 (EDT) Received: from smtp2.mei.co.jp (smtp2.mei.co.jp [133.183.129.27]) by mail.frascone.com (Postfix) with ESMTP id 877B2205C9 for ; Wed, 1 Jun 2005 05:36:10 -0400 (EDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id j519a8M3011774 for ; Wed, 1 Jun 2005 18:36:08 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j519a9215787 for ; Wed, 1 Jun 2005 18:36:09 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with ESMTP id j519a9c10954 for ; Wed, 1 Jun 2005 18:36:09 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <5F09D220B62F79418461A978CA0921BD27323D@pslexc01.psl.local> Thread-Topic: IEEE Review 10 - Configuration Consistency Thread-Index: AcVmjQAX4T4u8ItmSrezCMEdMWZt9Q== From: "Saravanan Govindan" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] IEEE Review 10 - Configuration Consistency Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Jun 2005 17:33:42 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Section 5.1.4 - Configuration Consistency (Description, Requirement) Comment: Section title is inconsistent with stated requirement.=20 Proposed Change: Configuration consistency is identified as an issue arising from lack of appropriate monitoring. This is brought out in the description and requirement. =20 Description:=20 "WLANs in the CAPWAP framework contain numerous WTPs, each of which need to be configured and managed in a consistent manner. The main concern in ensuring consistency is availability of appropriate information corresponding to WTP configuration states. So configuration consistency can be achieved by providing the centralized WLAN controller with regular updates on the state of WTP operations. The centralized WLAN controller can in turn apply information from the regular updates to ensure consistently among the WTPs." =20 Requirement:=20 "The CAPWAP protocol MUST include support for regular exchanges of state information between WTPs and WLAN controller. Examples of state information include WTP processing load and memory utilization." Motivation:=20 "A protocol that provides access to regular state information can in turn be used to enhance WLAN configuration and performance. The CAPWAP protocol will be better equipped to address configuration related problems with the regularly available state information. So with greater state information, control and management operations can be improved." Relation to Problem Statement:=20 "One of the major challenges described in the Problem Statement is that of maintaining consistent configuration across the numerous WTPs of a WLAN. This objective addresses the fundamental issue behind this - availability of timely state information."=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 1 05:44:05 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13058 for ; Wed, 1 Jun 2005 05:44:04 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 18C2120669; Wed, 1 Jun 2005 05:44:04 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A2E9120601; Wed, 1 Jun 2005 05:44:02 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8737220601 for ; Wed, 1 Jun 2005 05:43:12 -0400 (EDT) Received: from smtp2.mei.co.jp (smtp2.mei.co.jp [133.183.129.27]) by mail.frascone.com (Postfix) with ESMTP id 413F4205C9 for ; Wed, 1 Jun 2005 05:43:09 -0400 (EDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id j519h7M3018019 for ; Wed, 1 Jun 2005 18:43:07 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id j519h9X18717 for ; Wed, 1 Jun 2005 18:43:09 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with ESMTP id j519h7c13091 for ; Wed, 1 Jun 2005 18:43:07 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <5F09D220B62F79418461A978CA0921BD27323E@pslexc01.psl.local> Thread-Topic: IEEE Review 11 - Firmware Trigger Thread-Index: AcVmjfq4SG368wOcQAmHHdGncwHSrA== From: "Saravanan Govindan" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] IEEE Review 11 - Firmware Trigger Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Jun 2005 17:40:43 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Section 5.1.5 - Firmware Trigger (Requirement, Motivation, Relation) Comment:=20 Clarify use of firmware equivalence --XX-- Protocol requirement: Existing text: The CAPWAP protocol must support a trigger for delivery of firmware updates. =20 Proposed change: "The CAPWAP protocol MUST support a trigger for delivery of firmware." --XX-- =20 Motivation and Protocol Benefits: =20 Existing text: The CAPWAP protocol interfaces many WTPs to a centralized WLAN controller. Firmware distribution allows these interfaces to be appropriately equivalent. This in turn results in consistent configuration and simplified management. So the protocol benefits by including triggers for the distribution of firmware updates. Proposed change: "The CAPWAP protocol interfaces many WTPs to a centralized WLAN controller. Firmware distribution allows these interfaces to be compatible. This in turn results in consistent configuration and simplified management. So the protocol benefits by including triggers for the distribution of firmware updates."=20 --XX-- Relation to Problem Statement: =20 Existing text: Inconsistencies in the configuration of WTPs has been identified as a major challenge for large-scale WTPs. This objectives helps overcome the challenge by providing for a way for the protocol to initiate delivery of equivalent versions of firmware to all WTPs. Proposed change: "Inconsistencies in the configuration of WTPs has been identified as a major challenge for large-scale WTPs. This objectives helps overcome the challenge by providing for a way for the CAPWAP protocol to initiate delivery of firmware updates that are compatible among all WTPs." --XX-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 1 05:51:05 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14421 for ; Wed, 1 Jun 2005 05:51:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 19A6520673; Wed, 1 Jun 2005 05:51:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8320C20632; Wed, 1 Jun 2005 05:51:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2FC7620632 for ; Wed, 1 Jun 2005 05:50:48 -0400 (EDT) Received: from smtp2.mei.co.jp (smtp2.mei.co.jp [133.183.129.27]) by mail.frascone.com (Postfix) with ESMTP id 2923920601 for ; Wed, 1 Jun 2005 05:50:45 -0400 (EDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id j519ogM7005974 for ; Wed, 1 Jun 2005 18:50:42 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id j519ojX21253 for ; Wed, 1 Jun 2005 18:50:45 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/redsox) with ESMTP id j519ojD04703 for ; Wed, 1 Jun 2005 18:50:45 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <5F09D220B62F79418461A978CA0921BD273246@pslexc01.psl.local> Thread-Topic: IEEE Review 12 - Priority mapping Thread-Index: AcVmjwpkft1QFotxQaalKvhn34kVcg== From: "Saravanan Govindan" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] IEEE Review 12 - Priority mapping Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Jun 2005 17:48:19 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Section 5.1.7 - Resource Control Objective (Requirement) Comment:=20 Clarify mapping of priorities Existing text: The CAPWAP protocol must maintain IEEE 802.11e QoS mappings across the switching and wireless medium segments. Proposed change: "The CAPWAP protocol MUST map the IEEE 802.11e QoS priorities to equivalent QoS priorities across the switching and wireless medium segments."=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 1 06:25:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22925 for ; Wed, 1 Jun 2005 06:25:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0C9812065A; Wed, 1 Jun 2005 06:25:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5EE3620673; Wed, 1 Jun 2005 06:25:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 01AC420660 for ; Wed, 1 Jun 2005 06:24:57 -0400 (EDT) Received: from smtp2.mei.co.jp (smtp2.mei.co.jp [133.183.129.27]) by mail.frascone.com (Postfix) with ESMTP id CB9452065A for ; Wed, 1 Jun 2005 06:24:55 -0400 (EDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id j51AOqM7000702 for ; Wed, 1 Jun 2005 19:24:52 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id j51AOtX02285 for ; Wed, 1 Jun 2005 19:24:55 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with ESMTP id j51AOs511304 for ; Wed, 1 Jun 2005 19:24:55 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <5F09D220B62F79418461A978CA0921BD273254@pslexc01.psl.local> Thread-Topic: IEEE Review 13 - Protocol security Thread-Index: AcVmk81d7VDnGGMHS1K8cV3NZXQD4w== From: "Saravanan Govindan" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] IEEE Review 13 - Protocol security Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Jun 2005 18:22:24 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Section 5.1.8 - CAPWAP Protocol Secuirty (Description) Comment: Justify mutual authentication requirement Existing text: The CAPWAP protocol must first provide for the participating entities - WLAN controller and WTPs - to be mutually authenticated. This is to ensure that rogue WTPs do not breach legitimate WLAN systems. For example, WTPs may need to regularly renew their authentication state with the WLAN controller. Proposed change: The following changes include text from Charles Clancy.=20 "The CAPWAP protocol must first provide for the participating entities - WLAN controller and WTPs - to be mutually authenticated. This is to ensure that rogue elements do not gain access to the WLAN system. Rogue WTPs should not be allowed to breahch legitimate WLANs and at the same time rogue WLAN controllers should not be allowed to gain control of legitimate WTPs. For example, WTPs may need to regularly renew their authentication state with the WLAN controller and similarly for WLAN controllers. If authentication is performed via an authenticated key exchange, future knowledge of derived keys is not sufficient for authentication. Any session keys used between the AC and WTP MUST be mutually drived using entropy contributed by both parties. This ensures that no one party has control over the resulting session keys." : : "CAPWAP should not prevent the use of asymmetric authentication. The security considerations of such asymmetric authentication are described in the Security Considerations section." _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 1 06:43:05 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29027 for ; Wed, 1 Jun 2005 06:43:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0BC802069C; Wed, 1 Jun 2005 06:43:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 564DE20660; Wed, 1 Jun 2005 06:43:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4246020660 for ; Wed, 1 Jun 2005 06:42:52 -0400 (EDT) Received: from smtp2.mei.co.jp (smtp2.mei.co.jp [133.183.129.27]) by mail.frascone.com (Postfix) with ESMTP id A4CC22065A for ; Wed, 1 Jun 2005 06:42:50 -0400 (EDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id j51AgmM3001601 for ; Wed, 1 Jun 2005 19:42:48 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id j51AgoX08960 for ; Wed, 1 Jun 2005 19:42:50 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with ESMTP id j51Agn316794 for ; Wed, 1 Jun 2005 19:42:50 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <5F09D220B62F79418461A978CA0921BD27325F@pslexc01.psl.local> Thread-Topic: IEEE Review 14 - Interoperability Objective Thread-Index: AcVmllBDv6Xl0+xrRE25l3dhk8cErw== From: "Saravanan Govindan" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] IEEE Review 14 - Interoperability Objective Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Jun 2005 18:40:22 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Section 5.1.11 - Interoperability Objective (Description), paragraph 6 Comment: Clarify IEEE 802.11 APF AHC status Existing text: The definition of these interfaces in terms of finer granularity of functionalities will be based on the outcome of the IEEE AP Functionality (APF) Ad-Hoc Committee. The APF Ad-Hoc Committee will provide appropriate insight in to specific functional blocks which may be used for finer capabilities negotiations within the CAPWAP protocol.=09 Proposed change: "The definition of these interfaces in terms of finer granularity of functionalities will be based on AP functionality documents produced by the IEEE 802.11 AP Functionality (APF) Ad-Hoc Committee." _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 1 06:44:04 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29358 for ; Wed, 1 Jun 2005 06:44:04 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2AC3A206B1; Wed, 1 Jun 2005 06:44:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CEBEE20669; Wed, 1 Jun 2005 06:44:02 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3BD9F20669 for ; Wed, 1 Jun 2005 06:43:52 -0400 (EDT) Received: from smtp2.mei.co.jp (smtp2.mei.co.jp [133.183.129.27]) by mail.frascone.com (Postfix) with ESMTP id 29D8C20660 for ; Wed, 1 Jun 2005 06:43:49 -0400 (EDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id j51AhmFg017158 for ; Wed, 1 Jun 2005 19:43:48 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id j51AhnJ21775 for ; Wed, 1 Jun 2005 19:43:49 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with ESMTP id j51Ahn523589 for ; Wed, 1 Jun 2005 19:43:49 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <5F09D220B62F79418461A978CA0921BD273260@pslexc01.psl.local> Thread-Topic: IEEE Review 15 - Vendor flexibility Thread-Index: AcVmlnRTMVuYRxNQQ46t4gvdnzrpmQ== From: "Saravanan Govindan" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] IEEE Review 15 - Vendor flexibility Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Jun 2005 18:41:23 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Section 5.1.14 - Vendor Flexibility (Requirement) Comment: Requirement should reflect CAPWAP protocol instead of WTP vendor=09 Existing text: WTP vendors must not be bound to a specific MAC.=09 Proposed change: "The CAPWAP protocol MUST be compatible with both local-MAC and split-MAC WTPs." _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 1 06:45:05 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29767 for ; Wed, 1 Jun 2005 06:45:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 35772206B6; Wed, 1 Jun 2005 06:45:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DD5CA206AC; Wed, 1 Jun 2005 06:45:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A70D9206AC for ; Wed, 1 Jun 2005 06:44:51 -0400 (EDT) Received: from smtp2.mei.co.jp (smtp2.mei.co.jp [133.183.129.27]) by mail.frascone.com (Postfix) with ESMTP id 8FF8D20674 for ; Wed, 1 Jun 2005 06:44:49 -0400 (EDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id j51AimFg017879 for ; Wed, 1 Jun 2005 19:44:48 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id j51AinX09564 for ; Wed, 1 Jun 2005 19:44:49 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with ESMTP id j51Aimc00877 for ; Wed, 1 Jun 2005 19:44:48 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <5F09D220B62F79418461A978CA0921BD273261@pslexc01.psl.local> Thread-Topic: IEEE Review 16 - New IEEE Requirements Thread-Index: AcVmlpgfhP4zI38DShyYXJmdPcH3DA== From: "Saravanan Govindan" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] IEEE Review 16 - New IEEE Requirements Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Jun 2005 18:42:23 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Section 5.2.3 - Support for New IEEE Requirements (Description)=09 Comment: Clarify nature of the objective=09 Exiting text: The IEEE is currently reviewing IEEE 802.11 functionality. It is expected that the review by the IEEE AP Functionality Ad-Hoc Committee may result in new definitions of functional blocks, interfaces or information flows. The CAPWAP protocol must be able to incorporate these revisions with minimal change. This intent of this requirement is to cover changes/updates made by the APF AHC. Proposed change: "The IEEE 802.11 APF Ad-Hoc Committee has reviewed IEEE 802.11 functionality and has made more thorough definitions for them. The CAPWAP protocol must be able to incorporate these definitions with minimal change. " _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 1 10:33:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21853 for ; Wed, 1 Jun 2005 10:33:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DFFC2206C4; Wed, 1 Jun 2005 10:33:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 27388206C0; Wed, 1 Jun 2005 10:33:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 58452206C0 for ; Wed, 1 Jun 2005 10:32:30 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id 57890206BF for ; Wed, 1 Jun 2005 10:32:28 -0400 (EDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 01 Jun 2005 07:32:28 -0700 Received: from pacalhouwxp (dhcp-171-71-203-206.cisco.com [171.71.203.206]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j51EWNlw022699 for ; Wed, 1 Jun 2005 07:32:23 -0700 (PDT) Message-Id: <200506011432.j51EWNlw022699@sj-core-2.cisco.com> From: "Pat Calhoun" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C5667C.0F0BB310" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVmtrsFJNprui8LSZKBEWJ0aGfIlQ== X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] LWAPP Self Evaluation draft posted yesterday Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Jun 2005 07:32:25 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C5667C.0F0BB310 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, As per the protocol submission rules laid out by the chairs, the authors of the LWAPP protocol submitted a self evaluation to the I-D draft editors yesterday. I have made the draft available at http://www.capwap.org/draft-calhoun-capwap-lwapp-objectives-comparison-00.tx t. Comments welcomed! Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ------=_NextPart_000_0010_01C5667C.0F0BB310 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,
 
As per = the protocol=20 submission rules laid out by the chairs, the authors of the LWAPP = protocol=20 submitted a self evaluation to the I-D draft editors yesterday. I have = made the=20 draft available at http://www.capwap.org/draft-calhoun-capwap-lwapp-objectives-comp= arison-00.txt.
 
Comments=20 welcomed!
 

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

 
------=_NextPart_000_0010_01C5667C.0F0BB310-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 1 10:42:06 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22566 for ; Wed, 1 Jun 2005 10:42:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3B89C206C0; Wed, 1 Jun 2005 10:42:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 03AC6206C1; Wed, 1 Jun 2005 10:42:02 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 022E1206C1 for ; Wed, 1 Jun 2005 10:41:06 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id 24D18206C0 for ; Wed, 1 Jun 2005 10:41:04 -0400 (EDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 01 Jun 2005 07:41:04 -0700 Received: from pacalhouwxp (dhcp-171-71-203-206.cisco.com [171.71.203.206]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j51Eexbw001199; Wed, 1 Jun 2005 07:41:02 -0700 (PDT) Message-Id: <200506011441.j51Eexbw001199@sj-core-1.cisco.com> From: "Pat Calhoun" To: "'Saravanan Govindan'" , Subject: RE: [Capwap] IEEE Review 1 - Centralized WLAN definition MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <5F09D220B62F79418461A978CA0921BD273206@pslexc01.psl.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVmg9vsPRsqp4anTnGrg71ySMR7bQANA6gQ X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Jun 2005 07:40:59 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Works for me. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan > Sent: Wednesday, June 01, 2005 1:28 AM > To: capwap@frascone.com > Subject: [Capwap] IEEE Review 1 - Centralized WLAN definition > > Section 2 - Terminology > > Comment: > > Centralized WLAN" is not defined > > > Proposed Change: > > "Centralized WLAN: A WLAN based on the centralized WLAN > Architecture [Architecture Taxonomy]." > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 1 10:42:27 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22594 for ; Wed, 1 Jun 2005 10:42:26 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 87612206D5; Wed, 1 Jun 2005 10:42:26 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 49030206CA; Wed, 1 Jun 2005 10:42:09 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 35B7B206C1 for ; Wed, 1 Jun 2005 10:41:18 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 34813206C0 for ; Wed, 1 Jun 2005 10:41:15 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 01 Jun 2005 07:41:15 -0700 X-IronPort-AV: i="3.93,156,1115017200"; d="scan'208"; a="272601683:sNHT58978130" Received: from pacalhouwxp (dhcp-171-71-203-206.cisco.com [171.71.203.206]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j51EfClq008443; Wed, 1 Jun 2005 07:41:13 -0700 (PDT) Message-Id: <200506011441.j51EfClq008443@sj-core-5.cisco.com> From: "Pat Calhoun" To: "'Saravanan Govindan'" , Subject: RE: [Capwap] IEEE Review 3 - Rejected Objectives MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <5F09D220B62F79418461A978CA0921BD273213@pslexc01.psl.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVmhmTQPaW6XMbDQ1Wra+N3o2+BnAAMY2Mw X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Jun 2005 07:41:12 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Works for me. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan > Sent: Wednesday, June 01, 2005 1:46 AM > To: capwap@frascone.com > Subject: [Capwap] IEEE Review 3 - Rejected Objectives > > Comment: > > 'Rejected Objectives' to be referred to as 'Non-objectives' > > > Proposed change: > > Change 'Rejected Objectives' to 'Non-objectives' > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 1 10:43:06 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22641 for ; Wed, 1 Jun 2005 10:43:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6CD47206CE; Wed, 1 Jun 2005 10:43:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A49E4206C4; Wed, 1 Jun 2005 10:43:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EAFE9206D4 for ; Wed, 1 Jun 2005 10:42:44 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 02A40206C1 for ; Wed, 1 Jun 2005 10:42:24 -0400 (EDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 01 Jun 2005 07:42:24 -0700 X-IronPort-AV: i="3.93,156,1115017200"; d="scan'208"; a="272602337:sNHT29999338" Received: from pacalhouwxp (dhcp-171-71-203-206.cisco.com [171.71.203.206]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j51EgMbw002251; Wed, 1 Jun 2005 07:42:22 -0700 (PDT) Message-Id: <200506011442.j51EgMbw002251@sj-core-1.cisco.com> From: "Pat Calhoun" To: "'Saravanan Govindan'" , Subject: RE: [Capwap] IEEE Review 4 - Logical groups definition MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <5F09D220B62F79418461A978CA0921BD273216@pslexc01.psl.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVmhqdo7WxQU6JXQj+hwfnMafP7ZQAMV/1g X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Jun 2005 07:42:21 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I have issues with the last sentence "Virtual APs of alternative types are also lassified as logical groups." I can't tell what 'alternative type' means. I do like the rest of the text. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan > Sent: Wednesday, June 01, 2005 1:48 AM > To: capwap@frascone.com > Subject: [Capwap] IEEE Review 4 - Logical groups definition > > Section 5.1.1 - Logical Groups (Description), paragraph 3 > > > Comment: > > Clarify the term, and specify which types of "logical groups > must be supported." > > > Proposed Change: > > Add definition of logical groups in Section 2 - Terminology. > > "Logical Group: A logical separation of a physical WTP is > termed logical group. Each BSSID and constituent wireless > terminals are denoted as distinct logical groups of a > physical WTP. Virtual APs of alternative types are also > classified as logical groups." > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 1 10:43:26 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22690 for ; Wed, 1 Jun 2005 10:43:25 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CF2EE206C1; Wed, 1 Jun 2005 10:43:24 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 791F5206C4; Wed, 1 Jun 2005 10:43:09 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 79729206C1 for ; Wed, 1 Jun 2005 10:42:59 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id AE588206C4 for ; Wed, 1 Jun 2005 10:42:57 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 01 Jun 2005 07:42:57 -0700 X-IronPort-AV: i="3.93,156,1115017200"; d="scan'208"; a="272602795:sNHT27093000" Received: from pacalhouwxp (dhcp-171-71-203-206.cisco.com [171.71.203.206]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j51Egtlq010115; Wed, 1 Jun 2005 07:42:55 -0700 (PDT) Message-Id: <200506011442.j51Egtlq010115@sj-core-5.cisco.com> From: "Pat Calhoun" To: "'Saravanan Govindan'" , Subject: RE: [Capwap] IEEE Review 5 - Logical groups requirement MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <5F09D220B62F79418461A978CA0921BD273217@pslexc01.psl.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVmhvp1iPn67a0FTCqUvSPm8hWccAAMS9yw X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Jun 2005 07:42:54 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Works for me - interesting that IEEE is informing us of our own rules ;-) Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan > Sent: Wednesday, June 01, 2005 1:51 AM > To: capwap@frascone.com > Subject: [Capwap] IEEE Review 5 - Logical groups requirement > > Section 5.1.1 - Logical Groups (Protocol Requirement) > > Comment: > > Make requirement consistent with RFC 2119 > > > Existing text: > > WLAN deployment trends require the CAPWAP protocol to be > capable of controlling and managing physical WTPs in terms of > logical groups. > > > Proposed Change: > > "The CAPWAP protocol MUST be capable of controlling and > managing physical WTPs in terms of logical groups including > BSSID-based groups." > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 1 10:44:06 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22735 for ; Wed, 1 Jun 2005 10:44:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3A84C206D6; Wed, 1 Jun 2005 10:44:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2BEFA206C4; Wed, 1 Jun 2005 10:44:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 174DA206D4 for ; Wed, 1 Jun 2005 10:43:51 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id 420B8206E3 for ; Wed, 1 Jun 2005 10:43:44 -0400 (EDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 01 Jun 2005 07:43:45 -0700 Received: from pacalhouwxp (dhcp-171-71-203-206.cisco.com [171.71.203.206]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j51Ehblw001515; Wed, 1 Jun 2005 07:43:38 -0700 (PDT) Message-Id: <200506011443.j51Ehblw001515@sj-core-2.cisco.com> From: "Pat Calhoun" To: "'Saravanan Govindan'" , Subject: RE: [Capwap] IEEE Review 6 - Traffic Separation MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <5F09D220B62F79418461A978CA0921BD27321C@pslexc01.psl.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVmh/hjWTIDX2f4S66z6LT7LQxBPAAMFI5Q X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Jun 2005 07:43:40 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Works for me. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan > Sent: Wednesday, June 01, 2005 1:58 AM > To: capwap@frascone.com > Subject: [Capwap] IEEE Review 6 - Traffic Separation > > Section 5.1.2 - Support for Traffic Separation (Description), > paragraph > 2 > > Comment: > > Clarify use of "logical group" > > > Existing text: > > In particular, given the likelihood of different logical > groups being managed by different administrators, separation > of control and data is a first step towards individually > containing and securing the logical groups. > > > Proposed change: > > "In particular, given the likelihood of different logical > groups, such as BSSIDs, being managed by different > administrators, separation of control and data is a first > step towards individually containing and securing the logical > groups. " > > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 1 10:45:05 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22783 for ; Wed, 1 Jun 2005 10:45:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 364D7206DA; Wed, 1 Jun 2005 10:45:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 11E93206D3; Wed, 1 Jun 2005 10:45:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 915F1206CA for ; Wed, 1 Jun 2005 10:44:34 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id B57B5206C1 for ; Wed, 1 Jun 2005 10:44:32 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 01 Jun 2005 07:44:32 -0700 X-IronPort-AV: i="3.93,156,1115017200"; d="scan'208"; a="272603742:sNHT27011404" Received: from pacalhouwxp (dhcp-171-71-203-206.cisco.com [171.71.203.206]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j51EiUlq011323; Wed, 1 Jun 2005 07:44:30 -0700 (PDT) Message-Id: <200506011444.j51EiUlq011323@sj-core-5.cisco.com> From: "Pat Calhoun" To: "'Saravanan Govindan'" , Subject: RE: [Capwap] IEEE Review 7 - Traffic separation requirement MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <5F09D220B62F79418461A978CA0921BD27321D@pslexc01.psl.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVmiCETL+EkIXKQTjKaL9LVZY3umAAMEapA X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Jun 2005 07:44:29 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Works for me. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan > Sent: Wednesday, June 01, 2005 1:59 AM > To: capwap@frascone.com > Subject: [Capwap] IEEE Review 7 - Traffic separation requirement > > Section 5.1.2 - Support for Traffic Separation (Protocol Requirement) > > Comment: > > Make requirement consistent with RFC 2119 > > > Existing text: > > In order to maintain the separation of control and data > traffic, the CAPWAP protocol is required to define control > messages such that they do > not involve piggybacking or other combination with data traffic. > > > Proposed change: > > "The CAPWAP Protocol MUST define transport control messages > such that the transport of control messages is separate from > the transport of data messages." > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 1 10:47:05 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22910 for ; Wed, 1 Jun 2005 10:47:04 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2DE8B206DA; Wed, 1 Jun 2005 10:47:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CF227206CB; Wed, 1 Jun 2005 10:47:02 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3AE06206CB for ; Wed, 1 Jun 2005 10:46:13 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id 4CC32206CA for ; Wed, 1 Jun 2005 10:46:11 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 01 Jun 2005 07:46:11 -0700 Received: from pacalhouwxp (dhcp-171-71-203-206.cisco.com [171.71.203.206]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j51Ek8lq012881; Wed, 1 Jun 2005 07:46:09 -0700 (PDT) Message-Id: <200506011446.j51Ek8lq012881@sj-core-5.cisco.com> From: "Pat Calhoun" To: "'Saravanan Govindan'" , Subject: RE: [Capwap] IEEE Review 8 - Traffic separation edit MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <5F09D220B62F79418461A978CA0921BD273226@pslexc01.psl.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVmiUVRiXggZPpES9qWkf3BzCUtdwAL0S/w X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Jun 2005 07:46:08 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I'm confused by this comment. The previous comment was to change some of the text in the first paragraph, but now this commend recommends that the whole first paragraph, including the previous comment (7), be discarded in favor of this new text. Perhaps I'm missing something... Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan > Sent: Wednesday, June 01, 2005 2:07 AM > To: capwap@frascone.com > Subject: [Capwap] IEEE Review 8 - Traffic separation edit > > Section 5.1.2 - Support for Traffic Separation (Motivation), > paragraph 2 > > Comment: > > Edit redundancy > > > Existing text: > > Furthermore, in the context of shared WLAN deployments, the > mutual separation of control and data also addresses security > concerns. In particular, given the likelihood of different > logical groups being managed by different administrators, > separation of control and data is a first step towards > individually containing and securing the logical groups. > > > It is also important to ensure that traffic from each logical > group be mutually separated to maintain the integrity and > independence of the logical groups. > > > Proposed change: > > "Furthermore, this requirement will help remotely located > WTPs to handle > data traffic in alternative ways without the need for > forwarding them > across a wide network to the WLAN controller. > > > Separation of WTP control and data also aids in the secure > realization of shared WLAN deployments." > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 1 10:47:22 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22955 for ; Wed, 1 Jun 2005 10:47:22 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9D47D206CA; Wed, 1 Jun 2005 10:47:23 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1D153206CB; Wed, 1 Jun 2005 10:47:09 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6E99A206CB for ; Wed, 1 Jun 2005 10:46:28 -0400 (EDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.frascone.com (Postfix) with ESMTP id 99794206CA for ; Wed, 1 Jun 2005 10:46:26 -0400 (EDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 01 Jun 2005 07:46:26 -0700 X-IronPort-AV: i="3.93,156,1115017200"; d="scan'208"; a="640097489:sNHT26602516" Received: from pacalhouwxp (dhcp-171-71-203-206.cisco.com [171.71.203.206]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j51EkLlw003422; Wed, 1 Jun 2005 07:46:21 -0700 (PDT) Message-Id: <200506011446.j51EkLlw003422@sj-core-2.cisco.com> From: "Pat Calhoun" To: "'Saravanan Govindan'" , Subject: RE: [Capwap] IEEE Review 9 - Terminal transparency requirement MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <5F09D220B62F79418461A978CA0921BD27323C@pslexc01.psl.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVmjLDa6O1VofBoRX+DOX/I4kV19AAK/qng X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Jun 2005 07:46:23 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Works for me. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan > Sent: Wednesday, June 01, 2005 2:31 AM > To: capwap@frascone.com > Subject: [Capwap] IEEE Review 9 - Terminal transparency requirement > > Section 5.1.3 - Wireless Terminal Transparency (Requirement) > > Comment: > > Make requirement consistent with RFC 2119 > > > Existing text: > > Wireless terminals should not be required to recognize or be aware of > the CAPWAP protocol. > > > Proposed change: > > "Wireless terminals MUST NOT be required to recognize or be > aware of the CAPWAP protocol." > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 1 10:59:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23753 for ; Wed, 1 Jun 2005 10:59:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C7E37206E2; Wed, 1 Jun 2005 10:59:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 49033206D5; Wed, 1 Jun 2005 10:59:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8A482206CA for ; Wed, 1 Jun 2005 10:58:22 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id 9780B206C0 for ; Wed, 1 Jun 2005 10:58:20 -0400 (EDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 01 Jun 2005 07:58:21 -0700 Received: from booharawxp (dhcp-171-71-133-200.cisco.com [171.71.133.200]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j51EwFbw015429; Wed, 1 Jun 2005 07:58:16 -0700 (PDT) Message-Id: <200506011458.j51EwFbw015429@sj-core-1.cisco.com> Reply-To: From: "Bob O'Hara" To: "'Saravanan Govindan'" , Subject: RE: [Capwap] IEEE Review 15 - Vendor flexibility Organization: Cisco Systems MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <5F09D220B62F79418461A978CA0921BD273260@pslexc01.psl.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcVmlnRTMVuYRxNQQ46t4gvdnzrpmQAIyHJg X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Jun 2005 07:58:17 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I think that the IEEE review group did not understand this requirement in its original form, if this is the change that they have requested. I told them as much in the 802.11 meeting in Cairns. This requirement has nothing to do with local MAC/split MAC distinctions and everything to do with the fact that the proposed protocols MUST be entirely hardware independent, i.e., MUST NOT depend on the presence of a particular MAC chipset in order to provide the features and functions defined by the other Requirements. The correct text for this requirement should be" "The CAPWAP protocol MUST be independent of any hardware implementation of the AC and WTP, while simultaneously meeting the remaining requirements." -Bob -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan Sent: Wednesday, June 01, 2005 3:41 AM To: capwap@frascone.com Subject: [Capwap] IEEE Review 15 - Vendor flexibility Section 5.1.14 - Vendor Flexibility (Requirement) Comment: Requirement should reflect CAPWAP protocol instead of WTP vendor Existing text: WTP vendors must not be bound to a specific MAC. Proposed change: "The CAPWAP protocol MUST be compatible with both local-MAC and split-MAC WTPs." _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 1 11:30:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26589 for ; Wed, 1 Jun 2005 11:30:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 50DE2206EE; Wed, 1 Jun 2005 11:30:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 43487206E2; Wed, 1 Jun 2005 11:30:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 695C5206DE for ; Wed, 1 Jun 2005 11:30:00 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 9C814206C0 for ; Wed, 1 Jun 2005 11:29:58 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j51FPKxI037816; Wed, 1 Jun 2005 08:25:20 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200506011525.j51FPKxI037816@homebrew.trpz.com> To: bob.ohara@cisco.com Cc: "'Saravanan Govindan'" , capwap@frascone.com Subject: Re: [Capwap] IEEE Review 15 - Vendor flexibility In-Reply-To: Your message of "Wed, 01 Jun 2005 07:58:17 PDT." <200506011458.j51EwFbw015429@sj-core-1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <37814.1117639520.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 01 Jun 2005 08:25:20 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Bob, I think you mean "the correct text for this requirement MAY be" :-) I actually like Saravanan's suggestion better. The WG spent lots of time coming up with a taxonomy to describe the various split MAC and local MAC architectures. It makes sense to have a requirement that explicitly states that the resulting CAPWAP protocol MUST NOT force a specific architecture on implementors. Saravanan's suggestion says just that (although in a positive-- MUST, not a negative-- MUST NOT-- way). Dan. On Wed, 01 Jun 2005 07:58:17 PDT you wrote > I think that the IEEE review group did not understand this requirement in > its original form, if this is the change that they have requested. I told > them as much in the 802.11 meeting in Cairns. > > This requirement has nothing to do with local MAC/split MAC distinctions and > everything to do with the fact that the proposed protocols MUST be entirely > hardware independent, i.e., MUST NOT depend on the presence of a particular > MAC chipset in order to provide the features and functions defined by the > other Requirements. > > The correct text for this requirement should be" > > "The CAPWAP protocol MUST be independent of any hardware implementation of > the AC and WTP, while simultaneously meeting the remaining requirements." > > > -Bob > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf > Of Saravanan Govindan > Sent: Wednesday, June 01, 2005 3:41 AM > To: capwap@frascone.com > Subject: [Capwap] IEEE Review 15 - Vendor flexibility > > Section 5.1.14 - Vendor Flexibility (Requirement) > > Comment: > > Requirement should reflect CAPWAP protocol instead of WTP vendor > > > Existing text: > > WTP vendors must not be bound to a specific MAC. > > > Proposed change: > > "The CAPWAP protocol MUST be compatible with both local-MAC and > split-MAC WTPs." > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 1 11:37:09 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27126 for ; Wed, 1 Jun 2005 11:37:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 98D27206F1; Wed, 1 Jun 2005 11:37:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B1955206E7; Wed, 1 Jun 2005 11:37:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 988FD206E7 for ; Wed, 1 Jun 2005 11:36:44 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 182C220270 for ; Wed, 1 Jun 2005 11:36:41 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j51FX5lo037846; Wed, 1 Jun 2005 08:33:05 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200506011533.j51FX5lo037846@homebrew.trpz.com> To: "Saravanan Govindan" Cc: capwap@frascone.com Subject: Re: [Capwap] IEEE Review 13 - Protocol security In-Reply-To: Your message of "Wed, 01 Jun 2005 18:22:24 +0800." <5F09D220B62F79418461A978CA0921BD273254@pslexc01.psl.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <37844.1117639985.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 01 Jun 2005 08:33:05 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Saravanan, I clearly understand the threat posed by a "rogue WTP" but what is the threat posed by a "rogue AC"? A CAPWAP-capable WTP is not service providing all by its lonesome. It requires an AC to provision and control it, and to forward packets for its associated STAs. With that in mind the only thing I can see a "rogue AC" doing is analagous to physical theft. It can induce WTPs to be controlled and provisioned by it instead of a different, legitimate, AC. It cannot gain access to a wired network, only put a WTP's associated STAs on its network (if it has one). If the "rogue AC" is something CAPWAP MUST prevent then I'd like to see some text describing the threat to justify it. If the "rogue AC" is not something that CAPWAP MUST prevent (i.e. it SHOULD prevent) then the requirement for mutual authentication should also be a SHOULD. Dan. On Wed, 01 Jun 2005 18:22:24 +0800 you wrote > Section 5.1.8 - CAPWAP Protocol Secuirty (Description) > > Comment: > > Justify mutual authentication requirement > > > Existing text: > > The CAPWAP protocol must first provide for the participating entities - > WLAN controller and WTPs - to be mutually authenticated. This is to > ensure that rogue WTPs do not breach legitimate WLAN systems. For > example, WTPs may need to regularly renew their authentication state > with the WLAN controller. > > > Proposed change: > > The following changes include text from Charles Clancy. > > "The CAPWAP protocol must first provide for the participating entities - > WLAN controller and WTPs - to be mutually authenticated. This is to > ensure that rogue elements do not gain access to the WLAN system. Rogue > WTPs should not be allowed to breahch legitimate WLANs and at the same > time rogue WLAN controllers should not be allowed to gain control of > legitimate WTPs. For example, WTPs may need to regularly renew their > authentication state with the WLAN controller and similarly for WLAN > controllers. > > If authentication is performed via an authenticated key exchange, future > knowledge of derived keys is not sufficient for authentication. > > Any session keys used between the AC and WTP MUST be mutually drived > using entropy contributed by both parties. This ensures that no one > party has control over the resulting session keys." > : > : > "CAPWAP should not prevent the use of asymmetric authentication. The > security considerations of such asymmetric authentication are described > in the Security Considerations section." > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 1 11:59:05 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28735 for ; Wed, 1 Jun 2005 11:59:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 71458206F7; Wed, 1 Jun 2005 11:59:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9186B206EE; Wed, 1 Jun 2005 11:59:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8CE55206EE for ; Wed, 1 Jun 2005 11:58:49 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 96619206E7 for ; Wed, 1 Jun 2005 11:58:46 -0400 (EDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 01 Jun 2005 08:58:46 -0700 X-IronPort-AV: i="3.93,157,1115017200"; d="scan'208"; a="272651973:sNHT39224238" Received: from booharawxp ([10.32.30.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j51Fwdbw013574; Wed, 1 Jun 2005 08:58:39 -0700 (PDT) Message-Id: <200506011558.j51Fwdbw013574@sj-core-1.cisco.com> Reply-To: From: "Bob O'Hara" To: Cc: "'Saravanan Govindan'" Subject: RE: [Capwap] IEEE Review 15 - Vendor flexibility Organization: Cisco Systems MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <200506011525.j51FPKxI037816@homebrew.trpz.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcVmvttcT3lea8L5RjGdfFAkAQuU3AAA2RiQ X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.30.63] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Jun 2005 08:58:45 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Dan, I agree that the requirement to support both the local MAC and split MAC architectures you propose should be part of the CAPWAP requirements. I just believe that changing this requirement, as the IEEE reviewers propose, removes a significant requirement. I have no objection to adding a new requirement for architecture impartiality. -Bob -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Dan Harkins Sent: Wednesday, June 01, 2005 8:25 AM To: bob.ohara@cisco.com Cc: 'Saravanan Govindan'; capwap@frascone.com Subject: Re: [Capwap] IEEE Review 15 - Vendor flexibility Bob, I think you mean "the correct text for this requirement MAY be" :-) I actually like Saravanan's suggestion better. The WG spent lots of time coming up with a taxonomy to describe the various split MAC and local MAC architectures. It makes sense to have a requirement that explicitly states that the resulting CAPWAP protocol MUST NOT force a specific architecture on implementors. Saravanan's suggestion says just that (although in a positive-- MUST, not a negative-- MUST NOT-- way). Dan. On Wed, 01 Jun 2005 07:58:17 PDT you wrote > I think that the IEEE review group did not understand this requirement in > its original form, if this is the change that they have requested. I told > them as much in the 802.11 meeting in Cairns. > > This requirement has nothing to do with local MAC/split MAC distinctions and > everything to do with the fact that the proposed protocols MUST be entirely > hardware independent, i.e., MUST NOT depend on the presence of a particular > MAC chipset in order to provide the features and functions defined by the > other Requirements. > > The correct text for this requirement should be" > > "The CAPWAP protocol MUST be independent of any hardware implementation of > the AC and WTP, while simultaneously meeting the remaining requirements." > > > -Bob > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf > Of Saravanan Govindan > Sent: Wednesday, June 01, 2005 3:41 AM > To: capwap@frascone.com > Subject: [Capwap] IEEE Review 15 - Vendor flexibility > > Section 5.1.14 - Vendor Flexibility (Requirement) > > Comment: > > Requirement should reflect CAPWAP protocol instead of WTP vendor > > > Existing text: > > WTP vendors must not be bound to a specific MAC. > > > Proposed change: > > "The CAPWAP protocol MUST be compatible with both local-MAC and > split-MAC WTPs." > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 1 19:06:06 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18380 for ; Wed, 1 Jun 2005 19:06:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CF5B720710; Wed, 1 Jun 2005 19:06:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B81B42070C; Wed, 1 Jun 2005 19:06:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2E68A2070C for ; Wed, 1 Jun 2005 19:05:17 -0400 (EDT) Received: from smtp4.centerbeam.com (smtp4.centerbeam.com [63.120.115.248]) by mail.frascone.com (Postfix) with ESMTP id B887E2070A for ; Wed, 1 Jun 2005 19:05:15 -0400 (EDT) Received: from cba0e2k00.CBA0.centerbeam.com ([64.95.101.25]) by smtp4.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Jun 2005 16:06:06 -0700 Received: from CBA0E2K06.CBA0.centerbeam.com ([64.95.101.40]) by cba0e2k00.CBA0.centerbeam.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 1 Jun 2005 16:05:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] IEEE Review 13 - Protocol security Message-ID: Thread-Topic: [Capwap] IEEE Review 13 - Protocol security Thread-Index: AcVmv8OjShmG47ZIQQGq3PsM+8aa7AAOw2Yg From: "Darren Loher" To: "Dan Harkins" , "Saravanan Govindan" Cc: X-OriginalArrivalTime: 01 Jun 2005 23:05:05.0500 (UTC) FILETIME=[593FB1C0:01C566FE] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Jun 2005 16:05:01 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable If the path between a WTP and a AC contains an untrusted link(s), then there is a possibility of a Rogue-AC. If the path between the WTP and AC contains a wireless link then the likelyhood of a rogue AC seems just as likely as a Rogue-WTP. =20 Such a configuration is a reasonable scenario. Wifi hotspot providers often operate over an un-trusted network between the AC and the WTP. Often it is desirable for an enterprise to use their shared wired infrastructure for management between WTP's and AC's. This shared network may be trusted for general systems access, but not for network control. =20 In many scenarios, having AC - WTP communition on the wired network is only a minor security advantage. There's the FBI Computer Crime and Security survey that listed 45% of respondents saying they have detected unauthorized access by insiders. Quotes from the 2003 report at http://www.crime-research.org/news/01.06.2004/283/ I strongly support mutual authentication as a "MUST" have requirement. -Darren > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of Dan Harkins > Sent: Wednesday, June 01, 2005 9:33 AM > To: Saravanan Govindan > Cc: capwap@frascone.com > Subject: Re: [Capwap] IEEE Review 13 - Protocol security=20 >=20 > Saravanan, >=20 > I clearly understand the threat posed by a "rogue WTP" but=20 > what is the threat posed by a "rogue AC"? A CAPWAP-capable=20 > WTP is not service providing all by its lonesome. It requires=20 > an AC to provision and control it, and to forward packets for=20 > its associated STAs. With that in mind the only thing I can=20 > see a "rogue AC" doing is analagous to physical theft. > It can induce WTPs to be controlled and provisioned by it=20 > instead of a different, legitimate, AC. It cannot gain access=20 > to a wired network, only put a WTP's associated STAs on its=20 > network (if it has one). >=20 > If the "rogue AC" is something CAPWAP MUST prevent then I'd=20 > like to see some text describing the threat to justify it. If=20 > the "rogue AC" > is not something that CAPWAP MUST prevent (i.e. it SHOULD=20 > prevent) then the requirement for mutual authentication=20 > should also be a SHOULD. >=20 > Dan. >=20 > On Wed, 01 Jun 2005 18:22:24 +0800 you wrote > > Section 5.1.8 - CAPWAP Protocol Secuirty (Description) > >=20 > > Comment: > >=20 > > Justify mutual authentication requirement > >=20 > >=20 > > Existing text: > >=20 > > The CAPWAP protocol must first provide for the=20 > participating entities=20 > > - WLAN controller and WTPs - to be mutually authenticated. =20 > This is to=20 > > ensure that rogue WTPs do not breach legitimate WLAN systems. For=20 > > example, WTPs may need to regularly renew their=20 > authentication state=20 > > with the WLAN controller. > >=20 > >=20 > > Proposed change: > >=20 > > The following changes include text from Charles Clancy.=20 > >=20 > > "The CAPWAP protocol must first provide for the=20 > participating entities=20 > > - WLAN controller and WTPs - to be mutually authenticated. =20 > This is to=20 > > ensure that rogue elements do not gain access to the WLAN system.=20 > > Rogue WTPs should not be allowed to breahch legitimate WLANs and at=20 > > the same time rogue WLAN controllers should not be allowed to gain=20 > > control of legitimate WTPs. For example, WTPs may need to regularly=20 > > renew their authentication state with the WLAN controller and=20 > > similarly for WLAN controllers. > >=20 > > If authentication is performed via an authenticated key exchange,=20 > > future knowledge of derived keys is not sufficient for=20 > authentication. > >=20 > > Any session keys used between the AC and WTP MUST be=20 > mutually drived=20 > > using entropy contributed by both parties. This ensures=20 > that no one=20 > > party has control over the resulting session keys." > > : > > : > > "CAPWAP should not prevent the use of asymmetric=20 > authentication. The=20 > > security considerations of such asymmetric authentication are=20 > > described in the Security Considerations section." > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 1 19:07:05 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18433 for ; Wed, 1 Jun 2005 19:07:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E1FED20717; Wed, 1 Jun 2005 19:07:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6593D2070E; Wed, 1 Jun 2005 19:07:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8774D2070D for ; Wed, 1 Jun 2005 19:06:45 -0400 (EDT) Received: from smtp4.centerbeam.com (smtp4.centerbeam.com [63.120.115.248]) by mail.frascone.com (Postfix) with ESMTP id B8ED72070E for ; Wed, 1 Jun 2005 19:06:43 -0400 (EDT) Received: from cba0e2k00.CBA0.centerbeam.com ([64.95.101.25]) by smtp4.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Jun 2005 16:07:44 -0700 Received: from CBA0E2K06.CBA0.centerbeam.com ([64.95.101.40]) by cba0e2k00.CBA0.centerbeam.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 1 Jun 2005 16:06:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] IEEE Review 8 - Traffic separation edit Message-ID: Thread-Topic: [Capwap] IEEE Review 8 - Traffic separation edit Thread-Index: AcVmiUVRiXggZPpES9qWkf3BzCUtdwAL0S/wABF/76A= From: "Darren Loher" To: "Pat Calhoun" , "Saravanan Govindan" , X-OriginalArrivalTime: 01 Jun 2005 23:06:43.0199 (UTC) FILETIME=[937B60F0:01C566FE] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Jun 2005 16:06:39 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Perhaps the intention was to append the text, not replace? -Darren=20 > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun > Sent: Wednesday, June 01, 2005 8:46 AM > To: 'Saravanan Govindan'; capwap@frascone.com > Subject: RE: [Capwap] IEEE Review 8 - Traffic separation edit >=20 > I'm confused by this comment. The previous comment was to=20 > change some of the text in the first paragraph, but now this=20 > commend recommends that the whole first paragraph, including=20 > the previous comment (7), be discarded in favor of this new=20 > text. Perhaps I'm missing something... >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems >=20 > =20 >=20 > > -----Original Message----- > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan > > Sent: Wednesday, June 01, 2005 2:07 AM > > To: capwap@frascone.com > > Subject: [Capwap] IEEE Review 8 - Traffic separation edit > >=20 > > Section 5.1.2 - Support for Traffic Separation=20 > (Motivation), paragraph=20 > > 2 > >=20 > > Comment: > >=20 > > Edit redundancy > >=20 > >=20 > > Existing text: > >=20 > > Furthermore, in the context of shared WLAN deployments, the mutual=20 > > separation of control and data also addresses security=20 > concerns. In=20 > > particular, given the likelihood of different logical groups being=20 > > managed by different administrators, separation of control=20 > and data =20 > > is a first step towards individually containing and securing the =20 > > logical groups. > >=20 > >=20 > > It is also important to ensure that traffic from each=20 > logical group be=20 > > mutually separated to maintain the integrity and=20 > independence of the=20 > > logical groups. > >=20 > >=20 > > Proposed change: > >=20 > > "Furthermore, this requirement will help remotely located WTPs to=20 > > handle > > data traffic in alternative ways without the need for =20 > > forwarding them > > across a wide network to the WLAN controller. > >=20 > >=20 > > Separation of WTP control and data also aids in the secure=20 > realization=20 > > of shared WLAN deployments." > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 1 19:51:05 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21250 for ; Wed, 1 Jun 2005 19:51:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C0F0E2071A; Wed, 1 Jun 2005 19:51:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1B17120710; Wed, 1 Jun 2005 19:51:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EE18520710 for ; Wed, 1 Jun 2005 19:50:55 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id 076182043A for ; Wed, 1 Jun 2005 19:50:53 -0400 (EDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 01 Jun 2005 16:50:52 -0700 Received: from pacalhouwxp (dhcp-171-71-203-206.cisco.com [171.71.203.206]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j51Noobw012977; Wed, 1 Jun 2005 16:50:50 -0700 (PDT) Message-Id: <200506012350.j51Noobw012977@sj-core-1.cisco.com> From: "Pat Calhoun" To: "'Saravanan Govindan'" , Subject: RE: [Capwap] IEEE Review 10 - Configuration Consistency MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <5F09D220B62F79418461A978CA0921BD27323D@pslexc01.psl.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVmjQAX4T4u8ItmSrezCMEdMWZt9QAd7ixQ X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Jun 2005 16:50:49 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I'm ok with the recommended changes. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan > Sent: Wednesday, June 01, 2005 2:34 AM > To: capwap@frascone.com > Subject: [Capwap] IEEE Review 10 - Configuration Consistency > > Section 5.1.4 - Configuration Consistency (Description, Requirement) > > Comment: > > Section title is inconsistent with stated requirement. > > > Proposed Change: > > Configuration consistency is identified as an issue arising > from lack of appropriate monitoring. This is brought out in > the description and requirement. > > Description: > "WLANs in the CAPWAP framework contain numerous WTPs, each of > which need to be configured and managed in a consistent > manner. The main concern in ensuring consistency is > availability of appropriate information corresponding to WTP > configuration states. So configuration consistency can be > achieved by providing the centralized WLAN controller with > regular updates on the state of WTP operations. The > centralized WLAN controller can in turn apply information > from the regular updates to ensure consistently among the WTPs." > > Requirement: > "The CAPWAP protocol MUST include support for regular > exchanges of state information between WTPs and WLAN > controller. Examples of state information include WTP > processing load and memory utilization." > > Motivation: > "A protocol that provides access to regular state information > can in turn be used to enhance WLAN configuration and > performance. The CAPWAP protocol will be better equipped to > address configuration related problems with the regularly > available state information. So with greater state > information, control and management operations can be improved." > > Relation to Problem Statement: > "One of the major challenges described in the Problem > Statement is that of maintaining consistent configuration > across the numerous WTPs of a WLAN. This objective addresses > the fundamental issue behind this - availability of timely > state information." > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 1 20:08:05 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21968 for ; Wed, 1 Jun 2005 20:08:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A5AC02071F; Wed, 1 Jun 2005 20:08:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D8CED20718; Wed, 1 Jun 2005 20:08:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5402C20718 for ; Wed, 1 Jun 2005 20:07:13 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 5348A20716 for ; Wed, 1 Jun 2005 20:07:10 -0400 (EDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 01 Jun 2005 16:52:46 -0700 X-IronPort-AV: i="3.93,159,1115017200"; d="scan'208"; a="272907597:sNHT88597030324" Received: from pacalhouwxp (dhcp-171-71-203-206.cisco.com [171.71.203.206]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j51Nqibw014048; Wed, 1 Jun 2005 16:52:44 -0700 (PDT) Message-Id: <200506012352.j51Nqibw014048@sj-core-1.cisco.com> From: "Pat Calhoun" To: "'Saravanan Govindan'" , Subject: RE: [Capwap] IEEE Review 11 - Firmware Trigger MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <5F09D220B62F79418461A978CA0921BD27323E@pslexc01.psl.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVmjfq4SG368wOcQAmHHdGncwHSrAAdvDUA X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Jun 2005 16:52:44 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Ok with changes, with the exception that I'd like to see "This objectives" changed to "These objectives" Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan > Sent: Wednesday, June 01, 2005 2:41 AM > To: capwap@frascone.com > Subject: [Capwap] IEEE Review 11 - Firmware Trigger > > Section 5.1.5 - Firmware Trigger (Requirement, Motivation, Relation) > > Comment: > > Clarify use of firmware equivalence > --XX-- > > Protocol requirement: > > Existing text: > The CAPWAP protocol must support a trigger for delivery of > firmware updates. > > Proposed change: "The CAPWAP protocol MUST support a trigger > for delivery of firmware." > --XX-- > > Motivation and Protocol Benefits: > > Existing text: > The CAPWAP protocol interfaces many WTPs to a centralized > WLAN controller. Firmware distribution allows these > interfaces to be appropriately equivalent. This in turn > results in consistent configuration and simplified > management. So the protocol benefits by including triggers > for the distribution of firmware updates. > > Proposed change: > "The CAPWAP protocol interfaces many WTPs to a centralized > WLAN controller. Firmware distribution allows these > interfaces to be compatible. This in turn results in > consistent configuration and simplified management. So the > protocol benefits by including triggers for the distribution > of firmware updates." > --XX-- > > Relation to Problem Statement: > > Existing text: > Inconsistencies in the configuration of WTPs has been > identified as a major challenge for large-scale WTPs. This > objectives helps overcome the challenge by providing for a > way for the protocol to initiate delivery of equivalent > versions of firmware to all WTPs. > > Proposed change: > "Inconsistencies in the configuration of WTPs has been > identified as a major challenge for large-scale WTPs. This > objectives helps overcome the challenge by providing for a > way for the CAPWAP protocol to initiate delivery of firmware > updates that are compatible among all WTPs." > --XX-- > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 1 20:08:24 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21986 for ; Wed, 1 Jun 2005 20:08:24 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1FB042071E; Wed, 1 Jun 2005 20:08:26 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2CB7720724; Wed, 1 Jun 2005 20:08:12 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E3CF720718 for ; Wed, 1 Jun 2005 20:07:34 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 0FE0F20716 for ; Wed, 1 Jun 2005 20:07:32 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 01 Jun 2005 16:53:00 -0700 X-IronPort-AV: i="3.93,159,1115017200"; d="scan'208"; a="272907699:sNHT548827964" Received: from pacalhouwxp (dhcp-171-71-203-206.cisco.com [171.71.203.206]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j51Nqwlq009282; Wed, 1 Jun 2005 16:52:58 -0700 (PDT) Message-Id: <200506012352.j51Nqwlq009282@sj-core-5.cisco.com> From: "Pat Calhoun" To: "'Saravanan Govindan'" , Subject: RE: [Capwap] IEEE Review 12 - Priority mapping MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <5F09D220B62F79418461A978CA0921BD273246@pslexc01.psl.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVmjwpkft1QFotxQaalKvhn34kVcgAdfxiQ X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Jun 2005 16:52:58 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Works for me Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan > Sent: Wednesday, June 01, 2005 2:48 AM > To: capwap@frascone.com > Subject: [Capwap] IEEE Review 12 - Priority mapping > > Section 5.1.7 - Resource Control Objective (Requirement) > > Comment: > > Clarify mapping of priorities > > > Existing text: > > The CAPWAP protocol must maintain IEEE 802.11e QoS mappings > across the switching and wireless medium segments. > > > Proposed change: > > "The CAPWAP protocol MUST map the IEEE 802.11e QoS priorities > to equivalent QoS priorities across the switching and > wireless medium segments." > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 2 05:02:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19025 for ; Thu, 2 Jun 2005 05:02:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 37E4A20399; Thu, 2 Jun 2005 05:02:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 61A332038B; Thu, 2 Jun 2005 05:02:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7A6362038B for ; Thu, 2 Jun 2005 05:01:12 -0400 (EDT) Received: from smtp2.mei.co.jp (smtp2.mei.co.jp [133.183.129.27]) by mail.frascone.com (Postfix) with ESMTP id 070432037A for ; Thu, 2 Jun 2005 05:01:09 -0400 (EDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id j52916M3010657; Thu, 2 Jun 2005 18:01:06 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id j52915506944; Thu, 2 Jun 2005 18:01:05 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with ESMTP id j52914I19329; Thu, 2 Jun 2005 18:01:04 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] IEEE Review 8 - Traffic separation edit X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <5F09D220B62F79418461A978CA0921BD2F204F@pslexc01.psl.local> Thread-Topic: [Capwap] IEEE Review 8 - Traffic separation edit Thread-Index: AcVmiUVRiXggZPpES9qWkf3BzCUtdwAL0S/wACYmbsA= From: "Saravanan Govindan" To: "Pat Calhoun" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 2 Jun 2005 16:58:39 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Pat, Sorry, I mixed up edits across different paragraphs!=20 IEEE Review 7 covers the Protocol Requirement of the "Support for Traffic Separation" objective. The Protocol Requirement is changed to reflect RFC 2119's notations, in this case "MUST".=20 IEEE Review 8 is meant to cover the Description and Motivation sections of the "Support for Traffic Separation" objective.=20 The Description section is edited to clarify the use of "logical groups" and the Motivation section is edited to remove text redundancy.=20 Description:=20 Existing text: Furthermore, in the context of shared WLAN deployments, the mutual separation of control and data also addresses security concerns. In particular, given the likelihood of different logical groups being managed by different administrators, separation of control and data is a first step towards individually containing and securing the logical groups. Proposed change: "Furthermore, in the context of shared WLAN deployments, the mutual separation of control and data also addresses security concerns. In particular, given the likelihood of different logical groups, such as those established by different virtual APs, being managed by different administrators, separation of control and data is a first step towards individually containing and securing the logical groups." --XX-- Motivation: Existing text: Furthermore, such separation provides for the separation of data and control paths. This will help remotely located WTPs to handle data traffic in alternative ways without the need for forwarding them across a wide network to the WLAN controller. Proposed change: "Furthermore, this requirement will help remotely located WTPs to handle data traffic in alternative ways without the need for forwarding them across a wide network to the WLAN controller."=20 I hope this is better. Cheers, Saravanan > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@cisco.com]=20 > Sent: Wednesday, June 01, 2005 10:46 PM > To: Saravanan Govindan; capwap@frascone.com > Subject: RE: [Capwap] IEEE Review 8 - Traffic separation edit >=20 > I'm confused by this comment. The previous comment was to=20 > change some of the text in the first paragraph, but now this=20 > commend recommends that the whole first paragraph, including=20 > the previous comment (7), be discarded in favor of this new=20 > text. Perhaps I'm missing something... >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems >=20 > =20 >=20 > > -----Original Message----- > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan > > Sent: Wednesday, June 01, 2005 2:07 AM > > To: capwap@frascone.com > > Subject: [Capwap] IEEE Review 8 - Traffic separation edit > >=20 > > Section 5.1.2 - Support for Traffic Separation=20 > (Motivation), paragraph=20 > > 2 > >=20 > > Comment: > >=20 > > Edit redundancy > >=20 > >=20 > > Existing text: > >=20 > > Furthermore, in the context of shared WLAN deployments, the mutual=20 > > separation of control and data also addresses security=20 > concerns. In=20 > > particular, given the likelihood of different logical groups being=20 > > managed by different administrators, separation of control=20 > and data =20 > > is a first step towards individually containing and securing the =20 > > logical groups. > >=20 > >=20 > > It is also important to ensure that traffic from each=20 > logical group be=20 > > mutually separated to maintain the integrity and=20 > independence of the=20 > > logical groups. > >=20 > >=20 > > Proposed change: > >=20 > > "Furthermore, this requirement will help remotely located WTPs to=20 > > handle > > data traffic in alternative ways without the need for =20 > > forwarding them > > across a wide network to the WLAN controller. > >=20 > >=20 > > Separation of WTP control and data also aids in the secure=20 > realization=20 > > of shared WLAN deployments." > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 2 05:03:06 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19153 for ; Thu, 2 Jun 2005 05:03:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 602592039D; Thu, 2 Jun 2005 05:03:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7C67A2038D; Thu, 2 Jun 2005 05:03:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5B120203E9 for ; Thu, 2 Jun 2005 05:02:22 -0400 (EDT) Received: from smtp2.mei.co.jp (smtp2.mei.co.jp [133.183.129.27]) by mail.frascone.com (Postfix) with ESMTP id 6BD6D2039D for ; Thu, 2 Jun 2005 05:02:05 -0400 (EDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id j52922M7013594; Thu, 2 Jun 2005 18:02:02 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id j52923P20922; Thu, 2 Jun 2005 18:02:03 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with ESMTP id j52923522036; Thu, 2 Jun 2005 18:02:03 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] IEEE Review 4 - Logical groups definition X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <5F09D220B62F79418461A978CA0921BD2F2051@pslexc01.psl.local> Thread-Topic: [Capwap] IEEE Review 4 - Logical groups definition Thread-Index: AcVmhqdo7WxQU6JXQj+hwfnMafP7ZQAMV/1gACZTifA= From: "Saravanan Govindan" To: "Pat Calhoun" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 2 Jun 2005 16:59:37 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Pat, I should have clarified the text better. The intent was to acknowledge that there are different ways of implementing virtual APs. So the definition of a logical group is to cover virtual APs of varying implementations.=20 Would the following text be better? "Logical Group: A logical separation of a physical WTP is termed logical group. Each BSSID and constituent wireless terminals are denoted as distinct logical groups of a physical WTP. Virtual APs of various implementations are also classified as logical groups."=20 Saravanan > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@cisco.com]=20 > Sent: Wednesday, June 01, 2005 10:42 PM > To: Saravanan Govindan; capwap@frascone.com > Subject: RE: [Capwap] IEEE Review 4 - Logical groups definition >=20 > I have issues with the last sentence "Virtual APs of=20 > alternative types are also lassified as logical groups." I=20 > can't tell what 'alternative type' > means. I do like the rest of the text. >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems >=20 > =20 >=20 > > -----Original Message----- > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan > > Sent: Wednesday, June 01, 2005 1:48 AM > > To: capwap@frascone.com > > Subject: [Capwap] IEEE Review 4 - Logical groups definition > >=20 > > Section 5.1.1 - Logical Groups (Description), paragraph 3 > >=20 > >=20 > > Comment:=20 > >=20 > > Clarify the term, and specify which types of "logical=20 > groups must be=20 > > supported." > >=20 > >=20 > > Proposed Change: > >=20 > > Add definition of logical groups in Section 2 - Terminology. > >=20 > > "Logical Group: A logical separation of a physical WTP is termed=20 > > logical group. Each BSSID and constituent wireless terminals are=20 > > denoted as distinct logical groups of a physical WTP. =20 > Virtual APs of=20 > > alternative types are also classified as logical groups." > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 2 05:04:06 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19252 for ; Thu, 2 Jun 2005 05:04:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EFC8C2039D; Thu, 2 Jun 2005 05:04:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B779520396; Thu, 2 Jun 2005 05:04:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5ADEE2038D for ; Thu, 2 Jun 2005 05:03:22 -0400 (EDT) Received: from smtp2.mei.co.jp (smtp2.mei.co.jp [133.183.129.27]) by mail.frascone.com (Postfix) with ESMTP id 273C12039D for ; Thu, 2 Jun 2005 05:03:14 -0400 (EDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id j5293DM3012707; Thu, 2 Jun 2005 18:03:13 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j5293DB06734; Thu, 2 Jun 2005 18:03:13 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with ESMTP id j5293Dc24618; Thu, 2 Jun 2005 18:03:13 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] IEEE Review 13 - Protocol security X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <5F09D220B62F79418461A978CA0921BD2F2053@pslexc01.psl.local> Thread-Topic: [Capwap] IEEE Review 13 - Protocol security Thread-Index: AcVmv8OjShmG47ZIQQGq3PsM+8aa7AAOw2YgABWot7A= From: "Saravanan Govindan" To: "Darren Loher" , "Dan Harkins" Cc: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 2 Jun 2005 17:00:46 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Dan, Darren, In order to better describe the need for mutual authentication, could we add the following text in the Motivation section? Motivation: Existing text: WLANs are increasingly deployed in critical aspects of enterprise and consumer networks. In these contexts, protocol security is crucial to assure the privacy and integrity expected from network administrators and end-users. So securing the CAPWAP protocol has direct benefits in addressing these concerns. Proposed change: WLANs are increasingly deployed in critical aspects of enterprise and consumer networks. In these contexts, protocol security is crucial to assure the privacy and integrity expected from network administrators and end-users. So securing the CAPWAP protocol has direct benefits in addressing these concerns. "In many cases, the network path between a WTP and WLAN controller contains untrusted links. Such links could be leveraged by rogue WTPs to gain access to the WLAN system. They could also be used by rogue ACs to gain control of legitimate WTPs and their associated terminals to either redirect or compromise terminal traffic. These security concerns can be mitigated with this objective." Cheers, Saravanan > -----Original Message----- > From: Darren Loher [mailto:DLoher@rovingplanet.com]=20 > Sent: Thursday, June 02, 2005 7:05 AM > To: Dan Harkins; Saravanan Govindan > Cc: capwap@frascone.com > Subject: RE: [Capwap] IEEE Review 13 - Protocol security=20 >=20 > If the path between a WTP and a AC contains an untrusted=20 > link(s), then there is a possibility of a Rogue-AC. If the=20 > path between the WTP and AC contains a wireless link then the=20 > likelyhood of a rogue AC seems just as likely as a Rogue-WTP. =20 >=20 > Such a configuration is a reasonable scenario. Wifi hotspot=20 > providers often operate over an un-trusted network between=20 > the AC and the WTP. > Often it is desirable for an enterprise to use their shared=20 > wired infrastructure for management between WTP's and AC's. =20 > This shared network may be trusted for general systems=20 > access, but not for network control. =20 >=20 > In many scenarios, having AC - WTP communition on the wired=20 > network is only a minor security advantage. There's the FBI=20 > Computer Crime and Security survey that listed 45% of=20 > respondents saying they have detected unauthorized access by=20 > insiders. Quotes from the 2003 report at=20 > http://www.crime-research.org/news/01.06.2004/283/ >=20 > I strongly support mutual authentication as a "MUST" have requirement. >=20 > -Darren >=20 >=20 > > -----Original Message----- > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Dan Harkins > > Sent: Wednesday, June 01, 2005 9:33 AM > > To: Saravanan Govindan > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] IEEE Review 13 - Protocol security > >=20 > > Saravanan, > >=20 > > I clearly understand the threat posed by a "rogue WTP"=20 > but what is=20 > > the threat posed by a "rogue AC"? A CAPWAP-capable WTP is=20 > not service=20 > > providing all by its lonesome. It requires an AC to provision and=20 > > control it, and to forward packets for its associated STAs.=20 > With that=20 > > in mind the only thing I can see a "rogue AC" doing is analagous to=20 > > physical theft. > > It can induce WTPs to be controlled and provisioned by it=20 > instead of a=20 > > different, legitimate, AC. It cannot gain access to a wired=20 > network,=20 > > only put a WTP's associated STAs on its network (if it has one). > >=20 > > If the "rogue AC" is something CAPWAP MUST prevent then=20 > I'd like to=20 > > see some text describing the threat to justify it. If the "rogue AC" > > is not something that CAPWAP MUST prevent (i.e. it SHOULD > > prevent) then the requirement for mutual authentication=20 > should also be=20 > > a SHOULD. > >=20 > > Dan. > >=20 > > On Wed, 01 Jun 2005 18:22:24 +0800 you wrote > > > Section 5.1.8 - CAPWAP Protocol Secuirty (Description) > > >=20 > > > Comment: > > >=20 > > > Justify mutual authentication requirement > > >=20 > > >=20 > > > Existing text: > > >=20 > > > The CAPWAP protocol must first provide for the > > participating entities > > > - WLAN controller and WTPs - to be mutually authenticated. =20 > > This is to > > > ensure that rogue WTPs do not breach legitimate WLAN=20 > systems. For=20 > > > example, WTPs may need to regularly renew their > > authentication state > > > with the WLAN controller. > > >=20 > > >=20 > > > Proposed change: > > >=20 > > > The following changes include text from Charles Clancy.=20 > > >=20 > > > "The CAPWAP protocol must first provide for the > > participating entities > > > - WLAN controller and WTPs - to be mutually authenticated. =20 > > This is to > > > ensure that rogue elements do not gain access to the WLAN system.=20 > > > Rogue WTPs should not be allowed to breahch legitimate=20 > WLANs and at=20 > > > the same time rogue WLAN controllers should not be=20 > allowed to gain=20 > > > control of legitimate WTPs. For example, WTPs may need to=20 > regularly=20 > > > renew their authentication state with the WLAN controller and=20 > > > similarly for WLAN controllers. > > >=20 > > > If authentication is performed via an authenticated key exchange,=20 > > > future knowledge of derived keys is not sufficient for > > authentication. > > >=20 > > > Any session keys used between the AC and WTP MUST be > > mutually drived > > > using entropy contributed by both parties. This ensures > > that no one > > > party has control over the resulting session keys." > > > : > > > : > > > "CAPWAP should not prevent the use of asymmetric > > authentication. The > > > security considerations of such asymmetric authentication are=20 > > > described in the Security Considerations section." > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > >=20 > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > >=20 >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From villanveva@emailaccount.com Thu Jun 2 05:20:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21649; Thu, 2 Jun 2005 05:20:32 -0400 (EDT) Received: from cm-213-141-57-161.telecable.es ([213.141.57.161]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DdmCO-0000id-Vw; Thu, 02 Jun 2005 05:41:14 -0400 X-Apparently-To: brenton.daniels@ietf.org X-Sieve: CMU Sieve 2.2 Received: from ideal.buttress.pochta.ru ([unix socket]) by salute.pillory.pochta.ru (Cyrus v2.2.1) with LMTPA; Thu, 02 Jun 2005 11:13:34 +0100 Date: Thu, 02 Jun 2005 15:14:34 +0500 From: "Vern Peoples" Message-Id: X-Accept-Language: en,zh-TW,zh-CN,zh,ja,ko,tr,ru To: brenton.daniels@ietf.org Cc: bridge-mib@ietf.org, bridge-mib-admin@ietf.org, business@ietf.org, calsch@ietf.org, cancer@ietf.org, capwap-archive@ietf.org, ccips@ietf.org, cclark@ietf.org, cdi-archive@ietf.org, cdir-admin@ietf.org, cfrg@ietf.org, cfrg-admin@ietf.org, cfrg-archive@ietf.org, cfrg-bounces@ietf.org, cfrg-web-archive@ietf.org Subject: Pre-approved Application #OHFDT706 X-Mailer: Forte Agent 1.91/32.564 X-Spam-Score: 9.4 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $400,000 for as little as $400 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.cr3am.com/signs.asp Best Regards, Marilyn Gould to be remov(ed: http://www.cr3am.com/deletion.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From fessing@doramail.com Thu Jun 2 07:34:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04683; Thu, 2 Jun 2005 07:34:01 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdoHa-0007Ud-Mo; Thu, 02 Jun 2005 07:54:43 -0400 Received: from [84.5.52.221] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1DdnxV-0006l6-A8; Thu, 02 Jun 2005 07:33:59 -0400 Received: from blockage-jcoppens.com (EHLO controversy.jcoppens.com) by neuropathology.jcoppens.com with SMTP; Thu, 02 Jun 2005 07:23:32 -0500 Date: Thu, 02 Jun 2005 17:23:32 +0500 From: "Sophie Rowell" To: brenton.daniels@ietf.org Cc: bridge-mib@ietf.org, bridge-mib-admin@ietf.org, business@ietf.org, calsch@ietf.org, cancer@ietf.org, capwap-archive@ietf.org, ccips@ietf.org, cclark@ietf.org, cdi-archive@ietf.org, cdir-admin@ietf.org, cfrg@ietf.org, cfrg-admin@ietf.org Subject: Get the low rates before its late Message-ID: X-SpamTest-Info: Profile: SysLog X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [684], SpamtestISP/Release X-Mailer: MIME-tools 5.41 (Entity 5.404) X-Spam-Score: 4.7 (++++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $400,000 for as little as $400 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.cr3am.com/signs.asp Best Regards, Arron Casey to be remov(ed: http://www.cr3am.com/deletion.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From capwap-admin@frascone.com Thu Jun 2 09:00:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11538 for ; Thu, 2 Jun 2005 09:00:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8178720450; Thu, 2 Jun 2005 09:00:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0932820448; Thu, 2 Jun 2005 09:00:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3489220444 for ; Thu, 2 Jun 2005 08:59:26 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id E5CC120441 for ; Thu, 2 Jun 2005 08:59:24 -0400 (EDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 02 Jun 2005 05:59:24 -0700 X-IronPort-AV: i="3.93,161,1115017200"; d="scan'208"; a="273161714:sNHT28256456" Received: from pacalhouwxp (dhcp-171-71-203-206.cisco.com [171.71.203.206]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j52CxIlw013274; Thu, 2 Jun 2005 05:59:19 -0700 (PDT) Message-Id: <200506021259.j52CxIlw013274@sj-core-2.cisco.com> From: "Pat Calhoun" To: "'Saravanan Govindan'" , Subject: RE: [Capwap] IEEE Review 13 - Protocol security MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <5F09D220B62F79418461A978CA0921BD273254@pslexc01.psl.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVmk81d7VDnGGMHS1K8cV3NZXQD4wA3rFEw X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 2 Jun 2005 05:59:21 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Please see my comments below, otherwise I'm ok with the new text. > Existing text: > > The CAPWAP protocol must first provide for the participating > entities - WLAN controller and WTPs - to be mutually > authenticated. This is to ensure that rogue WTPs do not > breach legitimate WLAN systems. For example, WTPs may need > to regularly renew their authentication state with the WLAN > controller. > > > Proposed change: > > The following changes include text from Charles Clancy. > > "The CAPWAP protocol must first provide for the participating s/must/MUST/ > entities - WLAN controller and WTPs - to be mutually Charles' text stated "... to be explicitly mutually ..." ^^^^^^^^^^ > authenticated. This is to ensure that rogue elements do not > gain access to the WLAN system. Rogue WTPs should not be > allowed to breahch legitimate WLANs and at the same time Typo at breach > rogue WLAN controllers should not be allowed to gain control > of legitimate WTPs. For example, WTPs may need to regularly > renew their authentication state with the WLAN controller and > similarly for WLAN controllers. > > If authentication is performed via an authenticated key > exchange, future knowledge of derived keys is not sufficient > for authentication. > > Any session keys used between the AC and WTP MUST be mutually > drived using entropy contributed by both parties. This s/drived/derived/ > ensures that no one party has control over the resulting > session keys." > : > : > "CAPWAP should not prevent the use of asymmetric s/should not/MUST NOT/ > authentication. The security considerations of such > asymmetric authentication are described in the Security > Considerations section." Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 2 09:01:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11596 for ; Thu, 2 Jun 2005 09:01:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9DDAA20450; Thu, 2 Jun 2005 09:01:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 60E6E20448; Thu, 2 Jun 2005 09:01:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 334B02044F for ; Thu, 2 Jun 2005 09:00:27 -0400 (EDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.frascone.com (Postfix) with ESMTP id E56B820448 for ; Thu, 2 Jun 2005 09:00:24 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 02 Jun 2005 06:00:23 -0700 X-IronPort-AV: i="3.93,161,1115017200"; d="scan'208"; a="640459179:sNHT27547072" Received: from pacalhouwxp (dhcp-171-71-203-206.cisco.com [171.71.203.206]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j52D0Dlq012530; Thu, 2 Jun 2005 06:00:14 -0700 (PDT) Message-Id: <200506021300.j52D0Dlq012530@sj-core-5.cisco.com> From: "Pat Calhoun" To: "'Saravanan Govindan'" , Subject: RE: [Capwap] IEEE Review 14 - Interoperability Objective MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <5F09D220B62F79418461A978CA0921BD27325F@pslexc01.psl.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVmllBDv6Xl0+xrRE25l3dhk8cErwA3LDLQ X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 2 Jun 2005 06:00:13 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Looks good. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan > Sent: Wednesday, June 01, 2005 3:40 AM > To: capwap@frascone.com > Subject: [Capwap] IEEE Review 14 - Interoperability Objective > > Section 5.1.11 - Interoperability Objective (Description), paragraph 6 > > Comment: > > Clarify IEEE 802.11 APF AHC status > > > Existing text: > > The definition of these interfaces in terms of finer > granularity of functionalities will be based on the outcome > of the IEEE AP Functionality (APF) Ad-Hoc Committee. The APF > Ad-Hoc Committee will provide appropriate insight in to > specific functional blocks which may > be used for finer capabilities negotiations within the CAPWAP > protocol. > > > Proposed change: > > "The definition of these interfaces in terms of finer > granularity of functionalities will be based on AP > functionality documents produced by the IEEE 802.11 AP > Functionality (APF) Ad-Hoc Committee." > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 2 09:05:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11799 for ; Thu, 2 Jun 2005 09:05:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5DC012046C; Thu, 2 Jun 2005 09:05:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7783D20450; Thu, 2 Jun 2005 09:05:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CEF392044A for ; Thu, 2 Jun 2005 09:04:54 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id C055120444 for ; Thu, 2 Jun 2005 09:04:52 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 02 Jun 2005 06:04:52 -0700 X-IronPort-AV: i="3.93,161,1115017200"; d="scan'208"; a="273164028:sNHT28033210" Received: from pacalhouwxp (dhcp-171-71-203-206.cisco.com [171.71.203.206]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j52D4nlq015394; Thu, 2 Jun 2005 06:04:50 -0700 (PDT) Message-Id: <200506021304.j52D4nlq015394@sj-core-5.cisco.com> From: "Pat Calhoun" To: "'Saravanan Govindan'" , Subject: RE: [Capwap] IEEE Review 16 - New IEEE Requirements MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <5F09D220B62F79418461A978CA0921BD273261@pslexc01.psl.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVmlpgfhP4zI38DShyYXJmdPcH3DAA3IPlg X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 2 Jun 2005 06:04:49 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit This text I have an issue with. For instance, if you read the description text, which is being revised below, the description really talks about new "definition changes", while the protocol requirements section really talks about new 802.11 extensions being created by the IEEE. In my mind, the protocol requirements and motivation sections are the one that take precedence. I don't really view being able to conform to new definitions as being all that important. So I believe that the description text needs to be revised (or ammended). Personally, I view a protocol that can adapt for new technologies (such as 802.11k) as being much more important to the WG than conforming to definitions. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan > Sent: Wednesday, June 01, 2005 3:42 AM > To: capwap@frascone.com > Subject: [Capwap] IEEE Review 16 - New IEEE Requirements > > Section 5.2.3 - Support for New IEEE Requirements (Description) > > Comment: > Clarify nature of the objective > > > Exiting text: > The IEEE is currently reviewing IEEE 802.11 functionality. > It is expected that the review by the IEEE AP Functionality > Ad-Hoc Committee may result in new definitions of functional > blocks, interfaces or information flows. The CAPWAP protocol > must be able to incorporate > these revisions with minimal change. This intent of this requirement > is to cover changes/updates made by the APF AHC. > > > > Proposed change: > "The IEEE 802.11 APF Ad-Hoc Committee has reviewed IEEE > 802.11 functionality and has made more thorough definitions > for them. The CAPWAP protocol must be able to incorporate > these definitions with minimal change. " > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 2 09:58:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15529 for ; Thu, 2 Jun 2005 09:58:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B416B2047F; Thu, 2 Jun 2005 09:58:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BDB3520472; Thu, 2 Jun 2005 09:58:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3F8D720472 for ; Thu, 2 Jun 2005 09:57:42 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 266AC20455 for ; Thu, 2 Jun 2005 09:57:39 -0400 (EDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 02 Jun 2005 06:57:20 -0700 X-IronPort-AV: i="3.93,162,1115017200"; d="scan'208"; a="273184863:sNHT1228506426" Received: from pacalhouwxp (dhcp-171-71-203-206.cisco.com [171.71.203.206]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j52DvClw017452; Thu, 2 Jun 2005 06:57:13 -0700 (PDT) Message-Id: <200506021357.j52DvClw017452@sj-core-2.cisco.com> From: "Pat Calhoun" To: "'Saravanan Govindan'" , Subject: RE: [Capwap] IEEE Review 4 - Logical groups definition MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <5F09D220B62F79418461A978CA0921BD2F2051@pslexc01.psl.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVmhqdo7WxQU6JXQj+hwfnMafP7ZQAMV/1gACZTifAACmOBYA== X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 2 Jun 2005 06:57:17 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I would add the following to the last sentence: ", as long as it does not conflict with the 'Wireless Terminal Transparency' requirement'" Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > Sent: Thursday, June 02, 2005 2:00 AM > To: Pat Calhoun; capwap@frascone.com > Subject: RE: [Capwap] IEEE Review 4 - Logical groups definition > > Pat, > > I should have clarified the text better. The intent was to > acknowledge that there are different ways of implementing > virtual APs. So the definition of a logical group is to cover > virtual APs of varying implementations. > > Would the following text be better? > > "Logical Group: A logical separation of a physical WTP is > termed logical group. Each BSSID and constituent wireless > terminals are denoted as distinct logical groups of a > physical WTP. Virtual APs of various implementations are also > classified as logical groups." > > Saravanan > > > > > -----Original Message----- > > From: Pat Calhoun [mailto:pcalhoun@cisco.com] > > Sent: Wednesday, June 01, 2005 10:42 PM > > To: Saravanan Govindan; capwap@frascone.com > > Subject: RE: [Capwap] IEEE Review 4 - Logical groups definition > > > > I have issues with the last sentence "Virtual APs of > alternative types > > are also lassified as logical groups." I can't tell what > 'alternative > > type' > > means. I do like the rest of the text. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan > > > Sent: Wednesday, June 01, 2005 1:48 AM > > > To: capwap@frascone.com > > > Subject: [Capwap] IEEE Review 4 - Logical groups definition > > > > > > Section 5.1.1 - Logical Groups (Description), paragraph 3 > > > > > > > > > Comment: > > > > > > Clarify the term, and specify which types of "logical > > groups must be > > > supported." > > > > > > > > > Proposed Change: > > > > > > Add definition of logical groups in Section 2 - Terminology. > > > > > > "Logical Group: A logical separation of a physical WTP is termed > > > logical group. Each BSSID and constituent wireless terminals are > > > denoted as distinct logical groups of a physical WTP. > > Virtual APs of > > > alternative types are also classified as logical groups." > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 2 09:59:14 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15849 for ; Thu, 2 Jun 2005 09:59:12 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1FC1F20489; Thu, 2 Jun 2005 09:59:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6693F20475; Thu, 2 Jun 2005 09:59:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 859BC2047E for ; Thu, 2 Jun 2005 09:58:26 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id BD82C20455 for ; Thu, 2 Jun 2005 09:58:23 -0400 (EDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 02 Jun 2005 06:58:23 -0700 Received: from pacalhouwxp (dhcp-171-71-203-206.cisco.com [171.71.203.206]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j52DwFlw018057; Thu, 2 Jun 2005 06:58:15 -0700 (PDT) Message-Id: <200506021358.j52DwFlw018057@sj-core-2.cisco.com> From: "Pat Calhoun" To: "'Saravanan Govindan'" , "'Darren Loher'" , "'Dan Harkins'" Cc: Subject: RE: [Capwap] IEEE Review 13 - Protocol security MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <5F09D220B62F79418461A978CA0921BD2F2053@pslexc01.psl.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVmv8OjShmG47ZIQQGq3PsM+8aa7AAOw2YgABWot7AACmrigA== X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 2 Jun 2005 06:58:20 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Works for me. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan > Sent: Thursday, June 02, 2005 2:01 AM > To: Darren Loher; Dan Harkins > Cc: capwap@frascone.com > Subject: RE: [Capwap] IEEE Review 13 - Protocol security > > Dan, Darren, > > In order to better describe the need for mutual > authentication, could we add the following text in the > Motivation section? > > Motivation: > Existing text: > WLANs are increasingly deployed in critical aspects of > enterprise and consumer networks. In these contexts, > protocol security is crucial to assure the privacy and > integrity expected from network administrators and end-users. > So securing the CAPWAP protocol has direct benefits in > addressing these concerns. > > Proposed change: > WLANs are increasingly deployed in critical aspects of > enterprise and consumer networks. In these contexts, > protocol security is crucial to assure the privacy and > integrity expected from network administrators and end-users. > So securing the CAPWAP protocol has direct benefits in > addressing these concerns. > > "In many cases, the network path between a WTP and WLAN > controller contains untrusted links. Such links could be > leveraged by rogue WTPs to gain access to the WLAN system. > They could also be used by rogue ACs to gain control of > legitimate WTPs and their associated terminals to either > redirect or compromise terminal traffic. These security > concerns can be mitigated with this objective." > > Cheers, > > Saravanan > > > > > > -----Original Message----- > > From: Darren Loher [mailto:DLoher@rovingplanet.com] > > Sent: Thursday, June 02, 2005 7:05 AM > > To: Dan Harkins; Saravanan Govindan > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] IEEE Review 13 - Protocol security > > > > If the path between a WTP and a AC contains an untrusted > link(s), then > > there is a possibility of a Rogue-AC. If the path between > the WTP and > > AC contains a wireless link then the likelyhood of a rogue AC seems > > just as likely as a Rogue-WTP. > > > > Such a configuration is a reasonable scenario. Wifi > hotspot providers > > often operate over an un-trusted network between the AC and the WTP. > > Often it is desirable for an enterprise to use their shared wired > > infrastructure for management between WTP's and AC's. > > This shared network may be trusted for general systems > access, but not > > for network control. > > > > In many scenarios, having AC - WTP communition on the wired > network is > > only a minor security advantage. There's the FBI Computer > Crime and > > Security survey that listed 45% of respondents saying they have > > detected unauthorized access by insiders. Quotes from the > 2003 report > > at http://www.crime-research.org/news/01.06.2004/283/ > > > > I strongly support mutual authentication as a "MUST" have > requirement. > > > > -Darren > > > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On Behalf Of Dan Harkins > > > Sent: Wednesday, June 01, 2005 9:33 AM > > > To: Saravanan Govindan > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] IEEE Review 13 - Protocol security > > > > > > Saravanan, > > > > > > I clearly understand the threat posed by a "rogue WTP" > > but what is > > > the threat posed by a "rogue AC"? A CAPWAP-capable WTP is > > not service > > > providing all by its lonesome. It requires an AC to provision and > > > control it, and to forward packets for its associated STAs. > > With that > > > in mind the only thing I can see a "rogue AC" doing is > analagous to > > > physical theft. > > > It can induce WTPs to be controlled and provisioned by it > > instead of a > > > different, legitimate, AC. It cannot gain access to a wired > > network, > > > only put a WTP's associated STAs on its network (if it has one). > > > > > > If the "rogue AC" is something CAPWAP MUST prevent then > > I'd like to > > > see some text describing the threat to justify it. If the > "rogue AC" > > > is not something that CAPWAP MUST prevent (i.e. it SHOULD > > > prevent) then the requirement for mutual authentication > > should also be > > > a SHOULD. > > > > > > Dan. > > > > > > On Wed, 01 Jun 2005 18:22:24 +0800 you wrote > > > > Section 5.1.8 - CAPWAP Protocol Secuirty (Description) > > > > > > > > Comment: > > > > > > > > Justify mutual authentication requirement > > > > > > > > > > > > Existing text: > > > > > > > > The CAPWAP protocol must first provide for the > > > participating entities > > > > - WLAN controller and WTPs - to be mutually authenticated. > > > This is to > > > > ensure that rogue WTPs do not breach legitimate WLAN > > systems. For > > > > example, WTPs may need to regularly renew their > > > authentication state > > > > with the WLAN controller. > > > > > > > > > > > > Proposed change: > > > > > > > > The following changes include text from Charles Clancy. > > > > > > > > "The CAPWAP protocol must first provide for the > > > participating entities > > > > - WLAN controller and WTPs - to be mutually authenticated. > > > This is to > > > > ensure that rogue elements do not gain access to the > WLAN system. > > > > Rogue WTPs should not be allowed to breahch legitimate > > WLANs and at > > > > the same time rogue WLAN controllers should not be > > allowed to gain > > > > control of legitimate WTPs. For example, WTPs may need to > > regularly > > > > renew their authentication state with the WLAN controller and > > > > similarly for WLAN controllers. > > > > > > > > If authentication is performed via an authenticated key > exchange, > > > > future knowledge of derived keys is not sufficient for > > > authentication. > > > > > > > > Any session keys used between the AC and WTP MUST be > > > mutually drived > > > > using entropy contributed by both parties. This ensures > > > that no one > > > > party has control over the resulting session keys." > > > > : > > > > : > > > > "CAPWAP should not prevent the use of asymmetric > > > authentication. The > > > > security considerations of such asymmetric authentication are > > > > described in the Security Considerations section." > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 2 10:51:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22508 for ; Thu, 2 Jun 2005 10:51:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 795C5201F6; Thu, 2 Jun 2005 10:51:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 170EB20483; Thu, 2 Jun 2005 10:51:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D4D7820483 for ; Thu, 2 Jun 2005 10:50:35 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id 0DB3D201F6 for ; Thu, 2 Jun 2005 10:50:33 -0400 (EDT) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j52Em6dd005813 for ; Thu, 2 Jun 2005 10:48:06 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j52Em1dd005681 for ; Thu, 2 Jun 2005 10:48:03 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: updated SLAPP draft Thread-Index: AcVnJt3X3PYphVsjSfGmhaOlKq31OwAW3s/w From: "Mani, Mahalingam (Mahalingam)" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] FW: updated SLAPP draft Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 2 Jun 2005 08:50:25 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable -mani =3D=3D=3D=3D=3D=3D -----Original Message----- From: Partha Narasimhan [mailto:partha@arubanetworks.com]=20 Sent: Wednesday, June 01, 2005 8:55 PM To: Mani, Mahalingam (Mahalingam); Dorothy.Gellert@nokia.com Cc: dharkins@trpz.com; Subbu Ponnuswamy Subject: FW: updated SLAPP draft Mani/Dorothy I had sent this email earlier, but it still hasnt shown up on the list. Maybe I am facing the same issues that a few others did during the voting phase sometime back. Could one of you please forward it to the list? Thanks partha -----Original Message----- From: Partha Narasimhan Sent: Wed 6/1/2005 6:26 PM To: capwap@frascone.org Cc: Dan Harkins; Subbu Ponnuswamy Subject: updated SLAPP draft can be obtained from ftp://ftp.ietf.org/internet-drafts/draft-narasimhan-ietf-slapp-01.txt Thanks partha _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 2 10:56:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22937 for ; Thu, 2 Jun 2005 10:56:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CF6012049F; Thu, 2 Jun 2005 10:56:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 08D632048A; Thu, 2 Jun 2005 10:56:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 73FD82048A for ; Thu, 2 Jun 2005 10:55:23 -0400 (EDT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mail.frascone.com (Postfix) with ESMTP id 7A268201F6 for ; Thu, 2 Jun 2005 10:55:20 -0400 (EDT) Received: from office (pcp0010121692pcs.crosky01.pa.comcast.net[69.242.69.133]) by comcast.net (rwcrmhc13) with SMTP id <20050602145519015009851ve>; Thu, 2 Jun 2005 14:55:19 +0000 From: "Nanci Vogtli" To: Message-ID: <005a01c56783$1568e5e0$020aa8c0@OFFICE> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005B_01C56761.8E5745E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] CAPWAP poll results and next steps Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 2 Jun 2005 10:55:14 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------=_NextPart_000_005B_01C56761.8E5745E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks, Being new to this reflector perhaps I missed something in the email threads but, based on the following statement from May 11, I had expected that all four evaluation documents were to be posted to the website for WG review by COB this past Tuesday: The next step is for the champion of each protocol to submit an individual draft describing how their protocol meets the Objectives draft, the taxonomy draft and the Problem statement. The first version of these drafts should be submitted to the WG by Tuesday, May 31st. Has there been a change to the schedule or otherwise in the status of these four protocol proposals? Regards, Nanci Nanci Vogtli Concrete Logic www.concrete-logic.com SOLID ANALYSIS => SURPRISING SOLUTIONS email: nancivogtli@concrete-logic.com mobile +1 760.613.3886 ------=_NextPart_000_005B_01C56761.8E5745E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Folks,
 
Being = new to this=20 reflector perhaps I missed something in the email threads but, based on = the=20 following statement from May 11, I had expected that all=20 four evaluation documents were to be posted to the website for = WG=20 review by COB this past Tuesday:
 
The = next step is for=20 the champion of each protocol to submit an
individual draft = describing how=20 their protocol meets the Objectives
draft, the taxonomy draft and = the=20 Problem statement.   The first version
of these drafts = should be=20 submitted to the WG by Tuesday, May 31st.
Has = there been a=20 change to the schedule or otherwise in the status of these four = protocol=20 proposals?
 
Regards,
Nanci
 
Nanci=20 Vogtli
Concrete Logic www.concrete-logic.com
SOLID ANALYSIS=20 =3D> SURPRISING SOLUTIONS
email: nancivogtli@concrete-logic= .com
mobile +1 = 760.613.3886
 
------=_NextPart_000_005B_01C56761.8E5745E0-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 2 12:55:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06674 for ; Thu, 2 Jun 2005 12:55:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 62D8A2027E; Thu, 2 Jun 2005 12:55:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D1ABD20263; Thu, 2 Jun 2005 12:55:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 63C3E1FE14 for ; Thu, 2 Jun 2005 12:54:04 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id A52E81FE0B for ; Thu, 2 Jun 2005 12:53:59 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j52GoLPb050882; Thu, 2 Jun 2005 09:50:21 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200506021650.j52GoLPb050882@homebrew.trpz.com> To: "Darren Loher" Cc: "Saravanan Govindan" , capwap@frascone.com Subject: Re: [Capwap] IEEE Review 13 - Protocol security In-Reply-To: Your message of "Wed, 01 Jun 2005 16:05:01 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <50880.1117731021.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 02 Jun 2005 09:50:21 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Darren, Yes, I understand that a rogue AC is a realistic possibility, I am not questioning that. But what is the threat that it poses? It has nothing to do with the 45% of the people you mention in an FBI survey. In the Objective draft it describes threats posed by a rogue WTP and then says that mutual authentication is required. Mutual authen- tication is not required to address the threats described. Don't get me wrong. I'm all in favor of mutual authentication but I'd like to know the threat that is being addressed by having the AC authenticate itself to the WTP. There are configuration and management implications to mutual authentication-- precludes zero-config drop ship, requires some form of staging, scales less well. (Experience has shown that this added burden is enough to make some in IT so upset that they will actually gut the security of their key management protocol. I speak of the XAUTH hack to IKE). Because of this I think it is imperative that the threat(s) requring mutual authentication be spelled out. If they can't then the only alternative is to not make mutual authentication required. There's a reason why you don't need a personal certificate to purchase things from Amazon. And that is not because the possibility of a "rogue purchaser" is zero. It is because the threat that a "rogue purchaser" poses is not worth the trouble of requiring mutual authen- tication before selecting your purchase. A "rogue company" (a phishing expedition) is a possibility and the threats from that are well documented but, like with the current Objectives draft, those threats are not addressed by mutual authentication. Again, I'm not against mutual authentication. I'm just saying that it hasn't been justified and it needs to be because its cost is not trivial. Dan. On Wed, 01 Jun 2005 16:05:01 PDT you wrote > If the path between a WTP and a AC contains an untrusted link(s), then > there is a possibility of a Rogue-AC. If the path between the WTP and > AC contains a wireless link then the likelyhood of a rogue AC seems just > as likely as a Rogue-WTP. > > Such a configuration is a reasonable scenario. Wifi hotspot providers > often operate over an un-trusted network between the AC and the WTP. > Often it is desirable for an enterprise to use their shared wired > infrastructure for management between WTP's and AC's. This shared > network may be trusted for general systems access, but not for network > control. > > In many scenarios, having AC - WTP communition on the wired network is > only a minor security advantage. There's the FBI Computer Crime and > Security survey that listed 45% of respondents saying they have detected > unauthorized access by insiders. Quotes from the 2003 report at > http://www.crime-research.org/news/01.06.2004/283/ > > I strongly support mutual authentication as a "MUST" have requirement. > > -Darren > > > > -----Original Message----- > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Dan Harkins > > Sent: Wednesday, June 01, 2005 9:33 AM > > To: Saravanan Govindan > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] IEEE Review 13 - Protocol security > > > > Saravanan, > > > > I clearly understand the threat posed by a "rogue WTP" but > > what is the threat posed by a "rogue AC"? A CAPWAP-capable > > WTP is not service providing all by its lonesome. It requires > > an AC to provision and control it, and to forward packets for > > its associated STAs. With that in mind the only thing I can > > see a "rogue AC" doing is analagous to physical theft. > > It can induce WTPs to be controlled and provisioned by it > > instead of a different, legitimate, AC. It cannot gain access > > to a wired network, only put a WTP's associated STAs on its > > network (if it has one). > > > > If the "rogue AC" is something CAPWAP MUST prevent then I'd > > like to see some text describing the threat to justify it. If > > the "rogue AC" > > is not something that CAPWAP MUST prevent (i.e. it SHOULD > > prevent) then the requirement for mutual authentication > > should also be a SHOULD. > > > > Dan. > > > > On Wed, 01 Jun 2005 18:22:24 +0800 you wrote > > > Section 5.1.8 - CAPWAP Protocol Secuirty (Description) > > > > > > Comment: > > > > > > Justify mutual authentication requirement > > > > > > > > > Existing text: > > > > > > The CAPWAP protocol must first provide for the > > participating entities > > > - WLAN controller and WTPs - to be mutually authenticated. > > This is to > > > ensure that rogue WTPs do not breach legitimate WLAN systems. For > > > example, WTPs may need to regularly renew their > > authentication state > > > with the WLAN controller. > > > > > > > > > Proposed change: > > > > > > The following changes include text from Charles Clancy. > > > > > > "The CAPWAP protocol must first provide for the > > participating entities > > > - WLAN controller and WTPs - to be mutually authenticated. > > This is to > > > ensure that rogue elements do not gain access to the WLAN system. > > > Rogue WTPs should not be allowed to breahch legitimate WLANs and at > > > the same time rogue WLAN controllers should not be allowed to gain > > > control of legitimate WTPs. For example, WTPs may need to regularly > > > renew their authentication state with the WLAN controller and > > > similarly for WLAN controllers. > > > > > > If authentication is performed via an authenticated key exchange, > > > future knowledge of derived keys is not sufficient for > > authentication. > > > > > > Any session keys used between the AC and WTP MUST be > > mutually drived > > > using entropy contributed by both parties. This ensures > > that no one > > > party has control over the resulting session keys." > > > : > > > : > > > "CAPWAP should not prevent the use of asymmetric > > authentication. The > > > security considerations of such asymmetric authentication are > > > described in the Security Considerations section." > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 2 13:09:13 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07758 for ; Thu, 2 Jun 2005 13:09:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B51FE2027E; Thu, 2 Jun 2005 13:09:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E27B020263; Thu, 2 Jun 2005 13:09:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8BD582026B for ; Thu, 2 Jun 2005 13:08:57 -0400 (EDT) Received: from vms042pub.verizon.net (vms042pub.verizon.net [206.46.252.42]) by mail.frascone.com (Postfix) with ESMTP id 4D54220263 for ; Thu, 2 Jun 2005 13:08:53 -0400 (EDT) Received: from Matt-Holdrege.verizon.net ([208.179.69.254]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IHG00L8RVMLG403@vms042.mailsrvcs.net> for capwap@frascone.com; Thu, 02 Jun 2005 12:08:48 -0500 (CDT) From: Matt Holdrege Subject: Re: [Capwap] IEEE Review 13 - Protocol security In-reply-to: <200506021650.j52GoLPb050882@homebrew.trpz.com> X-Sender: res06gzk@incoming.verizon.net To: Dan Harkins , "Darren Loher" Cc: "Saravanan Govindan" , capwap@frascone.com Message-id: <6.1.2.0.2.20050602100150.032751a0@incoming.verizon.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Content-type: text/plain; charset=us-ascii; format=flowed References: <200506021650.j52GoLPb050882@homebrew.trpz.com> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 02 Jun 2005 10:08:44 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Also remember that an AC is a *function* and not necessarily an isolated piece of hardware. That function may operate anywhere in a network. It may operate on a laptop PC owned and operated by a hacker. So unless I'm missing something (quite possible!), I don't see how you can avoid a requirement for mutual authentication. I understand the burden placed on rolling out cheap AP's which must support this, but hey, security always costs you something. And the end user can choose to turn it off as they often do. -Matt At 09:50 AM 6/2/2005, Dan Harkins wrote: > Darren, > > Yes, I understand that a rogue AC is a realistic possibility, I am >not questioning that. But what is the threat that it poses? It has >nothing to do with the 45% of the people you mention in an FBI survey. > > In the Objective draft it describes threats posed by a rogue WTP >and then says that mutual authentication is required. Mutual authen- >tication is not required to address the threats described. Don't get me >wrong. I'm all in favor of mutual authentication but I'd like to >know the threat that is being addressed by having the AC authenticate >itself to the WTP. > > There are configuration and management implications to mutual >authentication-- precludes zero-config drop ship, requires some form >of staging, scales less well. (Experience has shown that this added >burden is enough to make some in IT so upset that they will actually >gut the security of their key management protocol. I speak of the >XAUTH hack to IKE). Because of this I think it is imperative that the >threat(s) requring mutual authentication be spelled out. If they can't >then the only alternative is to not make mutual authentication required. > > There's a reason why you don't need a personal certificate to purchase >things from Amazon. And that is not because the possibility of a >"rogue purchaser" is zero. It is because the threat that a "rogue >purchaser" poses is not worth the trouble of requiring mutual authen- >tication before selecting your purchase. A "rogue company" (a phishing >expedition) is a possibility and the threats from that are well >documented but, like with the current Objectives draft, those threats >are not addressed by mutual authentication. > > Again, I'm not against mutual authentication. I'm just saying that >it hasn't been justified and it needs to be because its cost is >not trivial. > > Dan. > >On Wed, 01 Jun 2005 16:05:01 PDT you wrote > > If the path between a WTP and a AC contains an untrusted link(s), then > > there is a possibility of a Rogue-AC. If the path between the WTP and > > AC contains a wireless link then the likelyhood of a rogue AC seems just > > as likely as a Rogue-WTP. > > > > Such a configuration is a reasonable scenario. Wifi hotspot providers > > often operate over an un-trusted network between the AC and the WTP. > > Often it is desirable for an enterprise to use their shared wired > > infrastructure for management between WTP's and AC's. This shared > > network may be trusted for general systems access, but not for network > > control. > > > > In many scenarios, having AC - WTP communition on the wired network is > > only a minor security advantage. There's the FBI Computer Crime and > > Security survey that listed 45% of respondents saying they have detected > > unauthorized access by insiders. Quotes from the 2003 report at > > http://www.crime-research.org/news/01.06.2004/283/ > > > > I strongly support mutual authentication as a "MUST" have requirement. > > > > -Darren > > > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On Behalf Of Dan Harkins > > > Sent: Wednesday, June 01, 2005 9:33 AM > > > To: Saravanan Govindan > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] IEEE Review 13 - Protocol security > > > > > > Saravanan, > > > > > > I clearly understand the threat posed by a "rogue WTP" but > > > what is the threat posed by a "rogue AC"? A CAPWAP-capable > > > WTP is not service providing all by its lonesome. It requires > > > an AC to provision and control it, and to forward packets for > > > its associated STAs. With that in mind the only thing I can > > > see a "rogue AC" doing is analagous to physical theft. > > > It can induce WTPs to be controlled and provisioned by it > > > instead of a different, legitimate, AC. It cannot gain access > > > to a wired network, only put a WTP's associated STAs on its > > > network (if it has one). > > > > > > If the "rogue AC" is something CAPWAP MUST prevent then I'd > > > like to see some text describing the threat to justify it. If > > > the "rogue AC" > > > is not something that CAPWAP MUST prevent (i.e. it SHOULD > > > prevent) then the requirement for mutual authentication > > > should also be a SHOULD. > > > > > > Dan. > > > > > > On Wed, 01 Jun 2005 18:22:24 +0800 you wrote > > > > Section 5.1.8 - CAPWAP Protocol Secuirty (Description) > > > > > > > > Comment: > > > > > > > > Justify mutual authentication requirement > > > > > > > > > > > > Existing text: > > > > > > > > The CAPWAP protocol must first provide for the > > > participating entities > > > > - WLAN controller and WTPs - to be mutually authenticated. > > > This is to > > > > ensure that rogue WTPs do not breach legitimate WLAN systems. For > > > > example, WTPs may need to regularly renew their > > > authentication state > > > > with the WLAN controller. > > > > > > > > > > > > Proposed change: > > > > > > > > The following changes include text from Charles Clancy. > > > > > > > > "The CAPWAP protocol must first provide for the > > > participating entities > > > > - WLAN controller and WTPs - to be mutually authenticated. > > > This is to > > > > ensure that rogue elements do not gain access to the WLAN system. > > > > Rogue WTPs should not be allowed to breahch legitimate WLANs and at > > > > the same time rogue WLAN controllers should not be allowed to gain > > > > control of legitimate WTPs. For example, WTPs may need to regularly > > > > renew their authentication state with the WLAN controller and > > > > similarly for WLAN controllers. > > > > > > > > If authentication is performed via an authenticated key exchange, > > > > future knowledge of derived keys is not sufficient for > > > authentication. > > > > > > > > Any session keys used between the AC and WTP MUST be > > > mutually drived > > > > using entropy contributed by both parties. This ensures > > > that no one > > > > party has control over the resulting session keys." > > > > : > > > > : > > > > "CAPWAP should not prevent the use of asymmetric > > > authentication. The > > > > security considerations of such asymmetric authentication are > > > > described in the Security Considerations section." > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > >_______________________________________________ >Capwap mailing list >Capwap@frascone.com >http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 2 13:34:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10098 for ; Thu, 2 Jun 2005 13:34:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CBF2B20353; Thu, 2 Jun 2005 13:34:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C51522027E; Thu, 2 Jun 2005 13:34:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2880F2027E for ; Thu, 2 Jun 2005 13:33:16 -0400 (EDT) Received: from carrierpigeon.cs.umd.edu (carrierpigeon.cs.umd.edu [128.8.129.58]) by mail.frascone.com (Postfix) with ESMTP id EEAB81FE11 for ; Thu, 2 Jun 2005 13:33:14 -0400 (EDT) Received: from ismene (ismene.cs.umd.edu [128.8.126.62]) by carrierpigeon.cs.umd.edu (8.12.10/8.12.5) with ESMTP id j52HO7tS020553; Thu, 2 Jun 2005 13:24:07 -0400 (EDT) From: Charles Clancy X-X-Sender: clancy@ismene To: Matt Holdrege Cc: Dan Harkins , Darren Loher , Saravanan Govindan , capwap@frascone.com Subject: Re: [Capwap] IEEE Review 13 - Protocol security In-Reply-To: <6.1.2.0.2.20050602100150.032751a0@incoming.verizon.net> Message-ID: References: <200506021650.j52GoLPb050882@homebrew.trpz.com> <6.1.2.0.2.20050602100150.032751a0@incoming.verizon.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 2 Jun 2005 13:20:09 -0400 (EDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I don't agree that mutual authentication is any more difficult than one-way authentication from a deployment perspective. To keep it simple, let's look at two basic authentication schemes -- preshared key and public key. In a preshared-key approach, both the WTP and AC need to know some static key. Mutual authentication can be accomplished by virtue of both parties knowing the key. Initial configuration of the WTP involves loading the key onto the client in some way -- this would have to be done even if the protocol did WTP->AC authentication only. Thus mutual authentication has no effect on deployments -- just two round-trips instead of one during the authentication phase. Now, in a public-key approach, you have to preload the WTP's key pair onto the device in order to perform one-way WTP->AC authentication. During this loading process, is it any more difficult to load some CA certificate as well? This CA certificate can verify a certification path for the AC certificate presented during authentication. IMHO, mutual authentication MUST be a MUST. [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] On Thu, 2 Jun 2005, Matt Holdrege wrote: > Also remember that an AC is a *function* and not necessarily an isolated > piece of hardware. That function may operate anywhere in a network. It may > operate on a laptop PC owned and operated by a hacker. So unless I'm missing > something (quite possible!), I don't see how you can avoid a requirement for > mutual authentication. > > I understand the burden placed on rolling out cheap AP's which must support > this, but hey, security always costs you something. And the end user can > choose to turn it off as they often do. > > -Matt > > At 09:50 AM 6/2/2005, Dan Harkins wrote: >> Darren, >> >> Yes, I understand that a rogue AC is a realistic possibility, I am >> not questioning that. But what is the threat that it poses? It has >> nothing to do with the 45% of the people you mention in an FBI survey. >> >> In the Objective draft it describes threats posed by a rogue WTP >> and then says that mutual authentication is required. Mutual authen- >> tication is not required to address the threats described. Don't get me >> wrong. I'm all in favor of mutual authentication but I'd like to >> know the threat that is being addressed by having the AC authenticate >> itself to the WTP. >> >> There are configuration and management implications to mutual >> authentication-- precludes zero-config drop ship, requires some form >> of staging, scales less well. (Experience has shown that this added >> burden is enough to make some in IT so upset that they will actually >> gut the security of their key management protocol. I speak of the >> XAUTH hack to IKE). Because of this I think it is imperative that the >> threat(s) requring mutual authentication be spelled out. If they can't >> then the only alternative is to not make mutual authentication required. >> >> There's a reason why you don't need a personal certificate to purchase >> things from Amazon. And that is not because the possibility of a >> "rogue purchaser" is zero. It is because the threat that a "rogue >> purchaser" poses is not worth the trouble of requiring mutual authen- >> tication before selecting your purchase. A "rogue company" (a phishing >> expedition) is a possibility and the threats from that are well >> documented but, like with the current Objectives draft, those threats >> are not addressed by mutual authentication. >> >> Again, I'm not against mutual authentication. I'm just saying that >> it hasn't been justified and it needs to be because its cost is >> not trivial. >> >> Dan. >> >> On Wed, 01 Jun 2005 16:05:01 PDT you wrote >> > If the path between a WTP and a AC contains an untrusted link(s), then >> > there is a possibility of a Rogue-AC. If the path between the WTP and >> > AC contains a wireless link then the likelyhood of a rogue AC seems just >> > as likely as a Rogue-WTP. >> > >> > Such a configuration is a reasonable scenario. Wifi hotspot providers >> > often operate over an un-trusted network between the AC and the WTP. >> > Often it is desirable for an enterprise to use their shared wired >> > infrastructure for management between WTP's and AC's. This shared >> > network may be trusted for general systems access, but not for network >> > control. >> > >> > In many scenarios, having AC - WTP communition on the wired network is >> > only a minor security advantage. There's the FBI Computer Crime and >> > Security survey that listed 45% of respondents saying they have detected >> > unauthorized access by insiders. Quotes from the 2003 report at >> > http://www.crime-research.org/news/01.06.2004/283/ >> > >> > I strongly support mutual authentication as a "MUST" have requirement. >> > >> > -Darren >> > >> > >> > > -----Original Message----- >> > > From: capwap-admin@frascone.com >> > > [mailto:capwap-admin@frascone.com] On Behalf Of Dan Harkins >> > > Sent: Wednesday, June 01, 2005 9:33 AM >> > > To: Saravanan Govindan >> > > Cc: capwap@frascone.com >> > > Subject: Re: [Capwap] IEEE Review 13 - Protocol security >> > > >> > > Saravanan, >> > > >> > > I clearly understand the threat posed by a "rogue WTP" but >> > > what is the threat posed by a "rogue AC"? A CAPWAP-capable >> > > WTP is not service providing all by its lonesome. It requires >> > > an AC to provision and control it, and to forward packets for >> > > its associated STAs. With that in mind the only thing I can >> > > see a "rogue AC" doing is analagous to physical theft. >> > > It can induce WTPs to be controlled and provisioned by it >> > > instead of a different, legitimate, AC. It cannot gain access >> > > to a wired network, only put a WTP's associated STAs on its >> > > network (if it has one). >> > > >> > > If the "rogue AC" is something CAPWAP MUST prevent then I'd >> > > like to see some text describing the threat to justify it. If >> > > the "rogue AC" >> > > is not something that CAPWAP MUST prevent (i.e. it SHOULD >> > > prevent) then the requirement for mutual authentication >> > > should also be a SHOULD. >> > > >> > > Dan. >> > > >> > > On Wed, 01 Jun 2005 18:22:24 +0800 you wrote >> > > > Section 5.1.8 - CAPWAP Protocol Secuirty (Description) >> > > > >> > > > Comment: >> > > > >> > > > Justify mutual authentication requirement >> > > > >> > > > >> > > > Existing text: >> > > > >> > > > The CAPWAP protocol must first provide for the >> > > participating entities >> > > > - WLAN controller and WTPs - to be mutually authenticated. >> > > This is to >> > > > ensure that rogue WTPs do not breach legitimate WLAN systems. For >> > > > example, WTPs may need to regularly renew their >> > > authentication state >> > > > with the WLAN controller. >> > > > >> > > > >> > > > Proposed change: >> > > > >> > > > The following changes include text from Charles Clancy. >> > > > >> > > > "The CAPWAP protocol must first provide for the >> > > participating entities >> > > > - WLAN controller and WTPs - to be mutually authenticated. >> > > This is to >> > > > ensure that rogue elements do not gain access to the WLAN system. >> > > > Rogue WTPs should not be allowed to breahch legitimate WLANs and at >> > > > the same time rogue WLAN controllers should not be allowed to gain >> > > > control of legitimate WTPs. For example, WTPs may need to regularly >> > > > renew their authentication state with the WLAN controller and >> > > > similarly for WLAN controllers. >> > > > >> > > > If authentication is performed via an authenticated key exchange, >> > > > future knowledge of derived keys is not sufficient for >> > > authentication. >> > > > >> > > > Any session keys used between the AC and WTP MUST be >> > > mutually drived >> > > > using entropy contributed by both parties. This ensures >> > > that no one >> > > > party has control over the resulting session keys." >> > > > : >> > > > : >> > > > "CAPWAP should not prevent the use of asymmetric >> > > authentication. The >> > > > security considerations of such asymmetric authentication are >> > > > described in the Security Considerations section." >> > > > _______________________________________________ >> > > > Capwap mailing list >> > > > Capwap@frascone.com >> > > > http://mail.frascone.com/mailman/listinfo/capwap >> > > > >> > > _______________________________________________ >> > > Capwap mailing list >> > > Capwap@frascone.com >> > > http://mail.frascone.com/mailman/listinfo/capwap >> > > >> > >> _______________________________________________ >> Capwap mailing list >> Capwap@frascone.com >> http://mail.frascone.com/mailman/listinfo/capwap > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 2 13:47:16 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10962 for ; Thu, 2 Jun 2005 13:47:12 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D81A420373; Thu, 2 Jun 2005 13:47:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D5899202AD; Thu, 2 Jun 2005 13:47:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E7205202AD for ; Thu, 2 Jun 2005 13:46:45 -0400 (EDT) Received: from smtp4.centerbeam.com (smtp4.centerbeam.com [63.120.115.248]) by mail.frascone.com (Postfix) with ESMTP id D1A4D1FE11 for ; Thu, 2 Jun 2005 13:46:43 -0400 (EDT) Received: from CBA0E2K01.CBA0.centerbeam.com ([64.95.101.24]) by smtp4.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Jun 2005 10:47:36 -0700 Received: from CBA0E2K06.CBA0.centerbeam.com ([64.95.101.40]) by CBA0E2K01.CBA0.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Jun 2005 10:46:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] IEEE Review 13 - Protocol security Message-ID: Thread-Topic: [Capwap] IEEE Review 13 - Protocol security Thread-Index: AcVnk7+Witqx0ilgT3q38Ska45EbmAAARTeQ From: "Darren Loher" To: "Dan Harkins" Cc: "Saravanan Govindan" , X-OriginalArrivalTime: 02 Jun 2005 17:46:29.0624 (UTC) FILETIME=[01B63F80:01C5679B] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 2 Jun 2005 10:46:30 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Two threats immediately come to mind for rogue AC that must be addressable are: Various nan in the middle attacks - Rogue AC can configure WTP to disable authentication requirements between STA and WTP, or change/slave the WTP to the Rogue AC's authentication proxy, capturing all STA passwords, etc. - Rogue AC can configure WTP to tunnel user data through an intermediate, packet capturing proxy=20 However, your points are absolutely valid! If it is too difficult, it won't be used. I'd say those points are a good case for supporting various authentication methods and asymmetric authentication. A simple authentication mechanism could be used for the WTP to authenticate the AC for initial setup to ensure the initial installation is an automated operation. =20 Zero configuration of the WTP could be supported using a pre-shared key: - AC and WTP loaded with a standard key from the factory - The AC or WTP discover each other using whatever mechanism - The WTP could check the shared key for the AC=20 - The AC could then configure the WTP to use a stronger mechanism to authenticate the AC if desired, providing stronger protection of the WTP against rogue AC's after the initial configuration This approach does leave new WTP's open to being hijacked at install time after the value of the pre-shared key gets out. But after initial configuration, the mutual authentication could be updated to a new pre-shared key or public key/certificate if the administrator chooses. This is still quite valuable as the WTP is only vulnerable at install time. In addition, a WTP hijacked at install time would show up as a rogue WTP if over the air methods are used to detect such WTP's. -Darren > -----Original Message----- > From: Dan Harkins [mailto:dharkins@trpz.com]=20 > Sent: Thursday, June 02, 2005 10:50 AM > To: Darren Loher > Cc: Saravanan Govindan; capwap@frascone.com > Subject: Re: [Capwap] IEEE Review 13 - Protocol security=20 >=20 > Darren, >=20 > Yes, I understand that a rogue AC is a realistic=20 > possibility, I am not questioning that. But what is the=20 > threat that it poses? It has nothing to do with the 45% of=20 > the people you mention in an FBI survey. >=20 > In the Objective draft it describes threats posed by a=20 > rogue WTP and then says that mutual authentication is=20 > required. Mutual authen- tication is not required to address=20 > the threats described. Don't get me wrong. I'm all in favor=20 > of mutual authentication but I'd like to know the threat that=20 > is being addressed by having the AC authenticate itself to the WTP. >=20 > There are configuration and management implications to mutual > authentication-- precludes zero-config drop ship, requires=20 > some form of staging, scales less well. (Experience has shown=20 > that this added burden is enough to make some in IT so upset=20 > that they will actually gut the security of their key=20 > management protocol. I speak of the XAUTH hack to IKE).=20 > Because of this I think it is imperative that the > threat(s) requring mutual authentication be spelled out. If=20 > they can't then the only alternative is to not make mutual=20 > authentication required.=20 >=20 > There's a reason why you don't need a personal certificate=20 > to purchase things from Amazon. And that is not because the=20 > possibility of a "rogue purchaser" is zero. It is because the=20 > threat that a "rogue purchaser" poses is not worth the=20 > trouble of requiring mutual authen- tication before selecting=20 > your purchase. A "rogue company" (a phishing > expedition) is a possibility and the threats from that are=20 > well documented but, like with the current Objectives draft,=20 > those threats are not addressed by mutual authentication. >=20 > Again, I'm not against mutual authentication. I'm just=20 > saying that it hasn't been justified and it needs to be=20 > because its cost is not trivial. > =09 > Dan. >=20 > On Wed, 01 Jun 2005 16:05:01 PDT you wrote > > If the path between a WTP and a AC contains an untrusted=20 > link(s), then=20 > > there is a possibility of a Rogue-AC. If the path between=20 > the WTP and=20 > > AC contains a wireless link then the likelyhood of a rogue AC seems=20 > > just as likely as a Rogue-WTP. > >=20 > > Such a configuration is a reasonable scenario. Wifi=20 > hotspot providers=20 > > often operate over an un-trusted network between the AC and the WTP. > > Often it is desirable for an enterprise to use their shared wired=20 > > infrastructure for management between WTP's and AC's. This shared=20 > > network may be trusted for general systems access, but not=20 > for network=20 > > control. > >=20 > > In many scenarios, having AC - WTP communition on the wired=20 > network is=20 > > only a minor security advantage. There's the FBI Computer=20 > Crime and=20 > > Security survey that listed 45% of respondents saying they have=20 > > detected unauthorized access by insiders. Quotes from the=20 > 2003 report=20 > > at http://www.crime-research.org/news/01.06.2004/283/ > >=20 > > I strongly support mutual authentication as a "MUST" have=20 > requirement. > >=20 > > -Darren > >=20 > >=20 > > > -----Original Message----- > > > From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On Behalf Of Dan Harkins > > > Sent: Wednesday, June 01, 2005 9:33 AM > > > To: Saravanan Govindan > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] IEEE Review 13 - Protocol security > > >=20 > > > Saravanan, > > >=20 > > > I clearly understand the threat posed by a "rogue WTP"=20 > but what is=20 > > > the threat posed by a "rogue AC"? A CAPWAP-capable WTP is not=20 > > > service providing all by its lonesome. It requires an AC to=20 > > > provision and control it, and to forward packets for its=20 > associated=20 > > > STAs. With that in mind the only thing I can see a "rogue=20 > AC" doing=20 > > > is analagous to physical theft. > > > It can induce WTPs to be controlled and provisioned by it=20 > instead of=20 > > > a different, legitimate, AC. It cannot gain access to a wired=20 > > > network, only put a WTP's associated STAs on its network=20 > (if it has=20 > > > one). > > >=20 > > > If the "rogue AC" is something CAPWAP MUST prevent then=20 > I'd like=20 > > > to see some text describing the threat to justify it. If=20 > the "rogue=20 > > > AC" > > > is not something that CAPWAP MUST prevent (i.e. it SHOULD > > > prevent) then the requirement for mutual authentication=20 > should also=20 > > > be a SHOULD. > > >=20 > > > Dan. > > >=20 > > > On Wed, 01 Jun 2005 18:22:24 +0800 you wrote > > > > Section 5.1.8 - CAPWAP Protocol Secuirty (Description) > > > >=20 > > > > Comment: > > > >=20 > > > > Justify mutual authentication requirement > > > >=20 > > > >=20 > > > > Existing text: > > > >=20 > > > > The CAPWAP protocol must first provide for the > > > participating entities > > > > - WLAN controller and WTPs - to be mutually authenticated. =20 > > > This is to > > > > ensure that rogue WTPs do not breach legitimate WLAN=20 > systems. For=20 > > > > example, WTPs may need to regularly renew their > > > authentication state > > > > with the WLAN controller. > > > >=20 > > > >=20 > > > > Proposed change: > > > >=20 > > > > The following changes include text from Charles Clancy.=20 > > > >=20 > > > > "The CAPWAP protocol must first provide for the > > > participating entities > > > > - WLAN controller and WTPs - to be mutually authenticated. =20 > > > This is to > > > > ensure that rogue elements do not gain access to the=20 > WLAN system.=20 > > > > Rogue WTPs should not be allowed to breahch legitimate=20 > WLANs and=20 > > > > at the same time rogue WLAN controllers should not be=20 > allowed to=20 > > > > gain control of legitimate WTPs. For example, WTPs may need to=20 > > > > regularly renew their authentication state with the WLAN=20 > > > > controller and similarly for WLAN controllers. > > > >=20 > > > > If authentication is performed via an authenticated key=20 > exchange,=20 > > > > future knowledge of derived keys is not sufficient for > > > authentication. > > > >=20 > > > > Any session keys used between the AC and WTP MUST be > > > mutually drived > > > > using entropy contributed by both parties. This ensures > > > that no one > > > > party has control over the resulting session keys." > > > > : > > > > : > > > > "CAPWAP should not prevent the use of asymmetric > > > authentication. The > > > > security considerations of such asymmetric authentication are=20 > > > > described in the Security Considerations section." > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > >=20 > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > >=20 > >=20 >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 2 13:52:15 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11315 for ; Thu, 2 Jun 2005 13:52:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BEBC220377; Thu, 2 Jun 2005 13:52:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 057A820234; Thu, 2 Jun 2005 13:52:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 19D1720234 for ; Thu, 2 Jun 2005 13:51:46 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 97E1F1FE11 for ; Thu, 2 Jun 2005 13:51:43 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j52Hm73B051190; Thu, 2 Jun 2005 10:48:07 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200506021748.j52Hm73B051190@homebrew.trpz.com> To: Matt Holdrege Cc: "Darren Loher" , "Saravanan Govindan" , capwap@frascone.com Subject: Re: [Capwap] IEEE Review 13 - Protocol security In-Reply-To: Your message of "Thu, 02 Jun 2005 10:08:44 PDT." <6.1.2.0.2.20050602100150.032751a0@incoming.verizon.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <51188.1117734487.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 02 Jun 2005 10:48:07 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Matt, I notice, further down in my inbox, that Saravanan sent out some additional text that sort of justifies it. But let me respond to you. OK, let's say that I'm a hacker, that my laptop implements the AC side of CAPWAP and I induse a WTP to become controlled and provisioned by me instead of the enterprise's AC which should be controlling and provisioning it. So now what can I do and what can I not do with that WTP? (Substitute "starbucks" for "enterprise" below if that's your cup of chai). - I can configure it so it can look like the legitimate enterprise's WTP. But, assuming 802.11i is used, a client will not successfully authenticate to the WTP. If you're not using 802.11i then this is just the same as going down to Fry's and buying a cutrate AP and configuring it to beacon out the enterprise's legitimate SSID and associated IEs. Nothing really new here and nothing that is necessarily solved by requiring mutual authentication in CAPWAP. - I cannot gain access to the enterprise's network. - I can configure it so that it will become part of my network. This is analagous to theft. I've just stolen the enterprise's property because I provisioned it to be part of my network. This is the threat that I brought up in my original post in this thread. I could redirect people to my services instead of the services of the legitimate enterprise. And I can expand my network without having to purchase the hardware that one normally would need to purchase. Yes, it's possible that a rogue AC can exist. It is important, though, to look at the threat it poses and why it is or is not worthwhile to address it. Saravanan has new text that mentions the last threat that I listed. That's great! Now we know why we need mutual authentication because the previous version of the Objectives draft didn't have that. Dan. On Thu, 02 Jun 2005 10:08:44 PDT you wrote > Also remember that an AC is a *function* and not necessarily an isolated > piece of hardware. That function may operate anywhere in a network. It may > operate on a laptop PC owned and operated by a hacker. So unless I'm > missing something (quite possible!), I don't see how you can avoid a > requirement for mutual authentication. > > I understand the burden placed on rolling out cheap AP's which must support > this, but hey, security always costs you something. And the end user can > choose to turn it off as they often do. > > -Matt > > At 09:50 AM 6/2/2005, Dan Harkins wrote: > > Darren, > > > > Yes, I understand that a rogue AC is a realistic possibility, I am > >not questioning that. But what is the threat that it poses? It has > >nothing to do with the 45% of the people you mention in an FBI survey. > > > > In the Objective draft it describes threats posed by a rogue WTP > >and then says that mutual authentication is required. Mutual authen- > >tication is not required to address the threats described. Don't get me > >wrong. I'm all in favor of mutual authentication but I'd like to > >know the threat that is being addressed by having the AC authenticate > >itself to the WTP. > > > > There are configuration and management implications to mutual > >authentication-- precludes zero-config drop ship, requires some form > >of staging, scales less well. (Experience has shown that this added > >burden is enough to make some in IT so upset that they will actually > >gut the security of their key management protocol. I speak of the > >XAUTH hack to IKE). Because of this I think it is imperative that the > >threat(s) requring mutual authentication be spelled out. If they can't > >then the only alternative is to not make mutual authentication required. > > > > There's a reason why you don't need a personal certificate to purchase > >things from Amazon. And that is not because the possibility of a > >"rogue purchaser" is zero. It is because the threat that a "rogue > >purchaser" poses is not worth the trouble of requiring mutual authen- > >tication before selecting your purchase. A "rogue company" (a phishing > >expedition) is a possibility and the threats from that are well > >documented but, like with the current Objectives draft, those threats > >are not addressed by mutual authentication. > > > > Again, I'm not against mutual authentication. I'm just saying that > >it hasn't been justified and it needs to be because its cost is > >not trivial. > > > > Dan. > > > >On Wed, 01 Jun 2005 16:05:01 PDT you wrote > > > If the path between a WTP and a AC contains an untrusted link(s), then > > > there is a possibility of a Rogue-AC. If the path between the WTP and > > > AC contains a wireless link then the likelyhood of a rogue AC seems just > > > as likely as a Rogue-WTP. > > > > > > Such a configuration is a reasonable scenario. Wifi hotspot providers > > > often operate over an un-trusted network between the AC and the WTP. > > > Often it is desirable for an enterprise to use their shared wired > > > infrastructure for management between WTP's and AC's. This shared > > > network may be trusted for general systems access, but not for network > > > control. > > > > > > In many scenarios, having AC - WTP communition on the wired network is > > > only a minor security advantage. There's the FBI Computer Crime and > > > Security survey that listed 45% of respondents saying they have detected > > > unauthorized access by insiders. Quotes from the 2003 report at > > > http://www.crime-research.org/news/01.06.2004/283/ > > > > > > I strongly support mutual authentication as a "MUST" have requirement. > > > > > > -Darren > > > > > > > > > > -----Original Message----- > > > > From: capwap-admin@frascone.com > > > > [mailto:capwap-admin@frascone.com] On Behalf Of Dan Harkins > > > > Sent: Wednesday, June 01, 2005 9:33 AM > > > > To: Saravanan Govindan > > > > Cc: capwap@frascone.com > > > > Subject: Re: [Capwap] IEEE Review 13 - Protocol security > > > > > > > > Saravanan, > > > > > > > > I clearly understand the threat posed by a "rogue WTP" but > > > > what is the threat posed by a "rogue AC"? A CAPWAP-capable > > > > WTP is not service providing all by its lonesome. It requires > > > > an AC to provision and control it, and to forward packets for > > > > its associated STAs. With that in mind the only thing I can > > > > see a "rogue AC" doing is analagous to physical theft. > > > > It can induce WTPs to be controlled and provisioned by it > > > > instead of a different, legitimate, AC. It cannot gain access > > > > to a wired network, only put a WTP's associated STAs on its > > > > network (if it has one). > > > > > > > > If the "rogue AC" is something CAPWAP MUST prevent then I'd > > > > like to see some text describing the threat to justify it. If > > > > the "rogue AC" > > > > is not something that CAPWAP MUST prevent (i.e. it SHOULD > > > > prevent) then the requirement for mutual authentication > > > > should also be a SHOULD. > > > > > > > > Dan. > > > > > > > > On Wed, 01 Jun 2005 18:22:24 +0800 you wrote > > > > > Section 5.1.8 - CAPWAP Protocol Secuirty (Description) > > > > > > > > > > Comment: > > > > > > > > > > Justify mutual authentication requirement > > > > > > > > > > > > > > > Existing text: > > > > > > > > > > The CAPWAP protocol must first provide for the > > > > participating entities > > > > > - WLAN controller and WTPs - to be mutually authenticated. > > > > This is to > > > > > ensure that rogue WTPs do not breach legitimate WLAN systems. For > > > > > example, WTPs may need to regularly renew their > > > > authentication state > > > > > with the WLAN controller. > > > > > > > > > > > > > > > Proposed change: > > > > > > > > > > The following changes include text from Charles Clancy. > > > > > > > > > > "The CAPWAP protocol must first provide for the > > > > participating entities > > > > > - WLAN controller and WTPs - to be mutually authenticated. > > > > This is to > > > > > ensure that rogue elements do not gain access to the WLAN system. > > > > > Rogue WTPs should not be allowed to breahch legitimate WLANs and at > > > > > the same time rogue WLAN controllers should not be allowed to gain > > > > > control of legitimate WTPs. For example, WTPs may need to regularly > > > > > renew their authentication state with the WLAN controller and > > > > > similarly for WLAN controllers. > > > > > > > > > > If authentication is performed via an authenticated key exchange, > > > > > future knowledge of derived keys is not sufficient for > > > > authentication. > > > > > > > > > > Any session keys used between the AC and WTP MUST be > > > > mutually drived > > > > > using entropy contributed by both parties. This ensures > > > > that no one > > > > > party has control over the resulting session keys." > > > > > : > > > > > : > > > > > "CAPWAP should not prevent the use of asymmetric > > > > authentication. The > > > > > security considerations of such asymmetric authentication are > > > > > described in the Security Considerations section." > > > > > _______________________________________________ > > > > > Capwap mailing list > > > > > Capwap@frascone.com > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > >_______________________________________________ > >Capwap mailing list > >Capwap@frascone.com > >http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 2 14:24:10 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13320 for ; Thu, 2 Jun 2005 14:24:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 47184203E4; Thu, 2 Jun 2005 14:24:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 02DB920298; Thu, 2 Jun 2005 14:24:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1274620298 for ; Thu, 2 Jun 2005 14:23:07 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 75C3A201F6 for ; Thu, 2 Jun 2005 14:23:03 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j52IJObH051291; Thu, 2 Jun 2005 11:19:24 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200506021819.j52IJObH051291@homebrew.trpz.com> To: Charles Clancy Cc: Matt Holdrege , Darren Loher , Saravanan Govindan , capwap@frascone.com Subject: Re: [Capwap] IEEE Review 13 - Protocol security In-Reply-To: Your message of "Thu, 02 Jun 2005 13:20:09 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <51289.1117736364.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 02 Jun 2005 11:19:24 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Charles, On Thu, 02 Jun 2005 13:20:09 EDT you wrote > I don't agree that mutual authentication is any more difficult than > one-way authentication from a deployment perspective. To keep it simple, > let's look at two basic authentication schemes -- preshared key and public > key. > > In a preshared-key approach, both the WTP and AC need to know some static > key. Mutual authentication can be accomplished by virtue of both parties > knowing the key. Initial configuration of the WTP involves loading the > key onto the client in some way -- this would have to be done even if the > protocol did WTP->AC authentication only. Thus mutual authentication has > no effect on deployments -- just two round-trips instead of one during the > authentication phase. That requires staging and precludes a zero-config drop ship. > Now, in a public-key approach, you have to preload the WTP's key pair onto > the device in order to perform one-way WTP->AC authentication. During > this loading process, is it any more difficult to load some CA certificate > as well? This CA certificate can verify a certification path for the AC > certificate presented during authentication. Whose CA certificate? Either it's the customer's which requires staging and has the same problems as pre-shared key, or it's the manufacturer's and then what sort of mutual authentication are you talking about? We don't want authentication that verifies the vendor of a WTP, we want authentication that verifies that it is the WTP we want to control and provision. That is, having a certificate in a WTP that say is signed by the vendor-- the Foobar AP company's CA-- is not interesting to an enterprise. So what? Is it the WTP that I purchased from the Foobar AP Company or is it the one that hacker purchased from the Foobar AP Company? An enterprise wants to put it's own certificate in the WTP. That, again, requires staging. Whether it's "difficult" to stage hundreds of WTPs or not is not my point. The point is that it is much more difficult than staging zero WTPs. Again, experience shows that people that buy these products we develop will go to extreme lengths-- even to gutting the security of the key exchange protocol-- to not have to put unique credentials on all products they deploy. If we're going to require that step than we MUST explain why it is necessary. > IMHO, mutual authentication MUST be a MUST. IMHO, justification for requirements MUST be a MUST. Dan. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 2 15:03:11 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17414 for ; Thu, 2 Jun 2005 15:03:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BC38620432; Thu, 2 Jun 2005 15:03:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D500320419; Thu, 2 Jun 2005 15:03:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4C21120419 for ; Thu, 2 Jun 2005 15:02:31 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 0876E203E4 for ; Thu, 2 Jun 2005 15:02:28 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j52IwnS8051453; Thu, 2 Jun 2005 11:58:51 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200506021858.j52IwnS8051453@homebrew.trpz.com> To: "Darren Loher" Cc: "Saravanan Govindan" , capwap@frascone.com Subject: Re: [Capwap] IEEE Review 13 - Protocol security In-Reply-To: Your message of "Thu, 02 Jun 2005 10:46:30 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <51451.1117738729.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 02 Jun 2005 11:58:49 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Darren, The man-in-the-middle attacks you describe would not work if 802.11i was used. If it wasn't then these attacks can still be mounted by configuring a generic cutrate AP, forget CAPWAP. It would not be possible to capture the STA's passwords because the STA authenticates the AS prior to devulging her passwords and she would not authenticate a rogue AS. Regarding the idea of loading a standard pre-shared key at the factory keep in mind that CAPWAP must be interoperable by different vendors so all vendors would have to use the same pre-shared key. Therefore let me refer you to the following (unfortunately now expired) Internet Draft: http://www.lounge.org/draft-ietf-ipsec-internet-key-00.txt I recommend reading the entire draft, it's pretty short, but check out the "Security Considerations" section. Then check out the date. For what it's worth I know of one company that shipped product that used that for authentication purposes as the "default pre-shared key" so there is precedense! Dan. On Thu, 02 Jun 2005 10:46:30 PDT you wrote > Two threats immediately come to mind for rogue AC that must be > addressable are: > > Various nan in the middle attacks > - Rogue AC can configure WTP to disable authentication requirements > between STA and WTP, or change/slave the WTP to the Rogue AC's > authentication proxy, capturing all STA passwords, etc. > - Rogue AC can configure WTP to tunnel user data through an > intermediate, packet capturing proxy > > However, your points are absolutely valid! If it is too difficult, it > won't be used. I'd say those points are a good case for supporting > various authentication methods and asymmetric authentication. A simple > authentication mechanism could be used for the WTP to authenticate the > AC for initial setup to ensure the initial installation is an automated > operation. > > Zero configuration of the WTP could be supported using a pre-shared key: > - AC and WTP loaded with a standard key from the factory > - The AC or WTP discover each other using whatever mechanism > - The WTP could check the shared key for the AC > - The AC could then configure the WTP to use a stronger mechanism to > authenticate the AC if desired, providing stronger protection of the WTP > against rogue AC's after the initial configuration > > This approach does leave new WTP's open to being hijacked at install > time after the value of the pre-shared key gets out. But after initial > configuration, the mutual authentication could be updated to a new > pre-shared key or public key/certificate if the administrator chooses. > This is still quite valuable as the WTP is only vulnerable at install > time. In addition, a WTP hijacked at install time would show up as a > rogue WTP if over the air methods are used to detect such WTP's. > > -Darren > > > > -----Original Message----- > > From: Dan Harkins [mailto:dharkins@trpz.com] > > Sent: Thursday, June 02, 2005 10:50 AM > > To: Darren Loher > > Cc: Saravanan Govindan; capwap@frascone.com > > Subject: Re: [Capwap] IEEE Review 13 - Protocol security > > > > Darren, > > > > Yes, I understand that a rogue AC is a realistic > > possibility, I am not questioning that. But what is the > > threat that it poses? It has nothing to do with the 45% of > > the people you mention in an FBI survey. > > > > In the Objective draft it describes threats posed by a > > rogue WTP and then says that mutual authentication is > > required. Mutual authen- tication is not required to address > > the threats described. Don't get me wrong. I'm all in favor > > of mutual authentication but I'd like to know the threat that > > is being addressed by having the AC authenticate itself to the WTP. > > > > There are configuration and management implications to mutual > > authentication-- precludes zero-config drop ship, requires > > some form of staging, scales less well. (Experience has shown > > that this added burden is enough to make some in IT so upset > > that they will actually gut the security of their key > > management protocol. I speak of the XAUTH hack to IKE). > > Because of this I think it is imperative that the > > threat(s) requring mutual authentication be spelled out. If > > they can't then the only alternative is to not make mutual > > authentication required. > > > > There's a reason why you don't need a personal certificate > > to purchase things from Amazon. And that is not because the > > possibility of a "rogue purchaser" is zero. It is because the > > threat that a "rogue purchaser" poses is not worth the > > trouble of requiring mutual authen- tication before selecting > > your purchase. A "rogue company" (a phishing > > expedition) is a possibility and the threats from that are > > well documented but, like with the current Objectives draft, > > those threats are not addressed by mutual authentication. > > > > Again, I'm not against mutual authentication. I'm just > > saying that it hasn't been justified and it needs to be > > because its cost is not trivial. > > > > Dan. > > > > On Wed, 01 Jun 2005 16:05:01 PDT you wrote > > > If the path between a WTP and a AC contains an untrusted > > link(s), then > > > there is a possibility of a Rogue-AC. If the path between > > the WTP and > > > AC contains a wireless link then the likelyhood of a rogue AC seems > > > just as likely as a Rogue-WTP. > > > > > > Such a configuration is a reasonable scenario. Wifi > > hotspot providers > > > often operate over an un-trusted network between the AC and the WTP. > > > Often it is desirable for an enterprise to use their shared wired > > > infrastructure for management between WTP's and AC's. This shared > > > network may be trusted for general systems access, but not > > for network > > > control. > > > > > > In many scenarios, having AC - WTP communition on the wired > > network is > > > only a minor security advantage. There's the FBI Computer > > Crime and > > > Security survey that listed 45% of respondents saying they have > > > detected unauthorized access by insiders. Quotes from the > > 2003 report > > > at http://www.crime-research.org/news/01.06.2004/283/ > > > > > > I strongly support mutual authentication as a "MUST" have > > requirement. > > > > > > -Darren > > > > > > > > > > -----Original Message----- > > > > From: capwap-admin@frascone.com > > > > [mailto:capwap-admin@frascone.com] On Behalf Of Dan Harkins > > > > Sent: Wednesday, June 01, 2005 9:33 AM > > > > To: Saravanan Govindan > > > > Cc: capwap@frascone.com > > > > Subject: Re: [Capwap] IEEE Review 13 - Protocol security > > > > > > > > Saravanan, > > > > > > > > I clearly understand the threat posed by a "rogue WTP" > > but what is > > > > the threat posed by a "rogue AC"? A CAPWAP-capable WTP is not > > > > service providing all by its lonesome. It requires an AC to > > > > provision and control it, and to forward packets for its > > associated > > > > STAs. With that in mind the only thing I can see a "rogue > > AC" doing > > > > is analagous to physical theft. > > > > It can induce WTPs to be controlled and provisioned by it > > instead of > > > > a different, legitimate, AC. It cannot gain access to a wired > > > > network, only put a WTP's associated STAs on its network > > (if it has > > > > one). > > > > > > > > If the "rogue AC" is something CAPWAP MUST prevent then > > I'd like > > > > to see some text describing the threat to justify it. If > > the "rogue > > > > AC" > > > > is not something that CAPWAP MUST prevent (i.e. it SHOULD > > > > prevent) then the requirement for mutual authentication > > should also > > > > be a SHOULD. > > > > > > > > Dan. > > > > > > > > On Wed, 01 Jun 2005 18:22:24 +0800 you wrote > > > > > Section 5.1.8 - CAPWAP Protocol Secuirty (Description) > > > > > > > > > > Comment: > > > > > > > > > > Justify mutual authentication requirement > > > > > > > > > > > > > > > Existing text: > > > > > > > > > > The CAPWAP protocol must first provide for the > > > > participating entities > > > > > - WLAN controller and WTPs - to be mutually authenticated. > > > > This is to > > > > > ensure that rogue WTPs do not breach legitimate WLAN > > systems. For > > > > > example, WTPs may need to regularly renew their > > > > authentication state > > > > > with the WLAN controller. > > > > > > > > > > > > > > > Proposed change: > > > > > > > > > > The following changes include text from Charles Clancy. > > > > > > > > > > "The CAPWAP protocol must first provide for the > > > > participating entities > > > > > - WLAN controller and WTPs - to be mutually authenticated. > > > > This is to > > > > > ensure that rogue elements do not gain access to the > > WLAN system. > > > > > Rogue WTPs should not be allowed to breahch legitimate > > WLANs and > > > > > at the same time rogue WLAN controllers should not be > > allowed to > > > > > gain control of legitimate WTPs. For example, WTPs may need to > > > > > regularly renew their authentication state with the WLAN > > > > > controller and similarly for WLAN controllers. > > > > > > > > > > If authentication is performed via an authenticated key > > exchange, > > > > > future knowledge of derived keys is not sufficient for > > > > authentication. > > > > > > > > > > Any session keys used between the AC and WTP MUST be > > > > mutually drived > > > > > using entropy contributed by both parties. This ensures > > > > that no one > > > > > party has control over the resulting session keys." > > > > > : > > > > > : > > > > > "CAPWAP should not prevent the use of asymmetric > > > > authentication. The > > > > > security considerations of such asymmetric authentication are > > > > > described in the Security Considerations section." > > > > > _______________________________________________ > > > > > Capwap mailing list > > > > > Capwap@frascone.com > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 2 15:08:10 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18167 for ; Thu, 2 Jun 2005 15:08:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 345A420443; Thu, 2 Jun 2005 15:08:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 406992041E; Thu, 2 Jun 2005 15:08:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E89B72041E for ; Thu, 2 Jun 2005 15:07:48 -0400 (EDT) Received: from carrierpigeon.cs.umd.edu (carrierpigeon.cs.umd.edu [128.8.129.58]) by mail.frascone.com (Postfix) with ESMTP id D92B1203E4 for ; Thu, 2 Jun 2005 15:07:46 -0400 (EDT) Received: from ismene (ismene.cs.umd.edu [128.8.126.62]) by carrierpigeon.cs.umd.edu (8.12.10/8.12.5) with ESMTP id j52J7jtS021176; Thu, 2 Jun 2005 15:07:45 -0400 (EDT) From: Charles Clancy X-X-Sender: clancy@ismene To: Dan Harkins Cc: Matt Holdrege , Darren Loher , Saravanan Govindan , capwap@frascone.com Subject: Re: [Capwap] IEEE Review 13 - Protocol security In-Reply-To: <200506021819.j52IJObH051291@homebrew.trpz.com> Message-ID: References: <200506021819.j52IJObH051291@homebrew.trpz.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 2 Jun 2005 15:03:47 -0400 (EDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > Whether it's "difficult" to stage hundreds of WTPs or not is not my > point. The point is that it is much more difficult than staging zero > WTPs. My point was that ANY cryptographically-secure one-way authentication will require staging, since you'll have to load some sort of long-term credential onto the client. Zero-config drop ships just aren't an option. So, if we're going to require WTP->AC authentication, there's not reason not to require mutual authentication. There are bootstrapping schemes that could securely provision keys to WTPs using, for example, a 4-digit numeric PIN. These schemes require less staging, but "less" is still more than "none". [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 2 16:41:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00052 for ; Thu, 2 Jun 2005 16:41:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 685B220361; Thu, 2 Jun 2005 16:41:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D37B42027D; Thu, 2 Jun 2005 16:41:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A98A520353 for ; Thu, 2 Jun 2005 16:40:04 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id F2397202BD for ; Thu, 2 Jun 2005 16:40:01 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j52KaLdt051891; Thu, 2 Jun 2005 13:36:21 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200506022036.j52KaLdt051891@homebrew.trpz.com> To: Charles Clancy Cc: Matt Holdrege , Darren Loher , Saravanan Govindan , capwap@frascone.com Subject: Re: [Capwap] IEEE Review 13 - Protocol security In-Reply-To: Your message of "Thu, 02 Jun 2005 15:03:47 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <51889.1117744581.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 02 Jun 2005 13:36:21 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Charles, I think you're misunderstanding me. I'm not saying that a secure connection is arrived out of nothing. The zero config I'm talking about is zero config of the WTP. Something must be done on the AC to cause it to trust the WTP's credential (which could be loaded at manufacture time). That scales much better than having to do something on the AC to cause it to trust the WTP's credential AND do something on the WTP to cause it to trust the AC's credential. That last step can be really really time consuming. Especially if it requires opening up a box, connecting the WTP to a power injector, connecting something to the WTP's console, doing the "monkey work" command, unplugging, putting it back in its case, readdressing it to the place where it ultimately will have to be installed (by someone whose technical expertise involves a ladder and a screwdriver), and sticking it on the loading dock to await FedEx. Do that for 100 WTPs. Or 500 WTPs. Or.... See my point? A zero config drop ship of the WTP would be much more appealing especially if the whole reason to require mutual authentication did not apply to the customer's deployment. But we've already agreed that there is a (small) reason to require the WTP to authenticate the AC and that is something analagous to physical theft and to theft of services provided through a WTP in some hotspot situation-- send the other company's customers to my expensive service instead of their less expensive service, "I thought this coffeehouse had a roaming agreement with the Blah Company, shoot, guess I'll have to pay the $5.95 cause I really need to check email but I'm not coming back here again". Obviously that is not the concern of all people who deploy WLANs so as long as we still require support for asymmetric authentication techniques which can be used with zero config drop ship all is well. (Note that the requirement is for supporting them, not using them). Dan. On Thu, 02 Jun 2005 15:03:47 EDT you wrote > > Whether it's "difficult" to stage hundreds of WTPs or not is not my > > point. The point is that it is much more difficult than staging zero > > WTPs. > > My point was that ANY cryptographically-secure one-way authentication will > require staging, since you'll have to load some sort of long-term > credential onto the client. Zero-config drop ships just aren't an option. > So, if we're going to require WTP->AC authentication, there's not reason > not to require mutual authentication. > > There are bootstrapping schemes that could securely provision keys to WTPs > using, for example, a 4-digit numeric PIN. These schemes require less > staging, but "less" is still more than "none". > > [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] > [ computer science ]-----[ university of maryland | college park ] > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 2 17:26:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02640 for ; Thu, 2 Jun 2005 17:26:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0407B20389; Thu, 2 Jun 2005 17:26:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0A37A20361; Thu, 2 Jun 2005 17:26:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7EDF020361 for ; Thu, 2 Jun 2005 17:25:26 -0400 (EDT) Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) by mail.frascone.com (Postfix) with ESMTP id 761CA1FC7B for ; Thu, 2 Jun 2005 17:25:23 -0400 (EDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j52LPEYt014824; Fri, 3 Jun 2005 00:25:14 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Jun 2005 00:25:13 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Jun 2005 16:25:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <893AE265F4ADF94AB7FB26D31A788E410C11A5@mvebe101.NOE.Nokia.com> Thread-Topic: Missed deadline for CAPWAP protocol individual evaluation draft Thread-Index: AcVnuY3RkUkjI5iBQ32Met8o57IseA== From: To: Cc: , , , X-OriginalArrivalTime: 02 Jun 2005 21:25:11.0570 (UTC) FILETIME=[8F004F20:01C567B9] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Missed deadline for CAPWAP protocol individual evaluation draft Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 2 Jun 2005 14:25:11 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable May 31st was the deadline to submit a self evaluation of the proposed protocols and how they meet the current CAPWAP Objectives, as stated in = an email sent to the WG list on 5/6/05: "The next step is for the champion of each protocol to submit an = individual draft describing how their protocol meets the Objectives = draft, the taxonomy draft and the Problem statement. The first version = of these drafts should be submitted to the WG by Tuesday, May 31st. Note the Objectives draft is still subject to change, and these = conformance drafts will have to be updated to reflect the new = objectives. We are requesting these individual evaluations before = finalizing the Objectives so the WG can begin commenting towards the = protocol evaluation as soon as possible." Three of the protocol submissions did not meet the individual protocol Objective evaluation deadline or attempt to provide an analysis of how their protocol meets the Objectives. The goal of this draft was to help the WG evaluate the objectives among the different protocols and give guidance to the Evaluation draft authors. Its disappointing that the authors did not take this responsibility seriously. This WG is very delay sensitive due to the market needs of this technology. We cannot afford to entertain delays in this process especially when all the protocol have been given an equal and fair amount of time to explain their approach to the Objectives. Obviously, protocol consensus can only be reached when the WG clearly understands the protocol, and creating the protocol Objectives analysis is a meaningful step towards an agreed CAPWAP protocol. This draft will be used by the evaluation authors to resolve objective disputes among the proposed protocols. The WG would like to thank the LWAPP authors for creating "http://www.capwap.org/draft-calhoun-capwap-lwapp-objectives-comparison-0= 0.txt" to help the WG evaluate the their protocol against the current = Objectives. =20 Regards, The WG Chairs. =20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 2 17:56:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04134 for ; Thu, 2 Jun 2005 17:56:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 23CC1203A5; Thu, 2 Jun 2005 17:56:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 935E020389; Thu, 2 Jun 2005 17:56:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BBC8120389 for ; Thu, 2 Jun 2005 17:55:48 -0400 (EDT) Received: from WNIMAIL.WoodsideNet.Com (wnifwl.woodsidenet.com [65.192.186.2]) by mail.frascone.com (Postfix) with ESMTP id 25FF12036B for ; Thu, 2 Jun 2005 17:55:45 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Missed deadline for CAPWAP protocol individual evaluation draft Message-ID: <3FFBC907DD03A34CA4410C5C745DEB1206AA651D@wnimail.WoodsideNet.Com> Thread-Topic: [Capwap] Missed deadline for CAPWAP protocol individual evaluation draft Thread-Index: AcVnuY3RkUkjI5iBQ32Met8o57IseAAA6f4g From: "Paul Lambert" To: , Cc: , , , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 2 Jun 2005 14:55:37 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable =20 >Its disappointing that the > authors did not take this responsibility seriously. This does seem to be a very unusual decison making process for the IETF. I do not see type of process in the IETF working group procedural handbook. Paul > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of=20 > Dorothy.Gellert@nokia.com > Sent: Thursday, June 02, 2005 2:25 PM > To: capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com;=20 > david.kessens@nokia.com; Dorothy.Gellert@nokia.com > Subject: [Capwap] Missed deadline for CAPWAP protocol=20 > individual evaluation draft >=20 >=20 > May 31st was the deadline to submit a self evaluation of the=20 > proposed protocols and how they meet the current CAPWAP=20 > Objectives, as stated in an email sent to the WG list on 5/6/05: >=20 > "The next step is for the champion of each protocol to submit=20 > an individual draft describing how their protocol meets the=20 > Objectives draft, the taxonomy draft and the Problem=20 > statement. The first version of these drafts should be=20 > submitted to the WG by Tuesday, May 31st. >=20 > Note the Objectives draft is still subject to change, and=20 > these conformance drafts will have to be updated to reflect=20 > the new objectives. We are requesting these individual=20 > evaluations before finalizing the Objectives so the WG can=20 > begin commenting towards the protocol evaluation as soon as possible." >=20 > Three of the protocol submissions did not meet the individual=20 > protocol Objective evaluation deadline or attempt to provide=20 > an analysis of how their protocol meets the Objectives. The=20 > goal of this draft was to help the WG evaluate the objectives=20 > among the different protocols and give > guidance to the Evaluation draft authors. Its disappointing that the > authors did not take this responsibility seriously. >=20 > This WG is very delay sensitive due to the market needs of=20 > this technology. We cannot afford to entertain delays in=20 > this process especially when all the protocol have been given=20 > an equal and fair amount of time to explain their approach to=20 > the Objectives. Obviously, protocol consensus can only be=20 > reached when the WG clearly understands the protocol, and=20 > creating the protocol Objectives analysis is a > meaningful step towards an agreed CAPWAP protocol. This=20 > draft will be > used by the evaluation authors to resolve objective disputes=20 > among the proposed protocols. >=20 > The WG would like to thank the LWAPP authors for creating > "http://www.capwap.org/draft-calhoun-capwap-lwapp-objectives-c > omparison-00.txt" to help the WG evaluate the their protocol=20 > against the current Objectives. =20 >=20 > Regards, > The WG Chairs. > =20 >=20 >=20 >=20 >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 2 18:15:10 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06366 for ; Thu, 2 Jun 2005 18:15:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F41C220435; Thu, 2 Jun 2005 18:15:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F22A920418; Thu, 2 Jun 2005 18:15:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5C23C203E4 for ; Thu, 2 Jun 2005 18:14:42 -0400 (EDT) Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) by mail.frascone.com (Postfix) with ESMTP id 5B2C02038C for ; Thu, 2 Jun 2005 18:14:39 -0400 (EDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j52MEMj7029560; Fri, 3 Jun 2005 01:14:28 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Jun 2005 01:13:34 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Jun 2005 17:13:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Missed deadline for CAPWAP protocol individual evaluation draft Message-ID: <893AE265F4ADF94AB7FB26D31A788E410C11A6@mvebe101.NOE.Nokia.com> Thread-Topic: [Capwap] Missed deadline for CAPWAP protocol individual evaluation draft Thread-Index: AcVnuY3RkUkjI5iBQ32Met8o57IseAAA6f4gAACGL5A= From: To: , Cc: , , , X-OriginalArrivalTime: 02 Jun 2005 22:13:30.0983 (UTC) FILETIME=[4F2F9F70:01C567C0] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 2 Jun 2005 15:13:30 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Paul,=20 The WG, chairs and ADs agree upon the milestones and deadlines within = the individual WGs to meet WG goals. =20 As always, the WG is open to discuss or comment upon these at any time, = but its best to do so before the deadlines pass, otherwise its difficult = to manage milestones. =20 -Dorothy -----Original Message----- From: ext Paul Lambert [mailto:PaulLambert@AirgoNetworks.Com] Sent: Thursday, June 02, 2005 2:56 PM To: Gellert Dorothy (Nokia-ES/MtView); capwap@frascone.com Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David (Nokia-NET/MtView); iab-execd@iab.org Subject: RE: [Capwap] Missed deadline for CAPWAP protocol individual evaluation draft =20 >Its disappointing that the > authors did not take this responsibility seriously. This does seem to be a very unusual decison making process for the IETF. I do not see type of process in the IETF working group procedural handbook. Paul > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of=20 > Dorothy.Gellert@nokia.com > Sent: Thursday, June 02, 2005 2:25 PM > To: capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com;=20 > david.kessens@nokia.com; Dorothy.Gellert@nokia.com > Subject: [Capwap] Missed deadline for CAPWAP protocol=20 > individual evaluation draft >=20 >=20 > May 31st was the deadline to submit a self evaluation of the=20 > proposed protocols and how they meet the current CAPWAP=20 > Objectives, as stated in an email sent to the WG list on 5/6/05: >=20 > "The next step is for the champion of each protocol to submit=20 > an individual draft describing how their protocol meets the=20 > Objectives draft, the taxonomy draft and the Problem=20 > statement. The first version of these drafts should be=20 > submitted to the WG by Tuesday, May 31st. >=20 > Note the Objectives draft is still subject to change, and=20 > these conformance drafts will have to be updated to reflect=20 > the new objectives. We are requesting these individual=20 > evaluations before finalizing the Objectives so the WG can=20 > begin commenting towards the protocol evaluation as soon as possible." >=20 > Three of the protocol submissions did not meet the individual=20 > protocol Objective evaluation deadline or attempt to provide=20 > an analysis of how their protocol meets the Objectives. The=20 > goal of this draft was to help the WG evaluate the objectives=20 > among the different protocols and give > guidance to the Evaluation draft authors. Its disappointing that the > authors did not take this responsibility seriously. >=20 > This WG is very delay sensitive due to the market needs of=20 > this technology. We cannot afford to entertain delays in=20 > this process especially when all the protocol have been given=20 > an equal and fair amount of time to explain their approach to=20 > the Objectives. Obviously, protocol consensus can only be=20 > reached when the WG clearly understands the protocol, and=20 > creating the protocol Objectives analysis is a > meaningful step towards an agreed CAPWAP protocol. This=20 > draft will be > used by the evaluation authors to resolve objective disputes=20 > among the proposed protocols. >=20 > The WG would like to thank the LWAPP authors for creating > "http://www.capwap.org/draft-calhoun-capwap-lwapp-objectives-c > omparison-00.txt" to help the WG evaluate the their protocol=20 > against the current Objectives. =20 >=20 > Regards, > The WG Chairs. > =20 >=20 >=20 >=20 >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 2 20:54:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15916 for ; Thu, 2 Jun 2005 20:54:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E81FC204AF; Thu, 2 Jun 2005 20:54:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 18CD22049F; Thu, 2 Jun 2005 20:54:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5666C2049F for ; Thu, 2 Jun 2005 20:53:13 -0400 (EDT) Received: from smtp4.centerbeam.com (smtp4.centerbeam.com [63.120.115.248]) by mail.frascone.com (Postfix) with ESMTP id 432E32043E for ; Thu, 2 Jun 2005 20:53:07 -0400 (EDT) Received: from CBA0E2K01.CBA0.centerbeam.com ([64.95.101.24]) by smtp4.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Jun 2005 17:51:59 -0700 Received: from CBA0E2K06.CBA0.centerbeam.com ([64.95.101.40]) by CBA0E2K01.CBA0.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Jun 2005 17:50:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] IEEE Review 13 - Protocol security Message-ID: Thread-Topic: [Capwap] IEEE Review 13 - Protocol security Thread-Index: AcVnpacmHQ6bqVX8SUKd48wJj36m8gABEsEA From: "Darren Loher" To: "Dan Harkins" Cc: "Saravanan Govindan" , X-OriginalArrivalTime: 03 Jun 2005 00:50:52.0408 (UTC) FILETIME=[4AB6BF80:01C567D6] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 2 Jun 2005 17:50:52 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Perhaps we can break this up into two parts: 1. day-one install=20 2. on going operations=20 The desire to have an easy, zero-touch day-one install does not have to preclude mandatory support for mutual authentication. Perhaps we should permit a "null" authentication method of the AC to be used for installation purposes. =20 After the AC and WTP discover each other via whatever method, as part of the first time configuration process the AC can instruct the WTP to perform authentication of the AC using a better method of the administrator's (the AC) choice. This would allow an automated, zero-touch installation approach which enables a "good" mutual authentication method for post-install operations. This minimizes risk of rogue AC to the WTP's install process. =20 Do we think think mutual auth is still worthy even with an install time risk like this? -Darren ps: Dan, your internet key draft is as funny as a draft about key exchange can be :) > -----Original Message----- > From: Dan Harkins [mailto:dharkins@trpz.com]=20 > Sent: Thursday, June 02, 2005 12:59 PM > To: Darren Loher > Cc: Saravanan Govindan; capwap@frascone.com > Subject: Re: [Capwap] IEEE Review 13 - Protocol security=20 >=20 > Darren, >=20 > The man-in-the-middle attacks you describe would not work=20 > if 802.11i was used. If it wasn't then these attacks can=20 > still be mounted by configuring a generic cutrate AP, forget=20 > CAPWAP. It would not be possible to capture the STA's=20 > passwords because the STA authenticates the AS prior to=20 > devulging her passwords and she would not authenticate a rogue AS. >=20 > Regarding the idea of loading a standard pre-shared key at=20 > the factory keep in mind that CAPWAP must be interoperable by=20 > different vendors so all vendors would have to use the same=20 > pre-shared key. Therefore let me refer you to the following=20 > (unfortunately now expired) Internet Draft: >=20 > http://www.lounge.org/draft-ietf-ipsec-internet-key-00.txt >=20 > I recommend reading the entire draft, it's pretty short, but=20 > check out the "Security Considerations" section. Then check=20 > out the date.=20 >=20 > For what it's worth I know of one company that shipped=20 > product that used that for authentication purposes as the=20 > "default pre-shared key" so there is precedense! >=20 > Dan. >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 2 21:48:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18742 for ; Thu, 2 Jun 2005 21:48:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 07384204BB; Thu, 2 Jun 2005 21:48:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8EAF6204AF; Thu, 2 Jun 2005 21:48:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4206A204AF for ; Thu, 2 Jun 2005 21:47:10 -0400 (EDT) Received: from vms040pub.verizon.net (vms040pub.verizon.net [206.46.252.40]) by mail.frascone.com (Postfix) with ESMTP id 9695C204A3 for ; Thu, 2 Jun 2005 21:47:08 -0400 (EDT) Received: from Matt-Holdrege.verizon.net ([208.179.69.254]) by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IHH009P1JMBPKN3@vms040.mailsrvcs.net> for capwap@frascone.com; Thu, 02 Jun 2005 20:47:02 -0500 (CDT) From: Matt Holdrege Subject: Re: [Capwap] IEEE Review 13 - Protocol security In-reply-to: <200506022036.j52KaLdt051891@homebrew.trpz.com> X-Sender: res06gzk@incoming.verizon.net To: Dan Harkins , Charles Clancy Cc: Darren Loher , Saravanan Govindan , capwap@frascone.com Message-id: <6.1.2.0.2.20050602184333.032fa790@incoming.verizon.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Content-type: text/plain; charset=us-ascii; format=flowed References: <200506022036.j52KaLdt051891@homebrew.trpz.com> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 02 Jun 2005 18:46:59 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Can I ask a silly question? Why can't the vendors of WTP's include the ability to input a shared key? The default could be no mutual authentication. And if people want security, they can input a key. Let the AC vendor also give their customers the choice of accepting trusted or un-trusted WTP's. Remember that we are developing a *protocol* here, rather than a set of products. So the CAPWAP protocol MUST support mutual authentication. We are not saying products MUST support this and we are absolutely not saying that end users MUST use mutual auth. -Matt _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 2 22:17:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20514 for ; Thu, 2 Jun 2005 22:17:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 941C6204CF; Thu, 2 Jun 2005 22:17:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C3381204C3; Thu, 2 Jun 2005 22:17:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EBE6C204C3 for ; Thu, 2 Jun 2005 22:16:34 -0400 (EDT) Received: from smtp2.mei.co.jp (smtp2.mei.co.jp [133.183.129.27]) by mail.frascone.com (Postfix) with ESMTP id 7A29C204B3 for ; Thu, 2 Jun 2005 22:16:32 -0400 (EDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id j532GQM7020425; Fri, 3 Jun 2005 11:16:26 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j532GSF19912; Fri, 3 Jun 2005 11:16:28 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with SMTP id j532GRc08551; Fri, 3 Jun 2005 11:16:27 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Missed deadline for CAPWAP protocol individual evaluation draft X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <5F09D220B62F79418461A978CA0921BD2F2141@pslexc01.psl.local> Thread-Topic: [Capwap] Missed deadline for CAPWAP protocol individual evaluation draft Thread-Index: AcVnuY3RkUkjI5iBQ32Met8o57IseAAJB1fA From: "Saravanan Govindan" To: , Cc: , , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 3 Jun 2005 10:13:54 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Dear All, The WiCoP authors apologise for the delay in submitting their evaluation draft. It was submitted yesterday to the IETF repository.=20 The evaluation document is currently available at: http://www.psl.com.sg/internet-drafts/draft-govindan-capwap-wicop-evalua tion-00.txt Saravanan > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of=20 > Dorothy.Gellert@nokia.com > Sent: Friday, June 03, 2005 5:25 AM > To: capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com;=20 > david.kessens@nokia.com; Dorothy.Gellert@nokia.com > Subject: [Capwap] Missed deadline for CAPWAP protocol=20 > individual evaluation draft >=20 >=20 > May 31st was the deadline to submit a self evaluation of the=20 > proposed protocols and how they meet the current CAPWAP=20 > Objectives, as stated in an email sent to the WG list on 5/6/05: >=20 > "The next step is for the champion of each protocol to submit=20 > an individual draft describing how their protocol meets the=20 > Objectives draft, the taxonomy draft and the Problem=20 > statement. The first version of these drafts should be=20 > submitted to the WG by Tuesday, May 31st. >=20 > Note the Objectives draft is still subject to change, and=20 > these conformance drafts will have to be updated to reflect=20 > the new objectives. We are requesting these individual=20 > evaluations before finalizing the Objectives so the WG can=20 > begin commenting towards the protocol evaluation as soon as possible." >=20 > Three of the protocol submissions did not meet the individual=20 > protocol Objective evaluation deadline or attempt to provide=20 > an analysis of how their protocol meets the Objectives. The=20 > goal of this draft was to help the WG evaluate the objectives=20 > among the different protocols and give > guidance to the Evaluation draft authors. Its disappointing that the > authors did not take this responsibility seriously. >=20 > This WG is very delay sensitive due to the market needs of=20 > this technology. We cannot afford to entertain delays in=20 > this process especially when all the protocol have been given=20 > an equal and fair amount of time to explain their approach to=20 > the Objectives. Obviously, protocol consensus can only be=20 > reached when the WG clearly understands the protocol, and=20 > creating the protocol Objectives analysis is a > meaningful step towards an agreed CAPWAP protocol. This=20 > draft will be > used by the evaluation authors to resolve objective disputes=20 > among the proposed protocols. >=20 > The WG would like to thank the LWAPP authors for creating > "http://www.capwap.org/draft-calhoun-capwap-lwapp-objectives-c > omparison-00.txt" to help the WG evaluate the their protocol=20 > against the current Objectives. =20 >=20 > Regards, > The WG Chairs. > =20 >=20 >=20 >=20 >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 2 23:13:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23173 for ; Thu, 2 Jun 2005 23:13:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7CA89204DB; Thu, 2 Jun 2005 23:13:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1464B204CF; Thu, 2 Jun 2005 23:13:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7A6FB204CF for ; Thu, 2 Jun 2005 23:12:55 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 9B6A7204CC for ; Thu, 2 Jun 2005 23:12:53 -0400 (EDT) Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5331CMs009326 for ; Thu, 2 Jun 2005 23:01:12 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5331BMs009304 for ; Thu, 2 Jun 2005 23:01:11 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] IEEE Review 4 - Logical groups definition Message-ID: <5844A41F4E146044A2E8356C6328588008C32FD2@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] IEEE Review 4 - Logical groups definition Thread-Index: AcVmhqdo7WxQU6JXQj+hwfnMafP7ZQAMV/1gACZTifAAJaqAAA== From: "Sadot, Emek (Emek)" To: "Saravanan Govindan" , "Pat Calhoun" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 2 Jun 2005 23:12:50 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Saravana, I think "constituent wireless terminals" should include client with dual / multiple radios, whereas each radio could be associated to different logical group (different SSIDs). Would the following text be better? "Logical Group: A logical separation of a physical WTP is termed logical group. Each BSSID and constituent wireless end station's radio are denoted as distinct logical groups of a physical WTP. Virtual APs of various implementations are also classified as logical groups."=20 Regards, Emek -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan Sent: Thursday, June 02, 2005 5:00 AM To: Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] IEEE Review 4 - Logical groups definition Pat, I should have clarified the text better. The intent was to acknowledge that there are different ways of implementing virtual APs. So the definition of a logical group is to cover virtual APs of varying implementations.=20 Would the following text be better? "Logical Group: A logical separation of a physical WTP is termed logical group. Each BSSID and constituent wireless terminals are denoted as distinct logical groups of a physical WTP. Virtual APs of various implementations are also classified as logical groups."=20 Saravanan > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@cisco.com] > Sent: Wednesday, June 01, 2005 10:42 PM > To: Saravanan Govindan; capwap@frascone.com > Subject: RE: [Capwap] IEEE Review 4 - Logical groups definition >=20 > I have issues with the last sentence "Virtual APs of alternative types > are also lassified as logical groups." I can't tell what 'alternative=20 > type' > means. I do like the rest of the text. >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit Cisco Systems >=20 > =20 >=20 > > -----Original Message----- > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan > > Sent: Wednesday, June 01, 2005 1:48 AM > > To: capwap@frascone.com > > Subject: [Capwap] IEEE Review 4 - Logical groups definition > >=20 > > Section 5.1.1 - Logical Groups (Description), paragraph 3 > >=20 > >=20 > > Comment:=20 > >=20 > > Clarify the term, and specify which types of "logical > groups must be > > supported." > >=20 > >=20 > > Proposed Change: > >=20 > > Add definition of logical groups in Section 2 - Terminology. > >=20 > > "Logical Group: A logical separation of a physical WTP is termed=20 > > logical group. Each BSSID and constituent wireless terminals are=20 > > denoted as distinct logical groups of a physical WTP. > Virtual APs of > > alternative types are also classified as logical groups." > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From ngkong@doneasy.com Fri Jun 3 01:25:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02023; Fri, 3 Jun 2005 01:25:50 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1De50y-0002gZ-NC; Fri, 03 Jun 2005 01:46:42 -0400 Received: from 84.94.61.39.cable.012.net.il ([84.94.61.39]) by mx2.foretec.com with smtp (Exim 4.24) id 1De4gi-0003Yl-To; Fri, 03 Jun 2005 01:25:46 -0400 Received: from embattle-jcoppens.com (EHLO harriet.jcoppens.com) by advisory.jcoppens.com with SMTP; Fri, 03 Jun 2005 00:20:17 -0600 Date: Thu, 02 Jun 2005 23:22:17 -0700 From: "Armand Colvin" To: capwap-archive@ietf.org Cc: ccips@ietf.org, cclark@ietf.org, cdi-archive@ietf.org, cdir-admin@ietf.org, cfrg@ietf.org, cfrg-admin@ietf.org, cfrg-archive@ietf.org, cfrg-bounces@ietf.org, cfrg-web-archive@ietf.org, chair@ietf.org, chiname.cn@ietf.org, chive@ietf.org, christine.fontenot@ietf.org Subject: Dont miss out on low rates Message-ID: X-SpamTest-Info: Profile: SysLog X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [086], SpamtestISP/Release X-Mailer: MIME-tools 5.41 (Entity 5.404) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $400,000 for as little as $400 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.cr3am.com/signs.asp Best Regards, Anne Rosas to be remov(ed: http://www.cr3am.com/deletion.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From capwap-admin@frascone.com Fri Jun 3 12:04:09 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10249 for ; Fri, 3 Jun 2005 12:04:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 909B6204C6; Fri, 3 Jun 2005 12:04:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E6EE4204A4; Fri, 3 Jun 2005 12:04:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4287C204A4 for ; Fri, 3 Jun 2005 12:03:49 -0400 (EDT) Received: from carrierpigeon.cs.umd.edu (carrierpigeon.cs.umd.edu [128.8.129.58]) by mail.frascone.com (Postfix) with ESMTP id 3124920489 for ; Fri, 3 Jun 2005 12:03:45 -0400 (EDT) Received: from ismene (ismene.cs.umd.edu [128.8.126.62]) by carrierpigeon.cs.umd.edu (8.12.10/8.12.5) with ESMTP id j53FjttS000469; Fri, 3 Jun 2005 11:45:55 -0400 (EDT) From: Charles Clancy X-X-Sender: clancy@ismene To: Matt Holdrege Cc: Dan Harkins , Darren Loher , Saravanan Govindan , capwap@frascone.com Subject: Re: [Capwap] IEEE Review 13 - Protocol security In-Reply-To: <6.1.2.0.2.20050602184333.032fa790@incoming.verizon.net> Message-ID: References: <200506022036.j52KaLdt051891@homebrew.trpz.com> <6.1.2.0.2.20050602184333.032fa790@incoming.verizon.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 3 Jun 2005 11:41:56 -0400 (EDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Another option might be SSH-style security. The WTP could be preprogramed with a self-signed cert. The public key could be saved on the AC. During the first authentication, the WTP saves the AC's public key. During later authentications, the WTP just verifies the AC's public key matches the saved one. Maybe we could allow non-mutual authentication during a provisioning phase, but require it afterwards? Matt brings up a good point -- do we want these mutual authentication requirements to be supported by the protocol, or required by the protocol? [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] On Thu, 2 Jun 2005, Matt Holdrege wrote: > Can I ask a silly question? Why can't the vendors of WTP's include the > ability to input a shared key? The default could be no mutual authentication. > And if people want security, they can input a key. Let the AC vendor also > give their customers the choice of accepting trusted or un-trusted WTP's. > > Remember that we are developing a *protocol* here, rather than a set of > products. So the CAPWAP protocol MUST support mutual authentication. We are > not saying products MUST support this and we are absolutely not saying that > end users MUST use mutual auth. > > -Matt > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jun 3 13:12:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15253 for ; Fri, 3 Jun 2005 13:12:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 01CCE204D1; Fri, 3 Jun 2005 13:12:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 17EEE204A5; Fri, 3 Jun 2005 13:12:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2FAE4204A5 for ; Fri, 3 Jun 2005 13:11:43 -0400 (EDT) Received: from WNIMAIL.WoodsideNet.Com (wnifwl.woodsidenet.com [65.192.186.2]) by mail.frascone.com (Postfix) with ESMTP id 67FF920466 for ; Fri, 3 Jun 2005 13:11:38 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] IEEE Review 13 - Protocol security Message-ID: <3FFBC907DD03A34CA4410C5C745DEB1206AA6623@wnimail.WoodsideNet.Com> Thread-Topic: [Capwap] IEEE Review 13 - Protocol security Thread-Index: AcVoVeLwyTqvgu6LTVWCqg1uR0wHGAACRKDQ From: "Paul Lambert" To: "Charles Clancy" , "Matt Holdrege" Cc: "Dan Harkins" , "Darren Loher" , "Saravanan Govindan" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 3 Jun 2005 10:11:32 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I be believe mutual authentication 'must' be a requirement. It's easy to change mutual authentication to one-sided, by difficult to do the reverse.=20 Paul=20 > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of Charles Clancy > Sent: Friday, June 03, 2005 8:42 AM > To: Matt Holdrege > Cc: Dan Harkins; Darren Loher; Saravanan Govindan; capwap@frascone.com > Subject: Re: [Capwap] IEEE Review 13 - Protocol security >=20 > Another option might be SSH-style security. The WTP could be=20 > preprogramed with a self-signed cert. The public key could=20 > be saved on the AC.=20 > During the first authentication, the WTP saves the AC's public key.=20 > During later authentications, the WTP just verifies the AC's=20 > public key matches the saved one. >=20 > Maybe we could allow non-mutual authentication during a=20 > provisioning phase, but require it afterwards? Matt brings=20 > up a good point -- do we want these mutual authentication=20 > requirements to be supported by the protocol, or required by=20 > the protocol? >=20 > [ t. charles clancy ]--[ tcc@umd.edu ]--[=20 > www.cs.umd.edu/~clancy ] [ computer science ]-----[=20 > university of maryland | college park ] >=20 >=20 > On Thu, 2 Jun 2005, Matt Holdrege wrote: >=20 > > Can I ask a silly question? Why can't the vendors of WTP's=20 > include the=20 > > ability to input a shared key? The default could be no=20 > mutual authentication. > > And if people want security, they can input a key. Let the=20 > AC vendor=20 > > also give their customers the choice of accepting trusted=20 > or un-trusted WTP's. > > > > Remember that we are developing a *protocol* here, rather=20 > than a set=20 > > of products. So the CAPWAP protocol MUST support mutual=20 > > authentication. We are not saying products MUST support this and we=20 > > are absolutely not saying that end users MUST use mutual auth. > > > > -Matt > > > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jun 3 13:13:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15346 for ; Fri, 3 Jun 2005 13:13:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 63988204DA; Fri, 3 Jun 2005 13:13:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3A460204CF; Fri, 3 Jun 2005 13:13:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BF985204CF for ; Fri, 3 Jun 2005 13:12:43 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id CC6B8204C9 for ; Fri, 3 Jun 2005 13:12:41 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j53H8n0P072234; Fri, 3 Jun 2005 10:08:54 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200506031708.j53H8n0P072234@homebrew.trpz.com> To: Charles Clancy Cc: capwap@frascone.com Subject: Re: [Capwap] IEEE Review 13 - Protocol security In-Reply-To: Your message of "Fri, 03 Jun 2005 11:41:56 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <72232.1117818529.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 03 Jun 2005 10:08:49 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Charles, On Fri, 03 Jun 2005 11:41:56 EDT you wrote > Another option might be SSH-style security. The WTP could be preprogramed > with a self-signed cert. The public key could be saved on the AC. > During the first authentication, the WTP saves the AC's public key. > During later authentications, the WTP just verifies the AC's public key > matches the saved one. Exactly! Except you don't even need a self-signed cert, just a keypair installed on the WTP at manufacture time. And you don't need to save the public key on the AC, just a fingerprint of it, SSH-style. Then you can do a TLS-style (or DTLS, see SLAPP) asymmetric authentication to secure the link. > Maybe we could allow non-mutual authentication during a provisioning > phase, but require it afterwards? Matt brings up a good point -- do we > want these mutual authentication requirements to be supported by the > protocol, or required by the protocol? There's a difference between required to implement and required to use. What I'm getting at is that we don't (can't) have a key exchange protocol that can only support mutual authentication. IKE is that way. There's many, too many, flavors of authentication but they're all mutual. But that's because mutual authentication is needed for IPsec. It is not needed for CAPWAP so we shouldn't have a protocol that only supports mutual authentication. Dan. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From mohale_thabo@yahoo.com Sun Jun 5 22:44:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22990 for ; Sun, 5 Jun 2005 22:44:23 -0400 (EDT) Received: from rrba-146-127-252.telkomadsl.co.za ([165.146.127.252] helo=user-73xs43pdok) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Df7vz-0004tO-Ho for capwap-archive@ietf.org; Sun, 05 Jun 2005 23:05:53 -0400 From: "Thabo Mohale" To: capwap-archive@ietf.org Subject: Partnership Request Date: Mon, 6 Jun 2005 04:44:00 +0200 MIME-Version: 1.0 X-Mailer: Internal Email Service (4.3.0.699) Message-ID: Reply-To: thabomohale@hotmail.com Content-Type: multipart/alternative; boundary="--=_NextPart_005E1042_3CF7D70C_01C9F258.D84EF1C0" X-Spam-Score: 4.3 (++++) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 This is a multi-part message in MIME format. ----=_NextPart_005E1042_3CF7D70C_01C9F258.D84EF1C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit June 6, 2005 FROM: DR. Thabo Mohale Pretoria, South Africa Dear Sir/Madam, STRICTLY CONFIDENTIAL AND URGENT! The South Africa economy has witnessed a steady growth since the end of Apartheid. Within the Ministry of Energy & Mineral Resources where I worked as director of Auditing and Project Implementation, Mining and Quarrying alone contributes 12.3 GDP (R25.9Billion), Gold made up R19.9Billion of the yearly export while Base metals and other mineral products contribute R6.7Billion and R5.0Billion respectively. This figures excludes Diamond, which is quoted separately. The Government has continuously strafed to improve and maintain good relationship with foreign governments and Non-Governmental financial agencies by ensuring payments for all debts owed foreign contractors. As a matter of fact, the Government has sponsored several trade delegations overseas to improve and attract foreign investments to South Africa. I write to solicit your partnership in a matter I believe will be of mutual benefit to us. This would require your trust and capability to work with me with your genuine cooperation according to instructions. I and two other colleagues involved in this transaction are still in active government service with the Ministry of Mines & Mineral Resources and we are in dire need of a foreign partner to assist us in the receipt and investment of US$ 28,200,000.00 (Twenty Eight Million, Two Hundred Thousand United States Dollars). The key issue is the transfer of the said sum to an account that will be provided by you for this purpose for safekeeping and subsequent investment in a profitable venture. We are ready to go into an agreement with you regarding your percentage in this transaction. It does not matter whether or not you own a company, we shall guide you on what to do. The basis will be that a major company won a contract and subcontracted it to you. More often, big trading companies and firms of unrelated fields win contracts and subcontract to more specialized firms for execution. We shall follow strictly all the legal procedures entailed in our laws and international laws in transferring the funds to you. The source of the fund is legitimate and authoritative; our caucus extends from my Ministry (Energy & Mineral Resources) to the Ministry of Finance. It is pertinent to know that under the South African Government monetary policy, strategic positioned Government officials are not allowed to operate or own a bank account overseas, hence your importance as a foreign partner. I have reposed my confidence in you and hope you will not disappoint me. Should you be willing to assist positively with a common goal, endeavor to contact me immediately through my numbers above. I await in anticipation your fullest co-operation. Best regards, DR. Thabo Mohale ----=_NextPart_005E1042_3CF7D70C_01C9F258.D84EF1C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

June 6,= 2005

 

FROM:  DR. Thabo Mohale

            =    Pretoria, South Africa

 

Dear Sir/Madam,

 

            =               STRICTLY CONFIDENTIAL AND URGENT!

 

The South Africa= economy has witnessed a steady growth since the end of Apartheid. Within the Ministry of Energy & Mineral Resources where I worked as director of Auditing and Project Implementation, Mining and Quarrying alone contributes 12.3 GDP (R25.9Billion), Gold made up R19.9Billion of the yearly export while Base= metals and other mineral products contribute R6.7Billion and R5.0Billion= respectively. This figures excludes Diamond, which is quoted separately. The Government has continuously strafed to improve and maintain good relationship with foreign governments and Non-Governmental financial agencies by ensuring payments for= all debts owed foreign contractors.

 

As a matter of fact,= the Government has sponsored several trade delegations overseas to improve and attract foreign investments to South Africa. I write to solicit your= partnership in a matter I believe will be of mutual benefit to us. This would require= your trust and capability to work with me with your genuine cooperation according= to instructions. I and two other colleagues involved in this transaction are= still in active government service with the Ministry of Mines & Mineral= Resources and we are in dire need of a foreign partner to assist us in the receipt and investment of US$ 28,200,000.00 (Twenty Eight Million, Two Hundred Thousand United States Dollars). The key issue is the transfer of the said sum to an account that will be provided by you for this purpose for safekeeping and subsequent investment in a profitable venture.

 

We are ready to go into= an agreement with you regarding your percentage in this transaction. It does not matter whether or not you own a company, we shall guide you on what to do.= The basis will be that a major company won a contract and subcontracted it to= you. More often, big trading companies and firms of unrelated fields win contracts and subcontract to more specialized firms for execution. We shall follow strictly all the legal procedures entailed in our laws and international laws= in transferring the funds to you. The source of the fund is legitimate and authoritative; our caucus extends from my Ministry (Energy & Mineral Resources) to the Ministry of Finance. It is pertinent to know that under the South African Government monetary policy, strategic positioned Government officials are not allowed to operate or own a bank account overseas, hence= your importance as a foreign partner. I have reposed my confidence in you and hope you will not disappoint me. Should you be willing to assist positively with a common goal, endeavor to contact me immediately through my numbers above.

 

 I await in anticipation your fullest co-operation.

 

Best regards,

 

DR. Thabo Mohale

 

 

----=_NextPart_005E1042_3CF7D70C_01C9F258.D84EF1C0-- From moczygemba@doneasy.com Mon Jun 6 02:59:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01121; Mon, 6 Jun 2005 02:59:40 -0400 (EDT) Received: from [218.50.123.207] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DfBv3-0001Em-VA; Mon, 06 Jun 2005 03:21:11 -0400 Received: from burgher.sonrmm.idiomatic.jocund.com by apprentice.fishmonger.embezzle.com (johupfix) with SMTP id 4B29E820684 for ; Mon, 06 Jun 2005 00:55:59 -0700 Message-ID: Date: Mon, 06 Jun 2005 10:57:59 +0300 From: "Wilma Dill" To: Subject: Dont miss out on low rates X-Mailer: KYX CP/M FNORD 5602 X-Spam-Score: 6.0 (++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $400,000 for as little as $400 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.t0wers.net/signs.asp Best Regards, Darla Horne to be remov(ed: http://www.t0wers.net/deletion.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From bgorge@doneasy.com Mon Jun 6 03:08:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03979; Mon, 6 Jun 2005 03:08:46 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfC3r-0001YM-Mu; Mon, 06 Jun 2005 03:30:16 -0400 Received: from [211.176.11.32] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1DfBiu-0002H0-Hm; Mon, 06 Jun 2005 03:08:42 -0400 Received: by concubine (Wostfix 07 70) id 10B50C1144429; Mon, 06 Jun 2005 02:06:38 -0600 Date: Mon, 06 Jun 2005 09:04:38 +0100 From: "Cruz Strickland" Message-ID: <423c.fsf@calle39.net> To: bpana@ietf.org Cc: brenton.daniels@ietf.org, bridge-mib@ietf.org, bridge-mib-admin@ietf.org, business@ietf.org, calsch@ietf.org, cancer@ietf.org, capwap-archive@ietf.org, ccips@ietf.org, cclark@ietf.org, cdi-archive@ietf.org, cdir-admin@ietf.org Subject: Your account #4Z7084 X-Mailer: Apple Mail (2.482) X-Spam-Score: 9.0 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $400,000 for as little as $400 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.t0wers.net/signs.asp Best Regards, Silvia James to be remov(ed: http://www.t0wers.net/deletion.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From pritchett@doramail.com Tue Jun 7 01:59:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27548; Tue, 7 Jun 2005 01:59:54 -0400 (EDT) Received: from [221.232.104.51] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DfXSv-0001nF-SF; Tue, 07 Jun 2005 02:21:37 -0400 Received: from athlete-gsgx.prka.net (HELO given-pzle.net) by avocado-ext.yhzln.net (8.9.0) with ESMTP id AAT12oqtq; Tue, 07 Jun 2005 03:51:43 -0300 Date: Tue, 07 Jun 2005 02:52:43 -0400 From: "Doris Steward" Message-ID: <141.70e558d5.2a9CMX44@yzg.com> To: cancer@ietf.org Cc: capwap-archive@ietf.org, ccips@ietf.org, cclark@ietf.org, cdi-archive@ietf.org Subject: Approval rate accepted X-Mailer: KMail [version 1.0.28] X-Spam-Score: 7.1 (+++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $400,000 for as little as $400 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.t0wers.net/signs.asp Best Regards, Jordan Strickland to be remov(ed: http://www.t0wers.net/deletion.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From hppgpld@yebox.com Tue Jun 7 02:50:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21234; Tue, 7 Jun 2005 02:50:08 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfYFV-0002dL-I5; Tue, 07 Jun 2005 03:11:52 -0400 Received: from [220.120.57.115] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1DfXuN-0007xP-Gn; Tue, 07 Jun 2005 02:49:58 -0400 Received: from gasd.biz by bloodshotgle (sp.9yo) id bwndeerafm with SMTP; Tue, 07 Jun 2005 13:44:23 +0600 Message-ID: <20041bgeot3.ED8DA244AE@mailhost1i.lists.techtarget.com> Date: Tue, 07 Jun 2005 05:49:23 -0200 From: "Tyler Lovett" To: bofchairs@ietf.org Cc: bounces-ietf@ietf.org, bpana@ietf.org, brenton.daniels@ietf.org, bridge-mib@ietf.org, bridge-mib-admin@ietf.org, business@ietf.org, calsch@ietf.org, cancer@ietf.org, capwap-archive@ietf.org, ccips@ietf.org, cclark@ietf.org Subject: High rates? Not with us! low fixed rate X-Mailer: KYX CP/M FNORD 5602 X-Spam-Score: 3.6 (+++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $400,000 for as little as $400 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.t0wers.net/signs.asp Best Regards, Jeanine Sampson to be remov(ed: http://www.t0wers.net/deletion.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From cporter@doramail.com Tue Jun 7 04:45:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00976; Tue, 7 Jun 2005 04:45:06 -0400 (EDT) Received: from [222.84.192.151] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dfa2q-0005Eg-Jj; Tue, 07 Jun 2005 05:06:51 -0400 Received: by either (Wostfix 53 64) id 28B40C1142699; Tue, 07 Jun 2005 13:40:45 +0400 Date: Tue, 07 Jun 2005 13:40:45 +0400 From: "Tabitha Xiong" Message-ID: <192c.fsf@calle69.net> To: bofchairs@ietf.org Cc: bounces-ietf@ietf.org, bpana@ietf.org, brenton.daniels@ietf.org, bridge-mib@ietf.org, bridge-mib-admin@ietf.org, business@ietf.org, calsch@ietf.org, cancer@ietf.org, capwap-archive@ietf.org, ccips@ietf.org, cclark@ietf.org, cdi-archive@ietf.org Subject: Pre-approved Application #FEMT600 X-Mailer: Apple Mail (2.482) X-Spam-Score: 7.5 (+++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $400,000 for as little as $400 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.t0wers.net/signs.asp Best Regards, Beau Manning to be remov(ed: http://www.t0wers.net/deletion.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From capwap-admin@frascone.com Tue Jun 7 11:15:09 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01844 for ; Tue, 7 Jun 2005 11:15:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7D92C20450; Tue, 7 Jun 2005 11:15:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C553920419; Tue, 7 Jun 2005 11:15:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DFECB203E1 for ; Tue, 7 Jun 2005 11:14:15 -0400 (EDT) Received: from aruba-server.arubanetworks.com (smtp.arubanetworks.com [216.31.249.252]) by mail.frascone.com (Postfix) with SMTP id 099DB20270 for ; Tue, 7 Jun 2005 11:14:13 -0400 (EDT) Received: from [10.240.1.40] ([10.240.1.40]) by aruba-server.arubanetworks.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 7 Jun 2005 08:02:32 -0700 From: Partha Narasimhan X-X-Sender: partha@localhost.localdomain To: capwap@frascone.com Cc: mmani@avaya.com, dorothy.gellert@nokia.com, Dan Harkins , Subbu Ponnuswamy , Susan Hares Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 07 Jun 2005 15:02:32.0846 (UTC) FILETIME=[EE99CAE0:01C56B71] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] SLAPP evaluation draft Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 7 Jun 2005 08:02:12 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The SLAPP evaluation draft has been submitted. It should show up in due course at http://www.ietf.org/internet-drafts/draft-narasimhan-capwap-slapp-evaluation-00.txt On behalf of the authors, I would like to apologize for the delay in submitting this draft. Thanks partha _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From guarner@doramail.com Tue Jun 7 13:58:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15399; Tue, 7 Jun 2005 13:58:34 -0400 (EDT) Received: from [221.145.25.62] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DfigY-0000rd-6H; Tue, 07 Jun 2005 14:20:24 -0400 Received: by shakeable (Wostfix 65 01) id 26B08C1141599; Tue, 07 Jun 2005 20:51:19 +0200 Date: Tue, 07 Jun 2005 13:53:19 -0500 From: "Dominick Barnhart" Message-ID: <275c.fsf@calle32.net> To: bofchairs@ietf.org Cc: bounces-ietf@ietf.org, bpana@ietf.org, brenton.daniels@ietf.org, bridge-mib@ietf.org, bridge-mib-admin@ietf.org, business@ietf.org, calsch@ietf.org, cancer@ietf.org, capwap-archive@ietf.org, ccips@ietf.org Subject: Your low mortage rate X-Mailer: Apple Mail (2.482) X-Spam-Score: 10.9 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $400,000 for as little as $400 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.t0wers.net/signs.asp Best Regards, Deon Beasley to be remov(ed: http://www.t0wers.net/deletion.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From stope@yebox.com Tue Jun 7 14:37:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19413; Tue, 7 Jun 2005 14:37:46 -0400 (EDT) Received: from bl5-156-213.dsl.telepac.pt ([82.154.156.213]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DfjIL-0001a7-51; Tue, 07 Jun 2005 14:59:37 -0400 Received: from coventry.cilkbz.thor.abash.com by dig.pastime.blunder.com (emhupfix) with SMTP id 3B29E820567 for ; Tue, 07 Jun 2005 15:32:29 -0400 Message-ID: Date: Tue, 07 Jun 2005 16:27:29 -0300 From: "Elvin Gagne" To: Subject: Get the low rates before its late X-Mailer: KYX CP/M FNORD 5602 X-Spam-Score: 2.6 (++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $400,000 for as little as $400 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.t0wers.net/signs.asp Best Regards, Antonia Duke to be remov(ed: http://www.t0wers.net/deletion.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From capwap-admin@frascone.com Tue Jun 7 15:36:13 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25877 for ; Tue, 7 Jun 2005 15:36:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 65F0A1FE1A; Tue, 7 Jun 2005 15:36:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AFBD11FC28; Tue, 7 Jun 2005 15:36:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7D3BC1FC28 for ; Tue, 7 Jun 2005 15:35:47 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id 366151FC21 for ; Tue, 7 Jun 2005 15:35:43 -0400 (EDT) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j57JXCdd002738 for ; Tue, 7 Jun 2005 15:33:12 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j57JX1dd002307 for ; Tue, 7 Jun 2005 15:33:02 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56B98.070277AA" Subject: RE: [Capwap] Support for Traffic Separation Message-ID: <5844A41F4E146044A2E8356C6328588008CB7BAB@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] Support for Traffic Separation Thread-Index: AcVmtrsFJNprui8LSZKBEWJ0aGfIlQE1bbGQ From: "Sadot, Emek (Emek)" To: "Pat Calhoun" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 7 Jun 2005 15:35:14 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C56B98.070277AA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pat, =20 A question regarding section 2.1.2 Support for Traffic Separation - author's interpretation of Support for Traffic Separation: does LWAPP supports an architecture in which the DS is implemented at the WTP? (avoid tunneling data frames to a control entity). =20 Regards, Emek _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun Sent: Wednesday, June 01, 2005 10:32 AM To: capwap@frascone.com Subject: [Capwap] LWAPP Self Evaluation draft posted yesterday All, =20 As per the protocol submission rules laid out by the chairs, the authors of the LWAPP protocol submitted a self evaluation to the I-D draft editors yesterday. I have made the draft available at http://www.capwap.org/draft-calhoun-capwap-lwapp-objectives-comparison-0 0.txt . =20 Comments welcomed! =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ------_=_NextPart_001_01C56B98.070277AA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Pat,
 
A=20 question regarding section 2.1.2 Support = for=20 Traffic Separation - author's interpretation = of Support for Traffic Separation: = does LWAPP=20 supports an architecture in which the DS is implemented at the WTP? = (avoid=20 tunneling data frames to a control entity).
 
Regards,
Emek

From: capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Pat=20 Calhoun
Sent: Wednesday, June 01, 2005 10:32 AM
To:=20 capwap@frascone.com
Subject: [Capwap] LWAPP Self Evaluation = draft=20 posted yesterday

All,
 
As per = the protocol=20 submission rules laid out by the chairs, the authors of the LWAPP = protocol=20 submitted a self evaluation to the I-D draft editors yesterday. I have = made the=20 draft available at http://www.capwap.org/draft-calhoun-capwap-lwapp-objectives-comp= arison-00.txt.
 
Comments=20 welcomed!
 

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

 
------_=_NextPart_001_01C56B98.070277AA-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Jun 7 16:28:15 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08778 for ; Tue, 7 Jun 2005 16:28:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E434C20278; Tue, 7 Jun 2005 16:28:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 13A5C1FC5D; Tue, 7 Jun 2005 16:28:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 383831FC5D for ; Tue, 7 Jun 2005 16:27:03 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 448F31FC28 for ; Tue, 7 Jun 2005 16:27:00 -0400 (EDT) Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j57KFGAK025247 for ; Tue, 7 Jun 2005 16:15:16 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j57KFEAK025193 for ; Tue, 7 Jun 2005 16:15:15 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56B9F.40C6F172" Message-ID: <5844A41F4E146044A2E8356C6328588008CB7C3A@nj7460avexu2.global.avaya.com> Thread-Topic: NAT traversal Thread-Index: AcVrn0BN0zy5JkI6Qi2V5rPKkheOWg== From: "Sadot, Emek (Emek)" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] NAT traversal Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 7 Jun 2005 16:26:58 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C56B9F.40C6F172 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 Would like to suggest adding a NAT traversal requirement to the CAPWAP objective document, i.e. the ability of AC and WTP to communicate across NAT device (UDP / TCP transport, refresh CAPWAP session at the NAT device, WTP identification behind NAT device, etc.). Deployment examples? say the WTP is located at branch office and the AC at the main office separated by NAT device, or within an Enterprise segregated by NAT devices. =20 Regards, Emek ------_=_NextPart_001_01C56B9F.40C6F172 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,
 
Would = like to=20 suggest adding a NAT traversal requirement to the CAPWAP objective=20 document, i.e. the ability of AC and WTP to communicate = across NAT=20 device (UDP / TCP transport, refresh CAPWAP session at the NAT device, = WTP=20 identification behind NAT device, etc.). Deployment examples? say = the WTP=20 is located at branch office and the AC at the main office separated = by NAT=20 device, or within an Enterprise segregated by NAT = devices.
 
Regards,
Emek
------_=_NextPart_001_01C56B9F.40C6F172-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From yodeled@doramail.com Tue Jun 7 19:38:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25867; Tue, 7 Jun 2005 19:38:17 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfnzO-0003rH-0c; Tue, 07 Jun 2005 20:00:10 -0400 Received: from [221.153.57.100] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1Dfne2-0001F4-7g; Tue, 07 Jun 2005 19:38:07 -0400 Received: from aflx.biz by transmitfys (er.9rz) id dbhvfqxcwr with SMTP; Tue, 07 Jun 2005 21:34:12 -0300 Message-ID: <20041bpoba3.ED8DA244AE@mailhost1z.lists.techtarget.com> Date: Wed, 08 Jun 2005 02:35:12 +0200 From: "Benita Duke" To: brenton.daniels@ietf.org Cc: bridge-mib@ietf.org, bridge-mib-admin@ietf.org, business@ietf.org, calsch@ietf.org, cancer@ietf.org, capwap-archive@ietf.org, ccips@ietf.org, cclark@ietf.org, cdi-archive@ietf.org, cdir-admin@ietf.org, cfrg@ietf.org, cfrg-admin@ietf.org, cfrg-archive@ietf.org, cfrg-bounces@ietf.org Subject: Save hundreds every month on low rates X-Mailer: KYX CP/M FNORD 5602 X-Spam-Score: 11.6 (+++++++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $400,000 for as little as $400 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.pr0ved.com/signs.asp Best Regards, Tammie Chavez to be remov(ed: http://www.pr0ved.com/deletion.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From capwap-admin@frascone.com Wed Jun 8 12:36:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15259 for ; Wed, 8 Jun 2005 12:36:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 15BB62048E; Wed, 8 Jun 2005 12:36:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 65C032046C; Wed, 8 Jun 2005 12:36:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4EA66203E9 for ; Wed, 8 Jun 2005 12:35:55 -0400 (EDT) Received: from typhoon.trangosoft.com (unknown [209.82.51.154]) by mail.frascone.com (Postfix) with ESMTP id EC85B2046C for ; Wed, 8 Jun 2005 12:35:52 -0400 (EDT) Received: from phantom-out.trangosoft.com ([136.157.233.22]) by 136.157.233.32 with trend_isnt_name_B; Wed, 08 Jun 2005 12:37:32 -0400 Received: from troll3.trangosoft.com (troll3.trangosoft.com [136.157.233.13]) by phantom-out.trangosoft.com (Postfix) with ESMTP id 0071F24FAC for ; Wed, 8 Jun 2005 12:13:38 -0400 (EDT) Received: by troll3.trangosoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jun 2005 12:32:10 -0400 Message-ID: <1652EBA28502ED4393B9BC9B8A4B6013122494@mism121a.toronto.chantrynetworks.com> From: Inderpreet Singh To: capwap@frascone.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56C48.231AFDC6" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] draft-francisco-capwap-ctp-evaluation-00.txt Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 8 Jun 2005 12:35:53 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C56C48.231AFDC6 Content-Type: text/plain Has been submitted to the ID repository. We apologize for the tardiness. Better late than never. Thanks --- Inderpreet Singh Chief Architect Chantry Networks Inc., A Siemens Company inderpreet.singh@siemens.com Work: 905-363-6412 Mobile: 416-831-3705 ------_=_NextPart_001_01C56C48.231AFDC6 Content-Type: text/html

Has been submitted to the ID repository.  We apologize for the tardiness.  Better late than never.

 

Thanks

 

---

Inderpreet Singh

Chief Architect

Chantry Networks Inc., A Siemens Company

inderpreet.singh@siemens.com

Work: 905-363-6412

Mobile: 416-831-3705

 

------_=_NextPart_001_01C56C48.231AFDC6-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 8 12:46:10 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15910 for ; Wed, 8 Jun 2005 12:46:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0CAE6204C0; Wed, 8 Jun 2005 12:46:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7B66E20485; Wed, 8 Jun 2005 12:46:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 20BCD20485 for ; Wed, 8 Jun 2005 12:45:24 -0400 (EDT) Received: from typhoon.trangosoft.com (unknown [209.82.51.154]) by mail.frascone.com (Postfix) with ESMTP id DB19E20477 for ; Wed, 8 Jun 2005 12:45:21 -0400 (EDT) Received: from phantom-out.trangosoft.com ([136.157.233.22]) by 136.157.233.32 with trend_isnt_name_B; Wed, 08 Jun 2005 12:46:59 -0400 Received: from troll3.trangosoft.com (troll3.trangosoft.com [136.157.233.13]) by phantom-out.trangosoft.com (Postfix) with ESMTP id EE48124FCD; Wed, 8 Jun 2005 12:23:04 -0400 (EDT) Received: by troll3.trangosoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jun 2005 12:41:37 -0400 Message-ID: <1652EBA28502ED4393B9BC9B8A4B601312249F@mism121a.toronto.chantrynetworks.com> From: Inderpreet Singh To: "Sadot, Emek (Emek)" , capwap@frascone.com Subject: RE: [Capwap] NAT traversal MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56C49.74D97D30" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 8 Jun 2005 12:45:19 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C56C49.74D97D30 Content-Type: text/plain Sounds like a good idea but it may be implicitly covered under "Interconnection Objective". Are you suggesting we make an explicit separate objective? --- Inderpreet Singh _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) Sent: Tuesday, June 07, 2005 4:27 PM To: capwap@frascone.com Subject: [Capwap] NAT traversal All, Would like to suggest adding a NAT traversal requirement to the CAPWAP objective document, i.e. the ability of AC and WTP to communicate across NAT device (UDP / TCP transport, refresh CAPWAP session at the NAT device, WTP identification behind NAT device, etc.). Deployment examples? say the WTP is located at branch office and the AC at the main office separated by NAT device, or within an Enterprise segregated by NAT devices. Regards, Emek ------_=_NextPart_001_01C56C49.74D97D30 Content-Type: text/html

Sounds like a good idea but it may be implicitly covered under “Interconnection Objective”.  Are you suggesting we make an explicit separate objective?

 

---

Inderpreet Singh

 

From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek)
Sent: Tuesday, June 07, 2005 4:27 PM
To: capwap@frascone.com
Subject: [Capwap] NAT traversal

 

All,

 

Would like to suggest adding a NAT traversal requirement to the CAPWAP objective document, i.e. the ability of AC and WTP to communicate across NAT device (UDP / TCP transport, refresh CAPWAP session at the NAT device, WTP identification behind NAT device, etc.). Deployment examples? say the WTP is located at branch office and the AC at the main office separated by NAT device, or within an Enterprise segregated by NAT devices.

 

Regards,

Emek

------_=_NextPart_001_01C56C49.74D97D30-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 8 13:23:09 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18735 for ; Wed, 8 Jun 2005 13:23:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 60A4020426; Wed, 8 Jun 2005 13:23:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 689EC20242; Wed, 8 Jun 2005 13:23:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C963820242 for ; Wed, 8 Jun 2005 13:22:00 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id A07B31FE0F for ; Wed, 8 Jun 2005 13:21:58 -0400 (EDT) Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j58HACAK008369 for ; Wed, 8 Jun 2005 13:10:12 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j58HABAK008328 for ; Wed, 8 Jun 2005 13:10:11 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56C4E.915829BD" Subject: RE: [Capwap] NAT traversal Message-ID: <5844A41F4E146044A2E8356C6328588008CB8183@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] NAT traversal Thread-Index: AcVsSX5vTwh6VyUGTeaAnqxohU28nwABHXPQ From: "Sadot, Emek (Emek)" To: "Inderpreet Singh" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 8 Jun 2005 13:21:55 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C56C4E.915829BD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Inderpreet, =20 NAT poses specific requirements whereas the interconnection objective, at least to my interpretation is too general. I would like to see an explicit NATG traversal objective and willing to put the wording around it if here no objection from the group. =20 Emek _____ =20 From: Inderpreet Singh [mailto:inderpreet.singh@siemens.com]=20 Sent: Wednesday, June 08, 2005 12:45 PM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] NAT traversal Sounds like a good idea but it may be implicitly covered under "Interconnection Objective". Are you suggesting we make an explicit separate objective? =20 --- Inderpreet Singh =20 _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) Sent: Tuesday, June 07, 2005 4:27 PM To: capwap@frascone.com Subject: [Capwap] NAT traversal =20 All, =20 Would like to suggest adding a NAT traversal requirement to the CAPWAP objective document, i.e. the ability of AC and WTP to communicate across NAT device (UDP / TCP transport, refresh CAPWAP session at the NAT device, WTP identification behind NAT device, etc.). Deployment examples? say the WTP is located at branch office and the AC at the main office separated by NAT device, or within an Enterprise segregated by NAT devices. =20 Regards, Emek ------_=_NextPart_001_01C56C4E.915829BD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Inderpreet,
 
NAT=20 poses specific requirements whereas the interconnection objective, = at least=20 to my interpretation is too general. I would like to see an = explicit NATG=20 traversal objective and willing to put the wording around it if here no=20 objection from the group.
 
Emek

From: Inderpreet Singh=20 [mailto:inderpreet.singh@siemens.com]
Sent: Wednesday, June = 08, 2005=20 12:45 PM
To: Sadot, Emek (Emek);=20 capwap@frascone.com
Subject: RE: [Capwap] NAT=20 traversal

Sounds like a = good idea=20 but it may be implicitly covered under “Interconnection = Objective”.  Are=20 you suggesting we make an explicit separate objective?

 

---

Inderpreet=20 Singh

 

From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek = (Emek)
Sent: Tuesday, June 07, 2005 4:27 = PM
To:=20 capwap@frascone.com
Subject:=20 [Capwap] NAT traversal

 

All,

 

Would like to suggest = adding=20 a NAT traversal requirement to the CAPWAP objective document, = i.e. the=20 ability of AC and WTP to communicate across NAT device (UDP / TCP=20 transport, refresh CAPWAP session at the NAT device, WTP identification = behind=20 NAT device, etc.). Deployment examples? say the WTP is located=20 at branch office and the AC at the main office separated by NAT = device, or=20 within an Enterprise segregated by NAT devices.

 

Regards,

Emek

------_=_NextPart_001_01C56C4E.915829BD-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 9 03:55:09 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01136 for ; Thu, 9 Jun 2005 03:55:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B1BEC20518; Thu, 9 Jun 2005 03:55:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1C71320505; Thu, 9 Jun 2005 03:55:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 65AC420368 for ; Thu, 9 Jun 2005 03:54:50 -0400 (EDT) Received: from smtp2.mei.co.jp (smtp2.mei.co.jp [133.183.129.27]) by mail.frascone.com (Postfix) with ESMTP id 2EF66202DB for ; Thu, 9 Jun 2005 03:54:45 -0400 (EDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id j597sdpQ009942; Thu, 9 Jun 2005 16:54:39 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j597sdF07665; Thu, 9 Jun 2005 16:54:39 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with ESMTP id j597sdD06857; Thu, 9 Jun 2005 16:54:39 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56CC8.2777DF1C" Subject: RE: [Capwap] NAT traversal X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <5F09D220B62F79418461A978CA0921BD2F2979@pslexc01.psl.local> Thread-Topic: [Capwap] NAT traversal Thread-Index: AcVrn0BN0zy5JkI6Qi2V5rPKkheOWgBJ+Brg From: "Cheng Hong" To: "Sadot, Emek (Emek)" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 9 Jun 2005 15:52:18 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C56CC8.2777DF1C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Emek, =20 Would like to know a bit more about the deployment examples: =20 >>say the WTP is located at branch office and the AC at the main office separated by NAT device =20 In this case, most likely the NAT traversal is not a problem for the WTP or AC directly. For the branch office and main office case, most likely there will be a VPN setup between them. To the WTP and AC, NAT will be transparent.=20 =20 >>or within an Enterprise segregated by NAT devices. =20 Does this mean AC and WTP are on different side of the NAT? It sounds interesting, but is there any reason for deploy it in such a way (A NAT inside the enterprise network to separate the AC and WTP)?=20 =20 cheers =20 Cheng Hong =20 =20 ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) Sent: Wednesday, June 08, 2005 4:27 AM To: capwap@frascone.com Subject: [Capwap] NAT traversal =09 =09 All, =20 Would like to suggest adding a NAT traversal requirement to the CAPWAP objective document, i.e. the ability of AC and WTP to communicate across NAT device (UDP / TCP transport, refresh CAPWAP session at the NAT device, WTP identification behind NAT device, etc.). Deployment examples? say the WTP is located at branch office and the AC at the main office separated by NAT device, or within an Enterprise segregated by NAT devices. =20 Regards, Emek ------_=_NextPart_001_01C56CC8.2777DF1C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Emek,
 
Would=20 like to know a bit more about the deployment = examples:
 
>>say the WTP=20 is located at branch office and the AC at the main office separated = by NAT=20 device
 
In = this case, most=20 likely the NAT traversal is not a problem for the WTP or AC directly. = For the=20 branch office and main office case, most likely there will be a VPN = setup=20 between them. To the WTP and AC, NAT will be=20 transparent. 
 
 >>or within an Enterprise = segregated by NAT=20 devices.
 
Does = this mean AC=20 and WTP are on different side of the NAT? It sounds interesting, but is = there=20 any reason for deploy it in such a way (A NAT inside the enterprise = network to=20 separate the AC and WTP)?
 
cheers
 
Cheng=20 Hong
 
 

From: capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek=20 (Emek)
Sent: Wednesday, June 08, 2005 4:27 AM
To:=20 capwap@frascone.com
Subject: [Capwap] NAT=20 traversal

All,
 
Would like to=20 suggest adding a NAT traversal requirement to the CAPWAP = objective=20 document, i.e. the ability of AC and WTP to communicate = across NAT=20 device (UDP / TCP transport, refresh CAPWAP session at the NAT device, = WTP=20 identification behind NAT device, etc.). Deployment examples? say = the WTP=20 is located at branch office and the AC at the main office = separated by=20 NAT device, or within an Enterprise segregated by NAT=20 devices.
 
Regards,
Emek
------_=_NextPart_001_01C56CC8.2777DF1C-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 9 09:19:09 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28214 for ; Thu, 9 Jun 2005 09:19:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CEFCE2054A; Thu, 9 Jun 2005 09:19:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DA69E20530; Thu, 9 Jun 2005 09:19:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CC17E20530 for ; Thu, 9 Jun 2005 09:18:39 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id 6EBBB2052F for ; Thu, 9 Jun 2005 09:18:36 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 09 Jun 2005 06:18:36 -0700 Received: from pacalhouwxp ([10.32.30.113]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j59DIXlq027514; Thu, 9 Jun 2005 06:18:34 -0700 (PDT) Message-Id: <200506091318.j59DIXlq027514@sj-core-5.cisco.com> From: "Pat Calhoun" To: "'Cheng Hong'" , "'Sadot, Emek (Emek)'" , Subject: RE: [Capwap] NAT traversal MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0174_01C56CBB.110F32A0" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVrn0BN0zy5JkI6Qi2V5rPKkheOWgBJ+BrgAAuifLA= In-Reply-To: <5F09D220B62F79418461A978CA0921BD2F2979@pslexc01.psl.local> X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.30.113] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 9 Jun 2005 06:18:33 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------=_NextPart_000_0174_01C56CBB.110F32A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Imagine a service provider connecting their AC to their customer's WTPs across a NAT. Makes sense to me. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Cheng Hong Sent: Thursday, June 09, 2005 12:52 AM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] NAT traversal Hi Emek, Would like to know a bit more about the deployment examples: >>say the WTP is located at branch office and the AC at the main office separated by NAT device In this case, most likely the NAT traversal is not a problem for the WTP or AC directly. For the branch office and main office case, most likely there will be a VPN setup between them. To the WTP and AC, NAT will be transparent. >>or within an Enterprise segregated by NAT devices. Does this mean AC and WTP are on different side of the NAT? It sounds interesting, but is there any reason for deploy it in such a way (A NAT inside the enterprise network to separate the AC and WTP)? cheers Cheng Hong _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) Sent: Wednesday, June 08, 2005 4:27 AM To: capwap@frascone.com Subject: [Capwap] NAT traversal All, Would like to suggest adding a NAT traversal requirement to the CAPWAP objective document, i.e. the ability of AC and WTP to communicate across NAT device (UDP / TCP transport, refresh CAPWAP session at the NAT device, WTP identification behind NAT device, etc.). Deployment examples? say the WTP is located at branch office and the AC at the main office separated by NAT device, or within an Enterprise segregated by NAT devices. Regards, Emek ------=_NextPart_000_0174_01C56CBB.110F32A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Imagine a service provider connecting their AC = to their=20 customer's WTPs across a NAT. Makes sense to me.
 

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

 

From: capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Cheng=20 Hong
Sent: Thursday, June 09, 2005 12:52 AM
To: = Sadot,=20 Emek (Emek); capwap@frascone.com
Subject: RE: [Capwap] NAT=20 traversal

Hi=20 Emek,
 
Would like to know a bit more about the deployment=20 examples:
 
>>say the=20 WTP is located at branch office and the AC at the main office = separated=20 by NAT device
 
In = this case, most=20 likely the NAT traversal is not a problem for the WTP or AC directly. = For the=20 branch office and main office case, most likely there will be a VPN = setup=20 between them. To the WTP and AC, NAT will be=20 transparent. 
 
 >>or within an Enterprise = segregated by NAT=20 devices.
 
Does = this mean AC=20 and WTP are on different side of the NAT? It sounds interesting, but = is there=20 any reason for deploy it in such a way (A NAT inside the enterprise = network to=20 separate the AC and WTP)?
 
cheers
 
Cheng=20 Hong
 
 

From: capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek=20 (Emek)
Sent: Wednesday, June 08, 2005 4:27 = AM
To:=20 capwap@frascone.com
Subject: [Capwap] NAT=20 traversal

All,
 
Would like to=20 suggest adding a NAT traversal requirement to the CAPWAP = objective=20 document, i.e. the ability of AC and WTP to communicate = across NAT=20 device (UDP / TCP transport, refresh CAPWAP session at the NAT = device, WTP=20 identification behind NAT device, etc.). Deployment examples? = say the=20 WTP is located at branch office and the AC at the main office = separated=20 by NAT device, or within an Enterprise segregated by NAT=20 devices.
 
Regards,
Emek
= ------=_NextPart_000_0174_01C56CBB.110F32A0-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From dulcose@didamail.com Thu Jun 9 13:38:15 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25899; Thu, 9 Jun 2005 13:38:15 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgRKN-0003LO-Vo; Thu, 09 Jun 2005 14:00:28 -0400 Received: from [61.37.132.61] (helo=XCOUNTER) by mx2.foretec.com with smtp (Exim 4.24) id 1DgQyi-0004v6-Ca; Thu, 09 Jun 2005 13:38:05 -0400 Received: from naws.biz by limpidjwe (fc.4st) id utuqjdrdze with SMTP; Thu, 09 Jun 2005 13:12:22 -0500 Message-ID: <20041eokry3.ED8DA244AE@mailhost1o.lists.techtarget.com> Date: Thu, 09 Jun 2005 14:14:22 -0400 From: "Stella Stallings" To: cancer@ietf.org Cc: capwap-archive@ietf.org, ccips@ietf.org, cclark@ietf.org, cdi-archive@ietf.org, cdir-admin@ietf.org, cfrg@ietf.org, cfrg-admin@ietf.org, cfrg-archive@ietf.org Subject: Become one of the low rates X-Mailer: KYX CP/M FNORD 5602 X-Spam-Score: 16.9 (++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have been selected for our lowest rate in years... You could get over $420,000 for as little as $400 a month! Ba(d credit, Bank*ruptcy? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.jo1nt.com/signs.asp Best Regards, Jamal Crum to be remov(ed: http://www.jo1nt.com/deletion.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From capwap-admin@frascone.com Thu Jun 9 16:46:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19035 for ; Thu, 9 Jun 2005 16:46:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 55DCE20460; Thu, 9 Jun 2005 16:46:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1A59F20435; Thu, 9 Jun 2005 16:46:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7C00A20435 for ; Thu, 9 Jun 2005 16:45:28 -0400 (EDT) Received: from smtpout1.bayarea.net (smtpout1.bayarea.net [209.128.95.10]) by mail.frascone.com (Postfix) with ESMTP id 5C699203A8 for ; Thu, 9 Jun 2005 16:45:25 -0400 (EDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j59KhmeQ012301; Thu, 9 Jun 2005 13:43:48 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j59KhiTS007142; Thu, 9 Jun 2005 13:43:44 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j59Khi8B007137; Thu, 9 Jun 2005 13:43:44 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Pat Calhoun Cc: "'Cheng Hong'" , "'Sadot, Emek (Emek)'" , capwap@frascone.com Subject: RE: [Capwap] NAT traversal In-Reply-To: <200506091318.j59DIXlq027514@sj-core-5.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 9 Jun 2005 13:43:43 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) HI, While it is possible, I really don't understand the motivation for an IP service provider to provide this service. Also, which address space would the stations be put in? Would you show a diagram with the IP address pools, and the wired and wireless overlays. Thanks, /david t. perkins On Thu, 9 Jun 2005, Pat Calhoun wrote: > Imagine a service provider connecting their AC to their customer's WTPs > across a NAT. Makes sense to me. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > _____ > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf > Of Cheng Hong > Sent: Thursday, June 09, 2005 12:52 AM > To: Sadot, Emek (Emek); capwap@frascone.com > Subject: RE: [Capwap] NAT traversal > > > Hi Emek, > > Would like to know a bit more about the deployment examples: > > >>say the WTP is located at branch office and the AC at the main office > separated by NAT device > > In this case, most likely the NAT traversal is not a problem for the WTP or > AC directly. For the branch office and main office case, most likely there > will be a VPN setup between them. To the WTP and AC, NAT will be > transparent. > > >>or within an Enterprise segregated by NAT devices. > > Does this mean AC and WTP are on different side of the NAT? It sounds > interesting, but is there any reason for deploy it in such a way (A NAT > inside the enterprise network to separate the AC and WTP)? > > cheers > > Cheng Hong > > > > > _____ > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf > Of Sadot, Emek (Emek) > Sent: Wednesday, June 08, 2005 4:27 AM > To: capwap@frascone.com > Subject: [Capwap] NAT traversal > > > All, > > Would like to suggest adding a NAT traversal requirement to the CAPWAP > objective document, i.e. the ability of AC and WTP to communicate across NAT > device (UDP / TCP transport, refresh CAPWAP session at the NAT device, WTP > identification behind NAT device, etc.). Deployment examples? say the WTP is > located at branch office and the AC at the main office separated by NAT > device, or within an Enterprise segregated by NAT devices. > > Regards, > Emek > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 9 17:28:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21433 for ; Thu, 9 Jun 2005 17:28:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BC7912054D; Thu, 9 Jun 2005 17:28:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9D92D20475; Thu, 9 Jun 2005 17:28:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1408D20475 for ; Thu, 9 Jun 2005 17:28:00 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id 107B42044E for ; Thu, 9 Jun 2005 17:27:58 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 09 Jun 2005 14:27:58 -0700 Received: from pacalhouwxp ([10.32.30.113]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j59LRtlq020932 for ; Thu, 9 Jun 2005 14:27:56 -0700 (PDT) Message-Id: <200506092127.j59LRtlq020932@sj-core-5.cisco.com> From: "Pat Calhoun" To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVtOhnDF7wSogXjSc25RD55TDTCAA== X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.30.113] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Taxonomy Recommendations Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 9 Jun 2005 14:27:55 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit All, I wanted to announce the early availability of the CAPWAP taxonomy recommendation draft that Bob O'Hara Inderpreet Singh and I have been working on. It can be found at http://www.capwap.org/draft-calhoun-capwap-taxonomy-recommendation-00.txt. Abstract The IETF's CAPWAP working group has documented various product architectures and has categorized the Centralized WLAN Architectures into two main buckets: Split and Local MAC. While the document contains very relevant and useful information, what it does is list the architectural variants of these two buckets, but does not unambiguously define either the Split MAC or Local MAC architectures. In order for CAPWAP to be successful, it is crucial for the protocol evaluation team, and the working group, to agree on unambiguous terminology to describe these architectures. This document proposes terminology to unambiguously describe the relevant architectures found in the taxonomy document, for the purpose of initiating a discussion within the working group and to allow the protocol evaluation work to come to a fruitful conclusion. We conclude in this document that the architectures are very similar and could be supported via a single protocol. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 9 17:56:10 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23284 for ; Thu, 9 Jun 2005 17:56:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2FD6A20559; Thu, 9 Jun 2005 17:56:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 77C2520475; Thu, 9 Jun 2005 17:56:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2B09720475 for ; Thu, 9 Jun 2005 17:55:13 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 11E352044E for ; Thu, 9 Jun 2005 17:55:11 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j59LnTgm003425; Thu, 9 Jun 2005 14:49:29 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200506092149.j59LnTgm003425@homebrew.trpz.com> To: "Pat Calhoun" Cc: capwap@frascone.com Subject: Re: [Capwap] Taxonomy Recommendations In-Reply-To: Your message of "Thu, 09 Jun 2005 14:27:55 PDT." <200506092127.j59LRtlq020932@sj-core-5.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3423.1118353769.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 09 Jun 2005 14:49:29 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Pat, I'm sure that everyone appreciates the hard work you've done-- I certainly do-- but I think it is necessary to note that this is just a personal submission and does not carry any offical weight in the working group. As Dorothy has pointed out, we're on a tight timeline here. If we allow random individual submissions to constrain or influence our work we'll never get done. I do not think your draft should be used to bring protocol evaluation to a fruitful conclusion. Dan. On Thu, 09 Jun 2005 14:27:55 PDT you wrote > All, > > I wanted to announce the early availability of the CAPWAP taxonomy > recommendation draft that Bob O'Hara Inderpreet Singh and I have been > working on. It can be found at > http://www.capwap.org/draft-calhoun-capwap-taxonomy-recommendation-00.txt. > > > Abstract > > The IETF's CAPWAP working group has documented various product > architectures and has categorized the Centralized WLAN Architectures > into two main buckets: Split and Local MAC. While the document > contains very relevant and useful information, what it does is list > the architectural variants of these two buckets, but does not > unambiguously define either the Split MAC or Local MAC architectures. > In order for CAPWAP to be successful, it is crucial for the protocol > evaluation team, and the working group, to agree on unambiguous > terminology to describe these architectures. > > This document proposes terminology to unambiguously describe the > relevant architectures found in the taxonomy document, for the > purpose of initiating a discussion within the working group and to > allow the protocol evaluation work to come to a fruitful conclusion. > We conclude in this document that the architectures are very similar > and could be supported via a single protocol. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 9 19:23:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29295 for ; Thu, 9 Jun 2005 19:23:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B734720563; Thu, 9 Jun 2005 19:23:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7F41B20475; Thu, 9 Jun 2005 19:23:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3E22A20475 for ; Thu, 9 Jun 2005 19:22:24 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id 3F82D2044E for ; Thu, 9 Jun 2005 19:22:22 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 09 Jun 2005 16:22:22 -0700 Received: from pacalhouwxp ([10.32.30.113]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j59NMJlq021158; Thu, 9 Jun 2005 16:22:19 -0700 (PDT) Message-Id: <200506092322.j59NMJlq021158@sj-core-5.cisco.com> From: "Pat Calhoun" To: "'David T. Perkins'" Cc: "'Cheng Hong'" , "'Sadot, Emek (Emek)'" , Subject: RE: [Capwap] NAT traversal MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVtNGICoY7W1bG/TfSvLUtPeDE3GQAFYfLQ In-Reply-To: X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.30.113] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 9 Jun 2005 16:22:19 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Assuming that Local MAC means local bridging, then the station could get an IP address from a local DHCP server. However, the WTP could be a managed service by the service provider (could include cool firewall features, etc). I'm not in this business, I'm simply stating a possibility for an application that could include a NAT. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of David T. Perkins > Sent: Thursday, June 09, 2005 1:44 PM > To: Pat Calhoun > Cc: 'Cheng Hong'; 'Sadot, Emek (Emek)'; capwap@frascone.com > Subject: RE: [Capwap] NAT traversal > > HI, > > While it is possible, I really don't understand the > motivation for an IP service provider to provide this > service. Also, which address space would the stations be put > in? Would you show a diagram with the IP address pools, and > the wired and wireless overlays. > > Thanks, > /david t. perkins > > On Thu, 9 Jun 2005, Pat Calhoun wrote: > > > Imagine a service provider connecting their AC to their customer's > > WTPs across a NAT. Makes sense to me. > > > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > > _____ > > > > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On > > Behalf Of Cheng Hong > > Sent: Thursday, June 09, 2005 12:52 AM > > To: Sadot, Emek (Emek); capwap@frascone.com > > Subject: RE: [Capwap] NAT traversal > > > > > > Hi Emek, > > > > Would like to know a bit more about the deployment examples: > > > > >>say the WTP is located at branch office and the AC at the main > > >>office > > separated by NAT device > > > > In this case, most likely the NAT traversal is not a > problem for the > > WTP or AC directly. For the branch office and main office > case, most > > likely there will be a VPN setup between them. To the WTP > and AC, NAT > > will be transparent. > > > > >>or within an Enterprise segregated by NAT devices. > > > > Does this mean AC and WTP are on different side of the NAT? > It sounds > > interesting, but is there any reason for deploy it in such a way (A > > NAT inside the enterprise network to separate the AC and WTP)? > > > > cheers > > > > Cheng Hong > > > > > > > > > > _____ > > > > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On > > Behalf Of Sadot, Emek (Emek) > > Sent: Wednesday, June 08, 2005 4:27 AM > > To: capwap@frascone.com > > Subject: [Capwap] NAT traversal > > > > > > All, > > > > Would like to suggest adding a NAT traversal requirement to > the CAPWAP > > objective document, i.e. the ability of AC and WTP to communicate > > across NAT device (UDP / TCP transport, refresh CAPWAP > session at the > > NAT device, WTP identification behind NAT device, etc.). Deployment > > examples? say the WTP is located at branch office and the AC at the > > main office separated by NAT device, or within an > Enterprise segregated by NAT devices. > > > > Regards, > > Emek > > > > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 9 19:25:12 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29425 for ; Thu, 9 Jun 2005 19:25:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0B1892056A; Thu, 9 Jun 2005 19:25:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E03252055F; Thu, 9 Jun 2005 19:25:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3A7592055F for ; Thu, 9 Jun 2005 19:24:19 -0400 (EDT) Received: from smtp4.centerbeam.com (smtp4.centerbeam.com [63.120.115.248]) by mail.frascone.com (Postfix) with ESMTP id D786220559 for ; Thu, 9 Jun 2005 19:24:16 -0400 (EDT) Received: from cba0e2k00.CBA0.centerbeam.com ([64.95.101.25]) by smtp4.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Jun 2005 16:25:24 -0700 Received: from CBA0E2K06.CBA0.centerbeam.com ([64.95.101.40]) by cba0e2k00.CBA0.centerbeam.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 9 Jun 2005 16:24:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56D4A.53B31938" Subject: RE: [Capwap] NAT traversal Message-ID: Thread-Topic: [Capwap] NAT traversal Thread-Index: AcVrn0BN0zy5JkI6Qi2V5rPKkheOWgBJ+BrgAAuifLAAA4qEsA== From: "Darren Loher" To: "Pat Calhoun" , "Cheng Hong" , "Sadot, Emek (Emek)" , X-OriginalArrivalTime: 09 Jun 2005 23:24:05.0342 (UTC) FILETIME=[53F3C7E0:01C56D4A] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 9 Jun 2005 16:24:03 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C56D4A.53B31938 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable On the requirements side for NAT, should we specify if the WTP is behind NAT, the AC behind NAT or both? I can see two basic scenarios realistically being implemented: =20 Assume: - Hotspot provider uses whatever available broadband connection as an Internet uplink -This connection is limited to one, dynamically assigned IP address -NAT is required to share the connection with multiple hosts =20 Scenario 1: The hotspot provider's AC is on the open Internet Scenario 2: The hotspot provider's AC is behind a NAT firewall and the hotspot provider has port forwarding and/or static NAT control of this firewall =20 There could be several more, but these seem very common and straightforward. =20 -Darren =20 =20 =20 ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun Sent: Thursday, June 09, 2005 7:19 AM To: 'Cheng Hong'; 'Sadot, Emek (Emek)'; capwap@frascone.com Subject: RE: [Capwap] NAT traversal =20 Imagine a service provider connecting their AC to their customer's WTPs across a NAT. Makes sense to me. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Cheng Hong Sent: Thursday, June 09, 2005 12:52 AM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] NAT traversal Hi Emek, =20 Would like to know a bit more about the deployment examples: =20 >>say the WTP is located at branch office and the AC at the main office separated by NAT device =20 In this case, most likely the NAT traversal is not a problem for the WTP or AC directly. For the branch office and main office case, most likely there will be a VPN setup between them. To the WTP and AC, NAT will be transparent.=20 =20 >>or within an Enterprise segregated by NAT devices. =20 Does this mean AC and WTP are on different side of the NAT? It sounds interesting, but is there any reason for deploy it in such a way (A NAT inside the enterprise network to separate the AC and WTP)?=20 =20 cheers =20 Cheng Hong =20 =20 =20 =09 ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) Sent: Wednesday, June 08, 2005 4:27 AM To: capwap@frascone.com Subject: [Capwap] NAT traversal All, =20 Would like to suggest adding a NAT traversal requirement to the CAPWAP objective document, i.e. the ability of AC and WTP to communicate across NAT device (UDP / TCP transport, refresh CAPWAP session at the NAT device, WTP identification behind NAT device, etc.). Deployment examples? say the WTP is located at branch office and the AC at the main office separated by NAT device, or within an Enterprise segregated by NAT devices. =20 Regards, Emek ------_=_NextPart_001_01C56D4A.53B31938 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

On the requirements side for NAT, sh= ould we specify if the WTP is behind NAT, the AC behind NAT or both?  I c= an see two basic scenarios realistically being implemented:

 

Assume:

=

- Hotspot provider uses whatever ava= ilable broadband connection as an Internet uplink

-This connection = is limited to one, dynamically assigned IP address

-NAT is required = to share the connection with multiple hosts

 

Scenario 1: The hotspot providerR= 17;s AC is on the open Internet

Scenario 2: The hotspot providerR= 17;s AC is behind a NAT firewall and the hotspot provider has port forwarding = and/or static NAT control of this firewall

 

There could be several more, but the= se seem very common and straightforward.

 

-Darren

=

 

 

 

From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun
Sent: Thursday, June 09, 2= 005 7:19 AM
To: 'Cheng Hong'; 'Sadot, = Emek (Emek)'; capwap@frascone.com
Subject: RE: [Capwap] NAT traversal

 

Imagine a service provider connectin= g their AC to their customer's WTPs across a NAT. Makes sense to me.=

 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

 

From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Cheng Hong
Sent: Thursday, June 09, 2= 005 12:52 AM
To: Sadot, Emek (Emek); capwap@frascone.com
Subject: RE: [Capwap] NAT traversal

Hi Emek,

 

Would like to know a bit more about = the deployment examples:

 

>>say the WTP is located at branch office a= nd the AC at the main office separated by NAT device

 

In this case, most likely the NAT traversal is not a p= roblem for the WTP or AC directly. For the branch office and main office case, m= ost likely there will be a VPN setup between them. To the WTP and AC, NA= T will be transparent. 

 

 >>or within an En= terprise segregated by NAT devices.

 

Does this mean AC and WTP are on different side of the= NAT? It sounds interesting, but is there any reason for deploy it in such a wa= y (A NAT inside the enterprise network to separate the AC and WTP)?

 

cheers

 

Cheng Hong

 

 

 

From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek)
= Sent: Wednesday, June 08, = 2005 4:27 AM
To: capwap@frascone.com Subject: [Capwap] NAT trav= ersal

All,

 

Would like to suggest adding a NAT traversal requirement to the CAPWAP objective document, i.e. the ability of AC= and WTP to communicate across NAT device (UDP / TCP transport, refresh C= APWAP session at the NAT device, WTP identification behind NAT device, etc= =2E). Deployment examples? say the WTP is located at branch office and the= AC at the main office separated by NAT device, or within an Enterprise segregated by NAT devices.=

 

Regards,

Emek

------_=_NextPart_001_01C56D4A.53B31938-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 9 20:21:10 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02378 for ; Thu, 9 Jun 2005 20:21:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 337CC20575; Thu, 9 Jun 2005 20:21:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4550120563; Thu, 9 Jun 2005 20:21:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EDF6020563 for ; Thu, 9 Jun 2005 20:20:42 -0400 (EDT) Received: from smtpout1.bayarea.net (smtpout1.bayarea.net [209.128.95.10]) by mail.frascone.com (Postfix) with ESMTP id 0943A2044E for ; Thu, 9 Jun 2005 20:20:40 -0400 (EDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j5A0KZeQ003111; Thu, 9 Jun 2005 17:20:35 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j5A0Jkv9027887; Thu, 9 Jun 2005 17:19:46 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j5A0JjJ7027884; Thu, 9 Jun 2005 17:19:45 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Darren Loher Cc: Pat Calhoun , Cheng Hong , "Sadot, Emek (Emek)" , capwap@frascone.com Subject: RE: [Capwap] NAT traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 9 Jun 2005 17:19:45 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) HI Darren & Pat, I'm still having a problem understanding what you are trying to accomplish. Here is a picture.... /------------\ 209.128.82.1 10.1.1.1 /---------------\ | | ---------- | | | Internet |-----------|NAT box |-----|Private Network | | |--- ---------- |(say 10.1.1.0/16)| \-----------/ \ \---------------/ | \ | AC \ WTP STA-IP=? 209.128.82.62 \ 10.1.2.1 \ /---------------\ \ ---------- | | --|NAT box |-----|Private Network | ---------- |(say 10.1.1.0/16)| 209.128.82.2 10.1.1.1 \---------------/ | WTP STA-IP=? 10.1.2.1 More NAT boxes Is this what you are talking about? And If so, tell me again what problem are you trying to solve, or service that you are wanting to provide? Regards, /david t. perkins On Thu, 9 Jun 2005, Darren Loher wrote: > On the requirements side for NAT, should we specify if the WTP is behind > NAT, the AC behind NAT or both? I can see two basic scenarios > realistically being implemented: > > > > Assume: > > - Hotspot provider uses whatever available broadband connection as an > Internet uplink > > -This connection is limited to one, dynamically assigned IP address > > -NAT is required to share the connection with multiple hosts > > > > Scenario 1: The hotspot provider's AC is on the open Internet > > Scenario 2: The hotspot provider's AC is behind a NAT firewall and the > hotspot provider has port forwarding and/or static NAT control of this > firewall > > > > There could be several more, but these seem very common and > straightforward. > > > > -Darren > > > > > > > > ________________________________ > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Pat Calhoun > Sent: Thursday, June 09, 2005 7:19 AM > To: 'Cheng Hong'; 'Sadot, Emek (Emek)'; capwap@frascone.com > Subject: RE: [Capwap] NAT traversal > > > > Imagine a service provider connecting their AC to their customer's WTPs > across a NAT. Makes sense to me. > > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > > > ________________________________ > > > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Cheng Hong > Sent: Thursday, June 09, 2005 12:52 AM > To: Sadot, Emek (Emek); capwap@frascone.com > Subject: RE: [Capwap] NAT traversal > > Hi Emek, > > > > Would like to know a bit more about the deployment examples: > > > > >>say the WTP is located at branch office and the AC at the main > office separated by NAT device > > > > In this case, most likely the NAT traversal is not a problem for > the WTP or AC directly. For the branch office and main office case, most > likely there will be a VPN setup between them. To the WTP and AC, NAT > will be transparent. > > > > >>or within an Enterprise segregated by NAT devices. > > > > Does this mean AC and WTP are on different side of the NAT? It > sounds interesting, but is there any reason for deploy it in such a way > (A NAT inside the enterprise network to separate the AC and WTP)? > > > > cheers > > > > Cheng Hong > > > > > > > > > ________________________________ > > > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) > Sent: Wednesday, June 08, 2005 4:27 AM > To: capwap@frascone.com > Subject: [Capwap] NAT traversal > > All, > > > > Would like to suggest adding a NAT traversal requirement > to the CAPWAP objective document, i.e. the ability of AC and WTP to > communicate across NAT device (UDP / TCP transport, refresh CAPWAP > session at the NAT device, WTP identification behind NAT device, etc.). > Deployment examples? say the WTP is located at branch office and the AC > at the main office separated by NAT device, or within an Enterprise > segregated by NAT devices. > > > > Regards, > > Emek > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From flecked@fadmail.com Thu Jun 9 21:00:18 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05149; Thu, 9 Jun 2005 21:00:17 -0400 (EDT) Date: Thu, 9 Jun 2005 21:00:17 -0400 (EDT) From: flecked@fadmail.com Message-Id: <200506100100.VAA05149@ietf.org> Received: from c-67-191-39-38.hsd1.fl.comcast.net ([67.191.39.38]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DgYE9-0008M2-Pe; Thu, 09 Jun 2005 21:22:31 -0400 Received: from KXWQWzxac.com (EHLO ahdbt-a.abound.LG.mpl.net) quahog by mail.mtk.nao.ac.jp (5.7[2 X-Spam-Score: 5.1 (+++++) X-Spam-Flag: YES X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From capwap-admin@frascone.com Thu Jun 9 23:28:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15365 for ; Thu, 9 Jun 2005 23:28:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BF00820593; Thu, 9 Jun 2005 23:28:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0E29720564; Thu, 9 Jun 2005 23:28:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BA33420564 for ; Thu, 9 Jun 2005 23:27:23 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 9EE8E2044E for ; Thu, 9 Jun 2005 23:27:20 -0400 (EDT) Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5A3FYAK000582 for ; Thu, 9 Jun 2005 23:15:34 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5A3FWAK000554 for ; Thu, 9 Jun 2005 23:15:33 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] NAT traversal Message-ID: <5844A41F4E146044A2E8356C6328588008D1AEDD@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] NAT traversal Thread-Index: AcVtUjjqoIyJDYDLQpqY9OKf8k0tTgAFTAyQ From: "Sadot, Emek (Emek)" To: "David T. Perkins" , "Darren Loher" Cc: "Pat Calhoun" , "Cheng Hong" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 9 Jun 2005 23:27:18 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable David, Excellent diagram. Respectfully I would avoid naming "Internet" as NAT device can segregate Enterprise's internal segments. A second WTP in the private domain (10.1.2.2) may be helpful as well. A few problems presented by a NAT device: 1. NAT manipulate layer 4 ports -> CAPWAP protocol cannot be layer 3 protocol based. 2. Symmetric NAT will drop AC communicating with the WTP unless the WTP initiate the communication first. 3. WTP unique identification at the AC must not by WTP's IP address (and port) based. 4. WTP to AC CAPWAP session must be refreshed at the NAT device. 5. CAPWAP protocol shall be immunized against NAT device crash. More specifically, since session mapping will be erased at the NAT device the WTP (in contrast to the AC) must send CAPWAP to resume communication. Emek -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com]=20 Sent: Thursday, June 09, 2005 8:20 PM To: Darren Loher Cc: Pat Calhoun; Cheng Hong; Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] NAT traversal HI Darren & Pat, I'm still having a problem understanding what you are trying to accomplish. Here is a picture.... /------------\ 209.128.82.1 10.1.1.1 /---------------\ | | ---------- | | | Internet |-----------|NAT box |-----|Private Network | | |--- ---------- |(say 10.1.1.0/16)| \-----------/ \ \---------------/ | \ | AC \ WTP STA-IP=3D? 209.128.82.62 \ 10.1.2.1 \ /---------------\=20 \ ---------- | | --|NAT box |-----|Private Network | ---------- |(say 10.1.1.0/16)| 209.128.82.2 10.1.1.1 \---------------/ |=20 WTP STA-IP=3D? 10.1.2.1 More NAT boxes Is this what you are talking about? And If so, tell me again what problem are you trying to solve, or service that you are wanting to provide?=20 Regards, /david t. perkins On Thu, 9 Jun 2005, Darren Loher wrote: > On the requirements side for NAT, should we specify if the WTP is behind > NAT, the AC behind NAT or both? I can see two basic scenarios > realistically being implemented: >=20 > =20 >=20 > Assume: >=20 > - Hotspot provider uses whatever available broadband connection as an > Internet uplink >=20 > -This connection is limited to one, dynamically assigned IP address >=20 > -NAT is required to share the connection with multiple hosts >=20 > =20 >=20 > Scenario 1: The hotspot provider's AC is on the open Internet >=20 > Scenario 2: The hotspot provider's AC is behind a NAT firewall and the > hotspot provider has port forwarding and/or static NAT control of this > firewall >=20 > =20 >=20 > There could be several more, but these seem very common and > straightforward. >=20 > =20 >=20 > -Darren >=20 > =20 >=20 > =20 >=20 > =20 >=20 > ________________________________ >=20 > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Pat Calhoun > Sent: Thursday, June 09, 2005 7:19 AM > To: 'Cheng Hong'; 'Sadot, Emek (Emek)'; capwap@frascone.com > Subject: RE: [Capwap] NAT traversal >=20 > =20 >=20 > Imagine a service provider connecting their AC to their customer's WTPs > across a NAT. Makes sense to me. >=20 > =20 >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems >=20 > =20 >=20 > =20 >=20 > =09 > ________________________________ >=20 >=20 > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Cheng Hong > Sent: Thursday, June 09, 2005 12:52 AM > To: Sadot, Emek (Emek); capwap@frascone.com > Subject: RE: [Capwap] NAT traversal >=20 > Hi Emek, >=20 > =20 >=20 > Would like to know a bit more about the deployment examples: >=20 > =20 >=20 > >>say the WTP is located at branch office and the AC at the main > office separated by NAT device >=20 > =20 >=20 > In this case, most likely the NAT traversal is not a problem for > the WTP or AC directly. For the branch office and main office case, most > likely there will be a VPN setup between them. To the WTP and AC, NAT > will be transparent.=20 >=20 > =20 >=20 > >>or within an Enterprise segregated by NAT devices. >=20 > =20 >=20 > Does this mean AC and WTP are on different side of the NAT? It > sounds interesting, but is there any reason for deploy it in such a way > (A NAT inside the enterprise network to separate the AC and WTP)?=20 >=20 > =20 >=20 > cheers >=20 > =20 >=20 > Cheng Hong >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =09 > ________________________________ >=20 >=20 > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) > Sent: Wednesday, June 08, 2005 4:27 AM > To: capwap@frascone.com > Subject: [Capwap] NAT traversal >=20 > All, >=20 > =20 >=20 > Would like to suggest adding a NAT traversal requirement > to the CAPWAP objective document, i.e. the ability of AC and WTP to > communicate across NAT device (UDP / TCP transport, refresh CAPWAP > session at the NAT device, WTP identification behind NAT device, etc.). > Deployment examples? say the WTP is located at branch office and the AC > at the main office separated by NAT device, or within an Enterprise > segregated by NAT devices. >=20 > =20 >=20 > Regards, >=20 > Emek >=20 >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 9 23:47:12 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16147 for ; Thu, 9 Jun 2005 23:47:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6A0282058E; Thu, 9 Jun 2005 23:47:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A19932044E; Thu, 9 Jun 2005 23:47:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DC1A32058E for ; Thu, 9 Jun 2005 23:46:38 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 46EE62044E for ; Thu, 9 Jun 2005 23:46:35 -0400 (EDT) Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5A3YnAK024441 for ; Thu, 9 Jun 2005 23:34:49 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5A3YmAK024419 for ; Thu, 9 Jun 2005 23:34:48 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56D6E.FEB5BD75" Subject: RE: [Capwap] NAT traversal Message-ID: <5844A41F4E146044A2E8356C6328588008D1AEE1@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] NAT traversal Thread-Index: AcVrn0BN0zy5JkI6Qi2V5rPKkheOWgBJ+BrgAAuifLAAA4qEsAAaH6vg From: "Sadot, Emek (Emek)" To: "Darren Loher" , "Pat Calhoun" , "Cheng Hong" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 9 Jun 2005 23:46:33 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C56D6E.FEB5BD75 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If both, AC and WTP, are behind symmetric NAT device then we have a problem due to the nature of symmetric NAT. It get worse if the AC obtains its IP address via DHCP protocol. If the AC is behind a symmetric NAT device and have a static IP address then administratively that NAT device can be configure to honor / accept WTP CAPWAP requests from the public side. =20 It boiled down to the question how the AC's IP address would be discovered by the WTP. - If the AC obtains its IP address via DHCP and register its IP address to a server where later the WTP will inquire then we have a problem. - If the AC is statically assigned with an IP address then the problem can be administratively mitigated (see above). =20 Emek _____ =20 From: Darren Loher [mailto:DLoher@rovingplanet.com]=20 Sent: Thursday, June 09, 2005 7:24 PM To: Pat Calhoun; Cheng Hong; Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] NAT traversal On the requirements side for NAT, should we specify if the WTP is behind NAT, the AC behind NAT or both? I can see two basic scenarios realistically being implemented: =20 Assume: - Hotspot provider uses whatever available broadband connection as an Internet uplink -This connection is limited to one, dynamically assigned IP address -NAT is required to share the connection with multiple hosts =20 Scenario 1: The hotspot provider's AC is on the open Internet Scenario 2: The hotspot provider's AC is behind a NAT firewall and the hotspot provider has port forwarding and/or static NAT control of this firewall =20 There could be several more, but these seem very common and straightforward. =20 -Darren =20 =20 =20 _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun Sent: Thursday, June 09, 2005 7:19 AM To: 'Cheng Hong'; 'Sadot, Emek (Emek)'; capwap@frascone.com Subject: RE: [Capwap] NAT traversal =20 Imagine a service provider connecting their AC to their customer's WTPs across a NAT. Makes sense to me. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Cheng Hong Sent: Thursday, June 09, 2005 12:52 AM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] NAT traversal Hi Emek, =20 Would like to know a bit more about the deployment examples: =20 >>say the WTP is located at branch office and the AC at the main office separated by NAT device =20 In this case, most likely the NAT traversal is not a problem for the WTP or AC directly. For the branch office and main office case, most likely there will be a VPN setup between them. To the WTP and AC, NAT will be transparent.=20 =20 >>or within an Enterprise segregated by NAT devices. =20 Does this mean AC and WTP are on different side of the NAT? It sounds interesting, but is there any reason for deploy it in such a way (A NAT inside the enterprise network to separate the AC and WTP)?=20 =20 cheers =20 Cheng Hong =20 =20 =20 =09 _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) Sent: Wednesday, June 08, 2005 4:27 AM To: capwap@frascone.com Subject: [Capwap] NAT traversal All, =20 Would like to suggest adding a NAT traversal requirement to the CAPWAP objective document, i.e. the ability of AC and WTP to communicate across NAT device (UDP / TCP transport, refresh CAPWAP session at the NAT device, WTP identification behind NAT device, etc.). Deployment examples? say the WTP is located at branch office and the AC at the main office separated by NAT device, or within an Enterprise segregated by NAT devices. =20 Regards, Emek ------_=_NextPart_001_01C56D6E.FEB5BD75 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
If=20 both, AC and WTP, are behind symmetric NAT device then we have a problem = due to=20 the nature of symmetric NAT. It get worse if the AC obtains=20 its IP address via DHCP protocol. If the AC is behind a symmetric = NAT=20 device and have a static IP address then administratively that NAT = device=20 can be configure to honor / accept WTP CAPWAP requests from the public=20 side.
 
It=20 boiled down to the question how the AC's IP address would=20 be discovered by the WTP.
- If=20 the AC obtains its IP address via DHCP and register its IP address to a = server=20 where later the WTP will inquire then we have a=20 problem.
- If=20 the AC is statically assigned with an IP address then the problem can be = administratively mitigated (see above).
 
Emek

From: Darren Loher=20 [mailto:DLoher@rovingplanet.com]
Sent: Thursday, June 09, = 2005 7:24=20 PM
To: Pat Calhoun; Cheng Hong; Sadot, Emek (Emek);=20 capwap@frascone.com
Subject: RE: [Capwap] NAT=20 traversal

On the = requirements=20 side for NAT, should we specify if the WTP is behind NAT, the AC behind = NAT or=20 both?  I can see two basic scenarios realistically being=20 implemented:

 

Assume:

- Hotspot = provider uses=20 whatever available broadband connection as an Internet=20 uplink

-This=20 connection is limited to one, dynamically assigned IP=20 address

-NAT is=20 required to share the connection with multiple=20 hosts

 

Scenario 1: = The hotspot=20 provider’s AC is on the open Internet

Scenario 2: = The hotspot=20 provider’s AC is behind a NAT firewall and the hotspot provider = has port=20 forwarding and/or static NAT control of this=20 firewall

 

There could = be several=20 more, but these seem very common and=20 straightforward.

 

-Darren

 

 

 

From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat = Calhoun
Sent: Thursday, June 09, 2005 = 7:19=20 AM
To: 'Cheng Hong'; = 'Sadot,=20 Emek (Emek)'; capwap@frascone.com
Subject: RE: [Capwap] NAT=20 traversal

 

Imagine a = service=20 provider connecting their AC to their customer's WTPs across a NAT. = Makes sense=20 to me.

 

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

 

 

From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Cheng = Hong
Sent: Thursday, June 09, 2005 = 12:52=20 AM
To: Sadot, Emek = (Emek);=20 capwap@frascone.com
Subject:=20 RE: [Capwap] NAT traversal

Hi=20 Emek,

 

Would like = to know a=20 bit more about the deployment = examples:

 

>>say the WTP is = located=20 at branch office and the AC at the main office separated by NAT=20 device

 

In this case, most = likely the NAT=20 traversal is not a problem for the WTP or AC directly. For the branch = office=20 and main office case, most likely there will be a VPN setup between = them. To=20 the WTP and AC, NAT will be=20 transparent. 

 

 >>or within = an=20 Enterprise segregated = by NAT=20 devices.

 

Does this mean AC and = WTP are on=20 different side of the NAT? It sounds interesting, but is there any = reason for=20 deploy it in such a way (A NAT inside the enterprise network to = separate the=20 AC and WTP)?

 

cheers

 

Cheng=20 Hong

 

 

 

From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] = On Behalf Of Sadot, Emek=20 (Emek)
Sent: = Wednesday,=20 June 08, 2005 4:27 AM
To:=20 capwap@frascone.com
Subject: [Capwap] NAT=20 traversal

All,

 

Would like to suggest = adding=20 a NAT traversal requirement to the CAPWAP objective document,=20 i.e. the ability of AC and WTP to communicate across NAT = device=20 (UDP / TCP transport, refresh CAPWAP session at the NAT device, WTP=20 identification behind NAT device, etc.). Deployment examples? = say the=20 WTP is located at branch office and the AC at the main office = separated=20 by NAT device, or within an Enterprise = segregated by NAT=20 devices.

 

Regards,

Emek

<= /DIV>
------_=_NextPart_001_01C56D6E.FEB5BD75-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jun 10 01:31:09 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23250 for ; Fri, 10 Jun 2005 01:31:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4F9F0205D8; Fri, 10 Jun 2005 01:31:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0B53320593; Fri, 10 Jun 2005 01:31:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6A59820593 for ; Fri, 10 Jun 2005 01:30:02 -0400 (EDT) Received: from smtp103.mail.sc5.yahoo.com (smtp103.mail.sc5.yahoo.com [66.163.169.222]) by mail.frascone.com (Postfix) with SMTP id 51E862044E for ; Fri, 10 Jun 2005 01:29:59 -0400 (EDT) Received: (qmail 31804 invoked from network); 10 Jun 2005 05:29:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:Message-ID:Date:From:Reply-To:User-Agent:X-Accept-Language:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=eb/grezYTbTrDrZ1K04otZ1uKyixX1RhhrF9V/D7BdEGrqOdEAS8AXVQTQzrGxI0IKHQpRY00Y67hgxvPk7Z/9aAr2UQ5dochIirecIUJArEWUZNh5KJn7ihh7Tf0J/IwLvW9Bo5KQUREGCdIiVoQ0+ZTDXvuoiPqspDBgK6/9U= ; Received: from unknown (HELO ?192.168.1.100?) (behcetsarikaya@24.71.246.198 with plain) by smtp103.mail.sc5.yahoo.com with SMTP; 10 Jun 2005 05:29:58 -0000 Message-ID: <42A92556.7080605@yahoo.com> From: Behcet Sarikaya Reply-To: sarikaya@ieee.org User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: capwap@frascone.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Protocol Evaluation Approach Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 09 Jun 2005 22:29:58 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Dear all, I was wondering if the chairs and AD are considering a design team approach or selecting one of the four is considered the only way to go? Thanks, --behcet _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jun 10 08:44:10 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16191 for ; Fri, 10 Jun 2005 08:44:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4F55B205FA; Fri, 10 Jun 2005 08:44:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 68326205DB; Fri, 10 Jun 2005 08:44:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2E108205DB for ; Fri, 10 Jun 2005 08:43:40 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id 35897205D8 for ; Fri, 10 Jun 2005 08:43:37 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 10 Jun 2005 05:43:37 -0700 Received: from pacalhouwxp ([10.32.30.113]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5AChXlq002247; Fri, 10 Jun 2005 05:43:34 -0700 (PDT) Message-Id: <200506101243.j5AChXlq002247@sj-core-5.cisco.com> From: "Pat Calhoun" To: "'David T. Perkins'" , "'Darren Loher'" Cc: "'Cheng Hong'" , "'Sadot, Emek (Emek)'" , Subject: RE: [Capwap] NAT traversal MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVtUkHhaREPb9vZStmUlyrh+qTrtAAZ0+mQ In-Reply-To: X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.30.113] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 10 Jun 2005 05:43:33 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Well, asking me what service or problem I'm trying to solve is not the right question - I'm not in this business ;-) That said, I was simply stating that one could envision a scenario such as the one you have shown in your diagram. Call it Service Provider Managed WLAN service. While service provider managed networks are fairly rare here in the US, they are rather common in Europe, so I could envision the small/medium business owner outsourcing their network to their service provider. Local access (data), but centralized configuration and provisioning. That said, we're not here to dictate who can do what. I was simply stating that a protocol should not disallow the diagram you provided below. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Thursday, June 09, 2005 5:20 PM > To: Darren Loher > Cc: Pat Calhoun; Cheng Hong; Sadot, Emek (Emek); capwap@frascone.com > Subject: RE: [Capwap] NAT traversal > > HI Darren & Pat, > > I'm still having a problem understanding what you are trying > to accomplish. > > Here is a picture.... > > > /------------\ 209.128.82.1 10.1.1.1 /---------------\ > | | ---------- | | > | Internet |-----------|NAT box |-----|Private Network | > | |--- ---------- |(say 10.1.1.0/16)| > \-----------/ \ \---------------/ > | \ | > AC \ WTP STA-IP=? > 209.128.82.62 \ 10.1.2.1 > \ /---------------\ > \ ---------- | | > --|NAT box |-----|Private Network | > ---------- |(say 10.1.1.0/16)| > 209.128.82.2 10.1.1.1 \---------------/ > | > WTP STA-IP=? > 10.1.2.1 > > More NAT boxes > > Is this what you are talking about? And If so, tell me again > what problem are you trying to solve, or service that you are > wanting to provide? > > Regards, > /david t. perkins > > On Thu, 9 Jun 2005, Darren Loher wrote: > > On the requirements side for NAT, should we specify if the WTP is > > behind NAT, the AC behind NAT or both? I can see two basic > scenarios > > realistically being implemented: > > > > > > > > Assume: > > > > - Hotspot provider uses whatever available broadband > connection as an > > Internet uplink > > > > -This connection is limited to one, dynamically assigned IP address > > > > -NAT is required to share the connection with multiple hosts > > > > > > > > Scenario 1: The hotspot provider's AC is on the open Internet > > > > Scenario 2: The hotspot provider's AC is behind a NAT > firewall and the > > hotspot provider has port forwarding and/or static NAT > control of this > > firewall > > > > > > > > There could be several more, but these seem very common and > > straightforward. > > > > > > > > -Darren > > > > > > > > > > > > > > > > ________________________________ > > > > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On > > Behalf Of Pat Calhoun > > Sent: Thursday, June 09, 2005 7:19 AM > > To: 'Cheng Hong'; 'Sadot, Emek (Emek)'; capwap@frascone.com > > Subject: RE: [Capwap] NAT traversal > > > > > > > > Imagine a service provider connecting their AC to their customer's > > WTPs across a NAT. Makes sense to me. > > > > > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > > > > > > ________________________________ > > > > > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Cheng Hong > > Sent: Thursday, June 09, 2005 12:52 AM > > To: Sadot, Emek (Emek); capwap@frascone.com > > Subject: RE: [Capwap] NAT traversal > > > > Hi Emek, > > > > > > > > Would like to know a bit more about the deployment examples: > > > > > > > > >>say the WTP is located at branch office and the AC at > the main > > office separated by NAT device > > > > > > > > In this case, most likely the NAT traversal is not a > problem for the > > WTP or AC directly. For the branch office and main office > case, most > > likely there will be a VPN setup between them. To the WTP > and AC, NAT > > will be transparent. > > > > > > > > >>or within an Enterprise segregated by NAT devices. > > > > > > > > Does this mean AC and WTP are on different side of the > NAT? It sounds > > interesting, but is there any reason for deploy it in such a way (A > > NAT inside the enterprise network to separate the AC and WTP)? > > > > > > > > cheers > > > > > > > > Cheng Hong > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) > > Sent: Wednesday, June 08, 2005 4:27 AM > > To: capwap@frascone.com > > Subject: [Capwap] NAT traversal > > > > All, > > > > > > > > Would like to suggest adding a NAT traversal > requirement to the > > CAPWAP objective document, i.e. the ability of AC and WTP to > > communicate across NAT device (UDP / TCP transport, refresh CAPWAP > > session at the NAT device, WTP identification behind NAT > device, etc.). > > Deployment examples? say the WTP is located at branch > office and the > > AC at the main office separated by NAT device, or within an > Enterprise > > segregated by NAT devices. > > > > > > > > Regards, > > > > Emek > > > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jun 10 08:46:10 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16409 for ; Fri, 10 Jun 2005 08:46:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8B97420616; Fri, 10 Jun 2005 08:46:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 52946205E3; Fri, 10 Jun 2005 08:46:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 32E5E205E3 for ; Fri, 10 Jun 2005 08:45:24 -0400 (EDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.frascone.com (Postfix) with ESMTP id 13E7E205D8 for ; Fri, 10 Jun 2005 08:45:21 -0400 (EDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 10 Jun 2005 05:45:21 -0700 X-IronPort-AV: i="3.93,189,1115017200"; d="scan'208"; a="642655095:sNHT32401376" Received: from pacalhouwxp ([10.32.30.113]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5ACjEbw007408; Fri, 10 Jun 2005 05:45:15 -0700 (PDT) Message-Id: <200506101245.j5ACjEbw007408@sj-core-1.cisco.com> From: "Pat Calhoun" To: "'Sadot, Emek (Emek)'" , "'David T. Perkins'" , "'Darren Loher'" Cc: "'Cheng Hong'" , Subject: RE: [Capwap] NAT traversal MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVtUjjqoIyJDYDLQpqY9OKf8k0tTgAFTAyQABSsBpA= In-Reply-To: <5844A41F4E146044A2E8356C6328588008D1AEDD@nj7460avexu2.global.avaya.com> X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.30.113] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 10 Jun 2005 05:45:14 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I am ok with most statements here, but not necessarily with number 5. I don't think we need to go as far as to try to create a protocol that can guard itself against broken NAT infrastructure. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Sadot, Emek (Emek) [mailto:esadot@avaya.com] > Sent: Thursday, June 09, 2005 8:27 PM > To: David T. Perkins; Darren Loher > Cc: Pat Calhoun; Cheng Hong; capwap@frascone.com > Subject: RE: [Capwap] NAT traversal > > David, > > Excellent diagram. Respectfully I would avoid naming > "Internet" as NAT device can segregate Enterprise's internal > segments. A second WTP in the private domain (10.1.2.2) may > be helpful as well. > > A few problems presented by a NAT device: > 1. NAT manipulate layer 4 ports -> CAPWAP protocol cannot be > layer 3 protocol based. > 2. Symmetric NAT will drop AC communicating with the WTP > unless the WTP initiate the communication first. > 3. WTP unique identification at the AC must not by WTP's IP > address (and > port) based. > 4. WTP to AC CAPWAP session must be refreshed at the NAT device. > 5. CAPWAP protocol shall be immunized against NAT device > crash. More specifically, since session mapping will be > erased at the NAT device the WTP (in contrast to the AC) must > send CAPWAP to resume communication. > > Emek > > > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Thursday, June 09, 2005 8:20 PM > To: Darren Loher > Cc: Pat Calhoun; Cheng Hong; Sadot, Emek (Emek); capwap@frascone.com > Subject: RE: [Capwap] NAT traversal > > HI Darren & Pat, > > I'm still having a problem understanding what you are trying > to accomplish. > > Here is a picture.... > > > /------------\ 209.128.82.1 10.1.1.1 /---------------\ > | | ---------- | | > | Internet |-----------|NAT box |-----|Private Network | > | |--- ---------- |(say 10.1.1.0/16)| > \-----------/ \ \---------------/ > | \ | > AC \ WTP STA-IP=? > 209.128.82.62 \ 10.1.2.1 > \ /---------------\ > \ ---------- | | > --|NAT box |-----|Private Network | > ---------- |(say 10.1.1.0/16)| > 209.128.82.2 10.1.1.1 \---------------/ > | > WTP STA-IP=? > 10.1.2.1 > > More NAT boxes > > Is this what you are talking about? And If so, tell me again > what problem are you trying to solve, or service that you are > wanting to provide? > > Regards, > /david t. perkins > > On Thu, 9 Jun 2005, Darren Loher wrote: > > On the requirements side for NAT, should we specify if the WTP is > behind > > NAT, the AC behind NAT or both? I can see two basic scenarios > > realistically being implemented: > > > > > > > > Assume: > > > > - Hotspot provider uses whatever available broadband > connection as an > > Internet uplink > > > > -This connection is limited to one, dynamically assigned IP address > > > > -NAT is required to share the connection with multiple hosts > > > > > > > > Scenario 1: The hotspot provider's AC is on the open Internet > > > > Scenario 2: The hotspot provider's AC is behind a NAT > firewall and the > > hotspot provider has port forwarding and/or static NAT > control of this > > firewall > > > > > > > > There could be several more, but these seem very common and > > straightforward. > > > > > > > > -Darren > > > > > > > > > > > > > > > > ________________________________ > > > > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On > > Behalf Of Pat Calhoun > > Sent: Thursday, June 09, 2005 7:19 AM > > To: 'Cheng Hong'; 'Sadot, Emek (Emek)'; capwap@frascone.com > > Subject: RE: [Capwap] NAT traversal > > > > > > > > Imagine a service provider connecting their AC to their customer's > WTPs > > across a NAT. Makes sense to me. > > > > > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > > > > > > ________________________________ > > > > > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Cheng Hong > > Sent: Thursday, June 09, 2005 12:52 AM > > To: Sadot, Emek (Emek); capwap@frascone.com > > Subject: RE: [Capwap] NAT traversal > > > > Hi Emek, > > > > > > > > Would like to know a bit more about the deployment examples: > > > > > > > > >>say the WTP is located at branch office and the AC at > the main > > office separated by NAT device > > > > > > > > In this case, most likely the NAT traversal is not a > problem for the > > WTP or AC directly. For the branch office and main office case, > most > > likely there will be a VPN setup between them. To the WTP > and AC, NAT > > will be transparent. > > > > > > > > >>or within an Enterprise segregated by NAT devices. > > > > > > > > Does this mean AC and WTP are on different side of the > NAT? It sounds > > interesting, but is there any reason for deploy it in such a > way > > (A NAT inside the enterprise network to separate the AC and WTP)? > > > > > > > > cheers > > > > > > > > Cheng Hong > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) > > Sent: Wednesday, June 08, 2005 4:27 AM > > To: capwap@frascone.com > > Subject: [Capwap] NAT traversal > > > > All, > > > > > > > > Would like to suggest adding a NAT traversal > requirement to the > > CAPWAP objective document, i.e. the ability of AC and WTP to > > communicate across NAT device (UDP / TCP transport, refresh CAPWAP > > session at the NAT device, WTP identification behind NAT device, > etc.). > > Deployment examples? say the WTP is located at branch office and the > AC > > at the main office separated by NAT device, or within an Enterprise > > segregated by NAT devices. > > > > > > > > Regards, > > > > Emek > > > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jun 10 09:17:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18846 for ; Fri, 10 Jun 2005 09:17:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1062D20632; Fri, 10 Jun 2005 09:17:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 343DE205FA; Fri, 10 Jun 2005 09:17:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 48626205FA for ; Fri, 10 Jun 2005 09:16:16 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id 4A6A5205D8 for ; Fri, 10 Jun 2005 09:16:13 -0400 (EDT) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5ADDjdd001712 for ; Fri, 10 Jun 2005 09:13:46 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5ADDidd001670 for ; Fri, 10 Jun 2005 09:13:44 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Protocol Evaluation Approach Message-ID: Thread-Topic: [Capwap] Protocol Evaluation Approach Thread-Index: AcVtfaGIO9ONy8qbTryPJteQ+bNrsQAQEXOQ From: "Mani, Mahalingam (Mahalingam)" To: , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 10 Jun 2005 07:16:10 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Not sure what you meant by design-team approach here. The intent is to adopt the best of features into the result of evaluation exercise - if the evaluation comes up with a distinct winner meeting the Objectives & RFC3990 criteria. -mani =3D=3D=3D=3D=3D=3D -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Behcet Sarikaya Sent: Thursday, June 09, 2005 10:30 PM To: capwap@frascone.com Subject: [Capwap] Protocol Evaluation Approach Dear all, I was wondering if the chairs and AD are considering a design team approach or selecting one of the four is considered the only way to go? Thanks, --behcet _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jun 10 09:52:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21275 for ; Fri, 10 Jun 2005 09:52:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 710E42062B; Fri, 10 Jun 2005 09:52:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 11548205D8; Fri, 10 Jun 2005 09:52:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9C101205D8 for ; Fri, 10 Jun 2005 09:51:43 -0400 (EDT) Received: from ctron-dnm.enterasys.com (ctron-dnm.enterasys.com [12.25.1.120]) by mail.frascone.com (Postfix) with ESMTP id B5A4D20593 for ; Fri, 10 Jun 2005 09:51:41 -0400 (EDT) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id JAA16066 for ; Fri, 10 Jun 2005 09:53:19 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma016043; Fri, 10 Jun 05 09:53:00 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Fri, 10 Jun 2005 09:51:20 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Fri, 10 Jun 2005 09:51:20 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 10 Jun 2005 09:51:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Protocol Evaluation Approach Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D690103237E@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Capwap] Protocol Evaluation Approach Thread-Index: AcVtfaGIO9ONy8qbTryPJteQ+bNrsQAQEXOQAAE6AQA= From: "Nelson, David" To: "Mani, Mahalingam (Mahalingam)" , , X-OriginalArrivalTime: 10 Jun 2005 13:51:19.0952 (UTC) FILETIME=[7AFF2900:01C56DC3] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:78.1961 M:98.8113 P:95.9108 R:95.9108 S:99.9000 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 10 Jun 2005 09:51:18 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable > Not sure what you meant by design-team approach here. > > The intent is to adopt the best of features into the result of > evaluation exercise - if the evaluation comes up with a distinct winner > meeting the Objectives & RFC3990 criteria. If the evaluation comes up with a distinct winner, this is not an issue. If the evaluation indicates that Protocol A meets most of the requirements, and more than any other protocol, but that adding certain features from Protocol B would meet all of the requirements, it may be desirable to have a design team tasked to perform the feature integration. We probably ought to see what the outcome of the evaluation is, and the WG's response to that evaluation, before deciding that a design team might be useful. -- Dave _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jun 10 09:57:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21526 for ; Fri, 10 Jun 2005 09:57:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0A4E520638; Fri, 10 Jun 2005 09:57:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 759D9205FA; Fri, 10 Jun 2005 09:57:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 234BB205FA for ; Fri, 10 Jun 2005 09:56:33 -0400 (EDT) Received: from psmtp.com (exprod8og5.obsmtp.com [64.18.3.206]) by mail.frascone.com (Postfix) with SMTP id 031B620593 for ; Fri, 10 Jun 2005 09:56:30 -0400 (EDT) Received: from source ([66.10.55.3]) by exprod8ob5.obsmtp.com ([64.18.7.12]) with SMTP; Fri, 10 Jun 2005 06:56:22 PDT Received: from mail1.bluesocket.com ([192.168.168.32]) by mailfe.bluesocket.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Jun 2005 09:56:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Protocol Evaluation Approach Message-ID: <0240FDD68D6C1F4289F73D134A2536A128C94C@mail1.bluesocket.com> Thread-Topic: [Capwap] Protocol Evaluation Approach Thread-Index: AcVtfaGIO9ONy8qbTryPJteQ+bNrsQAQEXOQAAE6AQAAAFECQA== From: "Dick Eckard" To: "Nelson, David" , "Mani, Mahalingam (Mahalingam)" , , X-OriginalArrivalTime: 10 Jun 2005 13:56:22.0528 (UTC) FILETIME=[2F589800:01C56DC4] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 10 Jun 2005 09:56:21 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Has an evaluation group been formed, or when is that likely to take place? Dick Eckard -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Nelson, David Sent: Friday, June 10, 2005 9:51 AM To: Mani, Mahalingam (Mahalingam); sarikaya@ieee.org; capwap@frascone.com Subject: RE: [Capwap] Protocol Evaluation Approach > Not sure what you meant by design-team approach here. > > The intent is to adopt the best of features into the result of > evaluation exercise - if the evaluation comes up with a distinct winner > meeting the Objectives & RFC3990 criteria. If the evaluation comes up with a distinct winner, this is not an issue. If the evaluation indicates that Protocol A meets most of the requirements, and more than any other protocol, but that adding certain features from Protocol B would meet all of the requirements, it may be desirable to have a design team tasked to perform the feature integration. We probably ought to see what the outcome of the evaluation is, and the WG's response to that evaluation, before deciding that a design team might be useful. -- Dave _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jun 10 10:52:09 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27678 for ; Fri, 10 Jun 2005 10:52:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C4AF42064C; Fri, 10 Jun 2005 10:52:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0CF06205FA; Fri, 10 Jun 2005 10:52:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0291A205FA for ; Fri, 10 Jun 2005 10:51:48 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 412BF20593 for ; Fri, 10 Jun 2005 10:51:46 -0400 (EDT) Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5AEdxAK004569 for ; Fri, 10 Jun 2005 10:39:59 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5AEdvAK004531 for ; Fri, 10 Jun 2005 10:39:58 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] NAT traversal Message-ID: <5844A41F4E146044A2E8356C6328588008D1B085@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] NAT traversal Thread-Index: AcVtUjjqoIyJDYDLQpqY9OKf8k0tTgAFTAyQABSsBpAABCjbIA== From: "Sadot, Emek (Emek)" To: "Pat Calhoun" , "David T. Perkins" , "Darren Loher" Cc: "Cheng Hong" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 10 Jun 2005 10:51:43 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Pat, Compare to other along-the-way network appliances NAT device reboot presents communication challenge as parties (e.g. AC and WTP) need to proactively resume communication / protocol from the private side of the NAT. I would say that the CAPWAP protocol can come up with a solution for #4 that will covers #5 scenario as well. Emek -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@cisco.com]=20 Sent: Friday, June 10, 2005 8:45 AM To: Sadot, Emek (Emek); 'David T. Perkins'; 'Darren Loher' Cc: 'Cheng Hong'; capwap@frascone.com Subject: RE: [Capwap] NAT traversal I am ok with most statements here, but not necessarily with number 5. I don't think we need to go as far as to try to create a protocol that can guard itself against broken NAT infrastructure. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Sadot, Emek (Emek) [mailto:esadot@avaya.com] > Sent: Thursday, June 09, 2005 8:27 PM > To: David T. Perkins; Darren Loher > Cc: Pat Calhoun; Cheng Hong; capwap@frascone.com > Subject: RE: [Capwap] NAT traversal >=20 > David, >=20 > Excellent diagram. Respectfully I would avoid naming "Internet" as NAT > device can segregate Enterprise's internal segments. A second WTP in=20 > the private domain (10.1.2.2) may be helpful as well. >=20 > A few problems presented by a NAT device: > 1. NAT manipulate layer 4 ports -> CAPWAP protocol cannot be layer 3=20 > protocol based. > 2. Symmetric NAT will drop AC communicating with the WTP unless the=20 > WTP initiate the communication first. > 3. WTP unique identification at the AC must not by WTP's IP address=20 > (and > port) based. > 4. WTP to AC CAPWAP session must be refreshed at the NAT device. > 5. CAPWAP protocol shall be immunized against NAT device crash. More=20 > specifically, since session mapping will be erased at the NAT device=20 > the WTP (in contrast to the AC) must send CAPWAP to resume=20 > communication. >=20 > Emek >=20 >=20 > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Thursday, June 09, 2005 8:20 PM > To: Darren Loher > Cc: Pat Calhoun; Cheng Hong; Sadot, Emek (Emek); capwap@frascone.com > Subject: RE: [Capwap] NAT traversal >=20 > HI Darren & Pat, >=20 > I'm still having a problem understanding what you are trying to=20 > accomplish. >=20 > Here is a picture.... >=20 >=20 > /------------\ 209.128.82.1 10.1.1.1 /---------------\ > | | ---------- | | > | Internet |-----------|NAT box |-----|Private Network | > | |--- ---------- |(say 10.1.1.0/16)| > \-----------/ \ \---------------/ > | \ | > AC \ WTP STA-IP=3D? > 209.128.82.62 \ 10.1.2.1 > \ /---------------\=20 > \ ---------- | | > --|NAT box |-----|Private Network | > ---------- |(say 10.1.1.0/16)| > 209.128.82.2 10.1.1.1 \---------------/ > |=20 > WTP STA-IP=3D? > 10.1.2.1 >=20 > More NAT boxes >=20 > Is this what you are talking about? And If so, tell me again what=20 > problem are you trying to solve, or service that you are wanting to=20 > provide? >=20 > Regards, > /david t. perkins >=20 > On Thu, 9 Jun 2005, Darren Loher wrote: > > On the requirements side for NAT, should we specify if the WTP is > behind > > NAT, the AC behind NAT or both? I can see two basic scenarios=20 > > realistically being implemented: > >=20 > > =20 > >=20 > > Assume: > >=20 > > - Hotspot provider uses whatever available broadband > connection as an > > Internet uplink > >=20 > > -This connection is limited to one, dynamically assigned IP address > >=20 > > -NAT is required to share the connection with multiple hosts > >=20 > > =20 > >=20 > > Scenario 1: The hotspot provider's AC is on the open Internet > >=20 > > Scenario 2: The hotspot provider's AC is behind a NAT > firewall and the > > hotspot provider has port forwarding and/or static NAT > control of this > > firewall > >=20 > > =20 > >=20 > > There could be several more, but these seem very common and=20 > > straightforward. > >=20 > > =20 > >=20 > > -Darren > >=20 > > =20 > >=20 > > =20 > >=20 > > =20 > >=20 > > ________________________________ > >=20 > > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On > > Behalf Of Pat Calhoun > > Sent: Thursday, June 09, 2005 7:19 AM > > To: 'Cheng Hong'; 'Sadot, Emek (Emek)'; capwap@frascone.com > > Subject: RE: [Capwap] NAT traversal > >=20 > > =20 > >=20 > > Imagine a service provider connecting their AC to their customer's > WTPs > > across a NAT. Makes sense to me. > >=20 > > =20 > >=20 > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > >=20 > > =20 > >=20 > > =20 > >=20 > > =09 > > ________________________________ > >=20 > >=20 > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Cheng Hong > > Sent: Thursday, June 09, 2005 12:52 AM > > To: Sadot, Emek (Emek); capwap@frascone.com > > Subject: RE: [Capwap] NAT traversal > >=20 > > Hi Emek, > >=20 > > =20 > >=20 > > Would like to know a bit more about the deployment examples: > >=20 > > =20 > >=20 > > >>say the WTP is located at branch office and the AC at > the main > > office separated by NAT device > >=20 > > =20 > >=20 > > In this case, most likely the NAT traversal is not a > problem for the > > WTP or AC directly. For the branch office and main office case, > most > > likely there will be a VPN setup between them. To the WTP > and AC, NAT > > will be transparent. > >=20 > > =20 > >=20 > > >>or within an Enterprise segregated by NAT devices. > >=20 > > =20 > >=20 > > Does this mean AC and WTP are on different side of the > NAT? It sounds > > interesting, but is there any reason for deploy it in such a > way > > (A NAT inside the enterprise network to separate the AC and WTP)?=20 > >=20 > > =20 > >=20 > > cheers > >=20 > > =20 > >=20 > > Cheng Hong > >=20 > > =20 > >=20 > > =20 > >=20 > > =20 > >=20 > > =09 > > ________________________________ > >=20 > >=20 > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) > > Sent: Wednesday, June 08, 2005 4:27 AM > > To: capwap@frascone.com > > Subject: [Capwap] NAT traversal > >=20 > > All, > >=20 > > =20 > >=20 > > Would like to suggest adding a NAT traversal > requirement to the > > CAPWAP objective document, i.e. the ability of AC and WTP to=20 > > communicate across NAT device (UDP / TCP transport, refresh CAPWAP=20 > > session at the NAT device, WTP identification behind NAT device, > etc.). > > Deployment examples? say the WTP is located at branch office and the > AC > > at the main office separated by NAT device, or within an Enterprise=20 > > segregated by NAT devices. > >=20 > > =20 > >=20 > > Regards, > >=20 > > Emek > >=20 > >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jun 10 12:34:37 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06239 for ; Fri, 10 Jun 2005 12:34:36 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9025420652; Fri, 10 Jun 2005 12:34:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D60B320638; Fri, 10 Jun 2005 12:34:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B9B7120638 for ; Fri, 10 Jun 2005 12:33:10 -0400 (EDT) Received: from smtp4.centerbeam.com (smtp4.centerbeam.com [63.120.115.248]) by mail.frascone.com (Postfix) with ESMTP id A8BE8205E3 for ; Fri, 10 Jun 2005 12:33:07 -0400 (EDT) Received: from cba0e2k00.CBA0.centerbeam.com ([64.95.101.25]) by smtp4.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Jun 2005 09:34:17 -0700 Received: from CBA0E2K06.CBA0.centerbeam.com ([64.95.101.40]) by cba0e2k00.CBA0.centerbeam.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 10 Jun 2005 09:32:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] NAT traversal Message-ID: Thread-Topic: [Capwap] NAT traversal Thread-Index: AcVtUjjqoIyJDYDLQpqY9OKf8k0tTgAFTAyQABvqjWA= From: "Darren Loher" To: "Sadot, Emek (Emek)" , "David T. Perkins" Cc: "Pat Calhoun" , "Cheng Hong" , X-OriginalArrivalTime: 10 Jun 2005 16:32:57.0130 (UTC) FILETIME=[0EF718A0:01C56DDA] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 10 Jun 2005 09:32:55 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I am starting to think we should leave the NAT issue open to implementers. We could say, "The CAPWAP protocol SHOULD minimally support WTP's which are behind a symmetric NAT. The CAPWAP protocol MAY operate over additional forms of NAT." The details of how and if this requirement is satisfied should be left to the CAPWAP protocol. I would certainly give preference to a protocol which solved at least the minimal case of a WTP's behind symmetric NAT as in David Perkin's diagram. Also regarding problem #5 below, I think this issue would likely be addressed with the discovery and connection management of the CAPWAP protocol. The working group has already agreed that discovery mechanisms are out of scope of CAPWAP, so we should not write in what are discovery through NAT requirement. =20 -Darren > -----Original Message----- > From: Sadot, Emek (Emek) [mailto:esadot@avaya.com] > Sent: Thursday, June 09, 2005 9:27 PM > To: David T. Perkins; Darren Loher > Cc: Pat Calhoun; Cheng Hong; capwap@frascone.com > Subject: RE: [Capwap] NAT traversal >=20 > David, >=20 > Excellent diagram. Respectfully I would avoid naming "Internet" as NAT > device can segregate Enterprise's internal segments. A second WTP in the > private domain (10.1.2.2) may be helpful as well. >=20 > A few problems presented by a NAT device: > 1. NAT manipulate layer 4 ports -> CAPWAP protocol cannot be layer 3 > protocol based. > 2. Symmetric NAT will drop AC communicating with the WTP unless the WTP > initiate the communication first. > 3. WTP unique identification at the AC must not by WTP's IP address (and > port) based. > 4. WTP to AC CAPWAP session must be refreshed at the NAT device. > 5. CAPWAP protocol shall be immunized against NAT device crash. More > specifically, since session mapping will be erased at the NAT device the > WTP (in contrast to the AC) must send CAPWAP to resume communication. >=20 > Emek >=20 >=20 > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Thursday, June 09, 2005 8:20 PM > To: Darren Loher > Cc: Pat Calhoun; Cheng Hong; Sadot, Emek (Emek); capwap@frascone.com > Subject: RE: [Capwap] NAT traversal >=20 > HI Darren & Pat, >=20 > I'm still having a problem understanding what you are trying > to accomplish. >=20 > Here is a picture.... >=20 >=20 > /------------\ 209.128.82.1 10.1.1.1 /---------------\ > | | ---------- | | > | Internet |-----------|NAT box |-----|Private Network | > | |--- ---------- |(say 10.1.1.0/16)| > \-----------/ \ \---------------/ > | \ | > AC \ WTP STA-IP=3D? > 209.128.82.62 \ 10.1.2.1 > \ /---------------\ > \ ---------- | | > --|NAT box |-----|Private Network | > ---------- |(say 10.1.1.0/16)| > 209.128.82.2 10.1.1.1 \---------------/ > | > WTP STA-IP=3D? > 10.1.2.1 >=20 > More NAT boxes >=20 > Is this what you are talking about? And If so, tell me again > what problem are you trying to solve, or service that you > are wanting to provide? >=20 > Regards, > /david t. perkins >=20 > On Thu, 9 Jun 2005, Darren Loher wrote: > > On the requirements side for NAT, should we specify if the WTP is > behind > > NAT, the AC behind NAT or both? I can see two basic scenarios > > realistically being implemented: > > > > > > > > Assume: > > > > - Hotspot provider uses whatever available broadband connection as an > > Internet uplink > > > > -This connection is limited to one, dynamically assigned IP address > > > > -NAT is required to share the connection with multiple hosts > > > > > > > > Scenario 1: The hotspot provider's AC is on the open Internet > > > > Scenario 2: The hotspot provider's AC is behind a NAT firewall and the > > hotspot provider has port forwarding and/or static NAT control of this > > firewall > > > > > > > > There could be several more, but these seem very common and > > straightforward. > > > > > > > > -Darren > > > > > > > > > > > > > > > > ________________________________ > > > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > > Behalf Of Pat Calhoun > > Sent: Thursday, June 09, 2005 7:19 AM > > To: 'Cheng Hong'; 'Sadot, Emek (Emek)'; capwap@frascone.com > > Subject: RE: [Capwap] NAT traversal > > > > > > > > Imagine a service provider connecting their AC to their customer's > WTPs > > across a NAT. Makes sense to me. > > > > > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > > > > > > > > > ________________________________ > > > > > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Cheng Hong > > Sent: Thursday, June 09, 2005 12:52 AM > > To: Sadot, Emek (Emek); capwap@frascone.com > > Subject: RE: [Capwap] NAT traversal > > > > Hi Emek, > > > > > > > > Would like to know a bit more about the deployment examples: > > > > > > > > >>say the WTP is located at branch office and the AC at the main > > office separated by NAT device > > > > > > > > In this case, most likely the NAT traversal is not a problem for > > the WTP or AC directly. For the branch office and main office case, > most > > likely there will be a VPN setup between them. To the WTP and AC, NAT > > will be transparent. > > > > > > > > >>or within an Enterprise segregated by NAT devices. > > > > > > > > Does this mean AC and WTP are on different side of the NAT? It > > sounds interesting, but is there any reason for deploy it in such a > way > > (A NAT inside the enterprise network to separate the AC and WTP)? > > > > > > > > cheers > > > > > > > > Cheng Hong > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) > > Sent: Wednesday, June 08, 2005 4:27 AM > > To: capwap@frascone.com > > Subject: [Capwap] NAT traversal > > > > All, > > > > > > > > Would like to suggest adding a NAT traversal requirement > > to the CAPWAP objective document, i.e. the ability of AC and WTP to > > communicate across NAT device (UDP / TCP transport, refresh CAPWAP > > session at the NAT device, WTP identification behind NAT device, > etc.). > > Deployment examples? say the WTP is located at branch office and the > AC > > at the main office separated by NAT device, or within an Enterprise > > segregated by NAT devices. > > > > > > > > Regards, > > > > Emek > > > > >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jun 10 12:48:09 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07383 for ; Fri, 10 Jun 2005 12:48:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F3A0F20654; Fri, 10 Jun 2005 12:48:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4C7AF2064C; Fri, 10 Jun 2005 12:48:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 355162064C for ; Fri, 10 Jun 2005 12:47:34 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 6B76120638 for ; Fri, 10 Jun 2005 12:47:31 -0400 (EDT) Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5AGZiAK017519 for ; Fri, 10 Jun 2005 12:35:44 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5AGZhAK017481 for ; Fri, 10 Jun 2005 12:35:43 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] NAT traversal Message-ID: Thread-Topic: [Capwap] NAT traversal Thread-Index: AcVtUjjqoIyJDYDLQpqY9OKf8k0tTgAFTAyQABvqjWAAANoDwA== From: "Mani, Mahalingam (Mahalingam)" To: "Darren Loher" , "Sadot, Emek (Emek)" , "David T. Perkins" Cc: "Pat Calhoun" , "Cheng Hong" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 10 Jun 2005 10:47:29 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Speaking as a member of the WG: It would be preferable to have the NAT problem scenarios articulated in a draft - so we have a distinct record of possible problem scenario(s). While this may not turn out to be a work item - inasmuch as it happens to be one of the possible provider and/or (extended) enterprise deployment scenarios - it would be unfair to let it go unaddressed.=20 The protocol (and the WG) is aimed to help solve the primary pain-points of managing large WLAN deployments - and avoid creating additional ones along the way if we can help it (that should be a generic objective as well :)). Some deployments may be able to address this by way of distributed (cooperating) AC instances. However, that may not be the normal case. Providers and large enterprise IT-admins on the list should speak up on this. -mani =3D=3D=3D=3D=3D=3D -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Darren Loher Sent: Friday, June 10, 2005 9:33 AM To: Sadot, Emek (Emek); David T. Perkins Cc: Pat Calhoun; Cheng Hong; capwap@frascone.com Subject: RE: [Capwap] NAT traversal I am starting to think we should leave the NAT issue open to implementers. We could say, "The CAPWAP protocol SHOULD minimally support WTP's which are behind a symmetric NAT. The CAPWAP protocol MAY operate over additional forms of NAT." The details of how and if this requirement is satisfied should be left to the CAPWAP protocol. I would certainly give preference to a protocol which solved at least the minimal case of a WTP's behind symmetric NAT as in David Perkin's diagram. Also regarding problem #5 below, I think this issue would likely be addressed with the discovery and connection management of the CAPWAP protocol. The working group has already agreed that discovery mechanisms are out of scope of CAPWAP, so we should not write in what are discovery through NAT requirement. =20 -Darren > -----Original Message----- > From: Sadot, Emek (Emek) [mailto:esadot@avaya.com] > Sent: Thursday, June 09, 2005 9:27 PM > To: David T. Perkins; Darren Loher > Cc: Pat Calhoun; Cheng Hong; capwap@frascone.com > Subject: RE: [Capwap] NAT traversal >=20 > David, >=20 > Excellent diagram. Respectfully I would avoid naming "Internet" as NAT > device can segregate Enterprise's internal segments. A second WTP in the > private domain (10.1.2.2) may be helpful as well. >=20 > A few problems presented by a NAT device: > 1. NAT manipulate layer 4 ports -> CAPWAP protocol cannot be layer 3 > protocol based. > 2. Symmetric NAT will drop AC communicating with the WTP unless the WTP > initiate the communication first. > 3. WTP unique identification at the AC must not by WTP's IP address (and > port) based. > 4. WTP to AC CAPWAP session must be refreshed at the NAT device. > 5. CAPWAP protocol shall be immunized against NAT device crash. More > specifically, since session mapping will be erased at the NAT device the > WTP (in contrast to the AC) must send CAPWAP to resume communication. >=20 > Emek >=20 >=20 > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Thursday, June 09, 2005 8:20 PM > To: Darren Loher > Cc: Pat Calhoun; Cheng Hong; Sadot, Emek (Emek); capwap@frascone.com > Subject: RE: [Capwap] NAT traversal >=20 > HI Darren & Pat, >=20 > I'm still having a problem understanding what you are trying > to accomplish. >=20 > Here is a picture.... >=20 >=20 > /------------\ 209.128.82.1 10.1.1.1 /---------------\ > | | ---------- | | > | Internet |-----------|NAT box |-----|Private Network | > | |--- ---------- |(say 10.1.1.0/16)| > \-----------/ \ \---------------/ > | \ | > AC \ WTP STA-IP=3D? > 209.128.82.62 \ 10.1.2.1 > \ /---------------\ > \ ---------- | | > --|NAT box |-----|Private Network | > ---------- |(say 10.1.1.0/16)| > 209.128.82.2 10.1.1.1 \---------------/ > | > WTP STA-IP=3D? > 10.1.2.1 >=20 > More NAT boxes >=20 > Is this what you are talking about? And If so, tell me again > what problem are you trying to solve, or service that you > are wanting to provide? >=20 > Regards, > /david t. perkins >=20 > On Thu, 9 Jun 2005, Darren Loher wrote: > > On the requirements side for NAT, should we specify if the WTP is > behind > > NAT, the AC behind NAT or both? I can see two basic scenarios > > realistically being implemented: > > > > > > > > Assume: > > > > - Hotspot provider uses whatever available broadband connection as an > > Internet uplink > > > > -This connection is limited to one, dynamically assigned IP address > > > > -NAT is required to share the connection with multiple hosts > > > > > > > > Scenario 1: The hotspot provider's AC is on the open Internet > > > > Scenario 2: The hotspot provider's AC is behind a NAT firewall and the > > hotspot provider has port forwarding and/or static NAT control of this > > firewall > > > > > > > > There could be several more, but these seem very common and > > straightforward. > > > > > > > > -Darren > > > > > > > > > > > > > > > > ________________________________ > > > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > > Behalf Of Pat Calhoun > > Sent: Thursday, June 09, 2005 7:19 AM > > To: 'Cheng Hong'; 'Sadot, Emek (Emek)'; capwap@frascone.com > > Subject: RE: [Capwap] NAT traversal > > > > > > > > Imagine a service provider connecting their AC to their customer's > WTPs > > across a NAT. Makes sense to me. > > > > > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > > > > > > > > > ________________________________ > > > > > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Cheng Hong > > Sent: Thursday, June 09, 2005 12:52 AM > > To: Sadot, Emek (Emek); capwap@frascone.com > > Subject: RE: [Capwap] NAT traversal > > > > Hi Emek, > > > > > > > > Would like to know a bit more about the deployment examples: > > > > > > > > >>say the WTP is located at branch office and the AC at the main > > office separated by NAT device > > > > > > > > In this case, most likely the NAT traversal is not a problem for > > the WTP or AC directly. For the branch office and main office case, > most > > likely there will be a VPN setup between them. To the WTP and AC, NAT > > will be transparent. > > > > > > > > >>or within an Enterprise segregated by NAT devices. > > > > > > > > Does this mean AC and WTP are on different side of the NAT? It > > sounds interesting, but is there any reason for deploy it in such a > way > > (A NAT inside the enterprise network to separate the AC and WTP)? > > > > > > > > cheers > > > > > > > > Cheng Hong > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) > > Sent: Wednesday, June 08, 2005 4:27 AM > > To: capwap@frascone.com > > Subject: [Capwap] NAT traversal > > > > All, > > > > > > > > Would like to suggest adding a NAT traversal requirement > > to the CAPWAP objective document, i.e. the ability of AC and WTP to > > communicate across NAT device (UDP / TCP transport, refresh CAPWAP > > session at the NAT device, WTP identification behind NAT device, > etc.). > > Deployment examples? say the WTP is located at branch office and the > AC > > at the main office separated by NAT device, or within an Enterprise > > segregated by NAT devices. > > > > > > > > Regards, > > > > Emek > > > > >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jun 10 13:03:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08691 for ; Fri, 10 Jun 2005 13:03:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8AB0B20655; Fri, 10 Jun 2005 13:03:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B96292064C; Fri, 10 Jun 2005 13:03:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BE26B2064C for ; Fri, 10 Jun 2005 13:02:45 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 46F2C20638 for ; Fri, 10 Jun 2005 13:02:42 -0400 (EDT) Message-ID: <027e01c56dde$62e095a0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Mani, Mahalingam (Mahalingam)" , "Darren Loher" , "Sadot, Emek (Emek)" , "David T. Perkins" Cc: "Pat Calhoun" , "Cheng Hong" , References: Subject: Re: [Capwap] NAT traversal MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 10 Jun 2005 10:03:48 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I think there might be some cases where the AC and WTPs might be on different sides of a NAT, but I think the most likely scenarios are fairly limited. I'm wondering if the CAPWAP protocol itself needs to support NATs or if it might be possible to include NAT support in a separate document, such as SIP/STUN and Mobile IP did? It might make the base protocol simplier. In addition, if CAPWAP supports IPv6 (will it?) and everyone's hopes actually become reality and IPv6 networks don't have NATs, then having a simplier base protocol could make IPv6 deployments simplier. jak ----- Original Message ----- From: "Mani, Mahalingam (Mahalingam)" To: "Darren Loher" ; "Sadot, Emek (Emek)" ; "David T. Perkins" Cc: "Pat Calhoun" ; "Cheng Hong" ; Sent: Friday, June 10, 2005 9:47 AM Subject: RE: [Capwap] NAT traversal Speaking as a member of the WG: It would be preferable to have the NAT problem scenarios articulated in a draft - so we have a distinct record of possible problem scenario(s). While this may not turn out to be a work item - inasmuch as it happens to be one of the possible provider and/or (extended) enterprise deployment scenarios - it would be unfair to let it go unaddressed. The protocol (and the WG) is aimed to help solve the primary pain-points of managing large WLAN deployments - and avoid creating additional ones along the way if we can help it (that should be a generic objective as well :)). Some deployments may be able to address this by way of distributed (cooperating) AC instances. However, that may not be the normal case. Providers and large enterprise IT-admins on the list should speak up on this. -mani ====== -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Darren Loher Sent: Friday, June 10, 2005 9:33 AM To: Sadot, Emek (Emek); David T. Perkins Cc: Pat Calhoun; Cheng Hong; capwap@frascone.com Subject: RE: [Capwap] NAT traversal I am starting to think we should leave the NAT issue open to implementers. We could say, "The CAPWAP protocol SHOULD minimally support WTP's which are behind a symmetric NAT. The CAPWAP protocol MAY operate over additional forms of NAT." The details of how and if this requirement is satisfied should be left to the CAPWAP protocol. I would certainly give preference to a protocol which solved at least the minimal case of a WTP's behind symmetric NAT as in David Perkin's diagram. Also regarding problem #5 below, I think this issue would likely be addressed with the discovery and connection management of the CAPWAP protocol. The working group has already agreed that discovery mechanisms are out of scope of CAPWAP, so we should not write in what are discovery through NAT requirement. -Darren > -----Original Message----- > From: Sadot, Emek (Emek) [mailto:esadot@avaya.com] > Sent: Thursday, June 09, 2005 9:27 PM > To: David T. Perkins; Darren Loher > Cc: Pat Calhoun; Cheng Hong; capwap@frascone.com > Subject: RE: [Capwap] NAT traversal > > David, > > Excellent diagram. Respectfully I would avoid naming "Internet" as NAT > device can segregate Enterprise's internal segments. A second WTP in the > private domain (10.1.2.2) may be helpful as well. > > A few problems presented by a NAT device: > 1. NAT manipulate layer 4 ports -> CAPWAP protocol cannot be layer 3 > protocol based. > 2. Symmetric NAT will drop AC communicating with the WTP unless the WTP > initiate the communication first. > 3. WTP unique identification at the AC must not by WTP's IP address (and > port) based. > 4. WTP to AC CAPWAP session must be refreshed at the NAT device. > 5. CAPWAP protocol shall be immunized against NAT device crash. More > specifically, since session mapping will be erased at the NAT device the > WTP (in contrast to the AC) must send CAPWAP to resume communication. > > Emek > > > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Thursday, June 09, 2005 8:20 PM > To: Darren Loher > Cc: Pat Calhoun; Cheng Hong; Sadot, Emek (Emek); capwap@frascone.com > Subject: RE: [Capwap] NAT traversal > > HI Darren & Pat, > > I'm still having a problem understanding what you are trying > to accomplish. > > Here is a picture.... > > > /------------\ 209.128.82.1 10.1.1.1 /---------------\ > | | ---------- | | > | Internet |-----------|NAT box |-----|Private Network | > | |--- ---------- |(say 10.1.1.0/16)| > \-----------/ \ \---------------/ > | \ | > AC \ WTP STA-IP=? > 209.128.82.62 \ 10.1.2.1 > \ /---------------\ > \ ---------- | | > --|NAT box |-----|Private Network | > ---------- |(say 10.1.1.0/16)| > 209.128.82.2 10.1.1.1 \---------------/ > | > WTP STA-IP=? > 10.1.2.1 > > More NAT boxes > > Is this what you are talking about? And If so, tell me again > what problem are you trying to solve, or service that you > are wanting to provide? > > Regards, > /david t. perkins > > On Thu, 9 Jun 2005, Darren Loher wrote: > > On the requirements side for NAT, should we specify if the WTP is > behind > > NAT, the AC behind NAT or both? I can see two basic scenarios > > realistically being implemented: > > > > > > > > Assume: > > > > - Hotspot provider uses whatever available broadband connection as an > > Internet uplink > > > > -This connection is limited to one, dynamically assigned IP address > > > > -NAT is required to share the connection with multiple hosts > > > > > > > > Scenario 1: The hotspot provider's AC is on the open Internet > > > > Scenario 2: The hotspot provider's AC is behind a NAT firewall and the > > hotspot provider has port forwarding and/or static NAT control of this > > firewall > > > > > > > > There could be several more, but these seem very common and > > straightforward. > > > > > > > > -Darren > > > > > > > > > > > > > > > > ________________________________ > > > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > > Behalf Of Pat Calhoun > > Sent: Thursday, June 09, 2005 7:19 AM > > To: 'Cheng Hong'; 'Sadot, Emek (Emek)'; capwap@frascone.com > > Subject: RE: [Capwap] NAT traversal > > > > > > > > Imagine a service provider connecting their AC to their customer's > WTPs > > across a NAT. Makes sense to me. > > > > > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > > > > > > > > > ________________________________ > > > > > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Cheng Hong > > Sent: Thursday, June 09, 2005 12:52 AM > > To: Sadot, Emek (Emek); capwap@frascone.com > > Subject: RE: [Capwap] NAT traversal > > > > Hi Emek, > > > > > > > > Would like to know a bit more about the deployment examples: > > > > > > > > >>say the WTP is located at branch office and the AC at the main > > office separated by NAT device > > > > > > > > In this case, most likely the NAT traversal is not a problem for > > the WTP or AC directly. For the branch office and main office case, > most > > likely there will be a VPN setup between them. To the WTP and AC, NAT > > will be transparent. > > > > > > > > >>or within an Enterprise segregated by NAT devices. > > > > > > > > Does this mean AC and WTP are on different side of the NAT? It > > sounds interesting, but is there any reason for deploy it in such a > way > > (A NAT inside the enterprise network to separate the AC and WTP)? > > > > > > > > cheers > > > > > > > > Cheng Hong > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) > > Sent: Wednesday, June 08, 2005 4:27 AM > > To: capwap@frascone.com > > Subject: [Capwap] NAT traversal > > > > All, > > > > > > > > Would like to suggest adding a NAT traversal requirement > > to the CAPWAP objective document, i.e. the ability of AC and WTP to > > communicate across NAT device (UDP / TCP transport, refresh CAPWAP > > session at the NAT device, WTP identification behind NAT device, > etc.). > > Deployment examples? say the WTP is located at branch office and the > AC > > at the main office separated by NAT device, or within an Enterprise > > segregated by NAT devices. > > > > > > > > Regards, > > > > Emek > > > > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jun 10 14:33:16 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18005 for ; Fri, 10 Jun 2005 14:33:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BCB732065A; Fri, 10 Jun 2005 14:33:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6B1A020651; Fri, 10 Jun 2005 14:33:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4147A20638 for ; Fri, 10 Jun 2005 14:32:47 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 4CC0620593 for ; Fri, 10 Jun 2005 14:32:44 -0400 (EDT) Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5AIKuAK004599 for ; Fri, 10 Jun 2005 14:20:57 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5AIK9AK003019 for ; Fri, 10 Jun 2005 14:20:10 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] NAT traversal Message-ID: <5844A41F4E146044A2E8356C6328588008D1B1F4@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] NAT traversal Thread-Index: AcVtUjjqoIyJDYDLQpqY9OKf8k0tTgAFTAyQABvqjWAABDfTwA== From: "Sadot, Emek (Emek)" To: "Darren Loher" , "David T. Perkins" Cc: "Pat Calhoun" , "Cheng Hong" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 10 Jun 2005 14:31:54 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Personally I would like to see a NAT objective spelled out in the objective document rather then give implementers the freedom. CAPWAP protocol shall facilitate other technologies, not only Wi-Fi. Let's do the right thing when we can. IMHO supporting NAT traversal should be fairly easy to accomplish at this stage of the CAPWAP working, rather of reengineering the protocol if needed so. Take it to extreme: we will be doomed if CAPWAP protocol turn to be a layer 3 transport based protocol. To your last point: Discovery will not solve problem #5 as WTP and AC already discovered / authenticate / and registered one each other. Having said that, I can see how #5 is a none-goal. Emek -----Original Message----- From: Darren Loher [mailto:DLoher@rovingplanet.com]=20 Sent: Friday, June 10, 2005 12:33 PM To: Sadot, Emek (Emek); David T. Perkins Cc: Pat Calhoun; Cheng Hong; capwap@frascone.com Subject: RE: [Capwap] NAT traversal I am starting to think we should leave the NAT issue open to implementers. We could say, "The CAPWAP protocol SHOULD minimally support WTP's which are behind a symmetric NAT. The CAPWAP protocol MAY operate over additional forms of NAT." The details of how and if this requirement is satisfied should be left to the CAPWAP protocol. I would certainly give preference to a protocol which solved at least the minimal case of a WTP's behind symmetric NAT as in David Perkin's diagram. Also regarding problem #5 below, I think this issue would likely be addressed with the discovery and connection management of the CAPWAP protocol. The working group has already agreed that discovery mechanisms are out of scope of CAPWAP, so we should not write in what are discovery through NAT requirement. =20 -Darren > -----Original Message----- > From: Sadot, Emek (Emek) [mailto:esadot@avaya.com] > Sent: Thursday, June 09, 2005 9:27 PM > To: David T. Perkins; Darren Loher > Cc: Pat Calhoun; Cheng Hong; capwap@frascone.com > Subject: RE: [Capwap] NAT traversal >=20 > David, >=20 > Excellent diagram. Respectfully I would avoid naming "Internet" as NAT > device can segregate Enterprise's internal segments. A second WTP in the > private domain (10.1.2.2) may be helpful as well. >=20 > A few problems presented by a NAT device: > 1. NAT manipulate layer 4 ports -> CAPWAP protocol cannot be layer 3=20 > protocol based. > 2. Symmetric NAT will drop AC communicating with the WTP unless the WTP > initiate the communication first. > 3. WTP unique identification at the AC must not by WTP's IP address (and > port) based. > 4. WTP to AC CAPWAP session must be refreshed at the NAT device. > 5. CAPWAP protocol shall be immunized against NAT device crash. More=20 > specifically, since session mapping will be erased at the NAT device the > WTP (in contrast to the AC) must send CAPWAP to resume communication. >=20 > Emek >=20 >=20 > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Thursday, June 09, 2005 8:20 PM > To: Darren Loher > Cc: Pat Calhoun; Cheng Hong; Sadot, Emek (Emek); capwap@frascone.com > Subject: RE: [Capwap] NAT traversal >=20 > HI Darren & Pat, >=20 > I'm still having a problem understanding what you are trying to=20 > accomplish. >=20 > Here is a picture.... >=20 >=20 > /------------\ 209.128.82.1 10.1.1.1 /---------------\ > | | ---------- | | > | Internet |-----------|NAT box |-----|Private Network | > | |--- ---------- |(say 10.1.1.0/16)| > \-----------/ \ \---------------/ > | \ | > AC \ WTP STA-IP=3D? > 209.128.82.62 \ 10.1.2.1 > \ /---------------\ > \ ---------- | | > --|NAT box |-----|Private Network | > ---------- |(say 10.1.1.0/16)| > 209.128.82.2 10.1.1.1 \---------------/ > | > WTP STA-IP=3D? > 10.1.2.1 >=20 > More NAT boxes >=20 > Is this what you are talking about? And If so, tell me again what=20 > problem are you trying to solve, or service that you are wanting to=20 > provide? >=20 > Regards, > /david t. perkins >=20 > On Thu, 9 Jun 2005, Darren Loher wrote: > > On the requirements side for NAT, should we specify if the WTP is > behind > > NAT, the AC behind NAT or both? I can see two basic scenarios=20 > > realistically being implemented: > > > > > > > > Assume: > > > > - Hotspot provider uses whatever available broadband connection as an > > Internet uplink > > > > -This connection is limited to one, dynamically assigned IP address > > > > -NAT is required to share the connection with multiple hosts > > > > > > > > Scenario 1: The hotspot provider's AC is on the open Internet > > > > Scenario 2: The hotspot provider's AC is behind a NAT firewall and the > > hotspot provider has port forwarding and/or static NAT control of this > > firewall > > > > > > > > There could be several more, but these seem very common and=20 > > straightforward. > > > > > > > > -Darren > > > > > > > > > > > > > > > > ________________________________ > > > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > > Behalf Of Pat Calhoun > > Sent: Thursday, June 09, 2005 7:19 AM > > To: 'Cheng Hong'; 'Sadot, Emek (Emek)'; capwap@frascone.com > > Subject: RE: [Capwap] NAT traversal > > > > > > > > Imagine a service provider connecting their AC to their customer's > WTPs > > across a NAT. Makes sense to me. > > > > > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > > > > > > ________________________________ > > > > > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Cheng Hong > > Sent: Thursday, June 09, 2005 12:52 AM > > To: Sadot, Emek (Emek); capwap@frascone.com > > Subject: RE: [Capwap] NAT traversal > > > > Hi Emek, > > > > > > > > Would like to know a bit more about the deployment examples: > > > > > > > > >>say the WTP is located at branch office and the AC at the main > > office separated by NAT device > > > > > > > > In this case, most likely the NAT traversal is not a problem for > > the WTP or AC directly. For the branch office and main office case, > most > > likely there will be a VPN setup between them. To the WTP and AC, NAT > > will be transparent. > > > > > > > > >>or within an Enterprise segregated by NAT devices. > > > > > > > > Does this mean AC and WTP are on different side of the NAT? It > > sounds interesting, but is there any reason for deploy it in such a > way > > (A NAT inside the enterprise network to separate the AC and WTP)? > > > > > > > > cheers > > > > > > > > Cheng Hong > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) > > Sent: Wednesday, June 08, 2005 4:27 AM > > To: capwap@frascone.com > > Subject: [Capwap] NAT traversal > > > > All, > > > > > > > > Would like to suggest adding a NAT traversal requirement > > to the CAPWAP objective document, i.e. the ability of AC and WTP to > > communicate across NAT device (UDP / TCP transport, refresh CAPWAP > > session at the NAT device, WTP identification behind NAT device, > etc.). > > Deployment examples? say the WTP is located at branch office and the > AC > > at the main office separated by NAT device, or within an Enterprise > > segregated by NAT devices. > > > > > > > > Regards, > > > > Emek > > > > >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jun 10 15:59:13 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01957 for ; Fri, 10 Jun 2005 15:59:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 581522065F; Fri, 10 Jun 2005 15:59:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3B70220638; Fri, 10 Jun 2005 15:59:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DE57D20638 for ; Fri, 10 Jun 2005 15:58:04 -0400 (EDT) Received: from smtp4.centerbeam.com (smtp4.centerbeam.com [63.120.115.248]) by mail.frascone.com (Postfix) with ESMTP id C2B5220416 for ; Fri, 10 Jun 2005 15:58:01 -0400 (EDT) Received: from cba0e2k00.CBA0.centerbeam.com ([64.95.101.25]) by smtp4.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Jun 2005 12:59:19 -0700 Received: from CBA0E2K06.CBA0.centerbeam.com ([64.95.101.40]) by cba0e2k00.CBA0.centerbeam.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 10 Jun 2005 12:57:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] NAT traversal Message-ID: Thread-Topic: [Capwap] NAT traversal Thread-Index: AcVtUjjqoIyJDYDLQpqY9OKf8k0tTgAFTAyQABSsBpAABCjbIAAD3sCA From: "Darren Loher" To: "Sadot, Emek (Emek)" , "Pat Calhoun" , "David T. Perkins" Cc: "Cheng Hong" , X-OriginalArrivalTime: 10 Jun 2005 19:57:58.0557 (UTC) FILETIME=[B32FE4D0:01C56DF6] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 10 Jun 2005 12:57:55 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I agree with Emek that #4 and #5 are important problems when using NAT. But I think wether communication is lost via NAT distruption/reboot, link issues or other reasons, a reasonable CAPWAP implementation should have a method to survive a lost connection and restore the connection between WTP and AC. =20 Connection integrity/keepalive type functions which would address problems like these probably do not need to be explicit requirements. -Darren > -----Original Message----- > From: Sadot, Emek (Emek) [mailto:esadot@avaya.com] > Sent: Friday, June 10, 2005 8:52 AM > To: Pat Calhoun; David T. Perkins; Darren Loher > Cc: Cheng Hong; capwap@frascone.com > Subject: RE: [Capwap] NAT traversal >=20 > Pat, >=20 > Compare to other along-the-way network appliances NAT device reboot > presents communication challenge as parties (e.g. AC and WTP) need to > proactively resume communication / protocol from the private side of the > NAT. I would say that the CAPWAP protocol can come up with a solution > for #4 that will covers #5 scenario as well. >=20 > Emek >=20 > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@cisco.com] > Sent: Friday, June 10, 2005 8:45 AM > To: Sadot, Emek (Emek); 'David T. Perkins'; 'Darren Loher' > Cc: 'Cheng Hong'; capwap@frascone.com > Subject: RE: [Capwap] NAT traversal >=20 > I am ok with most statements here, but not necessarily with number 5. I > don't think we need to go as far as to try to create a protocol that can > guard itself against broken NAT infrastructure. >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems >=20 >=20 >=20 > > -----Original Message----- > > From: Sadot, Emek (Emek) [mailto:esadot@avaya.com] > > Sent: Thursday, June 09, 2005 8:27 PM > > To: David T. Perkins; Darren Loher > > Cc: Pat Calhoun; Cheng Hong; capwap@frascone.com > > Subject: RE: [Capwap] NAT traversal > > > > David, > > > > Excellent diagram. Respectfully I would avoid naming "Internet" as NAT >=20 > > device can segregate Enterprise's internal segments. A second WTP in > > the private domain (10.1.2.2) may be helpful as well. > > > > A few problems presented by a NAT device: > > 1. NAT manipulate layer 4 ports -> CAPWAP protocol cannot be layer 3 > > protocol based. > > 2. Symmetric NAT will drop AC communicating with the WTP unless the > > WTP initiate the communication first. > > 3. WTP unique identification at the AC must not by WTP's IP address > > (and > > port) based. > > 4. WTP to AC CAPWAP session must be refreshed at the NAT device. > > 5. CAPWAP protocol shall be immunized against NAT device crash. More > > specifically, since session mapping will be erased at the NAT device > > the WTP (in contrast to the AC) must send CAPWAP to resume > > communication. > > > > Emek > > > > > > -----Original Message----- > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > Sent: Thursday, June 09, 2005 8:20 PM > > To: Darren Loher > > Cc: Pat Calhoun; Cheng Hong; Sadot, Emek (Emek); capwap@frascone.com > > Subject: RE: [Capwap] NAT traversal > > > > HI Darren & Pat, > > > > I'm still having a problem understanding what you are trying to > > accomplish. > > > > Here is a picture.... > > > > > > /------------\ 209.128.82.1 10.1.1.1 /---------------\ > > | | ---------- | | > > | Internet |-----------|NAT box |-----|Private Network | > > | |--- ---------- |(say 10.1.1.0/16)| > > \-----------/ \ \---------------/ > > | \ | > > AC \ WTP STA-IP=3D? > > 209.128.82.62 \ 10.1.2.1 > > \ /---------------\ > > \ ---------- | | > > --|NAT box |-----|Private Network | > > ---------- |(say 10.1.1.0/16)| > > 209.128.82.2 10.1.1.1 \---------------/ > > | > > WTP STA-IP=3D? > > 10.1.2.1 > > > > More NAT boxes > > > > Is this what you are talking about? And If so, tell me again what > > problem are you trying to solve, or service that you are wanting to > > provide? > > > > Regards, > > /david t. perkins > > > > On Thu, 9 Jun 2005, Darren Loher wrote: > > > On the requirements side for NAT, should we specify if the WTP is > > behind > > > NAT, the AC behind NAT or both? I can see two basic scenarios > > > realistically being implemented: > > > > > > > > > > > > Assume: > > > > > > - Hotspot provider uses whatever available broadband > > connection as an > > > Internet uplink > > > > > > -This connection is limited to one, dynamically assigned IP address > > > > > > -NAT is required to share the connection with multiple hosts > > > > > > > > > > > > Scenario 1: The hotspot provider's AC is on the open Internet > > > > > > Scenario 2: The hotspot provider's AC is behind a NAT > > firewall and the > > > hotspot provider has port forwarding and/or static NAT > > control of this > > > firewall > > > > > > > > > > > > There could be several more, but these seem very common and > > > straightforward. > > > > > > > > > > > > -Darren > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On > > > Behalf Of Pat Calhoun > > > Sent: Thursday, June 09, 2005 7:19 AM > > > To: 'Cheng Hong'; 'Sadot, Emek (Emek)'; capwap@frascone.com > > > Subject: RE: [Capwap] NAT traversal > > > > > > > > > > > > Imagine a service provider connecting their AC to their customer's > > WTPs > > > across a NAT. Makes sense to me. > > > > > > > > > > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On Behalf Of Cheng Hong > > > Sent: Thursday, June 09, 2005 12:52 AM > > > To: Sadot, Emek (Emek); capwap@frascone.com > > > Subject: RE: [Capwap] NAT traversal > > > > > > Hi Emek, > > > > > > > > > > > > Would like to know a bit more about the deployment examples: > > > > > > > > > > > > >>say the WTP is located at branch office and the AC at > > the main > > > office separated by NAT device > > > > > > > > > > > > In this case, most likely the NAT traversal is not a > > problem for the > > > WTP or AC directly. For the branch office and main office case, > > most > > > likely there will be a VPN setup between them. To the WTP > > and AC, NAT > > > will be transparent. > > > > > > > > > > > > >>or within an Enterprise segregated by NAT devices. > > > > > > > > > > > > Does this mean AC and WTP are on different side of the > > NAT? It sounds > > > interesting, but is there any reason for deploy it in such a > > way > > > (A NAT inside the enterprise network to separate the AC and WTP)? > > > > > > > > > > > > cheers > > > > > > > > > > > > Cheng Hong > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) > > > Sent: Wednesday, June 08, 2005 4:27 AM > > > To: capwap@frascone.com > > > Subject: [Capwap] NAT traversal > > > > > > All, > > > > > > > > > > > > Would like to suggest adding a NAT traversal > > requirement to the > > > CAPWAP objective document, i.e. the ability of AC and WTP to > > > communicate across NAT device (UDP / TCP transport, refresh CAPWAP > > > session at the NAT device, WTP identification behind NAT device, > > etc.). > > > Deployment examples? say the WTP is located at branch office and the > > AC > > > at the main office separated by NAT device, or within an Enterprise > > > segregated by NAT devices. > > > > > > > > > > > > Regards, > > > > > > Emek > > > > > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jun 10 16:08:10 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06350 for ; Fri, 10 Jun 2005 16:08:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7670B20669; Fri, 10 Jun 2005 16:08:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 422472065C; Fri, 10 Jun 2005 16:08:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9D8AF20638 for ; Fri, 10 Jun 2005 16:07:16 -0400 (EDT) Received: from smtp4.centerbeam.com (smtp4.centerbeam.com [63.120.115.248]) by mail.frascone.com (Postfix) with ESMTP id AF43020416 for ; Fri, 10 Jun 2005 16:07:14 -0400 (EDT) Received: from CBA0E2K01.CBA0.centerbeam.com ([64.95.101.24]) by smtp4.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Jun 2005 13:08:25 -0700 Received: from CBA0E2K06.CBA0.centerbeam.com ([64.95.101.40]) by CBA0E2K01.CBA0.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Jun 2005 13:07:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Protocol Evaluation Approach Message-ID: Thread-Topic: [Capwap] Protocol Evaluation Approach Thread-Index: AcVtfaGIO9ONy8qbTryPJteQ+bNrsQAQEXOQAAE6AQAADSKnoA== From: "Darren Loher" To: "Nelson, David" , "Mani, Mahalingam (Mahalingam)" , , X-OriginalArrivalTime: 10 Jun 2005 20:07:04.0713 (UTC) FILETIME=[F8B8AF90:01C56DF7] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 10 Jun 2005 13:07:03 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Like Dave suggests, I think we should wait and see what comes of the evaluation. I think it's possible the evaluation could recommend the integration of additional capabilities for a particular protocol. =20 If that were to happen, I am not sure of the best way to proceed, but I believe it would be up to the editors of that protocol to decide how best to add those capabilities to their draft and obtain working group acceptance of the changes. =20 -Darren > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Nelson, David > Sent: Friday, June 10, 2005 7:51 AM > To: Mani, Mahalingam (Mahalingam); sarikaya@ieee.org; capwap@frascone.com > Subject: RE: [Capwap] Protocol Evaluation Approach >=20 >=20 > > Not sure what you meant by design-team approach here. > > > > The intent is to adopt the best of features into the result of > > evaluation exercise - if the evaluation comes up with a distinct > winner > > meeting the Objectives & RFC3990 criteria. >=20 > If the evaluation comes up with a distinct winner, this is not an issue. > If the evaluation indicates that Protocol A meets most of the > requirements, and more than any other protocol, but that adding certain > features from Protocol B would meet all of the requirements, it may be > desirable to have a design team tasked to perform the feature > integration. We probably ought to see what the outcome of the > evaluation is, and the WG's response to that evaluation, before deciding > that a design team might be useful. >=20 > -- Dave _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From bullety@doneasy.com Fri Jun 10 19:43:31 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25253; Fri, 10 Jun 2005 19:43:31 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgtVi-0003Cx-3e; Fri, 10 Jun 2005 20:06:04 -0400 Received: from [220.79.156.249] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1Dgt9v-0002kZ-1K; Fri, 10 Jun 2005 19:43:31 -0400 Received: by swart (Wostfix 67 65) id 68B10C1146769; Sat, 11 Jun 2005 04:37:25 +0400 Date: Fri, 10 Jun 2005 23:37:25 -0100 From: "Katherine Lucas" Message-ID: <264c.fsf@calle06.net> To: capwap-archive@ietf.org Cc: ccips@ietf.org, cclark@ietf.org, cdi-archive@ietf.org Subject: Become one of the low rates X-Mailer: Apple Mail (2.482) X-Spam-Score: 10.5 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have been selected for our lowest rate in years... You could get over $420,000 for as little as $400 a month! Ba(d credit, Bank*ruptcy? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.jo1nt.com/signs.asp Best Regards, Jenifer Franks to be remov(ed: http://www.jo1nt.com/deletion.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From capwap-admin@frascone.com Fri Jun 10 22:22:09 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04192 for ; Fri, 10 Jun 2005 22:22:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0D56B20674; Fri, 10 Jun 2005 22:22:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 562552042E; Fri, 10 Jun 2005 22:22:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 914472042E for ; Fri, 10 Jun 2005 22:22:00 -0400 (EDT) Received: from mgw-ext02.nokia.com (mgw-ext02.nokia.com [131.228.20.94]) by mail.frascone.com (Postfix) with ESMTP id 8A69820353 for ; Fri, 10 Jun 2005 22:21:57 -0400 (EDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j5B2Lp1n001228; Sat, 11 Jun 2005 05:21:52 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Jun 2005 05:20:48 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Jun 2005 21:20:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <893AE265F4ADF94AB7FB26D31A788E410C11C5@mvebe101.NOE.Nokia.com> Thread-Topic: CAPWAP Evaluation Team Thread-Index: AcVuIfAVyAb+puajQaq77P2X1NbVLg== From: To: Cc: , , , X-OriginalArrivalTime: 11 Jun 2005 02:20:47.0066 (UTC) FILETIME=[2D7C3BA0:01C56E2C] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] CAPWAP Evaluation Team Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 10 Jun 2005 19:20:45 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi All- Thanks to everyone who volunteered for editorship of the CAPWAP = Evaluation draft. The Chairs and ADs have selected a team of = evaluators, based on participation on the list and the WG. The team = is as follows: Darren Loher (Roving Planet), Lead Editor David Nelson (Enterasys), Lead for Evaluation Process=20 Behcet Sarikaya (UofBC) Oleg Volinsky (Colubris) David Nelson has participated in a similar protocol evaluation process = in the AAA WG, and we are lucky to have his experience on the team to = benefit our evolution. The milestones for the CAPWAP evaluation draft are as follows: July 2005: Issue first Internet-Draft of CAPWAP Evaluation Draft = (00 draft deadline to repository is July 8th) August 2005: WGLC for CAPWAP Evaluation Draft. September 2005: Submit CAPWAP Evaluation Draft to IESG as Informational = RFC. The evaluation draft will be based on the WG consensus, self-evaluations = and the previous WG drafts. We expect the first draft will have a TBD as the recommended Protocol = for CAPWAP. =20 As we have stated before, the final evaluation may select one protocol = for the CAPWAP protocol, or the recommendation may be one protocol, with = specific objectives met by other protocols. =20 Congratulations to the Evaluation team! Best Regards, Dorothy and Mani _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sat Jun 11 00:33:11 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12536 for ; Sat, 11 Jun 2005 00:33:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CC58B20593; Sat, 11 Jun 2005 00:33:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C098B2042E; Sat, 11 Jun 2005 00:33:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E21652042E for ; Sat, 11 Jun 2005 00:32:43 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id D5C8420416 for ; Sat, 11 Jun 2005 00:32:41 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j5B4Su4Y009528; Fri, 10 Jun 2005 21:28:57 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200506110428.j5B4Su4Y009528@homebrew.trpz.com> To: Dorothy.Gellert@nokia.com Cc: capwap@frascone.com, mmani@avaya.com, bwijnen@lucent.com, david.kessens@nokia.com Subject: Re: [Capwap] CAPWAP Evaluation Team In-Reply-To: Your message of "Fri, 10 Jun 2005 19:20:45 PDT." <893AE265F4ADF94AB7FB26D31A788E410C11C5@mvebe101.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9526.1118464136.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 10 Jun 2005 21:28:56 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Hi Dorothy, You're saying that there are 2 possibilities: one protocol, periodfullstop; or, one protocol that needs to incorporate some features from other protocols. I don't recall ever seeing you (plural, or even singular) state that before. Can you please point out when that was? I was under the impression that the result could be what you state and also the possibility that no single protocol would be selected but that some hybrid that combines features from several of the candidates could result in an acceptable protocol. Or possibly (although doubtful) no protocol would be satisfactory. I'm concerned that you are giving guidance to this new team that does not originate from the working group. Also, you listed September 2005 as a date to submit a draft to the IESG as an Informational RFC. Per RFC2026 and Informational RFC "is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation." Given that it won't represent any consensus or recommentation how can it be used to select one or more of the candidate protocols? thanks, Dan. On Fri, 10 Jun 2005 19:20:45 PDT you wrote > Hi All- > > Thanks to everyone who volunteered for editorship of the CAPWAP Evaluation dr >aft. The Chairs and ADs have selected a team of evaluators, based on partici >pation on the list and the WG. The team is as follows: > > Darren Loher (Roving Planet), Lead Editor > David Nelson (Enterasys), Lead for Evaluation Process > Behcet Sarikaya (UofBC) > Oleg Volinsky (Colubris) > > David Nelson has participated in a similar protocol evaluation process in the > AAA WG, and we are lucky to have his experience on the team to benefit our ev >olution. > > The milestones for the CAPWAP evaluation draft are as follows: > > July 2005: Issue first Internet-Draft of CAPWAP Evaluation Draft > (00 draft deadline to repository is July 8th) > August 2005: WGLC for CAPWAP Evaluation Draft. > September 2005: Submit CAPWAP Evaluation Draft to IESG as Informational > RFC. > > The evaluation draft will be based on the WG consensus, self-evaluations and >the previous WG drafts. > We expect the first draft will have a TBD as the recommended Protocol for CAP >WAP. > > As we have stated before, the final evaluation may select one protocol for th >e CAPWAP protocol, or the recommendation may be one protocol, with specific ob >jectives met by other protocols. > > Congratulations to the Evaluation team! > > Best Regards, > Dorothy and Mani > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From slipin@doramail.com Sat Jun 11 02:18:48 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05345; Sat, 11 Jun 2005 02:18:47 -0400 (EDT) From: slipin@doramail.com Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgzgG-0001xL-EJ; Sat, 11 Jun 2005 02:41:21 -0400 Received: from pc-74-107-83-200.cm.vtr.net ([200.83.107.74]) by mx2.foretec.com with smtp (Exim 4.24) id 1DgzKM-0000cg-F1; Sat, 11 Jun 2005 02:18:46 -0400 Received: from UNOMXjamu.com (EHLO afvlk-a.bertie.MD.aay.net) hygiene by mail.mtk.nao.ac.jp (5.3[2 Message-Id: Date: Sat, 11 Jun 2005 02:18:46 -0400 X-Spam-Score: 4.0 (++++) X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From viseing@doramail.com Sat Jun 11 10:42:10 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16640; Sat, 11 Jun 2005 10:42:10 -0400 (EDT) Date: Sat, 11 Jun 2005 10:42:10 -0400 (EDT) From: viseing@doramail.com Message-Id: <200506111442.KAA16640@ietf.org> Received: from amarseille-152-1-13-217.w81-251.abo.wanadoo.fr ([81.251.231.217]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dh7XR-0005Xp-3j; Sat, 11 Jun 2005 11:04:49 -0400 Received: from RBHUQtbqv.com (EHLO ahjpc-a.excessive.AF.qoi.net) africa by mail.mtk.nao.ac.jp (8.8[2 X-Spam-Score: 5.5 (+++++) X-Spam-Flag: YES X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From viseing@doramail.com Sat Jun 11 10:45:30 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17507; Sat, 11 Jun 2005 10:45:30 -0400 (EDT) Date: Sat, 11 Jun 2005 10:45:30 -0400 (EDT) From: viseing@doramail.com Message-Id: <200506111445.KAA17507@ietf.org> Received: from [61.49.132.175] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dh7ah-0005lO-A8; Sat, 11 Jun 2005 11:08:09 -0400 Received: from RBHUQtbqv.com (EHLO ahjpc-a.excessive.AF.qoi.net) africa by mail.mtk.nao.ac.jp (8.8[2 X-Spam-Score: 6.2 (++++++) X-Spam-Flag: YES X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From capwap-admin@frascone.com Sun Jun 12 03:08:11 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13241 for ; Sun, 12 Jun 2005 03:08:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7132E20486; Sun, 12 Jun 2005 03:08:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A4BE9202C6; Sun, 12 Jun 2005 03:08:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CDAFE202C6 for ; Sun, 12 Jun 2005 03:07:04 -0400 (EDT) Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) by mail.frascone.com (Postfix) with ESMTP id CCADD1FE1E for ; Sun, 12 Jun 2005 03:07:02 -0400 (EDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j5C76n0a017194; Sun, 12 Jun 2005 10:06:53 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Jun 2005 10:06:52 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Jun 2005 02:06:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] CAPWAP Evaluation Team Message-ID: <893AE265F4ADF94AB7FB26D31A788E410C11CF@mvebe101.NOE.Nokia.com> Thread-Topic: [Capwap] CAPWAP Evaluation Team Thread-Index: AcVuPsXEgjBKHYbeTGKHtlaH3uFf1gA2Givg From: To: Cc: , , , X-OriginalArrivalTime: 12 Jun 2005 07:06:35.0166 (UTC) FILETIME=[44F663E0:01C56F1D] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Sat, 11 Jun 2005 23:57:25 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Dear Dan- Most recently Mani and I both responded to a email Paul Lambert sent to = the list on 4/25/05, Subject: RE: [Capwap] Selecting Protocols to = evaluate, where he asks if we can "mix and match sections from each = protocol". Mani replied on 4/26, and I replied on 5/2.=20 Also, during the IETF face to face meetings we have discussed this topic = during milestone review. That is why we have described the chosen = protocol as a "base" protocol for CAPWAP. As for the informational RFC, I'll discuss your concerns with the ADs. = However, the intent is to evaluate the proposals and make a = recommendation for the CAPWAP protocol. Work will progress along these = lines. Regards, Dorothy =20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On Behalf Of ext Dan Harkins Sent: Friday, June 10, 2005 9:29 PM To: Gellert Dorothy (Nokia-ES/MtView) Cc: capwap@frascone.com; mmani@avaya.com; bwijnen@lucent.com; Kessens David (Nokia-NET/MtView) Subject: Re: [Capwap] CAPWAP Evaluation Team=20 Hi Dorothy, You're saying that there are 2 possibilities: one protocol, = periodfullstop; or, one protocol that needs to incorporate some features from other = protocols. I don't recall ever seeing you (plural, or even singular) state that = before. Can you please point out when that was? I was under the impression that the result could be what you state and also the possibility that no single protocol would be selected but that some hybrid that combines features from several of the candidates could result in an acceptable protocol. Or possibly (although doubtful) no = protocol would be satisfactory. I'm concerned that you are giving guidance to this new team that does not originate from the working group. Also, you listed September 2005 as a date to submit a draft to the = IESG as an Informational RFC. Per RFC2026 and Informational RFC "is published = for the general information of the Internet community, and does not = represent an Internet community consensus or recommendation." Given that it won't=20 represent any consensus or recommentation how can it be used to select one or more of the candidate protocols? thanks, Dan. On Fri, 10 Jun 2005 19:20:45 PDT you wrote > Hi All- >=20 > Thanks to everyone who volunteered for editorship of the CAPWAP = Evaluation dr >aft. The Chairs and ADs have selected a team of evaluators, based on = partici >pation on the list and the WG. The team is as follows: >=20 > Darren Loher (Roving Planet), Lead Editor > David Nelson (Enterasys), Lead for Evaluation Process=20 > Behcet Sarikaya (UofBC) > Oleg Volinsky (Colubris) >=20 > David Nelson has participated in a similar protocol evaluation process = in the > AAA WG, and we are lucky to have his experience on the team to benefit = our ev >olution. >=20 > The milestones for the CAPWAP evaluation draft are as follows: >=20 > July 2005: Issue first Internet-Draft of CAPWAP Evaluation Draft =20 > (00 draft deadline to repository is July 8th) > August 2005: WGLC for CAPWAP Evaluation Draft. > September 2005: Submit CAPWAP Evaluation Draft to IESG as = Informational > RFC. >=20 > The evaluation draft will be based on the WG consensus, = self-evaluations and=20 >the previous WG drafts. > We expect the first draft will have a TBD as the recommended Protocol = for CAP >WAP. =20 >=20 > As we have stated before, the final evaluation may select one protocol = for th >e CAPWAP protocol, or the recommendation may be one protocol, with = specific ob >jectives met by other protocols. =20 >=20 > Congratulations to the Evaluation team! >=20 > Best Regards, > Dorothy and Mani > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From abelard@accesswave.com Sun Jun 12 17:14:19 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11525 for ; Sun, 12 Jun 2005 17:14:19 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dha8o-0005KV-29 for capwap-archive@ietf.org; Sun, 12 Jun 2005 17:37:15 -0400 Received: from aplessis-bouchard-151-1-61-21.w83-112.abo.wanadoo.fr ([83.112.127.21]) by mx2.foretec.com with smtp (Exim 4.24) id 1DhZmU-0000mM-BA for capwap-archive@ietf.org; Sun, 12 Jun 2005 17:14:11 -0400 Message-ID: <1ea501c56f91$6a03925b$edcc1a27@accesswave.com> From: "Vanessa J. Smith" To: capwap-archive@ietf.org Subject: =?iso-8859-1?B?T2ZmaWNlIHNvZnR3YXJlIC0gZHV0eS1mcmVlIHByaWNlcw==?= Date: Sun, 12 Jun 2005 21:00:47 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_293D2C7E.ECF29203" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.9 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 This is a multi-part message in MIME format. ------=_NextPart_000_0000_293D2C7E.ECF29203 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_AAD89AAB.02609F1C" ------=_NextPart_001_0001_AAD89AAB.02609F1C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Get access to all the software you ever imagined for prices substantially lower than in stores! Our software is 2-10 times cheaper than sold by our competitors. A few examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $69.95 MS Project 2003 Professional Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many more... Visit us at: http://www.soft-cds.biz Best regards, Vanessa Smith _____________________________________________________ To change your mail details, go: http://www.soft-cds.biz/uns.htm _____________________________________________________ ------=_NextPart_001_0001_AAD89AAB.02609F1C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
Get access to all the software you ever imagined for prices substantially lower than in stores!
Our software is 2-10 times cheaper than sold by our competitors.

A few examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
$79.95 Adobe Acrobat 6.0 Professional
$69.95 MS Project 2003 Professional

Special Offers:
$89.95 Windows XP Professional + Office XP Professional
$149.95 Adobe Creative Suite Premium (5 CD)
$129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And many more... Visit us at:

http://www.soft-cds.biz

Best regards,
Vanessa Smith


_____________________________________________________
To change your mail details, go: http://www.soft-cds.biz/uns.htm
_____________________________________________________

------=_NextPart_001_0001_AAD89AAB.02609F1C-- ------=_NextPart_000_0000_293D2C7E.ECF29203-- From capwap-admin@frascone.com Mon Jun 13 12:02:11 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24989 for ; Mon, 13 Jun 2005 12:02:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DB16220486; Mon, 13 Jun 2005 12:02:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 96B5520371; Mon, 13 Jun 2005 12:02:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5433920486 for ; Mon, 13 Jun 2005 12:01:35 -0400 (EDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by mail.frascone.com (Postfix) with ESMTP id 3721E2047C for ; Mon, 13 Jun 2005 12:01:32 -0400 (EDT) Received: by wproxy.gmail.com with SMTP id 49so140439wri for ; Mon, 13 Jun 2005 09:01:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=S74+LflbJXqZDc6wO3Sanz61Z5+LkT86Ts3q0AG4dxwd+8aohI0bjW3AY/vtZQpEr52z/lfYulxz8oxJJ5GQKSV7Jm8gO3u+aDslGPSivYyh/R+dsbWQr1o/93IZdYo+mo2sOm/CxMJh9J77XMx4PhfDvySF9SDbKsDlCxYlP9A= Received: by 10.54.17.28 with SMTP id 28mr148474wrq; Mon, 13 Jun 2005 09:01:31 -0700 (PDT) Received: by 10.54.19.19 with HTTP; Mon, 13 Jun 2005 09:01:30 -0700 (PDT) Message-ID: <9852189205061309013ede9db7@mail.gmail.com> From: Suresh Satapati Reply-To: Suresh Satapati To: Darren Loher Subject: Re: [Capwap] NAT traversal Cc: "Sadot, Emek (Emek)" , Pat Calhoun , "David T. Perkins" , Cheng Hong , capwap@frascone.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 13 Jun 2005 09:01:30 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable On 6/10/05, Darren Loher wrote: > I agree with Emek that #4 and #5 are important problems when using NAT. Agreed. Also agree with the two high level scenarios :- 1. WTP behind NAT 2. AC behind NAT I can send some text on different types of NATs in the market place today. We have gone through this exercise in V6OPS. All this can go into a separate document if the WG feels this is useful work.. =20 > But I think wether communication is lost via NAT distruption/reboot, > link issues or other reasons, a reasonable CAPWAP implementation should > have a method to survive a lost connection and restore the connection > between WTP and AC. >=20 > Connection integrity/keepalive type functions which would address > problems like these probably do not need to be explicit requirements. Yes. No need for explicit requirements here..=20 >=20 > -Darren >=20 > > -----Original Message----- > > From: Sadot, Emek (Emek) [mailto:esadot@avaya.com] > > Sent: Friday, June 10, 2005 8:52 AM > > To: Pat Calhoun; David T. Perkins; Darren Loher > > Cc: Cheng Hong; capwap@frascone.com > > Subject: RE: [Capwap] NAT traversal > > > > Pat, > > > > Compare to other along-the-way network appliances NAT device reboot > > presents communication challenge as parties (e.g. AC and WTP) need to > > proactively resume communication / protocol from the private side of > the > > NAT. I would say that the CAPWAP protocol can come up with a solution > > for #4 that will covers #5 scenario as well. > > > > Emek > > > > -----Original Message----- > > From: Pat Calhoun [mailto:pcalhoun@cisco.com] > > Sent: Friday, June 10, 2005 8:45 AM > > To: Sadot, Emek (Emek); 'David T. Perkins'; 'Darren Loher' > > Cc: 'Cheng Hong'; capwap@frascone.com > > Subject: RE: [Capwap] NAT traversal > > > > I am ok with most statements here, but not necessarily with number 5. > I > > don't think we need to go as far as to try to create a protocol that > can > > guard itself against broken NAT infrastructure. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > > > > -----Original Message----- > > > From: Sadot, Emek (Emek) [mailto:esadot@avaya.com] > > > Sent: Thursday, June 09, 2005 8:27 PM > > > To: David T. Perkins; Darren Loher > > > Cc: Pat Calhoun; Cheng Hong; capwap@frascone.com > > > Subject: RE: [Capwap] NAT traversal > > > > > > David, > > > > > > Excellent diagram. Respectfully I would avoid naming "Internet" as > NAT > > > > > device can segregate Enterprise's internal segments. A second WTP in > > > the private domain (10.1.2.2) may be helpful as well. > > > > > > A few problems presented by a NAT device: > > > 1. NAT manipulate layer 4 ports -> CAPWAP protocol cannot be layer 3 > > > protocol based. > > > 2. Symmetric NAT will drop AC communicating with the WTP unless the > > > WTP initiate the communication first. > > > 3. WTP unique identification at the AC must not by WTP's IP address > > > (and > > > port) based. > > > 4. WTP to AC CAPWAP session must be refreshed at the NAT device. > > > 5. CAPWAP protocol shall be immunized against NAT device crash. More > > > specifically, since session mapping will be erased at the NAT device > > > the WTP (in contrast to the AC) must send CAPWAP to resume > > > communication. > > > > > > Emek > > > > > > > > > -----Original Message----- > > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > > Sent: Thursday, June 09, 2005 8:20 PM > > > To: Darren Loher > > > Cc: Pat Calhoun; Cheng Hong; Sadot, Emek (Emek); capwap@frascone.com > > > Subject: RE: [Capwap] NAT traversal > > > > > > HI Darren & Pat, > > > > > > I'm still having a problem understanding what you are trying to > > > accomplish. > > > > > > Here is a picture.... > > > > > > > > > /------------\ 209.128.82.1 10.1.1.1 /---------------\ > > > | | ---------- | | > > > | Internet |-----------|NAT box |-----|Private Network | > > > | |--- ---------- |(say 10.1.1.0/16)| > > > \-----------/ \ \---------------/ > > > | \ | > > > AC \ WTP STA-IP=3D? > > > 209.128.82.62 \ 10.1.2.1 > > > \ /---------------\ > > > \ ---------- | | > > > --|NAT box |-----|Private Network | > > > ---------- |(say 10.1.1.0/16)| > > > 209.128.82.2 10.1.1.1 \---------------/ > > > | > > > WTP STA-IP=3D? > > > 10.1.2.1 > > > > > > More NAT boxes > > > > > > Is this what you are talking about? And If so, tell me again what > > > problem are you trying to solve, or service that you are wanting to > > > provide? > > > > > > Regards, > > > /david t. perkins > > > > > > On Thu, 9 Jun 2005, Darren Loher wrote: > > > > On the requirements side for NAT, should we specify if the WTP is > > > behind > > > > NAT, the AC behind NAT or both? I can see two basic scenarios > > > > realistically being implemented: > > > > > > > > > > > > > > > > Assume: > > > > > > > > - Hotspot provider uses whatever available broadband > > > connection as an > > > > Internet uplink > > > > > > > > -This connection is limited to one, dynamically assigned IP > address > > > > > > > > -NAT is required to share the connection with multiple hosts > > > > > > > > > > > > > > > > Scenario 1: The hotspot provider's AC is on the open Internet > > > > > > > > Scenario 2: The hotspot provider's AC is behind a NAT > > > firewall and the > > > > hotspot provider has port forwarding and/or static NAT > > > control of this > > > > firewall > > > > > > > > > > > > > > > > There could be several more, but these seem very common and > > > > straightforward. > > > > > > > > > > > > > > > > -Darren > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On > > > > Behalf Of Pat Calhoun > > > > Sent: Thursday, June 09, 2005 7:19 AM > > > > To: 'Cheng Hong'; 'Sadot, Emek (Emek)'; capwap@frascone.com > > > > Subject: RE: [Capwap] NAT traversal > > > > > > > > > > > > > > > > Imagine a service provider connecting their AC to their customer's > > > WTPs > > > > across a NAT. Makes sense to me. > > > > > > > > > > > > > > > > Pat Calhoun > > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > From: capwap-admin@frascone.com > > > > [mailto:capwap-admin@frascone.com] On Behalf Of Cheng Hong > > > > Sent: Thursday, June 09, 2005 12:52 AM > > > > To: Sadot, Emek (Emek); capwap@frascone.com > > > > Subject: RE: [Capwap] NAT traversal > > > > > > > > Hi Emek, > > > > > > > > > > > > > > > > Would like to know a bit more about the deployment examples: > > > > > > > > > > > > > > > > >>say the WTP is located at branch office and the AC at > > > the main > > > > office separated by NAT device > > > > > > > > > > > > > > > > In this case, most likely the NAT traversal is not a > > > problem for the > > > > WTP or AC directly. For the branch office and main office case, > > > most > > > > likely there will be a VPN setup between them. To the WTP > > > and AC, NAT > > > > will be transparent. > > > > > > > > > > > > > > > > >>or within an Enterprise segregated by NAT devices. > > > > > > > > > > > > > > > > Does this mean AC and WTP are on different side of the > > > NAT? It sounds > > > > interesting, but is there any reason for deploy it in such a > > > way > > > > (A NAT inside the enterprise network to separate the AC and WTP)? > > > > > > > > > > > > > > > > cheers > > > > > > > > > > > > > > > > Cheng Hong > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > From: capwap-admin@frascone.com > > > > [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) > > > > Sent: Wednesday, June 08, 2005 4:27 AM > > > > To: capwap@frascone.com > > > > Subject: [Capwap] NAT traversal > > > > > > > > All, > > > > > > > > > > > > > > > > Would like to suggest adding a NAT traversal > > > requirement to the > > > > CAPWAP objective document, i.e. the ability of AC and WTP to > > > > communicate across NAT device (UDP / TCP transport, refresh CAPWAP > > > > session at the NAT device, WTP identification behind NAT device, > > > etc.). > > > > Deployment examples? say the WTP is located at branch office and > the > > > AC > > > > at the main office separated by NAT device, or within an > Enterprise > > > > segregated by NAT devices. > > > > > > > > > > > > > > > > Regards, > > > > > > > > Emek > > > > > > > > >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Jun 13 12:17:11 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26726 for ; Mon, 13 Jun 2005 12:17:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 53B40204BE; Mon, 13 Jun 2005 12:17:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CED542047C; Mon, 13 Jun 2005 12:17:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4DA3C2047C for ; Mon, 13 Jun 2005 12:16:19 -0400 (EDT) Received: from smtp4.centerbeam.com (smtp4.centerbeam.com [63.120.115.248]) by mail.frascone.com (Postfix) with ESMTP id CA963202A8 for ; Mon, 13 Jun 2005 12:16:16 -0400 (EDT) Received: from cba0e2k00.CBA0.centerbeam.com ([64.95.101.25]) by smtp4.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Jun 2005 09:17:36 -0700 Received: from CBA0E2K06.CBA0.centerbeam.com ([64.95.101.40]) by cba0e2k00.CBA0.centerbeam.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Jun 2005 09:16:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] NAT traversal Message-ID: Thread-Topic: [Capwap] NAT traversal Thread-Index: AcVwMS6dexX5B/2xSWuSD61at+BtagAAKEKQ From: "Darren Loher" To: "Suresh Satapati" Cc: "Sadot, Emek (Emek)" , "Pat Calhoun" , "David T. Perkins" , "Cheng Hong" , X-OriginalArrivalTime: 13 Jun 2005 16:16:02.0307 (UTC) FILETIME=[3152A530:01C57033] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 13 Jun 2005 09:16:05 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable One could also reference STUN RFC 3489 which included study of NAT types in the SIP working group. http://www.ietf.org/rfc/rfc3489.txt It provides a solution for discovering and working around some types of NAT using a STUN server as a helper agent. (intended for a SIP environment) I only bring this up as background information. -Darren > -----Original Message----- > From: Suresh Satapati [mailto:satapati@gmail.com] > Sent: Monday, June 13, 2005 10:02 AM > To: Darren Loher > Cc: Sadot, Emek (Emek); Pat Calhoun; David T. Perkins; Cheng Hong; > capwap@frascone.com > Subject: Re: [Capwap] NAT traversal >=20 > On 6/10/05, Darren Loher wrote: > > I agree with Emek that #4 and #5 are important problems when using NAT. >=20 > Agreed. Also agree with the two high level scenarios :- > 1. WTP behind NAT > 2. AC behind NAT >=20 > I can send some text on different types of NATs in the market place > today. We have gone through this exercise in V6OPS. All this can go > into a separate document if the WG feels this is useful work.. >=20 > > But I think wether communication is lost via NAT distruption/reboot, > > link issues or other reasons, a reasonable CAPWAP implementation should > > have a method to survive a lost connection and restore the connection > > between WTP and AC. > > > > Connection integrity/keepalive type functions which would address > > problems like these probably do not need to be explicit requirements. >=20 > Yes. No need for explicit requirements here.. >=20 > > > > -Darren > > > > > -----Original Message----- > > > From: Sadot, Emek (Emek) [mailto:esadot@avaya.com] > > > Sent: Friday, June 10, 2005 8:52 AM > > > To: Pat Calhoun; David T. Perkins; Darren Loher > > > Cc: Cheng Hong; capwap@frascone.com > > > Subject: RE: [Capwap] NAT traversal > > > > > > Pat, > > > > > > Compare to other along-the-way network appliances NAT device reboot > > > presents communication challenge as parties (e.g. AC and WTP) need to > > > proactively resume communication / protocol from the private side of > > the > > > NAT. I would say that the CAPWAP protocol can come up with a solution > > > for #4 that will covers #5 scenario as well. > > > > > > Emek > > > > > > -----Original Message----- > > > From: Pat Calhoun [mailto:pcalhoun@cisco.com] > > > Sent: Friday, June 10, 2005 8:45 AM > > > To: Sadot, Emek (Emek); 'David T. Perkins'; 'Darren Loher' > > > Cc: 'Cheng Hong'; capwap@frascone.com > > > Subject: RE: [Capwap] NAT traversal > > > > > > I am ok with most statements here, but not necessarily with number 5. > > I > > > don't think we need to go as far as to try to create a protocol that > > can > > > guard itself against broken NAT infrastructure. > > > > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit > > > Cisco Systems > > > > > > > > > > > > > -----Original Message----- > > > > From: Sadot, Emek (Emek) [mailto:esadot@avaya.com] > > > > Sent: Thursday, June 09, 2005 8:27 PM > > > > To: David T. Perkins; Darren Loher > > > > Cc: Pat Calhoun; Cheng Hong; capwap@frascone.com > > > > Subject: RE: [Capwap] NAT traversal > > > > > > > > David, > > > > > > > > Excellent diagram. Respectfully I would avoid naming "Internet" as > > NAT > > > > > > > device can segregate Enterprise's internal segments. A second WTP in > > > > the private domain (10.1.2.2) may be helpful as well. > > > > > > > > A few problems presented by a NAT device: > > > > 1. NAT manipulate layer 4 ports -> CAPWAP protocol cannot be layer 3 > > > > protocol based. > > > > 2. Symmetric NAT will drop AC communicating with the WTP unless the > > > > WTP initiate the communication first. > > > > 3. WTP unique identification at the AC must not by WTP's IP address > > > > (and > > > > port) based. > > > > 4. WTP to AC CAPWAP session must be refreshed at the NAT device. > > > > 5. CAPWAP protocol shall be immunized against NAT device crash. More > > > > specifically, since session mapping will be erased at the NAT device > > > > the WTP (in contrast to the AC) must send CAPWAP to resume > > > > communication. > > > > > > > > Emek > > > > > > > > > > > > -----Original Message----- > > > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > > > Sent: Thursday, June 09, 2005 8:20 PM > > > > To: Darren Loher > > > > Cc: Pat Calhoun; Cheng Hong; Sadot, Emek (Emek); capwap@frascone.com > > > > Subject: RE: [Capwap] NAT traversal > > > > > > > > HI Darren & Pat, > > > > > > > > I'm still having a problem understanding what you are trying to > > > > accomplish. > > > > > > > > Here is a picture.... > > > > > > > > > > > > /------------\ 209.128.82.1 10.1.1.1 /---------------\ > > > > | | ---------- | | > > > > | Internet |-----------|NAT box |-----|Private Network | > > > > | |--- ---------- |(say 10.1.1.0/16)| > > > > \-----------/ \ \---------------/ > > > > | \ | > > > > AC \ WTP STA-IP=3D? > > > > 209.128.82.62 \ 10.1.2.1 > > > > \ /---------------\ > > > > \ ---------- | | > > > > --|NAT box |-----|Private Network | > > > > ---------- |(say 10.1.1.0/16)| > > > > 209.128.82.2 10.1.1.1 \---------------/ > > > > | > > > > WTP STA-IP=3D? > > > > 10.1.2.1 > > > > > > > > More NAT boxes > > > > > > > > Is this what you are talking about? And If so, tell me again what > > > > problem are you trying to solve, or service that you are wanting to > > > > provide? > > > > > > > > Regards, > > > > /david t. perkins > > > > > > > > On Thu, 9 Jun 2005, Darren Loher wrote: > > > > > On the requirements side for NAT, should we specify if the WTP is > > > > behind > > > > > NAT, the AC behind NAT or both? I can see two basic scenarios > > > > > realistically being implemented: > > > > > > > > > > > > > > > > > > > > Assume: > > > > > > > > > > - Hotspot provider uses whatever available broadband > > > > connection as an > > > > > Internet uplink > > > > > > > > > > -This connection is limited to one, dynamically assigned IP > > address > > > > > > > > > > -NAT is required to share the connection with multiple hosts > > > > > > > > > > > > > > > > > > > > Scenario 1: The hotspot provider's AC is on the open Internet > > > > > > > > > > Scenario 2: The hotspot provider's AC is behind a NAT > > > > firewall and the > > > > > hotspot provider has port forwarding and/or static NAT > > > > control of this > > > > > firewall > > > > > > > > > > > > > > > > > > > > There could be several more, but these seem very common and > > > > > straightforward. > > > > > > > > > > > > > > > > > > > > -Darren > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > From: capwap-admin@frascone.com > > > > [mailto:capwap-admin@frascone.com] On > > > > > Behalf Of Pat Calhoun > > > > > Sent: Thursday, June 09, 2005 7:19 AM > > > > > To: 'Cheng Hong'; 'Sadot, Emek (Emek)'; capwap@frascone.com > > > > > Subject: RE: [Capwap] NAT traversal > > > > > > > > > > > > > > > > > > > > Imagine a service provider connecting their AC to their customer's > > > > WTPs > > > > > across a NAT. Makes sense to me. > > > > > > > > > > > > > > > > > > > > Pat Calhoun > > > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > > > > From: capwap-admin@frascone.com > > > > > [mailto:capwap-admin@frascone.com] On Behalf Of Cheng Hong > > > > > Sent: Thursday, June 09, 2005 12:52 AM > > > > > To: Sadot, Emek (Emek); capwap@frascone.com > > > > > Subject: RE: [Capwap] NAT traversal > > > > > > > > > > Hi Emek, > > > > > > > > > > > > > > > > > > > > Would like to know a bit more about the deployment examples: > > > > > > > > > > > > > > > > > > > > >>say the WTP is located at branch office and the AC at > > > > the main > > > > > office separated by NAT device > > > > > > > > > > > > > > > > > > > > In this case, most likely the NAT traversal is not a > > > > problem for the > > > > > WTP or AC directly. For the branch office and main office case, > > > > most > > > > > likely there will be a VPN setup between them. To the WTP > > > > and AC, NAT > > > > > will be transparent. > > > > > > > > > > > > > > > > > > > > >>or within an Enterprise segregated by NAT devices. > > > > > > > > > > > > > > > > > > > > Does this mean AC and WTP are on different side of the > > > > NAT? It sounds > > > > > interesting, but is there any reason for deploy it in such a > > > > way > > > > > (A NAT inside the enterprise network to separate the AC and WTP)? > > > > > > > > > > > > > > > > > > > > cheers > > > > > > > > > > > > > > > > > > > > Cheng Hong > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > > > > From: capwap-admin@frascone.com > > > > > [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) > > > > > Sent: Wednesday, June 08, 2005 4:27 AM > > > > > To: capwap@frascone.com > > > > > Subject: [Capwap] NAT traversal > > > > > > > > > > All, > > > > > > > > > > > > > > > > > > > > Would like to suggest adding a NAT traversal > > > > requirement to the > > > > > CAPWAP objective document, i.e. the ability of AC and WTP to > > > > > communicate across NAT device (UDP / TCP transport, refresh CAPWAP > > > > > session at the NAT device, WTP identification behind NAT device, > > > > etc.). > > > > > Deployment examples? say the WTP is located at branch office and > > the > > > > AC > > > > > at the main office separated by NAT device, or within an > > Enterprise > > > > > segregated by NAT devices. > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Emek > > > > > > > > > > > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Jun 13 12:51:11 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29087 for ; Mon, 13 Jun 2005 12:51:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E1E4F2049C; Mon, 13 Jun 2005 12:51:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4A8C620427; Mon, 13 Jun 2005 12:51:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1B07720427 for ; Mon, 13 Jun 2005 12:50:59 -0400 (EDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.207]) by mail.frascone.com (Postfix) with ESMTP id 2B7B4202C8 for ; Mon, 13 Jun 2005 12:50:56 -0400 (EDT) Received: by wproxy.gmail.com with SMTP id 49so142665wri for ; Mon, 13 Jun 2005 09:50:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JlyKH/9fK7xuJARCVMZuOCIxqTNxdWdyeybmduSLhlyVc0fshpNXCZi0c2/+GJeDaqV3sVNy9YfdwFUd5iZQfwR9Niac3HGfRFJDL6Lmo3vFpS8I/MKBBg4YT+jDcPcOq95WScSLDGQRTNbSp4WZEP/ivkeVm7qaGVKILCI8oKI= Received: by 10.54.17.22 with SMTP id 22mr149966wrq; Mon, 13 Jun 2005 09:50:55 -0700 (PDT) Received: by 10.54.19.19 with HTTP; Mon, 13 Jun 2005 09:50:55 -0700 (PDT) Message-ID: <9852189205061309504562ebf0@mail.gmail.com> From: Suresh Satapati Reply-To: Suresh Satapati To: James Kempf Subject: Re: [Capwap] NAT traversal Cc: "Mani, Mahalingam (Mahalingam)" , Darren Loher , "Sadot, Emek (Emek)" , "David T. Perkins" , Pat Calhoun , Cheng Hong , capwap@frascone.com In-Reply-To: <027e01c56dde$62e095a0$016115ac@dcml.docomolabsusa.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <027e01c56dde$62e095a0$016115ac@dcml.docomolabsusa.com> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 13 Jun 2005 09:50:55 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Talk about IPv6, are there any thoughts/recommendations/experiences to share on how IPv6 is supposed to work ? Is this included in the charter (sorry haven't read the charter) ? There are several scenarios (enterprise, unmanaged, service-provider etc) documents in v6ops, where were written before CAPWAP was formed. Not sure how much of that work needs update or still holds true in the current context.. On 6/10/05, James Kempf wrote: > I think there might be some cases where the AC and WTPs might be on > different sides of a NAT, but I think the most likely scenarios are fairl= y > limited. >=20 > I'm wondering if the CAPWAP protocol itself needs to support NATs or if i= t > might be possible to include NAT support in a separate document, such as > SIP/STUN and Mobile IP did? It might make the base protocol simplier. In > addition, if CAPWAP supports IPv6 (will it?) and everyone's hopes actuall= y > become reality and IPv6 networks don't have NATs, then having a simplier > base protocol could make IPv6 deployments simplier. >=20 > jak >=20 >=20 > ----- Original Message ----- > From: "Mani, Mahalingam (Mahalingam)" > To: "Darren Loher" ; "Sadot, Emek (Emek)" > ; "David T. Perkins" > Cc: "Pat Calhoun" ; "Cheng Hong" > ; > Sent: Friday, June 10, 2005 9:47 AM > Subject: RE: [Capwap] NAT traversal >=20 >=20 > Speaking as a member of the WG: >=20 > It would be preferable to have the NAT problem scenarios articulated in > a draft - so we have a distinct record of possible problem scenario(s). > While this may not turn out to be a work item - inasmuch as it happens > to be one of the possible provider and/or (extended) enterprise > deployment scenarios - it would be unfair to let it go unaddressed. >=20 > The protocol (and the WG) is aimed to help solve the primary pain-points > of managing large WLAN deployments - and avoid creating additional ones > along the way if we can help it (that should be a generic objective as > well :)). >=20 > Some deployments may be able to address this by way of distributed > (cooperating) AC instances. However, that may not be the normal case. >=20 > Providers and large enterprise IT-admins on the list should speak up on > this. >=20 > -mani > =3D=3D=3D=3D=3D=3D > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Darren Loher > Sent: Friday, June 10, 2005 9:33 AM > To: Sadot, Emek (Emek); David T. Perkins > Cc: Pat Calhoun; Cheng Hong; capwap@frascone.com > Subject: RE: [Capwap] NAT traversal >=20 > I am starting to think we should leave the NAT issue open to > implementers. We could say, "The CAPWAP protocol SHOULD minimally > support WTP's which are behind a symmetric NAT. The CAPWAP protocol MAY > operate over additional forms of NAT." >=20 > The details of how and if this requirement is satisfied should be left > to the CAPWAP protocol. I would certainly give preference to a protocol > which solved at least the minimal case of a WTP's behind symmetric NAT > as in David Perkin's diagram. >=20 > Also regarding problem #5 below, I think this issue would likely be > addressed with the discovery and connection management of the CAPWAP > protocol. The working group has already agreed that discovery > mechanisms are out of scope of CAPWAP, so we should not write in what > are discovery through NAT requirement. >=20 > -Darren >=20 > > -----Original Message----- > > From: Sadot, Emek (Emek) [mailto:esadot@avaya.com] > > Sent: Thursday, June 09, 2005 9:27 PM > > To: David T. Perkins; Darren Loher > > Cc: Pat Calhoun; Cheng Hong; capwap@frascone.com > > Subject: RE: [Capwap] NAT traversal > > > > David, > > > > Excellent diagram. Respectfully I would avoid naming "Internet" as NAT > > device can segregate Enterprise's internal segments. A second WTP in > the > > private domain (10.1.2.2) may be helpful as well. > > > > A few problems presented by a NAT device: > > 1. NAT manipulate layer 4 ports -> CAPWAP protocol cannot be layer 3 > > protocol based. > > 2. Symmetric NAT will drop AC communicating with the WTP unless the > WTP > > initiate the communication first. > > 3. WTP unique identification at the AC must not by WTP's IP address > (and > > port) based. > > 4. WTP to AC CAPWAP session must be refreshed at the NAT device. > > 5. CAPWAP protocol shall be immunized against NAT device crash. More > > specifically, since session mapping will be erased at the NAT device > the > > WTP (in contrast to the AC) must send CAPWAP to resume communication. > > > > Emek > > > > > > -----Original Message----- > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > Sent: Thursday, June 09, 2005 8:20 PM > > To: Darren Loher > > Cc: Pat Calhoun; Cheng Hong; Sadot, Emek (Emek); capwap@frascone.com > > Subject: RE: [Capwap] NAT traversal > > > > HI Darren & Pat, > > > > I'm still having a problem understanding what you are trying > > to accomplish. > > > > Here is a picture.... > > > > > > /------------\ 209.128.82.1 10.1.1.1 /---------------\ > > | | ---------- | | > > | Internet |-----------|NAT box |-----|Private Network | > > | |--- ---------- |(say 10.1.1.0/16)| > > \-----------/ \ \---------------/ > > | \ | > > AC \ WTP STA-IP=3D? > > 209.128.82.62 \ 10.1.2.1 > > \ /---------------\ > > \ ---------- | | > > --|NAT box |-----|Private Network | > > ---------- |(say 10.1.1.0/16)| > > 209.128.82.2 10.1.1.1 \---------------/ > > | > > WTP STA-IP=3D? > > 10.1.2.1 > > > > More NAT boxes > > > > Is this what you are talking about? And If so, tell me again > > what problem are you trying to solve, or service that you > > are wanting to provide? > > > > Regards, > > /david t. perkins > > > > On Thu, 9 Jun 2005, Darren Loher wrote: > > > On the requirements side for NAT, should we specify if the WTP is > > behind > > > NAT, the AC behind NAT or both? I can see two basic scenarios > > > realistically being implemented: > > > > > > > > > > > > Assume: > > > > > > - Hotspot provider uses whatever available broadband connection as > an > > > Internet uplink > > > > > > -This connection is limited to one, dynamically assigned IP address > > > > > > -NAT is required to share the connection with multiple hosts > > > > > > > > > > > > Scenario 1: The hotspot provider's AC is on the open Internet > > > > > > Scenario 2: The hotspot provider's AC is behind a NAT firewall and > the > > > hotspot provider has port forwarding and/or static NAT control of > this > > > firewall > > > > > > > > > > > > There could be several more, but these seem very common and > > > straightforward. > > > > > > > > > > > > -Darren > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] > On > > > Behalf Of Pat Calhoun > > > Sent: Thursday, June 09, 2005 7:19 AM > > > To: 'Cheng Hong'; 'Sadot, Emek (Emek)'; capwap@frascone.com > > > Subject: RE: [Capwap] NAT traversal > > > > > > > > > > > > Imagine a service provider connecting their AC to their customer's > > WTPs > > > across a NAT. Makes sense to me. > > > > > > > > > > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit > > > Cisco Systems > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On Behalf Of Cheng Hong > > > Sent: Thursday, June 09, 2005 12:52 AM > > > To: Sadot, Emek (Emek); capwap@frascone.com > > > Subject: RE: [Capwap] NAT traversal > > > > > > Hi Emek, > > > > > > > > > > > > Would like to know a bit more about the deployment examples: > > > > > > > > > > > > >>say the WTP is located at branch office and the AC at the main > > > office separated by NAT device > > > > > > > > > > > > In this case, most likely the NAT traversal is not a problem for > > > the WTP or AC directly. For the branch office and main office case, > > most > > > likely there will be a VPN setup between them. To the WTP and AC, > NAT > > > will be transparent. > > > > > > > > > > > > >>or within an Enterprise segregated by NAT devices. > > > > > > > > > > > > Does this mean AC and WTP are on different side of the NAT? It > > > sounds interesting, but is there any reason for deploy it in such a > > way > > > (A NAT inside the enterprise network to separate the AC and WTP)? > > > > > > > > > > > > cheers > > > > > > > > > > > > Cheng Hong > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) > > > Sent: Wednesday, June 08, 2005 4:27 AM > > > To: capwap@frascone.com > > > Subject: [Capwap] NAT traversal > > > > > > All, > > > > > > > > > > > > Would like to suggest adding a NAT traversal requirement > > > to the CAPWAP objective document, i.e. the ability of AC and WTP to > > > communicate across NAT device (UDP / TCP transport, refresh CAPWAP > > > session at the NAT device, WTP identification behind NAT device, > > etc.). > > > Deployment examples? say the WTP is located at branch office and the > > AC > > > at the main office separated by NAT device, or within an Enterprise > > > segregated by NAT devices. > > > > > > > > > > > > Regards, > > > > > > Emek > > > > > > > > >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Jun 13 14:05:10 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04611 for ; Mon, 13 Jun 2005 14:05:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EADEC20477; Mon, 13 Jun 2005 14:05:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 477D1203E0; Mon, 13 Jun 2005 14:05:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A83A0203E0 for ; Mon, 13 Jun 2005 14:04:44 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id C23951FE0F for ; Mon, 13 Jun 2005 14:04:42 -0400 (EDT) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5DI2Ddd014266 for ; Mon, 13 Jun 2005 14:02:14 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5DI2Cdd014231 for ; Mon, 13 Jun 2005 14:02:12 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <5844A41F4E146044A2E8356C6328588008D1B7F8@nj7460avexu2.global.avaya.com> Thread-Topic: NAT traversal objective - take II Thread-Index: AcVwQl1GT4yI/UPOQcuCCQ69bUcp5A== From: "Sadot, Emek (Emek)" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] NAT traversal objective - take II Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 13 Jun 2005 14:04:39 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I would like to propose adding below NAT traversal requirement following the last thread on the subject. Classification: Architecture =20 Description: The CAPWAP protocol doesn't pose any restriction on the environment where the AC and the WTP will be deployed and which devices facilitate communication between the two. Therefore traversing NAT device cannot be ruled out and the CAPWAP protocol should be robusted against such a scenario. Protocol Requirement: CAPWAP protocol shall accommodate NAT traversal scenario and in particular allow NAT device to manipulate layer 4 ports, take into consideration symmetric NAT behavior (allowing access from the public side only after session establish from the private side) and avoid peer identification based on entity (e.g. WTP, AC) IP addresses. Motivation and Protocol Benefits: Independence of WTP and AC on intermediate devices and extending deployment topologies and variance. A service provider connecting their AC to their customer's WTP across a NAT device is an example of potential deployment scenario. Relation to Problem Statement: This requirement is based on WG discussions that have determined to be important for CAPWAP.=20 Emek _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Jun 13 14:26:11 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05897 for ; Mon, 13 Jun 2005 14:26:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0BBFE1FE0F; Mon, 13 Jun 2005 14:26:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D6CF6203E0; Mon, 13 Jun 2005 14:26:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DA681203E0 for ; Mon, 13 Jun 2005 14:25:15 -0400 (EDT) Received: from smtpout1.bayarea.net (smtpout1.BAYAREA.NET [209.128.95.10]) by mail.frascone.com (Postfix) with ESMTP id BF70F1FE0F for ; Mon, 13 Jun 2005 14:25:13 -0400 (EDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j5DIPDeQ015021; Mon, 13 Jun 2005 11:25:13 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j5DIPAFq025565; Mon, 13 Jun 2005 11:25:10 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j5DIP9Hp025557; Mon, 13 Jun 2005 11:25:10 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Sadot, Emek (Emek)" Cc: capwap@frascone.com Subject: Re: [Capwap] NAT traversal objective - take II In-Reply-To: <5844A41F4E146044A2E8356C6328588008D1B7F8@nj7460avexu2.global.avaya.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 13 Jun 2005 11:25:09 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) HI, In this discussion, it seems like all are focusing on just the AC to WTP communication and not the requirements and consequences of such communication on the STAs that associate with the WTPs. In the below, and in previous messages, a motivation was given as "A service provider connecting their AC to their customer's WTP across a NAT device is an example of potential deployment scenario." This seems like "technology solution" in search of a real world need. Would someone please describe what need and benefit is provided by "A service provider..." and include the IP address assignments, and a description of who the STAs would be communicating with. On Mon, 13 Jun 2005, Sadot, Emek (Emek) wrote: > I would like to propose adding below NAT traversal requirement following > the last thread on the subject. > > > Classification: Architecture > > Description: > The CAPWAP protocol doesn't pose any restriction on the environment > where the AC and the WTP will be deployed and which devices facilitate > communication between the two. Therefore traversing NAT device cannot be > ruled out and the CAPWAP protocol should be robusted against such a > scenario. > > Protocol Requirement: > CAPWAP protocol shall accommodate NAT traversal scenario and in > particular allow NAT device to manipulate layer 4 ports, take into > consideration symmetric NAT behavior (allowing access from the public > side only after session establish from the private side) and avoid peer > identification based on entity (e.g. WTP, AC) IP addresses. > > Motivation and Protocol Benefits: > Independence of WTP and AC on intermediate devices and extending > deployment topologies and variance. A service provider connecting their > AC to their customer's WTP across a NAT device is an example of > potential deployment scenario. > > Relation to Problem Statement: > This requirement is based on WG discussions that have determined to be > important for CAPWAP. > > > Emek > Regards, /david t. perkins _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Jun 13 16:16:10 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01558 for ; Mon, 13 Jun 2005 16:16:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 900DF204FE; Mon, 13 Jun 2005 16:16:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F1F45204B7; Mon, 13 Jun 2005 16:16:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8ACB6204B7 for ; Mon, 13 Jun 2005 16:15:17 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 37CBA2049C for ; Mon, 13 Jun 2005 16:15:13 -0400 (EDT) Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5DK3NAK012666 for ; Mon, 13 Jun 2005 16:03:23 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5DK3AAK012249 for ; Mon, 13 Jun 2005 16:03:11 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] NAT traversal Message-ID: Thread-Topic: [Capwap] NAT traversal Thread-Index: AcVt3j2GhRuHVYLkSTydcExy68RCcwCWiEfg From: "Mani, Mahalingam (Mahalingam)" To: "James Kempf" , "Darren Loher" , "Sadot, Emek (Emek)" , "David T. Perkins" Cc: "Pat Calhoun" , "Cheng Hong" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 13 Jun 2005 14:14:57 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Speaking as a WG member- I agree on the point of keeping the base protocol simple. I believe that NAT applicability could be managed as follows: Depending on how analogous the CAPWAP protocol shapes up - to other protocols encountering similar challenges at L3 and higher and have addressed them with/out limitations - applicability of existing SIP/STUN, IPsec/IKE, NSIS, BEHAVE approaches would be worth comparing. That is later. In CAPWAP case we have an opportunity to examine it up front. That said - We have to live with the need to maneuver in NAT environments. However, we should avoid built-in workarounds to NAT behaviors (that would be endorsing use of NAT). Thus - I think & agree it must not be a part of CAPWAP protocol to provide explicit support for NAT. As WG chair: Further - with the Objectives, Evaluation schedules and upcoming milestones in mind - we should preferably address it outside the scope of the base protocol. [Actually - at one point (and I still think it is true) - by default all new IETF protocols were implicitly required to support IPv6. if that is so - that becomes an implicit requirement (MUST). If not - it is a highly desirable objective (SHOULD). NAT-avoidance is a side-effect in IPv6]. Regards, -mani =3D=3D=3D=3D=3D=3D -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com]=20 Sent: Friday, June 10, 2005 10:04 AM To: Mani, Mahalingam (Mahalingam); Darren Loher; Sadot, Emek (Emek); David T. Perkins Cc: Pat Calhoun; Cheng Hong; capwap@frascone.com Subject: Re: [Capwap] NAT traversal I think there might be some cases where the AC and WTPs might be on different sides of a NAT, but I think the most likely scenarios are fairly limited. I'm wondering if the CAPWAP protocol itself needs to support NATs or if it might be possible to include NAT support in a separate document, such as SIP/STUN and Mobile IP did? It might make the base protocol simplier. In addition, if CAPWAP supports IPv6 (will it?) and everyone's hopes actually become reality and IPv6 networks don't have NATs, then having a simplier base protocol could make IPv6 deployments simplier. jak ----- Original Message -----=20 From: "Mani, Mahalingam (Mahalingam)" To: "Darren Loher" ; "Sadot, Emek (Emek)" ; "David T. Perkins" Cc: "Pat Calhoun" ; "Cheng Hong" ; Sent: Friday, June 10, 2005 9:47 AM Subject: RE: [Capwap] NAT traversal Speaking as a member of the WG: It would be preferable to have the NAT problem scenarios articulated in a draft - so we have a distinct record of possible problem scenario(s). While this may not turn out to be a work item - inasmuch as it happens to be one of the possible provider and/or (extended) enterprise deployment scenarios - it would be unfair to let it go unaddressed. The protocol (and the WG) is aimed to help solve the primary pain-points of managing large WLAN deployments - and avoid creating additional ones along the way if we can help it (that should be a generic objective as well :)). Some deployments may be able to address this by way of distributed (cooperating) AC instances. However, that may not be the normal case. Providers and large enterprise IT-admins on the list should speak up on this. -mani =3D=3D=3D=3D=3D=3D -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Darren Loher Sent: Friday, June 10, 2005 9:33 AM To: Sadot, Emek (Emek); David T. Perkins Cc: Pat Calhoun; Cheng Hong; capwap@frascone.com Subject: RE: [Capwap] NAT traversal I am starting to think we should leave the NAT issue open to implementers. We could say, "The CAPWAP protocol SHOULD minimally support WTP's which are behind a symmetric NAT. The CAPWAP protocol MAY operate over additional forms of NAT." The details of how and if this requirement is satisfied should be left to the CAPWAP protocol. I would certainly give preference to a protocol which solved at least the minimal case of a WTP's behind symmetric NAT as in David Perkin's diagram. Also regarding problem #5 below, I think this issue would likely be addressed with the discovery and connection management of the CAPWAP protocol. The working group has already agreed that discovery mechanisms are out of scope of CAPWAP, so we should not write in what are discovery through NAT requirement. -Darren > -----Original Message----- > From: Sadot, Emek (Emek) [mailto:esadot@avaya.com] > Sent: Thursday, June 09, 2005 9:27 PM > To: David T. Perkins; Darren Loher > Cc: Pat Calhoun; Cheng Hong; capwap@frascone.com > Subject: RE: [Capwap] NAT traversal > > David, > > Excellent diagram. Respectfully I would avoid naming "Internet" as NAT > device can segregate Enterprise's internal segments. A second WTP in the > private domain (10.1.2.2) may be helpful as well. > > A few problems presented by a NAT device: > 1. NAT manipulate layer 4 ports -> CAPWAP protocol cannot be layer 3 > protocol based. > 2. Symmetric NAT will drop AC communicating with the WTP unless the WTP > initiate the communication first. > 3. WTP unique identification at the AC must not by WTP's IP address (and > port) based. > 4. WTP to AC CAPWAP session must be refreshed at the NAT device. > 5. CAPWAP protocol shall be immunized against NAT device crash. More > specifically, since session mapping will be erased at the NAT device the > WTP (in contrast to the AC) must send CAPWAP to resume communication. > > Emek > > > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Thursday, June 09, 2005 8:20 PM > To: Darren Loher > Cc: Pat Calhoun; Cheng Hong; Sadot, Emek (Emek); capwap@frascone.com > Subject: RE: [Capwap] NAT traversal > > HI Darren & Pat, > > I'm still having a problem understanding what you are trying > to accomplish. > > Here is a picture.... > > > /------------\ 209.128.82.1 10.1.1.1 /---------------\ > | | ---------- | | > | Internet |-----------|NAT box |-----|Private Network | > | |--- ---------- |(say 10.1.1.0/16)| > \-----------/ \ \---------------/ > | \ | > AC \ WTP STA-IP=3D? > 209.128.82.62 \ 10.1.2.1 > \ /---------------\ > \ ---------- | | > --|NAT box |-----|Private Network | > ---------- |(say 10.1.1.0/16)| > 209.128.82.2 10.1.1.1 \---------------/ > | > WTP STA-IP=3D? > 10.1.2.1 > > More NAT boxes > > Is this what you are talking about? And If so, tell me again > what problem are you trying to solve, or service that you > are wanting to provide? > > Regards, > /david t. perkins > > On Thu, 9 Jun 2005, Darren Loher wrote: > > On the requirements side for NAT, should we specify if the WTP is > behind > > NAT, the AC behind NAT or both? I can see two basic scenarios > > realistically being implemented: > > > > > > > > Assume: > > > > - Hotspot provider uses whatever available broadband connection as an > > Internet uplink > > > > -This connection is limited to one, dynamically assigned IP address > > > > -NAT is required to share the connection with multiple hosts > > > > > > > > Scenario 1: The hotspot provider's AC is on the open Internet > > > > Scenario 2: The hotspot provider's AC is behind a NAT firewall and the > > hotspot provider has port forwarding and/or static NAT control of this > > firewall > > > > > > > > There could be several more, but these seem very common and > > straightforward. > > > > > > > > -Darren > > > > > > > > > > > > > > > > ________________________________ > > > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > > Behalf Of Pat Calhoun > > Sent: Thursday, June 09, 2005 7:19 AM > > To: 'Cheng Hong'; 'Sadot, Emek (Emek)'; capwap@frascone.com > > Subject: RE: [Capwap] NAT traversal > > > > > > > > Imagine a service provider connecting their AC to their customer's > WTPs > > across a NAT. Makes sense to me. > > > > > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > > > > > > > > > ________________________________ > > > > > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Cheng Hong > > Sent: Thursday, June 09, 2005 12:52 AM > > To: Sadot, Emek (Emek); capwap@frascone.com > > Subject: RE: [Capwap] NAT traversal > > > > Hi Emek, > > > > > > > > Would like to know a bit more about the deployment examples: > > > > > > > > >>say the WTP is located at branch office and the AC at the main > > office separated by NAT device > > > > > > > > In this case, most likely the NAT traversal is not a problem for > > the WTP or AC directly. For the branch office and main office case, > most > > likely there will be a VPN setup between them. To the WTP and AC, NAT > > will be transparent. > > > > > > > > >>or within an Enterprise segregated by NAT devices. > > > > > > > > Does this mean AC and WTP are on different side of the NAT? It > > sounds interesting, but is there any reason for deploy it in such a > way > > (A NAT inside the enterprise network to separate the AC and WTP)? > > > > > > > > cheers > > > > > > > > Cheng Hong > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) > > Sent: Wednesday, June 08, 2005 4:27 AM > > To: capwap@frascone.com > > Subject: [Capwap] NAT traversal > > > > All, > > > > > > > > Would like to suggest adding a NAT traversal requirement > > to the CAPWAP objective document, i.e. the ability of AC and WTP to > > communicate across NAT device (UDP / TCP transport, refresh CAPWAP > > session at the NAT device, WTP identification behind NAT device, > etc.). > > Deployment examples? say the WTP is located at branch office and the > AC > > at the main office separated by NAT device, or within an Enterprise > > segregated by NAT devices. > > > > > > > > Regards, > > > > Emek > > > > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Jun 13 17:29:09 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07641 for ; Mon, 13 Jun 2005 17:29:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 69BD020502; Mon, 13 Jun 2005 17:29:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DFCCE204BC; Mon, 13 Jun 2005 17:29:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 13E80204B7 for ; Mon, 13 Jun 2005 17:28:35 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 157E4204BC for ; Mon, 13 Jun 2005 17:28:33 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 13 Jun 2005 14:28:33 -0700 X-IronPort-AV: i="3.93,195,1115017200"; d="scan'208"; a="278207462:sNHT30775068" Received: from pacalhouwxp (sjc-vpn1-129.cisco.com [10.21.96.129]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5DLSUlq018671; Mon, 13 Jun 2005 14:28:31 -0700 (PDT) Message-Id: <200506132128.j5DLSUlq018671@sj-core-5.cisco.com> From: "Pat Calhoun" To: "'David T. Perkins'" , "'Sadot, Emek (Emek)'" Cc: Subject: RE: [Capwap] NAT traversal objective - take II MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVwRZqssq3XO7V0QbSCTQ8CwSjqfQAGOIew In-Reply-To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 13 Jun 2005 14:28:29 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I thought this picture that you had provided was correct. /------------\ 209.128.82.1 10.1.1.1 /---------------\ | | ---------- | | | Internet |-----------|NAT box |-----|Private Network | | |--- ---------- |(say 10.1.1.0/16)| \-----------/ \ \---------------/ | \ | AC \ WTP STA-IP=? 209.128.82.62 \ 10.1.2.1 \ /---------------\ \ ---------- | | --|NAT box |-----|Private Network | ---------- |(say 10.1.1.0/16)| 209.128.82.2 10.1.1.1 \---------------/ | WTP STA-IP=? 10.1.2.1 More NAT boxes Given you are quoting me, I had responded stating that I am not, and have no plans to be, a service provider. Further, I had stated that to my knowledge this type of deployment did not exist today, but that in certain geographical areas outsourcing of LAN exists, so I don't necessarily see WLAN as not being a possiblity. If we really believe that we are chasing a solution with no problem, then we don't have to. However, I really don't see a problem with requiring NAT in the objectives. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of David T. Perkins > Sent: Monday, June 13, 2005 11:25 AM > To: Sadot, Emek (Emek) > Cc: capwap@frascone.com > Subject: Re: [Capwap] NAT traversal objective - take II > > HI, > > In this discussion, it seems like all are focusing on just > the AC to WTP communication and not the requirements and > consequences of such communication on the STAs that associate > with the WTPs. > > In the below, and in previous messages, a motivation was > given as "A service provider connecting their AC to their > customer's WTP across a NAT device is an example of potential > deployment scenario." This seems like "technology solution" > in search of a real world need. > > Would someone please describe what need and benefit is > provided by "A service provider..." and include the IP > address assignments, and a description of who the STAs would > be communicating with. > > > On Mon, 13 Jun 2005, Sadot, Emek (Emek) wrote: > > I would like to propose adding below NAT traversal requirement > > following the last thread on the subject. > > > > > > Classification: Architecture > > > > Description: > > The CAPWAP protocol doesn't pose any restriction on the environment > > where the AC and the WTP will be deployed and which devices > facilitate > > communication between the two. Therefore traversing NAT > device cannot > > be ruled out and the CAPWAP protocol should be robusted > against such a > > scenario. > > > > Protocol Requirement: > > CAPWAP protocol shall accommodate NAT traversal scenario and in > > particular allow NAT device to manipulate layer 4 ports, take into > > consideration symmetric NAT behavior (allowing access from > the public > > side only after session establish from the private side) and avoid > > peer identification based on entity (e.g. WTP, AC) IP addresses. > > > > Motivation and Protocol Benefits: > > Independence of WTP and AC on intermediate devices and extending > > deployment topologies and variance. A service provider connecting > > their AC to their customer's WTP across a NAT device is an > example of > > potential deployment scenario. > > > > Relation to Problem Statement: > > This requirement is based on WG discussions that have > determined to be > > important for CAPWAP. > > > > > > Emek > > > Regards, > /david t. perkins > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From bedoka@emailaccount.com Mon Jun 13 22:54:07 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04403; Mon, 13 Jun 2005 22:54:07 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Di1vR-00056n-UG; Mon, 13 Jun 2005 23:17:19 -0400 Received: from s0106000325089261.ed.shawcable.net ([68.148.67.45]) by mx2.foretec.com with smtp (Exim 4.24) id 1Di1Yx-0000Vr-VS; Mon, 13 Jun 2005 22:54:06 -0400 Received: from brock.wcdaml.screech.antipode.com by hydrofluoric.promiscuity.wristband.com (sjhupfix) with SMTP id 4B29E820223 for ; Tue, 14 Jun 2005 01:24:38 -0200 Message-ID: Date: Tue, 14 Jun 2005 01:25:38 -0200 From: "Marcelo Jensen" To: Subject: Your account #7Z7509 X-Mailer: KYX CP/M FNORD 5602 X-Spam-Score: 2.2 (++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have been selected for our lowest rate in years... You could get over $420,000 for as little as $400 a month! Ba(d credit, Bank*ruptcy? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.sllly.com/signs.asp Best Regards, Lula Hedrick to be remov(ed: http://www.sllly.com/deletion.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From moonite@didamail.com Mon Jun 13 23:35:26 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10070; Mon, 13 Jun 2005 23:35:26 -0400 (EDT) Received: from [138.89.251.254] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Di2ZR-0006ry-0v; Mon, 13 Jun 2005 23:58:39 -0400 Received: from hquc.biz by rhapsodyqzz (sr.1yp) id pxordxyuyx with SMTP; Tue, 14 Jun 2005 07:09:16 +0300 Message-ID: <20041obylz3.ED8DA244AE@mailhost1t.lists.techtarget.com> Date: Tue, 14 Jun 2005 00:08:16 -0400 From: "Marcia Fournier" To: capwap-archive@ietf.org Cc: ccips@ietf.org, cclark@ietf.org, cdi-archive@ietf.org, cdir-admin@ietf.org, cfrg@ietf.org, cfrg-admin@ietf.org, cfrg-archive@ietf.org, cfrg-bounces@ietf.org, cfrg-web-archive@ietf.org, chair@ietf.org Subject: Low mortage rate accepted X-Mailer: KYX CP/M FNORD 5602 X-Spam-Score: 7.7 (+++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have been selected for our lowest rate in years... You could get over $420,000 for as little as $400 a month! Ba(d credit, Bank*ruptcy? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.sllly.com/signs.asp Best Regards, Maria Crow to be remov(ed: http://www.sllly.com/deletion.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From poppied@emailaccount.com Tue Jun 14 08:55:14 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10713; Tue, 14 Jun 2005 08:55:14 -0400 (EDT) Date: Tue, 14 Jun 2005 08:55:14 -0400 (EDT) From: poppied@emailaccount.com Message-Id: <200506141255.IAA10713@ietf.org> Received: from [211.199.19.119] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DiBJE-0006NG-0V; Tue, 14 Jun 2005 09:18:30 -0400 Received: from UMWMAbeae.com (EHLO aauet-a.croix.MH.hcz.net) polonium by mail.mtk.nao.ac.jp (6.4[2 X-Spam-Score: 6.2 (++++++) X-Spam-Flag: YES X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From capwap-admin@frascone.com Tue Jun 14 09:22:11 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16490 for ; Tue, 14 Jun 2005 09:22:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5FEA220373; Tue, 14 Jun 2005 09:22:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A485A2028D; Tue, 14 Jun 2005 09:22:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BF7E52028D for ; Tue, 14 Jun 2005 09:21:40 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id CF7232026B for ; Tue, 14 Jun 2005 09:21:38 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 14 Jun 2005 06:21:37 -0700 Received: from pacalhouwxp ([10.32.30.113]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5EDLZlq002721; Tue, 14 Jun 2005 06:21:35 -0700 (PDT) Message-Id: <200506141321.j5EDLZlq002721@sj-core-5.cisco.com> From: "Pat Calhoun" To: "'Sadot, Emek (Emek)'" , Subject: RE: [Capwap] NAT traversal objective - take II MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVwQl1GT4yI/UPOQcuCCQ69bUcp5AAoU83g In-Reply-To: <5844A41F4E146044A2E8356C6328588008D1B7F8@nj7460avexu2.global.avaya.com> X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.30.113] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 14 Jun 2005 06:21:34 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Having thought about this some more, it appears that the requirements for NAT conflict with the desire to split the control and the data path. While I agree that a WTP can be behind a NAT, I don't believe that an AC can. The reason being that in order to achieve the control/data path split objective, where data goes to one device and control goes to another, it is required that the protocol allows the AC to communicate the data path IP address - and the inclusion of such an IP address in the protocol implicitely breaks NAT traversal. So I would disagree with requiring that an AC can be behind a NAT. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) > Sent: Monday, June 13, 2005 11:05 AM > To: capwap@frascone.com > Subject: [Capwap] NAT traversal objective - take II > > I would like to propose adding below NAT traversal > requirement following the last thread on the subject. > > > Classification: Architecture > > Description: > The CAPWAP protocol doesn't pose any restriction on the > environment where the AC and the WTP will be deployed and > which devices facilitate communication between the two. > Therefore traversing NAT device cannot be ruled out and the > CAPWAP protocol should be robusted against such a scenario. > > Protocol Requirement: > CAPWAP protocol shall accommodate NAT traversal scenario and > in particular allow NAT device to manipulate layer 4 ports, > take into consideration symmetric NAT behavior (allowing > access from the public side only after session establish from > the private side) and avoid peer identification based on > entity (e.g. WTP, AC) IP addresses. > > Motivation and Protocol Benefits: > Independence of WTP and AC on intermediate devices and > extending deployment topologies and variance. A service > provider connecting their AC to their customer's WTP across a > NAT device is an example of potential deployment scenario. > > Relation to Problem Statement: > This requirement is based on WG discussions that have > determined to be important for CAPWAP. > > > Emek > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Jun 14 11:36:10 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27729 for ; Tue, 14 Jun 2005 11:36:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4CA2C20390; Tue, 14 Jun 2005 11:36:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9DCC12037B; Tue, 14 Jun 2005 11:36:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E89F32037B for ; Tue, 14 Jun 2005 11:35:28 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 4555020371 for ; Tue, 14 Jun 2005 11:35:25 -0400 (EDT) Message-ID: <049801c570f6$daf5ba50$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Pat Calhoun" , "'Sadot, Emek (Emek)'" , References: <200506141321.j5EDLZlq002721@sj-core-5.cisco.com> Subject: Re: [Capwap] NAT traversal objective - take II MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 14 Jun 2005 08:36:30 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Pat, > So I would disagree with requiring that an AC can be behind a NAT. > I think the only problem should be if the AC is behind a NAT and the WTPs aren't or the WTPs are behind a different NAT. How about if the AC and WTPs are behind the same NAT? I think that should work, right? jak _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Jun 14 11:44:13 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28196 for ; Tue, 14 Jun 2005 11:44:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B694C203A0; Tue, 14 Jun 2005 11:44:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CB6602037B; Tue, 14 Jun 2005 11:44:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 21E782037B for ; Tue, 14 Jun 2005 11:43:38 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id BFA4D20371 for ; Tue, 14 Jun 2005 11:43:35 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j5EFd2jw023249; Tue, 14 Jun 2005 08:39:02 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200506141539.j5EFd2jw023249@homebrew.trpz.com> To: "James Kempf" Cc: "Pat Calhoun" , "'Sadot, Emek (Emek)'" , capwap@frascone.com Subject: Re: [Capwap] NAT traversal objective - take II In-Reply-To: Your message of "Tue, 14 Jun 2005 08:36:30 PDT." <049801c570f6$daf5ba50$016115ac@dcml.docomolabsusa.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23247.1118763542.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 14 Jun 2005 08:39:02 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) James, If they're behind the same NAT then their packets to and from each other won't be NAT'd, right? In that case as far as CAPWAP is concerned it's just like there is no NAT. Dan. On Tue, 14 Jun 2005 08:36:30 PDT you wrote > Pat, > > > So I would disagree with requiring that an AC can be behind a NAT. > > > > I think the only problem should be if the AC is behind a NAT and the WTPs > aren't or the WTPs are behind a different NAT. How about if the AC and WTPs > are behind the same NAT? I think that should work, right? > > jak > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Jun 14 12:18:10 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01342 for ; Tue, 14 Jun 2005 12:18:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5F0BF204BC; Tue, 14 Jun 2005 12:18:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9DD162041F; Tue, 14 Jun 2005 12:18:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ABF932041F for ; Tue, 14 Jun 2005 12:17:23 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 2AC83203E7 for ; Tue, 14 Jun 2005 12:17:20 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j5EG9d3O023365; Tue, 14 Jun 2005 09:09:40 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200506141609.j5EG9d3O023365@homebrew.trpz.com> To: Dorothy.Gellert@nokia.com Cc: capwap@frascone.com, mmani@avaya.com, bwijnen@lucent.com, david.kessens@nokia.com Subject: Re: [Capwap] CAPWAP Evaluation Team In-Reply-To: Your message of "Sat, 11 Jun 2005 23:57:25 PDT." <893AE265F4ADF94AB7FB26D31A788E410C11CF@mvebe101.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23363.1118765379.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 14 Jun 2005 09:09:39 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Hi Dorothy, Paul asked if we could "mix and match" and Mani said, "Such considerations are welcome...mix-n-match of quality features is always possible if the WG feels so." Your response seemed more directed to the stage of the process at that time-- selecting protocols to evaluate-- and not to the process now-- evaluating the protocols selected. But you did say, "if one protocol is not accepted for evaluation as a baseline protocol, certainly portions of that protocol can be submitted to the WG to better address the objectives." So assuming the "not accepted for evaluation" implies "not acceptable after evaluation" I still don't see where you're coming up with only the two possible outcomes you mentioned below. So let me ask Paul's question once more. Is it possible for the evaluation team to mix-and-match and come up with some new baseline protocol that is the result of mixing-and-matching? The thread you directed me implies the answer is "yes". But if that's the case then how come you're saying that the outcome will be that the evaulation "may select one protocol" or it may select "one protocol with specific objectives met by other protocols."? Where are you coming up with this "one protocol" directive? Surely there is another possibility: that no one protocol is selected but features from more than one are combined to create a baseline protocol that does not resemble _any_ of the candidates being evaluated. Dan. On Sat, 11 Jun 2005 23:57:25 PDT you wrote > Dear Dan- > > Most recently Mani and I both responded to a email Paul Lambert sent to the l >ist on 4/25/05, Subject: RE: [Capwap] Selecting Protocols to evaluate, where >he asks if we can "mix and match sections from each protocol". Mani replied o >n 4/26, and I replied on 5/2. > > Also, during the IETF face to face meetings we have discussed this topic duri >ng milestone review. That is why we have described the chosen protocol as a " >base" protocol for CAPWAP. > > As for the informational RFC, I'll discuss your concerns with the ADs. Howev >er, the intent is to evaluate the proposals and make a recommendation for the >CAPWAP protocol. Work will progress along these lines. > > Regards, > Dorothy > > > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > Behalf Of ext Dan Harkins > Sent: Friday, June 10, 2005 9:29 PM > To: Gellert Dorothy (Nokia-ES/MtView) > Cc: capwap@frascone.com; mmani@avaya.com; bwijnen@lucent.com; Kessens > David (Nokia-NET/MtView) > Subject: Re: [Capwap] CAPWAP Evaluation Team > > > Hi Dorothy, > > You're saying that there are 2 possibilities: one protocol, periodfullstop; > or, one protocol that needs to incorporate some features from other protocols >. > > I don't recall ever seeing you (plural, or even singular) state that before >. > Can you please point out when that was? > > I was under the impression that the result could be what you state and > also the possibility that no single protocol would be selected but that > some hybrid that combines features from several of the candidates could > result in an acceptable protocol. Or possibly (although doubtful) no protocol > would be satisfactory. > > I'm concerned that you are giving guidance to this new team that does > not originate from the working group. > > Also, you listed September 2005 as a date to submit a draft to the IESG > as an Informational RFC. Per RFC2026 and Informational RFC "is published for > the general information of the Internet community, and does not represent an > Internet community consensus or recommendation." Given that it won't > represent any consensus or recommentation how can it be used to select > one or more of the candidate protocols? > > thanks, > > Dan. > > > On Fri, 10 Jun 2005 19:20:45 PDT you wrote > > Hi All- > > > > Thanks to everyone who volunteered for editorship of the CAPWAP Evaluation >dr > >aft. The Chairs and ADs have selected a team of evaluators, based on parti >ci > >pation on the list and the WG. The team is as follows: > > > > Darren Loher (Roving Planet), Lead Editor > > David Nelson (Enterasys), Lead for Evaluation Process > > Behcet Sarikaya (UofBC) > > Oleg Volinsky (Colubris) > > > > David Nelson has participated in a similar protocol evaluation process in t >he > > AAA WG, and we are lucky to have his experience on the team to benefit our >ev > >olution. > > > > The milestones for the CAPWAP evaluation draft are as follows: > > > > July 2005: Issue first Internet-Draft of CAPWAP Evaluation > Draft > > (00 draft deadline to repository is July 8th) > > August 2005: WGLC for CAPWAP Evaluation Draft. > > September 2005: Submit CAPWAP Evaluation Draft to IESG as Informational > > RFC. > > > > The evaluation draft will be based on the WG consensus, self-evaluations an >d > >the previous WG drafts. > > We expect the first draft will have a TBD as the recommended Protocol for C >AP > >WAP. > > > > As we have stated before, the final evaluation may select one protocol for >th > >e CAPWAP protocol, or the recommendation may be one protocol, with specific >ob > >jectives met by other protocols. > > > > Congratulations to the Evaluation team! > > > > Best Regards, > > Dorothy and Mani > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From luncher@didamail.com Tue Jun 14 14:18:05 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14189; Tue, 14 Jun 2005 14:18:05 -0400 (EDT) Date: Tue, 14 Jun 2005 14:18:05 -0400 (EDT) From: luncher@didamail.com Message-Id: <200506141818.OAA14189@ietf.org> Received: from host-217-172-248-106.lodz.mm.pl ([217.172.248.106]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DiGHY-0002zL-Lh; Tue, 14 Jun 2005 14:37:08 -0400 Received: from JMDIQyunm.com (EHLO asulw-a.it'd.JB.elm.net) aspirate by mail.mtk.nao.ac.jp (7.6[2 X-Spam-Score: 5.5 (+++++) X-Spam-Flag: YES X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From capwap-admin@frascone.com Tue Jun 14 15:05:11 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19406 for ; Tue, 14 Jun 2005 15:05:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A7FDB204BC; Tue, 14 Jun 2005 15:05:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DAAC92043C; Tue, 14 Jun 2005 15:05:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7B2D82043C for ; Tue, 14 Jun 2005 15:04:18 -0400 (EDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.192]) by mail.frascone.com (Postfix) with ESMTP id 6E97F2038C for ; Tue, 14 Jun 2005 15:04:15 -0400 (EDT) Received: by wproxy.gmail.com with SMTP id 49so194830wri for ; Tue, 14 Jun 2005 12:04:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=o4qEVa5jVv/zdmdBrFQLI3P6MNgSndhAyoT1cSt7MqaRWEnFTUsDPGOakjLcTz3oK8VFUW286SKP2NWJubg8vBeb/UPTCB2r1GwSaWuts0fu63/z+Z8IVZfUiI9T7DiFjWm+I9mg+5wFpTuz9JWY7MRiSsD0KBNCbKLTp+f9AhM= Received: by 10.54.20.40 with SMTP id 40mr181031wrt; Tue, 14 Jun 2005 12:04:15 -0700 (PDT) Received: by 10.54.19.19 with HTTP; Tue, 14 Jun 2005 12:04:15 -0700 (PDT) Message-ID: <985218920506141204683a8fc6@mail.gmail.com> From: Suresh Satapati Reply-To: Suresh Satapati To: James Kempf Subject: Re: [Capwap] NAT traversal objective - take II Cc: Pat Calhoun , "Sadot, Emek (Emek)" , capwap@frascone.com In-Reply-To: <049801c570f6$daf5ba50$016115ac@dcml.docomolabsusa.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200506141321.j5EDLZlq002721@sj-core-5.cisco.com> <049801c570f6$daf5ba50$016115ac@dcml.docomolabsusa.com> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 14 Jun 2005 12:04:15 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Should work, as long as data path doesn't traverse NATs at all or doesn't traverse different NATs.=20 However, I see this being too restrictive a scenario. I see and hear a lot= =20 about WTPs talking to different ACs, and those ACs doesn't need to be=20 behind the same NAT or the path between WTPs and ACs doesn't need to traverse the same NAT device. More I think about this, I feel it is better to leave this out, and=20 simply make a call to traversal solutions out there..=20 I do feel that a wording like "CAPWAP protocol must be transparent to NATs or must work with NAT traversal solutions", is important.=20 -Suresh On 6/14/05, James Kempf wrote: > Pat, >=20 > > So I would disagree with requiring that an AC can be behind a NAT. > > >=20 > I think the only problem should be if the AC is behind a NAT and the WTPs > aren't or the WTPs are behind a different NAT. How about if the AC and WT= Ps > are behind the same NAT? I think that should work, right? >=20 > jak >=20 >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Jun 14 23:30:12 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01106 for ; Tue, 14 Jun 2005 23:30:12 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0AAC22041F; Tue, 14 Jun 2005 23:30:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7D34720475; Tue, 14 Jun 2005 23:30:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 678EE20361 for ; Tue, 14 Jun 2005 23:29:15 -0400 (EDT) Received: from WV-MAILSRV2.strixsystems.com (unknown [208.179.69.254]) by mail.frascone.com (Postfix) with ESMTP id 45FF91FC75 for ; Tue, 14 Jun 2005 23:29:13 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57058.555D411D" Subject: RE: [Capwap] NAT traversal Message-ID: <542DAE1236ADDE45A5840C93FF1B4014CBCD01@wv-mailsrv2.strixsystems.com> Thread-Topic: RE: [Capwap] NAT traversal Thread-Index: AcVwWFMh1yT7Yc+CRMGYcJ/UssYU4g== From: "Matt Holdrege" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 13 Jun 2005 13:41:50 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C57058.555D411D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Speaking as the old NAT WG chair, please read and reference RFC 2663 and perhaps 3027 if you wish to engage in any formal NAT documentation exercises. Personally I think if the authors of the protocol draft understand the NAT problem (it's not that hard), they can write up a simple section in their document entitled "NAT Considerations".=20 -Matt ------_=_NextPart_001_01C57058.555D411D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Speaking as the old NAT WG chair, = please read and reference RFC 2663 and perhaps 3027 if you wish to engage in any = formal NAT documentation exercises.

Personally I think if the authors of the protocol draft understand the = NAT problem (it's not that hard), they can write up a simple section in = their document entitled "NAT Considerations".

-Matt

------_=_NextPart_001_01C57058.555D411D-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 15 08:17:14 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08459 for ; Wed, 15 Jun 2005 08:17:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DDEFF204CD; Wed, 15 Jun 2005 08:17:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8604F2049B; Wed, 15 Jun 2005 08:17:08 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B8F1B2044E for ; Wed, 15 Jun 2005 08:16:56 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id 6DD892049B for ; Wed, 15 Jun 2005 08:16:53 -0400 (EDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 15 Jun 2005 05:16:53 -0700 Received: from pacalhouwxp (sjc-vpn5-40.cisco.com [10.21.88.40]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5FCGYc2001896; Wed, 15 Jun 2005 05:16:49 -0700 (PDT) Message-Id: <200506151216.j5FCGYc2001896@sj-core-1.cisco.com> From: "Pat Calhoun" To: "'Sadot, Emek (Emek)'" , Subject: RE: [Capwap] Support for Traffic Separation MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_041F_01C57169.70075280" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVmtrsFJNprui8LSZKBEWJ0aGfIlQE1bbGQAXY8UlA= In-Reply-To: <5844A41F4E146044A2E8356C6328588008CB7BAB@nj7460avexu2.global.avaya.com> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 15 Jun 2005 05:16:30 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------=_NextPart_000_041F_01C57169.70075280 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit My apologies for the latency in my response. Yes, the LWAPP protocol supports what we refer to Local and Split MAC. In Split MAC, the user's traffic is tunneled between the WTP and the AC while in Local MAC the data is locally bridged. Draft 02 of the LWAPP draft does not include enough text to cover the Local MAC case, even though shipping LWAPP products do this today, but we will have this fixed up in -03. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _____ From: Sadot, Emek (Emek) [mailto:esadot@avaya.com] Sent: Tuesday, June 07, 2005 12:35 PM To: Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Pat, A question regarding section 2.1.2 Support for Traffic Separation - author's interpretation of Support for Traffic Separation: does LWAPP supports an architecture in which the DS is implemented at the WTP? (avoid tunneling data frames to a control entity). Regards, Emek _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun Sent: Wednesday, June 01, 2005 10:32 AM To: capwap@frascone.com Subject: [Capwap] LWAPP Self Evaluation draft posted yesterday All, As per the protocol submission rules laid out by the chairs, the authors of the LWAPP protocol submitted a self evaluation to the I-D draft editors yesterday. I have made the draft available at http://www.capwap.org/draft-calhoun-capwap-lwapp-objectives-comparison-00.tx t. Comments welcomed! Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ------=_NextPart_000_041F_01C57169.70075280 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
My apologies for the latency in my=20 response.
 
Yes, the LWAPP protocol supports what we refer = to Local and=20 Split MAC. In Split MAC, the user's traffic is tunneled between the = WTP and=20 the AC while in Local MAC the data is locally bridged. Draft 02 of the = LWAPP=20 draft does not include enough text to cover the Local MAC case, even = though=20 shipping LWAPP products do this today, but we will have this fixed = up in=20 -03.

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

 

From: Sadot, Emek (Emek)=20 [mailto:esadot@avaya.com]
Sent: Tuesday, June 07, 2005 = 12:35=20 PM
To: Pat Calhoun; capwap@frascone.com
Subject: = RE:=20 [Capwap] Support for Traffic Separation

Pat,
 
A=20 question regarding section 2.1.2 Support for=20 Traffic Separation - author's interpretation = of Support for Traffic Separation: = does LWAPP=20 supports an architecture in which the DS is implemented at the WTP? = (avoid=20 tunneling data frames to a control entity).
 
Regards,
Emek

From: capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Pat=20 Calhoun
Sent: Wednesday, June 01, 2005 10:32 = AM
To:=20 capwap@frascone.com
Subject: [Capwap] LWAPP Self Evaluation = draft=20 posted yesterday

All,
 
As = per the=20 protocol submission rules laid out by the chairs, the authors of the = LWAPP=20 protocol submitted a self evaluation to the I-D draft editors = yesterday. I=20 have made the draft available at http://www.capwap.org/draft-calhoun-capwap-lwapp-objectives-comp= arison-00.txt.
 
Comments=20 welcomed!
 

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

 
------=_NextPart_000_041F_01C57169.70075280-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 15 08:17:35 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08485 for ; Wed, 15 Jun 2005 08:17:34 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 00372204EA; Wed, 15 Jun 2005 08:17:33 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 31137204EC; Wed, 15 Jun 2005 08:17:24 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BA2A22049B for ; Wed, 15 Jun 2005 08:16:59 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id E009E2044E for ; Wed, 15 Jun 2005 08:16:57 -0400 (EDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 15 Jun 2005 05:16:57 -0700 X-IronPort-AV: i="3.93,200,1115017200"; d="scan'208"; a="278961015:sNHT33319968" Received: from pacalhouwxp (sjc-vpn5-40.cisco.com [10.21.88.40]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5FCGYc4001896 for ; Wed, 15 Jun 2005 05:16:53 -0700 (PDT) Message-Id: <200506151216.j5FCGYc4001896@sj-core-1.cisco.com> From: "Pat Calhoun" To: Subject: RE: [Capwap] Taxonomy Recommendations MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVtOhnDF7wSogXjSc25RD55TDTCAAEI74Sw In-Reply-To: <200506092127.j59LRtlq020932@sj-core-5.cisco.com> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 15 Jun 2005 05:16:30 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit All, I wanted to follow up on the draft that was sent last week, and explain some of the justification for this draft. When Inderpreet (co-author of the CAPWAP CTP submission), Bob O'Hara and I (co-authors of the CAPWAP LWAPP submission) discussed the differences between our respective approaches, it became clear that we did not have agreement on the definitions of Local and Split MAC. In re-reading the taxonomy specification, it became clear that while the taxonomy document lists the various approaches surveyed, it really did not provide a conclusion or recommendation. Therefore, the reader is left with no clear understanding the CAPWAP Working Group's definition of these two approaches. For instance, by following the letter of the taxonomy specification, one will observe that the split in functionality varies greatly from one implementation of Local MAC to another. The following is figure 9, taken directly from the document: Arch7 Arch8 Arch9 Arch10 Arch11 ----- ----- ----- ------ ------ Distribution Service AC AC WTP AC WTP Integration Service WTP WTP WTP WTP WTP Beacon Generation WTP WTP WTP WTP WTP Probe Response WTP WTP WTP WTP WTP Power mgmt Packet Buffering WTP WTP WTP WTP WTP Fragmentation/ Defragment. WTP WTP WTP WTP WTP Association Disassoc. Reassociation AC WTP WTP WTP WTP WME/11e -------------- classifying AC WTP scheduling WTP AC/WTP WTP WTP WTP queuing WTP WTP WTP WTP Authentication and Privacy -------------- 802.1x/EAP AC AC AC/WTP AC AC/WTP Keys Management AC AC WTP AC AC 802.11 Encryption/ Decryption WTP WTP WTP WTP WTP Figure 9: Mapping of 802.11 Functions for Local MAC Architecture Finally, the secion on Local MAC concludes with the following text: From Figure 7, Figure 8 and Figure 9, it is clear that differences among vendors in the Local MAC Architecture are relatively minor, and most of the functional mapping appears to be common across vendors. The issue with the above paragraph is that while the differences are restricted to specific functions (e.g., Distribution Service), these small differences will significantly change how products operate. In the case of Distribution Service, it will state whether traffic is tunneled to/from the WTP or not. Given the above, Inderpreet, Bob and I collaborated together in order to come to some agreement on what the differences between both approaches were. I think that the results of our extensive conversations resulted in the previously mentioned draft. I would urge the WG to take a look at this document and provide comments. At a minimum, we believe it would be in the best interest of the working group to at least discuss whether the taxonomy document is in need of some conclusions in order to set a frame of reference in the two main approaches. Thanks, Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun > Sent: Thursday, June 09, 2005 2:28 PM > To: capwap@frascone.com > Subject: [Capwap] Taxonomy Recommendations > > All, > > I wanted to announce the early availability of the CAPWAP > taxonomy recommendation draft that Bob O'Hara Inderpreet > Singh and I have been working on. It can be found at > http://www.capwap.org/draft-calhoun-capwap-taxonomy-recommenda > tion-00.txt. > > > Abstract > > The IETF's CAPWAP working group has documented various product > architectures and has categorized the Centralized WLAN > Architectures > into two main buckets: Split and Local MAC. While the document > contains very relevant and useful information, what it does is list > the architectural variants of these two buckets, but does not > unambiguously define either the Split MAC or Local MAC > architectures. > In order for CAPWAP to be successful, it is crucial for > the protocol > evaluation team, and the working group, to agree on unambiguous > terminology to describe these architectures. > > This document proposes terminology to unambiguously describe the > relevant architectures found in the taxonomy document, for the > purpose of initiating a discussion within the working group and to > allow the protocol evaluation work to come to a fruitful > conclusion. > We conclude in this document that the architectures are > very similar > and could be supported via a single protocol. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From wumi@eresmas.com Wed Jun 15 14:10:56 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10987; Wed, 15 Jun 2005 14:10:55 -0400 (EDT) Received: from smtp11.eresmas.com ([62.81.235.111]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiciX-0000TR-TK; Wed, 15 Jun 2005 14:34:27 -0400 Received: from [192.168.105.171] (helo=ma21.eresmas.com) by smtp11.eresmas.com with esmtp (Exim 4.51) id 1DicKQ-0005E7-8m; Wed, 15 Jun 2005 20:09:31 +0200 From: Miss Wumi Fatimo To: PattySpaulding@thefunnynyc.com Message-ID: <2ceb6fc2cee7b4.2cee7b42ceb6fc@ma21.eresmas.com> Date: Wed, 15 Jun 2005 18:09:32 GMT X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: en Subject: Thanks X-Accept-Language: en Content-Type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-Spam-Score: 7.4 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable =3Ctable border=3D0 width=3D=22100=25=22 cellpadding=3D=228=22 cellpaddi= ng=3D=228=22=3E=3Ctr=3E=3Ctd bgcolor=3D=22=23ffffff=22=3E=3CP=3EDear Sir/= Madam=2C=3CBR=3E=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp= =3B=26nbsp=3B=26nbsp=3B=26nbsp=3B My names are Miss=2E Wumi Fatimo Obasan= jo=2E I am one of the daughters of His Excellency=2C The President Of The= Federal Republic Of Nigeria=2E=3CBR=3E=26nbsp=3B=26nbsp=3B=26nbsp=3B=26n= bsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp= =3B I want to crave your indulgence taking a few minutes if your time=2E=3C= BR=3E=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B= =26nbsp=3B=26nbsp=3B=26nbsp=3B I understand that this letter might come t= o you as a surprise=2E I got your contact through the internet while sear= ching for an honest person who will assist me in a business transaction=2E= =3C/P=3E =3CP=3E=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbs= p=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B Due to my position in my fam= ily and my country=2C i had to contact you through email=2E My father=2C = His Excellency=2C The President=2C married many wives=2C seven official w= ives to be precise=2E And my mother is the sixth wife of His Excellency=2C= The President of The Federal Republic Of Nigeria=2E Due to the family pr= oblems between my father=2C The President and my mother =2C i am contacti= ng you=2E I and my mother has unanimously moved some Funds to Europe=2C i= n a Security Company since 2001=2E=3C/P=3E =3CP=3E=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbs= p=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B I am contacting you to assis= t us in applying for the release of this Funds=2E=3CBR=3E=26nbsp=3B=26nbs= p=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B= =26nbsp=3B=26nbsp=3B=26nbsp=3B Why we are doing this is because after the= tenor of my Father=2C The government must surely probe his governance=2E= =3CBR=3E=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nb= sp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B Indicate your int= erest by writing back to me as soon as possible =2EA handsome reward awai= ts you=2E=3CBR=3E=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbs= p=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B=26nbsp=3B Thanks=2C= =3C/P=3E =3CP=3E=26nbsp=3BYours=27 Faithfully=2C=3CBR=3E=26nbsp=3BWumi Fatimo=2C O= basanjo (Miss)=2E=3C/P=3E =3CP=3E=3CA href=3D=22mailto=3Acfc=40presidency=2Ecom=22=3Ecfc=40presiden= cy=2Ecom=3C/A=3E =3CBR=3E=26nbsp=3B=3C/P=3E =3CP=3E=26nbsp=3B=3CBR=3E=3C/P=3E=3C/td=3E=3C/tr=3E=3C/table=3E=3Cbr=3E=3C= br=3E=3Cspan style=3D=22font-family=3Amonospace=22=3E--------------------= ---------------------------------------------------=3C/span=3E=3Cbr=3E=3C= span style=3D=22font-family=3Averdana=3Bfont-size=3A11px=3B=22=3EEncuentr= a tu casa r=E1pida y c=F3modamente=2E Miles de viviendas te est=E1n esper= ando en =3Cbr=3E=3Ca href=3D=22http=3A//banner=2Eeresmas=2Ecom/adclick/CI= D=3D000064c2c858344d00000000/site=3DERESMAS/area=3DERESMAS=2ECORREO/aamsz= =3DPIE=5FWEBMAIL=22 target=3D=22=5Fblank=22=3Ehttp=3A//www=2Eportae=2Ecom= =3C/a=3E=3C/span=3E=3Cbr=3E From capwap-admin@frascone.com Wed Jun 15 14:15:11 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11736 for ; Wed, 15 Jun 2005 14:15:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E3CD9204DB; Wed, 15 Jun 2005 14:15:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7578A204AC; Wed, 15 Jun 2005 14:15:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D2BC7204AC for ; Wed, 15 Jun 2005 14:14:36 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id AD2EA202AD for ; Wed, 15 Jun 2005 14:14:32 -0400 (EDT) Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5FI2ZAK024867 for ; Wed, 15 Jun 2005 14:02:35 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5FI2QAK024631 for ; Wed, 15 Jun 2005 14:02:29 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Taxonomy Recommendations Message-ID: Thread-Topic: [Capwap] Taxonomy Recommendations Thread-Index: AcVtOhnDF7wSogXjSc25RD55TDTCAAAiOWVg From: "Mani, Mahalingam (Mahalingam)" To: "Pat Calhoun" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 15 Jun 2005 12:14:11 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Thanks for the joint effort (by authors of two candidate protocols for eval. as I see it) in making a case for clarification of terminology. If the changes and clarifications proposed are extensive - comments in form of I-D is useful to place-hold them. The WG should (especially the original taxonomy team authors) comment on these comments (draft): WG has approved the -06 version of the taxonomy draft. Two of the authors are in this as well :) It is also important to understand the implications, if any, (on Objectives draft) if WG agrees to any of the proposed clarifications. It may turn out to be transparent to the Objectives draft. This needs to happen soon for Objectives to freeze and let the evaluation team use a baselined version. [BTW: the taxonomy draft is in RFC editor's queue - actually just completed AUTH48]. -mani =3D=3D=3D=3D=3D=3D -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun Sent: Thursday, June 09, 2005 2:28 PM To: capwap@frascone.com Subject: [Capwap] Taxonomy Recommendations All, =20 I wanted to announce the early availability of the CAPWAP taxonomy recommendation draft that Bob O'Hara Inderpreet Singh and I have been working on. It can be found at http://www.capwap.org/draft-calhoun-capwap-taxonomy-recommendation-00.tx t. Abstract The IETF's CAPWAP working group has documented various product architectures and has categorized the Centralized WLAN Architectures into two main buckets: Split and Local MAC. While the document contains very relevant and useful information, what it does is list the architectural variants of these two buckets, but does not unambiguously define either the Split MAC or Local MAC architectures. In order for CAPWAP to be successful, it is crucial for the protocol evaluation team, and the working group, to agree on unambiguous terminology to describe these architectures. This document proposes terminology to unambiguously describe the relevant architectures found in the taxonomy document, for the purpose of initiating a discussion within the working group and to allow the protocol evaluation work to come to a fruitful conclusion. We conclude in this document that the architectures are very similar and could be supported via a single protocol. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 15 14:37:10 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13186 for ; Wed, 15 Jun 2005 14:37:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6FF7F204FB; Wed, 15 Jun 2005 14:37:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E9F02204CD; Wed, 15 Jun 2005 14:37:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 53829204CD for ; Wed, 15 Jun 2005 14:36:47 -0400 (EDT) Received: from smtp4.centerbeam.com (smtp4.centerbeam.com [63.120.115.248]) by mail.frascone.com (Postfix) with ESMTP id 59A84204AC for ; Wed, 15 Jun 2005 14:36:44 -0400 (EDT) Received: from cba0e2k00.CBA0.centerbeam.com ([64.95.101.25]) by smtp4.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Jun 2005 11:38:10 -0700 Received: from CBA0E2K06.CBA0.centerbeam.com ([64.95.101.40]) by cba0e2k00.CBA0.centerbeam.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 15 Jun 2005 11:36:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C571D9.2A37B5AC" Subject: RE: [Capwap] NAT traversal Message-ID: Thread-Topic: [Capwap] NAT traversal Thread-Index: AcVwWFMh1yT7Yc+CRMGYcJ/UssYU4gBa2CrQ From: "Darren Loher" To: "Matt Holdrege" , X-OriginalArrivalTime: 15 Jun 2005 18:36:33.0751 (UTC) FILETIME=[27AE6670:01C571D9] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 15 Jun 2005 11:36:37 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C571D9.2A37B5AC Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I like Matt's suggestion. "The CAPWAP protocol must include a section entitled NAT Considerations which will document how the protocol is intended to behave in a NAT environments described in RFC 2663." Or perhaps this could be a supplemental draft per protocol instead of a new additional section? =20 -Darren =20 =20 ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Matt Holdrege Sent: Monday, June 13, 2005 2:42 PM To: capwap@frascone.com Subject: RE: [Capwap] NAT traversal =20 Speaking as the old NAT WG chair, please read and reference RFC 2663 and perhaps 3027 if you wish to engage in any formal NAT documentation exercises. Personally I think if the authors of the protocol draft understand the NAT problem (it's not that hard), they can write up a simple section in their document entitled "NAT Considerations".=20 -Matt ------_=_NextPart_001_01C571D9.2A37B5AC Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

I like Matt’s suggestion. = ; “The CAPWAP protocol must include a section entitled NAT Considerations which = will document how the protocol is intended to behave in a NAT environments des= cribed in RFC 2663.”  Or perhaps this could be a supplemental draft p= er protocol instead of a new additional section?

 

-Darren

=

 

 

From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Matt Holdrege
Sent: Monday, June 13, 200= 5 2:42 PM
To: capwap@frascone.com Subject: RE: [Capwap] NAT traversal

 

Speaking as the old NAT WG chair, please read and reference RFC 2= 663 and perhaps 3027 if you wish to engage in any formal NAT documentation exercises.

Personally I think if the authors of the protocol draft understand the NA= T problem (it's not that hard), they can write up a simple section in their= document entitled "NAT Considerations".

-Matt

------_=_NextPart_001_01C571D9.2A37B5AC-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 15 16:20:18 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25018 for ; Wed, 15 Jun 2005 16:20:14 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 03F2C204DB; Wed, 15 Jun 2005 16:20:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1669F20418; Wed, 15 Jun 2005 16:20:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8B3ED20418 for ; Wed, 15 Jun 2005 16:19:22 -0400 (EDT) Received: from orsfmr002.jf.intel.com (fmr17.intel.com [134.134.136.16]) by mail.frascone.com (Postfix) with ESMTP id 7069F2036B for ; Wed, 15 Jun 2005 16:19:19 -0400 (EDT) Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j5FKJAOW021969; Wed, 15 Jun 2005 20:19:10 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j5FKIcix007046; Wed, 15 Jun 2005 20:19:08 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005061513190823684 ; Wed, 15 Jun 2005 13:19:08 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Jun 2005 13:19:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Taxonomy Recommendations Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE04BD84C9@orsmsx408> Thread-Topic: [Capwap] Taxonomy Recommendations Thread-Index: AcVtOhnDF7wSogXjSc25RD55TDTCAAAiOWVgAQXBbCAAAzh2cAAAIx2Q From: "Yang, Lily L" To: "Mani, Mahalingam (Mahalingam)" , "Pat Calhoun" Cc: X-OriginalArrivalTime: 15 Jun 2005 20:19:08.0247 (UTC) FILETIME=[7C0BF670:01C571E7] X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 15 Jun 2005 13:19:02 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi, Pat and Mani -- I have not read through the entire Taxonomy Recommendations document yet, but just reading through the first few pages, I believe the authors are correct in pointing out one of the "inconsistency" (error) in the taxonomy draft. There was a paragraph in the taxonomy draft Section 5.6: " The commonalities and differences between Local MAC and Split MAC are most clearly seen by comparing Figure 7 to Figure 10. The commonality is that 802.11 control frames are terminated at WTPs in both cases. The main difference between Local MAC and Split MAC is that the WTP terminates only the 802.11 control frames in the Split MAC, while the WTP may terminate all 802.11 frames in the Local MAC. An interesting consequence of this difference is that the Integration Service, which essentially refers to bridging between 802.11 and 802.3 frames, is implemented by the AC in the Split MAC, but can be part of either the AC or WTP in the Local MAC." The last sentence, as pointed out by Pat, Bob and Inderpreet's document, was incorrect. According to Figure 9, Integration Service, for all the parties classified as Local MAC, is implemented by WTP.=20 Given that we still have about 3 hours remaining in the authors' 48 hour window, I would like to send a note to RFC Editor suggesting the following sentence to replace the last sentence in the paragraph: "An interesting consequence of this difference is that the Integration Service, which essentially refers to bridging between 802.11 and 802.3 frames, is implemented by the AC in the Split MAC and by the WTP in the Local MAC, as shown in Figure 9 and Figure 12." Glaring as it is, I believe this error does not carry any far reaching implication to the entire document and hence it is bug we can fix right now. Regarding the comment from the authors that taxonomy draft lacks conclusion and recommendation and hence the motivation to take it further to clearly define what Local and Split MAC really mean in terms of functional split -- I think that is a fair comment -- Personally I was tempted to take that step in the taxonomy draft with the intention to help the WG moving forward, but as the editor of the draft, I received clear instruction from the chairs and the WG that a taxonomy only goes so far to "document" the reality of the market, not to "define" any architectures. So the draft deliberately didn't go far into making any specific functional split recommendation. As I advocated in both July and Nov IETF meeting last year, I believe there is indeed a gap between taxonomy draft and objective draft -- the WG needs a clear definition of the functional split for Local, especially Split MAC, but that is not the charter of either taxonomy draft or Objective draft. Some people have the illusion that IEEE 802.11 (specifically the APF ad hoc group) will provide such definition. The clear answer there is NO, IEEE would not do that. It is up to us in this group to agree on the split and move on. So if indeed this Taxonomy Recommendation draft fulfills this purpose, I personally believe it is a very necessary step to take in order to move forward. However, as I said, I have not reviewed the entire document yet and so I would reserve until then to offer any further comments. But I do want to fix the error in Section 5.6 in Taxonomy draft NOW.=20 Lily -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Mani, Mahalingam (Mahalingam) Sent: Wednesday, June 15, 2005 11:14 AM To: Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Taxonomy Recommendations Thanks for the joint effort (by authors of two candidate protocols for eval. as I see it) in making a case for clarification of terminology. If the changes and clarifications proposed are extensive - comments in form of I-D is useful to place-hold them. The WG should (especially the original taxonomy team authors) comment on these comments (draft): WG has approved the -06 version of the taxonomy draft. Two of the authors are in this as well :) It is also important to understand the implications, if any, (on Objectives draft) if WG agrees to any of the proposed clarifications. It may turn out to be transparent to the Objectives draft. This needs to happen soon for Objectives to freeze and let the evaluation team use a baselined version. [BTW: the taxonomy draft is in RFC editor's queue - actually just completed AUTH48]. -mani =3D=3D=3D=3D=3D=3D -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun Sent: Thursday, June 09, 2005 2:28 PM To: capwap@frascone.com Subject: [Capwap] Taxonomy Recommendations All, =20 I wanted to announce the early availability of the CAPWAP taxonomy recommendation draft that Bob O'Hara Inderpreet Singh and I have been working on. It can be found at http://www.capwap.org/draft-calhoun-capwap-taxonomy-recommendation-00.tx t. Abstract The IETF's CAPWAP working group has documented various product architectures and has categorized the Centralized WLAN Architectures into two main buckets: Split and Local MAC. While the document contains very relevant and useful information, what it does is list the architectural variants of these two buckets, but does not unambiguously define either the Split MAC or Local MAC architectures. In order for CAPWAP to be successful, it is crucial for the protocol evaluation team, and the working group, to agree on unambiguous terminology to describe these architectures. This document proposes terminology to unambiguously describe the relevant architectures found in the taxonomy document, for the purpose of initiating a discussion within the working group and to allow the protocol evaluation work to come to a fruitful conclusion. We conclude in this document that the architectures are very similar and could be supported via a single protocol. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 15 16:50:15 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05653 for ; Wed, 15 Jun 2005 16:50:14 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 89BF220510; Wed, 15 Jun 2005 16:50:13 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8335B204DB; Wed, 15 Jun 2005 16:50:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4009F204DB for ; Wed, 15 Jun 2005 16:49:42 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id E3EF720418 for ; Wed, 15 Jun 2005 16:49:39 -0400 (EDT) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5FKlBdd001088 for ; Wed, 15 Jun 2005 16:47:11 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5FKl8dd001010 for ; Wed, 15 Jun 2005 16:47:09 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C571EB.BD26226C" Subject: RE: [Capwap] Support for Traffic Separation Message-ID: <5844A41F4E146044A2E8356C6328588008D9125F@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] Support for Traffic Separation Thread-Index: AcVmtrsFJNprui8LSZKBEWJ0aGfIlQE1bbGQAXY8UlAAGRB+QA== From: "Sadot, Emek (Emek)" To: "Pat Calhoun" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 15 Jun 2005 16:49:35 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C571EB.BD26226C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pat, =20 Thanks for your response though it didn't address the issue I was trying to raise. The problem was at my end - rereading my question I realize I wasn't clear enough. My apologies. Let me rephrase my concern though this time in a suggestion manner (rather then challenging specific proposed protocol). =20 In my opinion the CAPWAP protocol shouldn't tie bridging the user's data traffic function to a specific architecture (split or local) and be flexible enough to accommodate all four permutations: Split / MAC & bridging at AC / WTP. As part of the initial configuration phase the AC shall instruct the WTP to either locally bridge data traffic or tunnel to an AC.=20 =20 Regards, Emek _____ =20 From: Pat Calhoun [mailto:pcalhoun@cisco.com]=20 Sent: Wednesday, June 15, 2005 2:17 PM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation My apologies for the latency in my response. =20 Yes, the LWAPP protocol supports what we refer to Local and Split MAC. In Split MAC, the user's traffic is tunneled between the WTP and the AC while in Local MAC the data is locally bridged. Draft 02 of the LWAPP draft does not include enough text to cover the Local MAC case, even though shipping LWAPP products do this today, but we will have this fixed up in -03. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 _____ =20 From: Sadot, Emek (Emek) [mailto:esadot@avaya.com]=20 Sent: Tuesday, June 07, 2005 12:35 PM To: Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation =09 =09 Pat, =20 A question regarding section 2.1.2 Support for Traffic Separation - author's interpretation of Support for Traffic Separation: does LWAPP supports an architecture in which the DS is implemented at the WTP? (avoid tunneling data frames to a control entity). =20 Regards, Emek _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun Sent: Wednesday, June 01, 2005 10:32 AM To: capwap@frascone.com Subject: [Capwap] LWAPP Self Evaluation draft posted yesterday =09 =09 All, =20 As per the protocol submission rules laid out by the chairs, the authors of the LWAPP protocol submitted a self evaluation to the I-D draft editors yesterday. I have made the draft available at http://www.capwap.org/draft-calhoun-capwap-lwapp-objectives-comparison-0 0.txt . =20 Comments welcomed! =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ------_=_NextPart_001_01C571EB.BD26226C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Pat,
 
Thanks=20 for your response though it didn't address the issue I was trying = to raise.=20 The problem was at my end - rereading my question I = realize I=20 wasn't clear enough. My apologies. Let me rephrase my concern though = this time=20 in a suggestion manner (rather then challenging specific proposed=20 protocol).
 
In my=20 opinion the CAPWAP protocol shouldn't tie bridging the user's data = traffic=20 function to a specific architecture (split or local) and be = flexible=20 enough to accommodate all four permutations: Split / MAC & = bridging at AC / WTP.
As=20 part of the initial configuration phase the AC = shall instruct the=20 WTP to either locally bridge data traffic or tunnel to an AC.=20
 
Regards,
Emek

From: Pat Calhoun = [mailto:pcalhoun@cisco.com]=20
Sent: Wednesday, June 15, 2005 2:17 PM
To: Sadot, = Emek=20 (Emek); capwap@frascone.com
Subject: RE: [Capwap] Support for = Traffic=20 Separation

My apologies for the latency in my=20 response.
 
Yes, the LWAPP protocol supports what we refer = to Local and=20 Split MAC. In Split MAC, the user's traffic is tunneled between the = WTP and=20 the AC while in Local MAC the data is locally bridged. Draft 02 of the = LWAPP=20 draft does not include enough text to cover the Local MAC case, even = though=20 shipping LWAPP products do this today, but we will have this fixed = up in=20 -03.

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

 

From: Sadot, Emek (Emek)=20 [mailto:esadot@avaya.com]
Sent: Tuesday, June 07, 2005 = 12:35=20 PM
To: Pat Calhoun; capwap@frascone.com
Subject: = RE:=20 [Capwap] Support for Traffic Separation

Pat,
 
A=20 question regarding section 2.1.2 Support for=20 Traffic Separation - author's interpretation = of Support for Traffic Separation: = does LWAPP=20 supports an architecture in which the DS is implemented at the WTP? = (avoid=20 tunneling data frames to a control entity).
 
Regards,
Emek

From: capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Pat=20 Calhoun
Sent: Wednesday, June 01, 2005 10:32 = AM
To:=20 capwap@frascone.com
Subject: [Capwap] LWAPP Self Evaluation = draft=20 posted yesterday

All,
 
As = per the=20 protocol submission rules laid out by the chairs, the authors of the = LWAPP=20 protocol submitted a self evaluation to the I-D draft editors = yesterday. I=20 have made the draft available at http://www.capwap.org/draft-calhoun-capwap-lwapp-objectives-comp= arison-00.txt.
 
Comments=20 welcomed!
 

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

 
------_=_NextPart_001_01C571EB.BD26226C-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 15 17:29:10 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07907 for ; Wed, 15 Jun 2005 17:29:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 91EEC20510; Wed, 15 Jun 2005 17:29:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3EA2320509; Wed, 15 Jun 2005 17:29:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E590020509 for ; Wed, 15 Jun 2005 17:28:30 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id C3A98204DB for ; Wed, 15 Jun 2005 17:28:28 -0400 (EDT) Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5FLGaAK022662 for ; Wed, 15 Jun 2005 17:16:36 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5FLGZAK022644 for ; Wed, 15 Jun 2005 17:16:35 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C571F1.2A290819" Subject: RE: [Capwap] NAT traversal Message-ID: <5844A41F4E146044A2E8356C6328588008D9128A@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] NAT traversal Thread-Index: AcVwWFMh1yT7Yc+CRMGYcJ/UssYU4gBa2CrQAAtV+9A= From: "Sadot, Emek (Emek)" To: "Darren Loher" , "Matt Holdrege" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 15 Jun 2005 17:28:25 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C571F1.2A290819 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am supportive. =20 Emek _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Darren Loher Sent: Wednesday, June 15, 2005 1:37 PM To: Matt Holdrege; capwap@frascone.com Subject: RE: [Capwap] NAT traversal I like Matt's suggestion. "The CAPWAP protocol must include a section entitled NAT Considerations which will document how the protocol is intended to behave in a NAT environments described in RFC 2663." Or perhaps this could be a supplemental draft per protocol instead of a new additional section? =20 -Darren =20 =20 _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Matt Holdrege Sent: Monday, June 13, 2005 2:42 PM To: capwap@frascone.com Subject: RE: [Capwap] NAT traversal =20 Speaking as the old NAT WG chair, please read and reference RFC 2663 and perhaps 3027 if you wish to engage in any formal NAT documentation exercises. Personally I think if the authors of the protocol draft understand the NAT problem (it's not that hard), they can write up a simple section in their document entitled "NAT Considerations".=20 -Matt ------_=_NextPart_001_01C571F1.2A290819 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I am=20 supportive.
 
Emek

From: capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Darren=20 Loher
Sent: Wednesday, June 15, 2005 1:37 PM
To: = Matt=20 Holdrege; capwap@frascone.com
Subject: RE: [Capwap] NAT=20 traversal

I like = Matt’s=20 suggestion.  “The CAPWAP protocol must include a section = entitled NAT=20 Considerations which will document how the protocol is intended to = behave in a=20 NAT environments described in RFC 2663.”  Or perhaps this = could be a=20 supplemental draft per protocol instead of a new additional=20 section?

 

-Darren

 

 

From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Matt = Holdrege
Sent: Monday, June 13, 2005 2:42=20 PM
To:=20 capwap@frascone.com
Subject:=20 RE: [Capwap] NAT traversal

 

Speaking as the old NAT WG chair, please read = and=20 reference RFC 2663 and perhaps 3027 if you wish to engage in any formal = NAT=20 documentation exercises.

Personally I think if the authors of the = protocol draft understand the NAT problem (it's not that hard), they can = write=20 up a simple section in their document entitled "NAT Considerations".=20

-Matt

------_=_NextPart_001_01C571F1.2A290819-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 15 17:30:13 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08025 for ; Wed, 15 Jun 2005 17:30:12 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A40CC20525; Wed, 15 Jun 2005 17:30:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CA45B20510; Wed, 15 Jun 2005 17:30:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4726120529 for ; Wed, 15 Jun 2005 17:29:25 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id 4DEB020528 for ; Wed, 15 Jun 2005 17:29:21 -0400 (EDT) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5FLQrdd028792 for ; Wed, 15 Jun 2005 17:26:53 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5FLQqdd028748 for ; Wed, 15 Jun 2005 17:26:52 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] NAT traversal objective - take II Message-ID: <5844A41F4E146044A2E8356C6328588008D9128B@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] NAT traversal objective - take II Thread-Index: AcVwQl1GT4yI/UPOQcuCCQ69bUcp5AAoU83gAEFjfwA= From: "Sadot, Emek (Emek)" To: "Pat Calhoun" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 15 Jun 2005 17:29:19 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Pat, Let me start by saying that my initial concern was related to WTP being deployed at the private sector of a NAT device in oppose to the AC, but I believe we should exercises caution when ruling out the latter, especially with regard to the motivation you provided which outlined protocol implementation issue rather then addressing the question: whether or not "AC behind NAT" is a feasible configuration. On a (partly) different note: I would appreciate if you could elaborate (though I acknowledge it's not tightly coupled with the CAPWAP protocol) how an AC(s) suppose to learn the IP address of the other device(s) to which user's data traffic should be tunneled by the WTP? what purpose such devices serves? and if several entities exists in a system how an AC determine to which one to directed the user's data traffic of "its" WTPs? Regards, Emek -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@cisco.com]=20 Sent: Tuesday, June 14, 2005 3:22 PM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] NAT traversal objective - take II Having thought about this some more, it appears that the requirements for NAT conflict with the desire to split the control and the data path. While I agree that a WTP can be behind a NAT, I don't believe that an AC can. The reason being that in order to achieve the control/data path split objective, where data goes to one device and control goes to another, it is required that the protocol allows the AC to communicate the data path IP address - and the inclusion of such an IP address in the protocol implicitely breaks NAT traversal. So I would disagree with requiring that an AC can be behind a NAT. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) > Sent: Monday, June 13, 2005 11:05 AM > To: capwap@frascone.com > Subject: [Capwap] NAT traversal objective - take II >=20 > I would like to propose adding below NAT traversal requirement=20 > following the last thread on the subject. >=20 >=20 > Classification: Architecture > =20 > Description: > The CAPWAP protocol doesn't pose any restriction on the environment=20 > where the AC and the WTP will be deployed and which devices facilitate > communication between the two. > Therefore traversing NAT device cannot be ruled out and the CAPWAP=20 > protocol should be robusted against such a scenario. >=20 > Protocol Requirement: > CAPWAP protocol shall accommodate NAT traversal scenario and in=20 > particular allow NAT device to manipulate layer 4 ports, take into=20 > consideration symmetric NAT behavior (allowing access from the public=20 > side only after session establish from the private side) and avoid=20 > peer identification based on entity (e.g. WTP, AC) IP addresses. >=20 > Motivation and Protocol Benefits: > Independence of WTP and AC on intermediate devices and extending=20 > deployment topologies and variance. A service provider connecting=20 > their AC to their customer's WTP across a NAT device is an example of=20 > potential deployment scenario. >=20 > Relation to Problem Statement: > This requirement is based on WG discussions that have determined to be > important for CAPWAP. >=20 >=20 > Emek >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 15 22:10:15 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01611 for ; Wed, 15 Jun 2005 22:10:15 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DBD3220509; Wed, 15 Jun 2005 22:10:14 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9D3A420513; Wed, 15 Jun 2005 22:10:09 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E131A20505 for ; Wed, 15 Jun 2005 22:09:06 -0400 (EDT) Received: from smtp015.mail.yahoo.com (smtp015.mail.yahoo.com [216.136.173.59]) by mail.frascone.com (Postfix) with SMTP id 0DBFA204DB for ; Wed, 15 Jun 2005 22:09:04 -0400 (EDT) Received: (qmail 15150 invoked from network); 16 Jun 2005 02:09:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:Message-ID:Date:From:Reply-To:User-Agent:X-Accept-Language:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=WwYbHdiJ9RgX4GZ5GOEYut1vWMXR2a1QAF7Vs3rcUXq2CYu7AS/1e94MRGQAAoPNYMHkqQWH2IXG1F6eFW6HDP3qvXLsMoehKMo6UldGBUmlyWv7infMTstNZHixbGL/EfbPDUwpv8W2bZncAhVW2nLrj0S06f80+y7VIp4Vl0M= ; Received: from unknown (HELO ?129.94.135.189?) (behcetsarikaya@129.94.135.189 with plain) by smtp015.mail.yahoo.com with SMTP; 16 Jun 2005 02:09:03 -0000 Message-ID: <42B0DF3F.2030803@yahoo.com> From: Behcet Sarikaya Reply-To: sarikaya@ieee.org User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: capwap@frascone.com Subject: Re: [Capwap] SLAPP evaluation draft References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 15 Jun 2005 19:09:03 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Has anyone been able to access this draft? I could not. Thx. --behcet Partha Narasimhan wrote: > > The SLAPP evaluation draft has been submitted. It should show up in due > course at > http://www.ietf.org/internet-drafts/draft-narasimhan-capwap-slapp-evaluation-00.txt > > > On behalf of the authors, I would like to apologize for the delay in > submitting this draft. > > Thanks > partha > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 15 22:14:09 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04303 for ; Wed, 15 Jun 2005 22:14:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8114220529; Wed, 15 Jun 2005 22:14:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3D9B420513; Wed, 15 Jun 2005 22:14:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 15C9F20513 for ; Wed, 15 Jun 2005 22:13:16 -0400 (EDT) Received: from typhoon.trangosoft.com (unknown [209.82.51.154]) by mail.frascone.com (Postfix) with ESMTP id 1E99C20505 for ; Wed, 15 Jun 2005 22:13:14 -0400 (EDT) Received: from phantom-out.trangosoft.com ([136.157.233.22]) by 136.157.233.32 with trend_isnt_name_B; Wed, 15 Jun 2005 22:14:55 -0400 Received: from troll3.trangosoft.com (troll3.trangosoft.com [136.157.233.13]) by phantom-out.trangosoft.com (Postfix) with ESMTP id 63AE324FFE; Wed, 15 Jun 2005 21:50:11 -0400 (EDT) Received: by troll3.trangosoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Jun 2005 22:09:25 -0400 Message-ID: <1652EBA28502ED4393B9BC9B8A4B6013164234@mism121a.toronto.chantrynetworks.com> From: Inderpreet Singh To: sarikaya@ieee.org, capwap@frascone.com Subject: RE: [Capwap] SLAPP evaluation draft MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 15 Jun 2005 22:13:15 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Bechet - no - I have not been able to find it in the repository either. --- Inderpreet Singh -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Behcet Sarikaya Sent: Wednesday, June 15, 2005 10:09 PM To: capwap@frascone.com Subject: Re: [Capwap] SLAPP evaluation draft Has anyone been able to access this draft? I could not. Thx. --behcet Partha Narasimhan wrote: > > The SLAPP evaluation draft has been submitted. It should show up in due > course at > http://www.ietf.org/internet-drafts/draft-narasimhan-capwap-slapp-evaluation -00.txt > > > On behalf of the authors, I would like to apologize for the delay in > submitting this draft. > > Thanks > partha > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 16 00:27:11 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15102 for ; Thu, 16 Jun 2005 00:27:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E71382053A; Thu, 16 Jun 2005 00:27:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2F24320505; Thu, 16 Jun 2005 00:27:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0C8B020505 for ; Thu, 16 Jun 2005 00:26:07 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id AFA1F203A1 for ; Thu, 16 Jun 2005 00:26:05 -0400 (EDT) Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5G4EDAK014347 for ; Thu, 16 Jun 2005 00:14:13 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5G4ECAK014319 for ; Thu, 16 Jun 2005 00:14:12 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5722B.818D1B49" Message-ID: Thread-Topic: Important Note: All Authors of Candidate Protocol Thread-Index: AcVyK34/MkqYZrMeQZK2Yo7hdm8eig== X-Priority: 1 Priority: Urgent Importance: high From: "Mani, Mahalingam (Mahalingam)" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Important Note: All Authors of Candidate Protocol Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 15 Jun 2005 22:26:03 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C5722B.818D1B49 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The evaluation team is in place and met for the first time today. =20 The Objectives draft authors are expected to deliver a revision reflecting the WG consensus on Friday (6/17). While the revision goes through the customary review process (we expect no impactive major revisions after this) and wends its way to WGLC and onwards; the evaluation team will use this version as baseline. =20 So far we have not frozen the candidate protocols from revising their drafts in consideration of meeting any (significant) changes to Objectives draft. Theoretically one does not preclude such changes to come about; but we believe this is the right point to do so in an optimistic approach to parallelism and moving the WG milestones forward albeit with all the delays so far. =20 Now - a deadline for revisions is flagged - a week from 6/17. Any revisions the protocol authors wish to make to their submissions please do so by 6//24/05. This will let the evaluation team do its work based on the baselined revisions of the Objectives and Protocol drafts. =20 The general guidelines for the evaluation process are along the lines used in evaluation of AAA protocol (refer RFC3127 ). =20 Hence - please note: 1. Baseline revision of Objectives draft for evaluation being submitted by 6/17 and available (may take a while to appear in ID repository). 2. Protocol revisions, if any, to be baselined by 6/24. If you do not expect to revise your draft submission between now and that date - do let the chairs know. We would notify the evaluation team to start their work on those. We request all authors to note and hold to this timeline (9pmPT of 6/24/05). 3. 6/24 is also the day for the authors to turn their comparison drafts in. that will be a soft-date. The hard date is 6/26/05 9pmPT. =20 We will be arranging for all comparison and protocol revisions to be accessible from the WG webpage . =20 Regards, -mani & Dorothy =3D=3D=3D=3D=3D=3D =20 ------_=_NextPart_001_01C5722B.818D1B49 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The evaluation team is in place and met for the first = time today.

 

The Objectives draft authors are expected to deliver = a revision reflecting the WG consensus on Friday = (6/17).

While the revision goes through the customary review = process (we expect no impactive major revisions after this) and wends its way to = WGLC and onwards; the evaluation team will use this version as = baseline.

 

So far we have not frozen the candidate protocols = from revising their drafts in consideration of meeting any (significant) = changes to Objectives draft. Theoretically one does not preclude such changes to = come about; but we believe this is the right point to do so in an optimistic approach to parallelism and moving the WG milestones forward albeit with = all the delays so far.

 

Now – a deadline for revisions is flagged = – a week from 6/17. Any revisions the protocol authors wish to make to their = submissions please do so by 6//24/05. This will let the evaluation team do its work = based on the baselined revisions of the Objectives and Protocol = drafts.

 

The general guidelines for the evaluation process are = along the lines used in evaluation of AAA protocol (refer RFC3127).<= o:p>

 

Hence – please = note:

  1. Baseline revision of = Objectives draft for evaluation being submitted by 6/17 and available (may = take a while to appear in ID repository).
  2. Protocol revisions, if = any, to be baselined by 6/24. If you do not expect to revise your draft = submission between now and that date – do let the chairs know. We would = notify the evaluation team to start their work on those. We request all = authors to note and hold to this timeline (9pmPT of = 6/24/05).
  3. 6/24 is also the day = for the authors to turn their comparison drafts in. that will be a = soft-date. The hard date is 6/26/05 9pmPT.

 

We will be arranging for all comparison and protocol revisions to be accessible from the WG webpage.

 

Regards,

-mani & Dorothy

=3D=3D=3D=3D=3D=3D

 

------_=_NextPart_001_01C5722B.818D1B49-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From scelsi@yebox.com Thu Jun 16 02:19:51 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13641; Thu, 16 Jun 2005 02:19:51 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dio67-0000gh-RO; Thu, 16 Jun 2005 02:43:32 -0400 Received: from [61.145.78.193] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1Dimnz-0002Pz-PW; Thu, 16 Jun 2005 01:21:03 -0400 Received: from tuesday-hrui.prlx.net (HELO dumbbell-yglz.net) by annihilate-ext.ttdra.net (8.9.0) with ESMTP id OLO12tkle; Thu, 16 Jun 2005 03:15:50 -0400 Date: Thu, 16 Jun 2005 09:17:50 +0200 From: "Cristina Riddle" Message-ID: <181.06e558d5.2a9VBO44@kjm.com> To: business@ietf.org Cc: calsch@ietf.org, cancer@ietf.org, capwap-archive@ietf.org, ccips@ietf.org, cclark@ietf.org, cdi-archive@ietf.org, cdir-admin@ietf.org, cfrg@ietf.org, cfrg-admin@ietf.org, cfrg-archive@ietf.org, cfrg-bounces@ietf.org, cfrg-web-archive@ietf.org Subject: Become one of the low rates X-Mailer: KMail [version 1.0.28] X-Spam-Score: 5.5 (+++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have been selected for our lowest rate in years... You could get over $420,000 for as little as $400 a month! Ba(d credit, Bank*ruptcy? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.cr3amier.net/signs.asp Best Regards, Paul Branch to be remov(ed: http://www.cr3amier.net/deletion.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From biliamee@access-one.com Thu Jun 16 03:36:54 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22287 for ; Thu, 16 Jun 2005 03:36:54 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DipIh-0006SA-5P for capwap-archive@ietf.org; Thu, 16 Jun 2005 04:00:36 -0400 Received: from cpe-68-174-130-248.nyc.res.rr.com ([68.174.130.248]) by mx2.foretec.com with smtp (Exim 4.24) id 1Dio0s-0005Mo-BV for capwap-archive@ietf.org; Thu, 16 Jun 2005 02:38:07 -0400 Message-ID: <39ba01c57243$df92b996$3947decd@access-one.com> From: "Richard K. Lee" To: capwap-archive@ietf.org Subject: =?iso-8859-1?B?Q2lhbGlzIC0gJDIuOTkvZG9zZQ==?= Date: Thu, 16 Jun 2005 07:18:41 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_1AFC5F03.377F857B" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 5.8 (+++++) X-Spam-Flag: YES X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 This is a multi-part message in MIME format. ------=_NextPart_000_0000_1AFC5F03.377F857B Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_E198698F.22003DB1" ------=_NextPart_001_0001_E198698F.22003DB1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Perfect erection Long duration of effects No prescription needed Only $2.99/$1.99 per dose (2 doses in each pill): CIALIS - http://www.pillsofdesire.com/sv/ VIAGRA - http://www.pillsofdesire.com/vt/ Delivered in a discreet package _________________________________________________________________________ To change your mail details, go here _________________________________________________________________________ ------=_NextPart_001_0001_E198698F.22003DB1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

Perfect erection
Long duration of effects
No prescription needed

Only $2.99/$1.99 per dose (2 doses in each pill):
CIALIS - http://www.pillsofdesire.com/sv/
VIAGRA - http://www.pillsofdesire.com/vt/

Delivered in a discreet package


_________________________________________________________________________
To change your mail details, go here
_________________________________________________________________________

------=_NextPart_001_0001_E198698F.22003DB1-- ------=_NextPart_000_0000_1AFC5F03.377F857B-- From capwap-admin@frascone.com Thu Jun 16 08:37:10 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14634 for ; Thu, 16 Jun 2005 08:37:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5FD5A2054D; Thu, 16 Jun 2005 08:37:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C8079204F1; Thu, 16 Jun 2005 08:37:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5E41A204F1 for ; Thu, 16 Jun 2005 08:36:35 -0400 (EDT) Received: from typhoon.trangosoft.com (unknown [209.82.51.154]) by mail.frascone.com (Postfix) with ESMTP id 84473204B0 for ; Thu, 16 Jun 2005 08:36:32 -0400 (EDT) Received: from phantom-out.trangosoft.com ([136.157.233.22]) by 136.157.233.32 with trend_isnt_name_B; Thu, 16 Jun 2005 08:36:55 -0400 Received: from troll3.trangosoft.com (troll3.trangosoft.com [136.157.233.13]) by phantom-out.trangosoft.com (Postfix) with ESMTP id 8F6B824FAC; Thu, 16 Jun 2005 08:12:08 -0400 (EDT) Received: by troll3.trangosoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Jun 2005 08:31:25 -0400 Message-ID: <1652EBA28502ED4393B9BC9B8A4B6013164241@mism121a.toronto.chantrynetworks.com> From: Michael Montemurro To: "Sadot, Emek (Emek)" , Pat Calhoun , capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5726F.D98C5F1E" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 16 Jun 2005 08:35:16 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5726F.D98C5F1E Content-Type: text/plain Emek, I just want to get clarification on your response. You believe there are four possibilities: 1) Split MAC - Bridge at WTP 2) Split MAC - Bridge at AC 3) Local MAC - Bridge at WTP 4) Local MAC - Bridge at AC I'd just like to understand how you envision case 1). What type of functionality would you envision would terminate at the AC? Could you be more specific on how you would handle WLAN management frames, security, and QoS in that case? Thanks, Mike Michael Montemurro Director, Advanced Technology and Standards Chantry Networks, A Siemens Company 1900 Minnesota Ct, Suite 125 Mississauga, ON, CANADA. T: 905-363-6413 F: 905-567-9900 E: michael.montemurro@siemens.com _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) Sent: June 15, 2005 4:50 PM To: Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Pat, Thanks for your response though it didn't address the issue I was trying to raise. The problem was at my end - rereading my question I realize I wasn't clear enough. My apologies. Let me rephrase my concern though this time in a suggestion manner (rather then challenging specific proposed protocol). In my opinion the CAPWAP protocol shouldn't tie bridging the user's data traffic function to a specific architecture (split or local) and be flexible enough to accommodate all four permutations: Split / MAC & bridging at AC / WTP. As part of the initial configuration phase the AC shall instruct the WTP to either locally bridge data traffic or tunnel to an AC. Regards, Emek _____ From: Pat Calhoun [mailto:pcalhoun@cisco.com] Sent: Wednesday, June 15, 2005 2:17 PM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation My apologies for the latency in my response. Yes, the LWAPP protocol supports what we refer to Local and Split MAC. In Split MAC, the user's traffic is tunneled between the WTP and the AC while in Local MAC the data is locally bridged. Draft 02 of the LWAPP draft does not include enough text to cover the Local MAC case, even though shipping LWAPP products do this today, but we will have this fixed up in -03. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _____ From: Sadot, Emek (Emek) [mailto:esadot@avaya.com] Sent: Tuesday, June 07, 2005 12:35 PM To: Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Pat, A question regarding section 2.1.2 Support for Traffic Separation - author's interpretation of Support for Traffic Separation: does LWAPP supports an architecture in which the DS is implemented at the WTP? (avoid tunneling data frames to a control entity). Regards, Emek _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun Sent: Wednesday, June 01, 2005 10:32 AM To: capwap@frascone.com Subject: [Capwap] LWAPP Self Evaluation draft posted yesterday All, As per the protocol submission rules laid out by the chairs, the authors of the LWAPP protocol submitted a self evaluation to the I-D draft editors yesterday. I have made the draft available at http://www.capwap.org/draft-calhoun-capwap-lwapp-objectives-comparison-00.tx t. Comments welcomed! Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ------_=_NextPart_001_01C5726F.D98C5F1E Content-Type: text/html
Emek,
 
I just want to get clarification on your response. You believe there are four possibilities:
 
    1) Split MAC - Bridge at WTP
    2) Split MAC - Bridge at AC
    3) Local MAC - Bridge at WTP
    4) Local MAC - Bridge at AC
 
I'd just like to understand how you envision case 1).  What type of functionality would you envision would terminate at the AC? Could you be more specific on how you would handle WLAN management frames, security, and QoS in that case?
 
Thanks,
 
    Mike
 

Michael Montemurro
Director, Advanced Technology and Standards
Chantry Networks, A Siemens Company
1900 Minnesota Ct, Suite 125
Mississauga, ON, CANADA.
T: 905-363-6413
F: 905-567-9900
E: michael.montemurro@siemens.com


From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek)
Sent: June 15, 2005 4:50 PM
To: Pat Calhoun; capwap@frascone.com
Subject: RE: [Capwap] Support for Traffic Separation

Pat,
 
Thanks for your response though it didn't address the issue I was trying to raise. The problem was at my end - rereading my question I realize I wasn't clear enough. My apologies. Let me rephrase my concern though this time in a suggestion manner (rather then challenging specific proposed protocol).
 
In my opinion the CAPWAP protocol shouldn't tie bridging the user's data traffic function to a specific architecture (split or local) and be flexible enough to accommodate all four permutations: Split / MAC & bridging at AC / WTP.
As part of the initial configuration phase the AC shall instruct the WTP to either locally bridge data traffic or tunnel to an AC.
 
Regards,
Emek

From: Pat Calhoun [mailto:pcalhoun@cisco.com]
Sent: Wednesday, June 15, 2005 2:17 PM
To: Sadot, Emek (Emek); capwap@frascone.com
Subject: RE: [Capwap] Support for Traffic Separation

My apologies for the latency in my response.
 
Yes, the LWAPP protocol supports what we refer to Local and Split MAC. In Split MAC, the user's traffic is tunneled between the WTP and the AC while in Local MAC the data is locally bridged. Draft 02 of the LWAPP draft does not include enough text to cover the Local MAC case, even though shipping LWAPP products do this today, but we will have this fixed up in -03.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

From: Sadot, Emek (Emek) [mailto:esadot@avaya.com]
Sent: Tuesday, June 07, 2005 12:35 PM
To: Pat Calhoun; capwap@frascone.com
Subject: RE: [Capwap] Support for Traffic Separation

Pat,
 
A question regarding section 2.1.2 Support for Traffic Separation - author's interpretation of Support for Traffic Separation: does LWAPP supports an architecture in which the DS is implemented at the WTP? (avoid tunneling data frames to a control entity).
 
Regards,
Emek

From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun
Sent: Wednesday, June 01, 2005 10:32 AM
To: capwap@frascone.com
Subject: [Capwap] LWAPP Self Evaluation draft posted yesterday

All,
 
 
Comments welcomed!
 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 
------_=_NextPart_001_01C5726F.D98C5F1E-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 16 08:54:10 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16384 for ; Thu, 16 Jun 2005 08:54:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A867A20558; Thu, 16 Jun 2005 08:54:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CF3FA204F1; Thu, 16 Jun 2005 08:54:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 85BD3204F1 for ; Thu, 16 Jun 2005 08:53:48 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id 61BB7204B0 for ; Thu, 16 Jun 2005 08:53:45 -0400 (EDT) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5GCpHdd015155 for ; Thu, 16 Jun 2005 08:51:17 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5GCpGdd015116 for ; Thu, 16 Jun 2005 08:51:16 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57272.6D293BED" Subject: RE: [Capwap] Support for Traffic Separation Message-ID: <5844A41F4E146044A2E8356C6328588008D913A8@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] Support for Traffic Separation Thread-Index: AcVyb+NMiWZ+QYnwQEu0hrVkigf1PgAAOZpQ From: "Sadot, Emek (Emek)" To: "Michael Montemurro" , "Pat Calhoun" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 16 Jun 2005 08:53:43 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C57272.6D293BED Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mike, =20 To make sure I am clear: by "bridge" I was referring to the Integration Services - bridging between 802.11 and 802.3. All management frames (security, QoS, etc.) should be handle by the AC. =20 Giving the operator / customer the freedom to run the IS function in AC or WTP is important and as far as I can tell doesn't break the CAPWAP model. Why it's important: well take #1 for example, if customer wishes to session to travel along the shorter path between peers, or maintain existing voice call when AC experience a failover and perform reboot (but new session or roaming obviously). =20 Emek _____ =20 From: Michael Montemurro [mailto:michael.montemurro@siemens.com]=20 Sent: Thursday, June 16, 2005 3:35 PM To: Sadot, Emek (Emek); Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Emek, =20 I just want to get clarification on your response. You believe there are four possibilities: =20 1) Split MAC - Bridge at WTP 2) Split MAC - Bridge at AC 3) Local MAC - Bridge at WTP 4) Local MAC - Bridge at AC =20 I'd just like to understand how you envision case 1). What type of functionality would you envision would terminate at the AC? Could you be more specific on how you would handle WLAN management frames, security, and QoS in that case? =20 Thanks, =20 Mike =20 Michael Montemurro Director, Advanced Technology and Standards Chantry Networks, A Siemens Company 1900 Minnesota Ct, Suite 125 Mississauga, ON, CANADA. T: 905-363-6413 F: 905-567-9900 E: michael.montemurro@siemens.com=20 _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) Sent: June 15, 2005 4:50 PM To: Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation =09 =09 Pat, =20 Thanks for your response though it didn't address the issue I was trying to raise. The problem was at my end - rereading my question I realize I wasn't clear enough. My apologies. Let me rephrase my concern though this time in a suggestion manner (rather then challenging specific proposed protocol). =20 In my opinion the CAPWAP protocol shouldn't tie bridging the user's data traffic function to a specific architecture (split or local) and be flexible enough to accommodate all four permutations: Split / MAC & bridging at AC / WTP. As part of the initial configuration phase the AC shall instruct the WTP to either locally bridge data traffic or tunnel to an AC.=20 =20 Regards, Emek _____ =20 From: Pat Calhoun [mailto:pcalhoun@cisco.com]=20 Sent: Wednesday, June 15, 2005 2:17 PM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation =09 =09 My apologies for the latency in my response. =20 Yes, the LWAPP protocol supports what we refer to Local and Split MAC. In Split MAC, the user's traffic is tunneled between the WTP and the AC while in Local MAC the data is locally bridged. Draft 02 of the LWAPP draft does not include enough text to cover the Local MAC case, even though shipping LWAPP products do this today, but we will have this fixed up in -03. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 _____ =20 From: Sadot, Emek (Emek) [mailto:esadot@avaya.com]=20 Sent: Tuesday, June 07, 2005 12:35 PM To: Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation =09 =09 Pat, =20 A question regarding section 2.1.2 Support for Traffic Separation - author's interpretation of Support for Traffic Separation: does LWAPP supports an architecture in which the DS is implemented at the WTP? (avoid tunneling data frames to a control entity). =20 Regards, Emek _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun Sent: Wednesday, June 01, 2005 10:32 AM To: capwap@frascone.com Subject: [Capwap] LWAPP Self Evaluation draft posted yesterday =09 =09 All, =20 As per the protocol submission rules laid out by the chairs, the authors of the LWAPP protocol submitted a self evaluation to the I-D draft editors yesterday. I have made the draft available at http://www.capwap.org/draft-calhoun-capwap-lwapp-objectives-comparison-0 0.txt . =20 Comments welcomed! =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ------_=_NextPart_001_01C57272.6D293BED Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Mike,
 
To=20 make sure I am clear: by "bridge" I was referring to the = Integration=20 Services -  bridging between 802.11 and 802.3.
All=20 management frames (security, QoS, etc.) should be handle by the=20 AC.
 
Giving=20 the operator / customer the freedom to run the IS function in AC or = WTP is=20 important and as far as I can tell doesn't break the CAPWAP=20 model.
Why=20 it's important: well take #1 for example, if customer = wishes to=20 session to travel along the shorter path between peers,=20 or maintain existing voice call when AC experience a = failover and=20 perform reboot (but new session or roaming=20 obviously).
 
Emek

From: Michael Montemurro=20 [mailto:michael.montemurro@siemens.com]
Sent: Thursday, June = 16, 2005=20 3:35 PM
To: Sadot, Emek (Emek); Pat Calhoun;=20 capwap@frascone.com
Subject: RE: [Capwap] Support for Traffic=20 Separation

Emek,
 
I just want to get clarification on your = response. You=20 believe there are four possibilities:
 
    1) Split MAC - Bridge at=20 WTP
    2) Split MAC - Bridge at=20 AC
    3) Local MAC - Bridge at=20 WTP
    4) Local MAC - Bridge at=20 AC
 
I'd just like to understand how you envision = case 1).=20  What type of functionality would you envision would terminate at = the AC?=20 Could you be more specific on how you would handle WLAN management = frames,=20 security, and QoS in that case?
 
Thanks,
 
    Mike
 

Michael Montemurro
Director, Advanced Technology = and=20 Standards
Chantry Networks, A Siemens Company
1900 Minnesota Ct, = Suite=20 125
Mississauga, ON, CANADA.
T: 905-363-6413
F: = 905-567-9900
E:=20 michael.montemurro@siemens.com


From: capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek=20 (Emek)
Sent: June 15, 2005 4:50 PM
To: Pat = Calhoun;=20 capwap@frascone.com
Subject: RE: [Capwap] Support for = Traffic=20 Separation

Pat,
 
Thanks for your response though it didn't address the = issue I was=20 trying to raise. The problem was at my end - rereading = my=20 question I realize I wasn't clear enough. My apologies. Let me = rephrase my=20 concern though this time in a suggestion manner (rather then = challenging=20 specific proposed protocol).
 
In=20 my opinion the CAPWAP protocol shouldn't tie bridging the user's = data=20 traffic function to a specific architecture (split or local) and = be=20 flexible enough to accommodate all four permutations: Split = / MAC=20 & bridging at AC / WTP.
As=20 part of the initial configuration phase the AC = shall instruct=20 the WTP to either locally bridge data traffic or tunnel to an AC. =
 
Regards,
Emek

From: Pat Calhoun = [mailto:pcalhoun@cisco.com]=20
Sent: Wednesday, June 15, 2005 2:17 PM
To: Sadot, = Emek=20 (Emek); capwap@frascone.com
Subject: RE: [Capwap] Support = for=20 Traffic Separation

My apologies for the latency in my=20 response.
 
Yes, the LWAPP protocol supports what we = refer to Local=20 and Split MAC. In Split MAC, the user's traffic is = tunneled between the=20 WTP and the AC while in Local MAC the data is locally bridged. Draft = 02 of the=20 LWAPP draft does not include enough text to cover the Local MAC case, = even=20 though shipping LWAPP products do this today, but we will have = this fixed=20 up in -03.

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

 

From: Sadot, Emek (Emek)=20 [mailto:esadot@avaya.com]
Sent: Tuesday, June 07, 2005 = 12:35=20 PM
To: Pat Calhoun; capwap@frascone.com
Subject: = RE:=20 [Capwap] Support for Traffic Separation

Pat,
 
A=20 question regarding section 2.1.2 Support for=20 Traffic Separation - author's interpretation = of Support for Traffic Separation: = does LWAPP=20 supports an architecture in which the DS is implemented at the WTP? = (avoid=20 tunneling data frames to a control entity).
 
Regards,
Emek

From: capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Pat=20 Calhoun
Sent: Wednesday, June 01, 2005 10:32 = AM
To:=20 capwap@frascone.com
Subject: [Capwap] LWAPP Self = Evaluation draft=20 posted yesterday

All,
 
As = per the=20 protocol submission rules laid out by the chairs, the authors of the = LWAPP=20 protocol submitted a self evaluation to the I-D draft editors = yesterday. I=20 have made the draft available at http://www.capwap.org/draft-calhoun-capwap-lwapp-objectives-comp= arison-00.txt.
 
Comments=20 welcomed!
 

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

 
------_=_NextPart_001_01C57272.6D293BED-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 16 08:54:34 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16462 for ; Thu, 16 Jun 2005 08:54:28 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5461C20567; Thu, 16 Jun 2005 08:54:26 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 76FB420561; Thu, 16 Jun 2005 08:54:22 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B31CD204F1 for ; Thu, 16 Jun 2005 08:53:55 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id C91CB204B0 for ; Thu, 16 Jun 2005 08:53:53 -0400 (EDT) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5GCpPdd015352 for ; Thu, 16 Jun 2005 08:51:25 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5GCpOdd015329 for ; Thu, 16 Jun 2005 08:51:24 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Taxonomy Recommendations Message-ID: <5844A41F4E146044A2E8356C6328588008D913A9@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] Taxonomy Recommendations Thread-Index: AcVtOhnDF7wSogXjSc25RD55TDTCAAEI74SwAEJJgXA= From: "Sadot, Emek (Emek)" To: "Pat Calhoun" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 16 Jun 2005 08:53:51 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable All, Let me start by saying that I agree with the authors conclusion that the protocol could / should support Local and Split MAC arch. However in my opinion the group should refrain from artificially articulate functionality-restriction around these two architectures buckets and avoid dive into a theoretical debate whether function X resides in the WTP or AC in each arch. I believe we better concentrate on dividing the functionality between AC and WTP and provide a mechanism for the AC to chose (based on WTP capabilities and operator commands) and instruct the WTP accordingly. Take for example the IS service: where it fits in Slit and Local - WTP or AC? I would disagree the authors conclusion (section 5 first bullet) w.r.t. bridging function, and believes we can, and should, allow the operator to chose. Since the spectrum of functionalities were outlined by APF SG and Taxonomy draft I would say we need to reach a consensus which functionality can be implemented at the AC and WTP (e.g. Integration Service) and which should solely reside at the AC( e.g. WTP Firmware or 802.1x authenticator).=20 If dependences among different functionalities are identified (what lead to Split vs. Local MAC arch in the first place) then, in my opinion, they need to be documented and impose restriction on customer configuration. Regards, Emek -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun Sent: Wednesday, June 15, 2005 3:17 PM To: capwap@frascone.com Subject: RE: [Capwap] Taxonomy Recommendations All, I wanted to follow up on the draft that was sent last week, and explain some of the justification for this draft.=20 When Inderpreet (co-author of the CAPWAP CTP submission), Bob O'Hara and I (co-authors of the CAPWAP LWAPP submission) discussed the differences between our respective approaches, it became clear that we did not have agreement on the definitions of Local and Split MAC. In re-reading the taxonomy specification, it became clear that while the taxonomy document lists the various approaches surveyed, it really did not provide a conclusion or recommendation. Therefore, the reader is left with no clear understanding the CAPWAP Working Group's definition of these two approaches. For instance, by following the letter of the taxonomy specification, one will observe that the split in functionality varies greatly from one implementation of Local MAC to another. The following is figure 9, taken directly from the document: Arch7 Arch8 Arch9 Arch10 Arch11 ----- ----- ----- ------ ------ Distribution Service AC AC WTP AC WTP Integration Service WTP WTP WTP WTP WTP Beacon Generation WTP WTP WTP WTP WTP Probe Response WTP WTP WTP WTP WTP Power mgmt Packet Buffering WTP WTP WTP WTP WTP Fragmentation/ Defragment. WTP WTP WTP WTP WTP Association Disassoc. Reassociation AC WTP WTP WTP WTP WME/11e -------------- classifying AC WTP scheduling WTP AC/WTP WTP WTP WTP queuing WTP WTP WTP WTP Authentication and Privacy -------------- 802.1x/EAP AC AC AC/WTP AC AC/WTP Keys Management AC AC WTP AC AC 802.11 Encryption/ Decryption WTP WTP WTP WTP WTP Figure 9: Mapping of 802.11 Functions for Local MAC Architecture Finally, the secion on Local MAC concludes with the following text: From Figure 7, Figure 8 and Figure 9, it is clear that differences among vendors in the Local MAC Architecture are relatively minor, and most of the functional mapping appears to be common across vendors. The issue with the above paragraph is that while the differences are restricted to specific functions (e.g., Distribution Service), these small differences will significantly change how products operate. In the case of Distribution Service, it will state whether traffic is tunneled to/from the WTP or not. Given the above, Inderpreet, Bob and I collaborated together in order to come to some agreement on what the differences between both approaches were. I think that the results of our extensive conversations resulted in the previously mentioned draft. I would urge the WG to take a look at this document and provide comments. At a minimum, we believe it would be in the best interest of the working group to at least discuss whether the taxonomy document is in need of some conclusions in order to set a frame of reference in the two main approaches. Thanks, Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun > Sent: Thursday, June 09, 2005 2:28 PM > To: capwap@frascone.com > Subject: [Capwap] Taxonomy Recommendations >=20 > All, > =20 > I wanted to announce the early availability of the CAPWAP taxonomy=20 > recommendation draft that Bob O'Hara Inderpreet Singh and I have been=20 > working on. It can be found at=20 > http://www.capwap.org/draft-calhoun-capwap-taxonomy-recommenda > tion-00.txt. >=20 >=20 > Abstract >=20 > The IETF's CAPWAP working group has documented various product > architectures and has categorized the Centralized WLAN=20 > Architectures > into two main buckets: Split and Local MAC. While the document > contains very relevant and useful information, what it does is list > the architectural variants of these two buckets, but does not > unambiguously define either the Split MAC or Local MAC=20 > architectures. > In order for CAPWAP to be successful, it is crucial for the=20 > protocol > evaluation team, and the working group, to agree on unambiguous > terminology to describe these architectures. >=20 > This document proposes terminology to unambiguously describe the > relevant architectures found in the taxonomy document, for the > purpose of initiating a discussion within the working group and to > allow the protocol evaluation work to come to a fruitful=20 > conclusion. > We conclude in this document that the architectures are very=20 > similar > and could be supported via a single protocol. >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit Cisco Systems >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 16 09:53:09 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21944 for ; Thu, 16 Jun 2005 09:53:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 340862055D; Thu, 16 Jun 2005 09:53:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 496EA204B0; Thu, 16 Jun 2005 09:53:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7940B2055A for ; Thu, 16 Jun 2005 09:52:08 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id 9B5B92046A for ; Thu, 16 Jun 2005 09:52:04 -0400 (EDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 16 Jun 2005 06:52:03 -0700 Received: from pacalhouwxp ([10.32.30.113]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5GDpv7l016303; Thu, 16 Jun 2005 06:51:57 -0700 (PDT) Message-Id: <200506161351.j5GDpv7l016303@sj-core-2.cisco.com> From: "Pat Calhoun" To: "'Yang, Lily L'" , "'Mani, Mahalingam (Mahalingam)'" Cc: Subject: RE: [Capwap] Taxonomy Recommendations MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVtOhnDF7wSogXjSc25RD55TDTCAAAiOWVgAQXBbCAAAzh2cAAAIx2QACSug4A= In-Reply-To: <2AF68A477DD44C4EBCBE338C24E7A9EE04BD84C9@orsmsx408> X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.30.113] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 16 Jun 2005 06:51:53 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Lily, I agree with your recommended change (and note the RFC editor will wait for your comments - even past the 48 hour window. Just make sure you inform them that you have changes and they will hold off). Further, I would like to stress the point made by Lily where there is a gap between the current taxonomy document and the objectives. The taxonomy recommendations is not intended to change any of the objectives per se (to address Mani's question), but it does attempt to provide a single frame of reference for the WG in our definitions of Split vs. Local MAC. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Yang, Lily L [mailto:lily.l.yang@intel.com] > Sent: Wednesday, June 15, 2005 1:19 PM > To: Mani, Mahalingam (Mahalingam); Pat Calhoun > Cc: capwap@frascone.com > Subject: RE: [Capwap] Taxonomy Recommendations > > > Hi, Pat and Mani -- > > I have not read through the entire Taxonomy Recommendations > document yet, but just reading through the first few pages, I > believe the authors are correct in pointing out one of the > "inconsistency" (error) in the taxonomy draft. There was a > paragraph in the taxonomy draft Section 5.6: > " The commonalities and differences between Local MAC and > Split MAC are > most clearly seen by comparing Figure 7 to Figure 10. The > commonality is that 802.11 control frames are terminated at WTPs in > both cases. The main difference between Local MAC and Split MAC is > that the WTP terminates only the 802.11 control frames in the Split > MAC, while the WTP may terminate all 802.11 frames in the > Local MAC. > An interesting consequence of this difference is that the > Integration > Service, which essentially refers to bridging between 802.11 and > 802.3 frames, is implemented by the AC in the Split MAC, but can be > part of either the AC or WTP in the Local MAC." > The last sentence, as pointed out by Pat, Bob and > Inderpreet's document, was incorrect. According to Figure 9, > Integration Service, for all the parties classified as Local > MAC, is implemented by WTP. > Given that we still have about 3 hours remaining in the > authors' 48 hour window, I would like to send a note to RFC > Editor suggesting the following sentence to replace the last > sentence in the paragraph: > "An interesting consequence of this difference is that the Integration > Service, which essentially refers to bridging between 802.11 and > 802.3 frames, is implemented by the AC in the Split MAC > and by the WTP in the Local MAC, as shown in Figure 9 and Figure 12." > > Glaring as it is, I believe this error does not carry any far > reaching implication to the entire document and hence it is > bug we can fix right now. > > Regarding the comment from the authors that taxonomy draft > lacks conclusion and recommendation and hence the motivation > to take it further to clearly define what Local and Split MAC > really mean in terms of functional split -- I think that is a > fair comment -- Personally I was tempted to take that step in > the taxonomy draft with the intention to help the WG moving > forward, but as the editor of the draft, I received clear > instruction from the chairs and the WG that a taxonomy only > goes so far to "document" the reality of the market, not to > "define" any architectures. So the draft deliberately didn't > go far into making any specific functional split recommendation. > > As I advocated in both July and Nov IETF meeting last year, I > believe there is indeed a gap between taxonomy draft and > objective draft -- the WG needs a clear definition of the > functional split for Local, especially Split MAC, but that is > not the charter of either taxonomy draft or Objective draft. > Some people have the illusion that IEEE 802.11 (specifically > the APF ad hoc group) will provide such definition. The clear > answer there is NO, IEEE would not do that. It is up to us in > this group to agree on the split and move on. So if indeed > this Taxonomy Recommendation draft fulfills this purpose, I > personally believe it is a very necessary step to take in > order to move forward. However, as I said, I have not > reviewed the entire document yet and so I would reserve until > then to offer any further comments. > > But I do want to fix the error in Section 5.6 in Taxonomy draft NOW. > > Lily > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Mani, > Mahalingam (Mahalingam) > Sent: Wednesday, June 15, 2005 11:14 AM > To: Pat Calhoun; capwap@frascone.com > Subject: RE: [Capwap] Taxonomy Recommendations > > Thanks for the joint effort (by authors of two candidate > protocols for eval. as I see it) in making a case for > clarification of terminology. > > If the changes and clarifications proposed are extensive - > comments in form of I-D is useful to place-hold them. > > The WG should (especially the original taxonomy team authors) > comment on these comments (draft): WG has approved the -06 > version of the taxonomy draft. Two of the authors are in this > as well :) > > It is also important to understand the implications, if any, > (on Objectives draft) if WG agrees to any of the proposed > clarifications. It may turn out to be transparent to the > Objectives draft. This needs to happen soon for Objectives to > freeze and let the evaluation team use a baselined version. > > [BTW: the taxonomy draft is in RFC editor's queue - actually > just completed AUTH48]. > > -mani > ====== > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun > Sent: Thursday, June 09, 2005 2:28 PM > To: capwap@frascone.com > Subject: [Capwap] Taxonomy Recommendations > > All, > > I wanted to announce the early availability of the CAPWAP > taxonomy recommendation draft that Bob O'Hara Inderpreet > Singh and I have been working on. It can be found at > http://www.capwap.org/draft-calhoun-capwap-taxonomy-recommenda > tion-00.tx > t. > > > Abstract > > The IETF's CAPWAP working group has documented various product > architectures and has categorized the Centralized WLAN > Architectures > into two main buckets: Split and Local MAC. While the document > contains very relevant and useful information, what it does is list > the architectural variants of these two buckets, but does not > unambiguously define either the Split MAC or Local MAC > architectures. > In order for CAPWAP to be successful, it is crucial for > the protocol > evaluation team, and the working group, to agree on unambiguous > terminology to describe these architectures. > > This document proposes terminology to unambiguously describe the > relevant architectures found in the taxonomy document, for the > purpose of initiating a discussion within the working group and to > allow the protocol evaluation work to come to a fruitful > conclusion. > We conclude in this document that the architectures are > very similar > and could be supported via a single protocol. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 16 09:54:09 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21996 for ; Thu, 16 Jun 2005 09:54:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A6DB2204F1; Thu, 16 Jun 2005 09:54:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E13262055A; Thu, 16 Jun 2005 09:54:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6FA1C20561 for ; Thu, 16 Jun 2005 09:53:35 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 027692055A for ; Thu, 16 Jun 2005 09:53:32 -0400 (EDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 16 Jun 2005 06:53:31 -0700 X-IronPort-AV: i="3.93,204,1115017200"; d="scan'208,217"; a="279512492:sNHT45395070" Received: from pacalhouwxp ([10.32.30.113]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5GDrQ7l017168; Thu, 16 Jun 2005 06:53:26 -0700 (PDT) Message-Id: <200506161353.j5GDrQ7l017168@sj-core-2.cisco.com> From: "Pat Calhoun" To: "'Sadot, Emek (Emek)'" , "'Darren Loher'" , "'Matt Holdrege'" , Subject: RE: [Capwap] NAT traversal MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05CD_01C57240.19D52680" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVwWFMh1yT7Yc+CRMGYcJ/UssYU4gBa2CrQAAtV+9AAIm0awA== In-Reply-To: <5844A41F4E146044A2E8356C6328588008D9128A@nj7460avexu2.global.avaya.com> X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.30.113] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 16 Jun 2005 06:53:22 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------=_NextPart_000_05CD_01C57240.19D52680 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit as am i Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) Sent: Wednesday, June 15, 2005 2:28 PM To: Darren Loher; Matt Holdrege; capwap@frascone.com Subject: RE: [Capwap] NAT traversal I am supportive. Emek _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Darren Loher Sent: Wednesday, June 15, 2005 1:37 PM To: Matt Holdrege; capwap@frascone.com Subject: RE: [Capwap] NAT traversal I like Matt's suggestion. "The CAPWAP protocol must include a section entitled NAT Considerations which will document how the protocol is intended to behave in a NAT environments described in RFC 2663." Or perhaps this could be a supplemental draft per protocol instead of a new additional section? -Darren _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Matt Holdrege Sent: Monday, June 13, 2005 2:42 PM To: capwap@frascone.com Subject: RE: [Capwap] NAT traversal Speaking as the old NAT WG chair, please read and reference RFC 2663 and perhaps 3027 if you wish to engage in any formal NAT documentation exercises. Personally I think if the authors of the protocol draft understand the NAT problem (it's not that hard), they can write up a simple section in their document entitled "NAT Considerations". -Matt ------=_NextPart_000_05CD_01C57240.19D52680 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
as am i
 

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

 

From: capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek=20 (Emek)
Sent: Wednesday, June 15, 2005 2:28 PM
To: = Darren=20 Loher; Matt Holdrege; capwap@frascone.com
Subject: RE: = [Capwap] NAT=20 traversal

I am=20 supportive.
 
Emek

From: capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Darren=20 Loher
Sent: Wednesday, June 15, 2005 1:37 PM
To: = Matt=20 Holdrege; capwap@frascone.com
Subject: RE: [Capwap] NAT=20 traversal

I like = Matt’s=20 suggestion.  “The CAPWAP protocol must include a section = entitled NAT=20 Considerations which will document how the protocol is intended to = behave in a=20 NAT environments described in RFC 2663.”  Or perhaps this = could be a=20 supplemental draft per protocol instead of a new additional=20 section?

 

-Darren

 

 

From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Matt = Holdrege
Sent: Monday, June 13, 2005 = 2:42=20 PM
To:=20 capwap@frascone.com
Subject:=20 RE: [Capwap] NAT traversal

 

Speaking as the old NAT WG chair, please = read and=20 reference RFC 2663 and perhaps 3027 if you wish to engage in any = formal NAT=20 documentation exercises.

Personally I think if the authors of = the=20 protocol draft understand the NAT problem (it's not that hard), they = can write=20 up a simple section in their document entitled "NAT Considerations".=20

-Matt

------=_NextPart_000_05CD_01C57240.19D52680-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 16 09:59:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22279 for ; Thu, 16 Jun 2005 09:59:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A0D4120572; Thu, 16 Jun 2005 09:59:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A9B992055A; Thu, 16 Jun 2005 09:59:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 785F22055A for ; Thu, 16 Jun 2005 09:58:17 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id CBFD5204B0 for ; Thu, 16 Jun 2005 09:58:14 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 16 Jun 2005 06:58:14 -0700 Received: from pacalhouwxp ([10.32.30.113]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5GDwBTc002561; Thu, 16 Jun 2005 06:58:12 -0700 (PDT) Message-Id: <200506161358.j5GDwBTc002561@sj-core-5.cisco.com> From: "Pat Calhoun" To: "'Michael Montemurro'" , "'Sadot, Emek (Emek)'" , Subject: RE: [Capwap] Support for Traffic Separation MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05D4_01C57240.C1E06830" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVycBVZCKVxg3scSxq6fXM8oyZE3gACvBow In-Reply-To: <1652EBA28502ED4393B9BC9B8A4B6013164241@mism121a.toronto.chantrynetworks.com> X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.30.113] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 16 Jun 2005 06:58:04 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------=_NextPart_000_05D4_01C57240.C1E06830 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Emek, Note that I disagree with the need for such complexity in the protocol, and my belief is this confusion stems from the lack of conclusion in the taxonomy draft. There is simply much more to tunneling traffic than just the Distribution and Integration Service, so one must actually be very specific in each case on where every function resides. My belief is that tunneling of user data is Split, while local bridging is Local. We have documented this in the Taxonomy Recommendations document, which I would urge you to comment on. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _____ From: Michael Montemurro [mailto:michael.montemurro@siemens.com] Sent: Thursday, June 16, 2005 5:35 AM To: Sadot, Emek (Emek); Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Emek, I just want to get clarification on your response. You believe there are four possibilities: 1) Split MAC - Bridge at WTP 2) Split MAC - Bridge at AC 3) Local MAC - Bridge at WTP 4) Local MAC - Bridge at AC I'd just like to understand how you envision case 1). What type of functionality would you envision would terminate at the AC? Could you be more specific on how you would handle WLAN management frames, security, and QoS in that case? Thanks, Mike Michael Montemurro Director, Advanced Technology and Standards Chantry Networks, A Siemens Company 1900 Minnesota Ct, Suite 125 Mississauga, ON, CANADA. T: 905-363-6413 F: 905-567-9900 E: michael.montemurro@siemens.com _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) Sent: June 15, 2005 4:50 PM To: Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Pat, Thanks for your response though it didn't address the issue I was trying to raise. The problem was at my end - rereading my question I realize I wasn't clear enough. My apologies. Let me rephrase my concern though this time in a suggestion manner (rather then challenging specific proposed protocol). In my opinion the CAPWAP protocol shouldn't tie bridging the user's data traffic function to a specific architecture (split or local) and be flexible enough to accommodate all four permutations: Split / MAC & bridging at AC / WTP. As part of the initial configuration phase the AC shall instruct the WTP to either locally bridge data traffic or tunnel to an AC. Regards, Emek _____ From: Pat Calhoun [mailto:pcalhoun@cisco.com] Sent: Wednesday, June 15, 2005 2:17 PM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation My apologies for the latency in my response. Yes, the LWAPP protocol supports what we refer to Local and Split MAC. In Split MAC, the user's traffic is tunneled between the WTP and the AC while in Local MAC the data is locally bridged. Draft 02 of the LWAPP draft does not include enough text to cover the Local MAC case, even though shipping LWAPP products do this today, but we will have this fixed up in -03. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _____ From: Sadot, Emek (Emek) [mailto:esadot@avaya.com] Sent: Tuesday, June 07, 2005 12:35 PM To: Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Pat, A question regarding section 2.1.2 Support for Traffic Separation - author's interpretation of Support for Traffic Separation: does LWAPP supports an architecture in which the DS is implemented at the WTP? (avoid tunneling data frames to a control entity). Regards, Emek _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun Sent: Wednesday, June 01, 2005 10:32 AM To: capwap@frascone.com Subject: [Capwap] LWAPP Self Evaluation draft posted yesterday All, As per the protocol submission rules laid out by the chairs, the authors of the LWAPP protocol submitted a self evaluation to the I-D draft editors yesterday. I have made the draft available at http://www.capwap.org/draft-calhoun-capwap-lwapp-objectives-comparison-00.tx t. Comments welcomed! Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ------=_NextPart_000_05D4_01C57240.C1E06830 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Emek,
 
Note that I disagree with the need for such = complexity in=20 the protocol, and my belief is this confusion stems from the lack of = conclusion=20 in the taxonomy draft. There is simply much more to tunneling traffic = than just=20 the Distribution and Integration Service, so one must actually be very = specific=20 in each case on where every function resides. My belief is that = tunneling of=20 user data is Split, while local bridging is Local. We have documented = this in=20 the Taxonomy Recommendations document, which I would urge you to comment = on.=20
 

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

 

From: Michael Montemurro=20 [mailto:michael.montemurro@siemens.com]
Sent: Thursday, = June 16,=20 2005 5:35 AM
To: Sadot, Emek (Emek); Pat Calhoun;=20 capwap@frascone.com
Subject: RE: [Capwap] Support for = Traffic=20 Separation

Emek,
 
I just want to get clarification on your = response. You=20 believe there are four possibilities:
 
   =20 1) Split MAC - = Bridge at=20 WTP
   =20 2) Split MAC - = Bridge at=20 AC
   =20 3) Local MAC - = Bridge at=20 WTP
    4) Local MAC - Bridge at=20 AC
 
I'd just like to understand how you envision = case 1).=20  What type of functionality would you envision would terminate at = the AC?=20 Could you be more specific on how you would handle WLAN management = frames,=20 security, and QoS in that case?
 
Thanks,
 
   =20 Mike
 

Michael Montemurro
Director, Advanced Technology = and=20 Standards
Chantry Networks, A Siemens Company
1900 Minnesota Ct, = Suite=20 125
Mississauga, ON, CANADA.
T: 905-363-6413
F: = 905-567-9900
E:=20 michael.montemurro@siemens.com


From: capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek=20 (Emek)
Sent: June 15, 2005 4:50 PM
To: Pat = Calhoun;=20 capwap@frascone.com
Subject: RE: [Capwap] Support for = Traffic=20 Separation

Pat,
 
Thanks for your response though it didn't address the = issue I=20 was trying to raise. The problem was at my end = - rereading my=20 question I realize I wasn't clear enough. My apologies. Let me = rephrase my=20 concern though this time in a suggestion manner (rather then=20 challenging specific proposed protocol).
 
In=20 my opinion the CAPWAP protocol shouldn't tie bridging the = user's data=20 traffic function to a specific architecture (split or local) = and be=20 flexible enough to accommodate all four permutations: = Split / MAC=20 & bridging at AC / WTP.
As=20 part of the initial configuration phase the AC = shall instruct=20 the WTP to either locally bridge data traffic or tunnel to = an AC.=20
 
Regards,
Emek

From: Pat Calhoun=20 [mailto:pcalhoun@cisco.com]
Sent: Wednesday, June 15, = 2005 2:17=20 PM
To: Sadot, Emek (Emek); = capwap@frascone.com
Subject:=20 RE: [Capwap] Support for Traffic Separation

My apologies for the latency in my=20 response.
 
Yes, the LWAPP protocol supports what we = refer to Local=20 and Split MAC. In Split MAC, the user's traffic is = tunneled between the=20 WTP and the AC while in Local MAC the data is locally bridged. Draft = 02 of=20 the LWAPP draft does not include enough text to cover the Local MAC = case,=20 even though shipping LWAPP products do this today, but we will = have=20 this fixed up in -03.

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

 

From: Sadot, Emek (Emek)=20 [mailto:esadot@avaya.com]
Sent: Tuesday, June 07, 2005 = 12:35=20 PM
To: Pat Calhoun; = capwap@frascone.com
Subject: RE:=20 [Capwap] Support for Traffic Separation

Pat,
 
A question regarding=20 section 2.1.2 Support for Traffic=20 Separation - author's interpretation = of Support for Traffic Separation:=20 does LWAPP supports an architecture in which the DS is = implemented at=20 the WTP? (avoid tunneling data frames to a control=20 entity).
 
Regards,
Emek

From: = capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Pat=20 Calhoun
Sent: Wednesday, June 01, 2005 10:32 = AM
To:=20 capwap@frascone.com
Subject: [Capwap] LWAPP Self = Evaluation=20 draft posted yesterday

All,
 
As per the=20 protocol submission rules laid out by the chairs, the authors of = the LWAPP=20 protocol submitted a self evaluation to the I-D draft editors = yesterday. I=20 have made the draft available at http://www.capwap.org/draft-calhoun-capwap-lwapp-objectives-comp= arison-00.txt.
 
Comments=20 welcomed!
 

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

=
 
------=_NextPart_000_05D4_01C57240.C1E06830-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 16 10:02:09 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22482 for ; Thu, 16 Jun 2005 10:02:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 144E120563; Thu, 16 Jun 2005 10:02:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2F692204AE; Thu, 16 Jun 2005 10:02:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CBAA3204B0 for ; Thu, 16 Jun 2005 10:01:49 -0400 (EDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail.frascone.com (Postfix) with ESMTP id EB5EA2055A for ; Thu, 16 Jun 2005 10:01:44 -0400 (EDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-4.cisco.com with ESMTP; 16 Jun 2005 07:01:44 -0700 Received: from pacalhouwxp ([10.32.30.113]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5GE1fQ3024953; Thu, 16 Jun 2005 07:01:42 -0700 (PDT) Message-Id: <200506161401.j5GE1fQ3024953@sj-core-1.cisco.com> From: "Pat Calhoun" To: "'Sadot, Emek (Emek)'" , Subject: RE: [Capwap] Taxonomy Recommendations MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVtOhnDF7wSogXjSc25RD55TDTCAAEI74SwAEJJgXAABSNLUA== In-Reply-To: <5844A41F4E146044A2E8356C6328588008D913A9@nj7460avexu2.global.avaya.com> X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.30.113] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 16 Jun 2005 07:01:34 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit To address your one comment: "However in my opinion the group should refrain from artificially articulate functionality-restriction around these two architectures buckets and avoid dive into a theoretical debate whether function X resides in the WTP or AC in each arch." I respectfully disagree. I believe that the only way that we can guarantee interoperability is by providing very clear guidelines, and not allow a checkboard approach where either the WTP or the AC can fulfill a function as it deems necessary. I believe that the alternative that you are proposing would take a considerable amount of time to get right, and would unnecessarily complicate the protocol. Let's define Split and Local and define a protocol that can address both. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Sadot, Emek (Emek) [mailto:esadot@avaya.com] > Sent: Thursday, June 16, 2005 5:54 AM > To: Pat Calhoun; capwap@frascone.com > Subject: RE: [Capwap] Taxonomy Recommendations > > All, > > Let me start by saying that I agree with the authors > conclusion that the protocol could / should support Local and > Split MAC arch. However in my opinion the group should > refrain from artificially articulate > functionality-restriction around these two architectures > buckets and avoid dive into a theoretical debate whether > function X resides in the WTP or AC in each arch. > > I believe we better concentrate on dividing the functionality > between AC and WTP and provide a mechanism for the AC to > chose (based on WTP capabilities and operator commands) and > instruct the WTP accordingly. > > Take for example the IS service: where it fits in Slit and > Local - WTP or AC? I would disagree the authors conclusion > (section 5 first bullet) w.r.t. bridging function, and > believes we can, and should, allow the operator to chose. > > Since the spectrum of functionalities were outlined by APF SG > and Taxonomy draft I would say we need to reach a consensus > which functionality can be implemented at the AC and WTP > (e.g. Integration > Service) and which should solely reside at the AC( e.g. WTP > Firmware or 802.1x authenticator). > If dependences among different functionalities are identified > (what lead to Split vs. Local MAC arch in the first place) > then, in my opinion, they need to be documented and impose > restriction on customer configuration. > > Regards, > Emek > > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun > Sent: Wednesday, June 15, 2005 3:17 PM > To: capwap@frascone.com > Subject: RE: [Capwap] Taxonomy Recommendations > > All, > > I wanted to follow up on the draft that was sent last week, > and explain some of the justification for this draft. > > When Inderpreet (co-author of the CAPWAP CTP submission), Bob > O'Hara and I (co-authors of the CAPWAP LWAPP submission) > discussed the differences between our respective approaches, > it became clear that we did not have agreement on the > definitions of Local and Split MAC. In re-reading the > taxonomy specification, it became clear that while the > taxonomy document lists the various approaches surveyed, it > really did not provide a conclusion or recommendation. > Therefore, the reader is left with no clear understanding the > CAPWAP Working Group's definition of these two approaches. > > For instance, by following the letter of the taxonomy > specification, one will observe that the split in > functionality varies greatly from one implementation of Local > MAC to another. The following is figure 9, taken directly > from the document: > > Arch7 Arch8 Arch9 Arch10 Arch11 > ----- ----- ----- ------ ------ > > Distribution > Service AC AC WTP AC WTP > > Integration > Service WTP WTP WTP WTP WTP > > Beacon > Generation WTP WTP WTP WTP WTP > > Probe > Response WTP WTP WTP WTP WTP > > Power mgmt > Packet > Buffering WTP WTP WTP WTP WTP > > Fragmentation/ > Defragment. WTP WTP WTP WTP WTP > > Association > Disassoc. > Reassociation AC WTP WTP WTP WTP > > WME/11e > -------------- > classifying AC WTP > > scheduling WTP AC/WTP WTP WTP WTP > > queuing WTP WTP WTP WTP > > Authentication > and Privacy > -------------- > 802.1x/EAP AC AC AC/WTP AC AC/WTP > > Keys > Management AC AC WTP AC AC > > 802.11 > Encryption/ > Decryption WTP WTP WTP WTP WTP > > Figure 9: Mapping of 802.11 Functions for Local MAC Architecture > > Finally, the secion on Local MAC concludes with the following text: > > From Figure 7, Figure 8 and Figure 9, it is clear that differences > among vendors in the Local MAC Architecture are relatively > minor, and > most of the functional mapping appears to be common across vendors. > > The issue with the above paragraph is that while the > differences are restricted to specific functions (e.g., > Distribution Service), these small differences will > significantly change how products operate. In the case of > Distribution Service, it will state whether traffic is > tunneled to/from the WTP or not. > > Given the above, Inderpreet, Bob and I collaborated together > in order to come to some agreement on what the differences > between both approaches were. > I think that the results of our extensive conversations > resulted in the previously mentioned draft. I would urge the > WG to take a look at this document and provide comments. At a > minimum, we believe it would be in the best interest of the > working group to at least discuss whether the taxonomy > document is in need of some conclusions in order to set a > frame of reference in the two main approaches. > > Thanks, > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > -----Original Message----- > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun > > Sent: Thursday, June 09, 2005 2:28 PM > > To: capwap@frascone.com > > Subject: [Capwap] Taxonomy Recommendations > > > > All, > > > > I wanted to announce the early availability of the CAPWAP taxonomy > > recommendation draft that Bob O'Hara Inderpreet Singh and I > have been > > working on. It can be found at > > http://www.capwap.org/draft-calhoun-capwap-taxonomy-recommenda > > tion-00.txt. > > > > > > Abstract > > > > The IETF's CAPWAP working group has documented various product > > architectures and has categorized the Centralized WLAN > > Architectures > > into two main buckets: Split and Local MAC. While the document > > contains very relevant and useful information, what it > does is list > > the architectural variants of these two buckets, but does not > > unambiguously define either the Split MAC or Local MAC > > architectures. > > In order for CAPWAP to be successful, it is crucial for the > > protocol > > evaluation team, and the working group, to agree on unambiguous > > terminology to describe these architectures. > > > > This document proposes terminology to unambiguously describe the > > relevant architectures found in the taxonomy document, for the > > purpose of initiating a discussion within the working > group and to > > allow the protocol evaluation work to come to a fruitful > > conclusion. > > We conclude in this document that the architectures are very > > similar > > and could be supported via a single protocol. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 16 10:14:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23940 for ; Thu, 16 Jun 2005 10:14:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 60EF320579; Thu, 16 Jun 2005 10:14:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 93440204B0; Thu, 16 Jun 2005 10:14:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B95E7204B0 for ; Thu, 16 Jun 2005 10:13:23 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id E9121204AE for ; Thu, 16 Jun 2005 10:13:21 -0400 (EDT) Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5GE1SAK023332 for ; Thu, 16 Jun 2005 10:01:29 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5GE1RAK023281 for ; Thu, 16 Jun 2005 10:01:27 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Taxonomy Recommendations Message-ID: Thread-Topic: [Capwap] Taxonomy Recommendations Thread-Index: AcVtOhnDF7wSogXjSc25RD55TDTCAAAiOWVgAQXBbCAAAzh2cAAAIx2QACOMOrA= From: "Mani, Mahalingam (Mahalingam)" To: "Yang, Lily L" , "Pat Calhoun" Cc: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 16 Jun 2005 08:13:18 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I have no objections to this 'bug-fix' if it can happen in time and has no author/WG objections. We can request the RFC Ed. to hold off. As for the other issue on split-MAC interpretation: The split-discussion is long overdue; and is worth having - to help evaluation as well. I think resolution of the discussion is important to arrive at the best approach to CAPWAP protocol accommodating/not split variants. History: We had clearly noted not to make any recommendations on what a split characteristic must be in the taxonomy. This has perhaps been argued many times in (taxonomy) design team and in IETF58-62 as well. There was no scope for us in the then charter to venture that way. When APF AHC initially started its work - the hope was it would offer enough information for CAPWAP to draw conclusions for future work; there were no expectations on what they would recommend the split ought to be once they were chartered (there were hopes much prior to that). Inasmuch as IEEE 802.11 endorsed and acknowledged the documented splits caused no standards departure/breakage in implementation or behavior - by its review of the taxonomy draft - we had validated all architectures from IEEE 802.11 perspective. It was clear when APF AHC group was formed that it will transpire to provide only clarifying interpretations of functions - not delineate or standardize splits. -mani =3D=3D=3D=3D=3D=3D -----Original Message----- From: Yang, Lily L [mailto:lily.l.yang@intel.com]=20 Sent: Wednesday, June 15, 2005 1:19 PM To: Mani, Mahalingam (Mahalingam); Pat Calhoun Cc: capwap@frascone.com Subject: RE: [Capwap] Taxonomy Recommendations Hi, Pat and Mani -- I have not read through the entire Taxonomy Recommendations document yet, but just reading through the first few pages, I believe the authors are correct in pointing out one of the "inconsistency" (error) in the taxonomy draft. There was a paragraph in the taxonomy draft Section 5.6: " The commonalities and differences between Local MAC and Split MAC are most clearly seen by comparing Figure 7 to Figure 10. The commonality is that 802.11 control frames are terminated at WTPs in both cases. The main difference between Local MAC and Split MAC is that the WTP terminates only the 802.11 control frames in the Split MAC, while the WTP may terminate all 802.11 frames in the Local MAC. An interesting consequence of this difference is that the Integration Service, which essentially refers to bridging between 802.11 and 802.3 frames, is implemented by the AC in the Split MAC, but can be part of either the AC or WTP in the Local MAC." The last sentence, as pointed out by Pat, Bob and Inderpreet's document, was incorrect. According to Figure 9, Integration Service, for all the parties classified as Local MAC, is implemented by WTP.=20 Given that we still have about 3 hours remaining in the authors' 48 hour window, I would like to send a note to RFC Editor suggesting the following sentence to replace the last sentence in the paragraph: "An interesting consequence of this difference is that the Integration Service, which essentially refers to bridging between 802.11 and 802.3 frames, is implemented by the AC in the Split MAC and by the WTP in the Local MAC, as shown in Figure 9 and Figure 12." Glaring as it is, I believe this error does not carry any far reaching implication to the entire document and hence it is bug we can fix right now. Regarding the comment from the authors that taxonomy draft lacks conclusion and recommendation and hence the motivation to take it further to clearly define what Local and Split MAC really mean in terms of functional split -- I think that is a fair comment -- Personally I was tempted to take that step in the taxonomy draft with the intention to help the WG moving forward, but as the editor of the draft, I received clear instruction from the chairs and the WG that a taxonomy only goes so far to "document" the reality of the market, not to "define" any architectures. So the draft deliberately didn't go far into making any specific functional split recommendation. As I advocated in both July and Nov IETF meeting last year, I believe there is indeed a gap between taxonomy draft and objective draft -- the WG needs a clear definition of the functional split for Local, especially Split MAC, but that is not the charter of either taxonomy draft or Objective draft. Some people have the illusion that IEEE 802.11 (specifically the APF ad hoc group) will provide such definition. The clear answer there is NO, IEEE would not do that. It is up to us in this group to agree on the split and move on. So if indeed this Taxonomy Recommendation draft fulfills this purpose, I personally believe it is a very necessary step to take in order to move forward. However, as I said, I have not reviewed the entire document yet and so I would reserve until then to offer any further comments. But I do want to fix the error in Section 5.6 in Taxonomy draft NOW.=20 Lily -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Mani, Mahalingam (Mahalingam) Sent: Wednesday, June 15, 2005 11:14 AM To: Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Taxonomy Recommendations Thanks for the joint effort (by authors of two candidate protocols for eval. as I see it) in making a case for clarification of terminology. If the changes and clarifications proposed are extensive - comments in form of I-D is useful to place-hold them. The WG should (especially the original taxonomy team authors) comment on these comments (draft): WG has approved the -06 version of the taxonomy draft. Two of the authors are in this as well :) It is also important to understand the implications, if any, (on Objectives draft) if WG agrees to any of the proposed clarifications. It may turn out to be transparent to the Objectives draft. This needs to happen soon for Objectives to freeze and let the evaluation team use a baselined version. [BTW: the taxonomy draft is in RFC editor's queue - actually just completed AUTH48]. -mani =3D=3D=3D=3D=3D=3D -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun Sent: Thursday, June 09, 2005 2:28 PM To: capwap@frascone.com Subject: [Capwap] Taxonomy Recommendations All, =20 I wanted to announce the early availability of the CAPWAP taxonomy recommendation draft that Bob O'Hara Inderpreet Singh and I have been working on. It can be found at http://www.capwap.org/draft-calhoun-capwap-taxonomy-recommendation-00.tx t. Abstract The IETF's CAPWAP working group has documented various product architectures and has categorized the Centralized WLAN Architectures into two main buckets: Split and Local MAC. While the document contains very relevant and useful information, what it does is list the architectural variants of these two buckets, but does not unambiguously define either the Split MAC or Local MAC architectures. In order for CAPWAP to be successful, it is crucial for the protocol evaluation team, and the working group, to agree on unambiguous terminology to describe these architectures. This document proposes terminology to unambiguously describe the relevant architectures found in the taxonomy document, for the purpose of initiating a discussion within the working group and to allow the protocol evaluation work to come to a fruitful conclusion. We conclude in this document that the architectures are very similar and could be supported via a single protocol. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From aessen@didamail.com Thu Jun 16 10:15:20 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24127; Thu, 16 Jun 2005 10:15:20 -0400 (EDT) Received: from [211.202.170.5] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DivWK-0002Jy-By; Thu, 16 Jun 2005 10:39:06 -0400 Received: by welles (Wostfix 98 30) id 72B07C1149249; Thu, 16 Jun 2005 18:08:56 +0300 Date: Thu, 16 Jun 2005 20:10:56 +0500 From: "Ramona Bateman" Message-ID: <531c.fsf@calle23.net> To: bofchairs@ietf.org Cc: bounces-ietf@ietf.org, bpana@ietf.org, brenton.daniels@ietf.org, bridge-mib@ietf.org, bridge-mib-admin@ietf.org, business@ietf.org, calsch@ietf.org, cancer@ietf.org, capwap-archive@ietf.org, ccips@ietf.org Subject: Become one of the low rates X-Mailer: Apple Mail (2.482) X-Spam-Score: 8.2 (++++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have been selected for our lowest rate in years... You could get over $420,000 for as little as $400 a month! Ba(d credit, Bank*ruptcy? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.cr3amier.net/signs.asp Best Regards, Stephan Looney to be remov(ed: http://www.cr3amier.net/deletion.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From capwap-admin@frascone.com Thu Jun 16 10:26:10 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25911 for ; Thu, 16 Jun 2005 10:26:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0C63D2057E; Thu, 16 Jun 2005 10:26:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5AFC7204B0; Thu, 16 Jun 2005 10:26:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E2A3A204B0 for ; Thu, 16 Jun 2005 10:25:04 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 6E4B9204AE for ; Thu, 16 Jun 2005 10:25:01 -0400 (EDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 16 Jun 2005 07:25:00 -0700 X-IronPort-AV: i="3.93,204,1115017200"; d="scan'208,217"; a="279521333:sNHT49934916" Received: from pacalhouwxp ([10.32.30.113]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5GEOq7l005250; Thu, 16 Jun 2005 07:24:53 -0700 (PDT) Message-Id: <200506161424.j5GEOq7l005250@sj-core-2.cisco.com> From: "Pat Calhoun" To: "'Sadot, Emek (Emek)'" , "'Michael Montemurro'" , Subject: RE: [Capwap] Support for Traffic Separation MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05DE_01C57244.807597E0" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVyb+NMiWZ+QYnwQEu0hrVkigf1PgAAOZpQAALNmBA= In-Reply-To: <5844A41F4E146044A2E8356C6328588008D913A8@nj7460avexu2.global.avaya.com> X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.30.113] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 16 Jun 2005 07:24:53 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------=_NextPart_000_05DE_01C57244.807597E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > Giving the operator / customer the freedom to run the IS function in AC or WTP is important and as far as I can tell doesn't > break the CAPWAP model. Why it's important: well take #1 for example, if customer wishes to session to travel along > the shorter path between peers, or maintain existing voice call when AC experience a failover and perform reboot (but new > session or roaming obviously)." Emek, I don't see how this can be achieved. A user's end device has a single IP address. One really cannot split the forwarding of user traffic based on the relative priority of the traffic or based on network failures, because the return path of the user's traffic would always end up on its home subnet. The above suggestion where sometimes the user's traffic is briged and sometimes it is tunneled, would REQUIRE the WTP and the AC to be on the same subnet - which conflicts with the "Interconnection Objective". Further, one must assume that there are functions that reside in the AC that are much more than just "tunnel termination", and if this is the case these functions are lost when you resort to brige mode. If redundancy/resiliency is required, then it must be provided in the CAPWAP protocol through some other means. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) Sent: Thursday, June 16, 2005 5:54 AM To: Michael Montemurro; Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Mike, To make sure I am clear: by "bridge" I was referring to the Integration Services - bridging between 802.11 and 802.3. All management frames (security, QoS, etc.) should be handle by the AC. Giving the operator / customer the freedom to run the IS function in AC or WTP is important and as far as I can tell doesn't break the CAPWAP model. Why it's important: well take #1 for example, if customer wishes to session to travel along the shorter path between peers, or maintain existing voice call when AC experience a failover and perform reboot (but new session or roaming obviously). Emek _____ From: Michael Montemurro [mailto:michael.montemurro@siemens.com] Sent: Thursday, June 16, 2005 3:35 PM To: Sadot, Emek (Emek); Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Emek, I just want to get clarification on your response. You believe there are four possibilities: 1) Split MAC - Bridge at WTP 2) Split MAC - Bridge at AC 3) Local MAC - Bridge at WTP 4) Local MAC - Bridge at AC I'd just like to understand how you envision case 1). What type of functionality would you envision would terminate at the AC? Could you be more specific on how you would handle WLAN management frames, security, and QoS in that case? Thanks, Mike Michael Montemurro Director, Advanced Technology and Standards Chantry Networks, A Siemens Company 1900 Minnesota Ct, Suite 125 Mississauga, ON, CANADA. T: 905-363-6413 F: 905-567-9900 E: michael.montemurro@siemens.com _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) Sent: June 15, 2005 4:50 PM To: Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Pat, Thanks for your response though it didn't address the issue I was trying to raise. The problem was at my end - rereading my question I realize I wasn't clear enough. My apologies. Let me rephrase my concern though this time in a suggestion manner (rather then challenging specific proposed protocol). In my opinion the CAPWAP protocol shouldn't tie bridging the user's data traffic function to a specific architecture (split or local) and be flexible enough to accommodate all four permutations: Split / MAC & bridging at AC / WTP. As part of the initial configuration phase the AC shall instruct the WTP to either locally bridge data traffic or tunnel to an AC. Regards, Emek _____ From: Pat Calhoun [mailto:pcalhoun@cisco.com] Sent: Wednesday, June 15, 2005 2:17 PM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation My apologies for the latency in my response. Yes, the LWAPP protocol supports what we refer to Local and Split MAC. In Split MAC, the user's traffic is tunneled between the WTP and the AC while in Local MAC the data is locally bridged. Draft 02 of the LWAPP draft does not include enough text to cover the Local MAC case, even though shipping LWAPP products do this today, but we will have this fixed up in -03. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _____ From: Sadot, Emek (Emek) [mailto:esadot@avaya.com] Sent: Tuesday, June 07, 2005 12:35 PM To: Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Pat, A question regarding section 2.1.2 Support for Traffic Separation - author's interpretation of Support for Traffic Separation: does LWAPP supports an architecture in which the DS is implemented at the WTP? (avoid tunneling data frames to a control entity). Regards, Emek _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun Sent: Wednesday, June 01, 2005 10:32 AM To: capwap@frascone.com Subject: [Capwap] LWAPP Self Evaluation draft posted yesterday All, As per the protocol submission rules laid out by the chairs, the authors of the LWAPP protocol submitted a self evaluation to the I-D draft editors yesterday. I have made the draft available at http://www.capwap.org/draft-calhoun-capwap-lwapp-objectives-comparison-00.tx t. Comments welcomed! Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ------=_NextPart_000_05DE_01C57244.807597E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
> Giving the operator / customer the freedom = to=20 run the IS function in AC or WTP is important and as far as I can = tell=20 doesn't
> break the=20 CAPWAP model. Why it's important: = well take #1 for=20 example, if customer wishes to session to travel along=20
>=20 the shorter path between peers, or maintain existing = voice=20 call when AC experience a failover and perform reboot (but new =
>=20 session or roaming obviously)."
 
Emek,=20 I don't see how this can be achieved. A user's end device has a single = IP=20 address. One really cannot split the forwarding of user traffic based on = the=20 relative priority of the traffic or based on network failures, because = the=20 return path of the user's traffic would always end up on its home = subnet. The=20 above suggestion where sometimes the user's traffic is briged and = sometimes it=20 is tunneled, would REQUIRE the WTP and the AC to be on the same subnet - = which=20 conflicts with the "Interconnection Objective". Further, one must assume = that=20 there are functions that reside in the AC that are much more than just = "tunnel=20 termination", and if this is the case these functions are lost when=20 you resort to brige mode.
 
If=20 redundancy/resiliency is required, then it must be provided in the = CAPWAP=20 protocol through some other means.
 

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

 

From: capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek=20 (Emek)
Sent: Thursday, June 16, 2005 5:54 AM
To: = Michael=20 Montemurro; Pat Calhoun; capwap@frascone.com
Subject: RE: = [Capwap]=20 Support for Traffic Separation

Mike,
 
To=20 make sure I am clear: by "bridge" I was referring to the = Integration=20 Services -  bridging between 802.11 and = 802.3.
All=20 management frames (security, QoS, etc.) should be handle by the=20 AC.
 
Giving the operator / customer the freedom to run the IS = function=20 in AC or WTP is important and as far as I can tell doesn't break the = CAPWAP=20 model.
Why=20 it's important: well take #1 for example, if customer = wishes to=20 session to travel along the shorter path between peers,=20 or maintain existing voice call when AC experience a = failover=20 and perform reboot (but new session or roaming=20 obviously).
 
Emek

From: Michael Montemurro=20 [mailto:michael.montemurro@siemens.com]
Sent: Thursday, = June 16,=20 2005 3:35 PM
To: Sadot, Emek (Emek); Pat Calhoun;=20 capwap@frascone.com
Subject: RE: [Capwap] Support for = Traffic=20 Separation

Emek,
 
I just want to get clarification on your = response. You=20 believe there are four possibilities:
 
   =20 1) Split MAC - = Bridge at=20 WTP
   =20 2) Split MAC - = Bridge at=20 AC
   =20 3) Local MAC - = Bridge at=20 WTP
    4) Local MAC - Bridge at=20 AC
 
I'd just like to understand how you envision = case 1).=20  What type of functionality would you envision would terminate at = the AC?=20 Could you be more specific on how you would handle WLAN management = frames,=20 security, and QoS in that case?
 
Thanks,
 
   =20 Mike
 

Michael Montemurro
Director, Advanced Technology = and=20 Standards
Chantry Networks, A Siemens Company
1900 Minnesota Ct, = Suite=20 125
Mississauga, ON, CANADA.
T: 905-363-6413
F: = 905-567-9900
E:=20 michael.montemurro@siemens.com


From: capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek=20 (Emek)
Sent: June 15, 2005 4:50 PM
To: Pat = Calhoun;=20 capwap@frascone.com
Subject: RE: [Capwap] Support for = Traffic=20 Separation

Pat,
 
Thanks for your response though it didn't address the = issue I=20 was trying to raise. The problem was at my end = - rereading my=20 question I realize I wasn't clear enough. My apologies. Let me = rephrase my=20 concern though this time in a suggestion manner (rather then=20 challenging specific proposed protocol).
 
In=20 my opinion the CAPWAP protocol shouldn't tie bridging the = user's data=20 traffic function to a specific architecture (split or local) = and be=20 flexible enough to accommodate all four permutations: = Split / MAC=20 & bridging at AC / WTP.
As=20 part of the initial configuration phase the AC = shall instruct=20 the WTP to either locally bridge data traffic or tunnel to = an AC.=20
 
Regards,
Emek

From: Pat Calhoun=20 [mailto:pcalhoun@cisco.com]
Sent: Wednesday, June 15, = 2005 2:17=20 PM
To: Sadot, Emek (Emek); = capwap@frascone.com
Subject:=20 RE: [Capwap] Support for Traffic Separation

My apologies for the latency in my=20 response.
 
Yes, the LWAPP protocol supports what we = refer to Local=20 and Split MAC. In Split MAC, the user's traffic is = tunneled between the=20 WTP and the AC while in Local MAC the data is locally bridged. Draft = 02 of=20 the LWAPP draft does not include enough text to cover the Local MAC = case,=20 even though shipping LWAPP products do this today, but we will = have=20 this fixed up in -03.

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

 

From: Sadot, Emek (Emek)=20 [mailto:esadot@avaya.com]
Sent: Tuesday, June 07, 2005 = 12:35=20 PM
To: Pat Calhoun; = capwap@frascone.com
Subject: RE:=20 [Capwap] Support for Traffic Separation

Pat,
 
A question regarding=20 section 2.1.2 Support for Traffic=20 Separation - author's interpretation = of Support for Traffic Separation:=20 does LWAPP supports an architecture in which the DS is = implemented at=20 the WTP? (avoid tunneling data frames to a control=20 entity).
 
Regards,
Emek

From: = capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Pat=20 Calhoun
Sent: Wednesday, June 01, 2005 10:32 = AM
To:=20 capwap@frascone.com
Subject: [Capwap] LWAPP Self = Evaluation=20 draft posted yesterday

All,
 
As per the=20 protocol submission rules laid out by the chairs, the authors of = the LWAPP=20 protocol submitted a self evaluation to the I-D draft editors = yesterday. I=20 have made the draft available at http://www.capwap.org/draft-calhoun-capwap-lwapp-objectives-comp= arison-00.txt.
 
Comments=20 welcomed!
 

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

=
 
------=_NextPart_000_05DE_01C57244.807597E0-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 16 15:12:12 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27041 for ; Thu, 16 Jun 2005 15:12:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 647C02037A; Thu, 16 Jun 2005 15:12:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E73F9202B7; Thu, 16 Jun 2005 15:12:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0DF05202B7 for ; Thu, 16 Jun 2005 15:11:21 -0400 (EDT) Received: from aruba-server.arubanetworks.com (smtp.arubanetworks.com [216.31.249.252]) by mail.frascone.com (Postfix) with SMTP id 24D97202A2 for ; Thu, 16 Jun 2005 15:11:19 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] SLAPP evaluation draft X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Message-ID: Thread-Topic: [Capwap] SLAPP evaluation draft Thread-Index: AcVyGTRtOf23+yEvR9a9T0CKcqYV5QAjMbvA From: "Subbu Ponnuswamy" To: "Inderpreet Singh" , , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 16 Jun 2005 12:11:18 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable We are not sure why the evaluation draft did not show up at the IETF repository. We have resubmitted the draft to the IETF. In the meantime, the draft can be accessed at http://www.arubanetworks.com/technology/draft-narasimhan-capwap-slapp-ev aluation-00.txt Thanks, --Subbu |> -----Original Message----- |> From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On |> Behalf Of Inderpreet Singh |> Sent: Wednesday, June 15, 2005 7:13 PM |> To: sarikaya@ieee.org; capwap@frascone.com |> Subject: RE: [Capwap] SLAPP evaluation draft |>=20 |> Bechet - no - I have not been able to find it in the repository either. |>=20 |> --- |> Inderpreet Singh |>=20 |>=20 |> -----Original Message----- |> From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On |> Behalf |> Of Behcet Sarikaya |> Sent: Wednesday, June 15, 2005 10:09 PM |> To: capwap@frascone.com |> Subject: Re: [Capwap] SLAPP evaluation draft |>=20 |> Has anyone been able to access this draft? I could not. |> Thx. |>=20 |> --behcet |>=20 |> Partha Narasimhan wrote: |>=20 |> > |> > The SLAPP evaluation draft has been submitted. It should show up in due |> > course at |> > |> http://www.ietf.org/internet-drafts/draft-narasimhan-capwap-slapp- |> evaluation |> -00.txt |> > |> > |> > On behalf of the authors, I would like to apologize for the delay in |> > submitting this draft. |> > |> > Thanks |> > partha |> > _______________________________________________ |> > Capwap mailing list |> > Capwap@frascone.com |> > http://mail.frascone.com/mailman/listinfo/capwap |> > |> _______________________________________________ |> Capwap mailing list |> Capwap@frascone.com |> http://mail.frascone.com/mailman/listinfo/capwap |> _______________________________________________ |> Capwap mailing list |> Capwap@frascone.com |> http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 16 16:44:18 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13866 for ; Thu, 16 Jun 2005 16:44:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 84FCB20446; Thu, 16 Jun 2005 16:44:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3E854203A4; Thu, 16 Jun 2005 16:44:08 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 246E2203A4 for ; Thu, 16 Jun 2005 16:43:41 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id 1688E2036F for ; Thu, 16 Jun 2005 16:43:38 -0400 (EDT) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5GKf9dd026238 for ; Thu, 16 Jun 2005 16:41:09 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5GKf8dd026199 for ; Thu, 16 Jun 2005 16:41:08 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C572B4.1128D668" Subject: RE: [Capwap] Support for Traffic Separation Message-ID: <5844A41F4E146044A2E8356C6328588008DFD87B@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] Support for Traffic Separation Thread-Index: AcVyb+NMiWZ+QYnwQEu0hrVkigf1PgAAOZpQAALNmBAADYYa4A== From: "Sadot, Emek (Emek)" To: "Pat Calhoun" , "Michael Montemurro" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 16 Jun 2005 16:43:35 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C572B4.1128D668 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pat, =20 "One really cannot split the forwarding of user traffic based on the relative priority of the traffic or based on network failures" - I agree that user data traffic cannot be split, and that wasn't my suggestion. I suggested that user data traffic will always be bridged at the WTP or AC. =20 "the return path of the user's traffic would always end up on its home subnet" - In my suggestion the return path will always hit one of the two: WTP, if bridging is implemented at the WTP (user's MAC address associate with the WTP) or AC, if bridging is implemented at the AC (user's MAC address associate with the AC). =20 "Further, one must assume that there are functions that reside in the AC that are much more than just "tunnel termination", and if this is the case these functions are lost when you resort to bridge mode." - I assume you meant that some functionality will be lost if bridging is implemented at the WTP, so if that's your argument then the counter argument would be: how these functions being materialized in Local MAc arch? =20 Emek =20 _____ =20 From: Pat Calhoun [mailto:pcalhoun@cisco.com]=20 Sent: Thursday, June 16, 2005 5:25 PM To: Sadot, Emek (Emek); 'Michael Montemurro'; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation > Giving the operator / customer the freedom to run the IS function in AC or WTP is important and as far as I can tell doesn't=20 > break the CAPWAP model. Why it's important: well take #1 for example, if customer wishes to session to travel along=20 > the shorter path between peers, or maintain existing voice call when AC experience a failover and perform reboot (but new=20 > session or roaming obviously)." =20 Emek, I don't see how this can be achieved. A user's end device has a single IP address. One really cannot split the forwarding of user traffic based on the relative priority of the traffic or based on network failures, because the return path of the user's traffic would always end up on its home subnet. The above suggestion where sometimes the user's traffic is briged and sometimes it is tunneled, would REQUIRE the WTP and the AC to be on the same subnet - which conflicts with the "Interconnection Objective". Further, one must assume that there are functions that reside in the AC that are much more than just "tunnel termination", and if this is the case these functions are lost when you resort to brige mode. =20 If redundancy/resiliency is required, then it must be provided in the CAPWAP protocol through some other means. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) Sent: Thursday, June 16, 2005 5:54 AM To: Michael Montemurro; Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation =09 =09 Mike, =20 To make sure I am clear: by "bridge" I was referring to the Integration Services - bridging between 802.11 and 802.3. All management frames (security, QoS, etc.) should be handle by the AC. =20 Giving the operator / customer the freedom to run the IS function in AC or WTP is important and as far as I can tell doesn't break the CAPWAP model. Why it's important: well take #1 for example, if customer wishes to session to travel along the shorter path between peers, or maintain existing voice call when AC experience a failover and perform reboot (but new session or roaming obviously). =20 Emek _____ =20 From: Michael Montemurro [mailto:michael.montemurro@siemens.com] Sent: Thursday, June 16, 2005 3:35 PM To: Sadot, Emek (Emek); Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation =09 =09 Emek, =20 I just want to get clarification on your response. You believe there are four possibilities: =20 1) Split MAC - Bridge at WTP 2) Split MAC - Bridge at AC 3) Local MAC - Bridge at WTP 4) Local MAC - Bridge at AC =20 I'd just like to understand how you envision case 1). What type of functionality would you envision would terminate at the AC? Could you be more specific on how you would handle WLAN management frames, security, and QoS in that case? =20 Thanks, =20 Mike =20 Michael Montemurro Director, Advanced Technology and Standards Chantry Networks, A Siemens Company 1900 Minnesota Ct, Suite 125 Mississauga, ON, CANADA. T: 905-363-6413 F: 905-567-9900 E: michael.montemurro@siemens.com=20 _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) Sent: June 15, 2005 4:50 PM To: Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation =09 =09 Pat, =20 Thanks for your response though it didn't address the issue I was trying to raise. The problem was at my end - rereading my question I realize I wasn't clear enough. My apologies. Let me rephrase my concern though this time in a suggestion manner (rather then challenging specific proposed protocol). =20 In my opinion the CAPWAP protocol shouldn't tie bridging the user's data traffic function to a specific architecture (split or local) and be flexible enough to accommodate all four permutations: Split / MAC & bridging at AC / WTP. As part of the initial configuration phase the AC shall instruct the WTP to either locally bridge data traffic or tunnel to an AC.=20 =20 Regards, Emek _____ =20 From: Pat Calhoun [mailto:pcalhoun@cisco.com]=20 Sent: Wednesday, June 15, 2005 2:17 PM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation =09 =09 My apologies for the latency in my response. =20 Yes, the LWAPP protocol supports what we refer to Local and Split MAC. In Split MAC, the user's traffic is tunneled between the WTP and the AC while in Local MAC the data is locally bridged. Draft 02 of the LWAPP draft does not include enough text to cover the Local MAC case, even though shipping LWAPP products do this today, but we will have this fixed up in -03. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 _____ =20 From: Sadot, Emek (Emek) [mailto:esadot@avaya.com]=20 Sent: Tuesday, June 07, 2005 12:35 PM To: Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation =09 =09 Pat, =20 A question regarding section 2.1.2 Support for Traffic Separation - author's interpretation of Support for Traffic Separation: does LWAPP supports an architecture in which the DS is implemented at the WTP? (avoid tunneling data frames to a control entity). =20 Regards, Emek _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun Sent: Wednesday, June 01, 2005 10:32 AM To: capwap@frascone.com Subject: [Capwap] LWAPP Self Evaluation draft posted yesterday =09 =09 All, =20 As per the protocol submission rules laid out by the chairs, the authors of the LWAPP protocol submitted a self evaluation to the I-D draft editors yesterday. I have made the draft available at http://www.capwap.org/draft-calhoun-capwap-lwapp-objectives-comparison-0 0.txt . =20 Comments welcomed! =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ------_=_NextPart_001_01C572B4.1128D668 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Pat,
 
"One really cannot split the forwarding of user traffic = based on=20 the relative priority of the traffic or based on network = failures" - I agree that user data traffic cannot be = split, and that=20 wasn't my suggestion. I suggested that user data traffic will always be=20 bridged at the WTP or AC.
 
"the return path of the user's = traffic would=20 always end up on its home subnet" - In my suggestion the return = path will=20 always hit one of the two: WTP, if bridging is implemented at = the WTP=20 (user's MAC address associate with the WTP) or AC, if bridging is = implemented at=20 the AC (user's MAC address associate with the = AC).
 
"Further, one must assume that there are functions that = reside in=20 the AC that are much more than just "tunnel termination", and if this is = the=20 case these functions are lost when you resort to bridge = mode." - I assume you meant that some functionality will = be=20 lost if bridging is implemented at the WTP, so if that's your = argument then=20 the counter argument would be: how these functions being=20 materialized in Local MAc arch?
 
Emek
 

From: Pat Calhoun = [mailto:pcalhoun@cisco.com]=20
Sent: Thursday, June 16, 2005 5:25 PM
To: Sadot, = Emek=20 (Emek); 'Michael Montemurro'; capwap@frascone.com
Subject: RE: = [Capwap] Support for Traffic Separation

> Giving the operator / customer the freedom = to=20 run the IS function in AC or WTP is important and as far as I can = tell=20 doesn't
> break the=20 CAPWAP model. Why it's important: = well take #1 for=20 example, if customer wishes to session to travel along=20
>=20 the shorter path between peers, or maintain existing = voice=20 call when AC experience a failover and perform reboot (but new =
>=20 session or roaming obviously)."
 
Emek,=20 I don't see how this can be achieved. A user's end device has a single = IP=20 address. One really cannot split the forwarding of user traffic based on = the=20 relative priority of the traffic or based on network failures, because = the=20 return path of the user's traffic would always end up on its home = subnet. The=20 above suggestion where sometimes the user's traffic is briged and = sometimes it=20 is tunneled, would REQUIRE the WTP and the AC to be on the same subnet - = which=20 conflicts with the "Interconnection Objective". Further, one must assume = that=20 there are functions that reside in the AC that are much more than just = "tunnel=20 termination", and if this is the case these functions are lost when=20 you resort to brige mode.
 
If=20 redundancy/resiliency is required, then it must be provided in the = CAPWAP=20 protocol through some other means.
 

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

 

From: capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek=20 (Emek)
Sent: Thursday, June 16, 2005 5:54 AM
To: = Michael=20 Montemurro; Pat Calhoun; capwap@frascone.com
Subject: RE: = [Capwap]=20 Support for Traffic Separation

Mike,
 
To=20 make sure I am clear: by "bridge" I was referring to the = Integration=20 Services -  bridging between 802.11 and = 802.3.
All=20 management frames (security, QoS, etc.) should be handle by the=20 AC.
 
Giving the operator / customer the freedom to run the IS = function=20 in AC or WTP is important and as far as I can tell doesn't break the = CAPWAP=20 model.
Why=20 it's important: well take #1 for example, if customer = wishes to=20 session to travel along the shorter path between peers,=20 or maintain existing voice call when AC experience a = failover=20 and perform reboot (but new session or roaming=20 obviously).
 
Emek

From: Michael Montemurro=20 [mailto:michael.montemurro@siemens.com]
Sent: Thursday, = June 16,=20 2005 3:35 PM
To: Sadot, Emek (Emek); Pat Calhoun;=20 capwap@frascone.com
Subject: RE: [Capwap] Support for = Traffic=20 Separation

Emek,
 
I just want to get clarification on your = response. You=20 believe there are four possibilities:
 
   =20 1) Split MAC - = Bridge at=20 WTP
   =20 2) Split MAC - = Bridge at=20 AC
   =20 3) Local MAC - = Bridge at=20 WTP
    4) Local MAC - Bridge at=20 AC
 
I'd just like to understand how you envision = case 1).=20  What type of functionality would you envision would terminate at = the AC?=20 Could you be more specific on how you would handle WLAN management = frames,=20 security, and QoS in that case?
 
Thanks,
 
   =20 Mike
 

Michael Montemurro
Director, Advanced Technology = and=20 Standards
Chantry Networks, A Siemens Company
1900 Minnesota Ct, = Suite=20 125
Mississauga, ON, CANADA.
T: 905-363-6413
F: = 905-567-9900
E:=20 michael.montemurro@siemens.com


From: capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek=20 (Emek)
Sent: June 15, 2005 4:50 PM
To: Pat = Calhoun;=20 capwap@frascone.com
Subject: RE: [Capwap] Support for = Traffic=20 Separation

Pat,
 
Thanks for your response though it didn't address the = issue I=20 was trying to raise. The problem was at my end = - rereading my=20 question I realize I wasn't clear enough. My apologies. Let me = rephrase my=20 concern though this time in a suggestion manner (rather then=20 challenging specific proposed protocol).
 
In=20 my opinion the CAPWAP protocol shouldn't tie bridging the = user's data=20 traffic function to a specific architecture (split or local) = and be=20 flexible enough to accommodate all four permutations: = Split / MAC=20 & bridging at AC / WTP.
As=20 part of the initial configuration phase the AC = shall instruct=20 the WTP to either locally bridge data traffic or tunnel to = an AC.=20
 
Regards,
Emek

From: Pat Calhoun=20 [mailto:pcalhoun@cisco.com]
Sent: Wednesday, June 15, = 2005 2:17=20 PM
To: Sadot, Emek (Emek); = capwap@frascone.com
Subject:=20 RE: [Capwap] Support for Traffic Separation

My apologies for the latency in my=20 response.
 
Yes, the LWAPP protocol supports what we = refer to Local=20 and Split MAC. In Split MAC, the user's traffic is = tunneled between the=20 WTP and the AC while in Local MAC the data is locally bridged. Draft = 02 of=20 the LWAPP draft does not include enough text to cover the Local MAC = case,=20 even though shipping LWAPP products do this today, but we will = have=20 this fixed up in -03.

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

 

From: Sadot, Emek (Emek)=20 [mailto:esadot@avaya.com]
Sent: Tuesday, June 07, 2005 = 12:35=20 PM
To: Pat Calhoun; = capwap@frascone.com
Subject: RE:=20 [Capwap] Support for Traffic Separation

Pat,
 
A question regarding=20 section 2.1.2 Support for Traffic=20 Separation - author's interpretation = of Support for Traffic Separation:=20 does LWAPP supports an architecture in which the DS is = implemented at=20 the WTP? (avoid tunneling data frames to a control=20 entity).
 
Regards,
Emek

From: = capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Pat=20 Calhoun
Sent: Wednesday, June 01, 2005 10:32 = AM
To:=20 capwap@frascone.com
Subject: [Capwap] LWAPP Self = Evaluation=20 draft posted yesterday

All,
 
As per the=20 protocol submission rules laid out by the chairs, the authors of = the LWAPP=20 protocol submitted a self evaluation to the I-D draft editors = yesterday. I=20 have made the draft available at http://www.capwap.org/draft-calhoun-capwap-lwapp-objectives-comp= arison-00.txt.
 
Comments=20 welcomed!
 

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

=
 
------_=_NextPart_001_01C572B4.1128D668-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 16 16:48:13 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14194 for ; Thu, 16 Jun 2005 16:48:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2B85020492; Thu, 16 Jun 2005 16:48:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 41C12203A4; Thu, 16 Jun 2005 16:48:08 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BA74A203A4 for ; Thu, 16 Jun 2005 16:47:19 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 41AAE2036F for ; Thu, 16 Jun 2005 16:47:16 -0400 (EDT) Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5GKZNAK009533 for ; Thu, 16 Jun 2005 16:35:24 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5GKZMAK009507 for ; Thu, 16 Jun 2005 16:35:23 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C572B4.93520140" Subject: RE: [Capwap] Support for Traffic Separation Message-ID: <5844A41F4E146044A2E8356C6328588008DFD882@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] Support for Traffic Separation Thread-Index: AcVycBVZCKVxg3scSxq6fXM8oyZE3gACvBowAA5KpgA= From: "Sadot, Emek (Emek)" To: "Pat Calhoun" , "Michael Montemurro" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 16 Jun 2005 16:47:14 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C572B4.93520140 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pat, I understand where you are coming from and respect it, though I respectfully disagree with the definition: tunneling of user data is Split, while local bridging is Local. =20 Emek _____ =20 From: Pat Calhoun [mailto:pcalhoun@cisco.com]=20 Sent: Thursday, June 16, 2005 4:58 PM To: 'Michael Montemurro'; Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Emek, =20 Note that I disagree with the need for such complexity in the protocol, and my belief is this confusion stems from the lack of conclusion in the taxonomy draft. There is simply much more to tunneling traffic than just the Distribution and Integration Service, so one must actually be very specific in each case on where every function resides. My belief is that tunneling of user data is Split, while local bridging is Local. We have documented this in the Taxonomy Recommendations document, which I would urge you to comment on.=20 =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 _____ =20 From: Michael Montemurro [mailto:michael.montemurro@siemens.com] Sent: Thursday, June 16, 2005 5:35 AM To: Sadot, Emek (Emek); Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation =09 =09 Emek, =20 I just want to get clarification on your response. You believe there are four possibilities: =20 1) Split MAC - Bridge at WTP 2) Split MAC - Bridge at AC 3) Local MAC - Bridge at WTP 4) Local MAC - Bridge at AC =20 I'd just like to understand how you envision case 1). What type of functionality would you envision would terminate at the AC? Could you be more specific on how you would handle WLAN management frames, security, and QoS in that case? =20 Thanks, =20 Mike =20 Michael Montemurro Director, Advanced Technology and Standards Chantry Networks, A Siemens Company 1900 Minnesota Ct, Suite 125 Mississauga, ON, CANADA. T: 905-363-6413 F: 905-567-9900 E: michael.montemurro@siemens.com=20 _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) Sent: June 15, 2005 4:50 PM To: Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation =09 =09 Pat, =20 Thanks for your response though it didn't address the issue I was trying to raise. The problem was at my end - rereading my question I realize I wasn't clear enough. My apologies. Let me rephrase my concern though this time in a suggestion manner (rather then challenging specific proposed protocol). =20 In my opinion the CAPWAP protocol shouldn't tie bridging the user's data traffic function to a specific architecture (split or local) and be flexible enough to accommodate all four permutations: Split / MAC & bridging at AC / WTP. As part of the initial configuration phase the AC shall instruct the WTP to either locally bridge data traffic or tunnel to an AC.=20 =20 Regards, Emek _____ =20 From: Pat Calhoun [mailto:pcalhoun@cisco.com]=20 Sent: Wednesday, June 15, 2005 2:17 PM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation =09 =09 My apologies for the latency in my response. =20 Yes, the LWAPP protocol supports what we refer to Local and Split MAC. In Split MAC, the user's traffic is tunneled between the WTP and the AC while in Local MAC the data is locally bridged. Draft 02 of the LWAPP draft does not include enough text to cover the Local MAC case, even though shipping LWAPP products do this today, but we will have this fixed up in -03. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 _____ =20 From: Sadot, Emek (Emek) [mailto:esadot@avaya.com]=20 Sent: Tuesday, June 07, 2005 12:35 PM To: Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation =09 =09 Pat, =20 A question regarding section 2.1.2 Support for Traffic Separation - author's interpretation of Support for Traffic Separation: does LWAPP supports an architecture in which the DS is implemented at the WTP? (avoid tunneling data frames to a control entity). =20 Regards, Emek _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun Sent: Wednesday, June 01, 2005 10:32 AM To: capwap@frascone.com Subject: [Capwap] LWAPP Self Evaluation draft posted yesterday =09 =09 All, =20 As per the protocol submission rules laid out by the chairs, the authors of the LWAPP protocol submitted a self evaluation to the I-D draft editors yesterday. I have made the draft available at http://www.capwap.org/draft-calhoun-capwap-lwapp-objectives-comparison-0 0.txt . =20 Comments welcomed! =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ------_=_NextPart_001_01C572B4.93520140 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Pat, I=20 understand where you are coming from and respect it, though I = respectfully=20 disagree with the definition: tunneling of user = data is=20 Split, while local bridging is Local.
 
Emek

From: Pat Calhoun = [mailto:pcalhoun@cisco.com]=20
Sent: Thursday, June 16, 2005 4:58 PM
To: 'Michael=20 Montemurro'; Sadot, Emek (Emek); capwap@frascone.com
Subject: = RE:=20 [Capwap] Support for Traffic Separation

Emek,
 
Note that I disagree with the need for such = complexity in=20 the protocol, and my belief is this confusion stems from the lack of = conclusion=20 in the taxonomy draft. There is simply much more to tunneling traffic = than just=20 the Distribution and Integration Service, so one must actually be very = specific=20 in each case on where every function resides. My belief is that = tunneling of=20 user data is Split, while local bridging is Local. We have documented = this in=20 the Taxonomy Recommendations document, which I would urge you to comment = on.=20
 

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

 

From: Michael Montemurro=20 [mailto:michael.montemurro@siemens.com]
Sent: Thursday, = June 16,=20 2005 5:35 AM
To: Sadot, Emek (Emek); Pat Calhoun;=20 capwap@frascone.com
Subject: RE: [Capwap] Support for = Traffic=20 Separation

Emek,
 
I just want to get clarification on your = response. You=20 believe there are four possibilities:
 
   =20 1) Split MAC - = Bridge at=20 WTP
   =20 2) Split MAC - = Bridge at=20 AC
   =20 3) Local MAC - = Bridge at=20 WTP
    4) Local MAC - Bridge at=20 AC
 
I'd just like to understand how you envision = case 1).=20  What type of functionality would you envision would terminate at = the AC?=20 Could you be more specific on how you would handle WLAN management = frames,=20 security, and QoS in that case?
 
Thanks,
 
   =20 Mike
 

Michael Montemurro
Director, Advanced Technology = and=20 Standards
Chantry Networks, A Siemens Company
1900 Minnesota Ct, = Suite=20 125
Mississauga, ON, CANADA.
T: 905-363-6413
F: = 905-567-9900
E:=20 michael.montemurro@siemens.com


From: capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek=20 (Emek)
Sent: June 15, 2005 4:50 PM
To: Pat = Calhoun;=20 capwap@frascone.com
Subject: RE: [Capwap] Support for = Traffic=20 Separation

Pat,
 
Thanks for your response though it didn't address the = issue I=20 was trying to raise. The problem was at my end = - rereading my=20 question I realize I wasn't clear enough. My apologies. Let me = rephrase my=20 concern though this time in a suggestion manner (rather then=20 challenging specific proposed protocol).
 
In=20 my opinion the CAPWAP protocol shouldn't tie bridging the = user's data=20 traffic function to a specific architecture (split or local) = and be=20 flexible enough to accommodate all four permutations: = Split / MAC=20 & bridging at AC / WTP.
As=20 part of the initial configuration phase the AC = shall instruct=20 the WTP to either locally bridge data traffic or tunnel to = an AC.=20
 
Regards,
Emek

From: Pat Calhoun=20 [mailto:pcalhoun@cisco.com]
Sent: Wednesday, June 15, = 2005 2:17=20 PM
To: Sadot, Emek (Emek); = capwap@frascone.com
Subject:=20 RE: [Capwap] Support for Traffic Separation

My apologies for the latency in my=20 response.
 
Yes, the LWAPP protocol supports what we = refer to Local=20 and Split MAC. In Split MAC, the user's traffic is = tunneled between the=20 WTP and the AC while in Local MAC the data is locally bridged. Draft = 02 of=20 the LWAPP draft does not include enough text to cover the Local MAC = case,=20 even though shipping LWAPP products do this today, but we will = have=20 this fixed up in -03.

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

 

From: Sadot, Emek (Emek)=20 [mailto:esadot@avaya.com]
Sent: Tuesday, June 07, 2005 = 12:35=20 PM
To: Pat Calhoun; = capwap@frascone.com
Subject: RE:=20 [Capwap] Support for Traffic Separation

Pat,
 
A question regarding=20 section 2.1.2 Support for Traffic=20 Separation - author's interpretation = of Support for Traffic Separation:=20 does LWAPP supports an architecture in which the DS is = implemented at=20 the WTP? (avoid tunneling data frames to a control=20 entity).
 
Regards,
Emek

From: = capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Pat=20 Calhoun
Sent: Wednesday, June 01, 2005 10:32 = AM
To:=20 capwap@frascone.com
Subject: [Capwap] LWAPP Self = Evaluation=20 draft posted yesterday

All,
 
As per the=20 protocol submission rules laid out by the chairs, the authors of = the LWAPP=20 protocol submitted a self evaluation to the I-D draft editors = yesterday. I=20 have made the draft available at http://www.capwap.org/draft-calhoun-capwap-lwapp-objectives-comp= arison-00.txt.
 
Comments=20 welcomed!
 

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

=
 
------_=_NextPart_001_01C572B4.93520140-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 16 17:57:06 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18656 for ; Thu, 16 Jun 2005 17:57:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 82A55204B3; Thu, 16 Jun 2005 17:57:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B78A0203A4; Thu, 16 Jun 2005 17:57:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BDBCB203A4 for ; Thu, 16 Jun 2005 17:56:54 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id B726820369 for ; Thu, 16 Jun 2005 17:56:52 -0400 (EDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 16 Jun 2005 14:56:52 -0700 Received: from pacalhouwxp ([10.32.30.113]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5GLunQ3005740; Thu, 16 Jun 2005 14:56:49 -0700 (PDT) Message-Id: <200506162156.j5GLunQ3005740@sj-core-1.cisco.com> From: "Pat Calhoun" To: "'Sadot, Emek (Emek)'" , "'Michael Montemurro'" , Subject: RE: [Capwap] Support for Traffic Separation MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_076F_01C57283.A01A7D60" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVyb+NMiWZ+QYnwQEu0hrVkigf1PgAAOZpQAALNmBAADYYa4AADAyJw In-Reply-To: <5844A41F4E146044A2E8356C6328588008DFD87B@nj7460avexu2.global.avaya.com> X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.30.113] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 16 Jun 2005 14:56:44 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------=_NextPart_000_076F_01C57283.A01A7D60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit "Further, one must assume that there are functions that reside in the AC that are much more than just "tunnel termination", and if this is the case these functions are lost when you resort to bridge mode." - I assume you meant that some functionality will be lost if bridging is implemented at the WTP, so if that's your argument then the counter argument would be: how these functions being materialized in Local MAc arch? So my point was that a Split MAC WTP does not necessarily have the functions to operate as a Local MAC. So requring it to operate in Local MAC mode when an AC has failed is not possible. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ------=_NextPart_000_076F_01C57283.A01A7D60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
"Further, one must assume that there are functions that = reside in=20 the AC that are much more than just "tunnel termination", and if this is = the=20 case these functions are lost when you resort to bridge = mode." - I=20 assume you meant that some functionality will be lost if = bridging is=20 implemented at the WTP, so if that's your argument then the counter = argument=20 would be: how these functions being materialized in Local = MAc=20 arch?
<PRC> So my point was that a Split MAC WTP = does not=20 necessarily have the functions to operate as a Local MAC. So requring it = to=20 operate in Local MAC mode when an AC has failed is not possible.=20
 

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

------=_NextPart_000_076F_01C57283.A01A7D60-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 16 18:02:10 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18999 for ; Thu, 16 Jun 2005 18:02:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 674962055F; Thu, 16 Jun 2005 18:02:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 92A332045F; Thu, 16 Jun 2005 18:02:08 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0A08F2045F for ; Thu, 16 Jun 2005 18:01:45 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id C27F620369 for ; Thu, 16 Jun 2005 18:01:41 -0400 (EDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 16 Jun 2005 15:01:40 -0700 X-IronPort-AV: i="3.93,205,1115017200"; d="scan'208,217"; a="279726268:sNHT47449572" Received: from pacalhouwxp ([10.32.30.113]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5GM1cQ3008874; Thu, 16 Jun 2005 15:01:38 -0700 (PDT) Message-Id: <200506162201.j5GM1cQ3008874@sj-core-1.cisco.com> From: "Pat Calhoun" To: "'Sadot, Emek (Emek)'" , "'Michael Montemurro'" , Subject: RE: [Capwap] Support for Traffic Separation MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0776_01C57284.4C5B5270" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVycBVZCKVxg3scSxq6fXM8oyZE3gACvBowAA5KpgAAAof+8A== In-Reply-To: <5844A41F4E146044A2E8356C6328588008DFD882@nj7460avexu2.global.avaya.com> X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.30.113] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 16 Jun 2005 15:01:33 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------=_NextPart_000_0776_01C57284.4C5B5270 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit So if you've had a chance to read the taxonomy recommendations document that I submitted, I think you'll understand that my argument is that there must be a clear delineation between Split and Local MAC. A WTP that has all of the MAC, but sends a message to the AC that encapsulates most of the information found in some 802.11 mac management packet, then you combine this with tunneling, you end up with something that is identical in fuctionatlity to a Split MAC architecture... but without the name. I think that we should pick two modes of operation, that are distinct and address a customer need, and then create a standard to address them. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) Sent: Thursday, June 16, 2005 1:47 PM To: Pat Calhoun; Michael Montemurro; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Pat, I understand where you are coming from and respect it, though I respectfully disagree with the definition: tunneling of user data is Split, while local bridging is Local. Emek _____ From: Pat Calhoun [mailto:pcalhoun@cisco.com] Sent: Thursday, June 16, 2005 4:58 PM To: 'Michael Montemurro'; Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Emek, Note that I disagree with the need for such complexity in the protocol, and my belief is this confusion stems from the lack of conclusion in the taxonomy draft. There is simply much more to tunneling traffic than just the Distribution and Integration Service, so one must actually be very specific in each case on where every function resides. My belief is that tunneling of user data is Split, while local bridging is Local. We have documented this in the Taxonomy Recommendations document, which I would urge you to comment on. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _____ From: Michael Montemurro [mailto:michael.montemurro@siemens.com] Sent: Thursday, June 16, 2005 5:35 AM To: Sadot, Emek (Emek); Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Emek, I just want to get clarification on your response. You believe there are four possibilities: 1) Split MAC - Bridge at WTP 2) Split MAC - Bridge at AC 3) Local MAC - Bridge at WTP 4) Local MAC - Bridge at AC I'd just like to understand how you envision case 1). What type of functionality would you envision would terminate at the AC? Could you be more specific on how you would handle WLAN management frames, security, and QoS in that case? Thanks, Mike Michael Montemurro Director, Advanced Technology and Standards Chantry Networks, A Siemens Company 1900 Minnesota Ct, Suite 125 Mississauga, ON, CANADA. T: 905-363-6413 F: 905-567-9900 E: michael.montemurro@siemens.com _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) Sent: June 15, 2005 4:50 PM To: Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Pat, Thanks for your response though it didn't address the issue I was trying to raise. The problem was at my end - rereading my question I realize I wasn't clear enough. My apologies. Let me rephrase my concern though this time in a suggestion manner (rather then challenging specific proposed protocol). In my opinion the CAPWAP protocol shouldn't tie bridging the user's data traffic function to a specific architecture (split or local) and be flexible enough to accommodate all four permutations: Split / MAC & bridging at AC / WTP. As part of the initial configuration phase the AC shall instruct the WTP to either locally bridge data traffic or tunnel to an AC. Regards, Emek _____ From: Pat Calhoun [mailto:pcalhoun@cisco.com] Sent: Wednesday, June 15, 2005 2:17 PM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation My apologies for the latency in my response. Yes, the LWAPP protocol supports what we refer to Local and Split MAC. In Split MAC, the user's traffic is tunneled between the WTP and the AC while in Local MAC the data is locally bridged. Draft 02 of the LWAPP draft does not include enough text to cover the Local MAC case, even though shipping LWAPP products do this today, but we will have this fixed up in -03. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _____ From: Sadot, Emek (Emek) [mailto:esadot@avaya.com] Sent: Tuesday, June 07, 2005 12:35 PM To: Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Pat, A question regarding section 2.1.2 Support for Traffic Separation - author's interpretation of Support for Traffic Separation: does LWAPP supports an architecture in which the DS is implemented at the WTP? (avoid tunneling data frames to a control entity). Regards, Emek _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun Sent: Wednesday, June 01, 2005 10:32 AM To: capwap@frascone.com Subject: [Capwap] LWAPP Self Evaluation draft posted yesterday All, As per the protocol submission rules laid out by the chairs, the authors of the LWAPP protocol submitted a self evaluation to the I-D draft editors yesterday. I have made the draft available at http://www.capwap.org/draft-calhoun-capwap-lwapp-objectives-comparison-00.tx t. Comments welcomed! Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ------=_NextPart_000_0776_01C57284.4C5B5270 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
So if you've had a chance to read the taxonomy=20 recommendations document that I submitted, I think you'll understand = that my=20 argument is that there must be a clear delineation between Split and = Local MAC.=20 A WTP that has all of the MAC, but sends a message to the AC that = encapsulates=20 most of the information found in some 802.11 mac management = packet, then=20 you combine this with tunneling, you end up with something that is=20 identical in fuctionatlity to a Split MAC architecture... but without = the=20 name.
 
I=20 think that we should pick two modes of operation, that are distinct and = address=20 a customer need, and then create a standard to address = them.

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

 

From: capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek=20 (Emek)
Sent: Thursday, June 16, 2005 1:47 PM
To: = Pat=20 Calhoun; Michael Montemurro; capwap@frascone.com
Subject: = RE:=20 [Capwap] Support for Traffic Separation

Pat,=20 I understand where you are coming from and respect it, though I = respectfully=20 disagree with the definition: tunneling of user = data is=20 Split, while local bridging is Local.
 
Emek

From: Pat Calhoun = [mailto:pcalhoun@cisco.com]=20
Sent: Thursday, June 16, 2005 4:58 PM
To: = 'Michael=20 Montemurro'; Sadot, Emek (Emek); = capwap@frascone.com
Subject: RE:=20 [Capwap] Support for Traffic Separation

Emek,
 
Note that I disagree with the need for such = complexity in=20 the protocol, and my belief is this confusion stems from the lack of=20 conclusion in the taxonomy draft. There is simply much more to = tunneling=20 traffic than just the Distribution and Integration Service, so one = must=20 actually be very specific in each case on where every function = resides. My=20 belief is that tunneling of user data is Split, while local bridging = is Local.=20 We have documented this in the Taxonomy Recommendations document, = which I=20 would urge you to comment on.
 

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

 

From: Michael Montemurro=20 [mailto:michael.montemurro@siemens.com]
Sent: Thursday, = June 16,=20 2005 5:35 AM
To: Sadot, Emek (Emek); Pat Calhoun;=20 capwap@frascone.com
Subject: RE: [Capwap] Support for = Traffic=20 Separation

Emek,
 
I just want to get clarification on your = response. You=20 believe there are four possibilities:
 
   =20 1) Split MAC - = Bridge at=20 WTP
   =20 2) Split MAC - = Bridge at=20 AC
   =20 3) Local MAC - = Bridge at=20 WTP
    4) Local MAC - Bridge at AC
 
I'd just like to understand how you = envision case 1).=20  What type of functionality would you envision would terminate = at the=20 AC? Could you be more specific on how you would handle WLAN = management=20 frames, security, and QoS in that case?
 
Thanks,
 
   =20 Mike
 

Michael Montemurro
Director, Advanced = Technology and=20 Standards
Chantry Networks, A Siemens Company
1900 Minnesota = Ct, Suite=20 125
Mississauga, ON, CANADA.
T: 905-363-6413
F: = 905-567-9900
E:=20 michael.montemurro@siemens.com


From: = capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek = (Emek)
Sent: June 15, 2005 4:50 PM
To: Pat = Calhoun;=20 capwap@frascone.com
Subject: RE: [Capwap] Support for = Traffic=20 Separation

Pat,
 
Thanks for your response though it didn't address = the issue I=20 was trying to raise. The problem was at my end = - rereading=20 my question I realize I wasn't clear enough. My apologies. Let me = rephrase=20 my concern though this time in a suggestion manner (rather = then=20 challenging specific proposed protocol).
 
In my opinion the CAPWAP protocol shouldn't tie = bridging the=20 user's data traffic function to a specific architecture = (split or=20 local) and be flexible enough to accommodate all four=20 permutations: Split / MAC & bridging at AC / = WTP.
As part of the initial configuration phase the = AC=20 shall instruct the WTP to either locally bridge data traffic = or=20 tunnel to an AC.
 
Regards,
Emek

From: Pat Calhoun=20 [mailto:pcalhoun@cisco.com]
Sent: Wednesday, June 15, = 2005 2:17=20 PM
To: Sadot, Emek (Emek);=20 capwap@frascone.com
Subject: RE: [Capwap] Support for = Traffic=20 Separation

My apologies for the latency in my=20 response.
 
Yes, the LWAPP protocol supports what we = refer to=20 Local and Split MAC. In Split MAC, the user's traffic is=20 tunneled between the WTP and the AC while in Local MAC the = data is=20 locally bridged. Draft 02 of the LWAPP draft does not include = enough text=20 to cover the Local MAC case, even though shipping LWAPP products = do this=20 today, but we will have this fixed up in = -03.

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

 

From: Sadot, Emek (Emek)=20 [mailto:esadot@avaya.com]
Sent: Tuesday, June 07, = 2005 12:35=20 PM
To: Pat Calhoun; = capwap@frascone.com
Subject: RE:=20 [Capwap] Support for Traffic Separation

Pat,
 
A question regarding=20 section 2.1.2 Support for Traffic = Separation - author's interpretation = of Support for Traffic Separation:=20 does LWAPP supports an architecture in which the DS is = implemented=20 at the WTP? (avoid tunneling data frames to a control=20 entity).
 
Regards,
Emek

From: = capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Pat=20 Calhoun
Sent: Wednesday, June 01, 2005 10:32 = AM
To:=20 capwap@frascone.com
Subject: [Capwap] LWAPP Self = Evaluation=20 draft posted yesterday

All,
 
As per the=20 protocol submission rules laid out by the chairs, the authors of = the=20 LWAPP protocol submitted a self evaluation to the I-D draft = editors=20 yesterday. I have made the draft available at http://www.capwap.org/draft-calhoun-capwap-lwapp-objectives-comp= arison-00.txt.
 
Comments=20 welcomed!
 

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

=
 
------=_NextPart_000_0776_01C57284.4C5B5270-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 16 18:03:12 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19072 for ; Thu, 16 Jun 2005 18:03:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 03D4C20567; Thu, 16 Jun 2005 18:03:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1EC8F20492; Thu, 16 Jun 2005 18:03:09 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8388B2055D for ; Thu, 16 Jun 2005 18:02:30 -0400 (EDT) Received: from typhoon.trangosoft.com (unknown [209.82.51.154]) by mail.frascone.com (Postfix) with ESMTP id 83C7620579 for ; Thu, 16 Jun 2005 18:02:23 -0400 (EDT) Received: from phantom-out.trangosoft.com ([136.157.233.22]) by 136.157.233.32 with trend_isnt_name_B; Thu, 16 Jun 2005 18:03:54 -0400 Received: from troll3.trangosoft.com (troll3.trangosoft.com [136.157.233.13]) by phantom-out.trangosoft.com (Postfix) with ESMTP id C523724FFC; Thu, 16 Jun 2005 17:39:05 -0400 (EDT) Received: by troll3.trangosoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Jun 2005 17:58:24 -0400 Message-ID: <1652EBA28502ED4393B9BC9B8A4B60131643C4@mism121a.toronto.chantrynetworks.com> From: Inderpreet Singh To: "Sadot, Emek (Emek)" , capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C572BF.0EA11F4C" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 16 Jun 2005 18:02:16 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C572BF.0EA11F4C Content-Type: text/plain >>"Further, one must assume that there are functions that reside in the AC that are much more than >>just "tunnel termination", and if this is the case these functions are lost when you resort to bridge >>mode." - I assume you meant that some functionality will be lost if bridging is implemented at the WTP, >>so if that's your argument then the counter argument would be: how these functions being materialized >>in Local MAc arch? If I am not mistaken, this discussion has let to two interpretations of the word "bridging" as well. 1. Emek understands bridging as 802.11 to 802.3 conversion. Which is technically correct, but really confined definition in our context. I think it would be useful to term in 802.11 MAC termination rather than simply bridging. 2. Pat, Mike and I believe that bridging in this context has to do with bridging the user traffic to the local physical interface. Usually this is Ethernet in the WTP case. Non-bridging would be where the traffic is tunneled to the AC. So I agree, if you bridge locally (ie. if the 802.11 MAC is terminated Locally and then the resulting 802.3 packets are bridged to the local physical interface), then it is possible for example to lose the functionality of L3 roaming of the client. However, in certain scenarios of deployments where this function/feature is not needed, local bridging is quite useful. Thanks Inderpreet _____ From: Pat Calhoun [mailto:pcalhoun@cisco.com] Sent: Thursday, June 16, 2005 5:25 PM To: Sadot, Emek (Emek); 'Michael Montemurro'; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation > Giving the operator / customer the freedom to run the IS function in AC or WTP is important and as far as I can tell doesn't > break the CAPWAP model. Why it's important: well take #1 for example, if customer wishes to session to travel along > the shorter path between peers, or maintain existing voice call when AC experience a failover and perform reboot (but new > session or roaming obviously)." Emek, I don't see how this can be achieved. A user's end device has a single IP address. One really cannot split the forwarding of user traffic based on the relative priority of the traffic or based on network failures, because the return path of the user's traffic would always end up on its home subnet. The above suggestion where sometimes the user's traffic is briged and sometimes it is tunneled, would REQUIRE the WTP and the AC to be on the same subnet - which conflicts with the "Interconnection Objective". Further, one must assume that there are functions that reside in the AC that are much more than just "tunnel termination", and if this is the case these functions are lost when you resort to brige mode. If redundancy/resiliency is required, then it must be provided in the CAPWAP protocol through some other means. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) Sent: Thursday, June 16, 2005 5:54 AM To: Michael Montemurro; Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Mike, To make sure I am clear: by "bridge" I was referring to the Integration Services - bridging between 802.11 and 802.3. All management frames (security, QoS, etc.) should be handle by the AC. Giving the operator / customer the freedom to run the IS function in AC or WTP is important and as far as I can tell doesn't break the CAPWAP model. Why it's important: well take #1 for example, if customer wishes to session to travel along the shorter path between peers, or maintain existing voice call when AC experience a failover and perform reboot (but new session or roaming obviously). Emek _____ From: Michael Montemurro [mailto:michael.montemurro@siemens.com] Sent: Thursday, June 16, 2005 3:35 PM To: Sadot, Emek (Emek); Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Emek, I just want to get clarification on your response. You believe there are four possibilities: 1) Split MAC - Bridge at WTP 2) Split MAC - Bridge at AC 3) Local MAC - Bridge at WTP 4) Local MAC - Bridge at AC I'd just like to understand how you envision case 1). What type of functionality would you envision would terminate at the AC? Could you be more specific on how you would handle WLAN management frames, security, and QoS in that case? Thanks, Mike Michael Montemurro Director, Advanced Technology and Standards Chantry Networks, A Siemens Company 1900 Minnesota Ct, Suite 125 Mississauga, ON, CANADA. T: 905-363-6413 F: 905-567-9900 E: michael.montemurro@siemens.com _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) Sent: June 15, 2005 4:50 PM To: Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Pat, Thanks for your response though it didn't address the issue I was trying to raise. The problem was at my end - rereading my question I realize I wasn't clear enough. My apologies. Let me rephrase my concern though this time in a suggestion manner (rather then challenging specific proposed protocol). In my opinion the CAPWAP protocol shouldn't tie bridging the user's data traffic function to a specific architecture (split or local) and be flexible enough to accommodate all four permutations: Split / MAC & bridging at AC / WTP. As part of the initial configuration phase the AC shall instruct the WTP to either locally bridge data traffic or tunnel to an AC. Regards, Emek _____ From: Pat Calhoun [mailto:pcalhoun@cisco.com] Sent: Wednesday, June 15, 2005 2:17 PM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation My apologies for the latency in my response. Yes, the LWAPP protocol supports what we refer to Local and Split MAC. In Split MAC, the user's traffic is tunneled between the WTP and the AC while in Local MAC the data is locally bridged. Draft 02 of the LWAPP draft does not include enough text to cover the Local MAC case, even though shipping LWAPP products do this today, but we will have this fixed up in -03. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _____ From: Sadot, Emek (Emek) [mailto:esadot@avaya.com] Sent: Tuesday, June 07, 2005 12:35 PM To: Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Pat, A question regarding section 2.1.2 Support for Traffic Separation - author's interpretation of Support for Traffic Separation: does LWAPP supports an architecture in which the DS is implemented at the WTP? (avoid tunneling data frames to a control entity). Regards, Emek _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun Sent: Wednesday, June 01, 2005 10:32 AM To: capwap@frascone.com Subject: [Capwap] LWAPP Self Evaluation draft posted yesterday All, As per the protocol submission rules laid out by the chairs, the authors of the LWAPP protocol submitted a self evaluation to the I-D draft editors yesterday. I have made the draft available at http://www.capwap.org/draft-calhoun-capwap-lwapp-objectives-comparison-00.tx t. Comments welcomed! Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ------_=_NextPart_001_01C572BF.0EA11F4C Content-Type: text/html

 

>>"Further, one must assume that there are functions that reside in the AC that are much more than

>>just "tunnel termination", and if this is the case these functions are lost when you resort to bridge

>>mode." - I assume you meant that some functionality will be lost if bridging is implemented at the WTP,

>>so if that's your argument then the counter argument would be: how these functions being materialized

>>in Local MAc arch?

 

If I am not mistaken, this discussion has let to two interpretations of the word “bridging” as well.

 

  1. Emek understands bridging as 802.11 to 802.3 conversion.  Which is technically correct, but really confined definition in our context.  I think it would be useful to term in 802.11 MAC termination rather than simply bridging.
  2. Pat, Mike and I believe that bridging in this context has to do with bridging the user traffic to the local physical interface.  Usually this is Ethernet in the WTP case.  Non-bridging would be where the traffic is tunneled to the AC.

 

So I agree, if you bridge locally (ie. if the 802.11 MAC is terminated Locally and then the resulting 802.3 packets are bridged to the local physical interface), then it is possible for example to lose the functionality of L3 roaming of the client.  However, in certain scenarios of deployments where this function/feature is not needed, local bridging is quite useful.

 

Thanks

 

Inderpreet

 

From: Pat Calhoun [mailto:pcalhoun@cisco.com]
Sent: Thursday, June 16, 2005 5:25 PM
To: Sadot, Emek (Emek); 'Michael Montemurro'; capwap@frascone.com
Subject: RE: [Capwap] Support for Traffic Separation

> Giving the operator / customer the freedom to run the IS function in AC or WTP is important and as far as I can tell doesn't

> break the CAPWAP model. Why it's important: well take #1 for example, if customer wishes to session to travel along

> the shorter path between peers, or maintain existing voice call when AC experience a failover and perform reboot (but new

> session or roaming obviously)."

 

Emek, I don't see how this can be achieved. A user's end device has a single IP address. One really cannot split the forwarding of user traffic based on the relative priority of the traffic or based on network failures, because the return path of the user's traffic would always end up on its home subnet. The above suggestion where sometimes the user's traffic is briged and sometimes it is tunneled, would REQUIRE the WTP and the AC to be on the same subnet - which conflicts with the "Interconnection Objective". Further, one must assume that there are functions that reside in the AC that are much more than just "tunnel termination", and if this is the case these functions are lost when you resort to brige mode.

 

If redundancy/resiliency is required, then it must be provided in the CAPWAP protocol through some other means.

 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

 

From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek)
Sent: Thursday, June 16, 2005 5:54 AM
To: Michael Montemurro; Pat Calhoun; capwap@frascone.com
Subject: RE: [Capwap] Support for Traffic Separation

Mike,

 

To make sure I am clear: by "bridge" I was referring to the Integration Services -  bridging between 802.11 and 802.3.

All management frames (security, QoS, etc.) should be handle by the AC.

 

Giving the operator / customer the freedom to run the IS function in AC or WTP is important and as far as I can tell doesn't break the CAPWAP model.

Why it's important: well take #1 for example, if customer wishes to session to travel along the shorter path between peers, or maintain existing voice call when AC experience a failover and perform reboot (but new session or roaming obviously).

 

Emek

 

From: Michael Montemurro [mailto:michael.montemurro@siemens.com]
Sent: Thursday, June 16, 2005 3:35 PM
To: Sadot, Emek (Emek); Pat Calhoun; capwap@frascone.com
Subject: RE: [Capwap] Support for Traffic Separation

Emek,

 

I just want to get clarification on your response. You believe there are four possibilities:

 

    1) Split MAC - Bridge at WTP

    2) Split MAC - Bridge at AC

    3) Local MAC - Bridge at WTP

    4) Local MAC - Bridge at AC

 

I'd just like to understand how you envision case 1).  What type of functionality would you envision would terminate at the AC? Could you be more specific on how you would handle WLAN management frames, security, and QoS in that case?

 

Thanks,

 

    Mike

 

Michael Montemurro
Director, Advanced Technology and Standards
Chantry Networks, A Siemens Company
1900 Minnesota Ct, Suite 125
Mississauga, ON, CANADA.
T: 905-363-6413
F: 905-567-9900
E: michael.montemurro@siemens.com

 

From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek)
Sent: June 15, 2005 4:50 PM
To: Pat Calhoun; capwap@frascone.com
Subject: RE: [Capwap] Support for Traffic Separation

Pat,

 

Thanks for your response though it didn't address the issue I was trying to raise. The problem was at my end - rereading my question I realize I wasn't clear enough. My apologies. Let me rephrase my concern though this time in a suggestion manner (rather then challenging specific proposed protocol).

 

In my opinion the CAPWAP protocol shouldn't tie bridging the user's data traffic function to a specific architecture (split or local) and be flexible enough to accommodate all four permutations: Split / MAC & bridging at AC / WTP.

As part of the initial configuration phase the AC shall instruct the WTP to either locally bridge data traffic or tunnel to an AC.

 

Regards,

Emek

 

From: Pat Calhoun [mailto:pcalhoun@cisco.com]
Sent: Wednesday, June 15, 2005 2:17 PM
To: Sadot, Emek (Emek); capwap@frascone.com
Subject: RE: [Capwap] Support for Traffic Separation

My apologies for the latency in my response.

 

Yes, the LWAPP protocol supports what we refer to Local and Split MAC. In Split MAC, the user's traffic is tunneled between the WTP and the AC while in Local MAC the data is locally bridged. Draft 02 of the LWAPP draft does not include enough text to cover the Local MAC case, even though shipping LWAPP products do this today, but we will have this fixed up in -03.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

 

From: Sadot, Emek (Emek) [mailto:esadot@avaya.com]
Sent: Tuesday, June 07, 2005 12:35 PM
To: Pat Calhoun; capwap@frascone.com
Subject: RE: [Capwap] Support for Traffic Separation

Pat,

 

A question regarding section 2.1.2 Support for Traffic Separation - author's interpretation of Support for Traffic Separation: does LWAPP supports an architecture in which the DS is implemented at the WTP? (avoid tunneling data frames to a control entity).

 

Regards,

Emek

 

From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun
Sent: Wednesday, June 01, 2005 10:32 AM
To: capwap@frascone.com
Subject: [Capwap] LWAPP Self Evaluation draft posted yesterday

All,

 

As per the protocol submission rules laid out by the chairs, the authors of the LWAPP protocol submitted a self evaluation to the I-D draft editors yesterday. I have made the draft available at http://www.capwap.org/draft-calhoun-capwap-lwapp-objectives-comparison-00.txt.

 

Comments welcomed!

 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

------_=_NextPart_001_01C572BF.0EA11F4C-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 16 18:49:09 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23345 for ; Thu, 16 Jun 2005 18:49:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9A40620566; Thu, 16 Jun 2005 18:49:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9CF442045F; Thu, 16 Jun 2005 18:49:08 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 623B92045F for ; Thu, 16 Jun 2005 18:48:29 -0400 (EDT) Received: from mx.sj.symbol.com (mx.sj.symbol.com [65.115.69.195]) by mail.frascone.com (Postfix) with ESMTP id 0BD0F2037A for ; Thu, 16 Jun 2005 18:48:27 -0400 (EDT) Received: from gwianameserver.sj.symbol.com (gwianameserver.sj.symbol.com [157.235.95.252]) by mx.sj.symbol.com (8.12.10/8.12.10) with ESMTP id j5GMZDDq020653 for ; Thu, 16 Jun 2005 15:35:13 -0700 Received: from SJ-DOM-MTA by gwianameserver.sj.symbol.com with Novell_GroupWise; Thu, 16 Jun 2005 15:48:25 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.4 From: "Clint Chaplin" To: , , Cc: Subject: RE: [Capwap] Taxonomy Recommendations: encrypt/decrypt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 16 Jun 2005 15:48:16 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable There is one issue in how to split the "split architecture" that will be = somewhat contentious in generating a standard for CAPWAP. That issue is: = who handles the 802.11i encryption decryption? There is already in the = market from major vendors equipment that falls on both sides of this = division. If the CAPWAP standard is to be inclusive with existing = architectural decisions, this one is going to have to be thrashed out. In = my opinion, the correct answer should be: both are supported. Clint (JOATMON) Chaplin Wireless Security Advisor Wireless Standards Manager >>> "Mani, Mahalingam (Mahalingam)" 6/16/05 07:13:18 >>> I have no objections to this 'bug-fix' if it can happen in time and has no author/WG objections. We can request the RFC Ed. to hold off. As for the other issue on split-MAC interpretation: The split-discussion is long overdue; and is worth having - to help evaluation as well. I think resolution of the discussion is important to arrive at the best approach to CAPWAP protocol accommodating/not split variants. History: We had clearly noted not to make any recommendations on what a split characteristic must be in the taxonomy. This has perhaps been argued many times in (taxonomy) design team and in IETF58-62 as well. There was no scope for us in the then charter to venture that way. When APF AHC initially started its work - the hope was it would offer enough information for CAPWAP to draw conclusions for future work; there were no expectations on what they would recommend the split ought to be once they were chartered (there were hopes much prior to that). Inasmuch as IEEE 802.11 endorsed and acknowledged the documented splits caused no standards departure/breakage in implementation or behavior - by its review of the taxonomy draft - we had validated all architectures from IEEE 802.11 perspective. It was clear when APF AHC group was formed that it will transpire to provide only clarifying interpretations of functions - not delineate or standardize splits. -mani =3D=3D=3D=3D=3D=3D -----Original Message----- From: Yang, Lily L [mailto:lily.l.yang@intel.com]=20 Sent: Wednesday, June 15, 2005 1:19 PM To: Mani, Mahalingam (Mahalingam); Pat Calhoun Cc: capwap@frascone.com=20 Subject: RE: [Capwap] Taxonomy Recommendations Hi, Pat and Mani -- I have not read through the entire Taxonomy Recommendations document yet, but just reading through the first few pages, I believe the authors are correct in pointing out one of the "inconsistency" (error) in the taxonomy draft. There was a paragraph in the taxonomy draft Section 5.6: " The commonalities and differences between Local MAC and Split MAC are most clearly seen by comparing Figure 7 to Figure 10. The commonality is that 802.11 control frames are terminated at WTPs in both cases. The main difference between Local MAC and Split MAC is that the WTP terminates only the 802.11 control frames in the Split MAC, while the WTP may terminate all 802.11 frames in the Local MAC. An interesting consequence of this difference is that the Integration Service, which essentially refers to bridging between 802.11 and 802.3 frames, is implemented by the AC in the Split MAC, but can be part of either the AC or WTP in the Local MAC." The last sentence, as pointed out by Pat, Bob and Inderpreet's document, was incorrect. According to Figure 9, Integration Service, for all the parties classified as Local MAC, is implemented by WTP.=20 Given that we still have about 3 hours remaining in the authors' 48 hour window, I would like to send a note to RFC Editor suggesting the following sentence to replace the last sentence in the paragraph: "An interesting consequence of this difference is that the Integration Service, which essentially refers to bridging between 802.11 and 802.3 frames, is implemented by the AC in the Split MAC and by the WTP in the Local MAC, as shown in Figure 9 and Figure 12." Glaring as it is, I believe this error does not carry any far reaching implication to the entire document and hence it is bug we can fix right now. Regarding the comment from the authors that taxonomy draft lacks conclusion and recommendation and hence the motivation to take it further to clearly define what Local and Split MAC really mean in terms of functional split -- I think that is a fair comment -- Personally I was tempted to take that step in the taxonomy draft with the intention to help the WG moving forward, but as the editor of the draft, I received clear instruction from the chairs and the WG that a taxonomy only goes so far to "document" the reality of the market, not to "define" any architectures. So the draft deliberately didn't go far into making any specific functional split recommendation. As I advocated in both July and Nov IETF meeting last year, I believe there is indeed a gap between taxonomy draft and objective draft -- the WG needs a clear definition of the functional split for Local, especially Split MAC, but that is not the charter of either taxonomy draft or Objective draft. Some people have the illusion that IEEE 802.11 (specifically the APF ad hoc group) will provide such definition. The clear answer there is NO, IEEE would not do that. It is up to us in this group to agree on the split and move on. So if indeed this Taxonomy Recommendation draft fulfills this purpose, I personally believe it is a very necessary step to take in order to move forward. However, as I said, I have not reviewed the entire document yet and so I would reserve until then to offer any further comments. But I do want to fix the error in Section 5.6 in Taxonomy draft NOW.=20 Lily -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Mani, Mahalingam (Mahalingam) Sent: Wednesday, June 15, 2005 11:14 AM To: Pat Calhoun; capwap@frascone.com=20 Subject: RE: [Capwap] Taxonomy Recommendations Thanks for the joint effort (by authors of two candidate protocols for eval. as I see it) in making a case for clarification of terminology. If the changes and clarifications proposed are extensive - comments in form of I-D is useful to place-hold them. The WG should (especially the original taxonomy team authors) comment on these comments (draft): WG has approved the -06 version of the taxonomy draft. Two of the authors are in this as well :) It is also important to understand the implications, if any, (on Objectives draft) if WG agrees to any of the proposed clarifications. It may turn out to be transparent to the Objectives draft. This needs to happen soon for Objectives to freeze and let the evaluation team use a baselined version. [BTW: the taxonomy draft is in RFC editor's queue - actually just completed AUTH48]. -mani =3D=3D=3D=3D=3D=3D -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun Sent: Thursday, June 09, 2005 2:28 PM To: capwap@frascone.com=20 Subject: [Capwap] Taxonomy Recommendations All, =20 I wanted to announce the early availability of the CAPWAP taxonomy recommendation draft that Bob O'Hara Inderpreet Singh and I have been working on. It can be found at http://www.capwap.org/draft-calhoun-capwap-taxonomy-recommendation-00.tx=20= t. Abstract The IETF's CAPWAP working group has documented various product architectures and has categorized the Centralized WLAN Architectures into two main buckets: Split and Local MAC. While the document contains very relevant and useful information, what it does is list the architectural variants of these two buckets, but does not unambiguously define either the Split MAC or Local MAC architectures. In order for CAPWAP to be successful, it is crucial for the protocol evaluation team, and the working group, to agree on unambiguous terminology to describe these architectures. This document proposes terminology to unambiguously describe the relevant architectures found in the taxonomy document, for the purpose of initiating a discussion within the working group and to allow the protocol evaluation work to come to a fruitful conclusion. We conclude in this document that the architectures are very similar and could be supported via a single protocol. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _______________________________________________ Capwap mailing list Capwap@frascone.com=20 http://mail.frascone.com/mailman/listinfo/capwap=20 _______________________________________________ Capwap mailing list Capwap@frascone.com=20 http://mail.frascone.com/mailman/listinfo/capwap=20 _______________________________________________ Capwap mailing list Capwap@frascone.com=20 http://mail.frascone.com/mailman/listinfo/capwap=20 ________________________________________________________________________ This email has been scanned for computer viruses. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 16 19:02:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24345 for ; Thu, 16 Jun 2005 19:02:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C92032055D; Thu, 16 Jun 2005 19:02:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 157672037A; Thu, 16 Jun 2005 19:02:08 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 017472037A for ; Thu, 16 Jun 2005 19:01:53 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id E714720369 for ; Thu, 16 Jun 2005 19:01:51 -0400 (EDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 16 Jun 2005 16:01:50 -0700 X-IronPort-AV: i="3.93,205,1115017200"; d="scan'208"; a="279749660:sNHT32090174" Received: from pacalhouwxp ([10.32.30.113]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5GN1jQ3012379; Thu, 16 Jun 2005 16:01:45 -0700 (PDT) Message-Id: <200506162301.j5GN1jQ3012379@sj-core-1.cisco.com> From: "Pat Calhoun" To: "'Clint Chaplin'" , , Cc: Subject: RE: [Capwap] Taxonomy Recommendations: encrypt/decrypt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVyxawE2SB7ZDG9SXKXLH2WL/XSUAAAVyMA In-Reply-To: X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.30.113] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 16 Jun 2005 16:01:43 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Clint, while I am OK with the proposed approach you are stating as long as CAPWAP's statement is clear that centralized encryption can be done either in the WTP or the AC, but the latter cannot work w/ HCCA. From a procedural standpoint, I can make changes to the taxonomy recommendations document, or the chairs can find another medium on which to document this. Either way works for me. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Clint Chaplin [mailto:cchaplin@sj.symbol.com] > Sent: Thursday, June 16, 2005 3:48 PM > To: mmani@avaya.com; pcalhoun@cisco.com; lily.l.yang@intel.com > Cc: capwap@frascone.com > Subject: RE: [Capwap] Taxonomy Recommendations: encrypt/decrypt > > There is one issue in how to split the "split architecture" > that will be somewhat contentious in generating a standard > for CAPWAP. That issue is: who handles the 802.11i > encryption decryption? There is already in the market from > major vendors equipment that falls on both sides of this > division. If the CAPWAP standard is to be inclusive with > existing architectural decisions, this one is going to have > to be thrashed out. In my opinion, the correct answer should > be: both are supported. > > Clint (JOATMON) Chaplin > Wireless Security Advisor > Wireless Standards Manager > > >>> "Mani, Mahalingam (Mahalingam)" 6/16/05 > 07:13:18 > >>> >>> > I have no objections to this 'bug-fix' if it can happen in > time and has no author/WG objections. We can request the RFC > Ed. to hold off. > > As for the other issue on split-MAC interpretation: > The split-discussion is long overdue; and is worth having - > to help evaluation as well. I think resolution of the > discussion is important to arrive at the best approach to > CAPWAP protocol accommodating/not split variants. > > History: > We had clearly noted not to make any recommendations on what > a split characteristic must be in the taxonomy. This has > perhaps been argued many times in (taxonomy) design team and > in IETF58-62 as well. There was no scope for us in the then > charter to venture that way. > > When APF AHC initially started its work - the hope was it > would offer enough information for CAPWAP to draw conclusions > for future work; there were no expectations on what they > would recommend the split ought to be once they were > chartered (there were hopes much prior to that). Inasmuch as > IEEE 802.11 endorsed and acknowledged the documented splits > caused no standards departure/breakage in implementation or > behavior - by its review of the taxonomy draft - we had > validated all architectures from IEEE 802.11 perspective. > > It was clear when APF AHC group was formed that it will > transpire to provide only clarifying interpretations of > functions - not delineate or standardize splits. > > -mani > ====== > -----Original Message----- > From: Yang, Lily L [mailto:lily.l.yang@intel.com] > Sent: Wednesday, June 15, 2005 1:19 PM > To: Mani, Mahalingam (Mahalingam); Pat Calhoun > Cc: capwap@frascone.com > Subject: RE: [Capwap] Taxonomy Recommendations > > > Hi, Pat and Mani -- > > I have not read through the entire Taxonomy Recommendations > document yet, but just reading through the first few pages, I > believe the authors are correct in pointing out one of the > "inconsistency" (error) in the taxonomy draft. There was a > paragraph in the taxonomy draft Section 5.6: > " The commonalities and differences between Local MAC and > Split MAC are > most clearly seen by comparing Figure 7 to Figure 10. The > commonality is that 802.11 control frames are terminated at WTPs in > both cases. The main difference between Local MAC and Split MAC is > that the WTP terminates only the 802.11 control frames in the Split > MAC, while the WTP may terminate all 802.11 frames in the > Local MAC. > An interesting consequence of this difference is that the > Integration > Service, which essentially refers to bridging between 802.11 and > 802.3 frames, is implemented by the AC in the Split MAC, but can be > part of either the AC or WTP in the Local MAC." > The last sentence, as pointed out by Pat, Bob and > Inderpreet's document, was incorrect. According to Figure 9, > Integration Service, for all the parties classified as Local > MAC, is implemented by WTP. > Given that we still have about 3 hours remaining in the > authors' 48 hour window, I would like to send a note to RFC > Editor suggesting the following sentence to replace the last > sentence in the paragraph: > "An interesting consequence of this difference is that the Integration > Service, which essentially refers to bridging between 802.11 and > 802.3 frames, is implemented by the AC in the Split MAC > and by the WTP in the Local MAC, as shown in Figure 9 and Figure 12." > > Glaring as it is, I believe this error does not carry any far > reaching implication to the entire document and hence it is > bug we can fix right now. > > Regarding the comment from the authors that taxonomy draft > lacks conclusion and recommendation and hence the motivation > to take it further to clearly define what Local and Split MAC > really mean in terms of functional split -- I think that is a > fair comment -- Personally I was tempted to take that step in > the taxonomy draft with the intention to help the WG moving > forward, but as the editor of the draft, I received clear > instruction from the chairs and the WG that a taxonomy only > goes so far to "document" the reality of the market, not to > "define" any architectures. So the draft deliberately didn't > go far into making any specific functional split recommendation. > > As I advocated in both July and Nov IETF meeting last year, I > believe there is indeed a gap between taxonomy draft and > objective draft -- the WG needs a clear definition of the > functional split for Local, especially Split MAC, but that is > not the charter of either taxonomy draft or Objective draft. > Some people have the illusion that IEEE 802.11 (specifically > the APF ad hoc group) will provide such definition. The clear > answer there is NO, IEEE would not do that. It is up to us in > this group to agree on the split and move on. So if indeed > this Taxonomy Recommendation draft fulfills this purpose, I > personally believe it is a very necessary step to take in > order to move forward. However, as I said, I have not > reviewed the entire document yet and so I would reserve until > then to offer any further comments. > > But I do want to fix the error in Section 5.6 in Taxonomy draft NOW. > > Lily > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Mani, > Mahalingam (Mahalingam) > Sent: Wednesday, June 15, 2005 11:14 AM > To: Pat Calhoun; capwap@frascone.com > Subject: RE: [Capwap] Taxonomy Recommendations > > Thanks for the joint effort (by authors of two candidate > protocols for eval. as I see it) in making a case for > clarification of terminology. > > If the changes and clarifications proposed are extensive - > comments in form of I-D is useful to place-hold them. > > The WG should (especially the original taxonomy team authors) > comment on these comments (draft): WG has approved the -06 > version of the taxonomy draft. Two of the authors are in this > as well :) > > It is also important to understand the implications, if any, > (on Objectives draft) if WG agrees to any of the proposed > clarifications. It may turn out to be transparent to the > Objectives draft. This needs to happen soon for Objectives to > freeze and let the evaluation team use a baselined version. > > [BTW: the taxonomy draft is in RFC editor's queue - actually > just completed AUTH48]. > > -mani > ====== > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun > Sent: Thursday, June 09, 2005 2:28 PM > To: capwap@frascone.com > Subject: [Capwap] Taxonomy Recommendations > > All, > > I wanted to announce the early availability of the CAPWAP > taxonomy recommendation draft that Bob O'Hara Inderpreet > Singh and I have been working on. It can be found at > http://www.capwap.org/draft-calhoun-capwap-taxonomy-recommenda > tion-00.tx > t. > > > Abstract > > The IETF's CAPWAP working group has documented various product > architectures and has categorized the Centralized WLAN > Architectures > into two main buckets: Split and Local MAC. While the document > contains very relevant and useful information, what it does is list > the architectural variants of these two buckets, but does not > unambiguously define either the Split MAC or Local MAC > architectures. > In order for CAPWAP to be successful, it is crucial for > the protocol > evaluation team, and the working group, to agree on unambiguous > terminology to describe these architectures. > > This document proposes terminology to unambiguously describe the > relevant architectures found in the taxonomy document, for the > purpose of initiating a discussion within the working group and to > allow the protocol evaluation work to come to a fruitful > conclusion. > We conclude in this document that the architectures are > very similar > and could be supported via a single protocol. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > ______________________________________________________________ > __________ > This email has been scanned for computer viruses. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 16 19:39:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26854 for ; Thu, 16 Jun 2005 19:39:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7771D20576; Thu, 16 Jun 2005 19:39:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1B6072045F; Thu, 16 Jun 2005 19:39:08 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3D9ED2045F for ; Thu, 16 Jun 2005 19:38:08 -0400 (EDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by mail.frascone.com (Postfix) with ESMTP id 33F7320369 for ; Thu, 16 Jun 2005 19:38:05 -0400 (EDT) Received: by wproxy.gmail.com with SMTP id 71so764690wra for ; Thu, 16 Jun 2005 16:38:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tY10xbjyeNXCKP+ub6LRkaFuGw6UhgXPweELCIsBhMQ65oTe5532L9vwLlPibUnvNfVjBb9HJ1hNjshwTetVsLFGJ3oGdI2KB/qxVJ3wGmbH1z4z3euQO9t+l30uIkOO1TkXs7RsjsKThRPnGV58RfPqReAWUs8dmuWFE2IPyow= Received: by 10.54.51.26 with SMTP id y26mr931134wry; Thu, 16 Jun 2005 16:38:05 -0700 (PDT) Received: by 10.54.140.4 with HTTP; Thu, 16 Jun 2005 16:38:05 -0700 (PDT) Message-ID: From: Chris Hinsz Reply-To: Chris Hinsz To: capwap@frascone.com Subject: Re: [Capwap] Taxonomy Recommendations: encrypt/decrypt In-Reply-To: <200506162301.j5GN1jQ3012379@sj-core-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200506162301.j5GN1jQ3012379@sj-core-1.cisco.com> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 16 Jun 2005 16:38:05 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Pat, I'm a bit confused by the end of your first paragraph: > CAPWAP's statement is clear that centralized encryption can be done eithe= r > in the WTP or the AC, but the latter cannot work w/ HCCA. First thing that confuses me, if the encryption is at the WTP, then it's not centralized, this statement seems to imply that it is.=20 Second, you note that encryption at the AC won't work with HCCA. I was not aware of this limitation. I freely admit that I am not a TGe expert, the access mechanism seems like it would be orthogonal to encryption. What is it about HCCA that effects the location of encryption? CSH On 6/16/05, Pat Calhoun wrote: > Clint, while I am OK with the proposed approach you are stating as long a= s > CAPWAP's statement is clear that centralized encryption can be done eithe= r > in the WTP or the AC, but the latter cannot work w/ HCCA. >=20 > From a procedural standpoint, I can make changes to the taxonomy > recommendations document, or the chairs can find another medium on which = to > document this. Either way works for me. >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems >=20 >=20 >=20 > > -----Original Message----- > > From: Clint Chaplin [mailto:cchaplin@sj.symbol.com] > > Sent: Thursday, June 16, 2005 3:48 PM > > To: mmani@avaya.com; pcalhoun@cisco.com; lily.l.yang@intel.com > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] Taxonomy Recommendations: encrypt/decrypt > > > > There is one issue in how to split the "split architecture" > > that will be somewhat contentious in generating a standard > > for CAPWAP. That issue is: who handles the 802.11i > > encryption decryption? There is already in the market from > > major vendors equipment that falls on both sides of this > > division. If the CAPWAP standard is to be inclusive with > > existing architectural decisions, this one is going to have > > to be thrashed out. In my opinion, the correct answer should > > be: both are supported. > > > > Clint (JOATMON) Chaplin > > Wireless Security Advisor > > Wireless Standards Manager > > > > >>> "Mani, Mahalingam (Mahalingam)" 6/16/05 > > 07:13:18 > > >>> >>> > > I have no objections to this 'bug-fix' if it can happen in > > time and has no author/WG objections. We can request the RFC > > Ed. to hold off. > > > > As for the other issue on split-MAC interpretation: > > The split-discussion is long overdue; and is worth having - > > to help evaluation as well. I think resolution of the > > discussion is important to arrive at the best approach to > > CAPWAP protocol accommodating/not split variants. > > > > History: > > We had clearly noted not to make any recommendations on what > > a split characteristic must be in the taxonomy. This has > > perhaps been argued many times in (taxonomy) design team and > > in IETF58-62 as well. There was no scope for us in the then > > charter to venture that way. > > > > When APF AHC initially started its work - the hope was it > > would offer enough information for CAPWAP to draw conclusions > > for future work; there were no expectations on what they > > would recommend the split ought to be once they were > > chartered (there were hopes much prior to that). Inasmuch as > > IEEE 802.11 endorsed and acknowledged the documented splits > > caused no standards departure/breakage in implementation or > > behavior - by its review of the taxonomy draft - we had > > validated all architectures from IEEE 802.11 perspective. > > > > It was clear when APF AHC group was formed that it will > > transpire to provide only clarifying interpretations of > > functions - not delineate or standardize splits. > > > > -mani > > =3D=3D=3D=3D=3D=3D > > -----Original Message----- > > From: Yang, Lily L [mailto:lily.l.yang@intel.com] > > Sent: Wednesday, June 15, 2005 1:19 PM > > To: Mani, Mahalingam (Mahalingam); Pat Calhoun > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] Taxonomy Recommendations > > > > > > Hi, Pat and Mani -- > > > > I have not read through the entire Taxonomy Recommendations > > document yet, but just reading through the first few pages, I > > believe the authors are correct in pointing out one of the > > "inconsistency" (error) in the taxonomy draft. There was a > > paragraph in the taxonomy draft Section 5.6: > > " The commonalities and differences between Local MAC and > > Split MAC are > > most clearly seen by comparing Figure 7 to Figure 10. The > > commonality is that 802.11 control frames are terminated at WTPs in > > both cases. The main difference between Local MAC and Split MAC is > > that the WTP terminates only the 802.11 control frames in the Split > > MAC, while the WTP may terminate all 802.11 frames in the > > Local MAC. > > An interesting consequence of this difference is that the > > Integration > > Service, which essentially refers to bridging between 802.11 and > > 802.3 frames, is implemented by the AC in the Split MAC, but can be > > part of either the AC or WTP in the Local MAC." > > The last sentence, as pointed out by Pat, Bob and > > Inderpreet's document, was incorrect. According to Figure 9, > > Integration Service, for all the parties classified as Local > > MAC, is implemented by WTP. > > Given that we still have about 3 hours remaining in the > > authors' 48 hour window, I would like to send a note to RFC > > Editor suggesting the following sentence to replace the last > > sentence in the paragraph: > > "An interesting consequence of this difference is that the Integration > > Service, which essentially refers to bridging between 802.11 and > > 802.3 frames, is implemented by the AC in the Split MAC > > and by the WTP in the Local MAC, as shown in Figure 9 and Figure 12." > > > > Glaring as it is, I believe this error does not carry any far > > reaching implication to the entire document and hence it is > > bug we can fix right now. > > > > Regarding the comment from the authors that taxonomy draft > > lacks conclusion and recommendation and hence the motivation > > to take it further to clearly define what Local and Split MAC > > really mean in terms of functional split -- I think that is a > > fair comment -- Personally I was tempted to take that step in > > the taxonomy draft with the intention to help the WG moving > > forward, but as the editor of the draft, I received clear > > instruction from the chairs and the WG that a taxonomy only > > goes so far to "document" the reality of the market, not to > > "define" any architectures. So the draft deliberately didn't > > go far into making any specific functional split recommendation. > > > > As I advocated in both July and Nov IETF meeting last year, I > > believe there is indeed a gap between taxonomy draft and > > objective draft -- the WG needs a clear definition of the > > functional split for Local, especially Split MAC, but that is > > not the charter of either taxonomy draft or Objective draft. > > Some people have the illusion that IEEE 802.11 (specifically > > the APF ad hoc group) will provide such definition. The clear > > answer there is NO, IEEE would not do that. It is up to us in > > this group to agree on the split and move on. So if indeed > > this Taxonomy Recommendation draft fulfills this purpose, I > > personally believe it is a very necessary step to take in > > order to move forward. However, as I said, I have not > > reviewed the entire document yet and so I would reserve until > > then to offer any further comments. > > > > But I do want to fix the error in Section 5.6 in Taxonomy draft NOW. > > > > Lily > > -----Original Message----- > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Mani, > > Mahalingam (Mahalingam) > > Sent: Wednesday, June 15, 2005 11:14 AM > > To: Pat Calhoun; capwap@frascone.com > > Subject: RE: [Capwap] Taxonomy Recommendations > > > > Thanks for the joint effort (by authors of two candidate > > protocols for eval. as I see it) in making a case for > > clarification of terminology. > > > > If the changes and clarifications proposed are extensive - > > comments in form of I-D is useful to place-hold them. > > > > The WG should (especially the original taxonomy team authors) > > comment on these comments (draft): WG has approved the -06 > > version of the taxonomy draft. Two of the authors are in this > > as well :) > > > > It is also important to understand the implications, if any, > > (on Objectives draft) if WG agrees to any of the proposed > > clarifications. It may turn out to be transparent to the > > Objectives draft. This needs to happen soon for Objectives to > > freeze and let the evaluation team use a baselined version. > > > > [BTW: the taxonomy draft is in RFC editor's queue - actually > > just completed AUTH48]. > > > > -mani > > =3D=3D=3D=3D=3D=3D > > -----Original Message----- > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun > > Sent: Thursday, June 09, 2005 2:28 PM > > To: capwap@frascone.com > > Subject: [Capwap] Taxonomy Recommendations > > > > All, > > > > I wanted to announce the early availability of the CAPWAP > > taxonomy recommendation draft that Bob O'Hara Inderpreet > > Singh and I have been working on. It can be found at > > http://www.capwap.org/draft-calhoun-capwap-taxonomy-recommenda > > tion-00.tx > > t. > > > > > > Abstract > > > > The IETF's CAPWAP working group has documented various product > > architectures and has categorized the Centralized WLAN > > Architectures > > into two main buckets: Split and Local MAC. While the document > > contains very relevant and useful information, what it does is list > > the architectural variants of these two buckets, but does not > > unambiguously define either the Split MAC or Local MAC > > architectures. > > In order for CAPWAP to be successful, it is crucial for > > the protocol > > evaluation team, and the working group, to agree on unambiguous > > terminology to describe these architectures. > > > > This document proposes terminology to unambiguously describe the > > relevant architectures found in the taxonomy document, for the > > purpose of initiating a discussion within the working group and to > > allow the protocol evaluation work to come to a fruitful > > conclusion. > > We conclude in this document that the architectures are > > very similar > > and could be supported via a single protocol. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > > > ______________________________________________________________ > > __________ > > This email has been scanned for computer viruses. > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 16 19:45:15 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27020 for ; Thu, 16 Jun 2005 19:45:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 190A320583; Thu, 16 Jun 2005 19:45:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 49D922045F; Thu, 16 Jun 2005 19:45:09 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 164E32045F for ; Thu, 16 Jun 2005 19:44:47 -0400 (EDT) Received: from smtp4.centerbeam.com (smtp4.centerbeam.com [63.120.115.248]) by mail.frascone.com (Postfix) with ESMTP id 9F0B820369 for ; Thu, 16 Jun 2005 19:44:45 -0400 (EDT) Received: from CBA0E2K01.CBA0.centerbeam.com ([64.95.101.24]) by smtp4.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 16:46:06 -0700 Received: from CBA0E2K06.CBA0.centerbeam.com ([64.95.101.40]) by CBA0E2K01.CBA0.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 16:44:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C572CD.58DB514F" Subject: RE: [Capwap] Support for Traffic Separation Message-ID: Thread-Topic: [Capwap] Support for Traffic Separation Thread-Index: AcVyv0Q9lzN8dWOqQWi8yNxovbTMLAAC7bzA From: "Darren Loher" To: "Inderpreet Singh" , "Sadot, Emek (Emek)" , X-OriginalArrivalTime: 16 Jun 2005 23:44:33.0491 (UTC) FILETIME=[58E0B230:01C572CD] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 16 Jun 2005 16:44:31 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C572CD.58DB514F Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Given the following scenarios: =20 1) Split MAC - Bridge at WTP =20 2) Split MAC - Bridge at AC 3) Local MAC - Bridge at WTP 4) Local MAC - Bridge at AC =20 I agree that #2-4 are required scenarios. I am not sure that #1 is required. If "bridge" means the IS function, #1 would be in conflict with the recent error correction/update of the taxonomy document. =20 When the IS function is implemented at the WTP, the WTP must be a local MAC WTP. However, in a local MAC scenario the CAPWAP protocol must still permit tunneling or not tunneling user traffic to an AC. A particular WTP device may not support this function, but the CAPWAP protocol MUST allow it (IMHO). This would be compatible with the new update/error correction to the taxonomy document and gives flexibility for implementers to create traffic separation if they choose in split and local MAC modes. =20 What does everyone think? (did I miss anything?) =20 -Darren =20 =20 ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Inderpreet Singh Sent: Thursday, June 16, 2005 4:02 PM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation =20 =20 >>"Further, one must assume that there are functions that reside in the AC that are much more than=20 >>just "tunnel termination", and if this is the case these functions are lost when you resort to bridge=20 >>mode." - I assume you meant that some functionality will be lost if bridging is implemented at the WTP,=20 >>so if that's your argument then the counter argument would be: how these functions being materialized=20 >>in Local MAc arch? =20 If I am not mistaken, this discussion has let to two interpretations of the word "bridging" as well. =20 1. Emek understands bridging as 802.11 to 802.3 conversion. Which is technically correct, but really confined definition in our context. I think it would be useful to term in 802.11 MAC termination rather than simply bridging. 2. Pat, Mike and I believe that bridging in this context has to do with bridging the user traffic to the local physical interface. Usually this is Ethernet in the WTP case. Non-bridging would be where the traffic is tunneled to the AC. =20 So I agree, if you bridge locally (ie. if the 802.11 MAC is terminated Locally and then the resulting 802.3 packets are bridged to the local physical interface), then it is possible for example to lose the functionality of L3 roaming of the client. However, in certain scenarios of deployments where this function/feature is not needed, local bridging is quite useful. =20 Thanks =20 Inderpreet =20 ________________________________ From: Pat Calhoun [mailto:pcalhoun@cisco.com]=20 Sent: Thursday, June 16, 2005 5:25 PM To: Sadot, Emek (Emek); 'Michael Montemurro'; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation > Giving the operator / customer the freedom to run the IS function in AC or WTP is important and as far as I can tell doesn't=20 > break the CAPWAP model. Why it's important: well take #1 for example, if customer wishes to session to travel along=20 > the shorter path between peers, or maintain existing voice call when AC experience a failover and perform reboot (but new=20 > session or roaming obviously)." =20 Emek, I don't see how this can be achieved. A user's end device has a single IP address. One really cannot split the forwarding of user traffic based on the relative priority of the traffic or based on network failures, because the return path of the user's traffic would always end up on its home subnet. The above suggestion where sometimes the user's traffic is briged and sometimes it is tunneled, would REQUIRE the WTP and the AC to be on the same subnet - which conflicts with the "Interconnection Objective". Further, one must assume that there are functions that reside in the AC that are much more than just "tunnel termination", and if this is the case these functions are lost when you resort to brige mode. =20 If redundancy/resiliency is required, then it must be provided in the CAPWAP protocol through some other means. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) Sent: Thursday, June 16, 2005 5:54 AM To: Michael Montemurro; Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Mike, =20 To make sure I am clear: by "bridge" I was referring to the Integration Services - bridging between 802.11 and 802.3. All management frames (security, QoS, etc.) should be handle by the AC. =20 Giving the operator / customer the freedom to run the IS function in AC or WTP is important and as far as I can tell doesn't break the CAPWAP model. Why it's important: well take #1 for example, if customer wishes to session to travel along the shorter path between peers, or maintain existing voice call when AC experience a failover and perform reboot (but new session or roaming obviously). =20 Emek =20 =09 ________________________________ From: Michael Montemurro [mailto:michael.montemurro@siemens.com] Sent: Thursday, June 16, 2005 3:35 PM To: Sadot, Emek (Emek); Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Emek, =20 I just want to get clarification on your response. You believe there are four possibilities: =20 1) Split MAC - Bridge at WTP 2) Split MAC - Bridge at AC 3) Local MAC - Bridge at WTP 4) Local MAC - Bridge at AC =20 I'd just like to understand how you envision case 1). What type of functionality would you envision would terminate at the AC? Could you be more specific on how you would handle WLAN management frames, security, and QoS in that case? =20 Thanks, =20 Mike =20 Michael Montemurro Director, Advanced Technology and Standards Chantry Networks, A Siemens Company 1900 Minnesota Ct, Suite 125 Mississauga, ON, CANADA. T: 905-363-6413 F: 905-567-9900 E: michael.montemurro@siemens.com=20 ------_=_NextPart_001_01C572CD.58DB514F Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Given the following scenarios:

 

 1) Split MAC - Br= idge at WTP 

 2) Split MAC - Br= idge at AC

 3) Local MAC - Br= idge at WTP

 4) Local MAC - Bridge at AC

 

I agree that #2-4 are required scenarios.  I am not sure that #1 is required.  If “bridg= e” means the IS function, #1 would be in conflict with the recent error correction/update of the taxonomy document.

 

When the IS function is implemented = at the WTP, the WTP must be a local MAC WTP.  However, in a local MAC scena= rio the CAPWAP protocol must still permit tunneling or not tunneling user traffic= to an AC.  A particular WTP device may not support this function, but the = CAPWAP protocol MUST allow it (IMHO).  This would be compatible with the ne= w update/error correction to the taxonomy document and gives flexibility fo= r implementers to create traffic separation if they choose in split and local MAC modes.=

 

What does everyone think? (did I mis= s anything?)

 

-Darren

=

 

 

From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Inderpreet Singh
Sent: Thursday, June 16, 2= 005 4:02 PM
To: Sadot, Emek (Emek); capwap@frascone.com
Subject: RE: [Capwap] Supp= ort for Traffic Separation

 

 

>>"Further, one must assume that the= re are functions that reside in the AC that are much more than

>>just "tunnel termination", and if this is the case = these functions are lost when you resort to bridge

>>mode." - I assume you = meant that some functionality will be lost if bridging is implemented= at the WTP,

>>so if that's your argument then the counter argument would be: how these functions being materialized

>>in Local MAc arch?

 

If I am not mistaken, this discussio= n has let to two interpretations of the word “bridging” as well.=

 

  1. Emek understands bridging as 802.11 to 802.3 conversion.  Which is technically correct, but really confined definition in our context.  I think it would be useful to term in 802.11 MAC termination r= ather than simply bridging.
  2. Pat, Mike and I believe that bridging in this context has to do with brid= ging the user traffic to the local physical interface.  Usually this= is Ethernet in the WTP case.  Non-bridging would be where the traf= fic is tunneled to the AC.

 

So I agree, if you bridge locally (i= e. if the 802.11 MAC is terminated Locally and then the resulting 802.3 packets= are bridged to the local physical interface), then it is possible for example= to lose the functionality of L3 roaming of the client.  However, in cer= tain scenarios of deployments where this function/feature is not needed, local= bridging is quite useful.

 

Thanks

 

Inderpreet<= /p>

 

From: Pat Calhoun [mailto:pcalhoun@cisco.com]
Sent: Thursday, June 16, 2= 005 5:25 PM
To: Sadot, Emek (Emek); 'M= ichael Montemurro'; capwap@frascone.com
Subject: RE: [Capwap] Supp= ort for Traffic Separation

> Giving the operator / customer the freedom to run the IS= function in AC or WTP is important and as far as I can tell doesn't

> break the CAPWAP model. Why it'= s important: well take #1 for example, if customer wishes to sess= ion to travel along

> the shorter path between p= eers, or maintain existing voice call when AC experience a failo= ver and perform reboot (but new

> session or roaming obviously)."

 

Emek, I don't see how this can be achieved. A user's end device has a single IP address. One really cannot = split the forwarding of user traffic based on the relative priority of the traf= fic or based on network failures, because the return path of the user's traffic = would always end up on its home subnet. The above suggestion where sometimes th= e user's traffic is briged and sometimes it is tunneled, would REQUIRE the = WTP and the AC to be on the same subnet - which conflicts with the "Inte= rconnection Objective". Further, one must assume that there are functions that r= eside in the AC that are much more than just "tunnel termination", an= d if this is the case these functions are lost when you resort to brige m= ode.

 

If redundancy/resiliency is required= , then it must be provided in the CAPWAP protocol through some other means.

 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

 

From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek)
= Sent: Thursday, June 16, 2= 005 5:54 AM
To: Michael Montemurro; Pa= t Calhoun; capwap@frascone.com
Subject: RE: [Capwap] Supp= ort for Traffic Separation

Mike,

 

To make sure I am clear: by "bridge" I was referring to the Integration Services = -  bridging between 802.11 and 802.3.

All management frames (security, QoS, etc.) should be handle by the AC.<= /span>

 

Giving the operator / customer the f= reedom to run the IS function in AC or WTP is important and as far as I can= tell doesn't break the CAPWAP model.

Why it's important: well take #1 for= example, if customer wishes to session to travel along the shorter path between peers, or maintain existing voice= call when AC experience a failover and perform reboot (but new = session or roaming obviously).

 

Emek

 

From: Michael Montemurro [mailto:michael.montemurro@siemens.com]
Sent: Thursday, June 16, 2= 005 3:35 PM
To: Sadot, Emek (Emek); Pa= t Calhoun; capwap@frascone.com
Subject: RE: [Capwap] Supp= ort for Traffic Separation

Emek,

 

I just want to get clarification on = your response. You believe there are four possibilities:

 

    1) Split MAC - Br= idge at WTP

    2) Split MAC - Br= idge at AC

    3) Local MAC - Br= idge at WTP

    4) Local MA= C - Bridge at AC

 

I'd just like to understand how you envision case 1).  What type of functionality would you envision wou= ld terminate at the AC? Could you be more specific on how you would handle W= LAN management frames, security, and QoS in that case?

 

Thanks,

=

 

    Mike

 

Michael Montemurro
Director, Advanced Technology and Standards
Chantry Networks, A Siemens Company
1900 Minnesota Ct, Suite= 125
Mississauga, ON, CANADA.
T: 905-363-6413
F: 905-567-9900
E: michael.montemurro@siemens.com

------_=_NextPart_001_01C572CD.58DB514F-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 16 19:51:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27423 for ; Thu, 16 Jun 2005 19:51:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0A7A520587; Thu, 16 Jun 2005 19:51:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4D1D52045F; Thu, 16 Jun 2005 19:51:08 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 55D682045F for ; Thu, 16 Jun 2005 19:50:58 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 6F2EB20369 for ; Thu, 16 Jun 2005 19:50:55 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j5GNl8pC033959; Thu, 16 Jun 2005 16:47:08 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200506162347.j5GNl8pC033959@homebrew.trpz.com> To: "Pat Calhoun" Cc: "'Clint Chaplin'" , mmani@avaya.com, lily.l.yang@intel.com, capwap@frascone.com Subject: Re: [Capwap] Taxonomy Recommendations: encrypt/decrypt In-Reply-To: Your message of "Thu, 16 Jun 2005 16:01:43 PDT." <200506162301.j5GN1jQ3012379@sj-core-1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <33957.1118965628.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 16 Jun 2005 16:47:08 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Thu, 16 Jun 2005 16:01:43 PDT you wrote > Clint, while I am OK with the proposed approach you are stating as long as > CAPWAP's statement is clear that centralized encryption can be done either > in the WTP or the AC, but the latter cannot work w/ HCCA. The fact that it would be problematic with HCCA is not anything that needs to be mentioned in any CAPWAP statement. It's useful to bring up during a product design phase when deciding where to do bulk data encryption in a particular split MAC but such architectures exist and all CAPWAP has to do is support it not say why one particular approach is better or worse than another. Note that you split the MAC the same way we did so my objection is not defensive or political. I just don't think it has any place in CAPWAP. Dan. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From uncurd@doneasy.com Fri Jun 17 03:58:25 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22072; Fri, 17 Jun 2005 03:58:25 -0400 (EDT) From: uncurd@doneasy.com Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjC7E-00069q-LA; Fri, 17 Jun 2005 04:22:17 -0400 Received: from [220.70.135.99] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1DjBk7-0002bW-7s; Fri, 17 Jun 2005 03:58:24 -0400 Received: from OTWGFbbfn.com (EHLO axbiq-a.cocaine.KE.ham.net) jamaica by mail.mtk.nao.ac.jp (4.9[2 Message-Id: Date: Fri, 17 Jun 2005 03:58:24 -0400 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From capwap-admin@frascone.com Fri Jun 17 08:47:13 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12346 for ; Fri, 17 Jun 2005 08:47:12 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9F73820493; Fri, 17 Jun 2005 08:47:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3ED13202C6; Fri, 17 Jun 2005 08:47:09 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4F8AC202C6 for ; Fri, 17 Jun 2005 08:46:08 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id E09EC202C1 for ; Fri, 17 Jun 2005 08:46:05 -0400 (EDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 17 Jun 2005 05:46:05 -0700 X-IronPort-AV: i="3.93,207,1115017200"; d="scan'208"; a="279945610:sNHT41701302" Received: from pacalhouwxp ([10.32.30.113]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5HCk37l021775; Fri, 17 Jun 2005 05:46:03 -0700 (PDT) Message-Id: <200506171246.j5HCk37l021775@sj-core-2.cisco.com> From: "Pat Calhoun" To: "'Chris Hinsz'" , Subject: RE: [Capwap] Taxonomy Recommendations: encrypt/decrypt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVyzLLi+9gXEJNvSuSpn8+2mfxRWQAbXSRw In-Reply-To: X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.30.113] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 17 Jun 2005 05:45:57 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Chris, Taken from http://www.ietf.org/internet-drafts/draft-calhoun-capwap-taxonomy-recommenda tion-00.txt: o Fragmentation/Defragmentation. Requiring this function to exist in the AC will cause issues with support for 802.11e. In the 802.11e specification, and more importantly the HCCA mechanism defined, an AP may need to fragment frames in order to fill a scheduled service period; thus 802.11e defines this function to be realtime for some instance. Moving this function to the AC is not possible since access to the air is required in order to be able to react to instantaneous changes in bandwidth, either as a result of noise or co-channel interference from adjacent APs or STAs. Placing this function in the AC would preclude an implementer from using the feature of 802.11e. In addition, this function is often used as part of the retransmission strategy, the control of which is in the WTP. o Privacy. There are two components to Privacy; 802.11 data privacy and secure session establishment (802.1X/EAP). It is agreed that the 802.1X/EAP function should reside in the AC. However, while encryption/decryption services could be performed in the WTP in most of today's circumstances, this becomes very problematic when used in conjunction with HCCA. As previously noted, HCCA will cause frames to be fragmented in order to fill a service period, and fragmentation occurs prior to encryption in 802.11. Requiring encryption services in the AC is not possible, again, else it preclude an implementer from utilizing these 802.11e features. Hope this helps, Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Chris Hinsz > Sent: Thursday, June 16, 2005 4:38 PM > To: capwap@frascone.com > Subject: Re: [Capwap] Taxonomy Recommendations: encrypt/decrypt > > Pat, > I'm a bit confused by the end of your first paragraph: > > CAPWAP's statement is clear that centralized encryption can be done > > either in the WTP or the AC, but the latter cannot work w/ HCCA. > First thing that confuses me, if the encryption is at the > WTP, then it's not centralized, this statement seems to imply > that it is. > Second, you note that encryption at the AC won't work with > HCCA. I was not aware of this limitation. I freely admit > that I am not a TGe expert, the access mechanism seems like > it would be orthogonal to encryption. What is it about HCCA > that effects the location of encryption? > CSH > > On 6/16/05, Pat Calhoun wrote: > > Clint, while I am OK with the proposed approach you are stating as > > long as CAPWAP's statement is clear that centralized > encryption can be > > done either in the WTP or the AC, but the latter cannot > work w/ HCCA. > > > > From a procedural standpoint, I can make changes to the taxonomy > > recommendations document, or the chairs can find another medium on > > which to document this. Either way works for me. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > -----Original Message----- > > > From: Clint Chaplin [mailto:cchaplin@sj.symbol.com] > > > Sent: Thursday, June 16, 2005 3:48 PM > > > To: mmani@avaya.com; pcalhoun@cisco.com; lily.l.yang@intel.com > > > Cc: capwap@frascone.com > > > Subject: RE: [Capwap] Taxonomy Recommendations: encrypt/decrypt > > > > > > There is one issue in how to split the "split architecture" > > > that will be somewhat contentious in generating a standard for > > > CAPWAP. That issue is: who handles the 802.11i encryption > > > decryption? There is already in the market from major vendors > > > equipment that falls on both sides of this division. If > the CAPWAP > > > standard is to be inclusive with existing architectural > decisions, > > > this one is going to have to be thrashed out. In my opinion, the > > > correct answer should > > > be: both are supported. > > > > > > Clint (JOATMON) Chaplin > > > Wireless Security Advisor > > > Wireless Standards Manager > > > > > > >>> "Mani, Mahalingam (Mahalingam)" 6/16/05 > > > 07:13:18 > > > >>> >>> > > > I have no objections to this 'bug-fix' if it can happen > in time and > > > has no author/WG objections. We can request the RFC Ed. > to hold off. > > > > > > As for the other issue on split-MAC interpretation: > > > The split-discussion is long overdue; and is worth having > - to help > > > evaluation as well. I think resolution of the discussion is > > > important to arrive at the best approach to CAPWAP protocol > > > accommodating/not split variants. > > > > > > History: > > > We had clearly noted not to make any recommendations on > what a split > > > characteristic must be in the taxonomy. This has perhaps > been argued > > > many times in (taxonomy) design team and in IETF58-62 as > well. There > > > was no scope for us in the then charter to venture that way. > > > > > > When APF AHC initially started its work - the hope was it would > > > offer enough information for CAPWAP to draw conclusions > for future > > > work; there were no expectations on what they would recommend the > > > split ought to be once they were chartered (there were hopes much > > > prior to that). Inasmuch as IEEE 802.11 endorsed and acknowledged > > > the documented splits caused no standards departure/breakage in > > > implementation or behavior - by its review of the > taxonomy draft - > > > we had validated all architectures from IEEE 802.11 perspective. > > > > > > It was clear when APF AHC group was formed that it will > transpire to > > > provide only clarifying interpretations of functions - > not delineate > > > or standardize splits. > > > > > > -mani > > > ====== > > > -----Original Message----- > > > From: Yang, Lily L [mailto:lily.l.yang@intel.com] > > > Sent: Wednesday, June 15, 2005 1:19 PM > > > To: Mani, Mahalingam (Mahalingam); Pat Calhoun > > > Cc: capwap@frascone.com > > > Subject: RE: [Capwap] Taxonomy Recommendations > > > > > > > > > Hi, Pat and Mani -- > > > > > > I have not read through the entire Taxonomy > Recommendations document > > > yet, but just reading through the first few pages, I believe the > > > authors are correct in pointing out one of the "inconsistency" > > > (error) in the taxonomy draft. There was a paragraph in > the taxonomy > > > draft Section 5.6: > > > " The commonalities and differences between Local MAC and > Split MAC > > > are > > > most clearly seen by comparing Figure 7 to Figure 10. The > > > commonality is that 802.11 control frames are > terminated at WTPs in > > > both cases. The main difference between Local MAC and > Split MAC is > > > that the WTP terminates only the 802.11 control frames > in the Split > > > MAC, while the WTP may terminate all 802.11 frames in > the Local > > > MAC. > > > An interesting consequence of this difference is that the > > > Integration > > > Service, which essentially refers to bridging between > 802.11 and > > > 802.3 frames, is implemented by the AC in the Split > MAC, but can be > > > part of either the AC or WTP in the Local MAC." > > > The last sentence, as pointed out by Pat, Bob and Inderpreet's > > > document, was incorrect. According to Figure 9, > Integration Service, > > > for all the parties classified as Local MAC, is > implemented by WTP. > > > Given that we still have about 3 hours remaining in the > authors' 48 > > > hour window, I would like to send a note to RFC Editor suggesting > > > the following sentence to replace the last sentence in the > > > paragraph: > > > "An interesting consequence of this difference is that > the Integration > > > Service, which essentially refers to bridging between > 802.11 and > > > 802.3 frames, is implemented by the AC in the Split MAC and by > > > the WTP in the Local MAC, as shown in Figure 9 and Figure 12." > > > > > > Glaring as it is, I believe this error does not carry any far > > > reaching implication to the entire document and hence it > is bug we > > > can fix right now. > > > > > > Regarding the comment from the authors that taxonomy draft lacks > > > conclusion and recommendation and hence the motivation to take it > > > further to clearly define what Local and Split MAC really mean in > > > terms of functional split -- I think that is a fair comment -- > > > Personally I was tempted to take that step in the taxonomy draft > > > with the intention to help the WG moving forward, but as > the editor > > > of the draft, I received clear instruction from the > chairs and the > > > WG that a taxonomy only goes so far to "document" the > reality of the > > > market, not to "define" any architectures. So the draft > deliberately > > > didn't go far into making any specific functional split > > > recommendation. > > > > > > As I advocated in both July and Nov IETF meeting last year, I > > > believe there is indeed a gap between taxonomy draft and > objective > > > draft -- the WG needs a clear definition of the > functional split for > > > Local, especially Split MAC, but that is not the charter > of either > > > taxonomy draft or Objective draft. > > > Some people have the illusion that IEEE 802.11 > (specifically the APF > > > ad hoc group) will provide such definition. The clear > answer there > > > is NO, IEEE would not do that. It is up to us in this > group to agree > > > on the split and move on. So if indeed this Taxonomy > Recommendation > > > draft fulfills this purpose, I personally believe it is a very > > > necessary step to take in order to move forward. However, > as I said, > > > I have not reviewed the entire document yet and so I > would reserve > > > until then to offer any further comments. > > > > > > But I do want to fix the error in Section 5.6 in Taxonomy > draft NOW. > > > > > > Lily > > > -----Original Message----- > > > From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On Behalf Of Mani, Mahalingam > > > (Mahalingam) > > > Sent: Wednesday, June 15, 2005 11:14 AM > > > To: Pat Calhoun; capwap@frascone.com > > > Subject: RE: [Capwap] Taxonomy Recommendations > > > > > > Thanks for the joint effort (by authors of two candidate > protocols > > > for eval. as I see it) in making a case for clarification of > > > terminology. > > > > > > If the changes and clarifications proposed are extensive > - comments > > > in form of I-D is useful to place-hold them. > > > > > > The WG should (especially the original taxonomy team authors) > > > comment on these comments (draft): WG has approved the > -06 version > > > of the taxonomy draft. Two of the authors are in this as well :) > > > > > > It is also important to understand the implications, if any, (on > > > Objectives draft) if WG agrees to any of the proposed > > > clarifications. It may turn out to be transparent to the > Objectives > > > draft. This needs to happen soon for Objectives to freeze and let > > > the evaluation team use a baselined version. > > > > > > [BTW: the taxonomy draft is in RFC editor's queue - actually just > > > completed AUTH48]. > > > > > > -mani > > > ====== > > > -----Original Message----- > > > From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun > > > Sent: Thursday, June 09, 2005 2:28 PM > > > To: capwap@frascone.com > > > Subject: [Capwap] Taxonomy Recommendations > > > > > > All, > > > > > > I wanted to announce the early availability of the CAPWAP > taxonomy > > > recommendation draft that Bob O'Hara Inderpreet Singh and I have > > > been working on. It can be found at > > > http://www.capwap.org/draft-calhoun-capwap-taxonomy-recommenda > > > tion-00.tx > > > t. > > > > > > > > > Abstract > > > > > > The IETF's CAPWAP working group has documented various product > > > architectures and has categorized the Centralized WLAN > > > Architectures > > > into two main buckets: Split and Local MAC. While the document > > > contains very relevant and useful information, what it > does is list > > > the architectural variants of these two buckets, but does not > > > unambiguously define either the Split MAC or Local MAC > > > architectures. > > > In order for CAPWAP to be successful, it is crucial for the > > > protocol > > > evaluation team, and the working group, to agree on unambiguous > > > terminology to describe these architectures. > > > > > > This document proposes terminology to unambiguously > describe the > > > relevant architectures found in the taxonomy document, for the > > > purpose of initiating a discussion within the working > group and to > > > allow the protocol evaluation work to come to a fruitful > > > conclusion. > > > We conclude in this document that the architectures are very > > > similar > > > and could be supported via a single protocol. > > > > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > ______________________________________________________________ > > > __________ > > > This email has been scanned for computer viruses. > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jun 17 08:54:18 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12864 for ; Fri, 17 Jun 2005 08:54:14 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8490720587; Fri, 17 Jun 2005 08:54:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0A388202C6; Fri, 17 Jun 2005 08:54:08 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BA297202C6 for ; Fri, 17 Jun 2005 08:53:32 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id CF7C2202C1 for ; Fri, 17 Jun 2005 08:53:29 -0400 (EDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 17 Jun 2005 05:53:29 -0700 X-IronPort-AV: i="3.93,207,1115017200"; d="scan'208,217"; a="279947787:sNHT58346542" Received: from pacalhouwxp ([10.32.30.113]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5HCrO7l024182; Fri, 17 Jun 2005 05:53:24 -0700 (PDT) Message-Id: <200506171253.j5HCrO7l024182@sj-core-2.cisco.com> From: "Pat Calhoun" To: "'Darren Loher'" , "'Inderpreet Singh'" , "'Sadot, Emek (Emek)'" , Subject: RE: [Capwap] Support for Traffic Separation MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_07C0_01C57300.E1D7D5E0" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVyv0Q9lzN8dWOqQWi8yNxovbTMLAAC7bzAABvpgyA= In-Reply-To: X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.30.113] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 17 Jun 2005 05:53:21 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------=_NextPart_000_07C0_01C57300.E1D7D5E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Darren, I actually believe that CAPWAP should focus on 2 and 3. I do believe that there are situations where option 3 makes sense, such as when centralized monitoring and configuration of the WTPs is desired, however local bridging is required. Imagine a scenario where the link between the WTP and the AC is constrained and therefore cannot sustain that all traffic be sent to the AC. One such example would be a retail environment, where every store has a few APs, but these are all centrally managed, while the traffic is locally bridged. Obviously option 2 is required for all other circumstances. My issue with mandating options 2 and 4, is that from a user standpoint there are identical - and therefore the only convenience that we've created is for the implementors of the WTPs. However, from a feature/function standpoint, they would end up being identical in nature - and if this is the case, I honestly don't understand why the WG should focus on creating two separate solutions to meet the exact same goal. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Darren Loher Sent: Thursday, June 16, 2005 4:45 PM To: Inderpreet Singh; Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Given the following scenarios: 1) Split MAC - Bridge at WTP 2) Split MAC - Bridge at AC 3) Local MAC - Bridge at WTP 4) Local MAC - Bridge at AC I agree that #2-4 are required scenarios. I am not sure that #1 is required. If "bridge" means the IS function, #1 would be in conflict with the recent error correction/update of the taxonomy document. When the IS function is implemented at the WTP, the WTP must be a local MAC WTP. However, in a local MAC scenario the CAPWAP protocol must still permit tunneling or not tunneling user traffic to an AC. A particular WTP device may not support this function, but the CAPWAP protocol MUST allow it (IMHO). This would be compatible with the new update/error correction to the taxonomy document and gives flexibility for implementers to create traffic separation if they choose in split and local MAC modes. What does everyone think? (did I miss anything?) -Darren _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Inderpreet Singh Sent: Thursday, June 16, 2005 4:02 PM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation >>"Further, one must assume that there are functions that reside in the AC that are much more than >>just "tunnel termination", and if this is the case these functions are lost when you resort to bridge >>mode." - I assume you meant that some functionality will be lost if bridging is implemented at the WTP, >>so if that's your argument then the counter argument would be: how these functions being materialized >>in Local MAc arch? If I am not mistaken, this discussion has let to two interpretations of the word "bridging" as well. 1. Emek understands bridging as 802.11 to 802.3 conversion. Which is technically correct, but really confined definition in our context. I think it would be useful to term in 802.11 MAC termination rather than simply bridging. 2. Pat, Mike and I believe that bridging in this context has to do with bridging the user traffic to the local physical interface. Usually this is Ethernet in the WTP case. Non-bridging would be where the traffic is tunneled to the AC. So I agree, if you bridge locally (ie. if the 802.11 MAC is terminated Locally and then the resulting 802.3 packets are bridged to the local physical interface), then it is possible for example to lose the functionality of L3 roaming of the client. However, in certain scenarios of deployments where this function/feature is not needed, local bridging is quite useful. Thanks Inderpreet _____ From: Pat Calhoun [mailto:pcalhoun@cisco.com] Sent: Thursday, June 16, 2005 5:25 PM To: Sadot, Emek (Emek); 'Michael Montemurro'; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation > Giving the operator / customer the freedom to run the IS function in AC or WTP is important and as far as I can tell doesn't > break the CAPWAP model. Why it's important: well take #1 for example, if customer wishes to session to travel along > the shorter path between peers, or maintain existing voice call when AC experience a failover and perform reboot (but new > session or roaming obviously)." Emek, I don't see how this can be achieved. A user's end device has a single IP address. One really cannot split the forwarding of user traffic based on the relative priority of the traffic or based on network failures, because the return path of the user's traffic would always end up on its home subnet. The above suggestion where sometimes the user's traffic is briged and sometimes it is tunneled, would REQUIRE the WTP and the AC to be on the same subnet - which conflicts with the "Interconnection Objective". Further, one must assume that there are functions that reside in the AC that are much more than just "tunnel termination", and if this is the case these functions are lost when you resort to brige mode. If redundancy/resiliency is required, then it must be provided in the CAPWAP protocol through some other means. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) Sent: Thursday, June 16, 2005 5:54 AM To: Michael Montemurro; Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Mike, To make sure I am clear: by "bridge" I was referring to the Integration Services - bridging between 802.11 and 802.3. All management frames (security, QoS, etc.) should be handle by the AC. Giving the operator / customer the freedom to run the IS function in AC or WTP is important and as far as I can tell doesn't break the CAPWAP model. Why it's important: well take #1 for example, if customer wishes to session to travel along the shorter path between peers, or maintain existing voice call when AC experience a failover and perform reboot (but new session or roaming obviously). Emek _____ From: Michael Montemurro [mailto:michael.montemurro@siemens.com] Sent: Thursday, June 16, 2005 3:35 PM To: Sadot, Emek (Emek); Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Emek, I just want to get clarification on your response. You believe there are four possibilities: 1) Split MAC - Bridge at WTP 2) Split MAC - Bridge at AC 3) Local MAC - Bridge at WTP 4) Local MAC - Bridge at AC I'd just like to understand how you envision case 1). What type of functionality would you envision would terminate at the AC? Could you be more specific on how you would handle WLAN management frames, security, and QoS in that case? Thanks, Mike Michael Montemurro Director, Advanced Technology and Standards Chantry Networks, A Siemens Company 1900 Minnesota Ct, Suite 125 Mississauga, ON, CANADA. T: 905-363-6413 F: 905-567-9900 E: michael.montemurro@siemens.com ------=_NextPart_000_07C0_01C57300.E1D7D5E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Darren,
 
I actually believe that CAPWAP should focus on = 2 and 3. I=20 do believe that there are situations where option 3 makes sense, such as = when=20 centralized monitoring and configuration of the WTPs is desired, however = local=20 bridging is required. Imagine a scenario where the link between the WTP = and the=20 AC is constrained and therefore cannot sustain that all traffic be sent = to the=20 AC. One such example would be a retail environment, where every store = has a few=20 APs, but these are all centrally managed, while the traffic is locally = bridged.=20 Obviously option 2 is required for all other = circumstances.
 
My issue with mandating options 2 and 4, is = that from a=20 user standpoint there are identical - and therefore the only convenience = that=20 we've created is for the implementors of the WTPs. However, from a=20 feature/function standpoint, they would end up being identical in nature = - and=20 if this is the case, I honestly don't understand why the WG should focus = on=20 creating two separate solutions to meet the exact same = goal.

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

 

 ------=_NextPart_000_07C0_01C57300.E1D7D5E0-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jun 17 08:58:12 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13241 for ; Fri, 17 Jun 2005 08:58:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D0C0E205A0; Fri, 17 Jun 2005 08:58:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 31F61202C6; Fri, 17 Jun 2005 08:58:08 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 66A3F202C6 for ; Fri, 17 Jun 2005 08:57:45 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 81DF4202C1 for ; Fri, 17 Jun 2005 08:57:43 -0400 (EDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 17 Jun 2005 05:57:43 -0700 X-IronPort-AV: i="3.93,207,1115017200"; d="scan'208"; a="279949096:sNHT27823712" Received: from pacalhouwxp ([10.32.30.113]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5HCvb7l025656; Fri, 17 Jun 2005 05:57:38 -0700 (PDT) Message-Id: <200506171257.j5HCvb7l025656@sj-core-2.cisco.com> From: "Pat Calhoun" To: "'Dan Harkins'" Cc: "'Clint Chaplin'" , , , Subject: RE: [Capwap] Taxonomy Recommendations: encrypt/decrypt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVyzlVPInmr5s+gQxO6JUtY0mpCMQAbT3Dg In-Reply-To: <200506162347.j5GNl8pC033959@homebrew.trpz.com> X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.30.113] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 17 Jun 2005 05:57:34 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > The fact that it would be problematic with HCCA is not > anything that needs to be mentioned in any CAPWAP statement. > It's useful to bring up during a product design phase when > deciding where to do bulk data encryption in a particular > split MAC but such architectures exist and all CAPWAP has to > do is support it not say why one particular approach is > better or worse than another. > > Note that you split the MAC the same way we did so my > objection is not defensive or political. I just don't think > it has any place in CAPWAP. I disagree - and for very specific technical reasons. This is the one area where splitting the MAC has significant implications. See my previous e-mail response to Chris Hinsz, but to summarize, in HCCA the fragmentation must occur prior to encryption in order to meet the service period negotiated within HCCA. One cannot centralize the encryption function (hence fragment) without direct access to the RF in real-time in order to gain access to interference and co-channel information. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jun 17 08:59:17 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13426 for ; Fri, 17 Jun 2005 08:59:12 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3D5D9205AE; Fri, 17 Jun 2005 08:59:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 11E1D20599; Fri, 17 Jun 2005 08:59:08 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 56785204CF for ; Fri, 17 Jun 2005 08:58:43 -0400 (EDT) Received: from typhoon.trangosoft.com (unknown [209.82.51.154]) by mail.frascone.com (Postfix) with ESMTP id 6802720599 for ; Fri, 17 Jun 2005 08:58:38 -0400 (EDT) Received: from phantom-out.trangosoft.com ([136.157.233.22]) by 136.157.233.32 with trend_isnt_name_B; Fri, 17 Jun 2005 09:00:12 -0400 Received: from troll3.trangosoft.com (troll3.trangosoft.com [136.157.233.13]) by phantom-out.trangosoft.com (Postfix) with ESMTP id 81CD524FA8; Fri, 17 Jun 2005 08:35:19 -0400 (EDT) Received: by troll3.trangosoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Jun 2005 08:54:41 -0400 Message-ID: <1652EBA28502ED4393B9BC9B8A4B601316441B@mism121a.toronto.chantrynetworks.com> From: Michael Montemurro To: Darren Loher , Inderpreet Singh , "Sadot, Emek (Emek)" , capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5733C.44C72AE4" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 17 Jun 2005 08:58:34 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5733C.44C72AE4 Content-Type: text/plain I would say agreed that 2-4 are the required scenarios. I'm not sure how split the MAC and bridge data traffic at the WTP in the case of #1 Cheers, Mike _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Darren Loher Sent: June 16, 2005 7:45 PM To: Inderpreet Singh; Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Given the following scenarios: 1) Split MAC - Bridge at WTP 2) Split MAC - Bridge at AC 3) Local MAC - Bridge at WTP 4) Local MAC - Bridge at AC I agree that #2-4 are required scenarios. I am not sure that #1 is required. If "bridge" means the IS function, #1 would be in conflict with the recent error correction/update of the taxonomy document. When the IS function is implemented at the WTP, the WTP must be a local MAC WTP. However, in a local MAC scenario the CAPWAP protocol must still permit tunneling or not tunneling user traffic to an AC. A particular WTP device may not support this function, but the CAPWAP protocol MUST allow it (IMHO). This would be compatible with the new update/error correction to the taxonomy document and gives flexibility for implementers to create traffic separation if they choose in split and local MAC modes. What does everyone think? (did I miss anything?) -Darren _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Inderpreet Singh Sent: Thursday, June 16, 2005 4:02 PM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation >>"Further, one must assume that there are functions that reside in the AC that are much more than >>just "tunnel termination", and if this is the case these functions are lost when you resort to bridge >>mode." - I assume you meant that some functionality will be lost if bridging is implemented at the WTP, >>so if that's your argument then the counter argument would be: how these functions being materialized >>in Local MAc arch? If I am not mistaken, this discussion has let to two interpretations of the word "bridging" as well. 1. Emek understands bridging as 802.11 to 802.3 conversion. Which is technically correct, but really confined definition in our context. I think it would be useful to term in 802.11 MAC termination rather than simply bridging. 2. Pat, Mike and I believe that bridging in this context has to do with bridging the user traffic to the local physical interface. Usually this is Ethernet in the WTP case. Non-bridging would be where the traffic is tunneled to the AC. So I agree, if you bridge locally (ie. if the 802.11 MAC is terminated Locally and then the resulting 802.3 packets are bridged to the local physical interface), then it is possible for example to lose the functionality of L3 roaming of the client. However, in certain scenarios of deployments where this function/feature is not needed, local bridging is quite useful. Thanks Inderpreet _____ From: Pat Calhoun [mailto:pcalhoun@cisco.com] Sent: Thursday, June 16, 2005 5:25 PM To: Sadot, Emek (Emek); 'Michael Montemurro'; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation > Giving the operator / customer the freedom to run the IS function in AC or WTP is important and as far as I can tell doesn't > break the CAPWAP model. Why it's important: well take #1 for example, if customer wishes to session to travel along > the shorter path between peers, or maintain existing voice call when AC experience a failover and perform reboot (but new > session or roaming obviously)." Emek, I don't see how this can be achieved. A user's end device has a single IP address. One really cannot split the forwarding of user traffic based on the relative priority of the traffic or based on network failures, because the return path of the user's traffic would always end up on its home subnet. The above suggestion where sometimes the user's traffic is briged and sometimes it is tunneled, would REQUIRE the WTP and the AC to be on the same subnet - which conflicts with the "Interconnection Objective". Further, one must assume that there are functions that reside in the AC that are much more than just "tunnel termination", and if this is the case these functions are lost when you resort to brige mode. If redundancy/resiliency is required, then it must be provided in the CAPWAP protocol through some other means. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) Sent: Thursday, June 16, 2005 5:54 AM To: Michael Montemurro; Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Mike, To make sure I am clear: by "bridge" I was referring to the Integration Services - bridging between 802.11 and 802.3. All management frames (security, QoS, etc.) should be handle by the AC. Giving the operator / customer the freedom to run the IS function in AC or WTP is important and as far as I can tell doesn't break the CAPWAP model. Why it's important: well take #1 for example, if customer wishes to session to travel along the shorter path between peers, or maintain existing voice call when AC experience a failover and perform reboot (but new session or roaming obviously). Emek _____ From: Michael Montemurro [mailto:michael.montemurro@siemens.com] Sent: Thursday, June 16, 2005 3:35 PM To: Sadot, Emek (Emek); Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Emek, I just want to get clarification on your response. You believe there are four possibilities: 1) Split MAC - Bridge at WTP 2) Split MAC - Bridge at AC 3) Local MAC - Bridge at WTP 4) Local MAC - Bridge at AC I'd just like to understand how you envision case 1). What type of functionality would you envision would terminate at the AC? Could you be more specific on how you would handle WLAN management frames, security, and QoS in that case? Thanks, Mike Michael Montemurro Director, Advanced Technology and Standards Chantry Networks, A Siemens Company 1900 Minnesota Ct, Suite 125 Mississauga, ON, CANADA. T: 905-363-6413 F: 905-567-9900 E: michael.montemurro@siemens.com ------_=_NextPart_001_01C5733C.44C72AE4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
I would say agreed that 2-4 are the required = scenarios.=20
 
I'm not sure how split the MAC and bridge data = traffic at=20 the WTP in the case of #1
 
Cheers,
 
    Mike

From: capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Darren=20 Loher
Sent: June 16, 2005 7:45 PM
To: Inderpreet = Singh;=20 Sadot, Emek (Emek); capwap@frascone.com
Subject: RE: = [Capwap]=20 Support for Traffic Separation

Given the following=20 scenarios:

 

 1) Split=20 MAC - Bridge at WTP 

 2) Split=20 MAC - Bridge at AC

 3) Local=20 MAC - Bridge at WTP

 4) = Local MAC -=20 Bridge at AC

 

I agree = that #2-4 are=20 required scenarios.  I am not sure that #1 is required.  If = “bridge”=20 means the IS function, #1 would be in conflict with the recent error=20 correction/update of the taxonomy = document.

 

When the = IS function=20 is implemented at the WTP, the WTP must be a local MAC WTP.  = However, in=20 a local MAC scenario the CAPWAP protocol must still permit tunneling = or not=20 tunneling user traffic to an AC.  A particular WTP device may = not support=20 this function, but the CAPWAP protocol MUST allow it (IMHO).  = This would=20 be compatible with the new update/error correction to the taxonomy = document=20 and gives flexibility for implementers to create traffic separation = if they=20 choose in split and local MAC modes.

 

What does = everyone=20 think? (did I miss anything?)

 

-Darren

 

 

From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Inderpreet = Singh
Sent: Thursday, June 16, 2005 = 4:02=20 PM
To: Sadot, Emek = (Emek);=20 capwap@frascone.com
Subject:=20 RE: [Capwap] Support for Traffic = Separation

 

 

>>"Further, one must assume = that there are=20 functions that reside in the AC that are much more than=20

>>just = "tunnel=20 termination", and if this is the case these functions are lost when=20 you resort to bridge

>>mode." - I = assume you=20 meant that some functionality will be lost if bridging is=20 implemented at the WTP,

>>so if = that's your=20 argument then the counter argument would be: how these=20 functions being materialized

>>in Local = MAc=20 arch?

 

If I am = not mistaken,=20 this discussion has let to two interpretations of the word = “bridging” as=20 well.

 

  1. Emek understands = bridging as=20 802.11 to 802.3 conversion.  Which is technically correct, but = really=20 confined definition in our context.  I think it would be = useful to term=20 in 802.11 MAC termination rather than simply=20 bridging.=20
  2. Pat, Mike and I = believe that=20 bridging in this context has to do with bridging the user traffic = to the=20 local physical interface.  Usually this is Ethernet in the WTP = case.  Non-bridging would be where the traffic is tunneled to = the=20 AC.

 

So I = agree, if you=20 bridge locally (ie. if the 802.11 MAC is terminated Locally and then = the=20 resulting 802.3 packets are bridged to the local physical interface), = then it=20 is possible for example to lose the functionality of L3 roaming of = the=20 client.  However, in certain scenarios of deployments where this = function/feature is not needed, local bridging is quite=20 useful.

 

Thanks

 

Inderpreet

 

From: Pat=20 Calhoun [mailto:pcalhoun@cisco.com]
Sent: Thursday, June 16, 2005 = 5:25=20 PM
To: Sadot, Emek = (Emek);=20 'Michael Montemurro'; capwap@frascone.com
Subject: RE: [Capwap] Support = for Traffic=20 Separation

>=20 Giving the = operator /=20 customer the freedom to run the IS function in AC or WTP is = important and=20 as far as I can tell doesn't

> break = the CAPWAP=20 model. Why it's important: well take #1 for example, if customer = wishes to session to travel along =

> = the shorter=20 path between peers, or maintain existing voice = call when AC=20 experience a failover and perform reboot (but new=20

>=20 session or roaming = obviously)."

 

Emek, I = don't see how=20 this can be achieved. A user's end device has a single IP address. = One really=20 cannot split the forwarding of user traffic based on the relative = priority of=20 the traffic or based on network failures, because the return path of = the=20 user's traffic would always end up on its home subnet. The above = suggestion=20 where sometimes the user's traffic is briged and sometimes it is = tunneled,=20 would REQUIRE the WTP and the AC to be on the same subnet - which = conflicts=20 with the "Interconnection Objective". Further, one must assume that = there are=20 functions that reside in the AC that are much more than just "tunnel=20 termination", and if this is the case these functions are lost when=20 you resort to brige mode.

 

If=20 redundancy/resiliency is required, then it must be provided in the = CAPWAP=20 protocol through some other means.

 

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

 

 

From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] = On Behalf Of Sadot, Emek=20 (Emek)
Sent: = Thursday, June=20 16, 2005 5:54 AM
To:=20 Michael Montemurro; Pat Calhoun; capwap@frascone.com
Subject: RE: [Capwap] = Support for=20 Traffic Separation

Mike,

 

To make = sure I am=20 clear: by "bridge" I was referring to the Integration = Services -=20  bridging between 802.11 and = 802.3.

All=20 management frames (security, QoS, etc.) should be handle by = the=20 AC.

 

Giving = the operator=20 / customer the freedom to run the IS function in AC or WTP is = important=20 and as far as I can tell doesn't break the CAPWAP=20 model.

Why it's = important:=20 well take #1 for example, if customer wishes to session=20 to travel along the shorter path between peers,=20 or maintain existing voice call when AC experience a = failover=20 and perform reboot (but new session or roaming=20 obviously).

 

Emek

 

From:=20 Michael Montemurro [mailto:michael.montemurro@siemens.com] =
Sent: Thursday, June 16, = 2005 3:35=20 PM
To: Sadot, = Emek (Emek);=20 Pat Calhoun; capwap@frascone.com
Subject: RE: [Capwap] = Support for=20 Traffic Separation

Emek,

 

I just = want to get=20 clarification on your response. You believe there are four=20 possibilities:

 

    1) Split = MAC -=20 Bridge at WTP

    2) Split = MAC -=20 Bridge at AC

    3) Local = MAC -=20 Bridge at WTP

    4) = Local MAC=20 - Bridge at AC

 

I'd just = like to=20 understand how you envision case 1).  What type of = functionality would=20 you envision would terminate at the AC? Could you be more specific = on how=20 you would handle WLAN management frames, security, and QoS in that=20 case?

 

Thanks,

 

    Mike

 

Michael=20 Montemurro
Director, Advanced Technology and = Standards
Chantry=20 Networks, A Siemens Company
1900 Minnesota Ct, Suite=20 125
Mississauga, ON,=20 CANADA.
T:=20 905-363-6413
F: 905-567-9900
E: = michael.montemurro@siemens.com

------_=_NextPart_001_01C5733C.44C72AE4-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jun 17 09:02:18 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13652 for ; Fri, 17 Jun 2005 09:02:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 989CC205B2; Fri, 17 Jun 2005 09:02:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 28A2D205A2; Fri, 17 Jun 2005 09:02:09 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 06220205A2 for ; Fri, 17 Jun 2005 09:01:54 -0400 (EDT) Received: from typhoon.trangosoft.com (unknown [209.82.51.154]) by mail.frascone.com (Postfix) with ESMTP id C2457204CF for ; Fri, 17 Jun 2005 09:01:45 -0400 (EDT) Received: from phantom-out.trangosoft.com ([136.157.233.22]) by 136.157.233.32 with trend_isnt_name_B; Fri, 17 Jun 2005 09:03:16 -0400 Received: from troll3.trangosoft.com (troll3.trangosoft.com [136.157.233.13]) by phantom-out.trangosoft.com (Postfix) with ESMTP id 90EF024FA8; Fri, 17 Jun 2005 08:38:23 -0400 (EDT) Received: by troll3.trangosoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Jun 2005 08:57:46 -0400 Message-ID: <1652EBA28502ED4393B9BC9B8A4B601316441D@mism121a.toronto.chantrynetworks.com> From: Michael Montemurro To: Pat Calhoun , "'Darren Loher'" , Inderpreet Singh , "'Sadot, Emek (Emek)'" , capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5733C.B24D3144" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 17 Jun 2005 09:01:37 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5733C.B24D3144 Content-Type: text/plain Pat, I respectfully dissagree with you with grouping together case 4. There is no reason why you couldn't terminate 802.11 at the WTP and bridge data traffic to the AC. Mike _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun Sent: June 17, 2005 8:53 AM To: 'Darren Loher'; Inderpreet Singh; 'Sadot, Emek (Emek)'; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Darren, I actually believe that CAPWAP should focus on 2 and 3. I do believe that there are situations where option 3 makes sense, such as when centralized monitoring and configuration of the WTPs is desired, however local bridging is required. Imagine a scenario where the link between the WTP and the AC is constrained and therefore cannot sustain that all traffic be sent to the AC. One such example would be a retail environment, where every store has a few APs, but these are all centrally managed, while the traffic is locally bridged. Obviously option 2 is required for all other circumstances. My issue with mandating options 2 and 4, is that from a user standpoint there are identical - and therefore the only convenience that we've created is for the implementors of the WTPs. However, from a feature/function standpoint, they would end up being identical in nature - and if this is the case, I honestly don't understand why the WG should focus on creating two separate solutions to meet the exact same goal. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Darren Loher Sent: Thursday, June 16, 2005 4:45 PM To: Inderpreet Singh; Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Given the following scenarios: 1) Split MAC - Bridge at WTP 2) Split MAC - Bridge at AC 3) Local MAC - Bridge at WTP 4) Local MAC - Bridge at AC I agree that #2-4 are required scenarios. I am not sure that #1 is required. If "bridge" means the IS function, #1 would be in conflict with the recent error correction/update of the taxonomy document. When the IS function is implemented at the WTP, the WTP must be a local MAC WTP. However, in a local MAC scenario the CAPWAP protocol must still permit tunneling or not tunneling user traffic to an AC. A particular WTP device may not support this function, but the CAPWAP protocol MUST allow it (IMHO). This would be compatible with the new update/error correction to the taxonomy document and gives flexibility for implementers to create traffic separation if they choose in split and local MAC modes. What does everyone think? (did I miss anything?) -Darren _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Inderpreet Singh Sent: Thursday, June 16, 2005 4:02 PM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation >>"Further, one must assume that there are functions that reside in the AC that are much more than >>just "tunnel termination", and if this is the case these functions are lost when you resort to bridge >>mode." - I assume you meant that some functionality will be lost if bridging is implemented at the WTP, >>so if that's your argument then the counter argument would be: how these functions being materialized >>in Local MAc arch? If I am not mistaken, this discussion has let to two interpretations of the word "bridging" as well. 1. Emek understands bridging as 802.11 to 802.3 conversion. Which is technically correct, but really confined definition in our context. I think it would be useful to term in 802.11 MAC termination rather than simply bridging. 2. Pat, Mike and I believe that bridging in this context has to do with bridging the user traffic to the local physical interface. Usually this is Ethernet in the WTP case. Non-bridging would be where the traffic is tunneled to the AC. So I agree, if you bridge locally (ie. if the 802.11 MAC is terminated Locally and then the resulting 802.3 packets are bridged to the local physical interface), then it is possible for example to lose the functionality of L3 roaming of the client. However, in certain scenarios of deployments where this function/feature is not needed, local bridging is quite useful. Thanks Inderpreet _____ From: Pat Calhoun [mailto:pcalhoun@cisco.com] Sent: Thursday, June 16, 2005 5:25 PM To: Sadot, Emek (Emek); 'Michael Montemurro'; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation > Giving the operator / customer the freedom to run the IS function in AC or WTP is important and as far as I can tell doesn't > break the CAPWAP model. Why it's important: well take #1 for example, if customer wishes to session to travel along > the shorter path between peers, or maintain existing voice call when AC experience a failover and perform reboot (but new > session or roaming obviously)." Emek, I don't see how this can be achieved. A user's end device has a single IP address. One really cannot split the forwarding of user traffic based on the relative priority of the traffic or based on network failures, because the return path of the user's traffic would always end up on its home subnet. The above suggestion where sometimes the user's traffic is briged and sometimes it is tunneled, would REQUIRE the WTP and the AC to be on the same subnet - which conflicts with the "Interconnection Objective". Further, one must assume that there are functions that reside in the AC that are much more than just "tunnel termination", and if this is the case these functions are lost when you resort to brige mode. If redundancy/resiliency is required, then it must be provided in the CAPWAP protocol through some other means. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) Sent: Thursday, June 16, 2005 5:54 AM To: Michael Montemurro; Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Mike, To make sure I am clear: by "bridge" I was referring to the Integration Services - bridging between 802.11 and 802.3. All management frames (security, QoS, etc.) should be handle by the AC. Giving the operator / customer the freedom to run the IS function in AC or WTP is important and as far as I can tell doesn't break the CAPWAP model. Why it's important: well take #1 for example, if customer wishes to session to travel along the shorter path between peers, or maintain existing voice call when AC experience a failover and perform reboot (but new session or roaming obviously). Emek _____ From: Michael Montemurro [mailto:michael.montemurro@siemens.com] Sent: Thursday, June 16, 2005 3:35 PM To: Sadot, Emek (Emek); Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Emek, I just want to get clarification on your response. You believe there are four possibilities: 1) Split MAC - Bridge at WTP 2) Split MAC - Bridge at AC 3) Local MAC - Bridge at WTP 4) Local MAC - Bridge at AC I'd just like to understand how you envision case 1). What type of functionality would you envision would terminate at the AC? Could you be more specific on how you would handle WLAN management frames, security, and QoS in that case? Thanks, Mike Michael Montemurro Director, Advanced Technology and Standards Chantry Networks, A Siemens Company 1900 Minnesota Ct, Suite 125 Mississauga, ON, CANADA. T: 905-363-6413 F: 905-567-9900 E: michael.montemurro@siemens.com ------_=_NextPart_001_01C5733C.B24D3144 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Pat,

I respectfully dissagree with you = with=20 grouping together case 4. There is no reason why you couldn't terminate = 802.11=20 at the WTP and bridge data traffic to the AC.
 
Mike

From: capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Pat=20 Calhoun
Sent: June 17, 2005 8:53 AM
To: 'Darren = Loher';=20 Inderpreet Singh; 'Sadot, Emek (Emek)'; = capwap@frascone.com
Subject:=20 RE: [Capwap] Support for Traffic Separation

Darren,
 
I actually believe that CAPWAP should focus = on 2 and 3. I=20 do believe that there are situations where option 3 makes sense, such = as when=20 centralized monitoring and configuration of the WTPs is desired, = however local=20 bridging is required. Imagine a scenario where the link between the = WTP and=20 the AC is constrained and therefore cannot sustain that all traffic = be sent to=20 the AC. One such example would be a retail environment, where every = store has=20 a few APs, but these are all centrally managed, while the traffic is = locally=20 bridged. Obviously option 2 is required for all other=20 circumstances.
 
My issue with mandating options 2 and 4, is = that from a=20 user standpoint there are identical - and therefore the only = convenience that=20 we've created is for the implementors of the WTPs. However, from a=20 feature/function standpoint, they would end up being identical in = nature - and=20 if this is the case, I honestly don't understand why the WG should = focus on=20 creating two separate solutions to meet the exact same=20 goal.

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

 

From: capwap-admin@frascone.com = [mailto:capwap-admin@frascone.com] On Behalf Of Darren=20 Loher
Sent: Thursday, June 16, 2005 4:45 PM
To: = Inderpreet Singh; Sadot, Emek (Emek); = capwap@frascone.com
Subject:=20 RE: [Capwap] Support for Traffic Separation

Given the following=20 scenarios:

 

 1)=20 Split MAC - Bridge at WTP 

 2)=20 Split MAC - Bridge at AC

 3)=20 Local MAC - Bridge at WTP

 4) = Local MAC=20 - Bridge at AC

 

I agree = that #2-4=20 are required scenarios.  I am not sure that #1 is = required.  If=20 “bridge” means the IS function, #1 would be in conflict = with the recent=20 error correction/update of the taxonomy=20 document.

 

When the = IS=20 function is implemented at the WTP, the WTP must be a local MAC = WTP. =20 However, in a local MAC scenario the CAPWAP protocol must still = permit=20 tunneling or not tunneling user traffic to an AC.  A = particular WTP=20 device may not support this function, but the CAPWAP protocol MUST = allow it=20 (IMHO).  This would be compatible with the new update/error = correction=20 to the taxonomy document and gives flexibility for implementers to = create=20 traffic separation if they choose in split and local MAC=20 modes.

 

What = does everyone=20 think? (did I miss anything?)

 

-Darren

 

 

From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] = On Behalf Of Inderpreet=20 Singh
Sent: = Thursday, June=20 16, 2005 4:02 PM
To: Sadot,=20 Emek (Emek); capwap@frascone.com
Subject: RE: [Capwap] = Support for=20 Traffic Separation

 

 

>>"Further, one must assume = that there are=20 functions that reside in the AC that are much more than=20

>>just = "tunnel=20 termination", and if this is the case these functions are lost when = you resort to bridge

>>mode." - I = assume you=20 meant that some functionality will be lost if bridging is = implemented at the WTP,

>>so if = that's your=20 argument then the counter argument would be: how these=20 functions being materialized

>>in = Local MAc=20 arch?

 

If I am = not=20 mistaken, this discussion has let to two interpretations of the = word=20 “bridging” as well.

 

  1. Emek understands = bridging as=20 802.11 to 802.3 conversion.  Which is technically correct, = but really=20 confined definition in our context.  I think it would be = useful to=20 term in 802.11 MAC termination rather than simply=20 bridging.=20
  2. Pat, Mike and I = believe that=20 bridging in this context has to do with bridging the user traffic = to the=20 local physical interface.  Usually this is Ethernet in the = WTP=20 case.  Non-bridging would be where the traffic is tunneled = to the=20 AC.

 

So I = agree, if you=20 bridge locally (ie. if the 802.11 MAC is terminated Locally and = then the=20 resulting 802.3 packets are bridged to the local physical = interface), then=20 it is possible for example to lose the functionality of L3 roaming = of the=20 client.  However, in certain scenarios of deployments where = this=20 function/feature is not needed, local bridging is quite=20 useful.

 

Thanks

 

Inderpreet

 

From: Pat=20 Calhoun [mailto:pcalhoun@cisco.com]
Sent: Thursday, June 16, = 2005 5:25=20 PM
To: Sadot, = Emek (Emek);=20 'Michael Montemurro'; capwap@frascone.com
Subject: RE: [Capwap] = Support for=20 Traffic Separation

>=20 Giving = the operator=20 / customer the freedom to run the IS function in AC or WTP is = important=20 and as far as I can tell doesn't

> = break the=20 CAPWAP model. Why it's important: well take #1 for example, = if customer=20 wishes to session to travel along =

>=20 the shorter path between peers, or maintain existing = voice=20 call when AC experience a failover and perform reboot = (but new=20

>=20 session or roaming = obviously)."

 

Emek, I = don't see=20 how this can be achieved. A user's end device has a single IP = address. One=20 really cannot split the forwarding of user traffic based on the = relative=20 priority of the traffic or based on network failures, because the = return=20 path of the user's traffic would always end up on its home subnet. = The above=20 suggestion where sometimes the user's traffic is briged and = sometimes it is=20 tunneled, would REQUIRE the WTP and the AC to be on the same subnet = - which=20 conflicts with the "Interconnection Objective". Further, one must = assume=20 that there are functions that reside in the AC that are much more = than just=20 "tunnel termination", and if this is the case these functions are = lost when=20 you resort to brige mode.

 

If=20 redundancy/resiliency is required, then it must be provided in the = CAPWAP=20 protocol through some other = means.

 

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

 

 

From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] = On Behalf Of Sadot, Emek=20 (Emek)
Sent: = Thursday,=20 June 16, 2005 5:54 AM
To:=20 Michael Montemurro; Pat Calhoun; capwap@frascone.com
Subject: RE: [Capwap] = Support for=20 Traffic Separation

Mike,

 

To = make sure I am=20 clear: by "bridge" I was referring to the Integration = Services -=20  bridging between 802.11 and=20 802.3.

All=20 management frames (security, QoS, etc.) should be handle by = the=20 AC.

 

Giving = the=20 operator / customer the freedom to run the IS function in AC = or WTP=20 is important and as far as I can tell doesn't break the CAPWAP=20 model.

Why = it's=20 important: well take #1 for example, if customer = wishes to=20 session to travel along the shorter path between peers, = or maintain existing voice call when AC experience = a=20 failover and perform reboot (but new = session or roaming=20 obviously).

 

Emek

 

From:=20 Michael Montemurro [mailto:michael.montemurro@siemens.com] =
Sent: Thursday, June 16, = 2005 3:35=20 PM
To: Sadot, = Emek=20 (Emek); Pat Calhoun; capwap@frascone.com
Subject: RE: [Capwap] = Support for=20 Traffic Separation

Emek,

 

I just = want to=20 get clarification on your response. You believe there are four=20 possibilities:

 

    1) = Split MAC -=20 Bridge at WTP

    2) = Split MAC -=20 Bridge at AC

    3) = Local MAC -=20 Bridge at WTP

    4) Local=20 MAC - Bridge at AC

 

I'd = just like to=20 understand how you envision case 1).  What type of = functionality=20 would you envision would terminate at the AC? Could you be more = specific=20 on how you would handle WLAN management frames, security, and QoS = in that=20 case?

 

Thanks,

 

    Mike

 

Michael=20 Montemurro
Director, Advanced Technology and = Standards
Chantry=20 Networks, A Siemens Company
1900 Minnesota Ct, Suite=20 125
Mississauga, ON,=20 CANADA.
T:=20 905-363-6413
F: 905-567-9900
E: = michael.montemurro@siemens.com

------_=_NextPart_001_01C5733C.B24D3144-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jun 17 09:40:17 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18150 for ; Fri, 17 Jun 2005 09:40:16 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 751FA20583; Fri, 17 Jun 2005 09:40:14 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DE0C920493; Fri, 17 Jun 2005 09:40:09 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DE31420493 for ; Fri, 17 Jun 2005 09:39:53 -0400 (EDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202]) by mail.frascone.com (Postfix) with ESMTP id 4643E202C1 for ; Fri, 17 Jun 2005 09:39:51 -0400 (EDT) Received: by wproxy.gmail.com with SMTP id 71so1038419wra for ; Fri, 17 Jun 2005 06:39:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=H1rAgEjFUDaTnOKBbgT58sTYdAzZXF6FoCFsVdPK/Hd2Gi23DXUbFJB3eS2Z7l2kicvoOOBq2R106tYlLeEypnRgytsLdhsVPS25gFq0W5I3EDI157WvGE1lU4x25QNBBnX8Y9r1Ooi3ZAmuSXDXjPdeGvcropzVbl1vHGrCnmY= Received: by 10.54.73.15 with SMTP id v15mr1262281wra; Fri, 17 Jun 2005 06:39:51 -0700 (PDT) Received: by 10.54.140.4 with HTTP; Fri, 17 Jun 2005 06:39:50 -0700 (PDT) Message-ID: From: Chris Hinsz Reply-To: Chris Hinsz To: Pat Calhoun Subject: Re: [Capwap] Taxonomy Recommendations: encrypt/decrypt Cc: Dan Harkins , Clint Chaplin , mmani@avaya.com, lily.l.yang@intel.com, capwap@frascone.com In-Reply-To: <200506171257.j5HCvb7l025656@sj-core-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200506162347.j5GNl8pC033959@homebrew.trpz.com> <200506171257.j5HCvb7l025656@sj-core-2.cisco.com> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 17 Jun 2005 06:39:50 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Pat, Thanks for directing me to those sections. I can now certainly see the issue you're referring to. Given this information I agree that CAPWAP should address this. CSH On 6/17/05, Pat Calhoun wrote: > > The fact that it would be problematic with HCCA is not > > anything that needs to be mentioned in any CAPWAP statement. > > It's useful to bring up during a product design phase when > > deciding where to do bulk data encryption in a particular > > split MAC but such architectures exist and all CAPWAP has to > > do is support it not say why one particular approach is > > better or worse than another. > > > > Note that you split the MAC the same way we did so my > > objection is not defensive or political. I just don't think > > it has any place in CAPWAP. >=20 > I disagree - and for very specific technical reasons. >=20 > This is the one area where splitting the MAC has > significant implications. See my previous e-mail response to > Chris Hinsz, but to summarize, in HCCA the fragmentation must > occur prior to encryption in order to meet the service period > negotiated within HCCA. One cannot centralize the encryption > function (hence fragment) without direct access to the RF in > real-time in order to gain access to interference and co-channel > information. >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jun 17 10:19:16 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22050 for ; Fri, 17 Jun 2005 10:19:12 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D7161205B9; Fri, 17 Jun 2005 10:19:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CC2ED20597; Fri, 17 Jun 2005 10:19:08 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2C12020597 for ; Fri, 17 Jun 2005 10:18:49 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 1276C20583 for ; Fri, 17 Jun 2005 10:18:46 -0400 (EDT) Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5HE6rAK009266 for ; Fri, 17 Jun 2005 10:06:53 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5HE6pAK009231 for ; Fri, 17 Jun 2005 10:06:52 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57347.77193C93" Subject: RE: [Capwap] Support for Traffic Separation Message-ID: <5844A41F4E146044A2E8356C6328588008DFDAD7@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] Support for Traffic Separation Thread-Index: AcVycBVZCKVxg3scSxq6fXM8oyZE3gACvBowAA5KpgAAAof+8AAhYlAA From: "Sadot, Emek (Emek)" To: "Pat Calhoun" , "Michael Montemurro" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 17 Jun 2005 10:18:42 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C57347.77193C93 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pat, =20 I did read the draft. I just hold a different opinion. Please see inline. =20 Emek _____ =20 From: Pat Calhoun [mailto:pcalhoun@cisco.com]=20 Sent: Friday, June 17, 2005 1:02 AM To: Sadot, Emek (Emek); 'Michael Montemurro'; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation So if you've had a chance to read the taxonomy recommendations document that I submitted, I think you'll understand that my argument is that there must be a clear delineation between Split and Local MAC. A WTP that has all of the MAC, but sends a message to the AC that encapsulates most of the information found in some 802.11 mac management packet, then you combine this with tunneling, you end up with something that is identical in fuctionatlity to a Split MAC architecture... but without the name. [Emek] I totally agree.=20 =20 I think that we should pick two modes of operation, that are distinct and address a customer need, and then create a standard to address them. [Emek] I have an issue with the distinct part. I would like to see some level of flexibility in each mode of operation, and especially the ability to run the bridging function in the WTP for Split MAC arch. =20 I interpreter Split MAC as performing 802.11 real-time functions in the WTP, and since bridging is a parallel function and since I believe that Split is superior over Local I would like to stress this point. =20 I see merits in implementing the bridge function at the WTP in Split MAC arch, since: (a) shortest path between peers, (b) increase solution's MTBF as end user sessions will be maintained while connection between WTP and AC is lost or AC reboot. An example: say the AC is in Enterprise' headquarter in NYC and a WTP(s) are located in London office, now i am at London office using my wi-fi phone to dial to a collage of mine at the same office (or a customer in GB), if the bridging function is implemented at the AC the call will be travel through the NYC office - doesn't make sense to me. =20 So i would like to present two discussions issues: 1. Pros and cons of implementing the bridging function in WTP / Split MAC (I stated mine). 2. What implementation-challenges / protocol-complexity / functionality-lost a bridging function at the WTP for Split MAC introduce that would worth shy away from such configuration. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) Sent: Thursday, June 16, 2005 1:47 PM To: Pat Calhoun; Michael Montemurro; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation =09 =09 Pat, I understand where you are coming from and respect it, though I respectfully disagree with the definition: tunneling of user data is Split, while local bridging is Local. =20 Emek _____ =20 From: Pat Calhoun [mailto:pcalhoun@cisco.com]=20 Sent: Thursday, June 16, 2005 4:58 PM To: 'Michael Montemurro'; Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation =09 =09 Emek, =20 Note that I disagree with the need for such complexity in the protocol, and my belief is this confusion stems from the lack of conclusion in the taxonomy draft. There is simply much more to tunneling traffic than just the Distribution and Integration Service, so one must actually be very specific in each case on where every function resides. My belief is that tunneling of user data is Split, while local bridging is Local. We have documented this in the Taxonomy Recommendations document, which I would urge you to comment on.=20 =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 _____ =20 From: Michael Montemurro [mailto:michael.montemurro@siemens.com]=20 Sent: Thursday, June 16, 2005 5:35 AM To: Sadot, Emek (Emek); Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation =09 =09 Emek, =20 I just want to get clarification on your response. You believe there are four possibilities: =20 1) Split MAC - Bridge at WTP 2) Split MAC - Bridge at AC 3) Local MAC - Bridge at WTP 4) Local MAC - Bridge at AC =20 I'd just like to understand how you envision case 1). What type of functionality would you envision would terminate at the AC? Could you be more specific on how you would handle WLAN management frames, security, and QoS in that case? =20 Thanks, =20 Mike =20 Michael Montemurro Director, Advanced Technology and Standards Chantry Networks, A Siemens Company 1900 Minnesota Ct, Suite 125 Mississauga, ON, CANADA. T: 905-363-6413 F: 905-567-9900 E: michael.montemurro@siemens.com=20 _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) Sent: June 15, 2005 4:50 PM To: Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation =09 =09 Pat, =20 Thanks for your response though it didn't address the issue I was trying to raise. The problem was at my end - rereading my question I realize I wasn't clear enough. My apologies. Let me rephrase my concern though this time in a suggestion manner (rather then challenging specific proposed protocol). =20 In my opinion the CAPWAP protocol shouldn't tie bridging the user's data traffic function to a specific architecture (split or local) and be flexible enough to accommodate all four permutations: Split / MAC & bridging at AC / WTP. As part of the initial configuration phase the AC shall instruct the WTP to either locally bridge data traffic or tunnel to an AC.=20 =20 Regards, Emek _____ =20 From: Pat Calhoun [mailto:pcalhoun@cisco.com]=20 Sent: Wednesday, June 15, 2005 2:17 PM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation =09 =09 My apologies for the latency in my response. =20 Yes, the LWAPP protocol supports what we refer to Local and Split MAC. In Split MAC, the user's traffic is tunneled between the WTP and the AC while in Local MAC the data is locally bridged. Draft 02 of the LWAPP draft does not include enough text to cover the Local MAC case, even though shipping LWAPP products do this today, but we will have this fixed up in -03. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 _____ =20 From: Sadot, Emek (Emek) [mailto:esadot@avaya.com]=20 Sent: Tuesday, June 07, 2005 12:35 PM To: Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation =09 =09 Pat, =20 A question regarding section 2.1.2 Support for Traffic Separation - author's interpretation of Support for Traffic Separation: does LWAPP supports an architecture in which the DS is implemented at the WTP? (avoid tunneling data frames to a control entity). =20 Regards, Emek _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun Sent: Wednesday, June 01, 2005 10:32 AM To: capwap@frascone.com Subject: [Capwap] LWAPP Self Evaluation draft posted yesterday =09 =09 All, =20 As per the protocol submission rules laid out by the chairs, the authors of the LWAPP protocol submitted a self evaluation to the I-D draft editors yesterday. I have made the draft available at http://www.capwap.org/draft-calhoun-capwap-lwapp-objectives-comparison-0 0.txt . =20 Comments welcomed! =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ------_=_NextPart_001_01C57347.77193C93 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Pat,
 
I did = read the=20 draft. I just hold a different opinion.
Please see inline.
 
=
Emek
From: Pat Calhoun = [mailto:pcalhoun@cisco.com]=20
Sent: Friday, June 17, 2005 1:02 AM
To: Sadot, Emek = (Emek);=20 'Michael Montemurro'; capwap@frascone.com
Subject: RE: = [Capwap]=20 Support for Traffic Separation

So if you've had a chance to read the = taxonomy=20 recommendations document that I submitted, I think you'll understand = that my=20 argument is that there must be a clear delineation between Split and = Local MAC.=20 A WTP that has all of the MAC, but sends a message to the AC that = encapsulates=20 most of the information found in some 802.11 mac management = packet, then=20 you combine this with tunneling, you end up with something that is=20 identical in fuctionatlity to a Split MAC architecture... but without = the=20 name.
[Emek] I=20 totally agree. 
 
I think that we should pick two modes of operation, that are = distinct and=20 address a customer need, and then create a standard to address = them.

[Emek] I = have an=20 issue with the distinct part. I would like to see some level = of=20 flexibility in each mode of operation, and especially the ability to run = the=20 bridging function in the WTP for Split MAC arch.

 

I=20 interpreter Split MAC as performing 802.11 real-time = functions in the=20 WTP, and since bridging is a parallel function and since I believe = that=20 Split is superior over Local I would like to stress=20 this point.

 

I see merits = in=20 implementing the bridge function at the WTP in Split = MAC arch,=20 since: (a) shortest path between peers, (b) increase solution's = MTBF=20 as end user sessions will be maintained while connection = between=20 WTP and AC is lost or AC reboot. An example: say the AC is in=20 Enterprise' headquarter in NYC and a WTP(s) are located in = London=20 office, now i am at London office using my wi-fi phone to dial to a = collage=20 of mine at the same office (or a customer in GB), if the bridging = function=20 is implemented at the AC the call will be travel through the NYC office = -=20 doesn't make sense to me.

 

So i would = like to=20 present two discussions issues:

1. Pros and = cons of=20 implementing the bridging function in WTP / Split MAC (I stated mine).

2. What=20 implementation-challenges / protocol-complexity / = functionality-lost a=20 bridging function at the WTP for Split MAC introduce that = would worth=20 shy away from such configuration.
 

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

From: capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek=20 (Emek)
Sent: Thursday, June 16, 2005 1:47 PM
To: = Pat=20 Calhoun; Michael Montemurro; capwap@frascone.com
Subject: = RE:=20 [Capwap] Support for Traffic Separation

Pat,=20 I understand where you are coming from and respect it, though I = respectfully=20 disagree with the definition: tunneling of user = data is=20 Split, while local bridging is Local.
 
Emek

From: Pat Calhoun = [mailto:pcalhoun@cisco.com]=20
Sent: Thursday, June 16, 2005 4:58 PM
To: = 'Michael=20 Montemurro'; Sadot, Emek (Emek); = capwap@frascone.com
Subject: RE:=20 [Capwap] Support for Traffic Separation

Emek,
 
Note that I disagree with the need for such = complexity in=20 the protocol, and my belief is this confusion stems from the lack of=20 conclusion in the taxonomy draft. There is simply much more to = tunneling=20 traffic than just the Distribution and Integration Service, so one = must=20 actually be very specific in each case on where every function = resides. My=20 belief is that tunneling of user data is Split, while local bridging = is Local.=20 We have documented this in the Taxonomy Recommendations document, = which I=20 would urge you to comment on.
 

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

 

From: Michael Montemurro=20 [mailto:michael.montemurro@siemens.com]
Sent: Thursday, = June 16,=20 2005 5:35 AM
To: Sadot, Emek (Emek); Pat Calhoun;=20 capwap@frascone.com
Subject: RE: [Capwap] Support for = Traffic=20 Separation

Emek,
 
I just want to get clarification on your = response. You=20 believe there are four possibilities:
 
   =20 1) Split MAC - = Bridge at=20 WTP
   =20 2) Split MAC - = Bridge at=20 AC
   =20 3) Local MAC - = Bridge at=20 WTP
    4) Local MAC - Bridge at AC
 
I'd just like to understand how you = envision case 1).=20  What type of functionality would you envision would terminate = at the=20 AC? Could you be more specific on how you would handle WLAN = management=20 frames, security, and QoS in that case?
 
Thanks,
 
   =20 Mike
 

Michael Montemurro
Director, Advanced = Technology and=20 Standards
Chantry Networks, A Siemens Company
1900 Minnesota = Ct, Suite=20 125
Mississauga, ON, CANADA.
T: 905-363-6413
F: = 905-567-9900
E:=20 michael.montemurro@siemens.com


From: = capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek = (Emek)
Sent: June 15, 2005 4:50 PM
To: Pat = Calhoun;=20 capwap@frascone.com
Subject: RE: [Capwap] Support for = Traffic=20 Separation

Pat,
 
Thanks for your response though it didn't address = the issue I=20 was trying to raise. The problem was at my end = - rereading=20 my question I realize I wasn't clear enough. My apologies. Let me = rephrase=20 my concern though this time in a suggestion manner (rather = then=20 challenging specific proposed protocol).
 
In my opinion the CAPWAP protocol shouldn't tie = bridging the=20 user's data traffic function to a specific architecture = (split or=20 local) and be flexible enough to accommodate all four=20 permutations: Split / MAC & bridging at AC / = WTP.
As part of the initial configuration phase the = AC=20 shall instruct the WTP to either locally bridge data traffic = or=20 tunnel to an AC.
 
Regards,
Emek

From: Pat Calhoun=20 [mailto:pcalhoun@cisco.com]
Sent: Wednesday, June 15, = 2005 2:17=20 PM
To: Sadot, Emek (Emek);=20 capwap@frascone.com
Subject: RE: [Capwap] Support for = Traffic=20 Separation

My apologies for the latency in my=20 response.
 
Yes, the LWAPP protocol supports what we = refer to=20 Local and Split MAC. In Split MAC, the user's traffic is=20 tunneled between the WTP and the AC while in Local MAC the = data is=20 locally bridged. Draft 02 of the LWAPP draft does not include = enough text=20 to cover the Local MAC case, even though shipping LWAPP products = do this=20 today, but we will have this fixed up in = -03.

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

 

From: Sadot, Emek (Emek)=20 [mailto:esadot@avaya.com]
Sent: Tuesday, June 07, = 2005 12:35=20 PM
To: Pat Calhoun; = capwap@frascone.com
Subject: RE:=20 [Capwap] Support for Traffic Separation

Pat,
 
A question regarding=20 section 2.1.2 Support for Traffic = Separation - author's interpretation = of Support for Traffic Separation:=20 does LWAPP supports an architecture in which the DS is = implemented=20 at the WTP? (avoid tunneling data frames to a control=20 entity).
 
Regards,
Emek

From: = capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Pat=20 Calhoun
Sent: Wednesday, June 01, 2005 10:32 = AM
To:=20 capwap@frascone.com
Subject: [Capwap] LWAPP Self = Evaluation=20 draft posted yesterday

All,
 
As per the=20 protocol submission rules laid out by the chairs, the authors of = the=20 LWAPP protocol submitted a self evaluation to the I-D draft = editors=20 yesterday. I have made the draft available at http://www.capwap.org/draft-calhoun-capwap-lwapp-objectives-comp= arison-00.txt.
 
Comments=20 welcomed!
 

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

=
 
------_=_NextPart_001_01C57347.77193C93-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jun 17 10:45:24 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24314 for ; Fri, 17 Jun 2005 10:45:16 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 84DD4205BA; Fri, 17 Jun 2005 10:45:14 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 346E0205AE; Fri, 17 Jun 2005 10:45:10 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1B54C205AE for ; Fri, 17 Jun 2005 10:44:23 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id A9B6220583 for ; Fri, 17 Jun 2005 10:44:21 -0400 (EDT) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5HEfqdd001397 for ; Fri, 17 Jun 2005 10:41:52 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5HEfpdd001374 for ; Fri, 17 Jun 2005 10:41:51 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5734B.0A040969" Subject: RE: [Capwap] Support for Traffic Separation Message-ID: <5844A41F4E146044A2E8356C6328588008DFDB10@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] Support for Traffic Separation Thread-Index: AcVyv0Q9lzN8dWOqQWi8yNxovbTMLAAC7bzAAB/ajcA= From: "Sadot, Emek (Emek)" To: "Darren Loher" , "Inderpreet Singh" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 17 Jun 2005 10:44:17 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C5734B.0A040969 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Darren, =20 Please see inline. =20 Emek _____ =20 From: Darren Loher [mailto:DLoher@rovingplanet.com]=20 Sent: Friday, June 17, 2005 2:45 AM To: Inderpreet Singh; Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Given the following scenarios: =20 1) Split MAC - Bridge at WTP =20 2) Split MAC - Bridge at AC 3) Local MAC - Bridge at WTP 4) Local MAC - Bridge at AC =20 I agree that #2-4 are required scenarios. I am not sure that #1 is required. If "bridge" means the IS function, #1 would be in conflict with the recent error correction/update of the taxonomy document. [Emek] The taxonomy draft didn't try to define Local / Split (and Remote) arch rather to describe the observed implementations in the market. =20 When the IS function is implemented at the WTP, the WTP must be a local MAC WTP. =20 [Emek] I disagree. In my mind IS function can be implemented at the WTP in Split MAC - IS and 802.11 real time function at WTP, whereas 802.11 management frame terminated at the AC. However, in a local MAC scenario the CAPWAP protocol must still permit tunneling or not tunneling user traffic to an AC. A particular WTP device may not support this function, but the CAPWAP protocol MUST allow it (IMHO). This would be compatible with the new update/error correction to the taxonomy document and gives flexibility for implementers to create traffic separation if they choose in split and local MAC modes. =20 What does everyone think? (did I miss anything?) =20 -Darren =20 =20 _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Inderpreet Singh Sent: Thursday, June 16, 2005 4:02 PM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation =20 =20 >>"Further, one must assume that there are functions that reside in the AC that are much more than=20 >>just "tunnel termination", and if this is the case these functions are lost when you resort to bridge=20 >>mode." - I assume you meant that some functionality will be lost if bridging is implemented at the WTP,=20 >>so if that's your argument then the counter argument would be: how these functions being materialized=20 >>in Local MAc arch? =20 If I am not mistaken, this discussion has let to two interpretations of the word "bridging" as well. =20 1. Emek understands bridging as 802.11 to 802.3 conversion. Which is technically correct, but really confined definition in our context. I think it would be useful to term in 802.11 MAC termination rather than simply bridging.=20 2. Pat, Mike and I believe that bridging in this context has to do with bridging the user traffic to the local physical interface. Usually this is Ethernet in the WTP case. Non-bridging would be where the traffic is tunneled to the AC.=20 =20 So I agree, if you bridge locally (ie. if the 802.11 MAC is terminated Locally and then the resulting 802.3 packets are bridged to the local physical interface), then it is possible for example to lose the functionality of L3 roaming of the client. However, in certain scenarios of deployments where this function/feature is not needed, local bridging is quite useful. =20 Thanks =20 Inderpreet =20 _____ =20 From: Pat Calhoun [mailto:pcalhoun@cisco.com]=20 Sent: Thursday, June 16, 2005 5:25 PM To: Sadot, Emek (Emek); 'Michael Montemurro'; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation > Giving the operator / customer the freedom to run the IS function in AC or WTP is important and as far as I can tell doesn't=20 > break the CAPWAP model. Why it's important: well take #1 for example, if customer wishes to session to travel along=20 > the shorter path between peers, or maintain existing voice call when AC experience a failover and perform reboot (but new=20 > session or roaming obviously)." =20 Emek, I don't see how this can be achieved. A user's end device has a single IP address. One really cannot split the forwarding of user traffic based on the relative priority of the traffic or based on network failures, because the return path of the user's traffic would always end up on its home subnet. The above suggestion where sometimes the user's traffic is briged and sometimes it is tunneled, would REQUIRE the WTP and the AC to be on the same subnet - which conflicts with the "Interconnection Objective". Further, one must assume that there are functions that reside in the AC that are much more than just "tunnel termination", and if this is the case these functions are lost when you resort to brige mode. =20 If redundancy/resiliency is required, then it must be provided in the CAPWAP protocol through some other means. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) Sent: Thursday, June 16, 2005 5:54 AM To: Michael Montemurro; Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Mike, =20 To make sure I am clear: by "bridge" I was referring to the Integration Services - bridging between 802.11 and 802.3. All management frames (security, QoS, etc.) should be handle by the AC. =20 Giving the operator / customer the freedom to run the IS function in AC or WTP is important and as far as I can tell doesn't break the CAPWAP model. Why it's important: well take #1 for example, if customer wishes to session to travel along the shorter path between peers, or maintain existing voice call when AC experience a failover and perform reboot (but new session or roaming obviously). =20 Emek =20 =09 _____ =20 From: Michael Montemurro [mailto:michael.montemurro@siemens.com] Sent: Thursday, June 16, 2005 3:35 PM To: Sadot, Emek (Emek); Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Support for Traffic Separation Emek, =20 I just want to get clarification on your response. You believe there are four possibilities: =20 1) Split MAC - Bridge at WTP 2) Split MAC - Bridge at AC 3) Local MAC - Bridge at WTP 4) Local MAC - Bridge at AC =20 I'd just like to understand how you envision case 1). What type of functionality would you envision would terminate at the AC? Could you be more specific on how you would handle WLAN management frames, security, and QoS in that case? =20 Thanks, =20 Mike =20 Michael Montemurro Director, Advanced Technology and Standards Chantry Networks, A Siemens Company 1900 Minnesota Ct, Suite 125 Mississauga, ON, CANADA. T: 905-363-6413 F: 905-567-9900 E: michael.montemurro@siemens.com=20 ------_=_NextPart_001_01C5734B.0A040969 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Darren,
 
Please=20 see inline.
 
Emek

From: Darren Loher=20 [mailto:DLoher@rovingplanet.com]
Sent: Friday, June 17, 2005 = 2:45=20 AM
To: Inderpreet Singh; Sadot, Emek (Emek);=20 capwap@frascone.com
Subject: RE: [Capwap] Support for Traffic=20 Separation

Given the following=20 scenarios:

 

 1) Split=20 MAC - Bridge at WTP 

 2) Split=20 MAC - Bridge at AC

 3) Local=20 MAC - Bridge at WTP

 4) = Local MAC -=20 Bridge at AC

 

I agree that = #2-4 are=20 required scenarios.  I am not sure that #1 is required.  If = “bridge”=20 means the IS function, #1 would be in conflict with the recent error=20 correction/update of the taxonomy document.
[Emek] The taxonomy draft didn't try to = define Local /=20 Split (and Remote) arch rather to describe the observed = implementations in=20 the market.

 

When the IS = function is=20 implemented at the WTP, the WTP must be a local MAC WTP. 
[Emek] I disagree. = In my=20 mind IS function can be implemented at the WTP in Split MAC - = IS=20 and 802.11 real time function at WTP, whereas 802.11 management = frame=20 terminated at the AC.


However, = in a local=20 MAC scenario the CAPWAP protocol must still permit tunneling or not = tunneling=20 user traffic to an AC.  A particular WTP device may not support = this=20 function, but the CAPWAP protocol MUST allow it (IMHO).  This would = be=20 compatible with the new update/error correction to the taxonomy document = and=20 gives flexibility for implementers to create traffic separation if they = choose=20 in split and local MAC modes.

 

What does = everyone=20 think? (did I miss anything?)

 

-Darren

 

 

From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Inderpreet = Singh
Sent: Thursday, June 16, 2005 = 4:02=20 PM
To: Sadot, Emek = (Emek);=20 capwap@frascone.com
Subject:=20 RE: [Capwap] Support for Traffic = Separation

 

 

>>"Further, one must assume that = there are=20 functions that reside in the AC that are much more than=20

>>just "tunnel=20 termination", and if this is the case these functions are lost when=20 you resort to bridge

>>mode." - I assume = you meant=20 that some functionality will be lost if bridging is = implemented at the=20 WTP,

>>so if that's = your=20 argument then the counter argument would be: how these=20 functions being materialized

>>in Local MAc = arch?

 

If I am not = mistaken,=20 this discussion has let to two interpretations of the word = “bridging” as=20 well.

 

  1. Emek understands = bridging as=20 802.11 to 802.3 conversion.  Which is technically correct, but = really=20 confined definition in our context.  I think it would be useful = to term=20 in 802.11 MAC termination rather than simply=20 bridging.=20
  2. Pat, Mike and I believe = that=20 bridging in this context has to do with bridging the user traffic to = the local=20 physical interface.  Usually this is Ethernet in the WTP = case. =20 Non-bridging would be where the traffic is tunneled to the=20 AC.

 

So I agree, = if you=20 bridge locally (ie. if the 802.11 MAC is terminated Locally and then the = resulting 802.3 packets are bridged to the local physical interface), = then it is=20 possible for example to lose the functionality of L3 roaming of the=20 client.  However, in certain scenarios of deployments where this=20 function/feature is not needed, local bridging is quite=20 useful.

 

Thanks

 

Inderpreet

 

From: Pat=20 Calhoun [mailto:pcalhoun@cisco.com]
Sent: Thursday, June 16, 2005 = 5:25=20 PM
To: Sadot, Emek = (Emek);=20 'Michael Montemurro'; capwap@frascone.com
Subject: RE: [Capwap] Support for = Traffic=20 Separation

>=20 Giving the = operator /=20 customer the freedom to run the IS function in AC or WTP is = important and=20 as far as I can tell doesn't

> break = the CAPWAP=20 model. Why it's important: well take #1 for example, if customer=20 wishes to session to travel along =

> = the shorter=20 path between peers, or maintain existing voice call when = AC=20 experience a failover and perform reboot (but new=20

>=20 session or roaming obviously)."

 

Emek, I don't = see how=20 this can be achieved. A user's end device has a single IP address. One = really=20 cannot split the forwarding of user traffic based on the relative = priority of=20 the traffic or based on network failures, because the return path of the = user's=20 traffic would always end up on its home subnet. The above suggestion = where=20 sometimes the user's traffic is briged and sometimes it is tunneled, = would=20 REQUIRE the WTP and the AC to be on the same subnet - which conflicts = with the=20 "Interconnection Objective". Further, one must assume that there are = functions=20 that reside in the AC that are much more than just "tunnel termination", = and if=20 this is the case these functions are lost when you resort to brige=20 mode.

 

If=20 redundancy/resiliency is required, then it must be provided in the = CAPWAP=20 protocol through some other means.

 

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

 

 

From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek=20 (Emek)
Sent: = Thursday, June=20 16, 2005 5:54 AM
To: Michael=20 Montemurro; Pat Calhoun; capwap@frascone.com
Subject: RE: [Capwap] Support = for Traffic=20 Separation

Mike,

 

To make = sure I am=20 clear: by "bridge" I was referring to the Integration = Services -=20  bridging between 802.11 and = 802.3.

All=20 management frames (security, QoS, etc.) should be handle by the=20 AC.

 

Giving the = operator /=20 customer the freedom to run the IS function in AC or WTP is = important and=20 as far as I can tell doesn't break the CAPWAP=20 model.

Why it's = important:=20 well take #1 for example, if customer wishes to session=20 to travel along the shorter path between peers,=20 or maintain existing voice call when AC experience a = failover=20 and perform reboot (but new session or roaming=20 obviously).

 

Emek

 

From: Michael=20 Montemurro [mailto:michael.montemurro@siemens.com]
Sent: Thursday, June 16, 2005 = 3:35=20 PM
To: Sadot, Emek = (Emek);=20 Pat Calhoun; capwap@frascone.com
Subject: RE: [Capwap] Support = for Traffic=20 Separation

Emek,

 

I just want = to get=20 clarification on your response. You believe there are four=20 possibilities:

 

    1) Split = MAC - Bridge=20 at WTP

    2) Split = MAC - Bridge=20 at AC

    3) Local = MAC - Bridge=20 at WTP

    4) = Local MAC -=20 Bridge at AC

 

I'd just = like to=20 understand how you envision case 1).  What type of functionality = would=20 you envision would terminate at the AC? Could you be more specific on = how you=20 would handle WLAN management frames, security, and QoS in that=20 case?

 

Thanks,

 

    Mike

 

Michael=20 Montemurro
Director, Advanced Technology and Standards
Chantry = Networks,=20 A Siemens Company
1900 Minnesota Ct, Suite=20 125
Mississauga, ON, CANADA.
T: = 905-363-6413
F:=20 905-567-9900
E: michael.montemurro@siemens.com

------_=_NextPart_001_01C5734B.0A040969-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jun 17 10:57:16 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24957 for ; Fri, 17 Jun 2005 10:57:14 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7F3C6205A0; Fri, 17 Jun 2005 10:57:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9CFD520452; Fri, 17 Jun 2005 10:57:09 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 63FC820452 for ; Fri, 17 Jun 2005 10:56:59 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id 43A58202B7 for ; Fri, 17 Jun 2005 10:56:57 -0400 (EDT) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5HEsSdd018847 for ; Fri, 17 Jun 2005 10:54:28 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5HEsRdd018826 for ; Fri, 17 Jun 2005 10:54:27 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Taxonomy Recommendations: encrypt/decrypt Message-ID: <5844A41F4E146044A2E8356C6328588008DFDB2B@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] Taxonomy Recommendations: encrypt/decrypt Thread-Index: AcVyxawE2SB7ZDG9SXKXLH2WL/XSUAAAVyMAACEdDlA= From: "Sadot, Emek (Emek)" To: "Pat Calhoun" , "Clint Chaplin" , "Mani, Mahalingam (Mahalingam)" , Cc: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 17 Jun 2005 10:56:53 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Pat, The three comments made so far against your draft with regard to the Split MAC arch - Bridging at WTP, HCCA and encryption/decryption - show a pattern: in term of labor division the Split MAC arch is not homogenous. It may be constructive to consider "splitting" the Split arch or allow for several functions to run at the AC or WTP. Regards, Emek -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun Sent: Friday, June 17, 2005 2:02 AM To: 'Clint Chaplin'; Mani, Mahalingam (Mahalingam); lily.l.yang@intel.com Cc: capwap@frascone.com Subject: RE: [Capwap] Taxonomy Recommendations: encrypt/decrypt Clint, while I am OK with the proposed approach you are stating as long as CAPWAP's statement is clear that centralized encryption can be done either in the WTP or the AC, but the latter cannot work w/ HCCA. From a procedural standpoint, I can make changes to the taxonomy recommendations document, or the chairs can find another medium on which to document this. Either way works for me. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Clint Chaplin [mailto:cchaplin@sj.symbol.com] > Sent: Thursday, June 16, 2005 3:48 PM > To: mmani@avaya.com; pcalhoun@cisco.com; lily.l.yang@intel.com > Cc: capwap@frascone.com > Subject: RE: [Capwap] Taxonomy Recommendations: encrypt/decrypt >=20 > There is one issue in how to split the "split architecture"=20 > that will be somewhat contentious in generating a standard for CAPWAP. > That issue is: who handles the 802.11i encryption decryption? There=20 > is already in the market from major vendors equipment that falls on=20 > both sides of this division. If the CAPWAP standard is to be=20 > inclusive with existing architectural decisions, this one is going to=20 > have to be thrashed out. In my opinion, the correct answer should > be: both are supported. >=20 > Clint (JOATMON) Chaplin > Wireless Security Advisor > Wireless Standards Manager >=20 > >>> "Mani, Mahalingam (Mahalingam)" 6/16/05 > 07:13:18 > >>> >>> > I have no objections to this 'bug-fix' if it can happen in time and=20 > has no author/WG objections. We can request the RFC Ed. to hold off. >=20 > As for the other issue on split-MAC interpretation: > The split-discussion is long overdue; and is worth having - to help=20 > evaluation as well. I think resolution of the discussion is important=20 > to arrive at the best approach to CAPWAP protocol accommodating/not=20 > split variants. >=20 > History: > We had clearly noted not to make any recommendations on what a split=20 > characteristic must be in the taxonomy. This has perhaps been argued=20 > many times in (taxonomy) design team and in IETF58-62 as well. There=20 > was no scope for us in the then charter to venture that way. >=20 > When APF AHC initially started its work - the hope was it would offer=20 > enough information for CAPWAP to draw conclusions for future work;=20 > there were no expectations on what they would recommend the split=20 > ought to be once they were chartered (there were hopes much prior to=20 > that). Inasmuch as IEEE 802.11 endorsed and acknowledged the=20 > documented splits caused no standards departure/breakage in=20 > implementation or behavior - by its review of the taxonomy draft - we=20 > had validated all architectures from IEEE 802.11 perspective. >=20 > It was clear when APF AHC group was formed that it will transpire to=20 > provide only clarifying interpretations of functions - not delineate=20 > or standardize splits. >=20 > -mani > =3D=3D=3D=3D=3D=3D > -----Original Message----- > From: Yang, Lily L [mailto:lily.l.yang@intel.com] > Sent: Wednesday, June 15, 2005 1:19 PM > To: Mani, Mahalingam (Mahalingam); Pat Calhoun > Cc: capwap@frascone.com > Subject: RE: [Capwap] Taxonomy Recommendations >=20 >=20 > Hi, Pat and Mani -- >=20 > I have not read through the entire Taxonomy Recommendations document=20 > yet, but just reading through the first few pages, I believe the=20 > authors are correct in pointing out one of the "inconsistency" (error) > in the taxonomy draft. There was a paragraph in the taxonomy draft=20 > Section 5.6: > " The commonalities and differences between Local MAC and Split MAC=20 > are > most clearly seen by comparing Figure 7 to Figure 10. The > commonality is that 802.11 control frames are terminated at WTPs in > both cases. The main difference between Local MAC and Split MAC is > that the WTP terminates only the 802.11 control frames in the Split > MAC, while the WTP may terminate all 802.11 frames in the Local=20 > MAC. > An interesting consequence of this difference is that the=20 > Integration > Service, which essentially refers to bridging between 802.11 and > 802.3 frames, is implemented by the AC in the Split MAC, but can be > part of either the AC or WTP in the Local MAC." > The last sentence, as pointed out by Pat, Bob and Inderpreet's=20 > document, was incorrect. According to Figure 9, Integration Service,=20 > for all the parties classified as Local MAC, is implemented by WTP. > Given that we still have about 3 hours remaining in the authors' 48=20 > hour window, I would like to send a note to RFC Editor suggesting the=20 > following sentence to replace the last sentence in the paragraph: > "An interesting consequence of this difference is that the Integration > Service, which essentially refers to bridging between 802.11 and > 802.3 frames, is implemented by the AC in the Split MAC and by the=20 > WTP in the Local MAC, as shown in Figure 9 and Figure 12." >=20 > Glaring as it is, I believe this error does not carry any far reaching > implication to the entire document and hence it is bug we can fix=20 > right now. >=20 > Regarding the comment from the authors that taxonomy draft lacks=20 > conclusion and recommendation and hence the motivation to take it=20 > further to clearly define what Local and Split MAC really mean in=20 > terms of functional split -- I think that is a fair comment --=20 > Personally I was tempted to take that step in the taxonomy draft with=20 > the intention to help the WG moving forward, but as the editor of the=20 > draft, I received clear instruction from the chairs and the WG that a=20 > taxonomy only goes so far to "document" the reality of the market, not > to "define" any architectures. So the draft deliberately didn't go far > into making any specific functional split recommendation. >=20 > As I advocated in both July and Nov IETF meeting last year, I believe=20 > there is indeed a gap between taxonomy draft and objective draft --=20 > the WG needs a clear definition of the functional split for Local,=20 > especially Split MAC, but that is not the charter of either taxonomy=20 > draft or Objective draft. > Some people have the illusion that IEEE 802.11 (specifically the APF=20 > ad hoc group) will provide such definition. The clear answer there is=20 > NO, IEEE would not do that. It is up to us in this group to agree on=20 > the split and move on. So if indeed this Taxonomy Recommendation draft > fulfills this purpose, I personally believe it is a very necessary=20 > step to take in order to move forward. However, as I said, I have not=20 > reviewed the entire document yet and so I would reserve until then to=20 > offer any further comments. >=20 > But I do want to fix the error in Section 5.6 in Taxonomy draft NOW.=20 >=20 > Lily > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Mani, Mahalingam=20 > (Mahalingam) > Sent: Wednesday, June 15, 2005 11:14 AM > To: Pat Calhoun; capwap@frascone.com > Subject: RE: [Capwap] Taxonomy Recommendations >=20 > Thanks for the joint effort (by authors of two candidate protocols for > eval. as I see it) in making a case for clarification of terminology. >=20 > If the changes and clarifications proposed are extensive - comments in > form of I-D is useful to place-hold them. >=20 > The WG should (especially the original taxonomy team authors) comment=20 > on these comments (draft): WG has approved the -06 version of the=20 > taxonomy draft. Two of the authors are in this as well :) >=20 > It is also important to understand the implications, if any, (on=20 > Objectives draft) if WG agrees to any of the proposed clarifications.=20 > It may turn out to be transparent to the Objectives draft. This needs=20 > to happen soon for Objectives to freeze and let the evaluation team=20 > use a baselined version. >=20 > [BTW: the taxonomy draft is in RFC editor's queue - actually just=20 > completed AUTH48]. >=20 > -mani > =3D=3D=3D=3D=3D=3D > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun > Sent: Thursday, June 09, 2005 2:28 PM > To: capwap@frascone.com > Subject: [Capwap] Taxonomy Recommendations >=20 > All, > =20 > I wanted to announce the early availability of the CAPWAP taxonomy=20 > recommendation draft that Bob O'Hara Inderpreet Singh and I have been=20 > working on. It can be found at=20 > http://www.capwap.org/draft-calhoun-capwap-taxonomy-recommenda > tion-00.tx > t. >=20 >=20 > Abstract >=20 > The IETF's CAPWAP working group has documented various product > architectures and has categorized the Centralized WLAN=20 > Architectures > into two main buckets: Split and Local MAC. While the document > contains very relevant and useful information, what it does is list > the architectural variants of these two buckets, but does not > unambiguously define either the Split MAC or Local MAC=20 > architectures. > In order for CAPWAP to be successful, it is crucial for the=20 > protocol > evaluation team, and the working group, to agree on unambiguous > terminology to describe these architectures. >=20 > This document proposes terminology to unambiguously describe the > relevant architectures found in the taxonomy document, for the > purpose of initiating a discussion within the working group and to > allow the protocol evaluation work to come to a fruitful=20 > conclusion. > We conclude in this document that the architectures are very=20 > similar > and could be supported via a single protocol. >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit Cisco Systems >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 > ______________________________________________________________ > __________ > This email has been scanned for computer viruses. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jun 17 12:30:17 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02326 for ; Fri, 17 Jun 2005 12:30:16 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 96652202B7; Fri, 17 Jun 2005 12:30:16 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DAD3D2042F; Fri, 17 Jun 2005 12:30:10 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DAA082042F for ; Fri, 17 Jun 2005 12:29:50 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 6B60A202B7 for ; Fri, 17 Jun 2005 12:29:47 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j5HGPwpS036842; Fri, 17 Jun 2005 09:25:59 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200506171625.j5HGPwpS036842@homebrew.trpz.com> To: "Pat Calhoun" Cc: "'Clint Chaplin'" , mmani@avaya.com, lily.l.yang@intel.com, capwap@frascone.com Subject: Re: [Capwap] Taxonomy Recommendations: encrypt/decrypt In-Reply-To: Your message of "Fri, 17 Jun 2005 05:57:34 PDT." <200506171257.j5HCvb7l025656@sj-core-2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <36840.1119025558.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 17 Jun 2005 09:25:58 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The specific technical reason is a reason not to put encryption/decryption in the AC. And it is a very good reason. As I mentioned, I agree with it. There are very valid technical reasons not to come up with a split MAC architecture in which encryption/decryption is done at the AC. What I don't agree with is that explaining this has any place in a CAPWAP document. As the taxonomy memo shows people have come up with different approaches. I don't necessarily agree with the rationale behind them but reasonable people can disagree and if someone wants to come up with an architecture that is problematic for use with 802.11e then that's their problem. CAPWAP just has to support the different architectures, it doesn't have to lecture people about how what they did is wrong or how a different approach would've been better. They did it that way. CAPWAP just needs to be able to support them. Let me point out again, since I don't think it sank in: this problematic architecture is not mine; you split the MAC the same way we did (and probably for similar reasons). My opposition to this text is that a protocol document is not the place for explaining why one supported architecture is bad as compared to another supported architecture. Dan. On Fri, 17 Jun 2005 05:57:34 PDT you wrote > > The fact that it would be problematic with HCCA is not > > anything that needs to be mentioned in any CAPWAP statement. > > It's useful to bring up during a product design phase when > > deciding where to do bulk data encryption in a particular > > split MAC but such architectures exist and all CAPWAP has to > > do is support it not say why one particular approach is > > better or worse than another. > > > > Note that you split the MAC the same way we did so my > > objection is not defensive or political. I just don't think > > it has any place in CAPWAP. > > I disagree - and for very specific technical reasons. > > This is the one area where splitting the MAC has > significant implications. See my previous e-mail response to > Chris Hinsz, but to summarize, in HCCA the fragmentation must > occur prior to encryption in order to meet the service period > negotiated within HCCA. One cannot centralize the encryption > function (hence fragment) without direct access to the RF in > real-time in order to gain access to interference and co-channel > information. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jun 17 18:30:14 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28320 for ; Fri, 17 Jun 2005 18:30:14 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 555F620372; Fri, 17 Jun 2005 18:30:14 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 81BFF1FE1E; Fri, 17 Jun 2005 18:30:09 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EDB2A20261 for ; Fri, 17 Jun 2005 18:29:32 -0400 (EDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.frascone.com (Postfix) with ESMTP id F3D7B1FE1E for ; Fri, 17 Jun 2005 18:29:29 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 17 Jun 2005 15:29:29 -0700 X-IronPort-AV: i="3.93,209,1115017200"; d="scan'208,217"; a="644401396:sNHT39877288" Received: from pacalhouwxp ([10.32.30.113]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5HMTPqi002921; Fri, 17 Jun 2005 15:29:26 -0700 (PDT) Message-Id: <200506172229.j5HMTPqi002921@sj-core-5.cisco.com> From: "Pat Calhoun" To: "'Michael Montemurro'" , "'Darren Loher'" , "'Inderpreet Singh'" , "'Sadot, Emek (Emek)'" , Subject: RE: [Capwap] Support for Traffic Separation MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0892_01C57351.58F93740" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVzeRm96Aiw9vLARFSvNXDVUs+7YAAErXNA In-Reply-To: <1652EBA28502ED4393B9BC9B8A4B6013164531@mism121a.toronto.chantrynetworks.com> X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.30.113] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 17 Jun 2005 15:29:21 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------=_NextPart_000_0892_01C57351.58F93740 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Michael, > I don't believe Option 4 requires significant protocol development effort over Option 2 and Option 3. There are > definitely architectures in the taxonomy which conform to this architecture and they should be addressed in the protocol > definition. Correct, the work is probably not insurmountable. The question comes down to whether the WG feels like it wants to put in the effort and have a protocol with the added complexity. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ------=_NextPart_000_0892_01C57351.58F93740 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Michael,
 
> I don't believe Option = 4=20 requires significant protocol development effort over Option 2 and = Option 3.=20 There are
> definitely = architectures in the=20 taxonomy which conform to this architecture and they should be addressed = in the=20 protocol
> definition.
Correct, the work is probably not = insurmountable. The=20 question comes down to whether the WG feels like it wants to put in the = effort=20 and have a protocol with the added complexity.
 

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

------=_NextPart_000_0892_01C57351.58F93740-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jun 17 18:40:14 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29050 for ; Fri, 17 Jun 2005 18:40:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7F3032027F; Fri, 17 Jun 2005 18:40:14 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 383BF20261; Fri, 17 Jun 2005 18:40:10 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9A83620261 for ; Fri, 17 Jun 2005 18:39:04 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 692471FE1E for ; Fri, 17 Jun 2005 18:39:01 -0400 (EDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 17 Jun 2005 15:39:01 -0700 X-IronPort-AV: i="3.93,209,1115017200"; d="scan'208"; a="280204299:sNHT30269680" Received: from pacalhouwxp ([10.32.30.113]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5HMcwFq013076; Fri, 17 Jun 2005 15:38:58 -0700 (PDT) Message-Id: <200506172238.j5HMcwFq013076@sj-core-1.cisco.com> From: "Pat Calhoun" To: "'Dan Harkins'" Cc: "'Clint Chaplin'" , , , Subject: RE: [Capwap] Taxonomy Recommendations: encrypt/decrypt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVzWhXOcjK+Y79mTKKkow0sGZu6PwAMfkEQ In-Reply-To: <200506171625.j5HGPwpS036842@homebrew.trpz.com> X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.30.113] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 17 Jun 2005 15:38:53 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I agree with you Dan, except that if we agree to allow a specific permutation of an architecture which breaks interoperability with an 802.11 feature, then it is our responsibility to make sure it isn't brushed under the rug. In the end, the market will decide. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Dan Harkins > Sent: Friday, June 17, 2005 9:26 AM > To: Pat Calhoun > Cc: 'Clint Chaplin'; mmani@avaya.com; lily.l.yang@intel.com; > capwap@frascone.com > Subject: Re: [Capwap] Taxonomy Recommendations: encrypt/decrypt > > The specific technical reason is a reason not to put > encryption/decryption in the AC. And it is a very good reason. > As I mentioned, I agree with it. There are very valid > technical reasons not to come up with a split MAC > architecture in which encryption/decryption is done at the > AC. What I don't agree with is that explaining this has any > place in a CAPWAP document. > > As the taxonomy memo shows people have come up with > different approaches. I don't necessarily agree with the > rationale behind them but reasonable people can disagree and > if someone wants to come up with an architecture that is > problematic for use with 802.11e then that's their problem. > > CAPWAP just has to support the different architectures, it > doesn't have to lecture people about how what they did is > wrong or how a different approach would've been better. They > did it that way. CAPWAP just needs to be able to support them. > > Let me point out again, since I don't think it sank in: > this problematic architecture is not mine; you split the MAC > the same way we did (and probably for similar reasons). My > opposition to this text is that a protocol document is not > the place for explaining why one supported architecture is > bad as compared to another supported architecture. > > Dan. > > On Fri, 17 Jun 2005 05:57:34 PDT you wrote > > > The fact that it would be problematic with HCCA is not anything > > > that needs to be mentioned in any CAPWAP statement. > > > It's useful to bring up during a product design phase > when deciding > > > where to do bulk data encryption in a particular split > MAC but such > > > architectures exist and all CAPWAP has to do is support > it not say > > > why one particular approach is better or worse than another. > > > > > > Note that you split the MAC the same way we did so my > objection is > > > not defensive or political. I just don't think it has any > place in > > > CAPWAP. > > > > I disagree - and for very specific technical reasons. > > > > This is the one area where splitting the MAC has significant > > implications. See my previous e-mail response to Chris > Hinsz, but to > > summarize, in HCCA the fragmentation must occur prior to > encryption in > > order to meet the service period negotiated within HCCA. One cannot > > centralize the encryption function (hence fragment) without direct > > access to the RF in real-time in order to gain access to > interference > > and co-channel information. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sat Jun 18 10:31:14 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16288 for ; Sat, 18 Jun 2005 10:31:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0538120266; Sat, 18 Jun 2005 10:31:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1FB2C1FDE9; Sat, 18 Jun 2005 10:31:10 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EF3DD1FDE9 for ; Sat, 18 Jun 2005 10:30:49 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id 290BB1FD61 for ; Sat, 18 Jun 2005 10:30:47 -0400 (EDT) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5IESBdd018926 for ; Sat, 18 Jun 2005 10:28:11 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5IESAdd018917 for ; Sat, 18 Jun 2005 10:28:10 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Taxonomy Recommendations: encrypt/decrypt Message-ID: <5844A41F4E146044A2E8356C6328588008DFDFA4@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] Taxonomy Recommendations: encrypt/decrypt Thread-Index: AcVzWhXOcjK+Y79mTKKkow0sGZu6PwAMfkEQACFBdDA= From: "Sadot, Emek (Emek)" To: "Pat Calhoun" , "Dan Harkins" Cc: "Clint Chaplin" , "Mani, Mahalingam (Mahalingam)" , , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Sat, 18 Jun 2005 10:30:37 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Pat, If you agree with Dan's point then please educate the group how it differs from allowing bridging function to run at the WTP in Split Mac arch. Philosophically they are the same, practically there are two notable distinction in favor of bridging: a) bridging in WTP doesn't break interoperability with an 802.11 feature and b) offers merits to the customer. Regards, Emek -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun Sent: Saturday, June 18, 2005 1:39 AM To: 'Dan Harkins' Cc: 'Clint Chaplin'; Mani, Mahalingam (Mahalingam); lily.l.yang@intel.com; capwap@frascone.com Subject: RE: [Capwap] Taxonomy Recommendations: encrypt/decrypt=20 I agree with you Dan, except that if we agree to allow a specific permutation of an architecture which breaks interoperability with an 802.11 feature, then it is our responsibility to make sure it isn't brushed under the rug. In the end, the market will decide. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Dan Harkins > Sent: Friday, June 17, 2005 9:26 AM > To: Pat Calhoun > Cc: 'Clint Chaplin'; mmani@avaya.com; lily.l.yang@intel.com;=20 > capwap@frascone.com > Subject: Re: [Capwap] Taxonomy Recommendations: encrypt/decrypt >=20 > The specific technical reason is a reason not to put=20 > encryption/decryption in the AC. And it is a very good reason. > As I mentioned, I agree with it. There are very valid technical=20 > reasons not to come up with a split MAC architecture in which=20 > encryption/decryption is done at the AC. What I don't agree with is=20 > that explaining this has any place in a CAPWAP document. >=20 > As the taxonomy memo shows people have come up with different=20 > approaches. I don't necessarily agree with the rationale behind them=20 > but reasonable people can disagree and if someone wants to come up=20 > with an architecture that is problematic for use with 802.11e then=20 > that's their problem. >=20 > CAPWAP just has to support the different architectures, it doesn't=20 > have to lecture people about how what they did is wrong or how a=20 > different approach would've been better. They did it that way. CAPWAP=20 > just needs to be able to support them. >=20 > Let me point out again, since I don't think it sank in: > this problematic architecture is not mine; you split the MAC the same=20 > way we did (and probably for similar reasons). My opposition to this=20 > text is that a protocol document is not the place for explaining why=20 > one supported architecture is bad as compared to another supported=20 > architecture. >=20 > Dan. >=20 > On Fri, 17 Jun 2005 05:57:34 PDT you wrote > > > The fact that it would be problematic with HCCA is not anything=20 > > > that needs to be mentioned in any CAPWAP statement. > > > It's useful to bring up during a product design phase > when deciding > > > where to do bulk data encryption in a particular split > MAC but such > > > architectures exist and all CAPWAP has to do is support > it not say > > > why one particular approach is better or worse than another. > > >=20 > > > Note that you split the MAC the same way we did so my > objection is > > > not defensive or political. I just don't think it has any > place in > > > CAPWAP. > >=20 > > I disagree - and for very specific technical reasons. > >=20 > > This is the one area where splitting the MAC has significant=20 > > implications. See my previous e-mail response to Chris > Hinsz, but to > > summarize, in HCCA the fragmentation must occur prior to > encryption in > > order to meet the service period negotiated within HCCA. One cannot=20 > > centralize the encryption function (hence fragment) without direct=20 > > access to the RF in real-time in order to gain access to > interference > > and co-channel information. > >=20 > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems=20 > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sat Jun 18 15:14:14 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06229 for ; Sat, 18 Jun 2005 15:14:14 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 22D3720445; Sat, 18 Jun 2005 15:14:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8B330202C4; Sat, 18 Jun 2005 15:14:08 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0FDF2202C4 for ; Sat, 18 Jun 2005 15:13:01 -0400 (EDT) Received: from aruba-mx.arubanetworks.com (mail.arubanetworks.com [216.31.249.253]) by mail.frascone.com (Postfix) with SMTP id D33D02027F for ; Sat, 18 Jun 2005 15:12:59 -0400 (EDT) Received: from aruba-server.arubanetworks.com ([10.1.1.40] RDNS failed) by aruba-mx.arubanetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Jun 2005 12:12:41 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Taxonomy Recommendations: encrypt/decrypt X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Message-ID: Thread-Topic: [Capwap] Taxonomy Recommendations: encrypt/decrypt Thread-Index: AcVzWhXOcjK+Y79mTKKkow0sGZu6PwAMfkEQACrwtdA= From: "Randy Chou" To: "Pat Calhoun" Cc: "Clint Chaplin" , "Avaya - Mani Mahalingam" , , , "Dan Harkins" , "Randy Chou" X-OriginalArrivalTime: 18 Jun 2005 19:12:41.0790 (UTC) FILETIME=[B32C25E0:01C57439] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Sat, 18 Jun 2005 12:12:58 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I'm glad you agreed. Just because a vendor can't figure out how another may solve a perceived problem doesn't mean it can't be done nor is it relevant to Capwap. Another example would be the amount of key distribution and key management required by each architecture. Virtually every cryptography expert will tell you the security advantages of minimizing key distribution and shear complexity of managing keys. Encrypting at the AC versus at the WTP clearly minizes key distribution and hence is much more secure. Are we going to spell that out in the security considerations section then? Let the market decide. Regards, -- Randy -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun Sent: Friday, June 17, 2005 3:39 PM To: 'Dan Harkins' Cc: 'Clint Chaplin'; Avaya - Mani Mahalingam; lily.l.yang@intel.com; capwap@frascone.com Subject: RE: [Capwap] Taxonomy Recommendations: encrypt/decrypt=20 I agree with you Dan, except that if we agree to allow a specific permutation of an architecture which breaks interoperability with an 802.11 feature, then it is our responsibility to make sure it isn't brushed under the rug. In the end, the market will decide. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Dan Harkins > Sent: Friday, June 17, 2005 9:26 AM > To: Pat Calhoun > Cc: 'Clint Chaplin'; mmani@avaya.com; lily.l.yang@intel.com;=20 > capwap@frascone.com > Subject: Re: [Capwap] Taxonomy Recommendations: encrypt/decrypt=20 >=20 > The specific technical reason is a reason not to put > encryption/decryption in the AC. And it is a very good reason. > As I mentioned, I agree with it. There are very valid=20 > technical reasons not to come up with a split MAC=20 > architecture in which encryption/decryption is done at the=20 > AC. What I don't agree with is that explaining this has any=20 > place in a CAPWAP document.=20 >=20 > As the taxonomy memo shows people have come up with > different approaches. I don't necessarily agree with the=20 > rationale behind them but reasonable people can disagree and=20 > if someone wants to come up with an architecture that is=20 > problematic for use with 802.11e then that's their problem. >=20 > CAPWAP just has to support the different architectures, it > doesn't have to lecture people about how what they did is=20 > wrong or how a different approach would've been better. They=20 > did it that way. CAPWAP just needs to be able to support them. >=20 > Let me point out again, since I don't think it sank in: this=20 > problematic architecture is not mine; you split the MAC the same way=20 > we did (and probably for similar reasons). My opposition to this text=20 > is that a protocol document is not the place for explaining why one=20 > supported architecture is bad as compared to another supported=20 > architecture. >=20 > Dan. >=20 > On Fri, 17 Jun 2005 05:57:34 PDT you wrote > > > The fact that it would be problematic with HCCA is not anything > > > that needs to be mentioned in any CAPWAP statement. > > > It's useful to bring up during a product design phase=20 > when deciding > > > where to do bulk data encryption in a particular split > MAC but such > > > architectures exist and all CAPWAP has to do is support > it not say > > > why one particular approach is better or worse than another. > > >=20 > > > Note that you split the MAC the same way we did so my > objection is > > > not defensive or political. I just don't think it has any > place in > > > CAPWAP. > >=20 > > I disagree - and for very specific technical reasons. > >=20 > > This is the one area where splitting the MAC has significant > > implications. See my previous e-mail response to Chris=20 > Hinsz, but to > > summarize, in HCCA the fragmentation must occur prior to > encryption in > > order to meet the service period negotiated within HCCA. One cannot > > centralize the encryption function (hence fragment) without direct=20 > > access to the RF in real-time in order to gain access to=20 > interference > > and co-channel information. > >=20 > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ > Capwap mailing list > Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From shags@didamail.com Sat Jun 18 18:26:46 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20178; Sat, 18 Jun 2005 18:26:46 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Djm9O-0003rx-0j; Sat, 18 Jun 2005 18:51:00 -0400 Received: from [222.89.168.247] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1Djllr-0000O5-8J; Sat, 18 Jun 2005 18:26:38 -0400 Received: from braun-mcmn.prpy.net (HELO honda-ddad.net) by foregoing-ext.mfspe.net (8.9.0) with ESMTP id MKS12dsmx; Sat, 18 Jun 2005 19:22:46 -0400 Date: Sat, 18 Jun 2005 21:29:46 -0200 From: "Simone Sinclair" Message-ID: <101.92e558d5.2a9SGS44@rjv.com> To: bofchairs@ietf.org Cc: bounces-ietf@ietf.org, bpana@ietf.org, brenton.daniels@ietf.org, bridge-mib@ietf.org, bridge-mib-admin@ietf.org, business@ietf.org, calsch@ietf.org, cancer@ietf.org, capwap-archive@ietf.org, ccips@ietf.org, cclark@ietf.org, cdi-archive@ietf.org Subject: Rates just dropped X-Mailer: KMail [version 1.0.28] X-Spam-Score: 7.7 (+++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have been selected for our lowest rate in years... You could get over $420,000 for as little as $400 a month! Ba(d credit, Bank*ruptcy? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.mtg1-23.com/signs.asp Best Regards, Eugenio Sanderson to be remov(ed: http://www.mtg1-23.com/deletion.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From navsses@yebox.com Sun Jun 19 07:03:29 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26200; Sun, 19 Jun 2005 07:03:28 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Djxxr-0001sl-VL; Sun, 19 Jun 2005 07:27:49 -0400 Received: from nkno119041.catv.ppp.infoweb.ne.jp ([218.226.247.41]) by mx2.foretec.com with smtp (Exim 4.24) id 1Djxa7-0008V2-TT; Sun, 19 Jun 2005 07:03:29 -0400 Received: from annapolis-aybm.prke.net (HELO ghana-kkkq.net) by bar-ext.jvbal.net (8.9.0) with ESMTP id FRU12yogn; Sun, 19 Jun 2005 13:59:17 +0200 Date: Sun, 19 Jun 2005 06:57:17 -0500 From: "Angelina Lassiter" Message-ID: <111.11e558d5.2a9QWI44@nkk.com> To: bofchairs@ietf.org Cc: bounces-ietf@ietf.org, bpana@ietf.org, brenton.daniels@ietf.org, bridge-mib@ietf.org, bridge-mib-admin@ietf.org, business@ietf.org, calsch@ietf.org, cancer@ietf.org, capwap-archive@ietf.org, ccips@ietf.org, cclark@ietf.org Subject: Notification: We offer low rates X-Mailer: KMail [version 1.0.28] X-Spam-Score: 3.5 (+++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have been selected for our lowest rate in years... You could get over $420,000 for as little as $400 a month! Ba(d credit, Bank*ruptcy? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.mtg1-23.com/signs.asp Best Regards, Antony Lee to be remov(ed: http://www.mtg1-23.com/deletion.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From aitao@doramail.com Sun Jun 19 10:58:50 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11328; Sun, 19 Jun 2005 10:58:50 -0400 (EDT) From: aitao@doramail.com Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dk1de-0006Z1-L9; Sun, 19 Jun 2005 11:23:11 -0400 Received: from [211.161.225.186] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1Dk1G5-0004ci-31; Sun, 19 Jun 2005 10:58:50 -0400 Received: from SILJYpevt.com (EHLO arldt-a.ampere.GX.udu.net) two by mail.mtk.nao.ac.jp (7.8[2 Message-Id: Date: Sun, 19 Jun 2005 10:58:50 -0400 X-Spam-Score: 5.1 (+++++) X-Spam-Flag: YES X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From mazes@emailaccount.com Sun Jun 19 13:14:21 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20299; Sun, 19 Jun 2005 13:14:21 -0400 (EDT) Date: Sun, 19 Jun 2005 13:14:21 -0400 (EDT) From: mazes@emailaccount.com Message-Id: <200506191714.NAA20299@ietf.org> Received: from [220.127.249.212] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dk3kp-0000wz-El; Sun, 19 Jun 2005 13:38:45 -0400 Received: from RKQAYrvjz.com (EHLO aqmgb-a.jolt.YJ.aly.net) heroic by mail.mtk.nao.ac.jp (0.7[2 X-Spam-Score: 7.3 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From anguses@doramail.com Sun Jun 19 16:14:58 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03448; Sun, 19 Jun 2005 16:14:58 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dk6Zd-0005Cm-Dv; Sun, 19 Jun 2005 16:39:22 -0400 Received: from pro75-3-82-234-175-18.fbx.proxad.net ([82.234.175.18]) by mx2.foretec.com with smtp (Exim 4.24) id 1Dk6C1-0002MA-Q0; Sun, 19 Jun 2005 16:14:58 -0400 Received: from grandfather.obqlid.pig.bloc.com by o.dynamo.cottony.com (xghupfix) with SMTP id 0B29E820408 for ; Mon, 20 Jun 2005 01:17:18 +0400 Message-ID: Date: Sun, 19 Jun 2005 16:15:18 -0500 From: "Allyson Calloway" To: Subject: Save hundreds every month on low rates X-Mailer: KYX CP/M FNORD 5602 X-Spam-Score: 5.7 (+++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have been selected for our lowest rate in years... You could get over $420,000 for as little as $400 a month! Ba(d credit, Bank*ruptcy? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.mtg1-23.com/signs.asp Best Regards, Fredrick Bowers to be remov(ed: http://www.mtg1-23.com/deletion.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From capwap-admin@frascone.com Sun Jun 19 21:28:13 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21431 for ; Sun, 19 Jun 2005 21:28:12 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E39992044F; Sun, 19 Jun 2005 21:28:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4FFA820427; Sun, 19 Jun 2005 21:28:09 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D473520427 for ; Sun, 19 Jun 2005 21:27:10 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id E6C6A203E7 for ; Sun, 19 Jun 2005 21:27:08 -0400 (EDT) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5K1Oddd019821 for ; Sun, 19 Jun 2005 21:24:39 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5K1OGdd019035 for ; Sun, 19 Jun 2005 21:24:23 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57537.1DC35792" Message-ID: Thread-Topic: Objectives Draft revision -03 available. Thread-Index: AcV1Nx1UZarZrs1XQ5qS+qUUxof8uw== X-Priority: 1 Priority: Urgent Importance: high From: "Mani, Mahalingam (Mahalingam)" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Objectives Draft revision -03 available. Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Sun, 19 Jun 2005 19:26:43 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C57537.1DC35792 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All: =20 Saravanan Govindan has submitted the next revision of Objectives draft to the repository (which is due to show up soon). This is draft-ietf-capwap-objectives-03. =20 Until then you may refer to this at the following website: http://www.capwap.org/draft-ietf-capwap-objectives-03.txt =20 This revision is intended to serve as the baseline revision for the protocol evaluation. =20 [Thanks to Dave Frascone for updating the site at very short notice]. =20 Regards, -mani =3D=3D=3D=3D=3D=3D =20 ------_=_NextPart_001_01C57537.1DC35792 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All:

 

Saravanan Govindan has submitted the next revision of Objectives draft to the repository (which is due to show up = soon).

This is = draft-ietf-capwap-objectives-03.

 

Until then you may refer to this at the following = website:

http:/= /www.capwap.org/draft-ietf-capwap-objectives-03.txt=

 

This revision is intended to serve as the baseline = revision for the protocol evaluation.

 

[Thanks to Dave Frascone for updating the site at = very short notice].

 

Regards,

-mani

=3D=3D=3D=3D=3D=3D

 

------_=_NextPart_001_01C57537.1DC35792-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Jun 20 13:21:14 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20403 for ; Mon, 20 Jun 2005 13:21:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 056742046E; Mon, 20 Jun 2005 13:21:13 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A51422038E; Mon, 20 Jun 2005 13:21:10 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 97B3B2038E for ; Mon, 20 Jun 2005 13:20:42 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id A10CC1FC7B for ; Mon, 20 Jun 2005 13:20:39 -0400 (EDT) Message-ID: <017901c575bc$8e8e9ea0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Sadot, Emek (Emek)" , "Pat Calhoun" , References: <5844A41F4E146044A2E8356C6328588008D913A9@nj7460avexu2.global.avaya.com> Subject: Re: [Capwap] Taxonomy Recommendations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 20 Jun 2005 10:21:50 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Emek, Take for example the IS service: where it fits in Slit and Local - WTP or AC? I would disagree the authors conclusion (section 5 first bullet) w.r.t. bridging function, and believes we can, and should, allow the operator to chose. jak>> OK, so what criteria would cause an operator to choose bridging at the WTP versus bridging at the AC? jak _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Jun 20 13:45:22 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22518 for ; Mon, 20 Jun 2005 13:45:18 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B390120475; Mon, 20 Jun 2005 13:45:13 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F11D72038E; Mon, 20 Jun 2005 13:45:09 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D9AC82038E for ; Mon, 20 Jun 2005 13:44:57 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 8B43F1FC7B for ; Mon, 20 Jun 2005 13:44:54 -0400 (EDT) Message-ID: <019101c575bf$f223e850$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Mani, Mahalingam (Mahalingam)" , "Yang, Lily L" , "Pat Calhoun" Cc: References: Subject: Re: [Capwap] Taxonomy Recommendations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 20 Jun 2005 10:46:06 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Mani, I think the basic problem here is that the taxonomy draft discusses functional architecture and existing network reference architectures but even though the network reference architectures in the different existing products are different and in some cased conflicting, the taxonomy draft doesn't really point out where there is a conflict because, as Lily said, that wasn't a goal of the draft. The grouping of functional entities into network entities (i.e. boxes) in the network reference architecture is what defines which interfaces between functional entities are instantiated as protocols and which are instantiated as APIs within a box. If CAPWAP is ever to develop a standardized, interoperable protocol, there must be a clear and precise understanding and agreement on where these interfaces are. Pat and Inderpreet's draft discuss a couple of issues around this but doesn't really get to the heart of the problem. For example, taking the issue of where the distribution function lies, if the distribution function is placed in the WTP, then bridging is an API within the WTP box. If the distribution function is placed in the AC, then there is need for a protocol across the WTP/AC interface to tunnel 802.11 data frames to the AC. Part of the problem is that the taxonomy draft renamed the AP without changing really what it is. Both the AP and WTP are network entities and not functional entities. The other, major part of the problem, as you outline below, is that the IEEE has refused to commit to a network reference architecture. They have only committed to a functional architecture. Exactly what the interfaces are between network entities and therefore where standardized protocols are required is therefore not specified. Different vendors have taken their own cut at this, so there are now multiple network reference architectural variants in the market. Not suprisingly, vendors are not going to agree to a particular network reference architecture if it means that their products will have protocol-requiring interfaces on the wrong side of the split. So, I think it will be very hard to achieve concensus on this, though I think it might help to start with defining what network reference architectural variants lead to what protocol interfaces. I think Pat and Inderpreet's draft does make a good start at the latter, though not in as formal a way as I've seen in past architectural studies. jak ----- Original Message ----- From: "Mani, Mahalingam (Mahalingam)" To: "Yang, Lily L" ; "Pat Calhoun" Cc: Sent: Thursday, June 16, 2005 7:13 AM Subject: RE: [Capwap] Taxonomy Recommendations I have no objections to this 'bug-fix' if it can happen in time and has no author/WG objections. We can request the RFC Ed. to hold off. As for the other issue on split-MAC interpretation: The split-discussion is long overdue; and is worth having - to help evaluation as well. I think resolution of the discussion is important to arrive at the best approach to CAPWAP protocol accommodating/not split variants. History: We had clearly noted not to make any recommendations on what a split characteristic must be in the taxonomy. This has perhaps been argued many times in (taxonomy) design team and in IETF58-62 as well. There was no scope for us in the then charter to venture that way. When APF AHC initially started its work - the hope was it would offer enough information for CAPWAP to draw conclusions for future work; there were no expectations on what they would recommend the split ought to be once they were chartered (there were hopes much prior to that). Inasmuch as IEEE 802.11 endorsed and acknowledged the documented splits caused no standards departure/breakage in implementation or behavior - by its review of the taxonomy draft - we had validated all architectures from IEEE 802.11 perspective. It was clear when APF AHC group was formed that it will transpire to provide only clarifying interpretations of functions - not delineate or standardize splits. -mani ====== -----Original Message----- From: Yang, Lily L [mailto:lily.l.yang@intel.com] Sent: Wednesday, June 15, 2005 1:19 PM To: Mani, Mahalingam (Mahalingam); Pat Calhoun Cc: capwap@frascone.com Subject: RE: [Capwap] Taxonomy Recommendations Hi, Pat and Mani -- I have not read through the entire Taxonomy Recommendations document yet, but just reading through the first few pages, I believe the authors are correct in pointing out one of the "inconsistency" (error) in the taxonomy draft. There was a paragraph in the taxonomy draft Section 5.6: " The commonalities and differences between Local MAC and Split MAC are most clearly seen by comparing Figure 7 to Figure 10. The commonality is that 802.11 control frames are terminated at WTPs in both cases. The main difference between Local MAC and Split MAC is that the WTP terminates only the 802.11 control frames in the Split MAC, while the WTP may terminate all 802.11 frames in the Local MAC. An interesting consequence of this difference is that the Integration Service, which essentially refers to bridging between 802.11 and 802.3 frames, is implemented by the AC in the Split MAC, but can be part of either the AC or WTP in the Local MAC." The last sentence, as pointed out by Pat, Bob and Inderpreet's document, was incorrect. According to Figure 9, Integration Service, for all the parties classified as Local MAC, is implemented by WTP. Given that we still have about 3 hours remaining in the authors' 48 hour window, I would like to send a note to RFC Editor suggesting the following sentence to replace the last sentence in the paragraph: "An interesting consequence of this difference is that the Integration Service, which essentially refers to bridging between 802.11 and 802.3 frames, is implemented by the AC in the Split MAC and by the WTP in the Local MAC, as shown in Figure 9 and Figure 12." Glaring as it is, I believe this error does not carry any far reaching implication to the entire document and hence it is bug we can fix right now. Regarding the comment from the authors that taxonomy draft lacks conclusion and recommendation and hence the motivation to take it further to clearly define what Local and Split MAC really mean in terms of functional split -- I think that is a fair comment -- Personally I was tempted to take that step in the taxonomy draft with the intention to help the WG moving forward, but as the editor of the draft, I received clear instruction from the chairs and the WG that a taxonomy only goes so far to "document" the reality of the market, not to "define" any architectures. So the draft deliberately didn't go far into making any specific functional split recommendation. As I advocated in both July and Nov IETF meeting last year, I believe there is indeed a gap between taxonomy draft and objective draft -- the WG needs a clear definition of the functional split for Local, especially Split MAC, but that is not the charter of either taxonomy draft or Objective draft. Some people have the illusion that IEEE 802.11 (specifically the APF ad hoc group) will provide such definition. The clear answer there is NO, IEEE would not do that. It is up to us in this group to agree on the split and move on. So if indeed this Taxonomy Recommendation draft fulfills this purpose, I personally believe it is a very necessary step to take in order to move forward. However, as I said, I have not reviewed the entire document yet and so I would reserve until then to offer any further comments. But I do want to fix the error in Section 5.6 in Taxonomy draft NOW. Lily -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Mani, Mahalingam (Mahalingam) Sent: Wednesday, June 15, 2005 11:14 AM To: Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Taxonomy Recommendations Thanks for the joint effort (by authors of two candidate protocols for eval. as I see it) in making a case for clarification of terminology. If the changes and clarifications proposed are extensive - comments in form of I-D is useful to place-hold them. The WG should (especially the original taxonomy team authors) comment on these comments (draft): WG has approved the -06 version of the taxonomy draft. Two of the authors are in this as well :) It is also important to understand the implications, if any, (on Objectives draft) if WG agrees to any of the proposed clarifications. It may turn out to be transparent to the Objectives draft. This needs to happen soon for Objectives to freeze and let the evaluation team use a baselined version. [BTW: the taxonomy draft is in RFC editor's queue - actually just completed AUTH48]. -mani ====== -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun Sent: Thursday, June 09, 2005 2:28 PM To: capwap@frascone.com Subject: [Capwap] Taxonomy Recommendations All, I wanted to announce the early availability of the CAPWAP taxonomy recommendation draft that Bob O'Hara Inderpreet Singh and I have been working on. It can be found at http://www.capwap.org/draft-calhoun-capwap-taxonomy-recommendation-00.tx t. Abstract The IETF's CAPWAP working group has documented various product architectures and has categorized the Centralized WLAN Architectures into two main buckets: Split and Local MAC. While the document contains very relevant and useful information, what it does is list the architectural variants of these two buckets, but does not unambiguously define either the Split MAC or Local MAC architectures. In order for CAPWAP to be successful, it is crucial for the protocol evaluation team, and the working group, to agree on unambiguous terminology to describe these architectures. This document proposes terminology to unambiguously describe the relevant architectures found in the taxonomy document, for the purpose of initiating a discussion within the working group and to allow the protocol evaluation work to come to a fruitful conclusion. We conclude in this document that the architectures are very similar and could be supported via a single protocol. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Jun 20 15:51:20 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03055 for ; Mon, 20 Jun 2005 15:51:18 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C8661202DB; Mon, 20 Jun 2005 15:51:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 967EE20278; Mon, 20 Jun 2005 15:51:09 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9438E20278 for ; Mon, 20 Jun 2005 15:50:16 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id B825F1FE0F for ; Mon, 20 Jun 2005 15:50:14 -0400 (EDT) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5KJlidd021930 for ; Mon, 20 Jun 2005 15:47:44 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5KJjsdd019461 for ; Mon, 20 Jun 2005 15:46:42 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Taxonomy Recommendations Message-ID: Thread-Topic: [Capwap] Taxonomy Recommendations Thread-Index: AcV1v8m9Rv16qrLzSLyyhjode34l/gACKjYg From: "Mani, Mahalingam (Mahalingam)" To: "James Kempf" Cc: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 20 Jun 2005 13:48:22 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Jim, I can't agree more on the first paragraph. That is actually at the heart of standardization challenge for CAPWAP protocol. More inline... -mani =3D=3D=3D=3D=3D=3D -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com]=20 Sent: Monday, June 20, 2005 10:46 AM To: Mani, Mahalingam (Mahalingam); Yang, Lily L; Pat Calhoun Cc: capwap@frascone.com Subject: Re: [Capwap] Taxonomy Recommendations Mani, I think the basic problem here is that the taxonomy draft discusses functional architecture and existing network reference architectures but even though the network reference architectures in the different existing products are different and in some cased conflicting, the taxonomy draft doesn't really point out where there is a conflict because, as Lily said, that wasn't a goal of the draft. The grouping of functional entities into network entities (i.e. boxes) in the network reference architecture is what defines which interfaces between functional entities are instantiated as protocols and which are instantiated as APIs within a box. If CAPWAP is ever to develop a standardized, interoperable protocol, there must be a clear and precise understanding and agreement on where these interfaces are. Pat and Inderpreet's draft discuss a couple of issues around this but doesn't really get to the heart of the problem. For example, taking the issue of where the distribution function lies, if the distribution function is placed in the WTP, then bridging is an API within the WTP box. If the distribution function is placed in the AC, then there is need for a protocol across the WTP/AC interface to tunnel 802.11 data frames to the AC. Part of the problem is that the taxonomy draft renamed the AP without [Mani, Mahalingam (Mahalingam)]=20 [Mani, Mahalingam (Mahalingam)] I agree it did do a name-change to distinguish the in split & local manifestations; the primary point - as I had stated earlier - and is now the active discussion; is with split & local AP itself (leave alone split-MAC); I disagree that was the only outcome - the draft went on to characterize WTP in these manifestations. Sure - enough within the scope of the taxonomy; not asserting to nail down one split behavior. changing really what it is. Both the AP and WTP are network entities and not functional entities. The other, major part of the problem, as you outline below, is that the IEEE has refused to commit to a network reference architecture. They have only committed to a functional architecture. Exactly what the interfaces are between network entities and therefore where standardized protocols are required is therefore not specified. Different vendors have taken their own cut at this, so there are now multiple network reference architectural variants in the market. Not suprisingly, vendors are not going to agree to a [Mani, Mahalingam (Mahalingam)]=20 [Mani, Mahalingam (Mahalingam)] either they disagree or agree on a way to get over this - protocol-wise or otherwise. If it is the former - we all have been burying our heads in the sand - knowing well this is coming anyway. [Mani] It is again going back to the recharter-phase discussions late last year (of separating and defining cleanly the control aspects - which is what should constitute the CAPWAP - while specifying how control impacts the dataplane and where it should be controlled/terminated) without specifying how the dataplane itself (tunneled/forwarded/terminated paths etc.). [mani] While it does not solve all the issues right away it paves way for a better perspective of what RFC3990 wants addressed; and allows for a better chance to articulate a protocol that solves the customer pains (of managing & controlling small & large deployments securely). [Mani] The AC, viewed as logically separate entity from the WLAN-switch/controller-box, can set the stage for architectural description of how and where to control the WTP and wherever the DS (dist. Services)-exit is. particular network reference architecture if it means that their products will have protocol-requiring interfaces on the wrong side of the split. So, [Mani, Mahalingam (Mahalingam)] it may be - we already made a start in taxonomy by at least allowing for two variants to exist and agreeing on WG recharter out of conviction to make this level of flexibility realizable in the protocol. I think it will be very hard to achieve concensus on this, though I think it might help to start with defining what network reference architectural variants lead to what protocol interfaces. I think Pat and Inderpreet's draft does make a good start at the latter, though not in as formal a way as I've seen in past architectural studies. [Mani, Mahalingam (Mahalingam)]=20 [Mani, Mahalingam (Mahalingam)] fortunately we made forward progress as WG - albeit doing mere taxonomy work (Bob at that time rightly mentioned we are documenting - or some such equivalent - not doing architecture). Unfortunately it was at the expense of having to sacrifice architectural analysis (which is what we did during the 2nd & 3rd BoFs) - which may be resurrecting now. jak ----- Original Message -----=20 From: "Mani, Mahalingam (Mahalingam)" To: "Yang, Lily L" ; "Pat Calhoun" Cc: Sent: Thursday, June 16, 2005 7:13 AM Subject: RE: [Capwap] Taxonomy Recommendations I have no objections to this 'bug-fix' if it can happen in time and has no author/WG objections. We can request the RFC Ed. to hold off. As for the other issue on split-MAC interpretation: The split-discussion is long overdue; and is worth having - to help evaluation as well. I think resolution of the discussion is important to arrive at the best approach to CAPWAP protocol accommodating/not split variants. History: We had clearly noted not to make any recommendations on what a split characteristic must be in the taxonomy. This has perhaps been argued many times in (taxonomy) design team and in IETF58-62 as well. There was no scope for us in the then charter to venture that way. When APF AHC initially started its work - the hope was it would offer enough information for CAPWAP to draw conclusions for future work; there were no expectations on what they would recommend the split ought to be once they were chartered (there were hopes much prior to that). Inasmuch as IEEE 802.11 endorsed and acknowledged the documented splits caused no standards departure/breakage in implementation or behavior - by its review of the taxonomy draft - we had validated all architectures from IEEE 802.11 perspective. It was clear when APF AHC group was formed that it will transpire to provide only clarifying interpretations of functions - not delineate or standardize splits. -mani =3D=3D=3D=3D=3D=3D -----Original Message----- From: Yang, Lily L [mailto:lily.l.yang@intel.com] Sent: Wednesday, June 15, 2005 1:19 PM To: Mani, Mahalingam (Mahalingam); Pat Calhoun Cc: capwap@frascone.com Subject: RE: [Capwap] Taxonomy Recommendations Hi, Pat and Mani -- I have not read through the entire Taxonomy Recommendations document yet, but just reading through the first few pages, I believe the authors are correct in pointing out one of the "inconsistency" (error) in the taxonomy draft. There was a paragraph in the taxonomy draft Section 5.6: " The commonalities and differences between Local MAC and Split MAC are most clearly seen by comparing Figure 7 to Figure 10. The commonality is that 802.11 control frames are terminated at WTPs in both cases. The main difference between Local MAC and Split MAC is that the WTP terminates only the 802.11 control frames in the Split MAC, while the WTP may terminate all 802.11 frames in the Local MAC. An interesting consequence of this difference is that the Integration Service, which essentially refers to bridging between 802.11 and 802.3 frames, is implemented by the AC in the Split MAC, but can be part of either the AC or WTP in the Local MAC." The last sentence, as pointed out by Pat, Bob and Inderpreet's document, was incorrect. According to Figure 9, Integration Service, for all the parties classified as Local MAC, is implemented by WTP. Given that we still have about 3 hours remaining in the authors' 48 hour window, I would like to send a note to RFC Editor suggesting the following sentence to replace the last sentence in the paragraph: "An interesting consequence of this difference is that the Integration Service, which essentially refers to bridging between 802.11 and 802.3 frames, is implemented by the AC in the Split MAC and by the WTP in the Local MAC, as shown in Figure 9 and Figure 12." Glaring as it is, I believe this error does not carry any far reaching implication to the entire document and hence it is bug we can fix right now. Regarding the comment from the authors that taxonomy draft lacks conclusion and recommendation and hence the motivation to take it further to clearly define what Local and Split MAC really mean in terms of functional split -- I think that is a fair comment -- Personally I was tempted to take that step in the taxonomy draft with the intention to help the WG moving forward, but as the editor of the draft, I received clear instruction from the chairs and the WG that a taxonomy only goes so far to "document" the reality of the market, not to "define" any architectures. So the draft deliberately didn't go far into making any specific functional split recommendation. As I advocated in both July and Nov IETF meeting last year, I believe there is indeed a gap between taxonomy draft and objective draft -- the WG needs a clear definition of the functional split for Local, especially Split MAC, but that is not the charter of either taxonomy draft or Objective draft. Some people have the illusion that IEEE 802.11 (specifically the APF ad hoc group) will provide such definition. The clear answer there is NO, IEEE would not do that. It is up to us in this group to agree on the split and move on. So if indeed this Taxonomy Recommendation draft fulfills this purpose, I personally believe it is a very necessary step to take in order to move forward. However, as I said, I have not reviewed the entire document yet and so I would reserve until then to offer any further comments. But I do want to fix the error in Section 5.6 in Taxonomy draft NOW. Lily -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Mani, Mahalingam (Mahalingam) Sent: Wednesday, June 15, 2005 11:14 AM To: Pat Calhoun; capwap@frascone.com Subject: RE: [Capwap] Taxonomy Recommendations Thanks for the joint effort (by authors of two candidate protocols for eval. as I see it) in making a case for clarification of terminology. If the changes and clarifications proposed are extensive - comments in form of I-D is useful to place-hold them. The WG should (especially the original taxonomy team authors) comment on these comments (draft): WG has approved the -06 version of the taxonomy draft. Two of the authors are in this as well :) It is also important to understand the implications, if any, (on Objectives draft) if WG agrees to any of the proposed clarifications. It may turn out to be transparent to the Objectives draft. This needs to happen soon for Objectives to freeze and let the evaluation team use a baselined version. [BTW: the taxonomy draft is in RFC editor's queue - actually just completed AUTH48]. -mani =3D=3D=3D=3D=3D=3D -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun Sent: Thursday, June 09, 2005 2:28 PM To: capwap@frascone.com Subject: [Capwap] Taxonomy Recommendations All, I wanted to announce the early availability of the CAPWAP taxonomy recommendation draft that Bob O'Hara Inderpreet Singh and I have been working on. It can be found at http://www.capwap.org/draft-calhoun-capwap-taxonomy-recommendation-00.tx t. Abstract The IETF's CAPWAP working group has documented various product architectures and has categorized the Centralized WLAN Architectures into two main buckets: Split and Local MAC. While the document contains very relevant and useful information, what it does is list the architectural variants of these two buckets, but does not unambiguously define either the Split MAC or Local MAC architectures. In order for CAPWAP to be successful, it is crucial for the protocol evaluation team, and the working group, to agree on unambiguous terminology to describe these architectures. This document proposes terminology to unambiguously describe the relevant architectures found in the taxonomy document, for the purpose of initiating a discussion within the working group and to allow the protocol evaluation work to come to a fruitful conclusion. We conclude in this document that the architectures are very similar and could be supported via a single protocol. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Jun 21 02:44:14 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16572 for ; Tue, 21 Jun 2005 02:44:14 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EB03E20475; Tue, 21 Jun 2005 02:44:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 521982034D; Tue, 21 Jun 2005 02:44:09 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7C70F2034D for ; Tue, 21 Jun 2005 02:43:03 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 7E9B5202A3 for ; Tue, 21 Jun 2005 02:43:00 -0400 (EDT) Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5L6V3AK024643 for ; Tue, 21 Jun 2005 02:31:04 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5L6V2AK024516 for ; Tue, 21 Jun 2005 02:31:02 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Taxonomy Recommendations Message-ID: <5844A41F4E146044A2E8356C6328588008DFE68E@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] Taxonomy Recommendations Thread-Index: AcV1vHEWo3ZDaar6RKy3OD8Tu9s2AQAKAKyQ From: "Sadot, Emek (Emek)" To: "James Kempf" , "Pat Calhoun" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 21 Jun 2005 02:42:57 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Jak The main reason I see to bridge frames at the WTP is to keep session's shortest path (diminish delay, latency, jitter, etc., for real-time application such as VoWLAN). For example: AC at NYC and WTP located at London; London office has two or three legs to the external world: (a) VPN/FR/Lease line to NYC main office, (b) local PSTN link and (c) local Internet service / exist to local ISP. Wi-Fi voice call from London office better not be traveled via NYC if not absolutely necessary. AC as a single point of failure is another point. Sustain existing Wi-Fi sessions while AC experience failure or experience network outage between WTP and AC. These are my points, other may have different view which is perfectly fine. Different architectures address different environments and different solutions. Just because a vendor can't figure out how another may solve a perceived problem doesn't mean it can't be done nor is it relevant to CAPWAP. I believe the group need to come up with a mechanism / process of how to decide on labor division. Only two distinctive options, Split and Local, is a bit too restricted. If I am not mistake there were four objectives which ignite CAPWAP: (a) AP is an IP-addressable device requiring management, monitoring, and control (b) Distributing and maintaining a consistent configuration, (c) Difficulty in dealing effectively with the dynamic nature of large WLAN and (d) Securing access to the network and preventing installation of unauthorized AP. CAPWAP is about Control and Provisioning. It says nothing about the user's data frames path. One more point, it's not mandatory that AC will be a dedicated HW appliance. It could be a piece of software runs on any platform. Overwhelming the AC with user's data implicitly dictates the former. It should be the other way around - one should come with a very good reason to execute bridging at the AC. In my opinion the protocol shell facilitate both, letting the operator the freedom to chose. To name a few reasons to consider bridging at the AC: 1. Statistics: AC can extract raw statistics / info from 802.11 frames. 2. Apply policy at the AC rather then at the WTP - simpler WTP. 3. If AC is a Layer 3 roaming facilitator. 4. If AC implements 802.11 encryption / decryption. (apologize, it turn out the answer is a bit too long that I expected) Emek -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com]=20 Sent: Monday, June 20, 2005 8:22 PM To: Sadot, Emek (Emek); Pat Calhoun; capwap@frascone.com Subject: Re: [Capwap] Taxonomy Recommendations Emek, Take for example the IS service: where it fits in Slit and Local - WTP or AC? I would disagree the authors conclusion (section 5 first bullet) w.r.t. bridging function, and believes we can, and should, allow the operator to chose. jak>> OK, so what criteria would cause an operator to choose bridging at jak>> the WTP versus bridging at the AC? jak _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Jun 21 10:25:17 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24058 for ; Tue, 21 Jun 2005 10:25:15 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C1D5720478; Tue, 21 Jun 2005 10:25:13 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8A9052045B; Tue, 21 Jun 2005 10:25:10 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 40D122045B for ; Tue, 21 Jun 2005 10:24:30 -0400 (EDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.frascone.com (Postfix) with ESMTP id D825320415 for ; Tue, 21 Jun 2005 10:24:27 -0400 (EDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 21 Jun 2005 07:24:26 -0700 Received: from pacalhouwxp ([10.32.30.113]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5LEOLFq002264; Tue, 21 Jun 2005 07:24:22 -0700 (PDT) Message-Id: <200506211424.j5LEOLFq002264@sj-core-1.cisco.com> From: "Pat Calhoun" To: "'James Kempf'" , "'Mani, Mahalingam (Mahalingam)'" , "'Yang, Lily L'" Cc: Subject: RE: [Capwap] Taxonomy Recommendations MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <019101c575bf$f223e850$016115ac@dcml.docomolabsusa.com> Thread-Index: AcV1v9o05ZJarCYBSKi/noumubZ5/gArO0dA X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.30.113] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 21 Jun 2005 07:24:23 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Thanks for your comments, Jim. If the WG desires, I can work the Bob O'Hara and Inderpreet in addressing comments to increase the value of the taxonomy recommendations draft. But before we go through this, is there a desire to start this activity, and is the said draft a good starting point? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Monday, June 20, 2005 10:46 AM > To: Mani, Mahalingam (Mahalingam); Yang, Lily L; Pat Calhoun > Cc: capwap@frascone.com > Subject: Re: [Capwap] Taxonomy Recommendations > > Mani, > > I think the basic problem here is that the taxonomy draft > discusses functional architecture and existing network > reference architectures but even though the network reference > architectures in the different existing products are > different and in some cased conflicting, the taxonomy draft > doesn't really point out where there is a conflict because, > as Lily said, that wasn't a goal of the draft. The grouping > of functional entities into network entities (i.e. boxes) in > the network reference architecture is what defines which > interfaces between functional entities are instantiated as > protocols and which are instantiated as APIs within a box. If > CAPWAP is ever to develop a standardized, interoperable > protocol, there must be a clear and precise understanding and > agreement on where these interfaces are. Pat and Inderpreet's > draft discuss a couple of issues around this but doesn't > really get to the heart of the problem. > > For example, taking the issue of where the distribution > function lies, if the distribution function is placed in the > WTP, then bridging is an API within the WTP box. If the > distribution function is placed in the AC, then there is need > for a protocol across the WTP/AC interface to tunnel 802.11 > data frames to the AC. > > Part of the problem is that the taxonomy draft renamed the AP > without changing really what it is. Both the AP and WTP are > network entities and not functional entities. > > The other, major part of the problem, as you outline below, > is that the IEEE has refused to commit to a network reference > architecture. They have only committed to a functional > architecture. Exactly what the interfaces are between network > entities and therefore where standardized protocols are > required is therefore not specified. Different vendors have > taken their own cut at this, so there are now multiple > network reference architectural variants in the market. Not > suprisingly, vendors are not going to agree to a particular > network reference architecture if it means that their > products will have protocol-requiring interfaces on the wrong > side of the split. So, I think it will be very hard to > achieve concensus on this, though I think it might help to > start with defining what network reference architectural > variants lead to what protocol interfaces. I think Pat and > Inderpreet's draft does make a good start at the latter, > though not in as formal a way as I've seen in past > architectural studies. > > jak > > > ----- Original Message ----- > From: "Mani, Mahalingam (Mahalingam)" > To: "Yang, Lily L" ; "Pat Calhoun" > > Cc: > Sent: Thursday, June 16, 2005 7:13 AM > Subject: RE: [Capwap] Taxonomy Recommendations > > > I have no objections to this 'bug-fix' if it can happen in > time and has > no author/WG objections. We can request the RFC Ed. to hold off. > > As for the other issue on split-MAC interpretation: > The split-discussion is long overdue; and is worth having - to help > evaluation as well. I think resolution of the discussion is > important to > arrive at the best approach to CAPWAP protocol accommodating/not split > variants. > > History: > We had clearly noted not to make any recommendations on what a split > characteristic must be in the taxonomy. This has perhaps been argued > many times in (taxonomy) design team and in IETF58-62 as > well. There was > no scope for us in the then charter to venture that way. > > When APF AHC initially started its work - the hope was it would offer > enough information for CAPWAP to draw conclusions for future > work; there > were no expectations on what they would recommend the split > ought to be > once they were chartered (there were hopes much prior to > that). Inasmuch > as IEEE 802.11 endorsed and acknowledged the documented > splits caused no > standards departure/breakage in implementation or behavior - by its > review of the taxonomy draft - we had validated all architectures from > IEEE 802.11 perspective. > > It was clear when APF AHC group was formed that it will transpire to > provide only clarifying interpretations of functions - not > delineate or > standardize splits. > > -mani > ====== > -----Original Message----- > From: Yang, Lily L [mailto:lily.l.yang@intel.com] > Sent: Wednesday, June 15, 2005 1:19 PM > To: Mani, Mahalingam (Mahalingam); Pat Calhoun > Cc: capwap@frascone.com > Subject: RE: [Capwap] Taxonomy Recommendations > > > Hi, Pat and Mani -- > > I have not read through the entire Taxonomy Recommendations document > yet, but just reading through the first few pages, I believe > the authors > are correct in pointing out one of the "inconsistency" (error) in the > taxonomy draft. There was a paragraph in the taxonomy draft > Section 5.6: > " The commonalities and differences between Local MAC and > Split MAC are > most clearly seen by comparing Figure 7 to Figure 10. The > commonality is that 802.11 control frames are terminated at WTPs in > both cases. The main difference between Local MAC and Split MAC is > that the WTP terminates only the 802.11 control frames in the Split > MAC, while the WTP may terminate all 802.11 frames in the > Local MAC. > An interesting consequence of this difference is that the > Integration > Service, which essentially refers to bridging between 802.11 and > 802.3 frames, is implemented by the AC in the Split MAC, but can be > part of either the AC or WTP in the Local MAC." > The last sentence, as pointed out by Pat, Bob and > Inderpreet's document, > was incorrect. According to Figure 9, Integration Service, for all the > parties classified as Local MAC, is implemented by WTP. > Given that we still have about 3 hours remaining in the > authors' 48 hour > window, I would like to send a note to RFC Editor suggesting the > following sentence to replace the last sentence in the paragraph: > "An interesting consequence of this difference is that the Integration > Service, which essentially refers to bridging between 802.11 and > 802.3 frames, is implemented by the AC in the Split MAC and by the > WTP in the Local MAC, as shown in Figure 9 and Figure 12." > > Glaring as it is, I believe this error does not carry any far reaching > implication to the entire document and hence it is bug we can > fix right > now. > > Regarding the comment from the authors that taxonomy draft lacks > conclusion and recommendation and hence the motivation to take it > further to clearly define what Local and Split MAC really > mean in terms > of functional split -- I think that is a fair comment -- Personally I > was tempted to take that step in the taxonomy draft with the intention > to help the WG moving forward, but as the editor of the draft, I > received clear instruction from the chairs and the WG that a taxonomy > only goes so far to "document" the reality of the market, not to > "define" any architectures. So the draft deliberately didn't > go far into > making any specific functional split recommendation. > > As I advocated in both July and Nov IETF meeting last year, I believe > there is indeed a gap between taxonomy draft and objective > draft -- the > WG needs a clear definition of the functional split for Local, > especially Split MAC, but that is not the charter of either taxonomy > draft or Objective draft. Some people have the illusion that > IEEE 802.11 > (specifically the APF ad hoc group) will provide such definition. The > clear answer there is NO, IEEE would not do that. It is up to > us in this > group to agree on the split and move on. So if indeed this Taxonomy > Recommendation draft fulfills this purpose, I personally > believe it is a > very necessary step to take in order to move forward. However, as I > said, I have not reviewed the entire document yet and so I > would reserve > until then to offer any further comments. > > But I do want to fix the error in Section 5.6 in Taxonomy draft NOW. > > Lily > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Mani, Mahalingam (Mahalingam) > Sent: Wednesday, June 15, 2005 11:14 AM > To: Pat Calhoun; capwap@frascone.com > Subject: RE: [Capwap] Taxonomy Recommendations > > Thanks for the joint effort (by authors of two candidate protocols for > eval. as I see it) in making a case for clarification of terminology. > > If the changes and clarifications proposed are extensive - comments in > form of I-D is useful to place-hold them. > > The WG should (especially the original taxonomy team authors) > comment on > these comments (draft): WG has approved the -06 version of > the taxonomy > draft. Two of the authors are in this as well :) > > It is also important to understand the implications, if any, (on > Objectives draft) if WG agrees to any of the proposed > clarifications. It > may turn out to be transparent to the Objectives draft. This needs to > happen soon for Objectives to freeze and let the evaluation team use a > baselined version. > > [BTW: the taxonomy draft is in RFC editor's queue - actually just > completed AUTH48]. > > -mani > ====== > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Pat Calhoun > Sent: Thursday, June 09, 2005 2:28 PM > To: capwap@frascone.com > Subject: [Capwap] Taxonomy Recommendations > > All, > > I wanted to announce the early availability of the CAPWAP taxonomy > recommendation draft that Bob O'Hara Inderpreet Singh and I have been > working on. It can be found at > http://www.capwap.org/draft-calhoun-capwap-taxonomy-recommenda > tion-00.tx > t. > > > Abstract > > The IETF's CAPWAP working group has documented various product > architectures and has categorized the Centralized WLAN > Architectures > into two main buckets: Split and Local MAC. While the document > contains very relevant and useful information, what it does is list > the architectural variants of these two buckets, but does not > unambiguously define either the Split MAC or Local MAC > architectures. > In order for CAPWAP to be successful, it is crucial for > the protocol > evaluation team, and the working group, to agree on unambiguous > terminology to describe these architectures. > > This document proposes terminology to unambiguously describe the > relevant architectures found in the taxonomy document, for the > purpose of initiating a discussion within the working group and to > allow the protocol evaluation work to come to a fruitful > conclusion. > We conclude in this document that the architectures are > very similar > and could be supported via a single protocol. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Jun 21 10:34:13 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25007 for ; Tue, 21 Jun 2005 10:34:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 66CE920484; Tue, 21 Jun 2005 10:34:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D8B762045B; Tue, 21 Jun 2005 10:34:09 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 545772045B for ; Tue, 21 Jun 2005 10:33:46 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 4C25120415 for ; Tue, 21 Jun 2005 10:33:43 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 21 Jun 2005 07:33:43 -0700 X-IronPort-AV: i="3.93,218,1115017200"; d="scan'208"; a="281322548:sNHT33043044" Received: from pacalhouwxp ([10.32.30.113]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5LEXeqi024365; Tue, 21 Jun 2005 07:33:41 -0700 (PDT) Message-Id: <200506211433.j5LEXeqi024365@sj-core-5.cisco.com> From: "Pat Calhoun" To: "'Sadot, Emek (Emek)'" , "'James Kempf'" , Subject: RE: [Capwap] Taxonomy Recommendations MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <5844A41F4E146044A2E8356C6328588008DFE68E@nj7460avexu2.global.avaya.com> Thread-Index: AcV1vHEWo3ZDaar6RKy3OD8Tu9s2AQAKAKyQACImhqA= X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.30.113] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 21 Jun 2005 07:33:40 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Emek, I'd like to address the two main points you've made in your e-mail. 1. Keep the data path short. I agree that there are some challenges when an AC is situated very far from the WTP, and that's the exact reason why one does need what I call Local AP in the taxonomy recommendations draft. However, most "CAPWAP-like" deployments out there really don't fall under the category you mention - all ACs are located topologically near the the WTPs, and in such cases having the data path centralized allows a powerful AC to perform many policy, security and mobility related functions that would be hard to do on a standalone WTP (but by being centralized allows for these functions to execute even across mobility events). Just using one example, what if NAT were to be provided on the WTP, how could the network converge in understanding what flows are active, and the related port mapping? Hence my recommendation for Split and Local AP - where the former tunnels the data to the AC and the latter does not. The customer can use one or the other, mostly based on topological requirements. 2. Single point of failure. I've addressed this in prior e-mails, and the LWAPP protocol addresses this. Further, if a WTP relies on an AC, you have a point of failure regardless. So this needs to be addressed in a protocol, and it's not just the data path that's at stake here. I realize we're not in complete agreement on this topic yet, but I still do believe that reducing the options is a feature, not a bug. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) > Sent: Monday, June 20, 2005 11:43 PM > To: James Kempf; Pat Calhoun; capwap@frascone.com > Subject: RE: [Capwap] Taxonomy Recommendations > > Jak > > The main reason I see to bridge frames at the WTP is to keep > session's shortest path (diminish delay, latency, jitter, > etc., for real-time application such as VoWLAN). For example: > AC at NYC and WTP located at London; London office has two or > three legs to the external world: (a) VPN/FR/Lease line to > NYC main office, (b) local PSTN link and (c) local Internet > service / exist to local ISP. Wi-Fi voice call from London > office better not be traveled via NYC if not absolutely necessary. > > AC as a single point of failure is another point. Sustain > existing Wi-Fi sessions while AC experience failure or > experience network outage between WTP and AC. > > These are my points, other may have different view which is > perfectly fine. Different architectures address different > environments and different solutions. Just because a vendor > can't figure out how another may solve a perceived problem > doesn't mean it can't be done nor is it relevant to CAPWAP. > > I believe the group need to come up with a mechanism / > process of how to decide on labor division. Only two > distinctive options, Split and Local, is a bit too restricted. > > If I am not mistake there were four objectives which ignite > CAPWAP: (a) AP is an IP-addressable device requiring > management, monitoring, and control (b) Distributing and > maintaining a consistent configuration, (c) Difficulty in > dealing effectively with the dynamic nature of large WLAN and > (d) Securing access to the network and preventing > installation of unauthorized AP. > > CAPWAP is about Control and Provisioning. It says nothing > about the user's data frames path. > One more point, it's not mandatory that AC will be a > dedicated HW appliance. It could be a piece of software runs > on any platform. > Overwhelming the AC with user's data implicitly dictates the former. > > It should be the other way around - one should come with a > very good reason to execute bridging at the AC. In my opinion > the protocol shell facilitate both, letting the operator the > freedom to chose. > To name a few reasons to consider bridging at the AC: > 1. Statistics: AC can extract raw statistics / info from > 802.11 frames. > 2. Apply policy at the AC rather then at the WTP - simpler WTP. > 3. If AC is a Layer 3 roaming facilitator. > 4. If AC implements 802.11 encryption / decryption. > > (apologize, it turn out the answer is a bit too long that I > expected) Emek > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Monday, June 20, 2005 8:22 PM > To: Sadot, Emek (Emek); Pat Calhoun; capwap@frascone.com > Subject: Re: [Capwap] Taxonomy Recommendations > > Emek, > > Take for example the IS service: where it fits in Slit and > Local - WTP or AC? I would disagree the authors conclusion > (section 5 first bullet) w.r.t. bridging function, and > believes we can, and should, allow the operator to chose. > > jak>> OK, so what criteria would cause an operator to choose > bridging at > > jak>> the > WTP versus bridging at the AC? > > jak > > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Jun 21 12:34:12 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06255 for ; Tue, 21 Jun 2005 12:34:12 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 63B6C2049B; Tue, 21 Jun 2005 12:34:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B63CC20443; Tue, 21 Jun 2005 12:34:09 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 645EE20443 for ; Tue, 21 Jun 2005 12:33:17 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 6FEB02042E for ; Tue, 21 Jun 2005 12:33:12 -0400 (EDT) Message-ID: <054901c5767f$1540a750$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Sadot, Emek (Emek)" , "Pat Calhoun" , References: <5844A41F4E146044A2E8356C6328588008DFE68E@nj7460avexu2.global.avaya.com> Subject: Re: [Capwap] Taxonomy Recommendations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 21 Jun 2005 09:34:16 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Emek, The main reason I see to bridge frames at the WTP is to keep session's shortest path (diminish delay, latency, jitter, etc., for real-time application such as VoWLAN). For example: AC at NYC and WTP located at London; London office has two or three legs to the external world: (a) VPN/FR/Lease line to NYC main office, (b) local PSTN link and (c) local Internet service / exist to local ISP. Wi-Fi voice call from London office better not be traveled via NYC if not absolutely necessary. jak>> Is this a realistic deployment scenerio? I don't know what the RTT packet latency is between NYC and London, but from San Jose, we typically get somewhere around 100-130 ms to Europe. I'm not sure that this would be acceptable even for control traffic. I think that any deployment which would experience delay/latency/jitter for application traffic might also have problems for control traffic too. AC as a single point of failure is another point. Sustain existing Wi-Fi sessions while AC experience failure or experience network outage between WTP and AC. jak>> Yes, that seems to be a realistic reason. It is also a reason for thinking about mechanisms for failover of the WTC to another AC in the control protocol. In some cases, it might be acceptable to have tunnel failover slightly delayed; in others, possibly not. ... CAPWAP is about Control and Provisioning. It says nothing about the user's data frames path. One more point, it's not mandatory that AC will be a dedicated HW appliance. It could be a piece of software runs on any platform. Overwhelming the AC with user's data implicitly dictates the former. jak>> I'm not so sure. There have been some arguments advanced why putting the distribution function at the AC would be desirable. You list them below. It should be the other way around - one should come with a very good reason to execute bridging at the AC. In my opinion the protocol shell facilitate both, letting the operator the freedom to chose. To name a few reasons to consider bridging at the AC: 1. Statistics: AC can extract raw statistics / info from 802.11 frames. 2. Apply policy at the AC rather then at the WTP - simpler WTP. 3. If AC is a Layer 3 roaming facilitator. 4. If AC implements 802.11 encryption / decryption. jak>> So it seems you are proposing to separate the control and data plane, and then some way in the control protocol to negotiate how the data plane is handled? Is that correct? jak _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Jun 21 16:43:14 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12893 for ; Tue, 21 Jun 2005 16:43:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 96F972034B; Tue, 21 Jun 2005 16:43:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D856020266; Tue, 21 Jun 2005 16:43:09 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6EC7920266 for ; Tue, 21 Jun 2005 16:42:49 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 521D41FC24 for ; Tue, 21 Jun 2005 16:42:46 -0400 (EDT) Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5LKUnAK025115 for ; Tue, 21 Jun 2005 16:30:49 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5LKUlAK025078 for ; Tue, 21 Jun 2005 16:30:48 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C576A1.C69D9638" Message-ID: Thread-Topic: Drafts availability on CAPWAP webpage. Thread-Index: AcV2ocUnsVEPrMEsTkqW8o94dEAPlA== X-Priority: 1 Priority: Urgent Importance: high From: "Mani, Mahalingam (Mahalingam)" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Drafts availability on CAPWAP webpage. Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 21 Jun 2005 14:42:44 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C576A1.C69D9638 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The candidate protocol drafts & comparison drafts are now available on the IETF CAPWAP webpage (current versions). The SLAPP comparison draft, missing from showing up in the IETF repository until recently, will also be placed there soon. =20 Regards, -mani =3D=3D=3D=3D=3D=3D =20 ------_=_NextPart_001_01C576A1.C69D9638 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The candidate protocol drafts & comparison drafts = are now available on the IETF CAPWAP webpage (current versions).

The SLAPP comparison draft, missing from showing up in the IETF repository = until recently, will also be placed there soon.

 

Regards,

-mani

=3D=3D=3D=3D=3D=3D

 

------_=_NextPart_001_01C576A1.C69D9638-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From balckburn@didamail.com Tue Jun 21 17:14:58 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15184; Tue, 21 Jun 2005 17:14:58 -0400 (EDT) From: balckburn@didamail.com Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkqTD-00060X-HR; Tue, 21 Jun 2005 17:39:48 -0400 Received: from pcp0011765087pcs.owngsm01.md.comcast.net ([68.33.83.43] helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1Dkq5C-0007YW-KC; Tue, 21 Jun 2005 17:14:59 -0400 Received: from IOROKholt.com (EHLO aeqlf-a.electrophorus.EW.ugf.net) wier by mail.mtk.nao.ac.jp (1.6[2 Message-Id: Date: Tue, 21 Jun 2005 17:14:59 -0400 X-Spam-Score: 7.1 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From lindbloom@fadmail.com Tue Jun 21 23:26:26 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14463; Tue, 21 Jun 2005 23:26:26 -0400 (EDT) Received: from [211.161.199.19] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DkwGj-0008Sa-Mh; Tue, 21 Jun 2005 23:51:20 -0400 Received: from covet.gfdzqp.usda.syria.com by portend.cartographer.demitting.com (lthupfix) with SMTP id 2B29E820989 for ; Wed, 22 Jun 2005 02:28:39 -0200 Message-ID: Date: Wed, 22 Jun 2005 02:23:39 -0200 From: "Leah Wiggins" To: Subject: Re-finance at todays low rate X-Mailer: KYX CP/M FNORD 5602 X-Spam-Score: 8.1 (++++++++) X-Spam-Flag: YES X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have been selected for our lowest rate in years... You could get over $420,000 for as little as $400 a month! Ba(d credit, Bank*ruptcy? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.stra1n.com/signs.asp Best Regards, Eldon Shaw to be remov(ed: http://www.stra1n.com/deletion.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From capwap-admin@frascone.com Thu Jun 23 11:47:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlTvD-0006IA-Oc for capwap-archive@megatron.ietf.org; Thu, 23 Jun 2005 11:47:19 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26212 for ; Thu, 23 Jun 2005 11:47:14 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8FC38202BA; Thu, 23 Jun 2005 11:47:13 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 700BD1FD61; Thu, 23 Jun 2005 11:47:10 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9381F1FD61 for ; Thu, 23 Jun 2005 11:46:46 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 66CED1FC41 for ; Thu, 23 Jun 2005 11:46:43 -0400 (EDT) Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5NFYiAK015295 for ; Thu, 23 Jun 2005 11:34:44 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5NFXpAK014134 for ; Thu, 23 Jun 2005 11:33:53 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5780A.9CC762F8" x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Capwap] Important Note: All Authors of Candidate Protocol Message-ID: Thread-Topic: [Capwap] Important Note: All Authors of Candidate Protocol Thread-Index: AcVyK34/MkqYZrMeQZK2Yo7hdm8eigF3sX7A X-Priority: 1 Priority: Urgent Importance: high From: "Mani, Mahalingam (Mahalingam)" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 23 Jun 2005 09:45:42 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C5780A.9CC762F8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a reminder that tomorrow is the deadline for submitting protocol draft revisions for baselining for evaluation. =20 It is also the preferred deadline for submitting revisions to comparison drafts - for baselining. Monday is the hard deadline. =20 Thanks, -WG Chairs =3D=3D=3D=3D=3D=3D _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Mani, Mahalingam (Mahalingam) Sent: Wednesday, June 15, 2005 9:26 PM To: capwap@frascone.com Subject: [Capwap] Important Note: All Authors of Candidate Protocol Importance: High =20 The evaluation team is in place and met for the first time today. =20 The Objectives draft authors are expected to deliver a revision reflecting the WG consensus on Friday (6/17). While the revision goes through the customary review process (we expect no impactive major revisions after this) and wends its way to WGLC and onwards; the evaluation team will use this version as baseline. =20 So far we have not frozen the candidate protocols from revising their drafts in consideration of meeting any (significant) changes to Objectives draft. Theoretically one does not preclude such changes to come about; but we believe this is the right point to do so in an optimistic approach to parallelism and moving the WG milestones forward albeit with all the delays so far. =20 Now - a deadline for revisions is flagged - a week from 6/17. Any revisions the protocol authors wish to make to their submissions please do so by 6//24/05. This will let the evaluation team do its work based on the baselined revisions of the Objectives and Protocol drafts. =20 The general guidelines for the evaluation process are along the lines used in evaluation of AAA protocol (refer RFC3127 ). =20 Hence - please note: 1. Baseline revision of Objectives draft for evaluation being submitted by 6/17 and available (may take a while to appear in ID repository). 2. Protocol revisions, if any, to be baselined by 6/24. If you do not expect to revise your draft submission between now and that date - do let the chairs know. We would notify the evaluation team to start their work on those. We request all authors to note and hold to this timeline (9pmPT of 6/24/05). 3. 6/24 is also the day for the authors to turn their comparison drafts in. that will be a soft-date. The hard date is 6/26/05 9pmPT. =20 We will be arranging for all comparison and protocol revisions to be accessible from the WG webpage . =20 Regards, -mani & Dorothy =3D=3D=3D=3D=3D=3D =20 ------_=_NextPart_001_01C5780A.9CC762F8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just a reminder that tomorrow is = the deadline for submitting protocol draft revisions for baselining  = for evaluation.

 

It is also the preferred deadline = for submitting revisions to comparison drafts – for baselining. Monday is the = hard deadline.

 

Thanks,

-WG = Chairs

=3D=3D=3D=3D=3D=3D<= o:p>

From: = capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Mani, = Mahalingam (Mahalingam)
Sent: Wednesday, June 15, = 2005 9:26 PM
To: = capwap@frascone.com
Subject: [Capwap] = Important Note: All Authors of Candidate Protocol
Importance: = High

 

The evaluation team is in place and met for the first = time today.

 

The Objectives draft authors are expected to deliver = a revision reflecting the WG consensus on Friday = (6/17).

While the revision goes through the customary review = process (we expect no impactive major revisions after this) and wends its way to = WGLC and onwards; the evaluation team will use this version as = baseline.

 

So far we have not frozen the candidate protocols = from revising their drafts in consideration of meeting any (significant) = changes to Objectives draft. Theoretically one does not preclude such changes to = come about; but we believe this is the right point to do so in an optimistic approach to parallelism and moving the WG milestones forward albeit with = all the delays so far.

 

Now – a deadline for revisions is flagged = – a week from 6/17. Any revisions the protocol authors wish to make to their submissions please do so by 6//24/05. This will let the evaluation team = do its work based on the baselined revisions of the Objectives and Protocol = drafts.

 

The general guidelines for the evaluation process are = along the lines used in evaluation of AAA protocol (refer RFC3127).<= o:p>

 

Hence – please = note:

  1. Baseline revision of = Objectives draft for evaluation being submitted by 6/17 and available (may = take a while to appear in ID repository).
  2. Protocol revisions, if = any, to be baselined by 6/24. If you do not expect to revise your draft = submission between now and that date – do let the chairs know. We would = notify the evaluation team to start their work on those. We request all = authors to note and hold to this timeline (9pmPT of = 6/24/05).
  3. 6/24 is also the day = for the authors to turn their comparison drafts in. that will be a = soft-date. The hard date is 6/26/05 9pmPT.

 

We will be arranging for all comparison and protocol revisions to be accessible from the WG webpage.

 

Regards,

-mani & Dorothy

=3D=3D=3D=3D=3D=3D

 

------_=_NextPart_001_01C5780A.9CC762F8-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Jun 27 11:24:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmvT6-0001eP-MQ for capwap-archive@megatron.ietf.org; Mon, 27 Jun 2005 11:24:16 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02928 for ; Mon, 27 Jun 2005 11:24:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B22602045C; Mon, 27 Jun 2005 11:24:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 901F220446; Mon, 27 Jun 2005 11:24:09 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B43DD20446 for ; Mon, 27 Jun 2005 11:23:03 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 89E1E2043E for ; Mon, 27 Jun 2005 11:23:00 -0400 (EDT) Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5RFAvAK023594 for ; Mon, 27 Jun 2005 11:10:58 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5RFApAK023413 for ; Mon, 27 Jun 2005 11:10:53 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: Protocol draft updates received Thread-Index: AcV7LBCitzXP6teRQjSguNxwU9dH7A== X-Priority: 1 Priority: Urgent Importance: high From: "Mani, Mahalingam (Mahalingam)" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Protocol draft updates received Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 27 Jun 2005 09:22:51 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable LWAPP draft updates - protocol and comparison - (received Friday 6/24 by IETF) have also been posted in www.capwap.org. They should soon appear in the IETF repository. All baselined protocol drafts can now be referenced from http://www.capwap.org/DraftsForEvaluation/ Any communications/questions to CAPWAP evaluation team may be sent to capwap-et@frascone.com (this email list is used by evaluation team to get evaluation work done). This (archived) list is not open for subscription. However, the archive will be available for viewing after evaluation phase. The proposed evaluation schedule will be posted later today. Regards, -mani & Dorothy =3D=3D=3D=3D=3D=3D _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Jun 27 15:37:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmzPy-0003cx-LZ for capwap-archive@megatron.ietf.org; Mon, 27 Jun 2005 15:37:19 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28440 for ; Mon, 27 Jun 2005 15:37:15 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E0BC920485; Mon, 27 Jun 2005 15:37:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CEDFD20472; Mon, 27 Jun 2005 15:37:08 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AA45D20472 for ; Mon, 27 Jun 2005 15:36:47 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id 353442045C for ; Mon, 27 Jun 2005 15:36:42 -0400 (EDT) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5RJYBdd026015 for ; Mon, 27 Jun 2005 15:34:12 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5RJWMdd023245 for ; Mon, 27 Jun 2005 15:33:01 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Protocol draft updates received Message-ID: Thread-Topic: [Capwap] Protocol draft updates received Thread-Index: AcV7LBCitzXP6teRQjSguNxwU9dH7AAGnQQg X-Priority: 1 Priority: Urgent Importance: high From: "Mani, Mahalingam (Mahalingam)" To: "Mani, Mahalingam (Mahalingam)" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 27 Jun 2005 13:34:51 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable CTP has also submitted a revision on 6/24. the updated link (to the updated version will appear) soon on the webpage (http://www.capwap.org/DraftsForEvaluation/) indicated below. -mani =3D=3D=3D=3D=3D=3D -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Mani, Mahalingam (Mahalingam) Sent: Monday, June 27, 2005 8:23 AM To: capwap@frascone.com Subject: [Capwap] Protocol draft updates received Importance: High LWAPP draft updates - protocol and comparison - (received Friday 6/24 by IETF) have also been posted in www.capwap.org. They should soon appear in the IETF repository. All baselined protocol drafts can now be referenced from http://www.capwap.org/DraftsForEvaluation/ Any communications/questions to CAPWAP evaluation team may be sent to capwap-et@frascone.com (this email list is used by evaluation team to get evaluation work done). This (archived) list is not open for subscription. However, the archive will be available for viewing after evaluation phase. The proposed evaluation schedule will be posted later today. Regards, -mani & Dorothy =3D=3D=3D=3D=3D=3D _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Jun 27 19:44:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn3Gx-0004ym-Tk for capwap-archive@megatron.ietf.org; Mon, 27 Jun 2005 19:44:16 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13318 for ; Mon, 27 Jun 2005 19:44:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0918A20484; Mon, 27 Jun 2005 19:44:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B6B622049D; Mon, 27 Jun 2005 19:44:09 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F315E2049D for ; Mon, 27 Jun 2005 19:44:00 -0400 (EDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail.frascone.com (Postfix) with ESMTP id 06CBC20484 for ; Mon, 27 Jun 2005 19:43:58 -0400 (EDT) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 27 Jun 2005 16:43:57 -0700 Received: from pacalhouwxp (dhcp-171-71-203-78.cisco.com [171.71.203.78]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j5RNhqbp012113; Mon, 27 Jun 2005 16:43:53 -0700 (PDT) Message-Id: <200506272343.j5RNhqbp012113@sj-core-4.cisco.com> From: "Pat Calhoun" To: Cc: "'Susan Hares'" , "'Bob O'Hara (boohara)'" , , , "'Nancy Winget (ncamwing)'" , "'Rohit Suri (rsuri)'" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcV7chMRxjblkAcVRFyHBjsaYj2fwA== X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Updated LWAPP spec Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 27 Jun 2005 16:43:52 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit All, I wanted to provide an update to the Working Group on the new LWAPP specification that was posted last Friday (http://www.capwap.org/DraftsForEvaluation/draft-ohara-capwap-lwapp-03.txt). This document emcompasses changes resulting from the security review, as well as changes to match the latest CAPWAP objectives specification. Further, we have not only added technical changes, but also included a significant number of changes describing behavioral recommendations that would improve implementations and help ensure interoperability. Here are the major changes introduced in this new version: - New State Machine now requires the use of the Join Confirm to provide explicit key confirmation (section 2.2, 6.3 and 6.4). Previously, the Join Confirm was only required for pre-shared key - New Key Update process now works very similarly to Join Confirm, where an additional round trip was included to provide explicit key confirmation (section 2.2, 6.9 and 6.10) - Support for IPv6 - Additional text to cover QoS handling of LWAPP Control Frames and 802.11 MAC Management Frames (sections 4.2.3 and 11.5, respectively) - Additional text covering configuration consistency (section 7.1). - Cleaned up text discussion LWAPP control frame encryption (section 10.2) - New X.509 and Pre-Shared Key key exchange. The approach is consistent with the comments provided during the security review, and has been reviewed by Charles Clancy. The text describing the whole key exchange has been significantly upgraded to ease readability (sections 10..3) - X.509 Certificate Profile to address a comment in the security review (section 10.4) - Division of Labor providing clear text and figures showing the behavior of a Split vs. Local MAC WTP/AC (section 11.1) - Recommended text on dealing with 802.11i for roaming stations, as recommended in the security review (section 11.2) - Recommended text on BSSID/WLAN Id mapping (section 11.4) - NAT Considerations section was added (section 14) - Required changes to the Security Considerations section to handle the new key exchange text (section 15) We have also submitted a new LWAPP Self Evaluation document to match the changes listed above (http://www.capwap.org/DraftsForEvaluation/draft-calhoun-capwap-lwapp-object ives-comparison-01.txt). The authors believe that protocol is now in compliance with all CAPWAP objectives. While we believe that the previous version of the LWAPP specification was very complete, we believe that the changes made resulting from the security review and the CAPWAP objectives specification have made the protocol much better, and for this we'd like to thank Charles Clancy and the Working Group. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From 634earl@5pillars.com Mon Jun 27 21:44:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn59H-0006Uf-16 for capwap-archive@megatron.ietf.org; Mon, 27 Jun 2005 21:44:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21656 for ; Mon, 27 Jun 2005 21:44:24 -0400 (EDT) Received: from 112.red-82-158-96.user.auna.net ([82.158.96.112]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dn5YT-0002jT-74 for capwap-archive@ietf.org; Mon, 27 Jun 2005 22:10:33 -0400 Message-ID: <351b01c57b81$dd1141ee$62ce9070@5pillars.com> From: "Vanessa J. Smith" <634earl@5pillars.com> To: capwap-archive@ietf.org Subject: =?iso-8859-1?B?V2luZG93cyBYUCArIE9mZmljZSBYUCA9ICQ4OS45NQ==?= Date: Tue, 28 Jun 2005 01:32:23 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_E1900EC8.5EE18227" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.4 (++) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc This is a multi-part message in MIME format. ------=_NextPart_000_0000_E1900EC8.5EE18227 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_8ED3DD1C.10133B02" ------=_NextPart_001_0001_8ED3DD1C.10133B02 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Get access to all the software possible for bottom prices! We sell software 2-6 times cheaper than retail price. Examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $69.95 MS Visio 2003 Professional Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many other... To visit us go: http://www.softdisks-ltd.com Best regards, Vanessa J. Smith _____________________________________________________ To change your mail details, go: http://www.softdisks-ltd.com/uns.htm _____________________________________________________ ------=_NextPart_001_0001_8ED3DD1C.10133B02 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
Get access to all the software possible for bottom prices!
We sell software 2-6 times cheaper than retail price.

Examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
$79.95 Adobe Acrobat 6.0 Professional
$69.95 MS Visio 2003 Professional

Special Offers:
$89.95 Windows XP Professional + Office XP Professional
$149.95 Adobe Creative Suite Premium (5 CD)
$129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And many other... To visit us go:

http://www.softdisks-ltd.com

Best regards,
Vanessa J. Smith


_____________________________________________________
To change your mail details, go: http://www.softdisks-ltd.com/uns.htm
_____________________________________________________

------=_NextPart_001_0001_8ED3DD1C.10133B02-- ------=_NextPart_000_0000_E1900EC8.5EE18227-- From capwap-admin@frascone.com Tue Jun 28 02:15:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn9NN-0008Bj-UV for capwap-archive@megatron.ietf.org; Tue, 28 Jun 2005 02:15:24 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25450 for ; Tue, 28 Jun 2005 02:15:15 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CBB70204A5; Tue, 28 Jun 2005 02:15:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0B5EE20446; Tue, 28 Jun 2005 02:15:09 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 985D620446 for ; Tue, 28 Jun 2005 02:14:17 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id B0C561FC24 for ; Tue, 28 Jun 2005 02:14:15 -0400 (EDT) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5S6Bjdd014443 for ; Tue, 28 Jun 2005 02:11:45 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5S6Bhdd014423 for ; Tue, 28 Jun 2005 02:11:44 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Taxonomy Recommendations Message-ID: <5844A41F4E146044A2E8356C6328588008EF8576@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] Taxonomy Recommendations Thread-Index: AcV2fyQvT3TFd7EIQ1WIYguu8qORuAFKGGzQ From: "Sadot, Emek (Emek)" To: "James Kempf" , "Pat Calhoun" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 28 Jun 2005 02:14:12 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable James, Please see inline. Emek=20 -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com]=20 Sent: Tuesday, June 21, 2005 7:34 PM To: Sadot, Emek (Emek); Pat Calhoun; capwap@frascone.com Subject: Re: [Capwap] Taxonomy Recommendations Emek, The main reason I see to bridge frames at the WTP is to keep session's shortest path (diminish delay, latency, jitter, etc., for real-time application such as VoWLAN). For example: AC at NYC and WTP located at London; London office has two or three legs to the external world: (a) VPN/FR/Lease line to NYC main office, (b) local PSTN link and (c) local Internet service / exist to local ISP. Wi-Fi voice call from London office better not be traveled via NYC if not absolutely necessary. jak>> Is this a realistic deployment scenerio? I don't know what the RTT packet latency is between NYC and London, but from San Jose, we typically get somewhere around 100-130 ms to Europe. I'm not sure that this would be acceptable even for control traffic. I think that any deployment which would experience delay/latency/jitter for application traffic might also have problems for control traffic too. [Emek] If you find it nonrealistic scenario then how about a local / domestic insurance company or a bank with local HQ and many local small offices? The point I am trying to make is that even if (respectfully) you and I cannot agree it shouldn't restrain the protocol from providing such an alternative. AC as a single point of failure is another point. Sustain existing Wi-Fi sessions while AC experience failure or experience network outage between WTP and AC. jak>> Yes, that seems to be a realistic reason. It is also a reason for thinking about mechanisms for failover of the WTC to another AC in the control protocol. In some cases, it might be acceptable to have tunnel failover slightly delayed; in others, possibly not. ... CAPWAP is about Control and Provisioning. It says nothing about the user's data frames path. One more point, it's not mandatory that AC will be a dedicated HW appliance. It could be a piece of software runs on any platform. Overwhelming the AC with user's data implicitly dictates the former. jak>> I'm not so sure. There have been some arguments advanced why=20 jak>> putting the distribution function at the AC would be desirable. You list them below. It should be the other way around - one should come with a very good reason to execute bridging at the AC. In my opinion the protocol shell facilitate both, letting the operator the freedom to chose. To name a few reasons to consider bridging at the AC: 1. Statistics: AC can extract raw statistics / info from 802.11 frames. 2. Apply policy at the AC rather then at the WTP - simpler WTP. 3. If AC is a Layer 3 roaming facilitator. 4. If AC implements 802.11 encryption / decryption. jak>> So it seems you are proposing to separate the control and data=20 jak>> plane, and then some way in the control protocol to negotiate how the data plane is handled? Is that correct? [Emek] It's exactly what I am proposing. jak _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Jun 28 02:15:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn9Ng-0008Ck-7K for capwap-archive@megatron.ietf.org; Tue, 28 Jun 2005 02:15:36 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25799 for ; Tue, 28 Jun 2005 02:15:34 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 30CE0204C5; Tue, 28 Jun 2005 02:15:33 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 73C881FC24; Tue, 28 Jun 2005 02:15:29 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A43D320446 for ; Tue, 28 Jun 2005 02:14:35 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id CBD941FC24 for ; Tue, 28 Jun 2005 02:14:33 -0400 (EDT) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5S6C4dd014730 for ; Tue, 28 Jun 2005 02:12:04 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5S6C2dd014698 for ; Tue, 28 Jun 2005 02:12:03 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Taxonomy Recommendations Message-ID: <5844A41F4E146044A2E8356C6328588008EF8577@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] Taxonomy Recommendations Thread-Index: AcV1vHEWo3ZDaar6RKy3OD8Tu9s2AQAKAKyQACImhqABTc6IoA== From: "Sadot, Emek (Emek)" To: "Pat Calhoun" , "James Kempf" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 28 Jun 2005 02:14:31 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Pat, We will just have to agree to disagree on whether or not the CAPWAP protocol should serve as a platform for more-then-just-two distinct architectures. I fail to see the NAT problem you described. Regards, Emek -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun Sent: Tuesday, June 21, 2005 5:34 PM To: Sadot, Emek (Emek); 'James Kempf'; capwap@frascone.com Subject: RE: [Capwap] Taxonomy Recommendations Emek, I'd like to address the two main points you've made in your e-mail. 1. Keep the data path short. I agree that there are some challenges when an AC is situated very far from the WTP, and that's the exact reason why one does need what I call Local AP in the taxonomy recommendations draft. However, most "CAPWAP-like" deployments out there really don't fall under the category you mention - all ACs are located topologically near the the WTPs, and in such cases having the data path centralized allows a powerful AC to perform many policy, security and mobility related functions that would be hard to do on a standalone WTP (but by being centralized allows for these functions to execute even across mobility events). Just using one example, what if NAT were to be provided on the WTP, how could the network converge in understanding what flows are active, and the related port mapping? Hence my recommendation for Split and Local AP - where the former tunnels the data to the AC and the latter does not. The customer can use one or the other, mostly based on topological requirements. 2. Single point of failure. I've addressed this in prior e-mails, and the LWAPP protocol addresses this. Further, if a WTP relies on an AC, you have a point of failure regardless. So this needs to be addressed in a protocol, and it's not just the data path that's at stake here. I realize we're not in complete agreement on this topic yet, but I still do believe that reducing the options is a feature, not a bug.=20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) > Sent: Monday, June 20, 2005 11:43 PM > To: James Kempf; Pat Calhoun; capwap@frascone.com > Subject: RE: [Capwap] Taxonomy Recommendations >=20 > Jak >=20 > The main reason I see to bridge frames at the WTP is to keep session's > shortest path (diminish delay, latency, jitter, etc., for real-time=20 > application such as VoWLAN). For example: > AC at NYC and WTP located at London; London office has two or three=20 > legs to the external world: (a) VPN/FR/Lease line to NYC main office,=20 > (b) local PSTN link and (c) local Internet service / exist to local=20 > ISP. Wi-Fi voice call from London office better not be traveled via=20 > NYC if not absolutely necessary. >=20 > AC as a single point of failure is another point. Sustain existing=20 > Wi-Fi sessions while AC experience failure or experience network=20 > outage between WTP and AC. >=20 > These are my points, other may have different view which is perfectly=20 > fine. Different architectures address different environments and=20 > different solutions. Just because a vendor can't figure out how=20 > another may solve a perceived problem doesn't mean it can't be done=20 > nor is it relevant to CAPWAP. >=20 > I believe the group need to come up with a mechanism / process of how=20 > to decide on labor division. Only two distinctive options, Split and=20 > Local, is a bit too restricted. >=20 > If I am not mistake there were four objectives which ignite > CAPWAP: (a) AP is an IP-addressable device requiring management,=20 > monitoring, and control (b) Distributing and maintaining a consistent=20 > configuration, (c) Difficulty in dealing effectively with the dynamic=20 > nature of large WLAN and > (d) Securing access to the network and preventing installation of=20 > unauthorized AP. >=20 > CAPWAP is about Control and Provisioning. It says nothing about the=20 > user's data frames path. > One more point, it's not mandatory that AC will be a dedicated HW=20 > appliance. It could be a piece of software runs on any platform. > Overwhelming the AC with user's data implicitly dictates the former. >=20 > It should be the other way around - one should come with a very good=20 > reason to execute bridging at the AC. In my opinion the protocol shell > facilitate both, letting the operator the freedom to chose. > To name a few reasons to consider bridging at the AC: > 1. Statistics: AC can extract raw statistics / info from > 802.11 frames. > 2. Apply policy at the AC rather then at the WTP - simpler WTP. > 3. If AC is a Layer 3 roaming facilitator. > 4. If AC implements 802.11 encryption / decryption. >=20 > (apologize, it turn out the answer is a bit too long that I > expected) Emek >=20 > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Monday, June 20, 2005 8:22 PM > To: Sadot, Emek (Emek); Pat Calhoun; capwap@frascone.com > Subject: Re: [Capwap] Taxonomy Recommendations >=20 > Emek, >=20 > Take for example the IS service: where it fits in Slit and Local - WTP > or AC? I would disagree the authors conclusion (section 5 first=20 > bullet) w.r.t. bridging function, and believes we can, and should,=20 > allow the operator to chose. >=20 > jak>> OK, so what criteria would cause an operator to choose > bridging at >=20 > jak>> the > WTP versus bridging at the AC? >=20 > jak >=20 >=20 >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Jun 28 10:48:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnHNp-0006GF-KJ for capwap-archive@megatron.ietf.org; Tue, 28 Jun 2005 10:48:17 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16121 for ; Tue, 28 Jun 2005 10:48:15 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B1924204CF; Tue, 28 Jun 2005 10:48:14 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ABEDF204A9; Tue, 28 Jun 2005 10:48:11 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1D0EE204A9; Tue, 28 Jun 2005 10:47:12 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 1CBB520492; Tue, 28 Jun 2005 10:47:09 -0400 (EDT) Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5SEZ3AK008354; Tue, 28 Jun 2005 10:35:04 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j5SEYwAK008204; Tue, 28 Jun 2005 10:34:58 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Protocol draft updates received Message-ID: Thread-Topic: [Capwap] Protocol draft updates received Thread-Index: AcV7LBCitzXP6teRQjSguNxwU9dH7AAGnQQgACo6SmA= From: "Mani, Mahalingam (Mahalingam)" To: Cc: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 28 Jun 2005 08:46:30 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable CTP self-evaluation revision has been submitted 6/27 (and will soon show up in repository and www.capwap.org). With this - we may have a complete set of baselined protocol drafts and self-eval drafts for evaluation already under way. -mani =3D=3D=3D=3D=3D=3D -----Original Message----- From: Mani, Mahalingam (Mahalingam)=20 Sent: Monday, June 27, 2005 12:35 PM To: Mani, Mahalingam (Mahalingam); capwap@frascone.com Subject: RE: [Capwap] Protocol draft updates received Importance: High CTP has also submitted a revision on 6/24. the updated link (to the updated version will appear) soon on the webpage (http://www.capwap.org/DraftsForEvaluation/) indicated below. -mani =3D=3D=3D=3D=3D=3D -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Mani, Mahalingam (Mahalingam) Sent: Monday, June 27, 2005 8:23 AM To: capwap@frascone.com Subject: [Capwap] Protocol draft updates received Importance: High LWAPP draft updates - protocol and comparison - (received Friday 6/24 by IETF) have also been posted in www.capwap.org. They should soon appear in the IETF repository. All baselined protocol drafts can now be referenced from http://www.capwap.org/DraftsForEvaluation/ Any communications/questions to CAPWAP evaluation team may be sent to capwap-et@frascone.com (this email list is used by evaluation team to get evaluation work done). This (archived) list is not open for subscription. However, the archive will be available for viewing after evaluation phase. The proposed evaluation schedule will be posted later today. Regards, -mani & Dorothy =3D=3D=3D=3D=3D=3D _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Jun 28 18:12:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnOJY-00084b-7p for capwap-archive@megatron.ietf.org; Tue, 28 Jun 2005 18:12:25 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03122 for ; Tue, 28 Jun 2005 18:12:15 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7AC0D204A9; Tue, 28 Jun 2005 18:12:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1A6DE20438; Tue, 28 Jun 2005 18:12:09 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7C53620438 for ; Tue, 28 Jun 2005 18:11:30 -0400 (EDT) Received: from cubert.e-centre.net (morbo.e-centre.net [66.154.82.3]) by mail.frascone.com (Postfix) with ESMTP id B66DC202CA for ; Tue, 28 Jun 2005 18:11:28 -0400 (EDT) Received: from [10.3.1.19] (helo=guestrelay.stayonline.net) by cubert.e-centre.net with esmtp (Exim 4.50) id 1DnOIc-0003A2-2j; Tue, 28 Jun 2005 18:11:22 -0400 Received: from et-dca-3.site.stayonline.net (unknown [67.151.170.141]) by guestrelay.stayonline.net (Spam Firewall) with ESMTP id 14738200631B; Tue, 28 Jun 2005 18:11:17 -0400 (EDT) Received: from pacalhouwxp ([172.16.1.142]) by et-dca-3.site.stayonline.net (8.12.6/8.12.6) with ESMTP id j5SMAmI1001246; Tue, 28 Jun 2005 22:11:02 GMT Message-Id: <200506282211.j5SMAmI1001246@et-dca-3.site.stayonline.net> From: "Pat Calhoun" To: "'Sadot, Emek (Emek)'" , "'James Kempf'" , Subject: RE: [Capwap] Taxonomy Recommendations MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcV1vHEWo3ZDaar6RKy3OD8Tu9s2AQAKAKyQACImhqABTc6IoAAXNcaA In-Reply-To: <5844A41F4E146044A2E8356C6328588008EF8577@nj7460avexu2.global.avaya.com> X-Virus-Scanned: by Barracuda Spam Firewall at stayonline.net X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 28 Jun 2005 15:10:56 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit One question I do have for you is that if your vision of the CAPWAP protocol is really a negotiation of various features allowing for any permutation, then why is our definition binary (meaning split vs. local). In your mind what consistutes a split vs local architecture, and why do we need two modes of operation vs one mode that can negotiate a number of configuration parameters. WRT the NAT text, I was trying (unsuccessfully) to provide an example where centralization of services makes sense. The example here was NAT. Imagine if NAT was implemented on every WTP. As you know, a NAT keeps track of all flows for an individual user, and when a mobility event occurs, the flow state would have to be transferred from one WTP to another - a difficult problem to resolve. Hence such advanced services are natural ones to be centralized in the AC. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Sadot, Emek (Emek) [mailto:esadot@avaya.com] > Sent: Monday, June 27, 2005 11:15 PM > To: Pat Calhoun; James Kempf; capwap@frascone.com > Subject: RE: [Capwap] Taxonomy Recommendations > > Pat, > > We will just have to agree to disagree on whether or not the > CAPWAP protocol should serve as a platform for > more-then-just-two distinct architectures. > > I fail to see the NAT problem you described. > > Regards, > Emek > > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun > Sent: Tuesday, June 21, 2005 5:34 PM > To: Sadot, Emek (Emek); 'James Kempf'; capwap@frascone.com > Subject: RE: [Capwap] Taxonomy Recommendations > > Emek, > > I'd like to address the two main points you've made in your e-mail. > > 1. Keep the data path short. I agree that there are some > challenges when an AC is situated very far from the WTP, and > that's the exact reason why one does need what I call Local > AP in the taxonomy recommendations draft. > However, most "CAPWAP-like" deployments out there really > don't fall under the category you mention - all ACs are > located topologically near the the WTPs, and in such cases > having the data path centralized allows a powerful AC to > perform many policy, security and mobility related functions > that would be hard to do on a standalone WTP (but by being > centralized allows for these functions to execute even across > mobility events). Just using one example, what if NAT were to > be provided on the WTP, how could the network converge in > understanding what flows are active, and the related port > mapping? Hence my recommendation for Split and Local AP - > where the former tunnels the data to the AC and the latter > does not. The customer can use one or the other, mostly based > on topological requirements. > 2. Single point of failure. I've addressed this in prior > e-mails, and the LWAPP protocol addresses this. Further, if a > WTP relies on an AC, you have a point of failure regardless. > So this needs to be addressed in a protocol, and it's not > just the data path that's at stake here. > > I realize we're not in complete agreement on this topic yet, > but I still do believe that reducing the options is a > feature, not a bug. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > -----Original Message----- > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) > > Sent: Monday, June 20, 2005 11:43 PM > > To: James Kempf; Pat Calhoun; capwap@frascone.com > > Subject: RE: [Capwap] Taxonomy Recommendations > > > > Jak > > > > The main reason I see to bridge frames at the WTP is to > keep session's > > > shortest path (diminish delay, latency, jitter, etc., for real-time > > application such as VoWLAN). For example: > > AC at NYC and WTP located at London; London office has two or three > > legs to the external world: (a) VPN/FR/Lease line to NYC > main office, > > (b) local PSTN link and (c) local Internet service / exist to local > > ISP. Wi-Fi voice call from London office better not be traveled via > > NYC if not absolutely necessary. > > > > AC as a single point of failure is another point. Sustain existing > > Wi-Fi sessions while AC experience failure or experience network > > outage between WTP and AC. > > > > These are my points, other may have different view which is > perfectly > > fine. Different architectures address different environments and > > different solutions. Just because a vendor can't figure out how > > another may solve a perceived problem doesn't mean it can't be done > > nor is it relevant to CAPWAP. > > > > I believe the group need to come up with a mechanism / > process of how > > to decide on labor division. Only two distinctive options, > Split and > > Local, is a bit too restricted. > > > > If I am not mistake there were four objectives which ignite > > CAPWAP: (a) AP is an IP-addressable device requiring management, > > monitoring, and control (b) Distributing and maintaining a > consistent > > configuration, (c) Difficulty in dealing effectively with > the dynamic > > nature of large WLAN and > > (d) Securing access to the network and preventing installation of > > unauthorized AP. > > > > CAPWAP is about Control and Provisioning. It says nothing about the > > user's data frames path. > > One more point, it's not mandatory that AC will be a dedicated HW > > appliance. It could be a piece of software runs on any platform. > > Overwhelming the AC with user's data implicitly dictates the former. > > > > It should be the other way around - one should come with a > very good > > reason to execute bridging at the AC. In my opinion the > protocol shell > > > facilitate both, letting the operator the freedom to chose. > > To name a few reasons to consider bridging at the AC: > > 1. Statistics: AC can extract raw statistics / info from > > 802.11 frames. > > 2. Apply policy at the AC rather then at the WTP - simpler WTP. > > 3. If AC is a Layer 3 roaming facilitator. > > 4. If AC implements 802.11 encryption / decryption. > > > > (apologize, it turn out the answer is a bit too long that I > > expected) Emek > > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Monday, June 20, 2005 8:22 PM > > To: Sadot, Emek (Emek); Pat Calhoun; capwap@frascone.com > > Subject: Re: [Capwap] Taxonomy Recommendations > > > > Emek, > > > > Take for example the IS service: where it fits in Slit and > Local - WTP > > > or AC? I would disagree the authors conclusion (section 5 first > > bullet) w.r.t. bridging function, and believes we can, and should, > > allow the operator to chose. > > > > jak>> OK, so what criteria would cause an operator to choose > > bridging at > > > > jak>> the > > WTP versus bridging at the AC? > > > > jak > > > > > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Jun 28 19:15:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnPIS-0001DB-Ul for capwap-archive@megatron.ietf.org; Tue, 28 Jun 2005 19:15:21 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08780 for ; Tue, 28 Jun 2005 19:15:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6889820370; Tue, 28 Jun 2005 19:15:13 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 655C31FE03; Tue, 28 Jun 2005 19:15:09 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8EA261FE03 for ; Tue, 28 Jun 2005 19:14:50 -0400 (EDT) Received: from smtp4.centerbeam.com (smtp4.centerbeam.com [63.120.115.248]) by mail.frascone.com (Postfix) with ESMTP id 764101FC1D for ; Tue, 28 Jun 2005 19:14:47 -0400 (EDT) Received: from cba0e2k00.CBA0.centerbeam.com ([64.95.101.25]) by smtp4.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Jun 2005 16:16:28 -0700 Received: from CBA0E2K06.CBA0.centerbeam.com ([64.95.101.40]) by cba0e2k00.CBA0.centerbeam.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 28 Jun 2005 16:14:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Taxonomy Recommendations Message-ID: Thread-Topic: [Capwap] Taxonomy Recommendations Thread-Index: AcV1vHEWo3ZDaar6RKy3OD8Tu9s2AQAKAKyQACImhqABTc6IoAAXNcaAAAw/aUA= From: "Darren Loher" To: "Pat Calhoun" , "Sadot, Emek (Emek)" , "James Kempf" , X-OriginalArrivalTime: 28 Jun 2005 23:14:30.0490 (UTC) FILETIME=[232993A0:01C57C37] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 28 Jun 2005 16:14:28 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Although certain implementations may constrain which tunneling options are available depending on split or local MAC, I don't think we have to assume this in the capwap protocol. =20 As James Kempf pointed out: jak>> So it seems you are proposing to separate the control and data=20 jak>> plane, and then some way in the control protocol to negotiate how=20 jak>> the data plane is handled? Is that correct? After James pointed it out I understood better what Emek is looking for. I think this is a great idea. We already have consensus that the CAPWAP protocol must support the ability to split user data from control and management data. This split is meant to enable flexibility on how user traffic is terminated onto the wired network. The CAPWAP protocol should not tightly associate the permutations of how traffic can be split in the different architectures. CAPWAP should allow an AC to configure a WTP to: - bridge 802.11 data traffic locally at the WTP - tunnel 802.11 data traffic to the AC And independently the AC should be able to configure a WTP to: - terminate & process 802.11 control and mgmt traffic locally - tunnel 802.11 control and mgmt traffic to the AC However, I also propose that an implementor should be given the option to create a solution which only supports a subset of the possible permutations of user and control traffic separation. To support this flexibility, the WTP could advertise its tunneling capabilities. =20 -Darren > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Pat Calhoun > Sent: Tuesday, June 28, 2005 4:11 PM > To: 'Sadot, Emek (Emek)'; 'James Kempf'; capwap@frascone.com > Subject: RE: [Capwap] Taxonomy Recommendations >=20 > One question I do have for you is that if your vision of the CAPWAP > protocol > is really a negotiation of various features allowing for any permutation, > then why is our definition binary (meaning split vs. local). In your mind > what consistutes a split vs local architecture, and why do we need two > modes > of operation vs one mode that can negotiate a number of configuration > parameters. >=20 > WRT the NAT text, I was trying (unsuccessfully) to provide an example > where > centralization of services makes sense. The example here was NAT. Imagine > if > NAT was implemented on every WTP. As you know, a NAT keeps track of all > flows for an individual user, and when a mobility event occurs, the flow > state would have to be transferred from one WTP to another - a difficult > problem to resolve. Hence such advanced services are natural ones to be > centralized in the AC. >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems >=20 >=20 >=20 > > -----Original Message----- > > From: Sadot, Emek (Emek) [mailto:esadot@avaya.com] > > Sent: Monday, June 27, 2005 11:15 PM > > To: Pat Calhoun; James Kempf; capwap@frascone.com > > Subject: RE: [Capwap] Taxonomy Recommendations > > > > Pat, > > > > We will just have to agree to disagree on whether or not the > > CAPWAP protocol should serve as a platform for > > more-then-just-two distinct architectures. > > > > I fail to see the NAT problem you described. > > > > Regards, > > Emek > > > > -----Original Message----- > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun > > Sent: Tuesday, June 21, 2005 5:34 PM > > To: Sadot, Emek (Emek); 'James Kempf'; capwap@frascone.com > > Subject: RE: [Capwap] Taxonomy Recommendations > > > > Emek, > > > > I'd like to address the two main points you've made in your e-mail. > > > > 1. Keep the data path short. I agree that there are some > > challenges when an AC is situated very far from the WTP, and > > that's the exact reason why one does need what I call Local > > AP in the taxonomy recommendations draft. > > However, most "CAPWAP-like" deployments out there really > > don't fall under the category you mention - all ACs are > > located topologically near the the WTPs, and in such cases > > having the data path centralized allows a powerful AC to > > perform many policy, security and mobility related functions > > that would be hard to do on a standalone WTP (but by being > > centralized allows for these functions to execute even across > > mobility events). Just using one example, what if NAT were to > > be provided on the WTP, how could the network converge in > > understanding what flows are active, and the related port > > mapping? Hence my recommendation for Split and Local AP - > > where the former tunnels the data to the AC and the latter > > does not. The customer can use one or the other, mostly based > > on topological requirements. > > 2. Single point of failure. I've addressed this in prior > > e-mails, and the LWAPP protocol addresses this. Further, if a > > WTP relies on an AC, you have a point of failure regardless. > > So this needs to be addressed in a protocol, and it's not > > just the data path that's at stake here. > > > > I realize we're not in complete agreement on this topic yet, > > but I still do believe that reducing the options is a > > feature, not a bug. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > -----Original Message----- > > > From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) > > > Sent: Monday, June 20, 2005 11:43 PM > > > To: James Kempf; Pat Calhoun; capwap@frascone.com > > > Subject: RE: [Capwap] Taxonomy Recommendations > > > > > > Jak > > > > > > The main reason I see to bridge frames at the WTP is to > > keep session's > > > > > shortest path (diminish delay, latency, jitter, etc., for real-time > > > application such as VoWLAN). For example: > > > AC at NYC and WTP located at London; London office has two or three > > > legs to the external world: (a) VPN/FR/Lease line to NYC > > main office, > > > (b) local PSTN link and (c) local Internet service / exist to local > > > ISP. Wi-Fi voice call from London office better not be traveled via > > > NYC if not absolutely necessary. > > > > > > AC as a single point of failure is another point. Sustain existing > > > Wi-Fi sessions while AC experience failure or experience network > > > outage between WTP and AC. > > > > > > These are my points, other may have different view which is > > perfectly > > > fine. Different architectures address different environments and > > > different solutions. Just because a vendor can't figure out how > > > another may solve a perceived problem doesn't mean it can't be done > > > nor is it relevant to CAPWAP. > > > > > > I believe the group need to come up with a mechanism / > > process of how > > > to decide on labor division. Only two distinctive options, > > Split and > > > Local, is a bit too restricted. > > > > > > If I am not mistake there were four objectives which ignite > > > CAPWAP: (a) AP is an IP-addressable device requiring management, > > > monitoring, and control (b) Distributing and maintaining a > > consistent > > > configuration, (c) Difficulty in dealing effectively with > > the dynamic > > > nature of large WLAN and > > > (d) Securing access to the network and preventing installation of > > > unauthorized AP. > > > > > > CAPWAP is about Control and Provisioning. It says nothing about the > > > user's data frames path. > > > One more point, it's not mandatory that AC will be a dedicated HW > > > appliance. It could be a piece of software runs on any platform. > > > Overwhelming the AC with user's data implicitly dictates the former. > > > > > > It should be the other way around - one should come with a > > very good > > > reason to execute bridging at the AC. In my opinion the > > protocol shell > > > > > facilitate both, letting the operator the freedom to chose. > > > To name a few reasons to consider bridging at the AC: > > > 1. Statistics: AC can extract raw statistics / info from > > > 802.11 frames. > > > 2. Apply policy at the AC rather then at the WTP - simpler WTP. > > > 3. If AC is a Layer 3 roaming facilitator. > > > 4. If AC implements 802.11 encryption / decryption. > > > > > > (apologize, it turn out the answer is a bit too long that I > > > expected) Emek > > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: Monday, June 20, 2005 8:22 PM > > > To: Sadot, Emek (Emek); Pat Calhoun; capwap@frascone.com > > > Subject: Re: [Capwap] Taxonomy Recommendations > > > > > > Emek, > > > > > > Take for example the IS service: where it fits in Slit and > > Local - WTP > > > > > or AC? I would disagree the authors conclusion (section 5 first > > > bullet) w.r.t. bridging function, and believes we can, and should, > > > allow the operator to chose. > > > > > > jak>> OK, so what criteria would cause an operator to choose > > > bridging at > > > > > > jak>> the > > > WTP versus bridging at the AC? > > > > > > jak > > > > > > > > > > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Jun 28 22:07:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnRyt-0002ix-HK for capwap-archive@megatron.ietf.org; Tue, 28 Jun 2005 22:07:15 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22917 for ; Tue, 28 Jun 2005 22:07:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E751B1FC1D; Tue, 28 Jun 2005 22:07:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9FD222043A; Tue, 28 Jun 2005 22:07:09 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 366192043A for ; Tue, 28 Jun 2005 22:06:28 -0400 (EDT) Received: from smtp2.mei.co.jp (smtp2.mei.co.jp [133.183.129.27]) by mail.frascone.com (Postfix) with ESMTP id D39E01FC1D for ; Tue, 28 Jun 2005 22:06:26 -0400 (EDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id j5T26NpU013236 for ; Wed, 29 Jun 2005 11:06:23 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id j5T26OB06633 for ; Wed, 29 Jun 2005 11:06:24 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with ESMTP id j5T26No07372 for ; Wed, 29 Jun 2005 11:06:23 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <5F09D220B62F79418461A978CA0921BD36AE5B@pslexc01.psl.local> Thread-Topic: WiCoP Update Thread-Index: AcV8Ts/uJItczwwVQpuHyGf8V9Bbpw== From: "Saravanan Govindan" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] WiCoP Update Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 29 Jun 2005 10:03:58 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Dear All, We submitted revisions to WiCoP - a first revision on Friday and a second on Monday. Both drafts are available;=20 http://www.psl.com.sg/internet-drafts/draft-iino-capwap-wicop-01.txt http://www.psl.com.sg/internet-drafts/draft-iino-capwap-wicop-02.txt Saravanan _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Jun 28 22:14:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnS5h-00054E-TM for capwap-archive@megatron.ietf.org; Tue, 28 Jun 2005 22:14:17 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23345 for ; Tue, 28 Jun 2005 22:14:15 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 31E94204B7; Tue, 28 Jun 2005 22:14:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7675F20484; Tue, 28 Jun 2005 22:14:09 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 998E420484 for ; Tue, 28 Jun 2005 22:13:12 -0400 (EDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.frascone.com (Postfix) with ESMTP id 991811FC1D for ; Tue, 28 Jun 2005 22:13:09 -0400 (EDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 28 Jun 2005 19:13:09 -0700 X-IronPort-AV: i="3.93,240,1115017200"; d="scan'208"; a="646185612:sNHT26820380" Received: from pacalhouwxp (sjc-vpn2-171.cisco.com [10.21.112.171]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5T2D3od013639; Tue, 28 Jun 2005 19:13:03 -0700 (PDT) Message-Id: <200506290213.j5T2D3od013639@sj-core-2.cisco.com> From: "Pat Calhoun" To: "'Saravanan Govindan'" , Subject: RE: [Capwap] WiCoP Update MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcV8Ts/uJItczwwVQpuHyGf8V9BbpwAATSLg In-Reply-To: <5F09D220B62F79418461A978CA0921BD36AE5B@pslexc01.psl.local> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 28 Jun 2005 19:13:07 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I thought the rules were such that Friday was the deadline. In any case, since I just reviewed the whole -01 version today, could you send a list of changes? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan > Sent: Tuesday, June 28, 2005 7:04 PM > To: capwap@frascone.com > Subject: [Capwap] WiCoP Update > > Dear All, > > We submitted revisions to WiCoP - a first revision on Friday > and a second on Monday. Both drafts are available; > > http://www.psl.com.sg/internet-drafts/draft-iino-capwap-wicop-01.txt > > http://www.psl.com.sg/internet-drafts/draft-iino-capwap-wicop-02.txt > > > Saravanan > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Jun 28 22:44:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnSYg-0004ig-FL for capwap-archive@megatron.ietf.org; Tue, 28 Jun 2005 22:44:15 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24706 for ; Tue, 28 Jun 2005 22:44:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DB344204B2; Tue, 28 Jun 2005 22:44:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4419C2043A; Tue, 28 Jun 2005 22:44:09 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BB2032043A for ; Tue, 28 Jun 2005 22:43:25 -0400 (EDT) Received: from smtp2.mei.co.jp (smtp2.mei.co.jp [133.183.129.27]) by mail.frascone.com (Postfix) with ESMTP id 8FCFC1FC1D for ; Tue, 28 Jun 2005 22:43:22 -0400 (EDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id j5T2h9pU019430; Wed, 29 Jun 2005 11:43:09 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id j5T2hBc08148; Wed, 29 Jun 2005 11:43:11 +0900 (JST) Received: from pslexc01.psl.local ([127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with ESMTP id j5T2hBw29145; Wed, 29 Jun 2005 11:43:11 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Capwap] WiCoP Update Message-ID: <5F09D220B62F79418461A978CA0921BD36AE7D@pslexc01.psl.local> Thread-Topic: [Capwap] WiCoP Update Thread-Index: AcV8Ts/uJItczwwVQpuHyGf8V9BbpwAATSLgAADS/aA= From: "Saravanan Govindan" To: "Pat Calhoun" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 29 Jun 2005 10:40:46 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Pat, WiCoP-02 simply corrects an error in Figure 10 of WiCoP-01.=20 In -01, Figure 10 incorrectly shows the Terminal receiving GTK and PTK. The Terminal should correctly receive just the GTK. This is the sole correction in -02. Saravanan > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@cisco.com]=20 > Sent: Wednesday, June 29, 2005 10:13 AM > To: Saravanan Govindan; capwap@frascone.com > Subject: RE: [Capwap] WiCoP Update >=20 > I thought the rules were such that Friday was the deadline. >=20 > In any case, since I just reviewed the whole -01 version=20 > today, could you send a list of changes? >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems >=20 > =20 >=20 > > -----Original Message----- > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan > > Sent: Tuesday, June 28, 2005 7:04 PM > > To: capwap@frascone.com > > Subject: [Capwap] WiCoP Update > >=20 > > Dear All, > >=20 > > We submitted revisions to WiCoP - a first revision on Friday and a=20 > > second on Monday. Both drafts are available; > >=20 > > http://www.psl.com.sg/internet-drafts/draft-iino-capwap-wicop-01.txt > >=20 > > http://www.psl.com.sg/internet-drafts/draft-iino-capwap-wicop-02.txt > >=20 > >=20 > > Saravanan > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Jun 28 22:49:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnSdY-0005ry-Gs for capwap-archive@megatron.ietf.org; Tue, 28 Jun 2005 22:49:16 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24947 for ; Tue, 28 Jun 2005 22:49:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3F5FE204B7; Tue, 28 Jun 2005 22:49:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7B9752043A; Tue, 28 Jun 2005 22:49:09 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5DD7F2043A for ; Tue, 28 Jun 2005 22:48:21 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 700E11FC1D for ; Tue, 28 Jun 2005 22:48:18 -0400 (EDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 28 Jun 2005 19:48:18 -0700 X-IronPort-AV: i="3.93,240,1115017200"; d="scan'208"; a="284058863:sNHT27511048" Received: from pacalhouwxp (sjc-vpn2-171.cisco.com [10.21.112.171]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5T2mFod025982; Tue, 28 Jun 2005 19:48:15 -0700 (PDT) Message-Id: <200506290248.j5T2mFod025982@sj-core-2.cisco.com> From: "Pat Calhoun" To: "'Saravanan Govindan'" , Subject: RE: [Capwap] WiCoP Update MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcV8Ts/uJItczwwVQpuHyGf8V9BbpwAATSLgAADS/aAAAGrcEA== In-Reply-To: <5F09D220B62F79418461A978CA0921BD36AE7D@pslexc01.psl.local> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 28 Jun 2005 19:48:16 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Oh - thanks much! Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan > Sent: Tuesday, June 28, 2005 7:41 PM > To: Pat Calhoun; capwap@frascone.com > Subject: RE: [Capwap] WiCoP Update > > Pat, > > WiCoP-02 simply corrects an error in Figure 10 of WiCoP-01. > > In -01, Figure 10 incorrectly shows the Terminal receiving > GTK and PTK. > The Terminal should correctly receive just the GTK. This is > the sole correction in -02. > > Saravanan > > > > > -----Original Message----- > > From: Pat Calhoun [mailto:pcalhoun@cisco.com] > > Sent: Wednesday, June 29, 2005 10:13 AM > > To: Saravanan Govindan; capwap@frascone.com > > Subject: RE: [Capwap] WiCoP Update > > > > I thought the rules were such that Friday was the deadline. > > > > In any case, since I just reviewed the whole -01 version > today, could > > you send a list of changes? > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan > > > Sent: Tuesday, June 28, 2005 7:04 PM > > > To: capwap@frascone.com > > > Subject: [Capwap] WiCoP Update > > > > > > Dear All, > > > > > > We submitted revisions to WiCoP - a first revision on > Friday and a > > > second on Monday. Both drafts are available; > > > > > > > http://www.psl.com.sg/internet-drafts/draft-iino-capwap-wicop-01.txt > > > > > > > http://www.psl.com.sg/internet-drafts/draft-iino-capwap-wicop-02.txt > > > > > > > > > Saravanan > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 29 11:21:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DneNI-0005gi-4b for capwap-archive@megatron.ietf.org; Wed, 29 Jun 2005 11:21:16 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01260 for ; Wed, 29 Jun 2005 11:21:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ECE71204FA; Wed, 29 Jun 2005 11:21:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 10EEE204EA; Wed, 29 Jun 2005 11:21:10 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B3CCB204EA for ; Wed, 29 Jun 2005 11:20:36 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id A083E204DB for ; Wed, 29 Jun 2005 11:20:32 -0400 (EDT) Message-ID: <06b701c57cbe$45867f80$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Darren Loher" , "Pat Calhoun" , "Sadot, Emek (Emek)" , References: Subject: Re: [Capwap] Taxonomy Recommendations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 29 Jun 2005 08:21:49 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Darren, While I think this may be an attractive idea, I think we need to consider the impact on other requirements. As pointed out by Pat, there may be some impact on handover performance. If the data plane is constrained to run through the AC, the AC needs only rewrite a few fields in an in-memory record in order to move link routing from one AP to another. The control interface between the AC and the distribution function in essentially an API> If the data plane is not so constrained, is a requirement for an additional protocol interface between the AC and the WTP. This may end up slowing handover. These issues could become clearer if there were a mapping of functional architecture to a few network reference architectures, in which the interfaces between functional elements were classified as either interior to network entities (i.e. an API) or between them (i.e. a protocol). In addition, last year someone, I think Dan, brought up the issue of additional complexity. If the AC supports both options, then the AC and WTP must negotiate the tunnel protocol (or not, if the WTP is performing distribution). This makes the protocol more complex. So the result is that there may be some tradeoffs in the objectives, in which some conflict, and I think prioritization may be necessary. jak ----- Original Message ----- From: "Darren Loher" To: "Pat Calhoun" ; "Sadot, Emek (Emek)" ; "James Kempf" ; Sent: Tuesday, June 28, 2005 4:14 PM Subject: RE: [Capwap] Taxonomy Recommendations Although certain implementations may constrain which tunneling options are available depending on split or local MAC, I don't think we have to assume this in the capwap protocol. As James Kempf pointed out: jak>> So it seems you are proposing to separate the control and data jak>> plane, and then some way in the control protocol to negotiate how jak>> the data plane is handled? Is that correct? After James pointed it out I understood better what Emek is looking for. I think this is a great idea. We already have consensus that the CAPWAP protocol must support the ability to split user data from control and management data. This split is meant to enable flexibility on how user traffic is terminated onto the wired network. The CAPWAP protocol should not tightly associate the permutations of how traffic can be split in the different architectures. CAPWAP should allow an AC to configure a WTP to: - bridge 802.11 data traffic locally at the WTP - tunnel 802.11 data traffic to the AC And independently the AC should be able to configure a WTP to: - terminate & process 802.11 control and mgmt traffic locally - tunnel 802.11 control and mgmt traffic to the AC However, I also propose that an implementor should be given the option to create a solution which only supports a subset of the possible permutations of user and control traffic separation. To support this flexibility, the WTP could advertise its tunneling capabilities. -Darren > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Pat Calhoun > Sent: Tuesday, June 28, 2005 4:11 PM > To: 'Sadot, Emek (Emek)'; 'James Kempf'; capwap@frascone.com > Subject: RE: [Capwap] Taxonomy Recommendations > > One question I do have for you is that if your vision of the CAPWAP > protocol > is really a negotiation of various features allowing for any permutation, > then why is our definition binary (meaning split vs. local). In your mind > what consistutes a split vs local architecture, and why do we need two > modes > of operation vs one mode that can negotiate a number of configuration > parameters. > > WRT the NAT text, I was trying (unsuccessfully) to provide an example > where > centralization of services makes sense. The example here was NAT. Imagine > if > NAT was implemented on every WTP. As you know, a NAT keeps track of all > flows for an individual user, and when a mobility event occurs, the flow > state would have to be transferred from one WTP to another - a difficult > problem to resolve. Hence such advanced services are natural ones to be > centralized in the AC. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Sadot, Emek (Emek) [mailto:esadot@avaya.com] > > Sent: Monday, June 27, 2005 11:15 PM > > To: Pat Calhoun; James Kempf; capwap@frascone.com > > Subject: RE: [Capwap] Taxonomy Recommendations > > > > Pat, > > > > We will just have to agree to disagree on whether or not the > > CAPWAP protocol should serve as a platform for > > more-then-just-two distinct architectures. > > > > I fail to see the NAT problem you described. > > > > Regards, > > Emek > > > > -----Original Message----- > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun > > Sent: Tuesday, June 21, 2005 5:34 PM > > To: Sadot, Emek (Emek); 'James Kempf'; capwap@frascone.com > > Subject: RE: [Capwap] Taxonomy Recommendations > > > > Emek, > > > > I'd like to address the two main points you've made in your e-mail. > > > > 1. Keep the data path short. I agree that there are some > > challenges when an AC is situated very far from the WTP, and > > that's the exact reason why one does need what I call Local > > AP in the taxonomy recommendations draft. > > However, most "CAPWAP-like" deployments out there really > > don't fall under the category you mention - all ACs are > > located topologically near the the WTPs, and in such cases > > having the data path centralized allows a powerful AC to > > perform many policy, security and mobility related functions > > that would be hard to do on a standalone WTP (but by being > > centralized allows for these functions to execute even across > > mobility events). Just using one example, what if NAT were to > > be provided on the WTP, how could the network converge in > > understanding what flows are active, and the related port > > mapping? Hence my recommendation for Split and Local AP - > > where the former tunnels the data to the AC and the latter > > does not. The customer can use one or the other, mostly based > > on topological requirements. > > 2. Single point of failure. I've addressed this in prior > > e-mails, and the LWAPP protocol addresses this. Further, if a > > WTP relies on an AC, you have a point of failure regardless. > > So this needs to be addressed in a protocol, and it's not > > just the data path that's at stake here. > > > > I realize we're not in complete agreement on this topic yet, > > but I still do believe that reducing the options is a > > feature, not a bug. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > -----Original Message----- > > > From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) > > > Sent: Monday, June 20, 2005 11:43 PM > > > To: James Kempf; Pat Calhoun; capwap@frascone.com > > > Subject: RE: [Capwap] Taxonomy Recommendations > > > > > > Jak > > > > > > The main reason I see to bridge frames at the WTP is to > > keep session's > > > > > shortest path (diminish delay, latency, jitter, etc., for real-time > > > application such as VoWLAN). For example: > > > AC at NYC and WTP located at London; London office has two or three > > > legs to the external world: (a) VPN/FR/Lease line to NYC > > main office, > > > (b) local PSTN link and (c) local Internet service / exist to local > > > ISP. Wi-Fi voice call from London office better not be traveled via > > > NYC if not absolutely necessary. > > > > > > AC as a single point of failure is another point. Sustain existing > > > Wi-Fi sessions while AC experience failure or experience network > > > outage between WTP and AC. > > > > > > These are my points, other may have different view which is > > perfectly > > > fine. Different architectures address different environments and > > > different solutions. Just because a vendor can't figure out how > > > another may solve a perceived problem doesn't mean it can't be done > > > nor is it relevant to CAPWAP. > > > > > > I believe the group need to come up with a mechanism / > > process of how > > > to decide on labor division. Only two distinctive options, > > Split and > > > Local, is a bit too restricted. > > > > > > If I am not mistake there were four objectives which ignite > > > CAPWAP: (a) AP is an IP-addressable device requiring management, > > > monitoring, and control (b) Distributing and maintaining a > > consistent > > > configuration, (c) Difficulty in dealing effectively with > > the dynamic > > > nature of large WLAN and > > > (d) Securing access to the network and preventing installation of > > > unauthorized AP. > > > > > > CAPWAP is about Control and Provisioning. It says nothing about the > > > user's data frames path. > > > One more point, it's not mandatory that AC will be a dedicated HW > > > appliance. It could be a piece of software runs on any platform. > > > Overwhelming the AC with user's data implicitly dictates the former. > > > > > > It should be the other way around - one should come with a > > very good > > > reason to execute bridging at the AC. In my opinion the > > protocol shell > > > > > facilitate both, letting the operator the freedom to chose. > > > To name a few reasons to consider bridging at the AC: > > > 1. Statistics: AC can extract raw statistics / info from > > > 802.11 frames. > > > 2. Apply policy at the AC rather then at the WTP - simpler WTP. > > > 3. If AC is a Layer 3 roaming facilitator. > > > 4. If AC implements 802.11 encryption / decryption. > > > > > > (apologize, it turn out the answer is a bit too long that I > > > expected) Emek > > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: Monday, June 20, 2005 8:22 PM > > > To: Sadot, Emek (Emek); Pat Calhoun; capwap@frascone.com > > > Subject: Re: [Capwap] Taxonomy Recommendations > > > > > > Emek, > > > > > > Take for example the IS service: where it fits in Slit and > > Local - WTP > > > > > or AC? I would disagree the authors conclusion (section 5 first > > > bullet) w.r.t. bridging function, and believes we can, and should, > > > allow the operator to chose. > > > > > > jak>> OK, so what criteria would cause an operator to choose > > > bridging at > > > > > > jak>> the > > > WTP versus bridging at the AC? > > > > > > jak > > > > > > > > > > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Jun 29 19:01:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnlYf-000657-94 for capwap-archive@megatron.ietf.org; Wed, 29 Jun 2005 19:01:36 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08091 for ; Wed, 29 Jun 2005 19:01:25 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D8FE12050E; Wed, 29 Jun 2005 19:01:25 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 04FBA20501; Wed, 29 Jun 2005 19:01:21 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 811C2204F3 for ; Wed, 29 Jun 2005 19:00:39 -0400 (EDT) Received: from smtp4.centerbeam.com (smtp4.centerbeam.com [63.120.115.248]) by mail.frascone.com (Postfix) with ESMTP id 36E9320444 for ; Wed, 29 Jun 2005 19:00:36 -0400 (EDT) Received: from CBA0E2K01.CBA0.centerbeam.com ([64.95.101.24]) by smtp4.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 29 Jun 2005 16:02:20 -0700 Received: from CBA0E2K06.CBA0.centerbeam.com ([64.95.101.40]) by CBA0E2K01.CBA0.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 29 Jun 2005 16:00:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: Negotiation for tunneling of user traffic (was: Taxonomy Recommendations) Thread-Index: AcV8vh5EeqbLdRW5QaCa9GfVpDLefwAJucBA From: "Darren Loher" To: "James Kempf" , "Pat Calhoun" , "Sadot, Emek (Emek)" , , X-OriginalArrivalTime: 29 Jun 2005 23:00:23.0908 (UTC) FILETIME=[54F92A40:01C57CFE] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Negotiation for tunneling of user traffic (was: Taxonomy Recommendations) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 29 Jun 2005 16:00:21 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi James, I think the only way to avoid negotiation of where data is terminated is if a CAPWAP protocol only supported one method of data termination. (only terminated at the AC or only terminated at the WTP). Certainly that solution is simple, but it would not meet the traffic separation objective which explicitly states a motivation to allow alternatives to the WTP tunneling data back to the AC. =20 I am not sure I can think of a way this can be done without somehow negotiating tunneling of data. However, how one solves for this does not have to be extremely complex. I'll use the SLAPP and CTP submissions as examples. SLAPP now has 5 WTP "mode" options. Tunneling performed based on which WTP "mode" is used. The available modes are advertised by a WTP and the AC "picks" which one is to be used. This effectively negotiates weather or not user data is tunneled to the AC based on the definitions of the 5 defined SLAPP modes. That is just one way to do it. CTP claims support of local MAC and split MAC modes independent of where user data is terminated. In addition, CTP defines its data message as optional. (so one does not have to implement a WTP with support for tunneling user data) I am not sure how CTP actually negotiates where user data is terminated though. (perhaps in a separate thread the CTP authors could help me understand how this is handled in CTP?) -Darren > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Wednesday, June 29, 2005 9:22 AM > To: Darren Loher; Pat Calhoun; Sadot, Emek (Emek); capwap@frascone.com > Subject: [SUSPECT] Re: [Capwap] Taxonomy Recommendations >=20 > Darren, >=20 > While I think this may be an attractive idea, I think we need to consider > the impact on other requirements. As pointed out by Pat, there may be some > impact on handover performance. If the data plane is constrained to run > through the AC, the AC needs only rewrite a few fields in an in-memory > record in order to move link routing from one AP to another. The control > interface between the AC and the distribution function in essentially an > API> If the data plane is not so constrained, is a requirement for an > additional protocol interface between the AC and the WTP. This may end up > slowing handover. These issues could become clearer if there were a > mapping > of functional architecture to a few network reference architectures, in > which the interfaces between functional elements were classified as either > interior to network entities (i.e. an API) or between them (i.e. a > protocol). >=20 > In addition, last year someone, I think Dan, brought up the issue of > additional complexity. If the AC supports both options, then the AC and > WTP > must negotiate the tunnel protocol (or not, if the WTP is performing > distribution). This makes the protocol more complex. >=20 > So the result is that there may be some tradeoffs in the objectives, in > which some conflict, and I think prioritization may be necessary. >=20 > jak >=20 >=20 > ----- Original Message ----- > From: "Darren Loher" > To: "Pat Calhoun" ; "Sadot, Emek (Emek)" > ; "James Kempf" ; > > Sent: Tuesday, June 28, 2005 4:14 PM > Subject: RE: [Capwap] Taxonomy Recommendations >=20 >=20 > Although certain implementations may constrain which tunneling options > are available depending on split or local MAC, I don't think we have to > assume this in the capwap protocol. >=20 > As James Kempf pointed out: > jak>> So it seems you are proposing to separate the control and data > jak>> plane, and then some way in the control protocol to negotiate how > jak>> the data plane is handled? Is that correct? >=20 > After James pointed it out I understood better what Emek is looking for. > I think this is a great idea. >=20 > We already have consensus that the CAPWAP protocol must support the > ability to split user data from control and management data. This split > is meant to enable flexibility on how user traffic is terminated onto > the wired network. The CAPWAP protocol should not tightly associate the > permutations of how traffic can be split in the different architectures. >=20 >=20 > CAPWAP should allow an AC to configure a WTP to: > - bridge 802.11 data traffic locally at the WTP > - tunnel 802.11 data traffic to the AC > And independently the AC should be able to configure a WTP to: > - terminate & process 802.11 control and mgmt traffic locally > - tunnel 802.11 control and mgmt traffic to the AC >=20 > However, I also propose that an implementor should be given the option > to create a solution which only supports a subset of the possible > permutations of user and control traffic separation. To support this > flexibility, the WTP could advertise its tunneling capabilities. >=20 > -Darren >=20 >=20 >=20 > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > > Behalf Of Pat Calhoun > > Sent: Tuesday, June 28, 2005 4:11 PM > > To: 'Sadot, Emek (Emek)'; 'James Kempf'; capwap@frascone.com > > Subject: RE: [Capwap] Taxonomy Recommendations > > > > One question I do have for you is that if your vision of the CAPWAP > > protocol > > is really a negotiation of various features allowing for any > permutation, > > then why is our definition binary (meaning split vs. local). In your > mind > > what consistutes a split vs local architecture, and why do we need two > > modes > > of operation vs one mode that can negotiate a number of configuration > > parameters. > > > > WRT the NAT text, I was trying (unsuccessfully) to provide an example > > where > > centralization of services makes sense. The example here was NAT. > Imagine > > if > > NAT was implemented on every WTP. As you know, a NAT keeps track of > all > > flows for an individual user, and when a mobility event occurs, the > flow > > state would have to be transferred from one WTP to another - a > difficult > > problem to resolve. Hence such advanced services are natural ones to > be > > centralized in the AC. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > > > > -----Original Message----- > > > From: Sadot, Emek (Emek) [mailto:esadot@avaya.com] > > > Sent: Monday, June 27, 2005 11:15 PM > > > To: Pat Calhoun; James Kempf; capwap@frascone.com > > > Subject: RE: [Capwap] Taxonomy Recommendations > > > > > > Pat, > > > > > > We will just have to agree to disagree on whether or not the > > > CAPWAP protocol should serve as a platform for > > > more-then-just-two distinct architectures. > > > > > > I fail to see the NAT problem you described. > > > > > > Regards, > > > Emek > > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun > > > Sent: Tuesday, June 21, 2005 5:34 PM > > > To: Sadot, Emek (Emek); 'James Kempf'; capwap@frascone.com > > > Subject: RE: [Capwap] Taxonomy Recommendations > > > > > > Emek, > > > > > > I'd like to address the two main points you've made in your e-mail. > > > > > > 1. Keep the data path short. I agree that there are some > > > challenges when an AC is situated very far from the WTP, and > > > that's the exact reason why one does need what I call Local > > > AP in the taxonomy recommendations draft. > > > However, most "CAPWAP-like" deployments out there really > > > don't fall under the category you mention - all ACs are > > > located topologically near the the WTPs, and in such cases > > > having the data path centralized allows a powerful AC to > > > perform many policy, security and mobility related functions > > > that would be hard to do on a standalone WTP (but by being > > > centralized allows for these functions to execute even across > > > mobility events). Just using one example, what if NAT were to > > > be provided on the WTP, how could the network converge in > > > understanding what flows are active, and the related port > > > mapping? Hence my recommendation for Split and Local AP - > > > where the former tunnels the data to the AC and the latter > > > does not. The customer can use one or the other, mostly based > > > on topological requirements. > > > 2. Single point of failure. I've addressed this in prior > > > e-mails, and the LWAPP protocol addresses this. Further, if a > > > WTP relies on an AC, you have a point of failure regardless. > > > So this needs to be addressed in a protocol, and it's not > > > just the data path that's at stake here. > > > > > > I realize we're not in complete agreement on this topic yet, > > > but I still do believe that reducing the options is a > > > feature, not a bug. > > > > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit > > > Cisco Systems > > > > -----Original Message----- > > > > From: capwap-admin@frascone.com > > > > [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) > > > > Sent: Monday, June 20, 2005 11:43 PM > > > > To: James Kempf; Pat Calhoun; capwap@frascone.com > > > > Subject: RE: [Capwap] Taxonomy Recommendations > > > > > > > > Jak > > > > > > > > The main reason I see to bridge frames at the WTP is to > > > keep session's > > > > > > > shortest path (diminish delay, latency, jitter, etc., for > real-time > > > > application such as VoWLAN). For example: > > > > AC at NYC and WTP located at London; London office has two or > three > > > > legs to the external world: (a) VPN/FR/Lease line to NYC > > > main office, > > > > (b) local PSTN link and (c) local Internet service / exist to > local > > > > ISP. Wi-Fi voice call from London office better not be traveled > via > > > > NYC if not absolutely necessary. > > > > > > > > AC as a single point of failure is another point. Sustain existing > > > > Wi-Fi sessions while AC experience failure or experience network > > > > outage between WTP and AC. > > > > > > > > These are my points, other may have different view which is > > > perfectly > > > > fine. Different architectures address different environments and > > > > different solutions. Just because a vendor can't figure out how > > > > another may solve a perceived problem doesn't mean it can't be > done > > > > nor is it relevant to CAPWAP. > > > > > > > > I believe the group need to come up with a mechanism / > > > process of how > > > > to decide on labor division. Only two distinctive options, > > > Split and > > > > Local, is a bit too restricted. > > > > > > > > If I am not mistake there were four objectives which ignite > > > > CAPWAP: (a) AP is an IP-addressable device requiring management, > > > > monitoring, and control (b) Distributing and maintaining a > > > consistent > > > > configuration, (c) Difficulty in dealing effectively with > > > the dynamic > > > > nature of large WLAN and > > > > (d) Securing access to the network and preventing installation of > > > > unauthorized AP. > > > > > > > > CAPWAP is about Control and Provisioning. It says nothing about > the > > > > user's data frames path. > > > > One more point, it's not mandatory that AC will be a dedicated HW > > > > appliance. It could be a piece of software runs on any platform. > > > > Overwhelming the AC with user's data implicitly dictates the > former. > > > > > > > > It should be the other way around - one should come with a > > > very good > > > > reason to execute bridging at the AC. In my opinion the > > > protocol shell > > > > > > > facilitate both, letting the operator the freedom to chose. > > > > To name a few reasons to consider bridging at the AC: > > > > 1. Statistics: AC can extract raw statistics / info from > > > > 802.11 frames. > > > > 2. Apply policy at the AC rather then at the WTP - simpler WTP. > > > > 3. If AC is a Layer 3 roaming facilitator. > > > > 4. If AC implements 802.11 encryption / decryption. > > > > > > > > (apologize, it turn out the answer is a bit too long that I > > > > expected) Emek > > > > > > > > -----Original Message----- > > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > > Sent: Monday, June 20, 2005 8:22 PM > > > > To: Sadot, Emek (Emek); Pat Calhoun; capwap@frascone.com > > > > Subject: Re: [Capwap] Taxonomy Recommendations > > > > > > > > Emek, > > > > > > > > Take for example the IS service: where it fits in Slit and > > > Local - WTP > > > > > > > or AC? I would disagree the authors conclusion (section 5 first > > > > bullet) w.r.t. bridging function, and believes we can, and should, > > > > allow the operator to chose. > > > > > > > > jak>> OK, so what criteria would cause an operator to choose > > > > bridging at > > > > > > > > jak>> the > > > > WTP versus bridging at the AC? > > > > > > > > jak > > > > > > > > > > > > > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jun 30 10:13:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnzn8-0008Gj-F8 for capwap-archive@megatron.ietf.org; Thu, 30 Jun 2005 10:13:22 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15803 for ; Thu, 30 Jun 2005 10:13:19 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D515C2048A; Thu, 30 Jun 2005 10:13:14 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 346CE2037B; Thu, 30 Jun 2005 10:13:11 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 94ACE2037B for ; Thu, 30 Jun 2005 10:12:54 -0400 (EDT) Received: from typhoon.trangosoft.com (unknown [209.82.51.154]) by mail.frascone.com (Postfix) with ESMTP id 49C2C20254 for ; Thu, 30 Jun 2005 10:12:51 -0400 (EDT) Received: from phantom-out.trangosoft.com ([136.157.233.22]) by 136.157.233.32 with trend_isnt_name_B; Thu, 30 Jun 2005 10:10:22 -0400 Received: from troll3.trangosoft.com (troll3.trangosoft.com [136.157.233.13]) by phantom-out.trangosoft.com (Postfix) with ESMTP id 57C0224FFA; Thu, 30 Jun 2005 09:45:59 -0400 (EDT) Received: by troll3.trangosoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Jun 2005 10:04:38 -0400 Message-ID: <1652EBA28502ED4393B9BC9B8A4B60131A3B20@mism121a.toronto.chantrynetworks.com> From: Michael Montemurro To: Darren Loher , James Kempf , Pat Calhoun , "Sadot, Emek (Emek)" , capwap@frascone.com, isingh@chantrynetworks.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Negotiation of user data Termination Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 30 Jun 2005 10:08:41 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Darren, In the CTP protocol, the WTP advertises its user data termination (WTP or AC) capabilities to the AC during the connection process. The AC can configure the user data termination mode (local or AC) at the WTP on a logical network basis. For example, in a branch environment, you could configure a WTP to advertise a network that is bridged locally to the LAN and a separate logical network that is tunnelled back through the WAN to the AC. The data termination mode negotiation is described in version 02 of the draft. Cheers, Mike _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap
From: capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Darren=20 Loher
Sent: Thursday, June 16, 2005 4:45 PM
To: = Inderpreet=20 Singh; Sadot, Emek (Emek); capwap@frascone.com
Subject: RE: = [Capwap]=20 Support for Traffic Separation

Given the following=20 scenarios:

 

 1) Split=20 MAC - Bridge at WTP 

 2) Split=20 MAC - Bridge at AC

 3) Local=20 MAC - Bridge at WTP

 4) = Local MAC -=20 Bridge at AC

 

I agree = that #2-4 are=20 required scenarios.  I am not sure that #1 is required.  If = “bridge”=20 means the IS function, #1 would be in conflict with the recent error=20 correction/update of the taxonomy = document.

 

When the IS = function=20 is implemented at the WTP, the WTP must be a local MAC WTP.  = However, in=20 a local MAC scenario the CAPWAP protocol must still permit tunneling = or not=20 tunneling user traffic to an AC.  A particular WTP device may not = support=20 this function, but the CAPWAP protocol MUST allow it (IMHO).  = This would=20 be compatible with the new update/error correction to the taxonomy = document=20 and gives flexibility for implementers to create traffic separation if = they=20 choose in split and local MAC modes.

 

What does = everyone=20 think? (did I miss anything?)

 

-Darren

 

 

From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Inderpreet = Singh
Sent: Thursday, June 16, 2005 = 4:02=20 PM
To: Sadot, Emek = (Emek);=20 capwap@frascone.com
Subject:=20 RE: [Capwap] Support for Traffic = Separation

 

 

>>"Further, one must assume that = there are=20 functions that reside in the AC that are much more than=20

>>just = "tunnel=20 termination", and if this is the case these functions are lost when=20 you resort to bridge

>>mode." - I = assume you=20 meant that some functionality will be lost if bridging is=20 implemented at the WTP,

>>so if = that's your=20 argument then the counter argument would be: how these=20 functions being materialized

>>in Local = MAc=20 arch?

 

If I am not = mistaken,=20 this discussion has let to two interpretations of the word = “bridging” as=20 well.

 

  1. Emek understands = bridging as=20 802.11 to 802.3 conversion.  Which is technically correct, but = really=20 confined definition in our context.  I think it would be useful = to term=20 in 802.11 MAC termination rather than simply=20 bridging.=20
  2. Pat, Mike and I = believe that=20 bridging in this context has to do with bridging the user traffic to = the=20 local physical interface.  Usually this is Ethernet in the WTP=20 case.  Non-bridging would be where the traffic is tunneled to = the=20 AC.

 

So I agree, = if you=20 bridge locally (ie. if the 802.11 MAC is terminated Locally and then = the=20 resulting 802.3 packets are bridged to the local physical interface), = then it=20 is possible for example to lose the functionality of L3 roaming of the = client.  However, in certain scenarios of deployments where this=20 function/feature is not needed, local bridging is quite=20 useful.

 

Thanks

 

Inderpreet

 

From: Pat=20 Calhoun [mailto:pcalhoun@cisco.com]
Sent: Thursday, June 16, 2005 = 5:25=20 PM
To: Sadot, Emek = (Emek);=20 'Michael Montemurro'; capwap@frascone.com
Subject: RE: [Capwap] Support = for Traffic=20 Separation

>=20 Giving the = operator /=20 customer the freedom to run the IS function in AC or WTP is = important and=20 as far as I can tell doesn't

> break = the CAPWAP=20 model. Why it's important: well take #1 for example, if customer=20 wishes to session to travel along =

> = the shorter=20 path between peers, or maintain existing voice = call when AC=20 experience a failover and perform reboot (but new=20

>=20 session or roaming obviously)."

 

Emek, I = don't see how=20 this can be achieved. A user's end device has a single IP address. One = really=20 cannot split the forwarding of user traffic based on the relative = priority of=20 the traffic or based on network failures, because the return path of = the=20 user's traffic would always end up on its home subnet. The above = suggestion=20 where sometimes the user's traffic is briged and sometimes it is = tunneled,=20 would REQUIRE the WTP and the AC to be on the same subnet - which = conflicts=20 with the "Interconnection Objective". Further, one must assume that = there are=20 functions that reside in the AC that are much more than just "tunnel=20 termination", and if this is the case these functions are lost when=20 you resort to brige mode.

 

If=20 redundancy/resiliency is required, then it must be provided in the = CAPWAP=20 protocol through some other means.

 

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

 

 

From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] = On Behalf Of Sadot, Emek=20 (Emek)
Sent: = Thursday, June=20 16, 2005 5:54 AM
To:=20 Michael Montemurro; Pat Calhoun; capwap@frascone.com
Subject: RE: [Capwap] Support = for=20 Traffic Separation

Mike,

 

To make = sure I am=20 clear: by "bridge" I was referring to the Integration = Services -=20  bridging between 802.11 and = 802.3.

All=20 management frames (security, QoS, etc.) should be handle by the = AC.

 

Giving = the operator=20 / customer the freedom to run the IS function in AC or WTP is = important=20 and as far as I can tell doesn't break the CAPWAP=20 model.

Why it's = important:=20 well take #1 for example, if customer wishes to session=20 to travel along the shorter path between peers,=20 or maintain existing voice call when AC experience a = failover=20 and perform reboot (but new session or roaming=20 obviously).

 

Emek

 

From:=20 Michael Montemurro [mailto:michael.montemurro@siemens.com] =
Sent: Thursday, June 16, 2005 = 3:35=20 PM
To: Sadot, = Emek (Emek);=20 Pat Calhoun; capwap@frascone.com
Subject: RE: [Capwap] Support = for=20 Traffic Separation

Emek,

 

I just = want to get=20 clarification on your response. You believe there are four=20 possibilities:

 

    1) Split = MAC -=20 Bridge at WTP

    2) Split = MAC -=20 Bridge at AC

    3) Local = MAC -=20 Bridge at WTP

    4) = Local MAC=20 - Bridge at AC

 

I'd just = like to=20 understand how you envision case 1).  What type of = functionality would=20 you envision would terminate at the AC? Could you be more specific = on how=20 you would handle WLAN management frames, security, and QoS in that=20 case?

 

Thanks,

 

    Mike

 

Michael=20 Montemurro
Director, Advanced Technology and Standards
Chantry = Networks, A Siemens Company
1900 Minnesota Ct, Suite=20 125
Mississauga, ON,=20 CANADA.
T:=20 905-363-6413
F: 905-567-9900
E: michael.montemurro@siemens.com =