From diameter-admin@frascone.com Sun Aug 1 05:27:49 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05380 for ; Sun, 1 Aug 2004 05:27:49 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2C0652147E for ; Sun, 1 Aug 2004 05:13:18 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 74A9421B62 for ; Sun, 1 Aug 2004 05:10:27 -0400 (EDT) Date: Sun, 01 Aug 2004 05:10:27 -0400 Message-ID: <20040801091027.11301.6795.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 Mon Aug 2 00:19:39 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27693 for ; Mon, 2 Aug 2004 00:19:38 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4358C21B6D; Mon, 2 Aug 2004 00:05:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8A60121B68; Mon, 2 Aug 2004 00:05:02 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 957C721B68 for ; Mon, 2 Aug 2004 00:04:05 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id E509621B5C for ; Mon, 2 Aug 2004 00:04:03 -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 i724C5SG026487 for ; Sun, 1 Aug 2004 23:12:05 -0500 (EST) 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 i724C3SG026481 for ; Sun, 1 Aug 2004 23:12:04 -0500 (EST) 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.0.6487.1 Message-ID: Thread-Topic: Agenda for IETF'60, San Diego Thread-Index: AcR4R8P329GKj0MfST2qUV7CG4TNRA== From: "Mani, Mahalingam (Mahalingam)" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Agenda for IETF'60, San Diego 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, 1 Aug 2004 22:18:34 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi All, The following agenda is proposed for the meeting on Wednesday (8/4/04, 1-3pmPT) session: 1. Agenda Bashing - 5 min.=20 2. Status of the current drafts - 5 min 3. WG milestone Review - 5 min. 4. Revision Changes to Architecture Taxonomy draft (http://www.ietf.org/internet-drafts/draft-ietf-capwap-arch-03.txt) - 20 min. (Lily Yang)=20 5. IEEE IETF Liaison and Status of IEEE activities - (Dorothy Stanley/Bob O'Hara) - 20 min.=20 6. Next steps for WG - Dorothy Gellert & Mani=20 7. Open discussions on possible re-charter 8. CAPWAP classifications - Cheng Hong / Saravanan 15 min. (time-permitting) Any updates on available documents and/or links will be posted before the meeting - hopefully a day ahead. Regards, -mani _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Aug 2 22:55:46 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24251 for ; Mon, 2 Aug 2004 22:55:45 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4506B1FE9F; Mon, 2 Aug 2004 22:41:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 986CB21650; Mon, 2 Aug 2004 22:41:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3C7F121630; Mon, 2 Aug 2004 22:40:50 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id 6629D1FE9F; Mon, 2 Aug 2004 22:40:48 -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 i732rqGa008896; Mon, 2 Aug 2004 22:53:52 -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 i732rpGa008885; Mon, 2 Aug 2004 22:53:51 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C47905.5068D924" Message-ID: Thread-Topic: More IETF Expert Review on rev-03... Thread-Index: AcR5BU0STRrMZQoKRm2DRDNdIH/Qmg== From: "Mani, Mahalingam (Mahalingam)" To: , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] More IETF Expert Review on rev-03... 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, 2 Aug 2004 20:55:20 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C47905.5068D924 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 Russ Housley's review comments are inline (embedded marked with a leading [ on column 1) to the draft. =20 http://www.cs.ucla.edu/~pzerfos/draft-ietf-capwap-arch-03-comments.txt =20 (They will also be posted to www.capwap.org website in due course). =20 Since -04 has been posted to WG (but not yet sent in as I-D) we can anticipate another rev-05 to include addressing these. Nevertheless, do review -04 (and in the light of these comments as well). =20 Regards, -mani ------_=_NextPart_001_01C47905.5068D924 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

Russ Housley’s review comments are inline = (embedded marked with a leading [ on column 1) to the draft.

 

http://www.cs.ucla.edu/~pzerfos/draft-ietf-capwap-arch-03-comments= .txt

 

(They will also be posted to www.capwap.org website in due course).

 

Since -04 has been posted to WG (but not yet sent in = as I-D) we can anticipate another rev-05 to include addressing = these.

Nevertheless,  do review -04 (and in the light = of these comments as well).

 

Regards,

-mani

------_=_NextPart_001_01C47905.5068D924-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Aug 2 23:19:42 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25531 for ; Mon, 2 Aug 2004 23:19:40 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A9DDD21630; Mon, 2 Aug 2004 23:05:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C997021989; Mon, 2 Aug 2004 23:05:02 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3FC5721988 for ; Mon, 2 Aug 2004 23:04:08 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id 6C4E821630 for ; Mon, 2 Aug 2004 23:04:06 -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 i733HAGa002496 for ; Mon, 2 Aug 2004 23:17:11 -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 i733H9Ga002468 for ; Mon, 2 Aug 2004 23:17:09 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C47908.91B5DF32" Message-ID: Thread-Topic: Update: Agenda for IETF'60, San Diego Thread-Index: AcR5CI4pWhSLe6k2TZuhk39r2GhE5g== X-Priority: 1 Priority: Urgent Importance: high From: "Mani, Mahalingam (Mahalingam)" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Update: Agenda for IETF'60, San Diego 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, 2 Aug 2004 21:18:38 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C47908.91B5DF32 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The following is the updated agenda for the meeting on Wednesday (8/4/04, 1-3pmPT) session: =20 1. Agenda Bashing - 5 min.=20 2. Status of the current drafts - 5 min 3. WG milestone Review - 5 min. 4. Revision Changes to Architecture Taxonomy draft from (http://www.ietf.org/internet-drafts/draft-ietf-capwap-arch-03.txt) to rev-04 (posted to WG and www.capwap.org) - 20 min. (Lily Yang)=20 5. IEEE IETF Liaison and Status of IEEE activities: 10 min (Dorothy Stanley) 6. Next steps for WG: Dorothy Gellert & Mani (10-15 min.) 7. Open discussions on possible re-charter 8. CAPWAP classifications - Saravanan Govindan ~15 min. (time-permitting) =20 Regards, -mani =20 ------_=_NextPart_001_01C47908.91B5DF32 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The following is the updated agenda for the meeting on Wednesday (8/4/04,

1-3pmPT) session:

 

1. Agenda Bashing - 5 min.

2. Status of the current drafts -  5 = min

3. WG milestone Review - 5 min.

4. Revision Changes to Architecture Taxonomy draft = from

   (http://www.ietf.org/internet-drafts/draft-ietf-capwap-arch-03.txt)<= /o:p>

   to rev-04 (posted to WG and www.capwap.org) - 20 = min. (Lily Yang)

5. IEEE IETF Liaison and Status of IEEE activities: 10 = min

   (Dorothy Stanley)

6. Next steps for WG: Dorothy Gellert & Mani (10-15 = min.)

7. Open discussions on possible = re-charter

8. CAPWAP classifications -  Saravanan = Govindan ~15 min. (time-permitting)

 

Regards,

-mani

 

------_=_NextPart_001_01C47908.91B5DF32-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Aug 3 01:30:48 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02745 for ; Tue, 3 Aug 2004 01:30:47 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3E18321019; Tue, 3 Aug 2004 01:16:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D0710208D2; Tue, 3 Aug 2004 01:16:02 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5A735208D2 for ; Tue, 3 Aug 2004 01:15:05 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id 40E7620659 for ; Tue, 3 Aug 2004 01:15:03 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i735TZO00886; Tue, 3 Aug 2004 08:29:35 +0300 (EET DST) X-Scanned: Tue, 3 Aug 2004 08:28:26 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i735SQel014308; Tue, 3 Aug 2004 08:28:26 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00vkTbH7; Tue, 03 Aug 2004 08:28:24 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i735SNu29325; Tue, 3 Aug 2004 08:28:23 +0300 (EET DST) Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 3 Aug 2004 00:28:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: Thread-Topic: Re-charter proposal text to discuss at CAPWAP WG Mtg Thread-Index: AcR5Gq9hPOwLvxIFTdi5uQS3ZCqdgg== From: To: Cc: , , X-OriginalArrivalTime: 03 Aug 2004 05:28:22.0756 (UTC) FILETIME=[B1843A40:01C4791A] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Re-charter proposal text to discuss at CAPWAP WG Mtg 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, 2 Aug 2004 22:28:21 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Attached is the CAPWAP WG Re-charter proposal we will review on = Wednesday during the CAPWAP WG meeting. Please review and provide comments on the process going forward, = deliverables and timeline suggested. Most of the WG meeting is dedicated to open discussion on how to = re-charter, so bring your comments! -Dorothy and Mani _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Aug 3 01:32:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02779 for ; Tue, 3 Aug 2004 01:32:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E62FC20A21; Tue, 3 Aug 2004 01:17:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5FF5320659; Tue, 3 Aug 2004 01:17:02 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 481E32092A for ; Tue, 3 Aug 2004 01:16:43 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mail.frascone.com (Postfix) with ESMTP id 33EC020659 for ; Tue, 3 Aug 2004 01:16:41 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i735VEW06231; Tue, 3 Aug 2004 08:31:14 +0300 (EET DST) X-Scanned: Tue, 3 Aug 2004 08:29:11 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i735TBTv016754; Tue, 3 Aug 2004 08:29:11 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 0052R4p3; Tue, 03 Aug 2004 08:29:09 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i735T8u00104; Tue, 3 Aug 2004 08:29:08 +0300 (EET DST) Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 3 Aug 2004 00:29:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C4791A.CBF1B550" Message-ID: X-MS-Has-Attach: yes Thread-Topic: Re-charter proposal text to discuss at CAPWAP WG Mtg Thread-Index: AcR5Gq9hPOwLvxIFTdi5uQS3ZCqdggAAAgaQ From: To: , Cc: , , X-OriginalArrivalTime: 03 Aug 2004 05:29:07.0542 (UTC) FILETIME=[CC360760:01C4791A] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP WG Mtg 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, 2 Aug 2004 22:29:07 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C4791A.CBF1B550 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ok, This time with the attachment.... -Dorothy <>=20 > -----Original Message----- > From: Gellert Dorothy (Nokia-ES/MtView) =20 > Sent: Monday, August 02, 2004 10:28 PM > To: 'capwap@frascone.com' > Cc: Bert Wijnen (E-mail); Mani Mahalingam (E-mail); Kessens=20 > David (Nokia-NET/MtView) > Subject: Re-charter proposal text to discuss at CAPWAP WG Mtg >=20 >=20 > Attached is the CAPWAP WG Re-charter proposal we will review=20 > on Wednesday during the CAPWAP WG meeting. > Please review and provide comments on the process going=20 > forward, deliverables and timeline suggested. >=20 > Most of the WG meeting is dedicated to open discussion on how=20 > to re-charter, so bring your comments! >=20 > -Dorothy and Mani ------_=_NextPart_001_01C4791A.CBF1B550 Content-Type: text/plain; name="recharter for CAPWAP_06.txt" Content-Description: recharter for CAPWAP_06.txt Content-Disposition: attachment; filename="recharter for CAPWAP_06.txt" Content-Transfer-Encoding: base64 Q0FQV0FQIFdHIENoYXJ0ZXIgUHJvcG9zYWw6DQoNClRoZSBvcmlnaW5hbCBDQVBXQVAgV0cgY2hh cnRlciBpbmNsdWRlZCBkcmFmdGluZyBhIHByb2JsZW0gc3RhdGVtZW50IGFuZCBhIHRheG9ub215 IGFyY2hpdGVjdHVyZSBkb2N1bWVudC4gVGhlIG5ldyBjaGFydGVyIG9mIHRoZSBDQVBXQVAgV0cg cHJvcG9zZXMgYnVpbGRpbmcgdXBvbiB0aGUgb3JpZ2luYWwgY2hhcnRlciBhbmQgZGV2ZWxvcGlu ZyBhIENBUFdBUCBwcm90b2NvbCB0byBwcm92aWRlIGludGVyb3BlcmFiaWxpdHkgYW1vbmcgV0xB TiBjb250cm9sbGVyIGJhY2tlbmQgYXJjaGl0ZWN0dXJlcy4gDQoNClRoZSBQcmltYXJ5IG9iamVj dGl2ZXMgb2YgdGhlIGdyb3VwIHdpbGwgYmUgdG8gd29yayBvbjoNCg0KMS4gRGVmaW5pbmcgYSBz ZXQgb2YgT2JqZWN0aXZlcyBiYXNlZCBvbiB0aGUgYXJjaGl0ZWN0dXJlIHRheG9ub215IHdvcmsg dGhhdCBsaXN0cyB0aGUgcmVxdWlyZW1lbnRzIGZvciBhbiBpbnRlcm9wZXJhYmxlIENBUFdBUCBw cm90b2NvbC4gIEluIGFkZGl0aW9uLCB0aGUgT2JqZWN0aXZlcyBkb2N1bWVudCB3aWxsIGluY2x1 ZGUgaW5wdXRzIGZyb20gYSBjdXN0b21lcidzIHByZXNwZWN0aXZlIHRoYXQgbWF5IG5vdCBiZSBy ZXByZXNlbnRlZCBpbiB0aGUgYXJjaGl0ZWN0dXJlIHRheG9ub215IHdvcmsuICBUaGlzIGRvY3Vt ZW50IHdpbGw6DQoJYS4gQWRkcmVzcyB0aGUgcHJvYmxlbXMgc3RhdGVkIGluIHRoZSBDQVBXQVAg UHJvYmxlbSBzdGF0ZW1lbnQgZHJhZnQgIA0KCWIuIERlc2NyaWJlIGVhY2ggb2JqZWN0aXZlLCBp dHMgYmVuZWZpdCB0byB0aGUgcHJvdG9jb2wgYW5kIGhvdyBpdCBzYXRpc2ZpZXMgdGhlIHByb2Js ZW0gc3RhdGVtZW50Lg0KCWMuIFByaW9yaXRpemUgYW5kIGNsYXNzaWZ5IHRoZSBvYmplY3RpdmVz IGludG8gMyBjYXRlZ29yaWVzOg0KCQlpLiAgIE1hbmRhdG9yeSBhbmQgQWNjZXB0ZWQgDQoJCWlp LiAgRGVzaXJlYWJsZQ0KCQlpaWkuIFJlamVjdGVkDQoJZC4gVW5kZXJnbyByZXZpZXcgaW4gSUVF RSBhcyBuZWVkZWQuDQoNCjIuIEV2YWx1YXRpbmcgYSBzZXQgb2YgY2FuZGlkYXRlIHByb3Bvc2Fs cyB0aGF0IGluY2x1ZGUgZXhpc3RpbmcgSUVURiBwcm90b2NvbHMgYW5kIGFueSBwcm9wb3NhbHMg bGVhZGluZyB0byB0aGUgc2VsZWN0aW9uIG9mIGEgcHJvdG9jb2wgb24gd2hpY2ggdG8gYmFzZSB0 aGUgQ0FQV0FQIHN0YW5kYXJkLg0KDQozLiBEZXZlbG9waW5nIGEgQ0FQV0FQIHByb3RvY29sIHN0 YW5kYXJkIHRoYXQgbWVldHMgdGhlIE1hbmRhdG9yeSBhbmQgQWNjZXB0ZWQgb2JqZWN0aXZlcyBm cm9tIHRoZSBFdmFsdWF0aW9uIGRyYWZ0IGFuZCBjb250YWlucyB0aGUgbWluaW1hbCBzZXQgb2Yg ZmVhdHVyZSBuZWVkZWQgdG8gY29udHJvbCBhbmQgcHJvdmlzaW9uIFdMQU4gQWNjZXNzIFBvaW50 cy4gIFNwZWNpZmljYWxseSBUaGUgQ0FQV0FQIHByb3RvY29sIGRvY3VtZW50IHdpbGwgYWRkcmVz cyB0aGUgZm9sbG93aW5nIGNvbnNpZGVyYXRpb25zOg0KCWEuIEFyY2hpdGVjdHVyZQ0KCWIuIE9w ZXJhdGlvbnMNCgljLiBTZWN1cml0eQ0KCWQuIE5ldHdvcmsgTWFuYWdlbWVudCANCgllLiBTY2Fs YWJpbGl0eQ0KCWYuIFBlcmZvcm1hbmNlDQoNCjQuIE1JQnMgdG8gc3VwcG9ydCB0aGUgQ0FQV0FQ IHByb3RvY29sLg0KDQpJbiBhZGRpdGlvbiwgdGhlIENBUFdBUCBXRyB3aWxsIG1haW50YWluIGl0 cyBMaWFpc29uIHdpdGggdGhlIElFRUUgdG8gZW5zdXJlIGNvbnNpc3RlbmN5IG9mIGl0cyB3b3Jr IHdpdGggdGhlIElFRUUgODAyLjExIFN0YW5kYXJkLg0KDQpEZWxpdmVyYWJsZXM6DQoJKiBPYmpl Y3RpdmVzL0NyaXRlcmlhIERvY3VtZW50IGZvciBDQVBXQVAgcHJvdG9jb2wNCgkqIFByb3RvY29s IGV2YWx1YXRpb24gYW5kIGJhc2UgcHJvdG9jb2wgc2VsZWN0aW9uIGRvY3VtZW50DQoJKiBDQVBX QVAgUHJvdG9jb2wgc3RhbmRhcmQNCgkqIE1JQiBzdXBwb3J0IHN0YW5kYXJkDQoNCkdvYWxzIGFu ZCBNaWxlc3RvbmVzOg0KDQpPY3QgMDQ6IElzc3VlIGZpcnN0IEludGVybmV0LURyYWZ0IG9mIENB UFdBUCBPYmplY3RpdmVzIGRvY3VtZW50DQpKYW4gMDU6IENhbGwgZm9yIGNhbmRpZGF0ZSBwcm90 b2NvbCBwcm9wb3NhbHMNCkZlYiAwNTogU3VibWl0IENBUFdBUCBPYmplY3RpdmVzIHRvIElFRUUv SUVURiBleHBlcnRzIHJldmlldw0KQXByIDA1OiBJc3N1ZSBmaXJzdCBJbnRlcm5ldC1EcmFmdCBv ZiBDQVBXQVAgRXZhbHVhdGlvbiBkcmFmdA0KTWF5IDA1OiBXR0xDIGZvciBDQVBXQVAgT2JqZWN0 aXZlcyBEcmFmdA0KSnVuIDA1OiBTdWJtaXQgQ0FQV0FQIE9iamVjdGl2ZXMgZHJhZnQgdG8gSUVT RyBhcyBJbmZvcm1hdGlvbmFsIFJGQw0KSnVuIDA1OiBXR0xDIGZvciBDQVBXQVAgRXZhbHVhdGlv biBkcmFmdA0KSnVsIDA1OiBTdWJtaXQgQ0FQV0FQIEV2YWx1YXRpb24gZHJhZnQgdG8gSUVTRyBh cyBJbmZvcm1hdGlvbiBSRkMNCkF1ZyAwNTogSXNzdWUgZmlyc3QgSW50ZXJuZXQgRHJhZnQgb2Yg Q0FQV0FQIHByb3RvY29sIA0KU2VwIDA1OiBJc3N1ZSBmaXJzdCBJbnRlcm5ldC1EcmFmdCBvZiBD QVBXQVAgTUlCLg0KT2N0IDA1OiBXR0xDIGZvciBDQVBXQVAgcHJvdG9jb2wNCk5vdiAwNTogU3Vi bWl0IENBUFdBUCBwcm90b2NvbCB0byBJRVNHIGFzIFByb3Bvc2VkIFN0YW5kYXJkIFJGQw0KTm92 IDA1OiBXR0xDIGZvciBDQVBXQVAgTUlCDQpKYW4gMDY6IFN1Ym1pdCBDQVBXQVAgTUlCIHRvIElF U0cgYXMgUHJvcG9zZWQgU3RhbmRhcmQgUkZDDQoNCg0KDQo= ------_=_NextPart_001_01C4791A.CBF1B550-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Aug 3 12:09:41 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17897 for ; Tue, 3 Aug 2004 12:09:40 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E8DA41FC7B; Tue, 3 Aug 2004 11:55:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 78ADC20312; Tue, 3 Aug 2004 11:55:02 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 774B12008F for ; Tue, 3 Aug 2004 11:54:24 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id 9BD131FC7B for ; Tue, 3 Aug 2004 11:54:22 -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 i73G7QGa019436 for ; Tue, 3 Aug 2004 12:07:27 -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 i73G7DGa019125 for ; Tue, 3 Aug 2004 12:07:17 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C47974.2573278C" Message-ID: Thread-Topic: More IETF Expert Review on rev-03... Thread-Index: AcR5BU0STRrMZQoKRm2DRDNdIH/QmgAbsEUg From: "Mani, Mahalingam (Mahalingam)" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] FW: More IETF Expert Review on rev-03... 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, 3 Aug 2004 10:08:42 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C47974.2573278C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The previous send has bounced - trying again. -mani _____ =20 From: Mani, Mahalingam (Mahalingam)=20 Sent: Monday, August 02, 2004 7:55 PM To: capwap@frascone.com; 'capwap-dt@frascone.com' Subject: More IETF Expert Review on rev-03... =20 All, =20 Russ Housley's review comments are inline (embedded marked with a leading [ on column 1) to the draft. =20 http://www.cs.ucla.edu/~pzerfos/draft-ietf-capwap-arch-03-comments.txt =20 (They will also be posted to www.capwap.org website in due course). =20 Since -04 has been posted to WG (but not yet sent in as I-D) we can anticipate another rev-05 to include addressing these. Nevertheless, do review -04 (and in the light of these comments as well). =20 Regards, -mani ------_=_NextPart_001_01C47974.2573278C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The previous send has bounced = – trying again.

-mani

From: Mani, = Mahalingam (Mahalingam)
Sent: Monday, August 02, = 2004 7:55 PM
To: capwap@frascone.com; = 'capwap-dt@frascone.com'
Subject: More IETF Expert = Review on rev-03...

 

All,

 

Russ Housley’s review comments are inline = (embedded marked with a leading [ on column 1) to the = draft.

 

http://www.cs.ucla.edu/~pzerfos/draft-ietf-capwap-arch-03-comments= .txt

 

(They will also be posted to www.capwap.org website in due course).

 

Since -04 has been posted to WG (but not yet sent in = as I-D) we can anticipate another rev-05 to include addressing = these.

Nevertheless,  do review -04 (and in the light = of these comments as well).

 

Regards,

-mani

------_=_NextPart_001_01C47974.2573278C-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Aug 3 14:17:43 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28937 for ; Tue, 3 Aug 2004 14:17:42 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 407F3205BD; Tue, 3 Aug 2004 14:03:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F233A218DF; Tue, 3 Aug 2004 14:03:02 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AAA58205BD for ; Tue, 3 Aug 2004 14:02:12 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 8700E20482 for ; Tue, 3 Aug 2004 14:02:10 -0400 (EDT) Message-ID: <033c01c47986$23cad350$936015ac@dcml.docomolabsusa.com> From: "James Kempf" To: , Cc: , , References: Subject: Re: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP WG Mtg 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, 3 Aug 2004 11:17:26 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Dorothy, Thanx for sending out this proposal. I looked through part of the draft and the proposal, and I have a (somewhat long) comment on the suggested recharter. There is an assumption in the recharter that there will be a single CAPWAP protocol. From the taxonomy document (part of which I briefly skimmed), it looks to me like there are three basic architectural approaches currently in the market: 1) the traditional MAC architecture, 2) the SplitMAC architecture in which the WTPs only implement delay sensitive functions and the rest are implemented on the ACs, and 3) the RemoteMAC architecture, where all the MAC functions are implemented in the ACs. 1) seems to me like it would be pretty much out of scope for a recharter, since there is not any need for additional protocol work on an interoperable access network protocol in traditional APs (but perhaps I'm missing something) because APs from different vendors exist today that interoperate. 2) and 3), however, seem to be to be two separate and largely incompatible architectures that represent two classes of products which could benefit from having an interoperable protocol between products in the class, but probably wouldn't benefit much from interoperability between classes. In the cellular world, there are two similar classes of products used for, for example, UMTS deployment. The best known is the RNC/Node B/UTRAN solution which is similar to SplitMAC in which a network controller runs a protocol over the access network that controls radio access points, but there's another solution, similar to RemoteMAC, in which wCDMA runs over fiber from what is essentially just a smart antenna doing PHY to PHY conversion to the controller. This latter solution has benefits in certain deployment situations, but requires lots of bandwidth on the link between the smart antenna and the controller, which might not be available in many cases. As far as I know, the two are really for different incompatible deployment cases and don't interoperate on the access network between the base station/access point and the controller. I would imagine that there are likely to be incompatible deployment situations in the WLAN world that would benefit more from one or the other of these solutions too. I think the recharter discussion needs to make a decision first whether there is need for interoperability between these two classes of products, and, if not, whether there is a need for interoperable protocol work between products in the same class for both classes, or whether only the class with the most need for an interoperable protocol should be focussed on. I have some opinions about this, but I will wait until the discussion tomorrow to express them. In addition, I think the WG chairs need to talk with the IESG about the right Area for this work, should the IESG agree to a recharter, since the scope of a protocol development effort for an access network control protocol seems like it might get a bit outside the Ops Area charter. Personally, I have some doubts about whether a recharter will be approved, since there may be a significant component of work in actual protocol development that involves decisions about MAC level functions, but perhaps we can get enough IEEE involvement to allow the work to proceed in IETF. It's a tough problem organizationally, because the technology spans both groups. jak ----- Original Message ----- From: To: ; Cc: ; ; Sent: Monday, August 02, 2004 10:29 PM Subject: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP WG Mtg Ok, This time with the attachment.... -Dorothy <> > -----Original Message----- > From: Gellert Dorothy (Nokia-ES/MtView) > Sent: Monday, August 02, 2004 10:28 PM > To: 'capwap@frascone.com' > Cc: Bert Wijnen (E-mail); Mani Mahalingam (E-mail); Kessens > David (Nokia-NET/MtView) > Subject: Re-charter proposal text to discuss at CAPWAP WG Mtg > > > Attached is the CAPWAP WG Re-charter proposal we will review > on Wednesday during the CAPWAP WG meeting. > Please review and provide comments on the process going > forward, deliverables and timeline suggested. > > Most of the WG meeting is dedicated to open discussion on how > to re-charter, so bring your comments! > > -Dorothy and Mani _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Aug 3 16:14:51 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08464 for ; Tue, 3 Aug 2004 16:14:50 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7A3D6203FB; Tue, 3 Aug 2004 15:59:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 96FB42073D; Tue, 3 Aug 2004 15:59:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5F7A1203FB for ; Tue, 3 Aug 2004 15:58:09 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id F0A7B2027E for ; Tue, 3 Aug 2004 15:58:06 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i73KCek04708; Tue, 3 Aug 2004 23:12:40 +0300 (EET DST) X-Scanned: Tue, 3 Aug 2004 23:09:49 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i73K9n9l009437; Tue, 3 Aug 2004 23:09:49 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00bo3mLc; Tue, 03 Aug 2004 23:09:16 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i73K9Eu25347; Tue, 3 Aug 2004 23:09:14 +0300 (EET DST) Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 3 Aug 2004 15:08:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] RE: Re-charter proposal text to discuss at CAPWAP WG Mtg Message-ID: Thread-Topic: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP WG Mtg Thread-Index: AcR5hpnYvHeO7J2xRNmrHm8OWZaExQAC5eFg From: To: , Cc: , , X-OriginalArrivalTime: 03 Aug 2004 20:08:26.0299 (UTC) FILETIME=[A2E178B0:01C47995] 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, 3 Aug 2004 13:08:24 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi James- Good comments. You have been an great advisor to us since the BOF. Are = you available/interested to get more involved with CAPWAP over the next = year? It would be good to have your expertise in any way possible. Response in line. Thanks, Dorothy > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > Behalf Of ext James Kempf > Sent: Tuesday, August 03, 2004 11:17 AM > To: Gellert Dorothy (Nokia-ES/MtView); capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David > (Nokia-NET/MtView) > Subject: Re: [Capwap] RE: Re-charter proposal text to discuss=20 > at CAPWAP > WG Mtg >=20 >=20 > Dorothy, >=20 > Thanx for sending out this proposal. I looked through part of=20 > the draft and > the proposal, and I have a (somewhat long) comment on the suggested > recharter. >=20 > There is an assumption in the recharter that there will be a=20 > single CAPWAP True. I didn't explicitly call this out because I thought that the = Objective document would address which architecture approach(s) out of = the taxonomy document we would pursue. The Objective draft is based = off of the taxonomy work, so the analysis (and experience gained) in = that document would be of significant value. =20 In addition, the evaluation draft is also a place where we could stress = 2 approaches/protocols to the solution. =20 =20 > protocol. From the taxonomy document (part of which I briefly=20 > skimmed), it > looks to me like there are three basic architectural=20 > approaches currently in > the market: 1) the traditional MAC architecture, 2) the SplitMAC > architecture in which the WTPs only implement delay sensitive=20 > functions and > the rest are implemented on the ACs, and 3) the RemoteMAC=20 > architecture, > where all the MAC functions are implemented in the ACs. >=20 > 1) seems to me like it would be pretty much out of scope for=20 > a recharter, > since there is not any need for additional protocol work on=20 > an interoperable > access network protocol in traditional APs (but perhaps I'm missing > something) because APs from different vendors exist today that > interoperate. >=20 > 2) and 3), however, seem to be to be two separate and largely=20 > incompatible > architectures that represent two classes of products which=20 > could benefit > from having an interoperable protocol between products in the=20 > class, but > probably wouldn't benefit much from interoperability between classes. >=20 > In the cellular world, there are two similar classes of=20 > products used for, > for example, UMTS deployment. The best known is the RNC/Node B/UTRAN > solution which is similar to SplitMAC in which a network=20 > controller runs a > protocol over the access network that controls radio access=20 > points, but > there's another solution, similar to RemoteMAC, in which=20 > wCDMA runs over > fiber from what is essentially just a smart antenna doing PHY to PHY > conversion to the controller. This latter solution has=20 > benefits in certain > deployment situations, but requires lots of bandwidth on the=20 > link between > the smart antenna and the controller, which might not be=20 > available in many > cases. As far as I know, the two are really for different incompatible > deployment cases and don't interoperate on the access network=20 > between the > base station/access point and the controller. I'm familiar with the UMTS deployment scenario, since I've been involved = in CDMA. The RNC/PDSN architecture feels very similar to what we are = doing here, and I admit I use this experience in evaluating these = architectures. I'm not as familiar with wCDMA, but I would like to = hear more about this benefits of this, as I'm sure would the group. =20 Bernard Aboba has advised us also to stress performance criteria, so the = low/high bandwidth distinction makes sense. We have it as part of the = protocol, but it should also be called out in the Objectives phase. I = believe we should be aware of the applications expected to run over this = network to assure we don't create something that essentially prevents = VOIP or other bandwidth sensitive applications. >=20 > I would imagine that there are likely to be incompatible deployment > situations in the WLAN world that would benefit more from one=20 > or the other > of these solutions too. >=20 > I think the recharter discussion needs to make a decision=20 > first whether > there is need for interoperability between these two classes=20 > of products, > and, if not, whether there is a need for interoperable protocol work > between products in the same class for both classes, or=20 > whether only the > class with the most need for an interoperable protocol should=20 > be focussed > on. I have some opinions about this, but I will wait until=20 > the discussion > tomorrow to express them. >=20 > In addition, I think the WG chairs need to talk with the IESG=20 > about the > right Area for this work, should the IESG agree to a=20 > recharter, since the > scope of a protocol development effort for an access network control > protocol seems like it might get a bit outside the Ops Area charter. > Personally, I have some doubts about whether a recharter will=20 > be approved, > since there may be a significant component of work in actual protocol > development that involves decisions about MAC level=20 > functions, but perhaps > we can get enough IEEE involvement to allow the work to=20 > proceed in IETF. We did get the IEEE to charter a study group to define the AP functions = better so we can effective distribute them as necessary. I believe = Dorothy Stanley has been elected the chair of this group and she is also = our liaison. I think we have set a good foundation for success in = working out issues with the IEEE. This is still a new model of = cooperation between IETF and other SDOs, but I think the time is upon us = to work in collaboration with each other to meet the mobility demands of = the market. > It's a tough problem organizationally, because the technology=20 > spans both > groups. >=20 > jak >=20 > ----- Original Message -----=20 > From: > To: ; > Cc: ; ; > Sent: Monday, August 02, 2004 10:29 PM > Subject: [Capwap] RE: Re-charter proposal text to discuss at=20 > CAPWAP WG Mtg >=20 >=20 > Ok, This time with the attachment.... >=20 > -Dorothy >=20 > <> >=20 > > -----Original Message----- > > From: Gellert Dorothy (Nokia-ES/MtView) > > Sent: Monday, August 02, 2004 10:28 PM > > To: 'capwap@frascone.com' > > Cc: Bert Wijnen (E-mail); Mani Mahalingam (E-mail); Kessens > > David (Nokia-NET/MtView) > > Subject: Re-charter proposal text to discuss at CAPWAP WG Mtg > > > > > > Attached is the CAPWAP WG Re-charter proposal we will review > > on Wednesday during the CAPWAP WG meeting. > > Please review and provide comments on the process going > > forward, deliverables and timeline suggested. > > > > Most of the WG meeting is dedicated to open discussion on how > > to re-charter, so bring your comments! > > > > -Dorothy and Mani >=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 Tue Aug 3 16:33:42 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09737 for ; Tue, 3 Aug 2004 16:33:42 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 76364208B9; Tue, 3 Aug 2004 16:19:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E2E2221183; Tue, 3 Aug 2004 16:19:02 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DE46521183 for ; Tue, 3 Aug 2004 16:18:56 -0400 (EDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by mail.frascone.com (Postfix) with ESMTP id 0038E208B9 for ; Tue, 3 Aug 2004 16:18:55 -0400 (EDT) Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i73KXZGP022771; Tue, 3 Aug 2004 20:33:35 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i73KQmOj014946; Tue, 3 Aug 2004 20:26:58 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004080313314103409 ; Tue, 03 Aug 2004 13:31:41 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Aug 2004 13:31:41 -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] RE: Re-charter proposal text to discuss at CAPWAP WG Mtg Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE01B57A0B@orsmsx408> Thread-Topic: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP WG Mtg Thread-Index: AcR5hkD2micDRlBWT7iOTl5TG723UwAEFgwA From: "Yang, Lily L" To: "James Kempf" , , Cc: , , X-OriginalArrivalTime: 03 Aug 2004 20:31:41.0528 (UTC) FILETIME=[E2808580:01C47998] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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, 3 Aug 2004 13:31:38 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I agree that there is an important decision to be made when we recharter the group, to decide what kind of interoperability we want across what architecture variants.=20 But I believe James's summary of the architecture taxonomy is not completely correct. The taxonomy classified the existing/emerging architecture spectrum as the following: +----------------+ |Autonomous | +---------->|Architecture | | |Family | | +----------------+ | +--------------+ | |Local | | +---->|MAC | | | |Architecture | | | +--------------+ | | | +----------------+ | +--------------+ | |Centralized | | |Split | +---------->|Architecture |--+---->|MAC | | |Family | | |Architecture | | +----------------+ | +--------------+ | | | | +--------------+ | | |Remote | | +---->|MAC | | |Architecture | | +--------------+ | +----------------+ | |Distributed Mesh| +---------->|Architecture | |Family | +----------------+ So we have to explicitly decide what kind of interoperability we want to achieve in this picture. It seems like a relatively easier decision at the first level. Autonomous Architecture doesn't need any further protocol. One example of the Distributed Architecture -- 802.11 mesh -- is being developed by IEEE 802.11 TGs, and it is not yet clear how much of the control/config aspect will be included in that effort. Centralized architecture is where we hear the interoperability demand the most.=20 Now within the Centralized architecture, there is a harder question to answer: what kind of interoperability we want? Across all 3 sub-categories with one protocol? Does that make sense, eps. If different sub-category suits for different deployment scenarios? Is it technically feasible to have one fit all? Or is it acceptable to have only interoperability within each sub-category? Should this group work on all 3? Or 1? 2? One option for the WG is to only draw the scope boundary around Centralized Architecture, but not dictating whether or not we should develop one solution for all, or separate solution for each one. If people can come up with solutions/proposals to solve interoperability across 3, I don't see why we shouldn't allow them to try. On the other hand, if people have strong proposals for each individual sub-category, that should be allowed too. The WG can evaluate all the options and then decide. Another option is to decide on the exact extend of interoperability now, and only accept proposals that work for it. I am not advocating any particular option in this email, but just want to point out that these are the questions we need to ponder upon when we discuss rechartering. Lily -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf Sent: Tuesday, August 03, 2004 11:17 AM To: Dorothy.Gellert@nokia.com; capwap@frascone.com Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com Subject: Re: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP WG Mtg Dorothy, Thanx for sending out this proposal. I looked through part of the draft and the proposal, and I have a (somewhat long) comment on the suggested recharter. There is an assumption in the recharter that there will be a single CAPWAP protocol. From the taxonomy document (part of which I briefly skimmed), it looks to me like there are three basic architectural approaches currently in the market: 1) the traditional MAC architecture, 2) the SplitMAC architecture in which the WTPs only implement delay sensitive functions and the rest are implemented on the ACs, and 3) the RemoteMAC architecture, where all the MAC functions are implemented in the ACs. 1) seems to me like it would be pretty much out of scope for a recharter, since there is not any need for additional protocol work on an interoperable access network protocol in traditional APs (but perhaps I'm missing something) because APs from different vendors exist today that interoperate. 2) and 3), however, seem to be to be two separate and largely incompatible architectures that represent two classes of products which could benefit from having an interoperable protocol between products in the class, but probably wouldn't benefit much from interoperability between classes. In the cellular world, there are two similar classes of products used for, for example, UMTS deployment. The best known is the RNC/Node B/UTRAN solution which is similar to SplitMAC in which a network controller runs a protocol over the access network that controls radio access points, but there's another solution, similar to RemoteMAC, in which wCDMA runs over fiber from what is essentially just a smart antenna doing PHY to PHY conversion to the controller. This latter solution has benefits in certain deployment situations, but requires lots of bandwidth on the link between the smart antenna and the controller, which might not be available in many cases. As far as I know, the two are really for different incompatible deployment cases and don't interoperate on the access network between the base station/access point and the controller. I would imagine that there are likely to be incompatible deployment situations in the WLAN world that would benefit more from one or the other of these solutions too. I think the recharter discussion needs to make a decision first whether there is need for interoperability between these two classes of products, and, if not, whether there is a need for interoperable protocol work between products in the same class for both classes, or whether only the class with the most need for an interoperable protocol should be focussed on. I have some opinions about this, but I will wait until the discussion tomorrow to express them. In addition, I think the WG chairs need to talk with the IESG about the right Area for this work, should the IESG agree to a recharter, since the scope of a protocol development effort for an access network control protocol seems like it might get a bit outside the Ops Area charter. Personally, I have some doubts about whether a recharter will be approved, since there may be a significant component of work in actual protocol development that involves decisions about MAC level functions, but perhaps we can get enough IEEE involvement to allow the work to proceed in IETF. It's a tough problem organizationally, because the technology spans both groups. jak ----- Original Message -----=20 From: To: ; Cc: ; ; Sent: Monday, August 02, 2004 10:29 PM Subject: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP WG Mtg Ok, This time with the attachment.... -Dorothy <> > -----Original Message----- > From: Gellert Dorothy (Nokia-ES/MtView) > Sent: Monday, August 02, 2004 10:28 PM > To: 'capwap@frascone.com' > Cc: Bert Wijnen (E-mail); Mani Mahalingam (E-mail); Kessens > David (Nokia-NET/MtView) > Subject: Re-charter proposal text to discuss at CAPWAP WG Mtg > > > Attached is the CAPWAP WG Re-charter proposal we will review > on Wednesday during the CAPWAP WG meeting. > Please review and provide comments on the process going > forward, deliverables and timeline suggested. > > Most of the WG meeting is dedicated to open discussion on how > to re-charter, so bring your comments! > > -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 capwap-admin@frascone.com Tue Aug 3 17:17:42 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12694 for ; Tue, 3 Aug 2004 17:17:41 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 27A9E20A6C; Tue, 3 Aug 2004 17:03:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8A9E920AAF; Tue, 3 Aug 2004 17:03:02 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 52DE020AAF for ; Tue, 3 Aug 2004 17:02:40 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 1BE2120A6C for ; Tue, 3 Aug 2004 17:02:38 -0400 (EDT) Message-ID: <036d01c4799f$5aaa55d0$936015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Yang, Lily L" , , Cc: , , References: <2AF68A477DD44C4EBCBE338C24E7A9EE01B57A0B@orsmsx408> Subject: Re: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP WG Mtg 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, 3 Aug 2004 14:17:56 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Lily, Thanx for the clarification. I did not distinguish between the distributed and centralized architecture. My opinion is that the new WG charter should concentrate on wired access network architecures, and, in that case, that access network control protocols for multihop/ad hoc access networks in the distributed class should be out of scope. Within the centralized class, I think the WG should make a decision about whether there is any need for IETF work on an interoperability protocol between all three classes. Personally, I don't believe there is such a need. I believe having products interoperate within a particular class is sufficient, because each class is likely to address a particular collection of deployment scenarios that don't overlap much, if at all. Given that IETF has limited resources, I think the WG should determine whether there is really any need for an interoperable IP level protocol between products in each of the classes, and should select one class (initially, maybe later the others if the need is there) where the need for interoperability is greatest. That's my 0.02 yen. jak ----- Original Message ----- From: "Yang, Lily L" To: "James Kempf" ; ; Cc: ; ; Sent: Tuesday, August 03, 2004 1:31 PM Subject: RE: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP WG Mtg I agree that there is an important decision to be made when we recharter the group, to decide what kind of interoperability we want across what architecture variants. But I believe James's summary of the architecture taxonomy is not completely correct. The taxonomy classified the existing/emerging architecture spectrum as the following: +----------------+ |Autonomous | +---------->|Architecture | | |Family | | +----------------+ | +--------------+ | |Local | | +---->|MAC | | | |Architecture | | | +--------------+ | | | +----------------+ | +--------------+ | |Centralized | | |Split | +---------->|Architecture |--+---->|MAC | | |Family | | |Architecture | | +----------------+ | +--------------+ | | | | +--------------+ | | |Remote | | +---->|MAC | | |Architecture | | +--------------+ | +----------------+ | |Distributed Mesh| +---------->|Architecture | |Family | +----------------+ So we have to explicitly decide what kind of interoperability we want to achieve in this picture. It seems like a relatively easier decision at the first level. Autonomous Architecture doesn't need any further protocol. One example of the Distributed Architecture -- 802.11 mesh -- is being developed by IEEE 802.11 TGs, and it is not yet clear how much of the control/config aspect will be included in that effort. Centralized architecture is where we hear the interoperability demand the most. Now within the Centralized architecture, there is a harder question to answer: what kind of interoperability we want? Across all 3 sub-categories with one protocol? Does that make sense, eps. If different sub-category suits for different deployment scenarios? Is it technically feasible to have one fit all? Or is it acceptable to have only interoperability within each sub-category? Should this group work on all 3? Or 1? 2? One option for the WG is to only draw the scope boundary around Centralized Architecture, but not dictating whether or not we should develop one solution for all, or separate solution for each one. If people can come up with solutions/proposals to solve interoperability across 3, I don't see why we shouldn't allow them to try. On the other hand, if people have strong proposals for each individual sub-category, that should be allowed too. The WG can evaluate all the options and then decide. Another option is to decide on the exact extend of interoperability now, and only accept proposals that work for it. I am not advocating any particular option in this email, but just want to point out that these are the questions we need to ponder upon when we discuss rechartering. Lily -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf Sent: Tuesday, August 03, 2004 11:17 AM To: Dorothy.Gellert@nokia.com; capwap@frascone.com Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com Subject: Re: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP WG Mtg Dorothy, Thanx for sending out this proposal. I looked through part of the draft and the proposal, and I have a (somewhat long) comment on the suggested recharter. There is an assumption in the recharter that there will be a single CAPWAP protocol. From the taxonomy document (part of which I briefly skimmed), it looks to me like there are three basic architectural approaches currently in the market: 1) the traditional MAC architecture, 2) the SplitMAC architecture in which the WTPs only implement delay sensitive functions and the rest are implemented on the ACs, and 3) the RemoteMAC architecture, where all the MAC functions are implemented in the ACs. 1) seems to me like it would be pretty much out of scope for a recharter, since there is not any need for additional protocol work on an interoperable access network protocol in traditional APs (but perhaps I'm missing something) because APs from different vendors exist today that interoperate. 2) and 3), however, seem to be to be two separate and largely incompatible architectures that represent two classes of products which could benefit from having an interoperable protocol between products in the class, but probably wouldn't benefit much from interoperability between classes. In the cellular world, there are two similar classes of products used for, for example, UMTS deployment. The best known is the RNC/Node B/UTRAN solution which is similar to SplitMAC in which a network controller runs a protocol over the access network that controls radio access points, but there's another solution, similar to RemoteMAC, in which wCDMA runs over fiber from what is essentially just a smart antenna doing PHY to PHY conversion to the controller. This latter solution has benefits in certain deployment situations, but requires lots of bandwidth on the link between the smart antenna and the controller, which might not be available in many cases. As far as I know, the two are really for different incompatible deployment cases and don't interoperate on the access network between the base station/access point and the controller. I would imagine that there are likely to be incompatible deployment situations in the WLAN world that would benefit more from one or the other of these solutions too. I think the recharter discussion needs to make a decision first whether there is need for interoperability between these two classes of products, and, if not, whether there is a need for interoperable protocol work between products in the same class for both classes, or whether only the class with the most need for an interoperable protocol should be focussed on. I have some opinions about this, but I will wait until the discussion tomorrow to express them. In addition, I think the WG chairs need to talk with the IESG about the right Area for this work, should the IESG agree to a recharter, since the scope of a protocol development effort for an access network control protocol seems like it might get a bit outside the Ops Area charter. Personally, I have some doubts about whether a recharter will be approved, since there may be a significant component of work in actual protocol development that involves decisions about MAC level functions, but perhaps we can get enough IEEE involvement to allow the work to proceed in IETF. It's a tough problem organizationally, because the technology spans both groups. jak ----- Original Message ----- From: To: ; Cc: ; ; Sent: Monday, August 02, 2004 10:29 PM Subject: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP WG Mtg Ok, This time with the attachment.... -Dorothy <> > -----Original Message----- > From: Gellert Dorothy (Nokia-ES/MtView) > Sent: Monday, August 02, 2004 10:28 PM > To: 'capwap@frascone.com' > Cc: Bert Wijnen (E-mail); Mani Mahalingam (E-mail); Kessens > David (Nokia-NET/MtView) > Subject: Re-charter proposal text to discuss at CAPWAP WG Mtg > > > Attached is the CAPWAP WG Re-charter proposal we will review > on Wednesday during the CAPWAP WG meeting. > Please review and provide comments on the process going > forward, deliverables and timeline suggested. > > Most of the WG meeting is dedicated to open discussion on how > to re-charter, so bring your comments! > > -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 capwap-admin@frascone.com Tue Aug 3 17:36:32 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14083 for ; Tue, 3 Aug 2004 17:36:32 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D6BDF2080A; Tue, 3 Aug 2004 17:20:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5400520C12; Tue, 3 Aug 2004 17:20:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BE5E420C12 for ; Tue, 3 Aug 2004 17:19: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 C30E62080A for ; Tue, 3 Aug 2004 17:19:40 -0400 (EDT) Message-ID: <037301c479a1$bc2407f0$936015ac@dcml.docomolabsusa.com> From: "James Kempf" To: , Cc: , , References: Subject: Re: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP WG Mtg 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, 3 Aug 2004 14:34:59 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Dorothy, Good comments. You have been an great advisor to us since the BOF. Are you available/interested to get more involved with CAPWAP over the next year? It would be good to have your expertise in any way possible. jak>> I can help, premised of course on the IESG approving the charter. True. I didn't explicitly call this out because I thought that the Objective document would address which architecture approach(s) out of the taxonomy document we would pursue. The Objective draft is based off of the taxonomy work, so the analysis (and experience gained) in that document would be of significant value. In addition, the evaluation draft is also a place where we could stress 2 approaches/protocols to the solution. jak>> Personally, I believe the charter should not include this kind of open-ended discussion decision making about what the WG will do. I think that discussion should be done prior to chartering, and the charter itself should constrain work sufficiently that the WG has a liklihood getting something useful done in a reasonable amount of time (3 years for example). If the WG argues about what it will do for the first year, there will be even less liklihood that something useful will result. We tried this in Seamoby and, take my word for it, it did not work. The kind of constraint I would like to see is something like "The WG will develop a protocol for interoperability between ACs and WTPs of different vendors that are implemented according to architecture XXX of the CAPWAP architectural taxonomy". There may be more than one such statement, but they need to be priortized if so. Bernard Aboba has advised us also to stress performance criteria, so the low/high bandwidth distinction makes sense. We have it as part of the protocol, but it should also be called out in the Objectives phase. I believe we should be aware of the applications expected to run over this network to assure we don't create something that essentially prevents VOIP or other bandwidth sensitive applications. jak>> Performance should be a major decision criteria, but I think other critera should be how willing vendors are to work together to develop the concensus needed for a standard (rather than push proprietary solutions) and how desparate network operators are for interoperable products. One alternative for prioritization would be picking the lowest hanging fruit- which class has the least work involved to standardize an interoperable protocol - and standardize that first. The other would be to take the class needing the most work first. We should talk about this at the meeting. We did get the IEEE to charter a study group to define the AP functions better so we can effective distribute them as necessary. I believe Dorothy Stanley has been elected the chair of this group and she is also our liaison. I think we have set a good foundation for success in working out issues with the IEEE. This is still a new model of cooperation between IETF and other SDOs, but I think the time is upon us to work in collaboration with each other to meet the mobility demands of the market. jak>> This sounds very promising, I think this kind of structure increases the chances of success. jak _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Aug 3 17:37:53 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14160 for ; Tue, 3 Aug 2004 17:37:52 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DE5C220955; Tue, 3 Aug 2004 17:23:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D339D2171E; Tue, 3 Aug 2004 17:23:02 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 10E0E21CA0 for ; Tue, 3 Aug 2004 17:22:16 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id 1FE3421727 for ; Tue, 3 Aug 2004 17:22:14 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C479A2.5FED772E" Message-ID: <55749BC69138654EBBC4C50BA4F55610020C446C@AIREMAIL.airespace.com> Thread-Topic: So many architectures, so little time... Thread-Index: AcR5n74gP7FgBe6xTgen0Qrkwn93tAAAYvcB From: "Pat R. Calhoun" To: "James Kempf" , "Yang, Lily L" , , Cc: , , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] So many architectures, so little time... 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, 3 Aug 2004 14:39:37 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C479A2.5FED772E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'd like to discuss my take on the various architectures. My belief is that standardizing the remote MAC architecture cannot be an IETF problem. First, the timing requirements of the real-time = functions of the MAC would create a significant challenge for the protocol = developers as the reality is that interoperability between the infrastructure and = the clients is paramount. Any architecture that now causes clients to no = longer associate with the network is not terribly useful. Then we have mesh networks. Mesh networks really consists of two = components: 1. Mesh Routing/Topology Discovery: I do not believe this is a problem = that is within our charter 2. The rest: I'm being a little vague here, but all of the normal AP = functions, such as access control, is within the charter. A protocol designed by the WG = should be applicable to any AP, regardless of whether it is reachable via a wired = network or via some wireless medium. As far as Local MAC, it's not clear that there is anything required = above and beyond what already exists. So I do believe that our goal should be to design a single protocol can = satisfy the Split MAC approaches. PatC ------_=_NextPart_001_01C479A2.5FED772E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So many architectures, so little time...

I'd like to discuss my take on the various = architectures.

My belief is that standardizing the remote MAC architecture cannot = be
an IETF problem. First, the timing requirements of the real-time = functions
of the MAC would create a significant challenge for the protocol = developers
as the reality is that interoperability between the infrastructure and = the
clients is paramount. Any architecture that now causes clients to no = longer
associate with the network is not terribly useful.

Then we have mesh networks. Mesh networks really consists of two = components:
1. Mesh Routing/Topology Discovery: I do not believe this is a problem = that is within our charter
2. The rest: I'm being a little vague here, but all of the normal AP = functions, such
as access control, is within the charter. A protocol designed by the WG = should be
applicable to any AP, regardless of whether it is reachable via a wired = network or
via some wireless medium.

As far as Local MAC, it's not clear that there is anything required = above and beyond
what already exists.

So I do believe that our goal should be to design a single protocol can = satisfy the
Split MAC approaches.

PatC

------_=_NextPart_001_01C479A2.5FED772E-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Aug 3 18:01:43 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15721 for ; Tue, 3 Aug 2004 18:01:43 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9EB2C21CA4; Tue, 3 Aug 2004 17:47:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0C37A21CA8; Tue, 3 Aug 2004 17:47:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3220D21CA8 for ; Tue, 3 Aug 2004 17:46:27 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id 4313F21CA4 for ; Tue, 3 Aug 2004 17:46:25 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C479A5.C894362E" Message-ID: <55749BC69138654EBBC4C50BA4F55610020C446F@AIREMAIL.airespace.com> Thread-Topic: So many architectures, so little time... - take 2 Thread-Index: AcR5hkD2micDRlBWT7iOTl5TG723UwAEFgwAAANHdKU= From: "Pat R. Calhoun" To: "Yang, Lily L" , "James Kempf" , , Cc: , , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] So many architectures, so little time... - take 2 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, 3 Aug 2004 15:04:01 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C479A5.C894362E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable After reading Lily's response to Jim, I realize that I fell down the = same trap. Local MAC is also a centralized approach, and so my previous response was not = complete. I believe the real question, in my mind, is whether we need to address either the = Local or the Split MAC architecture. Just looking at the Architecture Consideration tables (7 and 10) in the = specification, the main difference (at a high level) between both approaches is where the = 802.11 management terminates. For Local MAC, it's in the WTP, while for SPlit MAC, it's in = the AC. However, looking at table 8, most Local MAC approaches share STA state = between both the WTP and the AC. So clearly there is some signalling protocol between both = the WTP and the AC. Looking at one example of a Local MAC protocol (see = http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), = there is a protocol message that corresponds for every 802.11 MAC management event. So when a STA = associates, the AP breaks the message apart and creates an new protocol PDU, which contains = components found in the association request. I suspect that most Local MAC approaches do something very = similar. So if a protocol simply tunnels the 802.11 MAC management frames from = the WTP to the AC, it allows supports both approaches. For Local MAC, they get what they want via the = 802.11 frame, and this also works fine for Split MAC, which needs access to the MAC management = frame. What would be required in such a protocol is a way for the AP to communicate whether it will be = providing very specific functions - basically a capabilities negotiation approach. So I do believe that there is a way to address both architectures using = a single protocol. Thoughts? PatC ------_=_NextPart_001_01C479A5.C894362E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So many architectures, so little time... - take 2

After reading Lily's response to Jim, I realize that I = fell down the same trap. Local MAC
is also a centralized approach, and so my previous response was not = complete. I believe the
real question, in my mind, is whether we need to address either the = Local or the Split MAC
architecture.

Just looking at the Architecture Consideration tables (7 and 10) in the = specification, the
main difference (at a high level) between both approaches is where the = 802.11 management
terminates. For Local MAC, it's in the WTP, while for SPlit MAC, it's in = the AC.

However, looking at table 8, most Local MAC approaches share STA state = between both the WTP
and the AC. So clearly there is some signalling protocol between both = the WTP and the AC.

Looking at one example of a Local MAC protocol (see http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt),= there is a protocol message
that corresponds for every 802.11 MAC management event. So when a STA = associates, the AP breaks
the message apart and creates an new protocol PDU, which contains = components found in the association
request. I suspect that most Local MAC approaches do something very = similar.

So if a protocol simply tunnels the 802.11 MAC management frames from = the WTP to the AC, it allows
supports both approaches. For Local MAC, they get what they want via the = 802.11 frame, and this
also works fine for Split MAC, which needs access to the MAC management = frame. What would be required
in such a protocol is a way for the AP to communicate whether it will be = providing very specific
functions - basically a capabilities negotiation approach.

So I do believe that there is a way to address both architectures using = a single protocol.

Thoughts?

PatC

------_=_NextPart_001_01C479A5.C894362E-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Aug 3 18:09:48 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16688 for ; Tue, 3 Aug 2004 18:09:48 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5E45B20827; Tue, 3 Aug 2004 17:54:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3D3C62096E; Tue, 3 Aug 2004 17:54:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 00D6620827 for ; Tue, 3 Aug 2004 17:53:51 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mail.frascone.com (Postfix) with ESMTP id D0E0A206A4 for ; Tue, 3 Aug 2004 17:53:47 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i73M8FN20776; Wed, 4 Aug 2004 01:08:15 +0300 (EET DST) X-Scanned: Wed, 4 Aug 2004 01:06:05 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i73M652O028223; Wed, 4 Aug 2004 01:06:05 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00Y9xrTY; Wed, 04 Aug 2004 01:06:03 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i73M5un26269; Wed, 4 Aug 2004 01:05:56 +0300 (EET DST) Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 3 Aug 2004 17:05:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] RE: Re-charter proposal text to discuss at CAPWAP WG Mtg Message-ID: Thread-Topic: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP WG Mtg Thread-Index: AcR5hkD2micDRlBWT7iOTl5TG723UwAEFgwAAALYDyA= From: To: , , Cc: , , X-OriginalArrivalTime: 03 Aug 2004 22:05:55.0861 (UTC) FILETIME=[0CBF4450:01C479A6] 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, 3 Aug 2004 15:05:54 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I think these are good points and we need to re-charter to discuss and = solve them. The proposed charter has an Objectives phase where we can discuss = requirements such as these, and the protocol proposed are intended to = meet the objectives. =20 In drafting the objectives, we will take these issues to the WG list for = consensus and roll them into the Ojectives draft. =20 In addition to the list, anyone is free to write an internet-draft to = document issues in greater detail, and then discuss it on the WG list. Thanks, Dorohty > -----Original Message----- > From: ext Yang, Lily L [mailto:lily.l.yang@intel.com] > Sent: Tuesday, August 03, 2004 1:32 PM > To: James Kempf; Gellert Dorothy (Nokia-ES/MtView);=20 > capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David > (Nokia-NET/MtView) > Subject: RE: [Capwap] RE: Re-charter proposal text to discuss=20 > at CAPWAP > WG Mtg >=20 >=20 > I agree that there is an important decision to be made when=20 > we recharter > the group, to decide what kind of interoperability we want across what > architecture variants.=20 >=20 > But I believe James's summary of the architecture taxonomy is not > completely correct. The taxonomy classified the existing/emerging > architecture spectrum as the following: > +----------------+ > |Autonomous | > +---------->|Architecture | > | |Family | > | +----------------+ > | +--------------+ > | |Local | > | +---->|MAC | > | | |Architecture | > | | +--------------+ > | | > | +----------------+ | +--------------+ > | |Centralized | | |Split | > +---------->|Architecture |--+---->|MAC | > | |Family | | |Architecture | > | +----------------+ | +--------------+ > | | > | | +--------------+ > | | |Remote | > | +---->|MAC | > | |Architecture | > | +--------------+ > | +----------------+ > | |Distributed Mesh| > +---------->|Architecture | > |Family | > +----------------+ >=20 > So we have to explicitly decide what kind of interoperability=20 > we want to > achieve in this picture. It seems like a relatively easier decision at > the first level. Autonomous Architecture doesn't need any further > protocol. One example of the Distributed Architecture --=20 > 802.11 mesh -- > is being developed by IEEE 802.11 TGs, and it is not yet=20 > clear how much > of the control/config aspect will be included in that effort. > Centralized architecture is where we hear the interoperability demand > the most.=20 > Now within the Centralized architecture, there is a harder question to > answer: what kind of interoperability we want? Across all 3 > sub-categories with one protocol? Does that make sense, eps. If > different sub-category suits for different deployment scenarios? Is it > technically feasible to have one fit all? > Or is it acceptable to have only interoperability within each > sub-category? > Should this group work on all 3? Or 1? 2? >=20 > One option for the WG is to only draw the scope boundary around > Centralized Architecture, but not dictating whether or not we should > develop one solution for all, or separate solution for each one. If > people can come up with solutions/proposals to solve interoperability > across 3, I don't see why we shouldn't allow them to try. On the other > hand, if people have strong proposals for each individual=20 > sub-category, > that should be allowed too. The WG can evaluate all the=20 > options and then > decide. >=20 > Another option is to decide on the exact extend of=20 > interoperability now, > and only accept proposals that work for it. >=20 > I am not advocating any particular option in this email, but just want > to point out that these are the questions we need to ponder=20 > upon when we > discuss rechartering. >=20 > Lily >=20 > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of James Kempf > Sent: Tuesday, August 03, 2004 11:17 AM > To: Dorothy.Gellert@nokia.com; capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > Subject: Re: [Capwap] RE: Re-charter proposal text to discuss=20 > at CAPWAP > WG Mtg >=20 > Dorothy, >=20 > Thanx for sending out this proposal. I looked through part of=20 > the draft > and > the proposal, and I have a (somewhat long) comment on the suggested > recharter. >=20 > There is an assumption in the recharter that there will be a single > CAPWAP > protocol. From the taxonomy document (part of which I briefly=20 > skimmed), > it > looks to me like there are three basic architectural approaches > currently in > the market: 1) the traditional MAC architecture, 2) the SplitMAC > architecture in which the WTPs only implement delay sensitive=20 > functions > and > the rest are implemented on the ACs, and 3) the RemoteMAC=20 > architecture, > where all the MAC functions are implemented in the ACs. >=20 > 1) seems to me like it would be pretty much out of scope for a > recharter, > since there is not any need for additional protocol work on an > interoperable > access network protocol in traditional APs (but perhaps I'm missing > something) because APs from different vendors exist today that > interoperate. >=20 > 2) and 3), however, seem to be to be two separate and largely > incompatible > architectures that represent two classes of products which=20 > could benefit > from having an interoperable protocol between products in the=20 > class, but > probably wouldn't benefit much from interoperability between classes. >=20 > In the cellular world, there are two similar classes of products used > for, > for example, UMTS deployment. The best known is the RNC/Node B/UTRAN > solution which is similar to SplitMAC in which a network=20 > controller runs > a > protocol over the access network that controls radio access=20 > points, but > there's another solution, similar to RemoteMAC, in which=20 > wCDMA runs over > fiber from what is essentially just a smart antenna doing PHY to PHY > conversion to the controller. This latter solution has benefits in > certain > deployment situations, but requires lots of bandwidth on the link > between > the smart antenna and the controller, which might not be available in > many > cases. As far as I know, the two are really for different incompatible > deployment cases and don't interoperate on the access network between > the > base station/access point and the controller. >=20 > I would imagine that there are likely to be incompatible deployment > situations in the WLAN world that would benefit more from one or the > other > of these solutions too. >=20 > I think the recharter discussion needs to make a decision=20 > first whether > there is need for interoperability between these two classes of > products, > and, if not, whether there is a need for interoperable protocol work > between products in the same class for both classes, or=20 > whether only the > class with the most need for an interoperable protocol should be > focussed > on. I have some opinions about this, but I will wait until the > discussion > tomorrow to express them. >=20 > In addition, I think the WG chairs need to talk with the IESG=20 > about the > right Area for this work, should the IESG agree to a recharter, since > the > scope of a protocol development effort for an access network control > protocol seems like it might get a bit outside the Ops Area charter. > Personally, I have some doubts about whether a recharter will be > approved, > since there may be a significant component of work in actual protocol > development that involves decisions about MAC level functions, but > perhaps > we can get enough IEEE involvement to allow the work to=20 > proceed in IETF. > It's a tough problem organizationally, because the technology=20 > spans both > groups. >=20 > jak >=20 > ----- Original Message -----=20 > From: > To: ; > Cc: ; ; > Sent: Monday, August 02, 2004 10:29 PM > Subject: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP WG > Mtg >=20 >=20 > Ok, This time with the attachment.... >=20 > -Dorothy >=20 > <> >=20 > > -----Original Message----- > > From: Gellert Dorothy (Nokia-ES/MtView) > > Sent: Monday, August 02, 2004 10:28 PM > > To: 'capwap@frascone.com' > > Cc: Bert Wijnen (E-mail); Mani Mahalingam (E-mail); Kessens > > David (Nokia-NET/MtView) > > Subject: Re-charter proposal text to discuss at CAPWAP WG Mtg > > > > > > Attached is the CAPWAP WG Re-charter proposal we will review > > on Wednesday during the CAPWAP WG meeting. > > Please review and provide comments on the process going > > forward, deliverables and timeline suggested. > > > > Most of the WG meeting is dedicated to open discussion on how > > to re-charter, so bring your comments! > > > > -Dorothy and Mani >=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 Tue Aug 3 19:40:43 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22172 for ; Tue, 3 Aug 2004 19:40:42 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 617AA201AE; Tue, 3 Aug 2004 19:26:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1B5CD20C96; Tue, 3 Aug 2004 19:26:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 63FD620C96 for ; Tue, 3 Aug 2004 19:25:38 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id A54A1201AE for ; Tue, 3 Aug 2004 19:25:36 -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 i73NcgGa017298 for ; Tue, 3 Aug 2004 19:38:42 -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 i73NceGa017260 for ; Tue, 3 Aug 2004 19:38:41 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] RE: Re-charter proposal text to discuss at CAPWAP WG Mtg Message-ID: Thread-Topic: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP WG Mtg Thread-Index: AcR5hgu3oWEzmi2WS1uLeSrLaWE9egAKVzxg 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: Tue, 3 Aug 2004 17:40:09 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable James, Thanks for the comments. To add a few more points to Dorothy's response: -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com]=20 Sent: Tuesday, August 03, 2004 11:17 AM To: Dorothy.Gellert@nokia.com; capwap@frascone.com Cc: bwijnen@lucent.com; Mani, Mahalingam (Mahalingam); david.kessens@nokia.com Subject: Re: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP WG Mtg Dorothy, Thanx for sending out this proposal. I looked through part of the draft and the proposal, and I have a (somewhat long) comment on the suggested recharter. There is an assumption in the recharter that there will be a single CAPWAP protocol. From the taxonomy document (part of which I briefly skimmed), it looks to me like there are three basic architectural approaches currently in the market: 1) the traditional MAC architecture, 2) the SplitMAC architecture in which the WTPs only implement delay sensitive functions and the rest are implemented on the ACs, and 3) the RemoteMAC architecture, where all the MAC functions are implemented in the ACs. 1) seems to me like it would be pretty much out of scope for a recharter, since there is not any need for additional protocol work on an interoperable access network protocol in traditional APs (but perhaps I'm missing something) because APs from different vendors exist today that interoperate. [Mani, Mahalingam (Mahalingam)] the question of traditional APs interoperating from different vendors is debatable. Sure - that happened to be one of the motivations of IAPP but the latter itself has been ill-adopted. Within the scope that there needed little context to be transferred and BSS transitions within an ESS did not call on higher layer synchronizations inside the AP; interoperability is a trivial if not non-issue. The taxonomy deals with this case for the sake of completeness. That said, the 'traditional' AP vendors have also sought to provide glues to have a centralized control of sorts to manage the APs to various degrees. 2) and 3), however, seem to be to be two separate and largely incompatible architectures that represent two classes of products which could benefit from having an interoperable protocol between products in the class, but probably wouldn't benefit much from interoperability between classes. [Mani, Mahalingam (Mahalingam)] that is a valid point. The pre-CAPWAP version of architecture draft tended to dwell on such - perhaps a little too early - where, one approach is to discover/negotiate the class (capability discovery) and subsequently stay within the class. However, this is up for WG discussion - as a very probable manifestation of the single CAPWAP protocol that is suggested. In the cellular world, there are two similar classes of products used for, for example, UMTS deployment. The best known is the RNC/Node B/UTRAN solution which is similar to SplitMAC in which a network controller runs a protocol over the access network that controls radio access points, but there's another solution, similar to RemoteMAC, in which wCDMA runs over fiber from what is essentially just a smart antenna doing PHY to PHY conversion to the controller. This latter solution has benefits in certain deployment situations, but requires lots of bandwidth on the link between the smart antenna and the controller, which might not be available in many cases. As far as I know, the two are really for different incompatible deployment cases and don't interoperate on the access network between the base station/access point and the controller. I would imagine that there are likely to be incompatible deployment situations in the WLAN world that would benefit more from one or the other of these solutions too. I think the recharter discussion needs to make a decision first whether there is need for interoperability between these two classes of products, and, if not, whether there is a need for interoperable protocol work between products in the same class for both classes, or whether only the class with the most need for an interoperable protocol should be focussed on. I have some opinions about this, but I will wait until the discussion tomorrow to express them. [Mani, Mahalingam (Mahalingam)] the intent of the proposed charter itself is to motivate discussions of such issues up front in the session and the on the list; not necessarily constrain the scope without consensus. In addition, I think the WG chairs need to talk with the IESG about the right Area for this work, should the IESG agree to a recharter, since the scope of a protocol development effort for an access network control protocol seems like it might get a bit outside the Ops Area charter. Personally, I have some doubts about whether a recharter will be approved, since there may be a significant component of work in actual protocol development that involves decisions about MAC level functions, but perhaps we can get enough IEEE involvement to allow the work to proceed in IETF. It's a tough problem organizationally, because the technology spans both groups. [Mani, Mahalingam (Mahalingam)] As for interoperation enough has been said and done to lay the groundwork to ensure the proposed recharter (or otherwise) interworks with a parallel AP functions architecture study / task initiated, approved and started in IEEE 802.11 WLAN WG. (I will leave it to Dorothy Stanley to expand on that during the meeting). The degree of coupling required to continue this meaningfully in parallel to keep CAPWAP protocol work in sync. is something to be revisited. It is outlined in the milestone but needs more articulation later if the proposed effort is approved. jak [Mani, Mahalingam (Mahalingam)]=20 -mani ----- Original Message -----=20 From: To: ; Cc: ; ; Sent: Monday, August 02, 2004 10:29 PM Subject: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP WG Mtg Ok, This time with the attachment.... -Dorothy [Mani, Mahalingam (Mahalingam)] [...] _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Aug 3 22:37:43 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03750 for ; Tue, 3 Aug 2004 22:37:42 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A76E6204F6; Tue, 3 Aug 2004 22:23:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5B2A9208A0; Tue, 3 Aug 2004 22:23:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1E28D208A0 for ; Tue, 3 Aug 2004 22:22:19 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id 44C14204F6 for ; Tue, 3 Aug 2004 22:22:17 -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 i742ZMGa022817 for ; Tue, 3 Aug 2004 22:35:22 -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 i742ZLGa022792 for ; Tue, 3 Aug 2004 22:35:21 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C479CB.E521C627" Message-ID: Thread-Topic: So many architectures, so little time... Thread-Index: AcR5n74gP7FgBe6xTgen0Qrkwn93tAAAYvcBAApFL1A= From: "Mani, Mahalingam (Mahalingam)" To: "Pat R. Calhoun" , "James Kempf" , "Yang, Lily L" , , Cc: , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] RE: So many architectures, so little time... 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, 3 Aug 2004 20:36:50 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C479CB.E521C627 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just some minor points here... =20 _____ =20 From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]=20 Sent: Tuesday, August 03, 2004 2:40 PM To: James Kempf; Yang, Lily L; Dorothy.Gellert@nokia.com; capwap@frascone.com Cc: bwijnen@lucent.com; Mani, Mahalingam (Mahalingam); david.kessens@nokia.com Subject: So many architectures, so little time... =20 I'd like to discuss my take on the various architectures. My belief is that standardizing the remote MAC architecture cannot be an IETF problem. First, the timing requirements of the real-time functions of the MAC would create a significant challenge for the protocol developers as the reality is that interoperability between the infrastructure and the clients is paramount. Any architecture that now causes clients to no longer associate with the network is not terribly useful. Then we have mesh networks. Mesh networks really consists of two components: 1. Mesh Routing/Topology Discovery: I do not believe this is a problem that is within our charter 2. The rest: I'm being a little vague here, but all of the normal AP functions, such as access control, is within the charter. A protocol designed by the WG should be applicable to any AP, regardless of whether it is reachable via a wired network or via some wireless medium. [Mani, Mahalingam (Mahalingam)] the wireless backend is mobile. This implies more involvement of addressing the details of meshnetworking Into the protocol API rather than causing changes to the protocol itself - if done right. That is always true - if the design is towards the more general case of a mobile infrastructure - that should work for the normal case (of wireline CAPWAP backhaul). A simpler way to approach is also to ask ourselves what constitutes the WLAN control plane and its scope while isolating considerations of the fastpath which could be a union of multiple wireline and wireless (in case of mesh) hops. [Mani, Mahalingam (Mahalingam)] it would be fair to say even a meshnetwork of adhoc (mobile) BSSs will need a coordinating reference. The AC abstraction addresses this - perhaps pending minor adjustments to standardization of meshnetwork (802.11s). As far as Local MAC, it's not clear that there is anything required above and beyond what already exists. So I do believe that our goal should be to design a single protocol can satisfy the Split MAC approaches. [Mani, Mahalingam (Mahalingam)] a reasonable argument - barring cases where even autonomous APs leverage trivial control of a centralized AC. [Mani, Mahalingam (Mahalingam)] -mani PatC ------_=_NextPart_001_01C479CB.E521C627 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So many architectures, so little time...

Just some minor points = here…

 

From: Pat = R. Calhoun [mailto:pcalhoun@airespace.com]
Sent: Tuesday, August 03, = 2004 2:40 PM
To: James Kempf; Yang, = Lily L; Dorothy.Gellert@nokia.com; capwap@frascone.com
Cc: bwijnen@lucent.com; = Mani, Mahalingam (Mahalingam); david.kessens@nokia.com
Subject: So many = architectures, so little time...

 

I'd like to discuss my take on the various architectures.

My belief is that standardizing the remote MAC architecture cannot = be
an IETF problem. First, the timing requirements of the real-time = functions
of the MAC would create a significant challenge for the protocol = developers
as the reality is that interoperability between the infrastructure and = the
clients is paramount. Any architecture that now causes clients to no = longer
associate with the network is not terribly useful.

Then we have mesh networks. Mesh networks really consists of two = components:
1. Mesh Routing/Topology Discovery: I do not believe this is a problem = that is within our charter
2. The rest: I'm being a little vague here, but all of the normal AP = functions, such
as access control, is within the charter. A protocol designed by the WG = should be
applicable to any AP, regardless of whether it is reachable via a wired = network or
via some wireless medium.

[Mani, Mahalingam (Mahalingam)] the wireless backend is mobile. This implies = more involvement of addressing the details of = meshnetworking

Into = the protocol API rather than causing changes to the protocol itself – = if done right. That is always true – if the design is towards the more = general case of a mobile infrastructure – that should work for the normal = case (of wireline CAPWAP backhaul). A simpler way to approach is also to ask ourselves what constitutes the WLAN control plane and its scope while = isolating considerations of the fastpath which could be a union of multiple = wireline and wireless (in case of mesh) hops.

[Mani, Mahalingam (Mahalingam)] it would be fair to say even a = meshnetwork of adhoc (mobile) BSSs will need a coordinating reference. The AC = abstraction addresses this – perhaps pending minor adjustments to standardization of = meshnetwork (802.11s).

As far as Local MAC, it's not clear that there is anything required = above and beyond
what already exists.

So I do believe that our goal should be to design a single protocol can = satisfy the
Split MAC approaches.

[Mani, Mahalingam (Mahalingam)] a reasonable argument – barring cases = where even autonomous APs leverage trivial control of a centralized = AC.

[Mani, Mahalingam (Mahalingam)] -mani

PatC

------_=_NextPart_001_01C479CB.E521C627-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Aug 3 22:39:43 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03858 for ; Tue, 3 Aug 2004 22:39:42 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 285282171B; Tue, 3 Aug 2004 22:25:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 71E352173B; Tue, 3 Aug 2004 22:25:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 251022173B for ; Tue, 3 Aug 2004 22:24:37 -0400 (EDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by mail.frascone.com (Postfix) with ESMTP id 1CC78211B9 for ; Tue, 3 Aug 2004 22:24:35 -0400 (EDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i742c5b7025383; Wed, 4 Aug 2004 02:38:05 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i742fD1q013932; Wed, 4 Aug 2004 02:41:13 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004080319390302972 ; Tue, 03 Aug 2004 19:39:03 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Aug 2004 19:39:02 -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_01C479CC.340256C8" Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE01B57E85@orsmsx408> Thread-Topic: So many architectures, so little time... Thread-Index: AcR5n74gP7FgBe6xTgen0Qrkwn93tAAAYvcBAApWrcA= From: "Yang, Lily L" To: "Pat R. Calhoun" , "James Kempf" , , Cc: , , X-OriginalArrivalTime: 04 Aug 2004 02:39:02.0925 (UTC) FILETIME=[3432CBD0:01C479CC] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] RE: So many architectures, so little time... 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, 3 Aug 2004 19:38:57 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C479CC.340256C8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable See comments below in line. =20 ________________________________ From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]=20 Sent: Tuesday, August 03, 2004 2:40 PM To: James Kempf; Yang, Lily L; Dorothy.Gellert@nokia.com; capwap@frascone.com Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com Subject: So many architectures, so little time... =20 I'd like to discuss my take on the various architectures. My belief is that standardizing the remote MAC architecture cannot be an IETF problem. First, the timing requirements of the real-time functions of the MAC would create a significant challenge for the protocol developers as the reality is that interoperability between the infrastructure and the clients is paramount. Any architecture that now causes clients to no longer associate with the network is not terribly useful. [Yang, Lily L] I also think that developing such a protocol for remote MAC has challenges that are quite specific to this architecture, while it is more feasible to develop a common protocol supporting both local and split MAC. Then we have mesh networks. Mesh networks really consists of two components: 1. Mesh Routing/Topology Discovery: I do not believe this is a problem that is within our charter 2. The rest: I'm being a little vague here, but all of the normal AP functions, such as access control, is within the charter. A protocol designed by the WG should be applicable to any AP, regardless of whether it is reachable via a wired network or via some wireless medium. [Yang, Lily L] I would also agree that the protocol should be applicable, whether or not it is reachable via a wired network or some wireless backbone (like 802.11 mesh).=20 As far as Local MAC, it's not clear that there is anything required above and beyond what already exists. So I do believe that our goal should be to design a single protocol can satisfy the Split MAC approaches. PatC ------_=_NextPart_001_01C479CC.340256C8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So many architectures, so little time...

See comments = below in line.

 <= /span>

From: Pat R. = Calhoun [mailto:pcalhoun@airespace.com]
Sent: Tuesday, August 03, = 2004 2:40 PM
To: James Kempf; Yang, = Lily L; Dorothy.Gellert@nokia.com; capwap@frascone.com
Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com
Subject: So many = architectures, so little time...

 

I'd like to discuss my take on the various architectures.

My belief is that standardizing the remote MAC architecture cannot = be
an IETF problem. First, the timing requirements of the real-time = functions
of the MAC would create a significant challenge for the protocol = developers
as the reality is that interoperability between the infrastructure and = the
clients is paramount. Any architecture that now causes clients to no = longer
associate with the network is not terribly useful.

[Yang, Lily L] I also think that developing such a = protocol for remote MAC has challenges that are quite specific to this architecture, = while it is more feasible to develop a common protocol supporting both local = and split MAC.



Then we have mesh networks. Mesh networks really consists of two = components:
1. Mesh Routing/Topology Discovery: I do not believe this is a problem = that is within our charter
2. The rest: I'm being a little vague here, but all of the normal AP = functions, such
as access control, is within the charter. A protocol designed by the WG = should be
applicable to any AP, regardless of whether it is reachable via a wired = network or
via some wireless medium.

[Yang, Lily L] I would also agree that the protocol should = be applicable, whether or not it is reachable via a wired network or some = wireless backbone (like 802.11 mesh).



As far as Local MAC, it's not clear that there is anything required = above and beyond
what already exists.

So I do believe that our goal should be to design a single protocol can = satisfy the
Split MAC approaches.

PatC

------_=_NextPart_001_01C479CC.340256C8-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Aug 3 22:42:43 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04091 for ; Tue, 3 Aug 2004 22:42:42 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B1A0A208A0; Tue, 3 Aug 2004 22:28:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 325E121743; Tue, 3 Aug 2004 22:28:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A6FA821743 for ; Tue, 3 Aug 2004 22:27:31 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 5CECD208A0 for ; Tue, 3 Aug 2004 22:27:29 -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 i742ZVSG016476 for ; Tue, 3 Aug 2004 21:35:31 -0500 (EST) 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 i742ZUSG016437 for ; Tue, 3 Aug 2004 21:35:30 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C479CC.9F657D67" Message-ID: Thread-Topic: So many architectures, so little time... - take 2 Thread-Index: AcR5hkD2micDRlBWT7iOTl5TG723UwAEFgwAAANHdKUACiTt4A== From: "Mani, Mahalingam (Mahalingam)" To: "Pat R. Calhoun" , "Yang, Lily L" , "James Kempf" , , Cc: , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] RE: So many architectures, so little time... - take 2 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, 3 Aug 2004 20:42:02 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C479CC.9F657D67 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The taxonomy draft analysis leads to such a possibility. The solution space will likely involve a discovery and negotiation phase leading to supportability of significant architecture classes. =20 -mani _____ =20 From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]=20 Sent: Tuesday, August 03, 2004 3:04 PM To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com; capwap@frascone.com Cc: bwijnen@lucent.com; Mani, Mahalingam (Mahalingam); david.kessens@nokia.com Subject: So many architectures, so little time... - take 2 =20 After reading Lily's response to Jim, I realize that I fell down the same trap. Local MAC is also a centralized approach, and so my previous response was not complete. I believe the real question, in my mind, is whether we need to address either the Local or the Split MAC architecture. Just looking at the Architecture Consideration tables (7 and 10) in the specification, the main difference (at a high level) between both approaches is where the 802.11 management terminates. For Local MAC, it's in the WTP, while for SPlit MAC, it's in the AC. However, looking at table 8, most Local MAC approaches share STA state between both the WTP and the AC. So clearly there is some signalling protocol between both the WTP and the AC. Looking at one example of a Local MAC protocol (see http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), there is a protocol message that corresponds for every 802.11 MAC management event. So when a STA associates, the AP breaks the message apart and creates an new protocol PDU, which contains components found in the association request. I suspect that most Local MAC approaches do something very similar. So if a protocol simply tunnels the 802.11 MAC management frames from the WTP to the AC, it allows supports both approaches. For Local MAC, they get what they want via the 802.11 frame, and this also works fine for Split MAC, which needs access to the MAC management frame. What would be required in such a protocol is a way for the AP to communicate whether it will be providing very specific functions - basically a capabilities negotiation approach. So I do believe that there is a way to address both architectures using a single protocol. Thoughts? PatC=20 ------_=_NextPart_001_01C479CC.9F657D67 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So many architectures, so little time... - take 2

The taxonomy draft analysis leads = to such a possibility. The solution space will likely involve a discovery and negotiation phase

leading to supportability of = significant architecture classes.

 

-mani

From: Pat = R. Calhoun [mailto:pcalhoun@airespace.com]
Sent: Tuesday, August 03, = 2004 3:04 PM
To: Yang, Lily L; James = Kempf; Dorothy.Gellert@nokia.com; capwap@frascone.com
Cc: bwijnen@lucent.com; = Mani, Mahalingam (Mahalingam); david.kessens@nokia.com
Subject: So many = architectures, so little time... - take 2

 

After reading Lily's response to Jim, I realize that I fell down the same = trap. Local MAC
is also a centralized approach, and so my previous response was not = complete. I believe the
real question, in my mind, is whether we need to address either the = Local or the Split MAC
architecture.

Just looking at the Architecture Consideration tables (7 and 10) in the specification, the
main difference (at a high level) between both approaches is where the = 802.11 management
terminates. For Local MAC, it's in the WTP, while for SPlit MAC, it's in = the AC.

However, looking at table 8, most Local MAC approaches share STA state = between both the WTP
and the AC. So clearly there is some signalling protocol between both = the WTP and the AC.

Looking at one example of a Local MAC protocol (see http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt),= there is a protocol message
that corresponds for every 802.11 MAC management event. So when a STA associates, the AP breaks
the message apart and creates an new protocol PDU, which contains = components found in the association
request. I suspect that most Local MAC approaches do something very = similar.

So if a protocol simply tunnels the 802.11 MAC management frames from = the WTP to the AC, it allows
supports both approaches. For Local MAC, they get what they want via the = 802.11 frame, and this
also works fine for Split MAC, which needs access to the MAC management = frame. What would be required
in such a protocol is a way for the AP to communicate whether it will be providing very specific
functions - basically a capabilities negotiation approach.

So I do believe that there is a way to address both architectures using = a single protocol.

Thoughts?

PatC

------_=_NextPart_001_01C479CC.9F657D67-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Aug 3 22:44:44 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04261 for ; Tue, 3 Aug 2004 22:44:42 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0200F2173E; Tue, 3 Aug 2004 22:30:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9DB2221743; Tue, 3 Aug 2004 22:30:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D089C21743 for ; Tue, 3 Aug 2004 22:29:59 -0400 (EDT) Received: from orsfmr001.jf.intel.com (fmr12.intel.com [134.134.136.15]) by mail.frascone.com (Postfix) with ESMTP id C6CA22173E for ; Tue, 3 Aug 2004 22:29:57 -0400 (EDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i73Jiprf022914; Tue, 3 Aug 2004 19:44:59 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i742jp1s016414; Wed, 4 Aug 2004 02:46:01 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004080319435003387 ; Tue, 03 Aug 2004 19:43:50 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Aug 2004 19:43:50 -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_01C479CC.DF8B46B0" Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE01B57E86@orsmsx408> Thread-Topic: So many architectures, so little time... Thread-Index: AcR5n74gP7FgBe6xTgen0Qrkwn93tAAAYvcBAApFL1AAAIQk8A== From: "Yang, Lily L" To: "Mani, Mahalingam (Mahalingam)" , "Pat R. Calhoun" , "James Kempf" , , Cc: , X-OriginalArrivalTime: 04 Aug 2004 02:43:50.0603 (UTC) FILETIME=[DFAAF9B0:01C479CC] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] RE: So many architectures, so little time... 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, 3 Aug 2004 19:43:45 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C479CC.DF8B46B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just one minor point about your comment "the wireless backend is mobile" - true, but the degree of mobility is likely to be very different from the station mobility - TGs is still trying to define how much mobility it is required to support. In the case of home, office and enterprise, mobility of the backend mesh is probably low; while other usage scenarios may require higher degree of mobility. =20 ________________________________ From: Mani, Mahalingam (Mahalingam) [mailto:mmani@avaya.com]=20 Sent: Tuesday, August 03, 2004 7:37 PM To: Pat R. Calhoun; James Kempf; Yang, Lily L; Dorothy.Gellert@nokia.com; capwap@frascone.com Cc: bwijnen@lucent.com; david.kessens@nokia.com Subject: RE: So many architectures, so little time... =20 Just some minor points here... =20 ________________________________ From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]=20 Sent: Tuesday, August 03, 2004 2:40 PM To: James Kempf; Yang, Lily L; Dorothy.Gellert@nokia.com; capwap@frascone.com Cc: bwijnen@lucent.com; Mani, Mahalingam (Mahalingam); david.kessens@nokia.com Subject: So many architectures, so little time... =20 I'd like to discuss my take on the various architectures. My belief is that standardizing the remote MAC architecture cannot be an IETF problem. First, the timing requirements of the real-time functions of the MAC would create a significant challenge for the protocol developers as the reality is that interoperability between the infrastructure and the clients is paramount. Any architecture that now causes clients to no longer associate with the network is not terribly useful. Then we have mesh networks. Mesh networks really consists of two components: 1. Mesh Routing/Topology Discovery: I do not believe this is a problem that is within our charter 2. The rest: I'm being a little vague here, but all of the normal AP functions, such as access control, is within the charter. A protocol designed by the WG should be applicable to any AP, regardless of whether it is reachable via a wired network or via some wireless medium. [Mani, Mahalingam (Mahalingam)] the wireless backend is mobile. This implies more involvement of addressing the details of meshnetworking Into the protocol API rather than causing changes to the protocol itself - if done right. That is always true - if the design is towards the more general case of a mobile infrastructure - that should work for the normal case (of wireline CAPWAP backhaul). A simpler way to approach is also to ask ourselves what constitutes the WLAN control plane and its scope while isolating considerations of the fastpath which could be a union of multiple wireline and wireless (in case of mesh) hops. [Mani, Mahalingam (Mahalingam)] it would be fair to say even a meshnetwork of adhoc (mobile) BSSs will need a coordinating reference. The AC abstraction addresses this - perhaps pending minor adjustments to standardization of meshnetwork (802.11s). As far as Local MAC, it's not clear that there is anything required above and beyond what already exists. So I do believe that our goal should be to design a single protocol can satisfy the Split MAC approaches. [Mani, Mahalingam (Mahalingam)] a reasonable argument - barring cases where even autonomous APs leverage trivial control of a centralized AC. [Mani, Mahalingam (Mahalingam)] -mani PatC ------_=_NextPart_001_01C479CC.DF8B46B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So many architectures, so little time...

Just one minor = point about your comment  “the wireless backend is mobile” – = true, but the degree of mobility is likely to be very different from the station = mobility – TGs is still trying to define how much  mobility it is = required to support. In the case of home, office and enterprise, mobility of the = backend mesh is probably low; while other usage scenarios may require higher = degree of mobility.

 <= /span>

From: Mani, = Mahalingam (Mahalingam) [mailto:mmani@avaya.com]
Sent: Tuesday, August 03, = 2004 7:37 PM
To: Pat R. Calhoun; James = Kempf; Yang, Lily L; Dorothy.Gellert@nokia.com; capwap@frascone.com
Cc: bwijnen@lucent.com; david.kessens@nokia.com
Subject: RE: So many architectures, so little time...

 

Just some minor points = here…

 

From: Pat R. = Calhoun [mailto:pcalhoun@airespace.com]
Sent: Tuesday, August 03, = 2004 2:40 PM
To: James Kempf; Yang, = Lily L; Dorothy.Gellert@nokia.com; capwap@frascone.com
Cc: bwijnen@lucent.com; = Mani, Mahalingam (Mahalingam); david.kessens@nokia.com
Subject: So many = architectures, so little time...

 

I'd like to discuss my take on the various architectures.

My belief is that standardizing the remote MAC architecture cannot = be
an IETF problem. First, the timing requirements of the real-time = functions
of the MAC would create a significant challenge for the protocol = developers
as the reality is that interoperability between the infrastructure and = the
clients is paramount. Any architecture that now causes clients to no = longer
associate with the network is not terribly useful.

Then we have mesh networks. Mesh networks really consists of two = components:
1. Mesh Routing/Topology Discovery: I do not believe this is a problem = that is within our charter
2. The rest: I'm being a little vague here, but all of the normal AP = functions, such
as access control, is within the charter. A protocol designed by the WG = should be
applicable to any AP, regardless of whether it is reachable via a wired = network or
via some wireless medium.

[Mani, Mahalingam (Mahalingam)] the wireless backend is mobile. This implies more = involvement of addressing the details of = meshnetworking

Into the protocol = API rather than causing changes to the protocol itself – if done = right. That is always true – if the design is towards the more general case of = a mobile infrastructure – that should work for the normal case (of = wireline CAPWAP backhaul). A simpler way to approach is also to ask ourselves = what constitutes the WLAN control plane and its scope while isolating = considerations of the fastpath which could be a union of multiple wireline and wireless = (in case of mesh) hops.

[Mani, Mahalingam = (Mahalingam)] it would be fair to say even a meshnetwork of adhoc (mobile) BSSs will need a coordinating reference. The AC abstraction addresses this – = perhaps pending minor adjustments to standardization of meshnetwork = (802.11s).

As far as Local MAC, it's not clear that there is anything required = above and beyond
what already exists.

So I do believe that our goal should be to design a single protocol can = satisfy the
Split MAC approaches.

[Mani, Mahalingam (Mahalingam)] a reasonable argument – barring cases where even = autonomous APs leverage trivial control of a centralized = AC.

[Mani, Mahalingam = (Mahalingam)] -mani

PatC

------_=_NextPart_001_01C479CC.DF8B46B0-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Aug 4 00:08:42 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09406 for ; Wed, 4 Aug 2004 00:08:41 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 545BA219A6; Tue, 3 Aug 2004 23:54:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 33711219A7; Tue, 3 Aug 2004 23:54:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8CC7F219A7 for ; Tue, 3 Aug 2004 23:53:08 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 9C37E219A6 for ; Tue, 3 Aug 2004 23:53:06 -0400 (EDT) Message-ID: <042201c479d8$b1bbaca0$936015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Yang, Lily L" , "Mani, Mahalingam (Mahalingam)" , "Pat R. Calhoun" , , Cc: , References: <2AF68A477DD44C4EBCBE338C24E7A9EE01B57E86@orsmsx408> 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) Subject: [Capwap] Re: So many architectures, so little time... 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, 3 Aug 2004 21:08:23 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I think more to the point is that a wireless multihop backhaul probably will require some changes at the MAC level, and 802.11s isn't there yet. jak ----- Original Message ----- From: "Yang, Lily L" To: "Mani, Mahalingam (Mahalingam)" ; "Pat R. Calhoun" ; "James Kempf" ; ; Cc: ; Sent: Tuesday, August 03, 2004 7:43 PM Subject: RE: So many architectures, so little time... Just one minor point about your comment "the wireless backend is mobile" - true, but the degree of mobility is likely to be very different from the station mobility - TGs is still trying to define how much mobility it is required to support. In the case of home, office and enterprise, mobility of the backend mesh is probably low; while other usage scenarios may require higher degree of mobility. ________________________________ From: Mani, Mahalingam (Mahalingam) [mailto:mmani@avaya.com] Sent: Tuesday, August 03, 2004 7:37 PM To: Pat R. Calhoun; James Kempf; Yang, Lily L; Dorothy.Gellert@nokia.com; capwap@frascone.com Cc: bwijnen@lucent.com; david.kessens@nokia.com Subject: RE: So many architectures, so little time... Just some minor points here... ________________________________ From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Tuesday, August 03, 2004 2:40 PM To: James Kempf; Yang, Lily L; Dorothy.Gellert@nokia.com; capwap@frascone.com Cc: bwijnen@lucent.com; Mani, Mahalingam (Mahalingam); david.kessens@nokia.com Subject: So many architectures, so little time... I'd like to discuss my take on the various architectures. My belief is that standardizing the remote MAC architecture cannot be an IETF problem. First, the timing requirements of the real-time functions of the MAC would create a significant challenge for the protocol developers as the reality is that interoperability between the infrastructure and the clients is paramount. Any architecture that now causes clients to no longer associate with the network is not terribly useful. Then we have mesh networks. Mesh networks really consists of two components: 1. Mesh Routing/Topology Discovery: I do not believe this is a problem that is within our charter 2. The rest: I'm being a little vague here, but all of the normal AP functions, such as access control, is within the charter. A protocol designed by the WG should be applicable to any AP, regardless of whether it is reachable via a wired network or via some wireless medium. [Mani, Mahalingam (Mahalingam)] the wireless backend is mobile. This implies more involvement of addressing the details of meshnetworking Into the protocol API rather than causing changes to the protocol itself - if done right. That is always true - if the design is towards the more general case of a mobile infrastructure - that should work for the normal case (of wireline CAPWAP backhaul). A simpler way to approach is also to ask ourselves what constitutes the WLAN control plane and its scope while isolating considerations of the fastpath which could be a union of multiple wireline and wireless (in case of mesh) hops. [Mani, Mahalingam (Mahalingam)] it would be fair to say even a meshnetwork of adhoc (mobile) BSSs will need a coordinating reference. The AC abstraction addresses this - perhaps pending minor adjustments to standardization of meshnetwork (802.11s). As far as Local MAC, it's not clear that there is anything required above and beyond what already exists. So I do believe that our goal should be to design a single protocol can satisfy the Split MAC approaches. [Mani, Mahalingam (Mahalingam)] a reasonable argument - barring cases where even autonomous APs leverage trivial control of a centralized AC. [Mani, Mahalingam (Mahalingam)] -mani PatC _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Aug 4 00:40:42 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10680 for ; Wed, 4 Aug 2004 00:40:42 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E27991FF0F; Wed, 4 Aug 2004 00:26:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B2751208AB; Wed, 4 Aug 2004 00:26:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B2492203B2 for ; Wed, 4 Aug 2004 00:25:10 -0400 (EDT) Received: from toronto-mail.chantrynetworks.com (unknown [67.69.27.58]) by mail.frascone.com (Postfix) with ESMTP id 0CF341FF0F for ; Wed, 4 Aug 2004 00:25:09 -0400 (EDT) Received: from [192.168.5.106] (helo=wxp35) by toronto-mail.chantrynetworks.com with asmtp (Exim 4.31) id 1BsDYp-0006No-Jq; Wed, 04 Aug 2004 00:39:33 -0400 From: "Inderpreet Singh" To: Cc: , , , Subject: RE: [Capwap] So many architectures, so little time... - take 2 Message-ID: <002301c479dd$106b7e70$6a05a8c0@toronto.chantrynetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <55749BC69138654EBBC4C50BA4F55610020C446F@AIREMAIL.airespace.com> Importance: Normal X-AV-Scan: This message has been scanned by Chantry Networks using ClamAV 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, 4 Aug 2004 00:39:37 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit The issue(s) at hand and my opinions are: 1. Do we explicitly state in the re-charter which architecture the WG should consider? I think yes. I propose Centralized architecture only. Autonomous and Distributed should be out of scope based on the same reasons as per prior postings. 2. Within Centralized do we focus on all three sub architectures or a subset? Remote MAC should be excluded because if I am not mistaken, the connectivity constraint between the WTP and the AC is "direct connect". That being the case and that no IP layer is involved, it doesn't seem clear what kind of protocol would help with interoperability. I am concerned about the impact, dependencies and interaction with the recently constituted IEEE Study group on AP functionality on the Split MAC architectures. Furthermore, there are some pretty drastic differences on how the vendors have chosen to split the mac. Those differences will need to be worked out before designing a protocol. So, if the low hanging fruit strategy (as James suggested) for protocol development and progress is the way to go, then I think prioritizing on a protocol for Local MAC is a no brainer. So as far as focus, I feel we should do Local and Split and in that order. 3. This is not a re-chartering issue but is a response to Pat's suggestion that a protocol that just sends the 802.11 MAC frames from the AP to the AC would work. I think possibly, yes. But again the complications of splitting the MAC in an interoperable way will be an issue. Also, you may note in the draft to which you refer, we included a capabilities exchange phase. I had thought of including in the capability exchange such things as "AP supports Local MAC" and "AP supports Split MAC", but didn't put it in because the Taxonomy work was still in progress. Now that it is pretty much done we could surely include that. But again...let's recharter first. Thanks. Do people agree with 1 & 2? --- Inderpreet Singh Chantry Networks isingh@chantrynetworks.com Cell: 416-831-3705 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun Sent: Tuesday, August 03, 2004 6:04 PM To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com; capwap@frascone.com Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com Subject: [Capwap] So many architectures, so little time... - take 2 After reading Lily's response to Jim, I realize that I fell down the same trap. Local MAC is also a centralized approach, and so my previous response was not complete. I believe the real question, in my mind, is whether we need to address either the Local or the Split MAC architecture. Just looking at the Architecture Consideration tables (7 and 10) in the specification, the main difference (at a high level) between both approaches is where the 802.11 management terminates. For Local MAC, it's in the WTP, while for SPlit MAC, it's in the AC. However, looking at table 8, most Local MAC approaches share STA state between both the WTP and the AC. So clearly there is some signalling protocol between both the WTP and the AC. Looking at one example of a Local MAC protocol (see http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), there is a protocol message that corresponds for every 802.11 MAC management event. So when a STA associates, the AP breaks the message apart and creates an new protocol PDU, which contains components found in the association request. I suspect that most Local MAC approaches do something very similar. So if a protocol simply tunnels the 802.11 MAC management frames from the WTP to the AC, it allows supports both approaches. For Local MAC, they get what they want via the 802.11 frame, and this also works fine for Split MAC, which needs access to the MAC management frame. What would be required in such a protocol is a way for the AP to communicate whether it will be providing very specific functions - basically a capabilities negotiation approach. So I do believe that there is a way to address both architectures using a single protocol. Thoughts? PatC _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Aug 4 01:38:45 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12879 for ; Wed, 4 Aug 2004 01:38:44 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2DC8E219CD; Wed, 4 Aug 2004 01:24:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BA7C4219D8; Wed, 4 Aug 2004 01:24:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8DB02219D8 for ; Wed, 4 Aug 2004 01:23:35 -0400 (EDT) Received: from mail3.extremenetworks.com (sc-f100-01.extremenetworks.com [63.251.106.30]) by mail.frascone.com (Postfix) with ESMTP id 98A1F219CD for ; Wed, 4 Aug 2004 01:23:33 -0400 (EDT) Received: by mail3 with Internet Mail Service (5.5.2657.72) id <39FWD39W>; Tue, 3 Aug 2004 22:36:57 -0700 Message-ID: <4C8B0EA487B9554D910B0587CD91395C02704CD6@sc-msexch-03.extremenetworks.com> From: Victor Lin To: "Pat R. Calhoun" , "Yang, Lily L" , James Kempf , Dorothy.Gellert@nokia.com, capwap@frascone.com Cc: bwijnen@lucent.com, mmani@avaya.com, david.kessens@nokia.com Subject: RE: [Capwap] So many architectures, so little time... - take 2 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C479E4.AF4A19F0" 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, 3 Aug 2004 22:34:17 -0700 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_01C479E4.AF4A19F0 Content-Type: text/plain I think single protocol is the easy part. Pat's suggestion definitely works. But to support interoperability with multiple architectures, I think it is important to clearly define the functionality of WTP and AC and have a protocol for AC and WTP to negotiate/advertise their capability. Victor _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun Sent: Tuesday, August 03, 2004 3:04 PM To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com; capwap@frascone.com Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com Subject: [Capwap] So many architectures, so little time... - take 2 After reading Lily's response to Jim, I realize that I fell down the same trap. Local MAC is also a centralized approach, and so my previous response was not complete. I believe the real question, in my mind, is whether we need to address either the Local or the Split MAC architecture. Just looking at the Architecture Consideration tables (7 and 10) in the specification, the main difference (at a high level) between both approaches is where the 802.11 management terminates. For Local MAC, it's in the WTP, while for SPlit MAC, it's in the AC. However, looking at table 8, most Local MAC approaches share STA state between both the WTP and the AC. So clearly there is some signalling protocol between both the WTP and the AC. Looking at one example of a Local MAC protocol (see http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt ), there is a protocol message that corresponds for every 802.11 MAC management event. So when a STA associates, the AP breaks the message apart and creates an new protocol PDU, which contains components found in the association request. I suspect that most Local MAC approaches do something very similar. So if a protocol simply tunnels the 802.11 MAC management frames from the WTP to the AC, it allows supports both approaches. For Local MAC, they get what they want via the 802.11 frame, and this also works fine for Split MAC, which needs access to the MAC management frame. What would be required in such a protocol is a way for the AP to communicate whether it will be providing very specific functions - basically a capabilities negotiation approach. So I do believe that there is a way to address both architectures using a single protocol. Thoughts? PatC ------_=_NextPart_001_01C479E4.AF4A19F0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable So many architectures, so little time... - take 2

I think single protocol is the = easy part. Pat’s suggestion definitely works. But to support interoperability with = multiple architectures, I think it is important to clearly define the = functionality of WTP and AC and have a protocol for AC and WTP to negotiate/advertise their = capability.

 

=

 

=

Victor

=

 

=

From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun
Sent: Tuesday, August = 03, 2004 3:04 PM
To: Yang, Lily L; James = Kempf; Dorothy.Gellert@nokia.com; capwap@frascone.com
Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com
Subject: [Capwap] So = many architectures, so little time... - take 2

 

After reading Lily's response to Jim, I realize that I fell down the same = trap. Local MAC
is also a centralized approach, and so my previous response was not = complete. I believe the
real question, in my mind, is whether we need to address either the = Local or the Split MAC
architecture.

Just looking at the Architecture Consideration tables (7 and 10) in the specification, the
main difference (at a high level) between both approaches is where the = 802.11 management
terminates. For Local MAC, it's in the WTP, while for SPlit MAC, it's = in the AC.

However, looking at table 8, most Local MAC approaches share STA state = between both the WTP
and the AC. So clearly there is some signalling protocol between both = the WTP and the AC.

Looking at one example of a Local MAC protocol (see http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt= ), there is a protocol message
that corresponds for every 802.11 MAC management event. So when a STA associates, the AP breaks
the message apart and creates an new protocol PDU, which contains = components found in the association
request. I suspect that most Local MAC approaches do something very = similar.

So if a protocol simply tunnels the 802.11 MAC management frames from = the WTP to the AC, it allows
supports both approaches. For Local MAC, they get what they want via = the 802.11 frame, and this
also works fine for Split MAC, which needs access to the MAC management = frame. What would be required
in such a protocol is a way for the AP to communicate whether it will = be providing very specific
functions - basically a capabilities negotiation approach.

So I do believe that there is a way to address both architectures using = a single protocol.

Thoughts?

PatC

------_=_NextPart_001_01C479E4.AF4A19F0-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Aug 4 07:03:45 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26920 for ; Wed, 4 Aug 2004 07:03:45 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 582C4207AA; Wed, 4 Aug 2004 06:49:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 76E7B21216; Wed, 4 Aug 2004 06:49:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 912172120E for ; Wed, 4 Aug 2004 06:48:58 -0400 (EDT) Received: from out009.verizon.net (out009pub.verizon.net [206.46.170.131]) by mail.frascone.com (Postfix) with ESMTP id D1DAD207AA for ; Wed, 4 Aug 2004 06:48:56 -0400 (EDT) Received: from Matt-Holdrege.verizon.net ([62.188.142.104]) by out009.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040804110332.XSXY23440.out009.verizon.net@Matt-Holdrege.verizon.net>; Wed, 4 Aug 2004 06:03:32 -0500 Message-Id: <6.1.0.6.2.20040804130124.02182f08@incoming.verizon.net> X-Sender: res06gzk@incoming.verizon.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 To: "James Kempf" , From: Matt Holdrege Subject: Re: [Capwap] Re: So many architectures, so little time... In-Reply-To: <042201c479d8$b1bbaca0$936015ac@dcml.docomolabsusa.com> References: <2AF68A477DD44C4EBCBE338C24E7A9EE01B57E86@orsmsx408> <042201c479d8$b1bbaca0$936015ac@dcml.docomolabsusa.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authentication-Info: Submitted using SMTP AUTH at out009.verizon.net from [62.188.142.104] at Wed, 4 Aug 2004 06:03:29 -0500 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, 04 Aug 2004 13:03:24 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Why? Changes from one MAC to another are completely covered in 802. At 06:08 AM 8/4/2004, James Kempf wrote: >I think more to the point is that a wireless multihop backhaul probably will >require some changes at the MAC level, and 802.11s isn't there yet. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Aug 4 10:00:45 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05978 for ; Wed, 4 Aug 2004 10:00:45 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3B38421A3C; Wed, 4 Aug 2004 09:46:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 82C7D21A48; Wed, 4 Aug 2004 09:46:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4884021A48 for ; Wed, 4 Aug 2004 09:45:48 -0400 (EDT) Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mail.frascone.com (Postfix) with ESMTP id 6CB7721A3C for ; Wed, 4 Aug 2004 09:45:46 -0400 (EDT) Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id E6106DE53; Wed, 4 Aug 2004 14:00:15 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id 8F31FF599; Wed, 4 Aug 2004 14:00:15 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 5781912302; Wed, 4 Aug 2004 14:00:15 +0000 (UTC) Received: from mail1.dlh.st.com (mail1.dlh.st.com [138.198.194.102]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 4B722F59F; Wed, 4 Aug 2004 14:00:10 +0000 (GMT) Received: from DLHTPANWPC9 (dlhtpanwpc09.dlh.st.com [10.180.4.9]) by mail1.dlh.st.com (MOS 3.4.4-GR) with ESMTP id AEO08033 (AUTH "peyush agarwal"); Wed, 4 Aug 2004 19:30:08 +0530 (IST) From: Peyush AGARWAL To: "'Yang, Lily L'" , "'James Kempf'" , , Cc: , , Subject: RE: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP WG Mtg Message-ID: <004701c47a2b$5ad86510$0904b40a@dlh.st.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal In-Reply-To: <2AF68A477DD44C4EBCBE338C24E7A9EE01B57A0B@orsmsx408> 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, 4 Aug 2004 19:30:09 +0530 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable A bit of suggestion: We can target to achieve interoperability between Autonomous & = Centralized Architecture family in the initial stages of the draft! -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Yang, Lily L Sent: Wednesday, August 04, 2004 2:02 AM To: James Kempf; Dorothy.Gellert@nokia.com; capwap@frascone.com Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com Subject: RE: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP = WG Mtg I agree that there is an important decision to be made when we recharter = the group, to decide what kind of interoperability we want across what architecture variants.=20 But I believe James's summary of the architecture taxonomy is not = completely correct. The taxonomy classified the existing/emerging architecture = spectrum as the following: +----------------+ |Autonomous | +---------->|Architecture | | |Family | | +----------------+ | +--------------+ | |Local | | +---->|MAC | | | |Architecture | | | +--------------+ | | | +----------------+ | +--------------+ | |Centralized | | |Split | +---------->|Architecture |--+---->|MAC | | |Family | | |Architecture | | +----------------+ | +--------------+ | | | | +--------------+ | | |Remote | | +---->|MAC | | |Architecture | | +--------------+ | +----------------+ | |Distributed Mesh| +---------->|Architecture | |Family | +----------------+ So we have to explicitly decide what kind of interoperability we want to achieve in this picture. It seems like a relatively easier decision at = the first level. Autonomous Architecture doesn't need any further protocol. = One example of the Distributed Architecture -- 802.11 mesh -- is being = developed by IEEE 802.11 TGs, and it is not yet clear how much of the = control/config aspect will be included in that effort. Centralized architecture is = where we hear the interoperability demand the most.=20 Now within the Centralized architecture, there is a harder question to answer: what kind of interoperability we want? Across all 3 = sub-categories with one protocol? Does that make sense, eps. If different sub-category suits for different deployment scenarios? Is it technically feasible to = have one fit all? Or is it acceptable to have only interoperability within = each sub-category? Should this group work on all 3? Or 1? 2? One option for the WG is to only draw the scope boundary around = Centralized Architecture, but not dictating whether or not we should develop one solution for all, or separate solution for each one. If people can come = up with solutions/proposals to solve interoperability across 3, I don't see = why we shouldn't allow them to try. On the other hand, if people have strong proposals for each individual sub-category, that should be allowed too. = The WG can evaluate all the options and then decide. Another option is to decide on the exact extend of interoperability now, = and only accept proposals that work for it. I am not advocating any particular option in this email, but just want = to point out that these are the questions we need to ponder upon when we discuss rechartering. Lily -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of James Kempf Sent: Tuesday, August 03, 2004 11:17 AM To: Dorothy.Gellert@nokia.com; capwap@frascone.com Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com Subject: Re: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP = WG Mtg Dorothy, Thanx for sending out this proposal. I looked through part of the draft = and the proposal, and I have a (somewhat long) comment on the suggested recharter. There is an assumption in the recharter that there will be a single = CAPWAP protocol. From the taxonomy document (part of which I briefly skimmed), = it looks to me like there are three basic architectural approaches = currently in the market: 1) the traditional MAC architecture, 2) the SplitMAC architecture in which the WTPs only implement delay sensitive functions = and the rest are implemented on the ACs, and 3) the RemoteMAC architecture, where all the MAC functions are implemented in the ACs. 1) seems to me like it would be pretty much out of scope for a = recharter, since there is not any need for additional protocol work on an = interoperable access network protocol in traditional APs (but perhaps I'm missing something) because APs from different vendors exist today that interoperate. 2) and 3), however, seem to be to be two separate and largely = incompatible architectures that represent two classes of products which could benefit from having an interoperable protocol between products in the class, but probably wouldn't benefit much from interoperability between classes. In the cellular world, there are two similar classes of products used = for, for example, UMTS deployment. The best known is the RNC/Node B/UTRAN solution which is similar to SplitMAC in which a network controller runs = a protocol over the access network that controls radio access points, but there's another solution, similar to RemoteMAC, in which wCDMA runs over fiber from what is essentially just a smart antenna doing PHY to PHY conversion to the controller. This latter solution has benefits in = certain deployment situations, but requires lots of bandwidth on the link = between the smart antenna and the controller, which might not be available in = many cases. As far as I know, the two are really for different incompatible deployment cases and don't interoperate on the access network between = the base station/access point and the controller. I would imagine that there are likely to be incompatible deployment situations in the WLAN world that would benefit more from one or the = other of these solutions too. I think the recharter discussion needs to make a decision first whether there is need for interoperability between these two classes of = products, and, if not, whether there is a need for interoperable protocol work between products in the same class for both classes, or whether only the class with the most need for an interoperable protocol should be = focussed on. I have some opinions about this, but I will wait until the = discussion tomorrow to express them. In addition, I think the WG chairs need to talk with the IESG about the right Area for this work, should the IESG agree to a recharter, since = the scope of a protocol development effort for an access network control protocol seems like it might get a bit outside the Ops Area charter. Personally, I have some doubts about whether a recharter will be = approved, since there may be a significant component of work in actual protocol development that involves decisions about MAC level functions, but = perhaps we can get enough IEEE involvement to allow the work to proceed in IETF. It's a tough problem organizationally, because the technology spans both groups. jak ----- Original Message -----=20 From: To: ; Cc: ; ; Sent: Monday, August 02, 2004 10:29 PM Subject: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP WG = Mtg Ok, This time with the attachment.... -Dorothy <> > -----Original Message----- > From: Gellert Dorothy (Nokia-ES/MtView) > Sent: Monday, August 02, 2004 10:28 PM > To: 'capwap@frascone.com' > Cc: Bert Wijnen (E-mail); Mani Mahalingam (E-mail); Kessens David=20 > (Nokia-NET/MtView) > Subject: Re-charter proposal text to discuss at CAPWAP WG Mtg > > > Attached is the CAPWAP WG Re-charter proposal we will review on=20 > Wednesday during the CAPWAP WG meeting. Please review and provide=20 > comments on the process going forward, deliverables and timeline=20 > suggested. > > Most of the WG meeting is dedicated to open discussion on how to=20 > re-charter, so bring your comments! > > -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 From capwap-admin@frascone.com Wed Aug 4 10:22:51 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08397 for ; Wed, 4 Aug 2004 10:22:50 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F3E0420197; Wed, 4 Aug 2004 10:08:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4A79520AA9; Wed, 4 Aug 2004 10:08:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 18FCF20C1E for ; Wed, 4 Aug 2004 10:07:12 -0400 (EDT) Received: from aruba-server.arubanetworks.com (mail.arubanetworks.com [64.60.249.195]) by mail.frascone.com (Postfix) with SMTP id BEC9620AA9 for ; Wed, 4 Aug 2004 10:07:10 -0400 (EDT) Received: from [10.3.9.211] ([10.3.9.211] unverified) by aruba-server.arubanetworks.com over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Wed, 4 Aug 2004 07:21:41 -0700 Subject: RE: [Capwap] So many architectures, so little time... - take 2 From: Partha Narasimhan To: Inderpreet Singh Cc: capwap@frascone.com, bwijnen@lucent.com, mmani@avaya.com, david.kessens@nokia.com, Dorothy.Gellert@nokia.com In-Reply-To: <002301c479dd$106b7e70$6a05a8c0@toronto.chantrynetworks.com> References: <002301c479dd$106b7e70$6a05a8c0@toronto.chantrynetworks.com> Content-Type: text/plain Organization: Aruba Wireless Networks, Inc. Message-Id: <1091629276.2148.187.camel@sap1.arubanetworks.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Aug 2004 14:21:41.0906 (UTC) FILETIME=[5CE8C720:01C47A2E] X-NAI-Spam-Flag: NO X-NAI-Spam-Score: -4.6 X-NAI-Spam-Threshold: 5 X-NAI-Spam-Report: 2 Rules triggered * -4.9 -- BAYES_00 -- Bayesian spam probability is 0 to 1% * 0.3 -- AWL -- Auto-whitelist adjustment X-NAI-Spam-Checker-Version: NAI SpamAssassin 1.2 (core version 2.70 date 20031104 serial 1200) 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, 04 Aug 2004 07:21:30 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit If we all agree that a common protocol would work for both the local MAC and the split MAC architectures, then I propose that we work on this as a joint problem instead of doing one before the other. This avoids either - having to go back and attempt to change what was done at step 1 while working on step 2, or - work completed in step 1 constraining what is possible in step 2. Thanks partha On Tue, 2004-08-03 at 21:39, Inderpreet Singh wrote: > The issue(s) at hand and my opinions are: > > 1. Do we explicitly state in the re-charter which architecture the WG > should consider? > I think yes. I propose Centralized architecture only. > Autonomous and Distributed should be out of scope based on the same > reasons as per prior postings. > > 2. Within Centralized do we focus on all three sub architectures or a > subset? > Remote MAC should be excluded because if I am not mistaken, the > connectivity constraint between the WTP and the AC is "direct connect". > That being the case and that no IP layer is involved, it doesn't seem > clear what kind of protocol would help with interoperability. > I am concerned about the impact, dependencies and interaction > with the recently constituted IEEE Study group on AP functionality on > the Split MAC architectures. Furthermore, there are some pretty drastic > differences on how the vendors have chosen to split the mac. Those > differences will need to be worked out before designing a protocol. So, > if the low hanging fruit strategy (as James suggested) for protocol > development and progress is the way to go, then I think prioritizing on > a protocol for Local MAC is a no brainer. So as far as focus, I feel we > should do Local and Split and in that order. > > 3. This is not a re-chartering issue but is a response to Pat's > suggestion that a protocol that just sends the 802.11 MAC frames from > the AP to the AC would work. I think possibly, yes. But again the > complications of splitting the MAC in an interoperable way will be an > issue. Also, you may note in the draft to which you refer, we included > a capabilities exchange phase. I had thought of including in the > capability exchange such things as "AP supports Local MAC" and "AP > supports Split MAC", but didn't put it in because the Taxonomy work was > still in progress. Now that it is pretty much done we could surely > include that. But again...let's recharter first. > > Thanks. Do people agree with 1 & 2? > > --- > Inderpreet Singh > Chantry Networks > isingh@chantrynetworks.com > Cell: 416-831-3705 > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Pat R. Calhoun > Sent: Tuesday, August 03, 2004 6:04 PM > To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com; > capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > Subject: [Capwap] So many architectures, so little time... - take 2 > > After reading Lily's response to Jim, I realize that I fell down the > same trap. Local MAC > is also a centralized approach, and so my previous response was not > complete. I believe the > real question, in my mind, is whether we need to address either the > Local or the Split MAC > architecture. > > Just looking at the Architecture Consideration tables (7 and 10) in the > specification, the > main difference (at a high level) between both approaches is where the > 802.11 management > terminates. For Local MAC, it's in the WTP, while for SPlit MAC, it's in > the AC. > > However, looking at table 8, most Local MAC approaches share STA state > between both the WTP > and the AC. So clearly there is some signalling protocol between both > the WTP and the AC. > > Looking at one example of a Local MAC protocol (see > http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > there is a protocol message > that corresponds for every 802.11 MAC management event. So when a STA > associates, the AP breaks > the message apart and creates an new protocol PDU, which contains > components found in the association > request. I suspect that most Local MAC approaches do something very > similar. > > So if a protocol simply tunnels the 802.11 MAC management frames from > the WTP to the AC, it allows > supports both approaches. For Local MAC, they get what they want via the > 802.11 frame, and this > also works fine for Split MAC, which needs access to the MAC management > frame. What would be required > in such a protocol is a way for the AP to communicate whether it will be > providing very specific > functions - basically a capabilities negotiation approach. > > So I do believe that there is a way to address both architectures using > a single protocol. > > Thoughts? > > PatC > > _______________________________________________ > 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 Aug 4 10:32:47 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08991 for ; Wed, 4 Aug 2004 10:32:44 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E230B20242; Wed, 4 Aug 2004 10:18:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 64E91205D5; Wed, 4 Aug 2004 10:18:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 364C2205D5 for ; Wed, 4 Aug 2004 10:17:42 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id DEF3520242 for ; Wed, 4 Aug 2004 10:17:39 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C47A30.4292DF95" Subject: RE: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP WG Mtg Message-ID: <55749BC69138654EBBC4C50BA4F55610020C448D@AIREMAIL.airespace.com> Thread-Topic: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP WG Mtg Thread-Index: AcR6K93hI4pEAg5fQfqL5rv8dFNL5QABFj6O From: "Pat R. Calhoun" To: "Peyush AGARWAL" , "Yang, Lily L" , "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: Wed, 4 Aug 2004 07:34:57 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C47A30.4292DF95 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable But you get Autonomous interoperability by default, no? PatC -----Original Message----- From: capwap-admin@frascone.com on behalf of Peyush AGARWAL Sent: Wed 8/4/2004 7:00 AM To: 'Yang, Lily L'; 'James Kempf'; Dorothy.Gellert@nokia.com; = capwap@frascone.com Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com Subject: RE: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP = WG Mtg =20 A bit of suggestion: We can target to achieve interoperability between Autonomous & = Centralized Architecture family in the initial stages of the draft! -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Yang, Lily L Sent: Wednesday, August 04, 2004 2:02 AM To: James Kempf; Dorothy.Gellert@nokia.com; capwap@frascone.com Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com Subject: RE: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP = WG Mtg I agree that there is an important decision to be made when we recharter = the group, to decide what kind of interoperability we want across what architecture variants.=20 But I believe James's summary of the architecture taxonomy is not = completely correct. The taxonomy classified the existing/emerging architecture = spectrum as the following: +----------------+ |Autonomous | +---------->|Architecture | | |Family | | +----------------+ | +--------------+ | |Local | | +---->|MAC | | | |Architecture | | | +--------------+ | | | +----------------+ | +--------------+ | |Centralized | | |Split | +---------->|Architecture |--+---->|MAC | | |Family | | |Architecture | | +----------------+ | +--------------+ | | | | +--------------+ | | |Remote | | +---->|MAC | | |Architecture | | +--------------+ | +----------------+ | |Distributed Mesh| +---------->|Architecture | |Family | +----------------+ So we have to explicitly decide what kind of interoperability we want to achieve in this picture. It seems like a relatively easier decision at = the first level. Autonomous Architecture doesn't need any further protocol. = One example of the Distributed Architecture -- 802.11 mesh -- is being = developed by IEEE 802.11 TGs, and it is not yet clear how much of the = control/config aspect will be included in that effort. Centralized architecture is = where we hear the interoperability demand the most.=20 Now within the Centralized architecture, there is a harder question to answer: what kind of interoperability we want? Across all 3 = sub-categories with one protocol? Does that make sense, eps. If different sub-category suits for different deployment scenarios? Is it technically feasible to = have one fit all? Or is it acceptable to have only interoperability within = each sub-category? Should this group work on all 3? Or 1? 2? One option for the WG is to only draw the scope boundary around = Centralized Architecture, but not dictating whether or not we should develop one solution for all, or separate solution for each one. If people can come = up with solutions/proposals to solve interoperability across 3, I don't see = why we shouldn't allow them to try. On the other hand, if people have strong proposals for each individual sub-category, that should be allowed too. = The WG can evaluate all the options and then decide. Another option is to decide on the exact extend of interoperability now, = and only accept proposals that work for it. I am not advocating any particular option in this email, but just want = to point out that these are the questions we need to ponder upon when we discuss rechartering. Lily -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of James Kempf Sent: Tuesday, August 03, 2004 11:17 AM To: Dorothy.Gellert@nokia.com; capwap@frascone.com Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com Subject: Re: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP = WG Mtg Dorothy, Thanx for sending out this proposal. I looked through part of the draft = and the proposal, and I have a (somewhat long) comment on the suggested recharter. There is an assumption in the recharter that there will be a single = CAPWAP protocol. From the taxonomy document (part of which I briefly skimmed), = it looks to me like there are three basic architectural approaches = currently in the market: 1) the traditional MAC architecture, 2) the SplitMAC architecture in which the WTPs only implement delay sensitive functions = and the rest are implemented on the ACs, and 3) the RemoteMAC architecture, where all the MAC functions are implemented in the ACs. 1) seems to me like it would be pretty much out of scope for a = recharter, since there is not any need for additional protocol work on an = interoperable access network protocol in traditional APs (but perhaps I'm missing something) because APs from different vendors exist today that interoperate. 2) and 3), however, seem to be to be two separate and largely = incompatible architectures that represent two classes of products which could benefit from having an interoperable protocol between products in the class, but probably wouldn't benefit much from interoperability between classes. In the cellular world, there are two similar classes of products used = for, for example, UMTS deployment. The best known is the RNC/Node B/UTRAN solution which is similar to SplitMAC in which a network controller runs = a protocol over the access network that controls radio access points, but there's another solution, similar to RemoteMAC, in which wCDMA runs over fiber from what is essentially just a smart antenna doing PHY to PHY conversion to the controller. This latter solution has benefits in = certain deployment situations, but requires lots of bandwidth on the link = between the smart antenna and the controller, which might not be available in = many cases. As far as I know, the two are really for different incompatible deployment cases and don't interoperate on the access network between = the base station/access point and the controller. I would imagine that there are likely to be incompatible deployment situations in the WLAN world that would benefit more from one or the = other of these solutions too. I think the recharter discussion needs to make a decision first whether there is need for interoperability between these two classes of = products, and, if not, whether there is a need for interoperable protocol work between products in the same class for both classes, or whether only the class with the most need for an interoperable protocol should be = focussed on. I have some opinions about this, but I will wait until the = discussion tomorrow to express them. In addition, I think the WG chairs need to talk with the IESG about the right Area for this work, should the IESG agree to a recharter, since = the scope of a protocol development effort for an access network control protocol seems like it might get a bit outside the Ops Area charter. Personally, I have some doubts about whether a recharter will be = approved, since there may be a significant component of work in actual protocol development that involves decisions about MAC level functions, but = perhaps we can get enough IEEE involvement to allow the work to proceed in IETF. It's a tough problem organizationally, because the technology spans both groups. jak ----- Original Message -----=20 From: To: ; Cc: ; ; Sent: Monday, August 02, 2004 10:29 PM Subject: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP WG = Mtg Ok, This time with the attachment.... -Dorothy <> > -----Original Message----- > From: Gellert Dorothy (Nokia-ES/MtView) > Sent: Monday, August 02, 2004 10:28 PM > To: 'capwap@frascone.com' > Cc: Bert Wijnen (E-mail); Mani Mahalingam (E-mail); Kessens David=20 > (Nokia-NET/MtView) > Subject: Re-charter proposal text to discuss at CAPWAP WG Mtg > > > Attached is the CAPWAP WG Re-charter proposal we will review on=20 > Wednesday during the CAPWAP WG meeting. Please review and provide=20 > comments on the process going forward, deliverables and timeline=20 > suggested. > > Most of the WG meeting is dedicated to open discussion on how to=20 > re-charter, so bring your comments! > > -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 ------_=_NextPart_001_01C47A30.4292DF95 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP WG = Mtg

But you get Autonomous interoperability by default, = no?

PatC
-----Original Message-----
From: capwap-admin@frascone.com on behalf of Peyush AGARWAL
Sent: Wed 8/4/2004 7:00 AM
To: 'Yang, Lily L'; 'James Kempf'; Dorothy.Gellert@nokia.com; = capwap@frascone.com
Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com
Subject: RE: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP = WG Mtg

A bit of suggestion:
We can target to achieve interoperability between Autonomous & = Centralized
Architecture family in the initial stages of the draft!


-----Original Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On Behalf
Of Yang, Lily L
Sent: Wednesday, August 04, 2004 2:02 AM
To: James Kempf; Dorothy.Gellert@nokia.com; capwap@frascone.com
Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com
Subject: RE: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP = WG
Mtg


I agree that there is an important decision to be made when we recharter = the
group, to decide what kind of interoperability we want across what
architecture variants.

But I believe James's summary of the architecture taxonomy is not = completely
correct. The taxonomy classified the existing/emerging architecture = spectrum
as the following:
            &= nbsp;    +----------------+
            &= nbsp;    |Autonomous      |
     +---------->|Architecture    = |
     = |           = |Family          |
     = |           = +----------------+
     = |            =             &= nbsp;            = +--------------+
     = |            =             &= nbsp;            = |Local         |
     = |            =             &= nbsp;      = +---->|MAC          = |
     = |            =             &= nbsp;      |     = |Architecture  |
     = |            =             &= nbsp;      |     = +--------------+
     = |            =             &= nbsp;      |
     = |           = +----------------+  |     +--------------+
     = |           = |Centralized     |  |     = |Split         |
     +---------->|Architecture    = |--+---->|MAC         &nb= sp; |
     = |           = |Family          |  = |     |Architecture  |
     = |           = +----------------+  |     +--------------+
     = |            =             &= nbsp;      |
     = |            =             &= nbsp;      |     = +--------------+
     = |            =             &= nbsp;      |     = |Remote        |
     = |            =             &= nbsp;      = +---->|MAC          = |
     = |            =             &= nbsp;            = |Architecture  |
     = |            =             &= nbsp;            = +--------------+
     = |           = +----------------+
     = |           = |Distributed Mesh|
     +---------->|Architecture    = |
            &= nbsp;    = |Family          |
            &= nbsp;    +----------------+

So we have to explicitly decide what kind of interoperability we want = to
achieve in this picture. It seems like a relatively easier decision at = the
first level. Autonomous Architecture doesn't need any further protocol. = One
example of the Distributed Architecture -- 802.11 mesh -- is being = developed
by IEEE 802.11 TGs, and it is not yet clear how much of the = control/config
aspect will be included in that effort. Centralized architecture is = where we
hear the interoperability demand the most.
Now within the Centralized architecture, there is a harder question = to
answer: what kind of interoperability we want? Across all 3 = sub-categories
with one protocol? Does that make sense, eps. If different = sub-category
suits for different deployment scenarios? Is it technically feasible to = have
one fit all? Or is it acceptable to have only interoperability within = each
sub-category? Should this group work on all 3? Or 1? 2?

One option for the WG is to only draw the scope boundary around = Centralized
Architecture, but not dictating whether or not we should develop one
solution for all, or separate solution for each one. If people can come = up
with solutions/proposals to solve interoperability across 3, I don't see = why
we shouldn't allow them to try. On the other hand, if people have = strong
proposals for each individual sub-category, that should be allowed too. = The
WG can evaluate all the options and then decide.

Another option is to decide on the exact extend of interoperability now, = and
only accept proposals that work for it.

I am not advocating any particular option in this email, but just want = to
point out that these are the questions we need to ponder upon when = we
discuss rechartering.

Lily

-----Original Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On Behalf
Of James Kempf
Sent: Tuesday, August 03, 2004 11:17 AM
To: Dorothy.Gellert@nokia.com; capwap@frascone.com
Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com
Subject: Re: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP = WG
Mtg

Dorothy,

Thanx for sending out this proposal. I looked through part of the draft = and
the proposal, and I have a (somewhat long) comment on the suggested
recharter.

There is an assumption in the recharter that there will be a single = CAPWAP
protocol. From the taxonomy document (part of which I briefly skimmed), = it
looks to me like there are three basic architectural approaches = currently in
the market: 1) the traditional MAC architecture, 2) the SplitMAC
architecture in which the WTPs only implement delay sensitive functions = and
the rest are implemented on the ACs, and 3) the RemoteMAC = architecture,
where all the MAC functions are implemented in the ACs.

1) seems to me like it would be pretty much out of scope for a = recharter,
since there is not any need for additional protocol work on an = interoperable
access network protocol in traditional APs (but perhaps I'm missing
something)  because APs from different vendors exist today that
interoperate.

2) and 3), however, seem to be to be two separate and largely = incompatible
architectures that represent two classes of products which could = benefit
from having an interoperable protocol between products in the class, = but
probably wouldn't benefit much from interoperability between = classes.

In the cellular world, there are two similar classes of products used = for,
for example, UMTS deployment. The best known is the RNC/Node B/UTRAN
solution which is similar to SplitMAC in which a network controller runs = a
protocol over the access network that controls radio access points, = but
there's another solution, similar to RemoteMAC, in which wCDMA runs = over
fiber from what is essentially just a smart antenna doing PHY to PHY
conversion to the controller. This latter solution has benefits in = certain
deployment situations, but requires lots of bandwidth on the link = between
the smart antenna and the controller, which might not be available in = many
cases. As far as I know, the two are really for different = incompatible
deployment cases and don't interoperate on the access network between = the
base station/access point and the controller.

I would imagine that there are likely to be incompatible deployment
situations in the WLAN world that would benefit more from one or the = other
of these solutions too.

I think the recharter discussion needs to make a decision first = whether
there is need for interoperability between these two classes of = products,
and, if not,  whether there is a need for interoperable protocol = work
between products in the same class for both classes, or whether only = the
class with the most need for an interoperable protocol should be = focussed
on. I have some opinions about this, but I will wait until the = discussion
tomorrow to express them.

In addition, I think the WG chairs need to talk with the IESG about = the
right Area for this work, should the IESG agree to a recharter, since = the
scope of a protocol development effort for an access network control
protocol seems like it might get a bit outside the Ops Area charter.
Personally, I have some doubts about whether a recharter will be = approved,
since there may be a significant component of work in actual = protocol
development that involves decisions about MAC level functions, but = perhaps
we can get enough IEEE involvement to allow the work to proceed in = IETF.
It's a tough problem organizationally, because the technology spans = both
groups.

            &= nbsp;          jak

----- Original Message -----
From: <Dorothy.Gellert@nokia.com>
To: <Dorothy.Gellert@nokia.com>; <capwap@frascone.com>
Cc: <bwijnen@lucent.com>; <mmani@avaya.com>; = <david.kessens@nokia.com>
Sent: Monday, August 02, 2004 10:29 PM
Subject: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP WG = Mtg


Ok,  This time with the attachment....

-Dorothy

 <<recharter for CAPWAP_06.txt>>

>  -----Original Message-----
> From: Gellert Dorothy (Nokia-ES/MtView)
> Sent: Monday, August 02, 2004 10:28 PM
> To: 'capwap@frascone.com'
> Cc: Bert Wijnen (E-mail); Mani Mahalingam (E-mail); Kessens = David
> (Nokia-NET/MtView)
> Subject: Re-charter proposal text to discuss at CAPWAP WG Mtg
>
>
> Attached is the CAPWAP WG Re-charter proposal we will review on
> Wednesday during the CAPWAP WG meeting. Please review and = provide
> comments on the process going forward, deliverables and = timeline
> suggested.
>
> Most of the WG meeting is dedicated to open discussion on how = to
> re-charter, so bring your comments!
>
> -Dorothy and Mani


_______________________________________________
Capwap mailing list
Capwap@frascone.com http://mail.fra= scone.com/mailman/listinfo/capwap
_______________________________________________
Capwap mailing list
Capwap@frascone.com http://mail.fra= scone.com/mailman/listinfo/capwap

_______________________________________________
Capwap mailing list
Capwap@frascone.com
http://mail.fra= scone.com/mailman/listinfo/capwap

------_=_NextPart_001_01C47A30.4292DF95-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Aug 4 10:33:55 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09086 for ; Wed, 4 Aug 2004 10:33:54 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 17F2321A59; Wed, 4 Aug 2004 10:19:14 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F3D0821A5A; Wed, 4 Aug 2004 10:19:08 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4C75320D2E for ; Wed, 4 Aug 2004 10:18:43 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id 20EE620AA9 for ; Wed, 4 Aug 2004 10:18:41 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C47A30.65D0A1E5" Subject: RE: [Capwap] So many architectures, so little time... - take 2 Message-ID: <55749BC69138654EBBC4C50BA4F55610020C448E@AIREMAIL.airespace.com> Thread-Topic: [Capwap] So many architectures, so little time... - take 2 Thread-Index: AcR6LwMKeRU4bRznTDqWUJcdXe1yuAAAVqJm From: "Pat R. Calhoun" To: "Partha Narasimhan" , "Inderpreet Singh" 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: Wed, 4 Aug 2004 07:36:02 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C47A30.65D0A1E5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A fine suggestion. PatC -----Original Message----- From: capwap-admin@frascone.com on behalf of Partha Narasimhan Sent: Wed 8/4/2004 7:21 AM To: Inderpreet Singh Cc: capwap@frascone.com; bwijnen@lucent.com; mmani@avaya.com; = david.kessens@nokia.com; Dorothy.Gellert@nokia.com Subject: RE: [Capwap] So many architectures, so little time... - take 2 =20 If we all agree that a common protocol would work for both the local MAC and the split MAC architectures, then I propose that we work on this as a joint problem instead of doing one before the other. This avoids either =20 - having to go back and attempt to change what was done at step 1 while working on step 2, or - work completed in step 1 constraining what is possible in step 2.=20 Thanks partha On Tue, 2004-08-03 at 21:39, Inderpreet Singh wrote: > The issue(s) at hand and my opinions are: >=20 > 1. Do we explicitly state in the re-charter which architecture the WG > should consider? > I think yes. I propose Centralized architecture only. > Autonomous and Distributed should be out of scope based on the same > reasons as per prior postings. >=20 > 2. Within Centralized do we focus on all three sub architectures or a > subset? > Remote MAC should be excluded because if I am not mistaken, the > connectivity constraint between the WTP and the AC is "direct = connect". > That being the case and that no IP layer is involved, it doesn't seem > clear what kind of protocol would help with interoperability. > I am concerned about the impact, dependencies and interaction > with the recently constituted IEEE Study group on AP functionality on > the Split MAC architectures. Furthermore, there are some pretty = drastic > differences on how the vendors have chosen to split the mac. Those > differences will need to be worked out before designing a protocol. = So, > if the low hanging fruit strategy (as James suggested) for protocol > development and progress is the way to go, then I think prioritizing = on > a protocol for Local MAC is a no brainer. So as far as focus, I feel = we > should do Local and Split and in that order. >=20 > 3. This is not a re-chartering issue but is a response to Pat's > suggestion that a protocol that just sends the 802.11 MAC frames from > the AP to the AC would work. I think possibly, yes. But again the > complications of splitting the MAC in an interoperable way will be an > issue. Also, you may note in the draft to which you refer, we = included > a capabilities exchange phase. I had thought of including in the > capability exchange such things as "AP supports Local MAC" and "AP > supports Split MAC", but didn't put it in because the Taxonomy work = was > still in progress. Now that it is pretty much done we could surely > include that. But again...let's recharter first. >=20 > Thanks. Do people agree with 1 & 2? >=20 > --- > Inderpreet Singh > Chantry Networks > isingh@chantrynetworks.com > Cell: 416-831-3705 >=20 > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Pat R. Calhoun > Sent: Tuesday, August 03, 2004 6:04 PM > To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com; > capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > Subject: [Capwap] So many architectures, so little time... - take 2 >=20 > After reading Lily's response to Jim, I realize that I fell down the > same trap. Local MAC > is also a centralized approach, and so my previous response was not > complete. I believe the > real question, in my mind, is whether we need to address either the > Local or the Split MAC > architecture. >=20 > Just looking at the Architecture Consideration tables (7 and 10) in = the > specification, the > main difference (at a high level) between both approaches is where the > 802.11 management > terminates. For Local MAC, it's in the WTP, while for SPlit MAC, it's = in > the AC. >=20 > However, looking at table 8, most Local MAC approaches share STA state > between both the WTP > and the AC. So clearly there is some signalling protocol between both > the WTP and the AC. >=20 > Looking at one example of a Local MAC protocol (see > http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > there is a protocol message > that corresponds for every 802.11 MAC management event. So when a STA > associates, the AP breaks > the message apart and creates an new protocol PDU, which contains > components found in the association > request. I suspect that most Local MAC approaches do something very > similar. >=20 > So if a protocol simply tunnels the 802.11 MAC management frames from > the WTP to the AC, it allows > supports both approaches. For Local MAC, they get what they want via = the > 802.11 frame, and this > also works fine for Split MAC, which needs access to the MAC = management > frame. What would be required > in such a protocol is a way for the AP to communicate whether it will = be > providing very specific > functions - basically a capabilities negotiation approach. >=20 > So I do believe that there is a way to address both architectures = using > a single protocol. >=20 > Thoughts? >=20 > PatC=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 ------_=_NextPart_001_01C47A30.65D0A1E5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Capwap] So many architectures, so little time... - take = 2

A fine suggestion.

PatC


-----Original Message-----
From: capwap-admin@frascone.com on behalf of Partha Narasimhan
Sent: Wed 8/4/2004 7:21 AM
To: Inderpreet Singh
Cc: capwap@frascone.com; bwijnen@lucent.com; mmani@avaya.com; = david.kessens@nokia.com; Dorothy.Gellert@nokia.com
Subject: RE: [Capwap] So many architectures, so little time... - take = 2

If we all agree that a common protocol would work for both the local = MAC
and the split MAC architectures, then I propose that we work on this = as
a joint problem instead of doing one before the other. This avoids
either

- having to go back and attempt to change what was done at step 1 = while
working on step 2, or
- work completed in step 1 constraining what is possible in step 2.

Thanks
partha

On Tue, 2004-08-03 at 21:39, Inderpreet Singh wrote:
> The issue(s) at hand and my opinions are:
>
> 1. Do we explicitly state in the re-charter which architecture the = WG
> should consider?
>       I think yes.  I propose = Centralized architecture only.
> Autonomous and Distributed should be out of scope based on the = same
> reasons as per prior postings.
>
> 2. Within Centralized do we focus on all three sub architectures or = a
> subset?
>       Remote MAC should be excluded = because if I am not mistaken, the
> connectivity constraint between the WTP and the AC is "direct = connect".
> That being the case and that no IP layer is involved, it doesn't = seem
> clear what kind of protocol would help with interoperability.
>       I am concerned about the impact, = dependencies and interaction
> with the recently constituted IEEE Study group on AP functionality = on
> the Split MAC architectures.  Furthermore, there are some = pretty drastic
> differences on how the vendors have chosen to split the mac.  = Those
> differences will need to be worked out before designing a = protocol.  So,
> if the low hanging fruit strategy (as James suggested) for = protocol
> development and progress is the way to go, then I think = prioritizing on
> a protocol for Local MAC is a no brainer.  So as far as focus, = I feel we
> should do Local and Split and in that order.
>
> 3. This is not a re-chartering issue but is a response to Pat's
> suggestion that a protocol that just sends the 802.11 MAC frames = from
> the AP to the AC would work.  I think possibly, yes.  But = again the
> complications of splitting the MAC in an interoperable way will be = an
> issue.  Also, you may note in the draft to which you refer, we = included
> a capabilities exchange phase.  I had thought of including in = the
> capability exchange such things as "AP supports Local = MAC" and "AP
> supports Split MAC", but didn't put it in because the Taxonomy = work was
> still in progress.  Now that it is pretty much done we could = surely
> include that.  But again...let's recharter first.
>
> Thanks.  Do people agree with 1 & 2?
>
> ---
> Inderpreet Singh
> Chantry Networks
> isingh@chantrynetworks.com
> Cell: 416-831-3705
>
> -----Original Message-----
> From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On
> Behalf Of Pat R. Calhoun
> Sent: Tuesday, August 03, 2004 6:04 PM
> To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com;
> capwap@frascone.com
> Cc: bwijnen@lucent.com; mmani@avaya.com; = david.kessens@nokia.com
> Subject: [Capwap] So many architectures, so little time... - take = 2
>
> After reading Lily's response to Jim, I realize that I fell down = the
> same trap. Local MAC
> is also a centralized approach, and so my previous response was = not
> complete. I believe the
> real question, in my mind, is whether we need to address either = the
> Local or the Split MAC
> architecture.
>
> Just looking at the Architecture Consideration tables (7 and 10) in = the
> specification, the
> main difference (at a high level) between both approaches is where = the
> 802.11 management
> terminates. For Local MAC, it's in the WTP, while for SPlit MAC, = it's in
> the AC.
>
> However, looking at table 8, most Local MAC approaches share STA = state
> between both the WTP
> and the AC. So clearly there is some signalling protocol between = both
> the WTP and the AC.
>
> Looking at one example of a Local MAC protocol (see
> http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt),=
> there is a protocol message
> that corresponds for every 802.11 MAC management event. So when a = STA
> associates, the AP breaks
> the message apart and creates an new protocol PDU, which = contains
> components found in the association
> request. I suspect that most Local MAC approaches do something = very
> similar.
>
> So if a protocol simply tunnels the 802.11 MAC management frames = from
> the WTP to the AC, it allows
> supports both approaches. For Local MAC, they get what they want = via the
> 802.11 frame, and this
> also works fine for Split MAC, which needs access to the MAC = management
> frame. What would be required
> in such a protocol is a way for the AP to communicate whether it = will be
> providing very specific
> functions - basically a capabilities negotiation approach.
>
> So I do believe that there is a way to address both architectures = using
> a single protocol.
>
> Thoughts?
>
> PatC
>
> _______________________________________________
> Capwap mailing list
> Capwap@frascone.com
> http://mail.fra= scone.com/mailman/listinfo/capwap

_______________________________________________
Capwap mailing list
Capwap@frascone.com
http://mail.fra= scone.com/mailman/listinfo/capwap

------_=_NextPart_001_01C47A30.65D0A1E5-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Aug 4 12:56:50 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18596 for ; Wed, 4 Aug 2004 12:56:49 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6827521D05; Wed, 4 Aug 2004 12:42:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7861B20E91; Wed, 4 Aug 2004 12:42:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 927DB20E8B for ; Wed, 4 Aug 2004 12:41:37 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 26A0E208F5 for ; Wed, 4 Aug 2004 12:41:35 -0400 (EDT) Message-ID: <002d01c47a44$0dee91c0$966015ac@dcml.docomolabsusa.com> From: "James Kempf" To: , "Matt Holdrege" References: <2AF68A477DD44C4EBCBE338C24E7A9EE01B57E86@orsmsx408> <042201c479d8$b1bbaca0$936015ac@dcml.docomolabsusa.com> <6.1.0.6.2.20040804130124.02182f08@incoming.verizon.net> Subject: Re: [Capwap] Re: So many architectures, so little time... 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, 4 Aug 2004 09:56:55 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit What I had in mind was the following. 802.11s is working on MAC changes for multihop. I think it would be premature to do anything in IETF on multhop until they had completed. And, as a practical matter, I've seen some experimental data (unfortunately not public yet) that indicates changes are needed at the MAC level. But I'm not sure exactly what your question was, so maybe this didn't answer it. jak ----- Original Message ----- From: "Matt Holdrege" To: "James Kempf" ; Sent: Wednesday, August 04, 2004 4:03 AM Subject: Re: [Capwap] Re: So many architectures, so little time... > Why? Changes from one MAC to another are completely covered in 802. > > At 06:08 AM 8/4/2004, James Kempf wrote: > >I think more to the point is that a wireless multihop backhaul probably will > >require some changes at the MAC level, and 802.11s isn't there yet. > > > > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Aug 4 13:03:04 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18959 for ; Wed, 4 Aug 2004 13:03:04 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 87AD020E97; Wed, 4 Aug 2004 12:46:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 13AB1208F5; Wed, 4 Aug 2004 12:46:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9D2AB208F5 for ; Wed, 4 Aug 2004 12:44:46 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id D80CE205E2 for ; Wed, 4 Aug 2004 12:44:43 -0400 (EDT) Message-ID: <004401c47a44$7e89a050$966015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Partha Narasimhan" , "Inderpreet Singh" Cc: , , , , References: <002301c479dd$106b7e70$6a05a8c0@toronto.chantrynetworks.com> <1091629276.2148.187.camel@sap1.arubanetworks.com> Subject: Re: [Capwap] So many architectures, so little time... - take 2 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, 4 Aug 2004 10:00:04 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I agree. jak ----- Original Message ----- From: "Partha Narasimhan" To: "Inderpreet Singh" Cc: ; ; ; ; Sent: Wednesday, August 04, 2004 7:21 AM Subject: RE: [Capwap] So many architectures, so little time... - take 2 > If we all agree that a common protocol would work for both the local MAC > and the split MAC architectures, then I propose that we work on this as > a joint problem instead of doing one before the other. This avoids > either > > - having to go back and attempt to change what was done at step 1 while > working on step 2, or > - work completed in step 1 constraining what is possible in step 2. > > Thanks > partha > > On Tue, 2004-08-03 at 21:39, Inderpreet Singh wrote: > > The issue(s) at hand and my opinions are: > > > > 1. Do we explicitly state in the re-charter which architecture the WG > > should consider? > > I think yes. I propose Centralized architecture only. > > Autonomous and Distributed should be out of scope based on the same > > reasons as per prior postings. > > > > 2. Within Centralized do we focus on all three sub architectures or a > > subset? > > Remote MAC should be excluded because if I am not mistaken, the > > connectivity constraint between the WTP and the AC is "direct connect". > > That being the case and that no IP layer is involved, it doesn't seem > > clear what kind of protocol would help with interoperability. > > I am concerned about the impact, dependencies and interaction > > with the recently constituted IEEE Study group on AP functionality on > > the Split MAC architectures. Furthermore, there are some pretty drastic > > differences on how the vendors have chosen to split the mac. Those > > differences will need to be worked out before designing a protocol. So, > > if the low hanging fruit strategy (as James suggested) for protocol > > development and progress is the way to go, then I think prioritizing on > > a protocol for Local MAC is a no brainer. So as far as focus, I feel we > > should do Local and Split and in that order. > > > > 3. This is not a re-chartering issue but is a response to Pat's > > suggestion that a protocol that just sends the 802.11 MAC frames from > > the AP to the AC would work. I think possibly, yes. But again the > > complications of splitting the MAC in an interoperable way will be an > > issue. Also, you may note in the draft to which you refer, we included > > a capabilities exchange phase. I had thought of including in the > > capability exchange such things as "AP supports Local MAC" and "AP > > supports Split MAC", but didn't put it in because the Taxonomy work was > > still in progress. Now that it is pretty much done we could surely > > include that. But again...let's recharter first. > > > > Thanks. Do people agree with 1 & 2? > > > > --- > > Inderpreet Singh > > Chantry Networks > > isingh@chantrynetworks.com > > Cell: 416-831-3705 > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > > Behalf Of Pat R. Calhoun > > Sent: Tuesday, August 03, 2004 6:04 PM > > To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com; > > capwap@frascone.com > > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > > Subject: [Capwap] So many architectures, so little time... - take 2 > > > > After reading Lily's response to Jim, I realize that I fell down the > > same trap. Local MAC > > is also a centralized approach, and so my previous response was not > > complete. I believe the > > real question, in my mind, is whether we need to address either the > > Local or the Split MAC > > architecture. > > > > Just looking at the Architecture Consideration tables (7 and 10) in the > > specification, the > > main difference (at a high level) between both approaches is where the > > 802.11 management > > terminates. For Local MAC, it's in the WTP, while for SPlit MAC, it's in > > the AC. > > > > However, looking at table 8, most Local MAC approaches share STA state > > between both the WTP > > and the AC. So clearly there is some signalling protocol between both > > the WTP and the AC. > > > > Looking at one example of a Local MAC protocol (see > > http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > > there is a protocol message > > that corresponds for every 802.11 MAC management event. So when a STA > > associates, the AP breaks > > the message apart and creates an new protocol PDU, which contains > > components found in the association > > request. I suspect that most Local MAC approaches do something very > > similar. > > > > So if a protocol simply tunnels the 802.11 MAC management frames from > > the WTP to the AC, it allows > > supports both approaches. For Local MAC, they get what they want via the > > 802.11 frame, and this > > also works fine for Split MAC, which needs access to the MAC management > > frame. What would be required > > in such a protocol is a way for the AP to communicate whether it will be > > providing very specific > > functions - basically a capabilities negotiation approach. > > > > So I do believe that there is a way to address both architectures using > > a single protocol. > > > > Thoughts? > > > > PatC > > > > _______________________________________________ > > 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 Aug 4 14:57:15 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28674 for ; Wed, 4 Aug 2004 14:57:15 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 158F821247; Wed, 4 Aug 2004 14:41:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8F9AD2123C; Wed, 4 Aug 2004 14:41:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A105C205D0 for ; Wed, 4 Aug 2004 14:39:48 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mail.frascone.com (Postfix) with ESMTP id 0646B20D00 for ; Wed, 4 Aug 2004 14:39:45 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i74IsGl26467; Wed, 4 Aug 2004 21:54:16 +0300 (EET DST) X-Scanned: Wed, 4 Aug 2004 21:53:03 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i74Ir3JZ017409; Wed, 4 Aug 2004 21:53:03 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00BSrB5z; Wed, 04 Aug 2004 21:53:01 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i74Ir0u07041; Wed, 4 Aug 2004 21:53:00 +0300 (EET DST) Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 4 Aug 2004 13:52:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] So many architectures, so little time... - take 2 Message-ID: Thread-Topic: [Capwap] So many architectures, so little time... - take 2 Thread-Index: AcR53YVZdTXK/VrnRtGuZ/OBWyyDQgAdm05Q From: To: , Cc: , , X-OriginalArrivalTime: 04 Aug 2004 18:52:56.0485 (UTC) FILETIME=[41507550:01C47A54] 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, 4 Aug 2004 11:52:55 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I believe this is the consensus, to scope the charter to Centralized = Architecture and LocalMAC and=20 Split MAC.=20 I'll update the charter with this change after the CAPWAP WG Mtg. If there is resistance to this idea, please post to the list. Regards Dorothy > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > Behalf Of ext Inderpreet Singh > Sent: Tuesday, August 03, 2004 9:40 PM > To: capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David > (Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > Subject: RE: [Capwap] So many architectures, so little=20 > time... - take 2 >=20 >=20 > The issue(s) at hand and my opinions are: >=20 > 1. Do we explicitly state in the re-charter which architecture the WG > should consider? > I think yes. I propose Centralized architecture only. > Autonomous and Distributed should be out of scope based on the same > reasons as per prior postings. >=20 > 2. Within Centralized do we focus on all three sub architectures or a > subset? > Remote MAC should be excluded because if I am not mistaken, the > connectivity constraint between the WTP and the AC is "direct=20 > connect". > That being the case and that no IP layer is involved, it doesn't seem > clear what kind of protocol would help with interoperability. > I am concerned about the impact, dependencies and interaction > with the recently constituted IEEE Study group on AP functionality on > the Split MAC architectures. Furthermore, there are some=20 > pretty drastic > differences on how the vendors have chosen to split the mac. Those > differences will need to be worked out before designing a=20 > protocol. So, > if the low hanging fruit strategy (as James suggested) for protocol > development and progress is the way to go, then I think=20 > prioritizing on > a protocol for Local MAC is a no brainer. So as far as=20 > focus, I feel we > should do Local and Split and in that order. >=20 > 3. This is not a re-chartering issue but is a response to Pat's > suggestion that a protocol that just sends the 802.11 MAC frames from > the AP to the AC would work. I think possibly, yes. But again the > complications of splitting the MAC in an interoperable way will be an > issue. Also, you may note in the draft to which you refer,=20 > we included > a capabilities exchange phase. I had thought of including in the > capability exchange such things as "AP supports Local MAC" and "AP > supports Split MAC", but didn't put it in because the=20 > Taxonomy work was > still in progress. Now that it is pretty much done we could surely > include that. But again...let's recharter first. >=20 > Thanks. Do people agree with 1 & 2? >=20 > --- > Inderpreet Singh > Chantry Networks > isingh@chantrynetworks.com > Cell: 416-831-3705 >=20 > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Pat R. Calhoun > Sent: Tuesday, August 03, 2004 6:04 PM > To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com; > capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > Subject: [Capwap] So many architectures, so little time... - take 2 >=20 > After reading Lily's response to Jim, I realize that I fell down the > same trap. Local MAC > is also a centralized approach, and so my previous response was not > complete. I believe the > real question, in my mind, is whether we need to address either the > Local or the Split MAC > architecture. >=20 > Just looking at the Architecture Consideration tables (7 and=20 > 10) in the > specification, the > main difference (at a high level) between both approaches is where the > 802.11 management > terminates. For Local MAC, it's in the WTP, while for SPlit=20 > MAC, it's in > the AC. >=20 > However, looking at table 8, most Local MAC approaches share STA state > between both the WTP > and the AC. So clearly there is some signalling protocol between both > the WTP and the AC. >=20 > Looking at one example of a Local MAC protocol (see > http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > there is a protocol message > that corresponds for every 802.11 MAC management event. So when a STA > associates, the AP breaks > the message apart and creates an new protocol PDU, which contains > components found in the association > request. I suspect that most Local MAC approaches do something very > similar. >=20 > So if a protocol simply tunnels the 802.11 MAC management frames from > the WTP to the AC, it allows > supports both approaches. For Local MAC, they get what they=20 > want via the > 802.11 frame, and this > also works fine for Split MAC, which needs access to the MAC=20 > management > frame. What would be required > in such a protocol is a way for the AP to communicate whether=20 > it will be > providing very specific > functions - basically a capabilities negotiation approach. >=20 > So I do believe that there is a way to address both=20 > architectures using > a single protocol. >=20 > Thoughts? >=20 > PatC=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 Wed Aug 4 18:20:44 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13903 for ; Wed, 4 Aug 2004 18:20:43 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 39B871FE58; Wed, 4 Aug 2004 18:06:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7767E21288; Wed, 4 Aug 2004 18:06:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 994F421288 for ; Wed, 4 Aug 2004 18:05:19 -0400 (EDT) Received: from mail3.extremenetworks.com (sc-f100-01.extremenetworks.com [63.251.106.30]) by mail.frascone.com (Postfix) with ESMTP id BBCC01FE58 for ; Wed, 4 Aug 2004 18:05:17 -0400 (EDT) Received: by mail3 with Internet Mail Service (5.5.2657.72) id <39FWDR1P>; Wed, 4 Aug 2004 15:18:40 -0700 Message-ID: <1B8A2DD33C49824F8D9021678C127213026B0A53@sc-msexch-04.extremenetworks.com> From: Shehzad Merchant To: capwap@frascone.com Cc: bwijnen@lucent.com, mmani@avaya.com, david.kessens@nokia.com, Dorothy.Gellert@nokia.com, Inderpreet Singh Subject: RE: [Capwap] So many architectures, so little time... - take 2 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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, 4 Aug 2004 15:19:53 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I think the implementation variations even with the split MAC may cover a broad spectrum. As such its important to clearly articulate what aspects of interoperability we are targetting. Is it truly just control/management or is it interoperability between disparate implementations of the split MAC, i.e. mix and match operation of WTP and ACs of all variants within this category. I suspect for the latter we may have to arrive at some consensus on what particular implementations we are targeting interoperability for. If so, ultimately this problem statement could become part of the charter. -Shehzad -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Dorothy.Gellert@nokia.com Sent: Wednesday, August 04, 2004 11:53 AM To: isingh@chantrynetworks.com; capwap@frascone.com Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com Subject: RE: [Capwap] So many architectures, so little time... - take 2 I believe this is the consensus, to scope the charter to Centralized Architecture and LocalMAC and Split MAC. I'll update the charter with this change after the CAPWAP WG Mtg. If there is resistance to this idea, please post to the list. Regards Dorothy > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > Behalf Of ext Inderpreet Singh > Sent: Tuesday, August 03, 2004 9:40 PM > To: capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David > (Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > Subject: RE: [Capwap] So many architectures, so little time... - take > 2 > > > The issue(s) at hand and my opinions are: > > 1. Do we explicitly state in the re-charter which architecture the WG > should consider? > I think yes. I propose Centralized architecture only. > Autonomous and Distributed should be out of scope based on the same > reasons as per prior postings. > > 2. Within Centralized do we focus on all three sub architectures or a > subset? > Remote MAC should be excluded because if I am not mistaken, the > connectivity constraint between the WTP and the AC is "direct > connect". > That being the case and that no IP layer is involved, it doesn't seem > clear what kind of protocol would help with interoperability. > I am concerned about the impact, dependencies and interaction with > the recently constituted IEEE Study group on AP functionality on the > Split MAC architectures. Furthermore, there are some pretty drastic > differences on how the vendors have chosen to split the mac. Those > differences will need to be worked out before designing a protocol. > So, if the low hanging fruit strategy (as James suggested) for > protocol development and progress is the way to go, then I think > prioritizing on a protocol for Local MAC is a no brainer. So as far > as focus, I feel we should do Local and Split and in that order. > > 3. This is not a re-chartering issue but is a response to Pat's > suggestion that a protocol that just sends the 802.11 MAC frames from > the AP to the AC would work. I think possibly, yes. But again the > complications of splitting the MAC in an interoperable way will be an > issue. Also, you may note in the draft to which you refer, we > included a capabilities exchange phase. I had thought of including in > the capability exchange such things as "AP supports Local MAC" and "AP > supports Split MAC", but didn't put it in because the Taxonomy work > was still in progress. Now that it is pretty much done we could > surely include that. But again...let's recharter first. > > Thanks. Do people agree with 1 & 2? > > --- > Inderpreet Singh > Chantry Networks > isingh@chantrynetworks.com > Cell: 416-831-3705 > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Pat R. Calhoun > Sent: Tuesday, August 03, 2004 6:04 PM > To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com; > capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > Subject: [Capwap] So many architectures, so little time... - take 2 > > After reading Lily's response to Jim, I realize that I fell down the > same trap. Local MAC is also a centralized approach, and so my > previous response was not complete. I believe the real question, in my > mind, is whether we need to address either the Local or the Split MAC > architecture. > > Just looking at the Architecture Consideration tables (7 and > 10) in the > specification, the > main difference (at a high level) between both approaches is where the > 802.11 management > terminates. For Local MAC, it's in the WTP, while for SPlit MAC, it's > in the AC. > > However, looking at table 8, most Local MAC approaches share STA state > between both the WTP and the AC. So clearly there is some signalling > protocol between both the WTP and the AC. > > Looking at one example of a Local MAC protocol (see > http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > there is a protocol message > that corresponds for every 802.11 MAC management event. So when a STA > associates, the AP breaks the message apart and creates an new > protocol PDU, which contains components found in the association > request. I suspect that most Local MAC approaches do something very > similar. > > So if a protocol simply tunnels the 802.11 MAC management frames from > the WTP to the AC, it allows supports both approaches. For Local MAC, > they get what they want via the > 802.11 frame, and this > also works fine for Split MAC, which needs access to the MAC > management frame. What would be required in such a protocol is a way > for the AP to communicate whether it will be providing very specific > functions - basically a capabilities negotiation approach. > > So I do believe that there is a way to address both architectures > using a single protocol. > > Thoughts? > > PatC > > _______________________________________________ > 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 Aug 4 18:28:45 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15607 for ; Wed, 4 Aug 2004 18:28:43 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3DC4021A6F; Wed, 4 Aug 2004 18:14:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 99D2021A71; Wed, 4 Aug 2004 18:14:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 81E4321A71 for ; Wed, 4 Aug 2004 18:13: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 565B121A6F for ; Wed, 4 Aug 2004 18:13:15 -0400 (EDT) Message-ID: <015d01c47a72$63a73760$966015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Shehzad Merchant" , Cc: , , , , "Inderpreet Singh" References: <1B8A2DD33C49824F8D9021678C127213026B0A53@sc-msexch-04.extremenetworks.com> Subject: Re: [Capwap] So many architectures, so little time... - take 2 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, 4 Aug 2004 15:28:35 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit As a potential customer, let me put it concretely. I want to be able to buy my access points from Vendor X and my switch from Vendor Y and plug the two together and have them work without any configuration. Also, I'd like to be able to buy switches from Vendor Y and Vendor Z and be able to plug them into my network at various places and have them interoperate. jak ----- Original Message ----- From: "Shehzad Merchant" To: Cc: ; ; ; ; "Inderpreet Singh" Sent: Wednesday, August 04, 2004 3:19 PM Subject: RE: [Capwap] So many architectures, so little time... - take 2 > I think the implementation variations even with the split MAC may cover a > broad spectrum. As such its important to clearly articulate what aspects of > interoperability we are targetting. Is it truly just control/management or > is it interoperability between disparate implementations of the split MAC, > i.e. mix and match operation of WTP and ACs of all variants within this > category. > > I suspect for the latter we may have to arrive at some consensus on what > particular implementations we are targeting interoperability for. If so, > ultimately this problem statement could become part of the charter. > > -Shehzad > > > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf > Of Dorothy.Gellert@nokia.com > Sent: Wednesday, August 04, 2004 11:53 AM > To: isingh@chantrynetworks.com; capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > Subject: RE: [Capwap] So many architectures, so little time... - take 2 > > I believe this is the consensus, to scope the charter to Centralized > Architecture and LocalMAC and Split MAC. > > I'll update the charter with this change after the CAPWAP WG Mtg. > If there is resistance to this idea, please post to the list. > > Regards > Dorothy > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > > Behalf Of ext Inderpreet Singh > > Sent: Tuesday, August 03, 2004 9:40 PM > > To: capwap@frascone.com > > Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David > > (Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > > Subject: RE: [Capwap] So many architectures, so little time... - take > > 2 > > > > > > The issue(s) at hand and my opinions are: > > > > 1. Do we explicitly state in the re-charter which architecture the WG > > should consider? > > I think yes. I propose Centralized architecture only. > > Autonomous and Distributed should be out of scope based on the same > > reasons as per prior postings. > > > > 2. Within Centralized do we focus on all three sub architectures or a > > subset? > > Remote MAC should be excluded because if I am not mistaken, the > > connectivity constraint between the WTP and the AC is "direct > > connect". > > That being the case and that no IP layer is involved, it doesn't seem > > clear what kind of protocol would help with interoperability. > > I am concerned about the impact, dependencies and interaction with > > the recently constituted IEEE Study group on AP functionality on the > > Split MAC architectures. Furthermore, there are some pretty drastic > > differences on how the vendors have chosen to split the mac. Those > > differences will need to be worked out before designing a protocol. > > So, if the low hanging fruit strategy (as James suggested) for > > protocol development and progress is the way to go, then I think > > prioritizing on a protocol for Local MAC is a no brainer. So as far > > as focus, I feel we should do Local and Split and in that order. > > > > 3. This is not a re-chartering issue but is a response to Pat's > > suggestion that a protocol that just sends the 802.11 MAC frames from > > the AP to the AC would work. I think possibly, yes. But again the > > complications of splitting the MAC in an interoperable way will be an > > issue. Also, you may note in the draft to which you refer, we > > included a capabilities exchange phase. I had thought of including in > > the capability exchange such things as "AP supports Local MAC" and "AP > > supports Split MAC", but didn't put it in because the Taxonomy work > > was still in progress. Now that it is pretty much done we could > > surely include that. But again...let's recharter first. > > > > Thanks. Do people agree with 1 & 2? > > > > --- > > Inderpreet Singh > > Chantry Networks > > isingh@chantrynetworks.com > > Cell: 416-831-3705 > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > > Behalf Of Pat R. Calhoun > > Sent: Tuesday, August 03, 2004 6:04 PM > > To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com; > > capwap@frascone.com > > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > > Subject: [Capwap] So many architectures, so little time... - take 2 > > > > After reading Lily's response to Jim, I realize that I fell down the > > same trap. Local MAC is also a centralized approach, and so my > > previous response was not complete. I believe the real question, in my > > mind, is whether we need to address either the Local or the Split MAC > > architecture. > > > > Just looking at the Architecture Consideration tables (7 and > > 10) in the > > specification, the > > main difference (at a high level) between both approaches is where the > > 802.11 management > > terminates. For Local MAC, it's in the WTP, while for SPlit MAC, it's > > in the AC. > > > > However, looking at table 8, most Local MAC approaches share STA state > > between both the WTP and the AC. So clearly there is some signalling > > protocol between both the WTP and the AC. > > > > Looking at one example of a Local MAC protocol (see > > http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > > there is a protocol message > > that corresponds for every 802.11 MAC management event. So when a STA > > associates, the AP breaks the message apart and creates an new > > protocol PDU, which contains components found in the association > > request. I suspect that most Local MAC approaches do something very > > similar. > > > > So if a protocol simply tunnels the 802.11 MAC management frames from > > the WTP to the AC, it allows supports both approaches. For Local MAC, > > they get what they want via the > > 802.11 frame, and this > > also works fine for Split MAC, which needs access to the MAC > > management frame. What would be required in such a protocol is a way > > for the AP to communicate whether it will be providing very specific > > functions - basically a capabilities negotiation approach. > > > > So I do believe that there is a way to address both architectures > > using a single protocol. > > > > Thoughts? > > > > PatC > > > > _______________________________________________ > > 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 Aug 4 19:25:45 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19048 for ; Wed, 4 Aug 2004 19:25:44 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1153A21A80; Wed, 4 Aug 2004 19:11:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B3F4D21A83; Wed, 4 Aug 2004 19:11:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7358E21A75 for ; Wed, 4 Aug 2004 19:10:46 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id 6F77821A74 for ; Wed, 4 Aug 2004 19:10:44 -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 i74NNox9002395 for ; Wed, 4 Aug 2004 19:23:51 -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 i74NMbx9000983 for ; Wed, 4 Aug 2004 19:23:19 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] So many architectures, so little time... - take 2 Message-ID: Thread-Topic: [Capwap] So many architectures, so little time... - take 2 Thread-Index: AcR6cnKYh0rnVAihSSSeBb0ELxzY7gABsTBg From: "Mani, Mahalingam (Mahalingam)" To: "James Kempf" , "Shehzad Merchant" , Cc: , , , "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, 4 Aug 2004 17:23:59 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable This in itself justifies the need to be able to seek idiosyncracies and commonalities of "customer" pressure-points and later sit back to prioritize them. Of the two requirements the more thought about is the first (and more of the core challenge). However,... -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com]=20 Sent: Wednesday, August 04, 2004 3:29 PM To: Shehzad Merchant; capwap@frascone.com Cc: bwijnen@lucent.com; Mani, Mahalingam (Mahalingam); david.kessens@nokia.com; Dorothy.Gellert@nokia.com; Inderpreet Singh Subject: Re: [Capwap] So many architectures, so little time... - take 2 As a potential customer, let me put it concretely. I want to be able to buy my access points from Vendor X and my switch from Vendor Y and plug the two together and have them work without any configuration. Also, I'd like to be able to buy switches from Vendor Y and Vendor Z and be able to plug them [Mani, Mahalingam (Mahalingam)]=20 [Mani, Mahalingam (Mahalingam)] the latter is a new, good and interesting requirement to consider; whether it goes into desirable or mandatory bucket remains to be seen. Also - whether it is a coexistence requirement or interoperability requirement is to be analyzed as well. -mani into my network at various places and have them interoperate. jak ----- Original Message -----=20 From: "Shehzad Merchant" To: Cc: ; ; ; ; "Inderpreet Singh" Sent: Wednesday, August 04, 2004 3:19 PM Subject: RE: [Capwap] So many architectures, so little time... - take 2 > I think the implementation variations even with the split MAC may cover a > broad spectrum. As such its important to clearly articulate what aspects of > interoperability we are targetting. Is it truly just control/management or > is it interoperability between disparate implementations of the split MAC, > i.e. mix and match operation of WTP and ACs of all variants within this > category. > > I suspect for the latter we may have to arrive at some consensus on what > particular implementations we are targeting interoperability for. If so, > ultimately this problem statement could become part of the charter. > > -Shehzad > [Mani, Mahalingam (Mahalingam)] [...] _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Aug 4 20:04:45 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22175 for ; Wed, 4 Aug 2004 20:04:45 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C0588204A9; Wed, 4 Aug 2004 19:50:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 18F85206B3; Wed, 4 Aug 2004 19:50:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5E938206B3 for ; Wed, 4 Aug 2004 19:49:35 -0400 (EDT) Received: from aruba-server.arubanetworks.com (mail.arubanetworks.com [64.60.249.195]) by mail.frascone.com (Postfix) with SMTP id 947F8204A9 for ; Wed, 4 Aug 2004 19:49:33 -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] So many architectures, so little time... - take 2 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 Message-ID: Thread-Topic: [Capwap] So many architectures, so little time... - take 2 Thread-Index: AcR6cnKYh0rnVAihSSSeBb0ELxzY7gABsTBgAAGK3zA= From: "Randy Chou" To: "Mani, Mahalingam (Mahalingam)" , "James Kempf" , "Shehzad Merchant" , Cc: , , , "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, 4 Aug 2004 17:04:06 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I think most consumers not only want the first requirement, but more specifically want to be able to purchase the most inexpensive AP from any vendor without sacrificing security. If agreeable, I would suggest making that one of the goals of the charter. Regards, -- Randy=20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Mani, Mahalingam (Mahalingam) Sent: Wednesday, August 04, 2004 4:24 PM To: James Kempf; Shehzad Merchant; capwap@frascone.com Cc: bwijnen@lucent.com; david.kessens@nokia.com; Dorothy.Gellert@nokia.com; Inderpreet Singh Subject: RE: [Capwap] So many architectures, so little time... - take 2 This in itself justifies the need to be able to seek idiosyncracies and commonalities of "customer" pressure-points and later sit back to prioritize them. Of the two requirements the more thought about is the first (and more of the core challenge). However,... -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com]=20 Sent: Wednesday, August 04, 2004 3:29 PM To: Shehzad Merchant; capwap@frascone.com Cc: bwijnen@lucent.com; Mani, Mahalingam (Mahalingam); david.kessens@nokia.com; Dorothy.Gellert@nokia.com; Inderpreet Singh Subject: Re: [Capwap] So many architectures, so little time... - take 2 As a potential customer, let me put it concretely. I want to be able to buy my access points from Vendor X and my switch from Vendor Y and plug the two together and have them work without any configuration. Also, I'd like to be able to buy switches from Vendor Y and Vendor Z and be able to plug them [Mani, Mahalingam (Mahalingam)]=20 [Mani, Mahalingam (Mahalingam)] the latter is a new, good and interesting requirement to consider; whether it goes into desirable or mandatory bucket remains to be seen. Also - whether it is a coexistence requirement or interoperability requirement is to be analyzed as well. -mani into my network at various places and have them interoperate. jak ----- Original Message -----=20 From: "Shehzad Merchant" To: Cc: ; ; ; ; "Inderpreet Singh" Sent: Wednesday, August 04, 2004 3:19 PM Subject: RE: [Capwap] So many architectures, so little time... - take 2 > I think the implementation variations even with the split MAC may cover a > broad spectrum. As such its important to clearly articulate what aspects of > interoperability we are targetting. Is it truly just control/management or > is it interoperability between disparate implementations of the split MAC, > i.e. mix and match operation of WTP and ACs of all variants within this > category. > > I suspect for the latter we may have to arrive at some consensus on what > particular implementations we are targeting interoperability for. If so, > ultimately this problem statement could become part of the charter. > > -Shehzad > [Mani, Mahalingam (Mahalingam)] [...] _______________________________________________ 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 Aug 5 01:46:46 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10534 for ; Thu, 5 Aug 2004 01:46:45 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4CC5020C05; Thu, 5 Aug 2004 01:32:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 22EBF20F43; Thu, 5 Aug 2004 01:32:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CCA2D212C6 for ; Thu, 5 Aug 2004 01:31:27 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by mail.frascone.com (Postfix) with ESMTP id CE43E20F43 for ; Thu, 5 Aug 2004 01:31:25 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Aug 2004 07:45:44 +0200 Received: from [10.193.106.14] ([10.193.106.14]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Thu, 5 Aug 2004 07:45:42 +0200 Message-ID: <4111C9C0.1030807@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Mani, Mahalingam (Mahalingam)" , Dorothy.Gellert@nokia.com Cc: capwap@frascone.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Aug 2004 05:45:43.0554 (UTC) FILETIME=[72B4E620:01C47AAF] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Making the presentation made at IETF 60 available somewhere 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, 05 Aug 2004 07:46:40 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Would it please be possible to put up somewhere the slides that were presented this afternoon at IETF 60? The CAPWAP website seems an appropriate location to do so (next to the IETF 59 slides ;-)). What do you think? Many thanks in advance, Florent Mani, Mahalingam (Mahalingam) wrote: > The following is the updated agenda for the meeting on Wednesday (8/4/04, > > 1-3pmPT) session: > > > > 1. Agenda Bashing - 5 min. > > 2. Status of the current drafts - 5 min > > 3. WG milestone Review - 5 min. > > 4. Revision Changes to Architecture Taxonomy draft from > > (http://www.ietf.org/internet-drafts/draft-ietf-capwap-arch-03.txt) > > to rev-04 (posted to WG and www.capwap.org) - 20 min. (Lily Yang) > > 5. IEEE IETF Liaison and Status of IEEE activities: 10 min > > (Dorothy Stanley) > > 6. Next steps for WG: Dorothy Gellert & Mani (10-15 min.) > > 7. Open discussions on possible re-charter > > 8. CAPWAP classifications - Saravanan Govindan ~15 min. (time-permitting) > > > > Regards, > > -mani > > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Aug 5 08:38:47 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14730 for ; Thu, 5 Aug 2004 08:38:47 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B660D1FCCF; Thu, 5 Aug 2004 08:24:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 42BF9205F4; Thu, 5 Aug 2004 08:24:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CF2B41FCCF for ; Thu, 5 Aug 2004 08:23:51 -0400 (EDT) Received: from out009.verizon.net (out009pub.verizon.net [206.46.170.131]) by mail.frascone.com (Postfix) with ESMTP id 107FF205F4 for ; Thu, 5 Aug 2004 08:23:50 -0400 (EDT) Received: from Matt-Holdrege.verizon.net ([63.183.225.123]) by out009.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040805123826.KLBA23440.out009.verizon.net@Matt-Holdrege.verizon.net>; Thu, 5 Aug 2004 07:38:26 -0500 Message-Id: <6.1.0.6.2.20040805143618.02072d60@incoming.verizon.net> X-Sender: res06gzk@incoming.verizon.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 To: "James Kempf" , From: Matt Holdrege Subject: Re: [Capwap] Re: So many architectures, so little time... In-Reply-To: <002d01c47a44$0dee91c0$966015ac@dcml.docomolabsusa.com> References: <2AF68A477DD44C4EBCBE338C24E7A9EE01B57E86@orsmsx408> <042201c479d8$b1bbaca0$936015ac@dcml.docomolabsusa.com> <6.1.0.6.2.20040804130124.02182f08@incoming.verizon.net> <002d01c47a44$0dee91c0$966015ac@dcml.docomolabsusa.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authentication-Info: Submitted using SMTP AUTH at out009.verizon.net from [63.183.225.123] at Thu, 5 Aug 2004 07:38:22 -0500 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, 05 Aug 2004 14:38:18 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) What I meant was that hops are easy in the sense of hopping from say 802.11 to 802.3 then back to 802.11, then 802.3, etc. You can even do something like this on a chip. No new standardization is needed. -Matt At 06:56 PM 8/4/2004, James Kempf wrote: >What I had in mind was the following. 802.11s is working on MAC changes for >multihop. I think it would be premature to do anything in IETF on multhop >until they had completed. And, as a practical matter, I've seen some >experimental data (unfortunately not public yet) that indicates changes are >needed at the MAC level. But I'm not sure exactly what your question was, so >maybe this didn't answer it. > > > jak > >----- Original Message ----- >From: "Matt Holdrege" >To: "James Kempf" ; >Sent: Wednesday, August 04, 2004 4:03 AM >Subject: Re: [Capwap] Re: So many architectures, so little time... > > > > Why? Changes from one MAC to another are completely covered in 802. > > > > At 06:08 AM 8/4/2004, James Kempf wrote: > > >I think more to the point is that a wireless multihop backhaul probably >will > > >require some changes at the MAC level, and 802.11s isn't there yet. > > > > > > > > > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Aug 5 08:54:46 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15367 for ; Thu, 5 Aug 2004 08:54:45 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 177A720306; Thu, 5 Aug 2004 08:40:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 624CA2134F; Thu, 5 Aug 2004 08:40:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5238F2134F for ; Thu, 5 Aug 2004 08:39:23 -0400 (EDT) Received: from out002.verizon.net (out002pub.verizon.net [206.46.170.141]) by mail.frascone.com (Postfix) with ESMTP id 958E620306 for ; Thu, 5 Aug 2004 08:39:21 -0400 (EDT) Received: from Matt-Holdrege.verizon.net ([63.183.225.123]) by out002.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040805125358.IHWO24402.out002.verizon.net@Matt-Holdrege.verizon.net>; Thu, 5 Aug 2004 07:53:58 -0500 Message-Id: <6.1.0.6.2.20040805145223.02141e80@incoming.verizon.net> X-Sender: res06gzk@incoming.verizon.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 To: "Randy Chou" , From: Matt Holdrege Subject: RE: [Capwap] So many architectures, so little time... - take 2 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authentication-Info: Submitted using SMTP AUTH at out002.verizon.net from [63.183.225.123] at Thu, 5 Aug 2004 07:53:56 -0500 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, 05 Aug 2004 14:53:52 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Pricing should not be an issue in any IETF charter. Rather efficiency and performance are the major issues. It's up to manufacturers to set their prices. -Matt At 02:04 AM 8/5/2004, Randy Chou wrote: >I think most consumers not only want the first requirement, but more >specifically want to be able to purchase the most inexpensive AP from >any vendor without sacrificing security. If agreeable, I would suggest >making that one of the goals of the charter. > >Regards, > >-- >Randy > >-----Original Message----- >From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On >Behalf Of Mani, Mahalingam (Mahalingam) >Sent: Wednesday, August 04, 2004 4:24 PM >To: James Kempf; Shehzad Merchant; capwap@frascone.com >Cc: bwijnen@lucent.com; david.kessens@nokia.com; >Dorothy.Gellert@nokia.com; Inderpreet Singh >Subject: RE: [Capwap] So many architectures, so little time... - take 2 > > >This in itself justifies the need to be able to seek idiosyncracies and >commonalities of "customer" pressure-points and later sit back to >prioritize them. > >Of the two requirements the more thought about is the first (and more of >the core challenge). However,... > >-----Original Message----- >From: James Kempf [mailto:kempf@docomolabs-usa.com] >Sent: Wednesday, August 04, 2004 3:29 PM >To: Shehzad Merchant; capwap@frascone.com >Cc: bwijnen@lucent.com; Mani, Mahalingam (Mahalingam); >david.kessens@nokia.com; Dorothy.Gellert@nokia.com; Inderpreet Singh >Subject: Re: [Capwap] So many architectures, so little time... - take 2 > >As a potential customer, let me put it concretely. I want to be able to >buy my access points from Vendor X and my switch from Vendor Y and plug >the two together and have them work without any configuration. Also, I'd >like to be able to buy switches from Vendor Y and Vendor Z and be able >to plug them > >[Mani, Mahalingam (Mahalingam)] >[Mani, Mahalingam (Mahalingam)] the latter is a new, good and >interesting requirement to consider; whether it goes into desirable or >mandatory bucket remains to be seen. > >Also - whether it is a coexistence requirement or interoperability >requirement is to be analyzed as well. > >-mani > >into my network at various places and have them interoperate. > > jak > > >----- Original Message ----- >From: "Shehzad Merchant" >To: >Cc: ; ; ; >; "Inderpreet Singh" > >Sent: Wednesday, August 04, 2004 3:19 PM >Subject: RE: [Capwap] So many architectures, so little time... - take 2 > > > > I think the implementation variations even with the split MAC may >cover a > > broad spectrum. As such its important to clearly articulate what >aspects >of > > interoperability we are targetting. Is it truly just >control/management or > > is it interoperability between disparate implementations of the split >MAC, > > i.e. mix and match operation of WTP and ACs of all variants within >this > > category. > > > > I suspect for the latter we may have to arrive at some consensus on >what > > particular implementations we are targeting interoperability for. If >so, > > ultimately this problem statement could become part of the charter. > > > > -Shehzad > > >[Mani, Mahalingam (Mahalingam)] [...] > > >_______________________________________________ >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 Aug 5 11:32:45 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24513 for ; Thu, 5 Aug 2004 11:32:44 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 467A820EFB; Thu, 5 Aug 2004 11:18:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0F0C5213A7; Thu, 5 Aug 2004 11:18:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AEAF5213A7 for ; Thu, 5 Aug 2004 11:17:39 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id A60FA20EFB for ; Thu, 5 Aug 2004 11:17:37 -0400 (EDT) Message-ID: <027601c47b01$7e8a19a0$966015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Randy Chou" , , "Matt Holdrege" References: <6.1.0.6.2.20040805145223.02141e80@incoming.verizon.net> Subject: Re: [Capwap] So many architectures, so little time... - take 2 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: Thu, 5 Aug 2004 08:32:59 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit And interoperability. jak ----- Original Message ----- From: "Matt Holdrege" To: "Randy Chou" ; Sent: Thursday, August 05, 2004 5:53 AM Subject: RE: [Capwap] So many architectures, so little time... - take 2 > Pricing should not be an issue in any IETF charter. Rather efficiency and > performance are the major issues. It's up to manufacturers to set their > prices. > > -Matt > > At 02:04 AM 8/5/2004, Randy Chou wrote: > >I think most consumers not only want the first requirement, but more > >specifically want to be able to purchase the most inexpensive AP from > >any vendor without sacrificing security. If agreeable, I would suggest > >making that one of the goals of the charter. > > > >Regards, > > > >-- > >Randy > > > >-----Original Message----- > >From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > >Behalf Of Mani, Mahalingam (Mahalingam) > >Sent: Wednesday, August 04, 2004 4:24 PM > >To: James Kempf; Shehzad Merchant; capwap@frascone.com > >Cc: bwijnen@lucent.com; david.kessens@nokia.com; > >Dorothy.Gellert@nokia.com; Inderpreet Singh > >Subject: RE: [Capwap] So many architectures, so little time... - take 2 > > > > > >This in itself justifies the need to be able to seek idiosyncracies and > >commonalities of "customer" pressure-points and later sit back to > >prioritize them. > > > >Of the two requirements the more thought about is the first (and more of > >the core challenge). However,... > > > >-----Original Message----- > >From: James Kempf [mailto:kempf@docomolabs-usa.com] > >Sent: Wednesday, August 04, 2004 3:29 PM > >To: Shehzad Merchant; capwap@frascone.com > >Cc: bwijnen@lucent.com; Mani, Mahalingam (Mahalingam); > >david.kessens@nokia.com; Dorothy.Gellert@nokia.com; Inderpreet Singh > >Subject: Re: [Capwap] So many architectures, so little time... - take 2 > > > >As a potential customer, let me put it concretely. I want to be able to > >buy my access points from Vendor X and my switch from Vendor Y and plug > >the two together and have them work without any configuration. Also, I'd > >like to be able to buy switches from Vendor Y and Vendor Z and be able > >to plug them > > > >[Mani, Mahalingam (Mahalingam)] > >[Mani, Mahalingam (Mahalingam)] the latter is a new, good and > >interesting requirement to consider; whether it goes into desirable or > >mandatory bucket remains to be seen. > > > >Also - whether it is a coexistence requirement or interoperability > >requirement is to be analyzed as well. > > > >-mani > > > >into my network at various places and have them interoperate. > > > > jak > > > > > >----- Original Message ----- > >From: "Shehzad Merchant" > >To: > >Cc: ; ; ; > >; "Inderpreet Singh" > > > >Sent: Wednesday, August 04, 2004 3:19 PM > >Subject: RE: [Capwap] So many architectures, so little time... - take 2 > > > > > > > I think the implementation variations even with the split MAC may > >cover a > > > broad spectrum. As such its important to clearly articulate what > >aspects > >of > > > interoperability we are targetting. Is it truly just > >control/management or > > > is it interoperability between disparate implementations of the split > >MAC, > > > i.e. mix and match operation of WTP and ACs of all variants within > >this > > > category. > > > > > > I suspect for the latter we may have to arrive at some consensus on > >what > > > particular implementations we are targeting interoperability for. If > >so, > > > ultimately this problem statement could become part of the charter. > > > > > > -Shehzad > > > > >[Mani, Mahalingam (Mahalingam)] [...] > > > > > >_______________________________________________ > >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 Aug 5 14:28:47 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04783 for ; Thu, 5 Aug 2004 14:28:46 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3F3F92144F; Thu, 5 Aug 2004 14:14:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A2DF3217E2; Thu, 5 Aug 2004 14:14:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2C4B3217E2 for ; Thu, 5 Aug 2004 14:13:59 -0400 (EDT) Received: from sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by mail.frascone.com (Postfix) with ESMTP id 051DE2144F for ; Thu, 5 Aug 2004 14:13:58 -0400 (EDT) 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.6944.0 Subject: RE: [Capwap] So many architectures, so little time... - take 2 Message-ID: Thread-Topic: [Capwap] So many architectures, so little time... - take 2 Thread-Index: AcR6cvB6i/Y6+JuATMK0pGMKAhGL6QApcxAQ From: "Abhijit Choudhury" To: "James Kempf" , "Shehzad Merchant" , Cc: , , , , "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, 5 Aug 2004 11:32:17 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable It may be possible to achieve such interoperability within the split-MAC family or within the local-MAC family. It would sbe very hard to achieve=20 that between local and split MAC families. For example, if vendor X's WTP terminates 802.11 ctrl/mgmt packets and vendor Y's AC expects the 802.11 mgmt packets to come to it, there's no way you can be interoperable. Or are we planning to specify ONE architecture ? The last thing IETF should do is mandate an implementation. I think a modest and reasonable goal is to come up=20 with a protocol that allows sufficient flexbility so that vendors with splitMAC architectures can transfer most of the information they care about between the WTP and AC. Just my $0.02 ... Abhijit Choudhury -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf Sent: Wednesday, August 04, 2004 3:29 PM To: Shehzad Merchant; capwap@frascone.com Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; Dorothy.Gellert@nokia.com; Inderpreet Singh Subject: Re: [Capwap] So many architectures, so little time... - take 2 As a potential customer, let me put it concretely. I want to be able to buy my access points from Vendor X and my switch from Vendor Y and plug the two together and have them work without any configuration. Also, I'd like to be able to buy switches from Vendor Y and Vendor Z and be able to plug them into my network at various places and have them interoperate. jak ----- Original Message -----=20 From: "Shehzad Merchant" To: Cc: ; ; ; ; "Inderpreet Singh" Sent: Wednesday, August 04, 2004 3:19 PM Subject: RE: [Capwap] So many architectures, so little time... - take 2 > I think the implementation variations even with the split MAC may=20 > cover a broad spectrum. As such its important to clearly articulate=20 > what aspects of > interoperability we are targetting. Is it truly just=20 > control/management or is it interoperability between disparate=20 > implementations of the split MAC, i.e. mix and match operation of WTP=20 > and ACs of all variants within this category. > > I suspect for the latter we may have to arrive at some consensus on=20 > what particular implementations we are targeting interoperability for. > If so, ultimately this problem statement could become part of the=20 > charter. > > -Shehzad > > > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf > Of Dorothy.Gellert@nokia.com > Sent: Wednesday, August 04, 2004 11:53 AM > To: isingh@chantrynetworks.com; capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > Subject: RE: [Capwap] So many architectures, so little time... - take=20 > 2 > > I believe this is the consensus, to scope the charter to Centralized=20 > Architecture and LocalMAC and Split MAC. > > I'll update the charter with this change after the CAPWAP WG Mtg. If=20 > there is resistance to this idea, please post to the list. > > Regards > Dorothy > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > > Behalf Of ext Inderpreet Singh > > Sent: Tuesday, August 03, 2004 9:40 PM > > To: capwap@frascone.com > > Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David=20 > > (Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > > Subject: RE: [Capwap] So many architectures, so little time... -=20 > > take 2 > > > > > > The issue(s) at hand and my opinions are: > > > > 1. Do we explicitly state in the re-charter which architecture the=20 > > WG should consider? I think yes. I propose Centralized architecture > > only. Autonomous and Distributed should be out of scope based on the > > same reasons as per prior postings. > > > > 2. Within Centralized do we focus on all three sub architectures or=20 > > a subset? Remote MAC should be excluded because if I am not=20 > > mistaken, the connectivity constraint between the WTP and the AC is=20 > > "direct connect". > > That being the case and that no IP layer is involved, it doesn't seem > > clear what kind of protocol would help with interoperability. > > I am concerned about the impact, dependencies and interaction with > > the recently constituted IEEE Study group on AP functionality on the > > Split MAC architectures. Furthermore, there are some pretty drastic > > differences on how the vendors have chosen to split the mac. Those > > differences will need to be worked out before designing a protocol. > > So, if the low hanging fruit strategy (as James suggested) for > > protocol development and progress is the way to go, then I think > > prioritizing on a protocol for Local MAC is a no brainer. So as far > > as focus, I feel we should do Local and Split and in that order. > > > > 3. This is not a re-chartering issue but is a response to Pat's=20 > > suggestion that a protocol that just sends the 802.11 MAC frames=20 > > from the AP to the AC would work. I think possibly, yes. But again > > the complications of splitting the MAC in an interoperable way will=20 > > be an issue. Also, you may note in the draft to which you refer, we > > included a capabilities exchange phase. I had thought of including=20 > > in the capability exchange such things as "AP supports Local MAC"=20 > > and "AP supports Split MAC", but didn't put it in because the=20 > > Taxonomy work was still in progress. Now that it is pretty much=20 > > done we could surely include that. But again...let's recharter=20 > > first. > > > > Thanks. Do people agree with 1 & 2? > > > > --- > > Inderpreet Singh > > Chantry Networks > > isingh@chantrynetworks.com > > Cell: 416-831-3705 > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]=20 > > On Behalf Of Pat R. Calhoun > > Sent: Tuesday, August 03, 2004 6:04 PM > > To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com;=20 > > capwap@frascone.com > > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > > Subject: [Capwap] So many architectures, so little time... - take 2 > > > > After reading Lily's response to Jim, I realize that I fell down the > > same trap. Local MAC is also a centralized approach, and so my=20 > > previous response was not complete. I believe the real question, in=20 > > my mind, is whether we need to address either the Local or the Split > > MAC architecture. > > > > Just looking at the Architecture Consideration tables (7 and > > 10) in the > > specification, the > > main difference (at a high level) between both approaches is where=20 > > the 802.11 management terminates. For Local MAC, it's in the WTP,=20 > > while for SPlit MAC, it's in the AC. > > > > However, looking at table 8, most Local MAC approaches share STA=20 > > state between both the WTP and the AC. So clearly there is some=20 > > signalling protocol between both the WTP and the AC. > > > > Looking at one example of a Local MAC protocol (see=20 > > http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > > there is a protocol message > > that corresponds for every 802.11 MAC management event. So when a=20 > > STA associates, the AP breaks the message apart and creates an new=20 > > protocol PDU, which contains components found in the association=20 > > request. I suspect that most Local MAC approaches do something very=20 > > similar. > > > > So if a protocol simply tunnels the 802.11 MAC management frames=20 > > from the WTP to the AC, it allows supports both approaches. For=20 > > Local MAC, they get what they want via the 802.11 frame, and this > > also works fine for Split MAC, which needs access to the MAC > > management frame. What would be required in such a protocol is a way > > for the AP to communicate whether it will be providing very specific > > functions - basically a capabilities negotiation approach. > > > > So I do believe that there is a way to address both architectures=20 > > using a single protocol. > > > > Thoughts? > > > > PatC > > > > _______________________________________________ > > 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 Aug 5 14:40:48 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05646 for ; Thu, 5 Aug 2004 14:40:47 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A4610217E9; Thu, 5 Aug 2004 14:26:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 78FA8217EE; Thu, 5 Aug 2004 14:26:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D65F1217E9 for ; Thu, 5 Aug 2004 14:25:54 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id 9712D21420 for ; Thu, 5 Aug 2004 14:25:52 -0400 (EDT) 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] So many architectures, so little time... - take 2 Message-ID: <55749BC69138654EBBC4C50BA4F55610026AB09E@AIREMAIL.airespace.com> Thread-Topic: [Capwap] So many architectures, so little time... - take 2 Thread-Index: AcR6cvB6i/Y6+JuATMK0pGMKAhGL6QApcxAQAACl7AA= From: "Bob O'Hara" 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, 5 Aug 2004 11:43:19 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I think that interoperability will depend on two things. First, it will depend on how we define the protocol and the flexibility for supported architectures it incorporates. Second, it will depend on what manufacturers implement, i.e., the flexibility they build into their products. =20 I believe that it is possible to design the protocol for the required flexibility. I know it is possible to implement a product with the required flexibility. -Bob O'Hara =20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Abhijit Choudhury Sent: Thursday, August 05, 2004 11:32 AM To: James Kempf; Shehzad Merchant; capwap@frascone.com Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; Dorothy.Gellert@nokia.com; Inderpreet Singh Subject: RE: [Capwap] So many architectures, so little time... - take 2 It may be possible to achieve such interoperability within the split-MAC family or within the local-MAC family. It would sbe very hard to achieve=20 that between local and split MAC families. For example, if vendor X's WTP terminates 802.11 ctrl/mgmt packets and vendor Y's AC expects the 802.11 mgmt packets to come to it, there's no way you can be interoperable. Or are we planning to specify ONE architecture ? The last thing IETF should do is mandate an implementation. I think a modest and reasonable goal is to come up=20 with a protocol that allows sufficient flexbility so that vendors with splitMAC architectures can transfer most of the information they care about between the WTP and AC. Just my $0.02 ... Abhijit Choudhury -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf Sent: Wednesday, August 04, 2004 3:29 PM To: Shehzad Merchant; capwap@frascone.com Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; Dorothy.Gellert@nokia.com; Inderpreet Singh Subject: Re: [Capwap] So many architectures, so little time... - take 2 As a potential customer, let me put it concretely. I want to be able to buy my access points from Vendor X and my switch from Vendor Y and plug the two together and have them work without any configuration. Also, I'd like to be able to buy switches from Vendor Y and Vendor Z and be able to plug them into my network at various places and have them interoperate. jak ----- Original Message -----=20 From: "Shehzad Merchant" To: Cc: ; ; ; ; "Inderpreet Singh" Sent: Wednesday, August 04, 2004 3:19 PM Subject: RE: [Capwap] So many architectures, so little time... - take 2 > I think the implementation variations even with the split MAC may=20 > cover a broad spectrum. As such its important to clearly articulate=20 > what aspects of > interoperability we are targetting. Is it truly just=20 > control/management or is it interoperability between disparate=20 > implementations of the split MAC, i.e. mix and match operation of WTP=20 > and ACs of all variants within this category. > > I suspect for the latter we may have to arrive at some consensus on=20 > what particular implementations we are targeting interoperability for. > If so, ultimately this problem statement could become part of the=20 > charter. > > -Shehzad > > > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf > Of Dorothy.Gellert@nokia.com > Sent: Wednesday, August 04, 2004 11:53 AM > To: isingh@chantrynetworks.com; capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > Subject: RE: [Capwap] So many architectures, so little time... - take=20 > 2 > > I believe this is the consensus, to scope the charter to Centralized=20 > Architecture and LocalMAC and Split MAC. > > I'll update the charter with this change after the CAPWAP WG Mtg. If=20 > there is resistance to this idea, please post to the list. > > Regards > Dorothy > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > > Behalf Of ext Inderpreet Singh > > Sent: Tuesday, August 03, 2004 9:40 PM > > To: capwap@frascone.com > > Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David=20 > > (Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > > Subject: RE: [Capwap] So many architectures, so little time... -=20 > > take 2 > > > > > > The issue(s) at hand and my opinions are: > > > > 1. Do we explicitly state in the re-charter which architecture the=20 > > WG should consider? I think yes. I propose Centralized architecture > > only. Autonomous and Distributed should be out of scope based on the > > same reasons as per prior postings. > > > > 2. Within Centralized do we focus on all three sub architectures or=20 > > a subset? Remote MAC should be excluded because if I am not=20 > > mistaken, the connectivity constraint between the WTP and the AC is=20 > > "direct connect". > > That being the case and that no IP layer is involved, it doesn't seem > > clear what kind of protocol would help with interoperability. > > I am concerned about the impact, dependencies and interaction with > > the recently constituted IEEE Study group on AP functionality on the > > Split MAC architectures. Furthermore, there are some pretty drastic > > differences on how the vendors have chosen to split the mac. Those > > differences will need to be worked out before designing a protocol. > > So, if the low hanging fruit strategy (as James suggested) for > > protocol development and progress is the way to go, then I think > > prioritizing on a protocol for Local MAC is a no brainer. So as far > > as focus, I feel we should do Local and Split and in that order. > > > > 3. This is not a re-chartering issue but is a response to Pat's=20 > > suggestion that a protocol that just sends the 802.11 MAC frames=20 > > from the AP to the AC would work. I think possibly, yes. But again > > the complications of splitting the MAC in an interoperable way will=20 > > be an issue. Also, you may note in the draft to which you refer, we > > included a capabilities exchange phase. I had thought of including=20 > > in the capability exchange such things as "AP supports Local MAC"=20 > > and "AP supports Split MAC", but didn't put it in because the=20 > > Taxonomy work was still in progress. Now that it is pretty much=20 > > done we could surely include that. But again...let's recharter=20 > > first. > > > > Thanks. Do people agree with 1 & 2? > > > > --- > > Inderpreet Singh > > Chantry Networks > > isingh@chantrynetworks.com > > Cell: 416-831-3705 > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]=20 > > On Behalf Of Pat R. Calhoun > > Sent: Tuesday, August 03, 2004 6:04 PM > > To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com;=20 > > capwap@frascone.com > > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > > Subject: [Capwap] So many architectures, so little time... - take 2 > > > > After reading Lily's response to Jim, I realize that I fell down the > > same trap. Local MAC is also a centralized approach, and so my=20 > > previous response was not complete. I believe the real question, in=20 > > my mind, is whether we need to address either the Local or the Split > > MAC architecture. > > > > Just looking at the Architecture Consideration tables (7 and > > 10) in the > > specification, the > > main difference (at a high level) between both approaches is where=20 > > the 802.11 management terminates. For Local MAC, it's in the WTP,=20 > > while for SPlit MAC, it's in the AC. > > > > However, looking at table 8, most Local MAC approaches share STA=20 > > state between both the WTP and the AC. So clearly there is some=20 > > signalling protocol between both the WTP and the AC. > > > > Looking at one example of a Local MAC protocol (see=20 > > http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > > there is a protocol message > > that corresponds for every 802.11 MAC management event. So when a=20 > > STA associates, the AP breaks the message apart and creates an new=20 > > protocol PDU, which contains components found in the association=20 > > request. I suspect that most Local MAC approaches do something very=20 > > similar. > > > > So if a protocol simply tunnels the 802.11 MAC management frames=20 > > from the WTP to the AC, it allows supports both approaches. For=20 > > Local MAC, they get what they want via the 802.11 frame, and this > > also works fine for Split MAC, which needs access to the MAC > > management frame. What would be required in such a protocol is a way > > for the AP to communicate whether it will be providing very specific > > functions - basically a capabilities negotiation approach. > > > > So I do believe that there is a way to address both architectures=20 > > using a single protocol. > > > > Thoughts? > > > > PatC > > > > _______________________________________________ > > 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 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Aug 5 14:51:27 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06254 for ; Thu, 5 Aug 2004 14:51:26 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A75DE21451; Thu, 5 Aug 2004 14:36:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E47612085A; Thu, 5 Aug 2004 14:36:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 71B842046E for ; Thu, 5 Aug 2004 14:35:09 -0400 (EDT) Received: from mail3.extremenetworks.com (sc-f100-01.extremenetworks.com [63.251.106.30]) by mail.frascone.com (Postfix) with ESMTP id 30AD021444 for ; Thu, 5 Aug 2004 14:35:07 -0400 (EDT) Received: by mail3 with Internet Mail Service (5.5.2657.72) id <39FWDTS1>; Thu, 5 Aug 2004 11:48:29 -0700 Message-ID: <4C8B0EA487B9554D910B0587CD91395C027B53DE@sc-msexch-03.extremenetworks.com> From: Victor Lin To: "Bob O'Hara" , capwap@frascone.com Subject: RE: [Capwap] So many architectures, so little time... - take 2 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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: Thu, 5 Aug 2004 11:46:01 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I agree that we can design a protocol and implement the product that works all architectures. I think the question to CAPWAP is: Should we make it a requirement in CAPWAP protocol to achieve interoperability between different architectures? It is definitely doable, but I'm not sure if that is the right thing to do.. Victor -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Bob O'Hara Sent: Thursday, August 05, 2004 11:43 AM To: capwap@frascone.com Subject: RE: [Capwap] So many architectures, so little time... - take 2 I think that interoperability will depend on two things. First, it will depend on how we define the protocol and the flexibility for supported architectures it incorporates. Second, it will depend on what manufacturers implement, i.e., the flexibility they build into their products. I believe that it is possible to design the protocol for the required flexibility. I know it is possible to implement a product with the required flexibility. -Bob O'Hara -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Abhijit Choudhury Sent: Thursday, August 05, 2004 11:32 AM To: James Kempf; Shehzad Merchant; capwap@frascone.com Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; Dorothy.Gellert@nokia.com; Inderpreet Singh Subject: RE: [Capwap] So many architectures, so little time... - take 2 It may be possible to achieve such interoperability within the split-MAC family or within the local-MAC family. It would sbe very hard to achieve that between local and split MAC families. For example, if vendor X's WTP terminates 802.11 ctrl/mgmt packets and vendor Y's AC expects the 802.11 mgmt packets to come to it, there's no way you can be interoperable. Or are we planning to specify ONE architecture ? The last thing IETF should do is mandate an implementation. I think a modest and reasonable goal is to come up with a protocol that allows sufficient flexbility so that vendors with splitMAC architectures can transfer most of the information they care about between the WTP and AC. Just my $0.02 ... Abhijit Choudhury -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf Sent: Wednesday, August 04, 2004 3:29 PM To: Shehzad Merchant; capwap@frascone.com Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; Dorothy.Gellert@nokia.com; Inderpreet Singh Subject: Re: [Capwap] So many architectures, so little time... - take 2 As a potential customer, let me put it concretely. I want to be able to buy my access points from Vendor X and my switch from Vendor Y and plug the two together and have them work without any configuration. Also, I'd like to be able to buy switches from Vendor Y and Vendor Z and be able to plug them into my network at various places and have them interoperate. jak ----- Original Message ----- From: "Shehzad Merchant" To: Cc: ; ; ; ; "Inderpreet Singh" Sent: Wednesday, August 04, 2004 3:19 PM Subject: RE: [Capwap] So many architectures, so little time... - take 2 > I think the implementation variations even with the split MAC may > cover a broad spectrum. As such its important to clearly articulate > what aspects of > interoperability we are targetting. Is it truly just > control/management or is it interoperability between disparate > implementations of the split MAC, i.e. mix and match operation of WTP > and ACs of all variants within this category. > > I suspect for the latter we may have to arrive at some consensus on > what particular implementations we are targeting interoperability for. > If so, ultimately this problem statement could become part of the > charter. > > -Shehzad > > > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf > Of Dorothy.Gellert@nokia.com > Sent: Wednesday, August 04, 2004 11:53 AM > To: isingh@chantrynetworks.com; capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > Subject: RE: [Capwap] So many architectures, so little time... - take > 2 > > I believe this is the consensus, to scope the charter to Centralized > Architecture and LocalMAC and Split MAC. > > I'll update the charter with this change after the CAPWAP WG Mtg. If > there is resistance to this idea, please post to the list. > > Regards > Dorothy > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > > Behalf Of ext Inderpreet Singh > > Sent: Tuesday, August 03, 2004 9:40 PM > > To: capwap@frascone.com > > Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David > > (Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > > Subject: RE: [Capwap] So many architectures, so little time... - > > take 2 > > > > > > The issue(s) at hand and my opinions are: > > > > 1. Do we explicitly state in the re-charter which architecture the > > WG should consider? I think yes. I propose Centralized architecture > > only. Autonomous and Distributed should be out of scope based on the > > same reasons as per prior postings. > > > > 2. Within Centralized do we focus on all three sub architectures or > > a subset? Remote MAC should be excluded because if I am not > > mistaken, the connectivity constraint between the WTP and the AC is > > "direct connect". > > That being the case and that no IP layer is involved, it doesn't seem > > clear what kind of protocol would help with interoperability. > > I am concerned about the impact, dependencies and interaction with > > the recently constituted IEEE Study group on AP functionality on the > > Split MAC architectures. Furthermore, there are some pretty drastic > > differences on how the vendors have chosen to split the mac. Those > > differences will need to be worked out before designing a protocol. > > So, if the low hanging fruit strategy (as James suggested) for > > protocol development and progress is the way to go, then I think > > prioritizing on a protocol for Local MAC is a no brainer. So as far > > as focus, I feel we should do Local and Split and in that order. > > > > 3. This is not a re-chartering issue but is a response to Pat's > > suggestion that a protocol that just sends the 802.11 MAC frames > > from the AP to the AC would work. I think possibly, yes. But again > > the complications of splitting the MAC in an interoperable way will > > be an issue. Also, you may note in the draft to which you refer, we > > included a capabilities exchange phase. I had thought of including > > in the capability exchange such things as "AP supports Local MAC" > > and "AP supports Split MAC", but didn't put it in because the > > Taxonomy work was still in progress. Now that it is pretty much > > done we could surely include that. But again...let's recharter > > first. > > > > Thanks. Do people agree with 1 & 2? > > > > --- > > Inderpreet Singh > > Chantry Networks > > isingh@chantrynetworks.com > > Cell: 416-831-3705 > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] > > On Behalf Of Pat R. Calhoun > > Sent: Tuesday, August 03, 2004 6:04 PM > > To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com; > > capwap@frascone.com > > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > > Subject: [Capwap] So many architectures, so little time... - take 2 > > > > After reading Lily's response to Jim, I realize that I fell down the > > same trap. Local MAC is also a centralized approach, and so my > > previous response was not complete. I believe the real question, in > > my mind, is whether we need to address either the Local or the Split > > MAC architecture. > > > > Just looking at the Architecture Consideration tables (7 and > > 10) in the > > specification, the > > main difference (at a high level) between both approaches is where > > the 802.11 management terminates. For Local MAC, it's in the WTP, > > while for SPlit MAC, it's in the AC. > > > > However, looking at table 8, most Local MAC approaches share STA > > state between both the WTP and the AC. So clearly there is some > > signalling protocol between both the WTP and the AC. > > > > Looking at one example of a Local MAC protocol (see > > http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > > there is a protocol message > > that corresponds for every 802.11 MAC management event. So when a > > STA associates, the AP breaks the message apart and creates an new > > protocol PDU, which contains components found in the association > > request. I suspect that most Local MAC approaches do something very > > similar. > > > > So if a protocol simply tunnels the 802.11 MAC management frames > > from the WTP to the AC, it allows supports both approaches. For > > Local MAC, they get what they want via the 802.11 frame, and this > > also works fine for Split MAC, which needs access to the MAC > > management frame. What would be required in such a protocol is a way > > for the AP to communicate whether it will be providing very specific > > functions - basically a capabilities negotiation approach. > > > > So I do believe that there is a way to address both architectures > > using a single protocol. > > > > Thoughts? > > > > PatC > > > > _______________________________________________ > > 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 _______________________________________________ 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 Aug 5 15:08:48 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07537 for ; Thu, 5 Aug 2004 15:08:46 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B94B521405; Thu, 5 Aug 2004 14:54:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4B62C21452; Thu, 5 Aug 2004 14:54:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 856CF21458 for ; Thu, 5 Aug 2004 14:53:08 -0400 (EDT) Received: from aruba-server.arubanetworks.com (mail.arubanetworks.com [64.60.249.195]) by mail.frascone.com (Postfix) with SMTP id C9CEF21405 for ; Thu, 5 Aug 2004 14:52:59 -0400 (EDT) Received: from [10.3.9.211] ([10.3.9.211] unverified) by aruba-server.arubanetworks.com over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Thu, 5 Aug 2004 12:07:28 -0700 Subject: RE: [Capwap] So many architectures, so little time... - take 2 From: Partha Narasimhan To: Victor Lin Cc: "Bob O'Hara" , capwap@frascone.com In-Reply-To: <4C8B0EA487B9554D910B0587CD91395C027B53DE@sc-msexch-03.extremenetworks.com> References: <4C8B0EA487B9554D910B0587CD91395C027B53DE@sc-msexch-03.extremenetworks.com> Content-Type: text/plain Organization: Aruba Wireless Networks, Inc. Message-Id: <1091732841.16594.67.camel@sap1.arubanetworks.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Aug 2004 19:07:28.0349 (UTC) FILETIME=[736618D0:01C47B1F] 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, 05 Aug 2004 12:07:21 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit IMHO, the incremental effort to achieve interoperability between local-MAC and split-MAC architectures is small enough (we all agree that the devil is in the details) that we should work towards such an interoperable solution. Otherwise, we run the risk of defining a fragmented protocol that may offer little more than the multiple, incompatible implementations that exist in the marketplace today. Thanks partha On Thu, 2004-08-05 at 11:46, Victor Lin wrote: > I agree that we can design a protocol and implement the product that works > all architectures. I think the question to CAPWAP is: > > Should we make it a requirement in CAPWAP protocol to achieve > interoperability between different architectures? > > It is definitely doable, but I'm not sure if that is the right thing to do.. > > Victor > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf > Of Bob O'Hara > Sent: Thursday, August 05, 2004 11:43 AM > To: capwap@frascone.com > Subject: RE: [Capwap] So many architectures, so little time... - take 2 > > I think that interoperability will depend on two things. First, it will > depend on how we define the protocol and the flexibility for supported > architectures it incorporates. Second, it will depend on what > manufacturers implement, i.e., the flexibility they build into their > products. > > I believe that it is possible to design the protocol for the required > flexibility. I know it is possible to implement a product with the > required flexibility. > > -Bob O'Hara > > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Abhijit Choudhury > Sent: Thursday, August 05, 2004 11:32 AM > To: James Kempf; Shehzad Merchant; capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; > Dorothy.Gellert@nokia.com; Inderpreet Singh > Subject: RE: [Capwap] So many architectures, so little time... - take 2 > > > It may be possible to achieve such interoperability > within the split-MAC family or within the local-MAC > family. It would sbe very hard to achieve > that between local and split MAC families. > > For example, if vendor X's WTP terminates 802.11 ctrl/mgmt > packets and vendor Y's AC expects the 802.11 mgmt packets > to come to it, there's no way you can be interoperable. > > Or are we planning to specify ONE architecture ? > The last thing IETF should do is mandate an implementation. > > I think a modest and reasonable goal is to come up > with a protocol that allows sufficient flexbility so > that vendors with splitMAC architectures can transfer > most of the information they care about between the WTP and AC. > > Just my $0.02 ... > > > Abhijit Choudhury > > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of James Kempf > Sent: Wednesday, August 04, 2004 3:29 PM > To: Shehzad Merchant; capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; > Dorothy.Gellert@nokia.com; Inderpreet Singh > Subject: Re: [Capwap] So many architectures, so little time... - take 2 > > > As a potential customer, let me put it concretely. I want to be able to > buy my access points from Vendor X and my switch from Vendor Y and plug > the two together and have them work without any configuration. Also, I'd > like to be able to buy switches from Vendor Y and Vendor Z and be able > to plug them into my network at various places and have them > interoperate. > > jak > > > ----- Original Message ----- > From: "Shehzad Merchant" > To: > Cc: ; ; ; > ; "Inderpreet Singh" > > Sent: Wednesday, August 04, 2004 3:19 PM > Subject: RE: [Capwap] So many architectures, so little time... - take 2 > > > > I think the implementation variations even with the split MAC may > > cover a broad spectrum. As such its important to clearly articulate > > what aspects > of > > interoperability we are targetting. Is it truly just > > control/management or is it interoperability between disparate > > implementations of the split MAC, i.e. mix and match operation of WTP > > and ACs of all variants within this category. > > > > I suspect for the latter we may have to arrive at some consensus on > > what particular implementations we are targeting interoperability for. > > > If so, ultimately this problem statement could become part of the > > charter. > > > > -Shehzad > > > > > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf > > Of Dorothy.Gellert@nokia.com > > Sent: Wednesday, August 04, 2004 11:53 AM > > To: isingh@chantrynetworks.com; capwap@frascone.com > > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > > Subject: RE: [Capwap] So many architectures, so little time... - take > > 2 > > > > I believe this is the consensus, to scope the charter to Centralized > > Architecture and LocalMAC and Split MAC. > > > > I'll update the charter with this change after the CAPWAP WG Mtg. If > > there is resistance to this idea, please post to the list. > > > > Regards > > Dorothy > > > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > > > Behalf Of ext Inderpreet Singh > > > Sent: Tuesday, August 03, 2004 9:40 PM > > > To: capwap@frascone.com > > > Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David > > > (Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > > > Subject: RE: [Capwap] So many architectures, so little time... - > > > take 2 > > > > > > > > > The issue(s) at hand and my opinions are: > > > > > > 1. Do we explicitly state in the re-charter which architecture the > > > WG should consider? I think yes. I propose Centralized architecture > > > > only. Autonomous and Distributed should be out of scope based on the > > > > same reasons as per prior postings. > > > > > > 2. Within Centralized do we focus on all three sub architectures or > > > a subset? Remote MAC should be excluded because if I am not > > > mistaken, the connectivity constraint between the WTP and the AC is > > > "direct connect". > > > That being the case and that no IP layer is involved, it doesn't > seem > > > clear what kind of protocol would help with interoperability. > > > I am concerned about the impact, dependencies and interaction with > > > the recently constituted IEEE Study group on AP functionality on the > > > Split MAC architectures. Furthermore, there are some pretty drastic > > > differences on how the vendors have chosen to split the mac. Those > > > differences will need to be worked out before designing a protocol. > > > So, if the low hanging fruit strategy (as James suggested) for > > > protocol development and progress is the way to go, then I think > > > prioritizing on a protocol for Local MAC is a no brainer. So as far > > > as focus, I feel we should do Local and Split and in that order. > > > > > > 3. This is not a re-chartering issue but is a response to Pat's > > > suggestion that a protocol that just sends the 802.11 MAC frames > > > from the AP to the AC would work. I think possibly, yes. But again > > > > the complications of splitting the MAC in an interoperable way will > > > be an issue. Also, you may note in the draft to which you refer, we > > > > included a capabilities exchange phase. I had thought of including > > > in the capability exchange such things as "AP supports Local MAC" > > > and "AP supports Split MAC", but didn't put it in because the > > > Taxonomy work was still in progress. Now that it is pretty much > > > done we could surely include that. But again...let's recharter > > > first. > > > > > > Thanks. Do people agree with 1 & 2? > > > > > > --- > > > Inderpreet Singh > > > Chantry Networks > > > isingh@chantrynetworks.com > > > Cell: 416-831-3705 > > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] > > > On Behalf Of Pat R. Calhoun > > > Sent: Tuesday, August 03, 2004 6:04 PM > > > To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com; > > > capwap@frascone.com > > > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > > > Subject: [Capwap] So many architectures, so little time... - take 2 > > > > > > After reading Lily's response to Jim, I realize that I fell down the > > > > same trap. Local MAC is also a centralized approach, and so my > > > previous response was not complete. I believe the real question, in > > > my mind, is whether we need to address either the Local or the Split > > > > MAC architecture. > > > > > > Just looking at the Architecture Consideration tables (7 and > > > 10) in the > > > specification, the > > > main difference (at a high level) between both approaches is where > > > the 802.11 management terminates. For Local MAC, it's in the WTP, > > > while for SPlit MAC, it's in the AC. > > > > > > However, looking at table 8, most Local MAC approaches share STA > > > state between both the WTP and the AC. So clearly there is some > > > signalling protocol between both the WTP and the AC. > > > > > > Looking at one example of a Local MAC protocol (see > > > http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > > > there is a protocol message > > > that corresponds for every 802.11 MAC management event. So when a > > > STA associates, the AP breaks the message apart and creates an new > > > protocol PDU, which contains components found in the association > > > request. I suspect that most Local MAC approaches do something very > > > similar. > > > > > > So if a protocol simply tunnels the 802.11 MAC management frames > > > from the WTP to the AC, it allows supports both approaches. For > > > Local MAC, they get what they want via the 802.11 frame, and this > > > also works fine for Split MAC, which needs access to the MAC > > > management frame. What would be required in such a protocol is a way > > > for the AP to communicate whether it will be providing very specific > > > functions - basically a capabilities negotiation approach. > > > > > > So I do believe that there is a way to address both architectures > > > using a single protocol. > > > > > > Thoughts? > > > > > > PatC > > > > > > _______________________________________________ > > > 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 > _______________________________________________ > 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 Aug 5 15:15:48 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08496 for ; Thu, 5 Aug 2004 15:15:46 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2967A21800; Thu, 5 Aug 2004 15:01:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AC2C921805; Thu, 5 Aug 2004 15:01:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 74DA521800 for ; Thu, 5 Aug 2004 15:00:07 -0400 (EDT) Received: from aples2.jhuapl.edu (aples2.dom1.jhuapl.edu [128.244.26.86]) by mail.frascone.com (Postfix) with ESMTP id 89A6C21458 for ; Thu, 5 Aug 2004 15:00:05 -0400 (EDT) Received: by aples2.dom1.jhuapl.edu with Internet Mail Service (5.5.2655.55) id ; Thu, 5 Aug 2004 15:13:55 -0400 Message-ID: From: "Burbank, Jack L." To: "'Victor Lin '" , "'Bob O'Hara '" , "'capwap@frascone.com '" Subject: RE: [Capwap] So many architectures, so little time... - take 2 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" 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, 5 Aug 2004 15:13:46 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I think that interoperability between different architectures should be a requirement, if not the key requirement. As was mentioned yesterday, a goal of the IEEE is that they maintain flexibility in terms of how products and architectures are implemented. I think we shouldn't do anything that is contrary to that goal (or at least we should minimize the impact). I think that the goal of CAPWAP should be to retain this type of flexibility by designing a protocol that can maintain this implementation flexibility but enable interoperability between the various architecture implementations (that after all is the key problem with the deployment of these various architectures - lack of interoperability). IMO, if we don't design for interoperability between the basic architecture types, it is debatable if something useful would have been accomplished. Jack Burbank -----Original Message----- From: capwap-admin@frascone.com To: Bob O'Hara; capwap@frascone.com Sent: 8/5/2004 2:46 PM Subject: RE: [Capwap] So many architectures, so little time... - take 2 I agree that we can design a protocol and implement the product that works all architectures. I think the question to CAPWAP is: Should we make it a requirement in CAPWAP protocol to achieve interoperability between different architectures? It is definitely doable, but I'm not sure if that is the right thing to do.. Victor -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Bob O'Hara Sent: Thursday, August 05, 2004 11:43 AM To: capwap@frascone.com Subject: RE: [Capwap] So many architectures, so little time... - take 2 I think that interoperability will depend on two things. First, it will depend on how we define the protocol and the flexibility for supported architectures it incorporates. Second, it will depend on what manufacturers implement, i.e., the flexibility they build into their products. I believe that it is possible to design the protocol for the required flexibility. I know it is possible to implement a product with the required flexibility. -Bob O'Hara -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Abhijit Choudhury Sent: Thursday, August 05, 2004 11:32 AM To: James Kempf; Shehzad Merchant; capwap@frascone.com Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; Dorothy.Gellert@nokia.com; Inderpreet Singh Subject: RE: [Capwap] So many architectures, so little time... - take 2 It may be possible to achieve such interoperability within the split-MAC family or within the local-MAC family. It would sbe very hard to achieve that between local and split MAC families. For example, if vendor X's WTP terminates 802.11 ctrl/mgmt packets and vendor Y's AC expects the 802.11 mgmt packets to come to it, there's no way you can be interoperable. Or are we planning to specify ONE architecture ? The last thing IETF should do is mandate an implementation. I think a modest and reasonable goal is to come up with a protocol that allows sufficient flexbility so that vendors with splitMAC architectures can transfer most of the information they care about between the WTP and AC. Just my $0.02 ... Abhijit Choudhury -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf Sent: Wednesday, August 04, 2004 3:29 PM To: Shehzad Merchant; capwap@frascone.com Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; Dorothy.Gellert@nokia.com; Inderpreet Singh Subject: Re: [Capwap] So many architectures, so little time... - take 2 As a potential customer, let me put it concretely. I want to be able to buy my access points from Vendor X and my switch from Vendor Y and plug the two together and have them work without any configuration. Also, I'd like to be able to buy switches from Vendor Y and Vendor Z and be able to plug them into my network at various places and have them interoperate. jak ----- Original Message ----- From: "Shehzad Merchant" To: Cc: ; ; ; ; "Inderpreet Singh" Sent: Wednesday, August 04, 2004 3:19 PM Subject: RE: [Capwap] So many architectures, so little time... - take 2 > I think the implementation variations even with the split MAC may > cover a broad spectrum. As such its important to clearly articulate > what aspects of > interoperability we are targetting. Is it truly just > control/management or is it interoperability between disparate > implementations of the split MAC, i.e. mix and match operation of WTP > and ACs of all variants within this category. > > I suspect for the latter we may have to arrive at some consensus on > what particular implementations we are targeting interoperability for. > If so, ultimately this problem statement could become part of the > charter. > > -Shehzad > > > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf > Of Dorothy.Gellert@nokia.com > Sent: Wednesday, August 04, 2004 11:53 AM > To: isingh@chantrynetworks.com; capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > Subject: RE: [Capwap] So many architectures, so little time... - take > 2 > > I believe this is the consensus, to scope the charter to Centralized > Architecture and LocalMAC and Split MAC. > > I'll update the charter with this change after the CAPWAP WG Mtg. If > there is resistance to this idea, please post to the list. > > Regards > Dorothy > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > > Behalf Of ext Inderpreet Singh > > Sent: Tuesday, August 03, 2004 9:40 PM > > To: capwap@frascone.com > > Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David > > (Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > > Subject: RE: [Capwap] So many architectures, so little time... - > > take 2 > > > > > > The issue(s) at hand and my opinions are: > > > > 1. Do we explicitly state in the re-charter which architecture the > > WG should consider? I think yes. I propose Centralized architecture > > only. Autonomous and Distributed should be out of scope based on the > > same reasons as per prior postings. > > > > 2. Within Centralized do we focus on all three sub architectures or > > a subset? Remote MAC should be excluded because if I am not > > mistaken, the connectivity constraint between the WTP and the AC is > > "direct connect". > > That being the case and that no IP layer is involved, it doesn't seem > > clear what kind of protocol would help with interoperability. > > I am concerned about the impact, dependencies and interaction with > > the recently constituted IEEE Study group on AP functionality on the > > Split MAC architectures. Furthermore, there are some pretty drastic > > differences on how the vendors have chosen to split the mac. Those > > differences will need to be worked out before designing a protocol. > > So, if the low hanging fruit strategy (as James suggested) for > > protocol development and progress is the way to go, then I think > > prioritizing on a protocol for Local MAC is a no brainer. So as far > > as focus, I feel we should do Local and Split and in that order. > > > > 3. This is not a re-chartering issue but is a response to Pat's > > suggestion that a protocol that just sends the 802.11 MAC frames > > from the AP to the AC would work. I think possibly, yes. But again > > the complications of splitting the MAC in an interoperable way will > > be an issue. Also, you may note in the draft to which you refer, we > > included a capabilities exchange phase. I had thought of including > > in the capability exchange such things as "AP supports Local MAC" > > and "AP supports Split MAC", but didn't put it in because the > > Taxonomy work was still in progress. Now that it is pretty much > > done we could surely include that. But again...let's recharter > > first. > > > > Thanks. Do people agree with 1 & 2? > > > > --- > > Inderpreet Singh > > Chantry Networks > > isingh@chantrynetworks.com > > Cell: 416-831-3705 > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] > > On Behalf Of Pat R. Calhoun > > Sent: Tuesday, August 03, 2004 6:04 PM > > To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com; > > capwap@frascone.com > > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > > Subject: [Capwap] So many architectures, so little time... - take 2 > > > > After reading Lily's response to Jim, I realize that I fell down the > > same trap. Local MAC is also a centralized approach, and so my > > previous response was not complete. I believe the real question, in > > my mind, is whether we need to address either the Local or the Split > > MAC architecture. > > > > Just looking at the Architecture Consideration tables (7 and > > 10) in the > > specification, the > > main difference (at a high level) between both approaches is where > > the 802.11 management terminates. For Local MAC, it's in the WTP, > > while for SPlit MAC, it's in the AC. > > > > However, looking at table 8, most Local MAC approaches share STA > > state between both the WTP and the AC. So clearly there is some > > signalling protocol between both the WTP and the AC. > > > > Looking at one example of a Local MAC protocol (see > > http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > > there is a protocol message > > that corresponds for every 802.11 MAC management event. So when a > > STA associates, the AP breaks the message apart and creates an new > > protocol PDU, which contains components found in the association > > request. I suspect that most Local MAC approaches do something very > > similar. > > > > So if a protocol simply tunnels the 802.11 MAC management frames > > from the WTP to the AC, it allows supports both approaches. For > > Local MAC, they get what they want via the 802.11 frame, and this > > also works fine for Split MAC, which needs access to the MAC > > management frame. What would be required in such a protocol is a way > > for the AP to communicate whether it will be providing very specific > > functions - basically a capabilities negotiation approach. > > > > So I do believe that there is a way to address both architectures > > using a single protocol. > > > > Thoughts? > > > > PatC > > > > _______________________________________________ > > 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 _______________________________________________ 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 Aug 5 17:25:46 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15878 for ; Thu, 5 Aug 2004 17:25:44 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 385DF1FD41; Thu, 5 Aug 2004 17:11:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1C74D1FE30; Thu, 5 Aug 2004 17:11:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0A7AC1FDD8 for ; Thu, 5 Aug 2004 17:10:36 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id 3606F1FD41 for ; Thu, 5 Aug 2004 17:10:34 -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 i75LNgx9005313 for ; Thu, 5 Aug 2004 17:23:42 -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 i75LNex9005274 for ; Thu, 5 Aug 2004 17:23:41 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] So many architectures, so little time... - take 2 Message-ID: Thread-Topic: [Capwap] So many architectures, so little time... - take 2 Thread-Index: AcR7HUSbc1FVFE4WQeerj8/ModK5dAAEg9OA From: "Mani, Mahalingam (Mahalingam)" To: "Victor Lin" , "Bob O'Hara" , 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, 5 Aug 2004 15:25:10 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I am all ears to sense WG consensus on 'interoperability' between different architectures. Also keen to understand why it is not the right thing to do. Besides, one may also want to qualify what constitutes 'interoperability' between different architectures beyond discovery of WTP<->AC mutual compatibility. That's a matter of detail. In principle I have so far heard the feasibility of a single protocol that can help speak cross-arch. It is the capability of end-entity implementations (AC, WTP) that will eventually drive its benefit. In actuality - I also see this as providing output which is useful input for AP functions interfaces. Further - I would also urge us to think about this in the perspective of the scope of interoperability - broadly on the control, provisioning/ configuration, monitoring/alerting aspects. If the data-plane (fast-path) can be cleanly separated out of consideration (as a side-effect that does not bring dependencies on the core aspects of control, provisioning/configuration) - it goes a long way in clarifying the protocol problem space and leaves much of the architectural complexity that *seemingly* clouds the control-plane realization. Regards, -mani -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Victor Lin Sent: Thursday, August 05, 2004 11:46 AM To: Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] So many architectures, so little time... - take 2 I agree that we can design a protocol and implement the product that works all architectures. I think the question to CAPWAP is: Should we make it a requirement in CAPWAP protocol to achieve interoperability between different architectures?=20 It is definitely doable, but I'm not sure if that is the right thing to do.. Victor -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Bob O'Hara Sent: Thursday, August 05, 2004 11:43 AM To: capwap@frascone.com Subject: RE: [Capwap] So many architectures, so little time... - take 2 I think that interoperability will depend on two things. First, it will depend on how we define the protocol and the flexibility for supported architectures it incorporates. Second, it will depend on what manufacturers implement, i.e., the flexibility they build into their products. =20 I believe that it is possible to design the protocol for the required flexibility. I know it is possible to implement a product with the required flexibility. -Bob O'Hara =20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Abhijit Choudhury Sent: Thursday, August 05, 2004 11:32 AM To: James Kempf; Shehzad Merchant; capwap@frascone.com Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; Dorothy.Gellert@nokia.com; Inderpreet Singh Subject: RE: [Capwap] So many architectures, so little time... - take 2 It may be possible to achieve such interoperability within the split-MAC family or within the local-MAC family. It would sbe very hard to achieve=20 that between local and split MAC families. For example, if vendor X's WTP terminates 802.11 ctrl/mgmt packets and vendor Y's AC expects the 802.11 mgmt packets to come to it, there's no way you can be interoperable. Or are we planning to specify ONE architecture ? The last thing IETF should do is mandate an implementation. I think a modest and reasonable goal is to come up=20 with a protocol that allows sufficient flexbility so that vendors with splitMAC architectures can transfer most of the information they care about between the WTP and AC. Just my $0.02 ... Abhijit Choudhury -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf Sent: Wednesday, August 04, 2004 3:29 PM To: Shehzad Merchant; capwap@frascone.com Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; Dorothy.Gellert@nokia.com; Inderpreet Singh Subject: Re: [Capwap] So many architectures, so little time... - take 2 As a potential customer, let me put it concretely. I want to be able to buy my access points from Vendor X and my switch from Vendor Y and plug the two together and have them work without any configuration. Also, I'd like to be able to buy switches from Vendor Y and Vendor Z and be able to plug them into my network at various places and have them interoperate. jak ----- Original Message -----=20 From: "Shehzad Merchant" To: Cc: ; ; ; ; "Inderpreet Singh" Sent: Wednesday, August 04, 2004 3:19 PM Subject: RE: [Capwap] So many architectures, so little time... - take 2 > I think the implementation variations even with the split MAC may=20 > cover a broad spectrum. As such its important to clearly articulate=20 > what aspects of > interoperability we are targetting. Is it truly just=20 > control/management or is it interoperability between disparate=20 > implementations of the split MAC, i.e. mix and match operation of WTP=20 > and ACs of all variants within this category. > > I suspect for the latter we may have to arrive at some consensus on=20 > what particular implementations we are targeting interoperability for. > If so, ultimately this problem statement could become part of the=20 > charter. > > -Shehzad > > > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf > Of Dorothy.Gellert@nokia.com > Sent: Wednesday, August 04, 2004 11:53 AM > To: isingh@chantrynetworks.com; capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > Subject: RE: [Capwap] So many architectures, so little time... - take=20 > 2 > > I believe this is the consensus, to scope the charter to Centralized=20 > Architecture and LocalMAC and Split MAC. > > I'll update the charter with this change after the CAPWAP WG Mtg. If=20 > there is resistance to this idea, please post to the list. > > Regards > Dorothy > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > > Behalf Of ext Inderpreet Singh > > Sent: Tuesday, August 03, 2004 9:40 PM > > To: capwap@frascone.com > > Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David=20 > > (Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > > Subject: RE: [Capwap] So many architectures, so little time... -=20 > > take 2 > > > > > > The issue(s) at hand and my opinions are: > > > > 1. Do we explicitly state in the re-charter which architecture the=20 > > WG should consider? I think yes. I propose Centralized architecture > > only. Autonomous and Distributed should be out of scope based on the > > same reasons as per prior postings. > > > > 2. Within Centralized do we focus on all three sub architectures or=20 > > a subset? Remote MAC should be excluded because if I am not=20 > > mistaken, the connectivity constraint between the WTP and the AC is=20 > > "direct connect". > > That being the case and that no IP layer is involved, it doesn't seem > > clear what kind of protocol would help with interoperability. > > I am concerned about the impact, dependencies and interaction with > > the recently constituted IEEE Study group on AP functionality on the > > Split MAC architectures. Furthermore, there are some pretty drastic > > differences on how the vendors have chosen to split the mac. Those > > differences will need to be worked out before designing a protocol. > > So, if the low hanging fruit strategy (as James suggested) for > > protocol development and progress is the way to go, then I think > > prioritizing on a protocol for Local MAC is a no brainer. So as far > > as focus, I feel we should do Local and Split and in that order. > > > > 3. This is not a re-chartering issue but is a response to Pat's=20 > > suggestion that a protocol that just sends the 802.11 MAC frames=20 > > from the AP to the AC would work. I think possibly, yes. But again > > the complications of splitting the MAC in an interoperable way will=20 > > be an issue. Also, you may note in the draft to which you refer, we > > included a capabilities exchange phase. I had thought of including=20 > > in the capability exchange such things as "AP supports Local MAC"=20 > > and "AP supports Split MAC", but didn't put it in because the=20 > > Taxonomy work was still in progress. Now that it is pretty much=20 > > done we could surely include that. But again...let's recharter=20 > > first. > > > > Thanks. Do people agree with 1 & 2? > > > > --- > > Inderpreet Singh > > Chantry Networks > > isingh@chantrynetworks.com > > Cell: 416-831-3705 > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]=20 > > On Behalf Of Pat R. Calhoun > > Sent: Tuesday, August 03, 2004 6:04 PM > > To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com;=20 > > capwap@frascone.com > > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > > Subject: [Capwap] So many architectures, so little time... - take 2 > > > > After reading Lily's response to Jim, I realize that I fell down the > > same trap. Local MAC is also a centralized approach, and so my=20 > > previous response was not complete. I believe the real question, in=20 > > my mind, is whether we need to address either the Local or the Split > > MAC architecture. > > > > Just looking at the Architecture Consideration tables (7 and > > 10) in the > > specification, the > > main difference (at a high level) between both approaches is where=20 > > the 802.11 management terminates. For Local MAC, it's in the WTP,=20 > > while for SPlit MAC, it's in the AC. > > > > However, looking at table 8, most Local MAC approaches share STA=20 > > state between both the WTP and the AC. So clearly there is some=20 > > signalling protocol between both the WTP and the AC. > > > > Looking at one example of a Local MAC protocol (see=20 > > http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > > there is a protocol message > > that corresponds for every 802.11 MAC management event. So when a=20 > > STA associates, the AP breaks the message apart and creates an new=20 > > protocol PDU, which contains components found in the association=20 > > request. I suspect that most Local MAC approaches do something very=20 > > similar. > > > > So if a protocol simply tunnels the 802.11 MAC management frames=20 > > from the WTP to the AC, it allows supports both approaches. For=20 > > Local MAC, they get what they want via the 802.11 frame, and this > > also works fine for Split MAC, which needs access to the MAC > > management frame. What would be required in such a protocol is a way > > for the AP to communicate whether it will be providing very specific > > functions - basically a capabilities negotiation approach. > > > > So I do believe that there is a way to address both architectures=20 > > using a single protocol. > > > > Thoughts? > > > > PatC > > > > _______________________________________________ > > 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 _______________________________________________ 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 Aug 5 17:34:09 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16432 for ; Thu, 5 Aug 2004 17:34:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CCF0A1FCD5; Thu, 5 Aug 2004 17:19:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4CBF41FE30; Thu, 5 Aug 2004 17:19:04 -0400 (EDT) Delivered-To: capwap@capwap.org Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E07371FE4A for ; Thu, 5 Aug 2004 17:18:06 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id A56C31FE30 for ; Thu, 5 Aug 2004 17:18:04 -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 i75LQ6SG012026 for ; Thu, 5 Aug 2004 16:26:06 -0500 (EST) 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 i75LQ4SG012009 for ; Thu, 5 Aug 2004 16:26:05 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C47B33.BC662E0D" Message-ID: Thread-Topic: IETF60 presentations Thread-Index: AcR7M7v0eZCG8hsOTMyWS30t5sY5nA== X-Priority: 1 Priority: Urgent Importance: high From: "Mani, Mahalingam (Mahalingam)" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] IETF60 presentations 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, 5 Aug 2004 15:32:40 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C47B33.BC662E0D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Are now placed in http://www.capwap.org/ietf60/ =20 The fourth, 4-mani-capwap-ietf60-chairs.ppt, was not presented (held back for time considerations) but it is hopefully self-explanatory of the endorsements the WG's taxonomy work and its outcome. =20 A sixth presentation on capwap classifications (Saravanan) is yet to be received (and will be posted when received). =20 -mani ------_=_NextPart_001_01C47B33.BC662E0D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Are now placed in http://www.capwap.org/ietf60/<= o:p>

 

The fourth, 4-mani-capwap-ietf60-chairs.ppt, was not presented (held back for time considerations) but it is hopefully self-explanatory of the endorsements the WG’s taxonomy work and = its outcome.

 

A sixth presentation on capwap classifications = (Saravanan) is yet to be received (and will be posted when = received).

 

-mani

------_=_NextPart_001_01C47B33.BC662E0D-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Aug 5 18:51:49 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24006 for ; Thu, 5 Aug 2004 18:51:47 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 001C91FE3E; Thu, 5 Aug 2004 18:37:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8AA6F1FE44; Thu, 5 Aug 2004 18:37:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 761E91FE3E for ; Thu, 5 Aug 2004 18:36:57 -0400 (EDT) Received: from panther.cs.ucla.edu (Panther.CS.UCLA.EDU [131.179.128.25]) by mail.frascone.com (Postfix) with ESMTP id 763201FD4E for ; Thu, 5 Aug 2004 18:36:55 -0400 (EDT) Received: from localhost (pzerfos@localhost) by panther.cs.ucla.edu (8.11.7p1+Sun/8.11.6/UCLACS-5.2) with ESMTP id i75MpD821320; Thu, 5 Aug 2004 15:51:14 -0700 (PDT) From: Petros Zerfos To: "Mani, Mahalingam (Mahalingam)" Cc: Victor Lin , "Bob O'Hara" , capwap@frascone.com Subject: RE: [Capwap] So many architectures, so little time... - take 2 In-Reply-To: Message-ID: References: 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, 5 Aug 2004 15:51:13 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Hi all, I agree that we need to clarify the notion of interoperability. Specially if we want to include the cross-architecture_family interoperability case, where we actually have (at least) the following combinations: local_MAC WTP | split_MAC WTP -------------------+--------------- local_MAC AC | R | D | | split_MAC AC | D | R Legend ------ R = Required D = Desirable I think that everybody agrees that (local_MAC AC, local_MAC WTP) and (split_MAC AC, split_MAC WTP) interoperability is needed. From the previous emails, it seems that the other two (the cross-arch. family) types are highly desirable. Do they make sense though, from the implementation point of view? Since I assume we want to avoid the "update the firmware of the WTP (or AC?)", as a solution :) Also, deliberately I didn't include the Autonomous_AP case (another arch. family, in the cross-arch._family interop conundrum), since the number of possible combinations would increase. Also, the case between [split_MAC AC <--> local_MAC AC] (and the respective intra-arch._family combos) would extend the matrix. Just a first (small) attempt to formalize the interoperability cases. Petros On Thu, 5 Aug 2004, Mani, Mahalingam (Mahalingam) wrote: > I am all ears to sense WG consensus on 'interoperability' between > different architectures. Also keen to understand why it is not the right > thing to do. > > Besides, one may also want to qualify what constitutes > 'interoperability' between different architectures beyond discovery of > WTP<->AC mutual compatibility. That's a matter of detail. > > In principle I have so far heard the feasibility of a single protocol > that can help speak cross-arch. It is the capability of end-entity > implementations (AC, WTP) that will eventually drive its benefit. > > In actuality - I also see this as providing output which is useful input > for AP functions interfaces. > > Further - I would also urge us to think about this in the perspective of > the scope of interoperability - broadly on the control, provisioning/ > configuration, monitoring/alerting aspects. > > If the data-plane (fast-path) can be cleanly separated out of > consideration (as a side-effect that does not bring dependencies on the > core aspects of control, provisioning/configuration) - it goes a long > way in clarifying the protocol problem space and leaves much of the > architectural complexity that *seemingly* clouds the control-plane > realization. > > Regards, > -mani > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Victor Lin > Sent: Thursday, August 05, 2004 11:46 AM > To: Bob O'Hara; capwap@frascone.com > Subject: RE: [Capwap] So many architectures, so little time... - take 2 > > I agree that we can design a protocol and implement the product that > works > all architectures. I think the question to CAPWAP is: > > Should we make it a requirement in CAPWAP protocol to achieve > interoperability between different architectures? > > It is definitely doable, but I'm not sure if that is the right thing to > do.. > > Victor > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf > Of Bob O'Hara > Sent: Thursday, August 05, 2004 11:43 AM > To: capwap@frascone.com > Subject: RE: [Capwap] So many architectures, so little time... - take 2 > > I think that interoperability will depend on two things. First, it will > depend on how we define the protocol and the flexibility for supported > architectures it incorporates. Second, it will depend on what > manufacturers implement, i.e., the flexibility they build into their > products. > > I believe that it is possible to design the protocol for the required > flexibility. I know it is possible to implement a product with the > required flexibility. > > -Bob O'Hara > > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Abhijit Choudhury > Sent: Thursday, August 05, 2004 11:32 AM > To: James Kempf; Shehzad Merchant; capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; > Dorothy.Gellert@nokia.com; Inderpreet Singh > Subject: RE: [Capwap] So many architectures, so little time... - take 2 > > > It may be possible to achieve such interoperability > within the split-MAC family or within the local-MAC > family. It would sbe very hard to achieve > that between local and split MAC families. > > For example, if vendor X's WTP terminates 802.11 ctrl/mgmt > packets and vendor Y's AC expects the 802.11 mgmt packets > to come to it, there's no way you can be interoperable. > > Or are we planning to specify ONE architecture ? > The last thing IETF should do is mandate an implementation. > > I think a modest and reasonable goal is to come up > with a protocol that allows sufficient flexbility so > that vendors with splitMAC architectures can transfer > most of the information they care about between the WTP and AC. > > Just my $0.02 ... > > > Abhijit Choudhury > > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of James Kempf > Sent: Wednesday, August 04, 2004 3:29 PM > To: Shehzad Merchant; capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; > Dorothy.Gellert@nokia.com; Inderpreet Singh > Subject: Re: [Capwap] So many architectures, so little time... - take 2 > > > As a potential customer, let me put it concretely. I want to be able to > buy my access points from Vendor X and my switch from Vendor Y and plug > the two together and have them work without any configuration. Also, I'd > like to be able to buy switches from Vendor Y and Vendor Z and be able > to plug them into my network at various places and have them > interoperate. > > jak > > > ----- Original Message ----- > From: "Shehzad Merchant" > To: > Cc: ; ; ; > ; "Inderpreet Singh" > > Sent: Wednesday, August 04, 2004 3:19 PM > Subject: RE: [Capwap] So many architectures, so little time... - take 2 > > > > I think the implementation variations even with the split MAC may > > cover a broad spectrum. As such its important to clearly articulate > > what aspects > of > > interoperability we are targetting. Is it truly just > > control/management or is it interoperability between disparate > > implementations of the split MAC, i.e. mix and match operation of WTP > > and ACs of all variants within this category. > > > > I suspect for the latter we may have to arrive at some consensus on > > what particular implementations we are targeting interoperability for. > > > If so, ultimately this problem statement could become part of the > > charter. > > > > -Shehzad > > > > > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf > > Of Dorothy.Gellert@nokia.com > > Sent: Wednesday, August 04, 2004 11:53 AM > > To: isingh@chantrynetworks.com; capwap@frascone.com > > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > > Subject: RE: [Capwap] So many architectures, so little time... - take > > 2 > > > > I believe this is the consensus, to scope the charter to Centralized > > Architecture and LocalMAC and Split MAC. > > > > I'll update the charter with this change after the CAPWAP WG Mtg. If > > there is resistance to this idea, please post to the list. > > > > Regards > > Dorothy > > > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > > > Behalf Of ext Inderpreet Singh > > > Sent: Tuesday, August 03, 2004 9:40 PM > > > To: capwap@frascone.com > > > Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David > > > (Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > > > Subject: RE: [Capwap] So many architectures, so little time... - > > > take 2 > > > > > > > > > The issue(s) at hand and my opinions are: > > > > > > 1. Do we explicitly state in the re-charter which architecture the > > > WG should consider? I think yes. I propose Centralized architecture > > > > only. Autonomous and Distributed should be out of scope based on the > > > > same reasons as per prior postings. > > > > > > 2. Within Centralized do we focus on all three sub architectures or > > > a subset? Remote MAC should be excluded because if I am not > > > mistaken, the connectivity constraint between the WTP and the AC is > > > "direct connect". > > > That being the case and that no IP layer is involved, it doesn't > seem > > > clear what kind of protocol would help with interoperability. > > > I am concerned about the impact, dependencies and interaction with > > > the recently constituted IEEE Study group on AP functionality on the > > > Split MAC architectures. Furthermore, there are some pretty drastic > > > differences on how the vendors have chosen to split the mac. Those > > > differences will need to be worked out before designing a protocol. > > > So, if the low hanging fruit strategy (as James suggested) for > > > protocol development and progress is the way to go, then I think > > > prioritizing on a protocol for Local MAC is a no brainer. So as far > > > as focus, I feel we should do Local and Split and in that order. > > > > > > 3. This is not a re-chartering issue but is a response to Pat's > > > suggestion that a protocol that just sends the 802.11 MAC frames > > > from the AP to the AC would work. I think possibly, yes. But again > > > > the complications of splitting the MAC in an interoperable way will > > > be an issue. Also, you may note in the draft to which you refer, we > > > > included a capabilities exchange phase. I had thought of including > > > in the capability exchange such things as "AP supports Local MAC" > > > and "AP supports Split MAC", but didn't put it in because the > > > Taxonomy work was still in progress. Now that it is pretty much > > > done we could surely include that. But again...let's recharter > > > first. > > > > > > Thanks. Do people agree with 1 & 2? > > > > > > --- > > > Inderpreet Singh > > > Chantry Networks > > > isingh@chantrynetworks.com > > > Cell: 416-831-3705 > > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] > > > On Behalf Of Pat R. Calhoun > > > Sent: Tuesday, August 03, 2004 6:04 PM > > > To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com; > > > capwap@frascone.com > > > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > > > Subject: [Capwap] So many architectures, so little time... - take 2 > > > > > > After reading Lily's response to Jim, I realize that I fell down the > > > > same trap. Local MAC is also a centralized approach, and so my > > > previous response was not complete. I believe the real question, in > > > my mind, is whether we need to address either the Local or the Split > > > > MAC architecture. > > > > > > Just looking at the Architecture Consideration tables (7 and > > > 10) in the > > > specification, the > > > main difference (at a high level) between both approaches is where > > > the 802.11 management terminates. For Local MAC, it's in the WTP, > > > while for SPlit MAC, it's in the AC. > > > > > > However, looking at table 8, most Local MAC approaches share STA > > > state between both the WTP and the AC. So clearly there is some > > > signalling protocol between both the WTP and the AC. > > > > > > Looking at one example of a Local MAC protocol (see > > > http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > > > there is a protocol message > > > that corresponds for every 802.11 MAC management event. So when a > > > STA associates, the AP breaks the message apart and creates an new > > > protocol PDU, which contains components found in the association > > > request. I suspect that most Local MAC approaches do something very > > > similar. > > > > > > So if a protocol simply tunnels the 802.11 MAC management frames > > > from the WTP to the AC, it allows supports both approaches. For > > > Local MAC, they get what they want via the 802.11 frame, and this > > > also works fine for Split MAC, which needs access to the MAC > > > management frame. What would be required in such a protocol is a way > > > for the AP to communicate whether it will be providing very specific > > > functions - basically a capabilities negotiation approach. > > > > > > So I do believe that there is a way to address both architectures > > > using a single protocol. > > > > > > Thoughts? > > > > > > PatC > > > > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap > > > -- Petros Th. Zerfos UCLA - Computer Science Department email : pzerfos@cs.ucla.edu _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Aug 5 19:49:47 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27169 for ; Thu, 5 Aug 2004 19:49:46 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DE66521931; Thu, 5 Aug 2004 19:35:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 91CFE2192E; Thu, 5 Aug 2004 19:35:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1C8B621933 for ; Thu, 5 Aug 2004 19:34:16 -0400 (EDT) Received: from extrgate1.extremenetworks.com (unknown [66.7.144.52]) by mail.frascone.com (Postfix) with ESMTP id 28B702192E for ; Thu, 5 Aug 2004 19:34:14 -0400 (EDT) Received: by extrgate1.extremenetworks.com with Internet Mail Service (5.5.2656.59) id <388CKTA7>; Thu, 5 Aug 2004 16:48:24 -0700 Message-ID: <1B8A2DD33C49824F8D9021678C127213026B0AC6@sc-msexch-04.extremenetworks.com> From: Shehzad Merchant To: Paul Lambert , Abhijit Choudhury , James Kempf , Shehzad Merchant , capwap@frascone.com Cc: bwijnen@lucent.com, mmani@avaya.com, david.kessens@nokia.com, Dorothy.Gellert@nokia.com, Inderpreet Singh Subject: RE: [Capwap] So many architectures, so little time... - take 2 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) 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: Thu, 5 Aug 2004 16:48:45 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) To achieve interoperability one needs to define what you are trying to interopate between. i.e. you need to pick a model or a set of models between which interopability is guaranteed. Leaving that open ended will probably make interoperability more difficult and more drawn out. As such, I think we need to be explicit as to what architectures or subarchitectures one is targetting interoperability between and if that is a TBD, then perhaps the charter should make that a problem statement. -Shehzad -----Original Message----- From: Paul Lambert [mailto:PaulLambert@AirgoNetworks.Com] Sent: Thursday, August 05, 2004 4:18 PM To: Abhijit Choudhury; James Kempf; Shehzad Merchant; capwap@frascone.com Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; Dorothy.Gellert@nokia.com; Inderpreet Singh Subject: RE: [Capwap] So many architectures, so little time... - take 2 > The last thing IETF should do is mandate an implementation. Why not. Most IETF standards require two reference implementations that interoperate. If this working group is producing multiple non-iteroperable protocols, it should split into more than one working group. This working group should pick one approach, or disband. The current documentation has been a excellent survey, now the working group needs to move forward to a single 'consensus' solution. Paul > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Abhijit Choudhury > Sent: Thursday, August 05, 2004 11:32 AM > To: James Kempf; Shehzad Merchant; capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; > Dorothy.Gellert@nokia.com; Inderpreet Singh > Subject: RE: [Capwap] So many architectures, so little time... - take > 2 > > It may be possible to achieve such interoperability within the > split-MAC family or within the local-MAC family. It would sbe very > hard to achieve that between local and split MAC families. > > For example, if vendor X's WTP terminates 802.11 ctrl/mgmt packets and > vendor Y's AC expects the 802.11 mgmt packets to come to it, there's > no way you can be interoperable. > > Or are we planning to specify ONE architecture ? > The last thing IETF should do is mandate an implementation. > > I think a modest and reasonable goal is to come up with a protocol > that allows sufficient flexbility so that vendors with splitMAC > architectures can transfer most of the information they care about > between the WTP and AC. > > Just my $0.02 ... > > > Abhijit Choudhury > > > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf > Sent: Wednesday, August 04, 2004 3:29 PM > To: Shehzad Merchant; capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; > Dorothy.Gellert@nokia.com; Inderpreet Singh > Subject: Re: [Capwap] So many architectures, so little time... - take > 2 > > > As a potential customer, let me put it concretely. I want to be able > to buy my access points from Vendor X and my switch from Vendor Y and > plug the two together and have them work without any configuration. > Also, I'd like to be able to buy switches from Vendor Y and Vendor Z > and be able to plug them into my network at various places and have > them interoperate. > > jak > > > ----- Original Message ----- > From: "Shehzad Merchant" > To: > Cc: ; ; > ; ; "Inderpreet > Singh" > > Sent: Wednesday, August 04, 2004 3:19 PM > Subject: RE: [Capwap] So many architectures, so little time... - take > 2 > > > > I think the implementation variations even with the split MAC may > > cover a broad spectrum. As such its important to clearly articulate > > what aspects > of > > interoperability we are targetting. Is it truly just > > control/management or is it interoperability between disparate > > implementations of the split MAC, i.e. mix and match > operation of WTP > > and ACs of all variants within this category. > > > > I suspect for the latter we may have to arrive at some consensus on > > what particular implementations we are targeting > interoperability for. > > > If so, ultimately this problem statement could become part of the > > charter. > > > > -Shehzad > > > > > > > > -----Original Message----- > > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On > Behalf > > Of Dorothy.Gellert@nokia.com > > Sent: Wednesday, August 04, 2004 11:53 AM > > To: isingh@chantrynetworks.com; capwap@frascone.com > > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > > Subject: RE: [Capwap] So many architectures, so little > time... - take > > 2 > > > > I believe this is the consensus, to scope the charter to > Centralized > > Architecture and LocalMAC and Split MAC. > > > > I'll update the charter with this change after the CAPWAP > WG Mtg. If > > there is resistance to this idea, please post to the list. > > > > Regards > > Dorothy > > > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com]On > > > Behalf Of ext Inderpreet Singh > > > Sent: Tuesday, August 03, 2004 9:40 PM > > > To: capwap@frascone.com > > > Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David > > > (Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > > > Subject: RE: [Capwap] So many architectures, so little time... - > > > take 2 > > > > > > > > > The issue(s) at hand and my opinions are: > > > > > > 1. Do we explicitly state in the re-charter which > architecture the > > > WG should consider? I think yes. I propose Centralized > architecture > > > > only. Autonomous and Distributed should be out of scope > based on the > > > > same reasons as per prior postings. > > > > > > 2. Within Centralized do we focus on all three sub > architectures or > > > a subset? Remote MAC should be excluded because if I am not > > > mistaken, the connectivity constraint between the WTP and > the AC is > > > "direct connect". > > > That being the case and that no IP layer is involved, it doesn't > seem > > > clear what kind of protocol would help with interoperability. > > > I am concerned about the impact, dependencies and interaction with > > > the recently constituted IEEE Study group on AP > functionality on the > > > Split MAC architectures. Furthermore, there are some > pretty drastic > > > differences on how the vendors have chosen to split the > mac. Those > > > differences will need to be worked out before designing a > protocol. > > > So, if the low hanging fruit strategy (as James suggested) for > > > protocol development and progress is the way to go, then I think > > > prioritizing on a protocol for Local MAC is a no brainer. > So as far > > > as focus, I feel we should do Local and Split and in that order. > > > > > > 3. This is not a re-chartering issue but is a response to Pat's > > > suggestion that a protocol that just sends the 802.11 MAC frames > > > from the AP to the AC would work. I think possibly, yes. > But again > > > > the complications of splitting the MAC in an > interoperable way will > > > be an issue. Also, you may note in the draft to which > you refer, we > > > > included a capabilities exchange phase. I had thought of > including > > > in the capability exchange such things as "AP supports Local MAC" > > > and "AP supports Split MAC", but didn't put it in because the > > > Taxonomy work was still in progress. Now that it is pretty much > > > done we could surely include that. But again...let's recharter > > > first. > > > > > > Thanks. Do people agree with 1 & 2? > > > > > > --- > > > Inderpreet Singh > > > Chantry Networks > > > isingh@chantrynetworks.com > > > Cell: 416-831-3705 > > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] > > > On Behalf Of Pat R. Calhoun > > > Sent: Tuesday, August 03, 2004 6:04 PM > > > To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com; > > > capwap@frascone.com > > > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > > > Subject: [Capwap] So many architectures, so little > time... - take 2 > > > > > > After reading Lily's response to Jim, I realize that I > fell down the > > > > same trap. Local MAC is also a centralized approach, and so my > > > previous response was not complete. I believe the real > question, in > > > my mind, is whether we need to address either the Local > or the Split > > > > MAC architecture. > > > > > > Just looking at the Architecture Consideration tables (7 and > > > 10) in the > > > specification, the > > > main difference (at a high level) between both approaches > is where > > > the 802.11 management terminates. For Local MAC, it's in the WTP, > > > while for SPlit MAC, it's in the AC. > > > > > > However, looking at table 8, most Local MAC approaches share STA > > > state between both the WTP and the AC. So clearly there is some > > > signalling protocol between both the WTP and the AC. > > > > > > Looking at one example of a Local MAC protocol (see > > > > http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > > > there is a protocol message > > > that corresponds for every 802.11 MAC management event. So when a > > > STA associates, the AP breaks the message apart and > creates an new > > > protocol PDU, which contains components found in the association > > > request. I suspect that most Local MAC approaches do > something very > > > similar. > > > > > > So if a protocol simply tunnels the 802.11 MAC management frames > > > from the WTP to the AC, it allows supports both approaches. For > > > Local MAC, they get what they want via the 802.11 frame, and this > > > also works fine for Split MAC, which needs access to the MAC > > > management frame. What would be required in such a > protocol is a way > > > for the AP to communicate whether it will be providing > very specific > > > functions - basically a capabilities negotiation approach. > > > > > > So I do believe that there is a way to address both architectures > > > using a single protocol. > > > > > > Thoughts? > > > > > > PatC > > > > > > _______________________________________________ > > > 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 > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Aug 5 21:47:46 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02950 for ; Thu, 5 Aug 2004 21:47:45 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 393C21FEA0; Thu, 5 Aug 2004 21:33:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4CF091FEC4; Thu, 5 Aug 2004 21:33:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2C7171FEC9 for ; Thu, 5 Aug 2004 21:32:46 -0400 (EDT) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id CA0E51FEA0 for ; Thu, 5 Aug 2004 21:32:43 -0400 (EDT) Received: from Palpatine ([10.81.113.73]) by mailsrv.psl.com.sg (8.13.0/8.13.0) with ESMTP id i761iL14008519; Fri, 6 Aug 2004 09:44:30 +0800 (SGT) From: "Cheng Hong" To: "'Petros Zerfos'" , "'Mani, Mahalingam (Mahalingam)'" , Cc: "'Victor Lin'" , "'Bob O'Hara'" Subject: RE: [Capwap] So many architectures, so little time... - take 2 Organization: Panasonic Singapore Laboratories Message-ID: <002601c47b57$34d5e220$4971510a@Palpatine> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal 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, 6 Aug 2004 09:46:28 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Petros, That is a nice table to start discussion.=20 Regarding the interoperability table, please see some comments inline. > Hi all, >=20 > I agree that we need to clarify the notion of=20 > interoperability. Specially if we want to include the=20 > cross-architecture_family interoperability case, where we=20 > actually have (at least) the following combinations: >=20 > local_MAC WTP | split_MAC WTP > -------------------+--------------- > local_MAC AC | R | D > | | > split_MAC AC | D | R >=20 > Legend > ------ > R =3D Required > D =3D Desirable >=20 > I think that everybody agrees that (local_MAC AC, local_MAC=20 > WTP) and (split_MAC AC, split_MAC WTP) interoperability is needed. Agree. Without this, I don't think the protocol could achieve anything, unless the group is going towards one single implementation. > From the previous emails, it seems that the other two (the cross-arch. > family) types are highly desirable. Do they make sense=20 > though, from the implementation point of view? Since I assume=20 > we want to avoid the "update the firmware of the WTP (or=20 > AC?)", as a solution :) Not sure about the (Local_MAC AC, Split MAC WTP) case, since it may = require the some architecture change or additional functions in the WT or AC. = But for the (Split_MAC AC, Local_MAC WTP) case, interoperability should be supported. This does not need to update WTP, and only thing is for the = AC to support a subset of the functions it already has. This doesn't seems = like an irrational requirement. > Also, deliberately I didn't include the Autonomous_AP case=20 > (another arch. family, in the cross-arch._family interop=20 > conundrum), since the number of possible combinations would=20 > increase. Also, the case between [split_MAC AC <--> local_MAC=20 > AC] (and the respective intra-arch._family combos) would=20 > extend the matrix. It may make the matrix not as clean as it is, but including those could clearly indicate the group's stand on the extra possibilities. If = certain case could not be decided now, we can indicate it with T (TBD) and come = back later. I guess we need a full table in the "Objective" draft in the end. cheers Cheng > Just a first (small) attempt to formalize the interoperability cases. >=20 > Petros >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Aug 6 08:11:49 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22829 for ; Fri, 6 Aug 2004 08:11:48 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5CBE8209CD; Fri, 6 Aug 2004 07:57:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 15FA921025; Fri, 6 Aug 2004 07:57:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1C49E21025 for ; Fri, 6 Aug 2004 07:56:18 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 50923209CD for ; Fri, 6 Aug 2004 07:56: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 i76C4HSG005531 for ; Fri, 6 Aug 2004 07:04:18 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i76C4ESG005453 for ; Fri, 6 Aug 2004 07:04:16 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] So many architectures, so little time... - take 2 Message-ID: Thread-Topic: [Capwap] So many architectures, so little time... - take 2 Thread-Index: AcR6cqh5U/BKoibBQ+2liOxj9V97+wBOk7+A From: "Sadot, Emek (Emek)" To: "James Kempf" , "Shehzad Merchant" , Cc: , "Mani, Mahalingam (Mahalingam)" , , , "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, 6 Aug 2004 15:10:50 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I think that we should be very careful in adopting switch to switch = interoperability and protocol definition as part of the CAPWAP charter. = It certainly make sense for customer to purchase APs from different = vendors, though I don't 100% sure for different vendors' ACs. Even if it make sense, recharging the CAPWAP to encompass switch to = switch interoperability will jeopardize the chance of the CAPWAP to = converge. Time wise. Emek -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On = Behalf Of James Kempf Sent: Thursday, 05 August, 2004 1:29 AM To: Shehzad Merchant; capwap@frascone.com Cc: bwijnen@lucent.com; Mani, Mahalingam (Mahalingam); = david.kessens@nokia.com; Dorothy.Gellert@nokia.com; Inderpreet Singh Subject: Re: [Capwap] So many architectures, so little time... - take 2 As a potential customer, let me put it concretely. I want to be able to = buy my access points from Vendor X and my switch from Vendor Y and plug the = two together and have them work without any configuration. Also, I'd like to = be able to buy switches from Vendor Y and Vendor Z and be able to plug them into my network at various places and have them interoperate. jak ----- Original Message -----=20 From: "Shehzad Merchant" To: Cc: ; ; ; ; "Inderpreet Singh" = Sent: Wednesday, August 04, 2004 3:19 PM Subject: RE: [Capwap] So many architectures, so little time... - take 2 > I think the implementation variations even with the split MAC may = cover a > broad spectrum. As such its important to clearly articulate what = aspects of > interoperability we are targetting. Is it truly just = control/management or > is it interoperability between disparate implementations of the split = MAC, > i.e. mix and match operation of WTP and ACs of all variants within = this > category. > > I suspect for the latter we may have to arrive at some consensus on = what > particular implementations we are targeting interoperability for. If = so, > ultimately this problem statement could become part of the charter. > > -Shehzad > > > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf > Of Dorothy.Gellert@nokia.com > Sent: Wednesday, August 04, 2004 11:53 AM > To: isingh@chantrynetworks.com; capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > Subject: RE: [Capwap] So many architectures, so little time... - take = 2 > > I believe this is the consensus, to scope the charter to Centralized > Architecture and LocalMAC and Split MAC. > > I'll update the charter with this change after the CAPWAP WG Mtg. > If there is resistance to this idea, please post to the list. > > Regards > Dorothy > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > > Behalf Of ext Inderpreet Singh > > Sent: Tuesday, August 03, 2004 9:40 PM > > To: capwap@frascone.com > > Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David > > (Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > > Subject: RE: [Capwap] So many architectures, so little time... - = take > > 2 > > > > > > The issue(s) at hand and my opinions are: > > > > 1. Do we explicitly state in the re-charter which architecture the = WG > > should consider? > > I think yes. I propose Centralized architecture only. > > Autonomous and Distributed should be out of scope based on the same > > reasons as per prior postings. > > > > 2. Within Centralized do we focus on all three sub architectures or = a > > subset? > > Remote MAC should be excluded because if I am not mistaken, the > > connectivity constraint between the WTP and the AC is "direct > > connect". > > That being the case and that no IP layer is involved, it doesn't = seem > > clear what kind of protocol would help with interoperability. > > I am concerned about the impact, dependencies and interaction with > > the recently constituted IEEE Study group on AP functionality on the > > Split MAC architectures. Furthermore, there are some pretty drastic > > differences on how the vendors have chosen to split the mac. Those > > differences will need to be worked out before designing a protocol. > > So, if the low hanging fruit strategy (as James suggested) for > > protocol development and progress is the way to go, then I think > > prioritizing on a protocol for Local MAC is a no brainer. So as far > > as focus, I feel we should do Local and Split and in that order. > > > > 3. This is not a re-chartering issue but is a response to Pat's > > suggestion that a protocol that just sends the 802.11 MAC frames = from > > the AP to the AC would work. I think possibly, yes. But again the > > complications of splitting the MAC in an interoperable way will be = an > > issue. Also, you may note in the draft to which you refer, we > > included a capabilities exchange phase. I had thought of including = in > > the capability exchange such things as "AP supports Local MAC" and = "AP > > supports Split MAC", but didn't put it in because the Taxonomy work > > was still in progress. Now that it is pretty much done we could > > surely include that. But again...let's recharter first. > > > > Thanks. Do people agree with 1 & 2? > > > > --- > > Inderpreet Singh > > Chantry Networks > > isingh@chantrynetworks.com > > Cell: 416-831-3705 > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] = On > > Behalf Of Pat R. Calhoun > > Sent: Tuesday, August 03, 2004 6:04 PM > > To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com; > > capwap@frascone.com > > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > > Subject: [Capwap] So many architectures, so little time... - take 2 > > > > After reading Lily's response to Jim, I realize that I fell down the > > same trap. Local MAC is also a centralized approach, and so my > > previous response was not complete. I believe the real question, in = my > > mind, is whether we need to address either the Local or the Split = MAC > > architecture. > > > > Just looking at the Architecture Consideration tables (7 and > > 10) in the > > specification, the > > main difference (at a high level) between both approaches is where = the > > 802.11 management > > terminates. For Local MAC, it's in the WTP, while for SPlit MAC, = it's > > in the AC. > > > > However, looking at table 8, most Local MAC approaches share STA = state > > between both the WTP and the AC. So clearly there is some signalling > > protocol between both the WTP and the AC. > > > > Looking at one example of a Local MAC protocol (see > > http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > > there is a protocol message > > that corresponds for every 802.11 MAC management event. So when a = STA > > associates, the AP breaks the message apart and creates an new > > protocol PDU, which contains components found in the association > > request. I suspect that most Local MAC approaches do something very > > similar. > > > > So if a protocol simply tunnels the 802.11 MAC management frames = from > > the WTP to the AC, it allows supports both approaches. For Local = MAC, > > they get what they want via the > > 802.11 frame, and this > > also works fine for Split MAC, which needs access to the MAC > > management frame. What would be required in such a protocol is a way > > for the AP to communicate whether it will be providing very specific > > functions - basically a capabilities negotiation approach. > > > > So I do believe that there is a way to address both architectures > > using a single protocol. > > > > Thoughts? > > > > PatC > > > > _______________________________________________ > > 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 Fri Aug 6 08:21:49 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23258 for ; Fri, 6 Aug 2004 08:21:48 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2C389212C0; Fri, 6 Aug 2004 08:07:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DB2282102D; Fri, 6 Aug 2004 08:07:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 45B94209F8 for ; Fri, 6 Aug 2004 08:06:37 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id 8961921025 for ; Fri, 6 Aug 2004 08:06:35 -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 i76CJix9013634 for ; Fri, 6 Aug 2004 08:19:44 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i76CJfx9013576 for ; Fri, 6 Aug 2004 08:19:42 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] So many architectures, so little time... - take 2 Message-ID: Thread-Topic: [Capwap] So many architectures, so little time... - take 2 Thread-Index: AcR7V2Uu9xFfLIRFSAuJbf7Cap84FAAVxglA From: "Sadot, Emek (Emek)" To: "Cheng Hong" , "Petros Zerfos" , "Mani, Mahalingam (Mahalingam)" , Cc: "Victor Lin" , "Bob O'Hara" 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, 6 Aug 2004 15:21:10 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable The distinction between local and split is known to a limited group of = people. I would bet that customers need to make a decision to buy AP will not = show interest in split versus local architecture. Functionality, price, = interoperability will be the customers' criteria. In my humble opinion the group must strive for interoperability between = AC and AP irrespectively to split versus local. CAPWAP should not = support any variant on the 0..1 line but 2 to (max) 3 protocols flavors = would do the trick. I would change the "D" to "R" Emek -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On = Behalf Of Cheng Hong Sent: Friday, 06 August, 2004 4:46 AM To: 'Petros Zerfos'; Mani, Mahalingam (Mahalingam); capwap@frascone.com Cc: 'Victor Lin'; 'Bob O'Hara' Subject: RE: [Capwap] So many architectures, so little time... - take 2 Hi Petros, That is a nice table to start discussion.=20 Regarding the interoperability table, please see some comments inline. > Hi all, >=20 > I agree that we need to clarify the notion of=20 > interoperability. Specially if we want to include the=20 > cross-architecture_family interoperability case, where we=20 > actually have (at least) the following combinations: >=20 > local_MAC WTP | split_MAC WTP > -------------------+--------------- > local_MAC AC | R | D > | | > split_MAC AC | D | R >=20 > Legend > ------ > R =3D Required > D =3D Desirable >=20 > I think that everybody agrees that (local_MAC AC, local_MAC=20 > WTP) and (split_MAC AC, split_MAC WTP) interoperability is needed. Agree. Without this, I don't think the protocol could achieve anything, unless the group is going towards one single implementation. > From the previous emails, it seems that the other two (the cross-arch. > family) types are highly desirable. Do they make sense=20 > though, from the implementation point of view? Since I assume=20 > we want to avoid the "update the firmware of the WTP (or=20 > AC?)", as a solution :) Not sure about the (Local_MAC AC, Split MAC WTP) case, since it may = require the some architecture change or additional functions in the WT or AC. = But for the (Split_MAC AC, Local_MAC WTP) case, interoperability should be supported. This does not need to update WTP, and only thing is for the = AC to support a subset of the functions it already has. This doesn't seems = like an irrational requirement. > Also, deliberately I didn't include the Autonomous_AP case=20 > (another arch. family, in the cross-arch._family interop=20 > conundrum), since the number of possible combinations would=20 > increase. Also, the case between [split_MAC AC <--> local_MAC=20 > AC] (and the respective intra-arch._family combos) would=20 > extend the matrix. It may make the matrix not as clean as it is, but including those could clearly indicate the group's stand on the extra possibilities. If = certain case could not be decided now, we can indicate it with T (TBD) and come = back later. I guess we need a full table in the "Objective" draft in the end. cheers Cheng > Just a first (small) attempt to formalize the interoperability cases. >=20 > Petros >=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 Aug 6 09:47:52 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26785 for ; Fri, 6 Aug 2004 09:47:49 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7F49620FF1; Fri, 6 Aug 2004 09:33:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5DD4020381; Fri, 6 Aug 2004 09:33:05 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AB98420381 for ; Fri, 6 Aug 2004 09:32:38 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id BAAD51FF40 for ; Fri, 6 Aug 2004 09:32:34 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C47BBC.4D39B2B2" Subject: RE: [Capwap] So many architectures, so little time... - take 2 Message-ID: <55749BC69138654EBBC4C50BA4F55610020C44CE@AIREMAIL.airespace.com> Thread-Topic: [Capwap] So many architectures, so little time... - take 2 Thread-Index: AcR6cvB6i/Y6+JuATMK0pGMKAhGL6QApcxAQACjAk1c= From: "Pat R. Calhoun" To: "Abhijit Choudhury" , "James Kempf" , "Shehzad Merchant" , Cc: , , , , "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, 6 Aug 2004 06:46:16 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C47BBC.4D39B2B2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I guess it's no surprise that I disagree. Yes, there are functions in = split MAC that typically occur in the AC, while they normally occur in the WTP in local = MAC. However, what you will find is that in Local MAC, the functions really occurs in = both places, but the notification that is sent from the WTP to the AC is not an 802.11 = packet, but a packet that was derived from an 802.11 packet (for instance, the AP = breaks apart the=20 association request and sends a notification). Frankly, in the end it's = nearly the same thing. I really don't think that the architecture is that different. Furthermore, there is a HUGE disadvantage with a local MAC approach = (looking at the CTP protocol for instance, since its the only one that is available). When = the IEEE comes up with some extensions to 802.11 (e.g. 802.11e), there will be a need to = get together and create an extension to the local MAC protocol to pass this information = to the AC... so hierarchical systems will always lag in feature set until the IETF is = ready with the protocol extension - and those could take 12 months. The split MAC approach ensures that both the WTP and the AC receive the = 802.11 packets=20 and can therefore instantly support any new IEEE 802.11 extensions. PatC -----Original Message----- From: capwap-admin@frascone.com on behalf of Abhijit Choudhury Sent: Thu 8/5/2004 11:32 AM To: James Kempf; Shehzad Merchant; capwap@frascone.com Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; = Dorothy.Gellert@nokia.com; Inderpreet Singh Subject: RE: [Capwap] So many architectures, so little time... - take 2 =20 It may be possible to achieve such interoperability within the split-MAC family or within the local-MAC family. It would sbe very hard to achieve=20 that between local and split MAC families. For example, if vendor X's WTP terminates 802.11 ctrl/mgmt packets and vendor Y's AC expects the 802.11 mgmt packets to come to it, there's no way you can be interoperable. Or are we planning to specify ONE architecture ? The last thing IETF should do is mandate an implementation. I think a modest and reasonable goal is to come up=20 with a protocol that allows sufficient flexbility so that vendors with splitMAC architectures can transfer most of the information they care about between the WTP and AC. Just my $0.02 ... Abhijit Choudhury -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf Sent: Wednesday, August 04, 2004 3:29 PM To: Shehzad Merchant; capwap@frascone.com Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; Dorothy.Gellert@nokia.com; Inderpreet Singh Subject: Re: [Capwap] So many architectures, so little time... - take 2 As a potential customer, let me put it concretely. I want to be able to buy my access points from Vendor X and my switch from Vendor Y and plug the two together and have them work without any configuration. Also, I'd like to be able to buy switches from Vendor Y and Vendor Z and be able to plug them into my network at various places and have them interoperate. jak ----- Original Message -----=20 From: "Shehzad Merchant" To: Cc: ; ; ; ; "Inderpreet Singh" Sent: Wednesday, August 04, 2004 3:19 PM Subject: RE: [Capwap] So many architectures, so little time... - take 2 > I think the implementation variations even with the split MAC may=20 > cover a broad spectrum. As such its important to clearly articulate=20 > what aspects of > interoperability we are targetting. Is it truly just=20 > control/management or is it interoperability between disparate=20 > implementations of the split MAC, i.e. mix and match operation of WTP=20 > and ACs of all variants within this category. > > I suspect for the latter we may have to arrive at some consensus on=20 > what particular implementations we are targeting interoperability for. > If so, ultimately this problem statement could become part of the=20 > charter. > > -Shehzad > > > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf > Of Dorothy.Gellert@nokia.com > Sent: Wednesday, August 04, 2004 11:53 AM > To: isingh@chantrynetworks.com; capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > Subject: RE: [Capwap] So many architectures, so little time... - take=20 > 2 > > I believe this is the consensus, to scope the charter to Centralized=20 > Architecture and LocalMAC and Split MAC. > > I'll update the charter with this change after the CAPWAP WG Mtg. If=20 > there is resistance to this idea, please post to the list. > > Regards > Dorothy > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > > Behalf Of ext Inderpreet Singh > > Sent: Tuesday, August 03, 2004 9:40 PM > > To: capwap@frascone.com > > Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David=20 > > (Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > > Subject: RE: [Capwap] So many architectures, so little time... -=20 > > take 2 > > > > > > The issue(s) at hand and my opinions are: > > > > 1. Do we explicitly state in the re-charter which architecture the=20 > > WG should consider? I think yes. I propose Centralized architecture > > only. Autonomous and Distributed should be out of scope based on the > > same reasons as per prior postings. > > > > 2. Within Centralized do we focus on all three sub architectures or=20 > > a subset? Remote MAC should be excluded because if I am not=20 > > mistaken, the connectivity constraint between the WTP and the AC is=20 > > "direct connect". > > That being the case and that no IP layer is involved, it doesn't seem > > clear what kind of protocol would help with interoperability. > > I am concerned about the impact, dependencies and interaction with > > the recently constituted IEEE Study group on AP functionality on the > > Split MAC architectures. Furthermore, there are some pretty drastic > > differences on how the vendors have chosen to split the mac. Those > > differences will need to be worked out before designing a protocol. > > So, if the low hanging fruit strategy (as James suggested) for > > protocol development and progress is the way to go, then I think > > prioritizing on a protocol for Local MAC is a no brainer. So as far > > as focus, I feel we should do Local and Split and in that order. > > > > 3. This is not a re-chartering issue but is a response to Pat's=20 > > suggestion that a protocol that just sends the 802.11 MAC frames=20 > > from the AP to the AC would work. I think possibly, yes. But again > > the complications of splitting the MAC in an interoperable way will=20 > > be an issue. Also, you may note in the draft to which you refer, we > > included a capabilities exchange phase. I had thought of including=20 > > in the capability exchange such things as "AP supports Local MAC"=20 > > and "AP supports Split MAC", but didn't put it in because the=20 > > Taxonomy work was still in progress. Now that it is pretty much=20 > > done we could surely include that. But again...let's recharter=20 > > first. > > > > Thanks. Do people agree with 1 & 2? > > > > --- > > Inderpreet Singh > > Chantry Networks > > isingh@chantrynetworks.com > > Cell: 416-831-3705 > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]=20 > > On Behalf Of Pat R. Calhoun > > Sent: Tuesday, August 03, 2004 6:04 PM > > To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com;=20 > > capwap@frascone.com > > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > > Subject: [Capwap] So many architectures, so little time... - take 2 > > > > After reading Lily's response to Jim, I realize that I fell down the > > same trap. Local MAC is also a centralized approach, and so my=20 > > previous response was not complete. I believe the real question, in=20 > > my mind, is whether we need to address either the Local or the Split > > MAC architecture. > > > > Just looking at the Architecture Consideration tables (7 and > > 10) in the > > specification, the > > main difference (at a high level) between both approaches is where=20 > > the 802.11 management terminates. For Local MAC, it's in the WTP,=20 > > while for SPlit MAC, it's in the AC. > > > > However, looking at table 8, most Local MAC approaches share STA=20 > > state between both the WTP and the AC. So clearly there is some=20 > > signalling protocol between both the WTP and the AC. > > > > Looking at one example of a Local MAC protocol (see=20 > > http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > > there is a protocol message > > that corresponds for every 802.11 MAC management event. So when a=20 > > STA associates, the AP breaks the message apart and creates an new=20 > > protocol PDU, which contains components found in the association=20 > > request. I suspect that most Local MAC approaches do something very=20 > > similar. > > > > So if a protocol simply tunnels the 802.11 MAC management frames=20 > > from the WTP to the AC, it allows supports both approaches. For=20 > > Local MAC, they get what they want via the 802.11 frame, and this > > also works fine for Split MAC, which needs access to the MAC > > management frame. What would be required in such a protocol is a way > > for the AP to communicate whether it will be providing very specific > > functions - basically a capabilities negotiation approach. > > > > So I do believe that there is a way to address both architectures=20 > > using a single protocol. > > > > Thoughts? > > > > PatC > > > > _______________________________________________ > > 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 ------_=_NextPart_001_01C47BBC.4D39B2B2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Capwap] So many architectures, so little time... - take = 2

I guess it's no surprise that I disagree. Yes, there = are functions in split MAC that
typically occur in the AC, while they normally occur in the WTP in local = MAC. However,
what you will find is that in Local MAC, the functions really occurs in = both places, but
the notification that is sent from the WTP to the AC is not an 802.11 = packet, but a
packet that was derived from an 802.11 packet (for instance, the AP = breaks apart the
association request and sends a notification). Frankly, in the end it's = nearly the
same thing.

I really don't think that the architecture is that different.

Furthermore, there is a HUGE disadvantage with a local MAC approach = (looking at the CTP
protocol for instance, since its the only one that is available). When = the IEEE comes up
with some extensions to 802.11 (e.g. 802.11e), there will be a need to = get together and
create an extension to the local MAC protocol to pass this information = to the AC... so
hierarchical systems will always lag in feature set until the IETF is = ready with the
protocol extension - and those could take 12 months.

The split MAC approach ensures that both the WTP and the AC receive the = 802.11 packets
and can therefore instantly support any new IEEE 802.11 extensions.

PatC
-----Original Message-----
From: capwap-admin@frascone.com on behalf of Abhijit Choudhury
Sent: Thu 8/5/2004 11:32 AM
To: James Kempf; Shehzad Merchant; capwap@frascone.com
Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; = Dorothy.Gellert@nokia.com; Inderpreet Singh
Subject: RE: [Capwap] So many architectures, so little time... - take = 2

It may be possible to achieve such interoperability
within the split-MAC family or within the local-MAC
family.  It would sbe very hard to achieve
that between local and split MAC families.

For example, if vendor X's WTP terminates 802.11 ctrl/mgmt
packets and vendor Y's AC expects the 802.11 mgmt packets
to come to it, there's no way you can be interoperable.

Or are we planning to specify ONE architecture ?
The last thing IETF should do is mandate an implementation.

I think a modest and reasonable goal is to come up
with a protocol that allows sufficient flexbility so
that vendors with splitMAC architectures can transfer
most of the information they care about between the WTP and AC.

Just my $0.02 ...


Abhijit Choudhury


-----Original Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On
Behalf Of James Kempf
Sent: Wednesday, August 04, 2004 3:29 PM
To: Shehzad Merchant; capwap@frascone.com
Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com;
Dorothy.Gellert@nokia.com; Inderpreet Singh
Subject: Re: [Capwap] So many architectures, so little time... - take = 2


As a potential customer, let me put it concretely. I want to be able = to
buy my access points from Vendor X and my switch from Vendor Y and = plug
the two together and have them work without any configuration. Also, = I'd
like to be able to buy switches from Vendor Y and Vendor Z and be = able
to plug them into my network at various places and have them
interoperate.

            = jak


----- Original Message -----
From: "Shehzad Merchant" = <smerchant@extremenetworks.com>
To: <capwap@frascone.com>
Cc: <bwijnen@lucent.com>; <mmani@avaya.com>; = <david.kessens@nokia.com>;
<Dorothy.Gellert@nokia.com>; "Inderpreet Singh"
<isingh@chantrynetworks.com>
Sent: Wednesday, August 04, 2004 3:19 PM
Subject: RE: [Capwap] So many architectures, so little time... - take = 2


> I think the implementation variations even with the split MAC = may
> cover a broad spectrum. As such its important to clearly = articulate
> what aspects
of
> interoperability we are targetting. Is it truly just
> control/management or is it interoperability between disparate
> implementations of the split MAC, i.e. mix and match operation of = WTP
> and ACs of all variants within this category.
>
> I suspect for the latter we may have to arrive at some consensus = on
> what particular implementations we are targeting interoperability = for.

> If so, ultimately this problem statement could become part of = the
> charter.
>
> -Shehzad
>
>
>
> -----Original Message-----
> From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On
Behalf
> Of Dorothy.Gellert@nokia.com
> Sent: Wednesday, August 04, 2004 11:53 AM
> To: isingh@chantrynetworks.com; capwap@frascone.com
> Cc: bwijnen@lucent.com; mmani@avaya.com; = david.kessens@nokia.com
> Subject: RE: [Capwap] So many architectures, so little time... - = take
> 2
>
> I believe this is the consensus, to scope the charter to = Centralized
> Architecture and LocalMAC and Split MAC.
>
> I'll update the charter with this change after the CAPWAP WG Mtg. = If
> there is resistance to this idea, please post to the list.
>
> Regards
> Dorothy
>
>
> > -----Original Message-----
> > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m]On
> > Behalf Of ext Inderpreet Singh
> > Sent: Tuesday, August 03, 2004 9:40 PM
> > To: capwap@frascone.com
> > Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David
> > (Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView)
> > Subject: RE: [Capwap] So many architectures, so little time... = -
> > take 2
> >
> >
> > The issue(s) at hand and my opinions are:
> >
> > 1. Do we explicitly state in the re-charter which architecture = the
> > WG should consider? I think yes.  I propose Centralized = architecture

> > only. Autonomous and Distributed should be out of scope based = on the

> > same reasons as per prior postings.
> >
> > 2. Within Centralized do we focus on all three sub = architectures or
> > a subset? Remote MAC should be excluded because if I am = not
> > mistaken, the connectivity constraint between the WTP and the = AC is
> > "direct connect".
> > That being the case and that no IP layer is involved, it = doesn't
seem
> > clear what kind of protocol would help with = interoperability.
> > I am concerned about the impact, dependencies and interaction = with
> > the recently constituted IEEE Study group on AP functionality = on the
> > Split MAC architectures.  Furthermore, there are some = pretty drastic
> > differences on how the vendors have chosen to split the = mac.  Those
> > differences will need to be worked out before designing a = protocol.
> > So, if the low hanging fruit strategy (as James suggested) = for
> > protocol development and progress is the way to go, then I = think
> > prioritizing on a protocol for Local MAC is a no = brainer.  So as far
> > as focus, I feel we should do Local and Split and in that = order.
> >
> > 3. This is not a re-chartering issue but is a response to = Pat's
> > suggestion that a protocol that just sends the 802.11 MAC = frames
> > from the AP to the AC would work.  I think possibly, = yes.  But again

> > the complications of splitting the MAC in an interoperable way = will
> > be an issue.  Also, you may note in the draft to which = you refer, we

> > included a capabilities exchange phase.  I had thought of = including
> > in the capability exchange such things as "AP supports = Local MAC"
> > and "AP supports Split MAC", but didn't put it in = because the
> > Taxonomy work was still in progress.  Now that it is = pretty much
> > done we could surely include that.  But again...let's = recharter
> > first.
> >
> > Thanks.  Do people agree with 1 & 2?
> >
> > ---
> > Inderpreet Singh
> > Chantry Networks
> > isingh@chantrynetworks.com
> > Cell: 416-831-3705
> >
> > -----Original Message-----
> > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m]
> > On Behalf Of Pat R. Calhoun
> > Sent: Tuesday, August 03, 2004 6:04 PM
> > To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com;
> > capwap@frascone.com
> > Cc: bwijnen@lucent.com; mmani@avaya.com; = david.kessens@nokia.com
> > Subject: [Capwap] So many architectures, so little time... - = take 2
> >
> > After reading Lily's response to Jim, I realize that I fell = down the

> > same trap. Local MAC is also a centralized approach, and so = my
> > previous response was not complete. I believe the real = question, in
> > my mind, is whether we need to address either the Local or the = Split

> > MAC architecture.
> >
> > Just looking at the Architecture Consideration tables (7 = and
> > 10) in the
> > specification, the
> > main difference (at a high level) between both approaches is = where
> > the 802.11 management terminates. For Local MAC, it's in the = WTP,
> > while for SPlit MAC, it's in the AC.
> >
> > However, looking at table 8, most Local MAC approaches share = STA
> > state between both the WTP and the AC. So clearly there is = some
> > signalling protocol between both the WTP and the AC.
> >
> > Looking at one example of a Local MAC protocol (see
> > http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt),=
> > there is a protocol message
> > that corresponds for every 802.11 MAC management event. So = when a
> > STA associates, the AP breaks the message apart and creates an = new
> > protocol PDU, which contains components found in the = association
> > request. I suspect that most Local MAC approaches do something = very
> > similar.
> >
> > So if a protocol simply tunnels the 802.11 MAC management = frames
> > from the WTP to the AC, it allows supports both approaches. = For
> > Local MAC, they get what they want via the 802.11 frame, and = this
> > also works fine for Split MAC, which needs access to the = MAC
> > management frame. What would be required in such a protocol is = a way
> > for the AP to communicate whether it will be providing very = specific
> > functions - basically a capabilities negotiation approach.
> >
> > So I do believe that there is a way to address both = architectures
> > using a single protocol.
> >
> > Thoughts?
> >
> > PatC
> >
> > _______________________________________________
> > Capwap mailing list
> > Capwap@frascone.com http://mail.fra= scone.com/mailman/listinfo/capwap
> >
> _______________________________________________
> Capwap mailing list
> Capwap@frascone.com http://mail.fra= scone.com/mailman/listinfo/capwap
> _______________________________________________
> Capwap mailing list
> Capwap@frascone.com
> http://mail.fra= scone.com/mailman/listinfo/capwap


_______________________________________________
Capwap mailing list
Capwap@frascone.com http://mail.fra= scone.com/mailman/listinfo/capwap
_______________________________________________
Capwap mailing list
Capwap@frascone.com
http://mail.fra= scone.com/mailman/listinfo/capwap

------_=_NextPart_001_01C47BBC.4D39B2B2-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Aug 6 11:58:36 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06121 for ; Fri, 6 Aug 2004 11:58:35 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1626E20B6F; Fri, 6 Aug 2004 11:43:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A936B20A99; Fri, 6 Aug 2004 11:43:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2D6C62070A for ; Fri, 6 Aug 2004 11:42:27 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id E54C52038B for ; Fri, 6 Aug 2004 11:42:24 -0400 (EDT) Message-ID: <0e5201c47bce$20d00680$536115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Mani, Mahalingam (Mahalingam)" , "Victor Lin" , "Bob O'Hara" , References: Subject: Re: [Capwap] So many architectures, so little time... - take 2 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, 6 Aug 2004 08:57:49 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I think interoperability is only necessary between architectures which address roughly the same deployment niche. For example, I think split and local MAC address roughly the same deployment niche. For Inderjeet's benefit: there are probably some scenerios where one or the other does a better job, so there is not complete overlap, but there is enough overlap that having interoperable hardware will provide a significant benefit to customers. As I customer, I see local/split as largely an attempt at market segmentation, and while such tactics typically provide some short term benefit to the promoting vendors, in the long term, they typically tend to inhibit overall market growth and thus also inhibit the promoting vendors' bottom line. Autonomous poses a question, however, since one could argue that it currently addresses all deployment niches. I suppose I see the autonomous architecture becoming primarily a SOHO/home solution in the future, that is, it's niche contracts to a specific deployment scenario where it is best suited, as the benefits of centralized architectues for larger deployments become realized. Therefore, I feel there's less of a need for interoperability, though perhaps there are some issues (as was pointed by someone out in a previous email) which could be addressed. I don't see any need for having interoperability with remote and distributed, since I think the deployment scenerios are likely to be quite different than for local/split MAC and also I believe it would technically quite challenging to come up with a protocol that would integrate distributed, remote, and local/split MAC, essentially a research task. I'm basically trying to approach this from the standpoint of what my company might buy for an enterprise deployment that we as a sevice provider would support (unlike the US, there are some companies in Japan who contract some parts of their wireless IT support to service providers), and also for possible public access hotspot service (we already have a public access hotspot service, called MZone, in Japan). It's difficult to predict, but I think the current situation - with various noninteroperable but excellent centralized architecture products and lots of roughly interoperable autonomous architecture products - is not very promising for providing large scale, high quality WiFi service at a reasonable capital and system management cost. jak ----- Original Message ----- From: "Mani, Mahalingam (Mahalingam)" To: "Victor Lin" ; "Bob O'Hara" ; Sent: Thursday, August 05, 2004 2:25 PM Subject: RE: [Capwap] So many architectures, so little time... - take 2 I am all ears to sense WG consensus on 'interoperability' between different architectures. Also keen to understand why it is not the right thing to do. Besides, one may also want to qualify what constitutes 'interoperability' between different architectures beyond discovery of WTP<->AC mutual compatibility. That's a matter of detail. In principle I have so far heard the feasibility of a single protocol that can help speak cross-arch. It is the capability of end-entity implementations (AC, WTP) that will eventually drive its benefit. In actuality - I also see this as providing output which is useful input for AP functions interfaces. Further - I would also urge us to think about this in the perspective of the scope of interoperability - broadly on the control, provisioning/ configuration, monitoring/alerting aspects. If the data-plane (fast-path) can be cleanly separated out of consideration (as a side-effect that does not bring dependencies on the core aspects of control, provisioning/configuration) - it goes a long way in clarifying the protocol problem space and leaves much of the architectural complexity that *seemingly* clouds the control-plane realization. Regards, -mani -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Victor Lin Sent: Thursday, August 05, 2004 11:46 AM To: Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] So many architectures, so little time... - take 2 I agree that we can design a protocol and implement the product that works all architectures. I think the question to CAPWAP is: Should we make it a requirement in CAPWAP protocol to achieve interoperability between different architectures? It is definitely doable, but I'm not sure if that is the right thing to do.. Victor -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Bob O'Hara Sent: Thursday, August 05, 2004 11:43 AM To: capwap@frascone.com Subject: RE: [Capwap] So many architectures, so little time... - take 2 I think that interoperability will depend on two things. First, it will depend on how we define the protocol and the flexibility for supported architectures it incorporates. Second, it will depend on what manufacturers implement, i.e., the flexibility they build into their products. I believe that it is possible to design the protocol for the required flexibility. I know it is possible to implement a product with the required flexibility. -Bob O'Hara -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Abhijit Choudhury Sent: Thursday, August 05, 2004 11:32 AM To: James Kempf; Shehzad Merchant; capwap@frascone.com Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; Dorothy.Gellert@nokia.com; Inderpreet Singh Subject: RE: [Capwap] So many architectures, so little time... - take 2 It may be possible to achieve such interoperability within the split-MAC family or within the local-MAC family. It would sbe very hard to achieve that between local and split MAC families. For example, if vendor X's WTP terminates 802.11 ctrl/mgmt packets and vendor Y's AC expects the 802.11 mgmt packets to come to it, there's no way you can be interoperable. Or are we planning to specify ONE architecture ? The last thing IETF should do is mandate an implementation. I think a modest and reasonable goal is to come up with a protocol that allows sufficient flexbility so that vendors with splitMAC architectures can transfer most of the information they care about between the WTP and AC. Just my $0.02 ... Abhijit Choudhury -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf Sent: Wednesday, August 04, 2004 3:29 PM To: Shehzad Merchant; capwap@frascone.com Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; Dorothy.Gellert@nokia.com; Inderpreet Singh Subject: Re: [Capwap] So many architectures, so little time... - take 2 As a potential customer, let me put it concretely. I want to be able to buy my access points from Vendor X and my switch from Vendor Y and plug the two together and have them work without any configuration. Also, I'd like to be able to buy switches from Vendor Y and Vendor Z and be able to plug them into my network at various places and have them interoperate. jak ----- Original Message ----- From: "Shehzad Merchant" To: Cc: ; ; ; ; "Inderpreet Singh" Sent: Wednesday, August 04, 2004 3:19 PM Subject: RE: [Capwap] So many architectures, so little time... - take 2 > I think the implementation variations even with the split MAC may > cover a broad spectrum. As such its important to clearly articulate > what aspects of > interoperability we are targetting. Is it truly just > control/management or is it interoperability between disparate > implementations of the split MAC, i.e. mix and match operation of WTP > and ACs of all variants within this category. > > I suspect for the latter we may have to arrive at some consensus on > what particular implementations we are targeting interoperability for. > If so, ultimately this problem statement could become part of the > charter. > > -Shehzad > > > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf > Of Dorothy.Gellert@nokia.com > Sent: Wednesday, August 04, 2004 11:53 AM > To: isingh@chantrynetworks.com; capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > Subject: RE: [Capwap] So many architectures, so little time... - take > 2 > > I believe this is the consensus, to scope the charter to Centralized > Architecture and LocalMAC and Split MAC. > > I'll update the charter with this change after the CAPWAP WG Mtg. If > there is resistance to this idea, please post to the list. > > Regards > Dorothy > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > > Behalf Of ext Inderpreet Singh > > Sent: Tuesday, August 03, 2004 9:40 PM > > To: capwap@frascone.com > > Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David > > (Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > > Subject: RE: [Capwap] So many architectures, so little time... - > > take 2 > > > > > > The issue(s) at hand and my opinions are: > > > > 1. Do we explicitly state in the re-charter which architecture the > > WG should consider? I think yes. I propose Centralized architecture > > only. Autonomous and Distributed should be out of scope based on the > > same reasons as per prior postings. > > > > 2. Within Centralized do we focus on all three sub architectures or > > a subset? Remote MAC should be excluded because if I am not > > mistaken, the connectivity constraint between the WTP and the AC is > > "direct connect". > > That being the case and that no IP layer is involved, it doesn't seem > > clear what kind of protocol would help with interoperability. > > I am concerned about the impact, dependencies and interaction with > > the recently constituted IEEE Study group on AP functionality on the > > Split MAC architectures. Furthermore, there are some pretty drastic > > differences on how the vendors have chosen to split the mac. Those > > differences will need to be worked out before designing a protocol. > > So, if the low hanging fruit strategy (as James suggested) for > > protocol development and progress is the way to go, then I think > > prioritizing on a protocol for Local MAC is a no brainer. So as far > > as focus, I feel we should do Local and Split and in that order. > > > > 3. This is not a re-chartering issue but is a response to Pat's > > suggestion that a protocol that just sends the 802.11 MAC frames > > from the AP to the AC would work. I think possibly, yes. But again > > the complications of splitting the MAC in an interoperable way will > > be an issue. Also, you may note in the draft to which you refer, we > > included a capabilities exchange phase. I had thought of including > > in the capability exchange such things as "AP supports Local MAC" > > and "AP supports Split MAC", but didn't put it in because the > > Taxonomy work was still in progress. Now that it is pretty much > > done we could surely include that. But again...let's recharter > > first. > > > > Thanks. Do people agree with 1 & 2? > > > > --- > > Inderpreet Singh > > Chantry Networks > > isingh@chantrynetworks.com > > Cell: 416-831-3705 > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] > > On Behalf Of Pat R. Calhoun > > Sent: Tuesday, August 03, 2004 6:04 PM > > To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com; > > capwap@frascone.com > > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > > Subject: [Capwap] So many architectures, so little time... - take 2 > > > > After reading Lily's response to Jim, I realize that I fell down the > > same trap. Local MAC is also a centralized approach, and so my > > previous response was not complete. I believe the real question, in > > my mind, is whether we need to address either the Local or the Split > > MAC architecture. > > > > Just looking at the Architecture Consideration tables (7 and > > 10) in the > > specification, the > > main difference (at a high level) between both approaches is where > > the 802.11 management terminates. For Local MAC, it's in the WTP, > > while for SPlit MAC, it's in the AC. > > > > However, looking at table 8, most Local MAC approaches share STA > > state between both the WTP and the AC. So clearly there is some > > signalling protocol between both the WTP and the AC. > > > > Looking at one example of a Local MAC protocol (see > > http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > > there is a protocol message > > that corresponds for every 802.11 MAC management event. So when a > > STA associates, the AP breaks the message apart and creates an new > > protocol PDU, which contains components found in the association > > request. I suspect that most Local MAC approaches do something very > > similar. > > > > So if a protocol simply tunnels the 802.11 MAC management frames > > from the WTP to the AC, it allows supports both approaches. For > > Local MAC, they get what they want via the 802.11 frame, and this > > also works fine for Split MAC, which needs access to the MAC > > management frame. What would be required in such a protocol is a way > > for the AP to communicate whether it will be providing very specific > > functions - basically a capabilities negotiation approach. > > > > So I do believe that there is a way to address both architectures > > using a single protocol. > > > > Thoughts? > > > > PatC > > > > _______________________________________________ > > 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 _______________________________________________ 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 Fri Aug 6 13:45:49 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13394 for ; Fri, 6 Aug 2004 13:45:49 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0460320F17; Fri, 6 Aug 2004 13:31:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A50FA214B8; Fri, 6 Aug 2004 13:31:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D10C7212FA for ; Fri, 6 Aug 2004 13:30:43 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id ACA6520F17 for ; Fri, 6 Aug 2004 13:30:41 -0400 (EDT) Message-ID: <0eec01c47bdd$40fe6820$536115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Sadot, Emek (Emek)" , "Shehzad Merchant" , Cc: , "Mani, Mahalingam (Mahalingam)" , , , "Inderpreet Singh" References: Subject: Re: [Capwap] So many architectures, so little time... - take 2 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, 6 Aug 2004 10:46:05 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit So it seems there's two levels of interoperability: 1) Can I put two switches from different manufacturers into one LAN and not have them interfere? 2) Can I put two switches from different manufactuers into one LAN and have them interoperate? In either case, I would expect the set of WTPs controlled by the two switches to be disjoint. I believe 1) is absolutely essential, but I agree that 2) might be hard to achieve. jak ----- Original Message ----- From: "Sadot, Emek (Emek)" To: "James Kempf" ; "Shehzad Merchant" ; Cc: ; "Mani, Mahalingam (Mahalingam)" ; ; ; "Inderpreet Singh" Sent: Friday, August 06, 2004 5:10 AM Subject: RE: [Capwap] So many architectures, so little time... - take 2 I think that we should be very careful in adopting switch to switch interoperability and protocol definition as part of the CAPWAP charter. It certainly make sense for customer to purchase APs from different vendors, though I don't 100% sure for different vendors' ACs. Even if it make sense, recharging the CAPWAP to encompass switch to switch interoperability will jeopardize the chance of the CAPWAP to converge. Time wise. Emek -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On Behalf Of James Kempf Sent: Thursday, 05 August, 2004 1:29 AM To: Shehzad Merchant; capwap@frascone.com Cc: bwijnen@lucent.com; Mani, Mahalingam (Mahalingam); david.kessens@nokia.com; Dorothy.Gellert@nokia.com; Inderpreet Singh Subject: Re: [Capwap] So many architectures, so little time... - take 2 As a potential customer, let me put it concretely. I want to be able to buy my access points from Vendor X and my switch from Vendor Y and plug the two together and have them work without any configuration. Also, I'd like to be able to buy switches from Vendor Y and Vendor Z and be able to plug them into my network at various places and have them interoperate. jak ----- Original Message ----- From: "Shehzad Merchant" To: Cc: ; ; ; ; "Inderpreet Singh" Sent: Wednesday, August 04, 2004 3:19 PM Subject: RE: [Capwap] So many architectures, so little time... - take 2 > I think the implementation variations even with the split MAC may cover a > broad spectrum. As such its important to clearly articulate what aspects of > interoperability we are targetting. Is it truly just control/management or > is it interoperability between disparate implementations of the split MAC, > i.e. mix and match operation of WTP and ACs of all variants within this > category. > > I suspect for the latter we may have to arrive at some consensus on what > particular implementations we are targeting interoperability for. If so, > ultimately this problem statement could become part of the charter. > > -Shehzad > > > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf > Of Dorothy.Gellert@nokia.com > Sent: Wednesday, August 04, 2004 11:53 AM > To: isingh@chantrynetworks.com; capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > Subject: RE: [Capwap] So many architectures, so little time... - take 2 > > I believe this is the consensus, to scope the charter to Centralized > Architecture and LocalMAC and Split MAC. > > I'll update the charter with this change after the CAPWAP WG Mtg. > If there is resistance to this idea, please post to the list. > > Regards > Dorothy > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > > Behalf Of ext Inderpreet Singh > > Sent: Tuesday, August 03, 2004 9:40 PM > > To: capwap@frascone.com > > Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David > > (Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > > Subject: RE: [Capwap] So many architectures, so little time... - take > > 2 > > > > > > The issue(s) at hand and my opinions are: > > > > 1. Do we explicitly state in the re-charter which architecture the WG > > should consider? > > I think yes. I propose Centralized architecture only. > > Autonomous and Distributed should be out of scope based on the same > > reasons as per prior postings. > > > > 2. Within Centralized do we focus on all three sub architectures or a > > subset? > > Remote MAC should be excluded because if I am not mistaken, the > > connectivity constraint between the WTP and the AC is "direct > > connect". > > That being the case and that no IP layer is involved, it doesn't seem > > clear what kind of protocol would help with interoperability. > > I am concerned about the impact, dependencies and interaction with > > the recently constituted IEEE Study group on AP functionality on the > > Split MAC architectures. Furthermore, there are some pretty drastic > > differences on how the vendors have chosen to split the mac. Those > > differences will need to be worked out before designing a protocol. > > So, if the low hanging fruit strategy (as James suggested) for > > protocol development and progress is the way to go, then I think > > prioritizing on a protocol for Local MAC is a no brainer. So as far > > as focus, I feel we should do Local and Split and in that order. > > > > 3. This is not a re-chartering issue but is a response to Pat's > > suggestion that a protocol that just sends the 802.11 MAC frames from > > the AP to the AC would work. I think possibly, yes. But again the > > complications of splitting the MAC in an interoperable way will be an > > issue. Also, you may note in the draft to which you refer, we > > included a capabilities exchange phase. I had thought of including in > > the capability exchange such things as "AP supports Local MAC" and "AP > > supports Split MAC", but didn't put it in because the Taxonomy work > > was still in progress. Now that it is pretty much done we could > > surely include that. But again...let's recharter first. > > > > Thanks. Do people agree with 1 & 2? > > > > --- > > Inderpreet Singh > > Chantry Networks > > isingh@chantrynetworks.com > > Cell: 416-831-3705 > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > > Behalf Of Pat R. Calhoun > > Sent: Tuesday, August 03, 2004 6:04 PM > > To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com; > > capwap@frascone.com > > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > > Subject: [Capwap] So many architectures, so little time... - take 2 > > > > After reading Lily's response to Jim, I realize that I fell down the > > same trap. Local MAC is also a centralized approach, and so my > > previous response was not complete. I believe the real question, in my > > mind, is whether we need to address either the Local or the Split MAC > > architecture. > > > > Just looking at the Architecture Consideration tables (7 and > > 10) in the > > specification, the > > main difference (at a high level) between both approaches is where the > > 802.11 management > > terminates. For Local MAC, it's in the WTP, while for SPlit MAC, it's > > in the AC. > > > > However, looking at table 8, most Local MAC approaches share STA state > > between both the WTP and the AC. So clearly there is some signalling > > protocol between both the WTP and the AC. > > > > Looking at one example of a Local MAC protocol (see > > http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > > there is a protocol message > > that corresponds for every 802.11 MAC management event. So when a STA > > associates, the AP breaks the message apart and creates an new > > protocol PDU, which contains components found in the association > > request. I suspect that most Local MAC approaches do something very > > similar. > > > > So if a protocol simply tunnels the 802.11 MAC management frames from > > the WTP to the AC, it allows supports both approaches. For Local MAC, > > they get what they want via the > > 802.11 frame, and this > > also works fine for Split MAC, which needs access to the MAC > > management frame. What would be required in such a protocol is a way > > for the AP to communicate whether it will be providing very specific > > functions - basically a capabilities negotiation approach. > > > > So I do believe that there is a way to address both architectures > > using a single protocol. > > > > Thoughts? > > > > PatC > > > > _______________________________________________ > > 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 Sun Aug 8 20:27:05 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22750 for ; Sun, 8 Aug 2004 20:27:04 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 99CB320400; Sun, 8 Aug 2004 20:12:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7EE0120A0C; Sun, 8 Aug 2004 20:12:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 485F320B1F for ; Sun, 8 Aug 2004 20:11:22 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 87DBC20A0C for ; Sun, 8 Aug 2004 20:11: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 i790JKSG027203 for ; Sun, 8 Aug 2004 19:19:20 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i790JHSG027175 for ; Sun, 8 Aug 2004 19:19:18 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C47DA7.700F9391" Message-ID: Thread-Topic: Hi Thread-Index: AcR9p3AGwRboKE6sR4OweEa0lLvxyAAAAALL From: "Romascanu, Dan (Dan)" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Out of Office AutoReply: Hi 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, 9 Aug 2004 03:25:56 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C47DA7.700F9391 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable I will be traveling for business purposes between August 1 and 12, and = then will be on vacation until August 30. My e-mail connectivity will be = scarce during this period, especially after August 14. I will however = check voice mail daily, and can be reached for urgent matters at the = mobile phone number +1-917-622-7831. Regards, Dan ------_=_NextPart_001_01C47DA7.700F9391 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Out of Office AutoReply: <Possible SPAM> Hi

I will be traveling for business purposes between = August 1 and 12, and then will be on vacation until August 30. My e-mail = connectivity will be scarce during this period, especially after August = 14. I will however check voice mail daily, and can be reached for urgent = matters at the mobile phone number +1-917-622-7831.

Regards,

Dan

------_=_NextPart_001_01C47DA7.700F9391-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Aug 9 02:14:56 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05602 for ; Mon, 9 Aug 2004 02:14:55 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B7F332098C; Mon, 9 Aug 2004 02:00:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 52E37209B5; Mon, 9 Aug 2004 02:00:07 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1CCF62098C for ; Mon, 9 Aug 2004 01:59:49 -0400 (EDT) Received: from orsfmr001.jf.intel.com (fmr12.intel.com [134.134.136.15]) by mail.frascone.com (Postfix) with ESMTP id D5DD31FE99 for ; Mon, 9 Aug 2004 01:59:41 -0400 (EDT) Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i78NEbNS010601; Sun, 8 Aug 2004 23:15:14 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i79685eM031570; Mon, 9 Aug 2004 06:08:28 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004080823133014662 ; Sun, 08 Aug 2004 23:13:30 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 8 Aug 2004 23:13: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] So many architectures, so little time... - take 2 Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE01BE73BC@orsmsx408> Thread-Topic: [Capwap] So many architectures, so little time... - take 2 Thread-Index: AcR7IKOn52JidGBLRn+59StkpW+3xAADnJMQ From: "Yang, Lily L" To: "Burbank, Jack L." , "Victor Lin " , "Bob O'Hara " , X-OriginalArrivalTime: 09 Aug 2004 06:13:30.0675 (UTC) FILETIME=[FE0A6030:01C47DD7] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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: Sun, 8 Aug 2004 23:13:30 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I think setting the re-charter scope to develop a single protocol that allows interoperability between Local and Split MAC is a reasonable tradeoff: We exclude remote MAC because the constraint it imposes is very different from the rest and the benefit of including it is very little. But Local and Split MAC are reasonably close and hence the effort may be incremental only.=20 As many people noted, as of today, there is no single clear definition of what "Local MAC" and "Split MAC" really means yet. Each vendor has different definitions and some debate needs to happen so that the WG can reach consensus on what exactly that means, and what kinds of flexibility we want to retain within each class of architecture, and what kind of differences we can to resolve and agree up front. That should also be part of the work items for the new WG -- such agreement on the details for each architecture must be documented somewhere, if not separately, then as part of the Protocol document. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Burbank, Jack L. Sent: Thursday, August 05, 2004 12:14 PM To: 'Victor Lin '; 'Bob O'Hara '; 'capwap@frascone.com ' Subject: RE: [Capwap] So many architectures, so little time... - take 2 I think that interoperability between different architectures should be a requirement, if not the key requirement. As was mentioned yesterday, a goal of the IEEE is that they maintain flexibility in terms of how products and architectures are implemented. I think we shouldn't do anything that is contrary to that goal (or at least we should minimize the impact). I think that the goal of CAPWAP should be to retain this type of flexibility by designing a protocol that can maintain this implementation flexibility but enable interoperability between the various architecture implementations (that after all is the key problem with the deployment of these various architectures - lack of interoperability). IMO, if we don't design for interoperability between the basic architecture types, it is debatable if something useful would have been accomplished. Jack Burbank -----Original Message----- From: capwap-admin@frascone.com To: Bob O'Hara; capwap@frascone.com Sent: 8/5/2004 2:46 PM Subject: RE: [Capwap] So many architectures, so little time... - take 2 I agree that we can design a protocol and implement the product that works all architectures. I think the question to CAPWAP is: Should we make it a requirement in CAPWAP protocol to achieve interoperability between different architectures?=20 It is definitely doable, but I'm not sure if that is the right thing to do.. Victor -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Bob O'Hara Sent: Thursday, August 05, 2004 11:43 AM To: capwap@frascone.com Subject: RE: [Capwap] So many architectures, so little time... - take 2 I think that interoperability will depend on two things. First, it will depend on how we define the protocol and the flexibility for supported architectures it incorporates. Second, it will depend on what manufacturers implement, i.e., the flexibility they build into their products. =20 I believe that it is possible to design the protocol for the required flexibility. I know it is possible to implement a product with the required flexibility. -Bob O'Hara =20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Abhijit Choudhury Sent: Thursday, August 05, 2004 11:32 AM To: James Kempf; Shehzad Merchant; capwap@frascone.com Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; Dorothy.Gellert@nokia.com; Inderpreet Singh Subject: RE: [Capwap] So many architectures, so little time... - take 2 It may be possible to achieve such interoperability within the split-MAC family or within the local-MAC family. It would sbe very hard to achieve=20 that between local and split MAC families. For example, if vendor X's WTP terminates 802.11 ctrl/mgmt packets and vendor Y's AC expects the 802.11 mgmt packets to come to it, there's no way you can be interoperable. Or are we planning to specify ONE architecture ? The last thing IETF should do is mandate an implementation. I think a modest and reasonable goal is to come up=20 with a protocol that allows sufficient flexbility so that vendors with splitMAC architectures can transfer most of the information they care about between the WTP and AC. Just my $0.02 ... Abhijit Choudhury -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf Sent: Wednesday, August 04, 2004 3:29 PM To: Shehzad Merchant; capwap@frascone.com Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; Dorothy.Gellert@nokia.com; Inderpreet Singh Subject: Re: [Capwap] So many architectures, so little time... - take 2 As a potential customer, let me put it concretely. I want to be able to buy my access points from Vendor X and my switch from Vendor Y and plug the two together and have them work without any configuration. Also, I'd like to be able to buy switches from Vendor Y and Vendor Z and be able to plug them into my network at various places and have them interoperate. jak ----- Original Message -----=20 From: "Shehzad Merchant" To: Cc: ; ; ; ; "Inderpreet Singh" Sent: Wednesday, August 04, 2004 3:19 PM Subject: RE: [Capwap] So many architectures, so little time... - take 2 > I think the implementation variations even with the split MAC may=20 > cover a broad spectrum. As such its important to clearly articulate=20 > what aspects of > interoperability we are targetting. Is it truly just=20 > control/management or is it interoperability between disparate=20 > implementations of the split MAC, i.e. mix and match operation of WTP=20 > and ACs of all variants within this category. > > I suspect for the latter we may have to arrive at some consensus on=20 > what particular implementations we are targeting interoperability for. > If so, ultimately this problem statement could become part of the=20 > charter. > > -Shehzad > > > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf > Of Dorothy.Gellert@nokia.com > Sent: Wednesday, August 04, 2004 11:53 AM > To: isingh@chantrynetworks.com; capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > Subject: RE: [Capwap] So many architectures, so little time... - take=20 > 2 > > I believe this is the consensus, to scope the charter to Centralized=20 > Architecture and LocalMAC and Split MAC. > > I'll update the charter with this change after the CAPWAP WG Mtg. If=20 > there is resistance to this idea, please post to the list. > > Regards > Dorothy > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > > Behalf Of ext Inderpreet Singh > > Sent: Tuesday, August 03, 2004 9:40 PM > > To: capwap@frascone.com > > Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David=20 > > (Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > > Subject: RE: [Capwap] So many architectures, so little time... -=20 > > take 2 > > > > > > The issue(s) at hand and my opinions are: > > > > 1. Do we explicitly state in the re-charter which architecture the=20 > > WG should consider? I think yes. I propose Centralized architecture > > only. Autonomous and Distributed should be out of scope based on the > > same reasons as per prior postings. > > > > 2. Within Centralized do we focus on all three sub architectures or=20 > > a subset? Remote MAC should be excluded because if I am not=20 > > mistaken, the connectivity constraint between the WTP and the AC is=20 > > "direct connect". > > That being the case and that no IP layer is involved, it doesn't seem > > clear what kind of protocol would help with interoperability. > > I am concerned about the impact, dependencies and interaction with > > the recently constituted IEEE Study group on AP functionality on the > > Split MAC architectures. Furthermore, there are some pretty drastic > > differences on how the vendors have chosen to split the mac. Those > > differences will need to be worked out before designing a protocol. > > So, if the low hanging fruit strategy (as James suggested) for > > protocol development and progress is the way to go, then I think > > prioritizing on a protocol for Local MAC is a no brainer. So as far > > as focus, I feel we should do Local and Split and in that order. > > > > 3. This is not a re-chartering issue but is a response to Pat's=20 > > suggestion that a protocol that just sends the 802.11 MAC frames=20 > > from the AP to the AC would work. I think possibly, yes. But again > > the complications of splitting the MAC in an interoperable way will=20 > > be an issue. Also, you may note in the draft to which you refer, we > > included a capabilities exchange phase. I had thought of including=20 > > in the capability exchange such things as "AP supports Local MAC"=20 > > and "AP supports Split MAC", but didn't put it in because the=20 > > Taxonomy work was still in progress. Now that it is pretty much=20 > > done we could surely include that. But again...let's recharter=20 > > first. > > > > Thanks. Do people agree with 1 & 2? > > > > --- > > Inderpreet Singh > > Chantry Networks > > isingh@chantrynetworks.com > > Cell: 416-831-3705 > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]=20 > > On Behalf Of Pat R. Calhoun > > Sent: Tuesday, August 03, 2004 6:04 PM > > To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com;=20 > > capwap@frascone.com > > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > > Subject: [Capwap] So many architectures, so little time... - take 2 > > > > After reading Lily's response to Jim, I realize that I fell down the > > same trap. Local MAC is also a centralized approach, and so my=20 > > previous response was not complete. I believe the real question, in=20 > > my mind, is whether we need to address either the Local or the Split > > MAC architecture. > > > > Just looking at the Architecture Consideration tables (7 and > > 10) in the > > specification, the > > main difference (at a high level) between both approaches is where=20 > > the 802.11 management terminates. For Local MAC, it's in the WTP,=20 > > while for SPlit MAC, it's in the AC. > > > > However, looking at table 8, most Local MAC approaches share STA=20 > > state between both the WTP and the AC. So clearly there is some=20 > > signalling protocol between both the WTP and the AC. > > > > Looking at one example of a Local MAC protocol (see=20 > > http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > > there is a protocol message > > that corresponds for every 802.11 MAC management event. So when a=20 > > STA associates, the AP breaks the message apart and creates an new=20 > > protocol PDU, which contains components found in the association=20 > > request. I suspect that most Local MAC approaches do something very=20 > > similar. > > > > So if a protocol simply tunnels the 802.11 MAC management frames=20 > > from the WTP to the AC, it allows supports both approaches. For=20 > > Local MAC, they get what they want via the 802.11 frame, and this > > also works fine for Split MAC, which needs access to the MAC > > management frame. What would be required in such a protocol is a way > > for the AP to communicate whether it will be providing very specific > > functions - basically a capabilities negotiation approach. > > > > So I do believe that there is a way to address both architectures=20 > > using a single protocol. > > > > Thoughts? > > > > PatC > > > > _______________________________________________ > > 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 _______________________________________________ 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 Aug 9 09:14:57 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27652 for ; Mon, 9 Aug 2004 09:14:55 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CB4E320782; Mon, 9 Aug 2004 09:00:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3ADC3208CF; Mon, 9 Aug 2004 09:00:07 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0A6AE208CF for ; Mon, 9 Aug 2004 08:59:08 -0400 (EDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [192.11.222.161]) by mail.frascone.com (Postfix) with ESMTP id 47D7320782 for ; Mon, 9 Aug 2004 08:59:06 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i79DDl3r001997 for ; Mon, 9 Aug 2004 08:13:48 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 9 Aug 2004 15:13:46 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503C79B09@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Yang, Lily L'" , "Burbank, Jack L." , Victor Lin , "Bob O'Hara" , capwap@frascone.com Subject: RE: [Capwap] So many architectures, so little time... - take 2 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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: Mon, 9 Aug 2004 15:13:39 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Not sure who is confused... probably me... My understanding was/is that IF we do re-charter for CAPWAP protocol work, that it is then a NM protocol for "Control and Provisioning" and not any of the related stuff that moves the data from WTP to AC. Is everybody in agreement with that understanding. Thanks, Bert > -----Original Message----- > From: Yang, Lily L [mailto:lily.l.yang@intel.com] > Sent: maandag 9 augustus 2004 08:14 > To: Burbank, Jack L.; Victor Lin ; Bob O'Hara ; capwap@frascone.com > Subject: RE: [Capwap] So many architectures, so little > time... - take 2 > > > I think setting the re-charter scope to develop a single protocol that > allows interoperability between Local and Split MAC is a reasonable > tradeoff: > We exclude remote MAC because the constraint it imposes is very > different from the rest and the benefit of including it is > very little. > But Local and Split MAC are reasonably close and hence the > effort may be > incremental only. > As many people noted, as of today, there is no single clear definition > of what "Local MAC" and "Split MAC" really means yet. Each vendor has > different definitions and some debate needs to happen so that > the WG can > reach consensus on what exactly that means, and what kinds of > flexibility we want to retain within each class of architecture, and > what kind of differences we can to resolve and agree up front. That > should also be part of the work items for the new WG -- such agreement > on the details for each architecture must be documented somewhere, if > not separately, then as part of the Protocol document. > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Burbank, Jack L. > Sent: Thursday, August 05, 2004 12:14 PM > To: 'Victor Lin '; 'Bob O'Hara '; 'capwap@frascone.com ' > Subject: RE: [Capwap] So many architectures, so little > time... - take 2 > > I think that interoperability between different architectures > should be > a > requirement, if not the key requirement. As was mentioned > yesterday, a > goal > of the IEEE is that they maintain flexibility in terms of how products > and > architectures are implemented. I think we shouldn't do > anything that is > contrary to that goal (or at least we should minimize the impact). I > think > that the goal of CAPWAP should be to retain this type of > flexibility by > designing a protocol that can maintain this implementation flexibility > but > enable interoperability between the various architecture > implementations > (that after all is the key problem with the deployment of > these various > architectures - lack of interoperability). IMO, if we don't > design for > interoperability between the basic architecture types, it is debatable > if > something useful would have been accomplished. > > Jack Burbank > > -----Original Message----- > From: capwap-admin@frascone.com > To: Bob O'Hara; capwap@frascone.com > Sent: 8/5/2004 2:46 PM > Subject: RE: [Capwap] So many architectures, so little > time... - take 2 > > I agree that we can design a protocol and implement the product that > works > all architectures. I think the question to CAPWAP is: > > Should we make it a requirement in CAPWAP protocol to achieve > interoperability between different architectures? > > It is definitely doable, but I'm not sure if that is the > right thing to > do.. > > Victor > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf > Of Bob O'Hara > Sent: Thursday, August 05, 2004 11:43 AM > To: capwap@frascone.com > Subject: RE: [Capwap] So many architectures, so little > time... - take 2 > > I think that interoperability will depend on two things. > First, it will > depend on how we define the protocol and the flexibility for supported > architectures it incorporates. Second, it will depend on what > manufacturers implement, i.e., the flexibility they build into their > products. > > I believe that it is possible to design the protocol for the required > flexibility. I know it is possible to implement a product with the > required flexibility. > > -Bob O'Hara > > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Abhijit Choudhury > Sent: Thursday, August 05, 2004 11:32 AM > To: James Kempf; Shehzad Merchant; capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; > Dorothy.Gellert@nokia.com; Inderpreet Singh > Subject: RE: [Capwap] So many architectures, so little > time... - take 2 > > > It may be possible to achieve such interoperability > within the split-MAC family or within the local-MAC > family. It would sbe very hard to achieve > that between local and split MAC families. > > For example, if vendor X's WTP terminates 802.11 ctrl/mgmt > packets and vendor Y's AC expects the 802.11 mgmt packets > to come to it, there's no way you can be interoperable. > > Or are we planning to specify ONE architecture ? > The last thing IETF should do is mandate an implementation. > > I think a modest and reasonable goal is to come up > with a protocol that allows sufficient flexbility so > that vendors with splitMAC architectures can transfer > most of the information they care about between the WTP and AC. > > Just my $0.02 ... > > > Abhijit Choudhury > > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of James Kempf > Sent: Wednesday, August 04, 2004 3:29 PM > To: Shehzad Merchant; capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; > Dorothy.Gellert@nokia.com; Inderpreet Singh > Subject: Re: [Capwap] So many architectures, so little > time... - take 2 > > > As a potential customer, let me put it concretely. I want to > be able to > buy my access points from Vendor X and my switch from Vendor > Y and plug > the two together and have them work without any > configuration. Also, I'd > like to be able to buy switches from Vendor Y and Vendor Z and be able > to plug them into my network at various places and have them > interoperate. > > jak > > > ----- Original Message ----- > From: "Shehzad Merchant" > To: > Cc: ; ; > ; > ; "Inderpreet Singh" > > Sent: Wednesday, August 04, 2004 3:19 PM > Subject: RE: [Capwap] So many architectures, so little > time... - take 2 > > > > I think the implementation variations even with the split MAC may > > cover a broad spectrum. As such its important to clearly articulate > > what aspects > of > > interoperability we are targetting. Is it truly just > > control/management or is it interoperability between disparate > > implementations of the split MAC, i.e. mix and match > operation of WTP > > and ACs of all variants within this category. > > > > I suspect for the latter we may have to arrive at some consensus on > > what particular implementations we are targeting > interoperability for. > > > If so, ultimately this problem statement could become part of the > > charter. > > > > -Shehzad > > > > > > > > -----Original Message----- > > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On > Behalf > > Of Dorothy.Gellert@nokia.com > > Sent: Wednesday, August 04, 2004 11:53 AM > > To: isingh@chantrynetworks.com; capwap@frascone.com > > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > > Subject: RE: [Capwap] So many architectures, so little > time... - take > > 2 > > > > I believe this is the consensus, to scope the charter to > Centralized > > Architecture and LocalMAC and Split MAC. > > > > I'll update the charter with this change after the CAPWAP > WG Mtg. If > > there is resistance to this idea, please post to the list. > > > > Regards > > Dorothy > > > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com]On > > > Behalf Of ext Inderpreet Singh > > > Sent: Tuesday, August 03, 2004 9:40 PM > > > To: capwap@frascone.com > > > Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David > > > (Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > > > Subject: RE: [Capwap] So many architectures, so little time... - > > > take 2 > > > > > > > > > The issue(s) at hand and my opinions are: > > > > > > 1. Do we explicitly state in the re-charter which > architecture the > > > WG should consider? I think yes. I propose Centralized > architecture > > > > only. Autonomous and Distributed should be out of scope > based on the > > > > same reasons as per prior postings. > > > > > > 2. Within Centralized do we focus on all three sub > architectures or > > > a subset? Remote MAC should be excluded because if I am not > > > mistaken, the connectivity constraint between the WTP and > the AC is > > > "direct connect". > > > That being the case and that no IP layer is involved, it doesn't > seem > > > clear what kind of protocol would help with interoperability. > > > I am concerned about the impact, dependencies and interaction with > > > the recently constituted IEEE Study group on AP > functionality on the > > > Split MAC architectures. Furthermore, there are some > pretty drastic > > > differences on how the vendors have chosen to split the > mac. Those > > > differences will need to be worked out before designing a > protocol. > > > So, if the low hanging fruit strategy (as James suggested) for > > > protocol development and progress is the way to go, then I think > > > prioritizing on a protocol for Local MAC is a no brainer. > So as far > > > as focus, I feel we should do Local and Split and in that order. > > > > > > 3. This is not a re-chartering issue but is a response to Pat's > > > suggestion that a protocol that just sends the 802.11 MAC frames > > > from the AP to the AC would work. I think possibly, yes. > But again > > > > the complications of splitting the MAC in an > interoperable way will > > > be an issue. Also, you may note in the draft to which > you refer, we > > > > included a capabilities exchange phase. I had thought of > including > > > in the capability exchange such things as "AP supports Local MAC" > > > and "AP supports Split MAC", but didn't put it in because the > > > Taxonomy work was still in progress. Now that it is pretty much > > > done we could surely include that. But again...let's recharter > > > first. > > > > > > Thanks. Do people agree with 1 & 2? > > > > > > --- > > > Inderpreet Singh > > > Chantry Networks > > > isingh@chantrynetworks.com > > > Cell: 416-831-3705 > > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] > > > On Behalf Of Pat R. Calhoun > > > Sent: Tuesday, August 03, 2004 6:04 PM > > > To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com; > > > capwap@frascone.com > > > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > > > Subject: [Capwap] So many architectures, so little > time... - take 2 > > > > > > After reading Lily's response to Jim, I realize that I > fell down the > > > > same trap. Local MAC is also a centralized approach, and so my > > > previous response was not complete. I believe the real > question, in > > > my mind, is whether we need to address either the Local > or the Split > > > > MAC architecture. > > > > > > Just looking at the Architecture Consideration tables (7 and > > > 10) in the > > > specification, the > > > main difference (at a high level) between both approaches > is where > > > the 802.11 management terminates. For Local MAC, it's in the WTP, > > > while for SPlit MAC, it's in the AC. > > > > > > However, looking at table 8, most Local MAC approaches share STA > > > state between both the WTP and the AC. So clearly there is some > > > signalling protocol between both the WTP and the AC. > > > > > > Looking at one example of a Local MAC protocol (see > > > http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > > there is a protocol message > > that corresponds for every 802.11 MAC management event. So when a > > STA associates, the AP breaks the message apart and creates an new > > protocol PDU, which contains components found in the association > > request. I suspect that most Local MAC approaches do something very > > similar. > > > > So if a protocol simply tunnels the 802.11 MAC management frames > > from the WTP to the AC, it allows supports both approaches. For > > Local MAC, they get what they want via the 802.11 frame, and this > > also works fine for Split MAC, which needs access to the MAC > > management frame. What would be required in such a protocol is a way > > for the AP to communicate whether it will be providing very specific > > functions - basically a capabilities negotiation approach. > > > > So I do believe that there is a way to address both architectures > > using a single protocol. > > > > Thoughts? > > > > PatC > > > > _______________________________________________ > > 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 _______________________________________________ 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 Mon Aug 9 23:38:53 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26290 for ; Mon, 9 Aug 2004 23:38:52 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4C5FA1FE2A; Mon, 9 Aug 2004 23:24:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 05AB0209E3; Mon, 9 Aug 2004 23:24:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C0038208B2 for ; Mon, 9 Aug 2004 23:23:04 -0400 (EDT) Received: from gemini.lunarpages.com (gemini.lunarpages.com [64.235.234.128]) by mail.frascone.com (Postfix) with ESMTP id 45A261FE2A for ; Mon, 9 Aug 2004 23:23:03 -0400 (EDT) Received: from h-68-167-136-151.snvacaid.covad.net ([68.167.136.151] helo=shankar.org) by gemini.lunarpages.com with asmtp (Exim 4.34) id 1BuNTA-0002tF-Ur; Mon, 09 Aug 2004 20:38:37 -0700 Message-ID: <411842FB.7090205@shankar.org> From: Shankar Narayanaswamy User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" Cc: "'Yang, Lily L'" , "Burbank, Jack L." , Victor Lin , "Bob O'Hara" , capwap@frascone.com Subject: Re: [Capwap] So many architectures, so little time... - take 2 References: <7D5D48D2CAA3D84C813F5B154F43B15503C79B09@nl0006exch001u.nl.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gemini.lunarpages.com X-AntiAbuse: Original Domain - frascone.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shankar.org 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, 09 Aug 2004 20:37:31 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit The question is: control and provisioning of what? WTP alone? WTP with some MAC functionality? WTP with full MAC functionality? Which leads to how data is moved from the WTP to the AC. For example, is it encrypted or in the clear? Lily's proposal is a reasonable one, for which the next steps would be clearer definition of the meaning of "Local MAC" and "Split MAC", and greater clarity on the objectives/parameters of the architecture and supporting protocol (e.g. what does the security solution protect us from, latency goals to support VoIP, deployment scenarios, etc). -s Wijnen, Bert (Bert) wrote: > Not sure who is confused... probably me... > > My understanding was/is that IF we do re-charter for CAPWAP > protocol work, that it is then a NM protocol for > "Control and Provisioning" and not any of the related stuff > that moves the data from WTP to AC. > > Is everybody in agreement with that understanding. > > Thanks, > Bert -- Shankar Narayanaswamy, Ph.D. wireless@shankar.org Mobile: +1 650-387-4593 http://www.shankar.org E-Fax: +1 253-498-8372 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Aug 10 03:52:55 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29708 for ; Tue, 10 Aug 2004 03:52:54 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2BD3920B8F; Tue, 10 Aug 2004 03:38:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8482020C05; Tue, 10 Aug 2004 03:38:05 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B53E120C05 for ; Tue, 10 Aug 2004 03:37:23 -0400 (EDT) Received: from sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by mail.frascone.com (Postfix) with ESMTP id 9396A20B8F for ; Tue, 10 Aug 2004 03:37:21 -0400 (EDT) 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.6944.0 Subject: RE: [Capwap] So many architectures, so little time... - take 2 Message-ID: Thread-Topic: [Capwap] So many architectures, so little time... - take 2 Thread-Index: AcR+E23Uq/uiNMPOQGur07rM9sCFzgAmm+QQ From: "Abhijit Choudhury" To: "Wijnen, Bert (Bert)" , "Yang, Lily L" , "Burbank, Jack L." , "Victor Lin" , "Bob O'Hara" , 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, 10 Aug 2004 00:55:56 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable The same tunneling protocol that moves control and management packets from the WTP to the AC should be used to tunnel data packets as well. We would specify message exchanges to do control, provisioning and capability advertisement between WTPs and the AC. But all of this would be within the unified CAPWAP protocol that moves all packets including data between the WTP and AC. Vendors currently use LWAPP, GRE, IP and some proprietary encapsulations to achieve this. This group would come up with a "standard" way of doing this exchange. At least that was my understanding.... Regards, Abhijit=20 -----Original Mssage----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Wijnen, Bert (Bert) Sent: Monday, August 09, 2004 6:14 AM To: 'Yang, Lily L'; Burbank, Jack L.; Victor Lin; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] So many architectures, so little time... - take 2 Not sure who is confused... probably me... My understanding was/is that IF we do re-charter for CAPWAP protocol work, that it is then a NM protocol for=20 "Control and Provisioning" and not any of the related stuff=20 that moves the data from WTP to AC. Is everybody in agreement with that understanding. Thanks, Bert=20 > -----Original Message----- > From: Yang, Lily L [mailto:lily.l.yang@intel.com] > Sent: maandag 9 augustus 2004 08:14 > To: Burbank, Jack L.; Victor Lin ; Bob O'Hara ; capwap@frascone.com > Subject: RE: [Capwap] So many architectures, so little > time... - take 2 >=20 >=20 > I think setting the re-charter scope to develop a single protocol that > allows interoperability between Local and Split MAC is a reasonable > tradeoff: > We exclude remote MAC because the constraint it imposes is very=20 > different from the rest and the benefit of including it is very=20 > little. But Local and Split MAC are reasonably close and hence the > effort may be > incremental only.=20 > As many people noted, as of today, there is no single clear definition > of what "Local MAC" and "Split MAC" really means yet. Each vendor has > different definitions and some debate needs to happen so that=20 > the WG can > reach consensus on what exactly that means, and what kinds of > flexibility we want to retain within each class of architecture, and > what kind of differences we can to resolve and agree up front. That > should also be part of the work items for the new WG -- such agreement > on the details for each architecture must be documented somewhere, if > not separately, then as part of the Protocol document. >=20 > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On=20 > Behalf Of Burbank, Jack L. > Sent: Thursday, August 05, 2004 12:14 PM > To: 'Victor Lin '; 'Bob O'Hara '; 'capwap@frascone.com ' > Subject: RE: [Capwap] So many architectures, so little > time... - take 2 >=20 > I think that interoperability between different architectures > should be > a > requirement, if not the key requirement. As was mentioned=20 > yesterday, a > goal > of the IEEE is that they maintain flexibility in terms of how products > and > architectures are implemented. I think we shouldn't do=20 > anything that is > contrary to that goal (or at least we should minimize the impact). I > think > that the goal of CAPWAP should be to retain this type of=20 > flexibility by > designing a protocol that can maintain this implementation flexibility > but > enable interoperability between the various architecture=20 > implementations > (that after all is the key problem with the deployment of=20 > these various > architectures - lack of interoperability). IMO, if we don't=20 > design for > interoperability between the basic architecture types, it is debatable > if > something useful would have been accomplished. >=20 > Jack Burbank >=20 > -----Original Message----- > From: capwap-admin@frascone.com > To: Bob O'Hara; capwap@frascone.com > Sent: 8/5/2004 2:46 PM > Subject: RE: [Capwap] So many architectures, so little > time... - take 2 >=20 > I agree that we can design a protocol and implement the product that=20 > works all architectures. I think the question to CAPWAP is: >=20 > Should we make it a requirement in CAPWAP protocol to achieve=20 > interoperability between different architectures? >=20 > It is definitely doable, but I'm not sure if that is the > right thing to > do.. >=20 > Victor >=20 > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On=20 > Behalf Of Bob O'Hara > Sent: Thursday, August 05, 2004 11:43 AM > To: capwap@frascone.com > Subject: RE: [Capwap] So many architectures, so little=20 > time... - take 2 >=20 > I think that interoperability will depend on two things. > First, it will > depend on how we define the protocol and the flexibility for supported > architectures it incorporates. Second, it will depend on what > manufacturers implement, i.e., the flexibility they build into their > products. =20 >=20 > I believe that it is possible to design the protocol for the required=20 > flexibility. I know it is possible to implement a product with the=20 > required flexibility. >=20 > -Bob O'Hara > =20 >=20 > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On=20 > Behalf Of Abhijit Choudhury > Sent: Thursday, August 05, 2004 11:32 AM > To: James Kempf; Shehzad Merchant; capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com;=20 > Dorothy.Gellert@nokia.com; Inderpreet Singh > Subject: RE: [Capwap] So many architectures, so little > time... - take 2 >=20 >=20 > It may be possible to achieve such interoperability > within the split-MAC family or within the local-MAC > family. It would sbe very hard to achieve > that between local and split MAC families. >=20 > For example, if vendor X's WTP terminates 802.11 ctrl/mgmt packets and > vendor Y's AC expects the 802.11 mgmt packets to come to it, there's=20 > no way you can be interoperable. >=20 > Or are we planning to specify ONE architecture ? > The last thing IETF should do is mandate an implementation. >=20 > I think a modest and reasonable goal is to come up > with a protocol that allows sufficient flexbility so > that vendors with splitMAC architectures can transfer > most of the information they care about between the WTP and AC. >=20 > Just my $0.02 ... >=20 >=20 > Abhijit Choudhury >=20 >=20 > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On=20 > Behalf Of James Kempf > Sent: Wednesday, August 04, 2004 3:29 PM > To: Shehzad Merchant; capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com;=20 > Dorothy.Gellert@nokia.com; Inderpreet Singh > Subject: Re: [Capwap] So many architectures, so little > time... - take 2 >=20 >=20 > As a potential customer, let me put it concretely. I want to > be able to > buy my access points from Vendor X and my switch from Vendor=20 > Y and plug > the two together and have them work without any=20 > configuration. Also, I'd > like to be able to buy switches from Vendor Y and Vendor Z and be able > to plug them into my network at various places and have them > interoperate. >=20 > jak >=20 >=20 > ----- Original Message ----- > From: "Shehzad Merchant" > To: > Cc: ; ;=20 > ; > ; "Inderpreet Singh" > > Sent: Wednesday, August 04, 2004 3:19 PM > Subject: RE: [Capwap] So many architectures, so little=20 > time... - take 2 >=20 >=20 > > I think the implementation variations even with the split MAC may > > cover a broad spectrum. As such its important to clearly articulate=20 > > what aspects > of > > interoperability we are targetting. Is it truly just > > control/management or is it interoperability between disparate=20 > > implementations of the split MAC, i.e. mix and match=20 > operation of WTP > > and ACs of all variants within this category. > > > > I suspect for the latter we may have to arrive at some consensus on > > what particular implementations we are targeting=20 > interoperability for. >=20 > > If so, ultimately this problem statement could become part of the > > charter. > > > > -Shehzad > > > > > > > > -----Original Message----- > > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On > Behalf > > Of Dorothy.Gellert@nokia.com > > Sent: Wednesday, August 04, 2004 11:53 AM > > To: isingh@chantrynetworks.com; capwap@frascone.com > > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > > Subject: RE: [Capwap] So many architectures, so little > time... - take > > 2 > > > > I believe this is the consensus, to scope the charter to > Centralized > > Architecture and LocalMAC and Split MAC. > > > > I'll update the charter with this change after the CAPWAP > WG Mtg. If > > there is resistance to this idea, please post to the list. > > > > Regards > > Dorothy > > > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com]On > > > Behalf Of ext Inderpreet Singh > > > Sent: Tuesday, August 03, 2004 9:40 PM > > > To: capwap@frascone.com > > > Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David > > > (Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > > > Subject: RE: [Capwap] So many architectures, so little time... -=20 > > > take 2 > > > > > > > > > The issue(s) at hand and my opinions are: > > > > > > 1. Do we explicitly state in the re-charter which > architecture the > > > WG should consider? I think yes. I propose Centralized > architecture >=20 > > > only. Autonomous and Distributed should be out of scope > based on the >=20 > > > same reasons as per prior postings. > > > > > > 2. Within Centralized do we focus on all three sub > architectures or > > > a subset? Remote MAC should be excluded because if I am not > > > mistaken, the connectivity constraint between the WTP and=20 > the AC is > > > "direct connect". > > > That being the case and that no IP layer is involved, it doesn't > seem > > > clear what kind of protocol would help with interoperability. I am > > > concerned about the impact, dependencies and interaction with the=20 > > > recently constituted IEEE Study group on AP > functionality on the > > > Split MAC architectures. Furthermore, there are some > pretty drastic > > > differences on how the vendors have chosen to split the > mac. Those > > > differences will need to be worked out before designing a > protocol. > > > So, if the low hanging fruit strategy (as James suggested) for=20 > > > protocol development and progress is the way to go, then I think=20 > > > prioritizing on a protocol for Local MAC is a no brainer. > So as far > > > as focus, I feel we should do Local and Split and in that order. > > > > > > 3. This is not a re-chartering issue but is a response to Pat's > > > suggestion that a protocol that just sends the 802.11 MAC frames=20 > > > from the AP to the AC would work. I think possibly, yes.=20 > But again >=20 > > > the complications of splitting the MAC in an > interoperable way will > > > be an issue. Also, you may note in the draft to which > you refer, we >=20 > > > included a capabilities exchange phase. I had thought of > including > > > in the capability exchange such things as "AP supports Local MAC" > > > and "AP supports Split MAC", but didn't put it in because the=20 > > > Taxonomy work was still in progress. Now that it is pretty much=20 > > > done we could surely include that. But again...let's recharter=20 > > > first. > > > > > > Thanks. Do people agree with 1 & 2? > > > > > > --- > > > Inderpreet Singh > > > Chantry Networks > > > isingh@chantrynetworks.com > > > Cell: 416-831-3705 > > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] > > > On Behalf Of Pat R. Calhoun > > > Sent: Tuesday, August 03, 2004 6:04 PM > > > To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com; > > > capwap@frascone.com > > > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > > > Subject: [Capwap] So many architectures, so little=20 > time... - take 2 > > > > > > After reading Lily's response to Jim, I realize that I > fell down the >=20 > > > same trap. Local MAC is also a centralized approach, and so my > > > previous response was not complete. I believe the real=20 > question, in > > > my mind, is whether we need to address either the Local > or the Split >=20 > > > MAC architecture. > > > > > > Just looking at the Architecture Consideration tables (7 and > > > 10) in the > > > specification, the > > > main difference (at a high level) between both approaches > is where > > > the 802.11 management terminates. For Local MAC, it's in the WTP, > > > while for SPlit MAC, it's in the AC. > > > > > > However, looking at table 8, most Local MAC approaches share STA > > > state between both the WTP and the AC. So clearly there is some=20 > > > signalling protocol between both the WTP and the AC. > > > > > > Looking at one example of a Local MAC protocol (see > > >=20 http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > > there is a protocol message > > that corresponds for every 802.11 MAC management event. So when a > > STA associates, the AP breaks the message apart and creates an new=20 > > protocol PDU, which contains components found in the association=20 > > request. I suspect that most Local MAC approaches do something very=20 > > similar. > > > > So if a protocol simply tunnels the 802.11 MAC management frames > > from the WTP to the AC, it allows supports both approaches. For=20 > > Local MAC, they get what they want via the 802.11 frame, and this > > also works fine for Split MAC, which needs access to the MAC > > management frame. What would be required in such a protocol is a way > > for the AP to communicate whether it will be providing very specific > > functions - basically a capabilities negotiation approach. > > > > So I do believe that there is a way to address both architectures > > using a single protocol. > > > > Thoughts? > > > > PatC > > > > _______________________________________________ > > 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 _______________________________________________ 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 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Aug 10 11:21:14 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03839 for ; Tue, 10 Aug 2004 11:21:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CE9C1206C6; Tue, 10 Aug 2004 11:04:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5EE2520F1A; Tue, 10 Aug 2004 11:04:05 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 92B5C2137E for ; Tue, 10 Aug 2004 11:04:00 -0400 (EDT) Received: from aruba-server.arubanetworks.com (mail.arubanetworks.com [64.60.249.195]) by mail.frascone.com (Postfix) with SMTP id B733020F1A for ; Tue, 10 Aug 2004 11:03:57 -0400 (EDT) Received: from [10.3.9.211] ([10.3.9.211] unverified) by aruba-server.arubanetworks.com over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Tue, 10 Aug 2004 08:18:38 -0700 Subject: RE: [Capwap] So many architectures, so little time... - take 2 From: Partha Narasimhan To: "Wijnen, Bert (Bert)" Cc: "'Yang, Lily L'" , "Burbank, Jack L." , Victor Lin , "Bob O'Hara" , capwap@frascone.com In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15503C79B09@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B15503C79B09@nl0006exch001u.nl.lucent.com> Content-Type: text/plain Organization: Aruba Wireless Networks, Inc. Message-Id: <1092151112.16594.7808.camel@sap1.arubanetworks.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Aug 2004 15:18:38.0860 (UTC) FILETIME=[500D14C0:01C47EED] 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, 10 Aug 2004 08:18:34 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Since many of the AP functions are split between the WTP and the AC in most of the split-MAC or local-MAC submissions, this requires that a mechanism for transporting data frames (and some mgmt frames in the split MAC architecture) between the WTP and the AC be defined for a multi-vendor solution that works. So the transfer of data frames between the WTP and the AC is not a problem that we can ignore. Ideally, we should come up with a mechanism that works for both architectures (since there are differences) and for both data and mgmt frames. Thanks partha On Mon, 2004-08-09 at 06:13, Wijnen, Bert (Bert) wrote: > Not sure who is confused... probably me... > > My understanding was/is that IF we do re-charter for CAPWAP > protocol work, that it is then a NM protocol for > "Control and Provisioning" and not any of the related stuff > that moves the data from WTP to AC. > > Is everybody in agreement with that understanding. > > Thanks, > Bert > > > -----Original Message----- > > From: Yang, Lily L [mailto:lily.l.yang@intel.com] > > Sent: maandag 9 augustus 2004 08:14 > > To: Burbank, Jack L.; Victor Lin ; Bob O'Hara ; capwap@frascone.com > > Subject: RE: [Capwap] So many architectures, so little > > time... - take 2 > > > > > > I think setting the re-charter scope to develop a single protocol that > > allows interoperability between Local and Split MAC is a reasonable > > tradeoff: > > We exclude remote MAC because the constraint it imposes is very > > different from the rest and the benefit of including it is > > very little. > > But Local and Split MAC are reasonably close and hence the > > effort may be > > incremental only. > > As many people noted, as of today, there is no single clear definition > > of what "Local MAC" and "Split MAC" really means yet. Each vendor has > > different definitions and some debate needs to happen so that > > the WG can > > reach consensus on what exactly that means, and what kinds of > > flexibility we want to retain within each class of architecture, and > > what kind of differences we can to resolve and agree up front. That > > should also be part of the work items for the new WG -- such agreement > > on the details for each architecture must be documented somewhere, if > > not separately, then as part of the Protocol document. > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > > Behalf Of Burbank, Jack L. > > Sent: Thursday, August 05, 2004 12:14 PM > > To: 'Victor Lin '; 'Bob O'Hara '; 'capwap@frascone.com ' > > Subject: RE: [Capwap] So many architectures, so little > > time... - take 2 > > > > I think that interoperability between different architectures > > should be > > a > > requirement, if not the key requirement. As was mentioned > > yesterday, a > > goal > > of the IEEE is that they maintain flexibility in terms of how products > > and > > architectures are implemented. I think we shouldn't do > > anything that is > > contrary to that goal (or at least we should minimize the impact). I > > think > > that the goal of CAPWAP should be to retain this type of > > flexibility by > > designing a protocol that can maintain this implementation flexibility > > but > > enable interoperability between the various architecture > > implementations > > (that after all is the key problem with the deployment of > > these various > > architectures - lack of interoperability). IMO, if we don't > > design for > > interoperability between the basic architecture types, it is debatable > > if > > something useful would have been accomplished. > > > > Jack Burbank > > > > -----Original Message----- > > From: capwap-admin@frascone.com > > To: Bob O'Hara; capwap@frascone.com > > Sent: 8/5/2004 2:46 PM > > Subject: RE: [Capwap] So many architectures, so little > > time... - take 2 > > > > I agree that we can design a protocol and implement the product that > > works > > all architectures. I think the question to CAPWAP is: > > > > Should we make it a requirement in CAPWAP protocol to achieve > > interoperability between different architectures? > > > > It is definitely doable, but I'm not sure if that is the > > right thing to > > do.. > > > > Victor > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > > Behalf > > Of Bob O'Hara > > Sent: Thursday, August 05, 2004 11:43 AM > > To: capwap@frascone.com > > Subject: RE: [Capwap] So many architectures, so little > > time... - take 2 > > > > I think that interoperability will depend on two things. > > First, it will > > depend on how we define the protocol and the flexibility for supported > > architectures it incorporates. Second, it will depend on what > > manufacturers implement, i.e., the flexibility they build into their > > products. > > > > I believe that it is possible to design the protocol for the required > > flexibility. I know it is possible to implement a product with the > > required flexibility. > > > > -Bob O'Hara > > > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > > Behalf Of Abhijit Choudhury > > Sent: Thursday, August 05, 2004 11:32 AM > > To: James Kempf; Shehzad Merchant; capwap@frascone.com > > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; > > Dorothy.Gellert@nokia.com; Inderpreet Singh > > Subject: RE: [Capwap] So many architectures, so little > > time... - take 2 > > > > > > It may be possible to achieve such interoperability > > within the split-MAC family or within the local-MAC > > family. It would sbe very hard to achieve > > that between local and split MAC families. > > > > For example, if vendor X's WTP terminates 802.11 ctrl/mgmt > > packets and vendor Y's AC expects the 802.11 mgmt packets > > to come to it, there's no way you can be interoperable. > > > > Or are we planning to specify ONE architecture ? > > The last thing IETF should do is mandate an implementation. > > > > I think a modest and reasonable goal is to come up > > with a protocol that allows sufficient flexbility so > > that vendors with splitMAC architectures can transfer > > most of the information they care about between the WTP and AC. > > > > Just my $0.02 ... > > > > > > Abhijit Choudhury > > > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > > Behalf Of James Kempf > > Sent: Wednesday, August 04, 2004 3:29 PM > > To: Shehzad Merchant; capwap@frascone.com > > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; > > Dorothy.Gellert@nokia.com; Inderpreet Singh > > Subject: Re: [Capwap] So many architectures, so little > > time... - take 2 > > > > > > As a potential customer, let me put it concretely. I want to > > be able to > > buy my access points from Vendor X and my switch from Vendor > > Y and plug > > the two together and have them work without any > > configuration. Also, I'd > > like to be able to buy switches from Vendor Y and Vendor Z and be able > > to plug them into my network at various places and have them > > interoperate. > > > > jak > > > > > > ----- Original Message ----- > > From: "Shehzad Merchant" > > To: > > Cc: ; ; > > ; > > ; "Inderpreet Singh" > > > > Sent: Wednesday, August 04, 2004 3:19 PM > > Subject: RE: [Capwap] So many architectures, so little > > time... - take 2 > > > > > > > I think the implementation variations even with the split MAC may > > > cover a broad spectrum. As such its important to clearly articulate > > > what aspects > > of > > > interoperability we are targetting. Is it truly just > > > control/management or is it interoperability between disparate > > > implementations of the split MAC, i.e. mix and match > > operation of WTP > > > and ACs of all variants within this category. > > > > > > I suspect for the latter we may have to arrive at some consensus on > > > what particular implementations we are targeting > > interoperability for. > > > > > If so, ultimately this problem statement could become part of the > > > charter. > > > > > > -Shehzad > > > > > > > > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On > > Behalf > > > Of Dorothy.Gellert@nokia.com > > > Sent: Wednesday, August 04, 2004 11:53 AM > > > To: isingh@chantrynetworks.com; capwap@frascone.com > > > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > > > Subject: RE: [Capwap] So many architectures, so little > > time... - take > > > 2 > > > > > > I believe this is the consensus, to scope the charter to > > Centralized > > > Architecture and LocalMAC and Split MAC. > > > > > > I'll update the charter with this change after the CAPWAP > > WG Mtg. If > > > there is resistance to this idea, please post to the list. > > > > > > Regards > > > Dorothy > > > > > > > > > > -----Original Message----- > > > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com]On > > > > Behalf Of ext Inderpreet Singh > > > > Sent: Tuesday, August 03, 2004 9:40 PM > > > > To: capwap@frascone.com > > > > Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David > > > > (Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > > > > Subject: RE: [Capwap] So many architectures, so little time... - > > > > take 2 > > > > > > > > > > > > The issue(s) at hand and my opinions are: > > > > > > > > 1. Do we explicitly state in the re-charter which > > architecture the > > > > WG should consider? I think yes. I propose Centralized > > architecture > > > > > > only. Autonomous and Distributed should be out of scope > > based on the > > > > > > same reasons as per prior postings. > > > > > > > > 2. Within Centralized do we focus on all three sub > > architectures or > > > > a subset? Remote MAC should be excluded because if I am not > > > > mistaken, the connectivity constraint between the WTP and > > the AC is > > > > "direct connect". > > > > That being the case and that no IP layer is involved, it doesn't > > seem > > > > clear what kind of protocol would help with interoperability. > > > > I am concerned about the impact, dependencies and interaction with > > > > the recently constituted IEEE Study group on AP > > functionality on the > > > > Split MAC architectures. Furthermore, there are some > > pretty drastic > > > > differences on how the vendors have chosen to split the > > mac. Those > > > > differences will need to be worked out before designing a > > protocol. > > > > So, if the low hanging fruit strategy (as James suggested) for > > > > protocol development and progress is the way to go, then I think > > > > prioritizing on a protocol for Local MAC is a no brainer. > > So as far > > > > as focus, I feel we should do Local and Split and in that order. > > > > > > > > 3. This is not a re-chartering issue but is a response to Pat's > > > > suggestion that a protocol that just sends the 802.11 MAC frames > > > > from the AP to the AC would work. I think possibly, yes. > > But again > > > > > > the complications of splitting the MAC in an > > interoperable way will > > > > be an issue. Also, you may note in the draft to which > > you refer, we > > > > > > included a capabilities exchange phase. I had thought of > > including > > > > in the capability exchange such things as "AP supports Local MAC" > > > > and "AP supports Split MAC", but didn't put it in because the > > > > Taxonomy work was still in progress. Now that it is pretty much > > > > done we could surely include that. But again...let's recharter > > > > first. > > > > > > > > Thanks. Do people agree with 1 & 2? > > > > > > > > --- > > > > Inderpreet Singh > > > > Chantry Networks > > > > isingh@chantrynetworks.com > > > > Cell: 416-831-3705 > > > > > > > > -----Original Message----- > > > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] > > > > On Behalf Of Pat R. Calhoun > > > > Sent: Tuesday, August 03, 2004 6:04 PM > > > > To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com; > > > > capwap@frascone.com > > > > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > > > > Subject: [Capwap] So many architectures, so little > > time... - take 2 > > > > > > > > After reading Lily's response to Jim, I realize that I > > fell down the > > > > > > same trap. Local MAC is also a centralized approach, and so my > > > > previous response was not complete. I believe the real > > question, in > > > > my mind, is whether we need to address either the Local > > or the Split > > > > > > MAC architecture. > > > > > > > > Just looking at the Architecture Consideration tables (7 and > > > > 10) in the > > > > specification, the > > > > main difference (at a high level) between both approaches > > is where > > > > the 802.11 management terminates. For Local MAC, it's in the WTP, > > > > while for SPlit MAC, it's in the AC. > > > > > > > > However, looking at table 8, most Local MAC approaches share STA > > > > state between both the WTP and the AC. So clearly there is some > > > > signalling protocol between both the WTP and the AC. > > > > > > > > Looking at one example of a Local MAC protocol (see > > > > > http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > > > there is a protocol message > > > that corresponds for every 802.11 MAC management event. So when a > > > STA associates, the AP breaks the message apart and creates an new > > > protocol PDU, which contains components found in the association > > > request. I suspect that most Local MAC approaches do something very > > > similar. > > > > > > So if a protocol simply tunnels the 802.11 MAC management frames > > > from the WTP to the AC, it allows supports both approaches. For > > > Local MAC, they get what they want via the 802.11 frame, and this > > > also works fine for Split MAC, which needs access to the MAC > > > management frame. What would be required in such a protocol is a way > > > for the AP to communicate whether it will be providing very specific > > > functions - basically a capabilities negotiation approach. > > > > > > So I do believe that there is a way to address both architectures > > > using a single protocol. > > > > > > Thoughts? > > > > > > PatC > > > > > > _______________________________________________ > > > 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 > _______________________________________________ > 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 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Aug 10 13:30:58 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15375 for ; Tue, 10 Aug 2004 13:30:56 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8974921393; Tue, 10 Aug 2004 13:16:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4117E217AC; Tue, 10 Aug 2004 13:16:06 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ACE52217AC for ; Tue, 10 Aug 2004 13:15:44 -0400 (EDT) Received: from gemini.lunarpages.com (gemini.lunarpages.com [64.235.234.128]) by mail.frascone.com (Postfix) with ESMTP id CB07121393 for ; Tue, 10 Aug 2004 13:15:42 -0400 (EDT) Received: from h-68-167-136-151.snvacaid.covad.net ([68.167.136.151] helo=shankar.org) by gemini.lunarpages.com with asmtp (Exim 4.34) id 1BuaTA-00032Q-Er; Tue, 10 Aug 2004 10:31:28 -0700 Message-ID: <41190632.3040806@shankar.org> From: Shankar Narayanaswamy User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Abhijit Choudhury Cc: capwap@frascone.com Subject: Re: [Capwap] So many architectures, so little time... - take 2 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gemini.lunarpages.com X-AntiAbuse: Original Domain - frascone.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - shankar.org 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, 10 Aug 2004 10:30:26 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit On the first point: not necessarily. If data packets are encapsulated 802.11 data frames, then there is no need to protect them on the wire any more than they were encrypted over the air. But control and management packets will need protection over the wired network and therefore possibly a different tunneling protocol. On the second point (standard way of packet exchange): yes! -s Abhijit Choudhury wrote: > The same tunneling protocol that moves control and management > packets from the WTP to the AC should be used to tunnel data > packets as well. We would specify message exchanges to do > control, provisioning and capability advertisement between WTPs > and the AC. But all of this would be within the unified CAPWAP > protocol that moves all packets including data between the WTP > and AC. Vendors currently use LWAPP, GRE, IP and > some proprietary encapsulations to achieve this. This group > would come up with a "standard" way of doing this exchange. > > At least that was my understanding.... > > Regards, > Abhijit > > -----Original Mssage----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Wijnen, Bert (Bert) > Sent: Monday, August 09, 2004 6:14 AM > To: 'Yang, Lily L'; Burbank, Jack L.; Victor Lin; Bob O'Hara; > capwap@frascone.com > Subject: RE: [Capwap] So many architectures, so little time... - take 2 > > > Not sure who is confused... probably me... > > My understanding was/is that IF we do re-charter for CAPWAP protocol > work, that it is then a NM protocol for > "Control and Provisioning" and not any of the related stuff > that moves the data from WTP to AC. > > Is everybody in agreement with that understanding. > > Thanks, > Bert > > >>-----Original Message----- >>From: Yang, Lily L [mailto:lily.l.yang@intel.com] >>Sent: maandag 9 augustus 2004 08:14 >>To: Burbank, Jack L.; Victor Lin ; Bob O'Hara ; capwap@frascone.com >>Subject: RE: [Capwap] So many architectures, so little >>time... - take 2 >> >> >>I think setting the re-charter scope to develop a single protocol that > > >>allows interoperability between Local and Split MAC is a reasonable >>tradeoff: >>We exclude remote MAC because the constraint it imposes is very >>different from the rest and the benefit of including it is very >>little. But Local and Split MAC are reasonably close and hence the >>effort may be >>incremental only. >>As many people noted, as of today, there is no single clear definition >>of what "Local MAC" and "Split MAC" really means yet. Each vendor has >>different definitions and some debate needs to happen so that >>the WG can >>reach consensus on what exactly that means, and what kinds of >>flexibility we want to retain within each class of architecture, and >>what kind of differences we can to resolve and agree up front. That >>should also be part of the work items for the new WG -- such agreement >>on the details for each architecture must be documented somewhere, if >>not separately, then as part of the Protocol document. >> >>-----Original Message----- >>From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On >>Behalf Of Burbank, Jack L. >>Sent: Thursday, August 05, 2004 12:14 PM >>To: 'Victor Lin '; 'Bob O'Hara '; 'capwap@frascone.com ' >>Subject: RE: [Capwap] So many architectures, so little >>time... - take 2 >> >>I think that interoperability between different architectures >>should be >>a >>requirement, if not the key requirement. As was mentioned >>yesterday, a >>goal >>of the IEEE is that they maintain flexibility in terms of how products >>and >>architectures are implemented. I think we shouldn't do >>anything that is >>contrary to that goal (or at least we should minimize the impact). I >>think >>that the goal of CAPWAP should be to retain this type of >>flexibility by >>designing a protocol that can maintain this implementation flexibility >>but >>enable interoperability between the various architecture >>implementations >>(that after all is the key problem with the deployment of >>these various >>architectures - lack of interoperability). IMO, if we don't >>design for >>interoperability between the basic architecture types, it is debatable >>if >>something useful would have been accomplished. >> >>Jack Burbank >> >>-----Original Message----- >>From: capwap-admin@frascone.com >>To: Bob O'Hara; capwap@frascone.com >>Sent: 8/5/2004 2:46 PM >>Subject: RE: [Capwap] So many architectures, so little >>time... - take 2 >> >>I agree that we can design a protocol and implement the product that >>works all architectures. I think the question to CAPWAP is: >> >>Should we make it a requirement in CAPWAP protocol to achieve >>interoperability between different architectures? >> >>It is definitely doable, but I'm not sure if that is the >>right thing to >>do.. >> >>Victor >> >>-----Original Message----- >>From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On >>Behalf Of Bob O'Hara >>Sent: Thursday, August 05, 2004 11:43 AM >>To: capwap@frascone.com >>Subject: RE: [Capwap] So many architectures, so little >>time... - take 2 >> >>I think that interoperability will depend on two things. >>First, it will >>depend on how we define the protocol and the flexibility for supported >>architectures it incorporates. Second, it will depend on what >>manufacturers implement, i.e., the flexibility they build into their >>products. >> >>I believe that it is possible to design the protocol for the required >>flexibility. I know it is possible to implement a product with the >>required flexibility. >> >> -Bob O'Hara >> >> >>-----Original Message----- >>From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On >>Behalf Of Abhijit Choudhury >>Sent: Thursday, August 05, 2004 11:32 AM >>To: James Kempf; Shehzad Merchant; capwap@frascone.com >>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; >>Dorothy.Gellert@nokia.com; Inderpreet Singh >>Subject: RE: [Capwap] So many architectures, so little >>time... - take 2 >> >> >>It may be possible to achieve such interoperability >>within the split-MAC family or within the local-MAC >>family. It would sbe very hard to achieve >>that between local and split MAC families. >> >>For example, if vendor X's WTP terminates 802.11 ctrl/mgmt packets and > > >>vendor Y's AC expects the 802.11 mgmt packets to come to it, there's >>no way you can be interoperable. >> >>Or are we planning to specify ONE architecture ? >>The last thing IETF should do is mandate an implementation. >> >>I think a modest and reasonable goal is to come up >>with a protocol that allows sufficient flexbility so >>that vendors with splitMAC architectures can transfer >>most of the information they care about between the WTP and AC. >> >>Just my $0.02 ... >> >> >>Abhijit Choudhury >> >> >>-----Original Message----- >>From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On >>Behalf Of James Kempf >>Sent: Wednesday, August 04, 2004 3:29 PM >>To: Shehzad Merchant; capwap@frascone.com >>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; >>Dorothy.Gellert@nokia.com; Inderpreet Singh >>Subject: Re: [Capwap] So many architectures, so little >>time... - take 2 >> >> >>As a potential customer, let me put it concretely. I want to >>be able to >>buy my access points from Vendor X and my switch from Vendor >>Y and plug >>the two together and have them work without any >>configuration. Also, I'd >>like to be able to buy switches from Vendor Y and Vendor Z and be able >>to plug them into my network at various places and have them >>interoperate. >> >> jak >> >> >>----- Original Message ----- >>From: "Shehzad Merchant" >>To: >>Cc: ; ; >>; >>; "Inderpreet Singh" >> >>Sent: Wednesday, August 04, 2004 3:19 PM >>Subject: RE: [Capwap] So many architectures, so little >>time... - take 2 >> >> >> >>>I think the implementation variations even with the split MAC may >>>cover a broad spectrum. As such its important to clearly articulate >>>what aspects >> >>of >> >>>interoperability we are targetting. Is it truly just >>>control/management or is it interoperability between disparate >>>implementations of the split MAC, i.e. mix and match >> >>operation of WTP >> >>>and ACs of all variants within this category. >>> >>>I suspect for the latter we may have to arrive at some consensus on >>>what particular implementations we are targeting >> >>interoperability for. >> >> >>>If so, ultimately this problem statement could become part of the >>>charter. >>> >>>-Shehzad >>> >>> >>> >>>-----Original Message----- >>>From: capwap-admin@frascone.com >> >>[mailto:capwap-admin@frascone.com] On >>Behalf >> >>>Of Dorothy.Gellert@nokia.com >>>Sent: Wednesday, August 04, 2004 11:53 AM >>>To: isingh@chantrynetworks.com; capwap@frascone.com >>>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com >>>Subject: RE: [Capwap] So many architectures, so little >> >>time... - take >> >>>2 >>> >>>I believe this is the consensus, to scope the charter to >> >>Centralized >> >>>Architecture and LocalMAC and Split MAC. >>> >>>I'll update the charter with this change after the CAPWAP >> >>WG Mtg. If >> >>>there is resistance to this idea, please post to the list. >>> >>>Regards >>>Dorothy >>> >>> >>> >>>>-----Original Message----- >>>>From: capwap-admin@frascone.com >>> >>[mailto:capwap-admin@frascone.com]On >> >>>>Behalf Of ext Inderpreet Singh >>>>Sent: Tuesday, August 03, 2004 9:40 PM >>>>To: capwap@frascone.com >>>>Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David >>>>(Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) >>>>Subject: RE: [Capwap] So many architectures, so little time... - >>>>take 2 >>>> >>>> >>>>The issue(s) at hand and my opinions are: >>>> >>>>1. Do we explicitly state in the re-charter which >>> >>architecture the >> >>>>WG should consider? I think yes. I propose Centralized >>> >>architecture >> >> >>>>only. Autonomous and Distributed should be out of scope >>> >>based on the >> >> >>>>same reasons as per prior postings. >>>> >>>>2. Within Centralized do we focus on all three sub >>> >>architectures or >> >>>>a subset? Remote MAC should be excluded because if I am not >>>>mistaken, the connectivity constraint between the WTP and >>> >>the AC is >> >>>>"direct connect". >>>>That being the case and that no IP layer is involved, it doesn't >>> >>seem >> >>>>clear what kind of protocol would help with interoperability. I am >>> > >>>>concerned about the impact, dependencies and interaction with the >>>>recently constituted IEEE Study group on AP >>> >>functionality on the >> >>>>Split MAC architectures. Furthermore, there are some >>> >>pretty drastic >> >>>>differences on how the vendors have chosen to split the >>> >>mac. Those >> >>>>differences will need to be worked out before designing a >>> >>protocol. >> >>>>So, if the low hanging fruit strategy (as James suggested) for >>>>protocol development and progress is the way to go, then I think >>>>prioritizing on a protocol for Local MAC is a no brainer. >>> >> So as far >> >>>>as focus, I feel we should do Local and Split and in that order. >>>> >>>>3. This is not a re-chartering issue but is a response to Pat's >>>>suggestion that a protocol that just sends the 802.11 MAC frames >>>>from the AP to the AC would work. I think possibly, yes. >>> >> But again >> >> >>>>the complications of splitting the MAC in an >>> >>interoperable way will >> >>>>be an issue. Also, you may note in the draft to which >>> >>you refer, we >> >> >>>>included a capabilities exchange phase. I had thought of >>> >>including >> >>>>in the capability exchange such things as "AP supports Local MAC" >>>>and "AP supports Split MAC", but didn't put it in because the >>>>Taxonomy work was still in progress. Now that it is pretty much >>>>done we could surely include that. But again...let's recharter >>>>first. >>>> >>>>Thanks. Do people agree with 1 & 2? >>>> >>>>--- >>>>Inderpreet Singh >>>>Chantry Networks >>>>isingh@chantrynetworks.com >>>>Cell: 416-831-3705 >>>> >>>>-----Original Message----- >>>>From: capwap-admin@frascone.com >>> >>[mailto:capwap-admin@frascone.com] >> >>>>On Behalf Of Pat R. Calhoun >>>>Sent: Tuesday, August 03, 2004 6:04 PM >>>>To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com; >>>>capwap@frascone.com >>>>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com >>>>Subject: [Capwap] So many architectures, so little >>> >>time... - take 2 >> >>>>After reading Lily's response to Jim, I realize that I >>> >>fell down the >> >> >>>>same trap. Local MAC is also a centralized approach, and so my >>>>previous response was not complete. I believe the real >>> >>question, in >> >>>>my mind, is whether we need to address either the Local >>> >>or the Split >> >> >>>>MAC architecture. >>>> >>>>Just looking at the Architecture Consideration tables (7 and >>>>10) in the >>>>specification, the >>>>main difference (at a high level) between both approaches >>> >>is where >> >>>>the 802.11 management terminates. For Local MAC, it's in the WTP, >>>>while for SPlit MAC, it's in the AC. >>>> >>>>However, looking at table 8, most Local MAC approaches share STA >>>>state between both the WTP and the AC. So clearly there is some >>>>signalling protocol between both the WTP and the AC. >>>> >>>>Looking at one example of a Local MAC protocol (see >>>> >>> > http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > >>>there is a protocol message >>>that corresponds for every 802.11 MAC management event. So when a >>>STA associates, the AP breaks the message apart and creates an new >>>protocol PDU, which contains components found in the association >>>request. I suspect that most Local MAC approaches do something very >>>similar. >>> >>>So if a protocol simply tunnels the 802.11 MAC management frames >>>from the WTP to the AC, it allows supports both approaches. For >>>Local MAC, they get what they want via the 802.11 frame, and this >>>also works fine for Split MAC, which needs access to the MAC >>>management frame. What would be required in such a protocol is a way >>>for the AP to communicate whether it will be providing very specific >>>functions - basically a capabilities negotiation approach. >>> >>>So I do believe that there is a way to address both architectures >>>using a single protocol. >>> >>>Thoughts? >>> >>>PatC >>> >>>_______________________________________________ >>>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 > _______________________________________________ > 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 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap -- Shankar Narayanaswamy, Ph.D. wireless@shankar.org Mobile: +1 650-387-4593 http://www.shankar.org E-Fax: +1 253-498-8372 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Aug 10 14:13:59 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18510 for ; Tue, 10 Aug 2004 14:13:58 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CB6C12036C; Tue, 10 Aug 2004 13:59:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C6BAD213DA; Tue, 10 Aug 2004 13:59:06 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E962E2001C for ; Tue, 10 Aug 2004 13:58:18 -0400 (EDT) Received: from mail3.extremenetworks.com (sc-f100-01.extremenetworks.com [63.251.106.30]) by mail.frascone.com (Postfix) with ESMTP id C29CA2036C for ; Tue, 10 Aug 2004 13:58:16 -0400 (EDT) Received: by mail3 with Internet Mail Service (5.5.2657.72) id ; Tue, 10 Aug 2004 11:11:33 -0700 Message-ID: <1B8A2DD33C49824F8D9021678C127213026B0C17@sc-msexch-04.extremenetworks.com> From: Shehzad Merchant To: Shankar Narayanaswamy , Abhijit Choudhury Cc: capwap@frascone.com Subject: RE: [Capwap] So many architectures, so little time... - take 2 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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: Tue, 10 Aug 2004 11:12:56 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Additionally, for data tunneling one needs a lightweight mechanism that may not necessarily have the same requirements as that for control and management. For example, one would want to limit the tunneling and processing overhead on data packets to a minimum. Control and management may be more tolerant of tunneling/security/etc. overhead. Besides, there are plenty of standards in place for data tunneling. We may potentially be able to leverage off that work itself without having to invent yet another tunneling mechanism for data. -S -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Shankar Narayanaswamy Sent: Tuesday, August 10, 2004 10:30 AM To: Abhijit Choudhury Cc: capwap@frascone.com Subject: Re: [Capwap] So many architectures, so little time... - take 2 On the first point: not necessarily. If data packets are encapsulated 802.11 data frames, then there is no need to protect them on the wire any more than they were encrypted over the air. But control and management packets will need protection over the wired network and therefore possibly a different tunneling protocol. On the second point (standard way of packet exchange): yes! -s Abhijit Choudhury wrote: > The same tunneling protocol that moves control and management packets > from the WTP to the AC should be used to tunnel data packets as well. > We would specify message exchanges to do control, provisioning and > capability advertisement between WTPs and the AC. But all of this > would be within the unified CAPWAP protocol that moves all packets > including data between the WTP and AC. Vendors currently use LWAPP, > GRE, IP and some proprietary encapsulations to achieve this. This > group would come up with a "standard" way of doing this exchange. > > At least that was my understanding.... > > Regards, > Abhijit > > -----Original Mssage----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Wijnen, Bert (Bert) > Sent: Monday, August 09, 2004 6:14 AM > To: 'Yang, Lily L'; Burbank, Jack L.; Victor Lin; Bob O'Hara; > capwap@frascone.com > Subject: RE: [Capwap] So many architectures, so little time... - take > 2 > > > Not sure who is confused... probably me... > > My understanding was/is that IF we do re-charter for CAPWAP protocol > work, that it is then a NM protocol for "Control and Provisioning" and > not any of the related stuff that moves the data from WTP to AC. > > Is everybody in agreement with that understanding. > > Thanks, > Bert > > >>-----Original Message----- >>From: Yang, Lily L [mailto:lily.l.yang@intel.com] >>Sent: maandag 9 augustus 2004 08:14 >>To: Burbank, Jack L.; Victor Lin ; Bob O'Hara ; capwap@frascone.com >>Subject: RE: [Capwap] So many architectures, so little time... - take >>2 >> >> >>I think setting the re-charter scope to develop a single protocol that > > >>allows interoperability between Local and Split MAC is a reasonable >>tradeoff: >>We exclude remote MAC because the constraint it imposes is very >>different from the rest and the benefit of including it is very >>little. But Local and Split MAC are reasonably close and hence the >>effort may be incremental only. >>As many people noted, as of today, there is no single clear definition >>of what "Local MAC" and "Split MAC" really means yet. Each vendor has >>different definitions and some debate needs to happen so that the WG >>can reach consensus on what exactly that means, and what kinds of >>flexibility we want to retain within each class of architecture, and >>what kind of differences we can to resolve and agree up front. That >>should also be part of the work items for the new WG -- such agreement >>on the details for each architecture must be documented somewhere, if >>not separately, then as part of the Protocol document. >> >>-----Original Message----- >>From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On >>Behalf Of Burbank, Jack L. >>Sent: Thursday, August 05, 2004 12:14 PM >>To: 'Victor Lin '; 'Bob O'Hara '; 'capwap@frascone.com ' >>Subject: RE: [Capwap] So many architectures, so little time... - take >>2 >> >>I think that interoperability between different architectures should >>be a requirement, if not the key requirement. As was mentioned >>yesterday, a goal of the IEEE is that they maintain flexibility in >>terms of how products and architectures are implemented. I think we >>shouldn't do anything that is contrary to that goal (or at least we >>should minimize the impact). I think that the goal of CAPWAP should >>be to retain this type of flexibility by designing a protocol that can >>maintain this implementation flexibility but enable interoperability >>between the various architecture implementations (that after all is >>the key problem with the deployment of these various architectures - >>lack of interoperability). IMO, if we don't design for >>interoperability between the basic architecture types, it is debatable >>if something useful would have been accomplished. >> >>Jack Burbank >> >>-----Original Message----- >>From: capwap-admin@frascone.com >>To: Bob O'Hara; capwap@frascone.com >>Sent: 8/5/2004 2:46 PM >>Subject: RE: [Capwap] So many architectures, so little time... - take >>2 >> >>I agree that we can design a protocol and implement the product that >>works all architectures. I think the question to CAPWAP is: >> >>Should we make it a requirement in CAPWAP protocol to achieve >>interoperability between different architectures? >> >>It is definitely doable, but I'm not sure if that is the right thing >>to do.. >> >>Victor >> >>-----Original Message----- >>From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On >>Behalf Of Bob O'Hara >>Sent: Thursday, August 05, 2004 11:43 AM >>To: capwap@frascone.com >>Subject: RE: [Capwap] So many architectures, so little time... - take >>2 >> >>I think that interoperability will depend on two things. >>First, it will >>depend on how we define the protocol and the flexibility for supported >>architectures it incorporates. Second, it will depend on what >>manufacturers implement, i.e., the flexibility they build into their >>products. >> >>I believe that it is possible to design the protocol for the required >>flexibility. I know it is possible to implement a product with the >>required flexibility. >> >> -Bob O'Hara >> >> >>-----Original Message----- >>From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On >>Behalf Of Abhijit Choudhury >>Sent: Thursday, August 05, 2004 11:32 AM >>To: James Kempf; Shehzad Merchant; capwap@frascone.com >>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; >>Dorothy.Gellert@nokia.com; Inderpreet Singh >>Subject: RE: [Capwap] So many architectures, so little time... - take >>2 >> >> >>It may be possible to achieve such interoperability within the >>split-MAC family or within the local-MAC family. It would sbe very >>hard to achieve that between local and split MAC families. >> >>For example, if vendor X's WTP terminates 802.11 ctrl/mgmt packets and > > >>vendor Y's AC expects the 802.11 mgmt packets to come to it, there's >>no way you can be interoperable. >> >>Or are we planning to specify ONE architecture ? >>The last thing IETF should do is mandate an implementation. >> >>I think a modest and reasonable goal is to come up with a protocol >>that allows sufficient flexbility so that vendors with splitMAC >>architectures can transfer most of the information they care about >>between the WTP and AC. >> >>Just my $0.02 ... >> >> >>Abhijit Choudhury >> >> >>-----Original Message----- >>From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On >>Behalf Of James Kempf >>Sent: Wednesday, August 04, 2004 3:29 PM >>To: Shehzad Merchant; capwap@frascone.com >>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; >>Dorothy.Gellert@nokia.com; Inderpreet Singh >>Subject: Re: [Capwap] So many architectures, so little time... - take >>2 >> >> >>As a potential customer, let me put it concretely. I want to be able >>to buy my access points from Vendor X and my switch from Vendor Y and >>plug the two together and have them work without any configuration. >>Also, I'd like to be able to buy switches from Vendor Y and Vendor Z >>and be able to plug them into my network at various places and have >>them interoperate. >> >> jak >> >> >>----- Original Message ----- >>From: "Shehzad Merchant" >>To: >>Cc: ; ; >>; ; "Inderpreet >>Singh" >> >>Sent: Wednesday, August 04, 2004 3:19 PM >>Subject: RE: [Capwap] So many architectures, so little time... - take >>2 >> >> >> >>>I think the implementation variations even with the split MAC may >>>cover a broad spectrum. As such its important to clearly articulate >>>what aspects >> >>of >> >>>interoperability we are targetting. Is it truly just >>>control/management or is it interoperability between disparate >>>implementations of the split MAC, i.e. mix and match >> >>operation of WTP >> >>>and ACs of all variants within this category. >>> >>>I suspect for the latter we may have to arrive at some consensus on >>>what particular implementations we are targeting >> >>interoperability for. >> >> >>>If so, ultimately this problem statement could become part of the >>>charter. >>> >>>-Shehzad >>> >>> >>> >>>-----Original Message----- >>>From: capwap-admin@frascone.com >> >>[mailto:capwap-admin@frascone.com] On >>Behalf >> >>>Of Dorothy.Gellert@nokia.com >>>Sent: Wednesday, August 04, 2004 11:53 AM >>>To: isingh@chantrynetworks.com; capwap@frascone.com >>>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com >>>Subject: RE: [Capwap] So many architectures, so little >> >>time... - take >> >>>2 >>> >>>I believe this is the consensus, to scope the charter to >> >>Centralized >> >>>Architecture and LocalMAC and Split MAC. >>> >>>I'll update the charter with this change after the CAPWAP >> >>WG Mtg. If >> >>>there is resistance to this idea, please post to the list. >>> >>>Regards >>>Dorothy >>> >>> >>> >>>>-----Original Message----- >>>>From: capwap-admin@frascone.com >>> >>[mailto:capwap-admin@frascone.com]On >> >>>>Behalf Of ext Inderpreet Singh >>>>Sent: Tuesday, August 03, 2004 9:40 PM >>>>To: capwap@frascone.com >>>>Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David >>>>(Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) >>>>Subject: RE: [Capwap] So many architectures, so little time... - >>>>take 2 >>>> >>>> >>>>The issue(s) at hand and my opinions are: >>>> >>>>1. Do we explicitly state in the re-charter which >>> >>architecture the >> >>>>WG should consider? I think yes. I propose Centralized >>> >>architecture >> >> >>>>only. Autonomous and Distributed should be out of scope >>> >>based on the >> >> >>>>same reasons as per prior postings. >>>> >>>>2. Within Centralized do we focus on all three sub >>> >>architectures or >> >>>>a subset? Remote MAC should be excluded because if I am not >>>>mistaken, the connectivity constraint between the WTP and >>> >>the AC is >> >>>>"direct connect". >>>>That being the case and that no IP layer is involved, it doesn't >>> >>seem >> >>>>clear what kind of protocol would help with interoperability. I am >>> > >>>>concerned about the impact, dependencies and interaction with the >>>>recently constituted IEEE Study group on AP >>> >>functionality on the >> >>>>Split MAC architectures. Furthermore, there are some >>> >>pretty drastic >> >>>>differences on how the vendors have chosen to split the >>> >>mac. Those >> >>>>differences will need to be worked out before designing a >>> >>protocol. >> >>>>So, if the low hanging fruit strategy (as James suggested) for >>>>protocol development and progress is the way to go, then I think >>>>prioritizing on a protocol for Local MAC is a no brainer. >>> >> So as far >> >>>>as focus, I feel we should do Local and Split and in that order. >>>> >>>>3. This is not a re-chartering issue but is a response to Pat's >>>>suggestion that a protocol that just sends the 802.11 MAC frames >>>>from the AP to the AC would work. I think possibly, yes. >>> >> But again >> >> >>>>the complications of splitting the MAC in an >>> >>interoperable way will >> >>>>be an issue. Also, you may note in the draft to which >>> >>you refer, we >> >> >>>>included a capabilities exchange phase. I had thought of >>> >>including >> >>>>in the capability exchange such things as "AP supports Local MAC" >>>>and "AP supports Split MAC", but didn't put it in because the >>>>Taxonomy work was still in progress. Now that it is pretty much >>>>done we could surely include that. But again...let's recharter >>>>first. >>>> >>>>Thanks. Do people agree with 1 & 2? >>>> >>>>--- >>>>Inderpreet Singh >>>>Chantry Networks >>>>isingh@chantrynetworks.com >>>>Cell: 416-831-3705 >>>> >>>>-----Original Message----- >>>>From: capwap-admin@frascone.com >>> >>[mailto:capwap-admin@frascone.com] >> >>>>On Behalf Of Pat R. Calhoun >>>>Sent: Tuesday, August 03, 2004 6:04 PM >>>>To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com; >>>>capwap@frascone.com >>>>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com >>>>Subject: [Capwap] So many architectures, so little >>> >>time... - take 2 >> >>>>After reading Lily's response to Jim, I realize that I >>> >>fell down the >> >> >>>>same trap. Local MAC is also a centralized approach, and so my >>>>previous response was not complete. I believe the real >>> >>question, in >> >>>>my mind, is whether we need to address either the Local >>> >>or the Split >> >> >>>>MAC architecture. >>>> >>>>Just looking at the Architecture Consideration tables (7 and >>>>10) in the >>>>specification, the >>>>main difference (at a high level) between both approaches >>> >>is where >> >>>>the 802.11 management terminates. For Local MAC, it's in the WTP, >>>>while for SPlit MAC, it's in the AC. >>>> >>>>However, looking at table 8, most Local MAC approaches share STA >>>>state between both the WTP and the AC. So clearly there is some >>>>signalling protocol between both the WTP and the AC. >>>> >>>>Looking at one example of a Local MAC protocol (see >>>> >>> > http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > >>>there is a protocol message >>>that corresponds for every 802.11 MAC management event. So when a STA >>>associates, the AP breaks the message apart and creates an new >>>protocol PDU, which contains components found in the association >>>request. I suspect that most Local MAC approaches do something very >>>similar. >>> >>>So if a protocol simply tunnels the 802.11 MAC management frames from >>>the WTP to the AC, it allows supports both approaches. For Local MAC, >>>they get what they want via the 802.11 frame, and this also works >>>fine for Split MAC, which needs access to the MAC management frame. >>>What would be required in such a protocol is a way for the AP to >>>communicate whether it will be providing very specific functions - >>>basically a capabilities negotiation approach. >>> >>>So I do believe that there is a way to address both architectures >>>using a single protocol. >>> >>>Thoughts? >>> >>>PatC >>> >>>_______________________________________________ >>>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 > _______________________________________________ > 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 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap -- Shankar Narayanaswamy, Ph.D. wireless@shankar.org Mobile: +1 650-387-4593 http://www.shankar.org E-Fax: +1 253-498-8372 _______________________________________________ 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 Aug 10 14:49:57 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20464 for ; Tue, 10 Aug 2004 14:49:55 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6DAE121410; Tue, 10 Aug 2004 14:35:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EED912144D; Tue, 10 Aug 2004 14:35:05 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 22B782144D for ; Tue, 10 Aug 2004 14:34:25 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mail.frascone.com (Postfix) with ESMTP id B669E21410 for ; Tue, 10 Aug 2004 14:34:22 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7AIn0B15557; Tue, 10 Aug 2004 21:49:00 +0300 (EET DST) X-Scanned: Tue, 10 Aug 2004 21:48:36 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i7AImaSd009809; Tue, 10 Aug 2004 21:48:36 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00NlSZGT; Tue, 10 Aug 2004 21:48:35 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7AImXn11457; Tue, 10 Aug 2004 21:48:33 +0300 (EET DST) Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 10 Aug 2004 13:48:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] So many architectures, so little time... - take 2 Message-ID: Thread-Topic: [Capwap] So many architectures, so little time... - take 2 Thread-Index: AcR/Bjlu80/lGeszT4mLRixePDcBWAAA3mcA From: To: , , Cc: X-OriginalArrivalTime: 10 Aug 2004 18:48:01.0513 (UTC) FILETIME=[8FF9CD90:01C47F0A] 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, 10 Aug 2004 11:47:59 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Our charter is limited to control and management, not data tunneling. = Lets stay focused on our chartered goal, control and management. Thanks, Dorothy > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > Behalf Of ext Shehzad Merchant > Sent: Tuesday, August 10, 2004 11:13 AM > To: Shankar Narayanaswamy; Abhijit Choudhury > Cc: capwap@frascone.com > Subject: RE: [Capwap] So many architectures, so little=20 > time... - take 2 >=20 >=20 > Additionally, for data tunneling one needs a lightweight=20 > mechanism that may > not necessarily have the same requirements as that for control and > management. For example, one would want to limit the tunneling and > processing overhead on data packets to a minimum. Control and=20 > management may > be more tolerant of tunneling/security/etc. overhead.=20 > Besides, there are > plenty of standards in place for data tunneling. We may=20 > potentially be able > to leverage off that work itself without having to invent yet another > tunneling mechanism for data.=20 >=20 > -S >=20 >=20 > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf > Of Shankar Narayanaswamy > Sent: Tuesday, August 10, 2004 10:30 AM > To: Abhijit Choudhury > Cc: capwap@frascone.com > Subject: Re: [Capwap] So many architectures, so little=20 > time... - take 2 >=20 > On the first point: not necessarily. If data packets are encapsulated > 802.11 data frames, then there is no need to protect them on=20 > the wire any > more than they were encrypted over the air. >=20 > But control and management packets will need protection over the wired > network and therefore possibly a different tunneling protocol. >=20 > On the second point (standard way of packet exchange): yes! >=20 > -s >=20 > Abhijit Choudhury wrote: > > The same tunneling protocol that moves control and=20 > management packets=20 > > from the WTP to the AC should be used to tunnel data=20 > packets as well. =20 > > We would specify message exchanges to do control, provisioning and=20 > > capability advertisement between WTPs and the AC. But all of this=20 > > would be within the unified CAPWAP protocol that moves all packets=20 > > including data between the WTP and AC. Vendors currently=20 > use LWAPP,=20 > > GRE, IP and some proprietary encapsulations to achieve this. This=20 > > group would come up with a "standard" way of doing this exchange. > >=20 > > At least that was my understanding.... > >=20 > > Regards, > > Abhijit > >=20 > > -----Original Mssage----- > > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On=20 > > Behalf Of Wijnen, Bert (Bert) > > Sent: Monday, August 09, 2004 6:14 AM > > To: 'Yang, Lily L'; Burbank, Jack L.; Victor Lin; Bob O'Hara;=20 > > capwap@frascone.com > > Subject: RE: [Capwap] So many architectures, so little=20 > time... - take=20 > > 2 > >=20 > >=20 > > Not sure who is confused... probably me... > >=20 > > My understanding was/is that IF we do re-charter for CAPWAP=20 > protocol=20 > > work, that it is then a NM protocol for "Control and=20 > Provisioning" and=20 > > not any of the related stuff that moves the data from WTP to AC. > >=20 > > Is everybody in agreement with that understanding. > >=20 > > Thanks, > > Bert > >=20 > >=20 > >>-----Original Message----- > >>From: Yang, Lily L [mailto:lily.l.yang@intel.com] > >>Sent: maandag 9 augustus 2004 08:14 > >>To: Burbank, Jack L.; Victor Lin ; Bob O'Hara ; capwap@frascone.com > >>Subject: RE: [Capwap] So many architectures, so little=20 > time... - take=20 > >>2 > >> > >> > >>I think setting the re-charter scope to develop a single=20 > protocol that > >=20 > >=20 > >>allows interoperability between Local and Split MAC is a reasonable > >>tradeoff: > >>We exclude remote MAC because the constraint it imposes is very=20 > >>different from the rest and the benefit of including it is very=20 > >>little. But Local and Split MAC are reasonably close and hence the=20 > >>effort may be incremental only. > >>As many people noted, as of today, there is no single clear=20 > definition=20 > >>of what "Local MAC" and "Split MAC" really means yet. Each=20 > vendor has=20 > >>different definitions and some debate needs to happen so=20 > that the WG=20 > >>can reach consensus on what exactly that means, and what kinds of=20 > >>flexibility we want to retain within each class of=20 > architecture, and=20 > >>what kind of differences we can to resolve and agree up front. That=20 > >>should also be part of the work items for the new WG --=20 > such agreement=20 > >>on the details for each architecture must be documented=20 > somewhere, if=20 > >>not separately, then as part of the Protocol document. > >> > >>-----Original Message----- > >>From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On=20 > >>Behalf Of Burbank, Jack L. > >>Sent: Thursday, August 05, 2004 12:14 PM > >>To: 'Victor Lin '; 'Bob O'Hara '; 'capwap@frascone.com ' > >>Subject: RE: [Capwap] So many architectures, so little=20 > time... - take=20 > >>2 > >> > >>I think that interoperability between different=20 > architectures should=20 > >>be a requirement, if not the key requirement. As was mentioned=20 > >>yesterday, a goal of the IEEE is that they maintain flexibility in=20 > >>terms of how products and architectures are implemented. I=20 > think we=20 > >>shouldn't do anything that is contrary to that goal (or at least we=20 > >>should minimize the impact). I think that the goal of=20 > CAPWAP should=20 > >>be to retain this type of flexibility by designing a=20 > protocol that can=20 > >>maintain this implementation flexibility but enable=20 > interoperability=20 > >>between the various architecture implementations (that after all is=20 > >>the key problem with the deployment of these various=20 > architectures -=20 > >>lack of interoperability). IMO, if we don't design for=20 > >>interoperability between the basic architecture types, it=20 > is debatable=20 > >>if something useful would have been accomplished. > >> > >>Jack Burbank > >> > >>-----Original Message----- > >>From: capwap-admin@frascone.com > >>To: Bob O'Hara; capwap@frascone.com > >>Sent: 8/5/2004 2:46 PM > >>Subject: RE: [Capwap] So many architectures, so little=20 > time... - take=20 > >>2 > >> > >>I agree that we can design a protocol and implement the=20 > product that=20 > >>works all architectures. I think the question to CAPWAP is: > >> > >>Should we make it a requirement in CAPWAP protocol to achieve=20 > >>interoperability between different architectures? > >> > >>It is definitely doable, but I'm not sure if that is the=20 > right thing=20 > >>to do.. > >> > >>Victor > >> > >>-----Original Message----- > >>From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On=20 > >>Behalf Of Bob O'Hara > >>Sent: Thursday, August 05, 2004 11:43 AM > >>To: capwap@frascone.com > >>Subject: RE: [Capwap] So many architectures, so little=20 > time... - take=20 > >>2 > >> > >>I think that interoperability will depend on two things. > >>First, it will > >>depend on how we define the protocol and the flexibility=20 > for supported=20 > >>architectures it incorporates. Second, it will depend on what=20 > >>manufacturers implement, i.e., the flexibility they build=20 > into their=20 > >>products. > >> > >>I believe that it is possible to design the protocol for=20 > the required=20 > >>flexibility. I know it is possible to implement a product with the=20 > >>required flexibility. > >> > >> -Bob O'Hara > >>=20 > >> > >>-----Original Message----- > >>From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On=20 > >>Behalf Of Abhijit Choudhury > >>Sent: Thursday, August 05, 2004 11:32 AM > >>To: James Kempf; Shehzad Merchant; capwap@frascone.com > >>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com;=20 > >>Dorothy.Gellert@nokia.com; Inderpreet Singh > >>Subject: RE: [Capwap] So many architectures, so little=20 > time... - take=20 > >>2 > >> > >> > >>It may be possible to achieve such interoperability within the=20 > >>split-MAC family or within the local-MAC family. It would sbe very=20 > >>hard to achieve that between local and split MAC families. > >> > >>For example, if vendor X's WTP terminates 802.11 ctrl/mgmt=20 > packets and > >=20 > >=20 > >>vendor Y's AC expects the 802.11 mgmt packets to come to=20 > it, there's=20 > >>no way you can be interoperable. > >> > >>Or are we planning to specify ONE architecture ? > >>The last thing IETF should do is mandate an implementation. > >> > >>I think a modest and reasonable goal is to come up with a protocol=20 > >>that allows sufficient flexbility so that vendors with splitMAC=20 > >>architectures can transfer most of the information they care about=20 > >>between the WTP and AC. > >> > >>Just my $0.02 ... > >> > >> > >>Abhijit Choudhury > >> > >> > >>-----Original Message----- > >>From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On=20 > >>Behalf Of James Kempf > >>Sent: Wednesday, August 04, 2004 3:29 PM > >>To: Shehzad Merchant; capwap@frascone.com > >>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com;=20 > >>Dorothy.Gellert@nokia.com; Inderpreet Singh > >>Subject: Re: [Capwap] So many architectures, so little=20 > time... - take=20 > >>2 > >> > >> > >>As a potential customer, let me put it concretely. I want=20 > to be able=20 > >>to buy my access points from Vendor X and my switch from=20 > Vendor Y and=20 > >>plug the two together and have them work without any configuration.=20 > >>Also, I'd like to be able to buy switches from Vendor Y and=20 > Vendor Z=20 > >>and be able to plug them into my network at various places and have=20 > >>them interoperate. > >> > >> jak > >> > >> > >>----- Original Message ----- > >>From: "Shehzad Merchant" > >>To: > >>Cc: ; ;=20 > >>; ; "Inderpreet=20 > >>Singh" > >> > >>Sent: Wednesday, August 04, 2004 3:19 PM > >>Subject: RE: [Capwap] So many architectures, so little=20 > time... - take=20 > >>2 > >> > >> > >> > >>>I think the implementation variations even with the split MAC may=20 > >>>cover a broad spectrum. As such its important to clearly=20 > articulate=20 > >>>what aspects > >> > >>of > >> > >>>interoperability we are targetting. Is it truly just=20 > >>>control/management or is it interoperability between disparate=20 > >>>implementations of the split MAC, i.e. mix and match > >> > >>operation of WTP > >> > >>>and ACs of all variants within this category. > >>> > >>>I suspect for the latter we may have to arrive at some=20 > consensus on=20 > >>>what particular implementations we are targeting > >> > >>interoperability for. > >> > >> > >>>If so, ultimately this problem statement could become part of the=20 > >>>charter. > >>> > >>>-Shehzad > >>> > >>> > >>> > >>>-----Original Message----- > >>>From: capwap-admin@frascone.com > >> > >>[mailto:capwap-admin@frascone.com] On > >>Behalf > >> > >>>Of Dorothy.Gellert@nokia.com > >>>Sent: Wednesday, August 04, 2004 11:53 AM > >>>To: isingh@chantrynetworks.com; capwap@frascone.com > >>>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > >>>Subject: RE: [Capwap] So many architectures, so little > >> > >>time... - take > >> > >>>2 > >>> > >>>I believe this is the consensus, to scope the charter to > >> > >>Centralized > >> > >>>Architecture and LocalMAC and Split MAC. > >>> > >>>I'll update the charter with this change after the CAPWAP > >> > >>WG Mtg. If > >> > >>>there is resistance to this idea, please post to the list. > >>> > >>>Regards > >>>Dorothy > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: capwap-admin@frascone.com > >>> > >>[mailto:capwap-admin@frascone.com]On > >> > >>>>Behalf Of ext Inderpreet Singh > >>>>Sent: Tuesday, August 03, 2004 9:40 PM > >>>>To: capwap@frascone.com > >>>>Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David=20 > >>>>(Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > >>>>Subject: RE: [Capwap] So many architectures, so little time... -=20 > >>>>take 2 > >>>> > >>>> > >>>>The issue(s) at hand and my opinions are: > >>>> > >>>>1. Do we explicitly state in the re-charter which > >>> > >>architecture the > >> > >>>>WG should consider? I think yes. I propose Centralized > >>> > >>architecture > >> > >> > >>>>only. Autonomous and Distributed should be out of scope > >>> > >>based on the > >> > >> > >>>>same reasons as per prior postings. > >>>> > >>>>2. Within Centralized do we focus on all three sub > >>> > >>architectures or > >> > >>>>a subset? Remote MAC should be excluded because if I am not=20 > >>>>mistaken, the connectivity constraint between the WTP and > >>> > >>the AC is > >> > >>>>"direct connect". > >>>>That being the case and that no IP layer is involved, it doesn't > >>> > >>seem > >> > >>>>clear what kind of protocol would help with interoperability. I am > >>> > >=20 > >>>>concerned about the impact, dependencies and interaction with the=20 > >>>>recently constituted IEEE Study group on AP > >>> > >>functionality on the > >> > >>>>Split MAC architectures. Furthermore, there are some > >>> > >>pretty drastic > >> > >>>>differences on how the vendors have chosen to split the > >>> > >>mac. Those > >> > >>>>differences will need to be worked out before designing a > >>> > >>protocol. > >> > >>>>So, if the low hanging fruit strategy (as James suggested) for=20 > >>>>protocol development and progress is the way to go, then I think=20 > >>>>prioritizing on a protocol for Local MAC is a no brainer. > >>> > >> So as far > >> > >>>>as focus, I feel we should do Local and Split and in that order. > >>>> > >>>>3. This is not a re-chartering issue but is a response to Pat's=20 > >>>>suggestion that a protocol that just sends the 802.11 MAC frames=20 > >>>>from the AP to the AC would work. I think possibly, yes. > >>> > >> But again > >> > >> > >>>>the complications of splitting the MAC in an > >>> > >>interoperable way will > >> > >>>>be an issue. Also, you may note in the draft to which > >>> > >>you refer, we > >> > >> > >>>>included a capabilities exchange phase. I had thought of > >>> > >>including > >> > >>>>in the capability exchange such things as "AP supports Local MAC" > >>>>and "AP supports Split MAC", but didn't put it in because the=20 > >>>>Taxonomy work was still in progress. Now that it is pretty much=20 > >>>>done we could surely include that. But again...let's recharter=20 > >>>>first. > >>>> > >>>>Thanks. Do people agree with 1 & 2? > >>>> > >>>>--- > >>>>Inderpreet Singh > >>>>Chantry Networks > >>>>isingh@chantrynetworks.com > >>>>Cell: 416-831-3705 > >>>> > >>>>-----Original Message----- > >>>>From: capwap-admin@frascone.com > >>> > >>[mailto:capwap-admin@frascone.com] > >> > >>>>On Behalf Of Pat R. Calhoun > >>>>Sent: Tuesday, August 03, 2004 6:04 PM > >>>>To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com;=20 > >>>>capwap@frascone.com > >>>>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > >>>>Subject: [Capwap] So many architectures, so little > >>> > >>time... - take 2 > >> > >>>>After reading Lily's response to Jim, I realize that I > >>> > >>fell down the > >> > >> > >>>>same trap. Local MAC is also a centralized approach, and so my=20 > >>>>previous response was not complete. I believe the real > >>> > >>question, in > >> > >>>>my mind, is whether we need to address either the Local > >>> > >>or the Split > >> > >> > >>>>MAC architecture. > >>>> > >>>>Just looking at the Architecture Consideration tables (7 and > >>>>10) in the > >>>>specification, the > >>>>main difference (at a high level) between both approaches > >>> > >>is where > >> > >>>>the 802.11 management terminates. For Local MAC, it's in the WTP,=20 > >>>>while for SPlit MAC, it's in the AC. > >>>> > >>>>However, looking at table 8, most Local MAC approaches share STA=20 > >>>>state between both the WTP and the AC. So clearly there is some=20 > >>>>signalling protocol between both the WTP and the AC. > >>>> > >>>>Looking at one example of a Local MAC protocol (see > >>>> > >>> > > http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > >=20 > >>>there is a protocol message > >>>that corresponds for every 802.11 MAC management event. So=20 > when a STA=20 > >>>associates, the AP breaks the message apart and creates an new=20 > >>>protocol PDU, which contains components found in the association=20 > >>>request. I suspect that most Local MAC approaches do=20 > something very=20 > >>>similar. > >>> > >>>So if a protocol simply tunnels the 802.11 MAC management=20 > frames from=20 > >>>the WTP to the AC, it allows supports both approaches. For=20 > Local MAC,=20 > >>>they get what they want via the 802.11 frame, and this also works=20 > >>>fine for Split MAC, which needs access to the MAC=20 > management frame.=20 > >>>What would be required in such a protocol is a way for the AP to=20 > >>>communicate whether it will be providing very specific functions -=20 > >>>basically a capabilities negotiation approach. > >>> > >>>So I do believe that there is a way to address both architectures=20 > >>>using a single protocol. > >>> > >>>Thoughts? > >>> > >>>PatC > >>> > >>>_______________________________________________ > >>>Capwap mailing list > >>>Capwap@frascone.com=20 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 >=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 > _______________________________________________ > 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 -- Shankar Narayanaswamy, Ph.D. wireless@shankar.org Mobile: +1 650-387-4593 http://www.shankar.org E-Fax: +1 253-498-8372 _______________________________________________ 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 Aug 10 14:51:56 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20572 for ; Tue, 10 Aug 2004 14:51:55 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A2C3A217B5; Tue, 10 Aug 2004 14:37:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E2151217BF; Tue, 10 Aug 2004 14:37:05 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D00EE217B5 for ; Tue, 10 Aug 2004 14:36:07 -0400 (EDT) Received: from sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by mail.frascone.com (Postfix) with ESMTP id B1B1421456 for ; Tue, 10 Aug 2004 14:36:05 -0400 (EDT) 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.6944.0 Subject: RE: [Capwap] So many architectures, so little time... - take 2 Message-ID: Thread-Topic: [Capwap] So many architectures, so little time... - take 2 Thread-Index: AcR/Bmj8yt99Q2VUTPyN1QkjwC5gbAAA9dfQ From: "Sudhanshu Jain" To: "Shehzad Merchant" , "Shankar Narayanaswamy" , "Abhijit Choudhury" 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, 10 Aug 2004 11:54:42 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I fully agree with Shehzad. We need to separate the control and data plane. Control plane should provide the framework to use one of several tunneling protocol.=20 On data plane, if we need to define a new layer2/layer3 level tunneling protocol, it should be separate work from control protocol work.=20 -Suds -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Shehzad Merchant Sent: Tuesday, August 10, 2004 11:13 AM To: Shankar Narayanaswamy; Abhijit Choudhury Cc: capwap@frascone.com Subject: RE: [Capwap] So many architectures, so little time... - take 2 Additionally, for data tunneling one needs a lightweight mechanism that may not necessarily have the same requirements as that for control and management. For example, one would want to limit the tunneling and processing overhead on data packets to a minimum. Control and management may be more tolerant of tunneling/security/etc. overhead. Besides, there are plenty of standards in place for data tunneling. We may potentially be able to leverage off that work itself without having to invent yet another tunneling mechanism for data.=20 -S -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Shankar Narayanaswamy Sent: Tuesday, August 10, 2004 10:30 AM To: Abhijit Choudhury Cc: capwap@frascone.com Subject: Re: [Capwap] So many architectures, so little time... - take 2 On the first point: not necessarily. If data packets are encapsulated 802.11 data frames, then there is no need to protect them on the wire any more than they were encrypted over the air. But control and management packets will need protection over the wired network and therefore possibly a different tunneling protocol. On the second point (standard way of packet exchange): yes! -s Abhijit Choudhury wrote: > The same tunneling protocol that moves control and management packets=20 > from the WTP to the AC should be used to tunnel data packets as well. > We would specify message exchanges to do control, provisioning and=20 > capability advertisement between WTPs and the AC. But all of this=20 > would be within the unified CAPWAP protocol that moves all packets=20 > including data between the WTP and AC. Vendors currently use LWAPP,=20 > GRE, IP and some proprietary encapsulations to achieve this. This=20 > group would come up with a "standard" way of doing this exchange. >=20 > At least that was my understanding.... >=20 > Regards, > Abhijit >=20 > -----Original Mssage----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On=20 > Behalf Of Wijnen, Bert (Bert) > Sent: Monday, August 09, 2004 6:14 AM > To: 'Yang, Lily L'; Burbank, Jack L.; Victor Lin; Bob O'Hara;=20 > capwap@frascone.com > Subject: RE: [Capwap] So many architectures, so little time... - take=20 > 2 >=20 >=20 > Not sure who is confused... probably me... >=20 > My understanding was/is that IF we do re-charter for CAPWAP protocol=20 > work, that it is then a NM protocol for "Control and Provisioning" and > not any of the related stuff that moves the data from WTP to AC. >=20 > Is everybody in agreement with that understanding. >=20 > Thanks, > Bert >=20 >=20 >>-----Original Message----- >>From: Yang, Lily L [mailto:lily.l.yang@intel.com] >>Sent: maandag 9 augustus 2004 08:14 >>To: Burbank, Jack L.; Victor Lin ; Bob O'Hara ; capwap@frascone.com >>Subject: RE: [Capwap] So many architectures, so little time... - take=20 >>2 >> >> >>I think setting the re-charter scope to develop a single protocol that >=20 >=20 >>allows interoperability between Local and Split MAC is a reasonable >>tradeoff: >>We exclude remote MAC because the constraint it imposes is very=20 >>different from the rest and the benefit of including it is very=20 >>little. But Local and Split MAC are reasonably close and hence the=20 >>effort may be incremental only. >>As many people noted, as of today, there is no single clear definition >>of what "Local MAC" and "Split MAC" really means yet. Each vendor has=20 >>different definitions and some debate needs to happen so that the WG=20 >>can reach consensus on what exactly that means, and what kinds of=20 >>flexibility we want to retain within each class of architecture, and=20 >>what kind of differences we can to resolve and agree up front. That=20 >>should also be part of the work items for the new WG -- such agreement >>on the details for each architecture must be documented somewhere, if=20 >>not separately, then as part of the Protocol document. >> >>-----Original Message----- >>From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On=20 >>Behalf Of Burbank, Jack L. >>Sent: Thursday, August 05, 2004 12:14 PM >>To: 'Victor Lin '; 'Bob O'Hara '; 'capwap@frascone.com ' >>Subject: RE: [Capwap] So many architectures, so little time... - take=20 >>2 >> >>I think that interoperability between different architectures should=20 >>be a requirement, if not the key requirement. As was mentioned=20 >>yesterday, a goal of the IEEE is that they maintain flexibility in=20 >>terms of how products and architectures are implemented. I think we=20 >>shouldn't do anything that is contrary to that goal (or at least we=20 >>should minimize the impact). I think that the goal of CAPWAP should=20 >>be to retain this type of flexibility by designing a protocol that can >>maintain this implementation flexibility but enable interoperability=20 >>between the various architecture implementations (that after all is=20 >>the key problem with the deployment of these various architectures -=20 >>lack of interoperability). IMO, if we don't design for=20 >>interoperability between the basic architecture types, it is debatable >>if something useful would have been accomplished. >> >>Jack Burbank >> >>-----Original Message----- >>From: capwap-admin@frascone.com >>To: Bob O'Hara; capwap@frascone.com >>Sent: 8/5/2004 2:46 PM >>Subject: RE: [Capwap] So many architectures, so little time... - take=20 >>2 >> >>I agree that we can design a protocol and implement the product that=20 >>works all architectures. I think the question to CAPWAP is: >> >>Should we make it a requirement in CAPWAP protocol to achieve=20 >>interoperability between different architectures? >> >>It is definitely doable, but I'm not sure if that is the right thing=20 >>to do.. >> >>Victor >> >>-----Original Message----- >>From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On=20 >>Behalf Of Bob O'Hara >>Sent: Thursday, August 05, 2004 11:43 AM >>To: capwap@frascone.com >>Subject: RE: [Capwap] So many architectures, so little time... - take=20 >>2 >> >>I think that interoperability will depend on two things. >>First, it will >>depend on how we define the protocol and the flexibility for supported >>architectures it incorporates. Second, it will depend on what=20 >>manufacturers implement, i.e., the flexibility they build into their=20 >>products. >> >>I believe that it is possible to design the protocol for the required=20 >>flexibility. I know it is possible to implement a product with the=20 >>required flexibility. >> >> -Bob O'Hara >>=20 >> >>-----Original Message----- >>From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On=20 >>Behalf Of Abhijit Choudhury >>Sent: Thursday, August 05, 2004 11:32 AM >>To: James Kempf; Shehzad Merchant; capwap@frascone.com >>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com;=20 >>Dorothy.Gellert@nokia.com; Inderpreet Singh >>Subject: RE: [Capwap] So many architectures, so little time... - take=20 >>2 >> >> >>It may be possible to achieve such interoperability within the=20 >>split-MAC family or within the local-MAC family. It would sbe very=20 >>hard to achieve that between local and split MAC families. >> >>For example, if vendor X's WTP terminates 802.11 ctrl/mgmt packets and >=20 >=20 >>vendor Y's AC expects the 802.11 mgmt packets to come to it, there's=20 >>no way you can be interoperable. >> >>Or are we planning to specify ONE architecture ? >>The last thing IETF should do is mandate an implementation. >> >>I think a modest and reasonable goal is to come up with a protocol=20 >>that allows sufficient flexbility so that vendors with splitMAC=20 >>architectures can transfer most of the information they care about=20 >>between the WTP and AC. >> >>Just my $0.02 ... >> >> >>Abhijit Choudhury >> >> >>-----Original Message----- >>From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On=20 >>Behalf Of James Kempf >>Sent: Wednesday, August 04, 2004 3:29 PM >>To: Shehzad Merchant; capwap@frascone.com >>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com;=20 >>Dorothy.Gellert@nokia.com; Inderpreet Singh >>Subject: Re: [Capwap] So many architectures, so little time... - take=20 >>2 >> >> >>As a potential customer, let me put it concretely. I want to be able=20 >>to buy my access points from Vendor X and my switch from Vendor Y and=20 >>plug the two together and have them work without any configuration.=20 >>Also, I'd like to be able to buy switches from Vendor Y and Vendor Z=20 >>and be able to plug them into my network at various places and have=20 >>them interoperate. >> >> jak >> >> >>----- Original Message ----- >>From: "Shehzad Merchant" >>To: >>Cc: ; ;=20 >>; ; "Inderpreet=20 >>Singh" >> >>Sent: Wednesday, August 04, 2004 3:19 PM >>Subject: RE: [Capwap] So many architectures, so little time... - take=20 >>2 >> >> >> >>>I think the implementation variations even with the split MAC may=20 >>>cover a broad spectrum. As such its important to clearly articulate=20 >>>what aspects >> >>of >> >>>interoperability we are targetting. Is it truly just=20 >>>control/management or is it interoperability between disparate=20 >>>implementations of the split MAC, i.e. mix and match >> >>operation of WTP >> >>>and ACs of all variants within this category. >>> >>>I suspect for the latter we may have to arrive at some consensus on=20 >>>what particular implementations we are targeting >> >>interoperability for. >> >> >>>If so, ultimately this problem statement could become part of the=20 >>>charter. >>> >>>-Shehzad >>> >>> >>> >>>-----Original Message----- >>>From: capwap-admin@frascone.com >> >>[mailto:capwap-admin@frascone.com] On >>Behalf >> >>>Of Dorothy.Gellert@nokia.com >>>Sent: Wednesday, August 04, 2004 11:53 AM >>>To: isingh@chantrynetworks.com; capwap@frascone.com >>>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com >>>Subject: RE: [Capwap] So many architectures, so little >> >>time... - take >> >>>2 >>> >>>I believe this is the consensus, to scope the charter to >> >>Centralized >> >>>Architecture and LocalMAC and Split MAC. >>> >>>I'll update the charter with this change after the CAPWAP >> >>WG Mtg. If >> >>>there is resistance to this idea, please post to the list. >>> >>>Regards >>>Dorothy >>> >>> >>> >>>>-----Original Message----- >>>>From: capwap-admin@frascone.com >>> >>[mailto:capwap-admin@frascone.com]On >> >>>>Behalf Of ext Inderpreet Singh >>>>Sent: Tuesday, August 03, 2004 9:40 PM >>>>To: capwap@frascone.com >>>>Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David=20 >>>>(Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) >>>>Subject: RE: [Capwap] So many architectures, so little time... -=20 >>>>take 2 >>>> >>>> >>>>The issue(s) at hand and my opinions are: >>>> >>>>1. Do we explicitly state in the re-charter which >>> >>architecture the >> >>>>WG should consider? I think yes. I propose Centralized >>> >>architecture >> >> >>>>only. Autonomous and Distributed should be out of scope >>> >>based on the >> >> >>>>same reasons as per prior postings. >>>> >>>>2. Within Centralized do we focus on all three sub >>> >>architectures or >> >>>>a subset? Remote MAC should be excluded because if I am not=20 >>>>mistaken, the connectivity constraint between the WTP and >>> >>the AC is >> >>>>"direct connect". >>>>That being the case and that no IP layer is involved, it doesn't >>> >>seem >> >>>>clear what kind of protocol would help with interoperability. I am >>> >=20 >>>>concerned about the impact, dependencies and interaction with the=20 >>>>recently constituted IEEE Study group on AP >>> >>functionality on the >> >>>>Split MAC architectures. Furthermore, there are some >>> >>pretty drastic >> >>>>differences on how the vendors have chosen to split the >>> >>mac. Those >> >>>>differences will need to be worked out before designing a >>> >>protocol. >> >>>>So, if the low hanging fruit strategy (as James suggested) for=20 >>>>protocol development and progress is the way to go, then I think=20 >>>>prioritizing on a protocol for Local MAC is a no brainer. >>> >> So as far >> >>>>as focus, I feel we should do Local and Split and in that order. >>>> >>>>3. This is not a re-chartering issue but is a response to Pat's=20 >>>>suggestion that a protocol that just sends the 802.11 MAC frames=20 >>>>from the AP to the AC would work. I think possibly, yes. >>> >> But again >> >> >>>>the complications of splitting the MAC in an >>> >>interoperable way will >> >>>>be an issue. Also, you may note in the draft to which >>> >>you refer, we >> >> >>>>included a capabilities exchange phase. I had thought of >>> >>including >> >>>>in the capability exchange such things as "AP supports Local MAC" >>>>and "AP supports Split MAC", but didn't put it in because the=20 >>>>Taxonomy work was still in progress. Now that it is pretty much=20 >>>>done we could surely include that. But again...let's recharter=20 >>>>first. >>>> >>>>Thanks. Do people agree with 1 & 2? >>>> >>>>--- >>>>Inderpreet Singh >>>>Chantry Networks >>>>isingh@chantrynetworks.com >>>>Cell: 416-831-3705 >>>> >>>>-----Original Message----- >>>>From: capwap-admin@frascone.com >>> >>[mailto:capwap-admin@frascone.com] >> >>>>On Behalf Of Pat R. Calhoun >>>>Sent: Tuesday, August 03, 2004 6:04 PM >>>>To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com;=20 >>>>capwap@frascone.com >>>>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com >>>>Subject: [Capwap] So many architectures, so little >>> >>time... - take 2 >> >>>>After reading Lily's response to Jim, I realize that I >>> >>fell down the >> >> >>>>same trap. Local MAC is also a centralized approach, and so my=20 >>>>previous response was not complete. I believe the real >>> >>question, in >> >>>>my mind, is whether we need to address either the Local >>> >>or the Split >> >> >>>>MAC architecture. >>>> >>>>Just looking at the Architecture Consideration tables (7 and >>>>10) in the >>>>specification, the >>>>main difference (at a high level) between both approaches >>> >>is where >> >>>>the 802.11 management terminates. For Local MAC, it's in the WTP,=20 >>>>while for SPlit MAC, it's in the AC. >>>> >>>>However, looking at table 8, most Local MAC approaches share STA=20 >>>>state between both the WTP and the AC. So clearly there is some=20 >>>>signalling protocol between both the WTP and the AC. >>>> >>>>Looking at one example of a Local MAC protocol (see >>>> >>> > http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), >=20 >>>there is a protocol message >>>that corresponds for every 802.11 MAC management event. So when a STA >>>associates, the AP breaks the message apart and creates an new=20 >>>protocol PDU, which contains components found in the association=20 >>>request. I suspect that most Local MAC approaches do something very=20 >>>similar. >>> >>>So if a protocol simply tunnels the 802.11 MAC management frames from >>>the WTP to the AC, it allows supports both approaches. For Local MAC, >>>they get what they want via the 802.11 frame, and this also works=20 >>>fine for Split MAC, which needs access to the MAC management frame.=20 >>>What would be required in such a protocol is a way for the AP to=20 >>>communicate whether it will be providing very specific functions -=20 >>>basically a capabilities negotiation approach. >>> >>>So I do believe that there is a way to address both architectures=20 >>>using a single protocol. >>> >>>Thoughts? >>> >>>PatC >>> >>>_______________________________________________ >>>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 >=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 > _______________________________________________ > 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 -- Shankar Narayanaswamy, Ph.D. wireless@shankar.org Mobile: +1 650-387-4593 http://www.shankar.org E-Fax: +1 253-498-8372 _______________________________________________ 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 Aug 10 15:37:56 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24503 for ; Tue, 10 Aug 2004 15:37:55 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1A2351FCC0; Tue, 10 Aug 2004 15:23:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B05142046E; Tue, 10 Aug 2004 15:23:05 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1366E2046E for ; Tue, 10 Aug 2004 15:22:49 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.frascone.com (Postfix) with ESMTP id 1BF751FCC0 for ; Tue, 10 Aug 2004 15:22:47 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24476; Tue, 10 Aug 2004 15:37:30 -0400 (EDT) Message-Id: <200408101937.PAA24476@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: capwap@frascone.com From: Internet-Drafts@ietf.org X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] I-D ACTION:draft-ietf-capwap-arch-04.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: Tue, 10 Aug 2004 15:37:30 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Control And Provisioning of Wireless Access Points Working Group of the IETF. Title : Architecture Taxonomy for Control and Provisioning of Wireless Access Points(CAPWAP) Author(s) : L. Yang, et al. Filename : draft-ietf-capwap-arch-04.txt Pages : 42 Date : 2004-8-10 This document provides a taxonomy of the architectures employed in the existing IEEE 802.11 products in the market, by analyzing WLAN (Wireless LAN) functions and services and describing the different variants in distributing these functions and services among the architectural entities. This taxonomy may be utilized by the IEEE 802.11 Working Group as input to their task of defining the Access Point (AP) functional architecture. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-capwap-arch-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-capwap-arch-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-capwap-arch-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-8-10160342.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-capwap-arch-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-capwap-arch-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-10160342.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Aug 10 21:24:00 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22193 for ; Tue, 10 Aug 2004 21:23:58 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 996501FE71; Tue, 10 Aug 2004 21:09:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BFDE12050B; Tue, 10 Aug 2004 21:09:05 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DFE9720E06 for ; Tue, 10 Aug 2004 21:08:23 -0400 (EDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by mail.frascone.com (Postfix) with ESMTP id BAEC01FE71 for ; Tue, 10 Aug 2004 21:08:21 -0400 (EDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i7B1Lxeo008932; Wed, 11 Aug 2004 01:22:01 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i7B1NkOi021697; Wed, 11 Aug 2004 01:24:41 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004081018222112265 ; Tue, 10 Aug 2004 18:22:21 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 10 Aug 2004 18:22:20 -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] So many architectures, so little time... - take 2 Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE01C79F86@orsmsx408> Thread-Topic: [Capwap] So many architectures, so little time... - take 2 Thread-Index: AcR/Bmj8yt99Q2VUTPyN1QkjwC5gbAAA9dfQAA1oxBA= From: "Yang, Lily L" To: "Sudhanshu Jain" , "Shehzad Merchant" , "Shankar Narayanaswamy" , "Abhijit Choudhury" Cc: X-OriginalArrivalTime: 11 Aug 2004 01:22:20.0766 (UTC) FILETIME=[A5FD4FE0:01C47F41] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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, 10 Aug 2004 18:12:36 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable The question in my mind is: Can data plane and control plane be cleanly separated for Split MAC? I know it is feasible for Local MAC, but not sure about Split MAC.=20 Any insight? -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sudhanshu Jain Sent: Tuesday, August 10, 2004 11:55 AM To: Shehzad Merchant; Shankar Narayanaswamy; Abhijit Choudhury Cc: capwap@frascone.com Subject: RE: [Capwap] So many architectures, so little time... - take 2 I fully agree with Shehzad. We need to separate the control and data plane. Control plane should provide the framework to use one of several tunneling protocol.=20 On data plane, if we need to define a new layer2/layer3 level tunneling protocol, it should be separate work from control protocol work.=20 -Suds -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Shehzad Merchant Sent: Tuesday, August 10, 2004 11:13 AM To: Shankar Narayanaswamy; Abhijit Choudhury Cc: capwap@frascone.com Subject: RE: [Capwap] So many architectures, so little time... - take 2 Additionally, for data tunneling one needs a lightweight mechanism that may not necessarily have the same requirements as that for control and management. For example, one would want to limit the tunneling and processing overhead on data packets to a minimum. Control and management may be more tolerant of tunneling/security/etc. overhead. Besides, there are plenty of standards in place for data tunneling. We may potentially be able to leverage off that work itself without having to invent yet another tunneling mechanism for data.=20 -S -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Shankar Narayanaswamy Sent: Tuesday, August 10, 2004 10:30 AM To: Abhijit Choudhury Cc: capwap@frascone.com Subject: Re: [Capwap] So many architectures, so little time... - take 2 On the first point: not necessarily. If data packets are encapsulated 802.11 data frames, then there is no need to protect them on the wire any more than they were encrypted over the air. But control and management packets will need protection over the wired network and therefore possibly a different tunneling protocol. On the second point (standard way of packet exchange): yes! -s Abhijit Choudhury wrote: > The same tunneling protocol that moves control and management packets=20 > from the WTP to the AC should be used to tunnel data packets as well. > We would specify message exchanges to do control, provisioning and=20 > capability advertisement between WTPs and the AC. But all of this=20 > would be within the unified CAPWAP protocol that moves all packets=20 > including data between the WTP and AC. Vendors currently use LWAPP,=20 > GRE, IP and some proprietary encapsulations to achieve this. This=20 > group would come up with a "standard" way of doing this exchange. >=20 > At least that was my understanding.... >=20 > Regards, > Abhijit >=20 > -----Original Mssage----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On=20 > Behalf Of Wijnen, Bert (Bert) > Sent: Monday, August 09, 2004 6:14 AM > To: 'Yang, Lily L'; Burbank, Jack L.; Victor Lin; Bob O'Hara;=20 > capwap@frascone.com > Subject: RE: [Capwap] So many architectures, so little time... - take=20 > 2 >=20 >=20 > Not sure who is confused... probably me... >=20 > My understanding was/is that IF we do re-charter for CAPWAP protocol=20 > work, that it is then a NM protocol for "Control and Provisioning" and > not any of the related stuff that moves the data from WTP to AC. >=20 > Is everybody in agreement with that understanding. >=20 > Thanks, > Bert >=20 >=20 >>-----Original Message----- >>From: Yang, Lily L [mailto:lily.l.yang@intel.com] >>Sent: maandag 9 augustus 2004 08:14 >>To: Burbank, Jack L.; Victor Lin ; Bob O'Hara ; capwap@frascone.com >>Subject: RE: [Capwap] So many architectures, so little time... - take=20 >>2 >> >> >>I think setting the re-charter scope to develop a single protocol that >=20 >=20 >>allows interoperability between Local and Split MAC is a reasonable >>tradeoff: >>We exclude remote MAC because the constraint it imposes is very=20 >>different from the rest and the benefit of including it is very=20 >>little. But Local and Split MAC are reasonably close and hence the=20 >>effort may be incremental only. >>As many people noted, as of today, there is no single clear definition >>of what "Local MAC" and "Split MAC" really means yet. Each vendor has=20 >>different definitions and some debate needs to happen so that the WG=20 >>can reach consensus on what exactly that means, and what kinds of=20 >>flexibility we want to retain within each class of architecture, and=20 >>what kind of differences we can to resolve and agree up front. That=20 >>should also be part of the work items for the new WG -- such agreement >>on the details for each architecture must be documented somewhere, if=20 >>not separately, then as part of the Protocol document. >> >>-----Original Message----- >>From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On=20 >>Behalf Of Burbank, Jack L. >>Sent: Thursday, August 05, 2004 12:14 PM >>To: 'Victor Lin '; 'Bob O'Hara '; 'capwap@frascone.com ' >>Subject: RE: [Capwap] So many architectures, so little time... - take=20 >>2 >> >>I think that interoperability between different architectures should=20 >>be a requirement, if not the key requirement. As was mentioned=20 >>yesterday, a goal of the IEEE is that they maintain flexibility in=20 >>terms of how products and architectures are implemented. I think we=20 >>shouldn't do anything that is contrary to that goal (or at least we=20 >>should minimize the impact). I think that the goal of CAPWAP should=20 >>be to retain this type of flexibility by designing a protocol that can >>maintain this implementation flexibility but enable interoperability=20 >>between the various architecture implementations (that after all is=20 >>the key problem with the deployment of these various architectures -=20 >>lack of interoperability). IMO, if we don't design for=20 >>interoperability between the basic architecture types, it is debatable >>if something useful would have been accomplished. >> >>Jack Burbank >> >>-----Original Message----- >>From: capwap-admin@frascone.com >>To: Bob O'Hara; capwap@frascone.com >>Sent: 8/5/2004 2:46 PM >>Subject: RE: [Capwap] So many architectures, so little time... - take=20 >>2 >> >>I agree that we can design a protocol and implement the product that=20 >>works all architectures. I think the question to CAPWAP is: >> >>Should we make it a requirement in CAPWAP protocol to achieve=20 >>interoperability between different architectures? >> >>It is definitely doable, but I'm not sure if that is the right thing=20 >>to do.. >> >>Victor >> >>-----Original Message----- >>From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On=20 >>Behalf Of Bob O'Hara >>Sent: Thursday, August 05, 2004 11:43 AM >>To: capwap@frascone.com >>Subject: RE: [Capwap] So many architectures, so little time... - take=20 >>2 >> >>I think that interoperability will depend on two things. >>First, it will >>depend on how we define the protocol and the flexibility for supported >>architectures it incorporates. Second, it will depend on what=20 >>manufacturers implement, i.e., the flexibility they build into their=20 >>products. >> >>I believe that it is possible to design the protocol for the required=20 >>flexibility. I know it is possible to implement a product with the=20 >>required flexibility. >> >> -Bob O'Hara >>=20 >> >>-----Original Message----- >>From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On=20 >>Behalf Of Abhijit Choudhury >>Sent: Thursday, August 05, 2004 11:32 AM >>To: James Kempf; Shehzad Merchant; capwap@frascone.com >>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com;=20 >>Dorothy.Gellert@nokia.com; Inderpreet Singh >>Subject: RE: [Capwap] So many architectures, so little time... - take=20 >>2 >> >> >>It may be possible to achieve such interoperability within the=20 >>split-MAC family or within the local-MAC family. It would sbe very=20 >>hard to achieve that between local and split MAC families. >> >>For example, if vendor X's WTP terminates 802.11 ctrl/mgmt packets and >=20 >=20 >>vendor Y's AC expects the 802.11 mgmt packets to come to it, there's=20 >>no way you can be interoperable. >> >>Or are we planning to specify ONE architecture ? >>The last thing IETF should do is mandate an implementation. >> >>I think a modest and reasonable goal is to come up with a protocol=20 >>that allows sufficient flexbility so that vendors with splitMAC=20 >>architectures can transfer most of the information they care about=20 >>between the WTP and AC. >> >>Just my $0.02 ... >> >> >>Abhijit Choudhury >> >> >>-----Original Message----- >>From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On=20 >>Behalf Of James Kempf >>Sent: Wednesday, August 04, 2004 3:29 PM >>To: Shehzad Merchant; capwap@frascone.com >>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com;=20 >>Dorothy.Gellert@nokia.com; Inderpreet Singh >>Subject: Re: [Capwap] So many architectures, so little time... - take=20 >>2 >> >> >>As a potential customer, let me put it concretely. I want to be able=20 >>to buy my access points from Vendor X and my switch from Vendor Y and=20 >>plug the two together and have them work without any configuration.=20 >>Also, I'd like to be able to buy switches from Vendor Y and Vendor Z=20 >>and be able to plug them into my network at various places and have=20 >>them interoperate. >> >> jak >> >> >>----- Original Message ----- >>From: "Shehzad Merchant" >>To: >>Cc: ; ;=20 >>; ; "Inderpreet=20 >>Singh" >> >>Sent: Wednesday, August 04, 2004 3:19 PM >>Subject: RE: [Capwap] So many architectures, so little time... - take=20 >>2 >> >> >> >>>I think the implementation variations even with the split MAC may=20 >>>cover a broad spectrum. As such its important to clearly articulate=20 >>>what aspects >> >>of >> >>>interoperability we are targetting. Is it truly just=20 >>>control/management or is it interoperability between disparate=20 >>>implementations of the split MAC, i.e. mix and match >> >>operation of WTP >> >>>and ACs of all variants within this category. >>> >>>I suspect for the latter we may have to arrive at some consensus on=20 >>>what particular implementations we are targeting >> >>interoperability for. >> >> >>>If so, ultimately this problem statement could become part of the=20 >>>charter. >>> >>>-Shehzad >>> >>> >>> >>>-----Original Message----- >>>From: capwap-admin@frascone.com >> >>[mailto:capwap-admin@frascone.com] On >>Behalf >> >>>Of Dorothy.Gellert@nokia.com >>>Sent: Wednesday, August 04, 2004 11:53 AM >>>To: isingh@chantrynetworks.com; capwap@frascone.com >>>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com >>>Subject: RE: [Capwap] So many architectures, so little >> >>time... - take >> >>>2 >>> >>>I believe this is the consensus, to scope the charter to >> >>Centralized >> >>>Architecture and LocalMAC and Split MAC. >>> >>>I'll update the charter with this change after the CAPWAP >> >>WG Mtg. If >> >>>there is resistance to this idea, please post to the list. >>> >>>Regards >>>Dorothy >>> >>> >>> >>>>-----Original Message----- >>>>From: capwap-admin@frascone.com >>> >>[mailto:capwap-admin@frascone.com]On >> >>>>Behalf Of ext Inderpreet Singh >>>>Sent: Tuesday, August 03, 2004 9:40 PM >>>>To: capwap@frascone.com >>>>Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David=20 >>>>(Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) >>>>Subject: RE: [Capwap] So many architectures, so little time... -=20 >>>>take 2 >>>> >>>> >>>>The issue(s) at hand and my opinions are: >>>> >>>>1. Do we explicitly state in the re-charter which >>> >>architecture the >> >>>>WG should consider? I think yes. I propose Centralized >>> >>architecture >> >> >>>>only. Autonomous and Distributed should be out of scope >>> >>based on the >> >> >>>>same reasons as per prior postings. >>>> >>>>2. Within Centralized do we focus on all three sub >>> >>architectures or >> >>>>a subset? Remote MAC should be excluded because if I am not=20 >>>>mistaken, the connectivity constraint between the WTP and >>> >>the AC is >> >>>>"direct connect". >>>>That being the case and that no IP layer is involved, it doesn't >>> >>seem >> >>>>clear what kind of protocol would help with interoperability. I am >>> >=20 >>>>concerned about the impact, dependencies and interaction with the=20 >>>>recently constituted IEEE Study group on AP >>> >>functionality on the >> >>>>Split MAC architectures. Furthermore, there are some >>> >>pretty drastic >> >>>>differences on how the vendors have chosen to split the >>> >>mac. Those >> >>>>differences will need to be worked out before designing a >>> >>protocol. >> >>>>So, if the low hanging fruit strategy (as James suggested) for=20 >>>>protocol development and progress is the way to go, then I think=20 >>>>prioritizing on a protocol for Local MAC is a no brainer. >>> >> So as far >> >>>>as focus, I feel we should do Local and Split and in that order. >>>> >>>>3. This is not a re-chartering issue but is a response to Pat's=20 >>>>suggestion that a protocol that just sends the 802.11 MAC frames=20 >>>>from the AP to the AC would work. I think possibly, yes. >>> >> But again >> >> >>>>the complications of splitting the MAC in an >>> >>interoperable way will >> >>>>be an issue. Also, you may note in the draft to which >>> >>you refer, we >> >> >>>>included a capabilities exchange phase. I had thought of >>> >>including >> >>>>in the capability exchange such things as "AP supports Local MAC" >>>>and "AP supports Split MAC", but didn't put it in because the=20 >>>>Taxonomy work was still in progress. Now that it is pretty much=20 >>>>done we could surely include that. But again...let's recharter=20 >>>>first. >>>> >>>>Thanks. Do people agree with 1 & 2? >>>> >>>>--- >>>>Inderpreet Singh >>>>Chantry Networks >>>>isingh@chantrynetworks.com >>>>Cell: 416-831-3705 >>>> >>>>-----Original Message----- >>>>From: capwap-admin@frascone.com >>> >>[mailto:capwap-admin@frascone.com] >> >>>>On Behalf Of Pat R. Calhoun >>>>Sent: Tuesday, August 03, 2004 6:04 PM >>>>To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com;=20 >>>>capwap@frascone.com >>>>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com >>>>Subject: [Capwap] So many architectures, so little >>> >>time... - take 2 >> >>>>After reading Lily's response to Jim, I realize that I >>> >>fell down the >> >> >>>>same trap. Local MAC is also a centralized approach, and so my=20 >>>>previous response was not complete. I believe the real >>> >>question, in >> >>>>my mind, is whether we need to address either the Local >>> >>or the Split >> >> >>>>MAC architecture. >>>> >>>>Just looking at the Architecture Consideration tables (7 and >>>>10) in the >>>>specification, the >>>>main difference (at a high level) between both approaches >>> >>is where >> >>>>the 802.11 management terminates. For Local MAC, it's in the WTP,=20 >>>>while for SPlit MAC, it's in the AC. >>>> >>>>However, looking at table 8, most Local MAC approaches share STA=20 >>>>state between both the WTP and the AC. So clearly there is some=20 >>>>signalling protocol between both the WTP and the AC. >>>> >>>>Looking at one example of a Local MAC protocol (see >>>> >>> > http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), >=20 >>>there is a protocol message >>>that corresponds for every 802.11 MAC management event. So when a STA >>>associates, the AP breaks the message apart and creates an new=20 >>>protocol PDU, which contains components found in the association=20 >>>request. I suspect that most Local MAC approaches do something very=20 >>>similar. >>> >>>So if a protocol simply tunnels the 802.11 MAC management frames from >>>the WTP to the AC, it allows supports both approaches. For Local MAC, >>>they get what they want via the 802.11 frame, and this also works=20 >>>fine for Split MAC, which needs access to the MAC management frame.=20 >>>What would be required in such a protocol is a way for the AP to=20 >>>communicate whether it will be providing very specific functions -=20 >>>basically a capabilities negotiation approach. >>> >>>So I do believe that there is a way to address both architectures=20 >>>using a single protocol. >>> >>>Thoughts? >>> >>>PatC >>> >>>_______________________________________________ >>>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 >=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 > _______________________________________________ > 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 -- Shankar Narayanaswamy, Ph.D. wireless@shankar.org Mobile: +1 650-387-4593 http://www.shankar.org E-Fax: +1 253-498-8372 _______________________________________________ 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 Aug 10 22:00:59 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24250 for ; Tue, 10 Aug 2004 22:00:57 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 029A621943; Tue, 10 Aug 2004 21:46:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7E65D2193C; Tue, 10 Aug 2004 21:46:06 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CF4C12193C for ; Tue, 10 Aug 2004 21:45:02 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id 4A9071FE73 for ; Tue, 10 Aug 2004 21:45:00 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7B1xfj28803; Wed, 11 Aug 2004 04:59:41 +0300 (EET DST) X-Scanned: Wed, 11 Aug 2004 04:59:30 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i7B1xUL0006908; Wed, 11 Aug 2004 04:59:30 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00DFjgHj; Wed, 11 Aug 2004 04:59:27 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7B1xPu04927; Wed, 11 Aug 2004 04:59:25 +0300 (EET DST) Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 10 Aug 2004 20:59:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: Thread-Topic: [Capwap] So many architectures, so little time... - take 2 Thread-Index: AcR/Bmj8yt99Q2VUTPyN1QkjwC5gbAAA9dfQAA1oxBAAAUEzkA== From: To: , , , , Cc: X-OriginalArrivalTime: 11 Aug 2004 01:59:24.0893 (UTC) FILETIME=[D3AC28D0:01C47F46] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Data plane and control plane separation in Split MAC 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, 10 Aug 2004 18:59:23 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Good point. Can we have the volunteers that submitted architectures for = the taxonomy draft weigh in on this issue? =20 Also another point to consider is that we don't have to implement = *every* AP function in the first release of the CAPWAP protocol. One of = our charter goals is to start with the minimal set of functionality = needed to provide control. We have a "desirable" category where we can = put objectives that can be met with a later release or extension. Dorothy > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > Behalf Of ext Yang, Lily L > Sent: Tuesday, August 10, 2004 6:13 PM > To: Sudhanshu Jain; Shehzad Merchant; Shankar Narayanaswamy; Abhijit > Choudhury > Cc: capwap@frascone.com > Subject: RE: [Capwap] So many architectures, so little=20 > time... - take 2 >=20 >=20 > The question in my mind is: Can data plane and control plane=20 > be cleanly > separated for Split MAC? I know it is feasible for Local MAC, but not > sure about Split MAC.=20 > Any insight? >=20 > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Sudhanshu Jain > Sent: Tuesday, August 10, 2004 11:55 AM > To: Shehzad Merchant; Shankar Narayanaswamy; Abhijit Choudhury > Cc: capwap@frascone.com > Subject: RE: [Capwap] So many architectures, so little=20 > time... - take 2 >=20 > I fully agree with Shehzad. We need to separate the control and data > plane. Control plane should provide the framework to use one=20 > of several > tunneling protocol.=20 >=20 > On data plane, if we need to define a new layer2/layer3 level=20 > tunneling > protocol, it should be separate work from control protocol work.=20 >=20 > -Suds >=20 >=20 > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Shehzad Merchant > Sent: Tuesday, August 10, 2004 11:13 AM > To: Shankar Narayanaswamy; Abhijit Choudhury > Cc: capwap@frascone.com > Subject: RE: [Capwap] So many architectures, so little=20 > time... - take 2 >=20 > Additionally, for data tunneling one needs a lightweight=20 > mechanism that > may > not necessarily have the same requirements as that for control and > management. For example, one would want to limit the tunneling and > processing overhead on data packets to a minimum. Control and=20 > management > may > be more tolerant of tunneling/security/etc. overhead.=20 > Besides, there are > plenty of standards in place for data tunneling. We may potentially be > able > to leverage off that work itself without having to invent yet another > tunneling mechanism for data.=20 >=20 > -S >=20 >=20 > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf > Of Shankar Narayanaswamy > Sent: Tuesday, August 10, 2004 10:30 AM > To: Abhijit Choudhury > Cc: capwap@frascone.com > Subject: Re: [Capwap] So many architectures, so little=20 > time... - take 2 >=20 > On the first point: not necessarily. If data packets are encapsulated > 802.11 data frames, then there is no need to protect them on the wire > any > more than they were encrypted over the air. >=20 > But control and management packets will need protection over the wired > network and therefore possibly a different tunneling protocol. >=20 > On the second point (standard way of packet exchange): yes! >=20 > -s >=20 > Abhijit Choudhury wrote: > > The same tunneling protocol that moves control and=20 > management packets=20 > > from the WTP to the AC should be used to tunnel data=20 > packets as well. >=20 > > We would specify message exchanges to do control, provisioning and=20 > > capability advertisement between WTPs and the AC. But all of this=20 > > would be within the unified CAPWAP protocol that moves all packets=20 > > including data between the WTP and AC. Vendors currently=20 > use LWAPP,=20 > > GRE, IP and some proprietary encapsulations to achieve this. This=20 > > group would come up with a "standard" way of doing this exchange. > >=20 > > At least that was my understanding.... > >=20 > > Regards, > > Abhijit > >=20 > > -----Original Mssage----- > > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On=20 > > Behalf Of Wijnen, Bert (Bert) > > Sent: Monday, August 09, 2004 6:14 AM > > To: 'Yang, Lily L'; Burbank, Jack L.; Victor Lin; Bob O'Hara;=20 > > capwap@frascone.com > > Subject: RE: [Capwap] So many architectures, so little=20 > time... - take=20 > > 2 > >=20 > >=20 > > Not sure who is confused... probably me... > >=20 > > My understanding was/is that IF we do re-charter for CAPWAP=20 > protocol=20 > > work, that it is then a NM protocol for "Control and=20 > Provisioning" and >=20 > > not any of the related stuff that moves the data from WTP to AC. > >=20 > > Is everybody in agreement with that understanding. > >=20 > > Thanks, > > Bert > >=20 > >=20 > >>-----Original Message----- > >>From: Yang, Lily L [mailto:lily.l.yang@intel.com] > >>Sent: maandag 9 augustus 2004 08:14 > >>To: Burbank, Jack L.; Victor Lin ; Bob O'Hara ; capwap@frascone.com > >>Subject: RE: [Capwap] So many architectures, so little=20 > time... - take=20 > >>2 > >> > >> > >>I think setting the re-charter scope to develop a single=20 > protocol that > >=20 > >=20 > >>allows interoperability between Local and Split MAC is a reasonable > >>tradeoff: > >>We exclude remote MAC because the constraint it imposes is very=20 > >>different from the rest and the benefit of including it is very=20 > >>little. But Local and Split MAC are reasonably close and hence the=20 > >>effort may be incremental only. > >>As many people noted, as of today, there is no single clear=20 > definition >=20 > >>of what "Local MAC" and "Split MAC" really means yet. Each=20 > vendor has=20 > >>different definitions and some debate needs to happen so=20 > that the WG=20 > >>can reach consensus on what exactly that means, and what kinds of=20 > >>flexibility we want to retain within each class of=20 > architecture, and=20 > >>what kind of differences we can to resolve and agree up front. That=20 > >>should also be part of the work items for the new WG --=20 > such agreement >=20 > >>on the details for each architecture must be documented=20 > somewhere, if=20 > >>not separately, then as part of the Protocol document. > >> > >>-----Original Message----- > >>From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On=20 > >>Behalf Of Burbank, Jack L. > >>Sent: Thursday, August 05, 2004 12:14 PM > >>To: 'Victor Lin '; 'Bob O'Hara '; 'capwap@frascone.com ' > >>Subject: RE: [Capwap] So many architectures, so little=20 > time... - take=20 > >>2 > >> > >>I think that interoperability between different=20 > architectures should=20 > >>be a requirement, if not the key requirement. As was mentioned=20 > >>yesterday, a goal of the IEEE is that they maintain flexibility in=20 > >>terms of how products and architectures are implemented. I=20 > think we=20 > >>shouldn't do anything that is contrary to that goal (or at least we=20 > >>should minimize the impact). I think that the goal of=20 > CAPWAP should=20 > >>be to retain this type of flexibility by designing a=20 > protocol that can >=20 > >>maintain this implementation flexibility but enable=20 > interoperability=20 > >>between the various architecture implementations (that after all is=20 > >>the key problem with the deployment of these various=20 > architectures -=20 > >>lack of interoperability). IMO, if we don't design for=20 > >>interoperability between the basic architecture types, it=20 > is debatable >=20 > >>if something useful would have been accomplished. > >> > >>Jack Burbank > >> > >>-----Original Message----- > >>From: capwap-admin@frascone.com > >>To: Bob O'Hara; capwap@frascone.com > >>Sent: 8/5/2004 2:46 PM > >>Subject: RE: [Capwap] So many architectures, so little=20 > time... - take=20 > >>2 > >> > >>I agree that we can design a protocol and implement the=20 > product that=20 > >>works all architectures. I think the question to CAPWAP is: > >> > >>Should we make it a requirement in CAPWAP protocol to achieve=20 > >>interoperability between different architectures? > >> > >>It is definitely doable, but I'm not sure if that is the=20 > right thing=20 > >>to do.. > >> > >>Victor > >> > >>-----Original Message----- > >>From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On=20 > >>Behalf Of Bob O'Hara > >>Sent: Thursday, August 05, 2004 11:43 AM > >>To: capwap@frascone.com > >>Subject: RE: [Capwap] So many architectures, so little=20 > time... - take=20 > >>2 > >> > >>I think that interoperability will depend on two things. > >>First, it will > >>depend on how we define the protocol and the flexibility=20 > for supported >=20 > >>architectures it incorporates. Second, it will depend on what=20 > >>manufacturers implement, i.e., the flexibility they build=20 > into their=20 > >>products. > >> > >>I believe that it is possible to design the protocol for=20 > the required=20 > >>flexibility. I know it is possible to implement a product with the=20 > >>required flexibility. > >> > >> -Bob O'Hara > >>=20 > >> > >>-----Original Message----- > >>From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On=20 > >>Behalf Of Abhijit Choudhury > >>Sent: Thursday, August 05, 2004 11:32 AM > >>To: James Kempf; Shehzad Merchant; capwap@frascone.com > >>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com;=20 > >>Dorothy.Gellert@nokia.com; Inderpreet Singh > >>Subject: RE: [Capwap] So many architectures, so little=20 > time... - take=20 > >>2 > >> > >> > >>It may be possible to achieve such interoperability within the=20 > >>split-MAC family or within the local-MAC family. It would sbe very=20 > >>hard to achieve that between local and split MAC families. > >> > >>For example, if vendor X's WTP terminates 802.11 ctrl/mgmt=20 > packets and > >=20 > >=20 > >>vendor Y's AC expects the 802.11 mgmt packets to come to=20 > it, there's=20 > >>no way you can be interoperable. > >> > >>Or are we planning to specify ONE architecture ? > >>The last thing IETF should do is mandate an implementation. > >> > >>I think a modest and reasonable goal is to come up with a protocol=20 > >>that allows sufficient flexbility so that vendors with splitMAC=20 > >>architectures can transfer most of the information they care about=20 > >>between the WTP and AC. > >> > >>Just my $0.02 ... > >> > >> > >>Abhijit Choudhury > >> > >> > >>-----Original Message----- > >>From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On=20 > >>Behalf Of James Kempf > >>Sent: Wednesday, August 04, 2004 3:29 PM > >>To: Shehzad Merchant; capwap@frascone.com > >>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com;=20 > >>Dorothy.Gellert@nokia.com; Inderpreet Singh > >>Subject: Re: [Capwap] So many architectures, so little=20 > time... - take=20 > >>2 > >> > >> > >>As a potential customer, let me put it concretely. I want=20 > to be able=20 > >>to buy my access points from Vendor X and my switch from=20 > Vendor Y and=20 > >>plug the two together and have them work without any configuration.=20 > >>Also, I'd like to be able to buy switches from Vendor Y and=20 > Vendor Z=20 > >>and be able to plug them into my network at various places and have=20 > >>them interoperate. > >> > >> jak > >> > >> > >>----- Original Message ----- > >>From: "Shehzad Merchant" > >>To: > >>Cc: ; ;=20 > >>; ; "Inderpreet=20 > >>Singh" > >> > >>Sent: Wednesday, August 04, 2004 3:19 PM > >>Subject: RE: [Capwap] So many architectures, so little=20 > time... - take=20 > >>2 > >> > >> > >> > >>>I think the implementation variations even with the split MAC may=20 > >>>cover a broad spectrum. As such its important to clearly=20 > articulate=20 > >>>what aspects > >> > >>of > >> > >>>interoperability we are targetting. Is it truly just=20 > >>>control/management or is it interoperability between disparate=20 > >>>implementations of the split MAC, i.e. mix and match > >> > >>operation of WTP > >> > >>>and ACs of all variants within this category. > >>> > >>>I suspect for the latter we may have to arrive at some=20 > consensus on=20 > >>>what particular implementations we are targeting > >> > >>interoperability for. > >> > >> > >>>If so, ultimately this problem statement could become part of the=20 > >>>charter. > >>> > >>>-Shehzad > >>> > >>> > >>> > >>>-----Original Message----- > >>>From: capwap-admin@frascone.com > >> > >>[mailto:capwap-admin@frascone.com] On > >>Behalf > >> > >>>Of Dorothy.Gellert@nokia.com > >>>Sent: Wednesday, August 04, 2004 11:53 AM > >>>To: isingh@chantrynetworks.com; capwap@frascone.com > >>>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > >>>Subject: RE: [Capwap] So many architectures, so little > >> > >>time... - take > >> > >>>2 > >>> > >>>I believe this is the consensus, to scope the charter to > >> > >>Centralized > >> > >>>Architecture and LocalMAC and Split MAC. > >>> > >>>I'll update the charter with this change after the CAPWAP > >> > >>WG Mtg. If > >> > >>>there is resistance to this idea, please post to the list. > >>> > >>>Regards > >>>Dorothy > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: capwap-admin@frascone.com > >>> > >>[mailto:capwap-admin@frascone.com]On > >> > >>>>Behalf Of ext Inderpreet Singh > >>>>Sent: Tuesday, August 03, 2004 9:40 PM > >>>>To: capwap@frascone.com > >>>>Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David=20 > >>>>(Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > >>>>Subject: RE: [Capwap] So many architectures, so little time... -=20 > >>>>take 2 > >>>> > >>>> > >>>>The issue(s) at hand and my opinions are: > >>>> > >>>>1. Do we explicitly state in the re-charter which > >>> > >>architecture the > >> > >>>>WG should consider? I think yes. I propose Centralized > >>> > >>architecture > >> > >> > >>>>only. Autonomous and Distributed should be out of scope > >>> > >>based on the > >> > >> > >>>>same reasons as per prior postings. > >>>> > >>>>2. Within Centralized do we focus on all three sub > >>> > >>architectures or > >> > >>>>a subset? Remote MAC should be excluded because if I am not=20 > >>>>mistaken, the connectivity constraint between the WTP and > >>> > >>the AC is > >> > >>>>"direct connect". > >>>>That being the case and that no IP layer is involved, it doesn't > >>> > >>seem > >> > >>>>clear what kind of protocol would help with interoperability. I am > >>> > >=20 > >>>>concerned about the impact, dependencies and interaction with the=20 > >>>>recently constituted IEEE Study group on AP > >>> > >>functionality on the > >> > >>>>Split MAC architectures. Furthermore, there are some > >>> > >>pretty drastic > >> > >>>>differences on how the vendors have chosen to split the > >>> > >>mac. Those > >> > >>>>differences will need to be worked out before designing a > >>> > >>protocol. > >> > >>>>So, if the low hanging fruit strategy (as James suggested) for=20 > >>>>protocol development and progress is the way to go, then I think=20 > >>>>prioritizing on a protocol for Local MAC is a no brainer. > >>> > >> So as far > >> > >>>>as focus, I feel we should do Local and Split and in that order. > >>>> > >>>>3. This is not a re-chartering issue but is a response to Pat's=20 > >>>>suggestion that a protocol that just sends the 802.11 MAC frames=20 > >>>>from the AP to the AC would work. I think possibly, yes. > >>> > >> But again > >> > >> > >>>>the complications of splitting the MAC in an > >>> > >>interoperable way will > >> > >>>>be an issue. Also, you may note in the draft to which > >>> > >>you refer, we > >> > >> > >>>>included a capabilities exchange phase. I had thought of > >>> > >>including > >> > >>>>in the capability exchange such things as "AP supports Local MAC" > >>>>and "AP supports Split MAC", but didn't put it in because the=20 > >>>>Taxonomy work was still in progress. Now that it is pretty much=20 > >>>>done we could surely include that. But again...let's recharter=20 > >>>>first. > >>>> > >>>>Thanks. Do people agree with 1 & 2? > >>>> > >>>>--- > >>>>Inderpreet Singh > >>>>Chantry Networks > >>>>isingh@chantrynetworks.com > >>>>Cell: 416-831-3705 > >>>> > >>>>-----Original Message----- > >>>>From: capwap-admin@frascone.com > >>> > >>[mailto:capwap-admin@frascone.com] > >> > >>>>On Behalf Of Pat R. Calhoun > >>>>Sent: Tuesday, August 03, 2004 6:04 PM > >>>>To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com;=20 > >>>>capwap@frascone.com > >>>>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > >>>>Subject: [Capwap] So many architectures, so little > >>> > >>time... - take 2 > >> > >>>>After reading Lily's response to Jim, I realize that I > >>> > >>fell down the > >> > >> > >>>>same trap. Local MAC is also a centralized approach, and so my=20 > >>>>previous response was not complete. I believe the real > >>> > >>question, in > >> > >>>>my mind, is whether we need to address either the Local > >>> > >>or the Split > >> > >> > >>>>MAC architecture. > >>>> > >>>>Just looking at the Architecture Consideration tables (7 and > >>>>10) in the > >>>>specification, the > >>>>main difference (at a high level) between both approaches > >>> > >>is where > >> > >>>>the 802.11 management terminates. For Local MAC, it's in the WTP,=20 > >>>>while for SPlit MAC, it's in the AC. > >>>> > >>>>However, looking at table 8, most Local MAC approaches share STA=20 > >>>>state between both the WTP and the AC. So clearly there is some=20 > >>>>signalling protocol between both the WTP and the AC. > >>>> > >>>>Looking at one example of a Local MAC protocol (see > >>>> > >>> > > http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > >=20 > >>>there is a protocol message > >>>that corresponds for every 802.11 MAC management event. So=20 > when a STA >=20 > >>>associates, the AP breaks the message apart and creates an new=20 > >>>protocol PDU, which contains components found in the association=20 > >>>request. I suspect that most Local MAC approaches do=20 > something very=20 > >>>similar. > >>> > >>>So if a protocol simply tunnels the 802.11 MAC management=20 > frames from >=20 > >>>the WTP to the AC, it allows supports both approaches. For=20 > Local MAC, >=20 > >>>they get what they want via the 802.11 frame, and this also works=20 > >>>fine for Split MAC, which needs access to the MAC=20 > management frame.=20 > >>>What would be required in such a protocol is a way for the AP to=20 > >>>communicate whether it will be providing very specific functions -=20 > >>>basically a capabilities negotiation approach. > >>> > >>>So I do believe that there is a way to address both architectures=20 > >>>using a single protocol. > >>> > >>>Thoughts? > >>> > >>>PatC > >>> > >>>_______________________________________________ > >>>Capwap mailing list > >>>Capwap@frascone.com=20 > 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 > >=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 > > _______________________________________________ > > 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 >=20 >=20 > -- > Shankar Narayanaswamy, Ph.D. > wireless@shankar.org Mobile: +1 650-387-4593 > http://www.shankar.org E-Fax: +1 253-498-8372 >=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 >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Aug 10 22:16:03 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25035 for ; Tue, 10 Aug 2004 22:16:01 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 50CE121A70; Tue, 10 Aug 2004 22:01:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E5CD02198A; Tue, 10 Aug 2004 22:01:05 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CE1DA2198A for ; Tue, 10 Aug 2004 22:00:48 -0400 (EDT) Received: from sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by mail.frascone.com (Postfix) with ESMTP id A46CD2197C for ; Tue, 10 Aug 2004 22:00:46 -0400 (EDT) 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.6944.0 Subject: RE: [Capwap] So many architectures, so little time... - take 2 Message-ID: Thread-Topic: [Capwap] So many architectures, so little time... - take 2 Thread-Index: AcR/Bmj8yt99Q2VUTPyN1QkjwC5gbAAA9dfQAA1oxBAAAeEMEA== From: "Sudhanshu Jain" To: "Yang, Lily L" , "Shehzad Merchant" , "Shankar Narayanaswamy" , "Abhijit Choudhury" 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, 10 Aug 2004 19:19:24 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Problem we have to solve can be classified into three categories. * Control & Management of WTP * Control & Management of STA * 802.11 Data Since different functionalities has different requirements, it is possible to address them with separate sets of mechanism.=20 First version of CAPWAP control protocol should address first functionality with provision to communicate=20 * Tunneling mechanism * Information about MAC implementation (Local/Split/Centralized) etc. -Suds -----Original Message----- From: Yang, Lily L [mailto:lily.l.yang@intel.com]=20 Sent: Tuesday, August 10, 2004 6:13 PM To: Sudhanshu Jain; Shehzad Merchant; Shankar Narayanaswamy; Abhijit Choudhury Cc: capwap@frascone.com Subject: RE: [Capwap] So many architectures, so little time... - take 2 The question in my mind is: Can data plane and control plane be cleanly separated for Split MAC? I know it is feasible for Local MAC, but not sure about Split MAC.=20 Any insight? -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sudhanshu Jain Sent: Tuesday, August 10, 2004 11:55 AM To: Shehzad Merchant; Shankar Narayanaswamy; Abhijit Choudhury Cc: capwap@frascone.com Subject: RE: [Capwap] So many architectures, so little time... - take 2 I fully agree with Shehzad. We need to separate the control and data plane. Control plane should provide the framework to use one of several tunneling protocol.=20 On data plane, if we need to define a new layer2/layer3 level tunneling protocol, it should be separate work from control protocol work.=20 -Suds -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Shehzad Merchant Sent: Tuesday, August 10, 2004 11:13 AM To: Shankar Narayanaswamy; Abhijit Choudhury Cc: capwap@frascone.com Subject: RE: [Capwap] So many architectures, so little time... - take 2 Additionally, for data tunneling one needs a lightweight mechanism that may not necessarily have the same requirements as that for control and management. For example, one would want to limit the tunneling and processing overhead on data packets to a minimum. Control and management may be more tolerant of tunneling/security/etc. overhead. Besides, there are plenty of standards in place for data tunneling. We may potentially be able to leverage off that work itself without having to invent yet another tunneling mechanism for data.=20 -S -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Shankar Narayanaswamy Sent: Tuesday, August 10, 2004 10:30 AM To: Abhijit Choudhury Cc: capwap@frascone.com Subject: Re: [Capwap] So many architectures, so little time... - take 2 On the first point: not necessarily. If data packets are encapsulated 802.11 data frames, then there is no need to protect them on the wire any more than they were encrypted over the air. But control and management packets will need protection over the wired network and therefore possibly a different tunneling protocol. On the second point (standard way of packet exchange): yes! -s Abhijit Choudhury wrote: > The same tunneling protocol that moves control and management packets=20 > from the WTP to the AC should be used to tunnel data packets as well. > We would specify message exchanges to do control, provisioning and=20 > capability advertisement between WTPs and the AC. But all of this=20 > would be within the unified CAPWAP protocol that moves all packets=20 > including data between the WTP and AC. Vendors currently use LWAPP,=20 > GRE, IP and some proprietary encapsulations to achieve this. This=20 > group would come up with a "standard" way of doing this exchange. >=20 > At least that was my understanding.... >=20 > Regards, > Abhijit >=20 > -----Original Mssage----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On=20 > Behalf Of Wijnen, Bert (Bert) > Sent: Monday, August 09, 2004 6:14 AM > To: 'Yang, Lily L'; Burbank, Jack L.; Victor Lin; Bob O'Hara;=20 > capwap@frascone.com > Subject: RE: [Capwap] So many architectures, so little time... - take=20 > 2 >=20 >=20 > Not sure who is confused... probably me... >=20 > My understanding was/is that IF we do re-charter for CAPWAP protocol=20 > work, that it is then a NM protocol for "Control and Provisioning" and > not any of the related stuff that moves the data from WTP to AC. >=20 > Is everybody in agreement with that understanding. >=20 > Thanks, > Bert >=20 >=20 >>-----Original Message----- >>From: Yang, Lily L [mailto:lily.l.yang@intel.com] >>Sent: maandag 9 augustus 2004 08:14 >>To: Burbank, Jack L.; Victor Lin ; Bob O'Hara ; capwap@frascone.com >>Subject: RE: [Capwap] So many architectures, so little time... - take=20 >>2 >> >> >>I think setting the re-charter scope to develop a single protocol that >=20 >=20 >>allows interoperability between Local and Split MAC is a reasonable >>tradeoff: >>We exclude remote MAC because the constraint it imposes is very=20 >>different from the rest and the benefit of including it is very=20 >>little. But Local and Split MAC are reasonably close and hence the=20 >>effort may be incremental only. >>As many people noted, as of today, there is no single clear definition >>of what "Local MAC" and "Split MAC" really means yet. Each vendor has=20 >>different definitions and some debate needs to happen so that the WG=20 >>can reach consensus on what exactly that means, and what kinds of=20 >>flexibility we want to retain within each class of architecture, and=20 >>what kind of differences we can to resolve and agree up front. That=20 >>should also be part of the work items for the new WG -- such agreement >>on the details for each architecture must be documented somewhere, if=20 >>not separately, then as part of the Protocol document. >> >>-----Original Message----- >>From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On=20 >>Behalf Of Burbank, Jack L. >>Sent: Thursday, August 05, 2004 12:14 PM >>To: 'Victor Lin '; 'Bob O'Hara '; 'capwap@frascone.com ' >>Subject: RE: [Capwap] So many architectures, so little time... - take=20 >>2 >> >>I think that interoperability between different architectures should=20 >>be a requirement, if not the key requirement. As was mentioned=20 >>yesterday, a goal of the IEEE is that they maintain flexibility in=20 >>terms of how products and architectures are implemented. I think we=20 >>shouldn't do anything that is contrary to that goal (or at least we=20 >>should minimize the impact). I think that the goal of CAPWAP should=20 >>be to retain this type of flexibility by designing a protocol that can >>maintain this implementation flexibility but enable interoperability=20 >>between the various architecture implementations (that after all is=20 >>the key problem with the deployment of these various architectures -=20 >>lack of interoperability). IMO, if we don't design for=20 >>interoperability between the basic architecture types, it is debatable >>if something useful would have been accomplished. >> >>Jack Burbank >> >>-----Original Message----- >>From: capwap-admin@frascone.com >>To: Bob O'Hara; capwap@frascone.com >>Sent: 8/5/2004 2:46 PM >>Subject: RE: [Capwap] So many architectures, so little time... - take=20 >>2 >> >>I agree that we can design a protocol and implement the product that=20 >>works all architectures. I think the question to CAPWAP is: >> >>Should we make it a requirement in CAPWAP protocol to achieve=20 >>interoperability between different architectures? >> >>It is definitely doable, but I'm not sure if that is the right thing=20 >>to do.. >> >>Victor >> >>-----Original Message----- >>From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On=20 >>Behalf Of Bob O'Hara >>Sent: Thursday, August 05, 2004 11:43 AM >>To: capwap@frascone.com >>Subject: RE: [Capwap] So many architectures, so little time... - take=20 >>2 >> >>I think that interoperability will depend on two things. >>First, it will >>depend on how we define the protocol and the flexibility for supported >>architectures it incorporates. Second, it will depend on what=20 >>manufacturers implement, i.e., the flexibility they build into their=20 >>products. >> >>I believe that it is possible to design the protocol for the required=20 >>flexibility. I know it is possible to implement a product with the=20 >>required flexibility. >> >> -Bob O'Hara >>=20 >> >>-----Original Message----- >>From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On=20 >>Behalf Of Abhijit Choudhury >>Sent: Thursday, August 05, 2004 11:32 AM >>To: James Kempf; Shehzad Merchant; capwap@frascone.com >>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com;=20 >>Dorothy.Gellert@nokia.com; Inderpreet Singh >>Subject: RE: [Capwap] So many architectures, so little time... - take=20 >>2 >> >> >>It may be possible to achieve such interoperability within the=20 >>split-MAC family or within the local-MAC family. It would sbe very=20 >>hard to achieve that between local and split MAC families. >> >>For example, if vendor X's WTP terminates 802.11 ctrl/mgmt packets and >=20 >=20 >>vendor Y's AC expects the 802.11 mgmt packets to come to it, there's=20 >>no way you can be interoperable. >> >>Or are we planning to specify ONE architecture ? >>The last thing IETF should do is mandate an implementation. >> >>I think a modest and reasonable goal is to come up with a protocol=20 >>that allows sufficient flexbility so that vendors with splitMAC=20 >>architectures can transfer most of the information they care about=20 >>between the WTP and AC. >> >>Just my $0.02 ... >> >> >>Abhijit Choudhury >> >> >>-----Original Message----- >>From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On=20 >>Behalf Of James Kempf >>Sent: Wednesday, August 04, 2004 3:29 PM >>To: Shehzad Merchant; capwap@frascone.com >>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com;=20 >>Dorothy.Gellert@nokia.com; Inderpreet Singh >>Subject: Re: [Capwap] So many architectures, so little time... - take=20 >>2 >> >> >>As a potential customer, let me put it concretely. I want to be able=20 >>to buy my access points from Vendor X and my switch from Vendor Y and=20 >>plug the two together and have them work without any configuration.=20 >>Also, I'd like to be able to buy switches from Vendor Y and Vendor Z=20 >>and be able to plug them into my network at various places and have=20 >>them interoperate. >> >> jak >> >> >>----- Original Message ----- >>From: "Shehzad Merchant" >>To: >>Cc: ; ;=20 >>; ; "Inderpreet=20 >>Singh" >> >>Sent: Wednesday, August 04, 2004 3:19 PM >>Subject: RE: [Capwap] So many architectures, so little time... - take=20 >>2 >> >> >> >>>I think the implementation variations even with the split MAC may=20 >>>cover a broad spectrum. As such its important to clearly articulate=20 >>>what aspects >> >>of >> >>>interoperability we are targetting. Is it truly just=20 >>>control/management or is it interoperability between disparate=20 >>>implementations of the split MAC, i.e. mix and match >> >>operation of WTP >> >>>and ACs of all variants within this category. >>> >>>I suspect for the latter we may have to arrive at some consensus on=20 >>>what particular implementations we are targeting >> >>interoperability for. >> >> >>>If so, ultimately this problem statement could become part of the=20 >>>charter. >>> >>>-Shehzad >>> >>> >>> >>>-----Original Message----- >>>From: capwap-admin@frascone.com >> >>[mailto:capwap-admin@frascone.com] On >>Behalf >> >>>Of Dorothy.Gellert@nokia.com >>>Sent: Wednesday, August 04, 2004 11:53 AM >>>To: isingh@chantrynetworks.com; capwap@frascone.com >>>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com >>>Subject: RE: [Capwap] So many architectures, so little >> >>time... - take >> >>>2 >>> >>>I believe this is the consensus, to scope the charter to >> >>Centralized >> >>>Architecture and LocalMAC and Split MAC. >>> >>>I'll update the charter with this change after the CAPWAP >> >>WG Mtg. If >> >>>there is resistance to this idea, please post to the list. >>> >>>Regards >>>Dorothy >>> >>> >>> >>>>-----Original Message----- >>>>From: capwap-admin@frascone.com >>> >>[mailto:capwap-admin@frascone.com]On >> >>>>Behalf Of ext Inderpreet Singh >>>>Sent: Tuesday, August 03, 2004 9:40 PM >>>>To: capwap@frascone.com >>>>Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David=20 >>>>(Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) >>>>Subject: RE: [Capwap] So many architectures, so little time... -=20 >>>>take 2 >>>> >>>> >>>>The issue(s) at hand and my opinions are: >>>> >>>>1. Do we explicitly state in the re-charter which >>> >>architecture the >> >>>>WG should consider? I think yes. I propose Centralized >>> >>architecture >> >> >>>>only. Autonomous and Distributed should be out of scope >>> >>based on the >> >> >>>>same reasons as per prior postings. >>>> >>>>2. Within Centralized do we focus on all three sub >>> >>architectures or >> >>>>a subset? Remote MAC should be excluded because if I am not=20 >>>>mistaken, the connectivity constraint between the WTP and >>> >>the AC is >> >>>>"direct connect". >>>>That being the case and that no IP layer is involved, it doesn't >>> >>seem >> >>>>clear what kind of protocol would help with interoperability. I am >>> >=20 >>>>concerned about the impact, dependencies and interaction with the=20 >>>>recently constituted IEEE Study group on AP >>> >>functionality on the >> >>>>Split MAC architectures. Furthermore, there are some >>> >>pretty drastic >> >>>>differences on how the vendors have chosen to split the >>> >>mac. Those >> >>>>differences will need to be worked out before designing a >>> >>protocol. >> >>>>So, if the low hanging fruit strategy (as James suggested) for=20 >>>>protocol development and progress is the way to go, then I think=20 >>>>prioritizing on a protocol for Local MAC is a no brainer. >>> >> So as far >> >>>>as focus, I feel we should do Local and Split and in that order. >>>> >>>>3. This is not a re-chartering issue but is a response to Pat's=20 >>>>suggestion that a protocol that just sends the 802.11 MAC frames=20 >>>>from the AP to the AC would work. I think possibly, yes. >>> >> But again >> >> >>>>the complications of splitting the MAC in an >>> >>interoperable way will >> >>>>be an issue. Also, you may note in the draft to which >>> >>you refer, we >> >> >>>>included a capabilities exchange phase. I had thought of >>> >>including >> >>>>in the capability exchange such things as "AP supports Local MAC" >>>>and "AP supports Split MAC", but didn't put it in because the=20 >>>>Taxonomy work was still in progress. Now that it is pretty much=20 >>>>done we could surely include that. But again...let's recharter=20 >>>>first. >>>> >>>>Thanks. Do people agree with 1 & 2? >>>> >>>>--- >>>>Inderpreet Singh >>>>Chantry Networks >>>>isingh@chantrynetworks.com >>>>Cell: 416-831-3705 >>>> >>>>-----Original Message----- >>>>From: capwap-admin@frascone.com >>> >>[mailto:capwap-admin@frascone.com] >> >>>>On Behalf Of Pat R. Calhoun >>>>Sent: Tuesday, August 03, 2004 6:04 PM >>>>To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com;=20 >>>>capwap@frascone.com >>>>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com >>>>Subject: [Capwap] So many architectures, so little >>> >>time... - take 2 >> >>>>After reading Lily's response to Jim, I realize that I >>> >>fell down the >> >> >>>>same trap. Local MAC is also a centralized approach, and so my=20 >>>>previous response was not complete. I believe the real >>> >>question, in >> >>>>my mind, is whether we need to address either the Local >>> >>or the Split >> >> >>>>MAC architecture. >>>> >>>>Just looking at the Architecture Consideration tables (7 and >>>>10) in the >>>>specification, the >>>>main difference (at a high level) between both approaches >>> >>is where >> >>>>the 802.11 management terminates. For Local MAC, it's in the WTP,=20 >>>>while for SPlit MAC, it's in the AC. >>>> >>>>However, looking at table 8, most Local MAC approaches share STA=20 >>>>state between both the WTP and the AC. So clearly there is some=20 >>>>signalling protocol between both the WTP and the AC. >>>> >>>>Looking at one example of a Local MAC protocol (see >>>> >>> > http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), >=20 >>>there is a protocol message >>>that corresponds for every 802.11 MAC management event. So when a STA >>>associates, the AP breaks the message apart and creates an new=20 >>>protocol PDU, which contains components found in the association=20 >>>request. I suspect that most Local MAC approaches do something very=20 >>>similar. >>> >>>So if a protocol simply tunnels the 802.11 MAC management frames from >>>the WTP to the AC, it allows supports both approaches. For Local MAC, >>>they get what they want via the 802.11 frame, and this also works=20 >>>fine for Split MAC, which needs access to the MAC management frame.=20 >>>What would be required in such a protocol is a way for the AP to=20 >>>communicate whether it will be providing very specific functions -=20 >>>basically a capabilities negotiation approach. >>> >>>So I do believe that there is a way to address both architectures=20 >>>using a single protocol. >>> >>>Thoughts? >>> >>>PatC >>> >>>_______________________________________________ >>>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 >=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 > _______________________________________________ > 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 -- Shankar Narayanaswamy, Ph.D. wireless@shankar.org Mobile: +1 650-387-4593 http://www.shankar.org E-Fax: +1 253-498-8372 _______________________________________________ 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 Aug 11 02:15:57 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21903 for ; Wed, 11 Aug 2004 02:15:56 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1B3E920607; Wed, 11 Aug 2004 02:01:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 93CC3206F1; Wed, 11 Aug 2004 02:01:05 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8E43E20703 for ; Wed, 11 Aug 2004 02:00:22 -0400 (EDT) Received: from sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by mail.frascone.com (Postfix) with ESMTP id A0F0220607 for ; Wed, 11 Aug 2004 02:00:20 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C47F6B.16B1AC6C" X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Subject: FW: [Capwap] So many architectures, so little time... - take 2 Message-ID: Thread-Topic: [Capwap] So many architectures, so little time... - take 2 Thread-Index: AcR/Bmj8yt99Q2VUTPyN1QkjwC5gbAAA9dfQAA1oxBAAAeEMEAAIOBjmAACoasI= From: "Abhijit Choudhury" 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: Tue, 10 Aug 2004 23:17:43 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C47F6B.16B1AC6C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable One key objective that has been discussed in this group=20 is INTEROPERABILITY. It's not clear how you achieve interoperability between a WTP from vendor X and an AC=20 from vendor Y, if you don't support the same protocols on all three categories that you have pointed out. Sure you can achieve interoperability between the two, if you support the superset of all possible encapsulations, but then you are no better off than you are currently. That is why there is need for a standard. And it's easier to implement in hardware or software if there is one standard protocol instead of three. =20 We really should strive towards a unified tunneling protocol for control and data, although you can have separate connections for each, and different security on each. =20 But if this group stays away from specifying a common protocol for control/mgmt and data between the WTP and AC, or specifies one and not the other, there cannot be true interoperability even within the split-MAC architecture family. =20 Abhijit ________________________________ From: Sudhanshu Jain Sent: Tue 8/10/2004 7:19 PM To: 'Yang, Lily L'; Shehzad Merchant; Shankar Narayanaswamy; Abhijit = Choudhury Cc: capwap@frascone.com Subject: RE: [Capwap] So many architectures, so little time... - take 2 Problem we have to solve can be classified into three categories.=20 * Control & Management of WTP=20 * Control & Management of STA=20 * 802.11 Data=20 Since different functionalities has different requirements, it is = possible to address them with separate sets of mechanism.=20 First version of CAPWAP control protocol should address first = functionality with provision to communicate=20 * Tunneling mechanism=20 * Information about MAC implementation (Local/Split/Centralized) etc.=20 -Suds=20 ------_=_NextPart_001_01C47F6B.16B1AC6C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= =0A= RE: [Capwap] So many architectures, so little time... - take = 2=0A= =0A= =0A=
=0A=
One key = objective =0A= that has been discussed in this group
=0A=
=0A=
=0A=
is INTEROPERABILITY.  = It's not clear =0A= how you achieve
=0A=
interoperability between a = WTP from vendor =0A= X and an AC
=0A=
from vendor Y, if you don't = support the =0A= same protocols on
=0A=
all three categories that you = have pointed =0A= out.  Sure you can
=0A=
achieve interoperability = between the two, =0A= if you support the
=0A=
superset of all possible = encapsulations, =0A= but then you are no
=0A=
better off than you are = currently.  =0A= That is why there is need
=0A=
for a standard.   = And it's easier =0A= to implement in hardware or software
=0A=
if there is one standard = protocol instead =0A= of three.
=0A=
 
=0A=
We really should strive = towards a =0A= unified tunneling protocol for control
=0A=
and data, although you can = have separate =0A= connections
=0A=
for each, and different = security on =0A= each.
=0A=
 
=0A=
But if this group stays away = from =0A= specifying a common
=0A=
protocol for control/mgmt and = data between =0A= the WTP
=0A=
and AC, or specifies one and = not the =0A= other,
=0A=
there cannot be true = interoperability even =0A= within
=0A=
the split-MAC architecture =0A= family.
=0A=
 
=0A=
Abhijit
=0A=

=0A=
=0A= From: Sudhanshu Jain
Sent: = Tue =0A= 8/10/2004 7:19 PM
To: 'Yang, Lily L'; Shehzad Merchant; = Shankar =0A= Narayanaswamy; Abhijit Choudhury
Cc: =0A= capwap@frascone.com
Subject: RE: [Capwap] So many = architectures, so =0A= little time... - take 2

=0A=
=0A=

Problem we have to solve can be classified into three =0A= categories.

=0A=

* Control & Management of WTP
* =0A= Control & Management of STA
* 802.11 = Data =0A=

=0A=

Since different functionalities has different = requirements, it =0A= is possible to address them with separate sets of mechanism.

=0A=

First version of CAPWAP control protocol should = address first =0A= functionality with provision to communicate
* = Tunneling =0A= mechanism
* Information about MAC = implementation =0A= (Local/Split/Centralized) etc.

=0A=

-Suds

=0A= =0A= =0A= ------_=_NextPart_001_01C47F6B.16B1AC6C-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Aug 11 10:24:59 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08097 for ; Wed, 11 Aug 2004 10:24:59 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5C0162076F; Wed, 11 Aug 2004 10:10:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 44A8E20A98; Wed, 11 Aug 2004 10:10:06 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EA50D20A98 for ; Wed, 11 Aug 2004 10:09:25 -0400 (EDT) Received: from 0.0.0.0 (cm208.omega193.maxonline.com.sg [218.186.193.208]) by mail.frascone.com (Postfix) with SMTP id 543B02076F for ; Wed, 11 Aug 2004 10:09:22 -0400 (EDT) From: "Saravanan Govindan" To: "'Abhijit Choudhury'" , Subject: RE: [Capwap] So many architectures, so little time... - take 2 Organization: Panasonic Singapore Laboratories MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcR/Bmj8yt99Q2VUTPyN1QkjwC5gbAAA9dfQAA1oxBAAAeEMEAAIOBjmAACoasIAEI6eIA== In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Message-Id: <20040811140922.543B02076F@mail.frascone.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, 11 Aug 2004 22:23:42 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Given the various sides to the discussion on where MAC frames are handled, I suggest making this a configuration aspect of the CAPWAP protocol. So, the choice of which MAC frames are processed where can be left till the time of initializing APs. For example, when a controller initializes a local-MAC AP, it configures one instance of the CAPWAP protocol so as NOT to receive any MAC frames from the AP. Rather, the protocol instance expects to receive explicit CAPWAP messages/signals from the local-MAC AP. On the other hand, while initializing a split-MAC AP, another instance of the protocol is configured to receive 'some' MAC frames and 'other' remaining CAPWAP messages/signals. The 'some' and 'other' parts refer to particular split-MAC variations. The specifics of these parts can be left for refinement based on the analyses from the Architecture Taxonomy. The CAPWAP protocol can then be made to work on both raw MAC frames and abstracted CAPWAP messages/signals. This way, true interoperability is achieved, while at the same time allowing for different designs and implementations. Comments? Suggestions? Saravanan ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Abhijit Choudhury Sent: Wednesday, August 11, 2004 2:18 PM To: capwap@frascone.com Subject: FW: [Capwap] So many architectures, so little time... - take 2 One key objective that has been discussed in this group is INTEROPERABILITY. It's not clear how you achieve interoperability between a WTP from vendor X and an AC from vendor Y, if you don't support the same protocols on all three categories that you have pointed out. Sure you can achieve interoperability between the two, if you support the superset of all possible encapsulations, but then you are no better off than you are currently. That is why there is need for a standard. And it's easier to implement in hardware or software if there is one standard protocol instead of three. We really should strive towards a unified tunneling protocol for control and data, although you can have separate connections for each, and different security on each. But if this group stays away from specifying a common protocol for control/mgmt and data between the WTP and AC, or specifies one and not the other, there cannot be true interoperability even within the split-MAC architecture family. Abhijit ________________________________ From: Sudhanshu Jain Sent: Tue 8/10/2004 7:19 PM To: 'Yang, Lily L'; Shehzad Merchant; Shankar Narayanaswamy; Abhijit Choudhury Cc: capwap@frascone.com Subject: RE: [Capwap] So many architectures, so little time... - take 2 Problem we have to solve can be classified into three categories. * Control & Management of WTP * Control & Management of STA * 802.11 Data Since different functionalities has different requirements, it is possible to address them with separate sets of mechanism. First version of CAPWAP control protocol should address first functionality with provision to communicate * Tunneling mechanism * Information about MAC implementation (Local/Split/Centralized) etc. -Suds _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Aug 11 11:53:00 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14137 for ; Wed, 11 Aug 2004 11:52:58 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E7D6021448; Wed, 11 Aug 2004 11:38:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4A46D21460; Wed, 11 Aug 2004 11:38:06 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BAE2021460 for ; Wed, 11 Aug 2004 11:37:43 -0400 (EDT) Received: from mail3.extremenetworks.com (sc-f100-01.extremenetworks.com [63.251.106.30]) by mail.frascone.com (Postfix) with ESMTP id 920181FF40 for ; Wed, 11 Aug 2004 11:37:41 -0400 (EDT) Received: by mail3 with Internet Mail Service (5.5.2657.72) id ; Wed, 11 Aug 2004 08:51:01 -0700 Message-ID: <4C8B0EA487B9554D910B0587CD91395C027B5945@sc-msexch-03.extremenetworks.com> From: Victor Lin To: Dorothy.Gellert@nokia.com, lily.l.yang@intel.com, sudhanshu@sinett.com, Shehzad Merchant , wireless@shankar.org, Abhijit@sinett.com Cc: capwap@frascone.com Subject: RE: [Capwap] Data plane and control plane separation in Split MAC MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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, 11 Aug 2004 08:48:41 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I certain believe we can split control and data plane in split MAC protocol. The big difference between split MAC and split AP are: 1. Split AP tunnel back 802.3 frames where split MAC tunnel back 802.11 frames to AC. 2. Split AP terminate 802.11 management frame on WTP but split MAC tunnel back 802.11 management frames back to AC. Split will need some other means/protocols to synchronize control information between AC and WTP. Both architectures have clean separation between control and data plane, but they all use different method to handle control and data plane communication between AC and WTP. If the goal of the CAPWAP is to support interoperability between two architectures, we certainly need to address those differences. Victor -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Dorothy.Gellert@nokia.com Sent: Tuesday, August 10, 2004 6:59 PM To: lily.l.yang@intel.com; sudhanshu@sinett.com; smerchant@extremenetworks.com; wireless@shankar.org; Abhijit@sinett.com Cc: capwap@frascone.com Subject: [Capwap] Data plane and control plane separation in Split MAC Good point. Can we have the volunteers that submitted architectures for the taxonomy draft weigh in on this issue? Also another point to consider is that we don't have to implement *every* AP function in the first release of the CAPWAP protocol. One of our charter goals is to start with the minimal set of functionality needed to provide control. We have a "desirable" category where we can put objectives that can be met with a later release or extension. Dorothy > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > Behalf Of ext Yang, Lily L > Sent: Tuesday, August 10, 2004 6:13 PM > To: Sudhanshu Jain; Shehzad Merchant; Shankar Narayanaswamy; Abhijit > Choudhury > Cc: capwap@frascone.com > Subject: RE: [Capwap] So many architectures, so little > time... - take 2 > > > The question in my mind is: Can data plane and control plane > be cleanly > separated for Split MAC? I know it is feasible for Local MAC, but not > sure about Split MAC. > Any insight? > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Sudhanshu Jain > Sent: Tuesday, August 10, 2004 11:55 AM > To: Shehzad Merchant; Shankar Narayanaswamy; Abhijit Choudhury > Cc: capwap@frascone.com > Subject: RE: [Capwap] So many architectures, so little > time... - take 2 > > I fully agree with Shehzad. We need to separate the control and data > plane. Control plane should provide the framework to use one > of several > tunneling protocol. > > On data plane, if we need to define a new layer2/layer3 level > tunneling > protocol, it should be separate work from control protocol work. > > -Suds > > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Shehzad Merchant > Sent: Tuesday, August 10, 2004 11:13 AM > To: Shankar Narayanaswamy; Abhijit Choudhury > Cc: capwap@frascone.com > Subject: RE: [Capwap] So many architectures, so little > time... - take 2 > > Additionally, for data tunneling one needs a lightweight > mechanism that > may > not necessarily have the same requirements as that for control and > management. For example, one would want to limit the tunneling and > processing overhead on data packets to a minimum. Control and > management > may > be more tolerant of tunneling/security/etc. overhead. > Besides, there are > plenty of standards in place for data tunneling. We may potentially be > able > to leverage off that work itself without having to invent yet another > tunneling mechanism for data. > > -S > > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf > Of Shankar Narayanaswamy > Sent: Tuesday, August 10, 2004 10:30 AM > To: Abhijit Choudhury > Cc: capwap@frascone.com > Subject: Re: [Capwap] So many architectures, so little > time... - take 2 > > On the first point: not necessarily. If data packets are encapsulated > 802.11 data frames, then there is no need to protect them on the wire > any > more than they were encrypted over the air. > > But control and management packets will need protection over the wired > network and therefore possibly a different tunneling protocol. > > On the second point (standard way of packet exchange): yes! > > -s > > Abhijit Choudhury wrote: > > The same tunneling protocol that moves control and > management packets > > from the WTP to the AC should be used to tunnel data > packets as well. > > > We would specify message exchanges to do control, provisioning and > > capability advertisement between WTPs and the AC. But all of this > > would be within the unified CAPWAP protocol that moves all packets > > including data between the WTP and AC. Vendors currently > use LWAPP, > > GRE, IP and some proprietary encapsulations to achieve this. This > > group would come up with a "standard" way of doing this exchange. > > > > At least that was my understanding.... > > > > Regards, > > Abhijit > > > > -----Original Mssage----- > > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On > > Behalf Of Wijnen, Bert (Bert) > > Sent: Monday, August 09, 2004 6:14 AM > > To: 'Yang, Lily L'; Burbank, Jack L.; Victor Lin; Bob O'Hara; > > capwap@frascone.com > > Subject: RE: [Capwap] So many architectures, so little > time... - take > > 2 > > > > > > Not sure who is confused... probably me... > > > > My understanding was/is that IF we do re-charter for CAPWAP > protocol > > work, that it is then a NM protocol for "Control and > Provisioning" and > > > not any of the related stuff that moves the data from WTP to AC. > > > > Is everybody in agreement with that understanding. > > > > Thanks, > > Bert > > > > > >>-----Original Message----- > >>From: Yang, Lily L [mailto:lily.l.yang@intel.com] > >>Sent: maandag 9 augustus 2004 08:14 > >>To: Burbank, Jack L.; Victor Lin ; Bob O'Hara ; capwap@frascone.com > >>Subject: RE: [Capwap] So many architectures, so little > time... - take > >>2 > >> > >> > >>I think setting the re-charter scope to develop a single > protocol that > > > > > >>allows interoperability between Local and Split MAC is a reasonable > >>tradeoff: > >>We exclude remote MAC because the constraint it imposes is very > >>different from the rest and the benefit of including it is very > >>little. But Local and Split MAC are reasonably close and hence the > >>effort may be incremental only. > >>As many people noted, as of today, there is no single clear > definition > > >>of what "Local MAC" and "Split MAC" really means yet. Each > vendor has > >>different definitions and some debate needs to happen so > that the WG > >>can reach consensus on what exactly that means, and what kinds of > >>flexibility we want to retain within each class of > architecture, and > >>what kind of differences we can to resolve and agree up front. That > >>should also be part of the work items for the new WG -- > such agreement > > >>on the details for each architecture must be documented > somewhere, if > >>not separately, then as part of the Protocol document. > >> > >>-----Original Message----- > >>From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On > >>Behalf Of Burbank, Jack L. > >>Sent: Thursday, August 05, 2004 12:14 PM > >>To: 'Victor Lin '; 'Bob O'Hara '; 'capwap@frascone.com ' > >>Subject: RE: [Capwap] So many architectures, so little > time... - take > >>2 > >> > >>I think that interoperability between different > architectures should > >>be a requirement, if not the key requirement. As was mentioned > >>yesterday, a goal of the IEEE is that they maintain flexibility in > >>terms of how products and architectures are implemented. I > think we > >>shouldn't do anything that is contrary to that goal (or at least we > >>should minimize the impact). I think that the goal of > CAPWAP should > >>be to retain this type of flexibility by designing a > protocol that can > > >>maintain this implementation flexibility but enable > interoperability > >>between the various architecture implementations (that after all is > >>the key problem with the deployment of these various > architectures - > >>lack of interoperability). IMO, if we don't design for > >>interoperability between the basic architecture types, it > is debatable > > >>if something useful would have been accomplished. > >> > >>Jack Burbank > >> > >>-----Original Message----- > >>From: capwap-admin@frascone.com > >>To: Bob O'Hara; capwap@frascone.com > >>Sent: 8/5/2004 2:46 PM > >>Subject: RE: [Capwap] So many architectures, so little > time... - take > >>2 > >> > >>I agree that we can design a protocol and implement the > product that > >>works all architectures. I think the question to CAPWAP is: > >> > >>Should we make it a requirement in CAPWAP protocol to achieve > >>interoperability between different architectures? > >> > >>It is definitely doable, but I'm not sure if that is the > right thing > >>to do.. > >> > >>Victor > >> > >>-----Original Message----- > >>From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On > >>Behalf Of Bob O'Hara > >>Sent: Thursday, August 05, 2004 11:43 AM > >>To: capwap@frascone.com > >>Subject: RE: [Capwap] So many architectures, so little > time... - take > >>2 > >> > >>I think that interoperability will depend on two things. > >>First, it will > >>depend on how we define the protocol and the flexibility > for supported > > >>architectures it incorporates. Second, it will depend on what > >>manufacturers implement, i.e., the flexibility they build > into their > >>products. > >> > >>I believe that it is possible to design the protocol for > the required > >>flexibility. I know it is possible to implement a product with the > >>required flexibility. > >> > >> -Bob O'Hara > >> > >> > >>-----Original Message----- > >>From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On > >>Behalf Of Abhijit Choudhury > >>Sent: Thursday, August 05, 2004 11:32 AM > >>To: James Kempf; Shehzad Merchant; capwap@frascone.com > >>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; > >>Dorothy.Gellert@nokia.com; Inderpreet Singh > >>Subject: RE: [Capwap] So many architectures, so little > time... - take > >>2 > >> > >> > >>It may be possible to achieve such interoperability within the > >>split-MAC family or within the local-MAC family. It would sbe very > >>hard to achieve that between local and split MAC families. > >> > >>For example, if vendor X's WTP terminates 802.11 ctrl/mgmt > packets and > > > > > >>vendor Y's AC expects the 802.11 mgmt packets to come to > it, there's > >>no way you can be interoperable. > >> > >>Or are we planning to specify ONE architecture ? > >>The last thing IETF should do is mandate an implementation. > >> > >>I think a modest and reasonable goal is to come up with a protocol > >>that allows sufficient flexbility so that vendors with splitMAC > >>architectures can transfer most of the information they care about > >>between the WTP and AC. > >> > >>Just my $0.02 ... > >> > >> > >>Abhijit Choudhury > >> > >> > >>-----Original Message----- > >>From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On > >>Behalf Of James Kempf > >>Sent: Wednesday, August 04, 2004 3:29 PM > >>To: Shehzad Merchant; capwap@frascone.com > >>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; > >>Dorothy.Gellert@nokia.com; Inderpreet Singh > >>Subject: Re: [Capwap] So many architectures, so little > time... - take > >>2 > >> > >> > >>As a potential customer, let me put it concretely. I want > to be able > >>to buy my access points from Vendor X and my switch from > Vendor Y and > >>plug the two together and have them work without any configuration. > >>Also, I'd like to be able to buy switches from Vendor Y and > Vendor Z > >>and be able to plug them into my network at various places and have > >>them interoperate. > >> > >> jak > >> > >> > >>----- Original Message ----- > >>From: "Shehzad Merchant" > >>To: > >>Cc: ; ; > >>; ; "Inderpreet > >>Singh" > >> > >>Sent: Wednesday, August 04, 2004 3:19 PM > >>Subject: RE: [Capwap] So many architectures, so little > time... - take > >>2 > >> > >> > >> > >>>I think the implementation variations even with the split MAC may > >>>cover a broad spectrum. As such its important to clearly > articulate > >>>what aspects > >> > >>of > >> > >>>interoperability we are targetting. Is it truly just > >>>control/management or is it interoperability between disparate > >>>implementations of the split MAC, i.e. mix and match > >> > >>operation of WTP > >> > >>>and ACs of all variants within this category. > >>> > >>>I suspect for the latter we may have to arrive at some > consensus on > >>>what particular implementations we are targeting > >> > >>interoperability for. > >> > >> > >>>If so, ultimately this problem statement could become part of the > >>>charter. > >>> > >>>-Shehzad > >>> > >>> > >>> > >>>-----Original Message----- > >>>From: capwap-admin@frascone.com > >> > >>[mailto:capwap-admin@frascone.com] On > >>Behalf > >> > >>>Of Dorothy.Gellert@nokia.com > >>>Sent: Wednesday, August 04, 2004 11:53 AM > >>>To: isingh@chantrynetworks.com; capwap@frascone.com > >>>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > >>>Subject: RE: [Capwap] So many architectures, so little > >> > >>time... - take > >> > >>>2 > >>> > >>>I believe this is the consensus, to scope the charter to > >> > >>Centralized > >> > >>>Architecture and LocalMAC and Split MAC. > >>> > >>>I'll update the charter with this change after the CAPWAP > >> > >>WG Mtg. If > >> > >>>there is resistance to this idea, please post to the list. > >>> > >>>Regards > >>>Dorothy > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: capwap-admin@frascone.com > >>> > >>[mailto:capwap-admin@frascone.com]On > >> > >>>>Behalf Of ext Inderpreet Singh > >>>>Sent: Tuesday, August 03, 2004 9:40 PM > >>>>To: capwap@frascone.com > >>>>Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David > >>>>(Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > >>>>Subject: RE: [Capwap] So many architectures, so little time... - > >>>>take 2 > >>>> > >>>> > >>>>The issue(s) at hand and my opinions are: > >>>> > >>>>1. Do we explicitly state in the re-charter which > >>> > >>architecture the > >> > >>>>WG should consider? I think yes. I propose Centralized > >>> > >>architecture > >> > >> > >>>>only. Autonomous and Distributed should be out of scope > >>> > >>based on the > >> > >> > >>>>same reasons as per prior postings. > >>>> > >>>>2. Within Centralized do we focus on all three sub > >>> > >>architectures or > >> > >>>>a subset? Remote MAC should be excluded because if I am not > >>>>mistaken, the connectivity constraint between the WTP and > >>> > >>the AC is > >> > >>>>"direct connect". > >>>>That being the case and that no IP layer is involved, it doesn't > >>> > >>seem > >> > >>>>clear what kind of protocol would help with interoperability. I am > >>> > > > >>>>concerned about the impact, dependencies and interaction with the > >>>>recently constituted IEEE Study group on AP > >>> > >>functionality on the > >> > >>>>Split MAC architectures. Furthermore, there are some > >>> > >>pretty drastic > >> > >>>>differences on how the vendors have chosen to split the > >>> > >>mac. Those > >> > >>>>differences will need to be worked out before designing a > >>> > >>protocol. > >> > >>>>So, if the low hanging fruit strategy (as James suggested) for > >>>>protocol development and progress is the way to go, then I think > >>>>prioritizing on a protocol for Local MAC is a no brainer. > >>> > >> So as far > >> > >>>>as focus, I feel we should do Local and Split and in that order. > >>>> > >>>>3. This is not a re-chartering issue but is a response to Pat's > >>>>suggestion that a protocol that just sends the 802.11 MAC frames > >>>>from the AP to the AC would work. I think possibly, yes. > >>> > >> But again > >> > >> > >>>>the complications of splitting the MAC in an > >>> > >>interoperable way will > >> > >>>>be an issue. Also, you may note in the draft to which > >>> > >>you refer, we > >> > >> > >>>>included a capabilities exchange phase. I had thought of > >>> > >>including > >> > >>>>in the capability exchange such things as "AP supports Local MAC" > >>>>and "AP supports Split MAC", but didn't put it in because the > >>>>Taxonomy work was still in progress. Now that it is pretty much > >>>>done we could surely include that. But again...let's recharter > >>>>first. > >>>> > >>>>Thanks. Do people agree with 1 & 2? > >>>> > >>>>--- > >>>>Inderpreet Singh > >>>>Chantry Networks > >>>>isingh@chantrynetworks.com > >>>>Cell: 416-831-3705 > >>>> > >>>>-----Original Message----- > >>>>From: capwap-admin@frascone.com > >>> > >>[mailto:capwap-admin@frascone.com] > >> > >>>>On Behalf Of Pat R. Calhoun > >>>>Sent: Tuesday, August 03, 2004 6:04 PM > >>>>To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com; > >>>>capwap@frascone.com > >>>>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > >>>>Subject: [Capwap] So many architectures, so little > >>> > >>time... - take 2 > >> > >>>>After reading Lily's response to Jim, I realize that I > >>> > >>fell down the > >> > >> > >>>>same trap. Local MAC is also a centralized approach, and so my > >>>>previous response was not complete. I believe the real > >>> > >>question, in > >> > >>>>my mind, is whether we need to address either the Local > >>> > >>or the Split > >> > >> > >>>>MAC architecture. > >>>> > >>>>Just looking at the Architecture Consideration tables (7 and > >>>>10) in the > >>>>specification, the > >>>>main difference (at a high level) between both approaches > >>> > >>is where > >> > >>>>the 802.11 management terminates. For Local MAC, it's in the WTP, > >>>>while for SPlit MAC, it's in the AC. > >>>> > >>>>However, looking at table 8, most Local MAC approaches share STA > >>>>state between both the WTP and the AC. So clearly there is some > >>>>signalling protocol between both the WTP and the AC. > >>>> > >>>>Looking at one example of a Local MAC protocol (see > >>>> > >>> > > http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > > > >>>there is a protocol message > >>>that corresponds for every 802.11 MAC management event. So > when a STA > > >>>associates, the AP breaks the message apart and creates an new > >>>protocol PDU, which contains components found in the association > >>>request. I suspect that most Local MAC approaches do > something very > >>>similar. > >>> > >>>So if a protocol simply tunnels the 802.11 MAC management > frames from > > >>>the WTP to the AC, it allows supports both approaches. For > Local MAC, > > >>>they get what they want via the 802.11 frame, and this also works > >>>fine for Split MAC, which needs access to the MAC > management frame. > >>>What would be required in such a protocol is a way for the AP to > >>>communicate whether it will be providing very specific functions - > >>>basically a capabilities negotiation approach. > >>> > >>>So I do believe that there is a way to address both architectures > >>>using a single protocol. > >>> > >>>Thoughts? > >>> > >>>PatC > >>> > >>>_______________________________________________ > >>>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 > > _______________________________________________ > > 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 > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > > -- > Shankar Narayanaswamy, Ph.D. > wireless@shankar.org Mobile: +1 650-387-4593 > http://www.shankar.org E-Fax: +1 253-498-8372 > > _______________________________________________ > 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 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Aug 11 23:14:05 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11285 for ; Wed, 11 Aug 2004 23:14:01 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E8D81205BF; Wed, 11 Aug 2004 22:59:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0C23A2186C; Wed, 11 Aug 2004 22:59:07 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ACC732186C for ; Wed, 11 Aug 2004 22:58:32 -0400 (EDT) Received: from gemini.lunarpages.com (gemini.lunarpages.com [64.235.234.128]) by mail.frascone.com (Postfix) with ESMTP id AFECC205BF for ; Wed, 11 Aug 2004 22:58:30 -0400 (EDT) Received: from h-68-167-136-151.snvacaid.covad.net ([68.167.136.151] helo=shankar.org) by gemini.lunarpages.com with asmtp (Exim 4.34) id 1Bv62w-00066G-Cz; Wed, 11 Aug 2004 20:14:31 -0700 Message-ID: <411AE049.60209@shankar.org> From: Shankar Narayanaswamy User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dorothy.Gellert@nokia.com Cc: capwap@frascone.com References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gemini.lunarpages.com X-AntiAbuse: Original Domain - frascone.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - shankar.org X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Re: Data plane and control plane separation in Split MAC 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, 11 Aug 2004 20:13:13 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit The parameters by which the data plane communicates such as authentication/security info, destination switch (if any) for data frames, etc, are communicated by the control plane. Hence the need for some architectural assumptions regarding the data plane even if the focus is on the control plane. Or at least a decision on the data plane architectures to be supported. -s Dorothy.Gellert@nokia.com wrote: > Good point. Can we have the volunteers that submitted architectures for the taxonomy draft weigh in on this issue? > > Also another point to consider is that we don't have to implement *every* AP function in the first release of the CAPWAP protocol. One of our charter goals is to start with the minimal set of functionality needed to provide control. We have a "desirable" category where we can put objectives that can be met with a later release or extension. > > Dorothy > >>-----Original Message----- >>From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On >>Behalf Of ext Yang, Lily L >>Sent: Tuesday, August 10, 2004 6:13 PM >>To: Sudhanshu Jain; Shehzad Merchant; Shankar Narayanaswamy; Abhijit >>Choudhury >>Cc: capwap@frascone.com >>Subject: RE: [Capwap] So many architectures, so little >>time... - take 2 >> >> >>The question in my mind is: Can data plane and control plane >>be cleanly >>separated for Split MAC? I know it is feasible for Local MAC, but not >>sure about Split MAC. >>Any insight? >> >>-----Original Message----- >>From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On >>Behalf Of Sudhanshu Jain >>Sent: Tuesday, August 10, 2004 11:55 AM >>To: Shehzad Merchant; Shankar Narayanaswamy; Abhijit Choudhury >>Cc: capwap@frascone.com >>Subject: RE: [Capwap] So many architectures, so little >>time... - take 2 >> >>I fully agree with Shehzad. We need to separate the control and data >>plane. Control plane should provide the framework to use one >>of several >>tunneling protocol. >> >>On data plane, if we need to define a new layer2/layer3 level >>tunneling >>protocol, it should be separate work from control protocol work. >> >>-Suds >> >> >>-----Original Message----- >>From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On >>Behalf Of Shehzad Merchant >>Sent: Tuesday, August 10, 2004 11:13 AM >>To: Shankar Narayanaswamy; Abhijit Choudhury >>Cc: capwap@frascone.com >>Subject: RE: [Capwap] So many architectures, so little >>time... - take 2 >> >>Additionally, for data tunneling one needs a lightweight >>mechanism that >>may >>not necessarily have the same requirements as that for control and >>management. For example, one would want to limit the tunneling and >>processing overhead on data packets to a minimum. Control and >>management >>may >>be more tolerant of tunneling/security/etc. overhead. >>Besides, there are >>plenty of standards in place for data tunneling. We may potentially be >>able >>to leverage off that work itself without having to invent yet another >>tunneling mechanism for data. >> >>-S >> >> >>-----Original Message----- >>From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On >>Behalf >>Of Shankar Narayanaswamy >>Sent: Tuesday, August 10, 2004 10:30 AM >>To: Abhijit Choudhury >>Cc: capwap@frascone.com >>Subject: Re: [Capwap] So many architectures, so little >>time... - take 2 >> >>On the first point: not necessarily. If data packets are encapsulated >>802.11 data frames, then there is no need to protect them on the wire >>any >>more than they were encrypted over the air. >> >>But control and management packets will need protection over the wired >>network and therefore possibly a different tunneling protocol. >> >>On the second point (standard way of packet exchange): yes! >> >>-s >> >>Abhijit Choudhury wrote: >> >>>The same tunneling protocol that moves control and >> >>management packets >> >>>from the WTP to the AC should be used to tunnel data >> >>packets as well. >> >> >>>We would specify message exchanges to do control, provisioning and >>>capability advertisement between WTPs and the AC. But all of this >>>would be within the unified CAPWAP protocol that moves all packets >>>including data between the WTP and AC. Vendors currently >> >>use LWAPP, >> >>>GRE, IP and some proprietary encapsulations to achieve this. This >>>group would come up with a "standard" way of doing this exchange. >>> >>>At least that was my understanding.... >>> >>>Regards, >>>Abhijit >>> >>>-----Original Mssage----- >>>From: capwap-admin@frascone.com >> >>[mailto:capwap-admin@frascone.com] On >> >>>Behalf Of Wijnen, Bert (Bert) >>>Sent: Monday, August 09, 2004 6:14 AM >>>To: 'Yang, Lily L'; Burbank, Jack L.; Victor Lin; Bob O'Hara; >>>capwap@frascone.com >>>Subject: RE: [Capwap] So many architectures, so little >> >>time... - take >> >>>2 >>> >>> >>>Not sure who is confused... probably me... >>> >>>My understanding was/is that IF we do re-charter for CAPWAP >> >>protocol >> >>>work, that it is then a NM protocol for "Control and >> >>Provisioning" and >> >> >>>not any of the related stuff that moves the data from WTP to AC. >>> >>>Is everybody in agreement with that understanding. >>> >>>Thanks, >>>Bert >>> >>> >>> >>>>-----Original Message----- >>>>From: Yang, Lily L [mailto:lily.l.yang@intel.com] >>>>Sent: maandag 9 augustus 2004 08:14 >>>>To: Burbank, Jack L.; Victor Lin ; Bob O'Hara ; capwap@frascone.com >>>>Subject: RE: [Capwap] So many architectures, so little >>> >>time... - take >> >>>>2 >>>> >>>> >>>>I think setting the re-charter scope to develop a single >>> >>protocol that >> >>> >>>>allows interoperability between Local and Split MAC is a reasonable >>>>tradeoff: >>>>We exclude remote MAC because the constraint it imposes is very >>>>different from the rest and the benefit of including it is very >>>>little. But Local and Split MAC are reasonably close and hence the >>>>effort may be incremental only. >>>>As many people noted, as of today, there is no single clear >>> >>definition >> >> >>>>of what "Local MAC" and "Split MAC" really means yet. Each >>> >>vendor has >> >>>>different definitions and some debate needs to happen so >>> >>that the WG >> >>>>can reach consensus on what exactly that means, and what kinds of >>>>flexibility we want to retain within each class of >>> >>architecture, and >> >>>>what kind of differences we can to resolve and agree up front. That >>>>should also be part of the work items for the new WG -- >>> >>such agreement >> >> >>>>on the details for each architecture must be documented >>> >>somewhere, if >> >>>>not separately, then as part of the Protocol document. >>>> >>>>-----Original Message----- >>>>From: capwap-admin@frascone.com >>> >>[mailto:capwap-admin@frascone.com] On >> >>>>Behalf Of Burbank, Jack L. >>>>Sent: Thursday, August 05, 2004 12:14 PM >>>>To: 'Victor Lin '; 'Bob O'Hara '; 'capwap@frascone.com ' >>>>Subject: RE: [Capwap] So many architectures, so little >>> >>time... - take >> >>>>2 >>>> >>>>I think that interoperability between different >>> >>architectures should >> >>>>be a requirement, if not the key requirement. As was mentioned >>>>yesterday, a goal of the IEEE is that they maintain flexibility in >>>>terms of how products and architectures are implemented. I >>> >>think we >> >>>>shouldn't do anything that is contrary to that goal (or at least we >>>>should minimize the impact). I think that the goal of >>> >>CAPWAP should >> >>>>be to retain this type of flexibility by designing a >>> >>protocol that can >> >> >>>>maintain this implementation flexibility but enable >>> >>interoperability >> >>>>between the various architecture implementations (that after all is >>>>the key problem with the deployment of these various >>> >>architectures - >> >>>>lack of interoperability). IMO, if we don't design for >>>>interoperability between the basic architecture types, it >>> >>is debatable >> >> >>>>if something useful would have been accomplished. >>>> >>>>Jack Burbank >>>> >>>>-----Original Message----- >>>>From: capwap-admin@frascone.com >>>>To: Bob O'Hara; capwap@frascone.com >>>>Sent: 8/5/2004 2:46 PM >>>>Subject: RE: [Capwap] So many architectures, so little >>> >>time... - take >> >>>>2 >>>> >>>>I agree that we can design a protocol and implement the >>> >>product that >> >>>>works all architectures. I think the question to CAPWAP is: >>>> >>>>Should we make it a requirement in CAPWAP protocol to achieve >>>>interoperability between different architectures? >>>> >>>>It is definitely doable, but I'm not sure if that is the >>> >>right thing >> >>>>to do.. >>>> >>>>Victor >>>> >>>>-----Original Message----- >>>>From: capwap-admin@frascone.com >>> >>[mailto:capwap-admin@frascone.com] On >> >>>>Behalf Of Bob O'Hara >>>>Sent: Thursday, August 05, 2004 11:43 AM >>>>To: capwap@frascone.com >>>>Subject: RE: [Capwap] So many architectures, so little >>> >>time... - take >> >>>>2 >>>> >>>>I think that interoperability will depend on two things. >>>>First, it will >>>>depend on how we define the protocol and the flexibility >>> >>for supported >> >> >>>>architectures it incorporates. Second, it will depend on what >>>>manufacturers implement, i.e., the flexibility they build >>> >>into their >> >>>>products. >>>> >>>>I believe that it is possible to design the protocol for >>> >>the required >> >>>>flexibility. I know it is possible to implement a product with the >>>>required flexibility. >>>> >>>>-Bob O'Hara >>>> >>>> >>>>-----Original Message----- >>>>From: capwap-admin@frascone.com >>> >>[mailto:capwap-admin@frascone.com] On >> >>>>Behalf Of Abhijit Choudhury >>>>Sent: Thursday, August 05, 2004 11:32 AM >>>>To: James Kempf; Shehzad Merchant; capwap@frascone.com >>>>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; >>>>Dorothy.Gellert@nokia.com; Inderpreet Singh >>>>Subject: RE: [Capwap] So many architectures, so little >>> >>time... - take >> >>>>2 >>>> >>>> >>>>It may be possible to achieve such interoperability within the >>>>split-MAC family or within the local-MAC family. It would sbe very >>>>hard to achieve that between local and split MAC families. >>>> >>>>For example, if vendor X's WTP terminates 802.11 ctrl/mgmt >>> >>packets and >> >>> >>>>vendor Y's AC expects the 802.11 mgmt packets to come to >>> >>it, there's >> >>>>no way you can be interoperable. >>>> >>>>Or are we planning to specify ONE architecture ? >>>>The last thing IETF should do is mandate an implementation. >>>> >>>>I think a modest and reasonable goal is to come up with a protocol >>>>that allows sufficient flexbility so that vendors with splitMAC >>>>architectures can transfer most of the information they care about >>>>between the WTP and AC. >>>> >>>>Just my $0.02 ... >>>> >>>> >>>>Abhijit Choudhury >>>> >>>> >>>>-----Original Message----- >>>>From: capwap-admin@frascone.com >>> >>[mailto:capwap-admin@frascone.com] On >> >>>>Behalf Of James Kempf >>>>Sent: Wednesday, August 04, 2004 3:29 PM >>>>To: Shehzad Merchant; capwap@frascone.com >>>>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; >>>>Dorothy.Gellert@nokia.com; Inderpreet Singh >>>>Subject: Re: [Capwap] So many architectures, so little >>> >>time... - take >> >>>>2 >>>> >>>> >>>>As a potential customer, let me put it concretely. I want >>> >>to be able >> >>>>to buy my access points from Vendor X and my switch from >>> >>Vendor Y and >> >>>>plug the two together and have them work without any configuration. >>>>Also, I'd like to be able to buy switches from Vendor Y and >>> >>Vendor Z >> >>>>and be able to plug them into my network at various places and have >>>>them interoperate. >>>> >>>> jak >>>> >>>> >>>>----- Original Message ----- >>>>From: "Shehzad Merchant" >>>>To: >>>>Cc: ; ; >>>>; ; "Inderpreet >>>>Singh" >>>> >>>>Sent: Wednesday, August 04, 2004 3:19 PM >>>>Subject: RE: [Capwap] So many architectures, so little >>> >>time... - take >> >>>>2 >>>> >>>> >>>> >>>> >>>>>I think the implementation variations even with the split MAC may >>>>>cover a broad spectrum. As such its important to clearly >>>> >>articulate >> >>>>>what aspects >>>> >>>>of >>>> >>>> >>>>>interoperability we are targetting. Is it truly just >>>>>control/management or is it interoperability between disparate >>>>>implementations of the split MAC, i.e. mix and match >>>> >>>>operation of WTP >>>> >>>> >>>>>and ACs of all variants within this category. >>>>> >>>>>I suspect for the latter we may have to arrive at some >>>> >>consensus on >> >>>>>what particular implementations we are targeting >>>> >>>>interoperability for. >>>> >>>> >>>> >>>>>If so, ultimately this problem statement could become part of the >>>>>charter. >>>>> >>>>>-Shehzad >>>>> >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: capwap-admin@frascone.com >>>> >>>>[mailto:capwap-admin@frascone.com] On >>>>Behalf >>>> >>>> >>>>>Of Dorothy.Gellert@nokia.com >>>>>Sent: Wednesday, August 04, 2004 11:53 AM >>>>>To: isingh@chantrynetworks.com; capwap@frascone.com >>>>>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com >>>>>Subject: RE: [Capwap] So many architectures, so little >>>> >>>>time... - take >>>> >>>> >>>>>2 >>>>> >>>>>I believe this is the consensus, to scope the charter to >>>> >>>>Centralized >>>> >>>> >>>>>Architecture and LocalMAC and Split MAC. >>>>> >>>>>I'll update the charter with this change after the CAPWAP >>>> >>>>WG Mtg. If >>>> >>>> >>>>>there is resistance to this idea, please post to the list. >>>>> >>>>>Regards >>>>>Dorothy >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: capwap-admin@frascone.com >>>>> >>>>[mailto:capwap-admin@frascone.com]On >>>> >>>> >>>>>>Behalf Of ext Inderpreet Singh >>>>>>Sent: Tuesday, August 03, 2004 9:40 PM >>>>>>To: capwap@frascone.com >>>>>>Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David >>>>>>(Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) >>>>>>Subject: RE: [Capwap] So many architectures, so little time... - >>>>>>take 2 >>>>>> >>>>>> >>>>>>The issue(s) at hand and my opinions are: >>>>>> >>>>>>1. Do we explicitly state in the re-charter which >>>>> >>>>architecture the >>>> >>>> >>>>>>WG should consider? I think yes. I propose Centralized >>>>> >>>>architecture >>>> >>>> >>>> >>>>>>only. Autonomous and Distributed should be out of scope >>>>> >>>>based on the >>>> >>>> >>>> >>>>>>same reasons as per prior postings. >>>>>> >>>>>>2. Within Centralized do we focus on all three sub >>>>> >>>>architectures or >>>> >>>> >>>>>>a subset? Remote MAC should be excluded because if I am not >>>>>>mistaken, the connectivity constraint between the WTP and >>>>> >>>>the AC is >>>> >>>> >>>>>>"direct connect". >>>>>>That being the case and that no IP layer is involved, it doesn't >>>>> >>>>seem >>>> >>>> >>>>>>clear what kind of protocol would help with interoperability. I am >>>>> >>>>>>concerned about the impact, dependencies and interaction with the >>>>>>recently constituted IEEE Study group on AP >>>>> >>>>functionality on the >>>> >>>> >>>>>>Split MAC architectures. Furthermore, there are some >>>>> >>>>pretty drastic >>>> >>>> >>>>>>differences on how the vendors have chosen to split the >>>>> >>>>mac. Those >>>> >>>> >>>>>>differences will need to be worked out before designing a >>>>> >>>>protocol. >>>> >>>> >>>>>>So, if the low hanging fruit strategy (as James suggested) for >>>>>>protocol development and progress is the way to go, then I think >>>>>>prioritizing on a protocol for Local MAC is a no brainer. >>>>> >>>>So as far >>>> >>>> >>>>>>as focus, I feel we should do Local and Split and in that order. >>>>>> >>>>>>3. This is not a re-chartering issue but is a response to Pat's >>>>>>suggestion that a protocol that just sends the 802.11 MAC frames >>>>> >>>>>>from the AP to the AC would work. I think possibly, yes. >>>>> >>>> >>>>But again >>>> >>>> >>>> >>>>>>the complications of splitting the MAC in an >>>>> >>>>interoperable way will >>>> >>>> >>>>>>be an issue. Also, you may note in the draft to which >>>>> >>>>you refer, we >>>> >>>> >>>> >>>>>>included a capabilities exchange phase. I had thought of >>>>> >>>>including >>>> >>>> >>>>>>in the capability exchange such things as "AP supports Local MAC" >>>>>>and "AP supports Split MAC", but didn't put it in because the >>>>>>Taxonomy work was still in progress. Now that it is pretty much >>>>>>done we could surely include that. But again...let's recharter >>>>>>first. >>>>>> >>>>>>Thanks. Do people agree with 1 & 2? >>>>>> >>>>>>--- >>>>>>Inderpreet Singh >>>>>>Chantry Networks >>>>>>isingh@chantrynetworks.com >>>>>>Cell: 416-831-3705 >>>>>> >>>>>>-----Original Message----- >>>>>>From: capwap-admin@frascone.com >>>>> >>>>[mailto:capwap-admin@frascone.com] >>>> >>>> >>>>>>On Behalf Of Pat R. Calhoun >>>>>>Sent: Tuesday, August 03, 2004 6:04 PM >>>>>>To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com; >>>>>>capwap@frascone.com >>>>>>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com >>>>>>Subject: [Capwap] So many architectures, so little >>>>> >>>>time... - take 2 >>>> >>>> >>>>>>After reading Lily's response to Jim, I realize that I >>>>> >>>>fell down the >>>> >>>> >>>> >>>>>>same trap. Local MAC is also a centralized approach, and so my >>>>>>previous response was not complete. I believe the real >>>>> >>>>question, in >>>> >>>> >>>>>>my mind, is whether we need to address either the Local >>>>> >>>>or the Split >>>> >>>> >>>> >>>>>>MAC architecture. >>>>>> >>>>>>Just looking at the Architecture Consideration tables (7 and >>>>>>10) in the >>>>>>specification, the >>>>>>main difference (at a high level) between both approaches >>>>> >>>>is where >>>> >>>> >>>>>>the 802.11 management terminates. For Local MAC, it's in the WTP, >>>>>>while for SPlit MAC, it's in the AC. >>>>>> >>>>>>However, looking at table 8, most Local MAC approaches share STA >>>>>>state between both the WTP and the AC. So clearly there is some >>>>>>signalling protocol between both the WTP and the AC. >>>>>> >>>>>>Looking at one example of a Local MAC protocol (see >>>>>> >>>>> >>>http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), >>> >>> >>>>>there is a protocol message >>>>>that corresponds for every 802.11 MAC management event. So >>>> >>when a STA >> >> >>>>>associates, the AP breaks the message apart and creates an new >>>>>protocol PDU, which contains components found in the association >>>>>request. I suspect that most Local MAC approaches do >>>> >>something very >> >>>>>similar. >>>>> >>>>>So if a protocol simply tunnels the 802.11 MAC management >>>> >>frames from >> >> >>>>>the WTP to the AC, it allows supports both approaches. For >>>> >>Local MAC, >> >> >>>>>they get what they want via the 802.11 frame, and this also works >>>>>fine for Split MAC, which needs access to the MAC >>>> >>management frame. >> >>>>>What would be required in such a protocol is a way for the AP to >>>>>communicate whether it will be providing very specific functions - >>>>>basically a capabilities negotiation approach. >>>>> >>>>>So I do believe that there is a way to address both architectures >>>>>using a single protocol. >>>>> >>>>>Thoughts? >>>>> >>>>>PatC >>>>> >>>>>_______________________________________________ >>>>>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 >>>_______________________________________________ >>>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 >>>_______________________________________________ >>>Capwap mailing list >>>Capwap@frascone.com >>>http://mail.frascone.com/mailman/listinfo/capwap >> >> >>-- >>Shankar Narayanaswamy, Ph.D. >>wireless@shankar.org Mobile: +1 650-387-4593 >>http://www.shankar.org E-Fax: +1 253-498-8372 >> >>_______________________________________________ >>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 > > -- Shankar Narayanaswamy, Ph.D. wireless@shankar.org Mobile: +1 650-387-4593 http://www.shankar.org E-Fax: +1 253-498-8372 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Aug 12 05:31:00 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15919 for ; Thu, 12 Aug 2004 05:30:59 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 54A132034B; Thu, 12 Aug 2004 05:16:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C6ACB20C52; Thu, 12 Aug 2004 05:16:06 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EE63320C52 for ; Thu, 12 Aug 2004 05:15:55 -0400 (EDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [192.11.222.161]) by mail.frascone.com (Postfix) with ESMTP id E1B4F2034B for ; Thu, 12 Aug 2004 05:15:53 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i7C9UTYl024933 for ; Thu, 12 Aug 2004 04:30:29 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 12 Aug 2004 11:30:28 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15504F2A512@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Shankar Narayanaswamy , Dorothy.Gellert@nokia.com Cc: capwap@frascone.com Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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: Thu, 12 Aug 2004 11:30:27 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > -----Original Message----- > From: Shankar Narayanaswamy [mailto:wireless@shankar.org] > Sent: donderdag 12 augustus 2004 05:13 > To: Dorothy.Gellert@nokia.com > Cc: capwap@frascone.com > Subject: [Capwap] Re: Data plane and control plane separation in Split > MAC > > > The parameters by which the data plane communicates such as > authentication/security info, destination switch (if any) for data > frames, etc, are communicated by the control plane. Hence the need for > some architectural assumptions regarding the data plane even if the > focus is on the control plane. > > Or at least a decision on the data plane architectures to be > supported. > So... to me that sounds that we may potentially do an IMPLIED agreement on the architecture for data plane, based on the capabilities we define in the standards track control and provisioning protocol. That would be fine with me. But we should NOT get bogged down in that data plane stuff, or at least that to me seems to be the wrong focus. Bert > -s > > Dorothy.Gellert@nokia.com wrote: > > Good point. Can we have the volunteers that submitted > architectures for the taxonomy draft weigh in on this issue? > > > > Also another point to consider is that we don't have to > implement *every* AP function in the first release of the > CAPWAP protocol. One of our charter goals is to start with > the minimal set of functionality needed to provide control. > We have a "desirable" category where we can put objectives > that can be met with a later release or extension. > > > > Dorothy > > > >>-----Original Message----- > >>From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > >>Behalf Of ext Yang, Lily L > >>Sent: Tuesday, August 10, 2004 6:13 PM > >>To: Sudhanshu Jain; Shehzad Merchant; Shankar Narayanaswamy; Abhijit > >>Choudhury > >>Cc: capwap@frascone.com > >>Subject: RE: [Capwap] So many architectures, so little > >>time... - take 2 > >> > >> > >>The question in my mind is: Can data plane and control plane > >>be cleanly > >>separated for Split MAC? I know it is feasible for Local > MAC, but not > >>sure about Split MAC. > >>Any insight? > >> > >>-----Original Message----- > >>From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On > >>Behalf Of Sudhanshu Jain > >>Sent: Tuesday, August 10, 2004 11:55 AM > >>To: Shehzad Merchant; Shankar Narayanaswamy; Abhijit Choudhury > >>Cc: capwap@frascone.com > >>Subject: RE: [Capwap] So many architectures, so little > >>time... - take 2 > >> > >>I fully agree with Shehzad. We need to separate the control and data > >>plane. Control plane should provide the framework to use one > >>of several > >>tunneling protocol. > >> > >>On data plane, if we need to define a new layer2/layer3 level > >>tunneling > >>protocol, it should be separate work from control protocol work. > >> > >>-Suds > >> > >> > >>-----Original Message----- > >>From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On > >>Behalf Of Shehzad Merchant > >>Sent: Tuesday, August 10, 2004 11:13 AM > >>To: Shankar Narayanaswamy; Abhijit Choudhury > >>Cc: capwap@frascone.com > >>Subject: RE: [Capwap] So many architectures, so little > >>time... - take 2 > >> > >>Additionally, for data tunneling one needs a lightweight > >>mechanism that > >>may > >>not necessarily have the same requirements as that for control and > >>management. For example, one would want to limit the tunneling and > >>processing overhead on data packets to a minimum. Control and > >>management > >>may > >>be more tolerant of tunneling/security/etc. overhead. > >>Besides, there are > >>plenty of standards in place for data tunneling. We may > potentially be > >>able > >>to leverage off that work itself without having to invent > yet another > >>tunneling mechanism for data. > >> > >>-S > >> > >> > >>-----Original Message----- > >>From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On > >>Behalf > >>Of Shankar Narayanaswamy > >>Sent: Tuesday, August 10, 2004 10:30 AM > >>To: Abhijit Choudhury > >>Cc: capwap@frascone.com > >>Subject: Re: [Capwap] So many architectures, so little > >>time... - take 2 > >> > >>On the first point: not necessarily. If data packets are > encapsulated > >>802.11 data frames, then there is no need to protect them > on the wire > >>any > >>more than they were encrypted over the air. > >> > >>But control and management packets will need protection > over the wired > >>network and therefore possibly a different tunneling protocol. > >> > >>On the second point (standard way of packet exchange): yes! > >> > >>-s > >> > >>Abhijit Choudhury wrote: > >> > >>>The same tunneling protocol that moves control and > >> > >>management packets > >> > >>>from the WTP to the AC should be used to tunnel data > >> > >>packets as well. > >> > >> > >>>We would specify message exchanges to do control, provisioning and > >>>capability advertisement between WTPs and the AC. But all of this > >>>would be within the unified CAPWAP protocol that moves all packets > >>>including data between the WTP and AC. Vendors currently > >> > >>use LWAPP, > >> > >>>GRE, IP and some proprietary encapsulations to achieve this. This > >>>group would come up with a "standard" way of doing this exchange. > >>> > >>>At least that was my understanding.... > >>> > >>>Regards, > >>>Abhijit > >>> > >>>-----Original Mssage----- > >>>From: capwap-admin@frascone.com > >> > >>[mailto:capwap-admin@frascone.com] On > >> > >>>Behalf Of Wijnen, Bert (Bert) > >>>Sent: Monday, August 09, 2004 6:14 AM > >>>To: 'Yang, Lily L'; Burbank, Jack L.; Victor Lin; Bob O'Hara; > >>>capwap@frascone.com > >>>Subject: RE: [Capwap] So many architectures, so little > >> > >>time... - take > >> > >>>2 > >>> > >>> > >>>Not sure who is confused... probably me... > >>> > >>>My understanding was/is that IF we do re-charter for CAPWAP > >> > >>protocol > >> > >>>work, that it is then a NM protocol for "Control and > >> > >>Provisioning" and > >> > >> > >>>not any of the related stuff that moves the data from WTP to AC. > >>> > >>>Is everybody in agreement with that understanding. > >>> > >>>Thanks, > >>>Bert > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Yang, Lily L [mailto:lily.l.yang@intel.com] > >>>>Sent: maandag 9 augustus 2004 08:14 > >>>>To: Burbank, Jack L.; Victor Lin ; Bob O'Hara ; > capwap@frascone.com > >>>>Subject: RE: [Capwap] So many architectures, so little > >>> > >>time... - take > >> > >>>>2 > >>>> > >>>> > >>>>I think setting the re-charter scope to develop a single > >>> > >>protocol that > >> > >>> > >>>>allows interoperability between Local and Split MAC is a > reasonable > >>>>tradeoff: > >>>>We exclude remote MAC because the constraint it imposes is very > >>>>different from the rest and the benefit of including it is very > >>>>little. But Local and Split MAC are reasonably close and > hence the > >>>>effort may be incremental only. > >>>>As many people noted, as of today, there is no single clear > >>> > >>definition > >> > >> > >>>>of what "Local MAC" and "Split MAC" really means yet. Each > >>> > >>vendor has > >> > >>>>different definitions and some debate needs to happen so > >>> > >>that the WG > >> > >>>>can reach consensus on what exactly that means, and what kinds of > >>>>flexibility we want to retain within each class of > >>> > >>architecture, and > >> > >>>>what kind of differences we can to resolve and agree up > front. That > >>>>should also be part of the work items for the new WG -- > >>> > >>such agreement > >> > >> > >>>>on the details for each architecture must be documented > >>> > >>somewhere, if > >> > >>>>not separately, then as part of the Protocol document. > >>>> > >>>>-----Original Message----- > >>>>From: capwap-admin@frascone.com > >>> > >>[mailto:capwap-admin@frascone.com] On > >> > >>>>Behalf Of Burbank, Jack L. > >>>>Sent: Thursday, August 05, 2004 12:14 PM > >>>>To: 'Victor Lin '; 'Bob O'Hara '; 'capwap@frascone.com ' > >>>>Subject: RE: [Capwap] So many architectures, so little > >>> > >>time... - take > >> > >>>>2 > >>>> > >>>>I think that interoperability between different > >>> > >>architectures should > >> > >>>>be a requirement, if not the key requirement. As was mentioned > >>>>yesterday, a goal of the IEEE is that they maintain > flexibility in > >>>>terms of how products and architectures are implemented. I > >>> > >>think we > >> > >>>>shouldn't do anything that is contrary to that goal (or > at least we > >>>>should minimize the impact). I think that the goal of > >>> > >>CAPWAP should > >> > >>>>be to retain this type of flexibility by designing a > >>> > >>protocol that can > >> > >> > >>>>maintain this implementation flexibility but enable > >>> > >>interoperability > >> > >>>>between the various architecture implementations (that > after all is > >>>>the key problem with the deployment of these various > >>> > >>architectures - > >> > >>>>lack of interoperability). IMO, if we don't design for > >>>>interoperability between the basic architecture types, it > >>> > >>is debatable > >> > >> > >>>>if something useful would have been accomplished. > >>>> > >>>>Jack Burbank > >>>> > >>>>-----Original Message----- > >>>>From: capwap-admin@frascone.com > >>>>To: Bob O'Hara; capwap@frascone.com > >>>>Sent: 8/5/2004 2:46 PM > >>>>Subject: RE: [Capwap] So many architectures, so little > >>> > >>time... - take > >> > >>>>2 > >>>> > >>>>I agree that we can design a protocol and implement the > >>> > >>product that > >> > >>>>works all architectures. I think the question to CAPWAP is: > >>>> > >>>>Should we make it a requirement in CAPWAP protocol to achieve > >>>>interoperability between different architectures? > >>>> > >>>>It is definitely doable, but I'm not sure if that is the > >>> > >>right thing > >> > >>>>to do.. > >>>> > >>>>Victor > >>>> > >>>>-----Original Message----- > >>>>From: capwap-admin@frascone.com > >>> > >>[mailto:capwap-admin@frascone.com] On > >> > >>>>Behalf Of Bob O'Hara > >>>>Sent: Thursday, August 05, 2004 11:43 AM > >>>>To: capwap@frascone.com > >>>>Subject: RE: [Capwap] So many architectures, so little > >>> > >>time... - take > >> > >>>>2 > >>>> > >>>>I think that interoperability will depend on two things. > >>>>First, it will > >>>>depend on how we define the protocol and the flexibility > >>> > >>for supported > >> > >> > >>>>architectures it incorporates. Second, it will depend on what > >>>>manufacturers implement, i.e., the flexibility they build > >>> > >>into their > >> > >>>>products. > >>>> > >>>>I believe that it is possible to design the protocol for > >>> > >>the required > >> > >>>>flexibility. I know it is possible to implement a > product with the > >>>>required flexibility. > >>>> > >>>>-Bob O'Hara > >>>> > >>>> > >>>>-----Original Message----- > >>>>From: capwap-admin@frascone.com > >>> > >>[mailto:capwap-admin@frascone.com] On > >> > >>>>Behalf Of Abhijit Choudhury > >>>>Sent: Thursday, August 05, 2004 11:32 AM > >>>>To: James Kempf; Shehzad Merchant; capwap@frascone.com > >>>>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; > >>>>Dorothy.Gellert@nokia.com; Inderpreet Singh > >>>>Subject: RE: [Capwap] So many architectures, so little > >>> > >>time... - take > >> > >>>>2 > >>>> > >>>> > >>>>It may be possible to achieve such interoperability within the > >>>>split-MAC family or within the local-MAC family. It > would sbe very > >>>>hard to achieve that between local and split MAC families. > >>>> > >>>>For example, if vendor X's WTP terminates 802.11 ctrl/mgmt > >>> > >>packets and > >> > >>> > >>>>vendor Y's AC expects the 802.11 mgmt packets to come to > >>> > >>it, there's > >> > >>>>no way you can be interoperable. > >>>> > >>>>Or are we planning to specify ONE architecture ? > >>>>The last thing IETF should do is mandate an implementation. > >>>> > >>>>I think a modest and reasonable goal is to come up with a > protocol > >>>>that allows sufficient flexbility so that vendors with splitMAC > >>>>architectures can transfer most of the information they > care about > >>>>between the WTP and AC. > >>>> > >>>>Just my $0.02 ... > >>>> > >>>> > >>>>Abhijit Choudhury > >>>> > >>>> > >>>>-----Original Message----- > >>>>From: capwap-admin@frascone.com > >>> > >>[mailto:capwap-admin@frascone.com] On > >> > >>>>Behalf Of James Kempf > >>>>Sent: Wednesday, August 04, 2004 3:29 PM > >>>>To: Shehzad Merchant; capwap@frascone.com > >>>>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; > >>>>Dorothy.Gellert@nokia.com; Inderpreet Singh > >>>>Subject: Re: [Capwap] So many architectures, so little > >>> > >>time... - take > >> > >>>>2 > >>>> > >>>> > >>>>As a potential customer, let me put it concretely. I want > >>> > >>to be able > >> > >>>>to buy my access points from Vendor X and my switch from > >>> > >>Vendor Y and > >> > >>>>plug the two together and have them work without any > configuration. > >>>>Also, I'd like to be able to buy switches from Vendor Y and > >>> > >>Vendor Z > >> > >>>>and be able to plug them into my network at various > places and have > >>>>them interoperate. > >>>> > >>>> jak > >>>> > >>>> > >>>>----- Original Message ----- > >>>>From: "Shehzad Merchant" > >>>>To: > >>>>Cc: ; ; > >>>>; ; > "Inderpreet > >>>>Singh" > >>>> > >>>>Sent: Wednesday, August 04, 2004 3:19 PM > >>>>Subject: RE: [Capwap] So many architectures, so little > >>> > >>time... - take > >> > >>>>2 > >>>> > >>>> > >>>> > >>>> > >>>>>I think the implementation variations even with the > split MAC may > >>>>>cover a broad spectrum. As such its important to clearly > >>>> > >>articulate > >> > >>>>>what aspects > >>>> > >>>>of > >>>> > >>>> > >>>>>interoperability we are targetting. Is it truly just > >>>>>control/management or is it interoperability between disparate > >>>>>implementations of the split MAC, i.e. mix and match > >>>> > >>>>operation of WTP > >>>> > >>>> > >>>>>and ACs of all variants within this category. > >>>>> > >>>>>I suspect for the latter we may have to arrive at some > >>>> > >>consensus on > >> > >>>>>what particular implementations we are targeting > >>>> > >>>>interoperability for. > >>>> > >>>> > >>>> > >>>>>If so, ultimately this problem statement could become > part of the > >>>>>charter. > >>>>> > >>>>>-Shehzad > >>>>> > >>>>> > >>>>> > >>>>>-----Original Message----- > >>>>>From: capwap-admin@frascone.com > >>>> > >>>>[mailto:capwap-admin@frascone.com] On > >>>>Behalf > >>>> > >>>> > >>>>>Of Dorothy.Gellert@nokia.com > >>>>>Sent: Wednesday, August 04, 2004 11:53 AM > >>>>>To: isingh@chantrynetworks.com; capwap@frascone.com > >>>>>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > >>>>>Subject: RE: [Capwap] So many architectures, so little > >>>> > >>>>time... - take > >>>> > >>>> > >>>>>2 > >>>>> > >>>>>I believe this is the consensus, to scope the charter to > >>>> > >>>>Centralized > >>>> > >>>> > >>>>>Architecture and LocalMAC and Split MAC. > >>>>> > >>>>>I'll update the charter with this change after the CAPWAP > >>>> > >>>>WG Mtg. If > >>>> > >>>> > >>>>>there is resistance to this idea, please post to the list. > >>>>> > >>>>>Regards > >>>>>Dorothy > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>-----Original Message----- > >>>>>>From: capwap-admin@frascone.com > >>>>> > >>>>[mailto:capwap-admin@frascone.com]On > >>>> > >>>> > >>>>>>Behalf Of ext Inderpreet Singh > >>>>>>Sent: Tuesday, August 03, 2004 9:40 PM > >>>>>>To: capwap@frascone.com > >>>>>>Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David > >>>>>>(Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > >>>>>>Subject: RE: [Capwap] So many architectures, so little > time... - > >>>>>>take 2 > >>>>>> > >>>>>> > >>>>>>The issue(s) at hand and my opinions are: > >>>>>> > >>>>>>1. Do we explicitly state in the re-charter which > >>>>> > >>>>architecture the > >>>> > >>>> > >>>>>>WG should consider? I think yes. I propose Centralized > >>>>> > >>>>architecture > >>>> > >>>> > >>>> > >>>>>>only. Autonomous and Distributed should be out of scope > >>>>> > >>>>based on the > >>>> > >>>> > >>>> > >>>>>>same reasons as per prior postings. > >>>>>> > >>>>>>2. Within Centralized do we focus on all three sub > >>>>> > >>>>architectures or > >>>> > >>>> > >>>>>>a subset? Remote MAC should be excluded because if I am not > >>>>>>mistaken, the connectivity constraint between the WTP and > >>>>> > >>>>the AC is > >>>> > >>>> > >>>>>>"direct connect". > >>>>>>That being the case and that no IP layer is involved, it doesn't > >>>>> > >>>>seem > >>>> > >>>> > >>>>>>clear what kind of protocol would help with > interoperability. I am > >>>>> > >>>>>>concerned about the impact, dependencies and > interaction with the > >>>>>>recently constituted IEEE Study group on AP > >>>>> > >>>>functionality on the > >>>> > >>>> > >>>>>>Split MAC architectures. Furthermore, there are some > >>>>> > >>>>pretty drastic > >>>> > >>>> > >>>>>>differences on how the vendors have chosen to split the > >>>>> > >>>>mac. Those > >>>> > >>>> > >>>>>>differences will need to be worked out before designing a > >>>>> > >>>>protocol. > >>>> > >>>> > >>>>>>So, if the low hanging fruit strategy (as James suggested) for > >>>>>>protocol development and progress is the way to go, > then I think > >>>>>>prioritizing on a protocol for Local MAC is a no brainer. > >>>>> > >>>>So as far > >>>> > >>>> > >>>>>>as focus, I feel we should do Local and Split and in that order. > >>>>>> > >>>>>>3. This is not a re-chartering issue but is a response to Pat's > >>>>>>suggestion that a protocol that just sends the 802.11 > MAC frames > >>>>> > >>>>>>from the AP to the AC would work. I think possibly, yes. > >>>>> > >>>> > >>>>But again > >>>> > >>>> > >>>> > >>>>>>the complications of splitting the MAC in an > >>>>> > >>>>interoperable way will > >>>> > >>>> > >>>>>>be an issue. Also, you may note in the draft to which > >>>>> > >>>>you refer, we > >>>> > >>>> > >>>> > >>>>>>included a capabilities exchange phase. I had thought of > >>>>> > >>>>including > >>>> > >>>> > >>>>>>in the capability exchange such things as "AP supports > Local MAC" > >>>>>>and "AP supports Split MAC", but didn't put it in because the > >>>>>>Taxonomy work was still in progress. Now that it is > pretty much > >>>>>>done we could surely include that. But again...let's recharter > >>>>>>first. > >>>>>> > >>>>>>Thanks. Do people agree with 1 & 2? > >>>>>> > >>>>>>--- > >>>>>>Inderpreet Singh > >>>>>>Chantry Networks > >>>>>>isingh@chantrynetworks.com > >>>>>>Cell: 416-831-3705 > >>>>>> > >>>>>>-----Original Message----- > >>>>>>From: capwap-admin@frascone.com > >>>>> > >>>>[mailto:capwap-admin@frascone.com] > >>>> > >>>> > >>>>>>On Behalf Of Pat R. Calhoun > >>>>>>Sent: Tuesday, August 03, 2004 6:04 PM > >>>>>>To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com; > >>>>>>capwap@frascone.com > >>>>>>Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > >>>>>>Subject: [Capwap] So many architectures, so little > >>>>> > >>>>time... - take 2 > >>>> > >>>> > >>>>>>After reading Lily's response to Jim, I realize that I > >>>>> > >>>>fell down the > >>>> > >>>> > >>>> > >>>>>>same trap. Local MAC is also a centralized approach, and so my > >>>>>>previous response was not complete. I believe the real > >>>>> > >>>>question, in > >>>> > >>>> > >>>>>>my mind, is whether we need to address either the Local > >>>>> > >>>>or the Split > >>>> > >>>> > >>>> > >>>>>>MAC architecture. > >>>>>> > >>>>>>Just looking at the Architecture Consideration tables (7 and > >>>>>>10) in the > >>>>>>specification, the > >>>>>>main difference (at a high level) between both approaches > >>>>> > >>>>is where > >>>> > >>>> > >>>>>>the 802.11 management terminates. For Local MAC, it's > in the WTP, > >>>>>>while for SPlit MAC, it's in the AC. > >>>>>> > >>>>>>However, looking at table 8, most Local MAC approaches > share STA > >>>>>>state between both the WTP and the AC. So clearly there is some > >>>>>>signalling protocol between both the WTP and the AC. > >>>>>> > >>>>>>Looking at one example of a Local MAC protocol (see > >>>>>> > >>>>> > >>>http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > >>> > >>> > >>>>>there is a protocol message > >>>>>that corresponds for every 802.11 MAC management event. So > >>>> > >>when a STA > >> > >> > >>>>>associates, the AP breaks the message apart and creates an new > >>>>>protocol PDU, which contains components found in the association > >>>>>request. I suspect that most Local MAC approaches do > >>>> > >>something very > >> > >>>>>similar. > >>>>> > >>>>>So if a protocol simply tunnels the 802.11 MAC management > >>>> > >>frames from > >> > >> > >>>>>the WTP to the AC, it allows supports both approaches. For > >>>> > >>Local MAC, > >> > >> > >>>>>they get what they want via the 802.11 frame, and this > also works > >>>>>fine for Split MAC, which needs access to the MAC > >>>> > >>management frame. > >> > >>>>>What would be required in such a protocol is a way for the AP to > >>>>>communicate whether it will be providing very specific > functions - > >>>>>basically a capabilities negotiation approach. > >>>>> > >>>>>So I do believe that there is a way to address both > architectures > >>>>>using a single protocol. > >>>>> > >>>>>Thoughts? > >>>>> > >>>>>PatC > >>>>> > >>>>>_______________________________________________ > >>>>>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 >>>_______________________________________________ >>>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 >>>_______________________________________________ >>>Capwap mailing list >>>Capwap@frascone.com >>>http://mail.frascone.com/mailman/listinfo/capwap >> >> >>-- >>Shankar Narayanaswamy, Ph.D. >>wireless@shankar.org Mobile: +1 650-387-4593 >>http://www.shankar.org E-Fax: +1 253-498-8372 >> >>_______________________________________________ >>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 > > -- Shankar Narayanaswamy, Ph.D. wireless@shankar.org Mobile: +1 650-387-4593 http://www.shankar.org E-Fax: +1 253-498-8372 _______________________________________________ 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 Aug 12 13:45:59 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18738 for ; Thu, 12 Aug 2004 13:45:58 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9B1EA2034A; Thu, 12 Aug 2004 13:29:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9925B21383; Thu, 12 Aug 2004 13:29:07 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3736F21383 for ; Thu, 12 Aug 2004 13:28:35 -0400 (EDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by mail.frascone.com (Postfix) with ESMTP id CF2462034A for ; Thu, 12 Aug 2004 13:28:32 -0400 (EDT) Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i7CHgRbf025005; Thu, 12 Aug 2004 17:42:27 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i7CHbaAV016250; Thu, 12 Aug 2004 17:37:39 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004081210425411431 ; Thu, 12 Aug 2004 10:42:54 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 12 Aug 2004 10:42:54 -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] Re: Data plane and control plane separation in Split MAC Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE01836F8D@orsmsx408> Thread-Topic: [Capwap] Re: Data plane and control plane separation in Split MAC Thread-Index: AcSATx3ubzyBW0DHT0Oo3dMJW6wbqQAQKFiA From: "Yang, Lily L" To: "Wijnen, Bert (Bert)" , "Shankar Narayanaswamy" , Cc: X-OriginalArrivalTime: 12 Aug 2004 17:42:54.0728 (UTC) FILETIME=[CC2D3880:01C48093] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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, 12 Aug 2004 10:42:53 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable To examine our options of architecture assumptions, let me first put our my definition of data plane and control plane just to make sure we start from the same page: To me, 802.11 data plane means the dath path travelled by the native 802.11 data frames while 802.11 control plane means the data path between 802.11 STA and the 802.11-awared control end point. =20 For both Local and Split MAC, that 802.11-awared control point is AC. So both architecture has the same control path: STA->WTP->AC. The difference is how that control messages are implemented between WTP and AC: Split MAC simply tunneled the 802.11 management frames, while Local MAC translated them into some other non-802.11 forms. Another (implied) difference is that Split MAC largely relies on the AC to respond to those management frames from STA, while Local MAC relies on WTP to respond, but allow AC to be informed of such events as well. So the timing constraint may be more relaxed for local MAC. The question is on the data path. Here is my understanding so far: In Local MAC, the data path is between STA and WTP. From WTP, it can be switched or routed locally, entirely bypassing AC. For Split MAC, My impression has been that the data path is between STA and WTP and AC, because it seems that Split MAC vendors tunnel ALL 802.11 data back to AC, even though I don't see why it has to be that way. Just from the recent discussion, some have hinted that even Split MAC can allow data path terminate at WTP and be "locally" switched without involving AC. Is this true? Can anyone confirm more explicitly and elaborate this for me? To summarize: Common control path: STA->WTP->AC. (but control messages between WTP<->AC are done diffrently) Local MAC data path: STA->WTP. Split MAC data path: STA->WTP->AC or STA->WTP (This needs to be clarified). My hunch is that CAPWAP protocol would have to allow the flexibility in datapath, for either architecture (Split or Local). So in that case, it doesn't really matter if it is Split or Local, it should allow datapath to be configurable any way. In that sense, I agree with what Shankar was saying here. This seems also suggest that YES, we can cleanly separate data plane and control plane here. But that doesn't mean any discussion around data plane is out of scope -- because guess what? Why do we need the control plane at the first place? To control and configure the data plane! So understanding what data plane needs would drive our discussion for the control plane and CAPWAP. > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of Wijnen, Bert (Bert) > Sent: Thursday, August 12, 2004 2:30 AM > To: Shankar Narayanaswamy; Dorothy.Gellert@nokia.com > Cc: capwap@frascone.com > Subject: RE: [Capwap] Re: Data plane and control plane=20 > separation in Split MAC >=20 > > -----Original Message----- > > From: Shankar Narayanaswamy [mailto:wireless@shankar.org] > > Sent: donderdag 12 augustus 2004 05:13 > > To: Dorothy.Gellert@nokia.com > > Cc: capwap@frascone.com > > Subject: [Capwap] Re: Data plane and control plane=20 > separation in Split=20 > > MAC > >=20 > >=20 > > The parameters by which the data plane communicates such as=20 > > authentication/security info, destination switch (if any) for data=20 > > frames, etc, are communicated by the control plane. Hence=20 > the need for=20 > > some architectural assumptions regarding the data plane even if the=20 > > focus is on the control plane. > >=20 > > Or at least a decision on the data plane architectures to be=20 > > supported. > >=20 > So... to me that sounds that we may potentially do an IMPLIED=20 > agreement on the architecture for data plane, based on the=20 > capabilities we define in the standards track control and=20 > provisioning protocol. >=20 > That would be fine with me. But we should NOT get bogged down=20 > in that data plane stuff, or at least that to me seems to be=20 > the wrong focus. >=20 > Bert > > -s > >=20 > > Dorothy.Gellert@nokia.com wrote: > > > Good point. Can we have the volunteers that submitted > > architectures for the taxonomy draft weigh in on this issue? =20 > > >=20 > > > Also another point to consider is that we don't have to > > implement *every* AP function in the first release of the CAPWAP=20 > > protocol. One of our charter goals is to start with > > the minimal set of functionality needed to provide control. =20 > > We have a "desirable" category where we can put objectives=20 > that can be=20 > > met with a later release or extension. > > >=20 > > > Dorothy > > >=20 > > >>-----Original Message----- > > >>From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com]On > > >>Behalf Of ext Yang, Lily L > > >>Sent: Tuesday, August 10, 2004 6:13 PM > > >>To: Sudhanshu Jain; Shehzad Merchant; Shankar=20 > Narayanaswamy; Abhijit=20 > > >>Choudhury > > >>Cc: capwap@frascone.com > > >>Subject: RE: [Capwap] So many architectures, so little time... -=20 > > >>take 2 > > >> > > >> > > >>The question in my mind is: Can data plane and control plane be=20 > > >>cleanly separated for Split MAC? I know it is feasible for Local > > MAC, but not > > >>sure about Split MAC.=20 > > >>Any insight? > > >> > > >>-----Original Message----- > > >>From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On > > >>Behalf Of Sudhanshu Jain > > >>Sent: Tuesday, August 10, 2004 11:55 AM > > >>To: Shehzad Merchant; Shankar Narayanaswamy; Abhijit Choudhury > > >>Cc: capwap@frascone.com > > >>Subject: RE: [Capwap] So many architectures, so little time... -=20 > > >>take 2 > > >> > > >>I fully agree with Shehzad. We need to separate the=20 > control and data=20 > > >>plane. Control plane should provide the framework to use one of=20 > > >>several tunneling protocol. > > >> > > >>On data plane, if we need to define a new layer2/layer3 level=20 > > >>tunneling protocol, it should be separate work from=20 > control protocol=20 > > >>work. > > >> > > >>-Suds > > >> > > >> > > >>-----Original Message----- > > >>From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On > > >>Behalf Of Shehzad Merchant > > >>Sent: Tuesday, August 10, 2004 11:13 AM > > >>To: Shankar Narayanaswamy; Abhijit Choudhury > > >>Cc: capwap@frascone.com > > >>Subject: RE: [Capwap] So many architectures, so little time... -=20 > > >>take 2 > > >> > > >>Additionally, for data tunneling one needs a lightweight=20 > mechanism=20 > > >>that may not necessarily have the same requirements as that for=20 > > >>control and management. For example, one would want to limit the=20 > > >>tunneling and processing overhead on data packets to a minimum.=20 > > >>Control and management may be more tolerant of=20 > > >>tunneling/security/etc. overhead. > > >>Besides, there are > > >>plenty of standards in place for data tunneling. We may > > potentially be > > >>able > > >>to leverage off that work itself without having to invent > > yet another > > >>tunneling mechanism for data.=20 > > >> > > >>-S > > >> > > >> > > >>-----Original Message----- > > >>From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On > > >>Behalf > > >>Of Shankar Narayanaswamy > > >>Sent: Tuesday, August 10, 2004 10:30 AM > > >>To: Abhijit Choudhury > > >>Cc: capwap@frascone.com > > >>Subject: Re: [Capwap] So many architectures, so little time... -=20 > > >>take 2 > > >> > > >>On the first point: not necessarily. If data packets are > > encapsulated > > >>802.11 data frames, then there is no need to protect them > > on the wire > > >>any > > >>more than they were encrypted over the air. > > >> > > >>But control and management packets will need protection > > over the wired > > >>network and therefore possibly a different tunneling protocol. > > >> > > >>On the second point (standard way of packet exchange): yes! > > >> > > >>-s > > >> > > >>Abhijit Choudhury wrote: > > >> > > >>>The same tunneling protocol that moves control and > > >> > > >>management packets > > >> > > >>>from the WTP to the AC should be used to tunnel data > > >> > > >>packets as well. > > >> > > >> > > >>>We would specify message exchanges to do control,=20 > provisioning and=20 > > >>>capability advertisement between WTPs and the AC. But=20 > all of this=20 > > >>>would be within the unified CAPWAP protocol that moves=20 > all packets=20 > > >>>including data between the WTP and AC. Vendors currently > > >> > > >>use LWAPP, > > >> > > >>>GRE, IP and some proprietary encapsulations to achieve=20 > this. This=20 > > >>>group would come up with a "standard" way of doing this exchange. > > >>> > > >>>At least that was my understanding.... > > >>> > > >>>Regards, > > >>>Abhijit > > >>> > > >>>-----Original Mssage----- > > >>>From: capwap-admin@frascone.com > > >> > > >>[mailto:capwap-admin@frascone.com] On > > >> > > >>>Behalf Of Wijnen, Bert (Bert) > > >>>Sent: Monday, August 09, 2004 6:14 AM > > >>>To: 'Yang, Lily L'; Burbank, Jack L.; Victor Lin; Bob O'Hara;=20 > > >>>capwap@frascone.com > > >>>Subject: RE: [Capwap] So many architectures, so little > > >> > > >>time... - take > > >> > > >>>2 > > >>> > > >>> > > >>>Not sure who is confused... probably me... > > >>> > > >>>My understanding was/is that IF we do re-charter for CAPWAP > > >> > > >>protocol > > >> > > >>>work, that it is then a NM protocol for "Control and > > >> > > >>Provisioning" and > > >> > > >> > > >>>not any of the related stuff that moves the data from WTP to AC. > > >>> > > >>>Is everybody in agreement with that understanding. > > >>> > > >>>Thanks, > > >>>Bert > > >>> > > >>> > > >>> > > >>>>-----Original Message----- > > >>>>From: Yang, Lily L [mailto:lily.l.yang@intel.com] > > >>>>Sent: maandag 9 augustus 2004 08:14 > > >>>>To: Burbank, Jack L.; Victor Lin ; Bob O'Hara ; > > capwap@frascone.com > > >>>>Subject: RE: [Capwap] So many architectures, so little > > >>> > > >>time... - take > > >> > > >>>>2 > > >>>> > > >>>> > > >>>>I think setting the re-charter scope to develop a single > > >>> > > >>protocol that > > >> > > >>> > > >>>>allows interoperability between Local and Split MAC is a > > reasonable > > >>>>tradeoff: > > >>>>We exclude remote MAC because the constraint it imposes is very=20 > > >>>>different from the rest and the benefit of including it is very=20 > > >>>>little. But Local and Split MAC are reasonably close and > > hence the > > >>>>effort may be incremental only. > > >>>>As many people noted, as of today, there is no single clear > > >>> > > >>definition > > >> > > >> > > >>>>of what "Local MAC" and "Split MAC" really means yet. Each > > >>> > > >>vendor has > > >> > > >>>>different definitions and some debate needs to happen so > > >>> > > >>that the WG > > >> > > >>>>can reach consensus on what exactly that means, and=20 > what kinds of=20 > > >>>>flexibility we want to retain within each class of > > >>> > > >>architecture, and > > >> > > >>>>what kind of differences we can to resolve and agree up > > front. That > > >>>>should also be part of the work items for the new WG -- > > >>> > > >>such agreement > > >> > > >> > > >>>>on the details for each architecture must be documented > > >>> > > >>somewhere, if > > >> > > >>>>not separately, then as part of the Protocol document. > > >>>> > > >>>>-----Original Message----- > > >>>>From: capwap-admin@frascone.com > > >>> > > >>[mailto:capwap-admin@frascone.com] On > > >> > > >>>>Behalf Of Burbank, Jack L. > > >>>>Sent: Thursday, August 05, 2004 12:14 PM > > >>>>To: 'Victor Lin '; 'Bob O'Hara '; 'capwap@frascone.com ' > > >>>>Subject: RE: [Capwap] So many architectures, so little > > >>> > > >>time... - take > > >> > > >>>>2 > > >>>> > > >>>>I think that interoperability between different > > >>> > > >>architectures should > > >> > > >>>>be a requirement, if not the key requirement. As was mentioned=20 > > >>>>yesterday, a goal of the IEEE is that they maintain > > flexibility in > > >>>>terms of how products and architectures are implemented. I > > >>> > > >>think we > > >> > > >>>>shouldn't do anything that is contrary to that goal (or > > at least we > > >>>>should minimize the impact). I think that the goal of > > >>> > > >>CAPWAP should > > >> > > >>>>be to retain this type of flexibility by designing a > > >>> > > >>protocol that can > > >> > > >> > > >>>>maintain this implementation flexibility but enable > > >>> > > >>interoperability > > >> > > >>>>between the various architecture implementations (that > > after all is > > >>>>the key problem with the deployment of these various > > >>> > > >>architectures - > > >> > > >>>>lack of interoperability). IMO, if we don't design for=20 > > >>>>interoperability between the basic architecture types, it > > >>> > > >>is debatable > > >> > > >> > > >>>>if something useful would have been accomplished. > > >>>> > > >>>>Jack Burbank > > >>>> > > >>>>-----Original Message----- > > >>>>From: capwap-admin@frascone.com > > >>>>To: Bob O'Hara; capwap@frascone.com > > >>>>Sent: 8/5/2004 2:46 PM > > >>>>Subject: RE: [Capwap] So many architectures, so little > > >>> > > >>time... - take > > >> > > >>>>2 > > >>>> > > >>>>I agree that we can design a protocol and implement the > > >>> > > >>product that > > >> > > >>>>works all architectures. I think the question to CAPWAP is: > > >>>> > > >>>>Should we make it a requirement in CAPWAP protocol to achieve=20 > > >>>>interoperability between different architectures? > > >>>> > > >>>>It is definitely doable, but I'm not sure if that is the > > >>> > > >>right thing > > >> > > >>>>to do.. > > >>>> > > >>>>Victor > > >>>> > > >>>>-----Original Message----- > > >>>>From: capwap-admin@frascone.com > > >>> > > >>[mailto:capwap-admin@frascone.com] On > > >> > > >>>>Behalf Of Bob O'Hara > > >>>>Sent: Thursday, August 05, 2004 11:43 AM > > >>>>To: capwap@frascone.com > > >>>>Subject: RE: [Capwap] So many architectures, so little > > >>> > > >>time... - take > > >> > > >>>>2 > > >>>> > > >>>>I think that interoperability will depend on two things. > > >>>>First, it will > > >>>>depend on how we define the protocol and the flexibility > > >>> > > >>for supported > > >> > > >> > > >>>>architectures it incorporates. Second, it will depend on what=20 > > >>>>manufacturers implement, i.e., the flexibility they build > > >>> > > >>into their > > >> > > >>>>products. > > >>>> > > >>>>I believe that it is possible to design the protocol for > > >>> > > >>the required > > >> > > >>>>flexibility. I know it is possible to implement a > > product with the > > >>>>required flexibility. > > >>>> > > >>>>-Bob O'Hara > > >>>> > > >>>> > > >>>>-----Original Message----- > > >>>>From: capwap-admin@frascone.com > > >>> > > >>[mailto:capwap-admin@frascone.com] On > > >> > > >>>>Behalf Of Abhijit Choudhury > > >>>>Sent: Thursday, August 05, 2004 11:32 AM > > >>>>To: James Kempf; Shehzad Merchant; capwap@frascone.com > > >>>>Cc: bwijnen@lucent.com; mmani@avaya.com;=20 > david.kessens@nokia.com;=20 > > >>>>Dorothy.Gellert@nokia.com; Inderpreet Singh > > >>>>Subject: RE: [Capwap] So many architectures, so little > > >>> > > >>time... - take > > >> > > >>>>2 > > >>>> > > >>>> > > >>>>It may be possible to achieve such interoperability within the=20 > > >>>>split-MAC family or within the local-MAC family. It > > would sbe very > > >>>>hard to achieve that between local and split MAC families. > > >>>> > > >>>>For example, if vendor X's WTP terminates 802.11 ctrl/mgmt > > >>> > > >>packets and > > >> > > >>> > > >>>>vendor Y's AC expects the 802.11 mgmt packets to come to > > >>> > > >>it, there's > > >> > > >>>>no way you can be interoperable. > > >>>> > > >>>>Or are we planning to specify ONE architecture ? > > >>>>The last thing IETF should do is mandate an implementation. > > >>>> > > >>>>I think a modest and reasonable goal is to come up with a > > protocol > > >>>>that allows sufficient flexbility so that vendors with splitMAC=20 > > >>>>architectures can transfer most of the information they > > care about > > >>>>between the WTP and AC. > > >>>> > > >>>>Just my $0.02 ... > > >>>> > > >>>> > > >>>>Abhijit Choudhury > > >>>> > > >>>> > > >>>>-----Original Message----- > > >>>>From: capwap-admin@frascone.com > > >>> > > >>[mailto:capwap-admin@frascone.com] On > > >> > > >>>>Behalf Of James Kempf > > >>>>Sent: Wednesday, August 04, 2004 3:29 PM > > >>>>To: Shehzad Merchant; capwap@frascone.com > > >>>>Cc: bwijnen@lucent.com; mmani@avaya.com;=20 > david.kessens@nokia.com;=20 > > >>>>Dorothy.Gellert@nokia.com; Inderpreet Singh > > >>>>Subject: Re: [Capwap] So many architectures, so little > > >>> > > >>time... - take > > >> > > >>>>2 > > >>>> > > >>>> > > >>>>As a potential customer, let me put it concretely. I want > > >>> > > >>to be able > > >> > > >>>>to buy my access points from Vendor X and my switch from > > >>> > > >>Vendor Y and > > >> > > >>>>plug the two together and have them work without any > > configuration.=20 > > >>>>Also, I'd like to be able to buy switches from Vendor Y and > > >>> > > >>Vendor Z > > >> > > >>>>and be able to plug them into my network at various > > places and have > > >>>>them interoperate. > > >>>> > > >>>> jak > > >>>> > > >>>> > > >>>>----- Original Message ----- > > >>>>From: "Shehzad Merchant" > > >>>>To: > > >>>>Cc: ; ;=20 > > >>>>; ; > > "Inderpreet > > >>>>Singh" > > >>>> > > >>>>Sent: Wednesday, August 04, 2004 3:19 PM > > >>>>Subject: RE: [Capwap] So many architectures, so little > > >>> > > >>time... - take > > >> > > >>>>2 > > >>>> > > >>>> > > >>>> > > >>>> > > >>>>>I think the implementation variations even with the > > split MAC may > > >>>>>cover a broad spectrum. As such its important to clearly > > >>>> > > >>articulate > > >> > > >>>>>what aspects > > >>>> > > >>>>of > > >>>> > > >>>> > > >>>>>interoperability we are targetting. Is it truly just=20 > > >>>>>control/management or is it interoperability between disparate=20 > > >>>>>implementations of the split MAC, i.e. mix and match > > >>>> > > >>>>operation of WTP > > >>>> > > >>>> > > >>>>>and ACs of all variants within this category. > > >>>>> > > >>>>>I suspect for the latter we may have to arrive at some > > >>>> > > >>consensus on > > >> > > >>>>>what particular implementations we are targeting > > >>>> > > >>>>interoperability for. > > >>>> > > >>>> > > >>>> > > >>>>>If so, ultimately this problem statement could become > > part of the > > >>>>>charter. > > >>>>> > > >>>>>-Shehzad > > >>>>> > > >>>>> > > >>>>> > > >>>>>-----Original Message----- > > >>>>>From: capwap-admin@frascone.com > > >>>> > > >>>>[mailto:capwap-admin@frascone.com] On Behalf > > >>>> > > >>>> > > >>>>>Of Dorothy.Gellert@nokia.com > > >>>>>Sent: Wednesday, August 04, 2004 11:53 AM > > >>>>>To: isingh@chantrynetworks.com; capwap@frascone.com > > >>>>>Cc: bwijnen@lucent.com; mmani@avaya.com;=20 > david.kessens@nokia.com > > >>>>>Subject: RE: [Capwap] So many architectures, so little > > >>>> > > >>>>time... - take > > >>>> > > >>>> > > >>>>>2 > > >>>>> > > >>>>>I believe this is the consensus, to scope the charter to > > >>>> > > >>>>Centralized > > >>>> > > >>>> > > >>>>>Architecture and LocalMAC and Split MAC. > > >>>>> > > >>>>>I'll update the charter with this change after the CAPWAP > > >>>> > > >>>>WG Mtg. If > > >>>> > > >>>> > > >>>>>there is resistance to this idea, please post to the list. > > >>>>> > > >>>>>Regards > > >>>>>Dorothy > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>>>-----Original Message----- > > >>>>>>From: capwap-admin@frascone.com > > >>>>> > > >>>>[mailto:capwap-admin@frascone.com]On > > >>>> > > >>>> > > >>>>>>Behalf Of ext Inderpreet Singh > > >>>>>>Sent: Tuesday, August 03, 2004 9:40 PM > > >>>>>>To: capwap@frascone.com > > >>>>>>Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David=20 > > >>>>>>(Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > > >>>>>>Subject: RE: [Capwap] So many architectures, so little > > time... - > > >>>>>>take 2 > > >>>>>> > > >>>>>> > > >>>>>>The issue(s) at hand and my opinions are: > > >>>>>> > > >>>>>>1. Do we explicitly state in the re-charter which > > >>>>> > > >>>>architecture the > > >>>> > > >>>> > > >>>>>>WG should consider? I think yes. I propose Centralized > > >>>>> > > >>>>architecture > > >>>> > > >>>> > > >>>> > > >>>>>>only. Autonomous and Distributed should be out of scope > > >>>>> > > >>>>based on the > > >>>> > > >>>> > > >>>> > > >>>>>>same reasons as per prior postings. > > >>>>>> > > >>>>>>2. Within Centralized do we focus on all three sub > > >>>>> > > >>>>architectures or > > >>>> > > >>>> > > >>>>>>a subset? Remote MAC should be excluded because if I am not=20 > > >>>>>>mistaken, the connectivity constraint between the WTP and > > >>>>> > > >>>>the AC is > > >>>> > > >>>> > > >>>>>>"direct connect". > > >>>>>>That being the case and that no IP layer is involved,=20 > it doesn't > > >>>>> > > >>>>seem > > >>>> > > >>>> > > >>>>>>clear what kind of protocol would help with > > interoperability. I am > > >>>>> > > >>>>>>concerned about the impact, dependencies and > > interaction with the > > >>>>>>recently constituted IEEE Study group on AP > > >>>>> > > >>>>functionality on the > > >>>> > > >>>> > > >>>>>>Split MAC architectures. Furthermore, there are some > > >>>>> > > >>>>pretty drastic > > >>>> > > >>>> > > >>>>>>differences on how the vendors have chosen to split the > > >>>>> > > >>>>mac. Those > > >>>> > > >>>> > > >>>>>>differences will need to be worked out before designing a > > >>>>> > > >>>>protocol. > > >>>> > > >>>> > > >>>>>>So, if the low hanging fruit strategy (as James=20 > suggested) for=20 > > >>>>>>protocol development and progress is the way to go, > > then I think > > >>>>>>prioritizing on a protocol for Local MAC is a no brainer. > > >>>>> > > >>>>So as far > > >>>> > > >>>> > > >>>>>>as focus, I feel we should do Local and Split and in=20 > that order. > > >>>>>> > > >>>>>>3. This is not a re-chartering issue but is a=20 > response to Pat's=20 > > >>>>>>suggestion that a protocol that just sends the 802.11 > > MAC frames > > >>>>> > > >>>>>>from the AP to the AC would work. I think possibly, yes. > > >>>>> > > >>>> > > >>>>But again > > >>>> > > >>>> > > >>>> > > >>>>>>the complications of splitting the MAC in an > > >>>>> > > >>>>interoperable way will > > >>>> > > >>>> > > >>>>>>be an issue. Also, you may note in the draft to which > > >>>>> > > >>>>you refer, we > > >>>> > > >>>> > > >>>> > > >>>>>>included a capabilities exchange phase. I had thought of > > >>>>> > > >>>>including > > >>>> > > >>>> > > >>>>>>in the capability exchange such things as "AP supports > > Local MAC" > > >>>>>>and "AP supports Split MAC", but didn't put it in because the=20 > > >>>>>>Taxonomy work was still in progress. Now that it is > > pretty much > > >>>>>>done we could surely include that. But again...let's=20 > recharter=20 > > >>>>>>first. > > >>>>>> > > >>>>>>Thanks. Do people agree with 1 & 2? > > >>>>>> > > >>>>>>--- > > >>>>>>Inderpreet Singh > > >>>>>>Chantry Networks > > >>>>>>isingh@chantrynetworks.com > > >>>>>>Cell: 416-831-3705 > > >>>>>> > > >>>>>>-----Original Message----- > > >>>>>>From: capwap-admin@frascone.com > > >>>>> > > >>>>[mailto:capwap-admin@frascone.com] > > >>>> > > >>>> > > >>>>>>On Behalf Of Pat R. Calhoun > > >>>>>>Sent: Tuesday, August 03, 2004 6:04 PM > > >>>>>>To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com;=20 > > >>>>>>capwap@frascone.com > > >>>>>>Cc: bwijnen@lucent.com; mmani@avaya.com;=20 > david.kessens@nokia.com > > >>>>>>Subject: [Capwap] So many architectures, so little > > >>>>> > > >>>>time... - take 2 > > >>>> > > >>>> > > >>>>>>After reading Lily's response to Jim, I realize that I > > >>>>> > > >>>>fell down the > > >>>> > > >>>> > > >>>> > > >>>>>>same trap. Local MAC is also a centralized approach,=20 > and so my=20 > > >>>>>>previous response was not complete. I believe the real > > >>>>> > > >>>>question, in > > >>>> > > >>>> > > >>>>>>my mind, is whether we need to address either the Local > > >>>>> > > >>>>or the Split > > >>>> > > >>>> > > >>>> > > >>>>>>MAC architecture. > > >>>>>> > > >>>>>>Just looking at the Architecture Consideration tables (7 and > > >>>>>>10) in the > > >>>>>>specification, the > > >>>>>>main difference (at a high level) between both approaches > > >>>>> > > >>>>is where > > >>>> > > >>>> > > >>>>>>the 802.11 management terminates. For Local MAC, it's > > in the WTP, > > >>>>>>while for SPlit MAC, it's in the AC. > > >>>>>> > > >>>>>>However, looking at table 8, most Local MAC approaches > > share STA > > >>>>>>state between both the WTP and the AC. So clearly=20 > there is some=20 > > >>>>>>signalling protocol between both the WTP and the AC. > > >>>>>> > > >>>>>>Looking at one example of a Local MAC protocol (see > > >>>>>> > > >>>>> > >=20 > >>>http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > > >>> > > >>> > > >>>>>there is a protocol message > > >>>>>that corresponds for every 802.11 MAC management event. So > > >>>> > > >>when a STA > > >> > > >> > > >>>>>associates, the AP breaks the message apart and creates an new=20 > > >>>>>protocol PDU, which contains components found in the=20 > association=20 > > >>>>>request. I suspect that most Local MAC approaches do > > >>>> > > >>something very > > >> > > >>>>>similar. > > >>>>> > > >>>>>So if a protocol simply tunnels the 802.11 MAC management > > >>>> > > >>frames from > > >> > > >> > > >>>>>the WTP to the AC, it allows supports both approaches. For > > >>>> > > >>Local MAC, > > >> > > >> > > >>>>>they get what they want via the 802.11 frame, and this > > also works > > >>>>>fine for Split MAC, which needs access to the MAC > > >>>> > > >>management frame.=20 > > >> > > >>>>>What would be required in such a protocol is a way for=20 > the AP to=20 > > >>>>>communicate whether it will be providing very specific > > functions - > > >>>>>basically a capabilities negotiation approach. > > >>>>> > > >>>>>So I do believe that there is a way to address both > > architectures > > >>>>>using a single protocol. > > >>>>> > > >>>>>Thoughts? > > >>>>> > > >>>>>PatC > > >>>>> > > >>>>>_______________________________________________ > > >>>>>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=20 > http://mail.frascone.com/mailman/listinfo/capwap > >>>_______________________________________________ > >>>Capwap mailing list > >>>Capwap@frascone.com=20 > http://mail.frascone.com/mailman/listinfo/capwap > >>>_______________________________________________ > >>>Capwap mailing list > >>>Capwap@frascone.com=20 > http://mail.frascone.com/mailman/listinfo/capwap > >>>_______________________________________________ > >>>Capwap mailing list > >>>Capwap@frascone.com=20 > http://mail.frascone.com/mailman/listinfo/capwap > >>>_______________________________________________ > >>>Capwap mailing list > >>>Capwap@frascone.com=20 > http://mail.frascone.com/mailman/listinfo/capwap > >>>_______________________________________________ > >>>Capwap mailing list > >>>Capwap@frascone.com=20 > http://mail.frascone.com/mailman/listinfo/capwap > >>>_______________________________________________ > >>>Capwap mailing list > >>>Capwap@frascone.com > >>>http://mail.frascone.com/mailman/listinfo/capwap > >> > >> > >>-- > >>Shankar Narayanaswamy, Ph.D. > >>wireless@shankar.org Mobile: +1 650-387-4593 > >>http://www.shankar.org E-Fax: +1 253-498-8372 > >> > >>_______________________________________________ > >>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 > >=20 > >=20 >=20 >=20 > -- > Shankar Narayanaswamy, Ph.D. > wireless@shankar.org Mobile: +1 650-387-4593 > http://www.shankar.org E-Fax: +1 253-498-8372 >=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 >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Aug 12 16:20:09 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02297 for ; Thu, 12 Aug 2004 16:20:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E299D215BD; Thu, 12 Aug 2004 16:05:16 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 15F7421AC9; Thu, 12 Aug 2004 16:05:13 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AC2E021AC9 for ; Thu, 12 Aug 2004 16:04:45 -0400 (EDT) Received: from aruba-server.arubanetworks.com (mail.arubanetworks.com [64.60.249.195]) by mail.frascone.com (Postfix) with SMTP id 93BE521ACC for ; Thu, 12 Aug 2004 16:04:42 -0400 (EDT) Received: from [10.3.9.211] ([10.3.9.211] unverified) by aruba-server.arubanetworks.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 12 Aug 2004 13:19:26 -0700 Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC From: Partha Narasimhan To: Lily L Yang Cc: "Wijnen, Bert (Bert)" , Shankar Narayanaswamy , Dorothy.Gellert@nokia.com, capwap@frascone.com In-Reply-To: <2AF68A477DD44C4EBCBE338C24E7A9EE01836F8D@orsmsx408> References: <2AF68A477DD44C4EBCBE338C24E7A9EE01836F8D@orsmsx408> Content-Type: text/plain Organization: Aruba Wireless Networks, Inc. Message-Id: <1092341951.16594.11092.camel@sap1.arubanetworks.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Aug 2004 20:19:26.0570 (UTC) FILETIME=[AA2694A0:01C480A9] 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, 12 Aug 2004 13:19:21 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit The set of AP functions is split across the WTP and the AC in the split-MAC and, arguably to a lesser extent, in the local MAC architectures. As a result, the AP, in these architectures, is no longer a physical entity, but one that potentially spans a L3 boundary. The handling of data frames (and some mgmt frames in the split-MAC arch) within an AP could involve transferring it over a L3 network from the WTP to the AC or vice-versa. If these two end-points are from multiple different vendors, then there needs to be an agreement on the mode of this transfer. Hence, we cannot ignore this problem in defining a CAPWAP protocol. Thanks partha On Thu, 2004-08-12 at 10:42, Yang, Lily L wrote: > To examine our options of architecture assumptions, let me first put our > my definition of data plane and control plane just to make sure we start > from the same page: > > To me, 802.11 data plane means the dath path travelled by the native > 802.11 data frames while 802.11 control plane means the data path > between 802.11 STA and the 802.11-awared control end point. > > For both Local and Split MAC, that 802.11-awared control point is AC. So > both architecture has the same control path: STA->WTP->AC. The > difference is how that control messages are implemented between WTP and > AC: Split MAC simply tunneled the 802.11 management frames, while Local > MAC translated them into some other non-802.11 forms. Another (implied) > difference is that Split MAC largely relies on the AC to respond to > those management frames from STA, while Local MAC relies on WTP to > respond, but allow AC to be informed of such events as well. So the > timing constraint may be more relaxed for local MAC. > > The question is on the data path. Here is my understanding so far: > In Local MAC, the data path is between STA and WTP. From WTP, it can be > switched or routed locally, entirely bypassing AC. For Split MAC, My > impression has been that the data path is between STA and WTP and AC, > because it seems that Split MAC vendors tunnel ALL 802.11 data back to > AC, even though I don't see why it has to be that way. Just from the > recent discussion, some have hinted that even Split MAC can allow data > path terminate at WTP and be "locally" switched without involving AC. Is > this true? Can anyone confirm more explicitly and elaborate this for me? > > > To summarize: > Common control path: STA->WTP->AC. (but control messages between > WTP<->AC are done diffrently) > Local MAC data path: STA->WTP. > Split MAC data path: STA->WTP->AC or STA->WTP (This needs to be > clarified). > > My hunch is that CAPWAP protocol would have to allow the flexibility in > datapath, for either architecture (Split or Local). So in that case, it > doesn't really matter if it is Split or Local, it should allow datapath > to be configurable any way. In that sense, I agree with what Shankar was > saying here. This seems also suggest that YES, we can cleanly separate > data plane and control plane here. But that doesn't mean any discussion > around data plane is out of scope -- because guess what? Why do we need > the control plane at the first place? To control and configure the data > plane! > > So understanding what data plane needs would drive our discussion for > the control plane and CAPWAP. > > > -----Original Message----- > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Wijnen, Bert (Bert) > > Sent: Thursday, August 12, 2004 2:30 AM > > To: Shankar Narayanaswamy; Dorothy.Gellert@nokia.com > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] Re: Data plane and control plane > > separation in Split MAC > > > > > -----Original Message----- > > > From: Shankar Narayanaswamy [mailto:wireless@shankar.org] > > > Sent: donderdag 12 augustus 2004 05:13 > > > To: Dorothy.Gellert@nokia.com > > > Cc: capwap@frascone.com > > > Subject: [Capwap] Re: Data plane and control plane > > separation in Split > > > MAC > > > > > > > > > The parameters by which the data plane communicates such as > > > authentication/security info, destination switch (if any) for data > > > frames, etc, are communicated by the control plane. Hence > > the need for > > > some architectural assumptions regarding the data plane even if the > > > focus is on the control plane. > > > > > > Or at least a decision on the data plane architectures to be > > > supported. > > > > > So... to me that sounds that we may potentially do an IMPLIED > > agreement on the architecture for data plane, based on the > > capabilities we define in the standards track control and > > provisioning protocol. > > > > That would be fine with me. But we should NOT get bogged down > > in that data plane stuff, or at least that to me seems to be > > the wrong focus. > > > > Bert > > > -s > > > > > > Dorothy.Gellert@nokia.com wrote: > > > > Good point. Can we have the volunteers that submitted > > > architectures for the taxonomy draft weigh in on this issue? > > > > > > > > Also another point to consider is that we don't have to > > > implement *every* AP function in the first release of the CAPWAP > > > protocol. One of our charter goals is to start with > > > the minimal set of functionality needed to provide control. > > > We have a "desirable" category where we can put objectives > > that can be > > > met with a later release or extension. > > > > > > > > Dorothy > > > > > > > >>-----Original Message----- > > > >>From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com]On > > > >>Behalf Of ext Yang, Lily L > > > >>Sent: Tuesday, August 10, 2004 6:13 PM > > > >>To: Sudhanshu Jain; Shehzad Merchant; Shankar > > Narayanaswamy; Abhijit > > > >>Choudhury > > > >>Cc: capwap@frascone.com > > > >>Subject: RE: [Capwap] So many architectures, so little time... - > > > >>take 2 > > > >> > > > >> > > > >>The question in my mind is: Can data plane and control plane be > > > >>cleanly separated for Split MAC? I know it is feasible for Local > > > MAC, but not > > > >>sure about Split MAC. > > > >>Any insight? > > > >> > > > >>-----Original Message----- > > > >>From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On > > > >>Behalf Of Sudhanshu Jain > > > >>Sent: Tuesday, August 10, 2004 11:55 AM > > > >>To: Shehzad Merchant; Shankar Narayanaswamy; Abhijit Choudhury > > > >>Cc: capwap@frascone.com > > > >>Subject: RE: [Capwap] So many architectures, so little time... - > > > >>take 2 > > > >> > > > >>I fully agree with Shehzad. We need to separate the > > control and data > > > >>plane. Control plane should provide the framework to use one of > > > >>several tunneling protocol. > > > >> > > > >>On data plane, if we need to define a new layer2/layer3 level > > > >>tunneling protocol, it should be separate work from > > control protocol > > > >>work. > > > >> > > > >>-Suds > > > >> > > > >> > > > >>-----Original Message----- > > > >>From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On > > > >>Behalf Of Shehzad Merchant > > > >>Sent: Tuesday, August 10, 2004 11:13 AM > > > >>To: Shankar Narayanaswamy; Abhijit Choudhury > > > >>Cc: capwap@frascone.com > > > >>Subject: RE: [Capwap] So many architectures, so little time... - > > > >>take 2 > > > >> > > > >>Additionally, for data tunneling one needs a lightweight > > mechanism > > > >>that may not necessarily have the same requirements as that for > > > >>control and management. For example, one would want to limit the > > > >>tunneling and processing overhead on data packets to a minimum. > > > >>Control and management may be more tolerant of > > > >>tunneling/security/etc. overhead. > > > >>Besides, there are > > > >>plenty of standards in place for data tunneling. We may > > > potentially be > > > >>able > > > >>to leverage off that work itself without having to invent > > > yet another > > > >>tunneling mechanism for data. > > > >> > > > >>-S > > > >> > > > >> > > > >>-----Original Message----- > > > >>From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On > > > >>Behalf > > > >>Of Shankar Narayanaswamy > > > >>Sent: Tuesday, August 10, 2004 10:30 AM > > > >>To: Abhijit Choudhury > > > >>Cc: capwap@frascone.com > > > >>Subject: Re: [Capwap] So many architectures, so little time... - > > > >>take 2 > > > >> > > > >>On the first point: not necessarily. If data packets are > > > encapsulated > > > >>802.11 data frames, then there is no need to protect them > > > on the wire > > > >>any > > > >>more than they were encrypted over the air. > > > >> > > > >>But control and management packets will need protection > > > over the wired > > > >>network and therefore possibly a different tunneling protocol. > > > >> > > > >>On the second point (standard way of packet exchange): yes! > > > >> > > > >>-s > > > >> > > > >>Abhijit Choudhury wrote: > > > >> > > > >>>The same tunneling protocol that moves control and > > > >> > > > >>management packets > > > >> > > > >>>from the WTP to the AC should be used to tunnel data > > > >> > > > >>packets as well. > > > >> > > > >> > > > >>>We would specify message exchanges to do control, > > provisioning and > > > >>>capability advertisement between WTPs and the AC. But > > all of this > > > >>>would be within the unified CAPWAP protocol that moves > > all packets > > > >>>including data between the WTP and AC. Vendors currently > > > >> > > > >>use LWAPP, > > > >> > > > >>>GRE, IP and some proprietary encapsulations to achieve > > this. This > > > >>>group would come up with a "standard" way of doing this exchange. > > > >>> > > > >>>At least that was my understanding.... > > > >>> > > > >>>Regards, > > > >>>Abhijit > > > >>> > > > >>>-----Original Mssage----- > > > >>>From: capwap-admin@frascone.com > > > >> > > > >>[mailto:capwap-admin@frascone.com] On > > > >> > > > >>>Behalf Of Wijnen, Bert (Bert) > > > >>>Sent: Monday, August 09, 2004 6:14 AM > > > >>>To: 'Yang, Lily L'; Burbank, Jack L.; Victor Lin; Bob O'Hara; > > > >>>capwap@frascone.com > > > >>>Subject: RE: [Capwap] So many architectures, so little > > > >> > > > >>time... - take > > > >> > > > >>>2 > > > >>> > > > >>> > > > >>>Not sure who is confused... probably me... > > > >>> > > > >>>My understanding was/is that IF we do re-charter for CAPWAP > > > >> > > > >>protocol > > > >> > > > >>>work, that it is then a NM protocol for "Control and > > > >> > > > >>Provisioning" and > > > >> > > > >> > > > >>>not any of the related stuff that moves the data from WTP to AC. > > > >>> > > > >>>Is everybody in agreement with that understanding. > > > >>> > > > >>>Thanks, > > > >>>Bert > > > >>> > > > >>> > > > >>> > > > >>>>-----Original Message----- > > > >>>>From: Yang, Lily L [mailto:lily.l.yang@intel.com] > > > >>>>Sent: maandag 9 augustus 2004 08:14 > > > >>>>To: Burbank, Jack L.; Victor Lin ; Bob O'Hara ; > > > capwap@frascone.com > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>> > > > >>>>I think setting the re-charter scope to develop a single > > > >>> > > > >>protocol that > > > >> > > > >>> > > > >>>>allows interoperability between Local and Split MAC is a > > > reasonable > > > >>>>tradeoff: > > > >>>>We exclude remote MAC because the constraint it imposes is very > > > >>>>different from the rest and the benefit of including it is very > > > >>>>little. But Local and Split MAC are reasonably close and > > > hence the > > > >>>>effort may be incremental only. > > > >>>>As many people noted, as of today, there is no single clear > > > >>> > > > >>definition > > > >> > > > >> > > > >>>>of what "Local MAC" and "Split MAC" really means yet. Each > > > >>> > > > >>vendor has > > > >> > > > >>>>different definitions and some debate needs to happen so > > > >>> > > > >>that the WG > > > >> > > > >>>>can reach consensus on what exactly that means, and > > what kinds of > > > >>>>flexibility we want to retain within each class of > > > >>> > > > >>architecture, and > > > >> > > > >>>>what kind of differences we can to resolve and agree up > > > front. That > > > >>>>should also be part of the work items for the new WG -- > > > >>> > > > >>such agreement > > > >> > > > >> > > > >>>>on the details for each architecture must be documented > > > >>> > > > >>somewhere, if > > > >> > > > >>>>not separately, then as part of the Protocol document. > > > >>>> > > > >>>>-----Original Message----- > > > >>>>From: capwap-admin@frascone.com > > > >>> > > > >>[mailto:capwap-admin@frascone.com] On > > > >> > > > >>>>Behalf Of Burbank, Jack L. > > > >>>>Sent: Thursday, August 05, 2004 12:14 PM > > > >>>>To: 'Victor Lin '; 'Bob O'Hara '; 'capwap@frascone.com ' > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>>I think that interoperability between different > > > >>> > > > >>architectures should > > > >> > > > >>>>be a requirement, if not the key requirement. As was mentioned > > > >>>>yesterday, a goal of the IEEE is that they maintain > > > flexibility in > > > >>>>terms of how products and architectures are implemented. I > > > >>> > > > >>think we > > > >> > > > >>>>shouldn't do anything that is contrary to that goal (or > > > at least we > > > >>>>should minimize the impact). I think that the goal of > > > >>> > > > >>CAPWAP should > > > >> > > > >>>>be to retain this type of flexibility by designing a > > > >>> > > > >>protocol that can > > > >> > > > >> > > > >>>>maintain this implementation flexibility but enable > > > >>> > > > >>interoperability > > > >> > > > >>>>between the various architecture implementations (that > > > after all is > > > >>>>the key problem with the deployment of these various > > > >>> > > > >>architectures - > > > >> > > > >>>>lack of interoperability). IMO, if we don't design for > > > >>>>interoperability between the basic architecture types, it > > > >>> > > > >>is debatable > > > >> > > > >> > > > >>>>if something useful would have been accomplished. > > > >>>> > > > >>>>Jack Burbank > > > >>>> > > > >>>>-----Original Message----- > > > >>>>From: capwap-admin@frascone.com > > > >>>>To: Bob O'Hara; capwap@frascone.com > > > >>>>Sent: 8/5/2004 2:46 PM > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>>I agree that we can design a protocol and implement the > > > >>> > > > >>product that > > > >> > > > >>>>works all architectures. I think the question to CAPWAP is: > > > >>>> > > > >>>>Should we make it a requirement in CAPWAP protocol to achieve > > > >>>>interoperability between different architectures? > > > >>>> > > > >>>>It is definitely doable, but I'm not sure if that is the > > > >>> > > > >>right thing > > > >> > > > >>>>to do.. > > > >>>> > > > >>>>Victor > > > >>>> > > > >>>>-----Original Message----- > > > >>>>From: capwap-admin@frascone.com > > > >>> > > > >>[mailto:capwap-admin@frascone.com] On > > > >> > > > >>>>Behalf Of Bob O'Hara > > > >>>>Sent: Thursday, August 05, 2004 11:43 AM > > > >>>>To: capwap@frascone.com > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>>I think that interoperability will depend on two things. > > > >>>>First, it will > > > >>>>depend on how we define the protocol and the flexibility > > > >>> > > > >>for supported > > > >> > > > >> > > > >>>>architectures it incorporates. Second, it will depend on what > > > >>>>manufacturers implement, i.e., the flexibility they build > > > >>> > > > >>into their > > > >> > > > >>>>products. > > > >>>> > > > >>>>I believe that it is possible to design the protocol for > > > >>> > > > >>the required > > > >> > > > >>>>flexibility. I know it is possible to implement a > > > product with the > > > >>>>required flexibility. > > > >>>> > > > >>>>-Bob O'Hara > > > >>>> > > > >>>> > > > >>>>-----Original Message----- > > > >>>>From: capwap-admin@frascone.com > > > >>> > > > >>[mailto:capwap-admin@frascone.com] On > > > >> > > > >>>>Behalf Of Abhijit Choudhury > > > >>>>Sent: Thursday, August 05, 2004 11:32 AM > > > >>>>To: James Kempf; Shehzad Merchant; capwap@frascone.com > > > >>>>Cc: bwijnen@lucent.com; mmani@avaya.com; > > david.kessens@nokia.com; > > > >>>>Dorothy.Gellert@nokia.com; Inderpreet Singh > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>> > > > >>>>It may be possible to achieve such interoperability within the > > > >>>>split-MAC family or within the local-MAC family. It > > > would sbe very > > > >>>>hard to achieve that between local and split MAC families. > > > >>>> > > > >>>>For example, if vendor X's WTP terminates 802.11 ctrl/mgmt > > > >>> > > > >>packets and > > > >> > > > >>> > > > >>>>vendor Y's AC expects the 802.11 mgmt packets to come to > > > >>> > > > >>it, there's > > > >> > > > >>>>no way you can be interoperable. > > > >>>> > > > >>>>Or are we planning to specify ONE architecture ? > > > >>>>The last thing IETF should do is mandate an implementation. > > > >>>> > > > >>>>I think a modest and reasonable goal is to come up with a > > > protocol > > > >>>>that allows sufficient flexbility so that vendors with splitMAC > > > >>>>architectures can transfer most of the information they > > > care about > > > >>>>between the WTP and AC. > > > >>>> > > > >>>>Just my $0.02 ... > > > >>>> > > > >>>> > > > >>>>Abhijit Choudhury > > > >>>> > > > >>>> > > > >>>>-----Original Message----- > > > >>>>From: capwap-admin@frascone.com > > > >>> > > > >>[mailto:capwap-admin@frascone.com] On > > > >> > > > >>>>Behalf Of James Kempf > > > >>>>Sent: Wednesday, August 04, 2004 3:29 PM > > > >>>>To: Shehzad Merchant; capwap@frascone.com > > > >>>>Cc: bwijnen@lucent.com; mmani@avaya.com; > > david.kessens@nokia.com; > > > >>>>Dorothy.Gellert@nokia.com; Inderpreet Singh > > > >>>>Subject: Re: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>> > > > >>>>As a potential customer, let me put it concretely. I want > > > >>> > > > >>to be able > > > >> > > > >>>>to buy my access points from Vendor X and my switch from > > > >>> > > > >>Vendor Y and > > > >> > > > >>>>plug the two together and have them work without any > > > configuration. > > > >>>>Also, I'd like to be able to buy switches from Vendor Y and > > > >>> > > > >>Vendor Z > > > >> > > > >>>>and be able to plug them into my network at various > > > places and have > > > >>>>them interoperate. > > > >>>> > > > >>>> jak > > > >>>> > > > >>>> > > > >>>>----- Original Message ----- > > > >>>>From: "Shehzad Merchant" > > > >>>>To: > > > >>>>Cc: ; ; > > > >>>>; ; > > > "Inderpreet > > > >>>>Singh" > > > >>>> > > > >>>>Sent: Wednesday, August 04, 2004 3:19 PM > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>>>I think the implementation variations even with the > > > split MAC may > > > >>>>>cover a broad spectrum. As such its important to clearly > > > >>>> > > > >>articulate > > > >> > > > >>>>>what aspects > > > >>>> > > > >>>>of > > > >>>> > > > >>>> > > > >>>>>interoperability we are targetting. Is it truly just > > > >>>>>control/management or is it interoperability between disparate > > > >>>>>implementations of the split MAC, i.e. mix and match > > > >>>> > > > >>>>operation of WTP > > > >>>> > > > >>>> > > > >>>>>and ACs of all variants within this category. > > > >>>>> > > > >>>>>I suspect for the latter we may have to arrive at some > > > >>>> > > > >>consensus on > > > >> > > > >>>>>what particular implementations we are targeting > > > >>>> > > > >>>>interoperability for. > > > >>>> > > > >>>> > > > >>>> > > > >>>>>If so, ultimately this problem statement could become > > > part of the > > > >>>>>charter. > > > >>>>> > > > >>>>>-Shehzad > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>>-----Original Message----- > > > >>>>>From: capwap-admin@frascone.com > > > >>>> > > > >>>>[mailto:capwap-admin@frascone.com] On Behalf > > > >>>> > > > >>>> > > > >>>>>Of Dorothy.Gellert@nokia.com > > > >>>>>Sent: Wednesday, August 04, 2004 11:53 AM > > > >>>>>To: isingh@chantrynetworks.com; capwap@frascone.com > > > >>>>>Cc: bwijnen@lucent.com; mmani@avaya.com; > > david.kessens@nokia.com > > > >>>>>Subject: RE: [Capwap] So many architectures, so little > > > >>>> > > > >>>>time... - take > > > >>>> > > > >>>> > > > >>>>>2 > > > >>>>> > > > >>>>>I believe this is the consensus, to scope the charter to > > > >>>> > > > >>>>Centralized > > > >>>> > > > >>>> > > > >>>>>Architecture and LocalMAC and Split MAC. > > > >>>>> > > > >>>>>I'll update the charter with this change after the CAPWAP > > > >>>> > > > >>>>WG Mtg. If > > > >>>> > > > >>>> > > > >>>>>there is resistance to this idea, please post to the list. > > > >>>>> > > > >>>>>Regards > > > >>>>>Dorothy > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>>>-----Original Message----- > > > >>>>>>From: capwap-admin@frascone.com > > > >>>>> > > > >>>>[mailto:capwap-admin@frascone.com]On > > > >>>> > > > >>>> > > > >>>>>>Behalf Of ext Inderpreet Singh > > > >>>>>>Sent: Tuesday, August 03, 2004 9:40 PM > > > >>>>>>To: capwap@frascone.com > > > >>>>>>Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David > > > >>>>>>(Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > > > >>>>>>Subject: RE: [Capwap] So many architectures, so little > > > time... - > > > >>>>>>take 2 > > > >>>>>> > > > >>>>>> > > > >>>>>>The issue(s) at hand and my opinions are: > > > >>>>>> > > > >>>>>>1. Do we explicitly state in the re-charter which > > > >>>>> > > > >>>>architecture the > > > >>>> > > > >>>> > > > >>>>>>WG should consider? I think yes. I propose Centralized > > > >>>>> > > > >>>>architecture > > > >>>> > > > >>>> > > > >>>> > > > >>>>>>only. Autonomous and Distributed should be out of scope > > > >>>>> > > > >>>>based on the > > > >>>> > > > >>>> > > > >>>> > > > >>>>>>same reasons as per prior postings. > > > >>>>>> > > > >>>>>>2. Within Centralized do we focus on all three sub > > > >>>>> > > > >>>>architectures or > > > >>>> > > > >>>> > > > >>>>>>a subset? Remote MAC should be excluded because if I am not > > > >>>>>>mistaken, the connectivity constraint between the WTP and > > > >>>>> > > > >>>>the AC is > > > >>>> > > > >>>> > > > >>>>>>"direct connect". > > > >>>>>>That being the case and that no IP layer is involved, > > it doesn't > > > >>>>> > > > >>>>seem > > > >>>> > > > >>>> > > > >>>>>>clear what kind of protocol would help with > > > interoperability. I am > > > >>>>> > > > >>>>>>concerned about the impact, dependencies and > > > interaction with the > > > >>>>>>recently constituted IEEE Study group on AP > > > >>>>> > > > >>>>functionality on the > > > >>>> > > > >>>> > > > >>>>>>Split MAC architectures. Furthermore, there are some > > > >>>>> > > > >>>>pretty drastic > > > >>>> > > > >>>> > > > >>>>>>differences on how the vendors have chosen to split the > > > >>>>> > > > >>>>mac. Those > > > >>>> > > > >>>> > > > >>>>>>differences will need to be worked out before designing a > > > >>>>> > > > >>>>protocol. > > > >>>> > > > >>>> > > > >>>>>>So, if the low hanging fruit strategy (as James > > suggested) for > > > >>>>>>protocol development and progress is the way to go, > > > then I think > > > >>>>>>prioritizing on a protocol for Local MAC is a no brainer. > > > >>>>> > > > >>>>So as far > > > >>>> > > > >>>> > > > >>>>>>as focus, I feel we should do Local and Split and in > > that order. > > > >>>>>> > > > >>>>>>3. This is not a re-chartering issue but is a > > response to Pat's > > > >>>>>>suggestion that a protocol that just sends the 802.11 > > > MAC frames > > > >>>>> > > > >>>>>>from the AP to the AC would work. I think possibly, yes. > > > >>>>> > > > >>>> > > > >>>>But again > > > >>>> > > > >>>> > > > >>>> > > > >>>>>>the complications of splitting the MAC in an > > > >>>>> > > > >>>>interoperable way will > > > >>>> > > > >>>> > > > >>>>>>be an issue. Also, you may note in the draft to which > > > >>>>> > > > >>>>you refer, we > > > >>>> > > > >>>> > > > >>>> > > > >>>>>>included a capabilities exchange phase. I had thought of > > > >>>>> > > > >>>>including > > > >>>> > > > >>>> > > > >>>>>>in the capability exchange such things as "AP supports > > > Local MAC" > > > >>>>>>and "AP supports Split MAC", but didn't put it in because the > > > >>>>>>Taxonomy work was still in progress. Now that it is > > > pretty much > > > >>>>>>done we could surely include that. But again...let's > > recharter > > > >>>>>>first. > > > >>>>>> > > > >>>>>>Thanks. Do people agree with 1 & 2? > > > >>>>>> > > > >>>>>>--- > > > >>>>>>Inderpreet Singh > > > >>>>>>Chantry Networks > > > >>>>>>isingh@chantrynetworks.com > > > >>>>>>Cell: 416-831-3705 > > > >>>>>> > > > >>>>>>-----Original Message----- > > > >>>>>>From: capwap-admin@frascone.com > > > >>>>> > > > >>>>[mailto:capwap-admin@frascone.com] > > > >>>> > > > >>>> > > > >>>>>>On Behalf Of Pat R. Calhoun > > > >>>>>>Sent: Tuesday, August 03, 2004 6:04 PM > > > >>>>>>To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com; > > > >>>>>>capwap@frascone.com > > > >>>>>>Cc: bwijnen@lucent.com; mmani@avaya.com; > > david.kessens@nokia.com > > > >>>>>>Subject: [Capwap] So many architectures, so little > > > >>>>> > > > >>>>time... - take 2 > > > >>>> > > > >>>> > > > >>>>>>After reading Lily's response to Jim, I realize that I > > > >>>>> > > > >>>>fell down the > > > >>>> > > > >>>> > > > >>>> > > > >>>>>>same trap. Local MAC is also a centralized approach, > > and so my > > > >>>>>>previous response was not complete. I believe the real > > > >>>>> > > > >>>>question, in > > > >>>> > > > >>>> > > > >>>>>>my mind, is whether we need to address either the Local > > > >>>>> > > > >>>>or the Split > > > >>>> > > > >>>> > > > >>>> > > > >>>>>>MAC architecture. > > > >>>>>> > > > >>>>>>Just looking at the Architecture Consideration tables (7 and > > > >>>>>>10) in the > > > >>>>>>specification, the > > > >>>>>>main difference (at a high level) between both approaches > > > >>>>> > > > >>>>is where > > > >>>> > > > >>>> > > > >>>>>>the 802.11 management terminates. For Local MAC, it's > > > in the WTP, > > > >>>>>>while for SPlit MAC, it's in the AC. > > > >>>>>> > > > >>>>>>However, looking at table 8, most Local MAC approaches > > > share STA > > > >>>>>>state between both the WTP and the AC. So clearly > > there is some > > > >>>>>>signalling protocol between both the WTP and the AC. > > > >>>>>> > > > >>>>>>Looking at one example of a Local MAC protocol (see > > > >>>>>> > > > >>>>> > > > > > >>>http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > > > >>> > > > >>> > > > >>>>>there is a protocol message > > > >>>>>that corresponds for every 802.11 MAC management event. So > > > >>>> > > > >>when a STA > > > >> > > > >> > > > >>>>>associates, the AP breaks the message apart and creates an new > > > >>>>>protocol PDU, which contains components found in the > > association > > > >>>>>request. I suspect that most Local MAC approaches do > > > >>>> > > > >>something very > > > >> > > > >>>>>similar. > > > >>>>> > > > >>>>>So if a protocol simply tunnels the 802.11 MAC management > > > >>>> > > > >>frames from > > > >> > > > >> > > > >>>>>the WTP to the AC, it allows supports both approaches. For > > > >>>> > > > >>Local MAC, > > > >> > > > >> > > > >>>>>they get what they want via the 802.11 frame, and this > > > also works > > > >>>>>fine for Split MAC, which needs access to the MAC > > > >>>> > > > >>management frame. > > > >> > > > >>>>>What would be required in such a protocol is a way for > > the AP to > > > >>>>>communicate whether it will be providing very specific > > > functions - > > > >>>>>basically a capabilities negotiation approach. > > > >>>>> > > > >>>>>So I do believe that there is a way to address both > > > architectures > > > >>>>>using a single protocol. > > > >>>>> > > > >>>>>Thoughts? > > > >>>>> > > > >>>>>PatC > > > >>>>> > > > >>>>>_______________________________________________ > > > >>>>>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 > > >>>_______________________________________________ > > >>>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 > > >>>_______________________________________________ > > >>>Capwap mailing list > > >>>Capwap@frascone.com > > >>>http://mail.frascone.com/mailman/listinfo/capwap > > >> > > >> > > >>-- > > >>Shankar Narayanaswamy, Ph.D. > > >>wireless@shankar.org Mobile: +1 650-387-4593 > > >>http://www.shankar.org E-Fax: +1 253-498-8372 > > >> > > >>_______________________________________________ > > >>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 > > > > > > > > > > > > -- > > Shankar Narayanaswamy, Ph.D. > > wireless@shankar.org Mobile: +1 650-387-4593 > > http://www.shankar.org E-Fax: +1 253-498-8372 > > > > _______________________________________________ > > 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 Aug 12 17:53:08 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10947 for ; Thu, 12 Aug 2004 17:53:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 93053215F4; Thu, 12 Aug 2004 17:38:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6A7702188B; Thu, 12 Aug 2004 17:38:07 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6E26D215F4 for ; Thu, 12 Aug 2004 17:37:46 -0400 (EDT) Received: from smtp108.mail.sc5.yahoo.com (smtp108.mail.sc5.yahoo.com [66.163.170.6]) by mail.frascone.com (Postfix) with SMTP id 7C8A62015E for ; Thu, 12 Aug 2004 17:37:44 -0400 (EDT) Received: from unknown (HELO yahoo.com) (behcetsarikaya@24.71.248.99 with plain) by smtp108.mail.sc5.yahoo.com with SMTP; 12 Aug 2004 21:52:32 -0000 Message-ID: <411BE699.2050804@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.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" Cc: capwap@frascone.com Subject: Re: [Capwap] Re: Data plane and control plane separation in Split MAC References: <7D5D48D2CAA3D84C813F5B154F43B15504F2A512@nl0006exch001u.nl.lucent.com> In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15504F2A512@nl0006exch001u.nl.lucent.com> Content-Type: multipart/alternative; boundary="------------000200060706050409030402" 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, 12 Aug 2004 14:52:25 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. --------------000200060706050409030402 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Wijnen, Bert (Bert) wrote: >>-----Original Message----- >>From: Shankar Narayanaswamy [mailto:wireless@shankar.org] >>Sent: donderdag 12 augustus 2004 05:13 >>To: Dorothy.Gellert@nokia.com >>Cc: capwap@frascone.com >>Subject: [Capwap] Re: Data plane and control plane separation in Split >>MAC >> >> >>The parameters by which the data plane communicates such as >>authentication/security info, destination switch (if any) for data >>frames, etc, are communicated by the control plane. Hence the need for >>some architectural assumptions regarding the data plane even if the >>focus is on the control plane. >> >>Or at least a decision on the data plane architectures to be >>supported. >> >> >> >So... to me that sounds that we may potentially do an IMPLIED agreement >on the architecture for data plane, based on the capabilities we define >in the standards track control and provisioning protocol. > >That would be fine with me. But we should NOT get bogged down in that >data plane stuff, or at least that to me seems to be the wrong focus. > > Agreed. However, there might be interest in data packets for user-based security management. As in CTP, tunneling data frames to AC so that user-based authentication, etc. can be achieved. Is this within the scope? Otherwise control frames are probably sufficient for a control and provisioning protocol to deal with. --behcet --------------000200060706050409030402 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Wijnen, Bert (Bert) wrote:
-----Original Message-----
From: Shankar Narayanaswamy [mailto:wireless@shankar.org]
Sent: donderdag 12 augustus 2004 05:13
To: Dorothy.Gellert@nokia.com
Cc: capwap@frascone.com
Subject: [Capwap] Re: Data plane and control plane separation in Split
MAC


The parameters by which the data plane communicates such as 
authentication/security info, destination switch (if any) for data 
frames, etc, are communicated by the control plane. Hence the need for 
some architectural assumptions regarding the data plane even if the 
focus is on the control plane.

Or at least a decision on the data plane architectures to be 
supported.

    
So... to me that sounds that we may potentially do an IMPLIED agreement 
on the architecture for data plane, based on the capabilities we define
in the standards track control and provisioning protocol.

That would be fine with me. But we should NOT get bogged down in that
data plane stuff, or at least that to me seems to be the wrong focus.
Agreed.
However, there might be interest in data packets for user-based security management. As in CTP,
tunneling data frames to AC so that user-based authentication, etc. can be achieved.
Is this within the scope?
Otherwise control frames are probably sufficient for a control and provisioning protocol to deal with.
--behcet

--------------000200060706050409030402-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Aug 12 18:53:48 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15214 for ; Thu, 12 Aug 2004 18:53:47 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9B9F8205EB; Thu, 12 Aug 2004 18:36:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6AC03201A0; Thu, 12 Aug 2004 18:36:08 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1E5C120254 for ; Thu, 12 Aug 2004 18:34:35 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mail.frascone.com (Postfix) with ESMTP id DF7E82019A for ; Thu, 12 Aug 2004 18:34:31 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7CMnH324387; Fri, 13 Aug 2004 01:49:17 +0300 (EET DST) X-Scanned: Fri, 13 Aug 2004 01:49:13 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i7CMnDDa005960; Fri, 13 Aug 2004 01:49:13 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00zZ0PwU; Fri, 13 Aug 2004 01:49:11 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7CMn9u12468; Fri, 13 Aug 2004 01:49:09 +0300 (EET DST) Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 12 Aug 2004 17:49:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Data plane and control plane separation in Split MAC Message-ID: Thread-Topic: [Capwap] Re: Data plane and control plane separation in Split MAC Thread-Index: AcSATx3ubzyBW0DHT0Oo3dMJW6wbqQAQKFiAAAqMybA= From: To: , , Cc: X-OriginalArrivalTime: 12 Aug 2004 22:49:08.0766 (UTC) FILETIME=[93F4EBE0:01C480BE] 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, 12 Aug 2004 15:49:06 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Lily- In response to the Local MAC tunneling, my understanding is that that = user data can be switched off of the WTP in a normal GRE or IPinIP = tunnel or a number of other standard routing options, but it doesn't = make sense in terms of what we are trying to accomplish in the first = place, as you indicate.=20 In an earlier email Bert and Shankar agreed that the CAPWAP scope of = Local and Split MAC may have implications on the choice of data plane = architectures. I agree with this statement in the Charter focus/scope, = and to refine the requirement in the Objectives/Criteria document. If anyone has any objections, please comment. Dorothy > -----Original Message----- > From: ext Yang, Lily L [mailto:lily.l.yang@intel.com] > Sent: Thursday, August 12, 2004 10:43 AM > To: Wijnen, Bert (Bert); Shankar Narayanaswamy; Gellert Dorothy > (Nokia-ES/MtView) > Cc: capwap@frascone.com > Subject: RE: [Capwap] Re: Data plane and control plane separation in > Split MAC >=20 >=20 > To examine our options of architecture assumptions, let me=20 > first put our > my definition of data plane and control plane just to make=20 > sure we start > from the same page: >=20 > To me, 802.11 data plane means the dath path travelled by the native > 802.11 data frames while 802.11 control plane means the data path > between 802.11 STA and the 802.11-awared control end point. =20 >=20 > For both Local and Split MAC, that 802.11-awared control=20 > point is AC. So > both architecture has the same control path: STA->WTP->AC. The > difference is how that control messages are implemented=20 > between WTP and > AC: Split MAC simply tunneled the 802.11 management frames,=20 > while Local > MAC translated them into some other non-802.11 forms. Another=20 > (implied) > difference is that Split MAC largely relies on the AC to respond to > those management frames from STA, while Local MAC relies on WTP to > respond, but allow AC to be informed of such events as well. So the > timing constraint may be more relaxed for local MAC. >=20 > The question is on the data path. Here is my understanding so far: > In Local MAC, the data path is between STA and WTP. From WTP,=20 > it can be > switched or routed locally, entirely bypassing AC. For Split MAC, My > impression has been that the data path is between STA and WTP and AC, > because it seems that Split MAC vendors tunnel ALL 802.11 data back to > AC, even though I don't see why it has to be that way. Just from the > recent discussion, some have hinted that even Split MAC can allow data > path terminate at WTP and be "locally" switched without=20 > involving AC. Is > this true? Can anyone confirm more explicitly and elaborate=20 > this for me? >=20 >=20 > To summarize: > Common control path: STA->WTP->AC. (but control messages between > WTP<->AC are done diffrently) > Local MAC data path: STA->WTP. > Split MAC data path: STA->WTP->AC or STA->WTP (This needs to be > clarified). >=20 > My hunch is that CAPWAP protocol would have to allow the=20 > flexibility in > datapath, for either architecture (Split or Local). So in=20 > that case, it > doesn't really matter if it is Split or Local, it should=20 > allow datapath > to be configurable any way. In that sense, I agree with what=20 > Shankar was > saying here. This seems also suggest that YES, we can cleanly separate > data plane and control plane here. But that doesn't mean any=20 > discussion > around data plane is out of scope -- because guess what? Why=20 > do we need > the control plane at the first place? To control and=20 > configure the data > plane! >=20 > So understanding what data plane needs would drive our discussion for > the control plane and CAPWAP. >=20 > > -----Original Message----- > > From: capwap-admin@frascone.com=20 > > [mailto:capwap-admin@frascone.com] On Behalf Of Wijnen, Bert (Bert) > > Sent: Thursday, August 12, 2004 2:30 AM > > To: Shankar Narayanaswamy; Dorothy.Gellert@nokia.com > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] Re: Data plane and control plane=20 > > separation in Split MAC > >=20 > > > -----Original Message----- > > > From: Shankar Narayanaswamy [mailto:wireless@shankar.org] > > > Sent: donderdag 12 augustus 2004 05:13 > > > To: Dorothy.Gellert@nokia.com > > > Cc: capwap@frascone.com > > > Subject: [Capwap] Re: Data plane and control plane=20 > > separation in Split=20 > > > MAC > > >=20 > > >=20 > > > The parameters by which the data plane communicates such as=20 > > > authentication/security info, destination switch (if any)=20 > for data=20 > > > frames, etc, are communicated by the control plane. Hence=20 > > the need for=20 > > > some architectural assumptions regarding the data plane=20 > even if the=20 > > > focus is on the control plane. > > >=20 > > > Or at least a decision on the data plane architectures to be=20 > > > supported. > > >=20 > > So... to me that sounds that we may potentially do an IMPLIED=20 > > agreement on the architecture for data plane, based on the=20 > > capabilities we define in the standards track control and=20 > > provisioning protocol. > >=20 > > That would be fine with me. But we should NOT get bogged down=20 > > in that data plane stuff, or at least that to me seems to be=20 > > the wrong focus. > >=20 > > Bert > > > -s > > >=20 > > > Dorothy.Gellert@nokia.com wrote: > > > > Good point. Can we have the volunteers that submitted > > > architectures for the taxonomy draft weigh in on this issue? =20 > > > >=20 > > > > Also another point to consider is that we don't have to > > > implement *every* AP function in the first release of the CAPWAP=20 > > > protocol. One of our charter goals is to start with > > > the minimal set of functionality needed to provide control. =20 > > > We have a "desirable" category where we can put objectives=20 > > that can be=20 > > > met with a later release or extension. > > > >=20 > > > > Dorothy > > > >=20 > > > >>-----Original Message----- > > > >>From: capwap-admin@frascone.com=20 > > [mailto:capwap-admin@frascone.com]On > > > >>Behalf Of ext Yang, Lily L > > > >>Sent: Tuesday, August 10, 2004 6:13 PM > > > >>To: Sudhanshu Jain; Shehzad Merchant; Shankar=20 > > Narayanaswamy; Abhijit=20 > > > >>Choudhury > > > >>Cc: capwap@frascone.com > > > >>Subject: RE: [Capwap] So many architectures, so little=20 > time... -=20 > > > >>take 2 > > > >> > > > >> > > > >>The question in my mind is: Can data plane and control plane be=20 > > > >>cleanly separated for Split MAC? I know it is feasible for Local > > > MAC, but not > > > >>sure about Split MAC.=20 > > > >>Any insight? > > > >> > > > >>-----Original Message----- > > > >>From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On > > > >>Behalf Of Sudhanshu Jain > > > >>Sent: Tuesday, August 10, 2004 11:55 AM > > > >>To: Shehzad Merchant; Shankar Narayanaswamy; Abhijit Choudhury > > > >>Cc: capwap@frascone.com > > > >>Subject: RE: [Capwap] So many architectures, so little=20 > time... -=20 > > > >>take 2 > > > >> > > > >>I fully agree with Shehzad. We need to separate the=20 > > control and data=20 > > > >>plane. Control plane should provide the framework to use one of=20 > > > >>several tunneling protocol. > > > >> > > > >>On data plane, if we need to define a new layer2/layer3 level=20 > > > >>tunneling protocol, it should be separate work from=20 > > control protocol=20 > > > >>work. > > > >> > > > >>-Suds > > > >> > > > >> > > > >>-----Original Message----- > > > >>From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On > > > >>Behalf Of Shehzad Merchant > > > >>Sent: Tuesday, August 10, 2004 11:13 AM > > > >>To: Shankar Narayanaswamy; Abhijit Choudhury > > > >>Cc: capwap@frascone.com > > > >>Subject: RE: [Capwap] So many architectures, so little=20 > time... -=20 > > > >>take 2 > > > >> > > > >>Additionally, for data tunneling one needs a lightweight=20 > > mechanism=20 > > > >>that may not necessarily have the same requirements as that for=20 > > > >>control and management. For example, one would want to=20 > limit the=20 > > > >>tunneling and processing overhead on data packets to a minimum.=20 > > > >>Control and management may be more tolerant of=20 > > > >>tunneling/security/etc. overhead. > > > >>Besides, there are > > > >>plenty of standards in place for data tunneling. We may > > > potentially be > > > >>able > > > >>to leverage off that work itself without having to invent > > > yet another > > > >>tunneling mechanism for data.=20 > > > >> > > > >>-S > > > >> > > > >> > > > >>-----Original Message----- > > > >>From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On > > > >>Behalf > > > >>Of Shankar Narayanaswamy > > > >>Sent: Tuesday, August 10, 2004 10:30 AM > > > >>To: Abhijit Choudhury > > > >>Cc: capwap@frascone.com > > > >>Subject: Re: [Capwap] So many architectures, so little=20 > time... -=20 > > > >>take 2 > > > >> > > > >>On the first point: not necessarily. If data packets are > > > encapsulated > > > >>802.11 data frames, then there is no need to protect them > > > on the wire > > > >>any > > > >>more than they were encrypted over the air. > > > >> > > > >>But control and management packets will need protection > > > over the wired > > > >>network and therefore possibly a different tunneling protocol. > > > >> > > > >>On the second point (standard way of packet exchange): yes! > > > >> > > > >>-s > > > >> > > > >>Abhijit Choudhury wrote: > > > >> > > > >>>The same tunneling protocol that moves control and > > > >> > > > >>management packets > > > >> > > > >>>from the WTP to the AC should be used to tunnel data > > > >> > > > >>packets as well. > > > >> > > > >> > > > >>>We would specify message exchanges to do control,=20 > > provisioning and=20 > > > >>>capability advertisement between WTPs and the AC. But=20 > > all of this=20 > > > >>>would be within the unified CAPWAP protocol that moves=20 > > all packets=20 > > > >>>including data between the WTP and AC. Vendors currently > > > >> > > > >>use LWAPP, > > > >> > > > >>>GRE, IP and some proprietary encapsulations to achieve=20 > > this. This=20 > > > >>>group would come up with a "standard" way of doing=20 > this exchange. > > > >>> > > > >>>At least that was my understanding.... > > > >>> > > > >>>Regards, > > > >>>Abhijit > > > >>> > > > >>>-----Original Mssage----- > > > >>>From: capwap-admin@frascone.com > > > >> > > > >>[mailto:capwap-admin@frascone.com] On > > > >> > > > >>>Behalf Of Wijnen, Bert (Bert) > > > >>>Sent: Monday, August 09, 2004 6:14 AM > > > >>>To: 'Yang, Lily L'; Burbank, Jack L.; Victor Lin; Bob O'Hara;=20 > > > >>>capwap@frascone.com > > > >>>Subject: RE: [Capwap] So many architectures, so little > > > >> > > > >>time... - take > > > >> > > > >>>2 > > > >>> > > > >>> > > > >>>Not sure who is confused... probably me... > > > >>> > > > >>>My understanding was/is that IF we do re-charter for CAPWAP > > > >> > > > >>protocol > > > >> > > > >>>work, that it is then a NM protocol for "Control and > > > >> > > > >>Provisioning" and > > > >> > > > >> > > > >>>not any of the related stuff that moves the data from=20 > WTP to AC. > > > >>> > > > >>>Is everybody in agreement with that understanding. > > > >>> > > > >>>Thanks, > > > >>>Bert > > > >>> > > > >>> > > > >>> > > > >>>>-----Original Message----- > > > >>>>From: Yang, Lily L [mailto:lily.l.yang@intel.com] > > > >>>>Sent: maandag 9 augustus 2004 08:14 > > > >>>>To: Burbank, Jack L.; Victor Lin ; Bob O'Hara ; > > > capwap@frascone.com > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>> > > > >>>>I think setting the re-charter scope to develop a single > > > >>> > > > >>protocol that > > > >> > > > >>> > > > >>>>allows interoperability between Local and Split MAC is a > > > reasonable > > > >>>>tradeoff: > > > >>>>We exclude remote MAC because the constraint it=20 > imposes is very=20 > > > >>>>different from the rest and the benefit of including=20 > it is very=20 > > > >>>>little. But Local and Split MAC are reasonably close and > > > hence the > > > >>>>effort may be incremental only. > > > >>>>As many people noted, as of today, there is no single clear > > > >>> > > > >>definition > > > >> > > > >> > > > >>>>of what "Local MAC" and "Split MAC" really means yet. Each > > > >>> > > > >>vendor has > > > >> > > > >>>>different definitions and some debate needs to happen so > > > >>> > > > >>that the WG > > > >> > > > >>>>can reach consensus on what exactly that means, and=20 > > what kinds of=20 > > > >>>>flexibility we want to retain within each class of > > > >>> > > > >>architecture, and > > > >> > > > >>>>what kind of differences we can to resolve and agree up > > > front. That > > > >>>>should also be part of the work items for the new WG -- > > > >>> > > > >>such agreement > > > >> > > > >> > > > >>>>on the details for each architecture must be documented > > > >>> > > > >>somewhere, if > > > >> > > > >>>>not separately, then as part of the Protocol document. > > > >>>> > > > >>>>-----Original Message----- > > > >>>>From: capwap-admin@frascone.com > > > >>> > > > >>[mailto:capwap-admin@frascone.com] On > > > >> > > > >>>>Behalf Of Burbank, Jack L. > > > >>>>Sent: Thursday, August 05, 2004 12:14 PM > > > >>>>To: 'Victor Lin '; 'Bob O'Hara '; 'capwap@frascone.com ' > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>>I think that interoperability between different > > > >>> > > > >>architectures should > > > >> > > > >>>>be a requirement, if not the key requirement. As was=20 > mentioned=20 > > > >>>>yesterday, a goal of the IEEE is that they maintain > > > flexibility in > > > >>>>terms of how products and architectures are implemented. I > > > >>> > > > >>think we > > > >> > > > >>>>shouldn't do anything that is contrary to that goal (or > > > at least we > > > >>>>should minimize the impact). I think that the goal of > > > >>> > > > >>CAPWAP should > > > >> > > > >>>>be to retain this type of flexibility by designing a > > > >>> > > > >>protocol that can > > > >> > > > >> > > > >>>>maintain this implementation flexibility but enable > > > >>> > > > >>interoperability > > > >> > > > >>>>between the various architecture implementations (that > > > after all is > > > >>>>the key problem with the deployment of these various > > > >>> > > > >>architectures - > > > >> > > > >>>>lack of interoperability). IMO, if we don't design for=20 > > > >>>>interoperability between the basic architecture types, it > > > >>> > > > >>is debatable > > > >> > > > >> > > > >>>>if something useful would have been accomplished. > > > >>>> > > > >>>>Jack Burbank > > > >>>> > > > >>>>-----Original Message----- > > > >>>>From: capwap-admin@frascone.com > > > >>>>To: Bob O'Hara; capwap@frascone.com > > > >>>>Sent: 8/5/2004 2:46 PM > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>>I agree that we can design a protocol and implement the > > > >>> > > > >>product that > > > >> > > > >>>>works all architectures. I think the question to CAPWAP is: > > > >>>> > > > >>>>Should we make it a requirement in CAPWAP protocol to achieve=20 > > > >>>>interoperability between different architectures? > > > >>>> > > > >>>>It is definitely doable, but I'm not sure if that is the > > > >>> > > > >>right thing > > > >> > > > >>>>to do.. > > > >>>> > > > >>>>Victor > > > >>>> > > > >>>>-----Original Message----- > > > >>>>From: capwap-admin@frascone.com > > > >>> > > > >>[mailto:capwap-admin@frascone.com] On > > > >> > > > >>>>Behalf Of Bob O'Hara > > > >>>>Sent: Thursday, August 05, 2004 11:43 AM > > > >>>>To: capwap@frascone.com > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>>I think that interoperability will depend on two things. > > > >>>>First, it will > > > >>>>depend on how we define the protocol and the flexibility > > > >>> > > > >>for supported > > > >> > > > >> > > > >>>>architectures it incorporates. Second, it will=20 > depend on what=20 > > > >>>>manufacturers implement, i.e., the flexibility they build > > > >>> > > > >>into their > > > >> > > > >>>>products. > > > >>>> > > > >>>>I believe that it is possible to design the protocol for > > > >>> > > > >>the required > > > >> > > > >>>>flexibility. I know it is possible to implement a > > > product with the > > > >>>>required flexibility. > > > >>>> > > > >>>>-Bob O'Hara > > > >>>> > > > >>>> > > > >>>>-----Original Message----- > > > >>>>From: capwap-admin@frascone.com > > > >>> > > > >>[mailto:capwap-admin@frascone.com] On > > > >> > > > >>>>Behalf Of Abhijit Choudhury > > > >>>>Sent: Thursday, August 05, 2004 11:32 AM > > > >>>>To: James Kempf; Shehzad Merchant; capwap@frascone.com > > > >>>>Cc: bwijnen@lucent.com; mmani@avaya.com;=20 > > david.kessens@nokia.com;=20 > > > >>>>Dorothy.Gellert@nokia.com; Inderpreet Singh > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>> > > > >>>>It may be possible to achieve such interoperability=20 > within the=20 > > > >>>>split-MAC family or within the local-MAC family. It > > > would sbe very > > > >>>>hard to achieve that between local and split MAC families. > > > >>>> > > > >>>>For example, if vendor X's WTP terminates 802.11 ctrl/mgmt > > > >>> > > > >>packets and > > > >> > > > >>> > > > >>>>vendor Y's AC expects the 802.11 mgmt packets to come to > > > >>> > > > >>it, there's > > > >> > > > >>>>no way you can be interoperable. > > > >>>> > > > >>>>Or are we planning to specify ONE architecture ? > > > >>>>The last thing IETF should do is mandate an implementation. > > > >>>> > > > >>>>I think a modest and reasonable goal is to come up with a > > > protocol > > > >>>>that allows sufficient flexbility so that vendors=20 > with splitMAC=20 > > > >>>>architectures can transfer most of the information they > > > care about > > > >>>>between the WTP and AC. > > > >>>> > > > >>>>Just my $0.02 ... > > > >>>> > > > >>>> > > > >>>>Abhijit Choudhury > > > >>>> > > > >>>> > > > >>>>-----Original Message----- > > > >>>>From: capwap-admin@frascone.com > > > >>> > > > >>[mailto:capwap-admin@frascone.com] On > > > >> > > > >>>>Behalf Of James Kempf > > > >>>>Sent: Wednesday, August 04, 2004 3:29 PM > > > >>>>To: Shehzad Merchant; capwap@frascone.com > > > >>>>Cc: bwijnen@lucent.com; mmani@avaya.com;=20 > > david.kessens@nokia.com;=20 > > > >>>>Dorothy.Gellert@nokia.com; Inderpreet Singh > > > >>>>Subject: Re: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>> > > > >>>>As a potential customer, let me put it concretely. I want > > > >>> > > > >>to be able > > > >> > > > >>>>to buy my access points from Vendor X and my switch from > > > >>> > > > >>Vendor Y and > > > >> > > > >>>>plug the two together and have them work without any > > > configuration.=20 > > > >>>>Also, I'd like to be able to buy switches from Vendor Y and > > > >>> > > > >>Vendor Z > > > >> > > > >>>>and be able to plug them into my network at various > > > places and have > > > >>>>them interoperate. > > > >>>> > > > >>>> jak > > > >>>> > > > >>>> > > > >>>>----- Original Message ----- > > > >>>>From: "Shehzad Merchant" > > > >>>>To: > > > >>>>Cc: ; ;=20 > > > >>>>; ; > > > "Inderpreet > > > >>>>Singh" > > > >>>> > > > >>>>Sent: Wednesday, August 04, 2004 3:19 PM > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>>>I think the implementation variations even with the > > > split MAC may > > > >>>>>cover a broad spectrum. As such its important to clearly > > > >>>> > > > >>articulate > > > >> > > > >>>>>what aspects > > > >>>> > > > >>>>of > > > >>>> > > > >>>> > > > >>>>>interoperability we are targetting. Is it truly just=20 > > > >>>>>control/management or is it interoperability between=20 > disparate=20 > > > >>>>>implementations of the split MAC, i.e. mix and match > > > >>>> > > > >>>>operation of WTP > > > >>>> > > > >>>> > > > >>>>>and ACs of all variants within this category. > > > >>>>> > > > >>>>>I suspect for the latter we may have to arrive at some > > > >>>> > > > >>consensus on > > > >> > > > >>>>>what particular implementations we are targeting > > > >>>> > > > >>>>interoperability for. > > > >>>> > > > >>>> > > > >>>> > > > >>>>>If so, ultimately this problem statement could become > > > part of the > > > >>>>>charter. > > > >>>>> > > > >>>>>-Shehzad > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>>-----Original Message----- > > > >>>>>From: capwap-admin@frascone.com > > > >>>> > > > >>>>[mailto:capwap-admin@frascone.com] On Behalf > > > >>>> > > > >>>> > > > >>>>>Of Dorothy.Gellert@nokia.com > > > >>>>>Sent: Wednesday, August 04, 2004 11:53 AM > > > >>>>>To: isingh@chantrynetworks.com; capwap@frascone.com > > > >>>>>Cc: bwijnen@lucent.com; mmani@avaya.com;=20 > > david.kessens@nokia.com > > > >>>>>Subject: RE: [Capwap] So many architectures, so little > > > >>>> > > > >>>>time... - take > > > >>>> > > > >>>> > > > >>>>>2 > > > >>>>> > > > >>>>>I believe this is the consensus, to scope the charter to > > > >>>> > > > >>>>Centralized > > > >>>> > > > >>>> > > > >>>>>Architecture and LocalMAC and Split MAC. > > > >>>>> > > > >>>>>I'll update the charter with this change after the CAPWAP > > > >>>> > > > >>>>WG Mtg. If > > > >>>> > > > >>>> > > > >>>>>there is resistance to this idea, please post to the list. > > > >>>>> > > > >>>>>Regards > > > >>>>>Dorothy > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>>>-----Original Message----- > > > >>>>>>From: capwap-admin@frascone.com > > > >>>>> > > > >>>>[mailto:capwap-admin@frascone.com]On > > > >>>> > > > >>>> > > > >>>>>>Behalf Of ext Inderpreet Singh > > > >>>>>>Sent: Tuesday, August 03, 2004 9:40 PM > > > >>>>>>To: capwap@frascone.com > > > >>>>>>Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David=20 > > > >>>>>>(Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > > > >>>>>>Subject: RE: [Capwap] So many architectures, so little > > > time... - > > > >>>>>>take 2 > > > >>>>>> > > > >>>>>> > > > >>>>>>The issue(s) at hand and my opinions are: > > > >>>>>> > > > >>>>>>1. Do we explicitly state in the re-charter which > > > >>>>> > > > >>>>architecture the > > > >>>> > > > >>>> > > > >>>>>>WG should consider? I think yes. I propose Centralized > > > >>>>> > > > >>>>architecture > > > >>>> > > > >>>> > > > >>>> > > > >>>>>>only. Autonomous and Distributed should be out of scope > > > >>>>> > > > >>>>based on the > > > >>>> > > > >>>> > > > >>>> > > > >>>>>>same reasons as per prior postings. > > > >>>>>> > > > >>>>>>2. Within Centralized do we focus on all three sub > > > >>>>> > > > >>>>architectures or > > > >>>> > > > >>>> > > > >>>>>>a subset? Remote MAC should be excluded because if I am not=20 > > > >>>>>>mistaken, the connectivity constraint between the WTP and > > > >>>>> > > > >>>>the AC is > > > >>>> > > > >>>> > > > >>>>>>"direct connect". > > > >>>>>>That being the case and that no IP layer is involved,=20 > > it doesn't > > > >>>>> > > > >>>>seem > > > >>>> > > > >>>> > > > >>>>>>clear what kind of protocol would help with > > > interoperability. I am > > > >>>>> > > > >>>>>>concerned about the impact, dependencies and > > > interaction with the > > > >>>>>>recently constituted IEEE Study group on AP > > > >>>>> > > > >>>>functionality on the > > > >>>> > > > >>>> > > > >>>>>>Split MAC architectures. Furthermore, there are some > > > >>>>> > > > >>>>pretty drastic > > > >>>> > > > >>>> > > > >>>>>>differences on how the vendors have chosen to split the > > > >>>>> > > > >>>>mac. Those > > > >>>> > > > >>>> > > > >>>>>>differences will need to be worked out before designing a > > > >>>>> > > > >>>>protocol. > > > >>>> > > > >>>> > > > >>>>>>So, if the low hanging fruit strategy (as James=20 > > suggested) for=20 > > > >>>>>>protocol development and progress is the way to go, > > > then I think > > > >>>>>>prioritizing on a protocol for Local MAC is a no brainer. > > > >>>>> > > > >>>>So as far > > > >>>> > > > >>>> > > > >>>>>>as focus, I feel we should do Local and Split and in=20 > > that order. > > > >>>>>> > > > >>>>>>3. This is not a re-chartering issue but is a=20 > > response to Pat's=20 > > > >>>>>>suggestion that a protocol that just sends the 802.11 > > > MAC frames > > > >>>>> > > > >>>>>>from the AP to the AC would work. I think possibly, yes. > > > >>>>> > > > >>>> > > > >>>>But again > > > >>>> > > > >>>> > > > >>>> > > > >>>>>>the complications of splitting the MAC in an > > > >>>>> > > > >>>>interoperable way will > > > >>>> > > > >>>> > > > >>>>>>be an issue. Also, you may note in the draft to which > > > >>>>> > > > >>>>you refer, we > > > >>>> > > > >>>> > > > >>>> > > > >>>>>>included a capabilities exchange phase. I had thought of > > > >>>>> > > > >>>>including > > > >>>> > > > >>>> > > > >>>>>>in the capability exchange such things as "AP supports > > > Local MAC" > > > >>>>>>and "AP supports Split MAC", but didn't put it in=20 > because the=20 > > > >>>>>>Taxonomy work was still in progress. Now that it is > > > pretty much > > > >>>>>>done we could surely include that. But again...let's=20 > > recharter=20 > > > >>>>>>first. > > > >>>>>> > > > >>>>>>Thanks. Do people agree with 1 & 2? > > > >>>>>> > > > >>>>>>--- > > > >>>>>>Inderpreet Singh > > > >>>>>>Chantry Networks > > > >>>>>>isingh@chantrynetworks.com > > > >>>>>>Cell: 416-831-3705 > > > >>>>>> > > > >>>>>>-----Original Message----- > > > >>>>>>From: capwap-admin@frascone.com > > > >>>>> > > > >>>>[mailto:capwap-admin@frascone.com] > > > >>>> > > > >>>> > > > >>>>>>On Behalf Of Pat R. Calhoun > > > >>>>>>Sent: Tuesday, August 03, 2004 6:04 PM > > > >>>>>>To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com;=20 > > > >>>>>>capwap@frascone.com > > > >>>>>>Cc: bwijnen@lucent.com; mmani@avaya.com;=20 > > david.kessens@nokia.com > > > >>>>>>Subject: [Capwap] So many architectures, so little > > > >>>>> > > > >>>>time... - take 2 > > > >>>> > > > >>>> > > > >>>>>>After reading Lily's response to Jim, I realize that I > > > >>>>> > > > >>>>fell down the > > > >>>> > > > >>>> > > > >>>> > > > >>>>>>same trap. Local MAC is also a centralized approach,=20 > > and so my=20 > > > >>>>>>previous response was not complete. I believe the real > > > >>>>> > > > >>>>question, in > > > >>>> > > > >>>> > > > >>>>>>my mind, is whether we need to address either the Local > > > >>>>> > > > >>>>or the Split > > > >>>> > > > >>>> > > > >>>> > > > >>>>>>MAC architecture. > > > >>>>>> > > > >>>>>>Just looking at the Architecture Consideration tables (7 and > > > >>>>>>10) in the > > > >>>>>>specification, the > > > >>>>>>main difference (at a high level) between both approaches > > > >>>>> > > > >>>>is where > > > >>>> > > > >>>> > > > >>>>>>the 802.11 management terminates. For Local MAC, it's > > > in the WTP, > > > >>>>>>while for SPlit MAC, it's in the AC. > > > >>>>>> > > > >>>>>>However, looking at table 8, most Local MAC approaches > > > share STA > > > >>>>>>state between both the WTP and the AC. So clearly=20 > > there is some=20 > > > >>>>>>signalling protocol between both the WTP and the AC. > > > >>>>>> > > > >>>>>>Looking at one example of a Local MAC protocol (see > > > >>>>>> > > > >>>>> > > >=20 > >=20 > >>>http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > > > >>> > > > >>> > > > >>>>>there is a protocol message > > > >>>>>that corresponds for every 802.11 MAC management event. So > > > >>>> > > > >>when a STA > > > >> > > > >> > > > >>>>>associates, the AP breaks the message apart and=20 > creates an new=20 > > > >>>>>protocol PDU, which contains components found in the=20 > > association=20 > > > >>>>>request. I suspect that most Local MAC approaches do > > > >>>> > > > >>something very > > > >> > > > >>>>>similar. > > > >>>>> > > > >>>>>So if a protocol simply tunnels the 802.11 MAC management > > > >>>> > > > >>frames from > > > >> > > > >> > > > >>>>>the WTP to the AC, it allows supports both approaches. For > > > >>>> > > > >>Local MAC, > > > >> > > > >> > > > >>>>>they get what they want via the 802.11 frame, and this > > > also works > > > >>>>>fine for Split MAC, which needs access to the MAC > > > >>>> > > > >>management frame.=20 > > > >> > > > >>>>>What would be required in such a protocol is a way for=20 > > the AP to=20 > > > >>>>>communicate whether it will be providing very specific > > > functions - > > > >>>>>basically a capabilities negotiation approach. > > > >>>>> > > > >>>>>So I do believe that there is a way to address both > > > architectures > > > >>>>>using a single protocol. > > > >>>>> > > > >>>>>Thoughts? > > > >>>>> > > > >>>>>PatC > > > >>>>> > > > >>>>>_______________________________________________ > > > >>>>>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=20 > > http://mail.frascone.com/mailman/listinfo/capwap > > >>>_______________________________________________ > > >>>Capwap mailing list > > >>>Capwap@frascone.com=20 > > http://mail.frascone.com/mailman/listinfo/capwap > > >>>_______________________________________________ > > >>>Capwap mailing list > > >>>Capwap@frascone.com=20 > > http://mail.frascone.com/mailman/listinfo/capwap > > >>>_______________________________________________ > > >>>Capwap mailing list > > >>>Capwap@frascone.com=20 > > http://mail.frascone.com/mailman/listinfo/capwap > > >>>_______________________________________________ > > >>>Capwap mailing list > > >>>Capwap@frascone.com=20 > > http://mail.frascone.com/mailman/listinfo/capwap > > >>>_______________________________________________ > > >>>Capwap mailing list > > >>>Capwap@frascone.com=20 > > http://mail.frascone.com/mailman/listinfo/capwap > > >>>_______________________________________________ > > >>>Capwap mailing list > > >>>Capwap@frascone.com > > >>>http://mail.frascone.com/mailman/listinfo/capwap > > >> > > >> > > >>-- > > >>Shankar Narayanaswamy, Ph.D. > > >>wireless@shankar.org Mobile: +1 650-387-4593 > > >>http://www.shankar.org E-Fax: +1 253-498-8372 > > >> > > >>_______________________________________________ > > >>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 > > >=20 > > >=20 > >=20 > >=20 > > -- > > Shankar Narayanaswamy, Ph.D. > > wireless@shankar.org Mobile: +1 650-387-4593 > > http://www.shankar.org E-Fax: +1 253-498-8372 > >=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 > >=20 >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Aug 12 20:18:32 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19336 for ; Thu, 12 Aug 2004 20:18:32 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0286C21614; Thu, 12 Aug 2004 20:01:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B9AA121080; Thu, 12 Aug 2004 20:01:07 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DB59D20DC2 for ; Thu, 12 Aug 2004 20:00:06 -0400 (EDT) Received: from sunny.soongsil.ac.kr (sunny.ssu.ac.kr [203.253.25.22]) by mail.frascone.com (Postfix) with ESMTP id 11FDD2138B for ; Thu, 12 Aug 2004 20:00:04 -0400 (EDT) Received: from lunarmanson ([203.253.27.139]) by sunny.soongsil.ac.kr (8.12.8/8.12.8) with SMTP id i7D0DQGg023058 for ; Fri, 13 Aug 2004 09:13:26 +0900 Message-ID: <001101c480ca$72c72760$8b1bfdcb@lunarmanson> From: =?ks_c_5601-1987?B?uq+xpMij?= To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C48115.E29490A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] subscribe 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, 13 Aug 2004 09:14:06 +0900 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C48115.E29490A0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 c3Vic2NyaWJlDQoNCiBCZXN0IHJlZ2FyZHMuIA0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSANCiAgICAgICAgICAga3dhbmcgaG8gQnl1biAoQktIKSANCiAgICAgICAg ICAgDQogICAgICAgICAgIENvbW11bmljYXRpb24gTGFiLiBTY2hvb2wgb2YgQ29tcHV0aW5nDQog ICAgICAgICAgIFNvb25nLXNpbCBVbml2LiAoc3N1LmFjLmtyKSAgDQogICAgICAgICAgIEUtbWFp bDogbWFuc29uQHN1bm55LnNzdS5hYy5rciANCiAgICAgICAgICAgV2ViOiBzdW5ueS5zc3UuYWMu a3IgDQogICAgICAgICAgIFBob25lIE9mZmljZTogKzgyLTItODEyLTA2ODkgDQogICAgICAgICAg IE1vYmlsZSBQaG9uZTogKzgyLTExLTk5MzQtNTc5MSAgDQogICAgICAgICAgICM0MDIgQ29tbXVu aWNhdGlvbiBMYWIuIDIxZG9uZyAxLTEgU2FuZ2RvNS1Eb25nDQogICAgICAgICAgIERvbmdqYWst R3UgU2VvdWwgUy5Lb3JlYQ0KICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t IA== ------=_NextPart_000_000E_01C48115.E29490A0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI4MDAuMTQ1OCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPnN1YnNjcmli ZTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgc2l6ZT0yPiZuYnNwO0Jlc3QgcmVnYXJkcy4gPEJSPiZuYnNwOyZuYnNwOyANCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQo8QlI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGt3YW5nIGhvIEJ5 dW4gDQooQktIKSA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDb21tdW5pY2F0aW9uIA0KTGFiLiBTY2hvb2wg b2YgDQpDb21wdXRpbmc8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KU29vbmctc2lsIFVuaXYuIChzc3UuYWMua3IpJm5ic3A7 IA0KPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBFLW1haWw6IDxBIA0KaHJlZj0ibWFpbHRvOm1hbnNvbkBzdW5ueS5zc3UuYWMu a3IiPm1hbnNvbkBzdW5ueS5zc3UuYWMua3I8L0E+IA0KPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBXZWI6IA0Kc3Vubnkuc3N1 LmFjLmtyIDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgDQpQaG9uZSBPZmZpY2U6ICs4Mi0yLTgxMi0wNjg5IA0KPEJSPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBN b2JpbGUgUGhvbmU6IA0KKzgyLTExLTk5MzQtNTc5MSZuYnNwOyANCjxCUj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgIzQwMiANCkNv bW11bmljYXRpb24gTGFiLiAyMWRvbmcgMS0xIA0KU2FuZ2RvNS1Eb25nPEJSPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCkRvbmdq YWstR3UgU2VvdWwgUy5Lb3JlYTxCUj4mbmJzcDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSANCjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_000E_01C48115.E29490A0-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Aug 13 01:27:03 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04991 for ; Fri, 13 Aug 2004 01:27:03 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D3DA621651; Fri, 13 Aug 2004 01:12:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 056612126D; Fri, 13 Aug 2004 01:12:07 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6127F2126D for ; Fri, 13 Aug 2004 01:11:35 -0400 (EDT) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id D09F020F02 for ; Fri, 13 Aug 2004 01:11:32 -0400 (EDT) Received: from Saravanan ([10.81.113.32]) by mailsrv.psl.com.sg (8.13.0/8.13.0) with ESMTP id i7D5O7p3006958; Fri, 13 Aug 2004 13:24:07 +0800 (SGT) Message-Id: <200408130524.i7D5O7p3006958@mailsrv.psl.com.sg> From: "Saravanan Govindan" To: "'Yang, Lily L'" , "'Wijnen, Bert (Bert)'" , "'Shankar Narayanaswamy'" , Cc: Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC Organization: Panasonic Singapore Laboratories MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSATx3ubzyBW0DHT0Oo3dMJW6wbqQAQKFiAABkwHDA= In-Reply-To: <2AF68A477DD44C4EBCBE338C24E7A9EE01836F8D@orsmsx408> 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, 13 Aug 2004 13:26:15 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Lily, Good analysis of the different paths. Some input on the data & control plane separation; when using 802.1X, authentication information is encapsulated in 802.11 data frames. In such cases, we have 802.1X control information embedded in the data plane. So, it may not be possible to make a clean separation between data and control planes. Some sort of snooping will have to be done on the data frames to check if they are carrying authentication (control) information. This situtaion could be included as one that needs to be addressed. Cheers Saravanan > To examine our options of architecture assumptions, let me > first put our my definition of data plane and control plane > just to make sure we start from the same page: > > To me, 802.11 data plane means the dath path travelled by the native > 802.11 data frames while 802.11 control plane means the data > path between 802.11 STA and the 802.11-awared control end point. > > For both Local and Split MAC, that 802.11-awared control > point is AC. So both architecture has the same control path: > STA->WTP->AC. The difference is how that control messages are > implemented between WTP and > AC: Split MAC simply tunneled the 802.11 management frames, > while Local MAC translated them into some other non-802.11 > forms. Another (implied) difference is that Split MAC largely > relies on the AC to respond to those management frames from > STA, while Local MAC relies on WTP to respond, but allow AC > to be informed of such events as well. So the timing > constraint may be more relaxed for local MAC. > > The question is on the data path. Here is my understanding so far: > In Local MAC, the data path is between STA and WTP. From WTP, > it can be switched or routed locally, entirely bypassing AC. > For Split MAC, My impression has been that the data path is > between STA and WTP and AC, because it seems that Split MAC > vendors tunnel ALL 802.11 data back to AC, even though I > don't see why it has to be that way. Just from the recent > discussion, some have hinted that even Split MAC can allow > data path terminate at WTP and be "locally" switched without > involving AC. Is this true? Can anyone confirm more > explicitly and elaborate this for me? > > > To summarize: > Common control path: STA->WTP->AC. (but control messages > between WTP<->AC are done diffrently) Local MAC data path: STA->WTP. > Split MAC data path: STA->WTP->AC or STA->WTP (This needs to > be clarified). > > My hunch is that CAPWAP protocol would have to allow the > flexibility in datapath, for either architecture (Split or > Local). So in that case, it doesn't really matter if it is > Split or Local, it should allow datapath to be configurable > any way. In that sense, I agree with what Shankar was saying > here. This seems also suggest that YES, we can cleanly > separate data plane and control plane here. But that doesn't > mean any discussion around data plane is out of scope -- > because guess what? Why do we need the control plane at the > first place? To control and configure the data plane! > > So understanding what data plane needs would drive our > discussion for the control plane and CAPWAP. > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Aug 13 13:04:01 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29262 for ; Fri, 13 Aug 2004 13:04:00 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 34E7F202C5; Fri, 13 Aug 2004 12:49:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CC85A205EA; Fri, 13 Aug 2004 12:49:06 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 731AF205EA for ; Fri, 13 Aug 2004 12:48:03 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id A8CAC202C5 for ; Fri, 13 Aug 2004 12:48:01 -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 i7DH1C2A006018 for ; Fri, 13 Aug 2004 13:01: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 i7DH1A2A005980 for ; Fri, 13 Aug 2004 13:01:11 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Data plane and control plane separation in Split MAC Message-ID: Thread-Topic: [Capwap] Re: Data plane and control plane separation in Split MAC Thread-Index: AcSATx3ubzyBW0DHT0Oo3dMJW6wbqQAQKFiAABkwHDAAEkekIA== From: "Mani, Mahalingam (Mahalingam)" To: "Saravanan Govindan" , "Yang, Lily L" , "Wijnen, Bert (Bert)" , "Shankar Narayanaswamy" , 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, 13 Aug 2004 11:02:42 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Dataplane and control plane does not (have to) equate to 802.11 data frames and non-data frames verbatim. Specifically - 802.1X frame authentication traffic is distinguished at AP(WTP) as controlled port traffic i.e., as an AP function (, if you will) It can be classified as a (CAPWAP) control plane traffic and mapped as such. It is also true the 'real' control port function may end up residing in some arch. in AC. But a state-representation of it can (& will) still be present in WTP - if for nothing other than blocking data traffic until authentication. I suppose that is true for the protected 'tunneled' authentication part as well. This is a classic example needing to distinguish between identifying WLAN AP functions (not so much where they reside) but how they may interface & be controlled - beyond 802.11 MAC layer services. Thus, the reference would be more appropriately to CAPWAP 'data-plane' (it exists and is impacted - but not the focus of CAPWAP protocol) and control-plane - if you will - and how AP flows map to each. Comments? The case that Behcet is alluding to is more interesting. If I understand correctly where a 'non-AP' function is involved by way of user authentication that is not a standard recognizable as a MAC/link-layer function/interface; it is a higher layer function served by a higher layer service (at AC presumably) - past the 802.1X authentication. It looks clearly out of scope. I may have understood the issue wrongly - I could not spot the related text in the referred CTP draft. Regards, -mani -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan Sent: Thursday, August 12, 2004 10:26 PM To: 'Yang, Lily L'; 'Wijnen, Bert (Bert)'; 'Shankar Narayanaswamy'; Dorothy.Gellert@nokia.com Cc: capwap@frascone.com Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC Hi Lily, Good analysis of the different paths. Some input on the data & control plane separation; when using 802.1X, authentication information is encapsulated in 802.11 data frames. In such cases, we have 802.1X control information embedded in the data plane. So, it may not be possible to make a clean separation between data and control planes. Some sort of snooping will have to be done on the data frames to check if they are carrying authentication (control) information. This situtaion could be included as one that needs to be addressed.=20 Cheers Saravanan =20 > To examine our options of architecture assumptions, let me=20 > first put our my definition of data plane and control plane=20 > just to make sure we start from the same page: >=20 > To me, 802.11 data plane means the dath path travelled by the native > 802.11 data frames while 802.11 control plane means the data=20 > path between 802.11 STA and the 802.11-awared control end point. =20 >=20 > For both Local and Split MAC, that 802.11-awared control=20 > point is AC. So both architecture has the same control path:=20 > STA->WTP->AC. The difference is how that control messages are=20 > implemented between WTP and > AC: Split MAC simply tunneled the 802.11 management frames,=20 > while Local MAC translated them into some other non-802.11=20 > forms. Another (implied) difference is that Split MAC largely=20 > relies on the AC to respond to those management frames from=20 > STA, while Local MAC relies on WTP to respond, but allow AC=20 > to be informed of such events as well. So the timing=20 > constraint may be more relaxed for local MAC. >=20 > The question is on the data path. Here is my understanding so far: > In Local MAC, the data path is between STA and WTP. From WTP,=20 > it can be switched or routed locally, entirely bypassing AC. =20 > For Split MAC, My impression has been that the data path is=20 > between STA and WTP and AC, because it seems that Split MAC=20 > vendors tunnel ALL 802.11 data back to AC, even though I=20 > don't see why it has to be that way. Just from the recent=20 > discussion, some have hinted that even Split MAC can allow=20 > data path terminate at WTP and be "locally" switched without=20 > involving AC. Is this true? Can anyone confirm more=20 > explicitly and elaborate this for me? >=20 >=20 > To summarize: > Common control path: STA->WTP->AC. (but control messages=20 > between WTP<->AC are done diffrently) Local MAC data path: STA->WTP. > Split MAC data path: STA->WTP->AC or STA->WTP (This needs to=20 > be clarified). >=20 > My hunch is that CAPWAP protocol would have to allow the=20 > flexibility in datapath, for either architecture (Split or=20 > Local). So in that case, it doesn't really matter if it is=20 > Split or Local, it should allow datapath to be configurable=20 > any way. In that sense, I agree with what Shankar was saying=20 > here. This seems also suggest that YES, we can cleanly=20 > separate data plane and control plane here. But that doesn't=20 > mean any discussion around data plane is out of scope --=20 > because guess what? Why do we need the control plane at the=20 > first place? To control and configure the data plane! >=20 > So understanding what data plane needs would drive our=20 > discussion for the control plane and 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 Fri Aug 13 13:28:03 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00657 for ; Fri, 13 Aug 2004 13:28:02 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BD3951FE3A; Fri, 13 Aug 2004 13:13:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 190151FF48; Fri, 13 Aug 2004 13:13:07 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 44B271FF48 for ; Fri, 13 Aug 2004 13:12:51 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 45D291FE3A for ; Fri, 13 Aug 2004 13:12:49 -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 i7DHKt9N019715 for ; Fri, 13 Aug 2004 12:20:55 -0500 (EST) 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 i7DHKq9N019660 for ; Fri, 13 Aug 2004 12:20:53 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4815A.D300F8B4" Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC Message-ID: Thread-Topic: [Capwap] Re: Data plane and control plane separation in Split MAC Thread-Index: AcSAtyMW0RmR3gG3SbaCIdtCVkydLAAoDcvw From: "Mani, Mahalingam (Mahalingam)" To: , "Wijnen, Bert (Bert)" 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, 13 Aug 2004 11:27:36 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C4815A.D300F8B4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Behcet, =20 The case you're alluding to is interesting. If I understand correctly where a 'non-AP' function is involved by way of user authentication that is not a standard recognizable as a MAC/link-layer function/interface; it is a higher layer function served by a higher layer service (at AC presumably) - past the 802.1X authentication. It looks clearly out of scope. I may have understood the issue wrongly - I could not spot the related text in the referred CTP draft. =20 [I suppose you are not referring to the 'inner' authentication phase of tunneled EAP methods? It is still EAP and the uncontrolled port does not enable controlled port (I guess I switched the terms in an earlier email) until the entire sequence completes.] =20 Can you expand on this further? =20 -mani _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Behcet Sarikaya Sent: Thursday, August 12, 2004 2:52 PM To: Wijnen, Bert (Bert) Cc: capwap@frascone.com Subject: Re: [Capwap] Re: Data plane and control plane separation in Split MAC =20 Wijnen, Bert (Bert) wrote: -----Original Message----- From: Shankar Narayanaswamy [mailto:wireless@shankar.org] Sent: donderdag 12 augustus 2004 05:13 To: Dorothy.Gellert@nokia.com Cc: capwap@frascone.com Subject: [Capwap] Re: Data plane and control plane separation in Split MAC =20 =20 The parameters by which the data plane communicates such as=20 authentication/security info, destination switch (if any) for data=20 frames, etc, are communicated by the control plane. Hence the need for=20 some architectural assumptions regarding the data plane even if the=20 focus is on the control plane. =20 Or at least a decision on the data plane architectures to be=20 supported. =20 =20 So... to me that sounds that we may potentially do an IMPLIED agreement=20 on the architecture for data plane, based on the capabilities we define in the standards track control and provisioning protocol. =20 That would be fine with me. But we should NOT get bogged down in that data plane stuff, or at least that to me seems to be the wrong focus. =20 Agreed. However, there might be interest in data packets for user-based security management. As in CTP, tunneling data frames to AC so that user-based authentication, etc. can be achieved. Is this within the scope? Otherwise control frames are probably sufficient for a control and provisioning protocol to deal with. --behcet ------_=_NextPart_001_01C4815A.D300F8B4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Behcet,

 

The case you’re alluding to is interesting. If I = understand correctly where a 'non-AP' function is involved by way of user = authentication that is not a standard recognizable as a MAC/link-layer = function/interface; it is a higher layer function served by a higher layer service (at AC = presumably) - past the 802.1X authentication. It looks clearly out of scope. I may = have understood the issue wrongly - I could not spot the related text in the = referred CTP draft.

 

[I suppose you are not referring to = the ‘inner’ authentication phase of tunneled EAP methods? It is still EAP and the = uncontrolled port does not enable controlled port (I guess I switched the terms in an earlier email) until the entire sequence = completes.]

 

Can you expand on this = further?

 

-mani

From: capwap-admin@frascone.com = [mailto:capwap-admin@frascone.com] On Behalf Of Behcet = Sarikaya
Sent: Thursday, August = 12, 2004 2:52 PM
To: Wijnen, Bert = (Bert)
Cc: = capwap@frascone.com
Subject: Re: [Capwap] Re: = Data plane and control plane separation in Split MAC

 

Wijnen, Bert (Bert) wrote:

-----Original =
Message-----
From: Shankar Narayanaswamy [mailto:wireless@shankar.org]
Sent: donderdag 12 augustus 2004 =
05:13
To: Dorothy.Gellert@nokia.com
Cc: capwap@frascone.com
Subject: [Capwap] Re: Data plane and control =
plane separation in Split
MAC
 
 
The parameters by which the data plane =
communicates such as 
authentication/security info, destination =
switch (if any) for data 
frames, etc, are communicated by the control =
plane. Hence the need for 
some architectural assumptions regarding the =
data plane even if the 
focus is on the control =
plane.
 
Or at least a decision on the data plane =
architectures to be 
supported.
=
 
    =

So... to me that sounds that we may =
potentially do an IMPLIED agreement =

on the architecture for data plane, based on =
the capabilities we define
in the standards track control and =
provisioning protocol.
 
That would be fine with me. But we should NOT =
get bogged down in that
data plane stuff, or at least that to me =
seems to be the wrong focus.
 

Agreed.
However, there might be interest in data packets for user-based security management. As in CTP,
tunneling data frames to AC so that user-based authentication, etc. can = be achieved.
Is this within the scope?
Otherwise control frames are probably sufficient for a control and = provisioning protocol to deal with.
--behcet

------_=_NextPart_001_01C4815A.D300F8B4-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Aug 13 15:45:18 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10009 for ; Fri, 13 Aug 2004 15:45:17 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E9D1D20338; Fri, 13 Aug 2004 15:30:19 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2F25220501; Fri, 13 Aug 2004 15:30:17 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9C2DB20338 for ; Fri, 13 Aug 2004 15:29:48 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id 36ADB1FF84 for ; Fri, 13 Aug 2004 15:29:46 -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] Re: Data plane and control plane separation in Split MAC X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: <55749BC69138654EBBC4C50BA4F55610029718DF@AIREMAIL.airespace.com> Thread-Topic: [Capwap] Re: Data plane and control plane separation in Split MAC Thread-Index: AcSATx3ubzyBW0DHT0Oo3dMJW6wbqQAQKFiAADePHZA= From: "Bob O'Hara" 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, 13 Aug 2004 12:47:30 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Lily, Your description of the data and control paths for the split MAC architecture are accurate for the Airespace system, where the data path is terminated in the AC (STA->WTP->AC). -Bob =20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Yang, Lily L Sent: Thursday, August 12, 2004 10:43 AM To: Wijnen, Bert (Bert); Shankar Narayanaswamy; Dorothy.Gellert@nokia.com Cc: capwap@frascone.com Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC To examine our options of architecture assumptions, let me first put our my definition of data plane and control plane just to make sure we start from the same page: To me, 802.11 data plane means the dath path travelled by the native 802.11 data frames while 802.11 control plane means the data path between 802.11 STA and the 802.11-awared control end point. =20 For both Local and Split MAC, that 802.11-awared control point is AC. So both architecture has the same control path: STA->WTP->AC. The difference is how that control messages are implemented between WTP and AC: Split MAC simply tunneled the 802.11 management frames, while Local MAC translated them into some other non-802.11 forms. Another (implied) difference is that Split MAC largely relies on the AC to respond to those management frames from STA, while Local MAC relies on WTP to respond, but allow AC to be informed of such events as well. So the timing constraint may be more relaxed for local MAC. The question is on the data path. Here is my understanding so far: In Local MAC, the data path is between STA and WTP. From WTP, it can be switched or routed locally, entirely bypassing AC. For Split MAC, My impression has been that the data path is between STA and WTP and AC, because it seems that Split MAC vendors tunnel ALL 802.11 data back to AC, even though I don't see why it has to be that way. Just from the recent discussion, some have hinted that even Split MAC can allow data path terminate at WTP and be "locally" switched without involving AC. Is this true? Can anyone confirm more explicitly and elaborate this for me? To summarize: Common control path: STA->WTP->AC. (but control messages between WTP<->AC are done diffrently) Local MAC data path: STA->WTP. Split MAC data path: STA->WTP->AC or STA->WTP (This needs to be clarified). My hunch is that CAPWAP protocol would have to allow the flexibility in datapath, for either architecture (Split or Local). So in that case, it doesn't really matter if it is Split or Local, it should allow datapath to be configurable any way. In that sense, I agree with what Shankar was saying here. This seems also suggest that YES, we can cleanly separate data plane and control plane here. But that doesn't mean any discussion around data plane is out of scope -- because guess what? Why do we need the control plane at the first place? To control and configure the data plane! So understanding what data plane needs would drive our discussion for the control plane and CAPWAP. > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of Wijnen, Bert (Bert) > Sent: Thursday, August 12, 2004 2:30 AM > To: Shankar Narayanaswamy; Dorothy.Gellert@nokia.com > Cc: capwap@frascone.com > Subject: RE: [Capwap] Re: Data plane and control plane=20 > separation in Split MAC >=20 > > -----Original Message----- > > From: Shankar Narayanaswamy [mailto:wireless@shankar.org] > > Sent: donderdag 12 augustus 2004 05:13 > > To: Dorothy.Gellert@nokia.com > > Cc: capwap@frascone.com > > Subject: [Capwap] Re: Data plane and control plane=20 > separation in Split=20 > > MAC > >=20 > >=20 > > The parameters by which the data plane communicates such as=20 > > authentication/security info, destination switch (if any) for data=20 > > frames, etc, are communicated by the control plane. Hence=20 > the need for=20 > > some architectural assumptions regarding the data plane even if the=20 > > focus is on the control plane. > >=20 > > Or at least a decision on the data plane architectures to be=20 > > supported. > >=20 > So... to me that sounds that we may potentially do an IMPLIED=20 > agreement on the architecture for data plane, based on the=20 > capabilities we define in the standards track control and=20 > provisioning protocol. >=20 > That would be fine with me. But we should NOT get bogged down=20 > in that data plane stuff, or at least that to me seems to be=20 > the wrong focus. >=20 > Bert > > -s > >=20 > > Dorothy.Gellert@nokia.com wrote: > > > Good point. Can we have the volunteers that submitted > > architectures for the taxonomy draft weigh in on this issue? =20 > > >=20 > > > Also another point to consider is that we don't have to > > implement *every* AP function in the first release of the CAPWAP=20 > > protocol. One of our charter goals is to start with > > the minimal set of functionality needed to provide control. =20 > > We have a "desirable" category where we can put objectives=20 > that can be=20 > > met with a later release or extension. > > >=20 > > > Dorothy > > >=20 > > >>-----Original Message----- > > >>From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com]On > > >>Behalf Of ext Yang, Lily L > > >>Sent: Tuesday, August 10, 2004 6:13 PM > > >>To: Sudhanshu Jain; Shehzad Merchant; Shankar=20 > Narayanaswamy; Abhijit=20 > > >>Choudhury > > >>Cc: capwap@frascone.com > > >>Subject: RE: [Capwap] So many architectures, so little time... -=20 > > >>take 2 > > >> > > >> > > >>The question in my mind is: Can data plane and control plane be=20 > > >>cleanly separated for Split MAC? I know it is feasible for Local > > MAC, but not > > >>sure about Split MAC.=20 > > >>Any insight? > > >> > > >>-----Original Message----- > > >>From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On > > >>Behalf Of Sudhanshu Jain > > >>Sent: Tuesday, August 10, 2004 11:55 AM > > >>To: Shehzad Merchant; Shankar Narayanaswamy; Abhijit Choudhury > > >>Cc: capwap@frascone.com > > >>Subject: RE: [Capwap] So many architectures, so little time... -=20 > > >>take 2 > > >> > > >>I fully agree with Shehzad. We need to separate the=20 > control and data=20 > > >>plane. Control plane should provide the framework to use one of=20 > > >>several tunneling protocol. > > >> > > >>On data plane, if we need to define a new layer2/layer3 level=20 > > >>tunneling protocol, it should be separate work from=20 > control protocol=20 > > >>work. > > >> > > >>-Suds > > >> > > >> > > >>-----Original Message----- > > >>From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On > > >>Behalf Of Shehzad Merchant > > >>Sent: Tuesday, August 10, 2004 11:13 AM > > >>To: Shankar Narayanaswamy; Abhijit Choudhury > > >>Cc: capwap@frascone.com > > >>Subject: RE: [Capwap] So many architectures, so little time... -=20 > > >>take 2 > > >> > > >>Additionally, for data tunneling one needs a lightweight=20 > mechanism=20 > > >>that may not necessarily have the same requirements as that for=20 > > >>control and management. For example, one would want to limit the=20 > > >>tunneling and processing overhead on data packets to a minimum.=20 > > >>Control and management may be more tolerant of=20 > > >>tunneling/security/etc. overhead. > > >>Besides, there are > > >>plenty of standards in place for data tunneling. We may > > potentially be > > >>able > > >>to leverage off that work itself without having to invent > > yet another > > >>tunneling mechanism for data.=20 > > >> > > >>-S > > >> > > >> > > >>-----Original Message----- > > >>From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On > > >>Behalf > > >>Of Shankar Narayanaswamy > > >>Sent: Tuesday, August 10, 2004 10:30 AM > > >>To: Abhijit Choudhury > > >>Cc: capwap@frascone.com > > >>Subject: Re: [Capwap] So many architectures, so little time... -=20 > > >>take 2 > > >> > > >>On the first point: not necessarily. If data packets are > > encapsulated > > >>802.11 data frames, then there is no need to protect them > > on the wire > > >>any > > >>more than they were encrypted over the air. > > >> > > >>But control and management packets will need protection > > over the wired > > >>network and therefore possibly a different tunneling protocol. > > >> > > >>On the second point (standard way of packet exchange): yes! > > >> > > >>-s > > >> > > >>Abhijit Choudhury wrote: > > >> > > >>>The same tunneling protocol that moves control and > > >> > > >>management packets > > >> > > >>>from the WTP to the AC should be used to tunnel data > > >> > > >>packets as well. > > >> > > >> > > >>>We would specify message exchanges to do control,=20 > provisioning and=20 > > >>>capability advertisement between WTPs and the AC. But=20 > all of this=20 > > >>>would be within the unified CAPWAP protocol that moves=20 > all packets=20 > > >>>including data between the WTP and AC. Vendors currently > > >> > > >>use LWAPP, > > >> > > >>>GRE, IP and some proprietary encapsulations to achieve=20 > this. This=20 > > >>>group would come up with a "standard" way of doing this exchange. > > >>> > > >>>At least that was my understanding.... > > >>> > > >>>Regards, > > >>>Abhijit > > >>> > > >>>-----Original Mssage----- > > >>>From: capwap-admin@frascone.com > > >> > > >>[mailto:capwap-admin@frascone.com] On > > >> > > >>>Behalf Of Wijnen, Bert (Bert) > > >>>Sent: Monday, August 09, 2004 6:14 AM > > >>>To: 'Yang, Lily L'; Burbank, Jack L.; Victor Lin; Bob O'Hara;=20 > > >>>capwap@frascone.com > > >>>Subject: RE: [Capwap] So many architectures, so little > > >> > > >>time... - take > > >> > > >>>2 > > >>> > > >>> > > >>>Not sure who is confused... probably me... > > >>> > > >>>My understanding was/is that IF we do re-charter for CAPWAP > > >> > > >>protocol > > >> > > >>>work, that it is then a NM protocol for "Control and > > >> > > >>Provisioning" and > > >> > > >> > > >>>not any of the related stuff that moves the data from WTP to AC. > > >>> > > >>>Is everybody in agreement with that understanding. > > >>> > > >>>Thanks, > > >>>Bert > > >>> > > >>> > > >>> > > >>>>-----Original Message----- > > >>>>From: Yang, Lily L [mailto:lily.l.yang@intel.com] > > >>>>Sent: maandag 9 augustus 2004 08:14 > > >>>>To: Burbank, Jack L.; Victor Lin ; Bob O'Hara ; > > capwap@frascone.com > > >>>>Subject: RE: [Capwap] So many architectures, so little > > >>> > > >>time... - take > > >> > > >>>>2 > > >>>> > > >>>> > > >>>>I think setting the re-charter scope to develop a single > > >>> > > >>protocol that > > >> > > >>> > > >>>>allows interoperability between Local and Split MAC is a > > reasonable > > >>>>tradeoff: > > >>>>We exclude remote MAC because the constraint it imposes is very=20 > > >>>>different from the rest and the benefit of including it is very=20 > > >>>>little. But Local and Split MAC are reasonably close and > > hence the > > >>>>effort may be incremental only. > > >>>>As many people noted, as of today, there is no single clear > > >>> > > >>definition > > >> > > >> > > >>>>of what "Local MAC" and "Split MAC" really means yet. Each > > >>> > > >>vendor has > > >> > > >>>>different definitions and some debate needs to happen so > > >>> > > >>that the WG > > >> > > >>>>can reach consensus on what exactly that means, and=20 > what kinds of=20 > > >>>>flexibility we want to retain within each class of > > >>> > > >>architecture, and > > >> > > >>>>what kind of differences we can to resolve and agree up > > front. That > > >>>>should also be part of the work items for the new WG -- > > >>> > > >>such agreement > > >> > > >> > > >>>>on the details for each architecture must be documented > > >>> > > >>somewhere, if > > >> > > >>>>not separately, then as part of the Protocol document. > > >>>> > > >>>>-----Original Message----- > > >>>>From: capwap-admin@frascone.com > > >>> > > >>[mailto:capwap-admin@frascone.com] On > > >> > > >>>>Behalf Of Burbank, Jack L. > > >>>>Sent: Thursday, August 05, 2004 12:14 PM > > >>>>To: 'Victor Lin '; 'Bob O'Hara '; 'capwap@frascone.com ' > > >>>>Subject: RE: [Capwap] So many architectures, so little > > >>> > > >>time... - take > > >> > > >>>>2 > > >>>> > > >>>>I think that interoperability between different > > >>> > > >>architectures should > > >> > > >>>>be a requirement, if not the key requirement. As was mentioned=20 > > >>>>yesterday, a goal of the IEEE is that they maintain > > flexibility in > > >>>>terms of how products and architectures are implemented. I > > >>> > > >>think we > > >> > > >>>>shouldn't do anything that is contrary to that goal (or > > at least we > > >>>>should minimize the impact). I think that the goal of > > >>> > > >>CAPWAP should > > >> > > >>>>be to retain this type of flexibility by designing a > > >>> > > >>protocol that can > > >> > > >> > > >>>>maintain this implementation flexibility but enable > > >>> > > >>interoperability > > >> > > >>>>between the various architecture implementations (that > > after all is > > >>>>the key problem with the deployment of these various > > >>> > > >>architectures - > > >> > > >>>>lack of interoperability). IMO, if we don't design for=20 > > >>>>interoperability between the basic architecture types, it > > >>> > > >>is debatable > > >> > > >> > > >>>>if something useful would have been accomplished. > > >>>> > > >>>>Jack Burbank > > >>>> > > >>>>-----Original Message----- > > >>>>From: capwap-admin@frascone.com > > >>>>To: Bob O'Hara; capwap@frascone.com > > >>>>Sent: 8/5/2004 2:46 PM > > >>>>Subject: RE: [Capwap] So many architectures, so little > > >>> > > >>time... - take > > >> > > >>>>2 > > >>>> > > >>>>I agree that we can design a protocol and implement the > > >>> > > >>product that > > >> > > >>>>works all architectures. I think the question to CAPWAP is: > > >>>> > > >>>>Should we make it a requirement in CAPWAP protocol to achieve=20 > > >>>>interoperability between different architectures? > > >>>> > > >>>>It is definitely doable, but I'm not sure if that is the > > >>> > > >>right thing > > >> > > >>>>to do.. > > >>>> > > >>>>Victor > > >>>> > > >>>>-----Original Message----- > > >>>>From: capwap-admin@frascone.com > > >>> > > >>[mailto:capwap-admin@frascone.com] On > > >> > > >>>>Behalf Of Bob O'Hara > > >>>>Sent: Thursday, August 05, 2004 11:43 AM > > >>>>To: capwap@frascone.com > > >>>>Subject: RE: [Capwap] So many architectures, so little > > >>> > > >>time... - take > > >> > > >>>>2 > > >>>> > > >>>>I think that interoperability will depend on two things. > > >>>>First, it will > > >>>>depend on how we define the protocol and the flexibility > > >>> > > >>for supported > > >> > > >> > > >>>>architectures it incorporates. Second, it will depend on what=20 > > >>>>manufacturers implement, i.e., the flexibility they build > > >>> > > >>into their > > >> > > >>>>products. > > >>>> > > >>>>I believe that it is possible to design the protocol for > > >>> > > >>the required > > >> > > >>>>flexibility. I know it is possible to implement a > > product with the > > >>>>required flexibility. > > >>>> > > >>>>-Bob O'Hara > > >>>> > > >>>> > > >>>>-----Original Message----- > > >>>>From: capwap-admin@frascone.com > > >>> > > >>[mailto:capwap-admin@frascone.com] On > > >> > > >>>>Behalf Of Abhijit Choudhury > > >>>>Sent: Thursday, August 05, 2004 11:32 AM > > >>>>To: James Kempf; Shehzad Merchant; capwap@frascone.com > > >>>>Cc: bwijnen@lucent.com; mmani@avaya.com;=20 > david.kessens@nokia.com;=20 > > >>>>Dorothy.Gellert@nokia.com; Inderpreet Singh > > >>>>Subject: RE: [Capwap] So many architectures, so little > > >>> > > >>time... - take > > >> > > >>>>2 > > >>>> > > >>>> > > >>>>It may be possible to achieve such interoperability within the=20 > > >>>>split-MAC family or within the local-MAC family. It > > would sbe very > > >>>>hard to achieve that between local and split MAC families. > > >>>> > > >>>>For example, if vendor X's WTP terminates 802.11 ctrl/mgmt > > >>> > > >>packets and > > >> > > >>> > > >>>>vendor Y's AC expects the 802.11 mgmt packets to come to > > >>> > > >>it, there's > > >> > > >>>>no way you can be interoperable. > > >>>> > > >>>>Or are we planning to specify ONE architecture ? > > >>>>The last thing IETF should do is mandate an implementation. > > >>>> > > >>>>I think a modest and reasonable goal is to come up with a > > protocol > > >>>>that allows sufficient flexbility so that vendors with splitMAC=20 > > >>>>architectures can transfer most of the information they > > care about > > >>>>between the WTP and AC. > > >>>> > > >>>>Just my $0.02 ... > > >>>> > > >>>> > > >>>>Abhijit Choudhury > > >>>> > > >>>> > > >>>>-----Original Message----- > > >>>>From: capwap-admin@frascone.com > > >>> > > >>[mailto:capwap-admin@frascone.com] On > > >> > > >>>>Behalf Of James Kempf > > >>>>Sent: Wednesday, August 04, 2004 3:29 PM > > >>>>To: Shehzad Merchant; capwap@frascone.com > > >>>>Cc: bwijnen@lucent.com; mmani@avaya.com;=20 > david.kessens@nokia.com;=20 > > >>>>Dorothy.Gellert@nokia.com; Inderpreet Singh > > >>>>Subject: Re: [Capwap] So many architectures, so little > > >>> > > >>time... - take > > >> > > >>>>2 > > >>>> > > >>>> > > >>>>As a potential customer, let me put it concretely. I want > > >>> > > >>to be able > > >> > > >>>>to buy my access points from Vendor X and my switch from > > >>> > > >>Vendor Y and > > >> > > >>>>plug the two together and have them work without any > > configuration.=20 > > >>>>Also, I'd like to be able to buy switches from Vendor Y and > > >>> > > >>Vendor Z > > >> > > >>>>and be able to plug them into my network at various > > places and have > > >>>>them interoperate. > > >>>> > > >>>> jak > > >>>> > > >>>> > > >>>>----- Original Message ----- > > >>>>From: "Shehzad Merchant" > > >>>>To: > > >>>>Cc: ; ;=20 > > >>>>; ; > > "Inderpreet > > >>>>Singh" > > >>>> > > >>>>Sent: Wednesday, August 04, 2004 3:19 PM > > >>>>Subject: RE: [Capwap] So many architectures, so little > > >>> > > >>time... - take > > >> > > >>>>2 > > >>>> > > >>>> > > >>>> > > >>>> > > >>>>>I think the implementation variations even with the > > split MAC may > > >>>>>cover a broad spectrum. As such its important to clearly > > >>>> > > >>articulate > > >> > > >>>>>what aspects > > >>>> > > >>>>of > > >>>> > > >>>> > > >>>>>interoperability we are targetting. Is it truly just=20 > > >>>>>control/management or is it interoperability between disparate=20 > > >>>>>implementations of the split MAC, i.e. mix and match > > >>>> > > >>>>operation of WTP > > >>>> > > >>>> > > >>>>>and ACs of all variants within this category. > > >>>>> > > >>>>>I suspect for the latter we may have to arrive at some > > >>>> > > >>consensus on > > >> > > >>>>>what particular implementations we are targeting > > >>>> > > >>>>interoperability for. > > >>>> > > >>>> > > >>>> > > >>>>>If so, ultimately this problem statement could become > > part of the > > >>>>>charter. > > >>>>> > > >>>>>-Shehzad > > >>>>> > > >>>>> > > >>>>> > > >>>>>-----Original Message----- > > >>>>>From: capwap-admin@frascone.com > > >>>> > > >>>>[mailto:capwap-admin@frascone.com] On Behalf > > >>>> > > >>>> > > >>>>>Of Dorothy.Gellert@nokia.com > > >>>>>Sent: Wednesday, August 04, 2004 11:53 AM > > >>>>>To: isingh@chantrynetworks.com; capwap@frascone.com > > >>>>>Cc: bwijnen@lucent.com; mmani@avaya.com;=20 > david.kessens@nokia.com > > >>>>>Subject: RE: [Capwap] So many architectures, so little > > >>>> > > >>>>time... - take > > >>>> > > >>>> > > >>>>>2 > > >>>>> > > >>>>>I believe this is the consensus, to scope the charter to > > >>>> > > >>>>Centralized > > >>>> > > >>>> > > >>>>>Architecture and LocalMAC and Split MAC. > > >>>>> > > >>>>>I'll update the charter with this change after the CAPWAP > > >>>> > > >>>>WG Mtg. If > > >>>> > > >>>> > > >>>>>there is resistance to this idea, please post to the list. > > >>>>> > > >>>>>Regards > > >>>>>Dorothy > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>>>-----Original Message----- > > >>>>>>From: capwap-admin@frascone.com > > >>>>> > > >>>>[mailto:capwap-admin@frascone.com]On > > >>>> > > >>>> > > >>>>>>Behalf Of ext Inderpreet Singh > > >>>>>>Sent: Tuesday, August 03, 2004 9:40 PM > > >>>>>>To: capwap@frascone.com > > >>>>>>Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David=20 > > >>>>>>(Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > > >>>>>>Subject: RE: [Capwap] So many architectures, so little > > time... - > > >>>>>>take 2 > > >>>>>> > > >>>>>> > > >>>>>>The issue(s) at hand and my opinions are: > > >>>>>> > > >>>>>>1. Do we explicitly state in the re-charter which > > >>>>> > > >>>>architecture the > > >>>> > > >>>> > > >>>>>>WG should consider? I think yes. I propose Centralized > > >>>>> > > >>>>architecture > > >>>> > > >>>> > > >>>> > > >>>>>>only. Autonomous and Distributed should be out of scope > > >>>>> > > >>>>based on the > > >>>> > > >>>> > > >>>> > > >>>>>>same reasons as per prior postings. > > >>>>>> > > >>>>>>2. Within Centralized do we focus on all three sub > > >>>>> > > >>>>architectures or > > >>>> > > >>>> > > >>>>>>a subset? Remote MAC should be excluded because if I am not=20 > > >>>>>>mistaken, the connectivity constraint between the WTP and > > >>>>> > > >>>>the AC is > > >>>> > > >>>> > > >>>>>>"direct connect". > > >>>>>>That being the case and that no IP layer is involved,=20 > it doesn't > > >>>>> > > >>>>seem > > >>>> > > >>>> > > >>>>>>clear what kind of protocol would help with > > interoperability. I am > > >>>>> > > >>>>>>concerned about the impact, dependencies and > > interaction with the > > >>>>>>recently constituted IEEE Study group on AP > > >>>>> > > >>>>functionality on the > > >>>> > > >>>> > > >>>>>>Split MAC architectures. Furthermore, there are some > > >>>>> > > >>>>pretty drastic > > >>>> > > >>>> > > >>>>>>differences on how the vendors have chosen to split the > > >>>>> > > >>>>mac. Those > > >>>> > > >>>> > > >>>>>>differences will need to be worked out before designing a > > >>>>> > > >>>>protocol. > > >>>> > > >>>> > > >>>>>>So, if the low hanging fruit strategy (as James=20 > suggested) for=20 > > >>>>>>protocol development and progress is the way to go, > > then I think > > >>>>>>prioritizing on a protocol for Local MAC is a no brainer. > > >>>>> > > >>>>So as far > > >>>> > > >>>> > > >>>>>>as focus, I feel we should do Local and Split and in=20 > that order. > > >>>>>> > > >>>>>>3. This is not a re-chartering issue but is a=20 > response to Pat's=20 > > >>>>>>suggestion that a protocol that just sends the 802.11 > > MAC frames > > >>>>> > > >>>>>>from the AP to the AC would work. I think possibly, yes. > > >>>>> > > >>>> > > >>>>But again > > >>>> > > >>>> > > >>>> > > >>>>>>the complications of splitting the MAC in an > > >>>>> > > >>>>interoperable way will > > >>>> > > >>>> > > >>>>>>be an issue. Also, you may note in the draft to which > > >>>>> > > >>>>you refer, we > > >>>> > > >>>> > > >>>> > > >>>>>>included a capabilities exchange phase. I had thought of > > >>>>> > > >>>>including > > >>>> > > >>>> > > >>>>>>in the capability exchange such things as "AP supports > > Local MAC" > > >>>>>>and "AP supports Split MAC", but didn't put it in because the=20 > > >>>>>>Taxonomy work was still in progress. Now that it is > > pretty much > > >>>>>>done we could surely include that. But again...let's=20 > recharter=20 > > >>>>>>first. > > >>>>>> > > >>>>>>Thanks. Do people agree with 1 & 2? > > >>>>>> > > >>>>>>--- > > >>>>>>Inderpreet Singh > > >>>>>>Chantry Networks > > >>>>>>isingh@chantrynetworks.com > > >>>>>>Cell: 416-831-3705 > > >>>>>> > > >>>>>>-----Original Message----- > > >>>>>>From: capwap-admin@frascone.com > > >>>>> > > >>>>[mailto:capwap-admin@frascone.com] > > >>>> > > >>>> > > >>>>>>On Behalf Of Pat R. Calhoun > > >>>>>>Sent: Tuesday, August 03, 2004 6:04 PM > > >>>>>>To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com;=20 > > >>>>>>capwap@frascone.com > > >>>>>>Cc: bwijnen@lucent.com; mmani@avaya.com;=20 > david.kessens@nokia.com > > >>>>>>Subject: [Capwap] So many architectures, so little > > >>>>> > > >>>>time... - take 2 > > >>>> > > >>>> > > >>>>>>After reading Lily's response to Jim, I realize that I > > >>>>> > > >>>>fell down the > > >>>> > > >>>> > > >>>> > > >>>>>>same trap. Local MAC is also a centralized approach,=20 > and so my=20 > > >>>>>>previous response was not complete. I believe the real > > >>>>> > > >>>>question, in > > >>>> > > >>>> > > >>>>>>my mind, is whether we need to address either the Local > > >>>>> > > >>>>or the Split > > >>>> > > >>>> > > >>>> > > >>>>>>MAC architecture. > > >>>>>> > > >>>>>>Just looking at the Architecture Consideration tables (7 and > > >>>>>>10) in the > > >>>>>>specification, the > > >>>>>>main difference (at a high level) between both approaches > > >>>>> > > >>>>is where > > >>>> > > >>>> > > >>>>>>the 802.11 management terminates. For Local MAC, it's > > in the WTP, > > >>>>>>while for SPlit MAC, it's in the AC. > > >>>>>> > > >>>>>>However, looking at table 8, most Local MAC approaches > > share STA > > >>>>>>state between both the WTP and the AC. So clearly=20 > there is some=20 > > >>>>>>signalling protocol between both the WTP and the AC. > > >>>>>> > > >>>>>>Looking at one example of a Local MAC protocol (see > > >>>>>> > > >>>>> > >=20 > >>>http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > > >>> > > >>> > > >>>>>there is a protocol message > > >>>>>that corresponds for every 802.11 MAC management event. So > > >>>> > > >>when a STA > > >> > > >> > > >>>>>associates, the AP breaks the message apart and creates an new=20 > > >>>>>protocol PDU, which contains components found in the=20 > association=20 > > >>>>>request. I suspect that most Local MAC approaches do > > >>>> > > >>something very > > >> > > >>>>>similar. > > >>>>> > > >>>>>So if a protocol simply tunnels the 802.11 MAC management > > >>>> > > >>frames from > > >> > > >> > > >>>>>the WTP to the AC, it allows supports both approaches. For > > >>>> > > >>Local MAC, > > >> > > >> > > >>>>>they get what they want via the 802.11 frame, and this > > also works > > >>>>>fine for Split MAC, which needs access to the MAC > > >>>> > > >>management frame.=20 > > >> > > >>>>>What would be required in such a protocol is a way for=20 > the AP to=20 > > >>>>>communicate whether it will be providing very specific > > functions - > > >>>>>basically a capabilities negotiation approach. > > >>>>> > > >>>>>So I do believe that there is a way to address both > > architectures > > >>>>>using a single protocol. > > >>>>> > > >>>>>Thoughts? > > >>>>> > > >>>>>PatC > > >>>>> > > >>>>>_______________________________________________ > > >>>>>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=20 > http://mail.frascone.com/mailman/listinfo/capwap > >>>_______________________________________________ > >>>Capwap mailing list > >>>Capwap@frascone.com=20 > http://mail.frascone.com/mailman/listinfo/capwap > >>>_______________________________________________ > >>>Capwap mailing list > >>>Capwap@frascone.com=20 > http://mail.frascone.com/mailman/listinfo/capwap > >>>_______________________________________________ > >>>Capwap mailing list > >>>Capwap@frascone.com=20 > http://mail.frascone.com/mailman/listinfo/capwap > >>>_______________________________________________ > >>>Capwap mailing list > >>>Capwap@frascone.com=20 > http://mail.frascone.com/mailman/listinfo/capwap > >>>_______________________________________________ > >>>Capwap mailing list > >>>Capwap@frascone.com=20 > http://mail.frascone.com/mailman/listinfo/capwap > >>>_______________________________________________ > >>>Capwap mailing list > >>>Capwap@frascone.com > >>>http://mail.frascone.com/mailman/listinfo/capwap > >> > >> > >>-- > >>Shankar Narayanaswamy, Ph.D. > >>wireless@shankar.org Mobile: +1 650-387-4593 > >>http://www.shankar.org E-Fax: +1 253-498-8372 > >> > >>_______________________________________________ > >>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 > >=20 > >=20 >=20 >=20 > -- > Shankar Narayanaswamy, Ph.D. > wireless@shankar.org Mobile: +1 650-387-4593 > http://www.shankar.org E-Fax: +1 253-498-8372 >=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 >=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 Aug 13 15:57:07 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12157 for ; Fri, 13 Aug 2004 15:57:03 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4613D21C7F; Fri, 13 Aug 2004 15:42:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 443E921C7A; Fri, 13 Aug 2004 15:42:08 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 21DB221C7A for ; Fri, 13 Aug 2004 15:41:27 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id A28B720501 for ; Fri, 13 Aug 2004 15:41:24 -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] Re: Data plane and control plane separation in SplitMAC X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: <55749BC69138654EBBC4C50BA4F55610029718E2@AIREMAIL.airespace.com> Thread-Topic: [Capwap] Re: Data plane and control plane separation in SplitMAC Thread-Index: AcSAqjckPya/4OnTQrCIYdiZXlf3XQAxT/Lg From: "Bob O'Hara" 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, 13 Aug 2004 12:59:20 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I agree that for a complete solution, we cannot ignore the need for a data forwarding protocol. But for control and provisioning, not for operation, that problem can be separated from the initial protocol design. =20 What we might consider in the protocol design is negotiating the data forwarding protocol. I do not favor negotiation of that protocol as the final solution. It leads to too many options in a multivendor situation and will likely provide less interoperability rather than more. When the question arises, I would prefer we had the hard discussions to arrive at a single protocol to be used for data forwarding. -Bob =20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Partha Narasimhan Sent: Thursday, August 12, 2004 1:19 PM To: Lily L Yang Cc: Wijnen, Bert (Bert); Shankar Narayanaswamy; Dorothy.Gellert@nokia.com; capwap@frascone.com Subject: RE: [Capwap] Re: Data plane and control plane separation in SplitMAC The set of AP functions is split across the WTP and the AC in the split-MAC and, arguably to a lesser extent, in the local MAC architectures. As a result, the AP, in these architectures, is no longer a physical entity, but one that potentially spans a L3 boundary. The handling of data frames (and some mgmt frames in the split-MAC arch) within an AP could involve transferring it over a L3 network from the WTP to the AC or vice-versa. If these two end-points are from multiple different vendors, then there needs to be an agreement on the mode of this transfer. Hence, we cannot ignore this problem in defining a CAPWAP protocol. Thanks partha On Thu, 2004-08-12 at 10:42, Yang, Lily L wrote: > To examine our options of architecture assumptions, let me first put our > my definition of data plane and control plane just to make sure we start > from the same page: >=20 > To me, 802.11 data plane means the dath path travelled by the native > 802.11 data frames while 802.11 control plane means the data path > between 802.11 STA and the 802.11-awared control end point. =20 >=20 > For both Local and Split MAC, that 802.11-awared control point is AC. So > both architecture has the same control path: STA->WTP->AC. The > difference is how that control messages are implemented between WTP and > AC: Split MAC simply tunneled the 802.11 management frames, while Local > MAC translated them into some other non-802.11 forms. Another (implied) > difference is that Split MAC largely relies on the AC to respond to > those management frames from STA, while Local MAC relies on WTP to > respond, but allow AC to be informed of such events as well. So the > timing constraint may be more relaxed for local MAC. >=20 > The question is on the data path. Here is my understanding so far: > In Local MAC, the data path is between STA and WTP. From WTP, it can be > switched or routed locally, entirely bypassing AC. For Split MAC, My > impression has been that the data path is between STA and WTP and AC, > because it seems that Split MAC vendors tunnel ALL 802.11 data back to > AC, even though I don't see why it has to be that way. Just from the > recent discussion, some have hinted that even Split MAC can allow data > path terminate at WTP and be "locally" switched without involving AC. Is > this true? Can anyone confirm more explicitly and elaborate this for me? >=20 >=20 > To summarize: > Common control path: STA->WTP->AC. (but control messages between > WTP<->AC are done diffrently) > Local MAC data path: STA->WTP. > Split MAC data path: STA->WTP->AC or STA->WTP (This needs to be > clarified). >=20 > My hunch is that CAPWAP protocol would have to allow the flexibility in > datapath, for either architecture (Split or Local). So in that case, it > doesn't really matter if it is Split or Local, it should allow datapath > to be configurable any way. In that sense, I agree with what Shankar was > saying here. This seems also suggest that YES, we can cleanly separate > data plane and control plane here. But that doesn't mean any discussion > around data plane is out of scope -- because guess what? Why do we need > the control plane at the first place? To control and configure the data > plane! >=20 > So understanding what data plane needs would drive our discussion for > the control plane and CAPWAP. >=20 > > -----Original Message----- > > From: capwap-admin@frascone.com=20 > > [mailto:capwap-admin@frascone.com] On Behalf Of Wijnen, Bert (Bert) > > Sent: Thursday, August 12, 2004 2:30 AM > > To: Shankar Narayanaswamy; Dorothy.Gellert@nokia.com > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] Re: Data plane and control plane=20 > > separation in Split MAC > >=20 > > > -----Original Message----- > > > From: Shankar Narayanaswamy [mailto:wireless@shankar.org] > > > Sent: donderdag 12 augustus 2004 05:13 > > > To: Dorothy.Gellert@nokia.com > > > Cc: capwap@frascone.com > > > Subject: [Capwap] Re: Data plane and control plane=20 > > separation in Split=20 > > > MAC > > >=20 > > >=20 > > > The parameters by which the data plane communicates such as=20 > > > authentication/security info, destination switch (if any) for data > > > frames, etc, are communicated by the control plane. Hence=20 > > the need for=20 > > > some architectural assumptions regarding the data plane even if the=20 > > > focus is on the control plane. > > >=20 > > > Or at least a decision on the data plane architectures to be=20 > > > supported. > > >=20 > > So... to me that sounds that we may potentially do an IMPLIED=20 > > agreement on the architecture for data plane, based on the=20 > > capabilities we define in the standards track control and=20 > > provisioning protocol. > >=20 > > That would be fine with me. But we should NOT get bogged down=20 > > in that data plane stuff, or at least that to me seems to be=20 > > the wrong focus. > >=20 > > Bert > > > -s > > >=20 > > > Dorothy.Gellert@nokia.com wrote: > > > > Good point. Can we have the volunteers that submitted > > > architectures for the taxonomy draft weigh in on this issue? =20 > > > >=20 > > > > Also another point to consider is that we don't have to > > > implement *every* AP function in the first release of the CAPWAP=20 > > > protocol. One of our charter goals is to start with > > > the minimal set of functionality needed to provide control. =20 > > > We have a "desirable" category where we can put objectives=20 > > that can be=20 > > > met with a later release or extension. > > > >=20 > > > > Dorothy > > > >=20 > > > >>-----Original Message----- > > > >>From: capwap-admin@frascone.com=20 > > [mailto:capwap-admin@frascone.com]On > > > >>Behalf Of ext Yang, Lily L > > > >>Sent: Tuesday, August 10, 2004 6:13 PM > > > >>To: Sudhanshu Jain; Shehzad Merchant; Shankar=20 > > Narayanaswamy; Abhijit=20 > > > >>Choudhury > > > >>Cc: capwap@frascone.com > > > >>Subject: RE: [Capwap] So many architectures, so little time... - > > > >>take 2 > > > >> > > > >> > > > >>The question in my mind is: Can data plane and control plane be=20 > > > >>cleanly separated for Split MAC? I know it is feasible for Local > > > MAC, but not > > > >>sure about Split MAC.=20 > > > >>Any insight? > > > >> > > > >>-----Original Message----- > > > >>From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On > > > >>Behalf Of Sudhanshu Jain > > > >>Sent: Tuesday, August 10, 2004 11:55 AM > > > >>To: Shehzad Merchant; Shankar Narayanaswamy; Abhijit Choudhury > > > >>Cc: capwap@frascone.com > > > >>Subject: RE: [Capwap] So many architectures, so little time... - > > > >>take 2 > > > >> > > > >>I fully agree with Shehzad. We need to separate the=20 > > control and data=20 > > > >>plane. Control plane should provide the framework to use one of=20 > > > >>several tunneling protocol. > > > >> > > > >>On data plane, if we need to define a new layer2/layer3 level=20 > > > >>tunneling protocol, it should be separate work from=20 > > control protocol=20 > > > >>work. > > > >> > > > >>-Suds > > > >> > > > >> > > > >>-----Original Message----- > > > >>From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On > > > >>Behalf Of Shehzad Merchant > > > >>Sent: Tuesday, August 10, 2004 11:13 AM > > > >>To: Shankar Narayanaswamy; Abhijit Choudhury > > > >>Cc: capwap@frascone.com > > > >>Subject: RE: [Capwap] So many architectures, so little time... - > > > >>take 2 > > > >> > > > >>Additionally, for data tunneling one needs a lightweight=20 > > mechanism=20 > > > >>that may not necessarily have the same requirements as that for=20 > > > >>control and management. For example, one would want to limit the > > > >>tunneling and processing overhead on data packets to a minimum.=20 > > > >>Control and management may be more tolerant of=20 > > > >>tunneling/security/etc. overhead. > > > >>Besides, there are > > > >>plenty of standards in place for data tunneling. We may > > > potentially be > > > >>able > > > >>to leverage off that work itself without having to invent > > > yet another > > > >>tunneling mechanism for data.=20 > > > >> > > > >>-S > > > >> > > > >> > > > >>-----Original Message----- > > > >>From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On > > > >>Behalf > > > >>Of Shankar Narayanaswamy > > > >>Sent: Tuesday, August 10, 2004 10:30 AM > > > >>To: Abhijit Choudhury > > > >>Cc: capwap@frascone.com > > > >>Subject: Re: [Capwap] So many architectures, so little time... - > > > >>take 2 > > > >> > > > >>On the first point: not necessarily. If data packets are > > > encapsulated > > > >>802.11 data frames, then there is no need to protect them > > > on the wire > > > >>any > > > >>more than they were encrypted over the air. > > > >> > > > >>But control and management packets will need protection > > > over the wired > > > >>network and therefore possibly a different tunneling protocol. > > > >> > > > >>On the second point (standard way of packet exchange): yes! > > > >> > > > >>-s > > > >> > > > >>Abhijit Choudhury wrote: > > > >> > > > >>>The same tunneling protocol that moves control and > > > >> > > > >>management packets > > > >> > > > >>>from the WTP to the AC should be used to tunnel data > > > >> > > > >>packets as well. > > > >> > > > >> > > > >>>We would specify message exchanges to do control,=20 > > provisioning and=20 > > > >>>capability advertisement between WTPs and the AC. But=20 > > all of this=20 > > > >>>would be within the unified CAPWAP protocol that moves=20 > > all packets=20 > > > >>>including data between the WTP and AC. Vendors currently > > > >> > > > >>use LWAPP, > > > >> > > > >>>GRE, IP and some proprietary encapsulations to achieve=20 > > this. This=20 > > > >>>group would come up with a "standard" way of doing this exchange. > > > >>> > > > >>>At least that was my understanding.... > > > >>> > > > >>>Regards, > > > >>>Abhijit > > > >>> > > > >>>-----Original Mssage----- > > > >>>From: capwap-admin@frascone.com > > > >> > > > >>[mailto:capwap-admin@frascone.com] On > > > >> > > > >>>Behalf Of Wijnen, Bert (Bert) > > > >>>Sent: Monday, August 09, 2004 6:14 AM > > > >>>To: 'Yang, Lily L'; Burbank, Jack L.; Victor Lin; Bob O'Hara;=20 > > > >>>capwap@frascone.com > > > >>>Subject: RE: [Capwap] So many architectures, so little > > > >> > > > >>time... - take > > > >> > > > >>>2 > > > >>> > > > >>> > > > >>>Not sure who is confused... probably me... > > > >>> > > > >>>My understanding was/is that IF we do re-charter for CAPWAP > > > >> > > > >>protocol > > > >> > > > >>>work, that it is then a NM protocol for "Control and > > > >> > > > >>Provisioning" and > > > >> > > > >> > > > >>>not any of the related stuff that moves the data from WTP to AC. > > > >>> > > > >>>Is everybody in agreement with that understanding. > > > >>> > > > >>>Thanks, > > > >>>Bert > > > >>> > > > >>> > > > >>> > > > >>>>-----Original Message----- > > > >>>>From: Yang, Lily L [mailto:lily.l.yang@intel.com] > > > >>>>Sent: maandag 9 augustus 2004 08:14 > > > >>>>To: Burbank, Jack L.; Victor Lin ; Bob O'Hara ; > > > capwap@frascone.com > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>> > > > >>>>I think setting the re-charter scope to develop a single > > > >>> > > > >>protocol that > > > >> > > > >>> > > > >>>>allows interoperability between Local and Split MAC is a > > > reasonable > > > >>>>tradeoff: > > > >>>>We exclude remote MAC because the constraint it imposes is very=20 > > > >>>>different from the rest and the benefit of including it is very=20 > > > >>>>little. But Local and Split MAC are reasonably close and > > > hence the > > > >>>>effort may be incremental only. > > > >>>>As many people noted, as of today, there is no single clear > > > >>> > > > >>definition > > > >> > > > >> > > > >>>>of what "Local MAC" and "Split MAC" really means yet. Each > > > >>> > > > >>vendor has > > > >> > > > >>>>different definitions and some debate needs to happen so > > > >>> > > > >>that the WG > > > >> > > > >>>>can reach consensus on what exactly that means, and=20 > > what kinds of=20 > > > >>>>flexibility we want to retain within each class of > > > >>> > > > >>architecture, and > > > >> > > > >>>>what kind of differences we can to resolve and agree up > > > front. That > > > >>>>should also be part of the work items for the new WG -- > > > >>> > > > >>such agreement > > > >> > > > >> > > > >>>>on the details for each architecture must be documented > > > >>> > > > >>somewhere, if > > > >> > > > >>>>not separately, then as part of the Protocol document. > > > >>>> > > > >>>>-----Original Message----- > > > >>>>From: capwap-admin@frascone.com > > > >>> > > > >>[mailto:capwap-admin@frascone.com] On > > > >> > > > >>>>Behalf Of Burbank, Jack L. > > > >>>>Sent: Thursday, August 05, 2004 12:14 PM > > > >>>>To: 'Victor Lin '; 'Bob O'Hara '; 'capwap@frascone.com ' > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>>I think that interoperability between different > > > >>> > > > >>architectures should > > > >> > > > >>>>be a requirement, if not the key requirement. As was mentioned=20 > > > >>>>yesterday, a goal of the IEEE is that they maintain > > > flexibility in > > > >>>>terms of how products and architectures are implemented. I > > > >>> > > > >>think we > > > >> > > > >>>>shouldn't do anything that is contrary to that goal (or > > > at least we > > > >>>>should minimize the impact). I think that the goal of > > > >>> > > > >>CAPWAP should > > > >> > > > >>>>be to retain this type of flexibility by designing a > > > >>> > > > >>protocol that can > > > >> > > > >> > > > >>>>maintain this implementation flexibility but enable > > > >>> > > > >>interoperability > > > >> > > > >>>>between the various architecture implementations (that > > > after all is > > > >>>>the key problem with the deployment of these various > > > >>> > > > >>architectures - > > > >> > > > >>>>lack of interoperability). IMO, if we don't design for=20 > > > >>>>interoperability between the basic architecture types, it > > > >>> > > > >>is debatable > > > >> > > > >> > > > >>>>if something useful would have been accomplished. > > > >>>> > > > >>>>Jack Burbank > > > >>>> > > > >>>>-----Original Message----- > > > >>>>From: capwap-admin@frascone.com > > > >>>>To: Bob O'Hara; capwap@frascone.com > > > >>>>Sent: 8/5/2004 2:46 PM > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>>I agree that we can design a protocol and implement the > > > >>> > > > >>product that > > > >> > > > >>>>works all architectures. I think the question to CAPWAP is: > > > >>>> > > > >>>>Should we make it a requirement in CAPWAP protocol to achieve=20 > > > >>>>interoperability between different architectures? > > > >>>> > > > >>>>It is definitely doable, but I'm not sure if that is the > > > >>> > > > >>right thing > > > >> > > > >>>>to do.. > > > >>>> > > > >>>>Victor > > > >>>> > > > >>>>-----Original Message----- > > > >>>>From: capwap-admin@frascone.com > > > >>> > > > >>[mailto:capwap-admin@frascone.com] On > > > >> > > > >>>>Behalf Of Bob O'Hara > > > >>>>Sent: Thursday, August 05, 2004 11:43 AM > > > >>>>To: capwap@frascone.com > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>>I think that interoperability will depend on two things. > > > >>>>First, it will > > > >>>>depend on how we define the protocol and the flexibility > > > >>> > > > >>for supported > > > >> > > > >> > > > >>>>architectures it incorporates. Second, it will depend on what > > > >>>>manufacturers implement, i.e., the flexibility they build > > > >>> > > > >>into their > > > >> > > > >>>>products. > > > >>>> > > > >>>>I believe that it is possible to design the protocol for > > > >>> > > > >>the required > > > >> > > > >>>>flexibility. I know it is possible to implement a > > > product with the > > > >>>>required flexibility. > > > >>>> > > > >>>>-Bob O'Hara > > > >>>> > > > >>>> > > > >>>>-----Original Message----- > > > >>>>From: capwap-admin@frascone.com > > > >>> > > > >>[mailto:capwap-admin@frascone.com] On > > > >> > > > >>>>Behalf Of Abhijit Choudhury > > > >>>>Sent: Thursday, August 05, 2004 11:32 AM > > > >>>>To: James Kempf; Shehzad Merchant; capwap@frascone.com > > > >>>>Cc: bwijnen@lucent.com; mmani@avaya.com;=20 > > david.kessens@nokia.com;=20 > > > >>>>Dorothy.Gellert@nokia.com; Inderpreet Singh > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>> > > > >>>>It may be possible to achieve such interoperability within the > > > >>>>split-MAC family or within the local-MAC family. It > > > would sbe very > > > >>>>hard to achieve that between local and split MAC families. > > > >>>> > > > >>>>For example, if vendor X's WTP terminates 802.11 ctrl/mgmt > > > >>> > > > >>packets and > > > >> > > > >>> > > > >>>>vendor Y's AC expects the 802.11 mgmt packets to come to > > > >>> > > > >>it, there's > > > >> > > > >>>>no way you can be interoperable. > > > >>>> > > > >>>>Or are we planning to specify ONE architecture ? > > > >>>>The last thing IETF should do is mandate an implementation. > > > >>>> > > > >>>>I think a modest and reasonable goal is to come up with a > > > protocol > > > >>>>that allows sufficient flexbility so that vendors with splitMAC=20 > > > >>>>architectures can transfer most of the information they > > > care about > > > >>>>between the WTP and AC. > > > >>>> > > > >>>>Just my $0.02 ... > > > >>>> > > > >>>> > > > >>>>Abhijit Choudhury > > > >>>> > > > >>>> > > > >>>>-----Original Message----- > > > >>>>From: capwap-admin@frascone.com > > > >>> > > > >>[mailto:capwap-admin@frascone.com] On > > > >> > > > >>>>Behalf Of James Kempf > > > >>>>Sent: Wednesday, August 04, 2004 3:29 PM > > > >>>>To: Shehzad Merchant; capwap@frascone.com > > > >>>>Cc: bwijnen@lucent.com; mmani@avaya.com;=20 > > david.kessens@nokia.com;=20 > > > >>>>Dorothy.Gellert@nokia.com; Inderpreet Singh > > > >>>>Subject: Re: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>> > > > >>>>As a potential customer, let me put it concretely. I want > > > >>> > > > >>to be able > > > >> > > > >>>>to buy my access points from Vendor X and my switch from > > > >>> > > > >>Vendor Y and > > > >> > > > >>>>plug the two together and have them work without any > > > configuration.=20 > > > >>>>Also, I'd like to be able to buy switches from Vendor Y and > > > >>> > > > >>Vendor Z > > > >> > > > >>>>and be able to plug them into my network at various > > > places and have > > > >>>>them interoperate. > > > >>>> > > > >>>> jak > > > >>>> > > > >>>> > > > >>>>----- Original Message ----- > > > >>>>From: "Shehzad Merchant" > > > >>>>To: > > > >>>>Cc: ; ;=20 > > > >>>>; ; > > > "Inderpreet > > > >>>>Singh" > > > >>>> > > > >>>>Sent: Wednesday, August 04, 2004 3:19 PM > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>>>I think the implementation variations even with the > > > split MAC may > > > >>>>>cover a broad spectrum. As such its important to clearly > > > >>>> > > > >>articulate > > > >> > > > >>>>>what aspects > > > >>>> > > > >>>>of > > > >>>> > > > >>>> > > > >>>>>interoperability we are targetting. Is it truly just=20 > > > >>>>>control/management or is it interoperability between disparate=20 > > > >>>>>implementations of the split MAC, i.e. mix and match > > > >>>> > > > >>>>operation of WTP > > > >>>> > > > >>>> > > > >>>>>and ACs of all variants within this category. > > > >>>>> > > > >>>>>I suspect for the latter we may have to arrive at some > > > >>>> > > > >>consensus on > > > >> > > > >>>>>what particular implementations we are targeting > > > >>>> > > > >>>>interoperability for. > > > >>>> > > > >>>> > > > >>>> > > > >>>>>If so, ultimately this problem statement could become > > > part of the > > > >>>>>charter. > > > >>>>> > > > >>>>>-Shehzad > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>>-----Original Message----- > > > >>>>>From: capwap-admin@frascone.com > > > >>>> > > > >>>>[mailto:capwap-admin@frascone.com] On Behalf > > > >>>> > > > >>>> > > > >>>>>Of Dorothy.Gellert@nokia.com > > > >>>>>Sent: Wednesday, August 04, 2004 11:53 AM > > > >>>>>To: isingh@chantrynetworks.com; capwap@frascone.com > > > >>>>>Cc: bwijnen@lucent.com; mmani@avaya.com;=20 > > david.kessens@nokia.com > > > >>>>>Subject: RE: [Capwap] So many architectures, so little > > > >>>> > > > >>>>time... - take > > > >>>> > > > >>>> > > > >>>>>2 > > > >>>>> > > > >>>>>I believe this is the consensus, to scope the charter to > > > >>>> > > > >>>>Centralized > > > >>>> > > > >>>> > > > >>>>>Architecture and LocalMAC and Split MAC. > > > >>>>> > > > >>>>>I'll update the charter with this change after the CAPWAP > > > >>>> > > > >>>>WG Mtg. If > > > >>>> > > > >>>> > > > >>>>>there is resistance to this idea, please post to the list. > > > >>>>> > > > >>>>>Regards > > > >>>>>Dorothy > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>>>-----Original Message----- > > > >>>>>>From: capwap-admin@frascone.com > > > >>>>> > > > >>>>[mailto:capwap-admin@frascone.com]On > > > >>>> > > > >>>> > > > >>>>>>Behalf Of ext Inderpreet Singh > > > >>>>>>Sent: Tuesday, August 03, 2004 9:40 PM > > > >>>>>>To: capwap@frascone.com > > > >>>>>>Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David=20 > > > >>>>>>(Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > > > >>>>>>Subject: RE: [Capwap] So many architectures, so little > > > time... - > > > >>>>>>take 2 > > > >>>>>> > > > >>>>>> > > > >>>>>>The issue(s) at hand and my opinions are: > > > >>>>>> > > > >>>>>>1. Do we explicitly state in the re-charter which > > > >>>>> > > > >>>>architecture the > > > >>>> > > > >>>> > > > >>>>>>WG should consider? I think yes. I propose Centralized > > > >>>>> > > > >>>>architecture > > > >>>> > > > >>>> > > > >>>> > > > >>>>>>only. Autonomous and Distributed should be out of scope > > > >>>>> > > > >>>>based on the > > > >>>> > > > >>>> > > > >>>> > > > >>>>>>same reasons as per prior postings. > > > >>>>>> > > > >>>>>>2. Within Centralized do we focus on all three sub > > > >>>>> > > > >>>>architectures or > > > >>>> > > > >>>> > > > >>>>>>a subset? Remote MAC should be excluded because if I am not=20 > > > >>>>>>mistaken, the connectivity constraint between the WTP and > > > >>>>> > > > >>>>the AC is > > > >>>> > > > >>>> > > > >>>>>>"direct connect". > > > >>>>>>That being the case and that no IP layer is involved,=20 > > it doesn't > > > >>>>> > > > >>>>seem > > > >>>> > > > >>>> > > > >>>>>>clear what kind of protocol would help with > > > interoperability. I am > > > >>>>> > > > >>>>>>concerned about the impact, dependencies and > > > interaction with the > > > >>>>>>recently constituted IEEE Study group on AP > > > >>>>> > > > >>>>functionality on the > > > >>>> > > > >>>> > > > >>>>>>Split MAC architectures. Furthermore, there are some > > > >>>>> > > > >>>>pretty drastic > > > >>>> > > > >>>> > > > >>>>>>differences on how the vendors have chosen to split the > > > >>>>> > > > >>>>mac. Those > > > >>>> > > > >>>> > > > >>>>>>differences will need to be worked out before designing a > > > >>>>> > > > >>>>protocol. > > > >>>> > > > >>>> > > > >>>>>>So, if the low hanging fruit strategy (as James=20 > > suggested) for=20 > > > >>>>>>protocol development and progress is the way to go, > > > then I think > > > >>>>>>prioritizing on a protocol for Local MAC is a no brainer. > > > >>>>> > > > >>>>So as far > > > >>>> > > > >>>> > > > >>>>>>as focus, I feel we should do Local and Split and in=20 > > that order. > > > >>>>>> > > > >>>>>>3. This is not a re-chartering issue but is a=20 > > response to Pat's=20 > > > >>>>>>suggestion that a protocol that just sends the 802.11 > > > MAC frames > > > >>>>> > > > >>>>>>from the AP to the AC would work. I think possibly, yes. > > > >>>>> > > > >>>> > > > >>>>But again > > > >>>> > > > >>>> > > > >>>> > > > >>>>>>the complications of splitting the MAC in an > > > >>>>> > > > >>>>interoperable way will > > > >>>> > > > >>>> > > > >>>>>>be an issue. Also, you may note in the draft to which > > > >>>>> > > > >>>>you refer, we > > > >>>> > > > >>>> > > > >>>> > > > >>>>>>included a capabilities exchange phase. I had thought of > > > >>>>> > > > >>>>including > > > >>>> > > > >>>> > > > >>>>>>in the capability exchange such things as "AP supports > > > Local MAC" > > > >>>>>>and "AP supports Split MAC", but didn't put it in because the=20 > > > >>>>>>Taxonomy work was still in progress. Now that it is > > > pretty much > > > >>>>>>done we could surely include that. But again...let's=20 > > recharter=20 > > > >>>>>>first. > > > >>>>>> > > > >>>>>>Thanks. Do people agree with 1 & 2? > > > >>>>>> > > > >>>>>>--- > > > >>>>>>Inderpreet Singh > > > >>>>>>Chantry Networks > > > >>>>>>isingh@chantrynetworks.com > > > >>>>>>Cell: 416-831-3705 > > > >>>>>> > > > >>>>>>-----Original Message----- > > > >>>>>>From: capwap-admin@frascone.com > > > >>>>> > > > >>>>[mailto:capwap-admin@frascone.com] > > > >>>> > > > >>>> > > > >>>>>>On Behalf Of Pat R. Calhoun > > > >>>>>>Sent: Tuesday, August 03, 2004 6:04 PM > > > >>>>>>To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com;=20 > > > >>>>>>capwap@frascone.com > > > >>>>>>Cc: bwijnen@lucent.com; mmani@avaya.com;=20 > > david.kessens@nokia.com > > > >>>>>>Subject: [Capwap] So many architectures, so little > > > >>>>> > > > >>>>time... - take 2 > > > >>>> > > > >>>> > > > >>>>>>After reading Lily's response to Jim, I realize that I > > > >>>>> > > > >>>>fell down the > > > >>>> > > > >>>> > > > >>>> > > > >>>>>>same trap. Local MAC is also a centralized approach,=20 > > and so my=20 > > > >>>>>>previous response was not complete. I believe the real > > > >>>>> > > > >>>>question, in > > > >>>> > > > >>>> > > > >>>>>>my mind, is whether we need to address either the Local > > > >>>>> > > > >>>>or the Split > > > >>>> > > > >>>> > > > >>>> > > > >>>>>>MAC architecture. > > > >>>>>> > > > >>>>>>Just looking at the Architecture Consideration tables (7 and > > > >>>>>>10) in the > > > >>>>>>specification, the > > > >>>>>>main difference (at a high level) between both approaches > > > >>>>> > > > >>>>is where > > > >>>> > > > >>>> > > > >>>>>>the 802.11 management terminates. For Local MAC, it's > > > in the WTP, > > > >>>>>>while for SPlit MAC, it's in the AC. > > > >>>>>> > > > >>>>>>However, looking at table 8, most Local MAC approaches > > > share STA > > > >>>>>>state between both the WTP and the AC. So clearly=20 > > there is some=20 > > > >>>>>>signalling protocol between both the WTP and the AC. > > > >>>>>> > > > >>>>>>Looking at one example of a Local MAC protocol (see > > > >>>>>> > > > >>>>> > > >=20 > > >>>http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > > > >>> > > > >>> > > > >>>>>there is a protocol message > > > >>>>>that corresponds for every 802.11 MAC management event. So > > > >>>> > > > >>when a STA > > > >> > > > >> > > > >>>>>associates, the AP breaks the message apart and creates an new=20 > > > >>>>>protocol PDU, which contains components found in the=20 > > association=20 > > > >>>>>request. I suspect that most Local MAC approaches do > > > >>>> > > > >>something very > > > >> > > > >>>>>similar. > > > >>>>> > > > >>>>>So if a protocol simply tunnels the 802.11 MAC management > > > >>>> > > > >>frames from > > > >> > > > >> > > > >>>>>the WTP to the AC, it allows supports both approaches. For > > > >>>> > > > >>Local MAC, > > > >> > > > >> > > > >>>>>they get what they want via the 802.11 frame, and this > > > also works > > > >>>>>fine for Split MAC, which needs access to the MAC > > > >>>> > > > >>management frame.=20 > > > >> > > > >>>>>What would be required in such a protocol is a way for=20 > > the AP to=20 > > > >>>>>communicate whether it will be providing very specific > > > functions - > > > >>>>>basically a capabilities negotiation approach. > > > >>>>> > > > >>>>>So I do believe that there is a way to address both > > > architectures > > > >>>>>using a single protocol. > > > >>>>> > > > >>>>>Thoughts? > > > >>>>> > > > >>>>>PatC > > > >>>>> > > > >>>>>_______________________________________________ > > > >>>>>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=20 > > http://mail.frascone.com/mailman/listinfo/capwap > > >>>_______________________________________________ > > >>>Capwap mailing list > > >>>Capwap@frascone.com=20 > > http://mail.frascone.com/mailman/listinfo/capwap > > >>>_______________________________________________ > > >>>Capwap mailing list > > >>>Capwap@frascone.com=20 > > http://mail.frascone.com/mailman/listinfo/capwap > > >>>_______________________________________________ > > >>>Capwap mailing list > > >>>Capwap@frascone.com=20 > > http://mail.frascone.com/mailman/listinfo/capwap > > >>>_______________________________________________ > > >>>Capwap mailing list > > >>>Capwap@frascone.com=20 > > http://mail.frascone.com/mailman/listinfo/capwap > > >>>_______________________________________________ > > >>>Capwap mailing list > > >>>Capwap@frascone.com=20 > > http://mail.frascone.com/mailman/listinfo/capwap > > >>>_______________________________________________ > > >>>Capwap mailing list > > >>>Capwap@frascone.com > > >>>http://mail.frascone.com/mailman/listinfo/capwap > > >> > > >> > > >>-- > > >>Shankar Narayanaswamy, Ph.D. > > >>wireless@shankar.org Mobile: +1 650-387-4593 > > >>http://www.shankar.org E-Fax: +1 253-498-8372 > > >> > > >>_______________________________________________ > > >>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 > > >=20 > > >=20 > >=20 > >=20 > > -- > > Shankar Narayanaswamy, Ph.D. > > wireless@shankar.org Mobile: +1 650-387-4593 > > http://www.shankar.org E-Fax: +1 253-498-8372 > >=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 > >=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 Fri Aug 13 16:14:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15029 for ; Fri, 13 Aug 2004 16:14:03 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CFB1B2114B; Fri, 13 Aug 2004 15:59:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2DD2420575; Fri, 13 Aug 2004 15:59:09 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8B9F820541 for ; Fri, 13 Aug 2004 15:58:26 -0400 (EDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by mail.frascone.com (Postfix) with ESMTP id 28FDD2046F for ; Fri, 13 Aug 2004 15:58:24 -0400 (EDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i7DKCLRM012253; Fri, 13 Aug 2004 20:12:22 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i7DKFAtx002579; Fri, 13 Aug 2004 20:15:32 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004081313131008462 ; Fri, 13 Aug 2004 13:13:10 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 13:13:10 -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] Re: Data plane and control plane separation in SplitMAC Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE01D05B92@orsmsx408> Thread-Topic: [Capwap] Re: Data plane and control plane separation in SplitMAC Thread-Index: AcSAqjckPya/4OnTQrCIYdiZXlf3XQAxT/LgAACBlkA= From: "Yang, Lily L" To: "Bob O'Hara" , X-OriginalArrivalTime: 13 Aug 2004 20:13:10.0300 (UTC) FILETIME=[F44A15C0:01C48171] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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, 13 Aug 2004 13:13:08 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I also think it makes more sense to arrive at a single protocol for data forwarding. It doesn't mean CAPWAP has to reinvent the wheel to come up with yet another tunneling protocol -- existing protocol can be reused for that purpose. But for interoperability, we need to agree on one eventually. So the relevant discussion is to understand the requirements for data forwarding. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Bob O'Hara Sent: Friday, August 13, 2004 12:59 PM To: capwap@frascone.com Subject: RE: [Capwap] Re: Data plane and control plane separation in SplitMAC I agree that for a complete solution, we cannot ignore the need for a data forwarding protocol. But for control and provisioning, not for operation, that problem can be separated from the initial protocol design. =20 What we might consider in the protocol design is negotiating the data forwarding protocol. I do not favor negotiation of that protocol as the final solution. It leads to too many options in a multivendor situation and will likely provide less interoperability rather than more. When the question arises, I would prefer we had the hard discussions to arrive at a single protocol to be used for data forwarding. -Bob =20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Partha Narasimhan Sent: Thursday, August 12, 2004 1:19 PM To: Lily L Yang Cc: Wijnen, Bert (Bert); Shankar Narayanaswamy; Dorothy.Gellert@nokia.com; capwap@frascone.com Subject: RE: [Capwap] Re: Data plane and control plane separation in SplitMAC The set of AP functions is split across the WTP and the AC in the split-MAC and, arguably to a lesser extent, in the local MAC architectures. As a result, the AP, in these architectures, is no longer a physical entity, but one that potentially spans a L3 boundary. The handling of data frames (and some mgmt frames in the split-MAC arch) within an AP could involve transferring it over a L3 network from the WTP to the AC or vice-versa. If these two end-points are from multiple different vendors, then there needs to be an agreement on the mode of this transfer. Hence, we cannot ignore this problem in defining a CAPWAP protocol. Thanks partha On Thu, 2004-08-12 at 10:42, Yang, Lily L wrote: > To examine our options of architecture assumptions, let me first put our > my definition of data plane and control plane just to make sure we start > from the same page: >=20 > To me, 802.11 data plane means the dath path travelled by the native > 802.11 data frames while 802.11 control plane means the data path > between 802.11 STA and the 802.11-awared control end point. =20 >=20 > For both Local and Split MAC, that 802.11-awared control point is AC. So > both architecture has the same control path: STA->WTP->AC. The > difference is how that control messages are implemented between WTP and > AC: Split MAC simply tunneled the 802.11 management frames, while Local > MAC translated them into some other non-802.11 forms. Another (implied) > difference is that Split MAC largely relies on the AC to respond to > those management frames from STA, while Local MAC relies on WTP to > respond, but allow AC to be informed of such events as well. So the > timing constraint may be more relaxed for local MAC. >=20 > The question is on the data path. Here is my understanding so far: > In Local MAC, the data path is between STA and WTP. From WTP, it can be > switched or routed locally, entirely bypassing AC. For Split MAC, My > impression has been that the data path is between STA and WTP and AC, > because it seems that Split MAC vendors tunnel ALL 802.11 data back to > AC, even though I don't see why it has to be that way. Just from the > recent discussion, some have hinted that even Split MAC can allow data > path terminate at WTP and be "locally" switched without involving AC. Is > this true? Can anyone confirm more explicitly and elaborate this for me? >=20 >=20 > To summarize: > Common control path: STA->WTP->AC. (but control messages between > WTP<->AC are done diffrently) > Local MAC data path: STA->WTP. > Split MAC data path: STA->WTP->AC or STA->WTP (This needs to be > clarified). >=20 > My hunch is that CAPWAP protocol would have to allow the flexibility in > datapath, for either architecture (Split or Local). So in that case, it > doesn't really matter if it is Split or Local, it should allow datapath > to be configurable any way. In that sense, I agree with what Shankar was > saying here. This seems also suggest that YES, we can cleanly separate > data plane and control plane here. But that doesn't mean any discussion > around data plane is out of scope -- because guess what? Why do we need > the control plane at the first place? To control and configure the data > plane! >=20 > So understanding what data plane needs would drive our discussion for > the control plane and CAPWAP. >=20 > > -----Original Message----- > > From: capwap-admin@frascone.com=20 > > [mailto:capwap-admin@frascone.com] On Behalf Of Wijnen, Bert (Bert) > > Sent: Thursday, August 12, 2004 2:30 AM > > To: Shankar Narayanaswamy; Dorothy.Gellert@nokia.com > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] Re: Data plane and control plane=20 > > separation in Split MAC > >=20 > > > -----Original Message----- > > > From: Shankar Narayanaswamy [mailto:wireless@shankar.org] > > > Sent: donderdag 12 augustus 2004 05:13 > > > To: Dorothy.Gellert@nokia.com > > > Cc: capwap@frascone.com > > > Subject: [Capwap] Re: Data plane and control plane=20 > > separation in Split=20 > > > MAC > > >=20 > > >=20 > > > The parameters by which the data plane communicates such as=20 > > > authentication/security info, destination switch (if any) for data > > > frames, etc, are communicated by the control plane. Hence=20 > > the need for=20 > > > some architectural assumptions regarding the data plane even if the=20 > > > focus is on the control plane. > > >=20 > > > Or at least a decision on the data plane architectures to be=20 > > > supported. > > >=20 > > So... to me that sounds that we may potentially do an IMPLIED=20 > > agreement on the architecture for data plane, based on the=20 > > capabilities we define in the standards track control and=20 > > provisioning protocol. > >=20 > > That would be fine with me. But we should NOT get bogged down=20 > > in that data plane stuff, or at least that to me seems to be=20 > > the wrong focus. > >=20 > > Bert > > > -s > > >=20 > > > Dorothy.Gellert@nokia.com wrote: > > > > Good point. Can we have the volunteers that submitted > > > architectures for the taxonomy draft weigh in on this issue? =20 > > > >=20 > > > > Also another point to consider is that we don't have to > > > implement *every* AP function in the first release of the CAPWAP=20 > > > protocol. One of our charter goals is to start with > > > the minimal set of functionality needed to provide control. =20 > > > We have a "desirable" category where we can put objectives=20 > > that can be=20 > > > met with a later release or extension. > > > >=20 > > > > Dorothy > > > >=20 > > > >>-----Original Message----- > > > >>From: capwap-admin@frascone.com=20 > > [mailto:capwap-admin@frascone.com]On > > > >>Behalf Of ext Yang, Lily L > > > >>Sent: Tuesday, August 10, 2004 6:13 PM > > > >>To: Sudhanshu Jain; Shehzad Merchant; Shankar=20 > > Narayanaswamy; Abhijit=20 > > > >>Choudhury > > > >>Cc: capwap@frascone.com > > > >>Subject: RE: [Capwap] So many architectures, so little time... - > > > >>take 2 > > > >> > > > >> > > > >>The question in my mind is: Can data plane and control plane be=20 > > > >>cleanly separated for Split MAC? I know it is feasible for Local > > > MAC, but not > > > >>sure about Split MAC.=20 > > > >>Any insight? > > > >> > > > >>-----Original Message----- > > > >>From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On > > > >>Behalf Of Sudhanshu Jain > > > >>Sent: Tuesday, August 10, 2004 11:55 AM > > > >>To: Shehzad Merchant; Shankar Narayanaswamy; Abhijit Choudhury > > > >>Cc: capwap@frascone.com > > > >>Subject: RE: [Capwap] So many architectures, so little time... - > > > >>take 2 > > > >> > > > >>I fully agree with Shehzad. We need to separate the=20 > > control and data=20 > > > >>plane. Control plane should provide the framework to use one of=20 > > > >>several tunneling protocol. > > > >> > > > >>On data plane, if we need to define a new layer2/layer3 level=20 > > > >>tunneling protocol, it should be separate work from=20 > > control protocol=20 > > > >>work. > > > >> > > > >>-Suds > > > >> > > > >> > > > >>-----Original Message----- > > > >>From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On > > > >>Behalf Of Shehzad Merchant > > > >>Sent: Tuesday, August 10, 2004 11:13 AM > > > >>To: Shankar Narayanaswamy; Abhijit Choudhury > > > >>Cc: capwap@frascone.com > > > >>Subject: RE: [Capwap] So many architectures, so little time... - > > > >>take 2 > > > >> > > > >>Additionally, for data tunneling one needs a lightweight=20 > > mechanism=20 > > > >>that may not necessarily have the same requirements as that for=20 > > > >>control and management. For example, one would want to limit the > > > >>tunneling and processing overhead on data packets to a minimum.=20 > > > >>Control and management may be more tolerant of=20 > > > >>tunneling/security/etc. overhead. > > > >>Besides, there are > > > >>plenty of standards in place for data tunneling. We may > > > potentially be > > > >>able > > > >>to leverage off that work itself without having to invent > > > yet another > > > >>tunneling mechanism for data.=20 > > > >> > > > >>-S > > > >> > > > >> > > > >>-----Original Message----- > > > >>From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On > > > >>Behalf > > > >>Of Shankar Narayanaswamy > > > >>Sent: Tuesday, August 10, 2004 10:30 AM > > > >>To: Abhijit Choudhury > > > >>Cc: capwap@frascone.com > > > >>Subject: Re: [Capwap] So many architectures, so little time... - > > > >>take 2 > > > >> > > > >>On the first point: not necessarily. If data packets are > > > encapsulated > > > >>802.11 data frames, then there is no need to protect them > > > on the wire > > > >>any > > > >>more than they were encrypted over the air. > > > >> > > > >>But control and management packets will need protection > > > over the wired > > > >>network and therefore possibly a different tunneling protocol. > > > >> > > > >>On the second point (standard way of packet exchange): yes! > > > >> > > > >>-s > > > >> > > > >>Abhijit Choudhury wrote: > > > >> > > > >>>The same tunneling protocol that moves control and > > > >> > > > >>management packets > > > >> > > > >>>from the WTP to the AC should be used to tunnel data > > > >> > > > >>packets as well. > > > >> > > > >> > > > >>>We would specify message exchanges to do control,=20 > > provisioning and=20 > > > >>>capability advertisement between WTPs and the AC. But=20 > > all of this=20 > > > >>>would be within the unified CAPWAP protocol that moves=20 > > all packets=20 > > > >>>including data between the WTP and AC. Vendors currently > > > >> > > > >>use LWAPP, > > > >> > > > >>>GRE, IP and some proprietary encapsulations to achieve=20 > > this. This=20 > > > >>>group would come up with a "standard" way of doing this exchange. > > > >>> > > > >>>At least that was my understanding.... > > > >>> > > > >>>Regards, > > > >>>Abhijit > > > >>> > > > >>>-----Original Mssage----- > > > >>>From: capwap-admin@frascone.com > > > >> > > > >>[mailto:capwap-admin@frascone.com] On > > > >> > > > >>>Behalf Of Wijnen, Bert (Bert) > > > >>>Sent: Monday, August 09, 2004 6:14 AM > > > >>>To: 'Yang, Lily L'; Burbank, Jack L.; Victor Lin; Bob O'Hara;=20 > > > >>>capwap@frascone.com > > > >>>Subject: RE: [Capwap] So many architectures, so little > > > >> > > > >>time... - take > > > >> > > > >>>2 > > > >>> > > > >>> > > > >>>Not sure who is confused... probably me... > > > >>> > > > >>>My understanding was/is that IF we do re-charter for CAPWAP > > > >> > > > >>protocol > > > >> > > > >>>work, that it is then a NM protocol for "Control and > > > >> > > > >>Provisioning" and > > > >> > > > >> > > > >>>not any of the related stuff that moves the data from WTP to AC. > > > >>> > > > >>>Is everybody in agreement with that understanding. > > > >>> > > > >>>Thanks, > > > >>>Bert > > > >>> > > > >>> > > > >>> > > > >>>>-----Original Message----- > > > >>>>From: Yang, Lily L [mailto:lily.l.yang@intel.com] > > > >>>>Sent: maandag 9 augustus 2004 08:14 > > > >>>>To: Burbank, Jack L.; Victor Lin ; Bob O'Hara ; > > > capwap@frascone.com > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>> > > > >>>>I think setting the re-charter scope to develop a single > > > >>> > > > >>protocol that > > > >> > > > >>> > > > >>>>allows interoperability between Local and Split MAC is a > > > reasonable > > > >>>>tradeoff: > > > >>>>We exclude remote MAC because the constraint it imposes is very=20 > > > >>>>different from the rest and the benefit of including it is very=20 > > > >>>>little. But Local and Split MAC are reasonably close and > > > hence the > > > >>>>effort may be incremental only. > > > >>>>As many people noted, as of today, there is no single clear > > > >>> > > > >>definition > > > >> > > > >> > > > >>>>of what "Local MAC" and "Split MAC" really means yet. Each > > > >>> > > > >>vendor has > > > >> > > > >>>>different definitions and some debate needs to happen so > > > >>> > > > >>that the WG > > > >> > > > >>>>can reach consensus on what exactly that means, and=20 > > what kinds of=20 > > > >>>>flexibility we want to retain within each class of > > > >>> > > > >>architecture, and > > > >> > > > >>>>what kind of differences we can to resolve and agree up > > > front. That > > > >>>>should also be part of the work items for the new WG -- > > > >>> > > > >>such agreement > > > >> > > > >> > > > >>>>on the details for each architecture must be documented > > > >>> > > > >>somewhere, if > > > >> > > > >>>>not separately, then as part of the Protocol document. > > > >>>> > > > >>>>-----Original Message----- > > > >>>>From: capwap-admin@frascone.com > > > >>> > > > >>[mailto:capwap-admin@frascone.com] On > > > >> > > > >>>>Behalf Of Burbank, Jack L. > > > >>>>Sent: Thursday, August 05, 2004 12:14 PM > > > >>>>To: 'Victor Lin '; 'Bob O'Hara '; 'capwap@frascone.com ' > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>>I think that interoperability between different > > > >>> > > > >>architectures should > > > >> > > > >>>>be a requirement, if not the key requirement. As was mentioned=20 > > > >>>>yesterday, a goal of the IEEE is that they maintain > > > flexibility in > > > >>>>terms of how products and architectures are implemented. I > > > >>> > > > >>think we > > > >> > > > >>>>shouldn't do anything that is contrary to that goal (or > > > at least we > > > >>>>should minimize the impact). I think that the goal of > > > >>> > > > >>CAPWAP should > > > >> > > > >>>>be to retain this type of flexibility by designing a > > > >>> > > > >>protocol that can > > > >> > > > >> > > > >>>>maintain this implementation flexibility but enable > > > >>> > > > >>interoperability > > > >> > > > >>>>between the various architecture implementations (that > > > after all is > > > >>>>the key problem with the deployment of these various > > > >>> > > > >>architectures - > > > >> > > > >>>>lack of interoperability). IMO, if we don't design for=20 > > > >>>>interoperability between the basic architecture types, it > > > >>> > > > >>is debatable > > > >> > > > >> > > > >>>>if something useful would have been accomplished. > > > >>>> > > > >>>>Jack Burbank > > > >>>> > > > >>>>-----Original Message----- > > > >>>>From: capwap-admin@frascone.com > > > >>>>To: Bob O'Hara; capwap@frascone.com > > > >>>>Sent: 8/5/2004 2:46 PM > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>>I agree that we can design a protocol and implement the > > > >>> > > > >>product that > > > >> > > > >>>>works all architectures. I think the question to CAPWAP is: > > > >>>> > > > >>>>Should we make it a requirement in CAPWAP protocol to achieve=20 > > > >>>>interoperability between different architectures? > > > >>>> > > > >>>>It is definitely doable, but I'm not sure if that is the > > > >>> > > > >>right thing > > > >> > > > >>>>to do.. > > > >>>> > > > >>>>Victor > > > >>>> > > > >>>>-----Original Message----- > > > >>>>From: capwap-admin@frascone.com > > > >>> > > > >>[mailto:capwap-admin@frascone.com] On > > > >> > > > >>>>Behalf Of Bob O'Hara > > > >>>>Sent: Thursday, August 05, 2004 11:43 AM > > > >>>>To: capwap@frascone.com > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>>I think that interoperability will depend on two things. > > > >>>>First, it will > > > >>>>depend on how we define the protocol and the flexibility > > > >>> > > > >>for supported > > > >> > > > >> > > > >>>>architectures it incorporates. Second, it will depend on what > > > >>>>manufacturers implement, i.e., the flexibility they build > > > >>> > > > >>into their > > > >> > > > >>>>products. > > > >>>> > > > >>>>I believe that it is possible to design the protocol for > > > >>> > > > >>the required > > > >> > > > >>>>flexibility. I know it is possible to implement a > > > product with the > > > >>>>required flexibility. > > > >>>> > > > >>>>-Bob O'Hara > > > >>>> > > > >>>> > > > >>>>-----Original Message----- > > > >>>>From: capwap-admin@frascone.com > > > >>> > > > >>[mailto:capwap-admin@frascone.com] On > > > >> > > > >>>>Behalf Of Abhijit Choudhury > > > >>>>Sent: Thursday, August 05, 2004 11:32 AM > > > >>>>To: James Kempf; Shehzad Merchant; capwap@frascone.com > > > >>>>Cc: bwijnen@lucent.com; mmani@avaya.com;=20 > > david.kessens@nokia.com;=20 > > > >>>>Dorothy.Gellert@nokia.com; Inderpreet Singh > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>> > > > >>>>It may be possible to achieve such interoperability within the > > > >>>>split-MAC family or within the local-MAC family. It > > > would sbe very > > > >>>>hard to achieve that between local and split MAC families. > > > >>>> > > > >>>>For example, if vendor X's WTP terminates 802.11 ctrl/mgmt > > > >>> > > > >>packets and > > > >> > > > >>> > > > >>>>vendor Y's AC expects the 802.11 mgmt packets to come to > > > >>> > > > >>it, there's > > > >> > > > >>>>no way you can be interoperable. > > > >>>> > > > >>>>Or are we planning to specify ONE architecture ? > > > >>>>The last thing IETF should do is mandate an implementation. > > > >>>> > > > >>>>I think a modest and reasonable goal is to come up with a > > > protocol > > > >>>>that allows sufficient flexbility so that vendors with splitMAC=20 > > > >>>>architectures can transfer most of the information they > > > care about > > > >>>>between the WTP and AC. > > > >>>> > > > >>>>Just my $0.02 ... > > > >>>> > > > >>>> > > > >>>>Abhijit Choudhury > > > >>>> > > > >>>> > > > >>>>-----Original Message----- > > > >>>>From: capwap-admin@frascone.com > > > >>> > > > >>[mailto:capwap-admin@frascone.com] On > > > >> > > > >>>>Behalf Of James Kempf > > > >>>>Sent: Wednesday, August 04, 2004 3:29 PM > > > >>>>To: Shehzad Merchant; capwap@frascone.com > > > >>>>Cc: bwijnen@lucent.com; mmani@avaya.com;=20 > > david.kessens@nokia.com;=20 > > > >>>>Dorothy.Gellert@nokia.com; Inderpreet Singh > > > >>>>Subject: Re: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>> > > > >>>>As a potential customer, let me put it concretely. I want > > > >>> > > > >>to be able > > > >> > > > >>>>to buy my access points from Vendor X and my switch from > > > >>> > > > >>Vendor Y and > > > >> > > > >>>>plug the two together and have them work without any > > > configuration.=20 > > > >>>>Also, I'd like to be able to buy switches from Vendor Y and > > > >>> > > > >>Vendor Z > > > >> > > > >>>>and be able to plug them into my network at various > > > places and have > > > >>>>them interoperate. > > > >>>> > > > >>>> jak > > > >>>> > > > >>>> > > > >>>>----- Original Message ----- > > > >>>>From: "Shehzad Merchant" > > > >>>>To: > > > >>>>Cc: ; ;=20 > > > >>>>; ; > > > "Inderpreet > > > >>>>Singh" > > > >>>> > > > >>>>Sent: Wednesday, August 04, 2004 3:19 PM > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>>>I think the implementation variations even with the > > > split MAC may > > > >>>>>cover a broad spectrum. As such its important to clearly > > > >>>> > > > >>articulate > > > >> > > > >>>>>what aspects > > > >>>> > > > >>>>of > > > >>>> > > > >>>> > > > >>>>>interoperability we are targetting. Is it truly just=20 > > > >>>>>control/management or is it interoperability between disparate=20 > > > >>>>>implementations of the split MAC, i.e. mix and match > > > >>>> > > > >>>>operation of WTP > > > >>>> > > > >>>> > > > >>>>>and ACs of all variants within this category. > > > >>>>> > > > >>>>>I suspect for the latter we may have to arrive at some > > > >>>> > > > >>consensus on > > > >> > > > >>>>>what particular implementations we are targeting > > > >>>> > > > >>>>interoperability for. > > > >>>> > > > >>>> > > > >>>> > > > >>>>>If so, ultimately this problem statement could become > > > part of the > > > >>>>>charter. > > > >>>>> > > > >>>>>-Shehzad > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>>-----Original Message----- > > > >>>>>From: capwap-admin@frascone.com > > > >>>> > > > >>>>[mailto:capwap-admin@frascone.com] On Behalf > > > >>>> > > > >>>> > > > >>>>>Of Dorothy.Gellert@nokia.com > > > >>>>>Sent: Wednesday, August 04, 2004 11:53 AM > > > >>>>>To: isingh@chantrynetworks.com; capwap@frascone.com > > > >>>>>Cc: bwijnen@lucent.com; mmani@avaya.com;=20 > > david.kessens@nokia.com > > > >>>>>Subject: RE: [Capwap] So many architectures, so little > > > >>>> > > > >>>>time... - take > > > >>>> > > > >>>> > > > >>>>>2 > > > >>>>> > > > >>>>>I believe this is the consensus, to scope the charter to > > > >>>> > > > >>>>Centralized > > > >>>> > > > >>>> > > > >>>>>Architecture and LocalMAC and Split MAC. > > > >>>>> > > > >>>>>I'll update the charter with this change after the CAPWAP > > > >>>> > > > >>>>WG Mtg. If > > > >>>> > > > >>>> > > > >>>>>there is resistance to this idea, please post to the list. > > > >>>>> > > > >>>>>Regards > > > >>>>>Dorothy > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>>>-----Original Message----- > > > >>>>>>From: capwap-admin@frascone.com > > > >>>>> > > > >>>>[mailto:capwap-admin@frascone.com]On > > > >>>> > > > >>>> > > > >>>>>>Behalf Of ext Inderpreet Singh > > > >>>>>>Sent: Tuesday, August 03, 2004 9:40 PM > > > >>>>>>To: capwap@frascone.com > > > >>>>>>Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David=20 > > > >>>>>>(Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > > > >>>>>>Subject: RE: [Capwap] So many architectures, so little > > > time... - > > > >>>>>>take 2 > > > >>>>>> > > > >>>>>> > > > >>>>>>The issue(s) at hand and my opinions are: > > > >>>>>> > > > >>>>>>1. Do we explicitly state in the re-charter which > > > >>>>> > > > >>>>architecture the > > > >>>> > > > >>>> > > > >>>>>>WG should consider? I think yes. I propose Centralized > > > >>>>> > > > >>>>architecture > > > >>>> > > > >>>> > > > >>>> > > > >>>>>>only. Autonomous and Distributed should be out of scope > > > >>>>> > > > >>>>based on the > > > >>>> > > > >>>> > > > >>>> > > > >>>>>>same reasons as per prior postings. > > > >>>>>> > > > >>>>>>2. Within Centralized do we focus on all three sub > > > >>>>> > > > >>>>architectures or > > > >>>> > > > >>>> > > > >>>>>>a subset? Remote MAC should be excluded because if I am not=20 > > > >>>>>>mistaken, the connectivity constraint between the WTP and > > > >>>>> > > > >>>>the AC is > > > >>>> > > > >>>> > > > >>>>>>"direct connect". > > > >>>>>>That being the case and that no IP layer is involved,=20 > > it doesn't > > > >>>>> > > > >>>>seem > > > >>>> > > > >>>> > > > >>>>>>clear what kind of protocol would help with > > > interoperability. I am > > > >>>>> > > > >>>>>>concerned about the impact, dependencies and > > > interaction with the > > > >>>>>>recently constituted IEEE Study group on AP > > > >>>>> > > > >>>>functionality on the > > > >>>> > > > >>>> > > > >>>>>>Split MAC architectures. Furthermore, there are some > > > >>>>> > > > >>>>pretty drastic > > > >>>> > > > >>>> > > > >>>>>>differences on how the vendors have chosen to split the > > > >>>>> > > > >>>>mac. Those > > > >>>> > > > >>>> > > > >>>>>>differences will need to be worked out before designing a > > > >>>>> > > > >>>>protocol. > > > >>>> > > > >>>> > > > >>>>>>So, if the low hanging fruit strategy (as James=20 > > suggested) for=20 > > > >>>>>>protocol development and progress is the way to go, > > > then I think > > > >>>>>>prioritizing on a protocol for Local MAC is a no brainer. > > > >>>>> > > > >>>>So as far > > > >>>> > > > >>>> > > > >>>>>>as focus, I feel we should do Local and Split and in=20 > > that order. > > > >>>>>> > > > >>>>>>3. This is not a re-chartering issue but is a=20 > > response to Pat's=20 > > > >>>>>>suggestion that a protocol that just sends the 802.11 > > > MAC frames > > > >>>>> > > > >>>>>>from the AP to the AC would work. I think possibly, yes. > > > >>>>> > > > >>>> > > > >>>>But again > > > >>>> > > > >>>> > > > >>>> > > > >>>>>>the complications of splitting the MAC in an > > > >>>>> > > > >>>>interoperable way will > > > >>>> > > > >>>> > > > >>>>>>be an issue. Also, you may note in the draft to which > > > >>>>> > > > >>>>you refer, we > > > >>>> > > > >>>> > > > >>>> > > > >>>>>>included a capabilities exchange phase. I had thought of > > > >>>>> > > > >>>>including > > > >>>> > > > >>>> > > > >>>>>>in the capability exchange such things as "AP supports > > > Local MAC" > > > >>>>>>and "AP supports Split MAC", but didn't put it in because the=20 > > > >>>>>>Taxonomy work was still in progress. Now that it is > > > pretty much > > > >>>>>>done we could surely include that. But again...let's=20 > > recharter=20 > > > >>>>>>first. > > > >>>>>> > > > >>>>>>Thanks. Do people agree with 1 & 2? > > > >>>>>> > > > >>>>>>--- > > > >>>>>>Inderpreet Singh > > > >>>>>>Chantry Networks > > > >>>>>>isingh@chantrynetworks.com > > > >>>>>>Cell: 416-831-3705 > > > >>>>>> > > > >>>>>>-----Original Message----- > > > >>>>>>From: capwap-admin@frascone.com > > > >>>>> > > > >>>>[mailto:capwap-admin@frascone.com] > > > >>>> > > > >>>> > > > >>>>>>On Behalf Of Pat R. Calhoun > > > >>>>>>Sent: Tuesday, August 03, 2004 6:04 PM > > > >>>>>>To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com;=20 > > > >>>>>>capwap@frascone.com > > > >>>>>>Cc: bwijnen@lucent.com; mmani@avaya.com;=20 > > david.kessens@nokia.com > > > >>>>>>Subject: [Capwap] So many architectures, so little > > > >>>>> > > > >>>>time... - take 2 > > > >>>> > > > >>>> > > > >>>>>>After reading Lily's response to Jim, I realize that I > > > >>>>> > > > >>>>fell down the > > > >>>> > > > >>>> > > > >>>> > > > >>>>>>same trap. Local MAC is also a centralized approach,=20 > > and so my=20 > > > >>>>>>previous response was not complete. I believe the real > > > >>>>> > > > >>>>question, in > > > >>>> > > > >>>> > > > >>>>>>my mind, is whether we need to address either the Local > > > >>>>> > > > >>>>or the Split > > > >>>> > > > >>>> > > > >>>> > > > >>>>>>MAC architecture. > > > >>>>>> > > > >>>>>>Just looking at the Architecture Consideration tables (7 and > > > >>>>>>10) in the > > > >>>>>>specification, the > > > >>>>>>main difference (at a high level) between both approaches > > > >>>>> > > > >>>>is where > > > >>>> > > > >>>> > > > >>>>>>the 802.11 management terminates. For Local MAC, it's > > > in the WTP, > > > >>>>>>while for SPlit MAC, it's in the AC. > > > >>>>>> > > > >>>>>>However, looking at table 8, most Local MAC approaches > > > share STA > > > >>>>>>state between both the WTP and the AC. So clearly=20 > > there is some=20 > > > >>>>>>signalling protocol between both the WTP and the AC. > > > >>>>>> > > > >>>>>>Looking at one example of a Local MAC protocol (see > > > >>>>>> > > > >>>>> > > >=20 > > >>>http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > > > >>> > > > >>> > > > >>>>>there is a protocol message > > > >>>>>that corresponds for every 802.11 MAC management event. So > > > >>>> > > > >>when a STA > > > >> > > > >> > > > >>>>>associates, the AP breaks the message apart and creates an new=20 > > > >>>>>protocol PDU, which contains components found in the=20 > > association=20 > > > >>>>>request. I suspect that most Local MAC approaches do > > > >>>> > > > >>something very > > > >> > > > >>>>>similar. > > > >>>>> > > > >>>>>So if a protocol simply tunnels the 802.11 MAC management > > > >>>> > > > >>frames from > > > >> > > > >> > > > >>>>>the WTP to the AC, it allows supports both approaches. For > > > >>>> > > > >>Local MAC, > > > >> > > > >> > > > >>>>>they get what they want via the 802.11 frame, and this > > > also works > > > >>>>>fine for Split MAC, which needs access to the MAC > > > >>>> > > > >>management frame.=20 > > > >> > > > >>>>>What would be required in such a protocol is a way for=20 > > the AP to=20 > > > >>>>>communicate whether it will be providing very specific > > > functions - > > > >>>>>basically a capabilities negotiation approach. > > > >>>>> > > > >>>>>So I do believe that there is a way to address both > > > architectures > > > >>>>>using a single protocol. > > > >>>>> > > > >>>>>Thoughts? > > > >>>>> > > > >>>>>PatC > > > >>>>> > > > >>>>>_______________________________________________ > > > >>>>>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=20 > > http://mail.frascone.com/mailman/listinfo/capwap > > >>>_______________________________________________ > > >>>Capwap mailing list > > >>>Capwap@frascone.com=20 > > http://mail.frascone.com/mailman/listinfo/capwap > > >>>_______________________________________________ > > >>>Capwap mailing list > > >>>Capwap@frascone.com=20 > > http://mail.frascone.com/mailman/listinfo/capwap > > >>>_______________________________________________ > > >>>Capwap mailing list > > >>>Capwap@frascone.com=20 > > http://mail.frascone.com/mailman/listinfo/capwap > > >>>_______________________________________________ > > >>>Capwap mailing list > > >>>Capwap@frascone.com=20 > > http://mail.frascone.com/mailman/listinfo/capwap > > >>>_______________________________________________ > > >>>Capwap mailing list > > >>>Capwap@frascone.com=20 > > http://mail.frascone.com/mailman/listinfo/capwap > > >>>_______________________________________________ > > >>>Capwap mailing list > > >>>Capwap@frascone.com > > >>>http://mail.frascone.com/mailman/listinfo/capwap > > >> > > >> > > >>-- > > >>Shankar Narayanaswamy, Ph.D. > > >>wireless@shankar.org Mobile: +1 650-387-4593 > > >>http://www.shankar.org E-Fax: +1 253-498-8372 > > >> > > >>_______________________________________________ > > >>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 > > >=20 > > >=20 > >=20 > >=20 > > -- > > Shankar Narayanaswamy, Ph.D. > > wireless@shankar.org Mobile: +1 650-387-4593 > > http://www.shankar.org E-Fax: +1 253-498-8372 > >=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 > >=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 Fri Aug 13 16:42:15 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17009 for ; Fri, 13 Aug 2004 16:42:12 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3564521D8A; Fri, 13 Aug 2004 16:27:19 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D870621D87; Fri, 13 Aug 2004 16:27:15 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 67BE220368 for ; Fri, 13 Aug 2004 16:26:40 -0400 (EDT) Received: from gemini.lunarpages.com (gemini.lunarpages.com [64.235.234.128]) by mail.frascone.com (Postfix) with ESMTP id 2CB3F205FC for ; Fri, 13 Aug 2004 16:26:37 -0400 (EDT) Received: from cpanel by gemini.lunarpages.com with local (Exim 4.34) id 1Bviro-0001W0-3i; Fri, 13 Aug 2004 13:41:36 -0700 Received: from 127.0.0.1 ([127.0.0.1]) by shankar.org (IMP) with HTTP for ; Fri, 13 Aug 2004 13:41:36 -0700 Message-ID: <1092429696.411d27800c3d4@shankar.org> From: Shankar Narayanaswamy To: "Yang, Lily L" Cc: "Bob O'Hara" , capwap@frascone.com Subject: RE: [Capwap] Re: Data plane and control plane separation in SplitMAC References: <2AF68A477DD44C4EBCBE338C24E7A9EE01D05B92@orsmsx408> In-Reply-To: <2AF68A477DD44C4EBCBE338C24E7A9EE01D05B92@orsmsx408> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 127.0.0.1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gemini.lunarpages.com X-AntiAbuse: Original Domain - frascone.com X-AntiAbuse: Originator/Caller UID/GID - [32001 502] / [47 12] X-AntiAbuse: Sender Address Domain - shankar.org 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, 13 Aug 2004 13:41:36 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 8bit A single protocol for data forwarding is a worthy goal. However that may be suboptimal in some cases. Consider where the entire WEP/TKIP/WPA data frame is encrypted/decrypted in the AC. It would be unnecessary and unreasonably demanding to use SSL or some other encrypted IP tunneling protocol between the WTP and the AC. Any simple IP-in-IP protocol would suffice and allow the WTP to be more lightweight than would otherwise be the case. So we should aim for allowing a (very small) set of well-known, standard data forwarding protocols to be negotiated over the control plane. The actual number of protocols (and which ones) is something that we as a group will decide. -s -- Shankar Narayanaswamy, Ph.D. Quoting "Yang, Lily L" : > I also think it makes more sense to arrive at a single protocol for data > forwarding. It doesn't mean CAPWAP has to reinvent the wheel to come up > with yet another tunneling protocol -- existing protocol can be reused > for that purpose. But for interoperability, we need to agree on one > eventually. > So the relevant discussion is to understand the requirements for data > forwarding. > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Bob O'Hara > Sent: Friday, August 13, 2004 12:59 PM > To: capwap@frascone.com > Subject: RE: [Capwap] Re: Data plane and control plane separation in > SplitMAC > > I agree that for a complete solution, we cannot ignore the need for a > data forwarding protocol. But for control and provisioning, not for > operation, that problem can be separated from the initial protocol > design. > > What we might consider in the protocol design is negotiating the data > forwarding protocol. I do not favor negotiation of that protocol as the > final solution. It leads to too many options in a multivendor situation > and will likely provide less interoperability rather than more. When > the question arises, I would prefer we had the hard discussions to > arrive at a single protocol to be used for data forwarding. > > -Bob > > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Partha Narasimhan > Sent: Thursday, August 12, 2004 1:19 PM > To: Lily L Yang > Cc: Wijnen, Bert (Bert); Shankar Narayanaswamy; > Dorothy.Gellert@nokia.com; capwap@frascone.com > Subject: RE: [Capwap] Re: Data plane and control plane separation in > SplitMAC > > > The set of AP functions is split across the WTP and the AC in the > split-MAC and, arguably to a lesser extent, in the local MAC > architectures. As a result, the AP, in these architectures, is no longer > a physical entity, but one that potentially spans a L3 boundary. The > handling of data frames (and some mgmt frames in the split-MAC arch) > within an AP could involve transferring it over a L3 network from the > WTP to the AC or vice-versa. If these two end-points are from multiple > different vendors, then there needs to be an agreement on the mode of > this transfer. Hence, we cannot ignore this problem in defining a CAPWAP > protocol. > Thanks > partha > > On Thu, 2004-08-12 at 10:42, Yang, Lily L wrote: > > To examine our options of architecture assumptions, let me first put > our > > my definition of data plane and control plane just to make sure we > start > > from the same page: > > > > To me, 802.11 data plane means the dath path travelled by the native > > 802.11 data frames while 802.11 control plane means the data path > > between 802.11 STA and the 802.11-awared control end point. > > > > For both Local and Split MAC, that 802.11-awared control point is AC. > So > > both architecture has the same control path: STA->WTP->AC. The > > difference is how that control messages are implemented between WTP > and > > AC: Split MAC simply tunneled the 802.11 management frames, while > Local > > MAC translated them into some other non-802.11 forms. Another > (implied) > > difference is that Split MAC largely relies on the AC to respond to > > those management frames from STA, while Local MAC relies on WTP to > > respond, but allow AC to be informed of such events as well. So the > > timing constraint may be more relaxed for local MAC. > > > > The question is on the data path. Here is my understanding so far: > > In Local MAC, the data path is between STA and WTP. From WTP, it can > be > > switched or routed locally, entirely bypassing AC. For Split MAC, My > > impression has been that the data path is between STA and WTP and AC, > > because it seems that Split MAC vendors tunnel ALL 802.11 data back to > > AC, even though I don't see why it has to be that way. Just from the > > recent discussion, some have hinted that even Split MAC can allow data > > path terminate at WTP and be "locally" switched without involving AC. > Is > > this true? Can anyone confirm more explicitly and elaborate this for > me? > > > > > > To summarize: > > Common control path: STA->WTP->AC. (but control messages between > > WTP<->AC are done diffrently) > > Local MAC data path: STA->WTP. > > Split MAC data path: STA->WTP->AC or STA->WTP (This needs to be > > clarified). > > > > My hunch is that CAPWAP protocol would have to allow the flexibility > in > > datapath, for either architecture (Split or Local). So in that case, > it > > doesn't really matter if it is Split or Local, it should allow > datapath > > to be configurable any way. In that sense, I agree with what Shankar > was > > saying here. This seems also suggest that YES, we can cleanly separate > > data plane and control plane here. But that doesn't mean any > discussion > > around data plane is out of scope -- because guess what? Why do we > need > > the control plane at the first place? To control and configure the > data > > plane! > > > > So understanding what data plane needs would drive our discussion for > > the control plane and CAPWAP. > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On Behalf Of Wijnen, Bert (Bert) > > > Sent: Thursday, August 12, 2004 2:30 AM > > > To: Shankar Narayanaswamy; Dorothy.Gellert@nokia.com > > > Cc: capwap@frascone.com > > > Subject: RE: [Capwap] Re: Data plane and control plane > > > separation in Split MAC > > > > > > > -----Original Message----- > > > > From: Shankar Narayanaswamy [mailto:wireless@shankar.org] > > > > Sent: donderdag 12 augustus 2004 05:13 > > > > To: Dorothy.Gellert@nokia.com > > > > Cc: capwap@frascone.com > > > > Subject: [Capwap] Re: Data plane and control plane > > > separation in Split > > > > MAC > > > > > > > > > > > > The parameters by which the data plane communicates such as > > > > authentication/security info, destination switch (if any) for data > > > > > frames, etc, are communicated by the control plane. Hence > > > the need for > > > > some architectural assumptions regarding the data plane even if > the > > > > focus is on the control plane. > > > > > > > > Or at least a decision on the data plane architectures to be > > > > supported. > > > > > > > So... to me that sounds that we may potentially do an IMPLIED > > > agreement on the architecture for data plane, based on the > > > capabilities we define in the standards track control and > > > provisioning protocol. > > > > > > That would be fine with me. But we should NOT get bogged down > > > in that data plane stuff, or at least that to me seems to be > > > the wrong focus. > > > > > > Bert > > > > -s > > > > > > > > Dorothy.Gellert@nokia.com wrote: > > > > > Good point. Can we have the volunteers that submitted > > > > architectures for the taxonomy draft weigh in on this issue? > > > > > > > > > > Also another point to consider is that we don't have to > > > > implement *every* AP function in the first release of the CAPWAP > > > > protocol. One of our charter goals is to start with > > > > the minimal set of functionality needed to provide control. > > > > We have a "desirable" category where we can put objectives > > > that can be > > > > met with a later release or extension. > > > > > > > > > > Dorothy > > > > > > > > > >>-----Original Message----- > > > > >>From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com]On > > > > >>Behalf Of ext Yang, Lily L > > > > >>Sent: Tuesday, August 10, 2004 6:13 PM > > > > >>To: Sudhanshu Jain; Shehzad Merchant; Shankar > > > Narayanaswamy; Abhijit > > > > >>Choudhury > > > > >>Cc: capwap@frascone.com > > > > >>Subject: RE: [Capwap] So many architectures, so little time... - > > > > > >>take 2 > > > > >> > > > > >> > > > > >>The question in my mind is: Can data plane and control plane be > > > > >>cleanly separated for Split MAC? I know it is feasible for Local > > > > MAC, but not > > > > >>sure about Split MAC. > > > > >>Any insight? > > > > >> > > > > >>-----Original Message----- > > > > >>From: capwap-admin@frascone.com > > > > [mailto:capwap-admin@frascone.com] On > > > > >>Behalf Of Sudhanshu Jain > > > > >>Sent: Tuesday, August 10, 2004 11:55 AM > > > > >>To: Shehzad Merchant; Shankar Narayanaswamy; Abhijit Choudhury > > > > >>Cc: capwap@frascone.com > > > > >>Subject: RE: [Capwap] So many architectures, so little time... - > > > > > >>take 2 > > > > >> > > > > >>I fully agree with Shehzad. We need to separate the > > > control and data > > > > >>plane. Control plane should provide the framework to use one of > > > > >>several tunneling protocol. > > > > >> > > > > >>On data plane, if we need to define a new layer2/layer3 level > > > > >>tunneling protocol, it should be separate work from > > > control protocol > > > > >>work. > > > > >> > > > > >>-Suds > > > > >> > > > > >> > > > > >>-----Original Message----- > > > > >>From: capwap-admin@frascone.com > > > > [mailto:capwap-admin@frascone.com] On > > > > >>Behalf Of Shehzad Merchant > > > > >>Sent: Tuesday, August 10, 2004 11:13 AM > > > > >>To: Shankar Narayanaswamy; Abhijit Choudhury > > > > >>Cc: capwap@frascone.com > > > > >>Subject: RE: [Capwap] So many architectures, so little time... - > > > > > >>take 2 > > > > >> > > > > >>Additionally, for data tunneling one needs a lightweight > > > mechanism > > > > >>that may not necessarily have the same requirements as that for > > > > >>control and management. For example, one would want to limit the > > > > > >>tunneling and processing overhead on data packets to a minimum. > > > > >>Control and management may be more tolerant of > > > > >>tunneling/security/etc. overhead. > > > > >>Besides, there are > > > > >>plenty of standards in place for data tunneling. We may > > > > potentially be > > > > >>able > > > > >>to leverage off that work itself without having to invent > > > > yet another > > > > >>tunneling mechanism for data. > > > > >> > > > > >>-S > > > > >> > > > > >> > > > > >>-----Original Message----- > > > > >>From: capwap-admin@frascone.com > > > > [mailto:capwap-admin@frascone.com] On > > > > >>Behalf > > > > >>Of Shankar Narayanaswamy > > > > >>Sent: Tuesday, August 10, 2004 10:30 AM > > > > >>To: Abhijit Choudhury > > > > >>Cc: capwap@frascone.com > > > > >>Subject: Re: [Capwap] So many architectures, so little time... - > > > > > >>take 2 > > > > >> > > > > >>On the first point: not necessarily. If data packets are > > > > encapsulated > > > > >>802.11 data frames, then there is no need to protect them > > > > on the wire > > > > >>any > > > > >>more than they were encrypted over the air. > > > > >> > > > > >>But control and management packets will need protection > > > > over the wired > > > > >>network and therefore possibly a different tunneling protocol. > > > > >> > > > > >>On the second point (standard way of packet exchange): yes! > > > > >> > > > > >>-s > > > > >> > > > > >>Abhijit Choudhury wrote: > > > > >> > > > > >>>The same tunneling protocol that moves control and > > > > >> > > > > >>management packets > > > > >> > > > > >>>from the WTP to the AC should be used to tunnel data > > > > >> > > > > >>packets as well. > > > > >> > > > > >> > > > > >>>We would specify message exchanges to do control, > > > provisioning and > > > > >>>capability advertisement between WTPs and the AC. But > > > all of this > > > > >>>would be within the unified CAPWAP protocol that moves > > > all packets > > > > >>>including data between the WTP and AC. Vendors currently > > > > >> > > > > >>use LWAPP, > > > > >> > > > > >>>GRE, IP and some proprietary encapsulations to achieve > > > this. This > > > > >>>group would come up with a "standard" way of doing this > exchange. > > > > >>> > > > > >>>At least that was my understanding.... > > > > >>> > > > > >>>Regards, > > > > >>>Abhijit > > > > >>> > > > > >>>-----Original Mssage----- > > > > >>>From: capwap-admin@frascone.com > > > > >> > > > > >>[mailto:capwap-admin@frascone.com] On > > > > >> > > > > >>>Behalf Of Wijnen, Bert (Bert) > > > > >>>Sent: Monday, August 09, 2004 6:14 AM > > > > >>>To: 'Yang, Lily L'; Burbank, Jack L.; Victor Lin; Bob O'Hara; > > > > >>>capwap@frascone.com > > > > >>>Subject: RE: [Capwap] So many architectures, so little > > > > >> > > > > >>time... - take > > > > >> > > > > >>>2 > > > > >>> > > > > >>> > > > > >>>Not sure who is confused... probably me... > > > > >>> > > > > >>>My understanding was/is that IF we do re-charter for CAPWAP > > > > >> > > > > >>protocol > > > > >> > > > > >>>work, that it is then a NM protocol for "Control and > > > > >> > > > > >>Provisioning" and > > > > >> > > > > >> > > > > >>>not any of the related stuff that moves the data from WTP to > AC. > > > > >>> > > > > >>>Is everybody in agreement with that understanding. > > > > >>> > > > > >>>Thanks, > > > > >>>Bert > > > > >>> > > > > >>> > > > > >>> > > > > >>>>-----Original Message----- > > > > >>>>From: Yang, Lily L [mailto:lily.l.yang@intel.com] > > > > >>>>Sent: maandag 9 augustus 2004 08:14 > > > > >>>>To: Burbank, Jack L.; Victor Lin ; Bob O'Hara ; > > > > capwap@frascone.com > > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > > >>> > > > > >>time... - take > > > > >> > > > > >>>>2 > > > > >>>> > > > > >>>> > > > > >>>>I think setting the re-charter scope to develop a single > > > > >>> > > > > >>protocol that > > > > >> > > > > >>> > > > > >>>>allows interoperability between Local and Split MAC is a > > > > reasonable > > > > >>>>tradeoff: > > > > >>>>We exclude remote MAC because the constraint it imposes is > very > > > > >>>>different from the rest and the benefit of including it is > very > > > > >>>>little. But Local and Split MAC are reasonably close and > > > > hence the > > > > >>>>effort may be incremental only. > > > > >>>>As many people noted, as of today, there is no single clear > > > > >>> > > > > >>definition > > > > >> > > > > >> > > > > >>>>of what "Local MAC" and "Split MAC" really means yet. Each > > > > >>> > > > > >>vendor has > > > > >> > > > > >>>>different definitions and some debate needs to happen so > > > > >>> > > > > >>that the WG > > > > >> > > > > >>>>can reach consensus on what exactly that means, and > > > what kinds of > > > > >>>>flexibility we want to retain within each class of > > > > >>> > > > > >>architecture, and > > > > >> > > > > >>>>what kind of differences we can to resolve and agree up > > > > front. That > > > > >>>>should also be part of the work items for the new WG -- > > > > >>> > > > > >>such agreement > > > > >> > > > > >> > > > > >>>>on the details for each architecture must be documented > > > > >>> > > > > >>somewhere, if > > > > >> > > > > >>>>not separately, then as part of the Protocol document. > > > > >>>> > > > > >>>>-----Original Message----- > > > > >>>>From: capwap-admin@frascone.com > > > > >>> > > > > >>[mailto:capwap-admin@frascone.com] On > > > > >> > > > > >>>>Behalf Of Burbank, Jack L. > > > > >>>>Sent: Thursday, August 05, 2004 12:14 PM > > > > >>>>To: 'Victor Lin '; 'Bob O'Hara '; 'capwap@frascone.com ' > > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > > >>> > > > > >>time... - take > > > > >> > > > > >>>>2 > > > > >>>> > > > > >>>>I think that interoperability between different > > > > >>> > > > > >>architectures should > > > > >> > > > > >>>>be a requirement, if not the key requirement. As was > mentioned > > > > >>>>yesterday, a goal of the IEEE is that they maintain > > > > flexibility in > > > > >>>>terms of how products and architectures are implemented. I > > > > >>> > > > > >>think we > > > > >> > > > > >>>>shouldn't do anything that is contrary to that goal (or > > > > at least we > > > > >>>>should minimize the impact). I think that the goal of > > > > >>> > > > > >>CAPWAP should > > > > >> > > > > >>>>be to retain this type of flexibility by designing a > > > > >>> > > > > >>protocol that can > > > > >> > > > > >> > > > > >>>>maintain this implementation flexibility but enable > > > > >>> > > > > >>interoperability > > > > >> > > > > >>>>between the various architecture implementations (that > > > > after all is > > > > >>>>the key problem with the deployment of these various > > > > >>> > > > > >>architectures - > > > > >> > > > > >>>>lack of interoperability). IMO, if we don't design for > > > > >>>>interoperability between the basic architecture types, it > > > > >>> > > > > >>is debatable > > > > >> > > > > >> > > > > >>>>if something useful would have been accomplished. > > > > >>>> > > > > >>>>Jack Burbank > > > > >>>> > > > > >>>>-----Original Message----- > > > > >>>>From: capwap-admin@frascone.com > > > > >>>>To: Bob O'Hara; capwap@frascone.com > > > > >>>>Sent: 8/5/2004 2:46 PM > > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > > >>> > > > > >>time... - take > > > > >> > > > > >>>>2 > > > > >>>> > > > > >>>>I agree that we can design a protocol and implement the > > > > >>> > > > > >>product that > > > > >> > > > > >>>>works all architectures. I think the question to CAPWAP is: > > > > >>>> > > > > >>>>Should we make it a requirement in CAPWAP protocol to achieve > > > > >>>>interoperability between different architectures? > > > > >>>> > > > > >>>>It is definitely doable, but I'm not sure if that is the > > > > >>> > > > > >>right thing > > > > >> > > > > >>>>to do.. > > > > >>>> > > > > >>>>Victor > > > > >>>> > > > > >>>>-----Original Message----- > > > > >>>>From: capwap-admin@frascone.com > > > > >>> > > > > >>[mailto:capwap-admin@frascone.com] On > > > > >> > > > > >>>>Behalf Of Bob O'Hara > > > > >>>>Sent: Thursday, August 05, 2004 11:43 AM > > > > >>>>To: capwap@frascone.com > > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > > >>> > > > > >>time... - take > > > > >> > > > > >>>>2 > > > > >>>> > > > > >>>>I think that interoperability will depend on two things. > > > > >>>>First, it will > > > > >>>>depend on how we define the protocol and the flexibility > > > > >>> > > > > >>for supported > > > > >> > > > > >> > > > > >>>>architectures it incorporates. Second, it will depend on what > > > > > >>>>manufacturers implement, i.e., the flexibility they build > > > > >>> > > > > >>into their > > > > >> > > > > >>>>products. > > > > >>>> > > > > >>>>I believe that it is possible to design the protocol for > > > > >>> > > > > >>the required > > > > >> > > > > >>>>flexibility. I know it is possible to implement a > > > > product with the > > > > >>>>required flexibility. > > > > >>>> > > > > >>>>-Bob O'Hara > > > > >>>> > > > > >>>> > > > > >>>>-----Original Message----- > > > > >>>>From: capwap-admin@frascone.com > > > > >>> > > > > >>[mailto:capwap-admin@frascone.com] On > > > > >> > > > > >>>>Behalf Of Abhijit Choudhury > > > > >>>>Sent: Thursday, August 05, 2004 11:32 AM > > > > >>>>To: James Kempf; Shehzad Merchant; capwap@frascone.com > > > > >>>>Cc: bwijnen@lucent.com; mmani@avaya.com; > > > david.kessens@nokia.com; > > > > >>>>Dorothy.Gellert@nokia.com; Inderpreet Singh > > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > > >>> > > > > >>time... - take > > > > >> > > > > >>>>2 > > > > >>>> > > > > >>>> > > > > >>>>It may be possible to achieve such interoperability within the > > > > > >>>>split-MAC family or within the local-MAC family. It > > > > would sbe very > > > > >>>>hard to achieve that between local and split MAC families. > > > > >>>> > > > > >>>>For example, if vendor X's WTP terminates 802.11 ctrl/mgmt > > > > >>> > > > > >>packets and > > > > >> > > > > >>> > > > > >>>>vendor Y's AC expects the 802.11 mgmt packets to come to > > > > >>> > > > > >>it, there's > > > > >> > > > > >>>>no way you can be interoperable. > > > > >>>> > > > > >>>>Or are we planning to specify ONE architecture ? > > > > >>>>The last thing IETF should do is mandate an implementation. > > > > >>>> > > > > >>>>I think a modest and reasonable goal is to come up with a > > > > protocol > > > > >>>>that allows sufficient flexbility so that vendors with > splitMAC > > > > >>>>architectures can transfer most of the information they > > > > care about > > > > >>>>between the WTP and AC. > > > > >>>> > > > > >>>>Just my $0.02 ... > > > > >>>> > > > > >>>> > > > > >>>>Abhijit Choudhury > > > > >>>> > > > > >>>> > > > > >>>>-----Original Message----- > > > > >>>>From: capwap-admin@frascone.com > > > > >>> > > > > >>[mailto:capwap-admin@frascone.com] On > > > > >> > > > > >>>>Behalf Of James Kempf > > > > >>>>Sent: Wednesday, August 04, 2004 3:29 PM > > > > >>>>To: Shehzad Merchant; capwap@frascone.com > > > > >>>>Cc: bwijnen@lucent.com; mmani@avaya.com; > > > david.kessens@nokia.com; > > > > >>>>Dorothy.Gellert@nokia.com; Inderpreet Singh > > > > >>>>Subject: Re: [Capwap] So many architectures, so little > > > > >>> > > > > >>time... - take > > > > >> > > > > >>>>2 > > > > >>>> > > > > >>>> > > > > >>>>As a potential customer, let me put it concretely. I want > > > > >>> > > > > >>to be able > > > > >> > > > > >>>>to buy my access points from Vendor X and my switch from > > > > >>> > > > > >>Vendor Y and > > > > >> > > > > >>>>plug the two together and have them work without any > > > > configuration. > > > > >>>>Also, I'd like to be able to buy switches from Vendor Y and > > > > >>> > > > > >>Vendor Z > > > > >> > > > > >>>>and be able to plug them into my network at various > > > > places and have > > > > >>>>them interoperate. > > > > >>>> > > > > >>>> jak > > > > >>>> > > > > >>>> > > > > >>>>----- Original Message ----- > > > > >>>>From: "Shehzad Merchant" > > > > >>>>To: > > > > >>>>Cc: ; ; > > > > >>>>; ; > > > > "Inderpreet > > > > >>>>Singh" > > > > >>>> > > > > >>>>Sent: Wednesday, August 04, 2004 3:19 PM > > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > > >>> > > > > >>time... - take > > > > >> > > > > >>>>2 > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>I think the implementation variations even with the > > > > split MAC may > > > > >>>>>cover a broad spectrum. As such its important to clearly > > > > >>>> > > > > >>articulate > > > > >> > > > > >>>>>what aspects > > > > >>>> > > > > >>>>of > > > > >>>> > > > > >>>> > > > > >>>>>interoperability we are targetting. Is it truly just > > > > >>>>>control/management or is it interoperability between > disparate > > > > >>>>>implementations of the split MAC, i.e. mix and match > > > > >>>> > > > > >>>>operation of WTP > > > > >>>> > > > > >>>> > > > > >>>>>and ACs of all variants within this category. > > > > >>>>> > > > > >>>>>I suspect for the latter we may have to arrive at some > > > > >>>> > > > > >>consensus on > > > > >> > > > > >>>>>what particular implementations we are targeting > > > > >>>> > > > > >>>>interoperability for. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>If so, ultimately this problem statement could become > > > > part of the > > > > >>>>>charter. > > > > >>>>> > > > > >>>>>-Shehzad > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>>-----Original Message----- > > > > >>>>>From: capwap-admin@frascone.com > > > > >>>> > > > > >>>>[mailto:capwap-admin@frascone.com] On Behalf > > > > >>>> > > > > >>>> > > > > >>>>>Of Dorothy.Gellert@nokia.com > > > > >>>>>Sent: Wednesday, August 04, 2004 11:53 AM > > > > >>>>>To: isingh@chantrynetworks.com; capwap@frascone.com > > > > >>>>>Cc: bwijnen@lucent.com; mmani@avaya.com; > > > david.kessens@nokia.com > > > > >>>>>Subject: RE: [Capwap] So many architectures, so little > > > > >>>> > > > > >>>>time... - take > > > > >>>> > > > > >>>> > > > > >>>>>2 > > > > >>>>> > > > > >>>>>I believe this is the consensus, to scope the charter to > > > > >>>> > > > > >>>>Centralized > > > > >>>> > > > > >>>> > > > > >>>>>Architecture and LocalMAC and Split MAC. > > > > >>>>> > > > > >>>>>I'll update the charter with this change after the CAPWAP > > > > >>>> > > > > >>>>WG Mtg. If > > > > >>>> > > > > >>>> > > > > >>>>>there is resistance to this idea, please post to the list. > > > > >>>>> > > > > >>>>>Regards > > > > >>>>>Dorothy > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>>>-----Original Message----- > > > > >>>>>>From: capwap-admin@frascone.com > > > > >>>>> > > > > >>>>[mailto:capwap-admin@frascone.com]On > > > > >>>> > > > > >>>> > > > > >>>>>>Behalf Of ext Inderpreet Singh > > > > >>>>>>Sent: Tuesday, August 03, 2004 9:40 PM > > > > >>>>>>To: capwap@frascone.com > > > > >>>>>>Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David > > > > >>>>>>(Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > > > > >>>>>>Subject: RE: [Capwap] So many architectures, so little > > > > time... - > > > > >>>>>>take 2 > > > > >>>>>> > > > > >>>>>> > > > > >>>>>>The issue(s) at hand and my opinions are: > > > > >>>>>> > > > > >>>>>>1. Do we explicitly state in the re-charter which > > > > >>>>> > > > > >>>>architecture the > > > > >>>> > > > > >>>> > > > > >>>>>>WG should consider? I think yes. I propose Centralized > > > > >>>>> > > > > >>>>architecture > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>>only. Autonomous and Distributed should be out of scope > > > > >>>>> > > > > >>>>based on the > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>>same reasons as per prior postings. > > > > >>>>>> > > > > >>>>>>2. Within Centralized do we focus on all three sub > > > > >>>>> > > > > >>>>architectures or > > > > >>>> > > > > >>>> > > > > >>>>>>a subset? Remote MAC should be excluded because if I am not > > > > >>>>>>mistaken, the connectivity constraint between the WTP and > > > > >>>>> > > > > >>>>the AC is > > > > >>>> > > > > >>>> > > > > >>>>>>"direct connect". > > > > >>>>>>That being the case and that no IP layer is involved, > > > it doesn't > > > > >>>>> > > > > >>>>seem > > > > >>>> > > > > >>>> > > > > >>>>>>clear what kind of protocol would help with > > > > interoperability. I am > > > > >>>>> > > > > >>>>>>concerned about the impact, dependencies and > > > > interaction with the > > > > >>>>>>recently constituted IEEE Study group on AP > > > > >>>>> > > > > >>>>functionality on the > > > > >>>> > > > > >>>> > > > > >>>>>>Split MAC architectures. Furthermore, there are some > > > > >>>>> > > > > >>>>pretty drastic > > > > >>>> > > > > >>>> > > > > >>>>>>differences on how the vendors have chosen to split the > > > > >>>>> > > > > >>>>mac. Those > > > > >>>> > > > > >>>> > > > > >>>>>>differences will need to be worked out before designing a > > > > >>>>> > > > > >>>>protocol. > > > > >>>> > > > > >>>> > > > > >>>>>>So, if the low hanging fruit strategy (as James > > > suggested) for > > > > >>>>>>protocol development and progress is the way to go, > > > > then I think > > > > >>>>>>prioritizing on a protocol for Local MAC is a no brainer. > > > > >>>>> > > > > >>>>So as far > > > > >>>> > > > > >>>> > > > > >>>>>>as focus, I feel we should do Local and Split and in > > > that order. > > > > >>>>>> > > > > >>>>>>3. This is not a re-chartering issue but is a > > > response to Pat's > > > > >>>>>>suggestion that a protocol that just sends the 802.11 > > > > MAC frames > > > > >>>>> > > > > >>>>>>from the AP to the AC would work. I think possibly, yes. > > > > >>>>> > > > > >>>> > > > > >>>>But again > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>>the complications of splitting the MAC in an > > > > >>>>> > > > > >>>>interoperable way will > > > > >>>> > > > > >>>> > > > > >>>>>>be an issue. Also, you may note in the draft to which > > > > >>>>> > > > > >>>>you refer, we > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>>included a capabilities exchange phase. I had thought of > > > > >>>>> > > > > >>>>including > > > > >>>> > > > > >>>> > > > > >>>>>>in the capability exchange such things as "AP supports > > > > Local MAC" > > > > >>>>>>and "AP supports Split MAC", but didn't put it in because > the > > > > >>>>>>Taxonomy work was still in progress. Now that it is > > > > pretty much > > > > >>>>>>done we could surely include that. But again...let's > > > recharter > > > > >>>>>>first. > > > > >>>>>> > > > > >>>>>>Thanks. Do people agree with 1 & 2? > > > > >>>>>> > > > > >>>>>>--- > > > > >>>>>>Inderpreet Singh > > > > >>>>>>Chantry Networks > > > > >>>>>>isingh@chantrynetworks.com > > > > >>>>>>Cell: 416-831-3705 > > > > >>>>>> > > > > >>>>>>-----Original Message----- > > > > >>>>>>From: capwap-admin@frascone.com > > > > >>>>> > > > > >>>>[mailto:capwap-admin@frascone.com] > > > > >>>> > > > > >>>> > > > > >>>>>>On Behalf Of Pat R. Calhoun > > > > >>>>>>Sent: Tuesday, August 03, 2004 6:04 PM > > > > >>>>>>To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com; > > > > >>>>>>capwap@frascone.com > > > > >>>>>>Cc: bwijnen@lucent.com; mmani@avaya.com; > > > david.kessens@nokia.com > > > > >>>>>>Subject: [Capwap] So many architectures, so little > > > > >>>>> > > > > >>>>time... - take 2 > > > > >>>> > > > > >>>> > > > > >>>>>>After reading Lily's response to Jim, I realize that I > > > > >>>>> > > > > >>>>fell down the > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>>same trap. Local MAC is also a centralized approach, > > > and so my > > > > >>>>>>previous response was not complete. I believe the real > > > > >>>>> > > > > >>>>question, in > > > > >>>> > > > > >>>> > > > > >>>>>>my mind, is whether we need to address either the Local > > > > >>>>> > > > > >>>>or the Split > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>>MAC architecture. > > > > >>>>>> > > > > >>>>>>Just looking at the Architecture Consideration tables (7 and > > > > >>>>>>10) in the > > > > >>>>>>specification, the > > > > >>>>>>main difference (at a high level) between both approaches > > > > >>>>> > > > > >>>>is where > > > > >>>> > > > > >>>> > > > > >>>>>>the 802.11 management terminates. For Local MAC, it's > > > > in the WTP, > > > > >>>>>>while for SPlit MAC, it's in the AC. > > > > >>>>>> > > > > >>>>>>However, looking at table 8, most Local MAC approaches > > > > share STA > > > > >>>>>>state between both the WTP and the AC. So clearly > > > there is some > > > > >>>>>>signalling protocol between both the WTP and the AC. > > > > >>>>>> > > > > >>>>>>Looking at one example of a Local MAC protocol (see > > > > >>>>>> > > > > >>>>> > > > > > > > > >>>http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > > > > >>> > > > > >>> > > > > >>>>>there is a protocol message > > > > >>>>>that corresponds for every 802.11 MAC management event. So > > > > >>>> > > > > >>when a STA > > > > >> > > > > >> > > > > >>>>>associates, the AP breaks the message apart and creates an > new > > > > >>>>>protocol PDU, which contains components found in the > > > association > > > > >>>>>request. I suspect that most Local MAC approaches do > > > > >>>> > > > > >>something very > > > > >> > > > > >>>>>similar. > > > > >>>>> > > > > >>>>>So if a protocol simply tunnels the 802.11 MAC management > > > > >>>> > > > > >>frames from > > > > >> > > > > >> > > > > >>>>>the WTP to the AC, it allows supports both approaches. For > > > > >>>> > > > > >>Local MAC, > > > > >> > > > > >> > > > > >>>>>they get what they want via the 802.11 frame, and this > > > > also works > > > > >>>>>fine for Split MAC, which needs access to the MAC > > > > >>>> > > > > >>management frame. > > > > >> > > > > >>>>>What would be required in such a protocol is a way for > > > the AP to > > > > >>>>>communicate whether it will be providing very specific > > > > functions - > > > > >>>>>basically a capabilities negotiation approach. > > > > >>>>> > > > > >>>>>So I do believe that there is a way to address both > > > > architectures > > > > >>>>>using a single protocol. > > > > >>>>> > > > > >>>>>Thoughts? > > > > >>>>> > > > > >>>>>PatC > > > > >>>>> > > > > >>>>>_______________________________________________ > > > > >>>>>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 > > > >>>_______________________________________________ > > > >>>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 > > > >>>_______________________________________________ > > > >>>Capwap mailing list > > > >>>Capwap@frascone.com > > > >>>http://mail.frascone.com/mailman/listinfo/capwap > > > >> > > > >> > > > >>-- > > > >>Shankar Narayanaswamy, Ph.D. > > > >>wireless@shankar.org Mobile: +1 650-387-4593 > > > >>http://www.shankar.org E-Fax: +1 253-498-8372 > > > >> > > > >>_______________________________________________ > > > >>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 > > > > > > > > > > > > > > > > > -- > > > Shankar Narayanaswamy, Ph.D. > > > wireless@shankar.org Mobile: +1 650-387-4593 > > > http://www.shankar.org E-Fax: +1 253-498-8372 > > > > > > _______________________________________________ > > > 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 > _______________________________________________ > 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 Aug 13 17:36:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19372 for ; Fri, 13 Aug 2004 17:36:03 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9173821D96; Fri, 13 Aug 2004 17:21:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A812721D91; Fri, 13 Aug 2004 17:21:08 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 98FD821D91 for ; Fri, 13 Aug 2004 17:20:40 -0400 (EDT) Received: from sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by mail.frascone.com (Postfix) with ESMTP id 42D0E208B5 for ; Fri, 13 Aug 2004 17:20:38 -0400 (EDT) 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.6944.0 Subject: RE: [Capwap] Re: Data plane and control plane separation in SplitMAC Message-ID: Thread-Topic: [Capwap] Re: Data plane and control plane separation in SplitMAC Thread-Index: AcSBdqvGdoouw1IHR6miWronADv2MgABW0EQ From: "Sudhanshu Jain" To: "Shankar Narayanaswamy" , "Yang, Lily L" Cc: "Bob O'Hara" , 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, 13 Aug 2004 14:39:25 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable As a CAPWAP control protocol, we should discuss what are the different protocols can be used and how it can be used in data plane. We should have some contribution towards those objectives. But as a control protocol design, we should not limit to that.=20 -Suds -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Shankar Narayanaswamy Sent: Friday, August 13, 2004 1:42 PM To: Yang, Lily L Cc: Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Re: Data plane and control plane separation in SplitMAC A single protocol for data forwarding is a worthy goal. However that may be suboptimal in some cases. Consider where the entire WEP/TKIP/WPA data frame is encrypted/decrypted in the AC. It would be unnecessary and unreasonably demanding to use SSL or some other encrypted IP tunneling protocol between the WTP and the AC. Any simple IP-in-IP protocol would suffice and allow the WTP to be more lightweight than would otherwise be the case. So we should aim for allowing a (very small) set of well-known, standard data forwarding protocols to be negotiated over the control plane. The actual number of protocols (and which ones) is something that we as a group will decide. -s -- Shankar Narayanaswamy, Ph.D. Quoting "Yang, Lily L" : > I also think it makes more sense to arrive at a single protocol for data > forwarding. It doesn't mean CAPWAP has to reinvent the wheel to come up > with yet another tunneling protocol -- existing protocol can be reused > for that purpose. But for interoperability, we need to agree on one > eventually. > So the relevant discussion is to understand the requirements for data > forwarding. > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Bob O'Hara > Sent: Friday, August 13, 2004 12:59 PM > To: capwap@frascone.com > Subject: RE: [Capwap] Re: Data plane and control plane separation in > SplitMAC > > I agree that for a complete solution, we cannot ignore the need for a > data forwarding protocol. But for control and provisioning, not for > operation, that problem can be separated from the initial protocol > design. > > What we might consider in the protocol design is negotiating the data > forwarding protocol. I do not favor negotiation of that protocol as the > final solution. It leads to too many options in a multivendor situation > and will likely provide less interoperability rather than more. When > the question arises, I would prefer we had the hard discussions to > arrive at a single protocol to be used for data forwarding. > > -Bob > > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Partha Narasimhan > Sent: Thursday, August 12, 2004 1:19 PM > To: Lily L Yang > Cc: Wijnen, Bert (Bert); Shankar Narayanaswamy; > Dorothy.Gellert@nokia.com; capwap@frascone.com > Subject: RE: [Capwap] Re: Data plane and control plane separation in > SplitMAC > > > The set of AP functions is split across the WTP and the AC in the > split-MAC and, arguably to a lesser extent, in the local MAC > architectures. As a result, the AP, in these architectures, is no longer > a physical entity, but one that potentially spans a L3 boundary. The > handling of data frames (and some mgmt frames in the split-MAC arch) > within an AP could involve transferring it over a L3 network from the > WTP to the AC or vice-versa. If these two end-points are from multiple > different vendors, then there needs to be an agreement on the mode of > this transfer. Hence, we cannot ignore this problem in defining a CAPWAP > protocol. > Thanks > partha > > On Thu, 2004-08-12 at 10:42, Yang, Lily L wrote: > > To examine our options of architecture assumptions, let me first put > our > > my definition of data plane and control plane just to make sure we > start > > from the same page: > > > > To me, 802.11 data plane means the dath path travelled by the native > > 802.11 data frames while 802.11 control plane means the data path > > between 802.11 STA and the 802.11-awared control end point. > > > > For both Local and Split MAC, that 802.11-awared control point is AC. > So > > both architecture has the same control path: STA->WTP->AC. The > > difference is how that control messages are implemented between WTP > and > > AC: Split MAC simply tunneled the 802.11 management frames, while > Local > > MAC translated them into some other non-802.11 forms. Another > (implied) > > difference is that Split MAC largely relies on the AC to respond to > > those management frames from STA, while Local MAC relies on WTP to > > respond, but allow AC to be informed of such events as well. So the > > timing constraint may be more relaxed for local MAC. > > > > The question is on the data path. Here is my understanding so far: > > In Local MAC, the data path is between STA and WTP. From WTP, it can > be > > switched or routed locally, entirely bypassing AC. For Split MAC, My > > impression has been that the data path is between STA and WTP and AC, > > because it seems that Split MAC vendors tunnel ALL 802.11 data back to > > AC, even though I don't see why it has to be that way. Just from the > > recent discussion, some have hinted that even Split MAC can allow data > > path terminate at WTP and be "locally" switched without involving AC. > Is > > this true? Can anyone confirm more explicitly and elaborate this for > me? > > > > > > To summarize: > > Common control path: STA->WTP->AC. (but control messages between > > WTP<->AC are done diffrently) > > Local MAC data path: STA->WTP. > > Split MAC data path: STA->WTP->AC or STA->WTP (This needs to be > > clarified). > > > > My hunch is that CAPWAP protocol would have to allow the flexibility > in > > datapath, for either architecture (Split or Local). So in that case, > it > > doesn't really matter if it is Split or Local, it should allow > datapath > > to be configurable any way. In that sense, I agree with what Shankar > was > > saying here. This seems also suggest that YES, we can cleanly separate > > data plane and control plane here. But that doesn't mean any > discussion > > around data plane is out of scope -- because guess what? Why do we > need > > the control plane at the first place? To control and configure the > data > > plane! > > > > So understanding what data plane needs would drive our discussion for > > the control plane and CAPWAP. > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On Behalf Of Wijnen, Bert (Bert) > > > Sent: Thursday, August 12, 2004 2:30 AM > > > To: Shankar Narayanaswamy; Dorothy.Gellert@nokia.com > > > Cc: capwap@frascone.com > > > Subject: RE: [Capwap] Re: Data plane and control plane > > > separation in Split MAC > > > > > > > -----Original Message----- > > > > From: Shankar Narayanaswamy [mailto:wireless@shankar.org] > > > > Sent: donderdag 12 augustus 2004 05:13 > > > > To: Dorothy.Gellert@nokia.com > > > > Cc: capwap@frascone.com > > > > Subject: [Capwap] Re: Data plane and control plane > > > separation in Split > > > > MAC > > > > > > > > > > > > The parameters by which the data plane communicates such as > > > > authentication/security info, destination switch (if any) for data > > > > > frames, etc, are communicated by the control plane. Hence > > > the need for > > > > some architectural assumptions regarding the data plane even if > the > > > > focus is on the control plane. > > > > > > > > Or at least a decision on the data plane architectures to be > > > > supported. > > > > > > > So... to me that sounds that we may potentially do an IMPLIED > > > agreement on the architecture for data plane, based on the > > > capabilities we define in the standards track control and > > > provisioning protocol. > > > > > > That would be fine with me. But we should NOT get bogged down > > > in that data plane stuff, or at least that to me seems to be > > > the wrong focus. > > > > > > Bert > > > > -s > > > > > > > > Dorothy.Gellert@nokia.com wrote: > > > > > Good point. Can we have the volunteers that submitted > > > > architectures for the taxonomy draft weigh in on this issue? > > > > > > > > > > Also another point to consider is that we don't have to > > > > implement *every* AP function in the first release of the CAPWAP > > > > protocol. One of our charter goals is to start with > > > > the minimal set of functionality needed to provide control. > > > > We have a "desirable" category where we can put objectives > > > that can be > > > > met with a later release or extension. > > > > > > > > > > Dorothy > > > > > > > > > >>-----Original Message----- > > > > >>From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com]On > > > > >>Behalf Of ext Yang, Lily L > > > > >>Sent: Tuesday, August 10, 2004 6:13 PM > > > > >>To: Sudhanshu Jain; Shehzad Merchant; Shankar > > > Narayanaswamy; Abhijit > > > > >>Choudhury > > > > >>Cc: capwap@frascone.com > > > > >>Subject: RE: [Capwap] So many architectures, so little time... - > > > > > >>take 2 > > > > >> > > > > >> > > > > >>The question in my mind is: Can data plane and control plane be > > > > >>cleanly separated for Split MAC? I know it is feasible for Local > > > > MAC, but not > > > > >>sure about Split MAC. > > > > >>Any insight? > > > > >> > > > > >>-----Original Message----- > > > > >>From: capwap-admin@frascone.com > > > > [mailto:capwap-admin@frascone.com] On > > > > >>Behalf Of Sudhanshu Jain > > > > >>Sent: Tuesday, August 10, 2004 11:55 AM > > > > >>To: Shehzad Merchant; Shankar Narayanaswamy; Abhijit Choudhury > > > > >>Cc: capwap@frascone.com > > > > >>Subject: RE: [Capwap] So many architectures, so little time... - > > > > > >>take 2 > > > > >> > > > > >>I fully agree with Shehzad. We need to separate the > > > control and data > > > > >>plane. Control plane should provide the framework to use one of > > > > >>several tunneling protocol. > > > > >> > > > > >>On data plane, if we need to define a new layer2/layer3 level > > > > >>tunneling protocol, it should be separate work from > > > control protocol > > > > >>work. > > > > >> > > > > >>-Suds > > > > >> > > > > >> > > > > >>-----Original Message----- > > > > >>From: capwap-admin@frascone.com > > > > [mailto:capwap-admin@frascone.com] On > > > > >>Behalf Of Shehzad Merchant > > > > >>Sent: Tuesday, August 10, 2004 11:13 AM > > > > >>To: Shankar Narayanaswamy; Abhijit Choudhury > > > > >>Cc: capwap@frascone.com > > > > >>Subject: RE: [Capwap] So many architectures, so little time... - > > > > > >>take 2 > > > > >> > > > > >>Additionally, for data tunneling one needs a lightweight > > > mechanism > > > > >>that may not necessarily have the same requirements as that for > > > > >>control and management. For example, one would want to limit the > > > > > >>tunneling and processing overhead on data packets to a minimum. > > > > >>Control and management may be more tolerant of > > > > >>tunneling/security/etc. overhead. > > > > >>Besides, there are > > > > >>plenty of standards in place for data tunneling. We may > > > > potentially be > > > > >>able > > > > >>to leverage off that work itself without having to invent > > > > yet another > > > > >>tunneling mechanism for data. > > > > >> > > > > >>-S > > > > >> > > > > >> > > > > >>-----Original Message----- > > > > >>From: capwap-admin@frascone.com > > > > [mailto:capwap-admin@frascone.com] On > > > > >>Behalf > > > > >>Of Shankar Narayanaswamy > > > > >>Sent: Tuesday, August 10, 2004 10:30 AM > > > > >>To: Abhijit Choudhury > > > > >>Cc: capwap@frascone.com > > > > >>Subject: Re: [Capwap] So many architectures, so little time... - > > > > > >>take 2 > > > > >> > > > > >>On the first point: not necessarily. If data packets are > > > > encapsulated > > > > >>802.11 data frames, then there is no need to protect them > > > > on the wire > > > > >>any > > > > >>more than they were encrypted over the air. > > > > >> > > > > >>But control and management packets will need protection > > > > over the wired > > > > >>network and therefore possibly a different tunneling protocol. > > > > >> > > > > >>On the second point (standard way of packet exchange): yes! > > > > >> > > > > >>-s > > > > >> > > > > >>Abhijit Choudhury wrote: > > > > >> > > > > >>>The same tunneling protocol that moves control and > > > > >> > > > > >>management packets > > > > >> > > > > >>>from the WTP to the AC should be used to tunnel data > > > > >> > > > > >>packets as well. > > > > >> > > > > >> > > > > >>>We would specify message exchanges to do control, > > > provisioning and > > > > >>>capability advertisement between WTPs and the AC. But > > > all of this > > > > >>>would be within the unified CAPWAP protocol that moves > > > all packets > > > > >>>including data between the WTP and AC. Vendors currently > > > > >> > > > > >>use LWAPP, > > > > >> > > > > >>>GRE, IP and some proprietary encapsulations to achieve > > > this. This > > > > >>>group would come up with a "standard" way of doing this > exchange. > > > > >>> > > > > >>>At least that was my understanding.... > > > > >>> > > > > >>>Regards, > > > > >>>Abhijit > > > > >>> > > > > >>>-----Original Mssage----- > > > > >>>From: capwap-admin@frascone.com > > > > >> > > > > >>[mailto:capwap-admin@frascone.com] On > > > > >> > > > > >>>Behalf Of Wijnen, Bert (Bert) > > > > >>>Sent: Monday, August 09, 2004 6:14 AM > > > > >>>To: 'Yang, Lily L'; Burbank, Jack L.; Victor Lin; Bob O'Hara; > > > > >>>capwap@frascone.com > > > > >>>Subject: RE: [Capwap] So many architectures, so little > > > > >> > > > > >>time... - take > > > > >> > > > > >>>2 > > > > >>> > > > > >>> > > > > >>>Not sure who is confused... probably me... > > > > >>> > > > > >>>My understanding was/is that IF we do re-charter for CAPWAP > > > > >> > > > > >>protocol > > > > >> > > > > >>>work, that it is then a NM protocol for "Control and > > > > >> > > > > >>Provisioning" and > > > > >> > > > > >> > > > > >>>not any of the related stuff that moves the data from WTP to > AC. > > > > >>> > > > > >>>Is everybody in agreement with that understanding. > > > > >>> > > > > >>>Thanks, > > > > >>>Bert > > > > >>> > > > > >>> > > > > >>> > > > > >>>>-----Original Message----- > > > > >>>>From: Yang, Lily L [mailto:lily.l.yang@intel.com] > > > > >>>>Sent: maandag 9 augustus 2004 08:14 > > > > >>>>To: Burbank, Jack L.; Victor Lin ; Bob O'Hara ; > > > > capwap@frascone.com > > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > > >>> > > > > >>time... - take > > > > >> > > > > >>>>2 > > > > >>>> > > > > >>>> > > > > >>>>I think setting the re-charter scope to develop a single > > > > >>> > > > > >>protocol that > > > > >> > > > > >>> > > > > >>>>allows interoperability between Local and Split MAC is a > > > > reasonable > > > > >>>>tradeoff: > > > > >>>>We exclude remote MAC because the constraint it imposes is > very > > > > >>>>different from the rest and the benefit of including it is > very > > > > >>>>little. But Local and Split MAC are reasonably close and > > > > hence the > > > > >>>>effort may be incremental only. > > > > >>>>As many people noted, as of today, there is no single clear > > > > >>> > > > > >>definition > > > > >> > > > > >> > > > > >>>>of what "Local MAC" and "Split MAC" really means yet. Each > > > > >>> > > > > >>vendor has > > > > >> > > > > >>>>different definitions and some debate needs to happen so > > > > >>> > > > > >>that the WG > > > > >> > > > > >>>>can reach consensus on what exactly that means, and > > > what kinds of > > > > >>>>flexibility we want to retain within each class of > > > > >>> > > > > >>architecture, and > > > > >> > > > > >>>>what kind of differences we can to resolve and agree up > > > > front. That > > > > >>>>should also be part of the work items for the new WG -- > > > > >>> > > > > >>such agreement > > > > >> > > > > >> > > > > >>>>on the details for each architecture must be documented > > > > >>> > > > > >>somewhere, if > > > > >> > > > > >>>>not separately, then as part of the Protocol document. > > > > >>>> > > > > >>>>-----Original Message----- > > > > >>>>From: capwap-admin@frascone.com > > > > >>> > > > > >>[mailto:capwap-admin@frascone.com] On > > > > >> > > > > >>>>Behalf Of Burbank, Jack L. > > > > >>>>Sent: Thursday, August 05, 2004 12:14 PM > > > > >>>>To: 'Victor Lin '; 'Bob O'Hara '; 'capwap@frascone.com ' > > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > > >>> > > > > >>time... - take > > > > >> > > > > >>>>2 > > > > >>>> > > > > >>>>I think that interoperability between different > > > > >>> > > > > >>architectures should > > > > >> > > > > >>>>be a requirement, if not the key requirement. As was > mentioned > > > > >>>>yesterday, a goal of the IEEE is that they maintain > > > > flexibility in > > > > >>>>terms of how products and architectures are implemented. I > > > > >>> > > > > >>think we > > > > >> > > > > >>>>shouldn't do anything that is contrary to that goal (or > > > > at least we > > > > >>>>should minimize the impact). I think that the goal of > > > > >>> > > > > >>CAPWAP should > > > > >> > > > > >>>>be to retain this type of flexibility by designing a > > > > >>> > > > > >>protocol that can > > > > >> > > > > >> > > > > >>>>maintain this implementation flexibility but enable > > > > >>> > > > > >>interoperability > > > > >> > > > > >>>>between the various architecture implementations (that > > > > after all is > > > > >>>>the key problem with the deployment of these various > > > > >>> > > > > >>architectures - > > > > >> > > > > >>>>lack of interoperability). IMO, if we don't design for > > > > >>>>interoperability between the basic architecture types, it > > > > >>> > > > > >>is debatable > > > > >> > > > > >> > > > > >>>>if something useful would have been accomplished. > > > > >>>> > > > > >>>>Jack Burbank > > > > >>>> > > > > >>>>-----Original Message----- > > > > >>>>From: capwap-admin@frascone.com > > > > >>>>To: Bob O'Hara; capwap@frascone.com > > > > >>>>Sent: 8/5/2004 2:46 PM > > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > > >>> > > > > >>time... - take > > > > >> > > > > >>>>2 > > > > >>>> > > > > >>>>I agree that we can design a protocol and implement the > > > > >>> > > > > >>product that > > > > >> > > > > >>>>works all architectures. I think the question to CAPWAP is: > > > > >>>> > > > > >>>>Should we make it a requirement in CAPWAP protocol to achieve > > > > >>>>interoperability between different architectures? > > > > >>>> > > > > >>>>It is definitely doable, but I'm not sure if that is the > > > > >>> > > > > >>right thing > > > > >> > > > > >>>>to do.. > > > > >>>> > > > > >>>>Victor > > > > >>>> > > > > >>>>-----Original Message----- > > > > >>>>From: capwap-admin@frascone.com > > > > >>> > > > > >>[mailto:capwap-admin@frascone.com] On > > > > >> > > > > >>>>Behalf Of Bob O'Hara > > > > >>>>Sent: Thursday, August 05, 2004 11:43 AM > > > > >>>>To: capwap@frascone.com > > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > > >>> > > > > >>time... - take > > > > >> > > > > >>>>2 > > > > >>>> > > > > >>>>I think that interoperability will depend on two things. > > > > >>>>First, it will > > > > >>>>depend on how we define the protocol and the flexibility > > > > >>> > > > > >>for supported > > > > >> > > > > >> > > > > >>>>architectures it incorporates. Second, it will depend on what > > > > > >>>>manufacturers implement, i.e., the flexibility they build > > > > >>> > > > > >>into their > > > > >> > > > > >>>>products. > > > > >>>> > > > > >>>>I believe that it is possible to design the protocol for > > > > >>> > > > > >>the required > > > > >> > > > > >>>>flexibility. I know it is possible to implement a > > > > product with the > > > > >>>>required flexibility. > > > > >>>> > > > > >>>>-Bob O'Hara > > > > >>>> > > > > >>>> > > > > >>>>-----Original Message----- > > > > >>>>From: capwap-admin@frascone.com > > > > >>> > > > > >>[mailto:capwap-admin@frascone.com] On > > > > >> > > > > >>>>Behalf Of Abhijit Choudhury > > > > >>>>Sent: Thursday, August 05, 2004 11:32 AM > > > > >>>>To: James Kempf; Shehzad Merchant; capwap@frascone.com > > > > >>>>Cc: bwijnen@lucent.com; mmani@avaya.com; > > > david.kessens@nokia.com; > > > > >>>>Dorothy.Gellert@nokia.com; Inderpreet Singh > > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > > >>> > > > > >>time... - take > > > > >> > > > > >>>>2 > > > > >>>> > > > > >>>> > > > > >>>>It may be possible to achieve such interoperability within the > > > > > >>>>split-MAC family or within the local-MAC family. It > > > > would sbe very > > > > >>>>hard to achieve that between local and split MAC families. > > > > >>>> > > > > >>>>For example, if vendor X's WTP terminates 802.11 ctrl/mgmt > > > > >>> > > > > >>packets and > > > > >> > > > > >>> > > > > >>>>vendor Y's AC expects the 802.11 mgmt packets to come to > > > > >>> > > > > >>it, there's > > > > >> > > > > >>>>no way you can be interoperable. > > > > >>>> > > > > >>>>Or are we planning to specify ONE architecture ? > > > > >>>>The last thing IETF should do is mandate an implementation. > > > > >>>> > > > > >>>>I think a modest and reasonable goal is to come up with a > > > > protocol > > > > >>>>that allows sufficient flexbility so that vendors with > splitMAC > > > > >>>>architectures can transfer most of the information they > > > > care about > > > > >>>>between the WTP and AC. > > > > >>>> > > > > >>>>Just my $0.02 ... > > > > >>>> > > > > >>>> > > > > >>>>Abhijit Choudhury > > > > >>>> > > > > >>>> > > > > >>>>-----Original Message----- > > > > >>>>From: capwap-admin@frascone.com > > > > >>> > > > > >>[mailto:capwap-admin@frascone.com] On > > > > >> > > > > >>>>Behalf Of James Kempf > > > > >>>>Sent: Wednesday, August 04, 2004 3:29 PM > > > > >>>>To: Shehzad Merchant; capwap@frascone.com > > > > >>>>Cc: bwijnen@lucent.com; mmani@avaya.com; > > > david.kessens@nokia.com; > > > > >>>>Dorothy.Gellert@nokia.com; Inderpreet Singh > > > > >>>>Subject: Re: [Capwap] So many architectures, so little > > > > >>> > > > > >>time... - take > > > > >> > > > > >>>>2 > > > > >>>> > > > > >>>> > > > > >>>>As a potential customer, let me put it concretely. I want > > > > >>> > > > > >>to be able > > > > >> > > > > >>>>to buy my access points from Vendor X and my switch from > > > > >>> > > > > >>Vendor Y and > > > > >> > > > > >>>>plug the two together and have them work without any > > > > configuration. > > > > >>>>Also, I'd like to be able to buy switches from Vendor Y and > > > > >>> > > > > >>Vendor Z > > > > >> > > > > >>>>and be able to plug them into my network at various > > > > places and have > > > > >>>>them interoperate. > > > > >>>> > > > > >>>> jak > > > > >>>> > > > > >>>> > > > > >>>>----- Original Message ----- > > > > >>>>From: "Shehzad Merchant" > > > > >>>>To: > > > > >>>>Cc: ; ; > > > > >>>>; ; > > > > "Inderpreet > > > > >>>>Singh" > > > > >>>> > > > > >>>>Sent: Wednesday, August 04, 2004 3:19 PM > > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > > >>> > > > > >>time... - take > > > > >> > > > > >>>>2 > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>I think the implementation variations even with the > > > > split MAC may > > > > >>>>>cover a broad spectrum. As such its important to clearly > > > > >>>> > > > > >>articulate > > > > >> > > > > >>>>>what aspects > > > > >>>> > > > > >>>>of > > > > >>>> > > > > >>>> > > > > >>>>>interoperability we are targetting. Is it truly just > > > > >>>>>control/management or is it interoperability between > disparate > > > > >>>>>implementations of the split MAC, i.e. mix and match > > > > >>>> > > > > >>>>operation of WTP > > > > >>>> > > > > >>>> > > > > >>>>>and ACs of all variants within this category. > > > > >>>>> > > > > >>>>>I suspect for the latter we may have to arrive at some > > > > >>>> > > > > >>consensus on > > > > >> > > > > >>>>>what particular implementations we are targeting > > > > >>>> > > > > >>>>interoperability for. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>If so, ultimately this problem statement could become > > > > part of the > > > > >>>>>charter. > > > > >>>>> > > > > >>>>>-Shehzad > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>>-----Original Message----- > > > > >>>>>From: capwap-admin@frascone.com > > > > >>>> > > > > >>>>[mailto:capwap-admin@frascone.com] On Behalf > > > > >>>> > > > > >>>> > > > > >>>>>Of Dorothy.Gellert@nokia.com > > > > >>>>>Sent: Wednesday, August 04, 2004 11:53 AM > > > > >>>>>To: isingh@chantrynetworks.com; capwap@frascone.com > > > > >>>>>Cc: bwijnen@lucent.com; mmani@avaya.com; > > > david.kessens@nokia.com > > > > >>>>>Subject: RE: [Capwap] So many architectures, so little > > > > >>>> > > > > >>>>time... - take > > > > >>>> > > > > >>>> > > > > >>>>>2 > > > > >>>>> > > > > >>>>>I believe this is the consensus, to scope the charter to > > > > >>>> > > > > >>>>Centralized > > > > >>>> > > > > >>>> > > > > >>>>>Architecture and LocalMAC and Split MAC. > > > > >>>>> > > > > >>>>>I'll update the charter with this change after the CAPWAP > > > > >>>> > > > > >>>>WG Mtg. If > > > > >>>> > > > > >>>> > > > > >>>>>there is resistance to this idea, please post to the list. > > > > >>>>> > > > > >>>>>Regards > > > > >>>>>Dorothy > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>>>-----Original Message----- > > > > >>>>>>From: capwap-admin@frascone.com > > > > >>>>> > > > > >>>>[mailto:capwap-admin@frascone.com]On > > > > >>>> > > > > >>>> > > > > >>>>>>Behalf Of ext Inderpreet Singh > > > > >>>>>>Sent: Tuesday, August 03, 2004 9:40 PM > > > > >>>>>>To: capwap@frascone.com > > > > >>>>>>Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David > > > > >>>>>>(Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > > > > >>>>>>Subject: RE: [Capwap] So many architectures, so little > > > > time... - > > > > >>>>>>take 2 > > > > >>>>>> > > > > >>>>>> > > > > >>>>>>The issue(s) at hand and my opinions are: > > > > >>>>>> > > > > >>>>>>1. Do we explicitly state in the re-charter which > > > > >>>>> > > > > >>>>architecture the > > > > >>>> > > > > >>>> > > > > >>>>>>WG should consider? I think yes. I propose Centralized > > > > >>>>> > > > > >>>>architecture > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>>only. Autonomous and Distributed should be out of scope > > > > >>>>> > > > > >>>>based on the > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>>same reasons as per prior postings. > > > > >>>>>> > > > > >>>>>>2. Within Centralized do we focus on all three sub > > > > >>>>> > > > > >>>>architectures or > > > > >>>> > > > > >>>> > > > > >>>>>>a subset? Remote MAC should be excluded because if I am not > > > > >>>>>>mistaken, the connectivity constraint between the WTP and > > > > >>>>> > > > > >>>>the AC is > > > > >>>> > > > > >>>> > > > > >>>>>>"direct connect". > > > > >>>>>>That being the case and that no IP layer is involved, > > > it doesn't > > > > >>>>> > > > > >>>>seem > > > > >>>> > > > > >>>> > > > > >>>>>>clear what kind of protocol would help with > > > > interoperability. I am > > > > >>>>> > > > > >>>>>>concerned about the impact, dependencies and > > > > interaction with the > > > > >>>>>>recently constituted IEEE Study group on AP > > > > >>>>> > > > > >>>>functionality on the > > > > >>>> > > > > >>>> > > > > >>>>>>Split MAC architectures. Furthermore, there are some > > > > >>>>> > > > > >>>>pretty drastic > > > > >>>> > > > > >>>> > > > > >>>>>>differences on how the vendors have chosen to split the > > > > >>>>> > > > > >>>>mac. Those > > > > >>>> > > > > >>>> > > > > >>>>>>differences will need to be worked out before designing a > > > > >>>>> > > > > >>>>protocol. > > > > >>>> > > > > >>>> > > > > >>>>>>So, if the low hanging fruit strategy (as James > > > suggested) for > > > > >>>>>>protocol development and progress is the way to go, > > > > then I think > > > > >>>>>>prioritizing on a protocol for Local MAC is a no brainer. > > > > >>>>> > > > > >>>>So as far > > > > >>>> > > > > >>>> > > > > >>>>>>as focus, I feel we should do Local and Split and in > > > that order. > > > > >>>>>> > > > > >>>>>>3. This is not a re-chartering issue but is a > > > response to Pat's > > > > >>>>>>suggestion that a protocol that just sends the 802.11 > > > > MAC frames > > > > >>>>> > > > > >>>>>>from the AP to the AC would work. I think possibly, yes. > > > > >>>>> > > > > >>>> > > > > >>>>But again > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>>the complications of splitting the MAC in an > > > > >>>>> > > > > >>>>interoperable way will > > > > >>>> > > > > >>>> > > > > >>>>>>be an issue. Also, you may note in the draft to which > > > > >>>>> > > > > >>>>you refer, we > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>>included a capabilities exchange phase. I had thought of > > > > >>>>> > > > > >>>>including > > > > >>>> > > > > >>>> > > > > >>>>>>in the capability exchange such things as "AP supports > > > > Local MAC" > > > > >>>>>>and "AP supports Split MAC", but didn't put it in because > the > > > > >>>>>>Taxonomy work was still in progress. Now that it is > > > > pretty much > > > > >>>>>>done we could surely include that. But again...let's > > > recharter > > > > >>>>>>first. > > > > >>>>>> > > > > >>>>>>Thanks. Do people agree with 1 & 2? > > > > >>>>>> > > > > >>>>>>--- > > > > >>>>>>Inderpreet Singh > > > > >>>>>>Chantry Networks > > > > >>>>>>isingh@chantrynetworks.com > > > > >>>>>>Cell: 416-831-3705 > > > > >>>>>> > > > > >>>>>>-----Original Message----- > > > > >>>>>>From: capwap-admin@frascone.com > > > > >>>>> > > > > >>>>[mailto:capwap-admin@frascone.com] > > > > >>>> > > > > >>>> > > > > >>>>>>On Behalf Of Pat R. Calhoun > > > > >>>>>>Sent: Tuesday, August 03, 2004 6:04 PM > > > > >>>>>>To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com; > > > > >>>>>>capwap@frascone.com > > > > >>>>>>Cc: bwijnen@lucent.com; mmani@avaya.com; > > > david.kessens@nokia.com > > > > >>>>>>Subject: [Capwap] So many architectures, so little > > > > >>>>> > > > > >>>>time... - take 2 > > > > >>>> > > > > >>>> > > > > >>>>>>After reading Lily's response to Jim, I realize that I > > > > >>>>> > > > > >>>>fell down the > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>>same trap. Local MAC is also a centralized approach, > > > and so my > > > > >>>>>>previous response was not complete. I believe the real > > > > >>>>> > > > > >>>>question, in > > > > >>>> > > > > >>>> > > > > >>>>>>my mind, is whether we need to address either the Local > > > > >>>>> > > > > >>>>or the Split > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>>MAC architecture. > > > > >>>>>> > > > > >>>>>>Just looking at the Architecture Consideration tables (7 and > > > > >>>>>>10) in the > > > > >>>>>>specification, the > > > > >>>>>>main difference (at a high level) between both approaches > > > > >>>>> > > > > >>>>is where > > > > >>>> > > > > >>>> > > > > >>>>>>the 802.11 management terminates. For Local MAC, it's > > > > in the WTP, > > > > >>>>>>while for SPlit MAC, it's in the AC. > > > > >>>>>> > > > > >>>>>>However, looking at table 8, most Local MAC approaches > > > > share STA > > > > >>>>>>state between both the WTP and the AC. So clearly > > > there is some > > > > >>>>>>signalling protocol between both the WTP and the AC. > > > > >>>>>> > > > > >>>>>>Looking at one example of a Local MAC protocol (see > > > > >>>>>> > > > > >>>>> > > > > > > > > >>>http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > > > > >>> > > > > >>> > > > > >>>>>there is a protocol message > > > > >>>>>that corresponds for every 802.11 MAC management event. So > > > > >>>> > > > > >>when a STA > > > > >> > > > > >> > > > > >>>>>associates, the AP breaks the message apart and creates an > new > > > > >>>>>protocol PDU, which contains components found in the > > > association > > > > >>>>>request. I suspect that most Local MAC approaches do > > > > >>>> > > > > >>something very > > > > >> > > > > >>>>>similar. > > > > >>>>> > > > > >>>>>So if a protocol simply tunnels the 802.11 MAC management > > > > >>>> > > > > >>frames from > > > > >> > > > > >> > > > > >>>>>the WTP to the AC, it allows supports both approaches. For > > > > >>>> > > > > >>Local MAC, > > > > >> > > > > >> > > > > >>>>>they get what they want via the 802.11 frame, and this > > > > also works > > > > >>>>>fine for Split MAC, which needs access to the MAC > > > > >>>> > > > > >>management frame. > > > > >> > > > > >>>>>What would be required in such a protocol is a way for > > > the AP to > > > > >>>>>communicate whether it will be providing very specific > > > > functions - > > > > >>>>>basically a capabilities negotiation approach. > > > > >>>>> > > > > >>>>>So I do believe that there is a way to address both > > > > architectures > > > > >>>>>using a single protocol. > > > > >>>>> > > > > >>>>>Thoughts? > > > > >>>>> > > > > >>>>>PatC > > > > >>>>> > > > > >>>>>_______________________________________________ > > > > >>>>>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 > > > >>>_______________________________________________ > > > >>>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 > > > >>>_______________________________________________ > > > >>>Capwap mailing list > > > >>>Capwap@frascone.com > > > >>>http://mail.frascone.com/mailman/listinfo/capwap > > > >> > > > >> > > > >>-- > > > >>Shankar Narayanaswamy, Ph.D. > > > >>wireless@shankar.org Mobile: +1 650-387-4593 > > > >>http://www.shankar.org E-Fax: +1 253-498-8372 > > > >> > > > >>_______________________________________________ > > > >>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 > > > > > > > > > > > > > > > > > -- > > > Shankar Narayanaswamy, Ph.D. > > > wireless@shankar.org Mobile: +1 650-387-4593 > > > http://www.shankar.org E-Fax: +1 253-498-8372 > > > > > > _______________________________________________ > > > 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 > _______________________________________________ > 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 Aug 13 18:15:20 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22167 for ; Fri, 13 Aug 2004 18:15:16 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EFAA620A6C; Fri, 13 Aug 2004 18:00:25 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 60F1920B3B; Fri, 13 Aug 2004 18:00:22 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 231C020291 for ; Fri, 13 Aug 2004 17:59:06 -0400 (EDT) Received: from mail3.extremenetworks.com (sc-f100-01.extremenetworks.com [63.251.106.30]) by mail.frascone.com (Postfix) with ESMTP id C97BF20AAF for ; Fri, 13 Aug 2004 17:59:03 -0400 (EDT) Received: by mail3 with Internet Mail Service (5.5.2657.72) id ; Fri, 13 Aug 2004 15:12:19 -0700 Message-ID: <1B8A2DD33C49824F8D9021678C127213026B0D94@sc-msexch-04.extremenetworks.com> From: Shehzad Merchant To: "Bob O'Hara" , capwap@frascone.com Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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: Fri, 13 Aug 2004 15:13:48 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I do agree that the data forwarding protocol work can have some degree of independence from the initial control/provisioning work. However, would the data protocol convergence work come from the CAPWAP group? I think it should, in order to have a coheive and truly interoperable solution. -S -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Bob O'Hara Sent: Friday, August 13, 2004 12:59 PM To: capwap@frascone.com Subject: RE: [Capwap] Re: Data plane and control plane separation in SplitMAC I agree that for a complete solution, we cannot ignore the need for a data forwarding protocol. But for control and provisioning, not for operation, that problem can be separated from the initial protocol design. What we might consider in the protocol design is negotiating the data forwarding protocol. I do not favor negotiation of that protocol as the final solution. It leads to too many options in a multivendor situation and will likely provide less interoperability rather than more. When the question arises, I would prefer we had the hard discussions to arrive at a single protocol to be used for data forwarding. -Bob -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Partha Narasimhan Sent: Thursday, August 12, 2004 1:19 PM To: Lily L Yang Cc: Wijnen, Bert (Bert); Shankar Narayanaswamy; Dorothy.Gellert@nokia.com; capwap@frascone.com Subject: RE: [Capwap] Re: Data plane and control plane separation in SplitMAC The set of AP functions is split across the WTP and the AC in the split-MAC and, arguably to a lesser extent, in the local MAC architectures. As a result, the AP, in these architectures, is no longer a physical entity, but one that potentially spans a L3 boundary. The handling of data frames (and some mgmt frames in the split-MAC arch) within an AP could involve transferring it over a L3 network from the WTP to the AC or vice-versa. If these two end-points are from multiple different vendors, then there needs to be an agreement on the mode of this transfer. Hence, we cannot ignore this problem in defining a CAPWAP protocol. Thanks partha On Thu, 2004-08-12 at 10:42, Yang, Lily L wrote: > To examine our options of architecture assumptions, let me first put our > my definition of data plane and control plane just to make sure we start > from the same page: > > To me, 802.11 data plane means the dath path travelled by the native > 802.11 data frames while 802.11 control plane means the data path > between 802.11 STA and the 802.11-awared control end point. > > For both Local and Split MAC, that 802.11-awared control point is AC. So > both architecture has the same control path: STA->WTP->AC. The > difference is how that control messages are implemented between WTP and > AC: Split MAC simply tunneled the 802.11 management frames, while Local > MAC translated them into some other non-802.11 forms. Another (implied) > difference is that Split MAC largely relies on the AC to respond to > those management frames from STA, while Local MAC relies on WTP to > respond, but allow AC to be informed of such events as well. So the > timing constraint may be more relaxed for local MAC. > > The question is on the data path. Here is my understanding so far: > In Local MAC, the data path is between STA and WTP. From WTP, it can be > switched or routed locally, entirely bypassing AC. For Split MAC, My > impression has been that the data path is between STA and WTP and AC, > because it seems that Split MAC vendors tunnel ALL 802.11 data back to > AC, even though I don't see why it has to be that way. Just from the > recent discussion, some have hinted that even Split MAC can allow data > path terminate at WTP and be "locally" switched without involving AC. Is > this true? Can anyone confirm more explicitly and elaborate this for me? > > > To summarize: > Common control path: STA->WTP->AC. (but control messages between > WTP<->AC are done diffrently) Local MAC data path: STA->WTP. > Split MAC data path: STA->WTP->AC or STA->WTP (This needs to be > clarified). > > My hunch is that CAPWAP protocol would have to allow the flexibility in > datapath, for either architecture (Split or Local). So in that case, it > doesn't really matter if it is Split or Local, it should allow datapath > to be configurable any way. In that sense, I agree with what Shankar was > saying here. This seems also suggest that YES, we can cleanly separate > data plane and control plane here. But that doesn't mean any discussion > around data plane is out of scope -- because guess what? Why do we need > the control plane at the first place? To control and configure the data > plane! > > So understanding what data plane needs would drive our discussion for > the control plane and CAPWAP. > > > -----Original Message----- > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Wijnen, Bert (Bert) > > Sent: Thursday, August 12, 2004 2:30 AM > > To: Shankar Narayanaswamy; Dorothy.Gellert@nokia.com > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] Re: Data plane and control plane separation in > > Split MAC > > > > > -----Original Message----- > > > From: Shankar Narayanaswamy [mailto:wireless@shankar.org] > > > Sent: donderdag 12 augustus 2004 05:13 > > > To: Dorothy.Gellert@nokia.com > > > Cc: capwap@frascone.com > > > Subject: [Capwap] Re: Data plane and control plane > > separation in Split > > > MAC > > > > > > > > > The parameters by which the data plane communicates such as > > > authentication/security info, destination switch (if any) for data > > > frames, etc, are communicated by the control plane. Hence > > the need for > > > some architectural assumptions regarding the data plane even if the > > > focus is on the control plane. > > > > > > Or at least a decision on the data plane architectures to be > > > supported. > > > > > So... to me that sounds that we may potentially do an IMPLIED > > agreement on the architecture for data plane, based on the > > capabilities we define in the standards track control and > > provisioning protocol. > > > > That would be fine with me. But we should NOT get bogged down in > > that data plane stuff, or at least that to me seems to be the wrong > > focus. > > > > Bert > > > -s > > > > > > Dorothy.Gellert@nokia.com wrote: > > > > Good point. Can we have the volunteers that submitted > > > architectures for the taxonomy draft weigh in on this issue? > > > > > > > > Also another point to consider is that we don't have to > > > implement *every* AP function in the first release of the CAPWAP > > > protocol. One of our charter goals is to start with > > > the minimal set of functionality needed to provide control. > > > We have a "desirable" category where we can put objectives > > that can be > > > met with a later release or extension. > > > > > > > > Dorothy > > > > > > > >>-----Original Message----- > > > >>From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com]On > > > >>Behalf Of ext Yang, Lily L > > > >>Sent: Tuesday, August 10, 2004 6:13 PM > > > >>To: Sudhanshu Jain; Shehzad Merchant; Shankar > > Narayanaswamy; Abhijit > > > >>Choudhury > > > >>Cc: capwap@frascone.com > > > >>Subject: RE: [Capwap] So many architectures, so little time... - > > > >>take 2 > > > >> > > > >> > > > >>The question in my mind is: Can data plane and control plane be > > > >>cleanly separated for Split MAC? I know it is feasible for Local > > > MAC, but not > > > >>sure about Split MAC. > > > >>Any insight? > > > >> > > > >>-----Original Message----- > > > >>From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On > > > >>Behalf Of Sudhanshu Jain > > > >>Sent: Tuesday, August 10, 2004 11:55 AM > > > >>To: Shehzad Merchant; Shankar Narayanaswamy; Abhijit Choudhury > > > >>Cc: capwap@frascone.com > > > >>Subject: RE: [Capwap] So many architectures, so little time... - > > > >>take 2 > > > >> > > > >>I fully agree with Shehzad. We need to separate the > > control and data > > > >>plane. Control plane should provide the framework to use one of > > > >>several tunneling protocol. > > > >> > > > >>On data plane, if we need to define a new layer2/layer3 level > > > >>tunneling protocol, it should be separate work from > > control protocol > > > >>work. > > > >> > > > >>-Suds > > > >> > > > >> > > > >>-----Original Message----- > > > >>From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On > > > >>Behalf Of Shehzad Merchant > > > >>Sent: Tuesday, August 10, 2004 11:13 AM > > > >>To: Shankar Narayanaswamy; Abhijit Choudhury > > > >>Cc: capwap@frascone.com > > > >>Subject: RE: [Capwap] So many architectures, so little time... - > > > >>take 2 > > > >> > > > >>Additionally, for data tunneling one needs a lightweight > > mechanism > > > >>that may not necessarily have the same requirements as that for > > > >>control and management. For example, one would want to limit the > > > >>tunneling and processing overhead on data packets to a minimum. > > > >>Control and management may be more tolerant of > > > >>tunneling/security/etc. overhead. > > > >>Besides, there are > > > >>plenty of standards in place for data tunneling. We may > > > potentially be > > > >>able > > > >>to leverage off that work itself without having to invent > > > yet another > > > >>tunneling mechanism for data. > > > >> > > > >>-S > > > >> > > > >> > > > >>-----Original Message----- > > > >>From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On > > > >>Behalf > > > >>Of Shankar Narayanaswamy > > > >>Sent: Tuesday, August 10, 2004 10:30 AM > > > >>To: Abhijit Choudhury > > > >>Cc: capwap@frascone.com > > > >>Subject: Re: [Capwap] So many architectures, so little time... - > > > >>take 2 > > > >> > > > >>On the first point: not necessarily. If data packets are > > > encapsulated > > > >>802.11 data frames, then there is no need to protect them > > > on the wire > > > >>any > > > >>more than they were encrypted over the air. > > > >> > > > >>But control and management packets will need protection > > > over the wired > > > >>network and therefore possibly a different tunneling protocol. > > > >> > > > >>On the second point (standard way of packet exchange): yes! > > > >> > > > >>-s > > > >> > > > >>Abhijit Choudhury wrote: > > > >> > > > >>>The same tunneling protocol that moves control and > > > >> > > > >>management packets > > > >> > > > >>>from the WTP to the AC should be used to tunnel data > > > >> > > > >>packets as well. > > > >> > > > >> > > > >>>We would specify message exchanges to do control, > > provisioning and > > > >>>capability advertisement between WTPs and the AC. But > > all of this > > > >>>would be within the unified CAPWAP protocol that moves > > all packets > > > >>>including data between the WTP and AC. Vendors currently > > > >> > > > >>use LWAPP, > > > >> > > > >>>GRE, IP and some proprietary encapsulations to achieve > > this. This > > > >>>group would come up with a "standard" way of doing this exchange. > > > >>> > > > >>>At least that was my understanding.... > > > >>> > > > >>>Regards, > > > >>>Abhijit > > > >>> > > > >>>-----Original Mssage----- > > > >>>From: capwap-admin@frascone.com > > > >> > > > >>[mailto:capwap-admin@frascone.com] On > > > >> > > > >>>Behalf Of Wijnen, Bert (Bert) > > > >>>Sent: Monday, August 09, 2004 6:14 AM > > > >>>To: 'Yang, Lily L'; Burbank, Jack L.; Victor Lin; Bob O'Hara; > > > >>>capwap@frascone.com > > > >>>Subject: RE: [Capwap] So many architectures, so little > > > >> > > > >>time... - take > > > >> > > > >>>2 > > > >>> > > > >>> > > > >>>Not sure who is confused... probably me... > > > >>> > > > >>>My understanding was/is that IF we do re-charter for CAPWAP > > > >> > > > >>protocol > > > >> > > > >>>work, that it is then a NM protocol for "Control and > > > >> > > > >>Provisioning" and > > > >> > > > >> > > > >>>not any of the related stuff that moves the data from WTP to AC. > > > >>> > > > >>>Is everybody in agreement with that understanding. > > > >>> > > > >>>Thanks, > > > >>>Bert > > > >>> > > > >>> > > > >>> > > > >>>>-----Original Message----- > > > >>>>From: Yang, Lily L [mailto:lily.l.yang@intel.com] > > > >>>>Sent: maandag 9 augustus 2004 08:14 > > > >>>>To: Burbank, Jack L.; Victor Lin ; Bob O'Hara ; > > > capwap@frascone.com > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>> > > > >>>>I think setting the re-charter scope to develop a single > > > >>> > > > >>protocol that > > > >> > > > >>> > > > >>>>allows interoperability between Local and Split MAC is a > > > reasonable > > > >>>>tradeoff: > > > >>>>We exclude remote MAC because the constraint it imposes is very > > > >>>>different from the rest and the benefit of including it is very > > > >>>>little. But Local and Split MAC are reasonably close and > > > hence the > > > >>>>effort may be incremental only. > > > >>>>As many people noted, as of today, there is no single clear > > > >>> > > > >>definition > > > >> > > > >> > > > >>>>of what "Local MAC" and "Split MAC" really means yet. Each > > > >>> > > > >>vendor has > > > >> > > > >>>>different definitions and some debate needs to happen so > > > >>> > > > >>that the WG > > > >> > > > >>>>can reach consensus on what exactly that means, and > > what kinds of > > > >>>>flexibility we want to retain within each class of > > > >>> > > > >>architecture, and > > > >> > > > >>>>what kind of differences we can to resolve and agree up > > > front. That > > > >>>>should also be part of the work items for the new WG -- > > > >>> > > > >>such agreement > > > >> > > > >> > > > >>>>on the details for each architecture must be documented > > > >>> > > > >>somewhere, if > > > >> > > > >>>>not separately, then as part of the Protocol document. > > > >>>> > > > >>>>-----Original Message----- > > > >>>>From: capwap-admin@frascone.com > > > >>> > > > >>[mailto:capwap-admin@frascone.com] On > > > >> > > > >>>>Behalf Of Burbank, Jack L. > > > >>>>Sent: Thursday, August 05, 2004 12:14 PM > > > >>>>To: 'Victor Lin '; 'Bob O'Hara '; 'capwap@frascone.com ' > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>>I think that interoperability between different > > > >>> > > > >>architectures should > > > >> > > > >>>>be a requirement, if not the key requirement. As was mentioned > > > >>>>yesterday, a goal of the IEEE is that they maintain > > > flexibility in > > > >>>>terms of how products and architectures are implemented. I > > > >>> > > > >>think we > > > >> > > > >>>>shouldn't do anything that is contrary to that goal (or > > > at least we > > > >>>>should minimize the impact). I think that the goal of > > > >>> > > > >>CAPWAP should > > > >> > > > >>>>be to retain this type of flexibility by designing a > > > >>> > > > >>protocol that can > > > >> > > > >> > > > >>>>maintain this implementation flexibility but enable > > > >>> > > > >>interoperability > > > >> > > > >>>>between the various architecture implementations (that > > > after all is > > > >>>>the key problem with the deployment of these various > > > >>> > > > >>architectures - > > > >> > > > >>>>lack of interoperability). IMO, if we don't design for > > > >>>>interoperability between the basic architecture types, it > > > >>> > > > >>is debatable > > > >> > > > >> > > > >>>>if something useful would have been accomplished. > > > >>>> > > > >>>>Jack Burbank > > > >>>> > > > >>>>-----Original Message----- > > > >>>>From: capwap-admin@frascone.com > > > >>>>To: Bob O'Hara; capwap@frascone.com > > > >>>>Sent: 8/5/2004 2:46 PM > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>>I agree that we can design a protocol and implement the > > > >>> > > > >>product that > > > >> > > > >>>>works all architectures. I think the question to CAPWAP is: > > > >>>> > > > >>>>Should we make it a requirement in CAPWAP protocol to achieve > > > >>>>interoperability between different architectures? > > > >>>> > > > >>>>It is definitely doable, but I'm not sure if that is the > > > >>> > > > >>right thing > > > >> > > > >>>>to do.. > > > >>>> > > > >>>>Victor > > > >>>> > > > >>>>-----Original Message----- > > > >>>>From: capwap-admin@frascone.com > > > >>> > > > >>[mailto:capwap-admin@frascone.com] On > > > >> > > > >>>>Behalf Of Bob O'Hara > > > >>>>Sent: Thursday, August 05, 2004 11:43 AM > > > >>>>To: capwap@frascone.com > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>>I think that interoperability will depend on two things. > > > >>>>First, it will > > > >>>>depend on how we define the protocol and the flexibility > > > >>> > > > >>for supported > > > >> > > > >> > > > >>>>architectures it incorporates. Second, it will depend on what > > > >>>>manufacturers implement, i.e., the flexibility they build > > > >>> > > > >>into their > > > >> > > > >>>>products. > > > >>>> > > > >>>>I believe that it is possible to design the protocol for > > > >>> > > > >>the required > > > >> > > > >>>>flexibility. I know it is possible to implement a > > > product with the > > > >>>>required flexibility. > > > >>>> > > > >>>>-Bob O'Hara > > > >>>> > > > >>>> > > > >>>>-----Original Message----- > > > >>>>From: capwap-admin@frascone.com > > > >>> > > > >>[mailto:capwap-admin@frascone.com] On > > > >> > > > >>>>Behalf Of Abhijit Choudhury > > > >>>>Sent: Thursday, August 05, 2004 11:32 AM > > > >>>>To: James Kempf; Shehzad Merchant; capwap@frascone.com > > > >>>>Cc: bwijnen@lucent.com; mmani@avaya.com; > > david.kessens@nokia.com; > > > >>>>Dorothy.Gellert@nokia.com; Inderpreet Singh > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>> > > > >>>>It may be possible to achieve such interoperability within the > > > >>>>split-MAC family or within the local-MAC family. It > > > would sbe very > > > >>>>hard to achieve that between local and split MAC families. > > > >>>> > > > >>>>For example, if vendor X's WTP terminates 802.11 ctrl/mgmt > > > >>> > > > >>packets and > > > >> > > > >>> > > > >>>>vendor Y's AC expects the 802.11 mgmt packets to come to > > > >>> > > > >>it, there's > > > >> > > > >>>>no way you can be interoperable. > > > >>>> > > > >>>>Or are we planning to specify ONE architecture ? > > > >>>>The last thing IETF should do is mandate an implementation. > > > >>>> > > > >>>>I think a modest and reasonable goal is to come up with a > > > protocol > > > >>>>that allows sufficient flexbility so that vendors with splitMAC > > > >>>>architectures can transfer most of the information they > > > care about > > > >>>>between the WTP and AC. > > > >>>> > > > >>>>Just my $0.02 ... > > > >>>> > > > >>>> > > > >>>>Abhijit Choudhury > > > >>>> > > > >>>> > > > >>>>-----Original Message----- > > > >>>>From: capwap-admin@frascone.com > > > >>> > > > >>[mailto:capwap-admin@frascone.com] On > > > >> > > > >>>>Behalf Of James Kempf > > > >>>>Sent: Wednesday, August 04, 2004 3:29 PM > > > >>>>To: Shehzad Merchant; capwap@frascone.com > > > >>>>Cc: bwijnen@lucent.com; mmani@avaya.com; > > david.kessens@nokia.com; > > > >>>>Dorothy.Gellert@nokia.com; Inderpreet Singh > > > >>>>Subject: Re: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>> > > > >>>>As a potential customer, let me put it concretely. I want > > > >>> > > > >>to be able > > > >> > > > >>>>to buy my access points from Vendor X and my switch from > > > >>> > > > >>Vendor Y and > > > >> > > > >>>>plug the two together and have them work without any > > > configuration. > > > >>>>Also, I'd like to be able to buy switches from Vendor Y and > > > >>> > > > >>Vendor Z > > > >> > > > >>>>and be able to plug them into my network at various > > > places and have > > > >>>>them interoperate. > > > >>>> > > > >>>> jak > > > >>>> > > > >>>> > > > >>>>----- Original Message ----- > > > >>>>From: "Shehzad Merchant" > > > >>>>To: > > > >>>>Cc: ; ; > > > >>>>; ; > > > "Inderpreet > > > >>>>Singh" > > > >>>> > > > >>>>Sent: Wednesday, August 04, 2004 3:19 PM > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > >>> > > > >>time... - take > > > >> > > > >>>>2 > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>>>I think the implementation variations even with the > > > split MAC may > > > >>>>>cover a broad spectrum. As such its important to clearly > > > >>>> > > > >>articulate > > > >> > > > >>>>>what aspects > > > >>>> > > > >>>>of > > > >>>> > > > >>>> > > > >>>>>interoperability we are targetting. Is it truly just > > > >>>>>control/management or is it interoperability between disparate > > > >>>>>implementations of the split MAC, i.e. mix and match > > > >>>> > > > >>>>operation of WTP > > > >>>> > > > >>>> > > > >>>>>and ACs of all variants within this category. > > > >>>>> > > > >>>>>I suspect for the latter we may have to arrive at some > > > >>>> > > > >>consensus on > > > >> > > > >>>>>what particular implementations we are targeting > > > >>>> > > > >>>>interoperability for. > > > >>>> > > > >>>> > > > >>>> > > > >>>>>If so, ultimately this problem statement could become > > > part of the > > > >>>>>charter. > > > >>>>> > > > >>>>>-Shehzad > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>>-----Original Message----- > > > >>>>>From: capwap-admin@frascone.com > > > >>>> > > > >>>>[mailto:capwap-admin@frascone.com] On Behalf > > > >>>> > > > >>>> > > > >>>>>Of Dorothy.Gellert@nokia.com > > > >>>>>Sent: Wednesday, August 04, 2004 11:53 AM > > > >>>>>To: isingh@chantrynetworks.com; capwap@frascone.com > > > >>>>>Cc: bwijnen@lucent.com; mmani@avaya.com; > > david.kessens@nokia.com > > > >>>>>Subject: RE: [Capwap] So many architectures, so little > > > >>>> > > > >>>>time... - take > > > >>>> > > > >>>> > > > >>>>>2 > > > >>>>> > > > >>>>>I believe this is the consensus, to scope the charter to > > > >>>> > > > >>>>Centralized > > > >>>> > > > >>>> > > > >>>>>Architecture and LocalMAC and Split MAC. > > > >>>>> > > > >>>>>I'll update the charter with this change after the CAPWAP > > > >>>> > > > >>>>WG Mtg. If > > > >>>> > > > >>>> > > > >>>>>there is resistance to this idea, please post to the list. > > > >>>>> > > > >>>>>Regards > > > >>>>>Dorothy > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>>>-----Original Message----- > > > >>>>>>From: capwap-admin@frascone.com > > > >>>>> > > > >>>>[mailto:capwap-admin@frascone.com]On > > > >>>> > > > >>>> > > > >>>>>>Behalf Of ext Inderpreet Singh > > > >>>>>>Sent: Tuesday, August 03, 2004 9:40 PM > > > >>>>>>To: capwap@frascone.com > > > >>>>>>Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David > > > >>>>>>(Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > > > >>>>>>Subject: RE: [Capwap] So many architectures, so little > > > time... - > > > >>>>>>take 2 > > > >>>>>> > > > >>>>>> > > > >>>>>>The issue(s) at hand and my opinions are: > > > >>>>>> > > > >>>>>>1. Do we explicitly state in the re-charter which > > > >>>>> > > > >>>>architecture the > > > >>>> > > > >>>> > > > >>>>>>WG should consider? I think yes. I propose Centralized > > > >>>>> > > > >>>>architecture > > > >>>> > > > >>>> > > > >>>> > > > >>>>>>only. Autonomous and Distributed should be out of scope > > > >>>>> > > > >>>>based on the > > > >>>> > > > >>>> > > > >>>> > > > >>>>>>same reasons as per prior postings. > > > >>>>>> > > > >>>>>>2. Within Centralized do we focus on all three sub > > > >>>>> > > > >>>>architectures or > > > >>>> > > > >>>> > > > >>>>>>a subset? Remote MAC should be excluded because if I am not > > > >>>>>>mistaken, the connectivity constraint between the WTP and > > > >>>>> > > > >>>>the AC is > > > >>>> > > > >>>> > > > >>>>>>"direct connect". > > > >>>>>>That being the case and that no IP layer is involved, > > it doesn't > > > >>>>> > > > >>>>seem > > > >>>> > > > >>>> > > > >>>>>>clear what kind of protocol would help with > > > interoperability. I am > > > >>>>> > > > >>>>>>concerned about the impact, dependencies and > > > interaction with the > > > >>>>>>recently constituted IEEE Study group on AP > > > >>>>> > > > >>>>functionality on the > > > >>>> > > > >>>> > > > >>>>>>Split MAC architectures. Furthermore, there are some > > > >>>>> > > > >>>>pretty drastic > > > >>>> > > > >>>> > > > >>>>>>differences on how the vendors have chosen to split the > > > >>>>> > > > >>>>mac. Those > > > >>>> > > > >>>> > > > >>>>>>differences will need to be worked out before designing a > > > >>>>> > > > >>>>protocol. > > > >>>> > > > >>>> > > > >>>>>>So, if the low hanging fruit strategy (as James > > suggested) for > > > >>>>>>protocol development and progress is the way to go, > > > then I think > > > >>>>>>prioritizing on a protocol for Local MAC is a no brainer. > > > >>>>> > > > >>>>So as far > > > >>>> > > > >>>> > > > >>>>>>as focus, I feel we should do Local and Split and in > > that order. > > > >>>>>> > > > >>>>>>3. This is not a re-chartering issue but is a > > response to Pat's > > > >>>>>>suggestion that a protocol that just sends the 802.11 > > > MAC frames > > > >>>>> > > > >>>>>>from the AP to the AC would work. I think possibly, yes. > > > >>>>> > > > >>>> > > > >>>>But again > > > >>>> > > > >>>> > > > >>>> > > > >>>>>>the complications of splitting the MAC in an > > > >>>>> > > > >>>>interoperable way will > > > >>>> > > > >>>> > > > >>>>>>be an issue. Also, you may note in the draft to which > > > >>>>> > > > >>>>you refer, we > > > >>>> > > > >>>> > > > >>>> > > > >>>>>>included a capabilities exchange phase. I had thought of > > > >>>>> > > > >>>>including > > > >>>> > > > >>>> > > > >>>>>>in the capability exchange such things as "AP supports > > > Local MAC" > > > >>>>>>and "AP supports Split MAC", but didn't put it in because the > > > >>>>>>Taxonomy work was still in progress. Now that it is > > > pretty much > > > >>>>>>done we could surely include that. But again...let's > > recharter > > > >>>>>>first. > > > >>>>>> > > > >>>>>>Thanks. Do people agree with 1 & 2? > > > >>>>>> > > > >>>>>>--- > > > >>>>>>Inderpreet Singh > > > >>>>>>Chantry Networks > > > >>>>>>isingh@chantrynetworks.com > > > >>>>>>Cell: 416-831-3705 > > > >>>>>> > > > >>>>>>-----Original Message----- > > > >>>>>>From: capwap-admin@frascone.com > > > >>>>> > > > >>>>[mailto:capwap-admin@frascone.com] > > > >>>> > > > >>>> > > > >>>>>>On Behalf Of Pat R. Calhoun > > > >>>>>>Sent: Tuesday, August 03, 2004 6:04 PM > > > >>>>>>To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com; > > > >>>>>>capwap@frascone.com > > > >>>>>>Cc: bwijnen@lucent.com; mmani@avaya.com; > > david.kessens@nokia.com > > > >>>>>>Subject: [Capwap] So many architectures, so little > > > >>>>> > > > >>>>time... - take 2 > > > >>>> > > > >>>> > > > >>>>>>After reading Lily's response to Jim, I realize that I > > > >>>>> > > > >>>>fell down the > > > >>>> > > > >>>> > > > >>>> > > > >>>>>>same trap. Local MAC is also a centralized approach, > > and so my > > > >>>>>>previous response was not complete. I believe the real > > > >>>>> > > > >>>>question, in > > > >>>> > > > >>>> > > > >>>>>>my mind, is whether we need to address either the Local > > > >>>>> > > > >>>>or the Split > > > >>>> > > > >>>> > > > >>>> > > > >>>>>>MAC architecture. > > > >>>>>> > > > >>>>>>Just looking at the Architecture Consideration tables (7 and > > > >>>>>>10) in the > > > >>>>>>specification, the > > > >>>>>>main difference (at a high level) between both approaches > > > >>>>> > > > >>>>is where > > > >>>> > > > >>>> > > > >>>>>>the 802.11 management terminates. For Local MAC, it's > > > in the WTP, > > > >>>>>>while for SPlit MAC, it's in the AC. > > > >>>>>> > > > >>>>>>However, looking at table 8, most Local MAC approaches > > > share STA > > > >>>>>>state between both the WTP and the AC. So clearly > > there is some > > > >>>>>>signalling protocol between both the WTP and the AC. > > > >>>>>> > > > >>>>>>Looking at one example of a Local MAC protocol (see > > > >>>>>> > > > >>>>> > > > > > >>>http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > > > >>> > > > >>> > > > >>>>>there is a protocol message > > > >>>>>that corresponds for every 802.11 MAC management event. So > > > >>>> > > > >>when a STA > > > >> > > > >> > > > >>>>>associates, the AP breaks the message apart and creates an new > > > >>>>>protocol PDU, which contains components found in the > > association > > > >>>>>request. I suspect that most Local MAC approaches do > > > >>>> > > > >>something very > > > >> > > > >>>>>similar. > > > >>>>> > > > >>>>>So if a protocol simply tunnels the 802.11 MAC management > > > >>>> > > > >>frames from > > > >> > > > >> > > > >>>>>the WTP to the AC, it allows supports both approaches. For > > > >>>> > > > >>Local MAC, > > > >> > > > >> > > > >>>>>they get what they want via the 802.11 frame, and this > > > also works > > > >>>>>fine for Split MAC, which needs access to the MAC > > > >>>> > > > >>management frame. > > > >> > > > >>>>>What would be required in such a protocol is a way for > > the AP to > > > >>>>>communicate whether it will be providing very specific > > > functions - > > > >>>>>basically a capabilities negotiation approach. > > > >>>>> > > > >>>>>So I do believe that there is a way to address both > > > architectures > > > >>>>>using a single protocol. > > > >>>>> > > > >>>>>Thoughts? > > > >>>>> > > > >>>>>PatC > > > >>>>> > > > >>>>>_______________________________________________ > > > >>>>>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 > > >>>_______________________________________________ > > >>>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 > > >>>_______________________________________________ > > >>>Capwap mailing list > > >>>Capwap@frascone.com > > >>>http://mail.frascone.com/mailman/listinfo/capwap > > >> > > >> > > >>-- > > >>Shankar Narayanaswamy, Ph.D. > > >>wireless@shankar.org Mobile: +1 650-387-4593 > > >>http://www.shankar.org E-Fax: +1 253-498-8372 > > >> > > >>_______________________________________________ > > >>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 > > > > > > > > > > > > -- > > Shankar Narayanaswamy, Ph.D. > > wireless@shankar.org Mobile: +1 650-387-4593 > > http://www.shankar.org E-Fax: +1 253-498-8372 > > > > _______________________________________________ > > 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 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Aug 13 18:36:16 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23461 for ; Fri, 13 Aug 2004 18:36:15 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0887E20B3D; Fri, 13 Aug 2004 18:21:24 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EA635208C2; Fri, 13 Aug 2004 18:21:19 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 53F5D20733 for ; Fri, 13 Aug 2004 18:20:30 -0400 (EDT) Received: from smtp110.mail.sc5.yahoo.com (smtp110.mail.sc5.yahoo.com [66.163.170.8]) by mail.frascone.com (Postfix) with SMTP id 3A08220552 for ; Fri, 13 Aug 2004 18:20:28 -0400 (EDT) Received: from unknown (HELO yahoo.com) (behcetsarikaya@24.71.248.99 with plain) by smtp110.mail.sc5.yahoo.com with SMTP; 13 Aug 2004 22:35:17 -0000 Message-ID: <411D4221.4070506@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.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Mani, Mahalingam (Mahalingam)" Cc: capwap@frascone.com Subject: Re: [Capwap] Re: Data plane and control plane separation in Split MAC References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010207010706060503040707" 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, 13 Aug 2004 15:35:13 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. --------------010207010706060503040707 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mani, both cases look similar to me from control and provisioning point of view, AP needs to be provisioned, why not include one and exclude the other? Mani, Mahalingam (Mahalingam) wrote: > Behcet, > > > > The case you're alluding to is interesting. If I understand correctly > where a 'non-AP' function is involved by way of user authentication > that is not a standard recognizable as a MAC/link-layer > function/interface; it is a higher layer function served by a higher > layer service (at AC presumably) - past the 802.1X authentication. It > looks clearly out of scope. I may have understood the issue wrongly - > I could not spot the related text in the referred CTP draft. > > > > [I suppose you are not referring to the 'inner' authentication phase > of tunneled EAP methods? It is still EAP and the uncontrolled port > does not enable controlled port (I guess I switched the terms in an > earlier email) until the entire sequence completes.] > > > > Can you expand on this further? > > > > -mani > > ------------------------------------------------------------------------ > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Behcet Sarikaya > Sent: Thursday, August 12, 2004 2:52 PM > To: Wijnen, Bert (Bert) > Cc: capwap@frascone.com > Subject: Re: [Capwap] Re: Data plane and control plane separation in > Split MAC > > > > Wijnen, Bert (Bert) wrote: > >>-----Original Message----- >> >>From: Shankar Narayanaswamy [mailto:wireless@shankar.org] >> >>Sent: donderdag 12 augustus 2004 05:13 >> >>To: Dorothy.Gellert@nokia.com >> >>Cc: capwap@frascone.com >> >>Subject: [Capwap] Re: Data plane and control plane separation in Split >> >>MAC >> >> >> >> >> >>The parameters by which the data plane communicates such as >> >>authentication/security info, destination switch (if any) for data >> >>frames, etc, are communicated by the control plane. Hence the need for >> >>some architectural assumptions regarding the data plane even if the >> >>focus is on the control plane. >> >> >> >>Or at least a decision on the data plane architectures to be >> >>supported. >> >> >> >> >> >So... to me that sounds that we may potentially do an IMPLIED agreement > >on the architecture for data plane, based on the capabilities we define > >in the standards track control and provisioning protocol. > > > >That would be fine with me. But we should NOT get bogged down in that > >data plane stuff, or at least that to me seems to be the wrong focus. > > > > Agreed. > However, there might be interest in data packets for user-based > security management. As in CTP, > tunneling data frames to AC so that user-based authentication, etc. > can be achieved. > Is this within the scope? > Otherwise control frames are probably sufficient for a control and > provisioning protocol to deal with. > --behcet > --------------010207010706060503040707 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Mani, both cases look similar to me from control and provisioning point of view, AP needs to be
provisioned, why not include one and exclude the other?

Mani, Mahalingam (Mahalingam) wrote:

Behcet,

 

The case you’re alluding to is interesting. If I understand correctly where a 'non-AP' function is involved by way of user authentication that is not a standard recognizable as a MAC/link-layer function/interface; it is a higher layer function served by a higher layer service (at AC presumably) - past the 802.1X authentication. It looks clearly out of scope. I may have understood the issue wrongly - I could not spot the related text in the referred CTP draft.

 

[I suppose you are not referring to the ‘inner’ authentication phase of tunneled EAP methods? It is still EAP and the uncontrolled port does not enable controlled port (I guess I switched the terms in an earlier email) until the entire sequence completes.]

 

Can you expand on this further?

 

-mani

From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Behcet Sarikaya
Sent: Thursday, August 12, 2004 2:52 PM
To: Wijnen, Bert (Bert)
Cc: capwap@frascone.com
Subject: Re: [Capwap] Re: Data plane and control plane separation in Split MAC

 

Wijnen, Bert (Bert) wrote:

-----Original Message-----
From: Shankar Narayanaswamy [mailto:wireless@shankar.org]
Sent: donderdag 12 augustus 2004 05:13
To: Dorothy.Gellert@nokia.com
Cc: capwap@frascone.com
Subject: [Capwap] Re: Data plane and control plane separation in Split
MAC
 
 
The parameters by which the data plane communicates such as 
authentication/security info, destination switch (if any) for data 
frames, etc, are communicated by the control plane. Hence the need for 
some architectural assumptions regarding the data plane even if the 
focus is on the control plane.
 
Or at least a decision on the data plane architectures to be 
supported.
 
    
So... to me that sounds that we may potentially do an IMPLIED agreement 
on the architecture for data plane, based on the capabilities we define
in the standards track control and provisioning protocol.
 
That would be fine with me. But we should NOT get bogged down in that
data plane stuff, or at least that to me seems to be the wrong focus.
 

Agreed.
However, there might be interest in data packets for user-based security management. As in CTP,
tunneling data frames to AC so that user-based authentication, etc. can be achieved.
Is this within the scope?
Otherwise control frames are probably sufficient for a control and provisioning protocol to deal with.
--behcet

--------------010207010706060503040707-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Aug 13 18:44:11 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23812 for ; Fri, 13 Aug 2004 18:44:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F2191201AD; Fri, 13 Aug 2004 18:29:21 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C9D7F20733; Fri, 13 Aug 2004 18:29:18 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5083A2027E for ; Fri, 13 Aug 2004 18:28: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 658F1201AD for ; Fri, 13 Aug 2004 18:28:29 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.12.6/8.12.6) with ESMTP id i7DMhPrw004274; Fri, 13 Aug 2004 15:43:25 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200408132243.i7DMhPrw004274@homebrew.trpz.com> To: Shankar Narayanaswamy Cc: "Yang, Lily L" , "Bob O'Hara" , capwap@frascone.com Subject: Re: [Capwap] Re: Data plane and control plane separation in SplitMAC In-Reply-To: Your message of "Fri, 13 Aug 2004 13:41:36 PDT." <1092429696.411d27800c3d4@shankar.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4272.1092437005.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, 13 Aug 2004 15:43:25 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Unnecessary negotiation has been the bane of quite a few IETF protocols (I will submit IKE-- RFC2409-- as a prime example because I know who's responsible for it and he won't mind). Why can't the "set of well-known, standard data forwarding protocols" have a single member? Dan. On Fri, 13 Aug 2004 13:41:36 PDT you wrote > > So we should aim for allowing a (very small) set of well-known, standard data > forwarding protocols to be negotiated over the control plane. The actual numb >er > of protocols (and which ones) is something that we as a group will decide. > > -s > -- > Shankar Narayanaswamy, Ph.D. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Aug 13 20:39:20 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28010 for ; Fri, 13 Aug 2004 20:39:20 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B9BCB203BB; Fri, 13 Aug 2004 20:24:26 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 80A6921C9D; Fri, 13 Aug 2004 20:24:23 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 34BB721CA0 for ; Fri, 13 Aug 2004 20:23:13 -0400 (EDT) Received: from gemini.lunarpages.com (gemini.lunarpages.com [64.235.234.128]) by mail.frascone.com (Postfix) with ESMTP id B10BB21C9D for ; Fri, 13 Aug 2004 20:23:11 -0400 (EDT) Received: from dsl093-138-199.sfo4.dsl.speakeasy.net ([66.93.138.199] helo=shankar.org) by gemini.lunarpages.com with asmtp (Exim 4.34) id 1BvmYr-0001uu-0H; Fri, 13 Aug 2004 17:38:17 -0700 Message-ID: <411D5E93.7010205@shankar.org> From: Shankar Narayanaswamy User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Harkins Cc: "Yang, Lily L" , "Bob O'Hara" , capwap@frascone.com Subject: Re: [Capwap] Re: Data plane and control plane separation in SplitMAC References: <200408132243.i7DMhPrw004274@homebrew.trpz.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gemini.lunarpages.com X-AntiAbuse: Original Domain - frascone.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - shankar.org 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, 13 Aug 2004 17:36:35 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Mainly because having a single member may seriously impinge on the flexibility of the system. For example, do we insist that everyone use SSL with 1024 bit keys or allow different key lengths? Also, there is nothing magic about "1". However it often precludes "more than 1" if the system is not designed properly. It is fair to start with a single "required" member to guarantee interoperability. Others could be "optional" and determined by technical and/or market need. -s Dan Harkins wrote: > Unnecessary negotiation has been the bane of quite a few IETF protocols > (I will submit IKE-- RFC2409-- as a prime example because I know who's > responsible for it and he won't mind). Why can't the "set of well-known, > standard data forwarding protocols" have a single member? > > Dan. > > On Fri, 13 Aug 2004 13:41:36 PDT you wrote > >>So we should aim for allowing a (very small) set of well-known, standard data >>forwarding protocols to be negotiated over the control plane. The actual numb >>er >>of protocols (and which ones) is something that we as a group will decide. >> >>-s >>-- >>Shankar Narayanaswamy, Ph.D. > -- Shankar Narayanaswamy, Ph.D. wireless@shankar.org Mobile: +1 650-387-4593 http://www.shankar.org E-Fax: +1 253-498-8372 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Aug 13 21:09:25 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29848 for ; Fri, 13 Aug 2004 21:09:24 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9E92321CB9; Fri, 13 Aug 2004 20:51:27 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ACC3B21CAF; Fri, 13 Aug 2004 20:51:24 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B132D21A2F for ; Fri, 13 Aug 2004 20:50:42 -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 EB6E320C36 for ; Fri, 13 Aug 2004 20:50:40 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.12.6/8.12.6) with ESMTP id i7E15arw004688; Fri, 13 Aug 2004 18:05:36 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200408140105.i7E15arw004688@homebrew.trpz.com> To: Shankar Narayanaswamy Cc: "Yang, Lily L" , "Bob O'Hara" , capwap@frascone.com Subject: Re: [Capwap] Re: Data plane and control plane separation in SplitMAC In-Reply-To: Your message of "Fri, 13 Aug 2004 17:36:35 PDT." <411D5E93.7010205@shankar.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4686.1092445536.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, 13 Aug 2004 18:05:36 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Oh no. There is something quite magic about "1". There is also a rule that comes into play when designing protocols and it is ignored at one's own risk: "There are three possible values: zero, one and infinity." That rule as been shown to be true time and time again. Your SSL example does not apply as there is no negotiation necessary to deal with keys of different lengths. If you can't design a protocol that has a single way to tunnel packets then you're gonna need some negotiation capability to select which method (and probably end up having to implement the entire set-- woo-hoo code bloat!) and while that will allow you to design Yet Another Negotiation Protocol (tm) it's an unnecessary interoperability problem. One mandatory and multiple optional is a recipe for disaster. Been there; done that; got pilloried. Go ahead though. I reserve the right to say "ha ha told ya so" in a couple of years. Dan. On Fri, 13 Aug 2004 17:36:35 PDT you wrote > Mainly because having a single member may seriously impinge on the > flexibility of the system. For example, do we insist that everyone use > SSL with 1024 bit keys or allow different key lengths? > > Also, there is nothing magic about "1". However it often precludes "more > than 1" if the system is not designed properly. > > It is fair to start with a single "required" member to guarantee > interoperability. Others could be "optional" and determined by technical > and/or market need. > > -s > > Dan Harkins wrote: > > Unnecessary negotiation has been the bane of quite a few IETF protocols > > (I will submit IKE-- RFC2409-- as a prime example because I know who's > > responsible for it and he won't mind). Why can't the "set of well-known, > > standard data forwarding protocols" have a single member? > > > > Dan. > > > > On Fri, 13 Aug 2004 13:41:36 PDT you wrote > > > >>So we should aim for allowing a (very small) set of well-known, standard da >ta > >>forwarding protocols to be negotiated over the control plane. The actual nu >mb > >>er > >>of protocols (and which ones) is something that we as a group will decide. > >> > >>-s > >>-- > >>Shankar Narayanaswamy, Ph.D. > > > > > -- > Shankar Narayanaswamy, Ph.D. > wireless@shankar.org Mobile: +1 650-387-4593 > http://www.shankar.org E-Fax: +1 253-498-8372 > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Aug 13 21:32:19 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00541 for ; Fri, 13 Aug 2004 21:32:18 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9AE852091F; Fri, 13 Aug 2004 21:17:27 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4918F20C04; Fri, 13 Aug 2004 21:17:24 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 70FDB2091F for ; Fri, 13 Aug 2004 21:16:47 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id 29A8720C04 for ; Fri, 13 Aug 2004 21:16:44 -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] Re: Data plane and control plane separation in SplitMAC X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: <55749BC69138654EBBC4C50BA4F556100297192E@AIREMAIL.airespace.com> Thread-Topic: [Capwap] Re: Data plane and control plane separation in SplitMAC Thread-Index: AcSBmzs/GQc/LaOnR06R623GluFcrwAA0Wcg From: "Bob O'Hara" 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, 13 Aug 2004 18:34:39 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I agree with Dan. It is a Very Bad Idea(tm) to proliferate options, when they are not absolutely required. And if they are required, why would they be optional? =20 -Bob =20 -----Original Message----- From: Dan Harkins [mailto:dharkins@trpz.com]=20 Sent: Friday, August 13, 2004 6:06 PM To: Shankar Narayanaswamy Cc: Yang, Lily L; Bob O'Hara; capwap@frascone.com Subject: Re: [Capwap] Re: Data plane and control plane separation in SplitMAC=20 Oh no. There is something quite magic about "1". There is also a rule that comes into play when designing protocols and it is ignored at one's own risk: "There are three possible values: zero, one and infinity." That rule as been shown to be true time and time again. Your SSL example does not apply as there is no negotiation necessary to deal with keys of different lengths. If you can't design a protocol that has a single way to tunnel packets then you're gonna need some negotiation capability to select which method (and probably end up=20 having to implement the entire set-- woo-hoo code bloat!) and while that will allow you to design Yet Another Negotiation Protocol (tm) it's an unnecessary interoperability problem. One mandatory and multiple optional is a recipe for disaster. Been there; done that; got pilloried. Go ahead though. I reserve the right to say "ha ha told ya so" in a couple of years. Dan. On Fri, 13 Aug 2004 17:36:35 PDT you wrote > Mainly because having a single member may seriously impinge on the=20 > flexibility of the system. For example, do we insist that everyone use > SSL with 1024 bit keys or allow different key lengths? >=20 > Also, there is nothing magic about "1". However it often precludes "more=20 > than 1" if the system is not designed properly. >=20 > It is fair to start with a single "required" member to guarantee=20 > interoperability. Others could be "optional" and determined by technical=20 > and/or market need. >=20 > -s >=20 > Dan Harkins wrote: > > Unnecessary negotiation has been the bane of quite a few IETF protocols > > (I will submit IKE-- RFC2409-- as a prime example because I know who's > > responsible for it and he won't mind). Why can't the "set of well-known, > > standard data forwarding protocols" have a single member?=20 > >=20 > > Dan. > >=20 > > On Fri, 13 Aug 2004 13:41:36 PDT you wrote > >=20 > >>So we should aim for allowing a (very small) set of well-known, standard da >ta > >>forwarding protocols to be negotiated over the control plane. The actual nu >mb > >>er > >>of protocols (and which ones) is something that we as a group will decide. > >> > >>-s > >>-- > >>Shankar Narayanaswamy, Ph.D. > >=20 >=20 >=20 > --=20 > Shankar Narayanaswamy, Ph.D. > wireless@shankar.org Mobile: +1 650-387-4593 > http://www.shankar.org E-Fax: +1 253-498-8372 >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Aug 13 21:42:32 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01165 for ; Fri, 13 Aug 2004 21:42:31 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 38A082026B; Fri, 13 Aug 2004 21:27:33 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DD7BC20C6A; Fri, 13 Aug 2004 21:27:29 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0560D2118D for ; Fri, 13 Aug 2004 21:26:08 -0400 (EDT) Received: from sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by mail.frascone.com (Postfix) with ESMTP id 4044B20C04 for ; Fri, 13 Aug 2004 21:26:06 -0400 (EDT) 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.6944.0 Subject: RE: [Capwap] Re: Data plane and control plane separation in SplitMAC Message-ID: Thread-Topic: [Capwap] Re: Data plane and control plane separation in SplitMAC Thread-Index: AcSBmzs/GQc/LaOnR06R623GluFcrwAA0WcgAAAZczA= From: "Sudhanshu Jain" To: "Bob O'Hara" , 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, 13 Aug 2004 18:44:55 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I don't agree with Dan. I don't think we are designing a new protocol for tunneling the packets. Even if there are requirements to define a new one, we need to keep it separate from the control plane effort.=20 IMHO, there are existing protocols, which can be used for this purpose. -Suds -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Bob O'Hara Sent: Friday, August 13, 2004 6:35 PM To: capwap@frascone.com Subject: RE: [Capwap] Re: Data plane and control plane separation in SplitMAC=20 I agree with Dan. It is a Very Bad Idea(tm) to proliferate options, when they are not absolutely required. And if they are required, why would they be optional? =20 -Bob =20 -----Original Message----- From: Dan Harkins [mailto:dharkins@trpz.com]=20 Sent: Friday, August 13, 2004 6:06 PM To: Shankar Narayanaswamy Cc: Yang, Lily L; Bob O'Hara; capwap@frascone.com Subject: Re: [Capwap] Re: Data plane and control plane separation in SplitMAC=20 Oh no. There is something quite magic about "1". There is also a rule that comes into play when designing protocols and it is ignored at one's own risk: "There are three possible values: zero, one and infinity." That rule as been shown to be true time and time again. Your SSL example does not apply as there is no negotiation necessary to deal with keys of different lengths. If you can't design a protocol that has a single way to tunnel packets then you're gonna need some negotiation capability to select which method (and probably end up=20 having to implement the entire set-- woo-hoo code bloat!) and while that will allow you to design Yet Another Negotiation Protocol (tm) it's an unnecessary interoperability problem. One mandatory and multiple optional is a recipe for disaster. Been there; done that; got pilloried. Go ahead though. I reserve the right to say "ha ha told ya so" in a couple of years. Dan. On Fri, 13 Aug 2004 17:36:35 PDT you wrote > Mainly because having a single member may seriously impinge on the=20 > flexibility of the system. For example, do we insist that everyone use > SSL with 1024 bit keys or allow different key lengths? >=20 > Also, there is nothing magic about "1". However it often precludes "more=20 > than 1" if the system is not designed properly. >=20 > It is fair to start with a single "required" member to guarantee=20 > interoperability. Others could be "optional" and determined by technical=20 > and/or market need. >=20 > -s >=20 > Dan Harkins wrote: > > Unnecessary negotiation has been the bane of quite a few IETF protocols > > (I will submit IKE-- RFC2409-- as a prime example because I know who's > > responsible for it and he won't mind). Why can't the "set of well-known, > > standard data forwarding protocols" have a single member?=20 > >=20 > > Dan. > >=20 > > On Fri, 13 Aug 2004 13:41:36 PDT you wrote > >=20 > >>So we should aim for allowing a (very small) set of well-known, standard da >ta > >>forwarding protocols to be negotiated over the control plane. The actual nu >mb > >>er > >>of protocols (and which ones) is something that we as a group will decide. > >> > >>-s > >>-- > >>Shankar Narayanaswamy, Ph.D. > >=20 >=20 >=20 > --=20 > Shankar Narayanaswamy, Ph.D. > wireless@shankar.org Mobile: +1 650-387-4593 > http://www.shankar.org E-Fax: +1 253-498-8372 >=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 Sun Aug 15 22:06:40 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03256 for ; Sun, 15 Aug 2004 22:06:39 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DAF1A21802; Sun, 15 Aug 2004 21:51:45 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9FD2C204FB; Sun, 15 Aug 2004 21:51:42 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3EFBB204FB for ; Sun, 15 Aug 2004 21:50:41 -0400 (EDT) Received: from toronto-mail.chantrynetworks.com (unknown [67.69.27.58]) by mail.frascone.com (Postfix) with ESMTP id 7886A1FE68 for ; Sun, 15 Aug 2004 21:50:39 -0400 (EDT) Received: from [192.168.5.133] (helo=wxp35) by toronto-mail.chantrynetworks.com with asmtp (Exim 4.31) id 1BwWrS-0003Z7-PE for capwap@frascone.com; Sun, 15 Aug 2004 22:04:35 -0400 From: "Inderpreet Singh" To: Subject: RE: [Capwap] More IETF Expert Review on rev-03... Message-ID: <014201c48335$83801090$1ff11cac@toronto.chantrynetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-AV-Scan: This message has been scanned by Chantry Networks, Toronto using ClamAV 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: Sun, 15 Aug 2004 22:05:31 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable WG: I have been asked to review the last comments on rev-03 of the = Architecture Taxonomy draft. Since these comments came in towards the end of the completion of rev-04, some of the feedback was already taken care of. Nevertheless, I have reviewed the comments and here are the proposals = for resolution. One can read the rev-03 and comments at: http://www.cs.ucla.edu/~pzerfos/draft-ietf-capwap-arch-03-comments.txt If there are any issues, please raise them on the list. Draft rev-05 is almost done and just requires resolution to these comments. Thanks Inderpreet =3D=3D=3D=3D=3D=3D=3D Comment#1 [ Please take a look at draft-housley-cms-fw-wrap-04.txt. I = would like to know if it is useful in this context. If not, how can it be adjusted to be helpful? ] Proposed Resolution#1 - Section 2.2 - I think the scope of the = cms-fw-wrap draft is more the firmware package cryptographic protection. In the = context of CAPWAP what is more interesting is the firmware package transport mechanism. There was considerable discussion on this list regarding = this topic and I think it is out of scope even for the taxonomy document. Nevertheless, in the protocol design a discussion must take place as to whether firmware package transport, loading and of course cryptographic protection should be in scope or out of scope. And then, yes, = cms-fw-wrap would be applicable. Comment#2 [ This needs more meat. Today, this connection is wires, and there can be physical control over those wires. I would think that the threat described above is not a very significant one. I am........] Proposed Resolution #2 - Section 3.2 - Security section of the = Autonomous architecture. The following text was added to -04 in this area. I = think it is sufficient to meet the more meat requirement. >>> One of the security issues in this architecture is the need for mutual authentication between the WTP and the Ethernet infrastructure. This = can be ensured by existing mechanisms such as 802.1x between the WTP and the Ethernet switch it plugs into. Another critical security issue with this architecture is the very fact that the WTP is most likely not under lock = and key, but does contain secret information in order to communicate with = the backend systems, such as AAA, SNMP, etc. Due to the common management = method used by IT personnel of pushing a "template" to all devices, theft of = such a device would potentially compromise the wired network. <<< Comment#3 [ Not just rogue. Accidental misconfiguration needs to be considered. ] Proposed Resolution #3 - Section 4.7 - I don't think accidental misconfiguration applies here. The point being made is that if the WTP = does not authenticate the AC (thus implementing mutual authentication), then = its possible that the WTP connects to an AC that it is not supposed to, ie. Rogue AC. Now, since it is the AC that provides all the configuration = to the WTP, the possibility for misconfiguration exists, but has nothing to = do with the subject of authentication. Am I missing something? Comment#4 - [ I worry about the word "push" in the previous sentence. = It makes an assumption about the initiator of the communication. I think = that the word "transferred" varries less baggage. ] Proposed resolution#4 - Section 4.8.1 - Done. New text reads "the = resultant cryptographic keys for the session are required to be securely transferred from the = AC..." Comment#5 - [ What about the state? Who are the parties in the 4-way handshake? If the STA and the AC are the parties in the 4-way = handshake, then more than keys need to be transferred. Further, if the same key is used my more than one WTP, then there needs to be a lot of other stuff transferred to make sure that nonces are not reused. ] Proposed Resolution#5 - Section 4.8.1 - awaiting response from Partha Narasimhan. Comment#6 - [ Replay protection is probably important too. ] Proposed Resolution#6 - Section 4.8.2 - Agreed. Added text.=20 Old Text: =93Confidentiality and integrity of control channel frames=94 New text is: "Confidentiality, integrity and replay protection of = control channel frames" Comment#7 - [ State too. ] Proposed Resolution#7 =96 Section 4.8.2 - Agreed.=20 Old text: =93Secure management of WTPs and ACs, including mechanisms for securely setting and resetting secrets.=94 New text is: =93Secure management of WTPs and ACs, including mechanisms = for securely setting and resetting secrets and state=94. Comment#8 - [ You need confidentiality, integrity, and replay protection = on the over the air links. Saying, that the links ought to be encrypted is = not enough. ] Proposed resolution#8 =96 Section 5.1 - Already changed in rev -04 on = 7/25. Further changed text to include integrity and replay protection. Old Text: =93It is often recommended that all communication between mesh = nodes be encrypted, since they may carry user traffic that is not. For this reason, the operator should always encrypt mesh links, in order to fully secure the network.=94 New Text: =93It is often recommended that all communication between mesh = nodes be secured by some mechanism of confidentiality, integrity and replay protection, since they may carry user traffic that is not. For this = reason, the operator should always encrypt and protect mesh links, in order to = fully secure the network.=94 Comment#9 - [ Since the document discussed the use of IP-based protocols = in some situations, I expected to see a recommendation for an IETF WG to standardize it. ] Proposed Resolutoin #9 =96 Section 6 - Do we need this now that = consensus has formed anyway? Comment#10 - [ Need to add a discussion of replay. ] Proposed Resolution #10 =96 Section 7 - Changed text: Old Text: =93need to be securely transported from AC to WTP; secure = discovery of WTP and AC is required, mutual authentication of WTPs and AC is = needed, man-in-the-middle attacks to the control channel between WTP and AC,=20 confidentiality and integrity of control channel frames, and=20 theft of WTPs for extraction of embedded secrets within.=94 New Text: =93need to be securely transported from AC to WTP; secure = discovery of WTP and AC is required, mutual authentication of WTPs and AC is = needed, man-in-the-middle attacks to the control channel between WTP and AC,=20 confidentiality, integrity and replay protection of control channel = frames, and theft of WTPs for extraction of embedded secrets within.=94 --- Inderpreet Singh Chantry Networks isingh@chantrynetworks.com Cell: 416-831-3705 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Mani, Mahalingam (Mahalingam) Sent: Monday, August 02, 2004 10:55 PM To: capwap@frascone.com; capwap-dt@frascone.com Subject: [Capwap] More IETF Expert Review on rev-03... All, Russ Housley=92s review comments are inline (embedded marked with a = leading [ on column 1) to the draft. http://www.cs.ucla.edu/~pzerfos/draft-ietf-capwap-arch-03-comments.txt (They will also be posted to www.capwap.org website in due course). Since -04 has been posted to WG (but not yet sent in as I-D) we can anticipate another rev-05 to include addressing these. Nevertheless, =A0do review -04 (and in the light of these comments as = well). Regards, -mani _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Aug 16 12:24:34 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13901 for ; Mon, 16 Aug 2004 12:24:33 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 20E2C205F0; Mon, 16 Aug 2004 12:09:39 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8492120916; Mon, 16 Aug 2004 12:09:35 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3E40F20962 for ; Mon, 16 Aug 2004 12:08: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 E96DC20916 for ; Mon, 16 Aug 2004 12:08:25 -0400 (EDT) Message-ID: <00c101c483ad$7509e4a0$536115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Wijnen, Bert (Bert)" , "'Yang, Lily L'" , "Burbank, Jack L." , "Victor Lin" , "Bob O'Hara" , References: <7D5D48D2CAA3D84C813F5B154F43B15503C79B09@nl0006exch001u.nl.lucent.com> Subject: Re: [Capwap] So many architectures, so little time... - take 2 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, 16 Aug 2004 09:24:06 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Ack. jak ----- Original Message ----- From: "Wijnen, Bert (Bert)" To: "'Yang, Lily L'" ; "Burbank, Jack L." ; "Victor Lin" ; "Bob O'Hara" ; Sent: Monday, August 09, 2004 6:13 AM Subject: RE: [Capwap] So many architectures, so little time... - take 2 > Not sure who is confused... probably me... > > My understanding was/is that IF we do re-charter for CAPWAP > protocol work, that it is then a NM protocol for > "Control and Provisioning" and not any of the related stuff > that moves the data from WTP to AC. > > Is everybody in agreement with that understanding. > > Thanks, > Bert > > > -----Original Message----- > > From: Yang, Lily L [mailto:lily.l.yang@intel.com] > > Sent: maandag 9 augustus 2004 08:14 > > To: Burbank, Jack L.; Victor Lin ; Bob O'Hara ; capwap@frascone.com > > Subject: RE: [Capwap] So many architectures, so little > > time... - take 2 > > > > > > I think setting the re-charter scope to develop a single protocol that > > allows interoperability between Local and Split MAC is a reasonable > > tradeoff: > > We exclude remote MAC because the constraint it imposes is very > > different from the rest and the benefit of including it is > > very little. > > But Local and Split MAC are reasonably close and hence the > > effort may be > > incremental only. > > As many people noted, as of today, there is no single clear definition > > of what "Local MAC" and "Split MAC" really means yet. Each vendor has > > different definitions and some debate needs to happen so that > > the WG can > > reach consensus on what exactly that means, and what kinds of > > flexibility we want to retain within each class of architecture, and > > what kind of differences we can to resolve and agree up front. That > > should also be part of the work items for the new WG -- such agreement > > on the details for each architecture must be documented somewhere, if > > not separately, then as part of the Protocol document. > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > > Behalf Of Burbank, Jack L. > > Sent: Thursday, August 05, 2004 12:14 PM > > To: 'Victor Lin '; 'Bob O'Hara '; 'capwap@frascone.com ' > > Subject: RE: [Capwap] So many architectures, so little > > time... - take 2 > > > > I think that interoperability between different architectures > > should be > > a > > requirement, if not the key requirement. As was mentioned > > yesterday, a > > goal > > of the IEEE is that they maintain flexibility in terms of how products > > and > > architectures are implemented. I think we shouldn't do > > anything that is > > contrary to that goal (or at least we should minimize the impact). I > > think > > that the goal of CAPWAP should be to retain this type of > > flexibility by > > designing a protocol that can maintain this implementation flexibility > > but > > enable interoperability between the various architecture > > implementations > > (that after all is the key problem with the deployment of > > these various > > architectures - lack of interoperability). IMO, if we don't > > design for > > interoperability between the basic architecture types, it is debatable > > if > > something useful would have been accomplished. > > > > Jack Burbank > > > > -----Original Message----- > > From: capwap-admin@frascone.com > > To: Bob O'Hara; capwap@frascone.com > > Sent: 8/5/2004 2:46 PM > > Subject: RE: [Capwap] So many architectures, so little > > time... - take 2 > > > > I agree that we can design a protocol and implement the product that > > works > > all architectures. I think the question to CAPWAP is: > > > > Should we make it a requirement in CAPWAP protocol to achieve > > interoperability between different architectures? > > > > It is definitely doable, but I'm not sure if that is the > > right thing to > > do.. > > > > Victor > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > > Behalf > > Of Bob O'Hara > > Sent: Thursday, August 05, 2004 11:43 AM > > To: capwap@frascone.com > > Subject: RE: [Capwap] So many architectures, so little > > time... - take 2 > > > > I think that interoperability will depend on two things. > > First, it will > > depend on how we define the protocol and the flexibility for supported > > architectures it incorporates. Second, it will depend on what > > manufacturers implement, i.e., the flexibility they build into their > > products. > > > > I believe that it is possible to design the protocol for the required > > flexibility. I know it is possible to implement a product with the > > required flexibility. > > > > -Bob O'Hara > > > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > > Behalf Of Abhijit Choudhury > > Sent: Thursday, August 05, 2004 11:32 AM > > To: James Kempf; Shehzad Merchant; capwap@frascone.com > > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; > > Dorothy.Gellert@nokia.com; Inderpreet Singh > > Subject: RE: [Capwap] So many architectures, so little > > time... - take 2 > > > > > > It may be possible to achieve such interoperability > > within the split-MAC family or within the local-MAC > > family. It would sbe very hard to achieve > > that between local and split MAC families. > > > > For example, if vendor X's WTP terminates 802.11 ctrl/mgmt > > packets and vendor Y's AC expects the 802.11 mgmt packets > > to come to it, there's no way you can be interoperable. > > > > Or are we planning to specify ONE architecture ? > > The last thing IETF should do is mandate an implementation. > > > > I think a modest and reasonable goal is to come up > > with a protocol that allows sufficient flexbility so > > that vendors with splitMAC architectures can transfer > > most of the information they care about between the WTP and AC. > > > > Just my $0.02 ... > > > > > > Abhijit Choudhury > > > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > > Behalf Of James Kempf > > Sent: Wednesday, August 04, 2004 3:29 PM > > To: Shehzad Merchant; capwap@frascone.com > > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; > > Dorothy.Gellert@nokia.com; Inderpreet Singh > > Subject: Re: [Capwap] So many architectures, so little > > time... - take 2 > > > > > > As a potential customer, let me put it concretely. I want to > > be able to > > buy my access points from Vendor X and my switch from Vendor > > Y and plug > > the two together and have them work without any > > configuration. Also, I'd > > like to be able to buy switches from Vendor Y and Vendor Z and be able > > to plug them into my network at various places and have them > > interoperate. > > > > jak > > > > > > ----- Original Message ----- > > From: "Shehzad Merchant" > > To: > > Cc: ; ; > > ; > > ; "Inderpreet Singh" > > > > Sent: Wednesday, August 04, 2004 3:19 PM > > Subject: RE: [Capwap] So many architectures, so little > > time... - take 2 > > > > > > > I think the implementation variations even with the split MAC may > > > cover a broad spectrum. As such its important to clearly articulate > > > what aspects > > of > > > interoperability we are targetting. Is it truly just > > > control/management or is it interoperability between disparate > > > implementations of the split MAC, i.e. mix and match > > operation of WTP > > > and ACs of all variants within this category. > > > > > > I suspect for the latter we may have to arrive at some consensus on > > > what particular implementations we are targeting > > interoperability for. > > > > > If so, ultimately this problem statement could become part of the > > > charter. > > > > > > -Shehzad > > > > > > > > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On > > Behalf > > > Of Dorothy.Gellert@nokia.com > > > Sent: Wednesday, August 04, 2004 11:53 AM > > > To: isingh@chantrynetworks.com; capwap@frascone.com > > > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > > > Subject: RE: [Capwap] So many architectures, so little > > time... - take > > > 2 > > > > > > I believe this is the consensus, to scope the charter to > > Centralized > > > Architecture and LocalMAC and Split MAC. > > > > > > I'll update the charter with this change after the CAPWAP > > WG Mtg. If > > > there is resistance to this idea, please post to the list. > > > > > > Regards > > > Dorothy > > > > > > > > > > -----Original Message----- > > > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com]On > > > > Behalf Of ext Inderpreet Singh > > > > Sent: Tuesday, August 03, 2004 9:40 PM > > > > To: capwap@frascone.com > > > > Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David > > > > (Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > > > > Subject: RE: [Capwap] So many architectures, so little time... - > > > > take 2 > > > > > > > > > > > > The issue(s) at hand and my opinions are: > > > > > > > > 1. Do we explicitly state in the re-charter which > > architecture the > > > > WG should consider? I think yes. I propose Centralized > > architecture > > > > > > only. Autonomous and Distributed should be out of scope > > based on the > > > > > > same reasons as per prior postings. > > > > > > > > 2. Within Centralized do we focus on all three sub > > architectures or > > > > a subset? Remote MAC should be excluded because if I am not > > > > mistaken, the connectivity constraint between the WTP and > > the AC is > > > > "direct connect". > > > > That being the case and that no IP layer is involved, it doesn't > > seem > > > > clear what kind of protocol would help with interoperability. > > > > I am concerned about the impact, dependencies and interaction with > > > > the recently constituted IEEE Study group on AP > > functionality on the > > > > Split MAC architectures. Furthermore, there are some > > pretty drastic > > > > differences on how the vendors have chosen to split the > > mac. Those > > > > differences will need to be worked out before designing a > > protocol. > > > > So, if the low hanging fruit strategy (as James suggested) for > > > > protocol development and progress is the way to go, then I think > > > > prioritizing on a protocol for Local MAC is a no brainer. > > So as far > > > > as focus, I feel we should do Local and Split and in that order. > > > > > > > > 3. This is not a re-chartering issue but is a response to Pat's > > > > suggestion that a protocol that just sends the 802.11 MAC frames > > > > from the AP to the AC would work. I think possibly, yes. > > But again > > > > > > the complications of splitting the MAC in an > > interoperable way will > > > > be an issue. Also, you may note in the draft to which > > you refer, we > > > > > > included a capabilities exchange phase. I had thought of > > including > > > > in the capability exchange such things as "AP supports Local MAC" > > > > and "AP supports Split MAC", but didn't put it in because the > > > > Taxonomy work was still in progress. Now that it is pretty much > > > > done we could surely include that. But again...let's recharter > > > > first. > > > > > > > > Thanks. Do people agree with 1 & 2? > > > > > > > > --- > > > > Inderpreet Singh > > > > Chantry Networks > > > > isingh@chantrynetworks.com > > > > Cell: 416-831-3705 > > > > > > > > -----Original Message----- > > > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] > > > > On Behalf Of Pat R. Calhoun > > > > Sent: Tuesday, August 03, 2004 6:04 PM > > > > To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com; > > > > capwap@frascone.com > > > > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > > > > Subject: [Capwap] So many architectures, so little > > time... - take 2 > > > > > > > > After reading Lily's response to Jim, I realize that I > > fell down the > > > > > > same trap. Local MAC is also a centralized approach, and so my > > > > previous response was not complete. I believe the real > > question, in > > > > my mind, is whether we need to address either the Local > > or the Split > > > > > > MAC architecture. > > > > > > > > Just looking at the Architecture Consideration tables (7 and > > > > 10) in the > > > > specification, the > > > > main difference (at a high level) between both approaches > > is where > > > > the 802.11 management terminates. For Local MAC, it's in the WTP, > > > > while for SPlit MAC, it's in the AC. > > > > > > > > However, looking at table 8, most Local MAC approaches share STA > > > > state between both the WTP and the AC. So clearly there is some > > > > signalling protocol between both the WTP and the AC. > > > > > > > > Looking at one example of a Local MAC protocol (see > > > > > http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > > > there is a protocol message > > > that corresponds for every 802.11 MAC management event. So when a > > > STA associates, the AP breaks the message apart and creates an new > > > protocol PDU, which contains components found in the association > > > request. I suspect that most Local MAC approaches do something very > > > similar. > > > > > > So if a protocol simply tunnels the 802.11 MAC management frames > > > from the WTP to the AC, it allows supports both approaches. For > > > Local MAC, they get what they want via the 802.11 frame, and this > > > also works fine for Split MAC, which needs access to the MAC > > > management frame. What would be required in such a protocol is a way > > > for the AP to communicate whether it will be providing very specific > > > functions - basically a capabilities negotiation approach. > > > > > > So I do believe that there is a way to address both architectures > > > using a single protocol. > > > > > > Thoughts? > > > > > > PatC > > > > > > _______________________________________________ > > > 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 > _______________________________________________ > 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 > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Aug 16 13:28:26 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16566 for ; Mon, 16 Aug 2004 13:28:25 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1D02020B2C; Mon, 16 Aug 2004 13:12:49 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B8A0B20B6F; Mon, 16 Aug 2004 13:12:45 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 804CC20B2C for ; Mon, 16 Aug 2004 13:11: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 CBCD520B0B for ; Mon, 16 Aug 2004 13:11:25 -0400 (EDT) Message-ID: <018601c483b6$4243c280$536115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Abhijit Choudhury" , "Wijnen, Bert (Bert)" , "Yang, Lily L" , "Burbank, Jack L." , "Victor Lin" , "Bob O'Hara" , References: Subject: Re: [Capwap] So many architectures, so little time... - take 2 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, 16 Aug 2004 10:27:06 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I think the Capwap protocol should come up with some way to negotiate the data plane and leave the actual tunnelling protocol (or lack thereof) up to configuration. There are too many ways that one might want to do this depending on the deployment scenerio. For example, if my hotspot APs are using the Internet for backhaul, I might want to run the data plane using ESP tunnels rather than GRE or IP in IP tunnels. I don't think the Capwap protocol can select just one. jak ----- Original Message ----- From: "Abhijit Choudhury" To: "Wijnen, Bert (Bert)" ; "Yang, Lily L" ; "Burbank, Jack L." ; "Victor Lin" ; "Bob O'Hara" ; Sent: Tuesday, August 10, 2004 12:55 AM Subject: RE: [Capwap] So many architectures, so little time... - take 2 The same tunneling protocol that moves control and management packets from the WTP to the AC should be used to tunnel data packets as well. We would specify message exchanges to do control, provisioning and capability advertisement between WTPs and the AC. But all of this would be within the unified CAPWAP protocol that moves all packets including data between the WTP and AC. Vendors currently use LWAPP, GRE, IP and some proprietary encapsulations to achieve this. This group would come up with a "standard" way of doing this exchange. At least that was my understanding.... Regards, Abhijit -----Original Mssage----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Wijnen, Bert (Bert) Sent: Monday, August 09, 2004 6:14 AM To: 'Yang, Lily L'; Burbank, Jack L.; Victor Lin; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] So many architectures, so little time... - take 2 Not sure who is confused... probably me... My understanding was/is that IF we do re-charter for CAPWAP protocol work, that it is then a NM protocol for "Control and Provisioning" and not any of the related stuff that moves the data from WTP to AC. Is everybody in agreement with that understanding. Thanks, Bert > -----Original Message----- > From: Yang, Lily L [mailto:lily.l.yang@intel.com] > Sent: maandag 9 augustus 2004 08:14 > To: Burbank, Jack L.; Victor Lin ; Bob O'Hara ; capwap@frascone.com > Subject: RE: [Capwap] So many architectures, so little > time... - take 2 > > > I think setting the re-charter scope to develop a single protocol that > allows interoperability between Local and Split MAC is a reasonable > tradeoff: > We exclude remote MAC because the constraint it imposes is very > different from the rest and the benefit of including it is very > little. But Local and Split MAC are reasonably close and hence the > effort may be > incremental only. > As many people noted, as of today, there is no single clear definition > of what "Local MAC" and "Split MAC" really means yet. Each vendor has > different definitions and some debate needs to happen so that > the WG can > reach consensus on what exactly that means, and what kinds of > flexibility we want to retain within each class of architecture, and > what kind of differences we can to resolve and agree up front. That > should also be part of the work items for the new WG -- such agreement > on the details for each architecture must be documented somewhere, if > not separately, then as part of the Protocol document. > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Burbank, Jack L. > Sent: Thursday, August 05, 2004 12:14 PM > To: 'Victor Lin '; 'Bob O'Hara '; 'capwap@frascone.com ' > Subject: RE: [Capwap] So many architectures, so little > time... - take 2 > > I think that interoperability between different architectures > should be > a > requirement, if not the key requirement. As was mentioned > yesterday, a > goal > of the IEEE is that they maintain flexibility in terms of how products > and > architectures are implemented. I think we shouldn't do > anything that is > contrary to that goal (or at least we should minimize the impact). I > think > that the goal of CAPWAP should be to retain this type of > flexibility by > designing a protocol that can maintain this implementation flexibility > but > enable interoperability between the various architecture > implementations > (that after all is the key problem with the deployment of > these various > architectures - lack of interoperability). IMO, if we don't > design for > interoperability between the basic architecture types, it is debatable > if > something useful would have been accomplished. > > Jack Burbank > > -----Original Message----- > From: capwap-admin@frascone.com > To: Bob O'Hara; capwap@frascone.com > Sent: 8/5/2004 2:46 PM > Subject: RE: [Capwap] So many architectures, so little > time... - take 2 > > I agree that we can design a protocol and implement the product that > works all architectures. I think the question to CAPWAP is: > > Should we make it a requirement in CAPWAP protocol to achieve > interoperability between different architectures? > > It is definitely doable, but I'm not sure if that is the > right thing to > do.. > > Victor > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Bob O'Hara > Sent: Thursday, August 05, 2004 11:43 AM > To: capwap@frascone.com > Subject: RE: [Capwap] So many architectures, so little > time... - take 2 > > I think that interoperability will depend on two things. > First, it will > depend on how we define the protocol and the flexibility for supported > architectures it incorporates. Second, it will depend on what > manufacturers implement, i.e., the flexibility they build into their > products. > > I believe that it is possible to design the protocol for the required > flexibility. I know it is possible to implement a product with the > required flexibility. > > -Bob O'Hara > > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Abhijit Choudhury > Sent: Thursday, August 05, 2004 11:32 AM > To: James Kempf; Shehzad Merchant; capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; > Dorothy.Gellert@nokia.com; Inderpreet Singh > Subject: RE: [Capwap] So many architectures, so little > time... - take 2 > > > It may be possible to achieve such interoperability > within the split-MAC family or within the local-MAC > family. It would sbe very hard to achieve > that between local and split MAC families. > > For example, if vendor X's WTP terminates 802.11 ctrl/mgmt packets and > vendor Y's AC expects the 802.11 mgmt packets to come to it, there's > no way you can be interoperable. > > Or are we planning to specify ONE architecture ? > The last thing IETF should do is mandate an implementation. > > I think a modest and reasonable goal is to come up > with a protocol that allows sufficient flexbility so > that vendors with splitMAC architectures can transfer > most of the information they care about between the WTP and AC. > > Just my $0.02 ... > > > Abhijit Choudhury > > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of James Kempf > Sent: Wednesday, August 04, 2004 3:29 PM > To: Shehzad Merchant; capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; > Dorothy.Gellert@nokia.com; Inderpreet Singh > Subject: Re: [Capwap] So many architectures, so little > time... - take 2 > > > As a potential customer, let me put it concretely. I want to > be able to > buy my access points from Vendor X and my switch from Vendor > Y and plug > the two together and have them work without any > configuration. Also, I'd > like to be able to buy switches from Vendor Y and Vendor Z and be able > to plug them into my network at various places and have them > interoperate. > > jak > > > ----- Original Message ----- > From: "Shehzad Merchant" > To: > Cc: ; ; > ; > ; "Inderpreet Singh" > > Sent: Wednesday, August 04, 2004 3:19 PM > Subject: RE: [Capwap] So many architectures, so little > time... - take 2 > > > > I think the implementation variations even with the split MAC may > > cover a broad spectrum. As such its important to clearly articulate > > what aspects > of > > interoperability we are targetting. Is it truly just > > control/management or is it interoperability between disparate > > implementations of the split MAC, i.e. mix and match > operation of WTP > > and ACs of all variants within this category. > > > > I suspect for the latter we may have to arrive at some consensus on > > what particular implementations we are targeting > interoperability for. > > > If so, ultimately this problem statement could become part of the > > charter. > > > > -Shehzad > > > > > > > > -----Original Message----- > > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On > Behalf > > Of Dorothy.Gellert@nokia.com > > Sent: Wednesday, August 04, 2004 11:53 AM > > To: isingh@chantrynetworks.com; capwap@frascone.com > > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > > Subject: RE: [Capwap] So many architectures, so little > time... - take > > 2 > > > > I believe this is the consensus, to scope the charter to > Centralized > > Architecture and LocalMAC and Split MAC. > > > > I'll update the charter with this change after the CAPWAP > WG Mtg. If > > there is resistance to this idea, please post to the list. > > > > Regards > > Dorothy > > > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com]On > > > Behalf Of ext Inderpreet Singh > > > Sent: Tuesday, August 03, 2004 9:40 PM > > > To: capwap@frascone.com > > > Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David > > > (Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > > > Subject: RE: [Capwap] So many architectures, so little time... - > > > take 2 > > > > > > > > > The issue(s) at hand and my opinions are: > > > > > > 1. Do we explicitly state in the re-charter which > architecture the > > > WG should consider? I think yes. I propose Centralized > architecture > > > > only. Autonomous and Distributed should be out of scope > based on the > > > > same reasons as per prior postings. > > > > > > 2. Within Centralized do we focus on all three sub > architectures or > > > a subset? Remote MAC should be excluded because if I am not > > > mistaken, the connectivity constraint between the WTP and > the AC is > > > "direct connect". > > > That being the case and that no IP layer is involved, it doesn't > seem > > > clear what kind of protocol would help with interoperability. I am > > > concerned about the impact, dependencies and interaction with the > > > recently constituted IEEE Study group on AP > functionality on the > > > Split MAC architectures. Furthermore, there are some > pretty drastic > > > differences on how the vendors have chosen to split the > mac. Those > > > differences will need to be worked out before designing a > protocol. > > > So, if the low hanging fruit strategy (as James suggested) for > > > protocol development and progress is the way to go, then I think > > > prioritizing on a protocol for Local MAC is a no brainer. > So as far > > > as focus, I feel we should do Local and Split and in that order. > > > > > > 3. This is not a re-chartering issue but is a response to Pat's > > > suggestion that a protocol that just sends the 802.11 MAC frames > > > from the AP to the AC would work. I think possibly, yes. > But again > > > > the complications of splitting the MAC in an > interoperable way will > > > be an issue. Also, you may note in the draft to which > you refer, we > > > > included a capabilities exchange phase. I had thought of > including > > > in the capability exchange such things as "AP supports Local MAC" > > > and "AP supports Split MAC", but didn't put it in because the > > > Taxonomy work was still in progress. Now that it is pretty much > > > done we could surely include that. But again...let's recharter > > > first. > > > > > > Thanks. Do people agree with 1 & 2? > > > > > > --- > > > Inderpreet Singh > > > Chantry Networks > > > isingh@chantrynetworks.com > > > Cell: 416-831-3705 > > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] > > > On Behalf Of Pat R. Calhoun > > > Sent: Tuesday, August 03, 2004 6:04 PM > > > To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com; > > > capwap@frascone.com > > > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com > > > Subject: [Capwap] So many architectures, so little > time... - take 2 > > > > > > After reading Lily's response to Jim, I realize that I > fell down the > > > > same trap. Local MAC is also a centralized approach, and so my > > > previous response was not complete. I believe the real > question, in > > > my mind, is whether we need to address either the Local > or the Split > > > > MAC architecture. > > > > > > Just looking at the Architecture Consideration tables (7 and > > > 10) in the > > > specification, the > > > main difference (at a high level) between both approaches > is where > > > the 802.11 management terminates. For Local MAC, it's in the WTP, > > > while for SPlit MAC, it's in the AC. > > > > > > However, looking at table 8, most Local MAC approaches share STA > > > state between both the WTP and the AC. So clearly there is some > > > signalling protocol between both the WTP and the AC. > > > > > > Looking at one example of a Local MAC protocol (see > > > http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > > there is a protocol message > > that corresponds for every 802.11 MAC management event. So when a > > STA associates, the AP breaks the message apart and creates an new > > protocol PDU, which contains components found in the association > > request. I suspect that most Local MAC approaches do something very > > similar. > > > > So if a protocol simply tunnels the 802.11 MAC management frames > > from the WTP to the AC, it allows supports both approaches. For > > Local MAC, they get what they want via the 802.11 frame, and this > > also works fine for Split MAC, which needs access to the MAC > > management frame. What would be required in such a protocol is a way > > for the AP to communicate whether it will be providing very specific > > functions - basically a capabilities negotiation approach. > > > > So I do believe that there is a way to address both architectures > > using a single protocol. > > > > Thoughts? > > > > PatC > > > > _______________________________________________ > > 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 _______________________________________________ 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 _______________________________________________ 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 Aug 18 14:58:43 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29341 for ; Wed, 18 Aug 2004 14:58:32 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 240B921B31; Wed, 18 Aug 2004 14:42:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D01A2216DB; Wed, 18 Aug 2004 14:42:08 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A189721B2D for ; Wed, 18 Aug 2004 14:41:04 -0400 (EDT) Received: from hoemail1.lucent.com (hoemail1.lucent.com [192.11.226.161]) by mail.frascone.com (Postfix) with ESMTP id 05E4421B27 for ; Wed, 18 Aug 2004 14:41:03 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i7IItxRE002836 for ; Wed, 18 Aug 2004 13:55:59 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 18 Aug 2004 20:55:58 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503C79B78@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Capwap (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] IESG Evaluation of: draft-ietf-capwap-problem-statement-01.txt (I nformational) 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, 18 Aug 2004 20:55:56 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) CAPWAP WG members, When IESG reviews documents, they also ask for help from various specialists (like MIB Doctors, AAA_Doctors, OPS Directorate, etc etc) As a result of that we got the following feedback. Pls let me know what you think about the suggestion? The IESG review is NOT yet complete, so pls do not yet submit a new revision. Thanks, Bert --------- comment from AAA doctor: > o draft-ietf-capwap-problem-statement-01.txt > CAPWAP Problem Statement (Informational) - 6 of 6 This document is very good. One additional item that could perhaps be discussed in the security considerations section is related to problem #4, securing a distributed set of access points. I think problem #4 implies that people want to move some of the tasks of the APs to the controller so that the compromise of an access point would not compromise, say, a RADIUS shared secret or perhaps not even some of the keys used to protect the link layer. Security considederations does not point this out. It does say something about looking into physical security, but perhaps it could be expanded into that as well as the assignment of security parameters to the different parts of the system. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Aug 20 15:04:48 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06353 for ; Fri, 20 Aug 2004 15:04:47 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7CA0321408; Fri, 20 Aug 2004 14:49:14 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8CDC12138A; Fri, 20 Aug 2004 14:49:11 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 882A32146B for ; Fri, 20 Aug 2004 14:48:23 -0400 (EDT) Received: from intotoinc.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by mail.frascone.com (Postfix) with ESMTP id 075362001C for ; Fri, 20 Aug 2004 14:48:20 -0400 (EDT) Received: from SriniSony ([10.1.5.111]) by intotoinc.com (8.12.5/8.12.5) with SMTP id i7KJ84oO001858; Fri, 20 Aug 2004 12:08:05 -0700 Message-ID: <064c01c486e8$58ae2940$6f05010a@SriniSony> From: "Srini" To: "Yang, Lily L" , "Bob O'Hara" , References: <2AF68A477DD44C4EBCBE338C24E7A9EE01D05B92@orsmsx408> Subject: Re: [Capwap] Re: Data plane and control plane separation in SplitMAC MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 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, 20 Aug 2004 12:03:14 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I also believe that having a single tunneling protocol is simple and provides better interoperability among AC and WTPs. As you have indicated, it is important to come out with the requirements for data forwarding. Some of the requirements: - 802.3 or 802.11 (Based on whether it is Split AP or Split MAC) packets need to be forwarded to the AC from WTPs. - WTPs and AC can be connected either directly rechable (same physical network) or connected through intermediate routers. - WTP and AC are connected through insecure networks. - Quality of Service should not be compromized for data packets. IPinIP, IPSec, SSL alone can't be used to satisfy above requirements. We require tunneling protocol which encapsulate Layer2 data (MAC frames) in IP or UDP headers. TCP is not suitable as QoS may not be achieved. Wherever security is required, additional IPSec tunneling can be used to protect encapsulated traffic. Since control traffic such as 802.1x traffic, 802.11x events (such as Associate, De_Associate, Re-associate and others) need to be sent with reliability, TCP based protocol can be used. I feel that, two kinds of connections are required - TCP based for sending/receiving control traffic and MAC(L2) over IP/UDP based encapsulation for forwarding the data traffic. Optional IPSec can be used to protect this traffic. Paylaod formats of these protocols would be based on the type of control traffic is required to be sent/received between WTP and AC. Srini ----- Original Message ----- From: "Yang, Lily L" To: "Bob O'Hara" ; Sent: Friday, August 13, 2004 1:13 PM Subject: RE: [Capwap] Re: Data plane and control plane separation in SplitMAC > I also think it makes more sense to arrive at a single protocol for data > forwarding. It doesn't mean CAPWAP has to reinvent the wheel to come up > with yet another tunneling protocol -- existing protocol can be reused > for that purpose. But for interoperability, we need to agree on one > eventually. > So the relevant discussion is to understand the requirements for data > forwarding. > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Bob O'Hara > Sent: Friday, August 13, 2004 12:59 PM > To: capwap@frascone.com > Subject: RE: [Capwap] Re: Data plane and control plane separation in > SplitMAC > > I agree that for a complete solution, we cannot ignore the need for a > data forwarding protocol. But for control and provisioning, not for > operation, that problem can be separated from the initial protocol > design. > > What we might consider in the protocol design is negotiating the data > forwarding protocol. I do not favor negotiation of that protocol as the > final solution. It leads to too many options in a multivendor situation > and will likely provide less interoperability rather than more. When > the question arises, I would prefer we had the hard discussions to > arrive at a single protocol to be used for data forwarding. > > -Bob > > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Partha Narasimhan > Sent: Thursday, August 12, 2004 1:19 PM > To: Lily L Yang > Cc: Wijnen, Bert (Bert); Shankar Narayanaswamy; > Dorothy.Gellert@nokia.com; capwap@frascone.com > Subject: RE: [Capwap] Re: Data plane and control plane separation in > SplitMAC > > > The set of AP functions is split across the WTP and the AC in the > split-MAC and, arguably to a lesser extent, in the local MAC > architectures. As a result, the AP, in these architectures, is no longer > a physical entity, but one that potentially spans a L3 boundary. The > handling of data frames (and some mgmt frames in the split-MAC arch) > within an AP could involve transferring it over a L3 network from the > WTP to the AC or vice-versa. If these two end-points are from multiple > different vendors, then there needs to be an agreement on the mode of > this transfer. Hence, we cannot ignore this problem in defining a CAPWAP > protocol. > Thanks > partha > > On Thu, 2004-08-12 at 10:42, Yang, Lily L wrote: > > To examine our options of architecture assumptions, let me first put > our > > my definition of data plane and control plane just to make sure we > start > > from the same page: > > > > To me, 802.11 data plane means the dath path travelled by the native > > 802.11 data frames while 802.11 control plane means the data path > > between 802.11 STA and the 802.11-awared control end point. > > > > For both Local and Split MAC, that 802.11-awared control point is AC. > So > > both architecture has the same control path: STA->WTP->AC. The > > difference is how that control messages are implemented between WTP > and > > AC: Split MAC simply tunneled the 802.11 management frames, while > Local > > MAC translated them into some other non-802.11 forms. Another > (implied) > > difference is that Split MAC largely relies on the AC to respond to > > those management frames from STA, while Local MAC relies on WTP to > > respond, but allow AC to be informed of such events as well. So the > > timing constraint may be more relaxed for local MAC. > > > > The question is on the data path. Here is my understanding so far: > > In Local MAC, the data path is between STA and WTP. From WTP, it can > be > > switched or routed locally, entirely bypassing AC. For Split MAC, My > > impression has been that the data path is between STA and WTP and AC, > > because it seems that Split MAC vendors tunnel ALL 802.11 data back to > > AC, even though I don't see why it has to be that way. Just from the > > recent discussion, some have hinted that even Split MAC can allow data > > path terminate at WTP and be "locally" switched without involving AC. > Is > > this true? Can anyone confirm more explicitly and elaborate this for > me? > > > > > > To summarize: > > Common control path: STA->WTP->AC. (but control messages between > > WTP<->AC are done diffrently) > > Local MAC data path: STA->WTP. > > Split MAC data path: STA->WTP->AC or STA->WTP (This needs to be > > clarified). > > > > My hunch is that CAPWAP protocol would have to allow the flexibility > in > > datapath, for either architecture (Split or Local). So in that case, > it > > doesn't really matter if it is Split or Local, it should allow > datapath > > to be configurable any way. In that sense, I agree with what Shankar > was > > saying here. This seems also suggest that YES, we can cleanly separate > > data plane and control plane here. But that doesn't mean any > discussion > > around data plane is out of scope -- because guess what? Why do we > need > > the control plane at the first place? To control and configure the > data > > plane! > > > > So understanding what data plane needs would drive our discussion for > > the control plane and CAPWAP. > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On Behalf Of Wijnen, Bert (Bert) > > > Sent: Thursday, August 12, 2004 2:30 AM > > > To: Shankar Narayanaswamy; Dorothy.Gellert@nokia.com > > > Cc: capwap@frascone.com > > > Subject: RE: [Capwap] Re: Data plane and control plane > > > separation in Split MAC > > > > > > > -----Original Message----- > > > > From: Shankar Narayanaswamy [mailto:wireless@shankar.org] > > > > Sent: donderdag 12 augustus 2004 05:13 > > > > To: Dorothy.Gellert@nokia.com > > > > Cc: capwap@frascone.com > > > > Subject: [Capwap] Re: Data plane and control plane > > > separation in Split > > > > MAC > > > > > > > > > > > > The parameters by which the data plane communicates such as > > > > authentication/security info, destination switch (if any) for data > > > > > frames, etc, are communicated by the control plane. Hence > > > the need for > > > > some architectural assumptions regarding the data plane even if > the > > > > focus is on the control plane. > > > > > > > > Or at least a decision on the data plane architectures to be > > > > supported. > > > > > > > So... to me that sounds that we may potentially do an IMPLIED > > > agreement on the architecture for data plane, based on the > > > capabilities we define in the standards track control and > > > provisioning protocol. > > > > > > That would be fine with me. But we should NOT get bogged down > > > in that data plane stuff, or at least that to me seems to be > > > the wrong focus. > > > > > > Bert > > > > -s > > > > > > > > Dorothy.Gellert@nokia.com wrote: > > > > > Good point. Can we have the volunteers that submitted > > > > architectures for the taxonomy draft weigh in on this issue? > > > > > > > > > > Also another point to consider is that we don't have to > > > > implement *every* AP function in the first release of the CAPWAP > > > > protocol. One of our charter goals is to start with > > > > the minimal set of functionality needed to provide control. > > > > We have a "desirable" category where we can put objectives > > > that can be > > > > met with a later release or extension. > > > > > > > > > > Dorothy > > > > > > > > > >>-----Original Message----- > > > > >>From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com]On > > > > >>Behalf Of ext Yang, Lily L > > > > >>Sent: Tuesday, August 10, 2004 6:13 PM > > > > >>To: Sudhanshu Jain; Shehzad Merchant; Shankar > > > Narayanaswamy; Abhijit > > > > >>Choudhury > > > > >>Cc: capwap@frascone.com > > > > >>Subject: RE: [Capwap] So many architectures, so little time... - > > > > > >>take 2 > > > > >> > > > > >> > > > > >>The question in my mind is: Can data plane and control plane be > > > > >>cleanly separated for Split MAC? I know it is feasible for Local > > > > MAC, but not > > > > >>sure about Split MAC. > > > > >>Any insight? > > > > >> > > > > >>-----Original Message----- > > > > >>From: capwap-admin@frascone.com > > > > [mailto:capwap-admin@frascone.com] On > > > > >>Behalf Of Sudhanshu Jain > > > > >>Sent: Tuesday, August 10, 2004 11:55 AM > > > > >>To: Shehzad Merchant; Shankar Narayanaswamy; Abhijit Choudhury > > > > >>Cc: capwap@frascone.com > > > > >>Subject: RE: [Capwap] So many architectures, so little time... - > > > > > >>take 2 > > > > >> > > > > >>I fully agree with Shehzad. We need to separate the > > > control and data > > > > >>plane. Control plane should provide the framework to use one of > > > > >>several tunneling protocol. > > > > >> > > > > >>On data plane, if we need to define a new layer2/layer3 level > > > > >>tunneling protocol, it should be separate work from > > > control protocol > > > > >>work. > > > > >> > > > > >>-Suds > > > > >> > > > > >> > > > > >>-----Original Message----- > > > > >>From: capwap-admin@frascone.com > > > > [mailto:capwap-admin@frascone.com] On > > > > >>Behalf Of Shehzad Merchant > > > > >>Sent: Tuesday, August 10, 2004 11:13 AM > > > > >>To: Shankar Narayanaswamy; Abhijit Choudhury > > > > >>Cc: capwap@frascone.com > > > > >>Subject: RE: [Capwap] So many architectures, so little time... - > > > > > >>take 2 > > > > >> > > > > >>Additionally, for data tunneling one needs a lightweight > > > mechanism > > > > >>that may not necessarily have the same requirements as that for > > > > >>control and management. For example, one would want to limit the > > > > > >>tunneling and processing overhead on data packets to a minimum. > > > > >>Control and management may be more tolerant of > > > > >>tunneling/security/etc. overhead. > > > > >>Besides, there are > > > > >>plenty of standards in place for data tunneling. We may > > > > potentially be > > > > >>able > > > > >>to leverage off that work itself without having to invent > > > > yet another > > > > >>tunneling mechanism for data. > > > > >> > > > > >>-S > > > > >> > > > > >> > > > > >>-----Original Message----- > > > > >>From: capwap-admin@frascone.com > > > > [mailto:capwap-admin@frascone.com] On > > > > >>Behalf > > > > >>Of Shankar Narayanaswamy > > > > >>Sent: Tuesday, August 10, 2004 10:30 AM > > > > >>To: Abhijit Choudhury > > > > >>Cc: capwap@frascone.com > > > > >>Subject: Re: [Capwap] So many architectures, so little time... - > > > > > >>take 2 > > > > >> > > > > >>On the first point: not necessarily. If data packets are > > > > encapsulated > > > > >>802.11 data frames, then there is no need to protect them > > > > on the wire > > > > >>any > > > > >>more than they were encrypted over the air. > > > > >> > > > > >>But control and management packets will need protection > > > > over the wired > > > > >>network and therefore possibly a different tunneling protocol. > > > > >> > > > > >>On the second point (standard way of packet exchange): yes! > > > > >> > > > > >>-s > > > > >> > > > > >>Abhijit Choudhury wrote: > > > > >> > > > > >>>The same tunneling protocol that moves control and > > > > >> > > > > >>management packets > > > > >> > > > > >>>from the WTP to the AC should be used to tunnel data > > > > >> > > > > >>packets as well. > > > > >> > > > > >> > > > > >>>We would specify message exchanges to do control, > > > provisioning and > > > > >>>capability advertisement between WTPs and the AC. But > > > all of this > > > > >>>would be within the unified CAPWAP protocol that moves > > > all packets > > > > >>>including data between the WTP and AC. Vendors currently > > > > >> > > > > >>use LWAPP, > > > > >> > > > > >>>GRE, IP and some proprietary encapsulations to achieve > > > this. This > > > > >>>group would come up with a "standard" way of doing this > exchange. > > > > >>> > > > > >>>At least that was my understanding.... > > > > >>> > > > > >>>Regards, > > > > >>>Abhijit > > > > >>> > > > > >>>-----Original Mssage----- > > > > >>>From: capwap-admin@frascone.com > > > > >> > > > > >>[mailto:capwap-admin@frascone.com] On > > > > >> > > > > >>>Behalf Of Wijnen, Bert (Bert) > > > > >>>Sent: Monday, August 09, 2004 6:14 AM > > > > >>>To: 'Yang, Lily L'; Burbank, Jack L.; Victor Lin; Bob O'Hara; > > > > >>>capwap@frascone.com > > > > >>>Subject: RE: [Capwap] So many architectures, so little > > > > >> > > > > >>time... - take > > > > >> > > > > >>>2 > > > > >>> > > > > >>> > > > > >>>Not sure who is confused... probably me... > > > > >>> > > > > >>>My understanding was/is that IF we do re-charter for CAPWAP > > > > >> > > > > >>protocol > > > > >> > > > > >>>work, that it is then a NM protocol for "Control and > > > > >> > > > > >>Provisioning" and > > > > >> > > > > >> > > > > >>>not any of the related stuff that moves the data from WTP to > AC. > > > > >>> > > > > >>>Is everybody in agreement with that understanding. > > > > >>> > > > > >>>Thanks, > > > > >>>Bert > > > > >>> > > > > >>> > > > > >>> > > > > >>>>-----Original Message----- > > > > >>>>From: Yang, Lily L [mailto:lily.l.yang@intel.com] > > > > >>>>Sent: maandag 9 augustus 2004 08:14 > > > > >>>>To: Burbank, Jack L.; Victor Lin ; Bob O'Hara ; > > > > capwap@frascone.com > > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > > >>> > > > > >>time... - take > > > > >> > > > > >>>>2 > > > > >>>> > > > > >>>> > > > > >>>>I think setting the re-charter scope to develop a single > > > > >>> > > > > >>protocol that > > > > >> > > > > >>> > > > > >>>>allows interoperability between Local and Split MAC is a > > > > reasonable > > > > >>>>tradeoff: > > > > >>>>We exclude remote MAC because the constraint it imposes is > very > > > > >>>>different from the rest and the benefit of including it is > very > > > > >>>>little. But Local and Split MAC are reasonably close and > > > > hence the > > > > >>>>effort may be incremental only. > > > > >>>>As many people noted, as of today, there is no single clear > > > > >>> > > > > >>definition > > > > >> > > > > >> > > > > >>>>of what "Local MAC" and "Split MAC" really means yet. Each > > > > >>> > > > > >>vendor has > > > > >> > > > > >>>>different definitions and some debate needs to happen so > > > > >>> > > > > >>that the WG > > > > >> > > > > >>>>can reach consensus on what exactly that means, and > > > what kinds of > > > > >>>>flexibility we want to retain within each class of > > > > >>> > > > > >>architecture, and > > > > >> > > > > >>>>what kind of differences we can to resolve and agree up > > > > front. That > > > > >>>>should also be part of the work items for the new WG -- > > > > >>> > > > > >>such agreement > > > > >> > > > > >> > > > > >>>>on the details for each architecture must be documented > > > > >>> > > > > >>somewhere, if > > > > >> > > > > >>>>not separately, then as part of the Protocol document. > > > > >>>> > > > > >>>>-----Original Message----- > > > > >>>>From: capwap-admin@frascone.com > > > > >>> > > > > >>[mailto:capwap-admin@frascone.com] On > > > > >> > > > > >>>>Behalf Of Burbank, Jack L. > > > > >>>>Sent: Thursday, August 05, 2004 12:14 PM > > > > >>>>To: 'Victor Lin '; 'Bob O'Hara '; 'capwap@frascone.com ' > > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > > >>> > > > > >>time... - take > > > > >> > > > > >>>>2 > > > > >>>> > > > > >>>>I think that interoperability between different > > > > >>> > > > > >>architectures should > > > > >> > > > > >>>>be a requirement, if not the key requirement. As was > mentioned > > > > >>>>yesterday, a goal of the IEEE is that they maintain > > > > flexibility in > > > > >>>>terms of how products and architectures are implemented. I > > > > >>> > > > > >>think we > > > > >> > > > > >>>>shouldn't do anything that is contrary to that goal (or > > > > at least we > > > > >>>>should minimize the impact). I think that the goal of > > > > >>> > > > > >>CAPWAP should > > > > >> > > > > >>>>be to retain this type of flexibility by designing a > > > > >>> > > > > >>protocol that can > > > > >> > > > > >> > > > > >>>>maintain this implementation flexibility but enable > > > > >>> > > > > >>interoperability > > > > >> > > > > >>>>between the various architecture implementations (that > > > > after all is > > > > >>>>the key problem with the deployment of these various > > > > >>> > > > > >>architectures - > > > > >> > > > > >>>>lack of interoperability). IMO, if we don't design for > > > > >>>>interoperability between the basic architecture types, it > > > > >>> > > > > >>is debatable > > > > >> > > > > >> > > > > >>>>if something useful would have been accomplished. > > > > >>>> > > > > >>>>Jack Burbank > > > > >>>> > > > > >>>>-----Original Message----- > > > > >>>>From: capwap-admin@frascone.com > > > > >>>>To: Bob O'Hara; capwap@frascone.com > > > > >>>>Sent: 8/5/2004 2:46 PM > > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > > >>> > > > > >>time... - take > > > > >> > > > > >>>>2 > > > > >>>> > > > > >>>>I agree that we can design a protocol and implement the > > > > >>> > > > > >>product that > > > > >> > > > > >>>>works all architectures. I think the question to CAPWAP is: > > > > >>>> > > > > >>>>Should we make it a requirement in CAPWAP protocol to achieve > > > > >>>>interoperability between different architectures? > > > > >>>> > > > > >>>>It is definitely doable, but I'm not sure if that is the > > > > >>> > > > > >>right thing > > > > >> > > > > >>>>to do.. > > > > >>>> > > > > >>>>Victor > > > > >>>> > > > > >>>>-----Original Message----- > > > > >>>>From: capwap-admin@frascone.com > > > > >>> > > > > >>[mailto:capwap-admin@frascone.com] On > > > > >> > > > > >>>>Behalf Of Bob O'Hara > > > > >>>>Sent: Thursday, August 05, 2004 11:43 AM > > > > >>>>To: capwap@frascone.com > > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > > >>> > > > > >>time... - take > > > > >> > > > > >>>>2 > > > > >>>> > > > > >>>>I think that interoperability will depend on two things. > > > > >>>>First, it will > > > > >>>>depend on how we define the protocol and the flexibility > > > > >>> > > > > >>for supported > > > > >> > > > > >> > > > > >>>>architectures it incorporates. Second, it will depend on what > > > > > >>>>manufacturers implement, i.e., the flexibility they build > > > > >>> > > > > >>into their > > > > >> > > > > >>>>products. > > > > >>>> > > > > >>>>I believe that it is possible to design the protocol for > > > > >>> > > > > >>the required > > > > >> > > > > >>>>flexibility. I know it is possible to implement a > > > > product with the > > > > >>>>required flexibility. > > > > >>>> > > > > >>>>-Bob O'Hara > > > > >>>> > > > > >>>> > > > > >>>>-----Original Message----- > > > > >>>>From: capwap-admin@frascone.com > > > > >>> > > > > >>[mailto:capwap-admin@frascone.com] On > > > > >> > > > > >>>>Behalf Of Abhijit Choudhury > > > > >>>>Sent: Thursday, August 05, 2004 11:32 AM > > > > >>>>To: James Kempf; Shehzad Merchant; capwap@frascone.com > > > > >>>>Cc: bwijnen@lucent.com; mmani@avaya.com; > > > david.kessens@nokia.com; > > > > >>>>Dorothy.Gellert@nokia.com; Inderpreet Singh > > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > > >>> > > > > >>time... - take > > > > >> > > > > >>>>2 > > > > >>>> > > > > >>>> > > > > >>>>It may be possible to achieve such interoperability within the > > > > > >>>>split-MAC family or within the local-MAC family. It > > > > would sbe very > > > > >>>>hard to achieve that between local and split MAC families. > > > > >>>> > > > > >>>>For example, if vendor X's WTP terminates 802.11 ctrl/mgmt > > > > >>> > > > > >>packets and > > > > >> > > > > >>> > > > > >>>>vendor Y's AC expects the 802.11 mgmt packets to come to > > > > >>> > > > > >>it, there's > > > > >> > > > > >>>>no way you can be interoperable. > > > > >>>> > > > > >>>>Or are we planning to specify ONE architecture ? > > > > >>>>The last thing IETF should do is mandate an implementation. > > > > >>>> > > > > >>>>I think a modest and reasonable goal is to come up with a > > > > protocol > > > > >>>>that allows sufficient flexbility so that vendors with > splitMAC > > > > >>>>architectures can transfer most of the information they > > > > care about > > > > >>>>between the WTP and AC. > > > > >>>> > > > > >>>>Just my $0.02 ... > > > > >>>> > > > > >>>> > > > > >>>>Abhijit Choudhury > > > > >>>> > > > > >>>> > > > > >>>>-----Original Message----- > > > > >>>>From: capwap-admin@frascone.com > > > > >>> > > > > >>[mailto:capwap-admin@frascone.com] On > > > > >> > > > > >>>>Behalf Of James Kempf > > > > >>>>Sent: Wednesday, August 04, 2004 3:29 PM > > > > >>>>To: Shehzad Merchant; capwap@frascone.com > > > > >>>>Cc: bwijnen@lucent.com; mmani@avaya.com; > > > david.kessens@nokia.com; > > > > >>>>Dorothy.Gellert@nokia.com; Inderpreet Singh > > > > >>>>Subject: Re: [Capwap] So many architectures, so little > > > > >>> > > > > >>time... - take > > > > >> > > > > >>>>2 > > > > >>>> > > > > >>>> > > > > >>>>As a potential customer, let me put it concretely. I want > > > > >>> > > > > >>to be able > > > > >> > > > > >>>>to buy my access points from Vendor X and my switch from > > > > >>> > > > > >>Vendor Y and > > > > >> > > > > >>>>plug the two together and have them work without any > > > > configuration. > > > > >>>>Also, I'd like to be able to buy switches from Vendor Y and > > > > >>> > > > > >>Vendor Z > > > > >> > > > > >>>>and be able to plug them into my network at various > > > > places and have > > > > >>>>them interoperate. > > > > >>>> > > > > >>>> jak > > > > >>>> > > > > >>>> > > > > >>>>----- Original Message ----- > > > > >>>>From: "Shehzad Merchant" > > > > >>>>To: > > > > >>>>Cc: ; ; > > > > >>>>; ; > > > > "Inderpreet > > > > >>>>Singh" > > > > >>>> > > > > >>>>Sent: Wednesday, August 04, 2004 3:19 PM > > > > >>>>Subject: RE: [Capwap] So many architectures, so little > > > > >>> > > > > >>time... - take > > > > >> > > > > >>>>2 > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>I think the implementation variations even with the > > > > split MAC may > > > > >>>>>cover a broad spectrum. As such its important to clearly > > > > >>>> > > > > >>articulate > > > > >> > > > > >>>>>what aspects > > > > >>>> > > > > >>>>of > > > > >>>> > > > > >>>> > > > > >>>>>interoperability we are targetting. Is it truly just > > > > >>>>>control/management or is it interoperability between > disparate > > > > >>>>>implementations of the split MAC, i.e. mix and match > > > > >>>> > > > > >>>>operation of WTP > > > > >>>> > > > > >>>> > > > > >>>>>and ACs of all variants within this category. > > > > >>>>> > > > > >>>>>I suspect for the latter we may have to arrive at some > > > > >>>> > > > > >>consensus on > > > > >> > > > > >>>>>what particular implementations we are targeting > > > > >>>> > > > > >>>>interoperability for. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>If so, ultimately this problem statement could become > > > > part of the > > > > >>>>>charter. > > > > >>>>> > > > > >>>>>-Shehzad > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>>-----Original Message----- > > > > >>>>>From: capwap-admin@frascone.com > > > > >>>> > > > > >>>>[mailto:capwap-admin@frascone.com] On Behalf > > > > >>>> > > > > >>>> > > > > >>>>>Of Dorothy.Gellert@nokia.com > > > > >>>>>Sent: Wednesday, August 04, 2004 11:53 AM > > > > >>>>>To: isingh@chantrynetworks.com; capwap@frascone.com > > > > >>>>>Cc: bwijnen@lucent.com; mmani@avaya.com; > > > david.kessens@nokia.com > > > > >>>>>Subject: RE: [Capwap] So many architectures, so little > > > > >>>> > > > > >>>>time... - take > > > > >>>> > > > > >>>> > > > > >>>>>2 > > > > >>>>> > > > > >>>>>I believe this is the consensus, to scope the charter to > > > > >>>> > > > > >>>>Centralized > > > > >>>> > > > > >>>> > > > > >>>>>Architecture and LocalMAC and Split MAC. > > > > >>>>> > > > > >>>>>I'll update the charter with this change after the CAPWAP > > > > >>>> > > > > >>>>WG Mtg. If > > > > >>>> > > > > >>>> > > > > >>>>>there is resistance to this idea, please post to the list. > > > > >>>>> > > > > >>>>>Regards > > > > >>>>>Dorothy > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>>>-----Original Message----- > > > > >>>>>>From: capwap-admin@frascone.com > > > > >>>>> > > > > >>>>[mailto:capwap-admin@frascone.com]On > > > > >>>> > > > > >>>> > > > > >>>>>>Behalf Of ext Inderpreet Singh > > > > >>>>>>Sent: Tuesday, August 03, 2004 9:40 PM > > > > >>>>>>To: capwap@frascone.com > > > > >>>>>>Cc: bwijnen@lucent.com; mmani@avaya.com; Kessens David > > > > >>>>>>(Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView) > > > > >>>>>>Subject: RE: [Capwap] So many architectures, so little > > > > time... - > > > > >>>>>>take 2 > > > > >>>>>> > > > > >>>>>> > > > > >>>>>>The issue(s) at hand and my opinions are: > > > > >>>>>> > > > > >>>>>>1. Do we explicitly state in the re-charter which > > > > >>>>> > > > > >>>>architecture the > > > > >>>> > > > > >>>> > > > > >>>>>>WG should consider? I think yes. I propose Centralized > > > > >>>>> > > > > >>>>architecture > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>>only. Autonomous and Distributed should be out of scope > > > > >>>>> > > > > >>>>based on the > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>>same reasons as per prior postings. > > > > >>>>>> > > > > >>>>>>2. Within Centralized do we focus on all three sub > > > > >>>>> > > > > >>>>architectures or > > > > >>>> > > > > >>>> > > > > >>>>>>a subset? Remote MAC should be excluded because if I am not > > > > >>>>>>mistaken, the connectivity constraint between the WTP and > > > > >>>>> > > > > >>>>the AC is > > > > >>>> > > > > >>>> > > > > >>>>>>"direct connect". > > > > >>>>>>That being the case and that no IP layer is involved, > > > it doesn't > > > > >>>>> > > > > >>>>seem > > > > >>>> > > > > >>>> > > > > >>>>>>clear what kind of protocol would help with > > > > interoperability. I am > > > > >>>>> > > > > >>>>>>concerned about the impact, dependencies and > > > > interaction with the > > > > >>>>>>recently constituted IEEE Study group on AP > > > > >>>>> > > > > >>>>functionality on the > > > > >>>> > > > > >>>> > > > > >>>>>>Split MAC architectures. Furthermore, there are some > > > > >>>>> > > > > >>>>pretty drastic > > > > >>>> > > > > >>>> > > > > >>>>>>differences on how the vendors have chosen to split the > > > > >>>>> > > > > >>>>mac. Those > > > > >>>> > > > > >>>> > > > > >>>>>>differences will need to be worked out before designing a > > > > >>>>> > > > > >>>>protocol. > > > > >>>> > > > > >>>> > > > > >>>>>>So, if the low hanging fruit strategy (as James > > > suggested) for > > > > >>>>>>protocol development and progress is the way to go, > > > > then I think > > > > >>>>>>prioritizing on a protocol for Local MAC is a no brainer. > > > > >>>>> > > > > >>>>So as far > > > > >>>> > > > > >>>> > > > > >>>>>>as focus, I feel we should do Local and Split and in > > > that order. > > > > >>>>>> > > > > >>>>>>3. This is not a re-chartering issue but is a > > > response to Pat's > > > > >>>>>>suggestion that a protocol that just sends the 802.11 > > > > MAC frames > > > > >>>>> > > > > >>>>>>from the AP to the AC would work. I think possibly, yes. > > > > >>>>> > > > > >>>> > > > > >>>>But again > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>>the complications of splitting the MAC in an > > > > >>>>> > > > > >>>>interoperable way will > > > > >>>> > > > > >>>> > > > > >>>>>>be an issue. Also, you may note in the draft to which > > > > >>>>> > > > > >>>>you refer, we > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>>included a capabilities exchange phase. I had thought of > > > > >>>>> > > > > >>>>including > > > > >>>> > > > > >>>> > > > > >>>>>>in the capability exchange such things as "AP supports > > > > Local MAC" > > > > >>>>>>and "AP supports Split MAC", but didn't put it in because > the > > > > >>>>>>Taxonomy work was still in progress. Now that it is > > > > pretty much > > > > >>>>>>done we could surely include that. But again...let's > > > recharter > > > > >>>>>>first. > > > > >>>>>> > > > > >>>>>>Thanks. Do people agree with 1 & 2? > > > > >>>>>> > > > > >>>>>>--- > > > > >>>>>>Inderpreet Singh > > > > >>>>>>Chantry Networks > > > > >>>>>>isingh@chantrynetworks.com > > > > >>>>>>Cell: 416-831-3705 > > > > >>>>>> > > > > >>>>>>-----Original Message----- > > > > >>>>>>From: capwap-admin@frascone.com > > > > >>>>> > > > > >>>>[mailto:capwap-admin@frascone.com] > > > > >>>> > > > > >>>> > > > > >>>>>>On Behalf Of Pat R. Calhoun > > > > >>>>>>Sent: Tuesday, August 03, 2004 6:04 PM > > > > >>>>>>To: Yang, Lily L; James Kempf; Dorothy.Gellert@nokia.com; > > > > >>>>>>capwap@frascone.com > > > > >>>>>>Cc: bwijnen@lucent.com; mmani@avaya.com; > > > david.kessens@nokia.com > > > > >>>>>>Subject: [Capwap] So many architectures, so little > > > > >>>>> > > > > >>>>time... - take 2 > > > > >>>> > > > > >>>> > > > > >>>>>>After reading Lily's response to Jim, I realize that I > > > > >>>>> > > > > >>>>fell down the > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>>same trap. Local MAC is also a centralized approach, > > > and so my > > > > >>>>>>previous response was not complete. I believe the real > > > > >>>>> > > > > >>>>question, in > > > > >>>> > > > > >>>> > > > > >>>>>>my mind, is whether we need to address either the Local > > > > >>>>> > > > > >>>>or the Split > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>>MAC architecture. > > > > >>>>>> > > > > >>>>>>Just looking at the Architecture Consideration tables (7 and > > > > >>>>>>10) in the > > > > >>>>>>specification, the > > > > >>>>>>main difference (at a high level) between both approaches > > > > >>>>> > > > > >>>>is where > > > > >>>> > > > > >>>> > > > > >>>>>>the 802.11 management terminates. For Local MAC, it's > > > > in the WTP, > > > > >>>>>>while for SPlit MAC, it's in the AC. > > > > >>>>>> > > > > >>>>>>However, looking at table 8, most Local MAC approaches > > > > share STA > > > > >>>>>>state between both the WTP and the AC. So clearly > > > there is some > > > > >>>>>>signalling protocol between both the WTP and the AC. > > > > >>>>>> > > > > >>>>>>Looking at one example of a Local MAC protocol (see > > > > >>>>>> > > > > >>>>> > > > > > > > > >>>http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt), > > > > >>> > > > > >>> > > > > >>>>>there is a protocol message > > > > >>>>>that corresponds for every 802.11 MAC management event. So > > > > >>>> > > > > >>when a STA > > > > >> > > > > >> > > > > >>>>>associates, the AP breaks the message apart and creates an > new > > > > >>>>>protocol PDU, which contains components found in the > > > association > > > > >>>>>request. I suspect that most Local MAC approaches do > > > > >>>> > > > > >>something very > > > > >> > > > > >>>>>similar. > > > > >>>>> > > > > >>>>>So if a protocol simply tunnels the 802.11 MAC management > > > > >>>> > > > > >>frames from > > > > >> > > > > >> > > > > >>>>>the WTP to the AC, it allows supports both approaches. For > > > > >>>> > > > > >>Local MAC, > > > > >> > > > > >> > > > > >>>>>they get what they want via the 802.11 frame, and this > > > > also works > > > > >>>>>fine for Split MAC, which needs access to the MAC > > > > >>>> > > > > >>management frame. > > > > >> > > > > >>>>>What would be required in such a protocol is a way for > > > the AP to > > > > >>>>>communicate whether it will be providing very specific > > > > functions - > > > > >>>>>basically a capabilities negotiation approach. > > > > >>>>> > > > > >>>>>So I do believe that there is a way to address both > > > > architectures > > > > >>>>>using a single protocol. > > > > >>>>> > > > > >>>>>Thoughts? > > > > >>>>> > > > > >>>>>PatC > > > > >>>>> > > > > >>>>>_______________________________________________ > > > > >>>>>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 > > > >>>_______________________________________________ > > > >>>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 > > > >>>_______________________________________________ > > > >>>Capwap mailing list > > > >>>Capwap@frascone.com > > > >>>http://mail.frascone.com/mailman/listinfo/capwap > > > >> > > > >> > > > >>-- > > > >>Shankar Narayanaswamy, Ph.D. > > > >>wireless@shankar.org Mobile: +1 650-387-4593 > > > >>http://www.shankar.org E-Fax: +1 253-498-8372 > > > >> > > > >>_______________________________________________ > > > >>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 > > > > > > > > > > > > > > > > > -- > > > Shankar Narayanaswamy, Ph.D. > > > wireless@shankar.org Mobile: +1 650-387-4593 > > > http://www.shankar.org E-Fax: +1 253-498-8372 > > > > > > _______________________________________________ > > > 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 > _______________________________________________ > 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 Aug 25 18:54:22 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04556 for ; Wed, 25 Aug 2004 18:54:21 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A752A217D1; Wed, 25 Aug 2004 18:39:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6557F217D4; Wed, 25 Aug 2004 18:39:09 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 15782217D4 for ; Wed, 25 Aug 2004 18:38:34 -0400 (EDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by mail.frascone.com (Postfix) with ESMTP id 1F302217D1 for ; Wed, 25 Aug 2004 18:38:32 -0400 (EDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i7PMu0Ip015163 for ; Wed, 25 Aug 2004 22:56:00 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i7PMtoMa025904 for ; Wed, 25 Aug 2004 22:55:53 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004082515531510616 for ; Wed, 25 Aug 2004 15:53:15 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 25 Aug 2004 15:53:15 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] More IETF Expert Review on rev-03... Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE01836FE4@orsmsx408> Thread-Topic: [Capwap] More IETF Expert Review on rev-03... Thread-Index: AcSDNbovEshZSRrzQyuq4A3deOmEYAHv8SUA From: "Yang, Lily L" To: X-OriginalArrivalTime: 25 Aug 2004 22:53:15.0439 (UTC) FILETIME=[4E5AFBF0:01C48AF6] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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, 25 Aug 2004 15:53:14 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable To address comment #5 below, the authors propose to replace the first = paragraph in 4.8.1 with the following three paragraphs: -------------- The survey shows clearly that the termination point for "over the air" 802.11 encryption (802.11i) can be implemented either in the WTP or in the AC. Furthermore, the 802.1x/EAP functionality is also distributed between the WTP and the AC where, in almost all cases, the AC performs the necessary functions as the authenticator in the 802.1x exchange. =20 If the STA and AC are the parties in the 4-way handshake, and the = encryption/decryption happens at the WTP, then the PTK has to be = transferred from the AC to the WTP. If the PMK is reused across multiple = WTPs, then requiring a 4-way handshake for each WTP that the station = associates to, followed by the transfer of that PTK from the AC to the = WTP, would ensure that a different PTK is used at each WTP. Since the = keying material is part of the control and provisioning of the WTPs, a secure encrypted tunnel for control frames is employed to transport the keying material. =20 In the case where the 802.11i encryption/decryption is performed in the = AC, the key exchange and state transitions occur between the AC and STA. Therefore, there is no need to transfer any crypto material between the = AC and the WTP.=20 =20 --------------- If there are no further comments on the draft, I would submit the new = revision v05 with these resolutions very soon. Thanks, Lily > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of Inderpreet Singh > Sent: Sunday, August 15, 2004 7:06 PM > To: capwap@frascone.com > Subject: RE: [Capwap] More IETF Expert Review on rev-03... >=20 > WG: >=20 > I have been asked to review the last comments on rev-03 of=20 > the Architecture Taxonomy draft. Since these comments came=20 > in towards the end of the completion of rev-04, some of the=20 > feedback was already taken care of. > Nevertheless, I have reviewed the comments and here are the=20 > proposals for resolution. One can read the rev-03 and comments at: >=20 > http://www.cs.ucla.edu/~pzerfos/draft-ietf-capwap-arch-03-comments.txt >=20 > If there are any issues, please raise them on the list. =20 > Draft rev-05 is almost done and just requires resolution to=20 > these comments. >=20 > Thanks >=20 > Inderpreet >=20 > =3D=3D=3D=3D=3D=3D=3D >=20 > Comment#1 [ Please take a look at=20 > draft-housley-cms-fw-wrap-04.txt. I would like to know if it=20 > is useful in this context. If not, how can it be adjusted to=20 > be helpful? ] >=20 > Proposed Resolution#1 - Section 2.2 - I think the scope of=20 > the cms-fw-wrap draft is more the firmware package=20 > cryptographic protection. In the context of CAPWAP what is=20 > more interesting is the firmware package transport mechanism.=20 > There was considerable discussion on this list regarding=20 > this topic and I think it is out of scope even for the=20 > taxonomy document. > Nevertheless, in the protocol design a discussion must take=20 > place as to whether firmware package transport, loading and=20 > of course cryptographic protection should be in scope or out=20 > of scope. And then, yes, cms-fw-wrap would be applicable. >=20 > Comment#2 [ This needs more meat. Today, this connection is=20 > wires, and there can be physical control over those wires. I=20 > would think that the threat described above is not a very=20 > significant one. I am........] >=20 > Proposed Resolution #2 - Section 3.2 - Security section of=20 > the Autonomous architecture. The following text was added to=20 > -04 in this area. I think it is sufficient to meet the more=20 > meat requirement. >=20 > >>> > One of the security issues in this architecture is the need=20 > for mutual authentication between the WTP and the Ethernet=20 > infrastructure. This can be ensured by existing mechanisms=20 > such as 802.1x between the WTP and the Ethernet switch it=20 > plugs into. Another critical security issue with this=20 > architecture is the very fact that the WTP is most likely not=20 > under lock and key, but does contain secret information in=20 > order to communicate with the backend systems, such as AAA,=20 > SNMP, etc. Due to the common management method used by IT=20 > personnel of pushing a "template" to all devices, theft of=20 > such a device would potentially compromise the wired network. > <<< >=20 > Comment#3 [ Not just rogue. Accidental misconfiguration=20 > needs to be considered. ] >=20 > Proposed Resolution #3 - Section 4.7 - I don't think=20 > accidental misconfiguration applies here. The point being=20 > made is that if the WTP does not authenticate the AC (thus=20 > implementing mutual authentication), then its possible that=20 > the WTP connects to an AC that it is not supposed to, ie. > Rogue AC. Now, since it is the AC that provides all the=20 > configuration to the WTP, the possibility for=20 > misconfiguration exists, but has nothing to do with the=20 > subject of authentication. Am I missing something? >=20 > Comment#4 - [ I worry about the word "push" in the previous=20 > sentence. It makes an assumption about the initiator of the=20 > communication. I think that the word "transferred" varries=20 > less baggage. ] >=20 > Proposed resolution#4 - Section 4.8.1 - Done. New text reads=20 > "the resultant cryptographic keys for the session are=20 > required to be securely transferred from the AC..." >=20 > Comment#5 - [ What about the state? Who are the parties in=20 > the 4-way handshake? If the STA and the AC are the parties=20 > in the 4-way handshake, then more than keys need to be=20 > transferred. Further, if the same key is used my more than=20 > one WTP, then there needs to be a lot of other stuff=20 > transferred to make sure that nonces are not reused. ] >=20 > Proposed Resolution#5 - Section 4.8.1 - awaiting response=20 > from Partha Narasimhan. >=20 > Comment#6 - [ Replay protection is probably important too. ] >=20 > Proposed Resolution#6 - Section 4.8.2 - Agreed. Added text.=20 > Old Text: "Confidentiality and integrity of control channel frames" > New text is: "Confidentiality, integrity and replay=20 > protection of control channel frames" >=20 > Comment#7 - [ State too. ] >=20 > Proposed Resolution#7 - Section 4.8.2 - Agreed.=20 > Old text: "Secure management of WTPs and ACs, including=20 > mechanisms for securely setting and resetting secrets." > New text is: "Secure management of WTPs and ACs, including=20 > mechanisms for securely setting and resetting secrets and state". >=20 > Comment#8 - [ You need confidentiality, integrity, and replay=20 > protection on the over the air links. Saying, that the links=20 > ought to be encrypted is not enough. ] >=20 > Proposed resolution#8 - Section 5.1 - Already changed in rev=20 > -04 on 7/25. > Further changed text to include integrity and replay protection. > Old Text: "It is often recommended that all communication=20 > between mesh nodes be encrypted, since they may carry user=20 > traffic that is not. For this reason, the operator should=20 > always encrypt mesh links, in order to fully secure the network." > New Text: "It is often recommended that all communication=20 > between mesh nodes be secured by some mechanism of=20 > confidentiality, integrity and replay protection, since they=20 > may carry user traffic that is not. For this reason, the=20 > operator should always encrypt and protect mesh links, in=20 > order to fully secure the network." >=20 > Comment#9 - [ Since the document discussed the use of=20 > IP-based protocols in some situations, I expected to see a=20 > recommendation for an IETF WG to standardize it. ] >=20 > Proposed Resolutoin #9 - Section 6 - Do we need this now that=20 > consensus has formed anyway? >=20 > Comment#10 - [ Need to add a discussion of replay. ] >=20 > Proposed Resolution #10 - Section 7 - Changed text: > Old Text: "need to be securely transported from AC to WTP;=20 > secure discovery of WTP and AC is required, mutual=20 > authentication of WTPs and AC is needed, man-in-the-middle=20 > attacks to the control channel between WTP and AC,=20 > confidentiality and integrity of control channel frames, and=20 > theft of WTPs for extraction of embedded secrets within." >=20 > New Text: "need to be securely transported from AC to WTP;=20 > secure discovery of WTP and AC is required, mutual=20 > authentication of WTPs and AC is needed, man-in-the-middle=20 > attacks to the control channel between WTP and AC,=20 > confidentiality, integrity and replay protection of control=20 > channel frames, and theft of WTPs for extraction of embedded=20 > secrets within." >=20 >=20 >=20 > --- > Inderpreet Singh > Chantry Networks > isingh@chantrynetworks.com > Cell: 416-831-3705 >=20 > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf > Of Mani, Mahalingam (Mahalingam) > Sent: Monday, August 02, 2004 10:55 PM > To: capwap@frascone.com; capwap-dt@frascone.com > Subject: [Capwap] More IETF Expert Review on rev-03... >=20 > All, >=20 > Russ Housley's review comments are inline (embedded marked=20 > with a leading [ > on column 1) to the draft. >=20 > http://www.cs.ucla.edu/~pzerfos/draft-ietf-capwap-arch-03-comments.txt >=20 > (They will also be posted to www.capwap.org website in due course). >=20 > Since -04 has been posted to WG (but not yet sent in as I-D) we can > anticipate another rev-05 to include addressing these. > Nevertheless, =A0do review -04 (and in the light of these=20 > comments as well). >=20 > Regards, > -mani >=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 Aug 25 19:24:21 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06650 for ; Wed, 25 Aug 2004 19:24:20 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2C7DB20917; Wed, 25 Aug 2004 19:09:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 26FA220C2C; Wed, 25 Aug 2004 19:09:09 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BE9AB20917 for ; Wed, 25 Aug 2004 19:08:30 -0400 (EDT) Received: from panther.cs.ucla.edu (Panther.CS.UCLA.EDU [131.179.128.25]) by mail.frascone.com (Postfix) with ESMTP id 00E71202B2 for ; Wed, 25 Aug 2004 19:08:24 -0400 (EDT) Received: from localhost (pzerfos@localhost) by panther.cs.ucla.edu (8.11.7p1+Sun/8.11.7/UCLACS-5.2) with ESMTP id i7PNNLH08853; Wed, 25 Aug 2004 16:23:21 -0700 (PDT) From: Petros Zerfos To: "Yang, Lily L" Cc: capwap@frascone.com Subject: RE: [Capwap] More IETF Expert Review on rev-03... In-Reply-To: <2AF68A477DD44C4EBCBE338C24E7A9EE01836FE4@orsmsx408> Message-ID: References: <2AF68A477DD44C4EBCBE338C24E7A9EE01836FE4@orsmsx408> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-7 Content-Transfer-Encoding: QUOTED-PRINTABLE 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, 25 Aug 2004 16:23:21 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: QUOTED-PRINTABLE The three paragraphs are fine, and provide a better organization than the single paragraph of 4.8.1 (-04 version), since they highlight the two cases. Just two comments: a) the acronyms PTK and PMK (of the 802.11i?) are not defined anywhere b) neither the 4-way handshake is described elsewhere in the text. Should we mention (reference...) the 802.11i for the above, in order to make it more clear? Or even provide definitions to make the document more self-contained? Petros On Wed, 25 Aug 2004, Yang, Lily L wrote: > To address comment #5 below, the authors propose to replace the first par= agraph in 4.8.1 with the following three paragraphs: > -------------- > > The survey shows clearly that the termination point for "over the > air" 802.11 encryption (802.11i) can be implemented either in the WTP > or in the AC. Furthermore, the 802.1x/EAP functionality is also > distributed between the WTP and the AC where, in almost all cases, > the AC performs the necessary functions as the authenticator in the > 802.1x exchange. > > If the STA and AC are the parties in the 4-way handshake, and the > encryption/decryption happens at the WTP, then the PTK has to be > transferred from the AC to the WTP. If the PMK is reused across multiple > WTPs, then requiring a 4-way handshake for each WTP that the station > associates to, followed by the transfer of that PTK from the AC to the > WTP, would ensure that a different PTK is used at each WTP. Since the > keying material is part of the control and provisioning of the WTPs, a > secure encrypted tunnel for control frames is employed to transport the > keying material. > > In the case where the 802.11i encryption/decryption is performed in the > AC, the key exchange and state transitions occur between the AC and STA. > Therefore, there is no need to transfer any crypto material between the > AC and the WTP. > > --------------- > > If there are no further comments on the draft, I would submit the new > revision v05 with these resolutions very soon. > > Thanks, > Lily > > > -----Original Message----- > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Inderpreet Singh > > Sent: Sunday, August 15, 2004 7:06 PM > > To: capwap@frascone.com > > Subject: RE: [Capwap] More IETF Expert Review on rev-03... > > > > WG: > > > > I have been asked to review the last comments on rev-03 of > > the Architecture Taxonomy draft. Since these comments came > > in towards the end of the completion of rev-04, some of the > > feedback was already taken care of. > > Nevertheless, I have reviewed the comments and here are the > > proposals for resolution. One can read the rev-03 and comments at: > > > > http://www.cs.ucla.edu/~pzerfos/draft-ietf-capwap-arch-03-comments.txt > > > > If there are any issues, please raise them on the list. > > Draft rev-05 is almost done and just requires resolution to > > these comments. > > > > Thanks > > > > Inderpreet > > > > =3D=3D=3D=3D=3D=3D=3D > > > > Comment#1 [ Please take a look at > > draft-housley-cms-fw-wrap-04.txt. I would like to know if it > > is useful in this context. If not, how can it be adjusted to > > be helpful? ] > > > > Proposed Resolution#1 - Section 2.2 - I think the scope of > > the cms-fw-wrap draft is more the firmware package > > cryptographic protection. In the context of CAPWAP what is > > more interesting is the firmware package transport mechanism. > > There was considerable discussion on this list regarding > > this topic and I think it is out of scope even for the > > taxonomy document. > > Nevertheless, in the protocol design a discussion must take > > place as to whether firmware package transport, loading and > > of course cryptographic protection should be in scope or out > > of scope. And then, yes, cms-fw-wrap would be applicable. > > > > Comment#2 [ This needs more meat. Today, this connection is > > wires, and there can be physical control over those wires. I > > would think that the threat described above is not a very > > significant one. I am........] > > > > Proposed Resolution #2 - Section 3.2 - Security section of > > the Autonomous architecture. The following text was added to > > -04 in this area. I think it is sufficient to meet the more > > meat requirement. > > > > >>> > > One of the security issues in this architecture is the need > > for mutual authentication between the WTP and the Ethernet > > infrastructure. This can be ensured by existing mechanisms > > such as 802.1x between the WTP and the Ethernet switch it > > plugs into. Another critical security issue with this > > architecture is the very fact that the WTP is most likely not > > under lock and key, but does contain secret information in > > order to communicate with the backend systems, such as AAA, > > SNMP, etc. Due to the common management method used by IT > > personnel of pushing a "template" to all devices, theft of > > such a device would potentially compromise the wired network. > > <<< > > > > Comment#3 [ Not just rogue. Accidental misconfiguration > > needs to be considered. ] > > > > Proposed Resolution #3 - Section 4.7 - I don't think > > accidental misconfiguration applies here. The point being > > made is that if the WTP does not authenticate the AC (thus > > implementing mutual authentication), then its possible that > > the WTP connects to an AC that it is not supposed to, ie. > > Rogue AC. Now, since it is the AC that provides all the > > configuration to the WTP, the possibility for > > misconfiguration exists, but has nothing to do with the > > subject of authentication. Am I missing something? > > > > Comment#4 - [ I worry about the word "push" in the previous > > sentence. It makes an assumption about the initiator of the > > communication. I think that the word "transferred" varries > > less baggage. ] > > > > Proposed resolution#4 - Section 4.8.1 - Done. New text reads > > "the resultant cryptographic keys for the session are > > required to be securely transferred from the AC..." > > > > Comment#5 - [ What about the state? Who are the parties in > > the 4-way handshake? If the STA and the AC are the parties > > in the 4-way handshake, then more than keys need to be > > transferred. Further, if the same key is used my more than > > one WTP, then there needs to be a lot of other stuff > > transferred to make sure that nonces are not reused. ] > > > > Proposed Resolution#5 - Section 4.8.1 - awaiting response > > from Partha Narasimhan. > > > > Comment#6 - [ Replay protection is probably important too. ] > > > > Proposed Resolution#6 - Section 4.8.2 - Agreed. Added text. > > Old Text: "Confidentiality and integrity of control channel frames" > > New text is: "Confidentiality, integrity and replay > > protection of control channel frames" > > > > Comment#7 - [ State too. ] > > > > Proposed Resolution#7 - Section 4.8.2 - Agreed. > > Old text: "Secure management of WTPs and ACs, including > > mechanisms for securely setting and resetting secrets." > > New text is: "Secure management of WTPs and ACs, including > > mechanisms for securely setting and resetting secrets and state". > > > > Comment#8 - [ You need confidentiality, integrity, and replay > > protection on the over the air links. Saying, that the links > > ought to be encrypted is not enough. ] > > > > Proposed resolution#8 - Section 5.1 - Already changed in rev > > -04 on 7/25. > > Further changed text to include integrity and replay protection. > > Old Text: "It is often recommended that all communication > > between mesh nodes be encrypted, since they may carry user > > traffic that is not. For this reason, the operator should > > always encrypt mesh links, in order to fully secure the network." > > New Text: "It is often recommended that all communication > > between mesh nodes be secured by some mechanism of > > confidentiality, integrity and replay protection, since they > > may carry user traffic that is not. For this reason, the > > operator should always encrypt and protect mesh links, in > > order to fully secure the network." > > > > Comment#9 - [ Since the document discussed the use of > > IP-based protocols in some situations, I expected to see a > > recommendation for an IETF WG to standardize it. ] > > > > Proposed Resolutoin #9 - Section 6 - Do we need this now that > > consensus has formed anyway? > > > > Comment#10 - [ Need to add a discussion of replay. ] > > > > Proposed Resolution #10 - Section 7 - Changed text: > > Old Text: "need to be securely transported from AC to WTP; > > secure discovery of WTP and AC is required, mutual > > authentication of WTPs and AC is needed, man-in-the-middle > > attacks to the control channel between WTP and AC, > > confidentiality and integrity of control channel frames, and > > theft of WTPs for extraction of embedded secrets within." > > > > New Text: "need to be securely transported from AC to WTP; > > secure discovery of WTP and AC is required, mutual > > authentication of WTPs and AC is needed, man-in-the-middle > > attacks to the control channel between WTP and AC, > > confidentiality, integrity and replay protection of control > > channel frames, and theft of WTPs for extraction of embedded > > secrets within." > > > > > > > > --- > > Inderpreet Singh > > Chantry Networks > > isingh@chantrynetworks.com > > Cell: 416-831-3705 > > > > -----Original Message----- > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf > > Of Mani, Mahalingam (Mahalingam) > > Sent: Monday, August 02, 2004 10:55 PM > > To: capwap@frascone.com; capwap-dt@frascone.com > > Subject: [Capwap] More IETF Expert Review on rev-03... > > > > All, > > > > Russ Housley's review comments are inline (embedded marked > > with a leading [ > > on column 1) to the draft. > > > > http://www.cs.ucla.edu/~pzerfos/draft-ietf-capwap-arch-03-comments.txt > > > > (They will also be posted to www.capwap.org website in due course). > > > > Since -04 has been posted to WG (but not yet sent in as I-D) we can > > anticipate another rev-05 to include addressing these. > > Nevertheless, =A0do review -04 (and in the light of these > > comments as well). > > > > Regards, > > -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 > -- Petros Th. Zerfos UCLA - Computer Science Department email : pzerfos@cs.ucla.edu _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Aug 25 19:54:55 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08292 for ; Wed, 25 Aug 2004 19:54:54 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 08DC3217F2; Wed, 25 Aug 2004 19:36:13 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 00AB62137E; Wed, 25 Aug 2004 19:36:09 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6FBE0217EA for ; Wed, 25 Aug 2004 19:35:05 -0400 (EDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by mail.frascone.com (Postfix) with ESMTP id 44FBA217EC for ; Wed, 25 Aug 2004 19:35:02 -0400 (EDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i7PNnUFO003605 for ; Wed, 25 Aug 2004 23:49:31 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i7PNqgMa023436 for ; Wed, 25 Aug 2004 23:52:42 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004082516500721086 for ; Wed, 25 Aug 2004 16:50:07 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 25 Aug 2004 16:50:07 -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_01C48AFE.3FD17877" Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE01836FE8@orsmsx408> Thread-Topic: More suggested change on CAPWAP Architecture Taxonomy document Thread-Index: AcSK/j/GqF7dqbr0QoO5AORFPioDGg== From: "Yang, Lily L" To: X-OriginalArrivalTime: 25 Aug 2004 23:50:07.0477 (UTC) FILETIME=[4016AA50:01C48AFE] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] More suggested change on CAPWAP Architecture Taxonomy document 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, 25 Aug 2004 16:50:07 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C48AFE.3FD17877 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In light of the following comment on CAPWAP Problem Statement, we would propose to add a new subsection in v05 of CAPWAP Taxonomy document to highlight the physical security issues for Centralized Architecture as well: ----- proposed new text --------------------------=20 4.8.3 "Physical security of WTP and AC" WTPs are often installed in locations that are difficult to secure physically in order to provide comprehensive radio coverage, while it is relatively easier to secure the AC physically. If high-value secrets, such as a RADIUS shared secret, are stored in the AC instead of WTPs, then the physical loss of an WTP does not compromise these values. Hence, the Centralized Architecture may reduce the security consequences of a stolen WTP. =20 On the other hand, concentrating all of the high-value secrets in one place makes the AC an attractive target, and so strict physical, procedural and technical controls are needed to protect the secrets. -----------end of new text ---- --------- comment from AAA doctor: on CAPWAP Problem Statement (Informational)=20 This document is very good. One additional item that could perhaps be discussed in the security considerations section is related to problem #4, securing a distributed set of access points. I think problem #4 implies that people want to move some of the tasks of the APs to the controller so that the compromise of an access point would not compromise, say, a RADIUS shared secret or perhaps not even some of the keys used to protect the link layer. Security considederations does not point this out. It does say something about looking into physical security, but perhaps it could be expanded into that as well as the assignment of security parameters to the different parts of the system.=20 ------_=_NextPart_001_01C48AFE.3FD17877 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable More suggested change on CAPWAP Architecture Taxonomy = document

In light of the following comment on = CAPWAP Problem Statement, we would propose to add a new subsection in = v05 of CAPWAP Taxonomy document to highlight the physical security = issues for Centralized Architecture as well:

----- proposed new text = --------------------------
4.8.3 "Physical security of WTP = and AC"
WTPs are often installed in = locations that are difficult to secure physically in order to provide = comprehensive radio coverage, while it is relatively easier to secure = the AC physically.  If high-value secrets, such as a RADIUS shared = secret, are stored in the AC instead of WTPs, then the physical loss of = an WTP does not compromise these values. Hence, the Centralized = Architecture may reduce the security consequences of a stolen = WTP.  

On the other hand, concentrating = all of the high-value secrets in one place makes the AC an attractive = target, and so strict physical, procedural and technical controls are = needed to protect the secrets.

-----------end of new text ----

--------- comment from AAA doctor: on = <draft-ietf-capwap-problem-statement-01.txt > CAPWAP = Problem Statement (Informational)

This document is very good. One = additional item that could perhaps be discussed in the security = considerations section is related to problem #4, securing a distributed = set of access points. I think problem #4 implies that people want to = move some of the tasks of the APs to the controller so that the = compromise of an access point would not compromise, say, a RADIUS shared = secret or perhaps not even some of the keys used to protect the link = layer. Security considederations does not point this out. It does say = something about looking into physical security, but perhaps it could be = expanded into that as well as the assignment of security parameters to = the different parts of the system.

------_=_NextPart_001_01C48AFE.3FD17877-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Aug 26 12:04:16 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14226 for ; Thu, 26 Aug 2004 12:04:16 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5190820B33; Thu, 26 Aug 2004 11:48:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5B813209B0; Thu, 26 Aug 2004 11:48:08 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7748A20A3F for ; Thu, 26 Aug 2004 11:47:46 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 7DA8B206D3 for ; Thu, 26 Aug 2004 11:47:44 -0400 (EDT) Message-ID: <001101c48b86$42b82760$536115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Yang, Lily L" , References: <2AF68A477DD44C4EBCBE338C24E7A9EE01836FE8@orsmsx408> Subject: Re: [Capwap] More suggested change on CAPWAP Architecture Taxonomy document 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: Thu, 26 Aug 2004 09:03:41 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Just a minor editorial nit... ----- Original Message ----- From: "Yang, Lily L" To: Sent: Wednesday, August 25, 2004 4:50 PM Subject: [Capwap] More suggested change on CAPWAP Architecture Taxonomy document In light of the following comment on CAPWAP Problem Statement, we would propose to add a new subsection in v05 of CAPWAP Taxonomy document to highlight the physical security issues for Centralized Architecture as well: ----- proposed new text -------------------------- 4.8.3 "Physical security of WTP and AC" WTPs are often installed in locations that are difficult to secure physically in order to provide comprehensive radio coverage, while it is relatively easier to secure the AC physically. If high-value secrets, such as a RADIUS shared secret, are stored in the AC instead of WTPs, then the physical loss of an WTP does not compromise these values. jak>>> How about "assets" instead of "values"? Hence, the Centralized Architecture may reduce the security consequences of a stolen WTP. On the other hand, concentrating all of the high-value secrets in one place makes the AC an attractive target, and so strict physical, procedural and technical controls are needed to protect the secrets. -----------end of new text ---- --------- comment from AAA doctor: on CAPWAP Problem Statement (Informational) This document is very good. One additional item that could perhaps be discussed in the security considerations section is related to problem #4, securing a distributed set of access points. I think problem #4 implies that people want to move some of the tasks of the APs to the controller so that the compromise of an access point would not compromise, say, a RADIUS shared secret or perhaps not even some of the keys used to protect the link layer. Security considederations does not point this out. It does say something about looking into physical security, but perhaps it could be expanded into that as well as the assignment of security parameters to the different parts of the system. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Aug 27 11:35:03 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10009 for ; Fri, 27 Aug 2004 11:35:02 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CF0B321DE1; Fri, 27 Aug 2004 11:17:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5AF9620D49; Fri, 27 Aug 2004 11:17:09 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8154421DDD for ; Fri, 27 Aug 2004 11:16:40 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id 865CC21D2C for ; Fri, 27 Aug 2004 11:16:37 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48C4B.6C7F12C7" Subject: RE: [Capwap] So many architectures, so little time... - take 2 Message-ID: <55749BC69138654EBBC4C50BA4F55610020C45C3@AIREMAIL.airespace.com> Thread-Topic: [Capwap] So many architectures, so little time... - take 2 Thread-Index: AcR/Bmj8yt99Q2VUTPyN1QkjwC5gbAAA9dfQAA1oxBAAAeEMEAAIOBjmAACoasIAEI6eIAMncpCW From: "Pat R. Calhoun" To: "Saravanan Govindan" , "Abhijit Choudhury" , 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, 27 Aug 2004 08:31:32 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C48C4B.6C7F12C7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Well, the local MAC implementations that I am aware of also tunnel = traffic to the AC. =20 So I believe that there is some mis-understanding on what split vs. = local means. Frankly, the differences are quite small. Where split sends up the MAC frames for = access control processing on the AC, local MAC terminates the MAC on the AP but then = creates some control message that includes all of the data that was in the MAC = message. =20 So in my opinion, local MAC increases the protocol design work because = one needs to in essence "recreate" the 802.11 MAC mgmt protocol. Further, it's not = clear how the IETF would deal with new IEEE extensions (e.g. 802.11k) because these = recreated messages would have to include new information that isn't known today - so a = CAPWAP solution would always be behind. =20 Split MAC does not suffer from this approach. =20 PatC ________________________________ From: capwap-admin@frascone.com on behalf of Saravanan Govindan Sent: Wed 8/11/2004 7:23 AM To: 'Abhijit Choudhury'; capwap@frascone.com Subject: RE: [Capwap] So many architectures, so little time... - take 2 Given the various sides to the discussion on where MAC frames are = handled, I=20 suggest making this a configuration aspect of the CAPWAP protocol. So, = the=20 choice of which MAC frames are processed where can be left till the time = of=20 initializing APs.=20 For example, when a controller initializes a local-MAC AP, it configures = one=20 instance of the CAPWAP protocol so as NOT to receive any MAC frames from = the=20 AP. Rather, the protocol instance expects to receive explicit CAPWAP=20 messages/signals from the local-MAC AP.=20 On the other hand, while initializing a split-MAC AP, another instance = of=20 the protocol is configured to receive 'some' MAC frames and 'other'=20 remaining CAPWAP messages/signals. The 'some' and 'other' parts refer to = particular split-MAC variations. The specifics of these parts can be = left=20 for refinement based on the analyses from the Architecture Taxonomy.=20 The CAPWAP protocol can then be made to work on both raw MAC frames and=20 abstracted CAPWAP messages/signals. This way, true interoperability is=20 achieved, while at the same time allowing for different designs and=20 implementations.=20 Comments? Suggestions?=20 Saravanan=20 ________________________________=20 From: capwap-admin@frascone.com = [mailto:capwap-admin@frascone.com]=20 On Behalf Of Abhijit Choudhury=20 Sent: Wednesday, August 11, 2004 2:18 PM=20 To: capwap@frascone.com=20 Subject: FW: [Capwap] So many architectures, so little time... - = take 2=20 =20 =20 One key objective that has been discussed in this group=20 is INTEROPERABILITY. It's not clear how you achieve=20 interoperability between a WTP from vendor X and an AC=20 from vendor Y, if you don't support the same protocols on=20 all three categories that you have pointed out. Sure you can=20 achieve interoperability between the two, if you support the=20 superset of all possible encapsulations, but then you are no=20 better off than you are currently. That is why there is need=20 for a standard. And it's easier to implement in hardware or=20 software=20 if there is one standard protocol instead of three.=20 =20 We really should strive towards a unified tunneling protocol for = control=20 and data, although you can have separate connections=20 for each, and different security on each.=20 =20 But if this group stays away from specifying a common=20 protocol for control/mgmt and data between the WTP=20 and AC, or specifies one and not the other,=20 there cannot be true interoperability even within=20 the split-MAC architecture family.=20 =20 Abhijit=20 ________________________________=20 From: Sudhanshu Jain=20 Sent: Tue 8/10/2004 7:19 PM=20 To: 'Yang, Lily L'; Shehzad Merchant; Shankar Narayanaswamy; = Abhijit=20 Choudhury=20 Cc: capwap@frascone.com=20 Subject: RE: [Capwap] So many architectures, so little time... - = take 2=20 =20 =20 Problem we have to solve can be classified into three = categories.=20 * Control & Management of WTP=20 * Control & Management of STA=20 * 802.11 Data=20 Since different functionalities has different requirements, it = is=20 possible to address them with separate sets of mechanism.=20 First version of CAPWAP control protocol should address first=20 functionality with provision to communicate=20 * Tunneling mechanism=20 * Information about MAC implementation (Local/Split/Centralized) = etc.=20 -Suds=20 _______________________________________________=20 Capwap mailing list=20 Capwap@frascone.com=20 http://mail.frascone.com/mailman/listinfo/capwap=20 ------_=_NextPart_001_01C48C4B.6C7F12C7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= RE: [Capwap] So many architectures, so little time... - take = 2=0A= =0A= =0A=
=0A=
Well, the = local MAC =0A= implementations that I am aware of also tunnel traffic to the = AC.
=0A=
 
=0A=
So I believe that there is = some =0A= mis-understanding on what split vs. local means. Frankly,
=0A=
the differences are quite = small. Where =0A= split sends up the MAC frames for access control
=0A=
processing on the AC, local = MAC terminates =0A= the MAC on the AP but then creates some
=0A=
control message that includes = all of the =0A= data that was in the MAC message.
=0A=
 
=0A=
So in my  opinion, local MAC increases the protocol design work because = one needs =0A= to
=0A=
in essence "recreate"  the 802.11 = MAC mgmt =0A= protocol. Further, it's not clear how the IETF
=0A=
would deal with new IEEE extensions (e.g. 802.11k) because these recreated =0A= messages
=0A=
would have to include = new information that isn't known today - so a = CAPWAP =0A= solution
=0A=
would always be = behind.
=0A=
 
=0A=
Split MAC does not suffer = from this =0A= approach.
=0A=
 
=0A=
PatC
=0A=

=0A=
=0A= From: capwap-admin@frascone.com on = behalf of =0A= Saravanan Govindan
Sent: Wed 8/11/2004 7:23 AM
To: = 'Abhijit =0A= Choudhury'; capwap@frascone.com
Subject: RE: [Capwap] So many =0A= architectures, so little time... - take 2

=0A=
=0A=

Given the various sides to the discussion on where MAC = frames =0A= are handled, I
suggest making this a = configuration =0A= aspect of the CAPWAP protocol. So, the
choice = of which =0A= MAC frames are processed where can be left till the time of =
initializing APs.

=0A=

For example, when a controller initializes a local-MAC = AP, it =0A= configures one
instance of the CAPWAP protocol = so as NOT =0A= to receive any MAC frames from the
AP. Rather, = the =0A= protocol instance expects to receive explicit CAPWAP
messages/signals from the local-MAC AP.

=0A=

On the other hand, while initializing a split-MAC AP, = another =0A= instance of
the protocol is configured to = receive 'some' =0A= MAC frames and 'other'
remaining CAPWAP =0A= messages/signals. The 'some' and 'other' parts refer to
particular split-MAC variations. The specifics of these parts = can be =0A= left
for refinement based on the analyses from = the =0A= Architecture Taxonomy.

=0A=

The CAPWAP protocol can then be made to work on both = raw MAC =0A= frames and
abstracted CAPWAP messages/signals. = This way, =0A= true interoperability is
achieved, while at = the same =0A= time allowing for different designs and
implementations. =0A=

=0A=

Comments? Suggestions?

=0A=

Saravanan

=0A=

________________________________

=0A=

        From: =0A= capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] =0A=
On Behalf Of Abhijit Choudhury =0A=
        Sent: = Wednesday, =0A= August 11, 2004 2:18 PM =
        =0A= To: capwap@frascone.com =0A=
        Subject: = FW: =0A= [Capwap] So many architectures, so little time... -
take =0A= 2
        =0A=
        =0A=
        One key = objective =0A= that has been discussed in this group =0A=
        is =0A= INTEROPERABILITY.  It's not clear how you achieve =0A=
        interoperability =0A= between a WTP from vendor X and an AC =0A=
        from vendor =0A= Y, if you don't support the same protocols on =0A=
        all three = categories =0A= that you have pointed out.  Sure you can =0A=
        achieve =0A= interoperability between the two, if you support the =0A=
        superset = of all =0A= possible encapsulations, but then you are no =0A=
        better off = than you =0A= are currently.  That is why there is need =0A=
        for a =0A= standard.   And it's easier to implement in hardware or =0A=
software =
        =0A= if there is one standard protocol instead of = three. =0A=
         =0A=
        We = really =0A= should strive towards a unified tunneling protocol for
control
        = and data, although you can have separate connections =0A=
        for each, = and =0A= different security on each. =0A=
         =0A=
        But = if this =0A= group stays away from specifying a common =0A=
        protocol = for =0A= control/mgmt and data between the WTP =0A=
        and AC, or = specifies =0A= one and not the other, =
        =0A= there cannot be true interoperability even within =0A=
        the = split-MAC =0A= architecture family. =0A=
         =0A=
        Abhijit

=0A=

________________________________

=0A=

        From: = Sudhanshu =0A= Jain
        Sent: =0A= Tue 8/10/2004 7:19 PM =
        =0A= To: 'Yang, Lily L'; Shehzad Merchant; Shankar = Narayanaswamy; =0A= Abhijit
Choudhury =0A=
        Cc: =0A= capwap@frascone.com =
        Subject: RE: [Capwap] So many architectures, so little time... = - =0A=
take 2 =
        =0A=
       

=0A=

        Problem we = have to =0A= solve can be classified into three categories.

=0A=

        * Control = & =0A= Management of WTP
        = * Control & Management of STA =0A=
        * = 802.11 Data =0A=

=0A=

        Since = different =0A= functionalities has different requirements, it is
possible to address them with separate sets of mechanism. =

=0A=

        First = version of =0A= CAPWAP control protocol should address first
functionality with provision to communicate =0A=
        * = Tunneling =0A= mechanism
        * =0A= Information about MAC implementation (Local/Split/Centralized) =
etc.

=0A=

        -Suds =


=0A=

_______________________________________________ =
Capwap mailing list
Capwap@frascone.com =0A=
http://mail.fra= scone.com/mailman/listinfo/capwap =0A=

=0A= =0A= =0A= ------_=_NextPart_001_01C48C4B.6C7F12C7-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Aug 27 11:44:29 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10759 for ; Fri, 27 Aug 2004 11:44:29 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7A58621DE9; Fri, 27 Aug 2004 11:26:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 23F9C20881; Fri, 27 Aug 2004 11:26:09 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D3B0020881 for ; Fri, 27 Aug 2004 11:25:46 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id 39D012032A for ; Fri, 27 Aug 2004 11:25:44 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48C4C.B203056E" Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC Message-ID: <55749BC69138654EBBC4C50BA4F55610020C45C5@AIREMAIL.airespace.com> Thread-Topic: [Capwap] Re: Data plane and control plane separation in Split MAC Thread-Index: AcSAT4X7Tah78f9pSZq8HvPfi1HENgL/OFCe From: "Pat R. Calhoun" To: "Wijnen, Bert (Bert)" , "Shankar Narayanaswamy" , 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, 27 Aug 2004 08:42:05 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C48C4C.B203056E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > So... to me that sounds that we may potentially do an IMPLIED = agreement=20 > on the architecture for data plane, based on the capabilities we = define=20 > in the standards track control and provisioning protocol.=20 =20 > That would be fine with me. But we should NOT get bogged down in that=20 > data plane stuff, or at least that to me seems to be the wrong focus.=20 I respectfully disagree. The data plane is tied to the control channel = because a WTP should only forward frames for a given user when it has = received approval from the AC. The AC must make higher level access = control decisions, not the WTP. PatC ------_=_NextPart_001_01C48C4C.B203056E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= RE: [Capwap] Re: Data plane and control plane separation in Split = MAC=0A= =0A= =0A=
=0A=
> So... to = me that sounds =0A= that we may potentially do an IMPLIED agreement
> on =0A= the architecture for data plane, based on the capabilities we = define =0A=
> in the standards track control and provisioning =0A= protocol.
=0A=
 
=0A=
> That would = be fine with =0A= me. But we should NOT get bogged down in that
> data =0A= plane stuff, or at least that to me seems to be the wrong focus. =0A=
=0A=

I respectfully disagree. The data plane is tied to the control = channel =0A= because a WTP should only forward frames for a given user when it has = received =0A= approval from the AC. The AC must make higher level access control = decisions, =0A= not the WTP.

=0A=

PatC

=0A= =0A= =0A= ------_=_NextPart_001_01C48C4C.B203056E-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Aug 27 13:34:32 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18202 for ; Fri, 27 Aug 2004 13:34:31 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 828B120FF5; Fri, 27 Aug 2004 13:17:15 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1295020FEE; Fri, 27 Aug 2004 13:17:12 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1C5CE20CD4 for ; Fri, 27 Aug 2004 13:16:39 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 5F6FC20BED for ; Fri, 27 Aug 2004 13:16:36 -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 i7RHOnJS029677 for ; Fri, 27 Aug 2004 12:24:49 -0500 (EST) 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 i7RHOhJS029482 for ; Fri, 27 Aug 2004 12:24:44 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48C5B.B5E7DAC0" Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC Message-ID: Thread-Topic: [Capwap] Re: Data plane and control plane separation in Split MAC Thread-Index: AcSAT4X7Tah78f9pSZq8HvPfi1HENgL/OFCeAAAuM6A= From: "Mani, Mahalingam (Mahalingam)" To: "Pat R. Calhoun" , "Wijnen, Bert (Bert)" , "Shankar Narayanaswamy" , 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, 27 Aug 2004 11:31:39 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C48C5B.B5E7DAC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Correct me if I am wrong - but Bert's assertion does not discount AC being a PDP. The assertion is w.r.t. not to deal with CAPWAP protocol enveloping or specifying how it should be encapsulated or secured. =20 -mani _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun Sent: Friday, August 27, 2004 8:42 AM To: Wijnen, Bert (Bert); Shankar Narayanaswamy; Dorothy.Gellert@nokia.com Cc: capwap@frascone.com Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC =20 > So... to me that sounds that we may potentially do an IMPLIED agreement=20 > on the architecture for data plane, based on the capabilities we define=20 > in the standards track control and provisioning protocol.=20 =20 > That would be fine with me. But we should NOT get bogged down in that=20 > data plane stuff, or at least that to me seems to be the wrong focus.=20 I respectfully disagree. The data plane is tied to the control channel because a WTP should only forward frames for a given user when it has received approval from the AC. The AC must make higher level access control decisions, not the WTP. PatC ------_=_NextPart_001_01C48C5B.B5E7DAC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Capwap] Re: Data plane and control plane separation in Split = MAC

Correct me if I am wrong – = but Bert’s assertion does not discount AC being a PDP. The assertion is w.r.t. not = to deal with

CAPWAP protocol enveloping or = specifying how it should be encapsulated or secured.

 

-mani

From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun
Sent: Friday, August 27, = 2004 8:42 AM
To: Wijnen, Bert (Bert); = Shankar Narayanaswamy; Dorothy.Gellert@nokia.com
Cc: = capwap@frascone.com
Subject: RE: [Capwap] Re: = Data plane and control plane separation in Split = MAC

 

> So... to me that sounds that we may = potentially do an IMPLIED agreement
> on the architecture for data plane, = based on the capabilities we define
> in the standards track control and = provisioning protocol.

 

> That would be fine with me. But we = should NOT get bogged down in that
> data plane stuff, or at least that to me = seems to be the wrong focus.

I respectfully disagree. The data plane is tied to the control channel = because a WTP should only forward frames for a given user when it has received = approval from the AC. The AC must make higher level access control decisions, not = the WTP.

PatC

------_=_NextPart_001_01C48C5B.B5E7DAC0-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Aug 27 14:17:34 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21086 for ; Fri, 27 Aug 2004 14:17:33 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 433E221851; Fri, 27 Aug 2004 14:02:13 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 125E12157F; Fri, 27 Aug 2004 14:02:10 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AE4112157F for ; Fri, 27 Aug 2004 14:01:09 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id 2F03720220 for ; Fri, 27 Aug 2004 14:01:07 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48C62.6744FB31" Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC Message-ID: <55749BC69138654EBBC4C50BA4F55610020C45CC@AIREMAIL.airespace.com> Thread-Topic: [Capwap] Re: Data plane and control plane separation in Split MAC Thread-Index: AcSAT4X7Tah78f9pSZq8HvPfi1HENgL/OFCeAAAuM6AABUVnhQ== From: "Pat R. Calhoun" To: "Mani, Mahalingam (Mahalingam)" , "Wijnen, Bert (Bert)" , "Shankar Narayanaswamy" , 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, 27 Aug 2004 11:18:10 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C48C62.6744FB31 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm certainly not stating that L2TP is the right approach here, so my = point was not whether an AC should be a PDP. My point was that *like* L2TP, there has to be very close = coordination between the data and control path. These are not just open static GRE tunnels - there is policy = enforcement and access control required at the WTP, and this needs to be enforced by the AC. =20 PatC ________________________________ From: Mani, Mahalingam (Mahalingam) [mailto:mmani@avaya.com] Sent: Fri 8/27/2004 10:31 AM To: Pat R. Calhoun; Wijnen, Bert (Bert); Shankar Narayanaswamy; = Dorothy.Gellert@nokia.com Cc: capwap@frascone.com Subject: RE: [Capwap] Re: Data plane and control plane separation in = Split MAC Correct me if I am wrong - but Bert's assertion does not discount AC = being a PDP. The assertion is w.r.t. not to deal with CAPWAP protocol enveloping or specifying how it should be encapsulated = or secured. =20 -mani ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Pat R. Calhoun Sent: Friday, August 27, 2004 8:42 AM To: Wijnen, Bert (Bert); Shankar Narayanaswamy; = Dorothy.Gellert@nokia.com Cc: capwap@frascone.com Subject: RE: [Capwap] Re: Data plane and control plane separation in = Split MAC =20 > So... to me that sounds that we may potentially do an IMPLIED = agreement=20 > on the architecture for data plane, based on the capabilities we = define=20 > in the standards track control and provisioning protocol.=20 =20 > That would be fine with me. But we should NOT get bogged down in that=20 > data plane stuff, or at least that to me seems to be the wrong focus.=20 I respectfully disagree. The data plane is tied to the control channel = because a WTP should only forward frames for a given user when it has = received approval from the AC. The AC must make higher level access = control decisions, not the WTP. PatC ------_=_NextPart_001_01C48C62.6744FB31 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= =0A= RE: [Capwap] Re: Data plane and control plane separation in Split = MAC=0A= =0A= =0A= =0A= =0A= =0A=
=0A=
I'm certainly = not stating =0A= that L2TP is the right approach here, so my point was not whether an AC = should =0A= be a
=0A=
PDP. My point was that *like* = L2TP, there =0A= has to be very close coordination between the data and = control
=0A=
path. These are not just open = static GRE =0A= tunnels - there is policy enforcement and access control = required
=0A=
at the WTP, and this needs to = be enforced =0A= by the AC.
=0A=
 
=0A=
PatC
=0A=

=0A=
=0A= From: Mani, Mahalingam (Mahalingam) =0A= [mailto:mmani@avaya.com]
Sent: Fri 8/27/2004 10:31 = AM
To: =0A= Pat R. Calhoun; Wijnen, Bert (Bert); Shankar Narayanaswamy; =0A= Dorothy.Gellert@nokia.com
Cc: = capwap@frascone.com
Subject: =0A= RE: [Capwap] Re: Data plane and control plane separation in Split =0A= MAC

=0A=
=0A=
=0A=

Correct me if = I am =0A= wrong – but Bert’s assertion does not discount AC being a = PDP. The assertion is =0A= w.r.t. not to deal with

=0A=

CAPWAP = protocol =0A= enveloping or specifying how it should be encapsulated or =0A= secured.

=0A=

 

=0A=

-mani

=0A=
=0A=
=0A=
=0A=
=0A=

From: =0A= capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. = Calhoun
Sent: Friday, August 27, 2004 = 8:42 =0A= AM
To: Wijnen, Bert = (Bert); =0A= Shankar Narayanaswamy; Dorothy.Gellert@nokia.com
Cc: = capwap@frascone.com
Subject: RE: [Capwap] Re: Data = plane and =0A= control plane separation in Split MAC

=0A=

 

=0A=
=0A=
=0A=

> So... to me = that sounds =0A= that we may potentially do an IMPLIED agreement
> on the =0A= architecture for data plane, based on the capabilities we =0A= define
> in the =0A= standards track control and provisioning protocol. =0A=

=0A=
=0A=

 

=0A=
=0A=

> That would be = fine with =0A= me. But we should NOT get bogged down in that =0A=
> data plane = stuff, or at =0A= least that to me seems to be the wrong focus. =0A=

=0A=

I =0A= respectfully disagree. The data plane is tied to the control channel = because a =0A= WTP should only forward frames for a given user when it has received = approval =0A= from the AC. The AC must make higher level access control decisions, not = the =0A= WTP.

=0A=

PatC

=0A= =0A= =0A= =0A= ------_=_NextPart_001_01C48C62.6744FB31-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Aug 27 14:36:25 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22460 for ; Fri, 27 Aug 2004 14:36:24 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 19C3820FFE; Fri, 27 Aug 2004 14:21:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DF9D6215C7; Fri, 27 Aug 2004 14:21:08 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8CCE020FFE for ; Fri, 27 Aug 2004 14:20:41 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id 7FC9C215C7 for ; Fri, 27 Aug 2004 14:20:39 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48C65.2243B561" Subject: RE: [Capwap] More IETF Expert Review on rev-03... Message-ID: <55749BC69138654EBBC4C50BA4F55610020C45D7@AIREMAIL.airespace.com> Thread-Topic: [Capwap] More IETF Expert Review on rev-03... Thread-Index: AcSDNbovEshZSRrzQyuq4A3deOmEYAHv8SUAAFvTboM= From: "Pat R. Calhoun" To: "Yang, Lily L" , 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, 27 Aug 2004 11:36:42 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C48C65.2243B561 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My comments below. =20 PatC ________________________________ From: capwap-admin@frascone.com on behalf of Yang, Lily L Sent: Wed 8/25/2004 3:53 PM To: capwap@frascone.com Subject: RE: [Capwap] More IETF Expert Review on rev-03... To address comment #5 below, the authors propose to replace the first = paragraph in 4.8.1 with the following three paragraphs: --------------=20 The survey shows clearly that the termination point for "over the=20 air" 802.11 encryption (802.11i) can be implemented either in the WTP=20 or in the AC. Furthermore, the 802.1x/EAP functionality is also=20 distributed between the WTP and the AC where, in almost all cases,=20 the AC performs the necessary functions as the authenticator in the=20 802.1x exchange. =20 If the STA and AC are the parties in the 4-way handshake, and the = encryption/decryption happens at the WTP, then the PTK has to be = transferred from the AC to the WTP. If the PMK is reused across multiple = WTPs, then requiring a 4-way handshake for each WTP that the station = associates to, followed by the transfer of that PTK from the AC to the = WTP, would ensure that a different PTK is used at each WTP. Since the = keying material is part of the control and provisioning of the WTPs, a = secure encrypted tunnel for control frames is employed to transport the = keying material. =20 Although the key exchange occurs between the supplicant and the = authenticator (which is the AC), the supplicant has no way of knowing = that multiple BSSIDs share a single authenticator. So this is not quite = as simple as one would hope. This is also (in part) one of the tasks = that the 802.11r Tg is looking at solving (I believe). I don't think = this is a CAPWAP problem. In the case where the 802.11i encryption/decryption is performed in the = AC, the key exchange and state transitions occur between the AC and STA. = Therefore, there is no need to transfer any crypto material between the = AC and the WTP.=20 But there are cases were you need to encrypt close to the air, for = instance to provide 802.11e. PatC =20 ------_=_NextPart_001_01C48C65.2243B561 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= RE: [Capwap] More IETF Expert Review on rev-03...=0A= =0A= =0A=
=0A=
My comments =0A= below.
=0A=
 
=0A=
PatC
=0A=

=0A=
=0A= From: capwap-admin@frascone.com on = behalf of =0A= Yang, Lily L
Sent: Wed 8/25/2004 3:53 PM
To: =0A= capwap@frascone.com
Subject: RE: [Capwap] More IETF Expert = Review on =0A= rev-03...

=0A=
=0A=

To address comment #5 below, the authors propose to = replace the =0A= first paragraph in 4.8.1 with the following three paragraphs:

=0A=

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

=0A=

The survey shows clearly that the termination point = for "over =0A= the
air" 802.11 encryption (802.11i) can be = implemented =0A= either in the WTP
or in the AC.  = Furthermore, the =0A= 802.1x/EAP functionality is also
distributed = between the =0A= WTP and the AC where, in almost all cases,
the = AC =0A= performs the necessary functions as the authenticator in the =
802.1x exchange. 

=0A=

If the STA and AC are the parties in the 4-way = handshake, and =0A= the encryption/decryption happens at the WTP, then the PTK has to be = transferred =0A= from the AC to the WTP. If the PMK is reused across multiple WTPs, then =0A= requiring a 4-way handshake for each WTP that the station associates to, =0A= followed by the transfer of that PTK from the AC to the WTP, would = ensure that a =0A= different PTK is used at each WTP.  Since the keying material is = part of =0A= the control and provisioning of the WTPs, a secure = encrypted =0A= tunnel for control frames is employed to transport the =0A= keying material. 

=0A=

<PRC> Although the key exchange occurs between = the =0A= supplicant and the authenticator (which is the AC), the supplicant has = no way of =0A= knowing that multiple BSSIDs share a single authenticator. So this is = not quite =0A= as simple as one would hope. This is also (in part) one of the tasks = that the =0A= 802.11r Tg is looking at solving (I believe). I don't think this is a = CAPWAP =0A= problem.

=0A=

In the case where the 802.11i encryption/decryption is = performed =0A= in the AC, the key exchange and state transitions occur between the AC = and STA. =0A= Therefore, there is no need to transfer any crypto = material =0A= between the AC and the WTP.

=0A=

<PRC> But there are cases were you need to = encrypt =0A= close to the air, for instance to provide 802.11e.

=0A=
PatC
=0A=
 
=0A= =0A= =0A= ------_=_NextPart_001_01C48C65.2243B561-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Aug 27 14:42:26 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23134 for ; Fri, 27 Aug 2004 14:42:25 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3CEB220DB1; Fri, 27 Aug 2004 14:27:13 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0F1D120FFB; Fri, 27 Aug 2004 14:27:09 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2ED1220DB1 for ; Fri, 27 Aug 2004 14:26:04 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 2D00C20D23 for ; Fri, 27 Aug 2004 14:26:02 -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 i7RIYFJS026285 for ; Fri, 27 Aug 2004 13:34:16 -0500 (EST) 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 i7RIYEJS026255 for ; Fri, 27 Aug 2004 13:34:15 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48C65.6CF7221C" Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC Message-ID: Thread-Topic: [Capwap] Re: Data plane and control plane separation in Split MAC Thread-Index: AcSAT4X7Tah78f9pSZq8HvPfi1HENgL/OFCeAAAuM6AABUVnhQAAkAhA From: "Mani, Mahalingam (Mahalingam)" To: "Pat R. Calhoun" , "Wijnen, Bert (Bert)" , "Shankar Narayanaswamy" , 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, 27 Aug 2004 12:41:12 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C48C65.6CF7221C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pat, =20 _____ =20 From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]=20 Sent: Friday, August 27, 2004 11:18 AM To: Mani, Mahalingam (Mahalingam); Wijnen, Bert (Bert); Shankar Narayanaswamy; Dorothy.Gellert@nokia.com Cc: capwap@frascone.com Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC =20 [Mani, Mahalingam (Mahalingam)] [....] My point was that *like* L2TP, there has to be very close coordination between the data and control path. These are not just open static GRE tunnels - there is policy enforcement and access control required at the WTP, and this needs to be enforced by the AC. [Mani, Mahalingam (Mahalingam)] I tend to agree completely. I did not see that being ruled out - actually is well within scope of CAPWAP. =20 I will let Bert comment if he implied otherwise - I think not. =20 [Mani, Mahalingam (Mahalingam)] -mani PatC =20 _____ =20 From: Mani, Mahalingam (Mahalingam) [mailto:mmani@avaya.com] Sent: Fri 8/27/2004 10:31 AM To: Pat R. Calhoun; Wijnen, Bert (Bert); Shankar Narayanaswamy; Dorothy.Gellert@nokia.com Cc: capwap@frascone.com Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC Correct me if I am wrong - but Bert's assertion does not discount AC being a PDP. The assertion is w.r.t. not to deal with CAPWAP protocol enveloping or specifying how it should be encapsulated or secured. =20 -mani _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun Sent: Friday, August 27, 2004 8:42 AM To: Wijnen, Bert (Bert); Shankar Narayanaswamy; Dorothy.Gellert@nokia.com Cc: capwap@frascone.com Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC =20 > So... to me that sounds that we may potentially do an IMPLIED agreement=20 > on the architecture for data plane, based on the capabilities we define=20 > in the standards track control and provisioning protocol.=20 =20 > That would be fine with me. But we should NOT get bogged down in that=20 > data plane stuff, or at least that to me seems to be the wrong focus.=20 I respectfully disagree. The data plane is tied to the control channel because a WTP should only forward frames for a given user when it has received approval from the AC. The AC must make higher level access control decisions, not the WTP. PatC ------_=_NextPart_001_01C48C65.6CF7221C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Capwap] Re: Data plane and control plane separation in Split = MAC

Pat,

 

From: Pat = R. Calhoun [mailto:pcalhoun@airespace.com]
Sent: Friday, August 27, = 2004 11:18 AM
To: Mani, Mahalingam (Mahalingam); Wijnen, Bert (Bert); Shankar Narayanaswamy; Dorothy.Gellert@nokia.com
Cc: = capwap@frascone.com
Subject: RE: [Capwap] Re: = Data plane and control plane separation in Split = MAC

 

[Mani, = Mahalingam (Mahalingam)] [….]= My point was that *like* L2TP, there has to be very close coordination between = the data and control

path. These are not just open static GRE tunnels - = there is policy enforcement and access control = required

at the WTP, and this needs to be enforced by the = AC.

[Mani, = Mahalingam (Mahalingam)] I tend to agree completely. I did not see that being ruled = out – actually is well within scope of = CAPWAP.

 

I will let Bert comment if he implied otherwise = – I think not.

 

[Mani, = Mahalingam (Mahalingam)] -mani

PatC

 

From: Mani, Mahalingam (Mahalingam) [mailto:mmani@avaya.com]
Sent: Fri 8/27/2004 10:31 = AM
To: Pat R. Calhoun; = Wijnen, Bert (Bert); Shankar Narayanaswamy; Dorothy.Gellert@nokia.com
Cc: = capwap@frascone.com
Subject: RE: [Capwap] Re: = Data plane and control plane separation in Split = MAC

Correct me if I am wrong – = but Bert’s assertion does not discount AC being a PDP. The assertion = is w.r.t. not to deal with

CAPWAP protocol enveloping or = specifying how it should be encapsulated or secured.

 

-mani

From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun
Sent: Friday, August 27, = 2004 8:42 AM
To: Wijnen, Bert (Bert); = Shankar Narayanaswamy; Dorothy.Gellert@nokia.com
Cc: = capwap@frascone.com
Subject: RE: [Capwap] Re: = Data plane and control plane separation in Split = MAC

 

> So... to me that sounds that we may = potentially do an IMPLIED agreement
> on the architecture for data plane, = based on the capabilities we define
> in the standards track control and = provisioning protocol.

 

> That would be fine with me. But we = should NOT get bogged down in that
> data plane stuff, or at least that to me = seems to be the wrong focus.

I respectfully disagree. The data plane is tied to the control channel = because a WTP should only forward frames for a given user when it has received = approval from the AC. The AC must make higher level access control decisions, not = the WTP.

PatC

------_=_NextPart_001_01C48C65.6CF7221C-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Aug 27 15:47:05 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29487 for ; Fri, 27 Aug 2004 15:47:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BA59C21DF8; Fri, 27 Aug 2004 15:28:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5289021851; Fri, 27 Aug 2004 15:28:09 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 67E4920D47 for ; Fri, 27 Aug 2004 15:26:49 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.frascone.com (Postfix) with ESMTP id 20A73205C1 for ; Fri, 27 Aug 2004 15:26:47 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29197; Fri, 27 Aug 2004 15:41:55 -0400 (EDT) Message-Id: <200408271941.PAA29197@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: capwap@frascone.com From: Internet-Drafts@ietf.org X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] I-D ACTION:draft-ietf-capwap-arch-05.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: Fri, 27 Aug 2004 15:41:55 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Control And Provisioning of Wireless Access Points Working Group of the IETF. Title : Architecture Taxonomy for Control and Provisioning of Wireless Access Points(CAPWAP) Author(s) : L. Yang, et al. Filename : draft-ietf-capwap-arch-05.txt Pages : 42 Date : 2004-8-27 This document provides a taxonomy of the architectures employed in the existing IEEE 802.11 products in the market, by analyzing WLAN (Wireless LAN) functions and services and describing the different variants in distributing these functions and services among the architectural entities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-capwap-arch-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-capwap-arch-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-capwap-arch-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-8-27151121.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-capwap-arch-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-capwap-arch-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-27151121.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Aug 27 17:54:27 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13950 for ; Fri, 27 Aug 2004 17:54:27 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 911DF20BE4; Fri, 27 Aug 2004 17:39:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6F73D21021; Fri, 27 Aug 2004 17:39:09 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2BE392101D for ; Fri, 27 Aug 2004 17:38:42 -0400 (EDT) Received: from orsfmr001.jf.intel.com (fmr12.intel.com [134.134.136.15]) by mail.frascone.com (Postfix) with ESMTP id 3B64920F66 for ; Fri, 27 Aug 2004 17:38:40 -0400 (EDT) Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i7RLraZI026378 for ; Fri, 27 Aug 2004 21:53:43 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i7RLkO69020125 for ; Fri, 27 Aug 2004 21:47:26 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004082714533722938 for ; Fri, 27 Aug 2004 14:53:37 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 14:53:37 -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: <2AF68A477DD44C4EBCBE338C24E7A9EE01837012@orsmsx408> Thread-Topic: draft-ietf-capwap-arch-05.txt ready for WG Last Call Thread-Index: AcSMbrd3l2wzA8L8TKaJopW02T/5swAEVBQA From: "Yang, Lily L" To: X-OriginalArrivalTime: 27 Aug 2004 21:53:37.0162 (UTC) FILETIME=[4E5CBEA0:01C48C80] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] draft-ietf-capwap-arch-05.txt ready for WG Last Call 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, 27 Aug 2004 14:53:36 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi, all=20 We now have v05 of the CAPWAP Architecture Taxonomy draft submitted to the IETF repository. I believe this revision incorporated ALL the comments we received from IEEE and IETF. A detailed change log can be found below. Among all the people who helped to pull this revision together, I want to especially thank Inderpreet who spent time and effort to resolve comments on the security section, which is the main reason for this revision. Chairs: I think we are ready for WG Last Call on this document.=20 Thank you all, Lily --------- Change log from v04 to v05 -------- 1) 4.8.1:"Client Data Security" [change reason]First paragrah is expanded into 3 paragraphs to discuss the two different cases in more details. [old]=20 The survey shows clearly that the termination point for "over the air" 802.11 encryption (802.11i) can be implemented either in the WTP or in the AC. Furthermore, the 802.1x/EAP functionality is also distributed between the WTP and the AC where, in almost all cases, the AC performs the necessary functions as the authenticator in the 802.1x exchange. If the encryption is done at the WTPs, the resultant cryptographic keys for the session are required to be securely pushed from the AC to the WTP. Since this keying material is part of the control and provisioning of the WTPs, a secure encrypted tunnel for control frames is employed to transport the keying material. In the case where the 802.11i encryption/decryption is performed in the AC, the authentication and key management is also fully performed in the AC.=20 [new] The survey shows clearly that the termination point for "over the air" 802.11 encryption [5] can be implemented either in the WTP or in the AC. Furthermore, the 802.1X/EAP [7] functionality is also distributed between the WTP and the AC where, in almost all cases, the AC performs the necessary functions as the authenticator in the 802.1x exchange. If the STA and AC are the parties in the 4-way handshake (defined in [5]), and the encryption/decryption happens at the WTP, then the PTK (Pairwise Transient Key) has to be transferred from the AC to the WTP. If the PMK (Pairwise Master Key) is reused across multiple WTPs, then requiring a 4-way handshake for each WTP that the station associates to, followed by the transfer of that PTK from the AC to the WTP, would ensure that a different PTK is used at each WTP. Since the keying material is part of the control and provisioning of the WTPs, a secure encrypted tunnel for control frames is employed to transport the keying material. In the case where the 802.11i encryption/decryption is performed in the AC, the key exchange and state transitions occur between the AC and STA. Therefore, there is no need to transfer any crypto material between the AC and the WTP. 2) 4.8.2 "Security of control channel between WTP and AC" [change reason] security state should also be included. [old] "Secure management of WTPs and ACs, including mechanisms for securely setting and resetting secrets." [new]"Secure management of WTPs and ACs, including mechanisms for securely setting and resetting secrets and state". 3) A new subsection is added to address the physical security issue more explicitly: [new addition] 4.8.3 "Physical Security of WTPs and Acs"=20 In order to provide comprehensive radio coverage, WTPs are often installed in locations that are difficult to secure physically; while it is relatively easier to secure the AC physically. If high-value secrets, such as a RADIUS shared secret, are stored in the AC instead of WTPs, then the physical loss of an WTP does not compromise these secrets. Hence, the Centralized Architecture may reduce the security consequences of a stolen WTP. On the other hand, concentrating all of the high-value secrets in one place makes the AC an attractive target, so strict physical, procedural and technical controls are needed to protect the secrets. 4) 5.1 - include integrity and replay protection. [old] "It is often recommended that all communication between mesh nodes be encrypted, since they may carry user traffic that is not. For this reason, the operator should always encrypt mesh links, in order to fully secure the network." [new] "It is often recommended that all communication between mesh nodes be secured by some mechanism of confidentiality, integrity and replay protection, since they may carry user traffic that is not. For this reason, the operator should always encrypt and protect mesh links, in order to fully secure the network." 5) Reorgnanization of Section 5: structure the existing content into two subsections: 5.1 "Common Characteristics" and 5.2 "Security". The content basically stays the same, except that integrity and replay protection is more explicitly called out in the security subsection. 6) 7 "Security Considerations" [change reason] add a discussion of replay.=20 [old] "need to be securely transported from AC to WTP; secure discovery of WTP and AC is required, mutual authentication of WTPs and AC is needed, man-in-the-middle attacks to the control channel between WTP and AC, confidentiality and integrity of control channel frames, and theft of WTPs for extraction of embedded secrets within." [new] "need to be securely transported from AC to WTP; secure discovery of WTP and AC is required, mutual authentication of WTPs and AC is needed, man-in-the-middle attacks to the control channel between WTP and AC, confidentiality, integrity and replay protection of control channel frames, and theft of WTPs for extraction of embedded secrets within." ---------- end of v05 change log ---------------------- =20 > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of=20 > Internet-Drafts@ietf.org > Sent: Friday, August 27, 2004 12:42 PM > To: i-d-announce@ietf.org > Cc: capwap@frascone.com > Subject: [Capwap] I-D ACTION:draft-ietf-capwap-arch-05.txt >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Control And Provisioning of=20 > Wireless Access Points Working Group of the IETF. >=20 > Title : Architecture Taxonomy for Control and=20 > Provisioning of=20 > Wireless Access Points(CAPWAP) > Author(s) : L. Yang, et al. > Filename : draft-ietf-capwap-arch-05.txt > Pages : 42 > Date : 2004-8-27 > =09 > This document provides a taxonomy of the architectures employed in > the existing IEEE 802.11 products in the market, by analyzing WLAN > (Wireless LAN) functions and services and describing the different > variants in distributing these functions and services among the > architectural entities. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-capwap-arch-05.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message. =20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then > "get draft-ietf-capwap-arch-05.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-capwap-arch-05.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sat Aug 28 07:50:33 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10326 for ; Sat, 28 Aug 2004 07:50:31 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0AAEA2163B; Sat, 28 Aug 2004 07:35:14 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 759E3210DF; Sat, 28 Aug 2004 07:35:10 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 019691FEF9 for ; Sat, 28 Aug 2004 07:34:24 -0400 (EDT) Received: from hoemail1.lucent.com (hoemail1.lucent.com [192.11.226.161]) by mail.frascone.com (Postfix) with ESMTP id 2053B210BA for ; Sat, 28 Aug 2004 07:34:22 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i7SBnWU3000096 for ; Sat, 28 Aug 2004 06:49:33 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sat, 28 Aug 2004 13:49:31 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550516EEB1@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Mani, Mahalingam (Mahalingam)" , "Pat R. Calhoun" , "Wijnen, Bert (Bert)" , Shankar Narayanaswamy , Dorothy.Gellert@nokia.com Cc: capwap@frascone.com Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48CF5.13880918" 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, 28 Aug 2004 13:49:29 +0200 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_01C48CF5.13880918 Content-Type: text/plain Sorry, but I guess I do not exactly understand (yet) what you are talking about. If you tell me that WTP to AC communication is over a standard XXX (for example GRE) tunnel, then, I guess/think that it is fine to make such a statement and to have management/control objects/items to be communicated over/with the CAPWAP protocol. If you tell me that we must go down the path of specifying how data plane material gets encapsulated on an XXX (whichever) tunnel, then I (personally) do not believe that that would be in scope for the CAPWAP WG. Does that help? Thanks, Bert -----Original Message----- From: Mani, Mahalingam (Mahalingam) [mailto:mmani@avaya.com] Sent: Friday, August 27, 2004 20:41 To: Pat R. Calhoun; Wijnen, Bert (Bert); Shankar Narayanaswamy; Dorothy.Gellert@nokia.com Cc: capwap@frascone.com Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC Pat, _____ From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Friday, August 27, 2004 11:18 AM To: Mani, Mahalingam (Mahalingam); Wijnen, Bert (Bert); Shankar Narayanaswamy; Dorothy.Gellert@nokia.com Cc: capwap@frascone.com Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC [Mani, Mahalingam (Mahalingam)] [....] My point was that *like* L2TP, there has to be very close coordination between the data and control path. These are not just open static GRE tunnels - there is policy enforcement and access control required at the WTP, and this needs to be enforced by the AC. [Mani, Mahalingam (Mahalingam)] I tend to agree completely. I did not see that being ruled out - actually is well within scope of CAPWAP. I will let Bert comment if he implied otherwise - I think not. [Mani, Mahalingam (Mahalingam)] -mani PatC _____ From: Mani, Mahalingam (Mahalingam) [mailto:mmani@avaya.com] Sent: Fri 8/27/2004 10:31 AM To: Pat R. Calhoun; Wijnen, Bert (Bert); Shankar Narayanaswamy; Dorothy.Gellert@nokia.com Cc: capwap@frascone.com Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC Correct me if I am wrong - but Bert's assertion does not discount AC being a PDP. The assertion is w.r.t. not to deal with CAPWAP protocol enveloping or specifying how it should be encapsulated or secured. -mani _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun Sent: Friday, August 27, 2004 8:42 AM To: Wijnen, Bert (Bert); Shankar Narayanaswamy; Dorothy.Gellert@nokia.com Cc: capwap@frascone.com Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC > So... to me that sounds that we may potentially do an IMPLIED agreement > on the architecture for data plane, based on the capabilities we define > in the standards track control and provisioning protocol. > That would be fine with me. But we should NOT get bogged down in that > data plane stuff, or at least that to me seems to be the wrong focus. I respectfully disagree. The data plane is tied to the control channel because a WTP should only forward frames for a given user when it has received approval from the AC. The AC must make higher level access control decisions, not the WTP. PatC ------_=_NextPart_001_01C48CF5.13880918 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Capwap] Re: Data plane and control plane separation in = Split MAC
Sorry,=20 but I guess I do not exactly understand (yet) what you are talking=20 about.
 
If you=20 tell me that WTP to AC communication is over a standard XXX (for = example GRE)=20 tunnel,
then,=20 I guess/think that it is fine to make such a  statement and to = have=20 management/control
objects/items to be communicated over/with the = CAPWAP=20 protocol.
 
If you=20 tell me that we must go down the path of specifying how data plane = material gets=20 encapsulated
on an=20 XXX (whichever) tunnel, then I (personally) do not believe that that = would be in=20 scope for
the=20 CAPWAP WG.
 
Does=20 that help?

Thanks, Bert

-----Original Message-----
From: Mani, Mahalingam=20 (Mahalingam) [mailto:mmani@avaya.com]
Sent: Friday, August = 27, 2004=20 20:41
To: Pat R. Calhoun; Wijnen, Bert (Bert); Shankar=20 Narayanaswamy; Dorothy.Gellert@nokia.com
Cc:=20 capwap@frascone.com
Subject: RE: [Capwap] Re: Data plane = and control=20 plane separation in Split MAC

Pat,

 

From: Pat R.=20 Calhoun [mailto:pcalhoun@airespace.com]
Sent: Friday, August 27, 2004 = 11:18=20 AM
To: = Mani, Mahalingam (Mahalingam); Wijnen, = Bert (Bert);=20 Shankar Narayanaswamy; Dorothy.Gellert@nokia.com
Cc: = capwap@frascone.com
Subject: RE: [Capwap] Re: Data = plane and=20 control plane separation in Split = MAC

 

[Mani, Mahalingam (Mahalingam)]=20 [….] My point=20 was that *like* L2TP, there has to be very close coordination between = the data=20 and control

path. These are not = just open=20 static GRE tunnels - there is policy enforcement and access control=20 required

at the WTP, and this = needs to be=20 enforced by the AC.

[Mani, Mahalingam (Mahalingam)] I tend to = agree=20 completely. I did not see that being ruled out – actually is = well within scope=20 of CAPWAP.

 

I=20 will let Bert comment if he implied otherwise – I think=20 not.

 

[Mani, Mahalingam (Mahalingam)]=20 -mani

PatC

 

From:=20 Mani, Mahalingam = (Mahalingam)=20 [mailto:mmani@avaya.com]
Sent: Fri 8/27/2004 10:31 = AM
To: Pat R. Calhoun; Wijnen, = Bert (Bert);=20 Shankar Narayanaswamy; Dorothy.Gellert@nokia.com
Cc: = capwap@frascone.com
Subject: RE: [Capwap] Re: Data = plane and=20 control plane separation in Split = MAC

Correct me = if I am=20 wrong – but Bert’s assertion does not discount AC being a = PDP. The assertion=20 is w.r.t. not to deal with

CAPWAP = protocol=20 enveloping or specifying how it should be encapsulated or=20 secured.

 

-mani

From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. = Calhoun
Sent: Friday, August 27, 2004 = 8:42=20 AM
To: Wijnen, = Bert (Bert);=20 Shankar Narayanaswamy; Dorothy.Gellert@nokia.com
Cc: = capwap@frascone.com
Subject: RE: [Capwap] Re: Data = plane and=20 control plane separation in Split = MAC

 

> So... to = me that=20 sounds that we may potentially do an IMPLIED agreement =
> on the=20 architecture for data plane, based on the capabilities we=20 define
> in the=20 standards track control and provisioning protocol.=20

 

> That would = be fine=20 with me. But we should NOT get bogged down in that=20
> data plane = stuff, or=20 at least that to me seems to be the wrong focus.=20

I=20 respectfully disagree. The data plane is tied to the control channel = because a=20 WTP should only forward frames for a given user when it has received = approval=20 from the AC. The AC must make higher level access control decisions, = not the=20 WTP.

PatC

<= /HTML> ------_=_NextPart_001_01C48CF5.13880918-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sat Aug 28 23:34:30 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27665 for ; Sat, 28 Aug 2004 23:34:28 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F044D1FC71; Sat, 28 Aug 2004 23:19:13 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D1CFA217C2; Sat, 28 Aug 2004 23:19:09 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6C265217C2 for ; Sat, 28 Aug 2004 23:18: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 605A71FC71 for ; Sat, 28 Aug 2004 23:18:01 -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 i7T3QFJS011298 for ; Sat, 28 Aug 2004 22:26:15 -0500 (EST) 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 i7T3QEJS011285 for ; Sat, 28 Aug 2004 22:26:14 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48D78.E9BC3607" Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC Message-ID: Thread-Topic: [Capwap] Re: Data plane and control plane separation in Split MAC Thread-Index: AcSM9RkVPpZIJbM2QTCvcrWt9Ui74QAgxyQw From: "Mani, Mahalingam (Mahalingam)" To: "Wijnen, Bert (Bert)" , "Pat R. Calhoun" , "Shankar Narayanaswamy" , 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: Sat, 28 Aug 2004 21:33:13 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C48D78.E9BC3607 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bert, =20 My understanding of Pat's argument (I am unsure why he sets off disagreeing) is that no matter what the data (encapsulation) protocol WTP-level access control mechanisms such as where/what traffic goes-to/comes-from should be vested with AC. =20 That's what I mentioned agreeing on - as being a function of AC. That does not per se say anything about data-plane protocol. If it is not as simple as that it needs more clarification as to why not - which I have not heard so far.=20 =20 Regards, -mani _____ =20 From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 Sent: Saturday, August 28, 2004 4:49 AM To: Mani, Mahalingam (Mahalingam); Pat R. Calhoun; Wijnen, Bert (Bert); Shankar Narayanaswamy; Dorothy.Gellert@nokia.com Cc: capwap@frascone.com Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC =20 Sorry, but I guess I do not exactly understand (yet) what you are talking about. =20 If you tell me that WTP to AC communication is over a standard XXX (for example GRE) tunnel, then, I guess/think that it is fine to make such a statement and to have management/control=20 objects/items to be communicated over/with the CAPWAP protocol. =20 If you tell me that we must go down the path of specifying how data plane material gets encapsulated on an XXX (whichever) tunnel, then I (personally) do not believe that that would be in scope for the CAPWAP WG. =20 Does that help? Thanks, Bert=20 -----Original Message----- From: Mani, Mahalingam (Mahalingam) [mailto:mmani@avaya.com] Sent: Friday, August 27, 2004 20:41 To: Pat R. Calhoun; Wijnen, Bert (Bert); Shankar Narayanaswamy; Dorothy.Gellert@nokia.com Cc: capwap@frascone.com Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC Pat, =20 =09 _____ =20 From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]=20 Sent: Friday, August 27, 2004 11:18 AM To: Mani, Mahalingam (Mahalingam); Wijnen, Bert (Bert); Shankar Narayanaswamy; Dorothy.Gellert@nokia.com Cc: capwap@frascone.com Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC =20 [Mani, Mahalingam (Mahalingam)] [....] My point was that *like* L2TP, there has to be very close coordination between the data and control path. These are not just open static GRE tunnels - there is policy enforcement and access control required at the WTP, and this needs to be enforced by the AC. [Mani, Mahalingam (Mahalingam)] I tend to agree completely. I did not see that being ruled out - actually is well within scope of CAPWAP. =20 I will let Bert comment if he implied otherwise - I think not. =20 [Mani, Mahalingam (Mahalingam)] -mani PatC =20 =09 _____ =20 From: Mani, Mahalingam (Mahalingam) [mailto:mmani@avaya.com] Sent: Fri 8/27/2004 10:31 AM To: Pat R. Calhoun; Wijnen, Bert (Bert); Shankar Narayanaswamy; Dorothy.Gellert@nokia.com Cc: capwap@frascone.com Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC Correct me if I am wrong - but Bert's assertion does not discount AC being a PDP. The assertion is w.r.t. not to deal with CAPWAP protocol enveloping or specifying how it should be encapsulated or secured. =20 -mani =09 _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun Sent: Friday, August 27, 2004 8:42 AM To: Wijnen, Bert (Bert); Shankar Narayanaswamy; Dorothy.Gellert@nokia.com Cc: capwap@frascone.com Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC =20 > So... to me that sounds that we may potentially do an IMPLIED agreement=20 > on the architecture for data plane, based on the capabilities we define=20 > in the standards track control and provisioning protocol.=20 =20 > That would be fine with me. But we should NOT get bogged down in that=20 > data plane stuff, or at least that to me seems to be the wrong focus.=20 I respectfully disagree. The data plane is tied to the control channel because a WTP should only forward frames for a given user when it has received approval from the AC. The AC must make higher level access control decisions, not the WTP. PatC ------_=_NextPart_001_01C48D78.E9BC3607 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Capwap] Re: Data plane and control plane separation in Split = MAC

Bert,

 

My understanding of Pat’s = argument (I am unsure why he sets off disagreeing) is that no matter what the data = (encapsulation) protocol WTP-level

access control mechanisms such as = where/what traffic goes-to/comes-from should be vested with = AC.

 

That’s what I mentioned = agreeing on – as being a function of AC. That does not per se say anything about = data-plane protocol. If it is not as simple

as that it needs more clarification = as to why not – which I have not heard so far. =

 

Regards,

-mani

From: = Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Saturday, August = 28, 2004 4:49 AM
To: Mani, Mahalingam (Mahalingam); Pat R. Calhoun; Wijnen, Bert = (Bert); Shankar Narayanaswamy; Dorothy.Gellert@nokia.com
Cc: = capwap@frascone.com
Subject: RE: [Capwap] Re: = Data plane and control plane separation in Split = MAC

 

Sorry, but I guess I do not exactly understand (yet) what you are talking = about.

 

If you tell me that WTP to AC communication is over a standard XXX (for example GRE) = tunnel,

then, I guess/think that it is fine = to make such a  statement and to have management/control =

objects/items to be communicated = over/with the CAPWAP protocol.

 

If you tell me that we must go down = the path of specifying how data plane material gets = encapsulated

on an XXX (whichever) tunnel, then = I (personally) do not believe that that would be in scope = for

the CAPWAP = WG.

 

Does that = help?

Thanks, Bert

=

-----Original = Message-----
From: Mani, Mahalingam (Mahalingam) [mailto:mmani@avaya.com]
Sent: Friday, August 27, = 2004 20:41
To: Pat R. Calhoun; = Wijnen, Bert (Bert); Shankar Narayanaswamy; Dorothy.Gellert@nokia.com
Cc: = capwap@frascone.com
Subject: RE: [Capwap] Re: = Data plane and control plane separation in Split = MAC

Pat,

 

From: Pat = R. Calhoun [mailto:pcalhoun@airespace.com]
Sent: Friday, August 27, = 2004 11:18 AM
To: Mani, Mahalingam (Mahalingam); Wijnen, Bert (Bert); Shankar Narayanaswamy; Dorothy.Gellert@nokia.com
Cc: = capwap@frascone.com
Subject: RE: [Capwap] Re: = Data plane and control plane separation in Split = MAC

 

[Mani, = Mahalingam (Mahalingam)] [….]= My point was that *like* L2TP, there has to be very close coordination between = the data and control

path. These are not just open static GRE tunnels - = there is policy enforcement and access control = required

at the WTP, and this needs to be enforced by the = AC.

[Mani, = Mahalingam (Mahalingam)] I tend to agree completely. I did not see that being ruled = out – actually is well within scope of = CAPWAP.

 

I will let Bert comment if he implied otherwise = – I think not.

 

[Mani, = Mahalingam (Mahalingam)] -mani

PatC

 

From: Mani, Mahalingam (Mahalingam) [mailto:mmani@avaya.com]
Sent: Fri 8/27/2004 10:31 = AM
To: Pat R. Calhoun; = Wijnen, Bert (Bert); Shankar Narayanaswamy; Dorothy.Gellert@nokia.com
Cc: = capwap@frascone.com
Subject: RE: [Capwap] Re: = Data plane and control plane separation in Split = MAC

Correct me if I am wrong – = but Bert’s assertion does not discount AC being a PDP. The assertion = is w.r.t. not to deal with

CAPWAP protocol enveloping or = specifying how it should be encapsulated or secured.

 

-mani

From: = capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun
Sent: Friday, August 27, = 2004 8:42 AM
To: Wijnen, Bert (Bert); = Shankar Narayanaswamy; Dorothy.Gellert@nokia.com
Cc: = capwap@frascone.com
Subject: RE: [Capwap] Re: = Data plane and control plane separation in Split MAC

 

> So... to me that sounds that we may = potentially do an IMPLIED agreement
> on the architecture for data plane, = based on the capabilities we define
> in the standards track control and = provisioning protocol.

 

> That would be fine with me. But we = should NOT get bogged down in that
> data plane stuff, or at least that to me = seems to be the wrong focus.

I respectfully disagree. The data plane is tied to the control channel = because a WTP should only forward frames for a given user when it has received = approval from the AC. The AC must make higher level access control decisions, not = the WTP.

PatC

------_=_NextPart_001_01C48D78.E9BC3607-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Aug 30 09:02:04 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21007 for ; Mon, 30 Aug 2004 09:02:03 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 05B01212B8; Mon, 30 Aug 2004 08:44:13 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CC7B6212AD; Mon, 30 Aug 2004 08:44:10 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F2BC320B59 for ; Mon, 30 Aug 2004 08:42:55 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id 971DA20302 for ; Mon, 30 Aug 2004 08:42:50 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48E91.73333A76" Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC Message-ID: <55749BC69138654EBBC4C50BA4F55610020C45EE@AIREMAIL.airespace.com> Thread-Topic: [Capwap] Re: Data plane and control plane separation in Split MAC Thread-Index: AcSM9YwxeCF4UA8iTJyWh95Ib0ELfgBmtgq7 From: "Pat R. Calhoun" To: "Wijnen, Bert (Bert)" , "Mani, Mahalingam (Mahalingam)" , "Wijnen, Bert (Bert)" , "Shankar Narayanaswamy" , 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, 30 Aug 2004 06:01:22 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C48E91.73333A76 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It sounds like we agree that some method must be provided to communicate = the presence of a new station session, whose data is encapsulated within = some form of a data transport. if I understand the issue you are = raising, you wish to use an existing protocol, and not define a new one. =20 Interestingly enough, even though PPTP used GRE it still had to define = how GRE was used for their protocol - a departure from the text defined = in RFC 2637 (see section 4.1 - Enhanced GRE header), which I'm quite = familiar with since I originally proposed the use of GRE for PPTP and = came up with most of that text. So it's not clear to me that using stock = 2784 is sufficient. =20 When you define a standards based approach, would UDP with a = multiplexing layer (a la L2TP) not be considered standard? =20 PatC ________________________________ From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Sat 8/28/2004 4:49 AM To: Mani, Mahalingam (Mahalingam); Pat R. Calhoun; Wijnen, Bert (Bert); = Shankar Narayanaswamy; Dorothy.Gellert@nokia.com Cc: capwap@frascone.com Subject: RE: [Capwap] Re: Data plane and control plane separation in = Split MAC Sorry, but I guess I do not exactly understand (yet) what you are = talking about. =20 If you tell me that WTP to AC communication is over a standard XXX (for = example GRE) tunnel, then, I guess/think that it is fine to make such a statement and to = have management/control=20 objects/items to be communicated over/with the CAPWAP protocol. =20 If you tell me that we must go down the path of specifying how data = plane material gets encapsulated on an XXX (whichever) tunnel, then I (personally) do not believe that = that would be in scope for the CAPWAP WG. =20 Does that help? Thanks, Bert=20 -----Original Message----- From: Mani, Mahalingam (Mahalingam) [mailto:mmani@avaya.com] Sent: Friday, August 27, 2004 20:41 To: Pat R. Calhoun; Wijnen, Bert (Bert); Shankar Narayanaswamy; = Dorothy.Gellert@nokia.com Cc: capwap@frascone.com Subject: RE: [Capwap] Re: Data plane and control plane separation in = Split MAC =09 =09 Pat, =20 =09 ________________________________ From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]=20 Sent: Friday, August 27, 2004 11:18 AM To: Mani, Mahalingam (Mahalingam); Wijnen, Bert (Bert); Shankar = Narayanaswamy; Dorothy.Gellert@nokia.com Cc: capwap@frascone.com Subject: RE: [Capwap] Re: Data plane and control plane separation in = Split MAC =20 [Mani, Mahalingam (Mahalingam)] [....] My point was that *like* L2TP, = there has to be very close coordination between the data and control path. These are not just open static GRE tunnels - there is policy = enforcement and access control required at the WTP, and this needs to be enforced by the AC. [Mani, Mahalingam (Mahalingam)] I tend to agree completely. I did not = see that being ruled out - actually is well within scope of CAPWAP. =20 I will let Bert comment if he implied otherwise - I think not. =20 [Mani, Mahalingam (Mahalingam)] -mani PatC =20 =09 ________________________________ From: Mani, Mahalingam (Mahalingam) [mailto:mmani@avaya.com] Sent: Fri 8/27/2004 10:31 AM To: Pat R. Calhoun; Wijnen, Bert (Bert); Shankar Narayanaswamy; = Dorothy.Gellert@nokia.com Cc: capwap@frascone.com Subject: RE: [Capwap] Re: Data plane and control plane separation in = Split MAC Correct me if I am wrong - but Bert's assertion does not discount AC = being a PDP. The assertion is w.r.t. not to deal with CAPWAP protocol enveloping or specifying how it should be encapsulated = or secured. =20 -mani =09 ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Pat R. Calhoun Sent: Friday, August 27, 2004 8:42 AM To: Wijnen, Bert (Bert); Shankar Narayanaswamy; = Dorothy.Gellert@nokia.com Cc: capwap@frascone.com Subject: RE: [Capwap] Re: Data plane and control plane separation in = Split MAC =20 > So... to me that sounds that we may potentially do an IMPLIED = agreement=20 > on the architecture for data plane, based on the capabilities we = define=20 > in the standards track control and provisioning protocol.=20 =20 > That would be fine with me. But we should NOT get bogged down in that = > data plane stuff, or at least that to me seems to be the wrong focus. = I respectfully disagree. The data plane is tied to the control channel = because a WTP should only forward frames for a given user when it has = received approval from the AC. The AC must make higher level access = control decisions, not the WTP. PatC ------_=_NextPart_001_01C48E91.73333A76 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= RE: [Capwap] Re: Data plane and control plane separation in Split = MAC=0A= =0A= =0A= =0A= =0A= =0A=
=0A=
It sounds = like we agree that =0A= some method must be provided to communicate the presence of a new = station =0A= session, whose data is encapsulated within some form of a data = transport. if I =0A= understand the issue you are raising, you wish to use an existing = protocol, and =0A= not define a new one.
=0A=
 
=0A=
Interestingly = enough, even =0A= though PPTP used GRE it still had to define how GRE was used for their = protocol =0A= - a departure from the text defined in RFC 2637 (see section 4.1 - = Enhanced GRE =0A= header), which I'm quite familiar with since I originally proposed the = use of =0A= GRE for PPTP and came up with most of that text. So it's not clear to me = that =0A= using stock 2784 is sufficient.
=0A=
 
=0A=
When you define a standards = based approach, =0A= would UDP with a multiplexing layer (a la L2TP) not be considered =0A= standard?
=0A=
 
=0A=
PatC
=0A=
=0A= From: Wijnen, Bert (Bert) =0A= [mailto:bwijnen@lucent.com]
Sent: Sat 8/28/2004 4:49 = AM
To: =0A= Mani, Mahalingam (Mahalingam); Pat R. Calhoun; Wijnen, Bert (Bert); = Shankar =0A= Narayanaswamy; Dorothy.Gellert@nokia.com
Cc: =0A= capwap@frascone.com
Subject: RE: [Capwap] Re: Data plane and = control =0A= plane separation in Split MAC

=0A=
=0A=
Sorry, =0A= but I guess I do not exactly understand (yet) what you are talking =0A= about.
=0A=
 
=0A=
If you =0A= tell me that WTP to AC communication is over a standard XXX (for example = GRE) =0A= tunnel,
=0A=
then, =0A= I guess/think that it is fine to make such a  statement and to have =0A= management/control
=0A=
objects/items to be communicated over/with the = CAPWAP =0A= protocol.
=0A=
 
=0A=
If you =0A= tell me that we must go down the path of specifying how data plane = material gets =0A= encapsulated
=0A=
on an =0A= XXX (whichever) tunnel, then I (personally) do not believe that that = would be in =0A= scope for
=0A=
the =0A= CAPWAP WG.
=0A=
 
=0A=
Does =0A= that help?
=0A=

Thanks, Bert

=0A=
=0A=
-----Original Message-----
From: Mani, Mahalingam =0A= (Mahalingam) [mailto:mmani@avaya.com]
Sent: Friday, August = 27, 2004 =0A= 20:41
To: Pat R. Calhoun; Wijnen, Bert (Bert); Shankar =0A= Narayanaswamy; Dorothy.Gellert@nokia.com
Cc: =0A= capwap@frascone.com
Subject: RE: [Capwap] Re: Data plane and = control =0A= plane separation in Split MAC

=0A=
=0A=

Pat,

=0A=

 

=0A=
=0A=
=0A=
=0A=
=0A=

From: Pat R. =0A= Calhoun [mailto:pcalhoun@airespace.com]
Sent: Friday, August 27, 2004 = 11:18 =0A= AM
To: Mani, = Mahalingam =0A= (Mahalingam); Wijnen, Bert (Bert); Shankar Narayanaswamy; =0A= Dorothy.Gellert@nokia.com
Cc: =0A= capwap@frascone.com
Subject: =0A= RE: [Capwap] Re: Data plane and control plane separation in Split =0A= MAC

=0A=

 

=0A=
=0A=
=0A=

[Mani, =0A= Mahalingam (Mahalingam)] [….] My point =0A= was that *like* L2TP, there has to be very close coordination between = the data =0A= and control

=0A=
=0A=

path. These are not just = open =0A= static GRE tunnels - there is policy enforcement and access control =0A= required

=0A=
=0A=

at the WTP, and this = needs to be =0A= enforced by the AC.

=0A=

[Mani, =0A= Mahalingam (Mahalingam)] I tend to agree completely. I did not see = that being =0A= ruled out – actually is well within scope of = CAPWAP.

=0A=

 

=0A=

I =0A= will let Bert comment if he implied otherwise – I think =0A= not.

=0A=
=0A=

 

=0A=

[Mani, =0A= Mahalingam (Mahalingam)] -mani

=0A=
=0A=

PatC

=0A=
=0A=

 

=0A=
=0A=
=0A=
=0A=

From: Mani, =0A= Mahalingam (Mahalingam) [mailto:mmani@avaya.com]
Sent: Fri 8/27/2004 10:31 = AM
To: Pat R. Calhoun; Wijnen, = Bert (Bert); =0A= Shankar Narayanaswamy; Dorothy.Gellert@nokia.com
Cc: = capwap@frascone.com
Subject: RE: [Capwap] Re: Data = plane and =0A= control plane separation in Split MAC

=0A=
=0A=

Correct me = if I am =0A= wrong – but Bert’s assertion does not discount AC being a = PDP. The assertion =0A= is w.r.t. not to deal with

=0A=

CAPWAP = protocol =0A= enveloping or specifying how it should be encapsulated or =0A= secured.

=0A=

 

=0A=

-mani

=0A=
=0A=
=0A=
=0A=
=0A=

From: =0A= capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. = Calhoun
Sent: Friday, August 27, 2004 = 8:42 =0A= AM
To: Wijnen, Bert = (Bert); =0A= Shankar Narayanaswamy; Dorothy.Gellert@nokia.com
Cc: = capwap@frascone.com
Subject: RE: [Capwap] Re: Data = plane and =0A= control plane separation in Split MAC

=0A=

 

=0A=
=0A=
=0A=

> So... to me = that =0A= sounds that we may potentially do an IMPLIED agreement =
> on the =0A= architecture for data plane, based on the capabilities we =0A= define
> in the =0A= standards track control and provisioning protocol. =0A=

=0A=
=0A=

 

=0A=
=0A=

> That would = be fine =0A= with me. But we should NOT get bogged down in that =0A=
> data plane = stuff, or =0A= at least that to me seems to be the wrong focus. =0A=

=0A=

I =0A= respectfully disagree. The data plane is tied to the control channel = because a =0A= WTP should only forward frames for a given user when it has received = approval =0A= from the AC. The AC must make higher level access control decisions, = not the =0A= WTP.

=0A=

PatC

------_=_NextPart_001_01C48E91.73333A76-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Aug 30 18:03:33 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07288 for ; Mon, 30 Aug 2004 18:03:32 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0F27B21401; Mon, 30 Aug 2004 17:48:13 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AE0CF21407; Mon, 30 Aug 2004 17:48:09 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2304921407 for ; Mon, 30 Aug 2004 17:47:49 -0400 (EDT) Received: from note_back.accton.com (note_back.accton.com [67.115.116.242]) by mail.frascone.com (Postfix) with ESMTP id 34F2521401 for ; Mon, 30 Aug 2004 17:47:47 -0400 (EDT) Subject: RE: [Capwap] So many architectures, so little time... - take 2 To: capwap@frascone.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: ts_jou@accton.com X-MIMETrack: Serialize by Router on note_back/AcctonUS(Release 5.0.2c |February 2, 2000) at 08/30/2004 02:39:45 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable 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, 30 Aug 2004 15:19:09 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Pat, Just to clarify one point from your note to others: Your interpretation on the "Local MAC" can be true but not necessaril= y the only way to interpret/deploy/implement it. According to Section 4.6 of draft-ietf-capwap-arch-05.txt, in a Local= MAC deployment: both data plane and control plane should be terminated at WTP, but the 802.3 & 802.11 bridging "can be part of either the AC or WTP in the Local MAC". What you mentioned was correct, meanwhile, I am aware of another ven= dor who uses an AC (switch, not router) to manage/control APs (and STAs) but all dat= a traffic is plain 802.3 traffic to the AC (i.e. no tunneling for data traffic). Whatever we want to call it, this kind of implementation does exist and= makes sense (as others) technically. Yes extension to IEEE802.11 (such as TGk) may cause more complication i= n the future. Hopefully the protocol CAPWAP is going to adopt can allow flexibility i= f "Local MAC" is addressed. One thing obvious is the definitions of "local/split/remot" MAC may n= ot have been detailed enough to cleanly seperate all possibilities into 3 categories. This might be a g= ood starting point for the CAPWAP protocol design discussion, before people diving into proposing various solution= s. ---Tyan-Shu Jou = =20 = =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 Well, the local MAC implementati= ons=20 that I am aware of also tunnel = =20 traffic to the AC. = =20 = =20 So I believe that there is some = =20 mis-understanding on what split = vs.=20 local means. Frankly, = =20 the differences are quite small.= =20 Where split sends up the MAC fra= mes=20 for access control = =20 processing on the AC, local MAC = =20 terminates the MAC on the AP but= =20 then creates some = =20 control message that includes al= l =20 of the data that was in the MAC = =20 message. = =20 = =20 So in my=A0 opinion, local MAC = =20 increases the protocol design wo= rk =20 because one needs to = =20 in essence "recreate"=A0 the 802= .11 =20 MAC mgmt protocol. Further, it's= =20 not clear how the IETF = =20 would deal with new IEEE extensi= ons=20 (e.g. 802.11k) because these = =20 recreated messages = =20 would have to include new = =20 information that isn't known tod= ay =20 - so a CAPWAP solution = =20 would always be behind. = =20 = =20 Split MAC does not suffer from t= his=20 approach. = =20 = =20 PatC = =20 = =20 From: capwap-admin@frascone.com = on =20 behalf of Saravanan Govindan = =20 Sent: Wed 8/11/2004 7:23 AM = =20 To: 'Abhijit Choudhury'; = =20 capwap@frascone.com = =20 Subject: RE: [Capwap] So many = =20 architectures, so little time...= - =20 take 2 = =20 = =20 = =20 = =20 Given the various sides to the = =20 discussion on where MAC frames a= re =20 handled, I = =20 suggest making this a configurat= ion=20 aspect of the CAPWAP protocol. S= o, =20 the = =20 choice of which MAC frames are = =20 processed where can be left till= =20 the time of = =20 initializing APs. = =20 = =20 = =20 For example, when a controller = =20 initializes a local-MAC AP, it = =20 configures one = =20 instance of the CAPWAP protocol = so =20 as NOT to receive any MAC frames= =20 from the = =20 AP. Rather, the protocol instanc= e =20 expects to receive explicit CAPW= AP =20 messages/signals from the local-= MAC=20 AP. = =20 = =20 = =20 On the other hand, while = =20 initializing a split-MAC AP, = =20 another instance of = =20 the protocol is configured to = =20 receive 'some' MAC frames and = =20 'other' = =20 remaining CAPWAP messages/signal= s. =20 The 'some' and 'other' parts ref= er =20 to = =20 particular split-MAC variations.= =20 The specifics of these parts can= be=20 left = =20 for refinement based on the = =20 analyses from the Architecture = =20 Taxonomy. = =20 = =20 = =20 The CAPWAP protocol can then be = =20 made to work on both raw MAC fra= mes=20 and = =20 abstracted CAPWAP messages/signa= ls.=20 This way, true interoperability = is =20 achieved, while at the same time= =20 allowing for different designs a= nd =20 implementations. = =20 = =20 = =20 Comments? Suggestions? = =20 = =20 = =20 Saravanan = =20 = =20 = =20 ________________________________= =20 = =20 = =20 =A0=A0=A0=A0=A0=A0=A0 From: = =20 capwap-admin@frascone.com [ = =20 ?mod=3Dcompose&To=3Dcapwap-admin= @frasco=20 ne.com] = =20 On Behalf Of Abhijit Choudhury = =20 =A0=A0=A0=A0=A0=A0=A0 Sent: Wedn= esday, August 11,=20 2004 2:18 PM = =20 =A0=A0=A0=A0=A0=A0=A0 To: capwap= @frascone.com =20 =A0=A0=A0=A0=A0=A0=A0 Subject: F= W: [Capwap] So =20 many architectures, so little = =20 time... - = =20 take 2 = =20 = =20 = =20 =A0=A0=A0=A0=A0=A0=A0 One key ob= jective that has =20 been discussed in this group = =20 =A0=A0=A0=A0=A0=A0=A0 is INTEROP= ERABILITY.=A0 It's =20 not clear how you achieve = =20 =A0=A0=A0=A0=A0=A0=A0 interopera= bility between a =20 WTP from vendor X and an AC = =20 =A0=A0=A0=A0=A0=A0=A0 from vendo= r Y, if you don't=20 support the same protocols on = =20 =A0=A0=A0=A0=A0=A0=A0 all three = categories that =20 you have pointed out.=A0 Sure yo= u can=20 = =20 =A0=A0=A0=A0=A0=A0=A0 achieve in= teroperability =20 between the two, if you support = the=20 = =20 =A0=A0=A0=A0=A0=A0=A0 superset o= f all possible =20 encapsulations, but then you are= no=20 = =20 =A0=A0=A0=A0=A0=A0=A0 better off= than you are =20 currently.=A0 That is why there = is =20 need = =20 =A0=A0=A0=A0=A0=A0=A0 for a stan= dard.=A0=A0 And it's =20 easier to implement in hardware = or =20 software = =20 =A0=A0=A0=A0=A0=A0=A0 if there i= s one standard =20 protocol instead of three. = =20 = =20 =A0=A0=A0=A0=A0=A0=A0 We really = should strive =20 towards a unified tunneling = =20 protocol for = =20 control = =20 =A0=A0=A0=A0=A0=A0=A0 and data, = although you can =20 have separate connections = =20 =A0=A0=A0=A0=A0=A0=A0 for each, = and different =20 security on each. = =20 = =20 =A0=A0=A0=A0=A0=A0=A0 But if thi= s group stays =20 away from specifying a common = =20 =A0=A0=A0=A0=A0=A0=A0 protocol f= or control/mgmt =20 and data between the WTP = =20 =A0=A0=A0=A0=A0=A0=A0 and AC, or= specifies one =20 and not the other, = =20 =A0=A0=A0=A0=A0=A0=A0 there cann= ot be true =20 interoperability even within = =20 =A0=A0=A0=A0=A0=A0=A0 the split-= MAC architecture =20 family. = =20 = =20 =A0=A0=A0=A0=A0=A0=A0 Abhijit = =20 = =20 = =20 ________________________________= =20 = =20 = =20 =A0=A0=A0=A0=A0=A0=A0 From: Sudh= anshu Jain =20 =A0=A0=A0=A0=A0=A0=A0 Sent: Tue = 8/10/2004 7:19 PM=20 = =20 =A0=A0=A0=A0=A0=A0=A0 To: 'Yang,= Lily L'; Shehzad=20 Merchant; Shankar Narayanaswamy;= =20 Abhijit = =20 Choudhury = =20 =A0=A0=A0=A0=A0=A0=A0 Cc: capwap= @frascone.com =20 =A0=A0=A0=A0=A0=A0=A0 Subject: R= E: [Capwap] So =20 many architectures, so little = =20 time... - = =20 take 2 = =20 = =20 = =20 = =20 = =20 =A0=A0=A0=A0=A0=A0=A0 Problem we= have to solve =20 can be classified into three = =20 categories. = =20 = =20 = =20 =A0=A0=A0=A0=A0=A0=A0 * Control = & Management of =20 WTP = =20 =A0=A0=A0=A0=A0=A0=A0 * Control = & Management of =20 STA = =20 =A0=A0=A0=A0=A0=A0=A0 * 802.11 D= ata =20 = =20 = =20 =A0=A0=A0=A0=A0=A0=A0 Since diff= erent =20 functionalities has different = =20 requirements, it is = =20 possible to address them with = =20 separate sets of mechanism. = =20 = =20 = =20 =A0=A0=A0=A0=A0=A0=A0 First vers= ion of CAPWAP =20 control protocol should address = =20 first = =20 functionality with provision to = =20 communicate = =20 =A0=A0=A0=A0=A0=A0=A0 * Tunnelin= g mechanism =20 =A0=A0=A0=A0=A0=A0=A0 * Informat= ion about MAC =20 implementation = =20 (Local/Split/Centralized) = =20 etc. = =20 = =20 = =20 =A0=A0=A0=A0=A0=A0=A0 -Suds = =20 = =20 = =20 = =20 = =20 = =20 = _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Aug 30 20:48:32 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18519 for ; Mon, 30 Aug 2004 20:48:31 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CAEF31FD3B; Mon, 30 Aug 2004 20:33:13 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E775421431; Mon, 30 Aug 2004 20:33:09 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D539E217B7 for ; Mon, 30 Aug 2004 20:32:18 -0400 (EDT) Received: from note_back.accton.com (note_back.accton.com [67.115.116.242]) by mail.frascone.com (Postfix) with ESMTP id E0C731FD3B for ; Mon, 30 Aug 2004 20:32:16 -0400 (EDT) Subject: RE: [Capwap] So many architectures, so little time... - take 2 To: "Pat R. Calhoun" Cc: capwap@frascone.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: ts_jou@accton.com X-MIMETrack: Serialize by Router on note_back/AcctonUS(Release 5.0.2c |February 2, 2000) at 08/30/2004 05:24:14 PM 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, 30 Aug 2004 18:03:39 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Hi Pat, I have no strong opinion on the naming convention. Since "Local MAC" belongs to "Centralized WLAN Architecture" (vs. Autonomous WLAN Arch), I guess some config/management/control functions should be done in the AC. My understanding is the categorization in the Architecture Taxonomy document is based more on the control and management, rather than on the data path. In fact, there could be a case that the AC handles all data but partial MAC, whereas in the other case AC handles no data but all control/management. It might be difficult to categorize them all correctly. As for the reference I used in my previous mail, I believe a few of the "Local MAC" examples described in the document could have utilized similar fashion. Yes data do not even need to pass through the AC (so the AC is more like a station as you mentioned) if it really doesn't touch/monitor data traffic. I know some vendors provide extra filtering/policy in the switch/router in this case, while leave all data traffic is in pure 802.3 format in/out of the AC. Another reason to have above architecture is it allows existing Ethernet switch vendors to jump onto the "wireless switch" bandwagon without major change on existing products. Like it or not, the force to go for this direction can be strong. Yes PoE for APs could be the other reason. Thanks. Regards, --Tyan-Shu Jou "Pat R. Calhoun" To: , Subject: RE: [Capwap] So many architectures, so little time... - take 2 08/30/2004 03:43 PM Interesting. I would submit that if an implementation has an AC that provides some form of access control, then it participates in the mac management in some form, and therefore should fall under a split MAC category. Regardless of whether the signalling used happens to smell and taste like 802.11 mac mgmt, or whether it is another payload format that includes essentially the same items. The one case you are referring to is one where the AC does very little on the data path, and I would then ask why bother sending packets through the AC? This architecture would obviously only work for WTPs directly connected to the AC, presumably for PoE purposes. Does this architecture/implementation that you are referring to have centralized access control? It seems to me that in this case the AC is really nothing more than a management station, no? PatC From: capwap-admin@frascone.com on behalf of ts_jou@accton.com Sent: Mon 8/30/2004 3:19 PM To: capwap@frascone.com Subject: RE: [Capwap] So many architectures, so little time... - take 2 Hi Pat, Just to clarify one point from your note to others: Your interpretation on the "Local MAC" can be true but not necessarily the only way to interpret/deploy/implement it. According to Section 4.6 of draft-ietf-capwap-arch-05.txt, in a Local MAC deployment: both data plane and control plane should be terminated at WTP, but the 802.3 & 802.11 bridging "can be part of either the AC or WTP in the Local MAC". What you mentioned was correct, meanwhile, I am aware of another vendor who uses an AC (switch, not router) to manage/control APs (and STAs) but all data traffic is plain 802.3 traffic to the AC (i.e. no tunneling for data traffic). Whatever we want to call it, this kind of implementation does exist and makes sense (as others) technically. Yes extension to IEEE802.11 (such as TGk) may cause more complication in the future. Hopefully the protocol CAPWAP is going to adopt can allow flexibility if "Local MAC" is addressed. One thing obvious is the definitions of "local/split/remot" MAC may not have been detailed enough to cleanly seperate all possibilities into 3 categories. This might be a good starting point for the CAPWAP protocol design discussion, before people diving into proposing various solutions. ---Tyan-Shu Jou ================ Well, the local MAC implementations that I am aware of also tunnel traffic to the AC. So I believe that there is some mis-understanding on what split vs. local means. Frankly, the differences are quite small. Where split sends up the MAC frames for access control processing on the AC, local MAC terminates the MAC on the AP but then creates some control message that includes all of the data that was in the MAC message. So in my opinion, local MAC increases the protocol design work because one needs to in essence "recreate" the 802.11 MAC mgmt protocol. Further, it's not clear how the IETF would deal with new IEEE extensions (e.g. 802.11k) because these recreated messages would have to include new information that isn't known today - so a CAPWAP solution would always be behind. Split MAC does not suffer from this approach. PatC From: capwap-admin@frascone.com on behalf of Saravanan Govindan Sent: Wed 8/11/2004 7:23 AM To: 'Abhijit Choudhury'; capwap@frascone.com Subject: RE: [Capwap] So many architectures, so little time... - take 2 Given the various sides to the discussion on where MAC frames are handled, I suggest making this a configuration aspect of the CAPWAP protocol. So, the choice of which MAC frames are processed where can be left till the time of initializing APs. For example, when a controller initializes a local-MAC AP, it configures one instance of the CAPWAP protocol so as NOT to receive any MAC frames from the AP. Rather, the protocol instance expects to receive explicit CAPWAP messages/signals from the local-MAC AP. On the other hand, while initializing a split-MAC AP, another instance of the protocol is configured to receive 'some' MAC frames and 'other' remaining CAPWAP messages/signals. The 'some' and 'other' parts refer to particular split-MAC variations. The specifics of these parts can be left for refinement based on the analyses from the Architecture Taxonomy. The CAPWAP protocol can then be made to work on both raw MAC frames and abstracted CAPWAP messages/signals. This way, true interoperability is achieved, while at the same time allowing for different designs and implementations. Comments? Suggestions? Saravanan ________________________________ From: capwap-admin@frascone.com [ ?mod=compose&To=capwap-admin@frasco ne.com] On Behalf Of Abhijit Choudhury Sent: Wednesday, August 11, 2004 2:18 PM To: capwap@frascone.com Subject: FW: [Capwap] So many architectures, so little time... - take 2 One key objective that has been discussed in this group is INTEROPERABILITY. It's not clear how you achieve interoperability between a WTP from vendor X and an AC from vendor Y, if you don't support the same protocols on all three categories that you have pointed out. Sure you can achieve interoperability between the two, if you support the superset of all possible encapsulations, but then you are no better off than you are currently. That is why there is need for a standard. And it's easier to implement in hardware or software if there is one standard protocol instead of three. We really should strive towards a unified tunneling protocol for control and data, although you can have separate connections for each, and different security on each. But if this group stays away from specifying a common protocol for control/mgmt and data between the WTP and AC, or specifies one and not the other, there cannot be true interoperability even within the split-MAC architecture family. Abhijit ________________________________ From: Sudhanshu Jain Sent: Tue 8/10/2004 7:19 PM To: 'Yang, Lily L'; Shehzad Merchant; Shankar Narayanaswamy; Abhijit Choudhury Cc: capwap@frascone.com Subject: RE: [Capwap] So many architectures, so little time... - take 2 Problem we have to solve can be classified into three categories. * Control & Management of WTP * Control & Management of STA * 802.11 Data Since different functionalities has different requirements, it is possible to address them with separate sets of mechanism. First version of CAPWAP control protocol should address first functionality with provision to communicate * Tunneling mechanism * Information about MAC implementation (Local/Split/Centralized) etc. -Suds _______________________________________________ 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