From capwap-admin@frascone.com Wed Sep 1 01:43: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 BAA08950 for ; Wed, 1 Sep 2004 01:43:29 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F3C0C21A63; Wed, 1 Sep 2004 01:28:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9DA9421A66; Wed, 1 Sep 2004 01:28:02 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 61A6021A66 for ; Wed, 1 Sep 2004 01:27:07 -0400 (EDT) Received: from brahma.intotoind.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by mail.frascone.com (Postfix) with ESMTP id B797421A63 for ; Wed, 1 Sep 2004 01:27:04 -0400 (EDT) Received: from rkp.intoto.com (1mc70.intotoind.com [172.16.1.70]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i815gHnl030707 for ; Wed, 1 Sep 2004 11:12:17 +0530 Message-Id: <5.1.0.14.0.20040901111957.024b10c8@172.16.1.10> X-Sender: rkp@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: capwap@frascone.com From: Chunduru Rama Krishna Prasad Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.41 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Local 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, 01 Sep 2004 11:22:10 +0530 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Hi , Please correct if my interpretation of LOCAL MAC is wrong. WTP terminates 802.11 control packets and nothing is sent to AC . WTP terminates 802.11 mangement frames and corresponding events are sent to AC. WTP terminates 802.11 data frames, does decryption/encryption based on unique keys correspond to wireless stations, extracts 802.3 packet from the frame and send the frame across to AC. If needed, it might also send some control information along with each 802.3 packet. In this case, AC does not have knowledge of 802.11 header. It only needs knowledge of CAPWAP protocol, 802.1x termination, specific wireless related parameters. What makes it split MAC? My understanding is that, if AC terminates 802.11 frames and does encyption/decryption and has knowledge of 802.11 frames, then it is Split MAC. Is this understanding correct? Thanks Rama Krishna Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 1 09:29: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 JAA04814 for ; Wed, 1 Sep 2004 09:29:26 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1137C20370; Wed, 1 Sep 2004 09:14:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8E54021A94; Wed, 1 Sep 2004 09:14:02 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4D7B221A94 for ; Wed, 1 Sep 2004 09:13:18 -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 2ACFD20370 for ; Wed, 1 Sep 2004 09:13:16 -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_01C49028.079028A6" Subject: RE: [Capwap] Local MAC Message-ID: <55749BC69138654EBBC4C50BA4F55610020C4674@AIREMAIL.airespace.com> Thread-Topic: [Capwap] Local MAC Thread-Index: AcSP5xG3fD3GaO2uRN+96rM8siBwCgAPxrsm From: "Pat R. Calhoun" To: "Chunduru Rama Krishna Prasad" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Sep 2004 06:31:47 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C49028.079028A6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Great question. =20 As you observed below, the primary difference (from what I can tell) = between split and local MAC is that while the former simply sends the frames = untouched the latter reformulates the 802.11 messages into another format before = sending them to the AC. So sure the PDUs look different, but in reality they are = not really that different, right? =20 I mean what's the difference between sending a straight association = request to the AC vs. breaking the association request down into small components and = using the resulting information to create a message to be sent to the AC? =20 One could easily argue that using the straight association request will = ensure forward compatibility with any new IEEE 802.11 related standard. Let's use = 802.11k for instance, there are some new extensions that are added to existing MAC mgmt = frames. So while a protocol that simply forwards the MAC mgmt frames to the AC will be = able to handle 802.11k transparently, the other approach would require that the IETF WG = get together and define a way to map the new 802.11k extensions into whatever = protocol was created. Clearly, we cannot afford to have the IETF's protocol lag behind IEEE = standards. =20 On the data path, what is the difference between sending the straight = 802.11 frame vs. sending an 802.3 frame with some associated control information that = was derived from the 802.11 frame to begin with? What happens when protocols like = 802.11e change the actual format of the frame by inserting 2 bytes in the protocol = header? Sending the straight 802.11 frame to the AC ensures that whatever solution we've = come up with will be able to support these future extensions, while a protocol that breaks = down the PDU into an 802.3 frame will cause these extensions to be lost. =20 It's really not like understanding the 802.11 protocol is a complex = thing - there are plenty of implementations of 802.11 based products, and some of these = are even available as open source. So I would argue that parsing 802.11 packets is much = simpler than 802.3 with some control information since those stacks are publicly available. =20 PatC ________________________________ From: capwap-admin@frascone.com on behalf of Chunduru Rama Krishna = Prasad Sent: Tue 8/31/2004 10:52 PM To: capwap@frascone.com Subject: [Capwap] Local MAC Hi , Please correct if my interpretation of LOCAL MAC is wrong. WTP terminates 802.11 control packets and nothing is sent to AC . WTP terminates 802.11 mangement frames and corresponding events are sent = to AC. WTP terminates 802.11 data frames, does decryption/encryption based on unique keys correspond to wireless stations, extracts 802.3 packet from = the frame and send the frame across to AC. If needed, it might also send some control information along with each 802.3 packet. In this case, AC does not have knowledge of 802.11 header. It only needs knowledge of CAPWAP protocol, 802.1x termination, specific wireless related = parameters. What makes it split MAC? My understanding is that, if AC terminates = 802.11 frames and does encyption/decryption and has knowledge of 802.11 frames, then it is Split MAC. Is this understanding correct? Thanks Rama Krishna Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap ------_=_NextPart_001_01C49028.079028A6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= [Capwap] Local MAC=0A= =0A= =0A=
=0A=
Great = question.
=0A=
 
=0A=
As you observed below, the = primary =0A= difference (from what I can tell) between
=0A=
split and local MAC is that = while the =0A= former simply sends the frames untouched
=0A=
the latter reformulates the = 802.11 messages =0A= into another format before sending
=0A=
them to the AC. So sure the = PDUs look =0A= different, but in reality they are not really
=0A=
that different, = right?
=0A=
 
=0A=
I mean what's the difference = between =0A= sending a straight association request to the
=0A=
AC vs. breaking the = association request =0A= down into small components and using the
=0A=
resulting information to = create a message =0A= to be sent to the AC?
=0A=
=0A=
 
=0A=
One could easily argue that = using the =0A= straight association request will ensure forward
=0A=
compatibility with any new = IEEE 802.11 =0A= related standard. Let's use 802.11k for instance,
=0A=
there are some new extensions = that are =0A= added to existing MAC mgmt frames. So while
=0A=
a protocol that simply = forwards the MAC =0A= mgmt frames to the AC will be able to handle
=0A=
802.11k transparently, the = other approach =0A= would require that the IETF WG get together
=0A=
and define a way to map the = new 802.11k =0A= extensions into whatever protocol was created.
=0A=
Clearly, we cannot afford to = have the =0A= IETF's protocol lag behind IEEE standards.
=0A=
 
=0A=
On the data path, what is the = difference =0A= between sending the straight 802.11 frame
=0A=
vs. sending an 802.3 frame = with some =0A= associated control information that was derived
=0A=
from the 802.11 frame to = begin with? What =0A= happens when protocols like 802.11e change
=0A=
the actual format of the = frame by inserting =0A= 2 bytes in the protocol header? Sending the
=0A=
straight 802.11 frame to the = AC ensures =0A= that whatever solution we've come up with will
=0A=
be able to support these = future extensions, =0A= while a protocol that breaks down the PDU
=0A=
into an 802.3 frame will = cause these =0A= extensions to be lost.
=0A=
 
=0A=
It's really not like = understanding the =0A= 802.11 protocol is a complex thing - there are
=0A=
plenty of implementations of = 802.11 based =0A= products, and some of these are even available
=0A=
as open source. So I would = argue that =0A= parsing 802.11 packets is much simpler than 802.3
=0A=
with some control information = since those =0A= stacks are publicly available.
=0A=
 
=0A=
PatC
=0A=

=0A=
=0A= From: capwap-admin@frascone.com on = behalf of =0A= Chunduru Rama Krishna Prasad
Sent: Tue 8/31/2004 10:52 =0A= PM
To: capwap@frascone.com
Subject: [Capwap] Local =0A= MAC

=0A=
=0A=

Hi ,

Please correct if my interpretation of = LOCAL MAC is =0A= wrong.
WTP terminates 802.11 control packets and nothing is sent to = AC =0A= .
WTP terminates 802.11 mangement frames and corresponding events are = sent =0A= to
AC.
WTP terminates 802.11 data frames, does = decryption/encryption based =0A= on
unique keys correspond to wireless stations, extracts 802.3 packet = from =0A= the
frame and send the frame across to AC. If needed, it might also =0A= send
some control information along with each 802.3 packet.
In = this case, =0A= AC does not have knowledge of 802.11 header. It only needs
knowledge =0A= of
CAPWAP protocol, 802.1x termination, specific wireless related =0A= parameters.

What makes it split MAC? My understanding is that, if = AC =0A= terminates 802.11
frames and
does encyption/decryption and has = knowledge =0A= of 802.11 frames, then it is
Split MAC.
Is this understanding =0A= correct?

Thanks
Rama Krishna



Ch. Rama Krishna =0A= Prasad
Intoto Software(I) Pvt Ltd,
Uma Plaza, Nagarjuna =0A= circle,
Panjagutta. Hyderabad, AP
Tel No:s  2335 =0A= 8927/8928/8434

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

=0A= =0A= =0A= ------_=_NextPart_001_01C49028.079028A6-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From diameter-admin@frascone.com Wed Sep 1 11:01:24 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 LAA23671 for ; Wed, 1 Sep 2004 11:01:24 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4332921EA4 for ; Wed, 1 Sep 2004 05:12:38 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7962221C9F for ; Wed, 1 Sep 2004 05:11:40 -0400 (EDT) Date: Wed, 01 Sep 2004 05:11:40 -0400 Message-ID: <20040901091140.2098.8624.Mailman@xavier> Subject: frascone.com mailing list memberships reminder From: mailman-owner@wolverine.cnri.reston.va.us To: capwap-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: diameter-admin@frascone.com Errors-To: diameter-admin@frascone.com X-BeenThere: diameter@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a reminder, sent out once a month, about your frascone.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, capwap-request@frascone.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@wolverine. Thanks! Passwords for capwap-archive@lists.ietf.org: List Password // URL ---- -------- capwap@frascone.com xakour http://mail.frascone.com/mailman/options/capwap/capwap-archive%40lists.ietf.org From capwap-admin@frascone.com Wed Sep 1 13:02: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 NAA10716 for ; Wed, 1 Sep 2004 13:02:04 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 95CFD20413; Wed, 1 Sep 2004 12:46:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E76E820791; Wed, 1 Sep 2004 12:46:02 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6A45520791 for ; Wed, 1 Sep 2004 12:45:56 -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 38A4D20413 for ; Wed, 1 Sep 2004 12:45:54 -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_01C49045.BFAA873E" Subject: RE: [Capwap] Local MAC Message-ID: <55749BC69138654EBBC4C50BA4F5561002BF55FD@AIREMAIL.airespace.com> Thread-Topic: [Capwap] Local MAC Thread-Index: AcSP5xG3fD3GaO2uRN+96rM8siBwCgAPxrsmAAfTs8A= From: "Bob O'Hara" To: "Pat R. Calhoun" , "Chunduru Rama Krishna Prasad" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Sep 2004 10:04:31 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C49045.BFAA873E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think the difference can be summed up like this: =20 The protocol between an AC and the Local MAC and the Split MAC is semantically identical. Each uses a different syntax for this protocol. -Bob =20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun Sent: Wednesday, September 01, 2004 6:32 AM To: Chunduru Rama Krishna Prasad; capwap@frascone.com Subject: RE: [Capwap] Local MAC Great question. =20 As you observed below, the primary difference (from what I can tell) between split and local MAC is that while the former simply sends the frames untouched the latter reformulates the 802.11 messages into another format before sending them to the AC. So sure the PDUs look different, but in reality they are not really that different, right? =20 I mean what's the difference between sending a straight association request to the AC vs. breaking the association request down into small components and using the resulting information to create a message to be sent to the AC? =20 One could easily argue that using the straight association request will ensure forward compatibility with any new IEEE 802.11 related standard. Let's use 802.11k for instance, there are some new extensions that are added to existing MAC mgmt frames. So while a protocol that simply forwards the MAC mgmt frames to the AC will be able to handle 802.11k transparently, the other approach would require that the IETF WG get together and define a way to map the new 802.11k extensions into whatever protocol was created. Clearly, we cannot afford to have the IETF's protocol lag behind IEEE standards. =20 On the data path, what is the difference between sending the straight 802.11 frame vs. sending an 802.3 frame with some associated control information that was derived from the 802.11 frame to begin with? What happens when protocols like 802.11e change the actual format of the frame by inserting 2 bytes in the protocol header? Sending the straight 802.11 frame to the AC ensures that whatever solution we've come up with will be able to support these future extensions, while a protocol that breaks down the PDU into an 802.3 frame will cause these extensions to be lost. =20 It's really not like understanding the 802.11 protocol is a complex thing - there are plenty of implementations of 802.11 based products, and some of these are even available as open source. So I would argue that parsing 802.11 packets is much simpler than 802.3 with some control information since those stacks are publicly available. =20 PatC _____ =20 From: capwap-admin@frascone.com on behalf of Chunduru Rama Krishna Prasad Sent: Tue 8/31/2004 10:52 PM To: capwap@frascone.com Subject: [Capwap] Local MAC Hi , Please correct if my interpretation of LOCAL MAC is wrong. WTP terminates 802.11 control packets and nothing is sent to AC . WTP terminates 802.11 mangement frames and corresponding events are sent to AC. WTP terminates 802.11 data frames, does decryption/encryption based on unique keys correspond to wireless stations, extracts 802.3 packet from the frame and send the frame across to AC. If needed, it might also send some control information along with each 802.3 packet. In this case, AC does not have knowledge of 802.11 header. It only needs knowledge of CAPWAP protocol, 802.1x termination, specific wireless related parameters. What makes it split MAC? My understanding is that, if AC terminates 802.11 frames and does encyption/decryption and has knowledge of 802.11 frames, then it is Split MAC. Is this understanding correct? Thanks Rama Krishna Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap ------_=_NextPart_001_01C49045.BFAA873E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I=20 think the difference can be summed up like this:
 
The=20 protocol between an AC and the Local MAC and the Split MAC is = semantically=20 identical.  Each uses a different syntax for this=20 protocol.

 -Bob
 

-----Original Message-----
From: = capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Pat R.=20 Calhoun
Sent: Wednesday, September 01, 2004 6:32 = AM
To:=20 Chunduru Rama Krishna Prasad; capwap@frascone.com
Subject: RE: = [Capwap] Local MAC

Great = question.
 
As you observed below, the = primary=20 difference (from what I can tell) between
split and local MAC is that = while the=20 former simply sends the frames untouched
the latter reformulates the = 802.11 messages=20 into another format before sending
them to the AC. So sure the = PDUs look=20 different, but in reality they are not really
that different, = right?
 
I mean what's the difference = between=20 sending a straight association request to the
AC vs. breaking the = association request=20 down into small components and using the
resulting information to = create a message=20 to be sent to the AC?
 
One could easily argue that = using the=20 straight association request will ensure forward
compatibility with any new = IEEE 802.11=20 related standard. Let's use 802.11k for instance,
there are some new extensions = that are=20 added to existing MAC mgmt frames. So while
a protocol that simply = forwards the MAC=20 mgmt frames to the AC will be able to handle
802.11k transparently, the = other approach=20 would require that the IETF WG get together
and define a way to map the = new 802.11k=20 extensions into whatever protocol was created.
Clearly, we cannot afford to = have the=20 IETF's protocol lag behind IEEE standards.
 
On the data path, what is the = difference=20 between sending the straight 802.11 frame
vs. sending an 802.3 frame = with some=20 associated control information that was derived
from the 802.11 frame to = begin with? What=20 happens when protocols like 802.11e change
the actual format of the = frame by inserting=20 2 bytes in the protocol header? Sending the
straight 802.11 frame to the = AC ensures=20 that whatever solution we've come up with will
be able to support these = future extensions,=20 while a protocol that breaks down the PDU
into an 802.3 frame will = cause these=20 extensions to be lost.
 
It's really not like = understanding the=20 802.11 protocol is a complex thing - there are
plenty of implementations of = 802.11 based=20 products, and some of these are even available
as open source. So I would = argue that=20 parsing 802.11 packets is much simpler than 802.3
with some control information = since those=20 stacks are publicly available.
 
PatC

From: capwap-admin@frascone.com on = behalf of=20 Chunduru Rama Krishna Prasad
Sent: Tue 8/31/2004 10:52=20 PM
To: capwap@frascone.com
Subject: [Capwap] Local=20 MAC

Hi ,

Please correct if my interpretation of = LOCAL MAC is=20 wrong.
WTP terminates 802.11 control packets and nothing is sent to = AC=20 .
WTP terminates 802.11 mangement frames and corresponding events are = sent=20 to
AC.
WTP terminates 802.11 data frames, does = decryption/encryption based=20 on
unique keys correspond to wireless stations, extracts 802.3 packet = from=20 the
frame and send the frame across to AC. If needed, it might also=20 send
some control information along with each 802.3 packet.
In = this case,=20 AC does not have knowledge of 802.11 header. It only needs
knowledge=20 of
CAPWAP protocol, 802.1x termination, specific wireless related=20 parameters.

What makes it split MAC? My understanding is that, if = AC=20 terminates 802.11
frames and
does encyption/decryption and has = knowledge=20 of 802.11 frames, then it is
Split MAC.
Is this understanding=20 correct?

Thanks
Rama Krishna



Ch. Rama Krishna=20 Prasad
Intoto Software(I) Pvt Ltd,
Uma Plaza, Nagarjuna=20 circle,
Panjagutta. Hyderabad, AP
Tel No:s  2335=20 8927/8928/8434

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

------_=_NextPart_001_01C49045.BFAA873E-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 1 14:37: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 OAA19859 for ; Wed, 1 Sep 2004 14:37:26 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9AFD821CE7; Wed, 1 Sep 2004 14:22:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E0F9321CE9; Wed, 1 Sep 2004 14:22:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0B4A821CE9 for ; Wed, 1 Sep 2004 14:21:47 -0400 (EDT) Received: from fmsfmr004.fm.intel.com (fmr11.intel.com [192.55.52.31]) by mail.frascone.com (Postfix) with ESMTP id 5004421CE7 for ; Wed, 1 Sep 2004 14:21:44 -0400 (EDT) Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by fmsfmr004.fm.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 i81IdLEF007325; Wed, 1 Sep 2004 18:39:21 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.fm.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 i81Ic2wT010662; Wed, 1 Sep 2004 18:39:36 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 M2004090111365531118 ; Wed, 01 Sep 2004 11:36:55 -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, 1 Sep 2004 11:36:55 -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_01C49052.A771F040" Subject: RE: [Capwap] Local MAC Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE01F9FC2E@orsmsx408> Thread-Topic: [Capwap] Local MAC Thread-Index: AcSP5xG3fD3GaO2uRN+96rM8siBwCgAPxrsmAAfTs8AAAo3HgA== From: "Yang, Lily L" To: "Bob O'Hara" , "Pat R. Calhoun" , "Chunduru Rama Krishna Prasad" , X-OriginalArrivalTime: 01 Sep 2004 18:36:55.0156 (UTC) FILETIME=[A7E24B40:01C49052] 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, 1 Sep 2004 11:36:53 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C49052.A771F040 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is there any difference in terms of the sequence of request and response events that happen? The sequence that I understand for Split MAC, e.g. for an association request is: 1) request from STA to WTP 2) request forwarded from WTP to AC 3) AC talks to AS, and gets a response from AS 4) AC sends response to WTP 5) WTP forwards the response to STA Does the Local MAC follow the exact same sequence, even though using different PDU between WTP and AC for step 2) and 4)?=20 =20 Even if they follow the same sequence of events for association request, does that hold true in general for all the management frame handling, esp. those that don't involve backend AS? For example, take ADDTS request in the 11e. I can imagine two different sequences here: 1) ADDTS request from STA to WTP 2) ADDTS request forwarded from WTP to AC 3) ADDTS response made by AC=20 4) AC sends ADDTS response to WTP 5) WTP forwards the response to STA Or, 1) ADDTS request from STA to WTP 2) ADDTS response made by WTP 3) WTP sends response to STA =20 4) WTP report the response to AC =20 The round trip time for the former sequence is obviously longer than the latter. Is there difference in Split MAC and Local MAC on that aspect? =20 ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Bob O'Hara Sent: Wednesday, September 01, 2004 10:05 AM To: Pat R. Calhoun; Chunduru Rama Krishna Prasad; capwap@frascone.com Subject: RE: [Capwap] Local MAC =20 I think the difference can be summed up like this: =20 The protocol between an AC and the Local MAC and the Split MAC is semantically identical. Each uses a different syntax for this protocol. -Bob =20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun Sent: Wednesday, September 01, 2004 6:32 AM To: Chunduru Rama Krishna Prasad; capwap@frascone.com Subject: RE: [Capwap] Local MAC Great question. =20 As you observed below, the primary difference (from what I can tell) between split and local MAC is that while the former simply sends the frames untouched the latter reformulates the 802.11 messages into another format before sending them to the AC. So sure the PDUs look different, but in reality they are not really that different, right? =20 I mean what's the difference between sending a straight association request to the AC vs. breaking the association request down into small components and using the resulting information to create a message to be sent to the AC? =20 One could easily argue that using the straight association request will ensure forward compatibility with any new IEEE 802.11 related standard. Let's use 802.11k for instance, there are some new extensions that are added to existing MAC mgmt frames. So while a protocol that simply forwards the MAC mgmt frames to the AC will be able to handle 802.11k transparently, the other approach would require that the IETF WG get together and define a way to map the new 802.11k extensions into whatever protocol was created. Clearly, we cannot afford to have the IETF's protocol lag behind IEEE standards. =20 On the data path, what is the difference between sending the straight 802.11 frame vs. sending an 802.3 frame with some associated control information that was derived from the 802.11 frame to begin with? What happens when protocols like 802.11e change the actual format of the frame by inserting 2 bytes in the protocol header? Sending the straight 802.11 frame to the AC ensures that whatever solution we've come up with will be able to support these future extensions, while a protocol that breaks down the PDU into an 802.3 frame will cause these extensions to be lost. =20 It's really not like understanding the 802.11 protocol is a complex thing - there are plenty of implementations of 802.11 based products, and some of these are even available as open source. So I would argue that parsing 802.11 packets is much simpler than 802.3 with some control information since those stacks are publicly available. =20 PatC =20 ________________________________ From: capwap-admin@frascone.com on behalf of Chunduru Rama Krishna Prasad Sent: Tue 8/31/2004 10:52 PM To: capwap@frascone.com Subject: [Capwap] Local MAC Hi , Please correct if my interpretation of LOCAL MAC is wrong. WTP terminates 802.11 control packets and nothing is sent to AC . WTP terminates 802.11 mangement frames and corresponding events are sent to AC. WTP terminates 802.11 data frames, does decryption/encryption based on unique keys correspond to wireless stations, extracts 802.3 packet from the frame and send the frame across to AC. If needed, it might also send some control information along with each 802.3 packet. In this case, AC does not have knowledge of 802.11 header. It only needs knowledge of CAPWAP protocol, 802.1x termination, specific wireless related parameters. What makes it split MAC? My understanding is that, if AC terminates 802.11 frames and does encyption/decryption and has knowledge of 802.11 frames, then it is Split MAC. Is this understanding correct? Thanks Rama Krishna Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap ------_=_NextPart_001_01C49052.A771F040 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Is there any difference in terms of = the sequence of request and response events that happen? The sequence that I understand for Split MAC, e.g. for an association request = is:

1)       = request from STA to WTP

2)       = request forwarded from WTP to = AC

3)       = AC talks to AS, and gets a response from = AS

4)       = AC sends response to WTP

5)       = WTP forwards the response to = STA

Does the Local MAC follow the exact = same sequence, even though using different PDU between WTP and AC for step 2) = and 4)?

 

Even if they follow the same = sequence of events for association request, does that hold true in general for all = the management frame handling, esp. those that don’t involve backend = AS? For example, take ADDTS request in the 11e. I can imagine two different = sequences here:

1)       = ADDTS request from STA to WTP

2)       = ADDTS request forwarded from WTP to = AC

3)       = ADDTS response made by AC

4)       = AC sends ADDTS response to WTP

5)       = WTP forwards the response to = STA

Or,

1)       = ADDTS request from STA to WTP

2)       = ADDTS response made by WTP

3)       = WTP sends response to STA =  

4)       = WTP report the response to AC

 

The round trip time for the former sequence is obviously longer than the latter. Is there difference in = Split MAC and Local MAC on that aspect?

 

From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Bob O'Hara
Sent: Wednesday, = September 01, 2004 10:05 AM
To: Pat R. Calhoun; = Chunduru Rama Krishna Prasad; capwap@frascone.com
Subject: RE: [Capwap] = Local MAC

 

I think the difference can be = summed up like this:

 

The protocol between an AC and the = Local MAC and the Split MAC is semantically identical.  Each uses a = different syntax for this protocol.

 -Bob
 

-----Original = Message-----
From: = capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun
Sent: Wednesday, = September 01, 2004 6:32 AM
To: Chunduru Rama Krishna = Prasad; capwap@frascone.com
Subject: RE: [Capwap] = Local MAC

Great = question.

 

As you observed below, the primary difference (from = what I can tell) between

split and local MAC is that while the former simply = sends the frames untouched

the latter reformulates the 802.11 messages into = another format before sending

them to the AC. So sure the PDUs look different, but = in reality they are not really

that different, right?

 

I mean what's the difference between sending a = straight association request to the

AC vs. breaking the association request down into = small components and using the

resulting information to create a message to be sent = to the AC?

 

One could easily argue that using the straight = association request will ensure forward

compatibility with any new IEEE 802.11 related = standard. Let's use 802.11k for instance,

there are some new extensions that are added to = existing MAC mgmt frames. So while

a protocol that simply forwards the MAC mgmt frames = to the AC will be able to handle

802.11k transparently, the other approach would = require that the IETF WG get together

and define a way to map the new 802.11k extensions = into whatever protocol was created.

Clearly, we cannot afford to have the IETF's protocol = lag behind IEEE standards.

 

On the data path, what is the difference between = sending the straight 802.11 frame

vs. sending an 802.3 frame with some = associated control information that was derived

from the 802.11 frame to begin with? What happens = when protocols like 802.11e change

the actual format of the frame by inserting 2 bytes = in the protocol header? Sending the

straight 802.11 frame to the AC ensures that whatever solution we've come up with will

be able to support these future extensions, while a = protocol that breaks down the PDU

into an 802.3 frame will cause these extensions to be = lost.

 

It's really not like understanding the 802.11 = protocol is a complex thing - there are

plenty of implementations of 802.11 based products, = and some of these are even available

as open source. So I would argue that parsing 802.11 = packets is much simpler than 802.3

with some control information since those stacks are publicly available.

 

PatC

 

From: capwap-admin@frascone.com on behalf of Chunduru Rama Krishna Prasad
Sent: Tue 8/31/2004 10:52 = PM
To: = capwap@frascone.com
Subject: [Capwap] Local = MAC

Hi ,

Please correct if my interpretation of LOCAL MAC is wrong.
WTP terminates 802.11 control packets and nothing is sent to AC .
WTP terminates 802.11 mangement frames and corresponding events are sent = to
AC.
WTP terminates 802.11 data frames, does decryption/encryption based = on
unique keys correspond to wireless stations, extracts 802.3 packet from = the
frame and send the frame across to AC. If needed, it might also send
some control information along with each 802.3 packet.
In this case, AC does not have knowledge of 802.11 header. It only = needs
knowledge of
CAPWAP protocol, 802.1x termination, specific wireless related = parameters.

What makes it split MAC? My understanding is that, if AC terminates = 802.11
frames and
does encyption/decryption and has knowledge of 802.11 frames, then it = is
Split MAC.
Is this understanding correct?

Thanks
Rama Krishna



Ch. Rama Krishna Prasad
Intoto Software(I) Pvt Ltd,
Uma = Plaza, Nagarjuna circle,
Panjagutta. Hyderabad, AP
Tel No:s  2335 8927/8928/8434

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

------_=_NextPart_001_01C49052.A771F040-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 1 15:14: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 PAA22661 for ; Wed, 1 Sep 2004 15:14:42 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D8FCE21008; Wed, 1 Sep 2004 14:56:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DB207202A7; Wed, 1 Sep 2004 14:56:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A138B20DAC for ; Wed, 1 Sep 2004 14:55:22 -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 70C0A20D3B for ; Wed, 1 Sep 2004 14:55:19 -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_01C49057.D3FEC046" Subject: RE: [Capwap] Local MAC Message-ID: <55749BC69138654EBBC4C50BA4F5561002BF5623@AIREMAIL.airespace.com> Thread-Topic: [Capwap] Local MAC Thread-Index: AcSP5xG3fD3GaO2uRN+96rM8siBwCgAPxrsmAAfTs8AAAo3HgAAB74Gw 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: Wed, 1 Sep 2004 12:13:54 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C49057.D3FEC046 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lily, =20 If the description of the local MAC in the taxonomy is accurate, both local MAC and split MAC perform your first example identically. For the second example (drawn from 802.11e), both should behave the same, as well, performing the 5-step process. Otherwise, the AC isn't providing any "C". -Bob =20 -----Original Message----- From: Yang, Lily L [mailto:lily.l.yang@intel.com]=20 Sent: Wednesday, September 01, 2004 11:37 AM To: Bob O'Hara; Pat R. Calhoun; Chunduru Rama Krishna Prasad; capwap@frascone.com Subject: RE: [Capwap] Local MAC Is there any difference in terms of the sequence of request and response events that happen? The sequence that I understand for Split MAC, e.g. for an association request is: 1) request from STA to WTP 2) request forwarded from WTP to AC 3) AC talks to AS, and gets a response from AS 4) AC sends response to WTP 5) WTP forwards the response to STA Does the Local MAC follow the exact same sequence, even though using different PDU between WTP and AC for step 2) and 4)?=20 =20 Even if they follow the same sequence of events for association request, does that hold true in general for all the management frame handling, esp. those that don't involve backend AS? For example, take ADDTS request in the 11e. I can imagine two different sequences here: 1) ADDTS request from STA to WTP 2) ADDTS request forwarded from WTP to AC 3) ADDTS response made by AC=20 4) AC sends ADDTS response to WTP 5) WTP forwards the response to STA Or, 1) ADDTS request from STA to WTP 2) ADDTS response made by WTP 3) WTP sends response to STA =20 4) WTP report the response to AC =20 The round trip time for the former sequence is obviously longer than the latter. Is there difference in Split MAC and Local MAC on that aspect? =20 _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Bob O'Hara Sent: Wednesday, September 01, 2004 10:05 AM To: Pat R. Calhoun; Chunduru Rama Krishna Prasad; capwap@frascone.com Subject: RE: [Capwap] Local MAC =20 I think the difference can be summed up like this: =20 The protocol between an AC and the Local MAC and the Split MAC is semantically identical. Each uses a different syntax for this protocol. -Bob =20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun Sent: Wednesday, September 01, 2004 6:32 AM To: Chunduru Rama Krishna Prasad; capwap@frascone.com Subject: RE: [Capwap] Local MAC Great question. =20 As you observed below, the primary difference (from what I can tell) between split and local MAC is that while the former simply sends the frames untouched the latter reformulates the 802.11 messages into another format before sending them to the AC. So sure the PDUs look different, but in reality they are not really that different, right? =20 I mean what's the difference between sending a straight association request to the AC vs. breaking the association request down into small components and using the resulting information to create a message to be sent to the AC? =20 One could easily argue that using the straight association request will ensure forward compatibility with any new IEEE 802.11 related standard. Let's use 802.11k for instance, there are some new extensions that are added to existing MAC mgmt frames. So while a protocol that simply forwards the MAC mgmt frames to the AC will be able to handle 802.11k transparently, the other approach would require that the IETF WG get together and define a way to map the new 802.11k extensions into whatever protocol was created. Clearly, we cannot afford to have the IETF's protocol lag behind IEEE standards. =20 On the data path, what is the difference between sending the straight 802.11 frame vs. sending an 802.3 frame with some associated control information that was derived from the 802.11 frame to begin with? What happens when protocols like 802.11e change the actual format of the frame by inserting 2 bytes in the protocol header? Sending the straight 802.11 frame to the AC ensures that whatever solution we've come up with will be able to support these future extensions, while a protocol that breaks down the PDU into an 802.3 frame will cause these extensions to be lost. =20 It's really not like understanding the 802.11 protocol is a complex thing - there are plenty of implementations of 802.11 based products, and some of these are even available as open source. So I would argue that parsing 802.11 packets is much simpler than 802.3 with some control information since those stacks are publicly available. =20 PatC =20 _____ =20 From: capwap-admin@frascone.com on behalf of Chunduru Rama Krishna Prasad Sent: Tue 8/31/2004 10:52 PM To: capwap@frascone.com Subject: [Capwap] Local MAC Hi , Please correct if my interpretation of LOCAL MAC is wrong. WTP terminates 802.11 control packets and nothing is sent to AC . WTP terminates 802.11 mangement frames and corresponding events are sent to AC. WTP terminates 802.11 data frames, does decryption/encryption based on unique keys correspond to wireless stations, extracts 802.3 packet from the frame and send the frame across to AC. If needed, it might also send some control information along with each 802.3 packet. In this case, AC does not have knowledge of 802.11 header. It only needs knowledge of CAPWAP protocol, 802.1x termination, specific wireless related parameters. What makes it split MAC? My understanding is that, if AC terminates 802.11 frames and does encyption/decryption and has knowledge of 802.11 frames, then it is Split MAC. Is this understanding correct? Thanks Rama Krishna Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap ------_=_NextPart_001_01C49057.D3FEC046 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Lily,
 
If the=20 description of the local MAC in the taxonomy is accurate, both local MAC = and=20 split MAC perform your first example identically.  For the second = example=20 (drawn from 802.11e), both should behave the same, as well, performing = the=20 5-step process.  Otherwise, the AC isn't providing any=20 "C".

 -Bob
 

-----Original Message-----
From: Yang, Lily L=20 [mailto:lily.l.yang@intel.com]
Sent: Wednesday, September 01, = 2004=20 11:37 AM
To: Bob O'Hara; Pat R. Calhoun; Chunduru Rama Krishna = Prasad;=20 capwap@frascone.com
Subject: RE: [Capwap] Local=20 MAC

Is there any = difference=20 in terms of the sequence of request and response events that happen? The = sequence that I understand for Split MAC, e.g. for an association = request=20 is:

1)      =20 request=20 from STA to WTP

2)      =20 request=20 forwarded from WTP to AC

3)      =20 AC talks=20 to AS, and gets a response from AS

4)      =20 AC sends=20 response to WTP

5)      =20 WTP=20 forwards the response to STA

Does the = Local MAC=20 follow the exact same sequence, even though using different PDU between = WTP and=20 AC for step 2) and 4)?

 

Even if they = follow the=20 same sequence of events for association request, does that hold true in = general=20 for all the management frame handling, esp. those that don’t = involve backend AS?=20 For example, take ADDTS request in the 11e. I can imagine two different=20 sequences here:

1)      =20 ADDTS=20 request from STA to WTP

2)      =20 ADDTS=20 request forwarded from WTP to AC

3)      =20 ADDTS=20 response made by AC

4)      =20 AC sends=20 ADDTS response to WTP

5)      =20 WTP=20 forwards the response to STA

Or,

1)      =20 ADDTS=20 request from STA to WTP

2)      =20 ADDTS=20 response made by WTP

3)      =20 WTP sends=20 response to STA  

4)      =20 WTP report=20 the response to AC

 

The round = trip time for=20 the former sequence is obviously longer than the latter. Is there = difference in=20 Split MAC and Local MAC on that aspect?

 

From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Bob = O'Hara
Sent: Wednesday, September 01, = 2004 10:05=20 AM
To: Pat R. = Calhoun; Chunduru=20 Rama Krishna Prasad; capwap@frascone.com
Subject: RE: [Capwap] Local=20 MAC

 

I think the = difference=20 can be summed up like this:

 

The protocol = between an=20 AC and the Local MAC and the Split MAC is semantically identical.  = Each=20 uses a different syntax for this = protocol.

 -Bob
 =20

-----Original=20 Message-----
From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. = Calhoun
Sent: Wednesday, September 01, = 2004 6:32=20 AM
To: Chunduru Rama = Krishna=20 Prasad; capwap@frascone.com
Subject: RE: [Capwap] Local=20 MAC

Great=20 question.

 

As you observed below, the = primary=20 difference (from what I can tell) = between

split and local MAC is = that while=20 the former simply sends the frames = untouched

the latter reformulates = the 802.11=20 messages into another format before = sending

them to the AC. So sure = the PDUs=20 look different, but in reality they are not=20 really

that different,=20 right?

 

I mean what's the = difference between=20 sending a straight association request to = the

AC vs. breaking the = association=20 request down into small components and using=20 the

resulting information to = create a=20 message to be sent to the AC?

 

One could easily argue = that using=20 the straight association request will ensure=20 forward

compatibility with any new = IEEE=20 802.11 related standard. Let's use 802.11k for=20 instance,

there are some new = extensions that=20 are added to existing MAC mgmt frames. So=20 while

a protocol that simply = forwards the=20 MAC mgmt frames to the AC will be able to=20 handle

802.11k transparently, the = other=20 approach would require that the IETF WG get=20 together

and define a way to map = the new=20 802.11k extensions into whatever protocol was=20 created.

Clearly, we cannot afford = to have=20 the IETF's protocol lag behind IEEE=20 standards.

 

On the data path, what is = the=20 difference between sending the straight 802.11=20 frame

vs. sending an 802.3 frame = with some=20 associated control information that was=20 derived

from the 802.11 frame to = begin with?=20 What happens when protocols like 802.11e=20 change

the actual format of the = frame by=20 inserting 2 bytes in the protocol header? Sending=20 the

straight 802.11 frame to = the AC=20 ensures that whatever solution we've come up with=20 will

be able to support these = future=20 extensions, while a protocol that breaks down the=20 PDU

into an 802.3 frame will = cause these=20 extensions to be lost.

 

It's really not like = understanding=20 the 802.11 protocol is a complex thing - there=20 are

plenty of implementations = of 802.11=20 based products, and some of these are even=20 available

as open source. So I would = argue=20 that parsing 802.11 packets is much simpler than=20 802.3

with some control = information since=20 those stacks are publicly available.

 

PatC

 

From:=20 capwap-admin@frascone.com on behalf of Chunduru Rama Krishna = Prasad
Sent: Tue 8/31/2004 10:52 = PM
To: = capwap@frascone.com
Subject: [Capwap] Local=20 MAC

Hi=20 ,

Please correct if my interpretation of LOCAL MAC is = wrong.
WTP=20 terminates 802.11 control packets and nothing is sent to AC .
WTP = terminates=20 802.11 mangement frames and corresponding events are sent = to
AC.
WTP=20 terminates 802.11 data frames, does decryption/encryption based = on
unique=20 keys correspond to wireless stations, extracts 802.3 packet from = the
frame=20 and send the frame across to AC. If needed, it might also send
some = control=20 information along with each 802.3 packet.
In this case, AC does not = have=20 knowledge of 802.11 header. It only needs
knowledge of
CAPWAP = protocol,=20 802.1x termination, specific wireless related parameters.

What = makes it=20 split MAC? My understanding is that, if AC terminates 802.11
frames=20 and
does encyption/decryption and has knowledge of 802.11 frames, = then it=20 is
Split MAC.
Is this understanding correct?

Thanks
Rama = Krishna



Ch. Rama = Krishna=20 Prasad
Intoto Software(I) Pvt Ltd,
Uma Plaza, Nagarjuna = circle,
Panjagutta.=20 Hyderabad,=20 AP
Tel No:s  2335=20 8927/8928/8434

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

<= /DIV> ------_=_NextPart_001_01C49057.D3FEC046-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 1 15:31: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 PAA24378 for ; Wed, 1 Sep 2004 15:31:28 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8252C2087E; Wed, 1 Sep 2004 15:16:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2B80320D31; Wed, 1 Sep 2004 15:16:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8790E2087E; Wed, 1 Sep 2004 15:15:58 -0400 (EDT) Received: from note_back.accton.com (note_back.accton.com [67.115.116.242]) by mail.frascone.com (Postfix) with ESMTP id C44812008E; Wed, 1 Sep 2004 15:15:56 -0400 (EDT) Subject: RE: [Capwap] Local MAC To: "Bob O'Hara" Cc: capwap@frascone.com, capwap-admin@frascone.com, "Pat R. Calhoun" , "Chunduru Rama Krishna Prasad" 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 09/01/2004 12:07:55 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: Wed, 1 Sep 2004 12:47:26 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Hi Bob and Pat, Agree with your interpretation on the difference between Local MAC and Split MAC. Thanks. As to what is the best mechanism, I believe this is still open for debate. Maybe the opinion regarding the future protocol should be flexible (mentioned by Suds Jain in a different note) may not be a bad idea after all. I myself have not been convinced one way is better than the other. Since Pat has listed the merits of transmitting the full 802.11 frame between WTP and AC, I am listing the chanllenges below to balance the viewpoints to extend the discussion. For control and management messages, we all agree most information on 802.11 header will be needed in the AC. Some extra information may be needed as well. Hence, yes transmitting the original 802.11 header (may have to be encapsulated inside a CAPWAP header anyway) is straightforward. On the other hand, I didn't see much wrong if the new protocol header is defined flexible enough to include all the needed information. The merit of the latter is simply potentially smaller frame overhead. For data traffic, if WTP simply sends the full 802.11 frame to AC inside a L3 CAPWAP tunnel the frame may look like: 802.3 header + IP + UDP + CAPWAP header + 802.11 header + MSDU (say, ip+tcp+ftp ...) If the 802.11 & 802.3 bridging function is performed in WTP (one way to implement Local MAC), and some smartness (filtering, QoS...) can be set up in the AC via the control/management messages in advance, maybe we can get rid of the necessity for every single frame to carry the information (AC can differentiate the frames according to the L2 or L3 source address). In this case, the AC can forward the MSDU as a normal switch/router would do. Using above example, the frame can look like a normal 802.3 frame: 802.3 header + MSDU (say, ip+tcp+ftp...) or, if L3 cloud is between WTP and AC: 802.3 header + IP tunnel header + MSUD (day, ip+tcp+ftp) The advantage is not only the smaller frame overhead, but also the easiness of accelerated processing by hardware. Comments? --Tyan-Shu Jou "Bob O'Hara" , com> "Chunduru Rama Krishna Prasad" , Sent by: capwap-admin@fr cc: ascone.com Subject: RE: [Capwap] Local MAC 09/01/2004 10:04 AM I think the difference can be summed up like this: The protocol between an AC and the Local MAC and the Split MAC is semantically identical. Each uses a different syntax for this protocol. -Bob -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun Sent: Wednesday, September 01, 2004 6:32 AM To: Chunduru Rama Krishna Prasad; capwap@frascone.com Subject: RE: [Capwap] Local MAC Great question. As you observed below, the primary difference (from what I can tell) between split and local MAC is that while the former simply sends the frames untouched the latter reformulates the 802.11 messages into another format before sending them to the AC. So sure the PDUs look different, but in reality they are not really that different, right? I mean what's the difference between sending a straight association request to the AC vs. breaking the association request down into small components and using the resulting information to create a message to be sent to the AC? One could easily argue that using the straight association request will ensure forward compatibility with any new IEEE 802.11 related standard. Let's use 802.11k for instance, there are some new extensions that are added to existing MAC mgmt frames. So while a protocol that simply forwards the MAC mgmt frames to the AC will be able to handle 802.11k transparently, the other approach would require that the IETF WG get together and define a way to map the new 802.11k extensions into whatever protocol was created. Clearly, we cannot afford to have the IETF's protocol lag behind IEEE standards. On the data path, what is the difference between sending the straight 802.11 frame vs. sending an 802.3 frame with some associated control information that was derived from the 802.11 frame to begin with? What happens when protocols like 802.11e change the actual format of the frame by inserting 2 bytes in the protocol header? Sending the straight 802.11 frame to the AC ensures that whatever solution we've come up with will be able to support these future extensions, while a protocol that breaks down the PDU into an 802.3 frame will cause these extensions to be lost. It's really not like understanding the 802.11 protocol is a complex thing - there are plenty of implementations of 802.11 based products, and some of these are even available as open source. So I would argue that parsing 802.11 packets is much simpler than 802.3 with some control information since those stacks are publicly available. PatC From: capwap-admin@frascone.com on behalf of Chunduru Rama Krishna Prasad Sent: Tue 8/31/2004 10:52 PM To: capwap@frascone.com Subject: [Capwap] Local MAC Hi , Please correct if my interpretation of LOCAL MAC is wrong. WTP terminates 802.11 control packets and nothing is sent to AC . WTP terminates 802.11 mangement frames and corresponding events are sent to AC. WTP terminates 802.11 data frames, does decryption/encryption based on unique keys correspond to wireless stations, extracts 802.3 packet from the frame and send the frame across to AC. If needed, it might also send some control information along with each 802.3 packet. In this case, AC does not have knowledge of 802.11 header. It only needs knowledge of CAPWAP protocol, 802.1x termination, specific wireless related parameters. What makes it split MAC? My understanding is that, if AC terminates 802.11 frames and does encyption/decryption and has knowledge of 802.11 frames, then it is Split MAC. Is this understanding correct? Thanks Rama Krishna Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 _______________________________________________ Capwap mailing 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 Sep 1 18:04: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 SAA09364 for ; Wed, 1 Sep 2004 18:04:39 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B00AE20273; Wed, 1 Sep 2004 17:49:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3B7D72033F; Wed, 1 Sep 2004 17: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 BFC432033F for ; Wed, 1 Sep 2004 17:48:39 -0400 (EDT) Received: from hermes-pilot.fm.intel.com (fmr99.intel.com [192.55.52.32]) by mail.frascone.com (Postfix) with ESMTP id 6E15120273 for ; Wed, 1 Sep 2004 17:48:37 -0400 (EDT) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes-pilot.fm.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 i81M7JHA018559 for ; Wed, 1 Sep 2004 22:07:19 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.fm.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 i81M4Avc001924 for ; Wed, 1 Sep 2004 22:04:15 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 M2004090115034119620 for ; Wed, 01 Sep 2004 15:03:41 -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, 1 Sep 2004 15:03:38 -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_01C4906F.883A8991" Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE01837029@orsmsx408> Thread-Topic: CAPWAP Architecture Taxonomy V05 submitted, ready for WG Last Call Thread-Index: AcSQb4hXxIhopGj0RNWLxhuEZTyqDA== From: "Yang, Lily L" To: X-OriginalArrivalTime: 01 Sep 2004 22:03:38.0132 (UTC) FILETIME=[88A23D40:01C4906F] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] CAPWAP Architecture Taxonomy V05 submitted, 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: Wed, 1 Sep 2004 15:03:37 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C4906F.883A8991 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all=20 We now have v05 of the CAPWAP Architecture Taxonomy draft submitted to the IETF repository: http://www.ietf.org/internet-drafts/draft-ietf-capwap-arch-05.txt 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 - 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." 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 change log for v05 --------------------- ------_=_NextPart_001_01C4906F.883A8991 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable CAPWAP Architecture Taxonomy V05 submitted, ready for WG Last = Call

Hi, all

We now have v05 of the CAPWAP = Architecture Taxonomy draft submitted to the IETF repository:
http://www.ietf.org/internet-drafts/draft-ietf-capwap-arch= -05.txt

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.

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

[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"

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

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.
[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 change log for v05 = ---------------------


------_=_NextPart_001_01C4906F.883A8991-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Sep 2 00:20: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 AAA15844 for ; Thu, 2 Sep 2004 00:20:29 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F13E920384; Thu, 2 Sep 2004 00:05:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 67D9D21D76; Thu, 2 Sep 2004 00:05:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9615521D76 for ; Thu, 2 Sep 2004 00:05:00 -0400 (EDT) Received: from brahma.intotoind.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by mail.frascone.com (Postfix) with ESMTP id 3C15620384 for ; Thu, 2 Sep 2004 00:04:57 -0400 (EDT) Received: from rkp.intoto.com (1mc70.intotoind.com [172.16.1.70]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i824K7DX017763; Thu, 2 Sep 2004 09:50:07 +0530 Message-Id: <5.1.0.14.0.20040902095919.00a8b080@172.16.1.10> X-Sender: rkp@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: "Bob O'Hara" , "Pat R. Calhoun" , From: Chunduru Rama Krishna Prasad Subject: RE: [Capwap] Local MAC In-Reply-To: <55749BC69138654EBBC4C50BA4F5561002BF55FD@AIREMAIL.airespac e.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_3705937==_.ALT" X-Scanned-By: MIMEDefang 2.41 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 02 Sep 2004 10:00:02 +0530 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) --=====================_3705937==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed What about encryption/decryption of 802.11 packets? In Local MAC, as I understand clearly that it is done at the WTP. And I think, that is good thing to do. Does split MAC definition allow this operation at WTPs? Thanks Rama Krishna At 10:04 AM 9/1/2004 -0700, Bob O'Hara wrote: >I think the difference can be summed up like this: > >The protocol between an AC and the Local MAC and the Split MAC is >semantically identical. Each uses a different syntax for this protocol. > > -Bob > >-----Original Message----- >From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On >Behalf Of Pat R. Calhoun >Sent: Wednesday, September 01, 2004 6:32 AM >To: Chunduru Rama Krishna Prasad; capwap@frascone.com >Subject: RE: [Capwap] Local MAC > >Great question. > >As you observed below, the primary difference (from what I can tell) between >split and local MAC is that while the former simply sends the frames untouched >the latter reformulates the 802.11 messages into another format before sending >them to the AC. So sure the PDUs look different, but in reality they are >not really >that different, right? > >I mean what's the difference between sending a straight association >request to the >AC vs. breaking the association request down into small components and >using the >resulting information to create a message to be sent to the AC? > >One could easily argue that using the straight association request will >ensure forward >compatibility with any new IEEE 802.11 related standard. Let's use 802.11k >for instance, >there are some new extensions that are added to existing MAC mgmt frames. >So while >a protocol that simply forwards the MAC mgmt frames to the AC will be able >to handle >802.11k transparently, the other approach would require that the IETF WG >get together >and define a way to map the new 802.11k extensions into whatever protocol >was created. >Clearly, we cannot afford to have the IETF's protocol lag behind IEEE >standards. > >On the data path, what is the difference between sending the straight >802.11 frame >vs. sending an 802.3 frame with some associated control information that >was derived >from the 802.11 frame to begin with? What happens when protocols like >802.11e change >the actual format of the frame by inserting 2 bytes in the protocol >header? Sending the >straight 802.11 frame to the AC ensures that whatever solution we've come >up with will >be able to support these future extensions, while a protocol that breaks >down the PDU >into an 802.3 frame will cause these extensions to be lost. > >It's really not like understanding the 802.11 protocol is a complex thing >- there are >plenty of implementations of 802.11 based products, and some of these are >even available >as open source. So I would argue that parsing 802.11 packets is much >simpler than 802.3 >with some control information since those stacks are publicly available. > >PatC > > >---------- >From: capwap-admin@frascone.com on behalf of Chunduru Rama Krishna Prasad >Sent: Tue 8/31/2004 10:52 PM >To: capwap@frascone.com >Subject: [Capwap] Local MAC > >Hi , > >Please correct if my interpretation of LOCAL MAC is wrong. >WTP terminates 802.11 control packets and nothing is sent to AC . >WTP terminates 802.11 mangement frames and corresponding events are sent to >AC. >WTP terminates 802.11 data frames, does decryption/encryption based on >unique keys correspond to wireless stations, extracts 802.3 packet from the >frame and send the frame across to AC. If needed, it might also send >some control information along with each 802.3 packet. >In this case, AC does not have knowledge of 802.11 header. It only needs >knowledge of >CAPWAP protocol, 802.1x termination, specific wireless related parameters. > >What makes it split MAC? My understanding is that, if AC terminates 802.11 >frames and >does encyption/decryption and has knowledge of 802.11 frames, then it is >Split MAC. >Is this understanding correct? > >Thanks >Rama Krishna > > > >Ch. Rama Krishna Prasad >Intoto Software(I) Pvt Ltd, >Uma Plaza, Nagarjuna circle, >Panjagutta. Hyderabad, AP >Tel No:s 2335 8927/8928/8434 > >_______________________________________________ >Capwap mailing list >Capwap@frascone.com >http://mail.frascone.com/mailman/listinfo/capwap Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 --=====================_3705937==_.ALT Content-Type: text/html; charset="us-ascii"
What about encryption/decryption of 802.11 packets? In Local MAC, as I understand clearly that
it is done at the WTP. And I think, that is good thing to do.
Does split MAC definition allow this operation at WTPs?

Thanks
Rama Krishna

At 10:04 AM 9/1/2004 -0700, Bob O'Hara wrote:
I think the difference can be summed up like this:
 
The protocol between an AC and the Local MAC and the Split MAC is semantically identical.  Each uses a different syntax for this protocol.

 -Bob
 
-----Original Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun
Sent: Wednesday, September 01, 2004 6:32 AM
To: Chunduru Rama Krishna Prasad; capwap@frascone.com
Subject: RE: [Capwap] Local MAC

Great question.
 
As you observed below, the primary difference (from what I can tell) between
split and local MAC is that while the former simply sends the frames untouched
the latter reformulates the 802.11 messages into another format before sending
them to the AC. So sure the PDUs look different, but in reality they are not really
that different, right?
 
I mean what's the difference between sending a straight association request to the
AC vs. breaking the association request down into small components and using the
resulting information to create a message to be sent to the AC?
 
One could easily argue that using the straight association request will ensure forward
compatibility with any new IEEE 802.11 related standard. Let's use 802.11k for instance,
there are some new extensions that are added to existing MAC mgmt frames. So while
a protocol that simply forwards the MAC mgmt frames to the AC will be able to handle
802.11k transparently, the other approach would require that the IETF WG get together
and define a way to map the new 802.11k extensions into whatever protocol was created.
Clearly, we cannot afford to have the IETF's protocol lag behind IEEE standards.
 
On the data path, what is the difference between sending the straight 802.11 frame
vs. sending an 802.3 frame with some associated control information that was derived
from the 802.11 frame to begin with? What happens when protocols like 802.11e change
the actual format of the frame by inserting 2 bytes in the protocol header? Sending the
straight 802.11 frame to the AC ensures that whatever solution we've come up with will
be able to support these future extensions, while a protocol that breaks down the PDU
into an 802.3 frame will cause these extensions to be lost.
 
It's really not like understanding the 802.11 protocol is a complex thing - there are
plenty of implementations of 802.11 based products, and some of these are even available
as open source. So I would argue that parsing 802.11 packets is much simpler than 802.3
with some control information since those stacks are publicly available.
 
PatC

From: capwap-admin@frascone.com on behalf of Chunduru Rama Krishna Prasad
Sent: Tue 8/31/2004 10:52 PM
To: capwap@frascone.com
Subject: [Capwap] Local MAC

Hi ,

Please correct if my interpretation of LOCAL MAC is wrong.
WTP terminates 802.11 control packets and nothing is sent to AC .
WTP terminates 802.11 mangement frames and corresponding events are sent to
AC.
WTP terminates 802.11 data frames, does decryption/encryption based on
unique keys correspond to wireless stations, extracts 802.3 packet from the
frame and send the frame across to AC. If needed, it might also send
some control information along with each 802.3 packet.
In this case, AC does not have knowledge of 802.11 header. It only needs
knowledge of
CAPWAP protocol, 802.1x termination, specific wireless related parameters.

What makes it split MAC? My understanding is that, if AC terminates 802.11
frames and
does encyption/decryption and has knowledge of 802.11 frames, then it is
Split MAC.
Is this understanding correct?

Thanks
Rama Krishna



Ch. Rama Krishna Prasad
Intoto Software(I) Pvt Ltd,
Uma Plaza, Nagarjuna circle,
Panjagutta. Hyderabad, AP
Tel No:s  2335 8927/8928/8434

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

Ch. Rama Krishna Prasad
Intoto Software(I) Pvt Ltd,
Uma Plaza, Nagarjuna circle,
Panjagutta. Hyderabad, AP
Tel No:s  2335 8927/8928/8434 --=====================_3705937==_.ALT-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Sep 2 00:58: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 AAA17765 for ; Thu, 2 Sep 2004 00:58:54 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2D49D20E56; Thu, 2 Sep 2004 00:41:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0363D201AA; Thu, 2 Sep 2004 00: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 20503201E2 for ; Thu, 2 Sep 2004 00:40:35 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id 42E1C20091 for ; Thu, 2 Sep 2004 00:40:32 -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 i824sFmF004962 for ; Thu, 2 Sep 2004 00:54:15 -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 i824sDmF004933 for ; Thu, 2 Sep 2004 00:54:14 -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_01C490A9.1DF50A4C" Message-ID: Thread-Topic: WG last call on Architecture taxonomy draft-05 Thread-Index: AcSQqRvwv7nioONmRmKkxHnG2HEnhg== X-Priority: 1 Priority: Urgent Importance: high From: "Mani, Mahalingam (Mahalingam)" To: Cc: , , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] WG last call on Architecture taxonomy draft-05 Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 1 Sep 2004 22:55:49 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C490A9.1DF50A4C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The architecture taxonomy draft (has now been in the repository and announced for over a week: http://www.ietf.org/internet-drafts/draft-ietf-capwap-arch-05.txt =20 =20 This is the WG last call for comments on the architecture taxonomy draft-05. =20 Please review and provide all your comments to the list as soon as possible - closing 9/15/04 (15 sep 2004). =20 Regards, -mani ------_=_NextPart_001_01C490A9.1DF50A4C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The architecture taxonomy draft (has now been in the repository and announced for over a week:

http://www.ietf.org/internet= -drafts/draft-ietf-capwap-arch-05.txt=

 

This is the WG last call for comments on the = architecture taxonomy draft-05.

 

Please review and provide all your comments to the = list as soon as possible – closing 9/15/04 (15 sep = 2004).

 

Regards,

-mani

------_=_NextPart_001_01C490A9.1DF50A4C-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Sep 2 08:49: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 IAA29442 for ; Thu, 2 Sep 2004 08:49:29 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7FFF020A37; Thu, 2 Sep 2004 08:34:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9227A21952; Thu, 2 Sep 2004 08:34:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A6DF4210DF for ; Thu, 2 Sep 2004 08:33:06 -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 92F3720A37 for ; Thu, 2 Sep 2004 08:33:04 -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_01C490EB.99304BC6" Subject: RE: [Capwap] Local MAC Message-ID: <55749BC69138654EBBC4C50BA4F55610020C46A6@AIREMAIL.airespace.com> Thread-Topic: [Capwap] Local MAC Thread-Index: AcSQpJyqYztnUldTStSHT8Lfjf3pVgARtjPd From: "Pat R. Calhoun" To: "Chunduru Rama Krishna Prasad" , "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, 2 Sep 2004 05:50:43 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C490EB.99304BC6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I know of one implementation that decrypts in the WTP and another that = decrypts in the AC. There is no definition of where this function occurs = in split MAC (or if there is it should say "may occur either in the WTP = or in the AC" :) =20 PatC ________________________________ From: Chunduru Rama Krishna Prasad [mailto:rkp@intoto.com] Sent: Wed 9/1/2004 9:30 PM To: Bob O'Hara; Pat R. Calhoun; capwap@frascone.com Subject: RE: [Capwap] Local MAC What about encryption/decryption of 802.11 packets? In Local MAC, as I = understand clearly that=20 it is done at the WTP. And I think, that is good thing to do.=20 Does split MAC definition allow this operation at WTPs?=20 Thanks=20 Rama Krishna At 10:04 AM 9/1/2004 -0700, Bob O'Hara wrote: I think the difference can be summed up like this: =20 The protocol between an AC and the Local MAC and the Split MAC is = semantically identical. Each uses a different syntax for this protocol. =09 -Bob =20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Pat R. Calhoun Sent: Wednesday, September 01, 2004 6:32 AM To: Chunduru Rama Krishna Prasad; capwap@frascone.com Subject: RE: [Capwap] Local MAC =09 Great question. =20 As you observed below, the primary difference (from what I can tell) = between split and local MAC is that while the former simply sends the frames = untouched the latter reformulates the 802.11 messages into another format before = sending them to the AC. So sure the PDUs look different, but in reality they = are not really that different, right? =20 I mean what's the difference between sending a straight association = request to the AC vs. breaking the association request down into small components and = using the resulting information to create a message to be sent to the AC? =20 One could easily argue that using the straight association request will = ensure forward compatibility with any new IEEE 802.11 related standard. Let's use = 802.11k for instance, there are some new extensions that are added to existing MAC mgmt = frames. So while a protocol that simply forwards the MAC mgmt frames to the AC will be = able to handle 802.11k transparently, the other approach would require that the IETF = WG get together and define a way to map the new 802.11k extensions into whatever = protocol was created. Clearly, we cannot afford to have the IETF's protocol lag behind IEEE = standards. =20 On the data path, what is the difference between sending the straight = 802.11 frame vs. sending an 802.3 frame with some associated control information = that was derived from the 802.11 frame to begin with? What happens when protocols like = 802.11e change the actual format of the frame by inserting 2 bytes in the protocol = header? Sending the straight 802.11 frame to the AC ensures that whatever solution we've = come up with will be able to support these future extensions, while a protocol that = breaks down the PDU into an 802.3 frame will cause these extensions to be lost. =20 It's really not like understanding the 802.11 protocol is a complex = thing - there are plenty of implementations of 802.11 based products, and some of these = are even available as open source. So I would argue that parsing 802.11 packets is much = simpler than 802.3 with some control information since those stacks are publicly = available. =20 PatC =09 =09 ________________________________ From: capwap-admin@frascone.com on behalf of Chunduru Rama Krishna = Prasad Sent: Tue 8/31/2004 10:52 PM To: capwap@frascone.com Subject: [Capwap] Local MAC =09 Hi , =09 Please correct if my interpretation of LOCAL MAC is wrong. WTP terminates 802.11 control packets and nothing is sent to AC . WTP terminates 802.11 mangement frames and corresponding events are = sent to AC. WTP terminates 802.11 data frames, does decryption/encryption based on unique keys correspond to wireless stations, extracts 802.3 packet from = the frame and send the frame across to AC. If needed, it might also send some control information along with each 802.3 packet. In this case, AC does not have knowledge of 802.11 header. It only = needs knowledge of CAPWAP protocol, 802.1x termination, specific wireless related = parameters. =09 What makes it split MAC? My understanding is that, if AC terminates = 802.11 frames and does encyption/decryption and has knowledge of 802.11 frames, then it = is Split MAC. Is this understanding correct? =09 Thanks Rama Krishna =09 =09 =09 Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 =09 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434=20 ------_=_NextPart_001_01C490EB.99304BC6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
=0A=
I know of one = implementation =0A= that decrypts in the WTP and another that decrypts in the AC. There is = no =0A= definition of where this function occurs in split MAC (or if there is it = should =0A= say "may occur either in the WTP or in the AC" :)
=0A=
 
=0A=
PatC
=0A=

=0A=
=0A= From: Chunduru Rama Krishna Prasad =0A= [mailto:rkp@intoto.com]
Sent: Wed 9/1/2004 9:30 = PM
To: Bob =0A= O'Hara; Pat R. Calhoun; capwap@frascone.com
Subject: RE: = [Capwap] =0A= Local MAC

=0A=

What about encryption/decryption of 802.11 packets? In Local = MAC, as I =0A= understand clearly that
it is done at the WTP. And I think, that is = good =0A= thing to do.
Does split MAC definition allow this operation at WTPs? =0A=

Thanks
Rama Krishna

At 10:04 AM 9/1/2004 -0700, Bob = O'Hara =0A= wrote:
=0A=
I =0A= think the difference can be summed up like = this:
 
The protocol between an AC and = the Local MAC =0A= and the Split MAC is semantically identical.  Each uses a = different =0A= syntax for this protocol.

 -Bob
 
-----Original =0A= Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] =0A= On Behalf Of Pat R. Calhoun
Sent: Wednesday, = September 01, =0A= 2004 6:32 AM
To: Chunduru Rama Krishna Prasad; =0A= capwap@frascone.com
Subject: RE: [Capwap] Local =0A= MAC

Great =0A= question.
 
As you = observed below, =0A= the primary difference (from what I can tell) between
split and local MAC is that while the former = simply sends =0A= the frames untouched
the latter = reformulates =0A= the 802.11 messages into another format before sending
them to the AC. So sure the PDUs look different, = but in =0A= reality they are not really
that = different, =0A= right?
 
I mean what's = the =0A= difference between sending a straight association request to =0A= the
AC vs. breaking the = association request =0A= down into small components and using the
resulting information to create a message to be sent to the =0A= AC?
 
One could easily = argue that =0A= using the straight association request will ensure = forward
compatibility =0A= with any new IEEE 802.11 related standard. Let's use 802.11k for =0A= instance,
there are some new extensions that are added to existing = MAC mgmt =0A= frames. So while
a protocol that simply forwards the MAC mgmt = frames to the =0A= AC will be able to handle
802.11k transparently, the other approach = would =0A= require that the IETF WG get together
and define a way to map the = new =0A= 802.11k extensions into whatever protocol was created.
Clearly, we = cannot =0A= afford to have the IETF's protocol lag behind IEEE = standards.
 
On =0A= the data path, what is the difference between sending the straight = 802.11 =0A= frame
vs. sending an 802.3 frame = with some =0A= associated control information that was derived
from the 802.11 frame to begin with? What happens when = protocols like =0A= 802.11e change
the actual format = of the =0A= frame by inserting 2 bytes in the protocol header? Sending = the
straight 802.11 frame to the AC ensures that = whatever =0A= solution we've come up with will
be able to =0A= support these future extensions, while a protocol that breaks down the =0A= PDU
into an 802.3 frame will = cause these =0A= extensions to be lost.
 
It's really =0A= not like understanding the 802.11 protocol is a complex thing - there =0A= are
plenty of implementations of = 802.11 =0A= based products, and some of these are even available
as open source. So I would argue that parsing = 802.11 packets =0A= is much simpler than 802.3
with = some control =0A= information since those stacks are publicly =0A= available.
 
PatC

=0A=
=0A= From: capwap-admin@frascone.com on = behalf of =0A= Chunduru Rama Krishna Prasad
Sent: Tue 8/31/2004 10:52 =0A= PM
To: capwap@frascone.com
Subject: [Capwap] Local =0A= MAC

Hi ,

Please correct if my = interpretation =0A= of LOCAL MAC is wrong.
WTP terminates 802.11 control packets and = nothing is =0A= sent to AC .
WTP terminates 802.11 mangement frames and = corresponding =0A= events are sent to
AC.
WTP terminates 802.11 data frames, does =0A= decryption/encryption based on
unique keys correspond to wireless = stations, =0A= extracts 802.3 packet from the
frame and send the frame across to = AC. If =0A= needed, it might also send
some control information along with each = 802.3 =0A= packet.
In this case, AC does not have knowledge of 802.11 header. = It only =0A= needs
knowledge of
CAPWAP protocol, 802.1x termination, specific =0A= wireless related parameters.

What makes it split MAC? My = understanding =0A= is that, if AC terminates 802.11
frames and
does = encyption/decryption =0A= and has knowledge of 802.11 frames, then it is
Split MAC.
Is = this =0A= understanding correct?

Thanks
Rama = Krishna



Ch. Rama =0A= Krishna Prasad
Intoto Software(I) Pvt Ltd,
Uma Plaza, Nagarjuna =0A= circle,
Panjagutta. Hyderabad, AP
Tel No:s  2335 =0A= = 8927/8928/8434

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

Ch. Rama Krishna Prasad
Intoto Software(I) Pvt Ltd,
Uma Plaza, =0A= Nagarjuna circle,
Panjagutta. Hyderabad, AP
Tel No:s  2335 =0A= 8927/8928/8434

------_=_NextPart_001_01C490EB.99304BC6-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Sep 2 11:40: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 LAA13385 for ; Thu, 2 Sep 2004 11:40:28 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AA693219E7; Thu, 2 Sep 2004 11:25:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9484521A67; Thu, 2 Sep 2004 11: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 07F2621A67 for ; Thu, 2 Sep 2004 11:24: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 9E5F1219E7 for ; Thu, 2 Sep 2004 11:24:38 -0400 (EDT) Message-ID: <005701c49101$d4cfa7b0$536115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Pat R. Calhoun" , "Chunduru Rama Krishna Prasad" , "Bob O'Hara" , References: <55749BC69138654EBBC4C50BA4F55610020C46A6@AIREMAIL.airespace.com> Subject: Re: [Capwap] Local MAC 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, 2 Sep 2004 08:30:50 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit But for purposes of interoperability (i.e. being able to mix and match WTPs and ACs between vendors), doesn't this need to be specified? The standard could either specify where encyption/decryption is done, or it could allow for some type of negotiation when the WTP and AC first make contact and connect up. jak ----- Original Message ----- From: "Pat R. Calhoun" To: "Chunduru Rama Krishna Prasad" ; "Bob O'Hara" ; Sent: Thursday, September 02, 2004 5:50 AM Subject: RE: [Capwap] Local MAC I know of one implementation that decrypts in the WTP and another that decrypts in the AC. There is no definition of where this function occurs in split MAC (or if there is it should say "may occur either in the WTP or in the AC" :) PatC ________________________________ From: Chunduru Rama Krishna Prasad [mailto:rkp@intoto.com] Sent: Wed 9/1/2004 9:30 PM To: Bob O'Hara; Pat R. Calhoun; capwap@frascone.com Subject: RE: [Capwap] Local MAC What about encryption/decryption of 802.11 packets? In Local MAC, as I understand clearly that it is done at the WTP. And I think, that is good thing to do. Does split MAC definition allow this operation at WTPs? Thanks Rama Krishna At 10:04 AM 9/1/2004 -0700, Bob O'Hara wrote: I think the difference can be summed up like this: The protocol between an AC and the Local MAC and the Split MAC is semantically identical. Each uses a different syntax for this protocol. -Bob -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun Sent: Wednesday, September 01, 2004 6:32 AM To: Chunduru Rama Krishna Prasad; capwap@frascone.com Subject: RE: [Capwap] Local MAC Great question. As you observed below, the primary difference (from what I can tell) between split and local MAC is that while the former simply sends the frames untouched the latter reformulates the 802.11 messages into another format before sending them to the AC. So sure the PDUs look different, but in reality they are not really that different, right? I mean what's the difference between sending a straight association request to the AC vs. breaking the association request down into small components and using the resulting information to create a message to be sent to the AC? One could easily argue that using the straight association request will ensure forward compatibility with any new IEEE 802.11 related standard. Let's use 802.11k for instance, there are some new extensions that are added to existing MAC mgmt frames. So while a protocol that simply forwards the MAC mgmt frames to the AC will be able to handle 802.11k transparently, the other approach would require that the IETF WG get together and define a way to map the new 802.11k extensions into whatever protocol was created. Clearly, we cannot afford to have the IETF's protocol lag behind IEEE standards. On the data path, what is the difference between sending the straight 802.11 frame vs. sending an 802.3 frame with some associated control information that was derived from the 802.11 frame to begin with? What happens when protocols like 802.11e change the actual format of the frame by inserting 2 bytes in the protocol header? Sending the straight 802.11 frame to the AC ensures that whatever solution we've come up with will be able to support these future extensions, while a protocol that breaks down the PDU into an 802.3 frame will cause these extensions to be lost. It's really not like understanding the 802.11 protocol is a complex thing - there are plenty of implementations of 802.11 based products, and some of these are even available as open source. So I would argue that parsing 802.11 packets is much simpler than 802.3 with some control information since those stacks are publicly available. PatC ________________________________ From: capwap-admin@frascone.com on behalf of Chunduru Rama Krishna Prasad Sent: Tue 8/31/2004 10:52 PM To: capwap@frascone.com Subject: [Capwap] Local MAC Hi , Please correct if my interpretation of LOCAL MAC is wrong. WTP terminates 802.11 control packets and nothing is sent to AC . WTP terminates 802.11 mangement frames and corresponding events are sent to AC. WTP terminates 802.11 data frames, does decryption/encryption based on unique keys correspond to wireless stations, extracts 802.3 packet from the frame and send the frame across to AC. If needed, it might also send some control information along with each 802.3 packet. In this case, AC does not have knowledge of 802.11 header. It only needs knowledge of CAPWAP protocol, 802.1x termination, specific wireless related parameters. What makes it split MAC? My understanding is that, if AC terminates 802.11 frames and does encyption/decryption and has knowledge of 802.11 frames, then it is Split MAC. Is this understanding correct? Thanks Rama Krishna Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Sep 2 12:30: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 MAA16215 for ; Thu, 2 Sep 2004 12:30:32 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1A4F421AB8; Thu, 2 Sep 2004 12:15:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5727C21A81; Thu, 2 Sep 2004 12:15:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DA00621A73 for ; Thu, 2 Sep 2004 12:14:22 -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 8BD271FE75 for ; Thu, 2 Sep 2004 12:14:20 -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_01C4910A.823D03F9" Subject: RE: [Capwap] Local MAC Message-ID: <55749BC69138654EBBC4C50BA4F5561002BF5726@AIREMAIL.airespace.com> Thread-Topic: [Capwap] Local MAC Thread-Index: AcSQpJyqYztnUldTStSHT8Lfjf3pVgAZbUvA 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, 2 Sep 2004 09:32:57 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C4910A.823D03F9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You are improperly mixing control and provisioning with manipulation and carriage of the data frames. The question is irrelevant. -Bob =20 -----Original Message----- From: Chunduru Rama Krishna Prasad [mailto:rkp@intoto.com]=20 Sent: Wednesday, September 01, 2004 9:30 PM To: Bob O'Hara; Pat R. Calhoun; capwap@frascone.com Subject: RE: [Capwap] Local MAC What about encryption/decryption of 802.11 packets? In Local MAC, as I understand clearly that=20 it is done at the WTP. And I think, that is good thing to do.=20 Does split MAC definition allow this operation at WTPs?=20 Thanks=20 Rama Krishna At 10:04 AM 9/1/2004 -0700, Bob O'Hara wrote: I think the difference can be summed up like this: =20 The protocol between an AC and the Local MAC and the Split MAC is semantically identical. Each uses a different syntax for this protocol. -Bob =20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun Sent: Wednesday, September 01, 2004 6:32 AM To: Chunduru Rama Krishna Prasad; capwap@frascone.com Subject: RE: [Capwap] Local MAC Great question. =20 As you observed below, the primary difference (from what I can tell) between split and local MAC is that while the former simply sends the frames untouched the latter reformulates the 802.11 messages into another format before sending them to the AC. So sure the PDUs look different, but in reality they are not really that different, right? =20 I mean what's the difference between sending a straight association request to the AC vs. breaking the association request down into small components and using the resulting information to create a message to be sent to the AC? =20 One could easily argue that using the straight association request will ensure forward compatibility with any new IEEE 802.11 related standard. Let's use 802.11k for instance, there are some new extensions that are added to existing MAC mgmt frames. So while a protocol that simply forwards the MAC mgmt frames to the AC will be able to handle 802.11k transparently, the other approach would require that the IETF WG get together and define a way to map the new 802.11k extensions into whatever protocol was created. Clearly, we cannot afford to have the IETF's protocol lag behind IEEE standards. =20 On the data path, what is the difference between sending the straight 802.11 frame vs. sending an 802.3 frame with some associated control information that was derived from the 802.11 frame to begin with? What happens when protocols like 802.11e change the actual format of the frame by inserting 2 bytes in the protocol header? Sending the straight 802.11 frame to the AC ensures that whatever solution we've come up with will be able to support these future extensions, while a protocol that breaks down the PDU into an 802.3 frame will cause these extensions to be lost. =20 It's really not like understanding the 802.11 protocol is a complex thing - there are plenty of implementations of 802.11 based products, and some of these are even available as open source. So I would argue that parsing 802.11 packets is much simpler than 802.3 with some control information since those stacks are publicly available. =20 PatC _____ =20 From: capwap-admin@frascone.com on behalf of Chunduru Rama Krishna Prasad Sent: Tue 8/31/2004 10:52 PM To: capwap@frascone.com Subject: [Capwap] Local MAC Hi , Please correct if my interpretation of LOCAL MAC is wrong. WTP terminates 802.11 control packets and nothing is sent to AC . WTP terminates 802.11 mangement frames and corresponding events are sent to AC. WTP terminates 802.11 data frames, does decryption/encryption based on unique keys correspond to wireless stations, extracts 802.3 packet from the frame and send the frame across to AC. If needed, it might also send some control information along with each 802.3 packet. In this case, AC does not have knowledge of 802.11 header. It only needs knowledge of CAPWAP protocol, 802.1x termination, specific wireless related parameters. What makes it split MAC? My understanding is that, if AC terminates 802.11 frames and does encyption/decryption and has knowledge of 802.11 frames, then it is Split MAC. Is this understanding correct? Thanks Rama Krishna Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434=20 ------_=_NextPart_001_01C4910A.823D03F9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
You=20 are improperly mixing control and provisioning with manipulation and = carriage of=20 the data frames.  The question is = irrelevant.

 -Bob
 

-----Original Message-----
From: Chunduru Rama = Krishna Prasad=20 [mailto:rkp@intoto.com]
Sent: Wednesday, September 01, 2004 = 9:30=20 PM
To: Bob O'Hara; Pat R. Calhoun;=20 capwap@frascone.com
Subject: RE: [Capwap] Local=20 MAC


What about encryption/decryption of 802.11 = packets?=20 In Local MAC, as I understand clearly that
it is done at the WTP. = And I=20 think, that is good thing to do.
Does split MAC definition allow = this=20 operation at WTPs?

Thanks
Rama Krishna

At 10:04 AM = 9/1/2004=20 -0700, Bob O'Hara wrote:
I think the difference can be summed up like=20 this:
 
The protocol=20 between an AC and the Local MAC and the Split MAC is semantically=20 identical.  Each uses a different syntax for this=20 protocol.

 -Bob
  =
-----Original Message-----
From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf = Of Pat=20 R. Calhoun
Sent: Wednesday, September 01, 2004 6:32 = AM
To:=20 Chunduru Rama Krishna Prasad; capwap@frascone.com
Subject: = RE:=20 [Capwap] Local MAC

Great=20 question.
 
As you = observed below,=20 the primary difference (from what I can tell) between
split and local MAC is that while the former = simply sends=20 the frames untouched
the latter = reformulates=20 the 802.11 messages into another format before sending
them to the AC. So sure the PDUs look different, = but in=20 reality they are not really
that = different,=20 right?
 
I mean what's = the=20 difference between sending a straight association request to=20 the
AC vs. breaking the = association request=20 down into small components and using the
resulting information to create a message to be sent to the=20 AC?
 
One could easily = argue that=20 using the straight association request will ensure = forward
compatibility=20 with any new IEEE 802.11 related standard. Let's use 802.11k for=20 instance,
there are some new extensions that are added to existing = MAC mgmt=20 frames. So while
a protocol that simply forwards the MAC mgmt = frames to the=20 AC will be able to handle
802.11k transparently, the other approach = would=20 require that the IETF WG get together
and define a way to map the = new=20 802.11k extensions into whatever protocol was created.
Clearly, we = cannot=20 afford to have the IETF's protocol lag behind IEEE = standards.
 
On=20 the data path, what is the difference between sending the straight = 802.11=20 frame
vs. sending an 802.3 frame = with some=20 associated control information that was derived
from the 802.11 frame to begin with? What happens when = protocols like=20 802.11e change
the actual format = of the=20 frame by inserting 2 bytes in the protocol header? Sending = the
straight 802.11 frame to the AC ensures that = whatever=20 solution we've come up with will
be able to=20 support these future extensions, while a protocol that breaks down the = PDU
into an 802.3 frame will = cause these=20 extensions to be lost.
 
It's really=20 not like understanding the 802.11 protocol is a complex thing - there=20 are
plenty of implementations of = 802.11=20 based products, and some of these are even available
as open source. So I would argue that parsing = 802.11 packets=20 is much simpler than 802.3
with = some control=20 information since those stacks are publicly=20 available.
 
PatC

From: capwap-admin@frascone.com on = behalf of=20 Chunduru Rama Krishna Prasad
Sent: Tue 8/31/2004 10:52=20 PM
To: capwap@frascone.com
Subject: [Capwap] Local = MAC

Hi ,

Please correct if my = interpretation=20 of LOCAL MAC is wrong.
WTP terminates 802.11 control packets and = nothing is=20 sent to AC .
WTP terminates 802.11 mangement frames and = corresponding=20 events are sent to
AC.
WTP terminates 802.11 data frames, does=20 decryption/encryption based on
unique keys correspond to wireless = stations,=20 extracts 802.3 packet from the
frame and send the frame across to = AC. If=20 needed, it might also send
some control information along with each = 802.3=20 packet.
In this case, AC does not have knowledge of 802.11 header. = It only=20 needs
knowledge of
CAPWAP protocol, 802.1x termination, specific = wireless related parameters.

What makes it split MAC? My = understanding=20 is that, if AC terminates 802.11
frames and
does = encyption/decryption=20 and has knowledge of 802.11 frames, then it is
Split MAC.
Is = this=20 understanding correct?

Thanks
Rama = Krishna



Ch. Rama=20 Krishna Prasad
Intoto Software(I) Pvt Ltd,
Uma Plaza, Nagarjuna=20 circle,
Panjagutta. Hyderabad, AP
Tel No:s  2335=20 = 8927/8928/8434

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

Ch. Rama Krishna Prasad
Intoto Software(I) Pvt = Ltd,
Uma=20 Plaza, Nagarjuna circle,
Panjagutta. Hyderabad, AP
Tel No:s  = 2335=20 8927/8928/8434

------_=_NextPart_001_01C4910A.823D03F9-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Sep 2 12:51: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 MAA17697 for ; Thu, 2 Sep 2004 12:51:29 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 02F77206C7; Thu, 2 Sep 2004 12:36:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BB13A218DB; Thu, 2 Sep 2004 12: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 6AF83206C7 for ; Thu, 2 Sep 2004 12:35:40 -0400 (EDT) Received: from extrgate1.extremenetworks.com (sc-f100-01.extremenetworks.com [63.251.106.30]) by mail.frascone.com (Postfix) with ESMTP id 23964218DB for ; Thu, 2 Sep 2004 12:35:38 -0400 (EDT) Received: by extrgate1.extremenetworks.com with Internet Mail Service (5.5.2656.59) id ; Thu, 2 Sep 2004 09:50:29 -0700 Message-ID: <4C8B0EA487B9554D910B0587CD91395C028441F2@sc-msexch-03.extremenetworks.com> From: Victor Lin To: "Bob O'Hara" , capwap@frascone.com Subject: RE: [Capwap] Local MAC MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4910C.78A7E280" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 2 Sep 2004 09:47:02 -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_01C4910C.78A7E280 Content-Type: text/plain If the encryption/decryption is done in WTP, we will need a control protocol to deliver keys from AC to WTP. Also, MIC countermeasure will be detected at WTP and the event needs to be send back to AC. I think this will affect the detail design of control-provisioning protocol. Victor _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Bob O'Hara Sent: Thursday, September 02, 2004 9:33 AM To: capwap@frascone.com Subject: RE: [Capwap] Local MAC You are improperly mixing control and provisioning with manipulation and carriage of the data frames. The question is irrelevant. -Bob -----Original Message----- From: Chunduru Rama Krishna Prasad [mailto:rkp@intoto.com] Sent: Wednesday, September 01, 2004 9:30 PM To: Bob O'Hara; Pat R. Calhoun; capwap@frascone.com Subject: RE: [Capwap] Local MAC What about encryption/decryption of 802.11 packets? In Local MAC, as I understand clearly that it is done at the WTP. And I think, that is good thing to do. Does split MAC definition allow this operation at WTPs? Thanks Rama Krishna At 10:04 AM 9/1/2004 -0700, Bob O'Hara wrote: I think the difference can be summed up like this: The protocol between an AC and the Local MAC and the Split MAC is semantically identical. Each uses a different syntax for this protocol. -Bob -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com ] On Behalf Of Pat R. Calhoun Sent: Wednesday, September 01, 2004 6:32 AM To: Chunduru Rama Krishna Prasad; capwap@frascone.com Subject: RE: [Capwap] Local MAC Great question. As you observed below, the primary difference (from what I can tell) between split and local MAC is that while the former simply sends the frames untouched the latter reformulates the 802.11 messages into another format before sending them to the AC. So sure the PDUs look different, but in reality they are not really that different, right? I mean what's the difference between sending a straight association request to the AC vs. breaking the association request down into small components and using the resulting information to create a message to be sent to the AC? One could easily argue that using the straight association request will ensure forward compatibility with any new IEEE 802.11 related standard. Let's use 802.11k for instance, there are some new extensions that are added to existing MAC mgmt frames. So while a protocol that simply forwards the MAC mgmt frames to the AC will be able to handle 802.11k transparently, the other approach would require that the IETF WG get together and define a way to map the new 802.11k extensions into whatever protocol was created. Clearly, we cannot afford to have the IETF's protocol lag behind IEEE standards. On the data path, what is the difference between sending the straight 802.11 frame vs. sending an 802.3 frame with some associated control information that was derived from the 802.11 frame to begin with? What happens when protocols like 802.11e change the actual format of the frame by inserting 2 bytes in the protocol header? Sending the straight 802.11 frame to the AC ensures that whatever solution we've come up with will be able to support these future extensions, while a protocol that breaks down the PDU into an 802.3 frame will cause these extensions to be lost. It's really not like understanding the 802.11 protocol is a complex thing - there are plenty of implementations of 802.11 based products, and some of these are even available as open source. So I would argue that parsing 802.11 packets is much simpler than 802.3 with some control information since those stacks are publicly available. PatC _____ From: capwap-admin@frascone.com on behalf of Chunduru Rama Krishna Prasad Sent: Tue 8/31/2004 10:52 PM To: capwap@frascone.com Subject: [Capwap] Local MAC Hi , Please correct if my interpretation of LOCAL MAC is wrong. WTP terminates 802.11 control packets and nothing is sent to AC . WTP terminates 802.11 mangement frames and corresponding events are sent to AC. WTP terminates 802.11 data frames, does decryption/encryption based on unique keys correspond to wireless stations, extracts 802.3 packet from the frame and send the frame across to AC. If needed, it might also send some control information along with each 802.3 packet. In this case, AC does not have knowledge of 802.11 header. It only needs knowledge of CAPWAP protocol, 802.1x termination, specific wireless related parameters. What makes it split MAC? My understanding is that, if AC terminates 802.11 frames and does encyption/decryption and has knowledge of 802.11 frames, then it is Split MAC. Is this understanding correct? Thanks Rama Krishna Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 ------_=_NextPart_001_01C4910C.78A7E280 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message

If the encryption/decryption is = done in WTP, we will need a control protocol to deliver keys from AC to WTP. = Also, MIC countermeasure will be detected at WTP and the event needs to be send back to AC. I = think this will affect the detail design of control-provisioning = protocol.

 

=

Victor =

 

=

From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Bob O'Hara
Sent: Thursday, = September 02, 2004 9:33 AM
To: = capwap@frascone.com
Subject: RE: [Capwap] = Local MAC

 

You are improperly mixing control = and provisioning with manipulation and carriage of the data frames.  = The question is irrelevant.

 -Bob
 

-----Original = Message-----
From: Chunduru Rama = Krishna Prasad [mailto:rkp@intoto.com]
Sent: Wednesday, = September 01, 2004 9:30 PM
To: Bob O'Hara; Pat R. = Calhoun; capwap@frascone.com
Subject: RE: [Capwap] = Local MAC


What about encryption/decryption of 802.11 packets? In Local MAC, as I understand clearly that
it is done at the WTP. And I think, that is good thing to do.
Does split MAC definition allow this operation at WTPs?

Thanks
Rama Krishna

At 10:04 AM 9/1/2004 -0700, Bob O'Hara wrote:

I think the difference can be summed up like this:
 
The protocol between an AC and the Local MAC and the = Split MAC is semantically identical.  Each uses a different syntax for = this protocol.

 -Bob
 
-----Original Message-----
From: = capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. = Calhoun
Sent: Wednesday, = September 01, 2004 6:32 AM
To: Chunduru Rama = Krishna Prasad; capwap@frascone.com
Subject: RE: [Capwap] = Local MAC

Great question.
 
As you observed below, the primary difference (from what I can tell) = between
split and local MAC is that while the former simply sends the frames = untouched
the latter reformulates the 802.11 messages into another format before = sending
them to the AC. So sure the PDUs look different, but in reality they are not = really
that different, right?
 
I mean what's the difference between sending a straight association request to = the
AC vs. breaking the association request down into small components and using = the
resulting information to create a message to be sent to the AC?
 
One could easily argue that using the straight association request will = ensure forward
compatibility with any new IEEE 802.11 related standard. Let's use = 802.11k for instance,
there are some new extensions that are added to existing MAC mgmt = frames. So while
a protocol that simply forwards the MAC mgmt frames to the AC will be = able to handle
802.11k transparently, the other approach would require that the IETF = WG get together
and define a way to map the new 802.11k extensions into whatever = protocol was created.
Clearly, we cannot afford to have the IETF's protocol lag behind IEEE standards.
 
On the data path, what is the difference between sending the straight = 802.11 frame
vs. sending an 802.3 frame with some associated control information that = was derived
from the 802.11 frame to begin with? What happens when protocols like = 802.11e change
the actual format of the frame by inserting 2 bytes in the protocol header? = Sending the
straight 802.11 frame to the AC ensures that whatever solution we've come up = with will
be able to support these future extensions, while a protocol that breaks = down the PDU
into an 802.3 frame will cause these extensions to be = lost.
 
It's really not like understanding the 802.11 protocol is a complex thing - = there are
plenty of implementations of 802.11 based products, and some of these are even available
as open source. So I would argue that parsing 802.11 packets is much = simpler than 802.3
with some control information since those stacks are publicly = available.
 
PatC

From: capwap-admin@frascone.com on behalf of Chunduru Rama Krishna Prasad
Sent: Tue 8/31/2004 = 10:52 PM
To: = capwap@frascone.com
Subject: [Capwap] Local = MAC

Hi ,

Please correct if my interpretation of LOCAL MAC is wrong.
WTP terminates 802.11 control packets and nothing is sent to AC .
WTP terminates 802.11 mangement frames and corresponding events are = sent to
AC.
WTP terminates 802.11 data frames, does decryption/encryption based = on
unique keys correspond to wireless stations, extracts 802.3 packet from = the
frame and send the frame across to AC. If needed, it might also = send
some control information along with each 802.3 packet.
In this case, AC does not have knowledge of 802.11 header. It only = needs
knowledge of
CAPWAP protocol, 802.1x termination, specific wireless related = parameters.

What makes it split MAC? My understanding is that, if AC terminates = 802.11
frames and
does encyption/decryption and has knowledge of 802.11 frames, then it = is
Split MAC.
Is this understanding correct?

Thanks
Rama Krishna



Ch. Rama Krishna Prasad
Intoto Software(I) Pvt Ltd,
Uma = Plaza, Nagarjuna circle,
Panjagutta. Hyderabad, AP
Tel No:s  2335 8927/8928/8434

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

Ch. Rama Krishna Prasad
Intoto Software(I) Pvt Ltd,
Uma = Plaza, Nagarjuna circle,
Panjagutta. Hyderabad, AP
Tel No:s  2335 8927/8928/8434

------_=_NextPart_001_01C4910C.78A7E280-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Sep 2 14:31:31 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 OAA26006 for ; Thu, 2 Sep 2004 14:31:30 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A12DC21DE1; Thu, 2 Sep 2004 14:16:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0186B21DE5; Thu, 2 Sep 2004 14:16:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D7C6F21DE1 for ; Thu, 2 Sep 2004 14:15:06 -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 631FC214AA for ; Thu, 2 Sep 2004 14:15:04 -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/mixed; boundary="----_=_NextPart_001_01C4911B.5F186B92" Message-ID: <55749BC69138654EBBC4C50BA4F5561002BF5762@AIREMAIL.airespace.com> X-MS-Has-Attach: yes Thread-Topic: Update to problem statement Thread-Index: AcSRG17jPp6uTltUQGuKqOxR/Es9ng== From: "Bob O'Hara" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Update to problem statement Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 2 Sep 2004 11:33:40 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C4911B.5F186B92 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In response to comments from the IESG, I have updated the problem statement. It is attached for your review and comment. If I have not received any substantive comments by Monday, I will submit it to the IETF repository. Please comment to the list. There are some editorial changes and two new paragraphs in the Security Considerations section. -Bob Bob O'Hara Director of System Engineering, Founder Airespace, Inc. 110 Nortech Parkway San Jose, CA 95134-2307 Phone: +1 408 635 2025 Mobile: +1 408 218 4025 Fax: +1 408 635 2020 email: bob@airespace.com http://my.infotriever.com/to6ul4jo =20 ------_=_NextPart_001_01C4911B.5F186B92 Content-Type: text/plain; name="draft-ietf-capwap-problem-statement-02.txt" Content-Description: draft-ietf-capwap-problem-statement-02.txt Content-Disposition: attachment; filename="draft-ietf-capwap-problem-statement-02.txt" Content-Transfer-Encoding: base64 CgoKQ0FQV0FQIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgQi4gTydIYXJhCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgUC4gQ2FsaG91bgpFeHBpcmVzOiBGZWJydWFyeSAxOCwg MjAwNSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBaXJlc3BhY2UKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEouIEtlbXBmCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIERvY29tbyBMYWJzIFVTQQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAsIDIwMDQKCgogICAgICAgICAgICAg ICAgICAgICAgICBDQVBXQVAgUHJvYmxlbSBTdGF0ZW1lbnQKICAgICAgICAgICAgICAgICBkcmFm dC1pZXRmLWNhcHdhcC1wcm9ibGVtLXN0YXRlbWVudC0wMgoKU3RhdHVzIG9mIHRoaXMgTWVtbwoK ICAgVGhpcyBkb2N1bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMgaW4gZnVsbCBjb25m b3JtYW5jZSB3aXRoCiAgIGFsbCBwcm92aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YgUkZDMjAyNi4K CiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0 IEVuZ2luZWVyaW5nCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29y a2luZyBncm91cHMuICBOb3RlIHRoYXQKICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1 dGUgd29ya2luZyBkb2N1bWVudHMgYXMKICAgSW50ZXJuZXQtRHJhZnRzLgoKICAgSW50ZXJuZXQt RHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9u dGhzCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhl ciBkb2N1bWVudHMgYXQgYW55CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJ bnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBv dGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIKCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQg SW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdAogICBodHRwOi8vd3d3LmlldGYub3Jn L2lldGYvMWlkLWFic3RyYWN0cy50eHQuCgogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBT aGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0CiAgIGh0dHA6Ly93d3cuaWV0Zi5v cmcvc2hhZG93Lmh0bWwuCgogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIEZl YnJ1YXJ5IDE4LCAyMDA1LgoKQ29weXJpZ2h0IE5vdGljZQoKICAgQ29weXJpZ2h0IChDKSBUaGUg SW50ZXJuZXQgU29jaWV0eSAoMjAwNCkuICBBbGwgUmlnaHRzIFJlc2VydmVkLgoKQWJzdHJhY3QK CiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBDb25maWd1cmF0aW9uIGFuZCBQcm92aXNp b25pbmcgZm9yCiAgIFdpcmVsZXNzIEFjY2VzcyBQb2ludHMgKENBUFdBUCkgcHJvYmxlbSBzdGF0 ZW1lbnQuCgoKCgoKCgoKCgpPJ0hhcmEsIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkg MTgsIDIwMDUgICAgICAgICAgICAgICAgW1BhZ2UgMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg ICBDQVBXQVAgUHJvYmxlbSBTdGF0ZW1lbnQgICAgICAgICAgICAgQXVndXN0IDIwMDQKCgpUYWJs ZSBvZiBDb250ZW50cwoKICAgMS4gICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzCiAgIDIuICAgUHJvYmxlbSBTdGF0ZW1lbnQg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNAogICAzLiAgIFNl Y3VyaXR5IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDYKICAgICAgICBBdXRob3JzJyBBZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiA2CiAgICAgICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IGFuZCBD b3B5cmlnaHQgU3RhdGVtZW50cyAuIC4gLiAuIC4gLiAuIC4gOAoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCk8nSGFyYSwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBG ZWJydWFyeSAxOCwgMjAwNSAgICAgICAgICAgICAgICBbUGFnZSAyXQoMCkludGVybmV0LURyYWZ0 ICAgICAgICAgIENBUFdBUCBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAgICBBdWd1c3QgMjAw NAoKCjEuICBJbnRyb2R1Y3Rpb24KCiAgIFdpdGggdGhlIGFwcHJvdmFsIG9mIHRoZSA4MDIuMTEg c3RhbmRhcmQgYnkgdGhlIElFRUUgaW4gMTk5NywKICAgd2lyZWxlc3MgTEFOcyAoV0xBTnMpIGJl Z2FuIGEgc2xvdyBlbnRyeSBpbnRvIGVudGVycHJpc2UgbmV0d29ya3MuCiAgIFRoZSBsaW1pdGVk IGRhdGEgcmF0ZXMgb2YgdGhlIG9yaWdpbmFsIDgwMi4xMSBzdGFuZGFyZCwgb25seSAxLSBhbmQK ICAgMi1NYnBzLCBsaW1pdGVkIHdpZGVzcHJlYWQgYWRvcHRpb24gb2YgdGhlIHRlY2hub2xvZ3ku ICA4MDIuMTEgZm91bmQKICAgd2lkZSBkZXBsb3ltZW50IGluIHZlcnRpY2FsIGFwcGxpY2F0aW9u cywgc3VjaCBhcyBpbnZlbnRvcnkKICAgbWFuYWdlbWVudCwgcG9pbnQgb2Ygc2FsZSwgYW5kIHRy YW5zcG9ydGF0aW9uIG1hbmFnZW1lbnQuICBQaW9uZWVyaW5nCiAgIGVudGVycHJpc2VzIGJlZ2Fu IHRvIGRlcGxveSA4MDIuMTEsIG1vc3RseSBmb3IgZXhwZXJpbWVudGF0aW9uLgoKICAgSW4gMTk5 OSwgdGhlIElFRUUgYXBwcm92ZWQgdGhlIDgwMi4xMWEgYW5kIDgwMi4xMWIgYW1lbmRtZW50cyB0 byB0aGUKICAgYmFzZSBzdGFuZGFyZCwgaW5jcmVhc2luZyB0aGUgYXZhaWxhYmxlIGRhdGEgcmF0 ZSB0byA1NC0gYW5kIDExLU1icHMsCiAgIHJlc3BlY3RpdmVseSwgYW5kIGV4cGFuZGluZyB0byBh IG5ldyByYWRpbyBiYW5kLiAgVGhpcyByZW1vdmVkIG9uZSBvZgogICB0aGUgc2lnbmlmaWNhbnQg ZmFjdG9ycyBob2xkaW5nIGJhY2sgYWRvcHRpb24gb2YgODAyLjExIGluIGxhcmdlLAogICBlbnRl cnByaXNlIG5ldHdvcmtzLiAgVGhlc2UgbGFyZ2UgZGVwbG95bWVudHMgd2VyZSBib3VuZCBieSB0 aGUKICAgZGVmaW5pdGlvbiBhbmQgZnVuY3Rpb25hbGl0eSBvZiBhbiA4MDIuMTEgQWNjZXNzIFBv aW50IChBUCksIGFzCiAgIGRlc2NyaWJlZCBpbiB0aGUgODAyLjExIHN0YW5kYXJkLiAgVGhlIHRl Y2huaXF1ZXMgcmVxdWlyZWQgZXh0ZW5zaXZlCiAgIHVzZSBvZiBsYXllciAyIGJyaWRnaW5nIGFu ZCB3aWRlc3ByZWFkIFZMQU5zIHRvIGVuc3VyZSB0aGUgcHJvcGVyCiAgIG9wZXJhdGlvbiBvZiBo aWdoZXIgbGF5ZXIgcHJvdG9jb2xzLiAgRGVwbG95bWVudHMgb2YgODAyLjExIFdMQU5zIGFzCiAg IGxhcmdlIGFzIHNldmVyYWwgdGhvdXNhbmQgQVBzIGhhdmUgYmVlbiBkZXNjcmliZWQuCgogICBM YXJnZSBkZXBsb3ltZW50cyBvZiA4MDIuMTEgV0xBTnMgaGF2ZSBpbnRyb2R1Y2VkIHNldmVyYWwg cHJvYmxlbXMKICAgdGhhdCByZXF1aXJlIHNvbHV0aW9ucy4gIFRoZSBsaW1pdGF0aW9ucyBvbiB0 aGUgc2NhbGFiaWxpdHkgb2YKICAgYnJpZGdpbmcgc2hvdWxkIGNvbWUgYXMgbm8gc3VwcmlzZSB0 byB0aGUgbmV0d29ya2luZyBjb21tdW5pdHksIHNpbmNlCiAgIHNpbWlsYXIgbGltaXRhdGlvbnMg YXJvc2UgaW4gdGhlIGVhcmx5IDE5ODAncyBmb3Igd2lyZWQgbmV0d29yawogICBicmlkZ2luZyBk dXJpbmcgdGhlIGV4cGFuc2lvbiBhbmQgaW50ZXJjb25uZWN0aW9uIG9mIHdpcmVkIGxvY2FsIGFy ZWEKICAgbmV0d29ya3MuICBUaGlzIGRvY3VtZW50IHdpbGwgZGVzY3JpYmUgdGhlIHByb2JsZW1z IGludHJvZHVjZWQgYnkgdGhlCiAgIGxhcmdlIHNjYWxlIGRlcGxveW1lbnQgb2YgODAyLjExIFdM QU5zIGluIGVudGVycHJpc2UgbmV0d29ya3MuCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKTydIYXJh LCBldCBhbC4gICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDE4LCAyMDA1ICAgICAgICAgICAgICAg IFtQYWdlIDNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgQ0FQV0FQIFByb2JsZW0gU3RhdGVt ZW50ICAgICAgICAgICAgIEF1Z3VzdCAyMDA0CgoKMi4gIFByb2JsZW0gU3RhdGVtZW50CgogICBU aGUgZmlyc3QgcHJvYmxlbSBpbnRyb2R1Y2VkIGJ5IGxhcmdlIFdMQU4gZGVwbG95bWVudHMgaXMg dGhhdCBlYWNoCiAgIEFQIGlzIGFuIElQLWFkZHJlc3NhYmxlIGRldmljZSByZXF1aXJpbmcgbWFu YWdlbWVudCwgbW9uaXRvcmluZywgYW5kCiAgIGNvbnRyb2wuICBEZXBsb3ltZW50IG9mIGEgbGFy Z2UgV0xBTiB3aWxsIHR5cGljYWxseSBkb3VibGUgdGhlIG51bWJlcgogICBvZiBuZXR3b3JrIGlu ZnJhc3RydWN0dXJlIGRldmljZXMgdGhhdCByZXF1aXJlIG1hbmFnZW1lbnQsIG92ZXIgdGhlCiAg IGRldmljZXMgaW4gdGhlIG5ldHdvcmsgcHJpb3IgdG8gdGhlIGFkZGl0aW9uIG9mIHRoZSBXTEFO LiAgVGhpcwogICBwcmVzZW50cyBhIHNpZ25pZmljYW50IGFkZGl0aW9uYWwgYnVyZGVuIHRvIHRo ZSBuZXR3b3JrCiAgIGFkbWluaXN0cmF0aW9uIHJlc291cmNlcyBhbmQgaXMgb2Z0ZW4gYSBodXJk bGUgdG8gYWRvcHRpb24gb2YKICAgd2lyZWxlc3MgdGVjaG5vbG9naWVzLCBwYXJ0aWN1bGFybHkg YmVjYXVzZSB0aGUgY29uZmlndXJhdGlvbiBvZiBlYWNoCiAgIGFjY2VzcyBwb2ludCBpcyBuZWFy bHkgaWRlbnRpY2FsIHRvIHRoZSBuZXh0LiAgVGhpcyBuZWFyLXNhbWVuZXNzIG9mCiAgIGNvbmZp Z3VyYXRpb24gZnJvbSBvbmUgQVAgdG8gdGhlIG5leHQgb2Z0ZW4gbGVhZHMgdG8gbWlzY29uZmln dXJhdGlvbgogICBhbmQgaW1wcm9wZXIgb3BlcmF0aW9uIG9mIHRoZSBXTEFOLgoKICAgQSBzZWNv bmQgcHJvYmxlbSBpbnRyb2R1Y2VkIGJ5IGxhcmdlIFdMQU4gZGVwbG95bWVudHMgaXMgZGlzdHJp YnV0aW5nCiAgIGFuZCBtYWludGFpbmluZyBhIGNvbnNpc3RlbnQgY29uZmlndXJhdGlvbiB0aHJv dWdob3V0IHRoZSBlbnRpcmUgc2V0CiAgIG9mIGFjY2VzcyBwb2ludHMgaW4gdGhlIFdMQU4uICBB Y2Nlc3MgcG9pbnQgY29uZmlndXJhdGlvbiBjb25zaXN0cyBvZgogICBib3RoIGxvbmctdGVybSBz dGF0aWMgaW5mb3JtYXRpb24sIHN1Y2ggYXMgYWRkcmVzc2luZyBhbmQgaGFyZHdhcmUKICAgc2V0 dGluZ3MsIGFuZCBtb3JlIGR5bmFtaWMgcHJvdmlzaW9uaW5nIGluZm9ybWF0aW9uLCBzdWNoIGFz CiAgIGluZGl2aWR1YWwgV0xBTiBzZXR0aW5ncyBhbmQgc2VjdXJpdHkgcGFyYW1ldGVycy4gIExh cmdlIFdMQU4KICAgaW5zdGFsbGF0aW9ucyB0aGF0IG5lZWQgdG8gdXBkYXRlIGR5YW5taWMgcHJv dmlzaW9uaW5nIGluZm9ybWF0aW9uIGluCiAgIGFsbCB0aGUgQVBzIGluIHRoZSBXTEFOIHJlcXVp cmUgYSBwcm9sb25nZWQgcGhhc2Utb3ZlciB0aW1lLCB3aGlsZQogICBlYWNoIEFQIGlzIHVwZGF0 ZWQgYW5kIHRoZSBXTEFOIGRvZXMgbm90IGhhdmUgYSBzaW5nbGUsIGNvbnNpc3RlbnQsCiAgIGNv bmZpZ3VyYXRpb24uCgogICBBIHRoaXJkIHByb2JsZW0gaW50cm9kdWNlZCBieSBsYXJnZSBXTEFO IGRlcGxveW1lbnRzIGlzIHRoZQogICBkaWZmaWN1bHR5IGluIGRlYWxpbmcgZWZmZWN0aXZlbHkg d2l0aCB0aGUgZHluYW1pYyBuYXR1cmUgb2YgdGhlIFdMQU4KICAgbWVkaXVtLCBpdHNlbGYuICBE dWUgdG8gdGhlIHNoYXJlZCBuYXR1cmUgb2YgdGhlIHdpcmVsZXNzIG1lZGl1bSwKICAgc2hhcmVk IHdpdGggQVBzIGluIHRoZSBzYW1lIFdMQU4sIHdpdGggQVBzIGluIG90aGVyIFdMQU5zLCBhbmQg d2l0aAogICBkZXZpY2VzIHRoYXQgYXJlIG5vdCBBUHMgYXQgYWxsLCBwYXJhbWV0ZXJzIGNvbnRy b2xsaW5nIHRoZSB3aXJlbGVzcwogICBtZWRpdW0gb24gZWFjaCBBUCBtdXN0IGJlIG1vbml0b3Jl ZCBmcmVxdWVudGx5IGFuZCBtb2RpZmllZCBpbiBhCiAgIGNvb3JkaW5hdGVkIGZhc2hpb24gdG8g bWF4aW1pemUgcGVyZm9ybWFuY2UgZm9yIHRoZSBXTEFOIHRvIHV0aWxpemUKICAgdGhlIHdpcmVs ZXNzIG1lZGl1bSBlZmZpY2llbnRseS4gIFRoaXMgbXVzdCBiZSBjb29yZGluYXRlZCBhbW9uZyBh bGwKICAgdGhlIGFjY2VzcyBwb2ludHMsIHRvIG1pbmltaXplIHRoZSBpbnRlcmZlcmVuY2Ugb2Yg b25lIGFjY2VzcyBwb2ludAogICB3aXRoIGl0cyBuZWlnaGJvcnMuICBNYW51YWxseSBtb25pdG9y aW5nIHRoZXNlIG1ldHJpY3MgYW5kCiAgIGRldGVybWluaW5nIGEgbmV3LCBvcHRpbXVtIGNvbmZp Z3VyYXRpb24gZm9yIHRoZSBwYXJhbWV0ZXJzIHJlbGF0ZWQKICAgdG8gdGhlIHdpcmVsZXNzIG1l ZGl1bSBpcyBhIHRhc2sgdGhhdCB0YWtlcyBhIHNpZ25pZmljYW50IGFtb3VudCBvZgogICB0aW1l IGFuZCBlZmZvcnQuCgogICBBIGZvdXJ0aCBwcm9ibGVtIGludHJvZHVjZWQgYnkgbGFyZ2UgV0xB TiBkZXBsb3ltZW50cyBpcyBzZWN1cmluZwogICBhY2Nlc3MgdG8gdGhlIG5ldHdvcmsgYW5kIHBy ZXZlbnRpbmcgaW5zdGFsbGF0aW9uIG9mIHVuYXV0aG9yaXplZAogICBhY2Nlc3MgcG9pbnRzLiAg QWNjZXNzIHBvaW50cyBhcmUgb2Z0ZW4gZGlmZmljdWx0IHRvIHBoeXNpY2FsbHkKICAgc2VjdXJl LCBzaW5jZSB0aGVpciBsb2NhdGlvbiBtdXN0IG9mdGVuIGJlIG91dHNpZGUgb2YgYSBsb2NrZWQK ICAgbmV0d29yayBjbG9zZXQgb3Igc2VydmVyIHJvb20uICBUaGVmdCBvZiBhbiBhY2Nlc3MgcG9p bnQsIHdpdGggaXRzCiAgIGVtYmVkZGVkIHNlY3JldHMsIGFsbG93cyB0aGUgdGhpZWYgdG8gb2J0 YWluIGFjY2VzcyB0byB0aGUgcmVzb3VyY2VzCiAgIHNlY3VyZWQgYnkgdGhvc2Ugc2VjcmV0cy4K CiAgIFJlY2VudGx5LCBtdWx0aXBsZSB2ZW5kb3JzIGhhdmUgYmVndW4gb2ZmZXJpbmcgcHJvcHJp ZXRhcnkgc29sdXRpb25zCgoKCk8nSGFyYSwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBGZWJydWFy eSAxOCwgMjAwNSAgICAgICAgICAgICAgICBbUGFnZSA0XQoMCkludGVybmV0LURyYWZ0ICAgICAg ICAgIENBUFdBUCBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAgICBBdWd1c3QgMjAwNAoKCiAg IHRoYXQgY29tYmluZSBhc3BlY3RzIG9mIG5ldHdvcmsgc3dpdGNoaW5nLCBjZW50cmFsaXplZCBj b250cm9sIGFuZAogICBtYW5hZ2VtZW50LCBhbmQgZGlzdHJpYnV0ZWQgd2lyZWxlc3MgYWNjZXNz IGluIGEgdmFyaWV0eSBvZiBuZXcKICAgYXJjaGl0ZWN0dXJlcyB0byBhZHJlc3Mgc29tZSwgb3Ig YWxsLCBvZiB0aGUgYWJvdmUgbWVudGlvbmVkCiAgIHByb2JsZW1zLiAgU2luY2UgaW50ZXJvcGVy YWJsZSBzb2x1dGlvbnMgYWxsb3cgZW50ZXJwcmlzZXMgYW5kCiAgIHNlcnZpY2UgcHJvdmlkZXJz IGEgYnJvYWRlciBjaG9pY2UsIGEgc3RhbmRhcmRpemVkLCBpbnRlcm9wZXJhYmxlCiAgIGludGVy ZmFjZSBiZXR3ZWVuIGFjY2VzcyBwb2ludHMgYW5kIGEgY2VudHJhbGl6ZWQgY29udHJvbGxlcgog ICBhZGRyZXNzaW5nIHRoZSBhYm92ZSBtZW50aW9uZWQgcHJvYmxlbXMgc2VlbXMgZGVzaXJhYmxl LgoKICAgVGhlIHBoeXNpY2FsIHBvcnRpb25zIG9mIHRoaXMgbmV0d29yayBzeXN0ZW0sIGluIGN1 cnJlbnRseSBmaWVsZGVkCiAgIGRldmljZXMsIGFyZSBvbmUgb3IgbW9yZSA4MDIuMTEgYWNjZXNz IHBvaW50cyAoQVBzKSBhbmQgb25lIG9yIG1vcmUKICAgY2VudHJhbCBjb250cm9sIGRldmljZXMs IGFsdGVybmF0aXZlbHkgZGVzY3JpYmVkIGFzIGNvbnRyb2xsZXJzIChvcgogICBhY2Nlc3MgY29u dHJvbGxlcnMsIEFDcykuICBJZGVhbGx5LCBhIG5ldHdvcmsgZGVzaWduZXIgd291bGQgYmUgYWJs ZQogICB0byBjaG9vc2Ugb25lIG9yIG1vcmUgdmVuZG9ycyBmb3IgdGhlIEFQcyBhbmQgb25lIG9y IG1vcmUgdmVuZG9ycyBmb3IKICAgdGhlIGNlbnRyYWwgY29udHJvbCBkZXZpY2VzIGluIHN1ZmZp Y2llbnQgbnVtYmVycyB0byBkZXNpZ24gYSBuZXR3b3JrCiAgIHdpdGggODAyLjExIHdpcmVsZXNz IGFjY2VzcyB0byBtZWV0IHRoZSBkZXNpZ25lcidzIHJlcXVpcmVtZW50cy4KCiAgIEN1cnJlbnQg aW1wbGVtZW50YXRpb25zIGFyZSBwcm9wcmlldGFyeSBhbmQgbm90IGludGVyb3BlcmFibGUuICBU aGlzCiAgIGlzIGR1ZSB0byBhIG51bWJlciBvZiBmYWN0b3JzLCBpbmNsdWRpbmcgdGhlIGRpc3Bh cmF0ZSBhcmNoaXRlY3R1cmFsCiAgIGNob2ljZXMgbWFkZSBieSB0aGUgdmFyaW91cyBtYW51ZmFj dHVyZXJzLiAgQSB0YXhvbm9teSBvZiB0aGUKICAgYXJjaGl0ZWN0dXJlcyBlbXBsb3llZCBpbiB0 aGUgZXhpc3RpbmcgcHJvZHVjdHMgaW4gdGhlIG1hcmtldCB3aWxsCiAgIHByb3ZpZGUgdGhlIGJh c2lzIG9mIGFuIG91dHB1dCBkb2N1bWVudCB0byBiZSBwcm92aWRlZCB0byB0aGUgSUVFRQogICA4 MDIuMTEgV29ya2luZyBHcm91cC4gIFRoaXMgdGF4b25vbXkgd2lsbCBiZSB1dGlsaXplZCBieSB0 aGUgODAyLjExCiAgIFdvcmtpbmcgR3JvdXAgYXMgaW5wdXQgdG8gdGhlaXIgdGFzayBvZiBkZWZp bmluZyB0aGUgZnVuY3Rpb25hbAogICBhcmNoaXRlY3R1cmUgb2YgYW4gYWNjZXNzIHBvaW50LiAg VGhlIGZ1bmN0aW9uYWwgYXJjaGl0ZWN0dXJlLAogICBpbmNsdWRpbmcgZGVzY3JpcHRpb24gb2Yg ZGV0YWlsZWQgZnVuY3Rpb25hbCBibG9ja3MsIGludGVyZmFjZXMsIGFuZAogICBpbmZvcm1hdGlv biBmbG93LCB3aWxsIGJlIHJldmlld2VkIGJ5IENBUFdBUCB0byBkZXRlcm1pbmUgaWYgZnVydGhl cgogICB3b3JrIGlzIG5lZWRlZCB0byBhcHBseSBvciBkZXZlbG9wIHN0YW5kYXJkIHByb3RvY29s cyBwcm92aWRpbmcgZm9yCiAgIG11bHRpLXZlbmRvciBpbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0 aW9ucyBvZiBXTEFOcyBidWlsdCBmcm9tCiAgIGRldmljZXMgdGhhdCBhZGhlcmUgdG8gdGhlIG5l d2x5IGFwcGVhcmluZyBoaWVyYXJjaGljYWwgYXJjaGl0ZWN0dXJlCiAgIHV0aWxpemluZyBhIGZ1 bmN0aW9uYWwgc3BsaXQgYmV0d2VlbiBhbiBhY2Nlc3MgcG9pbnQgYW5kIGFuIGFjY2VzcwogICBj b250cm9sbGVyLgoKCgoKCgoKCgoKCgoKCgoKCgoKCk8nSGFyYSwgZXQgYWwuICAgICAgICAgRXhw aXJlcyBGZWJydWFyeSAxOCwgMjAwNSAgICAgICAgICAgICAgICBbUGFnZSA1XQoMCkludGVybmV0 LURyYWZ0ICAgICAgICAgIENBUFdBUCBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAgICBBdWd1 c3QgMjAwNAoKCjMuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucwoKICAgVGhlIGRldmljZXMgdXNl ZCBpbiBXTEFOcyBjb250cm9sIHRoZSBhY2Nlc3MgdG8gbmV0d29ya3MgYW5kIHByb3ZpZGUKICAg Zm9yIHRoZSBkZWxpdmVyeSBvZiBwYWNrZXRzIGJldHdlZW4gaG9zdHMgdXNpbmcgdGhlIFdMQU4g YW5kIG90aGVyCiAgIGhvc3RzIG9uIHRoZSBXTEFOIG9yIGVsc2V3aGVyZSBvbiB0aGUgSW50ZXJu ZXQuICBUaGUgZnVuY3Rpb25zIGZvcgogICBjb250cm9sIGFuZCBwcm92aXNpb25pbmcgb2Ygd2ly ZWxlc3MgYWNjZXNzIHBvaW50cywgdGhlcmVmb3JlIHJlcXVpcmUKICAgcHJvdGVjdGlvbiB0byBw cmV2ZW50IG1pc3VzZSBvZiB0aGUgZGV2aWNlcy4KCiAgIFJlcXVpcmVtZW50cyBmb3IgY2VudHJh bCBtYW5hZ2VtZW50LCBtb25pdG9yaW5nLCBhbmQgY29udHJvbCBvZgogICB3aXJlbGVzcyBhY2Nl c3MgcG9pbnRzIHRoYXQgc2hvdWxkIGJlIGFkZHJlc3NlZCBpbmNsdWRlCiAgIGNvbmZpZGVudGlh bGl0eSwgaW50ZWdyaXR5LCBhbmQgYXV0aGVudGljaXR5LiAgT25jZSBhbiBBUCBhbmQgQUMgaGF2 ZQogICBiZWVuIGF1dGhlbnRpY2F0ZWQgdG8gZWFjaCBvdGhlciwgaXQgbWF5IG5vdCBiZSBzdWZm aWNpZW50IHRoYXQgYQogICBzaW5nbGUgbGV2ZWwgb2YgYXV0aG9yaXphdGlvbiBhbGxvd3MgbW9u aXRvcmluZywgYXMgd2VsbCBhcyBjb250cm9sCiAgIGFuZCBwcm92aXNpb25pbmcuICBUaGUgcmVx dWlyZW1lbnQgZm9yIG1vcmUgdGhhbiBhIHNpbmdsZSBsZXZlbCBvZgogICBhdXRob3JpemF0aW9u IHNob3VsZCBiZSBkZXRlcm1pbmVkLiAgUGh5c2ljYWwgc2VjdXJpdHkgc2hvdWxkIGFsc28gYmUK ICAgYWRkcmVzc2VkLCBmb3IgdGhvc2UgZGV2aWNlcyB0aGF0IGNvbnRhaW4gc2VjdXJpdHkgcGFy YW1ldGVycyB0aGF0CiAgIGFyZSBzZW5zaXRpdmUgYW5kIG1pZ2h0IGNvbXByb21pc2UgdGhlIHNl Y3VyaXR5IG9mIHRoZSBzeXN0ZW0sIGlmCiAgIHRob3NlIHBhcmFtZXRlcnMgd2VyZSB0byBmYWxs IGludG8gdGhlIGhhbmRzIG9mIGFuIGF0dGFja2VyLgoKICAgQVBzIGFyZSBvZnRlbiBpbnN0YWxs ZWQgaW4gbG9jYXRpb25zIHRoYXQgYXJlIGRpZmZpY3VsdCB0byBzZWN1cmUsIGluCiAgIG9yZGVy IHRvIHByb3ZpZGUgY29tcHJlaGVuc2l2ZSByYWRpbyBjb3ZlcmFnZS4gIFRoZSBDQVBXQVAKICAg YXJjaGl0ZWN0dXJlIG1heSByZWR1Y2UgdGhlIGNvbnNlcXVlbmNlcyBvZiBhIHN0b2xlbiBBUC4g IElmCiAgIGhpZ2gtdmFsdWUgc2VjcmV0cywgc3VjaCBhcyBhIFJBRElVUyBzaGFyZWQgc2VjcmV0 LCBhcmUgc3RvcmVkIGluIHRoZQogICBBQywgdGhlbiB0aGUgcGh5c2ljYWwgbG9zcyBvZiBhbiBB UCBkb2VzIG5vdCBjb21wcm9taXNlIHRoZXNlCiAgIHNlY3JldHMuICBGdXJ0aGVyLCB0aGUgQUMg Y2FuIGVhc2lseSBiZSBsb2NhdGVkIGluIGEgcGh5c2ljYWxseQogICBzZWN1cmUgbG9jYXRpb24u ICBPZiBjb3Vyc2UsIGNvbmNlbnRyYXRpbmcgYWxsIG9mIHRoZSBoaWdoLXZhbHVlCiAgIHNlY3Jl dHMgaW4gb25lIHBsYWNlIG1ha2VzIHRoZSBBQyBhbiBhdHRyYWN0aXZlIHRhcmdldCwgYW5kIHN0 cmljdAogICBwaHlzaWNhbCwgcHJvY2VkdXJhbCwgYW5kIHRlY2huaWNhbCBjb250cm9scyBhcmUg bmVlZGVkIHRvIHByb3RlY3QKICAgdGhlIHNlY3JldHMuCgoKQXV0aG9ycycgQWRkcmVzc2VzCgog ICBCb2IgTydIYXJhCiAgIEFpcmVzcGFjZQogICAxMTAgTm9ydGVjaCBQYXJrd2F5CiAgIFNhbiBK b3NlLCBDQSAgOTUxMzQKCiAgIFBob25lOiArMSA0MDgtNjM1LTIwMjUKICAgRU1haWw6IGJvYkBh aXJlc3BhY2UuY29tCgoKCgoKCgoKCgoKTydIYXJhLCBldCBhbC4gICAgICAgICBFeHBpcmVzIEZl YnJ1YXJ5IDE4LCAyMDA1ICAgICAgICAgICAgICAgIFtQYWdlIDZdCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgQ0FQV0FQIFByb2JsZW0gU3RhdGVtZW50ICAgICAgICAgICAgIEF1Z3VzdCAyMDA0 CgoKICAgUGF0IFIuIENhbGhvdW4KICAgQWlyZXNwYWNlCiAgIDExMCBOb3J0ZWNoIFBhcmt3YXkK ICAgU2FuIEpvc2UsIENBICA5NTEzNAoKICAgUGhvbmU6ICsxIDQwOC02MzUtMjAwMAogICBFTWFp bDogcGNhbGhvdW5AYWlyZXNwYWNlLmNvbQoKCiAgIEphbWVzIEtlbXBmCiAgIERvY29tbyBMYWJz IFVTQQogICAxODEgTWV0cm8gRHJpdmUsIFN1aXRlIDMwMAogICBTYW4gSm9zZSwgQ0EgIDk1MTEw CgogICBQaG9uZTogKzEgNDA4IDQ1MSA0NzExCiAgIEVNYWlsOiBrZW1wZkBkb2NvbW9sYWJzLXVz YS5jb20KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpPJ0hhcmEsIGV0IGFsLiAg ICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMTgsIDIwMDUgICAgICAgICAgICAgICAgW1BhZ2UgN10K DApJbnRlcm5ldC1EcmFmdCAgICAgICAgICBDQVBXQVAgUHJvYmxlbSBTdGF0ZW1lbnQgICAgICAg ICAgICAgQXVndXN0IDIwMDQKCgpJbnRlbGxlY3R1YWwgUHJvcGVydHkgU3RhdGVtZW50CgogICBU aGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNjb3Bl IG9mIGFueQogICBpbnRlbGxlY3R1YWwgcHJvcGVydHkgb3Igb3RoZXIgcmlnaHRzIHRoYXQgbWln aHQgYmUgY2xhaW1lZCB0bwogICBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ug b2YgdGhlIHRlY2hub2xvZ3kgZGVzY3JpYmVkIGluCiAgIHRoaXMgZG9jdW1lbnQgb3IgdGhlIGV4 dGVudCB0byB3aGljaCBhbnkgbGljZW5zZSB1bmRlciBzdWNoIHJpZ2h0cwogICBtaWdodCBvciBt aWdodCBub3QgYmUgYXZhaWxhYmxlOyBuZWl0aGVyIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQK ICAgaGFzIG1hZGUgYW55IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3VjaCByaWdodHMuICBJbmZv cm1hdGlvbiBvbiB0aGUKICAgSUVURidzIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0 cyBpbiBzdGFuZGFyZHMtdHJhY2sgYW5kCiAgIHN0YW5kYXJkcy1yZWxhdGVkIGRvY3VtZW50YXRp b24gY2FuIGJlIGZvdW5kIGluIEJDUC0xMS4gIENvcGllcyBvZgogICBjbGFpbXMgb2YgcmlnaHRz IG1hZGUgYXZhaWxhYmxlIGZvciBwdWJsaWNhdGlvbiBhbmQgYW55IGFzc3VyYW5jZXMgb2YKICAg bGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2YgYW4gYXR0ZW1w dCBtYWRlIHRvCiAgIG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0 aGUgdXNlIG9mIHN1Y2gKICAgcHJvcHJpZXRhcnkgcmlnaHRzIGJ5IGltcGxlbWVudG9ycyBvciB1 c2VycyBvZiB0aGlzIHNwZWNpZmljYXRpb24gY2FuCiAgIGJlIG9idGFpbmVkIGZyb20gdGhlIElF VEYgU2VjcmV0YXJpYXQuCgogICBUaGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5 IHRvIGJyaW5nIHRvIGl0cyBhdHRlbnRpb24gYW55CiAgIGNvcHlyaWdodHMsIHBhdGVudHMgb3Ig cGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIgcHJvcHJpZXRhcnkKICAgcmlnaHRzIHdoaWNo IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJlcXVpcmVkIHRvIHByYWN0aWNlCiAg IHRoaXMgc3RhbmRhcmQuICBQbGVhc2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRpb24gdG8gdGhlIElF VEYgRXhlY3V0aXZlCiAgIERpcmVjdG9yLgoKCkZ1bGwgQ29weXJpZ2h0IFN0YXRlbWVudAoKICAg Q29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwNCkuICBBbGwgUmlnaHRzIFJl c2VydmVkLgoKICAgVGhpcyBkb2N1bWVudCBhbmQgdHJhbnNsYXRpb25zIG9mIGl0IG1heSBiZSBj b3BpZWQgYW5kIGZ1cm5pc2hlZCB0bwogICBvdGhlcnMsIGFuZCBkZXJpdmF0aXZlIHdvcmtzIHRo YXQgY29tbWVudCBvbiBvciBvdGhlcndpc2UgZXhwbGFpbiBpdAogICBvciBhc3Npc3QgaW4gaXRz IGltcGxlbWVudGF0aW9uIG1heSBiZSBwcmVwYXJlZCwgY29waWVkLCBwdWJsaXNoZWQKICAgYW5k IGRpc3RyaWJ1dGVkLCBpbiB3aG9sZSBvciBpbiBwYXJ0LCB3aXRob3V0IHJlc3RyaWN0aW9uIG9m IGFueQogICBraW5kLCBwcm92aWRlZCB0aGF0IHRoZSBhYm92ZSBjb3B5cmlnaHQgbm90aWNlIGFu ZCB0aGlzIHBhcmFncmFwaCBhcmUKICAgaW5jbHVkZWQgb24gYWxsIHN1Y2ggY29waWVzIGFuZCBk ZXJpdmF0aXZlIHdvcmtzLiAgSG93ZXZlciwgdGhpcwogICBkb2N1bWVudCBpdHNlbGYgbWF5IG5v dCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5LCBzdWNoIGFzIGJ5IHJlbW92aW5nCiAgIHRoZSBjb3B5 cmlnaHQgbm90aWNlIG9yIHJlZmVyZW5jZXMgdG8gdGhlIEludGVybmV0IFNvY2lldHkgb3Igb3Ro ZXIKICAgSW50ZXJuZXQgb3JnYW5pemF0aW9ucywgZXhjZXB0IGFzIG5lZWRlZCBmb3IgdGhlIHB1 cnBvc2Ugb2YKICAgZGV2ZWxvcGluZyBJbnRlcm5ldCBzdGFuZGFyZHMgaW4gd2hpY2ggY2FzZSB0 aGUgcHJvY2VkdXJlcyBmb3IKICAgY29weXJpZ2h0cyBkZWZpbmVkIGluIHRoZSBJbnRlcm5ldCBT dGFuZGFyZHMgcHJvY2VzcyBtdXN0IGJlCiAgIGZvbGxvd2VkLCBvciBhcyByZXF1aXJlZCB0byB0 cmFuc2xhdGUgaXQgaW50byBsYW5ndWFnZXMgb3RoZXIgdGhhbgogICBFbmdsaXNoLgoKICAgVGhl IGxpbWl0ZWQgcGVybWlzc2lvbnMgZ3JhbnRlZCBhYm92ZSBhcmUgcGVycGV0dWFsIGFuZCB3aWxs IG5vdCBiZQogICByZXZva2VkIGJ5IHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIGl0cyBzdWNjZXNz b3JzIG9yIGFzc2lnbmVlcy4KCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaGVyZWluIGlzIHByb3ZpZGVkIG9uIGFuCiAgICJBUyBJUyIgYmFzaXMgYW5kIFRI RSBJTlRFUk5FVCBTT0NJRVRZIEFORCBUSEUgSU5URVJORVQgRU5HSU5FRVJJTkcKICAgVEFTSyBG T1JDRSBESVNDTEFJTVMgQUxMIFdBUlJBTlRJRVMsIEVYUFJFU1MgT1IgSU1QTElFRCwgSU5DTFVE SU5HCiAgIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRI RSBJTkZPUk1BVElPTgoKCgpPJ0hhcmEsIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkg MTgsIDIwMDUgICAgICAgICAgICAgICAgW1BhZ2UgOF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg ICBDQVBXQVAgUHJvYmxlbSBTdGF0ZW1lbnQgICAgICAgICAgICAgQXVndXN0IDIwMDQKCgogICBI RVJFSU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRCBXQVJSQU5U SUVTIE9GCiAgIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVS UE9TRS4KCgpBY2tub3dsZWRnbWVudAoKICAgRnVuZGluZyBmb3IgdGhlIFJGQyBFZGl0b3IgZnVu Y3Rpb24gaXMgY3VycmVudGx5IHByb3ZpZGVkIGJ5IHRoZQogICBJbnRlcm5ldCBTb2NpZXR5LgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKTydIYXJhLCBldCBhbC4g ICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDE4LCAyMDA1ICAgICAgICAgICAgICAgIFtQYWdlIDld CgwKCg== ------_=_NextPart_001_01C4911B.5F186B92-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Sep 2 16:24: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 QAA04898 for ; Thu, 2 Sep 2004 16:24:32 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AD3E221603; Thu, 2 Sep 2004 16:09:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0C7662131D; Thu, 2 Sep 2004 16: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 68D472116D for ; Thu, 2 Sep 2004 16:08:10 -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 AA682208B8 for ; Thu, 2 Sep 2004 16:08: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_01C4912B.2B956DF4" Subject: RE: [Capwap] Local MAC Message-ID: <55749BC69138654EBBC4C50BA4F55610020C46BC@AIREMAIL.airespace.com> Thread-Topic: [Capwap] Local MAC Thread-Index: AcSRA5FiFY4dgUwhSbuNj3PZ9d1/sAAJ5Nuw From: "Pat R. Calhoun" To: "James Kempf" , "Chunduru Rama Krishna Prasad" , "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, 2 Sep 2004 13:26:36 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C4912B.2B956DF4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'd suggest negotiation PatC -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Thu 9/2/2004 8:30 AM To: Pat R. Calhoun; Chunduru Rama Krishna Prasad; Bob O'Hara; = capwap@frascone.com Subject: Re: [Capwap] Local MAC =20 But for purposes of interoperability (i.e. being able to mix and match = WTPs and ACs between vendors), doesn't this need to be specified? The = standard could either specify where encyption/decryption is done, or it could = allow for some type of negotiation when the WTP and AC first make contact and connect up. jak ----- Original Message -----=20 From: "Pat R. Calhoun" To: "Chunduru Rama Krishna Prasad" ; "Bob O'Hara" ; Sent: Thursday, September 02, 2004 5:50 AM Subject: RE: [Capwap] Local MAC I know of one implementation that decrypts in the WTP and another that decrypts in the AC. There is no definition of where this function occurs = in split MAC (or if there is it should say "may occur either in the WTP or = in the AC" :) PatC ________________________________ From: Chunduru Rama Krishna Prasad [mailto:rkp@intoto.com] Sent: Wed 9/1/2004 9:30 PM To: Bob O'Hara; Pat R. Calhoun; capwap@frascone.com Subject: RE: [Capwap] Local MAC What about encryption/decryption of 802.11 packets? In Local MAC, as I understand clearly that it is done at the WTP. And I think, that is good thing to do. Does split MAC definition allow this operation at WTPs? Thanks Rama Krishna At 10:04 AM 9/1/2004 -0700, Bob O'Hara wrote: I think the difference can be summed up like this: The protocol between an AC and the Local MAC and the Split MAC is semantically identical. Each uses a different syntax for this protocol. -Bob -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Pat R. Calhoun Sent: Wednesday, September 01, 2004 6:32 AM To: Chunduru Rama Krishna Prasad; capwap@frascone.com Subject: RE: [Capwap] Local MAC Great question. As you observed below, the primary difference (from what I can tell) = between split and local MAC is that while the former simply sends the frames untouched the latter reformulates the 802.11 messages into another format before sending them to the AC. So sure the PDUs look different, but in reality they are = not really that different, right? I mean what's the difference between sending a straight association = request to the AC vs. breaking the association request down into small components and = using the resulting information to create a message to be sent to the AC? One could easily argue that using the straight association request will ensure forward compatibility with any new IEEE 802.11 related standard. Let's use = 802.11k for instance, there are some new extensions that are added to existing MAC mgmt = frames. So while a protocol that simply forwards the MAC mgmt frames to the AC will be = able to handle 802.11k transparently, the other approach would require that the IETF WG = get together and define a way to map the new 802.11k extensions into whatever = protocol was created. Clearly, we cannot afford to have the IETF's protocol lag behind IEEE standards. On the data path, what is the difference between sending the straight = 802.11 frame vs. sending an 802.3 frame with some associated control information that = was derived from the 802.11 frame to begin with? What happens when protocols like 802.11e change the actual format of the frame by inserting 2 bytes in the protocol = header? Sending the straight 802.11 frame to the AC ensures that whatever solution we've = come up with will be able to support these future extensions, while a protocol that breaks down the PDU into an 802.3 frame will cause these extensions to be lost. It's really not like understanding the 802.11 protocol is a complex = thing - there are plenty of implementations of 802.11 based products, and some of these = are even available as open source. So I would argue that parsing 802.11 packets is much = simpler than 802.3 with some control information since those stacks are publicly available. PatC ________________________________ From: capwap-admin@frascone.com on behalf of Chunduru Rama Krishna = Prasad Sent: Tue 8/31/2004 10:52 PM To: capwap@frascone.com Subject: [Capwap] Local MAC Hi , Please correct if my interpretation of LOCAL MAC is wrong. WTP terminates 802.11 control packets and nothing is sent to AC . WTP terminates 802.11 mangement frames and corresponding events are sent = to AC. WTP terminates 802.11 data frames, does decryption/encryption based on unique keys correspond to wireless stations, extracts 802.3 packet from = the frame and send the frame across to AC. If needed, it might also send some control information along with each 802.3 packet. In this case, AC does not have knowledge of 802.11 header. It only needs knowledge of CAPWAP protocol, 802.1x termination, specific wireless related = parameters. What makes it split MAC? My understanding is that, if AC terminates = 802.11 frames and does encyption/decryption and has knowledge of 802.11 frames, then it is Split MAC. Is this understanding correct? Thanks Rama Krishna Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 ------_=_NextPart_001_01C4912B.2B956DF4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Capwap] Local MAC

I'd suggest negotiation

PatC


-----Original Message-----
From: James Kempf [mailto:kempf@docomolabs-usa.com<= /A>]
Sent: Thu 9/2/2004 8:30 AM
To: Pat R. Calhoun; Chunduru Rama Krishna Prasad; Bob O'Hara; = capwap@frascone.com
Subject: Re: [Capwap] Local MAC

But for purposes of interoperability (i.e. being able to mix and match = WTPs
and ACs between vendors), doesn't this need to be specified? The = standard
could either specify where encyption/decryption is done, or it could = allow
for some type of negotiation when the WTP and AC first make contact = and
connect up.

            &= nbsp;   jak

----- Original Message -----
From: "Pat R. Calhoun" <pcalhoun@airespace.com>
To: "Chunduru Rama Krishna Prasad" <rkp@intoto.com>; = "Bob O'Hara"
<bob@airespace.com>; <capwap@frascone.com>
Sent: Thursday, September 02, 2004 5:50 AM
Subject: RE: [Capwap] Local MAC


I know of one implementation that decrypts in the WTP and another = that
decrypts in the AC. There is no definition of where this function occurs = in
split MAC (or if there is it should say "may occur either in the = WTP or in
the AC" :)

PatC

________________________________

From: Chunduru Rama Krishna Prasad [mailto:rkp@intoto.com]
Sent: Wed 9/1/2004 9:30 PM
To: Bob O'Hara; Pat R. Calhoun; capwap@frascone.com
Subject: RE: [Capwap] Local MAC



What about encryption/decryption of 802.11 packets? In Local MAC, as = I
understand clearly that
it is done at the WTP. And I think, that is good thing to do.
Does split MAC definition allow this operation at WTPs?

Thanks
Rama Krishna

At 10:04 AM 9/1/2004 -0700, Bob O'Hara wrote:


I think the difference can be summed up like this:

The protocol between an AC and the Local MAC and the Split MAC is
semantically identical.  Each uses a different syntax for this = protocol.

-Bob

-----Original Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On Behalf
Of Pat R. Calhoun
Sent: Wednesday, September 01, 2004 6:32 AM
To: Chunduru Rama Krishna Prasad; capwap@frascone.com
Subject: RE: [Capwap] Local MAC

Great question.

As you observed below, the primary difference (from what I can tell) = between
split and local MAC is that while the former simply sends the frames
untouched
the latter reformulates the 802.11 messages into another format = before
sending
them to the AC. So sure the PDUs look different, but in reality they are = not
really
that different, right?

I mean what's the difference between sending a straight association = request
to the
AC vs. breaking the association request down into small components and = using
the
resulting information to create a message to be sent to the AC?

One could easily argue that using the straight association request = will
ensure forward
compatibility with any new IEEE 802.11 related standard. Let's use = 802.11k
for instance,
there are some new extensions that are added to existing MAC mgmt = frames. So
while
a protocol that simply forwards the MAC mgmt frames to the AC will be = able
to handle
802.11k transparently, the other approach would require that the IETF WG = get
together
and define a way to map the new 802.11k extensions into whatever = protocol
was created.
Clearly, we cannot afford to have the IETF's protocol lag behind = IEEE
standards.

On the data path, what is the difference between sending the straight = 802.11
frame
vs. sending an 802.3 frame with some associated control information that = was
derived
from the 802.11 frame to begin with? What happens when protocols = like
802.11e change
the actual format of the frame by inserting 2 bytes in the protocol = header?
Sending the
straight 802.11 frame to the AC ensures that whatever solution we've = come up
with will
be able to support these future extensions, while a protocol that = breaks
down the PDU
into an 802.3 frame will cause these extensions to be lost.

It's really not like understanding the 802.11 protocol is a complex = thing -
there are
plenty of implementations of 802.11 based products, and some of these = are
even available
as open source. So I would argue that parsing 802.11 packets is much = simpler
than 802.3
with some control information since those stacks are publicly = available.

PatC


________________________________

From: capwap-admin@frascone.com on behalf of Chunduru Rama Krishna = Prasad
Sent: Tue 8/31/2004 10:52 PM
To: capwap@frascone.com
Subject: [Capwap] Local MAC

Hi ,

Please correct if my interpretation of LOCAL MAC is wrong.
WTP terminates 802.11 control packets and nothing is sent to AC .
WTP terminates 802.11 mangement frames and corresponding events are sent = to
AC.
WTP terminates 802.11 data frames, does decryption/encryption based = on
unique keys correspond to wireless stations, extracts 802.3 packet from = the
frame and send the frame across to AC. If needed, it might also send
some control information along with each 802.3 packet.
In this case, AC does not have knowledge of 802.11 header. It only = needs
knowledge of
CAPWAP protocol, 802.1x termination, specific wireless related = parameters.

What makes it split MAC? My understanding is that, if AC terminates = 802.11
frames and
does encyption/decryption and has knowledge of 802.11 frames, then it = is
Split MAC.
Is this understanding correct?

Thanks
Rama Krishna



Ch. Rama Krishna Prasad
Intoto Software(I) Pvt Ltd,
Uma Plaza, Nagarjuna circle,
Panjagutta. Hyderabad, AP
Tel No:s  2335 8927/8928/8434

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

Ch. Rama Krishna Prasad
Intoto Software(I) Pvt Ltd,
Uma Plaza, Nagarjuna circle,
Panjagutta. Hyderabad, AP
Tel No:s  2335 8927/8928/8434

------_=_NextPart_001_01C4912B.2B956DF4-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Sep 2 17:23: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 RAA12857 for ; Thu, 2 Sep 2004 17:23:28 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 78DC721141; Thu, 2 Sep 2004 17:08:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9FE8C21AF2; Thu, 2 Sep 2004 17: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 3DE5821AF2 for ; Thu, 2 Sep 2004 17:07:36 -0400 (EDT) Received: from WNIMAIL.WoodsideNet.Com (wnifwl.woodsidenet.com [65.192.186.2]) by mail.frascone.com (Postfix) with ESMTP id 1B31621141 for ; Thu, 2 Sep 2004 17:07:34 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C49133.02DAD748" Subject: RE: [Capwap] Local MAC Message-ID: <3FFBC907DD03A34CA4410C5C745DEB1204673212@wnimail.WoodsideNet.Com> Thread-Topic: [Capwap] Local MAC Thread-Index: AcSRA5FiFY4dgUwhSbuNj3PZ9d1/sAAJ5NuwAAHOgQA= From: "Paul Lambert" To: "Pat R. Calhoun" , "James Kempf" , "Chunduru Rama Krishna Prasad" , "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, 2 Sep 2004 14:22:54 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C49133.02DAD748 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >I'd suggest negotiation =20 Even with negotiation, to ensure interoperability there must be a mandated set of capabilites. So, the working group will still have to pick a single perferred implementation approach. =20 Paul ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun Sent: Thursday, September 02, 2004 1:27 PM To: James Kempf; Chunduru Rama Krishna Prasad; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Local MAC =09 =09 I'd suggest negotiation =09 PatC =09 =09 -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Thu 9/2/2004 8:30 AM To: Pat R. Calhoun; Chunduru Rama Krishna Prasad; Bob O'Hara; capwap@frascone.com Subject: Re: [Capwap] Local MAC =09 But for purposes of interoperability (i.e. being able to mix and match WTPs and ACs between vendors), doesn't this need to be specified? The standard could either specify where encyption/decryption is done, or it could allow for some type of negotiation when the WTP and AC first make contact and connect up. =09 jak =09 ----- Original Message ----- From: "Pat R. Calhoun" To: "Chunduru Rama Krishna Prasad" ; "Bob O'Hara" ; Sent: Thursday, September 02, 2004 5:50 AM Subject: RE: [Capwap] Local MAC =09 =09 I know of one implementation that decrypts in the WTP and another that decrypts in the AC. There is no definition of where this function occurs in split MAC (or if there is it should say "may occur either in the WTP or in the AC" :) =09 PatC =09 ________________________________ =09 From: Chunduru Rama Krishna Prasad [mailto:rkp@intoto.com] Sent: Wed 9/1/2004 9:30 PM To: Bob O'Hara; Pat R. Calhoun; capwap@frascone.com Subject: RE: [Capwap] Local MAC =09 =09 =09 What about encryption/decryption of 802.11 packets? In Local MAC, as I understand clearly that it is done at the WTP. And I think, that is good thing to do. Does split MAC definition allow this operation at WTPs? =09 Thanks Rama Krishna =09 At 10:04 AM 9/1/2004 -0700, Bob O'Hara wrote: =09 =09 I think the difference can be summed up like this: =09 The protocol between an AC and the Local MAC and the Split MAC is semantically identical. Each uses a different syntax for this protocol. =09 -Bob =09 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun Sent: Wednesday, September 01, 2004 6:32 AM To: Chunduru Rama Krishna Prasad; capwap@frascone.com Subject: RE: [Capwap] Local MAC =09 Great question. =09 As you observed below, the primary difference (from what I can tell) between split and local MAC is that while the former simply sends the frames untouched the latter reformulates the 802.11 messages into another format before sending them to the AC. So sure the PDUs look different, but in reality they are not really that different, right? =09 I mean what's the difference between sending a straight association request to the AC vs. breaking the association request down into small components and using the resulting information to create a message to be sent to the AC? =09 One could easily argue that using the straight association request will ensure forward compatibility with any new IEEE 802.11 related standard. Let's use 802.11k for instance, there are some new extensions that are added to existing MAC mgmt frames. So while a protocol that simply forwards the MAC mgmt frames to the AC will be able to handle 802.11k transparently, the other approach would require that the IETF WG get together and define a way to map the new 802.11k extensions into whatever protocol was created. Clearly, we cannot afford to have the IETF's protocol lag behind IEEE standards. =09 On the data path, what is the difference between sending the straight 802.11 frame vs. sending an 802.3 frame with some associated control information that was derived from the 802.11 frame to begin with? What happens when protocols like 802.11e change the actual format of the frame by inserting 2 bytes in the protocol header? Sending the straight 802.11 frame to the AC ensures that whatever solution we've come up with will be able to support these future extensions, while a protocol that breaks down the PDU into an 802.3 frame will cause these extensions to be lost. =09 It's really not like understanding the 802.11 protocol is a complex thing - there are plenty of implementations of 802.11 based products, and some of these are even available as open source. So I would argue that parsing 802.11 packets is much simpler than 802.3 with some control information since those stacks are publicly available. =09 PatC =09 =09 ________________________________ =09 From: capwap-admin@frascone.com on behalf of Chunduru Rama Krishna Prasad Sent: Tue 8/31/2004 10:52 PM To: capwap@frascone.com Subject: [Capwap] Local MAC =09 Hi , =09 Please correct if my interpretation of LOCAL MAC is wrong. WTP terminates 802.11 control packets and nothing is sent to AC . WTP terminates 802.11 mangement frames and corresponding events are sent to AC. WTP terminates 802.11 data frames, does decryption/encryption based on unique keys correspond to wireless stations, extracts 802.3 packet from the frame and send the frame across to AC. If needed, it might also send some control information along with each 802.3 packet. In this case, AC does not have knowledge of 802.11 header. It only needs knowledge of CAPWAP protocol, 802.1x termination, specific wireless related parameters. =09 What makes it split MAC? My understanding is that, if AC terminates 802.11 frames and does encyption/decryption and has knowledge of 802.11 frames, then it is Split MAC. Is this understanding correct? =09 Thanks Rama Krishna =09 =09 =09 Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 =09 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap =09 Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 =09 =09 =09 =09 =09 ------_=_NextPart_001_01C49133.02DAD748 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Capwap] Local MAC
>I'd=20 suggest negotiation
 
Even with=20 negotiation, to ensure interoperability there must be a mandated set of=20 capabilites.  So, the working group will still have to = pick a=20 single perferred implementation approach.
 
Paul

From: capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Pat R.=20 Calhoun
Sent: Thursday, September 02, 2004 1:27 = PM
To:=20 James Kempf; Chunduru Rama Krishna Prasad; Bob O'Hara;=20 capwap@frascone.com
Subject: RE: [Capwap] Local=20 MAC

I'd suggest = negotiation

PatC


-----Original=20 Message-----
From: James Kempf [mailto:kempf@docomolabs-usa.com<= /A>]
Sent:=20 Thu 9/2/2004 8:30 AM
To: Pat R. Calhoun; Chunduru Rama Krishna = Prasad; Bob=20 O'Hara; capwap@frascone.com
Subject: Re: [Capwap] Local = MAC

But for=20 purposes of interoperability (i.e. being able to mix and match = WTPs
and ACs=20 between vendors), doesn't this need to be specified? The = standard
could=20 either specify where encyption/decryption is done, or it could = allow
for=20 some type of negotiation when the WTP and AC first make contact = and
connect=20 = up.

          &n= bsp;    =20 jak

----- Original Message -----
From: "Pat R. Calhoun"=20 <pcalhoun@airespace.com>
To: "Chunduru Rama Krishna Prasad"=20 <rkp@intoto.com>; "Bob O'Hara"
<bob@airespace.com>;=20 <capwap@frascone.com>
Sent: Thursday, September 02, 2004 5:50 = AM
Subject: RE: [Capwap] Local MAC


I know of one = implementation=20 that decrypts in the WTP and another that
decrypts in the AC. There = is no=20 definition of where this function occurs in
split MAC (or if there = is it=20 should say "may occur either in the WTP or in
the AC"=20 :)

PatC

________________________________

From: = Chunduru=20 Rama Krishna Prasad [mailto:rkp@intoto.com]
Sent: Wed = 9/1/2004=20 9:30 PM
To: Bob O'Hara; Pat R. Calhoun; = capwap@frascone.com
Subject: RE:=20 [Capwap] Local MAC



What about encryption/decryption of = 802.11=20 packets? In Local MAC, as I
understand clearly that
it is done = at the=20 WTP. And I think, that is good thing to do.
Does split MAC = definition allow=20 this operation at WTPs?

Thanks
Rama Krishna

At 10:04 = AM=20 9/1/2004 -0700, Bob O'Hara wrote:


I think the difference = can be=20 summed up like this:

The protocol between an AC and the Local = MAC and=20 the Split MAC is
semantically identical.  Each uses a = different syntax=20 for this protocol.

-Bob

-----Original = Message-----
From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m]=20 On Behalf
Of Pat R. Calhoun
Sent: Wednesday, September 01, 2004 = 6:32=20 AM
To: Chunduru Rama Krishna Prasad; = capwap@frascone.com
Subject: RE:=20 [Capwap] Local MAC

Great question.

As you observed = below, the=20 primary difference (from what I can tell) between
split and local = MAC is=20 that while the former simply sends the frames
untouched
the = latter=20 reformulates the 802.11 messages into another format = before
sending
them=20 to the AC. So sure the PDUs look different, but in reality they are=20 not
really
that different, right?

I mean what's the = difference=20 between sending a straight association request
to the
AC vs. = breaking=20 the association request down into small components and=20 using
the
resulting information to create a message to be sent = to the=20 AC?

One could easily argue that using the straight association = request=20 will
ensure forward
compatibility with any new IEEE 802.11 = related=20 standard. Let's use 802.11k
for instance,
there are some new = extensions=20 that are added to existing MAC mgmt frames. So
while
a protocol = that=20 simply forwards the MAC mgmt frames to the AC will be able
to=20 handle
802.11k transparently, the other approach would require that = the=20 IETF WG get
together
and define a way to map the new 802.11k = extensions=20 into whatever protocol
was created.
Clearly, we cannot afford to = have=20 the IETF's protocol lag behind IEEE
standards.

On the data = path,=20 what is the difference between sending the straight = 802.11
frame
vs.=20 sending an 802.3 frame with some associated control information that=20 was
derived
from the 802.11 frame to begin with? What happens = when=20 protocols like
802.11e change
the actual format of the frame by=20 inserting 2 bytes in the protocol header?
Sending the
straight = 802.11=20 frame to the AC ensures that whatever solution we've come up
with=20 will
be able to support these future extensions, while a protocol = that=20 breaks
down the PDU
into an 802.3 frame will cause these = extensions to=20 be lost.

It's really not like understanding the 802.11 protocol = is a=20 complex thing -
there are
plenty of implementations of 802.11 = based=20 products, and some of these are
even available
as open source. = So I=20 would argue that parsing 802.11 packets is much simpler
than = 802.3
with=20 some control information since those stacks are publicly=20 = available.

PatC


________________________________
From:=20 capwap-admin@frascone.com on behalf of Chunduru Rama Krishna = Prasad
Sent:=20 Tue 8/31/2004 10:52 PM
To: capwap@frascone.com
Subject: [Capwap] = Local=20 MAC

Hi ,

Please correct if my interpretation of LOCAL = MAC is=20 wrong.
WTP terminates 802.11 control packets and nothing is sent to = AC=20 .
WTP terminates 802.11 mangement frames and corresponding events = are sent=20 to
AC.
WTP terminates 802.11 data frames, does = decryption/encryption=20 based on
unique keys correspond to wireless stations, extracts = 802.3 packet=20 from the
frame and send the frame across to AC. If needed, it might = also=20 send
some control information along with each 802.3 packet.
In = this=20 case, AC does not have knowledge of 802.11 header. It only = needs
knowledge=20 of
CAPWAP protocol, 802.1x termination, specific wireless related=20 parameters.

What makes it split MAC? My understanding is that, = if AC=20 terminates 802.11
frames and
does encyption/decryption and has = knowledge=20 of 802.11 frames, then it is
Split MAC.
Is this understanding=20 correct?

Thanks
Rama Krishna



Ch. Rama Krishna = Prasad
Intoto Software(I) Pvt Ltd,
Uma Plaza, Nagarjuna=20 circle,
Panjagutta. Hyderabad, AP
Tel No:s  2335=20 = 8927/8928/8434

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

Ch.=20 Rama Krishna Prasad
Intoto Software(I) Pvt Ltd,
Uma Plaza, = Nagarjuna=20 circle,
Panjagutta. Hyderabad, AP
Tel No:s  2335=20 = 8927/8928/8434




------_=_NextPart_001_01C49133.02DAD748-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Sep 2 17:58: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 RAA15219 for ; Thu, 2 Sep 2004 17:58:28 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1A7F0216BF; Thu, 2 Sep 2004 17:43:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1648621141; Thu, 2 Sep 2004 17: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 06C6D21141 for ; Thu, 2 Sep 2004 17:42:24 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 48BF82037F for ; Thu, 2 Sep 2004 17:42:22 -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 i82LodJS027021 for ; Thu, 2 Sep 2004 16:50:40 -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 i82LocJS026991 for ; Thu, 2 Sep 2004 16:50:38 -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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Update to problem statement Message-ID: Thread-Topic: [Capwap] Update to problem statement Thread-Index: AcSRG17jPp6uTltUQGuKqOxR/Es9ngAG58hQ X-Priority: 1 Priority: Urgent Importance: high From: "Mani, Mahalingam (Mahalingam)" 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: Thu, 2 Sep 2004 15:57:41 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable All: Do take a look at the changes made and send any comments you may have to the list for authors to consider. As stated the current changes have incorporated observations from IESG review (the comment details & dispositions of which can be viewed at https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D 11362&rfc_flag=3D0 ) Regards, -mani Mahalingam Mani mmani@avaya.com +1 408.321.4840 (w) +1 408.396.2760 (m) -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Bob O'Hara Sent: Thursday, September 02, 2004 11:34 AM To: capwap@frascone.com Subject: [Capwap] Update to problem statement In response to comments from the IESG, I have updated the problem statement. It is attached for your review and comment. If I have not received any substantive comments by Monday, I will submit it to the IETF repository. Please comment to the list. There are some editorial changes and two new paragraphs in the Security Considerations section. -Bob Bob O'Hara Director of System Engineering, Founder Airespace, Inc. 110 Nortech Parkway San Jose, CA 95134-2307 Phone: +1 408 635 2025 Mobile: +1 408 218 4025 Fax: +1 408 635 2020 email: bob@airespace.com http://my.infotriever.com/to6ul4jo =20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Sep 3 03:22: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 DAA03766 for ; Fri, 3 Sep 2004 03:22:45 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6E0E42137D; Fri, 3 Sep 2004 03:05:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A79BB20205; Fri, 3 Sep 2004 03:05:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 64C1020205 for ; Fri, 3 Sep 2004 03:03:19 -0400 (EDT) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id 501F5204F6 for ; Fri, 3 Sep 2004 03:03:16 -0400 (EDT) Received: from Palpatine ([10.81.113.74]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id i837Fhgh015021; Fri, 3 Sep 2004 15:15:58 +0800 (SGT) From: "Cheng Hong" To: "'Paul Lambert'" , "'Pat R. Calhoun'" , "'James Kempf'" , "'Chunduru Rama Krishna Prasad'" , "'Bob O'Hara'" , Subject: RE: [Capwap] Local MAC Organization: Panasonic Singapore Laboratories Message-ID: <000401c49186$2e5da230$4a71510a@Palpatine> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C491C9.3C80E230" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <3FFBC907DD03A34CA4410C5C745DEB1204673212@wnimail.WoodsideNet.Com> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 3 Sep 2004 15:18:04 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C491C9.3C80E230 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable CAPWAP is not about how that is implemented. The protocol only needs to = be generic to support different implementations choices and provides negotiation methods. I don't think the group has to mandate a "single approach" of implementation. =20 cheers =20 Cheng=20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Paul Lambert Sent: Friday, September 03, 2004 5:23 AM To: Pat R. Calhoun; James Kempf; Chunduru Rama Krishna Prasad; Bob = O'Hara; capwap@frascone.com Subject: RE: [Capwap] Local MAC >I'd suggest negotiation =20 Even with negotiation, to ensure interoperability there must be a = mandated set of capabilites. So, the working group will still have to pick a = single perferred implementation approach. =20 Paul _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Pat R. Calhoun Sent: Thursday, September 02, 2004 1:27 PM To: James Kempf; Chunduru Rama Krishna Prasad; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Local MAC I'd suggest negotiation PatC -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Thu 9/2/2004 8:30 AM To: Pat R. Calhoun; Chunduru Rama Krishna Prasad; Bob O'Hara; capwap@frascone.com Subject: Re: [Capwap] Local MAC But for purposes of interoperability (i.e. being able to mix and match = WTPs and ACs between vendors), doesn't this need to be specified? The = standard could either specify where encyption/decryption is done, or it could = allow for some type of negotiation when the WTP and AC first make contact and connect up. jak ----- Original Message ----- From: "Pat R. Calhoun" To: "Chunduru Rama Krishna Prasad" ; "Bob O'Hara" ; Sent: Thursday, September 02, 2004 5:50 AM Subject: RE: [Capwap] Local MAC I know of one implementation that decrypts in the WTP and another that decrypts in the AC. There is no definition of where this function occurs = in split MAC (or if there is it should say "may occur either in the WTP or = in the AC" :) PatC ________________________________ From: Chunduru Rama Krishna Prasad [mailto:rkp@intoto.com] Sent: Wed 9/1/2004 9:30 PM To: Bob O'Hara; Pat R. Calhoun; capwap@frascone.com Subject: RE: [Capwap] Local MAC What about encryption/decryption of 802.11 packets? In Local MAC, as I understand clearly that it is done at the WTP. And I think, that is good thing to do. Does split MAC definition allow this operation at WTPs? Thanks Rama Krishna At 10:04 AM 9/1/2004 -0700, Bob O'Hara wrote: I think the difference can be summed up like this: The protocol between an AC and the Local MAC and the Split MAC is semantically identical. Each uses a different syntax for this protocol. -Bob -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Pat R. Calhoun Sent: Wednesday, September 01, 2004 6:32 AM To: Chunduru Rama Krishna Prasad; capwap@frascone.com Subject: RE: [Capwap] Local MAC Great question. As you observed below, the primary difference (from what I can tell) = between split and local MAC is that while the former simply sends the frames untouched the latter reformulates the 802.11 messages into another format before sending them to the AC. So sure the PDUs look different, but in reality they are = not really that different, right? I mean what's the difference between sending a straight association = request to the AC vs. breaking the association request down into small components and = using the resulting information to create a message to be sent to the AC? One could easily argue that using the straight association request will ensure forward compatibility with any new IEEE 802.11 related standard. Let's use = 802.11k for instance, there are some new extensions that are added to existing MAC mgmt = frames. So while a protocol that simply forwards the MAC mgmt frames to the AC will be = able to handle 802.11k transparently, the other approach would require that the IETF WG = get together and define a way to map the new 802.11k extensions into whatever = protocol was created. Clearly, we cannot afford to have the IETF's protocol lag behind IEEE standards. On the data path, what is the difference between sending the straight = 802.11 frame vs. sending an 802.3 frame with some associated control information that = was derived from the 802.11 frame to begin with? What happens when protocols like 802.11e change the actual format of the frame by inserting 2 bytes in the protocol = header? Sending the straight 802.11 frame to the AC ensures that whatever solution we've = come up with will be able to support these future extensions, while a protocol that breaks down the PDU into an 802.3 frame will cause these extensions to be lost. It's really not like understanding the 802.11 protocol is a complex = thing - there are plenty of implementations of 802.11 based products, and some of these = are even available as open source. So I would argue that parsing 802.11 packets is much = simpler than 802.3 with some control information since those stacks are publicly available. PatC ________________________________ From: capwap-admin@frascone.com on behalf of Chunduru Rama Krishna = Prasad Sent: Tue 8/31/2004 10:52 PM To: capwap@frascone.com Subject: [Capwap] Local MAC Hi , Please correct if my interpretation of LOCAL MAC is wrong. WTP terminates 802.11 control packets and nothing is sent to AC . WTP terminates 802.11 mangement frames and corresponding events are sent = to AC. WTP terminates 802.11 data frames, does decryption/encryption based on unique keys correspond to wireless stations, extracts 802.3 packet from = the frame and send the frame across to AC. If needed, it might also send some control information along with each 802.3 packet. In this case, AC does not have knowledge of 802.11 header. It only needs knowledge of CAPWAP protocol, 802.1x termination, specific wireless related = parameters. What makes it split MAC? My understanding is that, if AC terminates = 802.11 frames and does encyption/decryption and has knowledge of 802.11 frames, then it is Split MAC. Is this understanding correct? Thanks Rama Krishna Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 ------=_NextPart_000_0005_01C491C9.3C80E230 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
CAPWAP=20 is not about how that is implemented. The protocol only needs to be = generic to=20 support different implementations choices and provides negotiation = methods. I=20 don't think the group has to mandate a "single approach" of=20 implementation.
 
cheers
 
Cheng=20
-----Original Message-----
From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of=20 Paul Lambert
Sent: Friday, September 03, 2004 5:23=20 AM
To: Pat R. Calhoun; James Kempf; Chunduru Rama Krishna = Prasad;=20 Bob O'Hara; capwap@frascone.com
Subject: RE: [Capwap] Local=20 MAC

>I'd=20 suggest negotiation
 
Even with=20 negotiation, to ensure interoperability there must be a mandated set = of=20 capabilites.  So, the working group will still have to = pick a=20 single perferred implementation approach.
 
Paul

From: capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Pat R.=20 Calhoun
Sent: Thursday, September 02, 2004 1:27 = PM
To:=20 James Kempf; Chunduru Rama Krishna Prasad; Bob O'Hara;=20 capwap@frascone.com
Subject: RE: [Capwap] Local=20 MAC

I'd suggest = negotiation

PatC


-----Original=20 Message-----
From: James Kempf [mailto:kempf@docomolabs-usa.com<= /A>]
Sent:=20 Thu 9/2/2004 8:30 AM
To: Pat R. Calhoun; Chunduru Rama Krishna = Prasad;=20 Bob O'Hara; capwap@frascone.com
Subject: Re: [Capwap] Local=20 MAC

But for purposes of interoperability (i.e. being able to = mix and=20 match WTPs
and ACs between vendors), doesn't this need to be = specified?=20 The standard
could either specify where encyption/decryption is = done, or=20 it could allow
for some type of negotiation when the WTP and AC = first=20 make contact and
connect=20 = up.

          &n= bsp;    =20 jak

----- Original Message -----
From: "Pat R. Calhoun"=20 <pcalhoun@airespace.com>
To: "Chunduru Rama Krishna Prasad" = <rkp@intoto.com>; "Bob O'Hara"
<bob@airespace.com>;=20 <capwap@frascone.com>
Sent: Thursday, September 02, 2004 = 5:50=20 AM
Subject: RE: [Capwap] Local MAC


I know of one=20 implementation that decrypts in the WTP and another that
decrypts = in the=20 AC. There is no definition of where this function occurs in
split = MAC (or=20 if there is it should say "may occur either in the WTP or in
the = AC"=20 :)

PatC

________________________________

From: = Chunduru=20 Rama Krishna Prasad [mailto:rkp@intoto.com]
Sent: = Wed=20 9/1/2004 9:30 PM
To: Bob O'Hara; Pat R. Calhoun;=20 capwap@frascone.com
Subject: RE: [Capwap] Local = MAC



What=20 about encryption/decryption of 802.11 packets? In Local MAC, as=20 I
understand clearly that
it is done at the WTP. And I think, = that is=20 good thing to do.
Does split MAC definition allow this operation = at=20 WTPs?

Thanks
Rama Krishna

At 10:04 AM 9/1/2004 = -0700, Bob=20 O'Hara wrote:


I think the difference can be summed up = like=20 this:

The protocol between an AC and the Local MAC and the = Split MAC=20 is
semantically identical.  Each uses a different syntax for = this=20 protocol.

-Bob

-----Original Message-----
From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m]=20 On Behalf
Of Pat R. Calhoun
Sent: Wednesday, September 01, = 2004 6:32=20 AM
To: Chunduru Rama Krishna Prasad; = capwap@frascone.com
Subject: RE:=20 [Capwap] Local MAC

Great question.

As you observed = below, the=20 primary difference (from what I can tell) between
split and local = MAC is=20 that while the former simply sends the frames
untouched
the = latter=20 reformulates the 802.11 messages into another format=20 before
sending
them to the AC. So sure the PDUs look = different, but in=20 reality they are not
really
that different, right?

I = mean=20 what's the difference between sending a straight association = request
to=20 the
AC vs. breaking the association request down into small = components=20 and using
the
resulting information to create a message to be = sent to=20 the AC?

One could easily argue that using the straight = association=20 request will
ensure forward
compatibility with any new IEEE = 802.11=20 related standard. Let's use 802.11k
for instance,
there are = some new=20 extensions that are added to existing MAC mgmt frames. = So
while
a=20 protocol that simply forwards the MAC mgmt frames to the AC will be=20 able
to handle
802.11k transparently, the other approach would = require=20 that the IETF WG get
together
and define a way to map the new = 802.11k=20 extensions into whatever protocol
was created.
Clearly, we = cannot=20 afford to have the IETF's protocol lag behind = IEEE
standards.

On=20 the data path, what is the difference between sending the straight=20 802.11
frame
vs. sending an 802.3 frame with some associated = control=20 information that was
derived
from the 802.11 frame to begin = with? What=20 happens when protocols like
802.11e change
the actual format = of the=20 frame by inserting 2 bytes in the protocol header?
Sending=20 the
straight 802.11 frame to the AC ensures that whatever = solution we've=20 come up
with will
be able to support these future extensions, = while a=20 protocol that breaks
down the PDU
into an 802.3 frame will = cause these=20 extensions to be lost.

It's really not like understanding the = 802.11=20 protocol is a complex thing -
there are
plenty of = implementations of=20 802.11 based products, and some of these are
even available
as = open=20 source. So I would argue that parsing 802.11 packets is much = simpler
than=20 802.3
with some control information since those stacks are = publicly=20 = available.

PatC


________________________________
From:=20 capwap-admin@frascone.com on behalf of Chunduru Rama Krishna = Prasad
Sent:=20 Tue 8/31/2004 10:52 PM
To: capwap@frascone.com
Subject: = [Capwap] Local=20 MAC

Hi ,

Please correct if my interpretation of LOCAL = MAC is=20 wrong.
WTP terminates 802.11 control packets and nothing is sent = to AC=20 .
WTP terminates 802.11 mangement frames and corresponding events = are=20 sent to
AC.
WTP terminates 802.11 data frames, does=20 decryption/encryption based on
unique keys correspond to wireless = stations, extracts 802.3 packet from the
frame and send the frame = across=20 to AC. If needed, it might also send
some control information = along with=20 each 802.3 packet.
In this case, AC does not have knowledge of = 802.11=20 header. It only needs
knowledge of
CAPWAP protocol, 802.1x=20 termination, specific wireless related parameters.

What makes = it=20 split MAC? My understanding is that, if AC terminates = 802.11
frames=20 and
does encyption/decryption and has knowledge of 802.11 frames, = then it=20 is
Split MAC.
Is this understanding = correct?

Thanks
Rama=20 Krishna



Ch. Rama Krishna Prasad
Intoto Software(I) = Pvt=20 Ltd,
Uma Plaza, Nagarjuna circle,
Panjagutta. Hyderabad, = AP
Tel=20 No:s  2335=20 = 8927/8928/8434

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

Ch.=20 Rama Krishna Prasad
Intoto Software(I) Pvt Ltd,
Uma Plaza, = Nagarjuna=20 circle,
Panjagutta. Hyderabad, AP
Tel No:s  2335=20 = 8927/8928/8434




------=_NextPart_000_0005_01C491C9.3C80E230-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Sep 3 14:08: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 OAA03170 for ; Fri, 3 Sep 2004 14:08:31 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 35FB520E31; Fri, 3 Sep 2004 13:53:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B16AC21B4E; Fri, 3 Sep 2004 13:53:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B217721B52 for ; Fri, 3 Sep 2004 13:52:34 -0400 (EDT) Received: from extrgate1.extremenetworks.com (sc-f100-01.extremenetworks.com [63.251.106.30]) by mail.frascone.com (Postfix) with ESMTP id 9801E20E31 for ; Fri, 3 Sep 2004 13:52:32 -0400 (EDT) Received: by extrgate1.extremenetworks.com with Internet Mail Service (5.5.2656.59) id ; Fri, 3 Sep 2004 11:07:25 -0700 Message-ID: <1B8A2DD33C49824F8D9021678C127213028DC8CF@sc-msexch-04.extremenetworks.com> From: Shehzad Merchant To: Cheng Hong , "'Paul Lambert'" , "'Pat R. Calhoun'" , "'James Kempf'" , "'Chunduru Rama Krishna Prasad'" , "'Bob O'Hara'" , capwap@frascone.com Subject: RE: [Capwap] Local MAC MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C491E0.EDFF9B70" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 3 Sep 2004 11:07:52 -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_01C491E0.EDFF9B70 Content-Type: text/plain If you want to guarantee interoperability i.e. take WTP from vendor X, plug it into a network that has an AC from vendor Y and expect it to just work, I don't see how you can get there without a minimum set of functionality that is mandated and specified, both on the control/management plane as well as data plane. (there can always be capabilities beyond the minimum set that are optional and negotiable). I do agree that the mechanisms for control/management do not necessarily have to be the same as data plane i.e. one could specify the control/management protocol independently from the data plane, but I think to achieve full interoperability, a minimum set of both need to be specified. -S _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Cheng Hong Sent: Friday, September 03, 2004 12:18 AM To: 'Paul Lambert'; 'Pat R. Calhoun'; 'James Kempf'; 'Chunduru Rama Krishna Prasad'; 'Bob O'Hara'; capwap@frascone.com Subject: RE: [Capwap] Local MAC CAPWAP is not about how that is implemented. The protocol only needs to be generic to support different implementations choices and provides negotiation methods. I don't think the group has to mandate a "single approach" of implementation. cheers Cheng -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Paul Lambert Sent: Friday, September 03, 2004 5:23 AM To: Pat R. Calhoun; James Kempf; Chunduru Rama Krishna Prasad; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Local MAC >I'd suggest negotiation Even with negotiation, to ensure interoperability there must be a mandated set of capabilites. So, the working group will still have to pick a single perferred implementation approach. Paul _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun Sent: Thursday, September 02, 2004 1:27 PM To: James Kempf; Chunduru Rama Krishna Prasad; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Local MAC I'd suggest negotiation PatC -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com ] Sent: Thu 9/2/2004 8:30 AM To: Pat R. Calhoun; Chunduru Rama Krishna Prasad; Bob O'Hara; capwap@frascone.com Subject: Re: [Capwap] Local MAC But for purposes of interoperability (i.e. being able to mix and match WTPs and ACs between vendors), doesn't this need to be specified? The standard could either specify where encyption/decryption is done, or it could allow for some type of negotiation when the WTP and AC first make contact and connect up. jak ----- Original Message ----- From: "Pat R. Calhoun" To: "Chunduru Rama Krishna Prasad" ; "Bob O'Hara" ; Sent: Thursday, September 02, 2004 5:50 AM Subject: RE: [Capwap] Local MAC I know of one implementation that decrypts in the WTP and another that decrypts in the AC. There is no definition of where this function occurs in split MAC (or if there is it should say "may occur either in the WTP or in the AC" :) PatC ________________________________ From: Chunduru Rama Krishna Prasad [mailto:rkp@intoto.com ] Sent: Wed 9/1/2004 9:30 PM To: Bob O'Hara; Pat R. Calhoun; capwap@frascone.com Subject: RE: [Capwap] Local MAC What about encryption/decryption of 802.11 packets? In Local MAC, as I understand clearly that it is done at the WTP. And I think, that is good thing to do. Does split MAC definition allow this operation at WTPs? Thanks Rama Krishna At 10:04 AM 9/1/2004 -0700, Bob O'Hara wrote: I think the difference can be summed up like this: The protocol between an AC and the Local MAC and the Split MAC is semantically identical. Each uses a different syntax for this protocol. -Bob -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com ] On Behalf Of Pat R. Calhoun Sent: Wednesday, September 01, 2004 6:32 AM To: Chunduru Rama Krishna Prasad; capwap@frascone.com Subject: RE: [Capwap] Local MAC Great question. As you observed below, the primary difference (from what I can tell) between split and local MAC is that while the former simply sends the frames untouched the latter reformulates the 802.11 messages into another format before sending them to the AC. So sure the PDUs look different, but in reality they are not really that different, right? I mean what's the difference between sending a straight association request to the AC vs. breaking the association request down into small components and using the resulting information to create a message to be sent to the AC? One could easily argue that using the straight association request will ensure forward compatibility with any new IEEE 802.11 related standard. Let's use 802.11k for instance, there are some new extensions that are added to existing MAC mgmt frames. So while a protocol that simply forwards the MAC mgmt frames to the AC will be able to handle 802.11k transparently, the other approach would require that the IETF WG get together and define a way to map the new 802.11k extensions into whatever protocol was created. Clearly, we cannot afford to have the IETF's protocol lag behind IEEE standards. On the data path, what is the difference between sending the straight 802.11 frame vs. sending an 802.3 frame with some associated control information that was derived from the 802.11 frame to begin with? What happens when protocols like 802.11e change the actual format of the frame by inserting 2 bytes in the protocol header? Sending the straight 802.11 frame to the AC ensures that whatever solution we've come up with will be able to support these future extensions, while a protocol that breaks down the PDU into an 802.3 frame will cause these extensions to be lost. It's really not like understanding the 802.11 protocol is a complex thing - there are plenty of implementations of 802.11 based products, and some of these are even available as open source. So I would argue that parsing 802.11 packets is much simpler than 802.3 with some control information since those stacks are publicly available. PatC ________________________________ From: capwap-admin@frascone.com on behalf of Chunduru Rama Krishna Prasad Sent: Tue 8/31/2004 10:52 PM To: capwap@frascone.com Subject: [Capwap] Local MAC Hi , Please correct if my interpretation of LOCAL MAC is wrong. WTP terminates 802.11 control packets and nothing is sent to AC . WTP terminates 802.11 mangement frames and corresponding events are sent to AC. WTP terminates 802.11 data frames, does decryption/encryption based on unique keys correspond to wireless stations, extracts 802.3 packet from the frame and send the frame across to AC. If needed, it might also send some control information along with each 802.3 packet. In this case, AC does not have knowledge of 802.11 header. It only needs knowledge of CAPWAP protocol, 802.1x termination, specific wireless related parameters. What makes it split MAC? My understanding is that, if AC terminates 802.11 frames and does encyption/decryption and has knowledge of 802.11 frames, then it is Split MAC. Is this understanding correct? Thanks Rama Krishna Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 ------_=_NextPart_001_01C491E0.EDFF9B70 Content-Type: text/html Message
If you want to guarantee interoperability i.e. take WTP from vendor X, plug it into a network that has an AC from vendor Y and expect it to just work, I don't see how you can get there without a minimum set of functionality that is mandated and specified, both on the control/management plane as well as data plane. (there can always be capabilities beyond the minimum set that are optional and negotiable).
 
I do agree that the mechanisms for control/management do not necessarily have to be the same as data plane i.e. one could specify the control/management protocol independently from the data plane, but I think to achieve full interoperability, a minimum set of both need to be specified.
 
-S
 

From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Cheng Hong
Sent: Friday, September 03, 2004 12:18 AM
To: 'Paul Lambert'; 'Pat R. Calhoun'; 'James Kempf'; 'Chunduru Rama Krishna Prasad'; 'Bob O'Hara'; capwap@frascone.com
Subject: RE: [Capwap] Local MAC

CAPWAP is not about how that is implemented. The protocol only needs to be generic to support different implementations choices and provides negotiation methods. I don't think the group has to mandate a "single approach" of implementation.
 
cheers
 
Cheng
-----Original Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Paul Lambert
Sent: Friday, September 03, 2004 5:23 AM
To: Pat R. Calhoun; James Kempf; Chunduru Rama Krishna Prasad; Bob O'Hara; capwap@frascone.com
Subject: RE: [Capwap] Local MAC

>I'd suggest negotiation
 
Even with negotiation, to ensure interoperability there must be a mandated set of capabilites.  So, the working group will still have to pick a single perferred implementation approach.
 
Paul

From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun
Sent: Thursday, September 02, 2004 1:27 PM
To: James Kempf; Chunduru Rama Krishna Prasad; Bob O'Hara; capwap@frascone.com
Subject: RE: [Capwap] Local MAC

I'd suggest negotiation

PatC


-----Original Message-----
From: James Kempf [mailto:kempf@docomolabs-usa.com]
Sent: Thu 9/2/2004 8:30 AM
To: Pat R. Calhoun; Chunduru Rama Krishna Prasad; Bob O'Hara; capwap@frascone.com
Subject: Re: [Capwap] Local MAC

But for purposes of interoperability (i.e. being able to mix and match WTPs
and ACs between vendors), doesn't this need to be specified? The standard
could either specify where encyption/decryption is done, or it could allow
for some type of negotiation when the WTP and AC first make contact and
connect up.

                jak

----- Original Message -----
From: "Pat R. Calhoun" <pcalhoun@airespace.com>
To: "Chunduru Rama Krishna Prasad" <rkp@intoto.com>; "Bob O'Hara"
<bob@airespace.com>; <capwap@frascone.com>
Sent: Thursday, September 02, 2004 5:50 AM
Subject: RE: [Capwap] Local MAC


I know of one implementation that decrypts in the WTP and another that
decrypts in the AC. There is no definition of where this function occurs in
split MAC (or if there is it should say "may occur either in the WTP or in
the AC" :)

PatC

________________________________

From: Chunduru Rama Krishna Prasad [mailto:rkp@intoto.com]
Sent: Wed 9/1/2004 9:30 PM
To: Bob O'Hara; Pat R. Calhoun; capwap@frascone.com
Subject: RE: [Capwap] Local MAC



What about encryption/decryption of 802.11 packets? In Local MAC, as I
understand clearly that
it is done at the WTP. And I think, that is good thing to do.
Does split MAC definition allow this operation at WTPs?

Thanks
Rama Krishna

At 10:04 AM 9/1/2004 -0700, Bob O'Hara wrote:


I think the difference can be summed up like this:

The protocol between an AC and the Local MAC and the Split MAC is
semantically identical.  Each uses a different syntax for this protocol.

-Bob

-----Original Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf
Of Pat R. Calhoun
Sent: Wednesday, September 01, 2004 6:32 AM
To: Chunduru Rama Krishna Prasad; capwap@frascone.com
Subject: RE: [Capwap] Local MAC

Great question.

As you observed below, the primary difference (from what I can tell) between
split and local MAC is that while the former simply sends the frames
untouched
the latter reformulates the 802.11 messages into another format before
sending
them to the AC. So sure the PDUs look different, but in reality they are not
really
that different, right?

I mean what's the difference between sending a straight association request
to the
AC vs. breaking the association request down into small components and using
the
resulting information to create a message to be sent to the AC?

One could easily argue that using the straight association request will
ensure forward
compatibility with any new IEEE 802.11 related standard. Let's use 802.11k
for instance,
there are some new extensions that are added to existing MAC mgmt frames. So
while
a protocol that simply forwards the MAC mgmt frames to the AC will be able
to handle
802.11k transparently, the other approach would require that the IETF WG get
together
and define a way to map the new 802.11k extensions into whatever protocol
was created.
Clearly, we cannot afford to have the IETF's protocol lag behind IEEE
standards.

On the data path, what is the difference between sending the straight 802.11
frame
vs. sending an 802.3 frame with some associated control information that was
derived
from the 802.11 frame to begin with? What happens when protocols like
802.11e change
the actual format of the frame by inserting 2 bytes in the protocol header?
Sending the
straight 802.11 frame to the AC ensures that whatever solution we've come up
with will
be able to support these future extensions, while a protocol that breaks
down the PDU
into an 802.3 frame will cause these extensions to be lost.

It's really not like understanding the 802.11 protocol is a complex thing -
there are
plenty of implementations of 802.11 based products, and some of these are
even available
as open source. So I would argue that parsing 802.11 packets is much simpler
than 802.3
with some control information since those stacks are publicly available.

PatC


________________________________

From: capwap-admin@frascone.com on behalf of Chunduru Rama Krishna Prasad
Sent: Tue 8/31/2004 10:52 PM
To: capwap@frascone.com
Subject: [Capwap] Local MAC

Hi ,

Please correct if my interpretation of LOCAL MAC is wrong.
WTP terminates 802.11 control packets and nothing is sent to AC .
WTP terminates 802.11 mangement frames and corresponding events are sent to
AC.
WTP terminates 802.11 data frames, does decryption/encryption based on
unique keys correspond to wireless stations, extracts 802.3 packet from the
frame and send the frame across to AC. If needed, it might also send
some control information along with each 802.3 packet.
In this case, AC does not have knowledge of 802.11 header. It only needs
knowledge of
CAPWAP protocol, 802.1x termination, specific wireless related parameters.

What makes it split MAC? My understanding is that, if AC terminates 802.11
frames and
does encyption/decryption and has knowledge of 802.11 frames, then it is
Split MAC.
Is this understanding correct?

Thanks
Rama Krishna



Ch. Rama Krishna Prasad
Intoto Software(I) Pvt Ltd,
Uma Plaza, Nagarjuna circle,
Panjagutta. Hyderabad, AP
Tel No:s  2335 8927/8928/8434

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

Ch. Rama Krishna Prasad
Intoto Software(I) Pvt Ltd,
Uma Plaza, Nagarjuna circle,
Panjagutta. Hyderabad, AP
Tel No:s  2335 8927/8928/8434




------_=_NextPart_001_01C491E0.EDFF9B70-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sun Sep 5 22:53: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 WAA10662 for ; Sun, 5 Sep 2004 22:53:38 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8BFC521990; Sun, 5 Sep 2004 22:38:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ED66D2199C; Sun, 5 Sep 2004 22:38:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9CAF72199D for ; Sun, 5 Sep 2004 22:37:33 -0400 (EDT) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id D472921990 for ; Sun, 5 Sep 2004 22:37:29 -0400 (EDT) Received: from Palpatine ([10.81.113.73]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id i862nECB019780; Mon, 6 Sep 2004 10:49:45 +0800 (SGT) From: "Cheng Hong" To: "'Shehzad Merchant'" , "'Paul Lambert'" , "'Pat R. Calhoun'" , "'James Kempf'" , "'Chunduru Rama Krishna Prasad'" , "'Bob O'Hara'" , Cc: "'Saravanan Govindan'" Subject: RE: [Capwap] Local MAC Organization: Panasonic Singapore Laboratories Message-ID: <008001c493bc$7de28b30$4971510a@Palpatine> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0081_01C493FF.8C05CB30" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <1B8A2DD33C49824F8D9021678C127213028DC8CF@sc-msexch-04.extremenetworks.com> 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: Mon, 6 Sep 2004 10:51:36 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------=_NextPart_000_0081_01C493FF.8C05CB30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't object the idea of mandate or specifying the functionality set, = but I don't think the group should "pick a single perferred implementation approach"=20 =20 Whether we need to specify a minimum set of functions for WTP and AC is another issue. This depends on the objective we set for the CAPWAP. If = we set the target as: any WTP and AC with a CAPWAP lebel should be able to = work happily together and provide service, then the minimum functions should = be set. If the target is to provide a protocol for a WTP and AC to work together if they can, the minimum function required would be for the negotiation and function discovery. =20 Even for the first case, a negotiation function is necessary, since WTP = and AC could provide redundent functions, and they need to negotiate who to excute which part. =20 cheers =20 Cheng -----Original Message----- From: Shehzad Merchant [mailto:smerchant@extremenetworks.com]=20 Sent: Saturday, September 04, 2004 2:08 AM To: Cheng Hong; 'Paul Lambert'; 'Pat R. Calhoun'; 'James Kempf'; = 'Chunduru Rama Krishna Prasad'; 'Bob O'Hara'; capwap@frascone.com Subject: RE: [Capwap] Local MAC If you want to guarantee interoperability i.e. take WTP from vendor X, = plug it into a network that has an AC from vendor Y and expect it to just = work, I don't see how you can get there without a minimum set of functionality = that is mandated and specified, both on the control/management plane as well = as data plane. (there can always be capabilities beyond the minimum set = that are optional and negotiable).=20 =20 I do agree that the mechanisms for control/management do not necessarily have to be the same as data plane i.e. one could specify the control/management protocol independently from the data plane, but I = think to achieve full interoperability, a minimum set of both need to be specified. =20 -S =20 _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Cheng Hong Sent: Friday, September 03, 2004 12:18 AM To: 'Paul Lambert'; 'Pat R. Calhoun'; 'James Kempf'; 'Chunduru Rama = Krishna Prasad'; 'Bob O'Hara'; capwap@frascone.com Subject: RE: [Capwap] Local MAC CAPWAP is not about how that is implemented. The protocol only needs to = be generic to support different implementations choices and provides negotiation methods. I don't think the group has to mandate a "single approach" of implementation. =20 cheers =20 Cheng=20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Paul Lambert Sent: Friday, September 03, 2004 5:23 AM To: Pat R. Calhoun; James Kempf; Chunduru Rama Krishna Prasad; Bob = O'Hara; capwap@frascone.com Subject: RE: [Capwap] Local MAC >I'd suggest negotiation =20 Even with negotiation, to ensure interoperability there must be a = mandated set of capabilites. So, the working group will still have to pick a = single perferred implementation approach. =20 Paul _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Pat R. Calhoun Sent: Thursday, September 02, 2004 1:27 PM To: James Kempf; Chunduru Rama Krishna Prasad; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Local MAC I'd suggest negotiation PatC -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Thu 9/2/2004 8:30 AM To: Pat R. Calhoun; Chunduru Rama Krishna Prasad; Bob O'Hara; capwap@frascone.com Subject: Re: [Capwap] Local MAC But for purposes of interoperability (i.e. being able to mix and match = WTPs and ACs between vendors), doesn't this need to be specified? The = standard could either specify where encyption/decryption is done, or it could = allow for some type of negotiation when the WTP and AC first make contact and connect up. jak ----- Original Message ----- From: "Pat R. Calhoun" To: "Chunduru Rama Krishna Prasad" ; "Bob O'Hara" ; Sent: Thursday, September 02, 2004 5:50 AM Subject: RE: [Capwap] Local MAC I know of one implementation that decrypts in the WTP and another that decrypts in the AC. There is no definition of where this function occurs = in split MAC (or if there is it should say "may occur either in the WTP or = in the AC" :) PatC ________________________________ From: Chunduru Rama Krishna Prasad [mailto:rkp@intoto.com] Sent: Wed 9/1/2004 9:30 PM To: Bob O'Hara; Pat R. Calhoun; capwap@frascone.com Subject: RE: [Capwap] Local MAC What about encryption/decryption of 802.11 packets? In Local MAC, as I understand clearly that it is done at the WTP. And I think, that is good thing to do. Does split MAC definition allow this operation at WTPs? Thanks Rama Krishna At 10:04 AM 9/1/2004 -0700, Bob O'Hara wrote: I think the difference can be summed up like this: The protocol between an AC and the Local MAC and the Split MAC is semantically identical. Each uses a different syntax for this protocol. -Bob -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Pat R. Calhoun Sent: Wednesday, September 01, 2004 6:32 AM To: Chunduru Rama Krishna Prasad; capwap@frascone.com Subject: RE: [Capwap] Local MAC Great question. As you observed below, the primary difference (from what I can tell) = between split and local MAC is that while the former simply sends the frames untouched the latter reformulates the 802.11 messages into another format before sending them to the AC. So sure the PDUs look different, but in reality they are = not really that different, right? I mean what's the difference between sending a straight association = request to the AC vs. breaking the association request down into small components and = using the resulting information to create a message to be sent to the AC? One could easily argue that using the straight association request will ensure forward compatibility with any new IEEE 802.11 related standard. Let's use = 802.11k for instance, there are some new extensions that are added to existing MAC mgmt = frames. So while a protocol that simply forwards the MAC mgmt frames to the AC will be = able to handle 802.11k transparently, the other approach would require that the IETF WG = get together and define a way to map the new 802.11k extensions into whatever = protocol was created. Clearly, we cannot afford to have the IETF's protocol lag behind IEEE standards. On the data path, what is the difference between sending the straight = 802.11 frame vs. sending an 802.3 frame with some associated control information that = was derived from the 802.11 frame to begin with? What happens when protocols like 802.11e change the actual format of the frame by inserting 2 bytes in the protocol = header? Sending the straight 802.11 frame to the AC ensures that whatever solution we've = come up with will be able to support these future extensions, while a protocol that breaks down the PDU into an 802.3 frame will cause these extensions to be lost. It's really not like understanding the 802.11 protocol is a complex = thing - there are plenty of implementations of 802.11 based products, and some of these = are even available as open source. So I would argue that parsing 802.11 packets is much = simpler than 802.3 with some control information since those stacks are publicly available. PatC ________________________________ From: capwap-admin@frascone.com on behalf of Chunduru Rama Krishna = Prasad Sent: Tue 8/31/2004 10:52 PM To: capwap@frascone.com Subject: [Capwap] Local MAC Hi , Please correct if my interpretation of LOCAL MAC is wrong. WTP terminates 802.11 control packets and nothing is sent to AC . WTP terminates 802.11 mangement frames and corresponding events are sent = to AC. WTP terminates 802.11 data frames, does decryption/encryption based on unique keys correspond to wireless stations, extracts 802.3 packet from = the frame and send the frame across to AC. If needed, it might also send some control information along with each 802.3 packet. In this case, AC does not have knowledge of 802.11 header. It only needs knowledge of CAPWAP protocol, 802.1x termination, specific wireless related = parameters. What makes it split MAC? My understanding is that, if AC terminates = 802.11 frames and does encyption/decryption and has knowledge of 802.11 frames, then it is Split MAC. Is this understanding correct? Thanks Rama Krishna Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 ------=_NextPart_000_0081_01C493FF.8C05CB30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I=20 don't object the idea of mandate or specifying the functionality set, = but I=20 don't think the group should "pick a=20 single perferred implementation approach"
 
Whether we need to = specify a=20 minimum set of functions for WTP and AC is another issue. This depends = on the=20 objective we set for the CAPWAP. If we set the target as: any WTP and AC = with=20 a CAPWAP lebel should be able to work happily  together and = provide=20 service, then the minimum functions should be set. If the target is to = provide a=20 protocol for a WTP and AC to work together if they can, the minimum = function=20 required would be for the negotiation and function=20 discovery.
 
Even for the first = case, a=20 negotiation function is necessary, since WTP and AC could provide = redundent=20 functions, and they need to negotiate who to excute which=20 part.
 
cheers
 
Cheng
-----Original Message-----
From: = Shehzad Merchant=20 [mailto:smerchant@extremenetworks.com]
Sent: Saturday, = September=20 04, 2004 2:08 AM
To: Cheng Hong; 'Paul Lambert'; 'Pat R. = Calhoun';=20 'James Kempf'; 'Chunduru Rama Krishna Prasad'; 'Bob O'Hara';=20 capwap@frascone.com
Subject: RE: [Capwap] Local=20 MAC

If you want to guarantee interoperability = i.e. take WTP=20 from vendor X, plug it into a network that has an AC from vendor Y and = expect=20 it to just work, I don't see how you can get there without a minimum = set of=20 functionality that is mandated and specified, both on the = control/management=20 plane as well as data plane. (there can always be capabilities beyond = the=20 minimum set that are optional and negotiable). =
 
I do agree that the mechanisms for = control/management do=20 not necessarily have to be the same as data plane i.e. one could = specify=20 the control/management protocol independently from the data plane, but = I think=20 to achieve full interoperability, a minimum set of both need to be=20 specified.
 
-S
 

From: capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Cheng=20 Hong
Sent: Friday, September 03, 2004 12:18 AM
To: = 'Paul=20 Lambert'; 'Pat R. Calhoun'; 'James Kempf'; 'Chunduru Rama Krishna = Prasad';=20 'Bob O'Hara'; capwap@frascone.com
Subject: RE: [Capwap] = Local=20 MAC

CAPWAP is not about how that is implemented. The protocol = only needs to=20 be generic to support different implementations choices and provides=20 negotiation methods. I don't think the group has to mandate a "single=20 approach" of implementation.
 
cheers
 
Cheng
-----Original Message-----
From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of=20 Paul Lambert
Sent: Friday, September 03, 2004 5:23=20 AM
To: Pat R. Calhoun; James Kempf; Chunduru Rama Krishna = Prasad;=20 Bob O'Hara; capwap@frascone.com
Subject: RE: [Capwap] = Local=20 MAC

>I'd=20 suggest negotiation
 
Even=20 with negotiation, to ensure interoperability there must be a = mandated set of=20 capabilites.  So, the working group will still have = to pick a=20 single perferred implementation approach.
 
Paul

From: = capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Pat R.=20 Calhoun
Sent: Thursday, September 02, 2004 1:27 = PM
To:=20 James Kempf; Chunduru Rama Krishna Prasad; Bob O'Hara;=20 capwap@frascone.com
Subject: RE: [Capwap] Local=20 MAC

I'd suggest=20 negotiation

PatC


-----Original = Message-----
From:=20 James Kempf [mailto:kempf@docomolabs-usa.com<= /A>]
Sent:=20 Thu 9/2/2004 8:30 AM
To: Pat R. Calhoun; Chunduru Rama Krishna = Prasad;=20 Bob O'Hara; capwap@frascone.com
Subject: Re: [Capwap] Local=20 MAC

But for purposes of interoperability (i.e. being able = to mix=20 and match WTPs
and ACs between vendors), doesn't this need to = be=20 specified? The standard
could either specify where = encyption/decryption=20 is done, or it could allow
for some type of negotiation when = the WTP=20 and AC first make contact and
connect=20 = up.

          &n= bsp;    =20 jak

----- Original Message -----
From: "Pat R. Calhoun"=20 <pcalhoun@airespace.com>
To: "Chunduru Rama Krishna = Prasad"=20 <rkp@intoto.com>; "Bob O'Hara"
<bob@airespace.com>; = <capwap@frascone.com>
Sent: Thursday, September 02, 2004 = 5:50=20 AM
Subject: RE: [Capwap] Local MAC


I know of one=20 implementation that decrypts in the WTP and another = that
decrypts in=20 the AC. There is no definition of where this function occurs = in
split=20 MAC (or if there is it should say "may occur either in the WTP or=20 in
the AC"=20 = :)

PatC

________________________________

From:=20 Chunduru Rama Krishna Prasad [mailto:rkp@intoto.com]
Sent: = Wed=20 9/1/2004 9:30 PM
To: Bob O'Hara; Pat R. Calhoun;=20 capwap@frascone.com
Subject: RE: [Capwap] Local = MAC



What=20 about encryption/decryption of 802.11 packets? In Local MAC, as=20 I
understand clearly that
it is done at the WTP. And I = think, that=20 is good thing to do.
Does split MAC definition allow this = operation at=20 WTPs?

Thanks
Rama Krishna

At 10:04 AM 9/1/2004 = -0700, Bob=20 O'Hara wrote:


I think the difference can be summed up = like=20 this:

The protocol between an AC and the Local MAC and the = Split=20 MAC is
semantically identical.  Each uses a different = syntax for=20 this protocol.

-Bob

-----Original = Message-----
From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m]=20 On Behalf
Of Pat R. Calhoun
Sent: Wednesday, September 01, = 2004 6:32=20 AM
To: Chunduru Rama Krishna Prasad; = capwap@frascone.com
Subject:=20 RE: [Capwap] Local MAC

Great question.

As you = observed=20 below, the primary difference (from what I can tell) = between
split and=20 local MAC is that while the former simply sends the=20 frames
untouched
the latter reformulates the 802.11 messages = into=20 another format before
sending
them to the AC. So sure the = PDUs look=20 different, but in reality they are not
really
that = different,=20 right?

I mean what's the difference between sending a = straight=20 association request
to the
AC vs. breaking the association = request=20 down into small components and using
the
resulting = information to=20 create a message to be sent to the AC?

One could easily = argue that=20 using the straight association request will
ensure=20 forward
compatibility with any new IEEE 802.11 related = standard. Let's=20 use 802.11k
for instance,
there are some new extensions that = are=20 added to existing MAC mgmt frames. So
while
a protocol that = simply=20 forwards the MAC mgmt frames to the AC will be able
to=20 handle
802.11k transparently, the other approach would require = that the=20 IETF WG get
together
and define a way to map the new 802.11k = extensions into whatever protocol
was created.
Clearly, we = cannot=20 afford to have the IETF's protocol lag behind = IEEE
standards.

On=20 the data path, what is the difference between sending the straight = 802.11
frame
vs. sending an 802.3 frame with some associated = control=20 information that was
derived
from the 802.11 frame to begin = with?=20 What happens when protocols like
802.11e change
the actual = format of=20 the frame by inserting 2 bytes in the protocol header?
Sending=20 the
straight 802.11 frame to the AC ensures that whatever = solution=20 we've come up
with will
be able to support these future = extensions,=20 while a protocol that breaks
down the PDU
into an 802.3 = frame will=20 cause these extensions to be lost.

It's really not like=20 understanding the 802.11 protocol is a complex thing -
there=20 are
plenty of implementations of 802.11 based products, and = some of=20 these are
even available
as open source. So I would argue = that=20 parsing 802.11 packets is much simpler
than 802.3
with some = control=20 information since those stacks are publicly=20 = available.

PatC


________________________________
From:=20 capwap-admin@frascone.com on behalf of Chunduru Rama Krishna=20 Prasad
Sent: Tue 8/31/2004 10:52 PM
To:=20 capwap@frascone.com
Subject: [Capwap] Local MAC

Hi=20 ,

Please correct if my interpretation of LOCAL MAC is = wrong.
WTP=20 terminates 802.11 control packets and nothing is sent to AC = .
WTP=20 terminates 802.11 mangement frames and corresponding events are = sent=20 to
AC.
WTP terminates 802.11 data frames, does = decryption/encryption=20 based on
unique keys correspond to wireless stations, extracts = 802.3=20 packet from the
frame and send the frame across to AC. If = needed, it=20 might also send
some control information along with each 802.3=20 packet.
In this case, AC does not have knowledge of 802.11 = header. It=20 only needs
knowledge of
CAPWAP protocol, 802.1x termination, = specific wireless related parameters.

What makes it split = MAC? My=20 understanding is that, if AC terminates 802.11
frames = and
does=20 encyption/decryption and has knowledge of 802.11 frames, then it=20 is
Split MAC.
Is this understanding = correct?

Thanks
Rama=20 Krishna



Ch. Rama Krishna Prasad
Intoto = Software(I) Pvt=20 Ltd,
Uma Plaza, Nagarjuna circle,
Panjagutta. Hyderabad, = AP
Tel=20 No:s  2335=20 = 8927/8928/8434

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

Ch.=20 Rama Krishna Prasad
Intoto Software(I) Pvt Ltd,
Uma Plaza, = Nagarjuna=20 circle,
Panjagutta. Hyderabad, AP
Tel No:s  2335=20 = 8927/8928/8434




------=_NextPart_000_0081_01C493FF.8C05CB30-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sun Sep 5 22:54: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 WAA10733 for ; Sun, 5 Sep 2004 22:54:12 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 44CD7219A6; Sun, 5 Sep 2004 22:38:23 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 55056219A7; Sun, 5 Sep 2004 22:38:16 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E3B4C21990 for ; Sun, 5 Sep 2004 22:37:36 -0400 (EDT) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id 9CCE72199C for ; Sun, 5 Sep 2004 22:37:32 -0400 (EDT) Received: from Palpatine ([10.81.113.73]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id i862nxPu019809; Mon, 6 Sep 2004 10:50:08 +0800 (SGT) From: "Cheng Hong" To: "'Shehzad Merchant'" , "'Paul Lambert'" , "'Pat R. Calhoun'" , "'James Kempf'" , "'Chunduru Rama Krishna Prasad'" , "'Bob O'Hara'" , Cc: "'Saravanan Govindan'" Subject: RE: [Capwap] Local MAC Organization: Panasonic Singapore Laboratories Message-ID: <008501c493bc$8ba35b50$4971510a@Palpatine> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0086_01C493FF.99C69B50" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <1B8A2DD33C49824F8D9021678C127213028DC8CF@sc-msexch-04.extremenetworks.com> 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: Mon, 6 Sep 2004 10:52:17 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------=_NextPart_000_0086_01C493FF.99C69B50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't object the idea of mandate or specifying the functionality set, = but I don't think the group should "pick a single perferred implementation approach"=20 =20 Whether we need to specify a minimum set of functions for WTP and AC is another issue. This depends on the objective we set for the CAPWAP. If = we set the target as: any WTP and AC with a CAPWAP lebel should be able to = work happily together and provide service, then the minimum functions should = be set. If the target is to provide a protocol for a WTP and AC to work together if they can, the minimum function required would be for the negotiation and function discovery. =20 Even for the first case, a negotiation function is necessary, since WTP = and AC could provide redundent functions, and they need to negotiate who to excute which part. =20 cheers =20 Cheng -----Original Message----- From: Shehzad Merchant [mailto:smerchant@extremenetworks.com]=20 Sent: Saturday, September 04, 2004 2:08 AM To: Cheng Hong; 'Paul Lambert'; 'Pat R. Calhoun'; 'James Kempf'; = 'Chunduru Rama Krishna Prasad'; 'Bob O'Hara'; capwap@frascone.com Subject: RE: [Capwap] Local MAC If you want to guarantee interoperability i.e. take WTP from vendor X, = plug it into a network that has an AC from vendor Y and expect it to just = work, I don't see how you can get there without a minimum set of functionality = that is mandated and specified, both on the control/management plane as well = as data plane. (there can always be capabilities beyond the minimum set = that are optional and negotiable).=20 =20 I do agree that the mechanisms for control/management do not necessarily have to be the same as data plane i.e. one could specify the control/management protocol independently from the data plane, but I = think to achieve full interoperability, a minimum set of both need to be specified. =20 -S =20 _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Cheng Hong Sent: Friday, September 03, 2004 12:18 AM To: 'Paul Lambert'; 'Pat R. Calhoun'; 'James Kempf'; 'Chunduru Rama = Krishna Prasad'; 'Bob O'Hara'; capwap@frascone.com Subject: RE: [Capwap] Local MAC CAPWAP is not about how that is implemented. The protocol only needs to = be generic to support different implementations choices and provides negotiation methods. I don't think the group has to mandate a "single approach" of implementation. =20 cheers =20 Cheng=20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Paul Lambert Sent: Friday, September 03, 2004 5:23 AM To: Pat R. Calhoun; James Kempf; Chunduru Rama Krishna Prasad; Bob = O'Hara; capwap@frascone.com Subject: RE: [Capwap] Local MAC >I'd suggest negotiation =20 Even with negotiation, to ensure interoperability there must be a = mandated set of capabilites. So, the working group will still have to pick a = single perferred implementation approach. =20 Paul _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Pat R. Calhoun Sent: Thursday, September 02, 2004 1:27 PM To: James Kempf; Chunduru Rama Krishna Prasad; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Local MAC I'd suggest negotiation PatC -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Thu 9/2/2004 8:30 AM To: Pat R. Calhoun; Chunduru Rama Krishna Prasad; Bob O'Hara; capwap@frascone.com Subject: Re: [Capwap] Local MAC But for purposes of interoperability (i.e. being able to mix and match = WTPs and ACs between vendors), doesn't this need to be specified? The = standard could either specify where encyption/decryption is done, or it could = allow for some type of negotiation when the WTP and AC first make contact and connect up. jak ----- Original Message ----- From: "Pat R. Calhoun" To: "Chunduru Rama Krishna Prasad" ; "Bob O'Hara" ; Sent: Thursday, September 02, 2004 5:50 AM Subject: RE: [Capwap] Local MAC I know of one implementation that decrypts in the WTP and another that decrypts in the AC. There is no definition of where this function occurs = in split MAC (or if there is it should say "may occur either in the WTP or = in the AC" :) PatC ________________________________ From: Chunduru Rama Krishna Prasad [mailto:rkp@intoto.com] Sent: Wed 9/1/2004 9:30 PM To: Bob O'Hara; Pat R. Calhoun; capwap@frascone.com Subject: RE: [Capwap] Local MAC What about encryption/decryption of 802.11 packets? In Local MAC, as I understand clearly that it is done at the WTP. And I think, that is good thing to do. Does split MAC definition allow this operation at WTPs? Thanks Rama Krishna At 10:04 AM 9/1/2004 -0700, Bob O'Hara wrote: I think the difference can be summed up like this: The protocol between an AC and the Local MAC and the Split MAC is semantically identical. Each uses a different syntax for this protocol. -Bob -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Pat R. Calhoun Sent: Wednesday, September 01, 2004 6:32 AM To: Chunduru Rama Krishna Prasad; capwap@frascone.com Subject: RE: [Capwap] Local MAC Great question. As you observed below, the primary difference (from what I can tell) = between split and local MAC is that while the former simply sends the frames untouched the latter reformulates the 802.11 messages into another format before sending them to the AC. So sure the PDUs look different, but in reality they are = not really that different, right? I mean what's the difference between sending a straight association = request to the AC vs. breaking the association request down into small components and = using the resulting information to create a message to be sent to the AC? One could easily argue that using the straight association request will ensure forward compatibility with any new IEEE 802.11 related standard. Let's use = 802.11k for instance, there are some new extensions that are added to existing MAC mgmt = frames. So while a protocol that simply forwards the MAC mgmt frames to the AC will be = able to handle 802.11k transparently, the other approach would require that the IETF WG = get together and define a way to map the new 802.11k extensions into whatever = protocol was created. Clearly, we cannot afford to have the IETF's protocol lag behind IEEE standards. On the data path, what is the difference between sending the straight = 802.11 frame vs. sending an 802.3 frame with some associated control information that = was derived from the 802.11 frame to begin with? What happens when protocols like 802.11e change the actual format of the frame by inserting 2 bytes in the protocol = header? Sending the straight 802.11 frame to the AC ensures that whatever solution we've = come up with will be able to support these future extensions, while a protocol that breaks down the PDU into an 802.3 frame will cause these extensions to be lost. It's really not like understanding the 802.11 protocol is a complex = thing - there are plenty of implementations of 802.11 based products, and some of these = are even available as open source. So I would argue that parsing 802.11 packets is much = simpler than 802.3 with some control information since those stacks are publicly available. PatC ________________________________ From: capwap-admin@frascone.com on behalf of Chunduru Rama Krishna = Prasad Sent: Tue 8/31/2004 10:52 PM To: capwap@frascone.com Subject: [Capwap] Local MAC Hi , Please correct if my interpretation of LOCAL MAC is wrong. WTP terminates 802.11 control packets and nothing is sent to AC . WTP terminates 802.11 mangement frames and corresponding events are sent = to AC. WTP terminates 802.11 data frames, does decryption/encryption based on unique keys correspond to wireless stations, extracts 802.3 packet from = the frame and send the frame across to AC. If needed, it might also send some control information along with each 802.3 packet. In this case, AC does not have knowledge of 802.11 header. It only needs knowledge of CAPWAP protocol, 802.1x termination, specific wireless related = parameters. What makes it split MAC? My understanding is that, if AC terminates = 802.11 frames and does encyption/decryption and has knowledge of 802.11 frames, then it is Split MAC. Is this understanding correct? Thanks Rama Krishna Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 ------=_NextPart_000_0086_01C493FF.99C69B50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I=20 don't object the idea of mandate or specifying the functionality set, = but I=20 don't think the group should "pick a=20 single perferred implementation approach"
 
Whether we need to = specify a=20 minimum set of functions for WTP and AC is another issue. This depends = on the=20 objective we set for the CAPWAP. If we set the target as: any WTP and AC = with=20 a CAPWAP lebel should be able to work happily  together and = provide=20 service, then the minimum functions should be set. If the target is to = provide a=20 protocol for a WTP and AC to work together if they can, the minimum = function=20 required would be for the negotiation and function=20 discovery.
 
Even for the first = case, a=20 negotiation function is necessary, since WTP and AC could provide = redundent=20 functions, and they need to negotiate who to excute which=20 part.
 
cheers
 
Cheng
-----Original Message-----
From: = Shehzad Merchant=20 [mailto:smerchant@extremenetworks.com]
Sent: Saturday, = September=20 04, 2004 2:08 AM
To: Cheng Hong; 'Paul Lambert'; 'Pat R. = Calhoun';=20 'James Kempf'; 'Chunduru Rama Krishna Prasad'; 'Bob O'Hara';=20 capwap@frascone.com
Subject: RE: [Capwap] Local=20 MAC

If you want to guarantee interoperability = i.e. take WTP=20 from vendor X, plug it into a network that has an AC from vendor Y and = expect=20 it to just work, I don't see how you can get there without a minimum = set of=20 functionality that is mandated and specified, both on the = control/management=20 plane as well as data plane. (there can always be capabilities beyond = the=20 minimum set that are optional and negotiable). =
 
I do agree that the mechanisms for = control/management do=20 not necessarily have to be the same as data plane i.e. one could = specify=20 the control/management protocol independently from the data plane, but = I think=20 to achieve full interoperability, a minimum set of both need to be=20 specified.
 
-S
 

From: capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Cheng=20 Hong
Sent: Friday, September 03, 2004 12:18 AM
To: = 'Paul=20 Lambert'; 'Pat R. Calhoun'; 'James Kempf'; 'Chunduru Rama Krishna = Prasad';=20 'Bob O'Hara'; capwap@frascone.com
Subject: RE: [Capwap] = Local=20 MAC

CAPWAP is not about how that is implemented. The protocol = only needs to=20 be generic to support different implementations choices and provides=20 negotiation methods. I don't think the group has to mandate a "single=20 approach" of implementation.
 
cheers
 
Cheng
-----Original Message-----
From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of=20 Paul Lambert
Sent: Friday, September 03, 2004 5:23=20 AM
To: Pat R. Calhoun; James Kempf; Chunduru Rama Krishna = Prasad;=20 Bob O'Hara; capwap@frascone.com
Subject: RE: [Capwap] = Local=20 MAC

>I'd=20 suggest negotiation
 
Even=20 with negotiation, to ensure interoperability there must be a = mandated set of=20 capabilites.  So, the working group will still have = to pick a=20 single perferred implementation approach.
 
Paul

From: = capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Pat R.=20 Calhoun
Sent: Thursday, September 02, 2004 1:27 = PM
To:=20 James Kempf; Chunduru Rama Krishna Prasad; Bob O'Hara;=20 capwap@frascone.com
Subject: RE: [Capwap] Local=20 MAC

I'd suggest=20 negotiation

PatC


-----Original = Message-----
From:=20 James Kempf [mailto:kempf@docomolabs-usa.com<= /A>]
Sent:=20 Thu 9/2/2004 8:30 AM
To: Pat R. Calhoun; Chunduru Rama Krishna = Prasad;=20 Bob O'Hara; capwap@frascone.com
Subject: Re: [Capwap] Local=20 MAC

But for purposes of interoperability (i.e. being able = to mix=20 and match WTPs
and ACs between vendors), doesn't this need to = be=20 specified? The standard
could either specify where = encyption/decryption=20 is done, or it could allow
for some type of negotiation when = the WTP=20 and AC first make contact and
connect=20 = up.

          &n= bsp;    =20 jak

----- Original Message -----
From: "Pat R. Calhoun"=20 <pcalhoun@airespace.com>
To: "Chunduru Rama Krishna = Prasad"=20 <rkp@intoto.com>; "Bob O'Hara"
<bob@airespace.com>; = <capwap@frascone.com>
Sent: Thursday, September 02, 2004 = 5:50=20 AM
Subject: RE: [Capwap] Local MAC


I know of one=20 implementation that decrypts in the WTP and another = that
decrypts in=20 the AC. There is no definition of where this function occurs = in
split=20 MAC (or if there is it should say "may occur either in the WTP or=20 in
the AC"=20 = :)

PatC

________________________________

From:=20 Chunduru Rama Krishna Prasad [mailto:rkp@intoto.com]
Sent: = Wed=20 9/1/2004 9:30 PM
To: Bob O'Hara; Pat R. Calhoun;=20 capwap@frascone.com
Subject: RE: [Capwap] Local = MAC



What=20 about encryption/decryption of 802.11 packets? In Local MAC, as=20 I
understand clearly that
it is done at the WTP. And I = think, that=20 is good thing to do.
Does split MAC definition allow this = operation at=20 WTPs?

Thanks
Rama Krishna

At 10:04 AM 9/1/2004 = -0700, Bob=20 O'Hara wrote:


I think the difference can be summed up = like=20 this:

The protocol between an AC and the Local MAC and the = Split=20 MAC is
semantically identical.  Each uses a different = syntax for=20 this protocol.

-Bob

-----Original = Message-----
From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m]=20 On Behalf
Of Pat R. Calhoun
Sent: Wednesday, September 01, = 2004 6:32=20 AM
To: Chunduru Rama Krishna Prasad; = capwap@frascone.com
Subject:=20 RE: [Capwap] Local MAC

Great question.

As you = observed=20 below, the primary difference (from what I can tell) = between
split and=20 local MAC is that while the former simply sends the=20 frames
untouched
the latter reformulates the 802.11 messages = into=20 another format before
sending
them to the AC. So sure the = PDUs look=20 different, but in reality they are not
really
that = different,=20 right?

I mean what's the difference between sending a = straight=20 association request
to the
AC vs. breaking the association = request=20 down into small components and using
the
resulting = information to=20 create a message to be sent to the AC?

One could easily = argue that=20 using the straight association request will
ensure=20 forward
compatibility with any new IEEE 802.11 related = standard. Let's=20 use 802.11k
for instance,
there are some new extensions that = are=20 added to existing MAC mgmt frames. So
while
a protocol that = simply=20 forwards the MAC mgmt frames to the AC will be able
to=20 handle
802.11k transparently, the other approach would require = that the=20 IETF WG get
together
and define a way to map the new 802.11k = extensions into whatever protocol
was created.
Clearly, we = cannot=20 afford to have the IETF's protocol lag behind = IEEE
standards.

On=20 the data path, what is the difference between sending the straight = 802.11
frame
vs. sending an 802.3 frame with some associated = control=20 information that was
derived
from the 802.11 frame to begin = with?=20 What happens when protocols like
802.11e change
the actual = format of=20 the frame by inserting 2 bytes in the protocol header?
Sending=20 the
straight 802.11 frame to the AC ensures that whatever = solution=20 we've come up
with will
be able to support these future = extensions,=20 while a protocol that breaks
down the PDU
into an 802.3 = frame will=20 cause these extensions to be lost.

It's really not like=20 understanding the 802.11 protocol is a complex thing -
there=20 are
plenty of implementations of 802.11 based products, and = some of=20 these are
even available
as open source. So I would argue = that=20 parsing 802.11 packets is much simpler
than 802.3
with some = control=20 information since those stacks are publicly=20 = available.

PatC


________________________________
From:=20 capwap-admin@frascone.com on behalf of Chunduru Rama Krishna=20 Prasad
Sent: Tue 8/31/2004 10:52 PM
To:=20 capwap@frascone.com
Subject: [Capwap] Local MAC

Hi=20 ,

Please correct if my interpretation of LOCAL MAC is = wrong.
WTP=20 terminates 802.11 control packets and nothing is sent to AC = .
WTP=20 terminates 802.11 mangement frames and corresponding events are = sent=20 to
AC.
WTP terminates 802.11 data frames, does = decryption/encryption=20 based on
unique keys correspond to wireless stations, extracts = 802.3=20 packet from the
frame and send the frame across to AC. If = needed, it=20 might also send
some control information along with each 802.3=20 packet.
In this case, AC does not have knowledge of 802.11 = header. It=20 only needs
knowledge of
CAPWAP protocol, 802.1x termination, = specific wireless related parameters.

What makes it split = MAC? My=20 understanding is that, if AC terminates 802.11
frames = and
does=20 encyption/decryption and has knowledge of 802.11 frames, then it=20 is
Split MAC.
Is this understanding = correct?

Thanks
Rama=20 Krishna



Ch. Rama Krishna Prasad
Intoto = Software(I) Pvt=20 Ltd,
Uma Plaza, Nagarjuna circle,
Panjagutta. Hyderabad, = AP
Tel=20 No:s  2335=20 = 8927/8928/8434

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

Ch.=20 Rama Krishna Prasad
Intoto Software(I) Pvt Ltd,
Uma Plaza, = Nagarjuna=20 circle,
Panjagutta. Hyderabad, AP
Tel No:s  2335=20 = 8927/8928/8434




------=_NextPart_000_0086_01C493FF.99C69B50-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sun Sep 5 23: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 XAA11928 for ; Sun, 5 Sep 2004 23:17:33 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1EF1E1FEA8; Sun, 5 Sep 2004 23:02:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B465420383; Sun, 5 Sep 2004 23:02:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F344B20383 for ; Sun, 5 Sep 2004 23:01:28 -0400 (EDT) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id 0C4AD1FEA8 for ; Sun, 5 Sep 2004 23:01:26 -0400 (EDT) Received: from Saravanan ([10.81.113.32]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id i863E9IA020969; Mon, 6 Sep 2004 11:14:09 +0800 (SGT) Message-Id: <200409060314.i863E9IA020969@mailsrv.psl.com.sg> From: "Saravanan Govindan" To: "'Bob O'Hara'" , , Cc: "Cheng Hong" Subject: RE: [Capwap] Update to problem statement 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 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSRG17jPp6uTltUQGuKqOxR/Es9ngAG58hQAKEgDGA= 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, 6 Sep 2004 11:16:25 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit A few points on the draft; 1. In Section 2 (Problem Statement), the last sentence of the last paragraph ('The Functional architecture...') mentions a 'newly appearing hierarchical architecture'. Am I right in that this refers to an architecture where an AC controls a number of APs? Maybe some clarification would be useful. For example, 'hierarchical architecture' can be explicitly introduced in the paragraph on multiple vendor solutions (paragraph 5, 'Recently, multiple vendors...') 2. In Section 3 (Security Considerations), the second sentence of the third paragraph ('If high-value secrets....') seems to suggest only way of reducing the consequences of a stolen AP. There must also be ways of keeping secrets safe on the AP itself. So I think this design recommendation can be left for the ojbectives phase where it can be discussed further. Cheers Saravanan > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Mani, > Mahalingam (Mahalingam) > Sent: Friday, September 03, 2004 5:58 AM > To: Bob O'Hara; capwap@frascone.com > Subject: RE: [Capwap] Update to problem statement > Importance: High > > > All: > > Do take a look at the changes made and send any comments you > may have to the list for authors to consider. > > As stated the current changes have incorporated observations > from IESG review (the comment details & dispositions of which > can be viewed at > > https://datatracker.ietf.org/public/pidtracker.cgi?command=vie > w_id&dTag= > 11362&rfc_flag=0 > > ) > > Regards, > -mani > Mahalingam Mani > mmani@avaya.com > +1 408.321.4840 (w) > +1 408.396.2760 (m) > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Bob O'Hara > Sent: Thursday, September 02, 2004 11:34 AM > To: capwap@frascone.com > Subject: [Capwap] Update to problem statement > > In response to comments from the IESG, I have updated the > problem statement. It is attached for your review and > comment. If I have not received any substantive comments by > Monday, I will submit it to the IETF repository. Please > comment to the list. > > There are some editorial changes and two new paragraphs in > the Security Considerations section. > > -Bob > > Bob O'Hara > Director of System Engineering, Founder > Airespace, Inc. > 110 Nortech Parkway > San Jose, CA 95134-2307 > > Phone: +1 408 635 2025 > Mobile: +1 408 218 4025 > Fax: +1 408 635 2020 > email: bob@airespace.com > http://my.infotriever.com/to6ul4jo > > > > _______________________________________________ > Capwap mailing 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 Sep 7 01:13: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 BAA02532 for ; Tue, 7 Sep 2004 01:13:39 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C582D20E1B; Tue, 7 Sep 2004 00:58:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6DFF32106E; Tue, 7 Sep 2004 00:58:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5C66E2106E for ; Tue, 7 Sep 2004 00:58:01 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id 9E7B520E1B for ; Tue, 7 Sep 2004 00:57:59 -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 i875BnmF005908 for ; Tue, 7 Sep 2004 01:11:49 -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 i875BlmF005897 for ; Tue, 7 Sep 2004 01:11:48 -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] Update to problem statement Message-ID: Thread-Topic: [Capwap] Update to problem statement Thread-Index: AcSRG17jPp6uTltUQGuKqOxR/Es9ngAG58hQAKEgDGAAND+n8A== From: "Mani, Mahalingam (Mahalingam)" To: "Saravanan Govindan" , "Bob O'Hara" , Cc: "Cheng Hong" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 6 Sep 2004 23:13:25 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Saravanan, See inline. -----Original Message----- From: Saravanan Govindan [mailto:sgovindan@psl.com.sg]=20 Sent: Sunday, September 05, 2004 8:16 PM To: 'Bob O'Hara'; capwap@frascone.com; Mani, Mahalingam (Mahalingam) Cc: Cheng Hong Subject: RE: [Capwap] Update to problem statement A few points on the draft; 1. In Section 2 (Problem Statement), the last sentence of the last paragraph ('The Functional architecture...') mentions a 'newly appearing hierarchical architecture'. Am I right in that this refers to an architecture where an AC controls a number of APs? Maybe some clarification would be useful. For example, 'hierarchical architecture' can be explicitly introduced in the paragraph on multiple vendor solutions (paragraph 5, 'Recently, multiple vendors...') [Mani, Mahalingam (Mahalingam)] this section has not changed since -01 draft and still stands valid as is. The request for review is only for the delta between -01 and -02. 2. In Section 3 (Security Considerations), the second sentence of the third paragraph ('If high-value secrets....') seems to suggest only way of reducing the consequences of a stolen AP. There must also be ways of keeping secrets safe on the AP itself. So I think this design recommendation can be left for the ojbectives phase where it can be discussed further. [Mani, Mahalingam (Mahalingam)] the point is not about the mechanisms to secure secrets in AP; the section asserts that since the secret(s) consolidated/accumulated at the AC makes the AC more sensitive (accounting for multiple APs) compromise of one AC can lead to a greater compromise. Hence there needs to be an appropriately higher physical assurance of AC. The section's assertion is agnostic to the method of securing secrets inside an AP. =20 Cheers Saravanan [Mani, Mahalingam (Mahalingam)] -mani > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of Mani,=20 > Mahalingam (Mahalingam) > Sent: Friday, September 03, 2004 5:58 AM > To: Bob O'Hara; capwap@frascone.com > Subject: RE: [Capwap] Update to problem statement > Importance: High >=20 >=20 > All: >=20 > Do take a look at the changes made and send any comments you=20 > may have to the list for authors to consider. >=20 > As stated the current changes have incorporated observations=20 > from IESG review (the comment details & dispositions of which=20 > can be viewed at >=20 > https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dvie > w_id&dTag=3D > 11362&rfc_flag=3D0 >=20 > ) >=20 > Regards, > -mani > Mahalingam Mani > mmani@avaya.com > +1 408.321.4840 (w) > +1 408.396.2760 (m) > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of Bob O'Hara > Sent: Thursday, September 02, 2004 11:34 AM > To: capwap@frascone.com > Subject: [Capwap] Update to problem statement >=20 > In response to comments from the IESG, I have updated the=20 > problem statement. It is attached for your review and=20 > comment. If I have not received any substantive comments by=20 > Monday, I will submit it to the IETF repository. Please=20 > comment to the list. >=20 > There are some editorial changes and two new paragraphs in=20 > the Security Considerations section. >=20 > -Bob >=20 > Bob O'Hara > Director of System Engineering, Founder > Airespace, Inc. > 110 Nortech Parkway > San Jose, CA 95134-2307 >=20 > Phone: +1 408 635 2025 > Mobile: +1 408 218 4025 > Fax: +1 408 635 2020 > email: bob@airespace.com > http://my.infotriever.com/to6ul4jo > =20 >=20 >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 7 12:39:38 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 MAA06466 for ; Tue, 7 Sep 2004 12:39:37 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 24D5921573; Tue, 7 Sep 2004 12:24:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 788A821C29; Tue, 7 Sep 2004 12: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 BDB1321C2B for ; Tue, 7 Sep 2004 12:23:30 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 7FF0821573 for ; Tue, 7 Sep 2004 12:23:28 -0400 (EDT) Message-ID: <008a01c494f9$49f5a760$536115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Cheng Hong" , "'Shehzad Merchant'" , "'Paul Lambert'" , "'Pat R. Calhoun'" , "'Chunduru Rama Krishna Prasad'" , "'Bob O'Hara'" , Cc: "'Saravanan Govindan'" References: <008001c493bc$7de28b30$4971510a@Palpatine> Subject: CAPWAP tunneling and interoperability (was: Re: [Capwap] Local MAC) 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, 7 Sep 2004 09:39:45 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit My goal for CAPWAP is that I can buy a WTP from one vendor and a AC from another, connect them together, and have them work together with no configuration. Hopefully, this basic goal (complete interoperability) is shared by others. How to achieve this from a technical standpoint is what is at issue. On the one hand, one could specify a particular set of tunneling functionality (or the absence thereof) and limit it to that. On the other, one could specify a negotiation protocol so that the WTP and AC can negotiate a tunneling protocol dynamically (or the absence thereof). In either case, the standard must specify a minimum set of "required to implement" tunneling functionality (or absence thereof). The difference is that, in the first case, the functionality is limited to one choice, whereas in the second, it is limited to a few. Whether or not the second choice allows more tunneling options to be added beyond the minimum "required to implement" is a separate issue, and depends on whether the CAPWAP protocol provides extensibility for tunneling functionality. For example, the protocol could specify a few tunneling options ( for example: none, GRE, ESP) and not allow any further extensibility. Since vendors currently take different approaches about how to do data plane transport from the WTP to the AC, I think it may be hard, from a politicial standpoint, to achieve concensus on this issue. Perhaps someone could enumerate the current approaches? I don't recall having seen that in the architecture document. jak ----- Original Message ----- From: "Cheng Hong" To: "'Shehzad Merchant'" ; "'Paul Lambert'" ; "'Pat R. Calhoun'" ; "'James Kempf'" ; "'Chunduru Rama Krishna Prasad'" ; "'Bob O'Hara'" ; Cc: "'Saravanan Govindan'" Sent: Sunday, September 05, 2004 7:51 PM Subject: RE: [Capwap] Local MAC I don't object the idea of mandate or specifying the functionality set, but I don't think the group should "pick a single perferred implementation approach" Whether we need to specify a minimum set of functions for WTP and AC is another issue. This depends on the objective we set for the CAPWAP. If we set the target as: any WTP and AC with a CAPWAP lebel should be able to work happily together and provide service, then the minimum functions should be set. If the target is to provide a protocol for a WTP and AC to work together if they can, the minimum function required would be for the negotiation and function discovery. Even for the first case, a negotiation function is necessary, since WTP and AC could provide redundent functions, and they need to negotiate who to excute which part. cheers Cheng -----Original Message----- From: Shehzad Merchant [mailto:smerchant@extremenetworks.com] Sent: Saturday, September 04, 2004 2:08 AM To: Cheng Hong; 'Paul Lambert'; 'Pat R. Calhoun'; 'James Kempf'; 'Chunduru Rama Krishna Prasad'; 'Bob O'Hara'; capwap@frascone.com Subject: RE: [Capwap] Local MAC If you want to guarantee interoperability i.e. take WTP from vendor X, plug it into a network that has an AC from vendor Y and expect it to just work, I don't see how you can get there without a minimum set of functionality that is mandated and specified, both on the control/management plane as well as data plane. (there can always be capabilities beyond the minimum set that are optional and negotiable). I do agree that the mechanisms for control/management do not necessarily have to be the same as data plane i.e. one could specify the control/management protocol independently from the data plane, but I think to achieve full interoperability, a minimum set of both need to be specified. -S _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Cheng Hong Sent: Friday, September 03, 2004 12:18 AM To: 'Paul Lambert'; 'Pat R. Calhoun'; 'James Kempf'; 'Chunduru Rama Krishna Prasad'; 'Bob O'Hara'; capwap@frascone.com Subject: RE: [Capwap] Local MAC CAPWAP is not about how that is implemented. The protocol only needs to be generic to support different implementations choices and provides negotiation methods. I don't think the group has to mandate a "single approach" of implementation. cheers Cheng -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Paul Lambert Sent: Friday, September 03, 2004 5:23 AM To: Pat R. Calhoun; James Kempf; Chunduru Rama Krishna Prasad; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Local MAC >I'd suggest negotiation Even with negotiation, to ensure interoperability there must be a mandated set of capabilites. So, the working group will still have to pick a single perferred implementation approach. Paul _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun Sent: Thursday, September 02, 2004 1:27 PM To: James Kempf; Chunduru Rama Krishna Prasad; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Local MAC I'd suggest negotiation PatC -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Thu 9/2/2004 8:30 AM To: Pat R. Calhoun; Chunduru Rama Krishna Prasad; Bob O'Hara; capwap@frascone.com Subject: Re: [Capwap] Local MAC But for purposes of interoperability (i.e. being able to mix and match WTPs and ACs between vendors), doesn't this need to be specified? The standard could either specify where encyption/decryption is done, or it could allow for some type of negotiation when the WTP and AC first make contact and connect up. jak ----- Original Message ----- From: "Pat R. Calhoun" To: "Chunduru Rama Krishna Prasad" ; "Bob O'Hara" ; Sent: Thursday, September 02, 2004 5:50 AM Subject: RE: [Capwap] Local MAC I know of one implementation that decrypts in the WTP and another that decrypts in the AC. There is no definition of where this function occurs in split MAC (or if there is it should say "may occur either in the WTP or in the AC" :) PatC ________________________________ From: Chunduru Rama Krishna Prasad [mailto:rkp@intoto.com] Sent: Wed 9/1/2004 9:30 PM To: Bob O'Hara; Pat R. Calhoun; capwap@frascone.com Subject: RE: [Capwap] Local MAC What about encryption/decryption of 802.11 packets? In Local MAC, as I understand clearly that it is done at the WTP. And I think, that is good thing to do. Does split MAC definition allow this operation at WTPs? Thanks Rama Krishna At 10:04 AM 9/1/2004 -0700, Bob O'Hara wrote: I think the difference can be summed up like this: The protocol between an AC and the Local MAC and the Split MAC is semantically identical. Each uses a different syntax for this protocol. -Bob -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun Sent: Wednesday, September 01, 2004 6:32 AM To: Chunduru Rama Krishna Prasad; capwap@frascone.com Subject: RE: [Capwap] Local MAC Great question. As you observed below, the primary difference (from what I can tell) between split and local MAC is that while the former simply sends the frames untouched the latter reformulates the 802.11 messages into another format before sending them to the AC. So sure the PDUs look different, but in reality they are not really that different, right? I mean what's the difference between sending a straight association request to the AC vs. breaking the association request down into small components and using the resulting information to create a message to be sent to the AC? One could easily argue that using the straight association request will ensure forward compatibility with any new IEEE 802.11 related standard. Let's use 802.11k for instance, there are some new extensions that are added to existing MAC mgmt frames. So while a protocol that simply forwards the MAC mgmt frames to the AC will be able to handle 802.11k transparently, the other approach would require that the IETF WG get together and define a way to map the new 802.11k extensions into whatever protocol was created. Clearly, we cannot afford to have the IETF's protocol lag behind IEEE standards. On the data path, what is the difference between sending the straight 802.11 frame vs. sending an 802.3 frame with some associated control information that was derived from the 802.11 frame to begin with? What happens when protocols like 802.11e change the actual format of the frame by inserting 2 bytes in the protocol header? Sending the straight 802.11 frame to the AC ensures that whatever solution we've come up with will be able to support these future extensions, while a protocol that breaks down the PDU into an 802.3 frame will cause these extensions to be lost. It's really not like understanding the 802.11 protocol is a complex thing - there are plenty of implementations of 802.11 based products, and some of these are even available as open source. So I would argue that parsing 802.11 packets is much simpler than 802.3 with some control information since those stacks are publicly available. PatC ________________________________ From: capwap-admin@frascone.com on behalf of Chunduru Rama Krishna Prasad Sent: Tue 8/31/2004 10:52 PM To: capwap@frascone.com Subject: [Capwap] Local MAC Hi , Please correct if my interpretation of LOCAL MAC is wrong. WTP terminates 802.11 control packets and nothing is sent to AC . WTP terminates 802.11 mangement frames and corresponding events are sent to AC. WTP terminates 802.11 data frames, does decryption/encryption based on unique keys correspond to wireless stations, extracts 802.3 packet from the frame and send the frame across to AC. If needed, it might also send some control information along with each 802.3 packet. In this case, AC does not have knowledge of 802.11 header. It only needs knowledge of CAPWAP protocol, 802.1x termination, specific wireless related parameters. What makes it split MAC? My understanding is that, if AC terminates 802.11 frames and does encyption/decryption and has knowledge of 802.11 frames, then it is Split MAC. Is this understanding correct? Thanks Rama Krishna Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 8 15:36: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 PAA09839 for ; Wed, 8 Sep 2004 15:36:39 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 80A6C216EF; Wed, 8 Sep 2004 15:21:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1F65120E57; Wed, 8 Sep 2004 15:21:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 36C032133D for ; Wed, 8 Sep 2004 15:20:21 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.frascone.com (Postfix) with ESMTP id DE972208E5 for ; Wed, 8 Sep 2004 15:20:17 -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 PAA09691; Wed, 8 Sep 2004 15:35:46 -0400 (EDT) Message-Id: <200409081935.PAA09691@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-problem-statement-02.txt Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 08 Sep 2004 15:35:46 -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 : CAPWAP Problem Statement Author(s) : P. Calhoun, et al. Filename : draft-ietf-capwap-problem-statement-02.txt Pages : 9 Date : 2004-9-8 This document describes the Configuration and Provisioning for Wireless Access Points (CAPWAP) problem statement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-capwap-problem-statement-02.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-problem-statement-02.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-problem-statement-02.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-9-8154243.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-capwap-problem-statement-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-capwap-problem-statement-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-8154243.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Sep 9 16:18: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 QAA21936 for ; Thu, 9 Sep 2004 16:18:35 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CB0C6212D5; Thu, 9 Sep 2004 16:17:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6335D212EB; Thu, 9 Sep 2004 16:17:05 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A4DBE21C17 for ; Thu, 9 Sep 2004 16:15:41 -0400 (EDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by mail.frascone.com (Postfix) with ESMTP id 6FF1720825 for ; Thu, 9 Sep 2004 16:15:39 -0400 (EDT) Received: by mproxy.gmail.com with SMTP id 77so80520rnk for ; Thu, 09 Sep 2004 13:15:38 -0700 (PDT) Received: by 10.38.89.39 with SMTP id m39mr84316rnb; Thu, 09 Sep 2004 13:15:38 -0700 (PDT) Received: by 10.38.15.20 with HTTP; Thu, 9 Sep 2004 13:15:38 -0700 (PDT) Message-ID: From: Clint Chaplin Reply-To: Clint Chaplin To: capwap@frascone.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Test Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 9 Sep 2004 13:15:38 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Ping Sorry...... _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 14 23:41: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 XAA23670 for ; Tue, 14 Sep 2004 23:41:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3E6E52211F; Tue, 14 Sep 2004 23:41:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DD42B22120; Tue, 14 Sep 2004 23: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 5242822120 for ; Tue, 14 Sep 2004 23:40: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 91C111FD6C for ; Tue, 14 Sep 2004 23:40: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 i8F3X1Ca011015 for ; Tue, 14 Sep 2004 22:33:02 -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 i8F3X0Ca010995 for ; Tue, 14 Sep 2004 22:33:00 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C49AD5.B80915F2" Message-ID: Thread-Topic: Reminder: WG last call for Arch. taxonomy draft Thread-Index: AcSa1baimDKmb6w3Sx+JLX1JqZjitw== X-Priority: 1 Priority: Urgent Importance: high From: "Mani, Mahalingam (Mahalingam)" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Reminder: WG last call for Arch. taxonomy draft Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 14 Sep 2004 21:40:17 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C49AD5.B80915F2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The WGLC for architecture taxonomy draft closes in a couple of days - 15 sep 2004. Final comments on the draft are due by then. =20 -mani =20 =20 ------_=_NextPart_001_01C49AD5.B80915F2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The WGLC for architecture taxonomy draft closes in a couple of days – 15 sep 2004. Final comments on the = draft are due by then.

 

-mani

 

  

------_=_NextPart_001_01C49AD5.B80915F2-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 15 01:29: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 BAA00397 for ; Wed, 15 Sep 2004 01:29:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D60D81FE52; Wed, 15 Sep 2004 01:29:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 602CB2179A; Wed, 15 Sep 2004 01:29:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DDA612179A for ; Wed, 15 Sep 2004 01:28:07 -0400 (EDT) Received: from out014.verizon.net (out014pub.verizon.net [206.46.170.46]) by mail.frascone.com (Postfix) with ESMTP id 279F91FE52 for ; Wed, 15 Sep 2004 01:28:06 -0400 (EDT) Received: from Matt-Holdrege.verizon.net ([208.179.69.254]) by out014.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040915052804.OXZG24490.out014.verizon.net@Matt-Holdrege.verizon.net>; Wed, 15 Sep 2004 00:28:04 -0500 Message-Id: <6.1.2.0.2.20040915072523.01cc7e90@incoming.verizon.net> X-Sender: res06gzk@incoming.verizon.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 To: "Mani, Mahalingam (Mahalingam)" , From: Matt Holdrege Subject: Re: [Capwap] Reminder: WG last call for Arch. taxonomy draft In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_45881664==.ALT" X-Authentication-Info: Submitted using SMTP AUTH at out014.verizon.net from [208.179.69.254] at Wed, 15 Sep 2004 00:27:59 -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, 15 Sep 2004 07:28:04 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) --=====================_45881664==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable At 05:40 AM 9/15/2004, Mani, Mahalingam (Mahalingam) wrote: >The WGLC for architecture taxonomy=20 >draft=20 >closes in a couple of days =96 15 sep 2004. Final comments on the draft are= =20 >due by then. Are you sure your link is the most current draft? The draft Lily last sent= =20 out is different. I sent her some comments about the security section, but= =20 this draft has a different, abbreviated security section. -Matt --=====================_45881664==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 05:40 AM 9/15/2004, Mani, Mahalingam (Mahalingam) wrote:
The WGLC for architecture taxonomy draft closes in a couple of days =96 15 sep 2004. Final comments on the draft are= due by then.

Are you sure your link is the most current draft? The draft Lily last sent= out is different. I sent her some comments about the security section, but= this draft has a different, abbreviated security section.

-Matt
--=====================_45881664==.ALT-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 15 04:22: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 EAA11620 for ; Wed, 15 Sep 2004 04:22:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 82C20205F7; Wed, 15 Sep 2004 04:22:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D072F20B7F; Wed, 15 Sep 2004 04:22:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9B03520B7F for ; Wed, 15 Sep 2004 04:21:17 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id C66492000F for ; Wed, 15 Sep 2004 04:21:15 -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 i8F8DvCa004556 for ; Wed, 15 Sep 2004 03:13:57 -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 i8F8DuCa004548 for ; Wed, 15 Sep 2004 03:13:56 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C49AFC.F6C55982" Subject: RE: [Capwap] Reminder: WG last call for Arch. taxonomy draft Message-ID: Thread-Topic: [Capwap] Reminder: WG last call for Arch. taxonomy draft Thread-Index: AcSa5MjzV+NAKNPiS/e9wpV0MtBtTgAFpDZw From: "Mani, Mahalingam (Mahalingam)" To: "Matt Holdrege" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 15 Sep 2004 02:21:13 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C49AFC.F6C55982 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 http://www.ietf.org/internet-drafts/draft-ietf-capwap-arch-05.txt from Lily's email. =20 http://www.ietf.org/internet-drafts/draft-ietf-capwap-arch-05.txt from mine below (which I picked up from ID repository). =20 I can't divine any difference between the links. These are the same as the link provided in the email by internet-drafts@ietf.org on 8/27/04 to the list). =20 -mani _____ =20 From: Matt Holdrege [mailto:matt.holdrege@verizon.net]=20 Sent: Tuesday, September 14, 2004 10:28 PM To: Mani, Mahalingam (Mahalingam); capwap@frascone.com Subject: Re: [Capwap] Reminder: WG last call for Arch. taxonomy draft =20 At 05:40 AM 9/15/2004, Mani, Mahalingam (Mahalingam) wrote: The WGLC for architecture taxonomy draft closes in a couple of days - 15 sep 2004. Final comments on the draft are due by then. Are you sure your link is the most current draft? The draft Lily last sent out is different. I sent her some comments about the security section, but this draft has a different, abbreviated security section. -Matt ------_=_NextPart_001_01C49AFC.F6C55982 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

http://www.ietf.org/internet-drafts/draft-ietf-capwap-arch-05.txt from Lily’s email.

 

http://www.ietf.org/internet-drafts/draft-ietf-capwap-arch-05.txt from mine below (which I picked up from ID = repository).

 

I can’t divine any difference = between the links. These are the same as the link provided in the email by internet-drafts@ietf.org on = 8/27/04 to the list).

 

-mani

From: Matt = Holdrege [mailto:matt.holdrege@verizon.net]
Sent: Tuesday, September = 14, 2004 10:28 PM
To: Mani, Mahalingam (Mahalingam); capwap@frascone.com
Subject: Re: [Capwap] = Reminder: WG last call for Arch. taxonomy draft

 

At 05:40 AM 9/15/2004, Mani, = Mahalingam (Mahalingam) wrote:

The WGLC for architecture taxonomy draft closes in a couple of days – 15 sep 2004. Final comments on the = draft are due by then.


Are you sure your link is the most current draft? The draft Lily last = sent out is different. I sent her some comments about the security section, but = this draft has a different, abbreviated security section.

-Matt

------_=_NextPart_001_01C49AFC.F6C55982-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 15 10:06: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 KAA05186 for ; Wed, 15 Sep 2004 10:06:49 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0A46B20667; Wed, 15 Sep 2004 10:05:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0716F206DA; Wed, 15 Sep 2004 10:05:08 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B19EB207C4 for ; Wed, 15 Sep 2004 10:04:27 -0400 (EDT) Received: from web109.biz.mail.yahoo.com (web109.biz.mail.yahoo.com [216.136.174.219]) by mail.frascone.com (Postfix) with SMTP id 0ECFE20667 for ; Wed, 15 Sep 2004 10:04:25 -0400 (EDT) Message-ID: <20040915140424.84587.qmail@web109.biz.mail.yahoo.com> Received: from [63.154.44.103] by web109.biz.mail.yahoo.com via HTTP; Wed, 15 Sep 2004 07:04:23 PDT From: Max Factor Subject: Re: [Capwap] Reminder: WG last call for Arch. taxonomy draft To: "Mani, Mahalingam (Mahalingam)" , capwap@frascone.com In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-869444369-1095257063=:84076" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 15 Sep 2004 07:04:23 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) --0-869444369-1095257063=:84076 Content-Type: text/plain; charset=us-ascii One minor question, and please let me know if this was already discussed: MAC acronyms are used in this document for " medium access control ". However in the IT security industry MAC is also used for Mandatory Access Control. Do you think this will be a bit conflicting? Please see below: 1.2 IEEE 802.11 Definitions Station (STA): Any device that contains an IEEE 802.11 conformant medium access control (MAC) and physical layer (PHY) interface to the wireless medium (WM). "Mani, Mahalingam (Mahalingam)" wrote: The WGLC for architecture taxonomy draft closes in a couple of days – 15 sep 2004. Final comments on the draft are due by then. -mani SecurityForce1.Net --0-869444369-1095257063=:84076 Content-Type: text/html; charset=us-ascii

One minor question, and please let me know if this was already discussed:

 

MAC acronyms are used in this document for " medium access control ". However in the IT security industry MAC is also used for Mandatory Access Control.  Do you think this will be a bit conflicting? 

 

Please see below:

 

1.2  IEEE 802.11 Definitions

   Station (STA): Any device that contains an IEEE 802.11 conformant
   medium access control (MAC) and physical layer (PHY) interface to the
   wireless medium (WM).


"Mani, Mahalingam (Mahalingam)" <mmani@avaya.com> wrote:

The WGLC for architecture taxonomy draft closes in a couple of days – 15 sep 2004. Final comments on the draft are due by then.

 

-mani

 

  



SecurityForce1.Net --0-869444369-1095257063=:84076-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 15 10:59: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 KAA10748 for ; Wed, 15 Sep 2004 10:59:29 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7DDA62221B; Wed, 15 Sep 2004 10:55:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 620D32072D; Wed, 15 Sep 2004 10:55:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 572912072D for ; Wed, 15 Sep 2004 10:54:23 -0400 (EDT) Received: from out002.verizon.net (out002pub.verizon.net [206.46.170.141]) by mail.frascone.com (Postfix) with ESMTP id 0DE061FC66 for ; Wed, 15 Sep 2004 10:54:21 -0400 (EDT) Received: from Matt-Holdrege.verizon.net ([208.179.69.254]) by out002.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040915145419.IVL6722.out002.verizon.net@Matt-Holdrege.verizon.net>; Wed, 15 Sep 2004 09:54:19 -0500 Message-Id: <6.1.2.0.2.20040915165308.01cc1cf0@incoming.verizon.net> X-Sender: res06gzk@incoming.verizon.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 To: Max Factor , "Mani, Mahalingam (Mahalingam)" , capwap@frascone.com From: Matt Holdrege Subject: Re: [Capwap] Reminder: WG last call for Arch. taxonomy draft In-Reply-To: <20040915140424.84587.qmail@web109.biz.mail.yahoo.com> References: <20040915140424.84587.qmail@web109.biz.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Authentication-Info: Submitted using SMTP AUTH at out002.verizon.net from [208.179.69.254] at Wed, 15 Sep 2004 09:54:14 -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, 15 Sep 2004 16:54:21 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable No because in the context of 802, MAC is Medium Access Control. We operate= =20 in the standards industry rather than the IT industry. At 04:04 PM 9/15/2004, Max Factor wrote: >One minor question, and please let me know if this was already=20 >discussed:"urn:schemas-microsoft-com:office:office" /> > > > >MAC acronyms are used in this document for " medium access control ".=20 >However in the IT security industry MAC is also used for Mandatory Access= =20 >Control. Do you think this will be a bit conflicting? > > > >Please see below: > > >1.2 IEEE 802.11 Definitions > > Station (STA): Any device that contains an IEEE 802.11 conformant > medium access control (MAC) and physical layer (PHY) interface to the > wireless medium (WM). > > >"Mani, Mahalingam (Mahalingam)" wrote: >The WGLC for architecture taxonomy=20 >draft=20 >closes in a couple of days =96 15 sep 2004. Final comments on the draft are= =20 >due by then. > >-mani > > > > > >SecurityForce1.Net _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 15 11:43: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 LAA13108 for ; Wed, 15 Sep 2004 11:43:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 56EF9205DB; Wed, 15 Sep 2004 11:43:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0360F21349; Wed, 15 Sep 2004 11:43:05 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4BC8D21349 for ; Wed, 15 Sep 2004 11:42:11 -0400 (EDT) Received: from web108.biz.mail.yahoo.com (web108.biz.mail.yahoo.com [216.136.174.218]) by mail.frascone.com (Postfix) with SMTP id 66555205DB for ; Wed, 15 Sep 2004 11:42:09 -0400 (EDT) Message-ID: <20040915154208.60686.qmail@web108.biz.mail.yahoo.com> Received: from [63.154.44.103] by web108.biz.mail.yahoo.com via HTTP; Wed, 15 Sep 2004 08:42:08 PDT From: Max Factor Subject: Re: [Capwap] Reminder: WG last call for Arch. taxonomy draft To: Matt Holdrege , Max Factor , "Mani, Mahalingam (Mahalingam)" , capwap@frascone.com In-Reply-To: <6.1.2.0.2.20040915165308.01cc1cf0@incoming.verizon.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1096441726-1095262928=:60499" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 15 Sep 2004 08:42:08 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) --0-1096441726-1095262928=:60499 Content-Type: text/plain; charset=us-ascii Okay thanks! Matt Holdrege wrote: No because in the context of 802, MAC is Medium Access Control. We operate in the standards industry rather than the IT industry. At 04:04 PM 9/15/2004, Max Factor wrote: >One minor question, and please let me know if this was already >discussed:>"urn:schemas-microsoft-com:office:office" /> > > > >MAC acronyms are used in this document for " medium access control ". >However in the IT security industry MAC is also used for Mandatory Access >Control. Do you think this will be a bit conflicting? > > > >Please see below: > > >1.2 IEEE 802.11 Definitions > > Station (STA): Any device that contains an IEEE 802.11 conformant > medium access control (MAC) and physical layer (PHY) interface to the > wireless medium (WM). > > >"Mani, Mahalingam (Mahalingam)" wrote: >The WGLC for architecture taxonomy >draft >closes in a couple of days – 15 sep 2004. Final comments on the draft are >due by then. > >-mani > > > > > >SecurityForce1.Net _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap SecurityForce1.Net --0-1096441726-1095262928=:60499 Content-Type: text/html; charset=us-ascii
Okay thanks!


Matt Holdrege <matt.holdrege@verizon.net> wrote:
No because in the context of 802, MAC is Medium Access Control. We operate
in the standards industry rather than the IT industry.


At 04:04 PM 9/15/2004, Max Factor wrote:

>One minor question, and please let me know if this was already
>discussed:>"urn:schemas-microsoft-com:office:office" />
>
>
>
>MAC acronyms are used in this document for " medium access control ".
>However in the IT security industry MAC is also used for Mandatory Access
>Control. Do you think this will be a bit conflicting?
>
>
>
>Please see below:
>
>
>1.2 IEEE 802.11 Definitions
>
> Station (STA): Any device that contains an IEEE 802.11 conformant
> medium access control (MAC) and physical layer (PHY) interface to the
> wireless medium (WM).
>
>
>" Mani, Mahalingam (Mahalingam)" wrote:
>The WGLC for architecture taxonomy
>draft
>closes in a couple of days – 15 sep 2004. Final comments on the draft are
>due by then.
>
>-mani
>
>
>
>
>
>SecurityForce1.Net


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


SecurityForce1.Net --0-1096441726-1095262928=:60499-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 15 16:24:24 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 QAA06815 for ; Wed, 15 Sep 2004 16:24:24 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7570B22282; Wed, 15 Sep 2004 16:24:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 83B8421C10; Wed, 15 Sep 2004 16:24:05 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3BC8D22280 for ; Wed, 15 Sep 2004 16:23:29 -0400 (EDT) Received: from mx.sj.symbol.com (unknown [65.115.69.195]) by mail.frascone.com (Postfix) with ESMTP id F2D9521C10 for ; Wed, 15 Sep 2004 16:23:26 -0400 (EDT) Received: from RUNABOUT (gwianameserver.sj.symbol.com [157.235.95.252]) by mx.sj.symbol.com (8.12.10/8.12.10) with ESMTP id i8FKOqDq027333 for ; Wed, 15 Sep 2004 13:24:52 -0700 Received: from SJ-DOM-MTA by RUNABOUT with Novell_GroupWise; Wed, 15 Sep 2004 13:23:21 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.4 From: "Clint Chaplin" To: , , Subject: Re: [Capwap] Reminder: WG last call for Arch. taxonomy draft Mime-Version: 1.0 Content-Type: text/plain; charset=Windows-874 Content-Transfer-Encoding: 8bit Content-Disposition: inline X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 15 Sep 2004 13:23:10 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 8bit That's standard IEEE 802.11 terminology, unfortunately. It isn't in CAPWAP's charter to change that. Clint (JOATMON) Chaplin Wireless Security Advisor Wireless Standards Lead >>> Max Factor 09/15/04 07:11 AM >>> One minor question, and please let me know if this was already discussed: MAC acronyms are used in this document for " medium access control ". However in the IT security industry MAC is also used for Mandatory Access Control. Do you think this will be a bit conflicting? Please see below: 1.2 IEEE 802.11 Definitions Station (STA): Any device that contains an IEEE 802.11 conformant medium access control (MAC) and physical layer (PHY) interface to the wireless medium (WM). "Mani, Mahalingam (Mahalingam)" wrote: The WGLC for architecture taxonomy draft closes in a couple of days – 15 sep 2004. Final comments on the draft are due by then. -mani SecurityForce1.Net ________________________________________________________________________ This email has been scanned for computer viruses. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Sep 20 18:10:17 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 SAA27730 for ; Mon, 20 Sep 2004 18:10:16 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1701C201F0; Mon, 20 Sep 2004 18:09:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BE54020865; Mon, 20 Sep 2004 18:09:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E502220865 for ; Mon, 20 Sep 2004 18:08:45 -0400 (EDT) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mail.frascone.com (Postfix) with ESMTP id 6213B201F0 for ; Mon, 20 Sep 2004 18:08:44 -0400 (EDT) Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1C9WHy-0000C8-W0; Mon, 20 Sep 2004 18:05:38 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , capwap mailing list , capwap chair , capwap chair Message-Id: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Document Action: 'CAPWAP Problem Statement' to Informational RFC Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 20 Sep 2004 18:05:38 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The IESG has approved the following document: - 'CAPWAP Problem Statement ' as an Informational RFC This document is the product of the Control And Provisioning of Wireless Access Points Working Group. The IESG contact persons are Bert Wijnen and David Kessens. Technical Summary This document describes the Configuration and Provisioning for Wireless Access Points (CAPWAP) problem statement. Working Group Summary WG has consensus to publish this document as an Informational RFC. Protocol Quality Bert Wijnen reviewed this document for the IESG. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 21 16:01: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 QAA16090 for ; Tue, 21 Sep 2004 16:01:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 30B8921B8A; Tue, 21 Sep 2004 16:01:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3213021B8C; Tue, 21 Sep 2004 16: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 0D1E321B8C for ; Tue, 21 Sep 2004 16:00:35 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id 41D1021B8A for ; Tue, 21 Sep 2004 16:00:33 -0400 (EDT) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i8LJwqZp017316 for ; Tue, 21 Sep 2004 15:58: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 i8LJuaZp014619 for ; Tue, 21 Sep 2004 15:57:17 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4A015.537239EE" Message-ID: Thread-Topic: The WG Last call on Taxonomy has ended. Thread-Index: AcSgFVH3YmZUhxOoTbi6AC5YO3wn9g== From: "Mani, Mahalingam (Mahalingam)" To: Cc: "Dorothy Gellert (E-mail)" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] The WG Last call on Taxonomy has ended. Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 21 Sep 2004 13:58:12 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C4A015.537239EE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The last call on taxonomy draft (http://www.ietf.org/internet-drafts/draft-ietf-capwap-arch-05.txt) has closed last week (9/16/04). We did not receive/hear any comments on this call. We will be forqrding this for IESG to consider it to progress this as an informational RFC. =20 [The exception was the concern raised regarding wordings in security considerations in mesh-networks. The resolution at this time: Mesh-networking being a work-in-progress in IEEE - proposing / recommending solutions can be deferred until the threat model is better understood]. =20 Regards, -mani ------_=_NextPart_001_01C4A015.537239EE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The last call on taxonomy draft (http://www.ietf.org/internet-drafts/draft-ietf-capwap-arch-05.txt)= has closed last week (9/16/04). We did not = receive/hear

any comments on this call. We will be forqrding this = for IESG to consider it to progress this as an informational = RFC.

 

[The exception was the concern raised regarding = wordings in security considerations in mesh-networks. The resolution at this time: Mesh-networking being a work-in-progress in IEEE – proposing / recommending solutions can be deferred until the threat model is better understood].

 

Regards,

-mani

------_=_NextPart_001_01C4A015.537239EE-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 21 16:31: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 QAA23822 for ; Tue, 21 Sep 2004 16:31:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1894B21B8A; Tue, 21 Sep 2004 16:31:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 83C0921B9D; Tue, 21 Sep 2004 16: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 4888A21B9D for ; Tue, 21 Sep 2004 16:30:55 -0400 (EDT) Received: from out008.verizon.net (out008pub.verizon.net [206.46.170.108]) by mail.frascone.com (Postfix) with ESMTP id 55C4621B8A for ; Tue, 21 Sep 2004 16:30:53 -0400 (EDT) Received: from Matt-Holdrege.verizon.net ([83.194.37.3]) by out008.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040921203051.CTWE8960.out008.verizon.net@Matt-Holdrege.verizon.net>; Tue, 21 Sep 2004 15:30:51 -0500 Message-Id: <6.1.2.0.2.20040921222631.01d4cec0@incoming.verizon.net> X-Sender: res06gzk@incoming.verizon.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 To: "Mani, Mahalingam (Mahalingam)" , From: Matt Holdrege Subject: Re: [Capwap] The WG Last call on Taxonomy has ended. Cc: "Dorothy Gellert (E-mail)" In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_38154042==.ALT" X-Authentication-Info: Submitted using SMTP AUTH at out008.verizon.net from [83.194.37.3] at Tue, 21 Sep 2004 15:30:47 -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: Tue, 21 Sep 2004 22:30:57 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) --=====================_38154042==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable At 09:58 PM 9/21/2004, Mani, Mahalingam (Mahalingam) wrote: >The last call on taxonomy draft=20 >(http://= www.ietf.org/internet-drafts/draft-ietf-capwap-arch-05.txt)=20 >has closed last week (9/16/04). We did not receive/hear >any comments on this call. We will be forqrding this for IESG to consider= =20 >it to progress this as an informational RFC. > >[The exception was the concern raised regarding wordings in security=20 >considerations in mesh-networks. The resolution at this time:=20 >Mesh-networking being a work-in-progress in IEEE =96 proposing /=20 >recommending solutions can be deferred until the threat model is better=20 >understood]. I was the one who raised the concern as our original words that the design= =20 team developed were changed in this final draft. Mani told me we could=20 revise them as we get comments from the IESG. I'm fine with that. However I= =20 don't agree with the words above that we don't understand the threat model= =20 and we need to wait for IEEE work-in-progress. We understood it fine when=20 we put the security section together. We should complete our security=20 section properly before it becomes an RFC. -Matt --=====================_38154042==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 09:58 PM 9/21/2004, Mani, Mahalingam (Mahalingam) wrote:
The last call on taxonomy draft (= http://www.ietf.org/internet= -drafts/draft-ietf-capwap-arch-05.txt) has closed last week (9/16/04). We did not receive/hear
any comments on this call. We will be forqrding this for IESG to consider it to progress this as an informational RFC.
 
[The exception was the concern raised regarding wordings in security considerations in mesh-networks. The resolution at this time: Mesh-networking being a work-in-progress in IEEE =96 proposing / recommending solutions can be deferred until the threat model is better understood].

I was the one who raised the concern as our original words that the design team developed were changed in this final draft. Mani told me we could revise them as we get comments from the IESG. I'm fine with that. However I don't agree with the words above that we don't understand the threat model and we need to wait for IEEE work-in-progress. We understood it fine when we put the security section together. We should complete our security section properly before it becomes an RFC.

-Matt
--=====================_38154042==.ALT-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 22 10:44: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 KAA13604 for ; Wed, 22 Sep 2004 10:44:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C5D0B21E58; Wed, 22 Sep 2004 10:44:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 916B121E6D; Wed, 22 Sep 2004 10:44:05 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2439A21E6E for ; Wed, 22 Sep 2004 10:43:36 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 8EA3221E58 for ; Wed, 22 Sep 2004 10:43:33 -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 i8MEa7Zb017735 for ; Wed, 22 Sep 2004 09:36:07 -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 i8MEY3Zb014614 for ; Wed, 22 Sep 2004 09:34:55 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4A0B2.3D321332" Subject: RE: [Capwap] The WG Last call on Taxonomy has ended. Message-ID: Thread-Topic: [Capwap] The WG Last call on Taxonomy has ended. Thread-Index: AcSgGiNTVaxuD5nfQYOQwQHXTEtPOQAgEmOg From: "Mani, Mahalingam (Mahalingam)" To: "Matt Holdrege" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 22 Sep 2004 08:41:26 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C4A0B2.3D321332 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Matt, =20 Posting to the list the *changes* exactly as you *had* suggested. =20 "Similar security concerns for client data security as described in Section 4.8.1 also apply to the Distributed Mesh Architecture. Additionally, one important security consideration for the mesh networks is that the mesh nodes must authenticate each other within the same administrative domain, and data transmission among neighboring nodes must be secured. Each node that is part of the mesh must be fully trusted for the mesh to be secure. 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=20 fully secure the network." =20 "Similar security concerns for client data security as described in Section 4.8.1 also apply to the Distributed Mesh Architecture. Additionally, one important security consideration for the mesh networks is that the mesh nodes must authenticate each other within the same administrative domain.=20 Also to protect user and management data that may not be secured at layer 3, data transmission among neighboring nodes should be secured by a layer 2 mechanism of confidentiality, integrity and replay protection. IEEE 802.11i is recommended." =20 =20 My objection to the change is that we are not chartered to recommend security mechanisms over-the-air in the MAC-realm between mesh nodes. Discussion of this component of threat to meshnetwork is not in scope for CAPWAP. =20 Regards, -mani _____ =20 From: Matt Holdrege [mailto:matt.holdrege@verizon.net]=20 Sent: Tuesday, September 21, 2004 1:31 PM To: Mani, Mahalingam (Mahalingam); capwap@frascone.com Cc: Dorothy Gellert (E-mail) Subject: Re: [Capwap] The WG Last call on Taxonomy has ended. =20 At 09:58 PM 9/21/2004, Mani, Mahalingam (Mahalingam) wrote: The last call on taxonomy draft (http://www.ietf.org/internet-drafts/draft-ietf-capwap-arch-05.txt ) has closed last week (9/16/04). We did not receive/hear any comments on this call. We will be forqrding this for IESG to consider it to progress this as an informational RFC. =20 [The exception was the concern raised regarding wordings in security considerations in mesh-networks. The resolution at this time: Mesh-networking being a work-in-progress in IEEE - proposing / recommending solutions can be deferred until the threat model is better understood]. I was the one who raised the concern as our original words that the design team developed were changed in this final draft. Mani told me we could revise them as we get comments from the IESG. I'm fine with that. However I don't agree with the words above that we don't understand the threat model and we need to wait for IEEE work-in-progress. We understood it fine when we put the security section together. We should complete our security section properly before it becomes an RFC. -Matt ------_=_NextPart_001_01C4A0B2.3D321332 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Matt,

 

Posting to the list the *changes* exactly as you *had* = suggested.

 

<draft-05>
     “Similar =
security concerns for client data security as described =
in
   Section 4.8.1 also apply to the =
Distributed Mesh Architecture.
   Additionally, one important =
security consideration for the =
mesh
   networks is that the mesh nodes =
must authenticate each other =
within
   the same administrative domain, =
and data transmission among
   neighboring nodes must be =
secured.  Each node that is part of =
the
   mesh must be fully trusted for =
the mesh to be secure.  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.”



</draft-05><=
/font>



 



<matt-change-proposed>



“Similar =
security
concerns for client data security as described in =
Section



4.8.1 also apply to =
the
Distributed Mesh Architecture. Additionally, one important security
consideration for the mesh networks is that the mesh nodes must =
authenticate
each other within the same administrative domain. =




Also to protect =
user and
management data that may not be secured at layer 3, data transmission =
among
neighboring nodes should be secured by a layer 2 mechanism of =
confidentiality,
integrity and replay protection. IEEE 802.11i is =
recommended.”



</matt-change-proposed>



 



 



My objection to the change is that =
we are
not chartered to recommend security mechanisms over-the-air in the =
MAC-realm
between mesh nodes.



Discussion of this component of =
threat to
meshnetwork is not in scope for CAPWAP.



 



Regards,


-mani















From: Matt =
Holdrege
[mailto:matt.holdrege@verizon.net] 

Sent: Tuesday, September =
21, 2004
1:31 PM

To: Mani,
 Mahalingam (Mahalingam); capwap@frascone.com

Cc: Dorothy Gellert =
(E-mail)

Subject: Re: [Capwap] The =
WG Last
call on Taxonomy has ended.






 



At 09:58 PM 9/21/2004, Mani, =
Mahalingam
(Mahalingam) wrote:







The last call on taxonomy draft (http://www.ietf.org/internet-drafts/draft-ietf-capwap-arch-05=
.txt) has closed last week (9/16/04). We did not
receive/hear

any comments on this call. We will be forqrding this for IESG to =
consider it to
progress this as an informational RFC.

 

[The exception was the concern raised regarding wordings in security
considerations in mesh-networks. The resolution at this time: =
Mesh-networking
being a work-in-progress in IEEE – proposing / recommending =
solutions can
be deferred until the threat model is better =
understood].





I was the one who raised the concern as our original words that the =
design team
developed were changed in this final draft. Mani told me we could revise =
them
as we get comments from the IESG. I'm fine with that. However I don't =
agree
with the words above that we don't understand the threat model and we =
need to
wait for IEEE work-in-progress. We understood it fine when we put the =
security
section together. We should complete our security section properly =
before it
becomes an RFC.



-Matt
------_=_NextPart_001_01C4A0B2.3D321332-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Sep 24 19:13:13 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 TAA00651 for ; Fri, 24 Sep 2004 19:13:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 456AF20CF4; Fri, 24 Sep 2004 19:13:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4CA9820CFC; Fri, 24 Sep 2004 19:13:05 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D996220CFC for ; Fri, 24 Sep 2004 19:12:05 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mail.frascone.com (Postfix) with ESMTP id C49FF20CF4 for ; Fri, 24 Sep 2004 19:12:03 -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 i8ONC1L06858; Sat, 25 Sep 2004 02:12:01 +0300 (EET DST) X-Scanned: Sat, 25 Sep 2004 02:11:36 +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 i8ONBaDS020047; Sat, 25 Sep 2004 02:11:36 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 0064VPTI; Sat, 25 Sep 2004 02:11:35 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 i8ONBYS10726; Sat, 25 Sep 2004 02:11:34 +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); Fri, 24 Sep 2004 18:11:32 -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: Call For CAPWAP Objectives Draft Editor and Requirements Input Thread-Index: AcSii9MIPr8eSa9lQryLsxeHp1VUaA== From: To: Cc: , , , X-OriginalArrivalTime: 24 Sep 2004 23:11:32.0007 (UTC) FILETIME=[D45A7B70:01C4A28B] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Call For CAPWAP Objectives Draft Editor and Requirements Input Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 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, 24 Sep 2004 16:11:30 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi All- The chairs are now finalizing the re-charter proposal with the ADs and = Bert gave us the go-ahead to get started on the Objectives draft. We = are looking for volunteers (by Wednesday, 9/29) for editor of the CAPWAP = Objectives draft. This draft is a requirements draft for the CAPWAP = protocol and will define requirements in the form of Objectives, as was = discussed and agreed upon during the last IETF meeting: Define a set of Objectives based on the architecture taxonomy work that = lists the requirements for an interoperable CAPWAP protocol. This = document will: a. Address the problems stated in the CAPWAP Problem statement draft =20 b. Describe each objective, its benefit to the protocol and how it = satisfies the problem statement. c. Prioritize and classify the objectives into 3 categories: i. Mandatory and Accepted=20 ii. Desirable iii. Rejected d. Undergo review in IEEE as needed. A risk in developing protocols by the "requirements" approach is this = phase tends to drag out and stalemate occurs. In order to prevent this, = we will impose a hard limit on the protocol requirements phase. Bert = has suggested that if we can't meet this hard deadline, the WG will = close. With this in mind, the Objective draft editor will need to meet the = following deadlines. - first draft submitted by IETF 61. - Submission of the Objectives draft to IESG by Apr/May 2005. (To be = finalized in the Charter) If you do volunteer, please make sure you are availiable and willing to = put in the time required to meet these dates. Please volunteer by = Wednesday, 9/29, so we can get started on this draft quickly. =20 Thanks, Dorothy and Mani _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Sep 27 07:39: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 HAA21378 for ; Mon, 27 Sep 2004 07:39:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 01FA72196E; Mon, 27 Sep 2004 07:39:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 25F6721A3D; Mon, 27 Sep 2004 07:39:05 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 61DB821A3D for ; Mon, 27 Sep 2004 07:38:53 -0400 (EDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [192.11.222.161]) by mail.frascone.com (Postfix) with ESMTP id B2A412196E for ; Mon, 27 Sep 2004 07:38:51 -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 i8RBcnXd012809 for ; Mon, 27 Sep 2004 06:38:49 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 27 Sep 2004 13:38:40 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503C79D1E@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: capwap@frascone.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] RE: Call For CAPWAP Objectives Draft Editor and Requirements Inpu t Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 27 Sep 2004 13:38:34 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) CAPWAP WG participants, I like this initiative of the WG chairs to get this work going. But let me clarify: The WG charter does NOT yet include this activity. And I as a single AD cannot approve it, that is an IESG task. However, while the WG chairs, ADs and IESG are discussing the rechartering, the individuals of the WG of course can start working on things that seem obvious and usefull. Then by the time the charter gets approved, you may already have a good chunck of work done. So pls do not stop working while we are working the admin side. Bert > -----Original Message----- > From: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com] > Sent: Saturday, September 25, 2004 01:12 > To: capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; > Dorothy.Gellert@nokia.com > Subject: Call For CAPWAP Objectives Draft Editor and > Requirements Input > > > Hi All- > > The chairs are now finalizing the re-charter proposal with > the ADs and Bert gave us the go-ahead to get started on the > Objectives draft. We are looking for volunteers (by > Wednesday, 9/29) for editor of the CAPWAP Objectives draft. > This draft is a requirements draft for the CAPWAP protocol > and will define requirements in the form of Objectives, as > was discussed and agreed upon during the last IETF meeting: > > Define a set of Objectives based on the architecture taxonomy > work that lists the requirements for an interoperable CAPWAP > protocol. This document will: > a. Address the problems stated in the CAPWAP Problem > statement draft > b. Describe each objective, its benefit to the protocol > and how it satisfies the problem statement. > c. Prioritize and classify the objectives into 3 categories: > i. Mandatory and Accepted > ii. Desirable > iii. Rejected > d. Undergo review in IEEE as needed. > > A risk in developing protocols by the "requirements" > approach is this phase tends to drag out and stalemate > occurs. In order to prevent this, we will impose a hard > limit on the protocol requirements phase. Bert has suggested > that if we can't meet this hard deadline, the WG will close. > > With this in mind, the Objective draft editor will need to > meet the following deadlines. > - first draft submitted by IETF 61. > - Submission of the Objectives draft to IESG by Apr/May > 2005. (To be finalized in the Charter) > > If you do volunteer, please make sure you are availiable and > willing to put in the time required to meet these dates. > Please volunteer by Wednesday, 9/29, so we can get started on > this draft quickly. > > Thanks, > Dorothy and Mani > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap