From mmani@avaya.com Wed Nov 12 01:55:43 2003 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Tue, 11 Nov 2003 18:55:43 -0700 Subject: [Lwapp] Material for Friday: Charter and Issues. Message-ID: The following URL has the set of issues summarized from feedback on the list and from IESG. http://www.frascone.com/lwapp/ All are strongly encouraged to go over the issues list and comment. We will also be discussing the issues in the BoF on Friday (11/14/03). Also find the refined new charter posted in the website. Welcome discussions and comments. Revised agenda will be posted tomorrow with links to presentations from the same site. Regards, -mani -Dorothy From gspsl@yahoo.com.sg Wed Nov 12 04:00:40 2003 From: gspsl@yahoo.com.sg (Saravanan Govindan) Date: Wed, 12 Nov 2003 12:00:40 +0800 Subject: [Lwapp] Charter queries Message-ID: <000601c3a8d1$897b5b60$5b71510a@vivaldi> Dear All, I just went through the CAPWAP charter, drafts and have a few fundamental questions. 1. Regarding the split-AP architecture, I am wondering if this is a viable long-term solution to the question of large wireless LANs. If the AC is to manage non-real time, data transport and authentication issues, it is going to have to deal with a lot of functions/state for a lot of APs. This would increase the processing load, overhead and complexity at the AC. Would such a model be scalable and therefore be easy to deploy and operate over the long-run? 2. I remember reading in a previous version of one of the CAPWAP I-Ds that APs are now starting to include some IP functionality. With such new capabilities, why not push for more functionality at the APs? Then each AP would have greater control of itself and this would be inherently scalable. 3. In essence, greater functionality at the APs would lead to a distributed architecture where each AP is in charge of itself. Of course this would also give rise to the need for some means of collaboration between the APs. Since APs are now IP devices (has this been decided as absolute?) their interaction becomes more of an IETF issue. Also, by allowing APs to manage themselves the need for an AC diminishes and therefore AP-AC security issues become moot. 4. The problem statement mentions maintaining a consistent code base running on all the APs. I got the impression that this is too restrictive. If standard control functions have been defined, then their implementions should not affect their actual functionality. 5. I am not sure I understood the issue of authorizing access points. If it is about illegitimate APs connecting to a legitimate network (I am assuming a wired link here) isn't this more of a physical security issue, i.e., one where the points of connections to the legitimate network are to be secured? This also refers to the Rogue AP/AR issues in the LWAPP I-D. I look forward to your comments. Cheers, Saravanan From pcalhoun@airespace.com Wed Nov 12 15:33:39 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Wed, 12 Nov 2003 07:33:39 -0800 Subject: [Lwapp] Charter queries Message-ID: <55749BC69138654EBBC4C50BA4F55610599024@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3A932.58626142 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 1. Regarding the split-AP architecture, I am wondering if this is a = viable long-term solution to the question of large wireless LANs. If the AC is = to manage non-real time, data transport and authentication issues, it is = going to have to deal with a lot of functions/state for a lot of APs. This = would increase the processing load, overhead and complexity at the AC. Would = such a model be scalable and therefore be easy to deploy and operate over the long-run? I suspect that one could have made the same argument moving from isolated ethernet hubs to centralized ethernet switches. Sure it = requires processing power on the AC, but it also provides a significant set of=20 advantages. Being able to monitor and control a wireless network vs. a set of isolated and autonomous access points is the key here. The = benefits are all over the map from security to RF management. 2. I remember reading in a previous version of one of the CAPWAP I-Ds = that APs are now starting to include some IP functionality. With such new capabilities, why not push for more functionality at the APs? Then each = AP would have greater control of itself and this would be inherently = scalable. Well this is exactly what we have today, and this is what IT = managers keep telling me they do not want. They want a much smaller number of = managed devices in their network.=20 3. In essence, greater functionality at the APs would lead to a = distributed architecture where each AP is in charge of itself. Of course this would = also give rise to the need for some means of collaboration between the APs. = Since APs are now IP devices (has this been decided as absolute?) their interaction becomes more of an IETF issue. Also, by allowing APs to = manage themselves the need for an AC diminishes and therefore AP-AC security = issues become moot. ok - so it's possible to create a truly distributed approach, = allowing=20 each AP to communicate state and load on a sub second basis. Of course, = I would also assume that the APs need to understand geographical positioning = since you would probably not want all APs to communicate together in order to keep = this rather complex, bandwidth and CPU intensive protocol under some form of control. 4. The problem statement mentions maintaining a consistent code base = running on all the APs. I got the impression that this is too restrictive. If standard control functions have been defined, then their implementions should not affect their actual functionality. Fine, but realistically, IT managers test a code load and then = deploy.=20 I don't know of too many networks where identical devices run different code loads. 5. I am not sure I understood the issue of authorizing access points. If = it is about illegitimate APs connecting to a legitimate network (I am = assuming a wired link here) isn't this more of a physical security issue, i.e., = one where the points of connections to the legitimate network are to be = secured? This also refers to the Rogue AP/AR issues in the LWAPP I-D. Yes it does have something to do with physical security. However, = the point of the sentence is that APs need to be authenticated to the wired = network prior to being able to deliver service. ------_=_NextPart_001_01C3A932.58626142 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Charter queries

1. Regarding the split-AP architecture, I am wondering = if this is a viable
long-term solution to the question of large wireless LANs. If the AC is = to
manage non-real time, data transport and authentication issues, it is = going
to have to deal with a lot of functions/state for a lot of APs. This = would
increase the processing load, overhead and complexity at the AC. Would = such
a model be scalable and therefore be easy to deploy and operate over = the
long-run?

<PRC> I suspect that one could have made the same argument moving = from
isolated ethernet hubs to centralized ethernet switches. Sure it = requires
processing power on the AC, but it also provides a significant set = of
advantages. Being able to monitor and control a wireless network vs. = a
set of isolated and autonomous access points is the key here. The = benefits
are all over the map from security to RF management.

2. I remember reading in a previous version of one of the CAPWAP I-Ds = that
APs are now starting to include some IP functionality. With such new
capabilities, why not push for more functionality at the APs? Then each = AP
would have greater control of itself and this would be inherently = scalable.

<PRC> Well this is exactly what we have today, and this is what IT = managers
keep telling me they do not want. They want a much smaller number of = managed
devices in their network.

3. In essence, greater functionality at the APs would lead to a = distributed
architecture where each AP is in charge of itself. Of course this would = also
give rise to the need for some means of collaboration between the APs. = Since
APs are now IP devices (has this been decided as absolute?) their
interaction becomes more of an IETF issue. Also, by allowing APs to = manage
themselves the need for an AC diminishes and therefore AP-AC security = issues
become moot.

<PRC> ok - so it's possible to create a truly distributed = approach, allowing
each AP to communicate state and load on a sub second basis. Of course, = I would
also assume that the APs need to understand geographical positioning = since you
would probably not want all APs to communicate together in order to keep = this
rather complex, bandwidth and CPU intensive protocol under some form = of
control.

4. The problem statement mentions maintaining a consistent code base = running
on all the APs. I got the impression that this is too restrictive. = If
standard control functions have been defined, then their = implementions
should not affect their actual functionality.

<PRC> Fine, but realistically, IT managers test a code load and = then deploy.
I don't know of too many networks where identical devices run = different
code loads.

5. I am not sure I understood the issue of authorizing access points. If = it
is about illegitimate APs connecting to a legitimate network (I am = assuming
a wired link here) isn't this more of a physical security issue, i.e., = one
where the points of connections to the legitimate network are to be = secured?
This also refers to the Rogue AP/AR issues in the LWAPP I-D.

<PRC> Yes it does have something to do with physical security. = However, the point
of the sentence is that APs need to be authenticated to the wired = network prior to
being able to deliver service.

------_=_NextPart_001_01C3A932.58626142-- From mmani@avaya.com Wed Nov 12 16:58:58 2003 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Wed, 12 Nov 2003 09:58:58 -0700 Subject: [Lwapp] Charter queries Message-ID: Saravanan, Good detailed questions. I agree with the subsequent response from Pat. See inline for some more. > -----Original Message----- > From: Saravanan Govindan [mailto:gspsl@yahoo.com.sg] > Sent: Tuesday, November 11, 2003 8:01 PM > To: Mani, Mahalingam (Mahalingam); lwapp@frascone.com; gspsl@yahoo.com.sg > Subject: [Lwapp] Charter queries >=20 > Dear All, >=20 > I just went through the CAPWAP charter, drafts and have a few fundamental > questions. >=20 > 1. Regarding the split-AP architecture, I am wondering if this is a viable > long-term solution to the question of large wireless LANs. If the AC is to > manage non-real time, data transport and authentication issues, it is > going > to have to deal with a lot of functions/state for a lot of APs. This would > increase the processing load, overhead and complexity at the AC. Would > such > a model be scalable and therefore be easy to deploy and operate over the > long-run? >=20 [Mani, Mahalingam (Mahalingam)]=20 [Mani, Mahalingam (Mahalingam)] This is a classic case of balancing between centralization and distribution. The issue at hand is the need for centralization. The roaming domain needs a WLAN perspective wider than that of a AP's cell to make meaningful use of control, monitoring and triggers.=20 Having established the benefits of centralization of control - comes its scalability - for large configurations. One typically achieves that by hierarchical or distributed control. This is a generic problem area that have many available standard industry solutions. The WG's goal is to focus on the first of the problems. Moreover, to deal with scalability of control is saner than on a per-AP basis where they are installed/deployed on considerations of physical access/coverage than on network topology, control and security. > 2. I remember reading in a previous version of one of the CAPWAP I-Ds that > APs are now starting to include some IP functionality. With such new > capabilities, why not push for more functionality at the APs? Then each AP > would have greater control of itself and this would be inherently scalable. >=20 > 3. In essence, greater functionality at the APs would lead to a > distributed > architecture where each AP is in charge of itself. Of course this would > also > give rise to the need for some means of collaboration between the APs. > Since > APs are now IP devices (has this been decided as absolute?) their > interaction becomes more of an IETF issue. Also, by allowing APs to manage > themselves the need for an AC diminishes and therefore AP-AC security > issues > become moot. [Mani, Mahalingam (Mahalingam)]=20 [Mani, Mahalingam (Mahalingam)]=20 my response to (1) applies equally well here. APs cannot meaningfully exist by managing themselves. That is the important difference between a mobilility perspective and a mere wire-line switch/bridge perspective. There are contexts that need to be communicated to larger and larger number of adjacent APs (to cite your expanding WLAN case) that it needs to communicate with (and securely) that it becomes a backend network infrastructure nightmare. All networking is a fine balance of three C's - Control, Computation and Communication. Self-governing APs communicating their contexts (more IP and higher layer functions means more contexts) leads to the imbalance in control and communication (where control traffic competes with genuine communication) rendering the state-management more complex. >=20 > 4. The problem statement mentions maintaining a consistent code base > running > on all the APs. I got the impression that this is too restrictive. If > standard control functions have been defined, then their implementions > should not affect their actual functionality. >=20 [Mani, Mahalingam (Mahalingam)]=20 [Mani, Mahalingam (Mahalingam)] we will be clarifying the assertion in the meeting (update due on the draft spec.) - as Pat has done in his response. This does *not* imply uniform code across different AP architectures/vendors. > 5. I am not sure I understood the issue of authorizing access points. If > it > is about illegitimate APs connecting to a legitimate network (I am > assuming > a wired link here) isn't this more of a physical security issue, i.e., one > where the points of connections to the legitimate network are to be > secured? > This also refers to the Rogue AP/AR issues in the LWAPP I-D. >=20 [Mani, Mahalingam (Mahalingam)]=20 [Mani, Mahalingam (Mahalingam)] as mentioned earlier, placement decisions of APs favor physical coverage over physical security. Physical security is a relative term as well - even inside enterprises - where FBI studies indicate threat sources from within are higher. That's another express reason to vest control with higher physical assurance systems (such as controllers). > I look forward to your comments. >=20 > Cheers, >=20 > Saravanan >=20 >=20 [Mani, Mahalingam (Mahalingam)] I hope that clarifies. -mani From alper@docomolabs-usa.com Wed Nov 12 20:10:50 2003 From: alper@docomolabs-usa.com (Alper Yegin) Date: Wed, 12 Nov 2003 12:10:50 -0800 Subject: [Lwapp] Charter queries In-Reply-To: <55749BC69138654EBBC4C50BA4F55610599024@AIREMAIL.airespace.com> Message-ID: On 11/12/03 7:33 AM, "Pat R. Calhoun" wrote: > 5. I am not sure I understood the issue of authorizing access points. If it > is about illegitimate APs connecting to a legitimate network (I am assuming > a wired link here) isn't this more of a physical security issue, i.e., one > where the points of connections to the legitimate network are to be secured? > This also refers to the Rogue AP/AR issues in the LWAPP I-D. > > Yes it does have something to do with physical security. However, the > point > of the sentence is that APs need to be authenticated to the wired network > prior to > being able to deliver service. This sounds like "network access authorization" for which there are already solutions. In the context of this protocol design, we should be looking at "capwap authorization" which is a separate issue. Alper From david.putzolu@intel.com Wed Nov 12 20:57:32 2003 From: david.putzolu@intel.com (Putzolu, David) Date: Wed, 12 Nov 2003 12:57:32 -0800 Subject: [Lwapp] Charter queries Message-ID: <52D13A805349A249960B9943E5590BD881F6C1@orsmsx409.jf.intel.com> Pat Calhoun wrote> Saravanan Govindan wrote>> >>5. I am not sure I understood the issue of authorizing access points. If it >>is about illegitimate APs connecting to a legitimate network (I am assuming >>a wired link here) isn't this more of a physical security issue, i.e., one >>where the points of connections to the legitimate network are to be secured? >>This also refers to the Rogue AP/AR issues in the LWAPP I-D. > Yes it does have something to do with physical security. However, the point >of the sentence is that APs need to be authenticated to the wired network prior to >being able to deliver service. Doesn't the security issue apply to both the AP and AR? - Each AP needs to make sure that the entity controlling it via LWAPP is authenticated, and authorized, to do so. =20 - Each AR needs to make sure that the AP it is controlling is at least authenticated and authorized as an allowed AP on the network. =20 Thanks, David From pcalhoun@airespace.com Wed Nov 12 20:59:43 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Wed, 12 Nov 2003 12:59:43 -0800 Subject: [Lwapp] Charter queries Message-ID: <55749BC69138654EBBC4C50BA4F5561059903B@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3A960.065BF808 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Doesn't the security issue apply to both the AP and AR? >=20 > - Each AP needs to make sure that the entity controlling it > via LWAPP is authenticated, and authorized, to do so. =20 >=20 > - Each AR needs to make sure that the AP it is controlling > is at least authenticated and authorized as an allowed > AP on the network. =20 Yes, you are correct. mutual authentication is required. PatC ------_=_NextPart_001_01C3A960.065BF808 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Charter queries

> Doesn't the security issue apply to both the AP = and AR?
>
> - Each AP needs to make sure that the entity controlling it
>   via LWAPP is authenticated, and authorized, to do = so. 
>
> - Each AR needs to make sure that the AP it is controlling
>   is at least authenticated and authorized as an = allowed
>   AP on the network. 

<PRC> Yes, you are correct. mutual authentication is required.

PatC

------_=_NextPart_001_01C3A960.065BF808-- From mmani@avaya.com Wed Nov 12 22:20:52 2003 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Wed, 12 Nov 2003 15:20:52 -0700 Subject: [Lwapp] Charter queries Message-ID: > -----Original Message----- > From: Putzolu, David [mailto:david.putzolu@intel.com] > Sent: Wednesday, November 12, 2003 12:58 PM > To: Pat R. Calhoun; gspsl@yahoo.com.sg; Mani, Mahalingam (Mahalingam); > lwapp@frascone.com > Subject: RE: [Lwapp] Charter queries >=20 > Pat Calhoun wrote> > Saravanan Govindan wrote>> > >>5. I am not sure I understood the issue of authorizing access points. > If it > >>is about illegitimate APs connecting to a legitimate network (I am > assuming > >>a wired link here) isn't this more of a physical security issue, i.e., > one > >>where the points of connections to the legitimate network are to be > secured? > >>This also refers to the Rogue AP/AR issues in the LWAPP I-D. >=20 > > Yes it does have something to do with physical security. However, > the point > >of the sentence is that APs need to be authenticated to the wired > network prior to > >being able to deliver service. >=20 > Doesn't the security issue apply to both the AP and AR? >=20 > - Each AP needs to make sure that the entity controlling it > via LWAPP is authenticated, and authorized, to do so. [Mani, Mahalingam (Mahalingam)]=20 [Mani, Mahalingam (Mahalingam)] AP can validate the identity (authenticate) of the AR - implicitly allowing AR to control it in the process (e.g., such as on the basis of the certificate OID being a server type in addition to other constraint checks). Just an example - not the only possible mechanism. It may otherwise have to 'validate the authorization' with some other common trusted entity such as policy server - after the fact. >=20 > - Each AR needs to make sure that the AP it is controlling > is at least authenticated and authorized as an allowed > AP on the network. >=20 > Thanks, > David [Mani, Mahalingam (Mahalingam)]=20 -mani From Marcus Brunner Thu Nov 13 01:32:55 2003 From: Marcus Brunner (Marcus Brunner) Date: Wed, 12 Nov 2003 19:32:55 -0600 Subject: [Lwapp] Charter queries In-Reply-To: <55749BC69138654EBBC4C50BA4F55610599024@AIREMAIL.airespace.com> References: <55749BC69138654EBBC4C50BA4F55610599024@AIREMAIL.airespace.com> Message-ID: <20584569.1068665574@dyn130-38.ietf58.ietf.org> > 2. I remember reading in a previous version of one of the CAPWAP I-Ds that > APs are now starting to include some IP functionality. With such new > capabilities, why not push for more functionality at the APs? Then each AP > would have greater control of itself and this would be inherently > scalable. > > Well this is exactly what we have today, and this is what IT > managers keep telling me they do not want. They want a much smaller > number of managed devices in their network. Unfortunately, the number of managed devices is not getting small even when capwap is used, but you a hierarchy in managing the large number. From bran@arraycomm.com Thu Nov 13 01:56:39 2003 From: bran@arraycomm.com (Branislav Meandzija) Date: Wed, 12 Nov 2003 17:56:39 -0800 Subject: [Lwapp] Charter queries Message-ID: <200311130156.hAD1uift019372@lester.arraycomm.com> 2. I remember reading in a previous version of one of the CAPWAP I-Ds that APs are now starting to include some IP functionality. With such new capabilities, why not push for more functionality at the APs? Then each AP would have greater control of itself and this would be inherently scalable.= Well this is exactly what we have today, and this is what IT managers= keep telling me they do not want. They want a much smaller number of manage= d devices in their network. BM: I do not understand why we would not manage APs using the same architec= ture and protocols as all other IP network devices? IMHO, creating specialized m= anagement = architectures rolls back some 15 years of attempts to create a single stand= ard network management architecture and simplify network management. Branislav From gspsl@yahoo.com.sg Thu Nov 13 05:26:46 2003 From: gspsl@yahoo.com.sg (Saravanan Govindan) Date: Thu, 13 Nov 2003 13:26:46 +0800 Subject: [Lwapp] Charter queries Message-ID: <000101c3a9a6$bb68aad0$5b71510a@vivaldi> Dear All, 1. >> BM: I do not understand why we would not manage APs using the same architecture and protocols as all other IP network devices? IMHO, creating specialized management architectures rolls back some 15 years of attempts to create a single standard network management architecture and simplify network management. This is a good point. In my view, given the innate nature of APs - that they are for the wireless dynamic networks - they are fundamentally different from the static network devices for which current protocols have been developed. It is natural to want to fit existing IP solutions to this new framework, however this may not take full advantage of the wireless network's characteristics. I think we can look at specific wireless features that are to be supported/leveraged and then incorporate them into existing protocols. 2. >> Well this is exactly what we have today, and this is what IT managers keep telling me they do not want. They want a much smaller number of managed devices in their network. I think the reason for IP functionality to move towards the AP is that it provides easier abstraction at a network planning level. IT managers wanting fewer managed devices also implies that they want more devices to manage themselves. This is what makes me think of a distributed control architecture. I understand that there are benefits to the CAPWAP architecture, however we may want to consider all that the other side offers too. Saravanan From mmani@avaya.com Thu Nov 13 15:43:43 2003 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Thu, 13 Nov 2003 08:43:43 -0700 Subject: [Lwapp] Charter queries Message-ID: Please see inline. > -----Original Message----- > From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf > Of Saravanan Govindan > Sent: Wednesday, November 12, 2003 9:27 PM > To: lwapp@frascone.com > Subject: Re: [Lwapp] Charter queries >=20 > Dear All, >=20 > 1. >> BM: I do not understand why we would not manage APs using the same > architecture and protocols as all other IP network devices? IMHO, creating > specialized management architectures rolls back some 15 years of attempts > to > create a single standard network management architecture and simplify > network management. >=20 > This is a good point. In my view, given the innate nature of APs - > that > they are for the wireless dynamic networks - they are fundamentally > different from the static network devices for which current protocols have > been developed. It is natural to want to fit existing IP solutions to this > new framework, however this may not take full advantage of the wireless > network's characteristics. I think we can look at specific wireless > features > that are to be supported/leveraged and then incorporate them into existing > protocols. [Mani, Mahalingam (Mahalingam)]=20 [Mani, Mahalingam (Mahalingam)] Right. The goal of the currently proposed charter is to make that architectural analysis and use that to arrive at the right fitting protocol(s) for the discovery, encapsulation, control and monitoring needs this mobility-driven network brings. They may entail use of existing ones - as the charter states clearly - possibly with specific extensions. >=20 > 2. >> Well this is exactly what we have today, and this is what IT > managers keep telling me they do not want. They want a much smaller number > of managed devices in their network. >=20 > I think the reason for IP functionality to move towards the AP is > that > it provides easier abstraction at a network planning level. IT managers > wanting fewer managed devices also implies that they want more devices to > manage themselves. This is what makes me think of a distributed control > architecture. I understand that there are benefits to the CAPWAP > architecture, however we may want to consider all that the other side > offers > too. >=20 [Mani, Mahalingam (Mahalingam)] correct. -mani > Saravanan >=20 > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp From kempf@docomolabs-usa.com Thu Nov 13 15:54:02 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Thu, 13 Nov 2003 07:54:02 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: <02cf01c3a9fe$5c3a0740$85818182@dclkempt40> So here's a possible other way to think about CAPWAP, inspired by talking with Bernard Abboba, that may point a way out of the "to SNMP or not to SNMP" discussion. Here at IETF 58, the NOC apparently has provisoned with "too many" access points, and partially as a result, the access points keep appearing and disappearing as the load changes and they interfere with each other, according to some conversation we were having last night. This behavior is kind of like route flapping, and, when you think about it, CAPWAP is acting kind of like a routing protocol. That is, it is communicating between access points for purposes of power and load control, among others. The difference is that the CAPWAP Access Controller (or AR) is co-ordinating the control, rather than having distributed control as in routing protocols. I believe this difference is primarily because the access network topology is almost exclusively a star with respect to the controlling switch or router, rather than a mesh as in general IP networks. That is, it is never the case that an access point functions as a forwarding intermediary (note that this would not be the case in a mesh or multihop network, but CAPWAP isn't intended for those kinds of networks). Now, nobody would suggest using SNMP for routing information distribution, though I suppose it could be used for that purpose. So, while SNMP may have value for managing the static configuration of access points, it isn't the appropriate protocol for managing the routing. Sound reasonable? jak From john.loughney@nokia.com Thu Nov 13 15:58:43 2003 From: john.loughney@nokia.com (john.loughney@nokia.com) Date: Thu, 13 Nov 2003 17:58:43 +0200 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: James, Thanks for the perspective. I think that is a reasonable way to think of this problem. John > -----Original Message----- > From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com]On > Behalf Of ext James Kempf > Sent: 13 November, 2003 17:54 > To: LWAPP > Subject: [Lwapp] Another Way to Think about CAPWAP >=20 >=20 > So here's a possible other way to think about CAPWAP,=20 > inspired by talking > with Bernard Abboba, that may point a way out of the "to SNMP=20 > or not to > SNMP" discussion. >=20 > Here at IETF 58, the NOC apparently has provisoned with "too=20 > many" access > points, and partially as a result, the access points keep=20 > appearing and > disappearing as the load changes and they interfere with each other, > according to some conversation we were having last night. >=20 > This behavior is kind of like route flapping, and, when you=20 > think about it, > CAPWAP is acting kind of like a routing protocol. That is, it is > communicating between access points for purposes of power and=20 > load control, > among others. The difference is that the CAPWAP Access=20 > Controller (or AR) is > co-ordinating the control, rather than having distributed=20 > control as in > routing protocols. I believe this difference is primarily=20 > because the access > network topology is almost exclusively a star with respect to the > controlling switch or router, rather than a mesh as in=20 > general IP networks. > That is, it is never the case that an access point functions=20 > as a forwarding > intermediary (note that this would not be the case in a mesh=20 > or multihop > network, but CAPWAP isn't intended for those kinds of networks). >=20 > Now, nobody would suggest using SNMP for routing information=20 > distribution, > though I suppose it could be used for that purpose. So, while=20 > SNMP may have > value for managing the static configuration of access points,=20 > it isn't the > appropriate protocol for managing the routing. >=20 > Sound reasonable? >=20 > jak >=20 > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp >=20 From bran@arraycomm.com Thu Nov 13 16:27:54 2003 From: bran@arraycomm.com (Branislav Meandzija) Date: Thu, 13 Nov 2003 08:27:54 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: <200311131627.hADGRvft018273@lester.arraycomm.com> > So here's a possible other way to think about CAPWAP, = > inspired by talking > with Bernard Abboba, that may point a way out of the "to SNMP = > or not to > SNMP" discussion. > = > Here at IETF 58, the NOC apparently has provisoned with "too = > many" access > points, and partially as a result, the access points keep = > appearing and > disappearing as the load changes and they interfere with each other, > according to some conversation we were having last night. This is a problem (I haven't noticed any service problems here at the IETF) but I do not understand what it has to do with "to SNMP or not to SNMP". Anything "to many" we can deal with using an intermediate hierarchy level, lets call it MOC. NOC to MOC is more of a network reposititory type of a problem. MOC to AP is clearly an SNMP, or whatever the chosen standard IETF management protocol is, = type of a problem. Branislav From kempf@docomolabs-usa.com Thu Nov 13 16:34:00 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Thu, 13 Nov 2003 08:34:00 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP References: <200311131627.hADGRvft018273@lester.arraycomm.com> Message-ID: <032401c3aa03$f2306eb0$85818182@dclkempt40> > This is a problem (I haven't noticed any service problems here at the > IETF) but I do not understand what it has to do with > "to SNMP or not to SNMP". Anything "to many" we can deal with using > an intermediate hierarchy level, lets call it MOC. NOC to MOC is more > of a network reposititory type of a problem. MOC to AP is clearly > an SNMP, or whatever the chosen standard IETF management protocol is, > type of a problem. > It isn't clear to me. Why? jak From bran@arraycomm.com Thu Nov 13 16:43:26 2003 From: bran@arraycomm.com (Branislav Meandzija) Date: Thu, 13 Nov 2003 08:43:26 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: <200311131643.hADGhUft020425@lester.arraycomm.com> > = > > This is a problem (I haven't noticed any service problems = > here at the > > IETF) but I do not understand what it has to do with > > "to SNMP or not to SNMP". Anything "to many" we can deal with using > > an intermediate hierarchy level, lets call it MOC. NOC to = > MOC is more > > of a network reposititory type of a problem. MOC to AP is clearly > > an SNMP, or whatever the chosen standard IETF management = > protocol is, = > > type of a problem. > > = > = > It isn't clear to me. Why? Because its function is to do monitoring and control of network devices usi= ng IP. Branislav From sgoswami@umich.edu Thu Nov 13 17:45:37 2003 From: sgoswami@umich.edu (s. goswami) Date: Thu, 13 Nov 2003 12:45:37 -0500 (EST) Subject: [Lwapp] Another Way to Think about CAPWAP In-Reply-To: <02cf01c3a9fe$5c3a0740$85818182@dclkempt40> References: <02cf01c3a9fe$5c3a0740$85818182@dclkempt40> Message-ID: James, see my comments inline. On Thu, 13 Nov 2003, James Kempf wrote: > So here's a possible other way to think about CAPWAP, inspired by talking > with Bernard Abboba, that may point a way out of the "to SNMP or not to > SNMP" discussion. > > Here at IETF 58, the NOC apparently has provisoned with "too many" access > points, and partially as a result, the access points keep appearing and > disappearing as the load changes and they interfere with each other, > according to some conversation we were having last night. > Are you assuming these Access Points to be Access Routers also ? The AP's are L2 devices whereas AR's are L3 devices. Not all AP's are AR's. > This behavior is kind of like route flapping, and, when you think about it, > CAPWAP is acting kind of like a routing protocol. That is, it is > communicating between access points for purposes of power and load control, > among others. The difference is that the CAPWAP Access Controller (or AR) is > co-ordinating the control, rather than having distributed control as in > routing protocols. I believe this difference is primarily because the access > network topology is almost exclusively a star with respect to the > controlling switch or router, rather than a mesh as in general IP networks. > That is, it is never the case that an access point functions as a forwarding > intermediary (note that this would not be the case in a mesh or multihop > network, but CAPWAP isn't intended for those kinds of networks). > Would CAPWAP handle a mixed environment of pure L2 AP and L3 AR ? > Now, nobody would suggest using SNMP for routing information distribution, > though I suppose it could be used for that purpose. So, while SNMP may have > value for managing the static configuration of access points, it isn't the > appropriate protocol for managing the routing. > I do not agree with your opinion of SNMP (it would be beneficial if you could list a few problems in using SNMP). SNMP SMI has the appropriate Information Model to manage routing. The SNMP transport protocol may not be appropriate for carrying routing information in a "mesh" network. Subrata > Sound reasonable? > > jak > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > From kempf@docomolabs-usa.com Thu Nov 13 19:12:03 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Thu, 13 Nov 2003 11:12:03 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP References: <200311131643.hADGhUft020425@lester.arraycomm.com> Message-ID: <033f01c3aa1a$07dfb980$85818182@dclkempt40> ----- Original Message ----- From: "Branislav Meandzija" To: "James Kempf" ; "LWAPP" Sent: Thursday, November 13, 2003 8:43 AM Subject: RE: [Lwapp] Another Way to Think about CAPWAP > > > > > > This is a problem (I haven't noticed any service problems > > here at the > > > IETF) but I do not understand what it has to do with > > > "to SNMP or not to SNMP". Anything "to many" we can deal with using > > > an intermediate hierarchy level, lets call it MOC. NOC to > > MOC is more > > > of a network reposititory type of a problem. MOC to AP is clearly > > > an SNMP, or whatever the chosen standard IETF management > > protocol is, > > > type of a problem. > > > > > > > It isn't clear to me. Why? > > Because its function is to do monitoring and control of network devices using IP. > But it also shifts hosts from one access point to another to achieve load balancing. That's a routing-type function. jak From kempf@docomolabs-usa.com Thu Nov 13 19:21:21 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Thu, 13 Nov 2003 11:21:21 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP References: <02cf01c3a9fe$5c3a0740$85818182@dclkempt40> Message-ID: <038101c3aa1b$5eab9d50$85818182@dclkempt40> > > Are you assuming these Access Points to be Access Routers also ? The > AP's are L2 devices whereas AR's are L3 devices. Not all AP's are > AR's. > No, I'm assuming they are standard CAPWAP access points. > > Would CAPWAP handle a mixed environment of pure L2 AP and L3 AR ? > In the architecture, the AR contains the access point controller. So the AR is not itself controlled by CAPWAP. > I do not agree with your opinion of SNMP (it would be beneficial if you > could list a few problems in using SNMP). SNMP SMI has the appropriate > Information Model to manage routing. The SNMP transport protocol may > not be appropriate for carrying routing information in a "mesh" > network. > Since SNMP has objects, it could be used to describe routing but it isn't. Why? OSPF and IS-IS are used for that. I believe it is the type of information and time scale of the exchange that is important. The type of information for a routing protocol consists of routes, hosts, and information on link conditions. That is precisely the kind of information that needs to be exchanged between access points. SNMP is for retreiving and setting static configuration and logging information, not for controlling link conditions and host location. Of course, it could be used for that, but I think it would be a misuse of the protocol. jak From pcalhoun@airespace.com Thu Nov 13 19:23:13 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Thu, 13 Nov 2003 11:23:13 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: <55749BC69138654EBBC4C50BA4F5561059906C@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3AA1C.0A38F0F5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >> I do not agree with your opinion of SNMP (it would be beneficial if = you >> could list a few problems in using SNMP). SNMP SMI has the = appropriate >> Information Model to manage routing. The SNMP transport protocol may >> not be appropriate for carrying routing information in a "mesh" >> network. >> > >Since SNMP has objects, it could be used to describe routing but it = isn't. >Why? OSPF and IS-IS are used for that. I believe it is the type of >information and time scale of the exchange that is important. The type = of >information for a routing protocol consists of routes, hosts, and >information on link conditions. That is precisely the kind of = information >that needs to be exchanged between access points. SNMP is for = retreiving and >setting static configuration and logging information, not for = controlling >link conditions and host location. Of course, it could be used for = that, but >I think it would be a misuse of the protocol. Another analogy is L2TP. Since CAPWAP is trying to split the AP in a = similar way that L2TP has split a NAS function, I think the fact that l2TP does not = use SNMP to control the LAC in real-time. Again, SNMP could be used, when it does = get tricky to design a state machine that relies on multiple protocols. This can = lead to some rather unfortunate race conditions, and is very difficult to ensure = correct timing of operations. PatC PatC ------_=_NextPart_001_01C3AA1C.0A38F0F5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Another Way to Think about CAPWAP

>> I do not agree with your opinion of SNMP (it = would be beneficial if you
>> could list a few problems in using SNMP). SNMP SMI has the = appropriate
>> Information Model to manage routing. The SNMP transport = protocol may
>> not be appropriate for carrying routing information in a = "mesh"
>> network.
>>
>
>Since SNMP has objects, it could be used to describe routing but it = isn't.
>Why? OSPF and IS-IS are used for that. I believe it is the type = of
>information and time scale of the exchange that is important. The = type of
>information for a routing protocol consists of routes, hosts, = and
>information on link conditions. That is precisely the kind of = information
>that needs to be exchanged between access points. SNMP is for = retreiving and
>setting static configuration and logging information, not for = controlling
>link conditions and host location. Of course, it could be used for = that, but
>I think it would be a misuse of the protocol.

Another analogy is L2TP. Since CAPWAP is trying to split the AP in a = similar way
that L2TP has split a NAS function, I think the fact that l2TP does not = use SNMP
to control the LAC in real-time. Again, SNMP could be used, when it does = get tricky
to design a state machine that relies on multiple protocols. This can = lead to some
rather unfortunate race conditions, and is very difficult to ensure = correct timing of
operations.

PatC

PatC

------_=_NextPart_001_01C3AA1C.0A38F0F5-- From sgoswami@umich.edu Thu Nov 13 19:40:07 2003 From: sgoswami@umich.edu (s. goswami) Date: Thu, 13 Nov 2003 14:40:07 -0500 (EST) Subject: [Lwapp] Another Way to Think about CAPWAP In-Reply-To: <55749BC69138654EBBC4C50BA4F5561059906C@AIREMAIL.airespace.com> References: <55749BC69138654EBBC4C50BA4F5561059906C@AIREMAIL.airespace.com> Message-ID: Thanks Pat, see my comments. On Thu, 13 Nov 2003, Pat R. Calhoun wrote: > > >> I do not agree with your opinion of SNMP (it would be beneficial if you > >> could list a few problems in using SNMP). SNMP SMI has the appropriate > >> Information Model to manage routing. The SNMP transport protocol may > >> not be appropriate for carrying routing information in a "mesh" > >> network. > >> > > > >Since SNMP has objects, it could be used to describe routing but it isn't. > >Why? OSPF and IS-IS are used for that. I believe it is the type of > >information and time scale of the exchange that is important. The type of > >information for a routing protocol consists of routes, hosts, and > >information on link conditions. That is precisely the kind of information > >that needs to be exchanged between access points. SNMP is for retreiving and > >setting static configuration and logging information, not for controlling > >link conditions and host location. Of course, it could be used for that, but > >I think it would be a misuse of the protocol. > > Another analogy is L2TP. Since CAPWAP is trying to split the AP in a similar way > that L2TP has split a NAS function, I think the fact that l2TP does not use SNMP > to control the LAC in real-time. Again, SNMP could be used, when it does get tricky > to design a state machine that relies on multiple protocols. This can lead to some > rather unfortunate race conditions, and is very difficult to ensure correct timing of > operations. > Why not use SNMP PDU's over the CAPWAP transport ? That way the AP's and AR's can be modeled as SNMP SMI MIB and CAPWAP can use the same OID etc. verbatim. What would be the negative side , if any ? Subrata > PatC > > PatC > From bran@arraycomm.com Thu Nov 13 20:04:51 2003 From: bran@arraycomm.com (Branislav Meandzija) Date: Thu, 13 Nov 2003 12:04:51 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: <200311132004.hADK4rft001108@lester.arraycomm.com> > > > > > > > This is a problem (I haven't noticed any service problems > > > here at the > > > > IETF) but I do not understand what it has to do with > > > > "to SNMP or not to SNMP". Anything "to many" we can = > deal with using > > > > an intermediate hierarchy level, lets call it MOC. NOC to > > > MOC is more > > > > of a network reposititory type of a problem. MOC to AP = > is clearly > > > > an SNMP, or whatever the chosen standard IETF management > > > protocol is, > > > > type of a problem. > > > > > > > > > > It isn't clear to me. Why? > > > > Because its function is to do monitoring and control of = > network devices > using IP. > > > = > But it also shifts hosts from one access point to another to = > achieve load > balancing. That's a routing-type function. > = Not really, as it is just a single hop (AP/Manager) transaction. The = only distinguishing factor to typical monitoring and control is the pseudo real-time nature of this particular AP management aspect. I've seen SNMP used in pseudo real-time applications like switching on failover. So, considering that this function is tractable with traditional monitoring and control and that all other functions are traditional monitoring and control, I don't see any reason for a new architecture and protocol. That being said, given that SNMP is now on life-support mode and that NETCONF is in the making as a new configuration protocol, I would suggest separating the protocol aspect and the application aspect of this, and = handling the protocol in the traditional IETF management area, and the = application (i.e. the MIB or the equivalent) in LWAPP. Branislav From pcalhoun@airespace.com Thu Nov 13 20:09:22 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Thu, 13 Nov 2003 12:09:22 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: <55749BC69138654EBBC4C50BA4F55610599076@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3AA22.22A97B75 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Why not use SNMP PDU's over the CAPWAP transport ? That way the AP's = and > AR's can be modeled as SNMP SMI MIB and CAPWAP can use the same OID = etc. > verbatim. What would be the negative side , if any ? If it is determined that SNMP is the right protocol, then I think we = should use it as is. I'm not sure that it is really wise to create another = transport for SNMP. patC ------_=_NextPart_001_01C3AA22.22A97B75 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Another Way to Think about CAPWAP

> Why not use SNMP PDU's over the CAPWAP transport = ? That way the AP's and
> AR's can be modeled as SNMP SMI MIB and CAPWAP can use the same OID = etc.
> verbatim. What would be the negative side , if any ?

If it is determined that SNMP is the right protocol, then I think we = should
use it as is. I'm not sure that it is really wise to create another = transport
for SNMP.

patC

------_=_NextPart_001_01C3AA22.22A97B75-- From kempf@docomolabs-usa.com Thu Nov 13 20:22:28 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Thu, 13 Nov 2003 12:22:28 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP References: <200311132004.hADK4rft001108@lester.arraycomm.com> Message-ID: <042601c3aa23$dd9fcac0$85818182@dclkempt40> > > But it also shifts hosts from one access point to another to > > achieve load > > balancing. That's a routing-type function. > > > > Not really, as it is just a single hop (AP/Manager) transaction. The That's why I said "routing-type" and not "routing". See Pat's comments about L2TP in this regard. > only distinguishing factor to typical monitoring and control is the > pseudo real-time nature of this particular AP management aspect. > I've seen SNMP used in pseudo real-time applications like switching > on failover. > Sure. Protocols can be used for whatever people want. I've seen people in 3GPP advocate using SIP for setting up HTTP sessions. The point is, some protocols are specifically engineered for specific purposes. And SNMP was not engineered for routing-type control functions, IMHO. > So, considering that this function is tractable with traditional > monitoring and control and that all other functions are traditional > monitoring and control, I don't see any reason for a new architecture > and protocol. > > That being said, given that SNMP is now on life-support mode and that > NETCONF is in the making as a new configuration protocol, I would suggest > separating the protocol aspect and the application aspect of this, and > handling the protocol in the traditional IETF management area, and the > application (i.e. the MIB or the equivalent) in LWAPP. > Guess we just don't agree here. jak From sgoswami@umich.edu Thu Nov 13 20:46:27 2003 From: sgoswami@umich.edu (sgoswami@umich.edu) Date: Thu, 13 Nov 2003 15:46:27 -0500 Subject: [Lwapp] Another Way to Think about CAPWAP In-Reply-To: <042601c3aa23$dd9fcac0$85818182@dclkempt40> References: <200311132004.hADK4rft001108@lester.arraycomm.com> <042601c3aa23$dd9fcac0$85818182@dclkempt40> Message-ID: <1068756387.3fb3eda391cff@carrierpigeon.mail.umich.edu> See my single comment in-line. Quoting James Kempf : > > > But it also shifts hosts from one access point to another to > > > achieve load > > > balancing. That's a routing-type function. > > > > > > > Not really, as it is just a single hop (AP/Manager) transaction. The > > That's why I said "routing-type" and not "routing". See Pat's comments about > L2TP in this regard. > > > only distinguishing factor to typical monitoring and control is the > > pseudo real-time nature of this particular AP management aspect. > > I've seen SNMP used in pseudo real-time applications like switching > > on failover. > > > > Sure. Protocols can be used for whatever people want. I've seen people in > 3GPP advocate using SIP for setting up HTTP sessions. The point is, some > protocols are specifically engineered for specific purposes. And SNMP was > not engineered for routing-type control functions, IMHO. > > > So, considering that this function is tractable with traditional > > monitoring and control and that all other functions are traditional > > monitoring and control, I don't see any reason for a new architecture > > and protocol. > > > > That being said, given that SNMP is now on life-support mode and that > > NETCONF is in the making as a new configuration protocol, I would suggest > > separating the protocol aspect and the application aspect of this, and > > handling the protocol in the traditional IETF management area, and the > > application (i.e. the MIB or the equivalent) in LWAPP. > > > Not sure what you meant by SNMP "on life support". Are you saying SNMP will be repalced by NETCONF in a year or two ? > Guess we just don't agree here. > > jak > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > Subrata Goswami, Ph.D. From Dorothy.Gellert@nokia.com Thu Nov 13 20:59:02 2003 From: Dorothy.Gellert@nokia.com (Dorothy.Gellert@nokia.com) Date: Thu, 13 Nov 2003 12:59:02 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: <4D7B558499107545BB45044C63822DDE03F081F7@mvebe001.americas.nokia.com> Great discussion thread on SNMP. keep in mind that we propose to = initially limit the charter to architecture development that will flush out requirements to = help us decide the protocol question. =20 The Friday CAPWAP BOF is intended to gain consensus that there is a = problem to fix and decide if we can form a WG to solve it. If you haven't looked at the updated charter, its at: = http://www.frascone.com/capwap Dorothy > -----Original Message----- > From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com]On > Behalf Of ext James Kempf > Sent: Thursday, November 13, 2003 12:22 PM > To: Branislav Meandzija; LWAPP > Subject: Re: [Lwapp] Another Way to Think about CAPWAP >=20 >=20 > > > But it also shifts hosts from one access point to another to > > > achieve load > > > balancing. That's a routing-type function. > > > > > > > Not really, as it is just a single hop (AP/Manager) transaction. The >=20 > That's why I said "routing-type" and not "routing". See Pat's=20 > comments about > L2TP in this regard. >=20 > > only distinguishing factor to typical monitoring and control is the > > pseudo real-time nature of this particular AP management aspect. > > I've seen SNMP used in pseudo real-time applications like switching > > on failover. > > >=20 > Sure. Protocols can be used for whatever people want. I've=20 > seen people in > 3GPP advocate using SIP for setting up HTTP sessions. The=20 > point is, some > protocols are specifically engineered for specific purposes.=20 > And SNMP was > not engineered for routing-type control functions, IMHO. >=20 > > So, considering that this function is tractable with traditional > > monitoring and control and that all other functions are traditional > > monitoring and control, I don't see any reason for a new=20 > architecture > > and protocol. > > > > That being said, given that SNMP is now on life-support=20 > mode and that > > NETCONF is in the making as a new configuration protocol, I=20 > would suggest > > separating the protocol aspect and the application aspect=20 > of this, and > > handling the protocol in the traditional IETF management=20 > area, and the > > application (i.e. the MIB or the equivalent) in LWAPP. > > >=20 > Guess we just don't agree here. >=20 > jak >=20 > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp >=20 From bran@arraycomm.com Thu Nov 13 21:25:18 2003 From: bran@arraycomm.com (Branislav Meandzija) Date: Thu, 13 Nov 2003 13:25:18 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: <200311132125.hADLPPft024694@lester.arraycomm.com> > = > Not sure what you meant by SNMP "on life support". Are you = > saying SNMP = > will be repalced by NETCONF in a year or two ? = I can't speak for what the official statement is but as I understand it NETCONF will be used as the configuration protocol, thus at least suggesting using SNMP for monitoring only. IMHO, monitoring is not enough today to justify an investment into SNMP. So, a new management protocol for APs, like LWAPP makes this situation for all only worse and throws us possibly back into the pre-SNMP, pre-CMIP times. That is why I make the suggestion on focusing on the LWAPP application only in the LWAPP WG and letting the network management WGs come up with a viable solution for the protocol. Branislav From bran@arraycomm.com Thu Nov 13 21:29:11 2003 From: bran@arraycomm.com (Branislav Meandzija) Date: Thu, 13 Nov 2003 13:29:11 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: <200311132129.hADLTDft026153@lester.arraycomm.com> > = > The Friday CAPWAP BOF is intended to gain consensus that = > there is a problem to fix and decide > if we can form a WG to solve it. > = > If you haven't looked at the updated charter, its at: = > http://www.frascone.com/capwap Thanks, I will look at it. I will not be able to attend the BOF (have to leave the IETF this afternoon), but think I have made my point. Branislav From jmurphy@trapezenetworks.com Fri Nov 14 00:02:17 2003 From: jmurphy@trapezenetworks.com (Jim Murphy) Date: Thu, 13 Nov 2003 16:02:17 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: QSBiaXQgbW9yZSB0byBhZGQgdG8gdGhpcyBhcmd1bWVudC4gVG9kYXksIEFDcyBhcmUgbW9yZSB0 aGFuIGNvbmZpZ3VyYXRpb24NCmFuZCBtYW5hZ2VtZW50IGRldmljZXMgd2l0aCByZXNwZWN0IHRv IHRoZWlyIHJlbGF0aW9uc2hpcCB3aXRoIEFQcy4NCiANCkFDcyBkbyB1c2VyIGFuZCBzZXNzaW9u IG1hbmFnZW1ldC4gQUNzIHRlcm1pbmF0ZSA4MDIuMTEgY29udHJvbCBmcmFtZXMgYW5kDQphcHBs eSBkeW5hbWljIHBvbGljeSBiYXNlZCBvbiBsb2FkIGFuZCB1c2VyIHNwZWNpZmljIGF0dHJpYnV0 ZXMgZnJvbSBsb2NhbCBvciBiYWNrZW5kDQpBQUEgc2VydmVycy4NCiANCkFDcyB0ZXJtaW5hdGUg dXNlciBkYXRhIHN0cmVhbXMsIHBvc3NpYmx5IGFwcGx5aW5nIGZvcndhcmRpbmcgcG9saWNpZXMu DQpUaGUgQUMgbWF5IGFjdCBpbiBhIFZMQU4gb3IgVnJvdXRlciBlbnZpcm9ubWVudC4gVGhlIGFj Y2VzcyAoVilMQU4NCmJldHdlZW4gdGhlIEFDIGFuZCB0aGUgQVAgbWF5IG5vdCBiZSB0aGUgbmV0 d29yayB0aGF0IHRoZSBlbmQgdXNlcg0KKG1vYmlsZSBzdGF0aW9uKSBhY3R1YWxseSBiZWNvbWVz IGFzc29jaWF0ZWQgd2l0aC4NCiANCkkgdGhpbmsgdGhlIG9iamVjdGl2ZSBpcyB0byBrZWVwIEFQ cyBsaWdodHdlaWdodCwgYnVyZGVuaW5nIGV2ZXkgQVAgd2l0aCB0aGUNCmZlYXR1cmVzIGxpc3Rl ZCBoZXJlIG9yLCBldmVuIG1vcmUgaHVtb3JvdXNseSwgcnVubmluZyB0aGVzZSBmZWF0dXJlcyBv dmVyDQpTTk1QIGlzIGEgbm9uLXN0YXJ0ZXIuDQogDQpUaGFua3MsDQogDQpKaW0NCiANCg0KCS0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIA0KCUZyb206IEphbWVzIEtlbXBmIFttYWlsdG86a2Vt cGZAZG9jb21vbGFicy11c2EuY29tXSANCglTZW50OiBUaHUgMTEvMTMvMjAwMyAxMjoyMiBQTSAN CglUbzogQnJhbmlzbGF2IE1lYW5kemlqYTsgTFdBUFAgDQoJQ2M6IA0KCVN1YmplY3Q6IFJlOiBb THdhcHBdIEFub3RoZXIgV2F5IHRvIFRoaW5rIGFib3V0IENBUFdBUA0KCQ0KCQ0KDQoJPiA+IEJ1 dCBpdCBhbHNvIHNoaWZ0cyBob3N0cyBmcm9tIG9uZSBhY2Nlc3MgcG9pbnQgdG8gYW5vdGhlciB0 bw0KCT4gPiBhY2hpZXZlIGxvYWQNCgk+ID4gYmFsYW5jaW5nLiBUaGF0J3MgYSByb3V0aW5nLXR5 cGUgZnVuY3Rpb24uDQoJPiA+DQoJPg0KCT4gTm90IHJlYWxseSwgYXMgaXQgaXMganVzdCBhIHNp bmdsZSBob3AgKEFQL01hbmFnZXIpIHRyYW5zYWN0aW9uLiBUaGUNCgkNCglUaGF0J3Mgd2h5IEkg c2FpZCAicm91dGluZy10eXBlIiBhbmQgbm90ICJyb3V0aW5nIi4gU2VlIFBhdCdzIGNvbW1lbnRz IGFib3V0DQoJTDJUUCBpbiB0aGlzIHJlZ2FyZC4NCgkNCgk+IG9ubHkgZGlzdGluZ3Vpc2hpbmcg ZmFjdG9yIHRvIHR5cGljYWwgbW9uaXRvcmluZyBhbmQgY29udHJvbCBpcyB0aGUNCgk+IHBzZXVk byByZWFsLXRpbWUgbmF0dXJlIG9mIHRoaXMgcGFydGljdWxhciBBUCBtYW5hZ2VtZW50IGFzcGVj dC4NCgk+IEkndmUgc2VlbiBTTk1QIHVzZWQgaW4gcHNldWRvIHJlYWwtdGltZSBhcHBsaWNhdGlv bnMgbGlrZSBzd2l0Y2hpbmcNCgk+IG9uIGZhaWxvdmVyLg0KCT4NCgkNCglTdXJlLiBQcm90b2Nv bHMgY2FuIGJlIHVzZWQgZm9yIHdoYXRldmVyIHBlb3BsZSB3YW50LiBJJ3ZlIHNlZW4gcGVvcGxl IGluDQoJM0dQUCBhZHZvY2F0ZSB1c2luZyBTSVAgZm9yIHNldHRpbmcgdXAgSFRUUCBzZXNzaW9u cy4gVGhlIHBvaW50IGlzLCBzb21lDQoJcHJvdG9jb2xzIGFyZSBzcGVjaWZpY2FsbHkgZW5naW5l ZXJlZCBmb3Igc3BlY2lmaWMgcHVycG9zZXMuIEFuZCBTTk1QIHdhcw0KCW5vdCBlbmdpbmVlcmVk IGZvciByb3V0aW5nLXR5cGUgY29udHJvbCBmdW5jdGlvbnMsIElNSE8uDQoJDQoJPiBTbywgY29u c2lkZXJpbmcgdGhhdCB0aGlzIGZ1bmN0aW9uIGlzIHRyYWN0YWJsZSB3aXRoIHRyYWRpdGlvbmFs DQoJPiBtb25pdG9yaW5nIGFuZCBjb250cm9sIGFuZCB0aGF0IGFsbCBvdGhlciBmdW5jdGlvbnMg YXJlIHRyYWRpdGlvbmFsDQoJPiBtb25pdG9yaW5nIGFuZCBjb250cm9sLCBJIGRvbid0IHNlZSBh bnkgcmVhc29uIGZvciBhIG5ldyBhcmNoaXRlY3R1cmUNCgk+IGFuZCBwcm90b2NvbC4NCgk+DQoJ PiBUaGF0IGJlaW5nIHNhaWQsIGdpdmVuIHRoYXQgU05NUCBpcyBub3cgb24gbGlmZS1zdXBwb3J0 IG1vZGUgYW5kIHRoYXQNCgk+IE5FVENPTkYgaXMgaW4gdGhlIG1ha2luZyBhcyBhIG5ldyBjb25m aWd1cmF0aW9uIHByb3RvY29sLCBJIHdvdWxkIHN1Z2dlc3QNCgk+IHNlcGFyYXRpbmcgdGhlIHBy b3RvY29sIGFzcGVjdCBhbmQgdGhlIGFwcGxpY2F0aW9uIGFzcGVjdCBvZiB0aGlzLCBhbmQNCgk+ IGhhbmRsaW5nIHRoZSBwcm90b2NvbCBpbiB0aGUgdHJhZGl0aW9uYWwgSUVURiBtYW5hZ2VtZW50 IGFyZWEsIGFuZCB0aGUNCgk+IGFwcGxpY2F0aW9uIChpLmUuIHRoZSBNSUIgb3IgdGhlIGVxdWl2 YWxlbnQpIGluIExXQVBQLg0KCT4NCgkNCglHdWVzcyB3ZSBqdXN0IGRvbid0IGFncmVlIGhlcmUu DQoJDQoJICAgICAgICAgICAgamFrDQoJDQoJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCglMd2FwcCBtYWlsaW5nIGxpc3QNCglMd2FwcEBmcmFzY29uZS5j b20NCglodHRwOi8vbWFpbC5mcmFzY29uZS5jb20vbWFpbG1hbi9saXN0aW5mby9sd2FwcA0KCQ0K DQo= From jmurphy@trapezenetworks.com Fri Nov 14 17:50:33 2003 From: jmurphy@trapezenetworks.com (Jim Murphy) Date: Fri, 14 Nov 2003 09:50:33 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: IA0KDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJRnJvbTogUGF1bG8gRnJhbmNpc2Nv IFttYWlsdG86cGF1bG9AY2hhbnRyeW5ldHdvcmtzLmNvbV0gDQoJU2VudDogVGh1IDExLzEzLzIw MDMgMTA6MDAgUE0gDQoJVG86IEppbSBNdXJwaHk7ICdKYW1lcyBLZW1wZic7ICdCcmFuaXNsYXYg TWVhbmR6aWphJzsgJ0xXQVBQJyANCglDYzogDQoJU3ViamVjdDogUkU6IFtMd2FwcF0gQW5vdGhl ciBXYXkgdG8gVGhpbmsgYWJvdXQgQ0FQV0FQDQoJDQoJDQoNCg0KCS4uLg0KDQoJDQoJW1BGPl0g SSBmYWlsIHRvIHNlZSB3aHkgdGhlIGluc2lzdGVuY2Ugb2YgIkFDcyB0ZXJtaW5hdGUgODAyLjEx IGNvbnRyb2wgZnJhbWVzICIga2VlcHMgb24gYmVpbmcgbWFkZS4gVGhpcyBpcyB2ZXJ5IHJlc3Ry aWN0aXZlIHRvIGN1cnJlbnQgODAyLjExIHRlY2hub2xvZ3ksIHNvIGJhc2ljYWxseSBpdCBpcyBz YXlpbmcgdGhhdCBpZiBpbiB0aGUgZnV0dXJlIHNvbWUgb3RoZXIgdGVjaG5vbG9neSBiZWNvbWVz IGRvbWluYW50IG92ZXIgODAyLjExIHRoYXQgQ0FQV0FQIHdpbGwgaGF2ZSB0byByZS1zcGVjaWZp ZWQuIEluIG15IG9waW5pb24gaXQgd291bGQgc3VmZmljZSB0byBpbnRyb2R1Y2UgYSBtZXNzYWdl IHNldCB0byBhYnN0cmFjdCBhbmQgY29udmV5IHRoZSBjb250cm9sIHNldCB0aGF0IGlzIHJlYWxs eSBvZiBpbnRlcmVzdCB0byBjZW50cmFsIGNvbnRyb2wgKEFSL0FDKSBhbmQgbGV0IHRoZSBBUCBo YW5kbGUgdGhlIGFjdHVhbCA4MDIuMTEgbWVzc2FnZSBzZXQuIFRoaXMgbWVzc2FnZSBzZXQgY291 bGQgdGhlbiBzaW1wbHkgYmUgcmVtYXBwZWQgYXQgdGhlIEFQIHRvIGZ1dHVyZSB0ZWNobm9sb2dp ZXMgb3IgZGlmZmVyZW50IHByb3RvY29sIHR5cGVzIChwYXJkb24gdGhlIHJlZmVyZW5jZS4uIEJs dWV0b290aCkuIFRoaXMgd291bGQgcHJvdmlkZSBhbiBleHRlbmRhYmxlIGluZnJhc3RydWN0dXJl IHRoYXQgd291bGQgcHJvbW90ZSByZS11c2FiaWxpdHkuDQoJVGhpcyB3b3VsZCBhbHNvIHJlbW92 ZSBzb21lIG9mIHRoZSBvdmVybGFwIG9mIHJlc3BvbnNpYmlsaXRpZXMgYmV0d2VlbiBDQVBXQVAv SUVURiBhbmQgSUVFRS4NCgkNCg0KCVtKTT5dIEFuIGFic3RyYWN0IG1lc3NhZ2Ugc2V0IGlzIGhh cmQgdG8gYWNoaWV2ZSB1bmxlc3MgeW91IGtub3cgbm93IHRoZSBzZXQgb2YgcHJvdG9jb2xzIHlv dSBleHBlY3QgdG8gc3VwcG9ydCAgKGFuZCBldmVuIHRoZW4gaXQgY2FuIGJlIGhhcmQpLiBJdCBn b2VzIGJleW9uZCBtZXJlbHkgdGhlIGNvbnRlbnQgb2YgdGhlIG1lc3NhZ2VzIGJ1dCBpc3N1ZXMg bGlrZSB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gbWVzc2FnZXMgYW5kIHRoZWlyIHNlcXVlbmNp bmcgYmVjb21lIGNyaXRpY2FsLiBJIGRvIGFncmVlIHRoYXQgZXh0ZW5zaWJpbGl0eSB0byBvdGhl ciBwcm90b2NvbHMgaXMgYSBnb29kIGlkZWEuIEFuIGFsdGVybmF0aXZlIG1lY2hhbmlzbSB0byBh Y2hpZXZlIGV4dGVuc2liaWxpdHkgaXMgdGhhdCBDQVBXQVAgc2hvdWxkIGNhcnJ5IGFyYml0cmFy eSBwcm90b2NvbCBwYWNrZXRzLiBUaGUgc3BlY2lmaWMgcHJvdG9jb2wgYmVpbmcgY2FycmllZCBp cyBlc3RhYmxpc2hlZCBhdCBpbml0aWFsaXphdGlvbiB0aW1lLg0KDQoJVGhhbmtzLA0KDQoJSmlt DQoNCgkNCgkNCgkgDQoNCg== From bran@arraycomm.com Fri Nov 14 18:09:51 2003 From: bran@arraycomm.com (Branislav Meandzija) Date: Fri, 14 Nov 2003 10:09:51 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: <200311141810.hAEIA0ft006404@lester.arraycomm.com> DQo+IEFDcyB0ZXJtaW5hdGUgdXNlciBkYXRhIHN0cmVhbXMsIHBvc3NpYmx5IGFwcGx5aW5n IGZvcndhcmRpbmcgDQo+IHBvbGljaWVzLg0KPiBUaGUgQUMgbWF5IGFjdCBpbiBhIFZMQU4g b3IgVnJvdXRlciBlbnZpcm9ubWVudC4gVGhlIGFjY2VzcyAoVilMQU4NCj4gYmV0d2VlbiB0 aGUgQUMgYW5kIHRoZSBBUCBtYXkgbm90IGJlIHRoZSBuZXR3b3JrIHRoYXQgdGhlIGVuZCB1 c2VyDQo+IChtb2JpbGUgc3RhdGlvbikgYWN0dWFsbHkgYmVjb21lcyBhc3NvY2lhdGVkIHdp dGguDQo+ICANCj4gSSB0aGluayB0aGUgb2JqZWN0aXZlIGlzIHRvIGtlZXAgQVBzIGxpZ2h0 d2VpZ2h0LCBidXJkZW5pbmcgDQo+IGV2ZXkgQVAgd2l0aCB0aGUNCj4gZmVhdHVyZXMgbGlz dGVkIGhlcmUgb3IsIGV2ZW4gbW9yZSBodW1vcm91c2x5LCBydW5uaW5nIHRoZXNlIA0KPiBm ZWF0dXJlcyBvdmVyDQo+IFNOTVAgaXMgYSBub24tc3RhcnRlci4NCj4gIA0KPiBbUEY+XSBU aGUgb25seSB0aGluZyBiZWluZyB0aGF0IElFRUUgZG9lcyBhbHJlYWR5IHNwZWNpZnkgYSAN Cj4gTUlCIGZvcm1hdCBmb3IgYWRtaW5pc3RlcmluZyBhbiBBUC4gUHJldHR5IG11Y2ggYW55 IEFQIA0KPiBpbXBsZW1lbnRhdGlvbiBkb2VzIGFscmVhZHkgaW1wbGVtZW50IHN1Y2ggTUlC IGFuZCBtb3N0IA0KPiBsaWtlbHkgd2lsbCBpbiB0aGUgZnV0dXJlLiBJdCB3b3VsZCBzaW1w bHkgc3VmZmljZSB0byBwcm92aWRlIA0KPiBhIG1lc3NhZ2Ugc2V0IGZvciBlbmNhcHN1bGF0 aW9uIG9mIHRoZXNlIG1lc3NhZ2VzLCB0aHVzIGl0IA0KPiB3b3VsZCBtYXhpbWl6ZSBsZXZl cmFnaW5nIG9mIGV4aXN0aW5nIGluZnJhc3RydWN0dXJlLiBQbHVzIA0KPiBJJ20gYWZyYWlk IHRoYXQgaWYgQ0FQV0FQIHByb2NlZWRzIHdpdGggdGhlIHNwZWNpZmljYXRpb24gb2YgDQo+ IGl0cyBvd24gY29uZmlndXJhdGlvbiBtZXNzYWdlIHNldCBpdCB3aWxsIGJlIHZlcnkgaGFy ZCB0byANCj4ga2VlcCB1cCB3aXRoIGZ1dHVyZSBjb25maWd1cmF0aW9uIHJlcXVpcmVtZW50 cyBhdCB0aGUgQVAuIA0KPiBXaGlsZSBpcyBmYWlybHkgZWFzeSB0byBhZGQgYW4gT0lEIHRv IGFuIFNOTVAgaW5mcmFzdHJ1Y3R1cmUsIA0KPiBmcm9tIHdoYXQgSSBzZWUgb2YgTFdBUFAg c3BlY2lmaWNhdGlvbiB0aGUgYWN0dWFsIG1lc3NhZ2Ugc2V0IA0KPiB3b3VsZCBoYXZlIHRv IGJlIGV4dGVuZGVkIGV2ZXJ5IHRpbWUgbmV3IGZ1bmN0aW9uYWxpdHkgaXMgDQo+IHJlcXVp cmVkLCBzdWNoIGFzIHZlbmRvciBleHRlbnNpb25zIChiZWNhdXNlIHlvdSBrbm93IHRoYXQg aW4gDQo+IHRoZSBlbmQgZWFjaCBBUCB2ZW5kb3Igd2lsbCBoYXZlIGRpZmZlcmVudCBmZWF0 dXJlcyB0aGF0IG1heSANCj4gcmVxdWlyZSBzcGVjaWFsIGNvbmZpZ3VyYXRpb24pLiANCj4g DQo+IEFsc28sIHdlIGhhdmUgdG8gcmUtYmFzZSBvdXIgYXNzdW1wdGlvbnMgYXMgdG8gd2hh dCBpdCBtZWFucyANCj4gdG8gYmUgJ2xpZ2h0d2VpZ2h0JyBmb3IgYW4gQVAuICANCj4gQmFz aWNhbGx5IHRoZSBwcm9ibGVtIGlzIHRvIHRyeSB0byBhZGRyZXNzIHRoZSBkZXBsb3ltZW50 IG9mIA0KPiB0cmFkaXRpb25hbCBBUHMgd2hpY2ggYXJlIGtub3duIGFzICdmYXQnLiBXaGF0 IG1ha2VzIHRoZXNlIA0KPiBBUCdzICdmYXQnIGlzIHRoZSBhbW91bnQgb2YgZmVhdHVyZXMg dGhleSBuYXRpdmVseSBzdXBwb3J0IA0KPiBzdWNoIGFzIERIQ1BTZXJ2ZXIsIFJhZGl1c0Ns aWVudCBhbmQgc29tZSBldmVuIGhhdmUgZnVsbCANCj4gZnVuY3Rpb25hbCByb3V0aW5nIHN0 YWNrcyBpbiB0aGVtIChSSVAvT1NQRikuIFRoYXQgYWxsIGFkZHMgDQo+IHVwIHRvIGEgY29t cGxleCBhbmQgZXhwZW5zaXZlIEFQLiANCj4gVGhlcmVmb3JlIHRoZSBhaW0gb2YgYSAnbGln aHR3ZWlnaHQnIEFQIGlzIHRvIHJlZHVjZSANCj4gY29tcGxleGl0eSBhbmQgY29zdCBieSBy ZW1vdmluZyBmcm9tIHRoZSBBUCBhcyBtYW55IGZlYXR1cmVzIA0KPiBhcyBpdCBpcyBwb3Nz aWJsZS4gVGhpcyBpcyBhY2NvbXBsaXNoZWQgYnkgbW92aW5nIHRoZXNlIA0KPiBleHBlbnNp dmUgZmVhdHVyZXMgdG8gYSBjZW50cmFsaXplZCBjb250cm9sbGVyLiBUaHVzIGlmIGluIA0K PiB0aGUgZW5kIHlvdSBlbmQgdXAgd2l0aCBhbiBBUCBvbiB3aGljaCBhbGwgeW91IG5lZWQg dG8gZGVwbG95IA0KPiBpcyBhbiBJUCBzdGFjaywgYSBMV0FQUCB0cmFuc2xhdGlvbiBhcHAs IGFuIFNOTVAgYWdlbnQgYW5kIGFuIA0KPiA4MDIuMTEgc3RhY2ssIHlvdSd2ZSBhbHJlYWR5 IHRyaW1tZWQgbW9zdCBvZiB0aGUgJ2ZhdCcuDQo+IA0KDQpJIGd1ZXNzIHRoYXQgbWFrZXMg YSBjb21wZWxsaW5nIGFyZ3VtZW50IHRvIGdvIHdpdGggU05NUC4NCg0KQnJhbmlzbGF2DQo= From pcalhoun@airespace.com Fri Nov 14 19:58:38 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Fri, 14 Nov 2003 11:58:38 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: <55749BC69138654EBBC4C50BA4F556105990A6@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3AAEA.39F15C09 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =09 [PF>] I fail to see why the insistence of "ACs terminate 802.11 control = frames " keeps on being made. This is very restrictive to current 802.11 = technology, so basically it is saying that if in the future some other = technology becomes dominant over 802.11 that CAPWAP will have to = re-specified. In my opinion it would suffice to introduce a message set = to abstract and convey the control set that is really of interest to = central control (AR/AC) and let the AP handle the actual 802.11 message = set. This message set could then simply be remapped at the AP to future = technologies or different protocol types (pardon the reference.. = Bluetooth). This would provide an extendable infrastructure that would = promote re-usability. This would also remove some of the overlap of responsibilities between = CAPWAP/IETF and IEEE. In the end, you will end up creating a protocol that looks a hell = of a lot like the 802.11 mac management protocol. You'll want to auth = the user, association indication from the AP to the AC, you'll want the = ability to disconnect (or learn about disconnects). All these link layer = trigger information is needed by the AC. So I would argue that creating = a protocol to provide the information that is already in the 802.11 = protocol is silly. We already have what we need - we just need to send = it to the AC. [JM>] An abstract message set is hard to achieve unless you know now = the set of protocols you expect to support (and even then it can be = hard). It goes beyond merely the content of the messages but issues like = the relationship between messages and their sequencing become critical. = I do agree that extensibility to other protocols is a good idea. An = alternative mechanism to achieve extensibility is that CAPWAP should = carry arbitrary protocol packets. The specific protocol being carried is = established at initialization time. relationship between messages and sequencing in the CAPWAP model = is no different than in the traditional (or should I say legacy? :) AP = architecture. We've also discussed extensibility, but the IESG has informed us that it = would be a really good idea to keep the scope of the WG smaller, solve = the problem, and then if we were successful, extend to other = technologies (if the market requires it). PatC ------_=_NextPart_001_01C3AAEA.39F15C09 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Another Way to Think about CAPWAP

       
        [PF>] I = fail to see why the insistence of "ACs terminate 802.11 control = frames " keeps on being made. This is very restrictive to current = 802.11 technology, so basically it is saying that if in the future some = other technology becomes dominant over 802.11 that CAPWAP will have to = re-specified. In my opinion it would suffice to introduce a message set = to abstract and convey the control set that is really of interest to = central control (AR/AC) and let the AP handle the actual 802.11 message = set. This message set could then simply be remapped at the AP to future = technologies or different protocol types (pardon the reference.. = Bluetooth). This would provide an extendable infrastructure that would = promote re-usability.
        This would also remove some = of the overlap of responsibilities between CAPWAP/IETF and IEEE.

<PRC> In the end, you will end up creating a protocol that looks a = hell of a lot like the 802.11 mac management protocol. You'll want to = auth the user, association indication from the AP to the AC, you'll want = the ability to disconnect (or learn about disconnects). All these link = layer trigger information is needed by the AC. So I would argue that = creating a protocol to provide the information that is already in the = 802.11 protocol is silly. We already have what we need - we just need to = send it to the AC.

        [JM>] An abstract message = set is hard to achieve unless you know now the set of protocols you = expect to support  (and even then it can be hard). It goes beyond = merely the content of the messages but issues like the relationship = between messages and their sequencing become critical. I do agree that = extensibility to other protocols is a good idea. An alternative = mechanism to achieve extensibility is that CAPWAP should carry arbitrary = protocol packets. The specific protocol being carried is established at = initialization time.

<PRC> relationship between messages and sequencing in the CAPWAP = model is no different than in the traditional (or should I say legacy? = :) AP architecture.
We've also discussed extensibility, but the IESG has informed us that it = would be a really good idea to keep the scope of the WG smaller, solve = the problem, and then if we were successful, extend to other = technologies (if the market requires it).

PatC

------_=_NextPart_001_01C3AAEA.39F15C09-- From pcalhoun@airespace.com Sat Nov 15 00:39:39 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Fri, 14 Nov 2003 16:39:39 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: <55749BC69138654EBBC4C50BA4F556105990B8@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3AB10.F3B4CBE6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [PF>] True, but as demonstrated by DIRAC and a few similar implementations an abstraction protocol is very much doable. While it is true that some of the message set will be pure duplicates of 802.11 messages [and maybe with the current scope of definitions this is definitely true], it does stand to reason that it isn't hard to imagine that other technologies would provide a similar set of functionality (user associate notification, disconnect user, etc) . All it takes is to identify the set of parameters that make sense to an AC (what does it actually need to know) [DIRAC] actions, events and statistics and you should be able to achieve the goal of portability.=20 ok - so you take an 802.11 message, decompose it, create a = request, send it to the AC, the AC responds, the AP breaks it apart, creates an = 802.11 response and then sends it to the user. Unnecessarily complex. The message set is already there? Why = re-ivent it? You'll only end up increasing latency. Such specification IMO would definitely assist in the goal of defining interoperability, as it could definitely leverage AP functionality implemented by the AP vendor. Conversion of APs to support the interoperability would become a simple matter of implementing the translation protocol. As an add-on module it would not require many changes to the 802.11 stack other than interface points.=20 FWIW, my system works great, we got WiFi certified and are = completely interoperable with all clients out there... so I'm not sure that I = follow. The nice thing about using the 802.11 mac mgmt messages is that you = already have guaranteed interoperability - you're relying on an existing = protocol and just processing it in another system. PatC ------_=_NextPart_001_01C3AB10.F3B4CBE6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Another Way to Think about CAPWAP

[PF>] True, but as demonstrated by DIRAC and a few = similar
implementations an abstraction protocol is very much doable. While it = is
true that some of the message set will be pure duplicates of 802.11
messages [and maybe with the current scope of definitions this is
definitely true], it does stand to reason that it isn't hard to = imagine
that other technologies would provide a similar set of functionality
(user associate notification, disconnect user, etc)  . All it takes = is
to identify the set of parameters that make sense to an AC (what does = it
actually need to know) [DIRAC] actions, events and statistics and = you
should be able to achieve the goal of portability.

<PRC> ok - so you take an 802.11 message, decompose it, create a = request,
send it to the AC, the AC responds, the AP breaks it apart, creates an = 802.11
response and then sends it to the user.

<PRC> Unnecessarily complex. The message set is already there? Why = re-ivent it?
You'll only end up increasing latency.

Such specification
IMO would definitely assist in the goal of defining interoperability, = as
it could definitely leverage AP functionality implemented by the AP
vendor. Conversion of APs to support the interoperability would become = a
simple matter of implementing the translation protocol.  As an = add-on
module it would not require many changes to the 802.11 stack other = than
interface points.

<PRC> FWIW, my system works great, we got WiFi certified and are = completely
interoperable with all clients out there... so I'm not sure that I = follow.
The nice thing about using the 802.11 mac mgmt messages is that you = already
have guaranteed interoperability - you're relying on an existing = protocol and
just processing it in another system.

PatC

------_=_NextPart_001_01C3AB10.F3B4CBE6-- From jmurphy@trapezenetworks.com Sat Nov 15 01:19:57 2003 From: jmurphy@trapezenetworks.com (Jim Murphy) Date: Fri, 14 Nov 2003 17:19:57 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: relationship between messages and sequencing in the CAPWAP model = is no different than in the traditional (or should I say legacy? :) AP = architecture. [JM] I understand that but bluetooth was mentioned. We've also discussed extensibility, but the IESG has informed us that it = would be a really good idea to keep the scope of the WG smaller, solve = the problem, and then if we were successful, extend to other = technologies (if the market requires it). [JM] I'm OK with that. PatC From bran@arraycomm.com Sat Nov 15 01:56:18 2003 From: bran@arraycomm.com (Branislav Meandzija) Date: Fri, 14 Nov 2003 17:56:18 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: <200311150156.hAF1uOft008925@lester.arraycomm.com> [PF>] True, but as demonstrated by DIRAC and a few similar implementations an abstraction protocol is very much doable. While it is true that some of the message set will be pure duplicates of 802.11 messages [and maybe with the current scope of definitions this is definitely true], it does stand to reason that it isn't hard to imagine that other technologies would provide a similar set of functionality (user associate notification, disconnect user, etc) . All it takes is to identify the set of parameters that make sense to an AC (what does it actually need to know) [DIRAC] actions, events and statistics and you should be able to achieve the goal of portability. ok - so you take an 802.11 message, decompose it, create a request, send it to the AC, the AC responds, the AP breaks it apart, creates an 802.= 11 response and then sends it to the user. Unnecessarily complex. The message set is already there? Why re-ivent= it? You'll only end up increasing latency. -- BM - The solutions are actually not that different in performance as the 80= 2.11 message break down needs to happen somewhere, either in the AP, or the AC. = The difference is that instead of using a cross-technology management standard = = and architecture, the solution you describe proposes a strap-on protocol in= between = the AP and AC. -- Such specification IMO would definitely assist in the goal of defining interoperability, as it could definitely leverage AP functionality implemented by the AP vendor. Conversion of APs to support the interoperability would become a simple matter of implementing the translation protocol. As an add-on module it would not require many changes to the 802.11 stack other than interface points. FWIW, my system works great, we got WiFi certified and are completely= interoperable with all clients out there... so I'm not sure that I follow. The nice thing about using the 802.11 mac mgmt messages is that you already= have guaranteed interoperability - you're relying on an existing protocol a= nd just processing it in another system. -- BM - How do other vendor's AP's and AP managers interoperate with your syst= em? If they want to fit in, both AP and management solution vendors would have to add 8= 02.11 message processing functionality between AP and AC. If a management standar= d was used, = management vendors would just need to support the data model (e.g. MIB) and= provide = applications, and AP vendors would just need to extend their data model (e.= g. MIB) = and data model instrumentation. That would seem simpler than repurposing 80= 2.11 mac mngmt messages for AP/AC communication, and doing custom hacks in the AP an= d the manager. Branislav Branislav From pcalhoun@airespace.com Sat Nov 15 02:20:15 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Fri, 14 Nov 2003 18:20:15 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: <55749BC69138654EBBC4C50BA4F556105990C0@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3AB1F.019FDC8C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable BM - The solutions are actually not that different in performance as the = 802.11 message break down needs to happen somewhere, either in the AP, or the = AC. The difference is that instead of using a cross-technology management = standard=20 and architecture, the solution you describe proposes a strap-on protocol = in between=20 the AP and AC. Incorrect. On the AP you need to break down the message, create a = new one, and again when receiving the reply from the AC. This is not = required if you are simply tunneling the mac management packet to the = AC. -- Such specification IMO would definitely assist in the goal of defining interoperability, as it could definitely leverage AP functionality implemented by the AP vendor. Conversion of APs to support the interoperability would become a simple matter of implementing the translation protocol. As an add-on module it would not require many changes to the 802.11 stack other than interface points. I see. I find it rather interesting to note that APs actually = already have an 802.11 stack and not processing them, but rather = tunneling them to a centralized controller will somehow lower chances of = interoperability vs. creating a new protocol stack.=20 Intercepting these packets are calling a function with the packet = so that they get tunneled instead of calling a function to create a new = request doesn't seem like a huge difference in how difficult it is to = implement (in fact, I'd argue that tunneling is safer because you really = can't screw something up - you're simply forwarding the request). Oh, = and tunneling the packets also allows you to automagically handle any = new 802.11 extensions that get created. I guess you can safely assume that I respectfully disagree. BM - How do other vendor's AP's and AP managers interoperate with your = system? If they want to fit in, both AP and management solution vendors would have to = add 802.11 message processing functionality between AP and AC. If a management = standard was used,=20 management vendors would just need to support the data model (e.g. MIB) = and provide=20 applications, and AP vendors would just need to extend their data model = (e.g. MIB)=20 and data model instrumentation. That would seem simpler than repurposing = 802.11 mac mngmt messages for AP/AC communication, and doing custom hacks in the AP = and the manager. Well other APs don't currently interoperate with my system - = that's kind of the point of the proposed WG. But I think that I = understand your point here. You're proposing SNMP as a method of sending = link layer information to the AC. If this is in fact what you are = saying, I think that there is some gross mis-use of protocol being = proposed here. We need something compact, fast and requires low cpu = overhead. Last time I checked out my switch's SNMPv3 source code, it = really didn't meet any of those three requirements (why do I have a = feeling I'm about to get an e-mail informing me that there's an = implementation of SNMPv3 that fits in 4k ;-). PatC ------_=_NextPart_001_01C3AB1F.019FDC8C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Another Way to Think about CAPWAP

BM - The solutions are actually not that different in = performance as the 802.11
message break down needs to happen somewhere, either in the AP, or the = AC. The
difference is that instead of using a cross-technology management = standard
and architecture, the solution you describe proposes a strap-on protocol = in between
the AP and AC.

<PRC> Incorrect. On the AP you need to break down the message, = create a new one, and again when receiving the reply from the AC. This = is not required if you are simply tunneling the mac management packet to = the AC.

--
Such specification
IMO would definitely assist in the goal of defining interoperability, = as
it could definitely leverage AP functionality implemented by the AP
vendor. Conversion of APs to support the interoperability would become = a
simple matter of implementing the translation protocol.  As an = add-on
module it would not require many changes to the 802.11 stack other = than
interface points.

<PRC> I see. I find it rather interesting to note that APs = actually already have an 802.11 stack and not processing them, but = rather tunneling them to a centralized controller will somehow lower = chances of interoperability vs. creating a new protocol stack.

<PRC> Intercepting these packets are calling a function with the = packet so that they get tunneled instead of calling a function to create = a new request doesn't seem like a huge difference in how difficult it is = to implement (in fact, I'd argue that tunneling is safer because you = really can't screw something up - you're simply forwarding the request). = Oh, and tunneling the packets also allows you to automagically handle = any new 802.11 extensions that get created.

<PRC> I guess you can safely assume that I respectfully = disagree.


BM - How do other vendor's AP's and AP managers interoperate with your = system? If they
want to fit in, both AP and management solution vendors would have to = add 802.11
message processing functionality between AP and AC. If a management = standard was used,
management vendors would just need to support the data model (e.g. MIB) = and provide
applications, and AP vendors would just need to extend their data model = (e.g. MIB)
and data model instrumentation. That would seem simpler than repurposing = 802.11 mac
mngmt messages for AP/AC communication, and doing custom hacks in the AP = and the manager.

<PRC> Well other APs don't currently interoperate with my system - = that's kind of the point of the proposed WG. But I think that I = understand your point here. You're proposing SNMP as a method of sending = link layer information to the AC. If this is in fact what you are = saying, I think that there is some gross mis-use of protocol being = proposed here. We need something compact, fast and requires low cpu = overhead. Last time I checked out my switch's SNMPv3 source code, it = really didn't meet any of those three requirements (why do I have a = feeling I'm about to get an e-mail informing me that there's an = implementation of SNMPv3 that fits in 4k ;-).

PatC

------_=_NextPart_001_01C3AB1F.019FDC8C-- From paulo@chantrynetworks.com Fri Nov 14 06:00:22 2003 From: paulo@chantrynetworks.com (Paulo Francisco) Date: Fri, 14 Nov 2003 01:00:22 -0500 Subject: [Lwapp] Another Way to Think about CAPWAP In-Reply-To: Message-ID: <002401c3aa74$989fe5d0$98838182@testarossa> See below -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On = Behalf Of Jim Murphy Sent: Thursday, November 13, 2003 7:02 PM To: James Kempf; Branislav Meandzija; LWAPP Subject: RE: [Lwapp] Another Way to Think about CAPWAP A bit more to add to this argument. Today, ACs are more than = configuration and management devices with respect to their relationship with APs. =20 ACs do user and session managemet. ACs terminate 802.11 control frames = and apply dynamic policy based on load and user specific attributes from = local or backend AAA servers. [PF>] I fail to see why the insistence of "ACs terminate 802.11 control = frames " keeps on being made. This is very restrictive to current 802.11 = technology, so basically it is saying that if in the future some other = technology becomes dominant over 802.11 that CAPWAP will have to = re-specified. In my opinion it would suffice to introduce a message set = to abstract and convey the control set that is really of interest to = central control (AR/AC) and let the AP handle the actual 802.11 message = set. This message set could then simply be remapped at the AP to future = technologies or different protocol types (pardon the reference.. = Bluetooth). This would provide an extendable infrastructure that would = promote re-usability. This would also remove some of the overlap of responsibilities between = CAPWAP/IETF and IEEE.=20 =20 ACs terminate user data streams, possibly applying forwarding policies. The AC may act in a VLAN or Vrouter environment. The access (V)LAN between the AC and the AP may not be the network that the end user (mobile station) actually becomes associated with. =20 I think the objective is to keep APs lightweight, burdening evey AP with = the features listed here or, even more humorously, running these features = over SNMP is a non-starter. =20 [PF>] The only thing being that IEEE does already specify a MIB format = for administering an AP. Pretty much any AP implementation does already = implement such MIB and most likely will in the future. It would simply = suffice to provide a message set for encapsulation of these messages, = thus it would maximize leveraging of existing infrastructure. Plus I'm = afraid that if CAPWAP proceeds with the specification of its own = configuration message set it will be very hard to keep up with future = configuration requirements at the AP. While is fairly easy to add an OID = to an SNMP infrastructure, from what I see of LWAPP specification the = actual message set would have to be extended every time new = functionality is required, such as vendor extensions (because you know = that in the end each AP vendor will have different features that may = require special configuration).=20 Also, we have to re-base our assumptions as to what it means to be = 'lightweight' for an AP. =20 Basically the problem is to try to address the deployment of traditional = APs which are known as 'fat'. What makes these AP's 'fat' is the amount = of features they natively support such as DHCPServer, RadiusClient and = some even have full functional routing stacks in them (RIP/OSPF). That = all adds up to a complex and expensive AP.=20 Therefore the aim of a 'lightweight' AP is to reduce complexity and cost = by removing from the AP as many features as it is possible. This is = accomplished by moving these expensive features to a centralized = controller. Thus if in the end you end up with an AP on which all you = need to deploy is an IP stack, a LWAPP translation app, an SNMP agent = and an 802.11 stack, you've already trimmed most of the 'fat'. Paulo =20 -----Original Message-----=20 From: James Kempf [mailto:kempf@docomolabs-usa.com]=20 Sent: Thu 11/13/2003 12:22 PM=20 To: Branislav Meandzija; LWAPP=20 Cc:=20 Subject: Re: [Lwapp] Another Way to Think about CAPWAP =09 =09 > > But it also shifts hosts from one access point to another to > > achieve load > > balancing. That's a routing-type function. > > > > Not really, as it is just a single hop (AP/Manager) transaction. The =09 That's why I said "routing-type" and not "routing". See Pat's comments = about L2TP in this regard. =09 > only distinguishing factor to typical monitoring and control is the > pseudo real-time nature of this particular AP management aspect. > I've seen SNMP used in pseudo real-time applications like switching > on failover. > =09 Sure. Protocols can be used for whatever people want. I've seen people = in 3GPP advocate using SIP for setting up HTTP sessions. The point is, = some protocols are specifically engineered for specific purposes. And SNMP = was not engineered for routing-type control functions, IMHO. =09 > So, considering that this function is tractable with traditional > monitoring and control and that all other functions are traditional > monitoring and control, I don't see any reason for a new architecture > and protocol. > > That being said, given that SNMP is now on life-support mode and that > NETCONF is in the making as a new configuration protocol, I would = suggest > separating the protocol aspect and the application aspect of this, = and > handling the protocol in the traditional IETF management area, and = the > application (i.e. the MIB or the equivalent) in LWAPP. > =09 Guess we just don't agree here. =09 jak =09 _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp =09 /=06f)+/=06 y=CA=86 Wj Y ~j From paulo@chantrynetworks.com Fri Nov 14 20:44:40 2003 From: paulo@chantrynetworks.com (Paulo Francisco) Date: Fri, 14 Nov 2003 15:44:40 -0500 Subject: [Lwapp] Another Way to Think about CAPWAP In-Reply-To: <55749BC69138654EBBC4C50BA4F556105990A6@AIREMAIL.airespace.com> Message-ID: <008901c3aaf0$7ab178f0$98838182@testarossa> This is a multi-part message in MIME format. ------=_NextPart_000_008A_01C3AAC6.91DB70F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Paulo Francisco Principal Engineer and Founding Architect Team Lead - Network Processor Development T: (905) 567-6900 x231 www.chantrynetworks.com -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Friday, November 14, 2003 2:59 PM To: Jim Murphy; Paulo Francisco; James Kempf; Branislav Meandzija; LWAPP Subject: RE: [Lwapp] Another Way to Think about CAPWAP [PF>] I fail to see why the insistence of "ACs terminate 802.11 control frames " keeps on being made. This is very restrictive to current 802.11 technology, so basically it is saying that if in the future some other technology becomes dominant over 802.11 that CAPWAP will have to re-specified. In my opinion it would suffice to introduce a message set to abstract and convey the control set that is really of interest to central control (AR/AC) and let the AP handle the actual 802.11 message set. This message set could then simply be remapped at the AP to future technologies or different protocol types (pardon the reference.. Bluetooth). This would provide an extendable infrastructure that would promote re-usability. This would also remove some of the overlap of responsibilities between CAPWAP/IETF and IEEE. In the end, you will end up creating a protocol that looks a hell of a lot like the 802.11 mac management protocol. You'll want to auth the user, association indication from the AP to the AC, you'll want the ability to disconnect (or learn about disconnects). All these link layer trigger information is needed by the AC. So I would argue that creating a protocol to provide the information that is already in the 802.11 protocol is silly. We already have what we need - we just need to send it to the AC. [PF>] True, but as demonstrated by DIRAC and a few similar implementations an abstraction protocol is very much doable. While it is true that some of the message set will be pure duplicates of 802.11 messages [and maybe with the current scope of definitions this is definitely true], it does stand to reason that it isn't hard to imagine that other technologies would provide a similar set of functionality (user associate notification, disconnect user, etc) . All it takes is to identify the set of parameters that make sense to an AC (what does it actually need to know) [DIRAC] actions, events and statistics and you should be able to achieve the goal of portability. Such specification IMO would definitely assist in the goal of defining interoperability, as it could definitely leverage AP functionality implemented by the AP vendor. Conversion of APs to support the interoperability would become a simple matter of implementing the translation protocol. As an add-on module it would not require many changes to the 802.11 stack other than interface points. [JM>] An abstract message set is hard to achieve unless you know now the set of protocols you expect to support (and even then it can be hard). It goes beyond merely the content of the messages but issues like the relationship between messages and their sequencing become critical. I do agree that extensibility to other protocols is a good idea. An alternative mechanism to achieve extensibility is that CAPWAP should carry arbitrary protocol packets. The specific protocol being carried is established at initialization time. relationship between messages and sequencing in the CAPWAP model is no different than in the traditional (or should I say legacy? :) AP architecture. We've also discussed extensibility, but the IESG has informed us that it would be a really good idea to keep the scope of the WG smaller, solve the problem, and then if we were successful, extend to other technologies (if the market requires it). PatC ------=_NextPart_000_008A_01C3AAC6.91DB70F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Another Way to Think about CAPWAP

 

 

= Paulo Francisco=
Principal Engineer and Founding Architect
Team Lead – Network Processor Development
T: (905) 567-6900 x231
www.chantrynetworks.com

-----Original = Message-----
From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]
Sent
:
Friday, November 14, = 2003 2:59 PM
To: Jim Murphy; =
Paulo Francisco; James Kempf; Branislav = Meandzija; LWAPP
Subject: RE: [Lwapp] = Another Way to Think about CAPWAP

 

       
=        
[PF>] I fail to see why the insistence of = "ACs terminate 802.11 control frames " keeps on being made. This is very restrictive to current 802.11 technology, so basically it is saying that = if in the future some other technology becomes dominant over 802.11 that = CAPWAP will have to re-specified. In my opinion it would suffice to introduce a = message set to abstract and convey the control set that is really of interest to = central control (AR/AC) and let the AP handle the actual 802.11 message set. = This message set could then simply be remapped at the AP to future = technologies or different protocol types (pardon the reference.. Bluetooth). This would = provide an extendable infrastructure that would promote re-usability.
        This would also remove some = of the overlap of responsibilities between CAPWAP/IETF and IEEE.

<PRC> In the end, you will end up creating a protocol that looks a = hell of a lot like the 802.11 mac management protocol. You'll want to auth = the user, association indication from the AP to the AC, you'll want the ability to disconnect (or learn about disconnects). All these link layer trigger information is needed by the AC. So I would argue that creating a = protocol to provide the information that is already in the 802.11 protocol is silly. = We already have what we need - we just need to send it to the AC.

[PF>] True, but as demonstrated by DIRAC = and a few similar implementations an abstraction protocol is very much doable. = While it is true that some of the message set will be pure duplicates of = 802.11 messages [and maybe with the current scope of definitions this is = definitely true], it does stand to reason that it isn’t hard to imagine that other = technologies would provide a similar set of functionality (user associate = notification, disconnect user, etc)  . = All it takes is to identify the set of parameters that make sense to an AC = (what does it actually need to know) [DIRAC] actions, events and statistics and you = should be able to achieve the goal of portability. Such specification IMO would = definitely assist in the goal of defining interoperability, as it could definitely = leverage AP functionality implemented by the AP vendor. Conversion of APs to support the interoperability would become a = simple matter of implementing the translation protocol.  As an add-on module it would not = require many changes to the 802.11 stack other than interface points. =


        [JM>] An abstract message = set is hard to achieve unless you know now the set of protocols you expect to = support  (and even then it can be hard). It goes = beyond merely the content of the messages but issues like the relationship between = messages and their sequencing become critical. I do agree that extensibility to = other protocols is a good idea. An alternative mechanism to achieve = extensibility is that CAPWAP should carry arbitrary protocol packets. The specific = protocol being carried is established at initialization time.

<PRC> relationship between messages and sequencing in the CAPWAP = model is no different than in the traditional (or should I say legacy? :) AP = architecture.
We've also discussed extensibility, but the IESG has informed us that it = would be a really good idea to keep the scope of the WG smaller, solve the = problem, and then if we were successful, extend to other technologies (if the = market requires it).

PatC

------=_NextPart_000_008A_01C3AAC6.91DB70F0-- From pcalhoun@airespace.com Mon Nov 17 17:48:00 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Mon, 17 Nov 2003 09:48:00 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: <55749BC69138654EBBC4C50BA4F556105990F2@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3AD33.41EB5890 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [PF>] I fail to see why the insistence of "ACs terminate 802.11 control = frames " keeps on being made. This is very restrictive to current 802.11 = technology, so basically it is saying that if in the future some other = technology becomes dominant over 802.11 that CAPWAP will have to = re-specified. In my opinion it would suffice to introduce a message set = to abstract and convey the control set that is really of interest to = central control (AR/AC) and let the AP handle the actual 802.11 message = set. This message set could then simply be remapped at the AP to future = technologies or different protocol types (pardon the reference.. = Bluetooth). This would provide an extendable infrastructure that would = promote re-usability. This would also remove some of the overlap of responsibilities between = CAPWAP/IETF and IEEE.=20 Re-engineering will be required anyways. The next technology will = be significantly different from 802.11, and the options used in 802.11 = mac mgmt messages will most likely not translate to the next technology. = I think that the IESG's request to focus on the problem at hand is a = great idea. Further, if we decide to work on wireless technology 'x', = then we could also use that technology's management frames as well. =20 PatC ------_=_NextPart_001_01C3AD33.41EB5890 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Another Way to Think about CAPWAP

[PF>] I fail to see why the insistence of "ACs = terminate 802.11 control frames " keeps on being made. This is very = restrictive to current 802.11 technology, so basically it is saying that = if in the future some other technology becomes dominant over 802.11 that = CAPWAP will have to re-specified. In my opinion it would suffice to = introduce a message set to abstract and convey the control set that is = really of interest to central control (AR/AC) and let the AP handle the = actual 802.11 message set. This message set could then simply be = remapped at the AP to future technologies or different protocol types = (pardon the reference.. Bluetooth). This would provide an extendable = infrastructure that would promote re-usability.
This would also remove some of the overlap of responsibilities between = CAPWAP/IETF and IEEE.

<PRC> Re-engineering will be required anyways. The next technology = will be significantly different from 802.11, and the options used in = 802.11 mac mgmt messages will most likely not translate to the next = technology. I think that the IESG's request to focus on the problem at = hand is a great idea. Further, if we decide to work on wireless = technology 'x', then we could also use that technology's management = frames as well.

PatC

------_=_NextPart_001_01C3AD33.41EB5890-- From bran@arraycomm.com Mon Nov 17 18:06:42 2003 From: bran@arraycomm.com (Branislav Meandzija) Date: Mon, 17 Nov 2003 10:06:42 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: <200311171807.hAHI7Dft009888@lester.arraycomm.com> BM - The solutions are actually not that different in performance as the 80= 2.11 message break down needs to happen somewhere, either in the AP, or the AC. = The difference is that instead of using a cross-technology management standard and architecture, the solution you describe proposes a strap-on protocol in= between the AP and AC. Incorrect. On the AP you need to break down the message, create a new= one, and again when receiving the reply from the AC. This is not required = if you are simply tunneling the mac management packet to the AC. BM - Do you think the microseconds that this will take will make a differen= ce? -- Such specification IMO would definitely assist in the goal of defining interoperability, as it could definitely leverage AP functionality implemented by the AP vendor. Conversion of APs to support the interoperability would become a simple matter of implementing the translation protocol. As an add-on module it would not require many changes to the 802.11 stack other than interface points. I see. I find it rather interesting to note that APs actually already= have an 802.11 stack and not processing them, but rather tunneling them to= a centralized controller will somehow lower chances of interoperability vs= . creating a new protocol stack. Intercepting these packets are calling a function with the packet so = that they get tunneled instead of calling a function to create a new reques= t doesn't seem like a huge difference in how difficult it is to implement (= in fact, I'd argue that tunneling is safer because you really can't screw s= omething up - you're simply forwarding the request). Oh, and tunneling the = packets also allows you to automagically handle any new 802.11 extensions t= hat get created. I guess you can safely assume that I respectfully disagree. BM - How do other vendor's AP's and AP managers interoperate with your syst= em? If they want to fit in, both AP and management solution vendors would have to add 8= 02.11 message processing functionality between AP and AC. If a management standar= d was used, management vendors would just need to support the data model (e.g. MIB) and= provide applications, and AP vendors would just need to extend their data model (e.= g. MIB) and data model instrumentation. That would seem simpler than repurposing 80= 2.11 mac mngmt messages for AP/AC communication, and doing custom hacks in the AP an= d the manager. Well other APs don't currently interoperate with my system - that's k= ind of the point of the proposed WG. But I think that I understand your poi= nt here. You're proposing SNMP as a method of sending link layer informatio= n to the AC. If this is in fact what you are saying, I think that there is = some gross mis-use of protocol being proposed here. We need something compa= ct, fast and requires low cpu overhead. Last time I checked out my switch's= SNMPv3 source code, it really didn't meet any of those three requirements = (why do I have a feeling I'm about to get an e-mail informing me that there= 's an implementation of SNMPv3 that fits in 4k ;-). BM - Just designing an LWAPP SNMP MIB is a distinct possibility and the sho= rtest path to getting the standard done. Another possibility if there is a = religious war is to start with a separation of the application and the tran= sport aspects here. The main LWAPP RFC would be application. The main trans= port mapping RFC could be LWAPP over SNMP. But perhaps other transport opti= ons could be given? Branislav PatC From pcalhoun@airespace.com Mon Nov 17 18:59:46 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Mon, 17 Nov 2003 10:59:46 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: <55749BC69138654EBBC4C50BA4F556105990F8@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3AD3D.5F1E48E5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Incorrect. On the AP you need to break down the message, create a = new one, and again when receiving the reply from the AC. This is not = required if you are simply tunneling the mac management packet to the = AC. BM - Do you think the microseconds that this will take will make a = difference? Yes... it adds latency, and under load is where you see the = difference. It also requires more engineering work at the IETF to try to = replicate the 802.11 mac management protocol - and make sure that it = keeps up with the various TGs at IEEE. BM - How do other vendor's AP's and AP managers interoperate with your = system? If they want to fit in, both AP and management solution vendors would have to = add 802.11 message processing functionality between AP and AC. If a management = standard was used, management vendors would just need to support the data model (e.g. MIB) = and provide applications, and AP vendors would just need to extend their data model = (e.g. MIB) and data model instrumentation. That would seem simpler than repurposing = 802.11 mac mngmt messages for AP/AC communication, and doing custom hacks in the AP = and the manager. repurposing 802.11 mac messages -> they are used EXACTLY the way = the 802.11-1999 standard specifies. There is no intent to change the = meaning, or behavior, of 802.11. If this is the intent of anyone in this = (proposed) WG, then we should talk. BM - Just designing an LWAPP SNMP MIB is a distinct possibility and the = shortest path to getting the standard done. Another possibility if there = is a religious war is to start with a separation of the application and = the transport aspects here. The main LWAPP RFC would be application. The = main transport mapping RFC could be LWAPP over SNMP. But perhaps other = transport options could be given? Again, the main issue is how to get a state machine that includes = multiple protocols, each with different behaviors and timing = characteristics... and yet make it all work. I just don't see it happen. PatC ------_=_NextPart_001_01C3AD3D.5F1E48E5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Another Way to Think about CAPWAP

<PRC> Incorrect. On the AP you need to break = down the message, create a new one, and again when receiving the reply = from the AC. This is not required if you are simply tunneling the mac = management packet to the AC.

BM - Do you think the microseconds that this will take will make a = difference?

<PRC> Yes... it adds latency, and under load is where you see the = difference. It also requires more engineering work at the IETF to try to = replicate the 802.11 mac management protocol - and make sure that it = keeps up with the various TGs at IEEE.

BM - How do other vendor's AP's and AP managers interoperate with your = system? If they
want to fit in, both AP and management solution vendors would have to = add 802.11
message processing functionality between AP and AC. If a management = standard was used,
management vendors would just need to support the data model (e.g. MIB) = and provide
applications, and AP vendors would just need to extend their data model = (e.g. MIB)
and data model instrumentation. That would seem simpler than repurposing = 802.11 mac
mngmt messages for AP/AC communication, and doing custom hacks in the AP = and the manager.

<PRC> repurposing 802.11 mac messages -> they are used EXACTLY = the way the 802.11-1999 standard specifies. There is no intent to change = the meaning, or behavior, of 802.11. If this is the intent of anyone in = this (proposed) WG, then we should talk.


BM - Just designing an LWAPP SNMP MIB is a distinct possibility and the = shortest path to getting the standard done. Another possibility if there = is a religious war is to start with a separation of the application and = the transport aspects here. The main LWAPP RFC would be application. The = main transport mapping RFC could be LWAPP over SNMP. But perhaps other = transport options could be given?

<PRC> Again, the main issue is how to get a state machine that = includes multiple protocols, each with different behaviors and timing = characteristics... and yet make it all work. I just don't see it = happen.

PatC

------_=_NextPart_001_01C3AD3D.5F1E48E5-- From kempf@docomolabs-usa.com Mon Nov 17 21:55:01 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Mon, 17 Nov 2003 13:55:01 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP References: <55749BC69138654EBBC4C50BA4F556105990B8@AIREMAIL.airespace.com> Message-ID: <042301c3ad55$73467a90$956015ac@dclkempt40> Hi Pat, FWIW, my system works great, we got WiFi certified and are completely interoperable with all clients out there... so I'm not sure that I follow. The nice thing about using the 802.11 mac mgmt messages is that you already have guaranteed interoperability - you're relying on an existing protocol and just processing it in another system. So if the protocol is just a tunnel for 802.11 MAC management messages, why do we need an IETF WG to define a new protocol? The only issue is agreeing what the tunnel should be (IP in IP, IPsec ESP, TLS over UDP, an L2 tunnel, etc.) for interoperability. The functional interface between the AP and AC is where a protocol would be defined, and if it is just a tunnel interface, the functional interface is in the AC, and consists of decoding 802.11 MAC management frames and recoding the responses, which is not a network interface. jak From pcalhoun@airespace.com Mon Nov 17 21:57:26 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Mon, 17 Nov 2003 13:57:26 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: <55749BC69138654EBBC4C50BA4F556105990FF@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3AD55.F92DA37A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So if the protocol is just a tunnel for 802.11 MAC management messages, = why do we need an IETF WG to define a new protocol? The only issue is = agreeing what the tunnel should be (IP in IP, IPsec ESP, TLS over UDP, an L2 = tunnel, etc.) for interoperability. The functional interface between the AP and = AC is where a protocol would be defined, and if it is just a tunnel = interface, the functional interface is in the AC, and consists of decoding 802.11 = MAC management frames and recoding the responses, which is not a network interface. There is also the tunnel setup protocol, which is what LWAPP = basically is. LWAPP also consists of an in-band configuration protocol to the AP - = allowing a state machine to use the same control mechanism from the AC to the AP. PatC ------_=_NextPart_001_01C3AD55.F92DA37A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Another Way to Think about CAPWAP

So if the protocol is just a tunnel for 802.11 MAC = management messages, why
do we need an IETF WG to define a new protocol? The only issue is = agreeing
what the tunnel should be (IP in IP, IPsec ESP, TLS over UDP, an L2 = tunnel,
etc.) for interoperability. The functional interface between the AP and = AC
is where a protocol would be defined, and if it is just a tunnel = interface,
the functional interface is in the AC, and consists of decoding 802.11 = MAC
management frames and recoding the responses, which is not a network
interface.

<PRC> There is also the tunnel setup protocol, which is what LWAPP = basically
is. LWAPP also consists of an in-band configuration protocol to the AP - = allowing
a state machine to use the same control mechanism from the AC to the = AP.

PatC


------_=_NextPart_001_01C3AD55.F92DA37A-- From kempf@docomolabs-usa.com Mon Nov 17 23:11:12 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Mon, 17 Nov 2003 15:11:12 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP References: <55749BC69138654EBBC4C50BA4F556105990FF@AIREMAIL.airespace.com> Message-ID: <049901c3ad60$18a29640$956015ac@dclkempt40> >There is also the tunnel setup protocol, which is what LWAPP basically > is. So considering the alternatives, here is how they would set up: IP in IP - no setup protocol. IPsec - IKE for key exchange, then everything going between the two endpoints to the indicated port is encrypted using ESP. If transport mode is used, there's no tunnel overhead. One could also use the new BEET (Bound End to End Tunnel) mode to reduce transport overhead for tunnel mode, but that is currently somewhat controversial among IETF security folks. TLS over UDP - TLS to set up on the indicated port, then everything is encrypted at the transport layer. L2 tunnel - no setup protocol (so far as I am aware, perhaps 802 has something though). The charter requires an existing tunnel mechanism to be used, so two out of the three would already have a mechanism. Perhaps there are more mechanisms I'm missing? Or is there something else required to set up the tunnel besides agreeing on a port number and encapsulation format? >LWAPP also consists of an in-band configuration protocol to the AP - allowing >a state machine to use the same control mechanism from the AC to the AP. Is this to keep the state machine synchronized between the two sides? Or is there some other reason for it? jak From pcalhoun@airespace.com Mon Nov 17 23:41:41 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Mon, 17 Nov 2003 15:41:41 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: <55749BC69138654EBBC4C50BA4F55610599108@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3AD64.E6B73596 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So considering the alternatives, here is how they would set up: IP in IP - no setup protocol. Not sufficient - we need 802.11 (link layer) triggers. IPsec - IKE for key exchange, then everything going between the two endpoints to the indicated port is encrypted using ESP. If transport = mode is used, there's no tunnel overhead. One could also use the new BEET (Bound = End to End Tunnel) mode to reduce transport overhead for tunnel mode, but = that is currently somewhat controversial among IETF security folks. If you want to run IPSec to protect LWAPP, you could, but this = still doesn't change the fact that you need to send 802.11 frames to the AC, = and these aren't encap'ed directly over IP - so UDP is very convenient. TLS over UDP - TLS to set up on the indicated port, then everything is encrypted at the transport layer. Right... but TLS over UDP is quite rare - in any case, see above. L2 tunnel - no setup protocol (so far as I am aware, perhaps 802 has something though). well, something is required here anyways. You don't want to just = receive any arbitrary frames on a given UDP port. The charter requires an existing tunnel mechanism to be used, so two out = of the three would already have a mechanism. Perhaps there are more = mechanisms I'm missing? Or is there something else required to set up the tunnel besides = agreeing on a port number and encapsulation format? Basically, that's quite close. The protocol used in LWAPP is = 802.11 over UDP, similar to how L2TP works (which is PPP over UDP). Note that the LWAPP protocol is = modeled after the 802.11 protocol - unlike L2TP which is really designed for dial-up (although it = is used for more than just dial-up today). >LWAPP also consists of an in-band configuration protocol to the AP - allowing >a state machine to use the same control mechanism from the AC to the = AP. Is this to keep the state machine synchronized between the two sides? Or = is there some other reason for it? Multiple reasons. One is to push down policies (allow traffic for = a particular MAC address), while others are for configuration reasons (change channel = to x on radio y). PatC ------_=_NextPart_001_01C3AD64.E6B73596 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Another Way to Think about CAPWAP

So considering the alternatives, here is how they = would set up:

IP in IP - no setup protocol.
<PRC> Not sufficient - we need 802.11 (link layer) triggers.

IPsec  - IKE for key exchange, then everything going between the = two
endpoints to the indicated port is encrypted using ESP. If transport = mode is
used, there's no tunnel overhead. One could also use the new BEET (Bound = End
to End Tunnel) mode to reduce transport overhead for tunnel mode, but = that
is currently somewhat controversial among IETF security folks.
<PRC> If you want to run IPSec to protect LWAPP, you could, but = this still
doesn't change the fact that you need to send 802.11 frames to the AC, = and
these aren't encap'ed directly over IP - so UDP is very convenient.

TLS over UDP - TLS to set up on the indicated port, then everything = is
encrypted at the transport layer.
<PRC> Right... but TLS over UDP is quite rare - in any case, see = above.

L2 tunnel - no setup protocol (so far as I am aware, perhaps 802 has
something though).

<PRC> well, something is required here anyways. You don't want to = just receive
any arbitrary frames on a given UDP port.

The charter requires an existing tunnel mechanism to be used, so two out = of
the three would already have a mechanism. Perhaps there are more = mechanisms
I'm missing?

Or is there something else required to set up the tunnel besides = agreeing on
a port number and encapsulation format?

<PRC> Basically, that's quite close. The protocol used in LWAPP is = 802.11 over UDP, similar to
how L2TP works (which is PPP over UDP). Note that the LWAPP protocol is = modeled after the 802.11
protocol - unlike L2TP which is really designed for dial-up (although it = is used for more than
just dial-up today).

>LWAPP also consists of an in-band configuration protocol to the AP = -
allowing
>a state machine to use the same control mechanism from the AC to the = AP.

Is this to keep the state machine synchronized between the two sides? Or = is
there some other reason for it?

<PRC> Multiple reasons. One is to push down policies (allow = traffic for a particular
MAC address), while others are for configuration reasons (change channel = to x on radio y).

PatC

------_=_NextPart_001_01C3AD64.E6B73596-- From kempf@docomolabs-usa.com Tue Nov 18 00:09:26 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Mon, 17 Nov 2003 16:09:26 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP References: <55749BC69138654EBBC4C50BA4F55610599108@AIREMAIL.airespace.com> Message-ID: <051301c3ad68$3a92d050$956015ac@dclkempt40> Basically, that's quite close. The protocol used in LWAPP is 802.11 over UDP, similar to how L2TP works (which is PPP over UDP). Note that the LWAPP protocol is modeled after the 802.11 protocol - unlike L2TP which is really designed for dial-up (although it is used for more than just dial-up today). jak>>Is L2TP tied to PPP or could it be used and/or modified for CAPWAP? Multiple reasons. One is to push down policies (allow traffic for a particular MAC address), while others are for configuration reasons (change channel to x on radio y). jak>>OK. So that means there is still some signaling independent of the tunnel. jak From rkp@intotoinc.com Tue Nov 18 00:18:41 2003 From: rkp@intotoinc.com (Rama Krishna Prasad) Date: Mon, 17 Nov 2003 16:18:41 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP References: <55749BC69138654EBBC4C50BA4F556105990FF@AIREMAIL.airespace.com> <049901c3ad60$18a29640$956015ac@dclkempt40> Message-ID: <15ca01c3ad69$86ee4780$2305010a@SindhuSriha> I think, breaking down the problem into secure transport and signaling/configuration is very good. Secure transport can be achieved by IPSEC/IKE or even L2TPoverIPSEC. This group can concentrate on defining signaling/configuration protocol based on UDP, that is required to signal messages from AP and configuration information from AC to AP. Rama Krishna Intoto Inc. www.intotoinc.com ----- Original Message ----- From: "James Kempf" To: "Pat R. Calhoun" ; "Paulo Francisco" ; "Jim Murphy" ; "Branislav Meandzija" ; "LWAPP" Sent: Monday, November 17, 2003 3:11 PM Subject: Re: [Lwapp] Another Way to Think about CAPWAP > >There is also the tunnel setup protocol, which is what LWAPP basically > > is. > > So considering the alternatives, here is how they would set up: > > IP in IP - no setup protocol. > > IPsec - IKE for key exchange, then everything going between the two > endpoints to the indicated port is encrypted using ESP. If transport mode is > used, there's no tunnel overhead. One could also use the new BEET (Bound End > to End Tunnel) mode to reduce transport overhead for tunnel mode, but that > is currently somewhat controversial among IETF security folks. > > TLS over UDP - TLS to set up on the indicated port, then everything is > encrypted at the transport layer. > > L2 tunnel - no setup protocol (so far as I am aware, perhaps 802 has > something though). > > The charter requires an existing tunnel mechanism to be used, so two out of > the three would already have a mechanism. Perhaps there are more mechanisms > I'm missing? > > Or is there something else required to set up the tunnel besides agreeing on > a port number and encapsulation format? > > >LWAPP also consists of an in-band configuration protocol to the AP - > allowing > >a state machine to use the same control mechanism from the AC to the AP. > > Is this to keep the state machine synchronized between the two sides? Or is > there some other reason for it? > > jak > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp From lily.l.yang@intel.com Tue Nov 18 00:29:27 2003 From: lily.l.yang@intel.com (Yang, Lily L) Date: Mon, 17 Nov 2003 16:29:27 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: <26BDFAFFB541B047B24179002EBE6D27155FD7@orsmsx410.jf.intel.com> BTW, while we are on it, may I ask why UDP is assumed here? I know that is what LWAPP uses, but I don't really know why though. Why isn't reliability needed for LWAPP, given that configuration messages are mission critical for the WLAN operation.=20 -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf Of Rama Krishna Prasad Sent: Monday, November 17, 2003 4:19 PM To: James Kempf; Pat R. Calhoun; Paulo Francisco; Jim Murphy; Branislav Meandzija; LWAPP Subject: Re: [Lwapp] Another Way to Think about CAPWAP I think, breaking down the problem into secure transport and signaling/configuration is very good. Secure transport can be achieved by IPSEC/IKE or even L2TPoverIPSEC. This group can concentrate on defining signaling/configuration protocol based on UDP, that is required to signal messages from AP and configuration information from AC to AP. Rama Krishna Intoto Inc. www.intotoinc.com ----- Original Message -----=20 From: "James Kempf" To: "Pat R. Calhoun" ; "Paulo Francisco" ; "Jim Murphy" ; "Branislav Meandzija" ; "LWAPP" Sent: Monday, November 17, 2003 3:11 PM Subject: Re: [Lwapp] Another Way to Think about CAPWAP > >There is also the tunnel setup protocol, which is what LWAPP basically > > is. > > So considering the alternatives, here is how they would set up: > > IP in IP - no setup protocol. > > IPsec - IKE for key exchange, then everything going between the two > endpoints to the indicated port is encrypted using ESP. If transport mode is > used, there's no tunnel overhead. One could also use the new BEET (Bound End > to End Tunnel) mode to reduce transport overhead for tunnel mode, but that > is currently somewhat controversial among IETF security folks. > > TLS over UDP - TLS to set up on the indicated port, then everything is > encrypted at the transport layer. > > L2 tunnel - no setup protocol (so far as I am aware, perhaps 802 has > something though). > > The charter requires an existing tunnel mechanism to be used, so two out of > the three would already have a mechanism. Perhaps there are more mechanisms > I'm missing? > > Or is there something else required to set up the tunnel besides agreeing on > a port number and encapsulation format? > > >LWAPP also consists of an in-band configuration protocol to the AP - > allowing > >a state machine to use the same control mechanism from the AC to the AP. > > Is this to keep the state machine synchronized between the two sides? Or is > there some other reason for it? > > jak > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From pcalhoun@airespace.com Tue Nov 18 00:32:30 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Mon, 17 Nov 2003 16:32:30 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: <55749BC69138654EBBC4C50BA4F5561059910B@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3AD6B.92D3DF2B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Basically, that's quite close. The protocol used in LWAPP is = 802.11 over UDP, similar to how L2TP works (which is PPP over UDP). Note that the LWAPP protocol is modeled after the 802.11 protocol - unlike L2TP which is really designed for dial-up (although it = is used for more than just dial-up today). jak>>Is L2TP tied to PPP or could it be used and/or modified for CAPWAP? We'd have to look at the call flow - it doesn't work for my = implementation without significant modifications of the L2TP state machine, but that = doesn't mean we shouldn't look at it. Multiple reasons. One is to push down policies (allow traffic for = a particular MAC address), while others are for configuration reasons (change channel = to x on radio y). jak>>OK. So that means there is still some signaling independent of the tunnel. Correct. ------_=_NextPart_001_01C3AD6B.92D3DF2B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Another Way to Think about CAPWAP

<PRC> Basically, that's quite close. The = protocol used in LWAPP is 802.11
over UDP, similar to
how L2TP works (which is PPP over UDP). Note that the LWAPP protocol = is
modeled after the 802.11
protocol - unlike L2TP which is really designed for dial-up (although it = is
used for more than
just dial-up today).

jak>>Is L2TP tied to PPP or could it be used and/or modified for = CAPWAP?

<PRC> We'd have to look at the call flow - it doesn't work for my = implementation
without significant modifications of the L2TP state machine, but that = doesn't mean
we shouldn't look at it.



<PRC> Multiple reasons. One is to push down policies (allow = traffic for a
particular
MAC address), while others are for configuration reasons (change channel = to
x on radio y).

jak>>OK. So that means there is still some signaling independent = of the
tunnel.

<PRC> Correct.


------_=_NextPart_001_01C3AD6B.92D3DF2B-- From pcalhoun@airespace.com Tue Nov 18 00:33:46 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Mon, 17 Nov 2003 16:33:46 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: <55749BC69138654EBBC4C50BA4F5561059910C@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3AD6B.AED7BB6B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think, breaking down the problem into secure transport and = signaling/configuration is very good. Secure transport can be achieved by IPSEC/IKE or even L2TPoverIPSEC. This group can concentrate on defining signaling/configuration protocol = based on UDP, that is required to signal messages from AP and configuration information from = AC to AP. I guess we could just call is WAPP, and drop the "L" :) PatC ------_=_NextPart_001_01C3AD6B.AED7BB6B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Another Way to Think about CAPWAP

I think, breaking down the problem into secure = transport and signaling/configuration
is very good.
Secure transport can be achieved by IPSEC/IKE or even L2TPoverIPSEC.
This group can concentrate on defining signaling/configuration protocol = based on UDP, that is
required to signal messages from AP and configuration information from = AC to AP.

<PRC> I guess we could just call is WAPP, and drop the = "L" :)

PatC

------_=_NextPart_001_01C3AD6B.AED7BB6B-- From pcalhoun@airespace.com Tue Nov 18 00:34:23 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Mon, 17 Nov 2003 16:34:23 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: <55749BC69138654EBBC4C50BA4F5561059910D@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3AD6C.11CC41F2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable BTW, while we are on it, may I ask why UDP is assumed here? I know that is what LWAPP uses, but I don't really know why though. Why isn't reliability needed for LWAPP, given that configuration messages are mission critical for the WLAN operation.=20 Only assumed because of it's wide availability on all embedded operating systems. That's not to say that nothing can change... but it=20 was convenient to use in the discussion PatC ------_=_NextPart_001_01C3AD6C.11CC41F2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Another Way to Think about CAPWAP

BTW, while we are on it, may I ask why UDP is assumed = here? I know that
is what LWAPP uses, but I don't really know why though. Why isn't
reliability needed for LWAPP, given that configuration messages are
mission critical for the WLAN operation.

<PRC> Only assumed because of it's wide availability on all = embedded
operating systems. That's not to say that nothing can change... but = it
was convenient to use in the discussion

PatC

------_=_NextPart_001_01C3AD6C.11CC41F2-- From mmani@avaya.com Tue Nov 18 00:42:54 2003 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Mon, 17 Nov 2003 17:42:54 -0700 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: > -----Original Message----- > From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf > Of James Kempf > Sent: Monday, November 17, 2003 4:09 PM > To: Pat R. Calhoun; Paulo Francisco; Jim Murphy; Branislav Meandzija; > LWAPP > Subject: Re: [Lwapp] Another Way to Think about CAPWAP >=20 >=20 > Basically, that's quite close. The protocol used in LWAPP is 802.11 > over UDP, similar to > how L2TP works (which is PPP over UDP). Note that the LWAPP protocol is > modeled after the 802.11 > protocol - unlike L2TP which is really designed for dial-up (although it > is > used for more than > just dial-up today). >=20 > jak>>Is L2TP tied to PPP or could it be used and/or modified for CAPWAP? >=20 > Multiple reasons. One is to push down policies (allow traffic for a > particular > MAC address), while others are for configuration reasons (change channel > to > x on radio y). >=20 > jak>>OK. So that means there is still some signaling independent of the > tunnel. [Mani, Mahalingam (Mahalingam)]=20 [Mani, Mahalingam (Mahalingam)] you could push that down the tunnel too. Either way - it is still reasonable to expect a frame format definition inside the tunnel to describe the type of frame you are 'tunneling' - including specifications of versioning etc. it still has to be CAPWAP frames over some encapsulation. 1. Some CAPWAP frames are candidates for plain simple tunneling of MAC management frames. 2. Others may be of configuration and control of APs that are directed to AP by AC. 3. Some others may be alert messages originating from AP as a result of some function the AP is commanded to aggregate/threshold event to trigger - possibly. This may be over and above MAC layer function - that can actually let CAPWAP shine over and above what 802.11 MAC offers - in principle. It may also be required as the scope of CAPWAP asks fat APs to provide this info. in an abstracted form. 4. there will, as pointed out by Pat, be a need to discover ACs and negotiate capabilities - if need be. Unless we arrive at a single model=20 that CAPWAP will support. -mani >=20 > jak >=20 > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp From pcalhoun@airespace.com Tue Nov 18 01:02:02 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Mon, 17 Nov 2003 17:02:02 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: <55749BC69138654EBBC4C50BA4F5561059910E@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3AD6F.BE2B723B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We should actually be creating at least 2 separate categories for interchange: Control - Configuration,statistics, events, actions - This could be a TCP based stream to provide immediate indication as to whether the AP-AC connection has been lost. Encrypted if necessary. I guess you'd better provide your definition of immediate, because TCP doesn't provide this. Data - This could be UDP/IP_in_IP encapsulation to avoid congestion. If the packet is lost the original client will most likely re-transmit.=20 Right - so don't forward 802.11 mac mgmt frames, and reconstruct=20 a protocol that does the same thing that 802.11 mac, except extend it for every standard the IEEE publishes. PatC -----Original Message----- From: Yang, Lily L [mailto:lily.l.yang@intel.com]=20 Sent: Monday, November 17, 2003 7:29 PM To: Rama Krishna Prasad; James Kempf; Pat R. Calhoun; Paulo Francisco; Jim Murphy; Branislav Meandzija; LWAPP Subject: RE: [Lwapp] Another Way to Think about CAPWAP BTW, while we are on it, may I ask why UDP is assumed here? I know that is what LWAPP uses, but I don't really know why though. Why isn't reliability needed for LWAPP, given that configuration messages are mission critical for the WLAN operation.=20 -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf Of Rama Krishna Prasad Sent: Monday, November 17, 2003 4:19 PM To: James Kempf; Pat R. Calhoun; Paulo Francisco; Jim Murphy; Branislav Meandzija; LWAPP Subject: Re: [Lwapp] Another Way to Think about CAPWAP I think, breaking down the problem into secure transport and signaling/configuration is very good. Secure transport can be achieved by IPSEC/IKE or even L2TPoverIPSEC. This group can concentrate on defining signaling/configuration protocol based on UDP, that is required to signal messages from AP and configuration information from AC to AP. Rama Krishna Intoto Inc. www.intotoinc.com ----- Original Message -----=20 From: "James Kempf" To: "Pat R. Calhoun" ; "Paulo Francisco" ; "Jim Murphy" ; "Branislav Meandzija" ; "LWAPP" Sent: Monday, November 17, 2003 3:11 PM Subject: Re: [Lwapp] Another Way to Think about CAPWAP > >There is also the tunnel setup protocol, which is what LWAPP basically > > is. > > So considering the alternatives, here is how they would set up: > > IP in IP - no setup protocol. > > IPsec - IKE for key exchange, then everything going between the two > endpoints to the indicated port is encrypted using ESP. If transport mode is > used, there's no tunnel overhead. One could also use the new BEET (Bound End > to End Tunnel) mode to reduce transport overhead for tunnel mode, but that > is currently somewhat controversial among IETF security folks. > > TLS over UDP - TLS to set up on the indicated port, then everything is > encrypted at the transport layer. > > L2 tunnel - no setup protocol (so far as I am aware, perhaps 802 has > something though). > > The charter requires an existing tunnel mechanism to be used, so two out of > the three would already have a mechanism. Perhaps there are more mechanisms > I'm missing? > > Or is there something else required to set up the tunnel besides agreeing on > a port number and encapsulation format? > > >LWAPP also consists of an in-band configuration protocol to the AP - > allowing > >a state machine to use the same control mechanism from the AC to the AP. > > Is this to keep the state machine synchronized between the two sides? Or is > there some other reason for it? > > jak > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp ------_=_NextPart_001_01C3AD6F.BE2B723B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Another Way to Think about CAPWAP

We should actually be creating at least 2 separate = categories for
interchange:
Control - Configuration,statistics, events, actions - This could be = a
TCP based stream to provide immediate indication as to whether the = AP-AC
connection has been lost. Encrypted if necessary.

<PRC> I guess you'd better provide your definition of immediate, = because
TCP doesn't provide this.

Data - This could be UDP/IP_in_IP encapsulation to avoid congestion. = If
the packet is lost the original client will most likely re-transmit.
<PRC> Right - so don't forward 802.11 mac mgmt frames, and = reconstruct
a protocol that does the same thing that 802.11 mac, except extend = it
for every standard the IEEE publishes.

PatC
-----Original Message-----
From: Yang, Lily L [mailto:lily.l.yang@intel.com] Sent: Monday, November 17, 2003 7:29 PM
To: Rama Krishna Prasad; James Kempf; Pat R. Calhoun; Paulo = Francisco;
Jim Murphy; Branislav Meandzija; LWAPP
Subject: RE: [Lwapp] Another Way to Think about CAPWAP

BTW, while we are on it, may I ask why UDP is assumed here? I know = that
is what LWAPP uses, but I don't really know why though. Why isn't
reliability needed for LWAPP, given that configuration messages are
mission critical for the WLAN operation.

-----Original Message-----
From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com<= /A>] On
Behalf Of Rama Krishna Prasad
Sent: Monday, November 17, 2003 4:19 PM
To: James Kempf; Pat R. Calhoun; Paulo Francisco; Jim Murphy; = Branislav
Meandzija; LWAPP
Subject: Re: [Lwapp] Another Way to Think about CAPWAP

I think, breaking down the problem into secure transport and
signaling/configuration
is very good.
Secure transport can be achieved by IPSEC/IKE or even L2TPoverIPSEC.
This group can concentrate on defining signaling/configuration = protocol
based on UDP, that is
required to signal messages from AP and configuration information = from
AC to AP.

Rama Krishna
Intoto Inc.
www.intotoinc.com


----- Original Message -----
From: "James Kempf" <kempf@docomolabs-usa.com>
To: "Pat R. Calhoun" <pcalhoun@airespace.com>; = "Paulo Francisco"
<paulo@chantrynetworks.com>; "Jim Murphy"
<jmurphy@trapezenetworks.com>; "Branislav Meandzija"
<bran@arraycomm.com>; "LWAPP" = <lwapp@frascone.com>
Sent: Monday, November 17, 2003 3:11 PM
Subject: Re: [Lwapp] Another Way to Think about CAPWAP


> >There is also the tunnel setup protocol, which is what = LWAPP
basically
> > is.
>
> So considering the alternatives, here is how they would set up:
>
> IP in IP - no setup protocol.
>
> IPsec  - IKE for key exchange, then everything going between = the two
> endpoints to the indicated port is encrypted using ESP. If = transport
mode is
> used, there's no tunnel overhead. One could also use the new = BEET
(Bound End
> to End Tunnel) mode to reduce transport overhead for tunnel mode, = but
that
> is currently somewhat controversial among IETF security folks.
>
> TLS over UDP - TLS to set up on the indicated port, then everything = is
> encrypted at the transport layer.
>
> L2 tunnel - no setup protocol (so far as I am aware, perhaps 802 = has
> something though).
>
> The charter requires an existing tunnel mechanism to be used, so = two
out of
> the three would already have a mechanism. Perhaps there are = more
mechanisms
> I'm missing?
>
> Or is there something else required to set up the tunnel = besides
agreeing on
> a port number and encapsulation format?
>
> >LWAPP also consists of an in-band configuration protocol to the = AP -
> allowing
> >a state machine to use the same control mechanism from the AC = to the
AP.
>
> Is this to keep the state machine synchronized between the two = sides?
Or is
> there some other reason for it?
>
>           &nb= sp; jak
>
> _______________________________________________
> Lwapp mailing list
> Lwapp@frascone.com
>
http://mail.fras= cone.com/mailman/listinfo/lwapp

_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.fras= cone.com/mailman/listinfo/lwapp





------_=_NextPart_001_01C3AD6F.BE2B723B-- From rkp@intotoinc.com Tue Nov 18 02:16:26 2003 From: rkp@intotoinc.com (Rama Krishna Prasad) Date: Mon, 17 Nov 2003 18:16:26 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP References: <26BDFAFFB541B047B24179002EBE6D27155FD7@orsmsx410.jf.intel.com> Message-ID: <165101c3ad79$fbc86c10$2305010a@SindhuSriha> There are mainly three different types of data that need to go between AP and AC. Discovery related messages, configuration/signaling information and actual data packets. Data packet could be voice data and requires QoS. TCP is not a good transport to transfer this information. For discovery, multicasting is required and TCP is not suitable. For control and signaling data, either TCP or UDP with application reliability can be adapted. Rama Krishna Intoto Inc. www.intotoinc.com ----- Original Message ----- From: "Yang, Lily L" To: "Rama Krishna Prasad" ; "James Kempf" ; "Pat R. Calhoun" ; "Paulo Francisco" ; "Jim Murphy" ; "Branislav Meandzija" ; "LWAPP" Sent: Monday, November 17, 2003 4:29 PM Subject: RE: [Lwapp] Another Way to Think about CAPWAP > BTW, while we are on it, may I ask why UDP is assumed here? I know that > is what LWAPP uses, but I don't really know why though. Why isn't > reliability needed for LWAPP, given that configuration messages are > mission critical for the WLAN operation. > > -----Original Message----- > From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On > Behalf Of Rama Krishna Prasad > Sent: Monday, November 17, 2003 4:19 PM > To: James Kempf; Pat R. Calhoun; Paulo Francisco; Jim Murphy; Branislav > Meandzija; LWAPP > Subject: Re: [Lwapp] Another Way to Think about CAPWAP > > I think, breaking down the problem into secure transport and > signaling/configuration > is very good. > Secure transport can be achieved by IPSEC/IKE or even L2TPoverIPSEC. > This group can concentrate on defining signaling/configuration protocol > based on UDP, that is > required to signal messages from AP and configuration information from > AC to AP. > > Rama Krishna > Intoto Inc. > www.intotoinc.com > > > ----- Original Message ----- > From: "James Kempf" > To: "Pat R. Calhoun" ; "Paulo Francisco" > ; "Jim Murphy" > ; "Branislav Meandzija" > ; "LWAPP" > Sent: Monday, November 17, 2003 3:11 PM > Subject: Re: [Lwapp] Another Way to Think about CAPWAP > > > > >There is also the tunnel setup protocol, which is what LWAPP > basically > > > is. > > > > So considering the alternatives, here is how they would set up: > > > > IP in IP - no setup protocol. > > > > IPsec - IKE for key exchange, then everything going between the two > > endpoints to the indicated port is encrypted using ESP. If transport > mode is > > used, there's no tunnel overhead. One could also use the new BEET > (Bound End > > to End Tunnel) mode to reduce transport overhead for tunnel mode, but > that > > is currently somewhat controversial among IETF security folks. > > > > TLS over UDP - TLS to set up on the indicated port, then everything is > > encrypted at the transport layer. > > > > L2 tunnel - no setup protocol (so far as I am aware, perhaps 802 has > > something though). > > > > The charter requires an existing tunnel mechanism to be used, so two > out of > > the three would already have a mechanism. Perhaps there are more > mechanisms > > I'm missing? > > > > Or is there something else required to set up the tunnel besides > agreeing on > > a port number and encapsulation format? > > > > >LWAPP also consists of an in-band configuration protocol to the AP - > > allowing > > >a state machine to use the same control mechanism from the AC to the > AP. > > > > Is this to keep the state machine synchronized between the two sides? > Or is > > there some other reason for it? > > > > jak > > > > _______________________________________________ > > Lwapp mailing list > > Lwapp@frascone.com > > http://mail.frascone.com/mailman/listinfo/lwapp > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp From lily.l.yang@intel.com Tue Nov 18 02:39:30 2003 From: lily.l.yang@intel.com (Yang, Lily L) Date: Mon, 17 Nov 2003 18:39:30 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: <26BDFAFFB541B047B24179002EBE6D278CAF2D@orsmsx410.jf.intel.com> This seems like a pretty reasonable break down to me. > -----Original Message----- > From: Rama Krishna Prasad [mailto:rkp@intotoinc.com] > Sent: Monday, November 17, 2003 6:16 PM > To: Yang, Lily L; James Kempf; Pat R. Calhoun; Paulo Francisco; Jim > Murphy; Branislav Meandzija; LWAPP > Subject: Re: [Lwapp] Another Way to Think about CAPWAP >=20 >=20 >=20 > There are mainly three different types of data that need to=20 > go between AP and AC. > Discovery related messages, configuration/signaling=20 > information and actual > data packets. Data packet could be voice data and requires=20 > QoS. TCP is not > a good transport to transfer this information. For discovery, > multicasting is required and TCP is not suitable. For control=20 > and signaling data, > either TCP or UDP with application reliability can be adapted. >=20 > Rama Krishna > Intoto Inc. > www.intotoinc.com > ----- Original Message -----=20 > From: "Yang, Lily L" > To: "Rama Krishna Prasad" ; "James Kempf"=20 > ; "Pat R. Calhoun" > ; "Paulo Francisco"=20 > ; "Jim Murphy"=20 > ; "Branislav > Meandzija" ; "LWAPP" > Sent: Monday, November 17, 2003 4:29 PM > Subject: RE: [Lwapp] Another Way to Think about CAPWAP >=20 >=20 > > BTW, while we are on it, may I ask why UDP is assumed here?=20 > I know that > > is what LWAPP uses, but I don't really know why though. Why isn't > > reliability needed for LWAPP, given that configuration messages are > > mission critical for the WLAN operation. > > > > -----Original Message----- > > From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On > > Behalf Of Rama Krishna Prasad > > Sent: Monday, November 17, 2003 4:19 PM > > To: James Kempf; Pat R. Calhoun; Paulo Francisco; Jim=20 > Murphy; Branislav > > Meandzija; LWAPP > > Subject: Re: [Lwapp] Another Way to Think about CAPWAP > > > > I think, breaking down the problem into secure transport and > > signaling/configuration > > is very good. > > Secure transport can be achieved by IPSEC/IKE or even L2TPoverIPSEC. > > This group can concentrate on defining=20 > signaling/configuration protocol > > based on UDP, that is > > required to signal messages from AP and configuration=20 > information from > > AC to AP. > > > > Rama Krishna > > Intoto Inc. > > www.intotoinc.com > > > > > > ----- Original Message -----=20 > > From: "James Kempf" > > To: "Pat R. Calhoun" ; "Paulo Francisco" > > ; "Jim Murphy" > > ; "Branislav Meandzija" > > ; "LWAPP" > > Sent: Monday, November 17, 2003 3:11 PM > > Subject: Re: [Lwapp] Another Way to Think about CAPWAP > > > > > > > >There is also the tunnel setup protocol, which is what LWAPP > > basically > > > > is. > > > > > > So considering the alternatives, here is how they would set up: > > > > > > IP in IP - no setup protocol. > > > > > > IPsec - IKE for key exchange, then everything going=20 > between the two > > > endpoints to the indicated port is encrypted using ESP.=20 > If transport > > mode is > > > used, there's no tunnel overhead. One could also use the new BEET > > (Bound End > > > to End Tunnel) mode to reduce transport overhead for=20 > tunnel mode, but > > that > > > is currently somewhat controversial among IETF security folks. > > > > > > TLS over UDP - TLS to set up on the indicated port, then=20 > everything is > > > encrypted at the transport layer. > > > > > > L2 tunnel - no setup protocol (so far as I am aware,=20 > perhaps 802 has > > > something though). > > > > > > The charter requires an existing tunnel mechanism to be=20 > used, so two > > out of > > > the three would already have a mechanism. Perhaps there are more > > mechanisms > > > I'm missing? > > > > > > Or is there something else required to set up the tunnel besides > > agreeing on > > > a port number and encapsulation format? > > > > > > >LWAPP also consists of an in-band configuration protocol=20 > to the AP - > > > allowing > > > >a state machine to use the same control mechanism from=20 > the AC to the > > AP. > > > > > > Is this to keep the state machine synchronized between=20 > the two sides? > > Or is > > > there some other reason for it? > > > > > > jak > > > > > > _______________________________________________ > > > Lwapp mailing list > > > Lwapp@frascone.com > > > http://mail.frascone.com/mailman/listinfo/lwapp > > > > _______________________________________________ > > Lwapp mailing list > > Lwapp@frascone.com > > http://mail.frascone.com/mailman/listinfo/lwapp > > _______________________________________________ > > Lwapp mailing list > > Lwapp@frascone.com > > http://mail.frascone.com/mailman/listinfo/lwapp >=20 >=20 From pcalhoun@airespace.com Tue Nov 18 03:26:27 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Mon, 17 Nov 2003 19:26:27 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: <55749BC69138654EBBC4C50BA4F55610599114@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3AD84.6E4F807A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I hope this doesn't go out as an HTML attachment... [PF>] Well.. I would hope it wouldn't be quite that bad. I would expect = any future protocols to have some similarity at least in terms of = control functions to those provided by 802.11 . Further, I don't truly = believe that every single aspect of the packet is actual meaningful to = the AC. Some are only meaningful to the AP so why send them up? With = that in mind an abstraction protocol (even if at this point it truly = mimics 802.11 in its payload) may actually be what will keep us from = having to re-design this entire infrastructure next time IEEE introduces = a new protocol and an new access mechanism comes on the market.This = would accomplish true separation between APs and ARs models (even if = you're required to do 802.1d at the APs)=20 =20 Well, having worked on 3 different wireless protocols, I can tell = you without a doubt that they are in fact all quite different. And = furthermore, the session setup involves various technology specific = extensions that the AC really really needs to know about. I would also = argue that if we decide to limit what information makes it to the AC, it = will limit innovation. What is not important to you, is very important = to me (and probably vice versa). As expressed by other participants in this thread, if all we're doing is = defining a transport mechanism for un-translated frames across a medium, = we can then probably simply identify the message set and use a = tried-and-tested existing protocol (with embedded security if need be). OK - shoot. What would that tried and tested protocol be? I mean, you're already going to have to define message sets outside of = the 802.11 specification, particularly for discovery and configuration = so why stop half way? Why not simply finish remapping the rest of the = operations and obtain true separation. How about to get something done faster? Having spent many many = years designing protocols at the IETF, I can tell you that once you've = been on something for 3-4 years, you will wish you'd taken the quicker = approach (of course, assuming the quicker approach works). =20 PatC =20 ------_=_NextPart_001_01C3AD84.6E4F807A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= RE: [Lwapp] Another Way to Think about CAPWAP=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
=0A=
I hope this = doesn't go out as =0A= an HTML attachment...
=0A=

=0A=
[PF>] =0A= Well.. I would hope it wouldn’t be = quite that bad. I =0A= would expect any future protocols to have some similarity at least in = terms of =0A= control functions to those provided by 802.11 = . =0A= Further,  I don’t = truly believe that =0A= every single aspect of the packet is actual meaningful to the AC. Some = are only =0A= meaningful to the AP so why send them up? With that in mind an = abstraction =0A= protocol (even if at this point it truly mimics 802.11 in its payload) = may =0A= actually be what will keep us from having to re-design this entire =0A= infrastructure next time IEEE introduces a new protocol and an new = access =0A= mechanism comes on the market.This would = accomplish =0A= true separation between APs and ARs models (even if you’re required to do = 802.1d at the =0A= APs)
=0A=
 
=0A=
<PRC> =0A= Well, having worked on 3 different wireless protocols, I can tell you = without a =0A= doubt that they are in fact all quite different. And furthermore, the = session =0A= setup involves various technology specific extensions that the AC really = really =0A= needs to know about. I would also argue that if we decide to limit what =0A= information makes it to the AC, it will limit innovation. What is not = important =0A= to you, is very important to me (and probably vice =0A= versa).
=0A=
=0A=
=0A=

As =0A= expressed by other participants in this thread, if all we’re doing = is defining a =0A= transport mechanism for un-translated frames across a medium, we can = then =0A= probably simply identify the message set and use a tried-and-tested = existing =0A= protocol (with embedded security if need be).

=0A=

<PRC> =0A= OK - shoot. What would that tried and tested protocol =0A= be?

=0A=

I =0A= mean, you’re already going to have to define message sets outside = of the 802.11 =0A= specification, particularly for discovery and configuration so why stop = half =0A= way? Why not simply finish remapping the rest of the operations and = obtain true =0A= separation.

=0A=

<PRC> =0A= How about to get something done faster? Having spent many many years = designing =0A= protocols at the IETF, I can tell you that once you've been on something = for 3-4 =0A= years, you will wish you'd taken the quicker approach (of course, = assuming the =0A= quicker approach works).

=0A=

 

=0A=

PatC

=0A=

 

=0A= =0A= =0A= =0A= ------_=_NextPart_001_01C3AD84.6E4F807A-- From paulo@chantrynetworks.com Tue Nov 18 00:39:23 2003 From: paulo@chantrynetworks.com (Paulo Francisco) Date: Mon, 17 Nov 2003 19:39:23 -0500 Subject: [Lwapp] Another Way to Think about CAPWAP In-Reply-To: <26BDFAFFB541B047B24179002EBE6D27155FD7@orsmsx410.jf.intel.com> Message-ID: <00ce01c3ad6c$765ff820$e601a8c0@testarossa> I agree with Lily. We should actually be creating at least 2 separate categories for interchange: Control - Configuration,statistics, events, actions - This could be a TCP based stream to provide immediate indication as to whether the AP-AC connection has been lost. Encrypted if necessary. Data - This could be UDP/IP_in_IP encapsulation to avoid congestion. If the packet is lost the original client will most likely re-transmit. -----Original Message----- From: Yang, Lily L [mailto:lily.l.yang@intel.com] Sent: Monday, November 17, 2003 7:29 PM To: Rama Krishna Prasad; James Kempf; Pat R. Calhoun; Paulo Francisco; Jim Murphy; Branislav Meandzija; LWAPP Subject: RE: [Lwapp] Another Way to Think about CAPWAP BTW, while we are on it, may I ask why UDP is assumed here? I know that is what LWAPP uses, but I don't really know why though. Why isn't reliability needed for LWAPP, given that configuration messages are mission critical for the WLAN operation. -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf Of Rama Krishna Prasad Sent: Monday, November 17, 2003 4:19 PM To: James Kempf; Pat R. Calhoun; Paulo Francisco; Jim Murphy; Branislav Meandzija; LWAPP Subject: Re: [Lwapp] Another Way to Think about CAPWAP I think, breaking down the problem into secure transport and signaling/configuration is very good. Secure transport can be achieved by IPSEC/IKE or even L2TPoverIPSEC. This group can concentrate on defining signaling/configuration protocol based on UDP, that is required to signal messages from AP and configuration information from AC to AP. Rama Krishna Intoto Inc. www.intotoinc.com ----- Original Message ----- From: "James Kempf" To: "Pat R. Calhoun" ; "Paulo Francisco" ; "Jim Murphy" ; "Branislav Meandzija" ; "LWAPP" Sent: Monday, November 17, 2003 3:11 PM Subject: Re: [Lwapp] Another Way to Think about CAPWAP > >There is also the tunnel setup protocol, which is what LWAPP basically > > is. > > So considering the alternatives, here is how they would set up: > > IP in IP - no setup protocol. > > IPsec - IKE for key exchange, then everything going between the two > endpoints to the indicated port is encrypted using ESP. If transport mode is > used, there's no tunnel overhead. One could also use the new BEET (Bound End > to End Tunnel) mode to reduce transport overhead for tunnel mode, but that > is currently somewhat controversial among IETF security folks. > > TLS over UDP - TLS to set up on the indicated port, then everything is > encrypted at the transport layer. > > L2 tunnel - no setup protocol (so far as I am aware, perhaps 802 has > something though). > > The charter requires an existing tunnel mechanism to be used, so two out of > the three would already have a mechanism. Perhaps there are more mechanisms > I'm missing? > > Or is there something else required to set up the tunnel besides agreeing on > a port number and encapsulation format? > > >LWAPP also consists of an in-band configuration protocol to the AP - > allowing > >a state machine to use the same control mechanism from the AC to the AP. > > Is this to keep the state machine synchronized between the two sides? Or is > there some other reason for it? > > jak > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From paulo@chantrynetworks.com Tue Nov 18 01:28:45 2003 From: paulo@chantrynetworks.com (Paulo Francisco) Date: Mon, 17 Nov 2003 20:28:45 -0500 Subject: [Lwapp] Another Way to Think about CAPWAP In-Reply-To: <55749BC69138654EBBC4C50BA4F5561059910E@AIREMAIL.airespace.com> Message-ID: <00de01c3ad73$5c11f1b0$e601a8c0@testarossa> This is a multi-part message in MIME format. ------=_NextPart_000_00DF_01C3AD49.733BE9B0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit We should actually be creating at least 2 separate categories for interchange: Control - Configuration,statistics, events, actions - This could be a TCP based stream to provide immediate indication as to whether the AP-AC connection has been lost. Encrypted if necessary. I guess you'd better provide your definition of immediate, because TCP doesn't provide this. Data - This could be UDP/IP_in_IP encapsulation to avoid congestion. If the packet is lost the original client will most likely re-transmit. Right - so don't forward 802.11 mac mgmt frames, and reconstruct a protocol that does the same thing that 802.11 mac, except extend it for every standard the IEEE publishes. [PF>] Well.. I would hope it wouldn't be quite that bad. I would expect any future protocols to have some similarity at least in terms of control functions to those provided by 802.11 . Further, I don't truly believe that every single aspect of the packet is actual meaningful to the AC. Some are only meaningful to the AP so why send them up? With that in mind an abstraction protocol (even if at this point it truly mimics 802.11 in its payload) may actually be what will keep us from having to re-design this entire infrastructure next time IEEE introduces a new protocol and an new access mechanism comes on the market.This would accomplish true separation between APs and ARs models (even if you're required to do 802.1d at the APs) As expressed by other participants in this thread, if all we're doing is defining a transport mechanism for un-translated frames across a medium, we can then probably simply identify the message set and use a tried-and-tested existing protocol (with embedded security if need be). I mean, you're already going to have to define message sets outside of the 802.11 specification, particularly for discovery and configuration so why stop half way? Why not simply finish remapping the rest of the operations and obtain true separation. PatC -----Original Message----- From: Yang, Lily L [mailto:lily.l.yang@intel.com] Sent: Monday, November 17, 2003 7:29 PM To: Rama Krishna Prasad; James Kempf; Pat R. Calhoun; Paulo Francisco; Jim Murphy; Branislav Meandzija; LWAPP Subject: RE: [Lwapp] Another Way to Think about CAPWAP BTW, while we are on it, may I ask why UDP is assumed here? I know that is what LWAPP uses, but I don't really know why though. Why isn't reliability needed for LWAPP, given that configuration messages are mission critical for the WLAN operation. -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf Of Rama Krishna Prasad Sent: Monday, November 17, 2003 4:19 PM To: James Kempf; Pat R. Calhoun; Paulo Francisco; Jim Murphy; Branislav Meandzija; LWAPP Subject: Re: [Lwapp] Another Way to Think about CAPWAP I think, breaking down the problem into secure transport and signaling/configuration is very good. Secure transport can be achieved by IPSEC/IKE or even L2TPoverIPSEC. This group can concentrate on defining signaling/configuration protocol based on UDP, that is required to signal messages from AP and configuration information from AC to AP. Rama Krishna Intoto Inc. www.intotoinc.com ----- Original Message ----- From: "James Kempf" To: "Pat R. Calhoun" ; "Paulo Francisco" ; "Jim Murphy" ; "Branislav Meandzija" ; "LWAPP" Sent: Monday, November 17, 2003 3:11 PM Subject: Re: [Lwapp] Another Way to Think about CAPWAP > >There is also the tunnel setup protocol, which is what LWAPP basically > > is. > > So considering the alternatives, here is how they would set up: > > IP in IP - no setup protocol. > > IPsec - IKE for key exchange, then everything going between the two > endpoints to the indicated port is encrypted using ESP. If transport mode is > used, there's no tunnel overhead. One could also use the new BEET (Bound End > to End Tunnel) mode to reduce transport overhead for tunnel mode, but that > is currently somewhat controversial among IETF security folks. > > TLS over UDP - TLS to set up on the indicated port, then everything is > encrypted at the transport layer. > > L2 tunnel - no setup protocol (so far as I am aware, perhaps 802 has > something though). > > The charter requires an existing tunnel mechanism to be used, so two out of > the three would already have a mechanism. Perhaps there are more mechanisms > I'm missing? > > Or is there something else required to set up the tunnel besides agreeing on > a port number and encapsulation format? > > >LWAPP also consists of an in-band configuration protocol to the AP - > allowing > >a state machine to use the same control mechanism from the AC to the AP. > > Is this to keep the state machine synchronized between the two sides? Or is > there some other reason for it? > > jak > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp ------=_NextPart_000_00DF_01C3AD49.733BE9B0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Another Way to Think about CAPWAP

 

We should actually be creating at least 2 separate categories = for
interchange:
Control - Configuration,statistics, events, = actions - This could be a
TCP based stream to provide immediate indication as to whether the = AP-AC
connection has been lost. Encrypted if = necessary.

<PRC> I guess you'd better provide your definition of immediate, = because
TCP doesn't provide this.

Data - This could be UDP/IP_in_IP encapsulation to avoid congestion. = If
the packet is lost the original client will most likely re-transmit.
<PRC> Right - so don't forward 802.11 mac mgmt frames, and = reconstruct
a protocol that does the same thing that = 802.11 mac, except extend it
for every standard the IEEE publishes.

[PF>] Well.. I would hope it wouldn’t be = quite that bad. I would expect any future protocols to have some similarity at = least in terms of control functions to those provided by 802.11 . Further,  I don’t truly believe that every single aspect of the packet is = actual meaningful to the AC. Some are only meaningful to the AP so why send = them up? With that in mind an abstraction protocol (even if at this point it truly = mimics 802.11 in its payload) may actually be what will keep us from having to re-design this entire infrastructure next time IEEE introduces a new = protocol and an new access mechanism comes on the market.This would accomplish true separation between APs = and ARs models (even if you’re required to do = 802.1d at the APs) =

As expressed by other participants in this thread, if all we’re doing = is defining a transport mechanism for un-translated frames across a medium, = we can then probably simply identify the message set and use a tried-and-tested existing protocol (with embedded security if need = be).

I mean, you’re already going to have to define message sets outside = of the 802.11 specification, particularly for discovery and configuration so = why stop half way? Why not simply finish remapping the rest of the operations and = obtain true separation.
 
=


PatC
-----Original Message-----
From: Yang, Lily L [mailto:lily.l.yang@intel.com] Sent:
Monday, November 17, = 2003 7:29 = PM
To: Rama Krishna Prasad; James Kempf; Pat R. Calhoun; Paulo = Francisco;
Jim Murphy; Branislav Meandzija; LWAPP
Subject: RE: [Lwapp] Another Way to Think about CAPWAP

BTW, while we are on it, may I ask why UDP is assumed here? I know = that
is what LWAPP uses, but I don't really know why though. Why isn't
reliability needed for LWAPP, given that configuration messages are
mission critical for the WLAN operation.

-----Original Message-----
From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com<= /a>] On
Behalf Of Rama
Krishna Prasad
Sent:
Monday, November 17, = 2003 4:19 = PM
To: James Kempf; Pat R. Calhoun; Paulo Francisco; Jim Murphy; = Branislav
Meandzija; LWAPP
Subject: Re: [Lwapp] Another Way to Think about CAPWAP

I think, breaking down the problem into secure transport and
signaling/configuration
is very good.
Secure transport can be achieved by IPSEC/IKE or even L2TPoverIPSEC.
This group can concentrate on defining signaling/configuration = protocol
based on UDP, that is
required to signal messages from AP and configuration information = from
AC to AP.

Rama
Krishna
Intoto Inc.
www.intotoinc.com


----- Original Message -----
From: "James Kempf" <kempf@docomolabs-usa.com>
To: "Pat R. Calhoun" <pcalhoun@airespace.com>; = "Paulo Francisco"
<paulo@chantrynetworks.com>; "Jim Murphy"
<jmurphy@trapezenetworks.com>; "Branislav Meandzija"
<bran@arraycomm.com>; "LWAPP" = <lwapp@frascone.com>
Sent:
Monday, November 17, = 2003 3:11 = PM
Subject: Re: [Lwapp] Another Way to Think about CAPWAP


> >There is also the tunnel setup protocol, which is what = LWAPP
basically
> > is.
>
> So considering the alternatives, here is how they would set up:
>
> IP in IP - no setup protocol.
>
> IPsec  - IKE for key exchange, then everything going between = the two
> endpoints to the indicated port is encrypted using ESP. If = transport
mode is
> used, there's no tunnel overhead. One could also use the new = BEET
(Bound End
> to End Tunnel) mode to reduce transport overhead for tunnel mode, = but
that
> is currently somewhat controversial among IETF security folks.
>
> TLS over UDP - TLS to set up on the indicated port, then everything = is
> encrypted at the transport layer.
>
> L2 tunnel - no setup protocol (so far as I am aware, perhaps 802 = has
> something though).
>
> The charter requires an existing tunnel mechanism to be used, so = two
out of
> the three would already have a mechanism. Perhaps there are = more
mechanisms
> I'm missing?
>
> Or is there something else required to set up the tunnel = besides
agreeing on
> a port number and encapsulation format?
>
> >LWAPP also consists of an in-band configuration protocol to the = AP -
> allowing
> >a state machine to use the same control mechanism from the AC = to the
AP.
>
> Is this to keep the state machine synchronized between the two = sides?
Or is
> there some other reason for it?
>
>           &nb= sp; jak
>
> _______________________________________________
> Lwapp mailing list
> Lwapp@frascone.com
>
http://mail.fras= cone.com/mailman/listinfo/lwapp

_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.fras= cone.com/mailman/listinfo/lwapp




------=_NextPart_000_00DF_01C3AD49.733BE9B0-- From pcalhoun@airespace.com Tue Nov 18 13:25:26 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Tue, 18 Nov 2003 05:25:26 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: <55749BC69138654EBBC4C50BA4F55610599117@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3ADD7.9495255A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There are mainly three different types of data that need to go between = AP and AC. Discovery related messages, configuration/signaling information and = actual data packets. Data packet could be voice data and requires QoS. TCP is = not a good transport to transfer this information. For discovery, multicasting is required and TCP is not suitable. For control and = signaling data, either TCP or UDP with application reliability can be adapted. For the most part you are correct, but it also depends on the = aggressiveness required for control messages. For instance, if TCP's backoff algorithm = could harm the 802.11 service, then it may not be the right transport. PatC ------_=_NextPart_001_01C3ADD7.9495255A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Another Way to Think about CAPWAP

There are mainly three different types of data that = need to go between AP and AC.
Discovery related messages,  configuration/signaling information = and actual
data packets.  Data packet could be voice data and requires QoS. = TCP is not
a good transport to transfer this information. For discovery,
multicasting is required and TCP is not suitable. For control and = signaling data,
either TCP or UDP with application reliability can be adapted.

<PRC> For the most part you are correct, but it also depends on = the aggressiveness
required for control messages. For instance, if TCP's backoff algorithm = could harm
the 802.11 service, then it may not be the right transport.

PatC

------_=_NextPart_001_01C3ADD7.9495255A-- From esadot@avaya.com Tue Nov 18 14:58:39 2003 From: esadot@avaya.com (Sadot, Emek (Emek)) Date: Tue, 18 Nov 2003 16:58:39 +0200 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C3ADE4.731BC9A1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What is the rational behind pushing policies to the AP? Doesn't = centralizing functionality at the AR level is one of the AR/AP = architecture motivations? Besides doesn't it contradict the "L" concept? = =20 Emek -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com]On = Behalf Of Pat R. Calhoun Sent: Tuesday, 18 November, 2003 1:42 AM To: James Kempf; Paulo Francisco; Jim Murphy; Branislav Meandzija; LWAPP Subject: RE: [Lwapp] Another Way to Think about CAPWAP >LWAPP also consists of an in-band configuration protocol to the AP - allowing >a state machine to use the same control mechanism from the AC to the = AP. Is this to keep the state machine synchronized between the two sides? Or = is there some other reason for it? Multiple reasons. One is to push down policies (allow traffic for = a particular MAC address), while others are for configuration reasons (change channel = to x on radio y). PatC ------_=_NextPart_001_01C3ADE4.731BC9A1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Another Way to Think about CAPWAP
What is the = rational=20 behind pushing policies to the AP? Doesn't centralizing functionality at the AR level is = one of=20 the AR/AP architecture motivations? Besides doesn't it contradict = the "L"=20 concept? 
 
Emek
-----Original Message-----
From: = lwapp-admin@frascone.com=20 [mailto:lwapp-admin@frascone.com]On Behalf Of Pat R.=20 Calhoun
Sent: Tuesday, 18 November, 2003 1:42 = AM
To: James=20 Kempf; Paulo Francisco; Jim Murphy; Branislav Meandzija;=20 LWAPP
Subject: RE: [Lwapp] Another Way to Think about=20 CAPWAP


>LWAPP also consists of an in-band configuration = protocol=20 to the AP -
allowing
>a state machine to use the same control = mechanism from the AC to the AP.

Is this to keep the state = machine=20 synchronized between the two sides? Or is
there some other reason = for=20 it?

<PRC> Multiple reasons. One is to push down policies = (allow=20 traffic for a particular
MAC address), while others are for = configuration=20 reasons (change channel to x on radio=20 y).

PatC

------_=_NextPart_001_01C3ADE4.731BC9A1-- From pcalhoun@airespace.com Tue Nov 18 15:01:28 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Tue, 18 Nov 2003 07:01:28 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: <55749BC69138654EBBC4C50BA4F5561059911D@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3ADE4.F7853961 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Well, for instance, if you look at the LWAPP draft, you can tell the AP = to only allow 802.1x packets for a given mobile station. This minimizes = unnecessary packets to the AC, conserves bandwidth not to mention CPU = cycles in the AC. PatC -----Original Message----- From: Sadot, Emek (Emek) [mailto:esadot@avaya.com] Sent: Tue 11/18/2003 6:58 AM To: Pat R. Calhoun; James Kempf; Paulo Francisco; Jim Murphy; Branislav = Meandzija; LWAPP Subject: RE: [Lwapp] Another Way to Think about CAPWAP =20 What is the rational behind pushing policies to the AP? Doesn't = centralizing functionality at the AR level is one of the AR/AP = architecture motivations? Besides doesn't it contradict the "L" concept? = =20 Emek -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com]On = Behalf Of Pat R. Calhoun Sent: Tuesday, 18 November, 2003 1:42 AM To: James Kempf; Paulo Francisco; Jim Murphy; Branislav Meandzija; LWAPP Subject: RE: [Lwapp] Another Way to Think about CAPWAP >LWAPP also consists of an in-band configuration protocol to the AP - allowing >a state machine to use the same control mechanism from the AC to the = AP. Is this to keep the state machine synchronized between the two sides? Or = is there some other reason for it? Multiple reasons. One is to push down policies (allow traffic for = a particular MAC address), while others are for configuration reasons (change channel = to x on radio y). PatC ------_=_NextPart_001_01C3ADE4.F7853961 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Another Way to Think about CAPWAP

Well, for instance, if you look at the LWAPP draft, = you can tell the AP to only allow 802.1x packets for a given mobile = station. This minimizes unnecessary packets to the AC, conserves = bandwidth not to mention CPU cycles in the AC.

PatC

-----Original Message-----
From: Sadot, Emek (Emek) [mailto:esadot@avaya.com]
Sent: Tue 11/18/2003 6:58 AM
To: Pat R. Calhoun; James Kempf; Paulo Francisco; Jim Murphy; Branislav = Meandzija; LWAPP
Subject: RE: [Lwapp] Another Way to Think about CAPWAP

What is the rational behind pushing policies to the AP? Doesn't = centralizing functionality at the AR level is one of the AR/AP = architecture motivations? Besides doesn't it contradict the = "L" concept?

Emek

-----Original Message-----
From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com<= /A>]On Behalf Of Pat R. Calhoun
Sent: Tuesday, 18 November, 2003 1:42 AM
To: James Kempf; Paulo Francisco; Jim Murphy; Branislav Meandzija; = LWAPP
Subject: RE: [Lwapp] Another Way to Think about CAPWAP




>LWAPP also consists of an in-band configuration protocol to the AP = -
allowing
>a state machine to use the same control mechanism from the AC to the = AP.

Is this to keep the state machine synchronized between the two sides? Or = is
there some other reason for it?

<PRC> Multiple reasons. One is to push down policies (allow = traffic for a particular
MAC address), while others are for configuration reasons (change channel = to x on radio y).

PatC





------_=_NextPart_001_01C3ADE4.F7853961-- From jmoisand@juniper.net Tue Nov 18 15:52:45 2003 From: jmoisand@juniper.net (Jerome Moisand) Date: Tue, 18 Nov 2003 10:52:45 -0500 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C3ADEC.0236BE16 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I've been monitoring this thread for a while. Quite a lively = discussion... ;-) =20 I'm speaking as somebody with experience about large BRAS deployment = (working for Juniper Networks), and thinking that it might a natural = extension for a RAS system to act as an AR (as explained in the original = LWAPP write-ups if I remember well). =20 I think we have to be very careful not to reinvent the wheel. =20 I absolutely agree with the view that discovery & = configuration/signaling (what I would call a control plane) should be = cleanly separate from a data plane (user data being forwarded). Such = control/data separation has been proven a wise architectural construct = in many many contexts... =20 I absolutely agree with that the data plane is very = performance-sensititive (cf. multimedia/VoIP traffic down the road), and = should be based on a STANDARD form of IP tunneling technique (there are = more than enough to choose from). I'm not 100% sure encryption is an = absolute requirement for such tunneling, but I can see why this might be = interesting as an option. I would definitely let 802.11-specific = encryption (WEP, TKIP, AES, etc) occur in the AP, since it's applicable = only on the 802.11 (MAC) network segment, and requires very specific = hardware. =20 So it seems to me that the main task here (after selecting one tunneling = protocol or another - preferably a light one-) is to work on the control = plane. Here we have a RAS-like device (the AR) controlling a light = access device (the AP in this case). This is clearly a new concept, = which may (but not necessarily) require a new protocol. Spelling out = requirements for such "inband" control protocol should help refine the = problem, before jumping to specifications. =20 I can't help but think that such RAS<->AccessDevice scenario is not = specific to WiFi/802.11. Please read again the e-mail I sent to you guys = a while ago on this topic... For your information, while you guys were = meeting at IETF last week, there was a push in the DSL-Forum (also last = week!) to have a similar control mechanism between a BRAS and a DSLAM = (another form of a layer2 access device).=20 =20 So I tend to believe we should have a fairly generic control protocol, = and then some form of information model on top of it to define = technology-specific objects to be conveyed... I don't believe there = would be that many policy objects for WiFi "light" APs. In this respect, = the SNMP idea which was discussed is interesting, although this is = likely at odds with performance and simplicity (notably on the AR/RAS = side) requirements (SNMP proponents, please don't flame me, just = expressing my view). Yet, thinking to the use of a management protocol = for such "inband" control has definite merits, as long as it is = "transactional-enough and simple-enough".=20 =20 Bottomline: let me suggest to cleanly separate control plane & data = plane as a starting principle; then to not start much of = yet-another-raging-protocol-debate, but come back to spelling out = requirements first. =20 Tx Jerome =20 -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com]On = Behalf Of Pat R. Calhoun Sent: Tuesday, November 18, 2003 8:25 AM To: Rama Krishna Prasad; Yang, Lily L; James Kempf; Paulo Francisco; Jim = Murphy; Branislav Meandzija; LWAPP Subject: RE: [Lwapp] Another Way to Think about CAPWAP There are mainly three different types of data that need to go between = AP and AC. Discovery related messages, configuration/signaling information and = actual data packets. Data packet could be voice data and requires QoS. TCP is = not a good transport to transfer this information. For discovery, multicasting is required and TCP is not suitable. For control and = signaling data, either TCP or UDP with application reliability can be adapted. For the most part you are correct, but it also depends on the = aggressiveness required for control messages. For instance, if TCP's backoff algorithm = could harm the 802.11 service, then it may not be the right transport. PatC=20 ------_=_NextPart_001_01C3ADEC.0236BE16 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Another Way to Think about CAPWAP
I've=20 been monitoring this thread for a while. Quite a lively = discussion... =20 ;-)
 
I'm=20 speaking as somebody with experience about large BRAS deployment = (working for=20 Juniper Networks), and thinking that it might a natural extension for a = RAS=20 system to act as an AR (as explained in the original LWAPP write-ups if = I=20 remember well).
 
I=20 think we have to be very careful not to reinvent the = wheel.
 
I=20 absolutely agree with the view that discovery & = configuration/signaling=20 (what I would call a control plane) should be cleanly separate from a = data plane=20 (user data being forwarded). Such control/data separation has been = proven a wise=20 architectural construct in many many contexts...
 
I=20 absolutely agree with that the data plane is very = performance-sensititive (cf.=20 multimedia/VoIP traffic down the road), and should be based on a = STANDARD form=20 of IP tunneling technique (there are more than enough to choose from). = I'm not=20 100% sure encryption is an absolute requirement for such tunneling, but = I can=20 see why this might be interesting as an option. I would definitely let=20 802.11-specific encryption (WEP, TKIP, AES, etc) occur in the AP, since = it's=20 applicable only on the 802.11 (MAC) network segment, and requires = very=20 specific hardware.
 
So it=20 seems to me that the main task here (after selecting one tunneling = protocol or=20 another - preferably a light one-) is to work on the control plane. Here = we have=20 a RAS-like device (the AR) controlling a light access device (the AP in = this=20 case). This is clearly a new concept, which may (but not necessarily) = require a=20 new protocol. Spelling out requirements for such "inband" control = protocol=20 should help refine the problem, before jumping to=20 specifications.
 
I=20 can't help but think that such RAS<->AccessDevice scenario is not = specific=20 to WiFi/802.11. Please read again the e-mail I sent to you guys a while = ago on=20 this topic... For your information, while you guys were meeting at IETF = last=20 week, there was a push in the DSL-Forum (also last week!) to have a = similar=20 control mechanism between a BRAS and a DSLAM (another form of a layer2 = access=20 device).
 
So I=20 tend to believe we should have a fairly generic control protocol, and = then some=20 form of information model on top of it to define technology-specific = objects to=20 be conveyed... I don't believe there would be that many policy objects = for WiFi=20 "light" APs. In this respect, the SNMP idea which was discussed is = interesting,=20 although this is likely at odds with performance and simplicity (notably = on the=20 AR/RAS side) requirements (SNMP proponents, please don't flame me, just=20 expressing my view). Yet, thinking to the use of a management protocol = for such=20 "inband" control has definite merits, as long as it is = "transactional-enough and=20 simple-enough".
 
Bottomline: let me suggest to cleanly = separate control=20 plane & data plane as a starting principle; then to not start much = of=20 yet-another-raging-protocol-debate, but come back to spelling out = requirements=20 first.
 
Tx
Jerome
 

-----Original=20 Message-----
From: lwapp-admin@frascone.com=20 [mailto:lwapp-admin@frascone.com]On Behalf Of Pat R.=20 Calhoun
Sent: Tuesday, November 18, 2003 8:25 AM
To: = Rama=20 Krishna Prasad; Yang, Lily L; James Kempf; Paulo Francisco; Jim Murphy;=20 Branislav Meandzija; LWAPP
Subject: RE: [Lwapp] Another Way to = Think=20 about CAPWAP

There are mainly three different types of data that = need to go=20 between AP and AC.
Discovery related messages, =20 configuration/signaling information and actual
data packets.  = Data=20 packet could be voice data and requires QoS. TCP is not
a good = transport to=20 transfer this information. For discovery,
multicasting is required = and TCP=20 is not suitable. For control and signaling data,
either TCP or UDP = with=20 application reliability can be adapted.

<PRC> For the = most part=20 you are correct, but it also depends on the aggressiveness
required = for=20 control messages. For instance, if TCP's backoff algorithm could = harm
the=20 802.11 service, then it may not be the right = transport.

PatC
=20

------_=_NextPart_001_01C3ADEC.0236BE16-- From mmani@avaya.com Tue Nov 18 16:09:15 2003 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Tue, 18 Nov 2003 09:09:15 -0700 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C3ADEE.4FDFBD61 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It is fair to summarize in discussions so far that the behavior of AP-AC communication should be such as to preserve the aggregate behavior of AP-AC as a a. 802.11 MAC (a given) a. Reliability of the forwarded mgmt./control frames should be preserved across the AP-AC hop (inasmuch as the AP may have already signaled the successful reception of the frame to the sending client it should not break the guarantees the 802.11 semantics imply). b. Likewise - client data frames will need to be as consistent AP path-component - its reliability depends on the entire data path. For that matter this data may/not go through the AC. b. 802.11 AP. This needs some qualification though seems very obvious as well. a. This should not result in latencies or jitter on the data-plane as a result of the separation beyond acceptable for the additional hop(s) - if any. b. Control/discovery/provisioning and other traffic that may be purely between AP<->AC should be non-real-time enough not to require timing constraints. c. In cases such time-sensitive real-time functions do relegate to AC - constraints on AP-AC topology should be quantifiable (such as number of hops or latency of the AP-AC stretch). More? -mani -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf Of Pat R. Calhoun Sent: Tuesday, November 18, 2003 5:25 AM To: Rama Krishna Prasad; Yang, Lily L; James Kempf; Paulo Francisco; Jim Murphy; Branislav Meandzija; LWAPP Subject: RE: [Lwapp] Another Way to Think about CAPWAP There are mainly three different types of data that need to go between AP and AC. Discovery related messages, configuration/signaling information and actual data packets. Data packet could be voice data and requires QoS. TCP is not a good transport to transfer this information. For discovery, multicasting is required and TCP is not suitable. For control and signaling data, either TCP or UDP with application reliability can be adapted. For the most part you are correct, but it also depends on the aggressiveness required for control messages. For instance, if TCP's backoff algorithm could harm the 802.11 service, then it may not be the right transport. PatC=20 ------_=_NextPart_001_01C3ADEE.4FDFBD61 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Another Way to Think about CAPWAP

It is fair to = summarize in discussions so far that the behavior of AP-AC communication should be such as to preserve the aggregate behavior of AP-AC as = a

a.      = 802.11 MAC (a = given)
a.      Reliability of the forwarded mgmt./control frames should be preserved across the AP-AC = hop (inasmuch as the AP may = have = already signaled the successful reception of the frame to the sending = client it = should not = break the guarantees the 802.11 semantics imply).

b.      Likewise = client = data frames will need to = be as consistent AP path-component its = reliability = depends on the = entire data path. = For that matter this data may/not = go through the AC.

b.      802.11 AP.

      This needs some qualification though = seems very obvious as well.

a.      This should not result in latencies or jitter on the data-plane as a result of the separation beyond acceptable for the additional = hop(s) = if any.

b.      Control/discovery/provisioning and other traffic that may be purely between = AP<->AC = should = be non-real-time enough not to require timing = constraints.

c.      In cases such time-sensitive real-time functions do relegate to = AC constraints on AP-AC topology should be quantifiable (such as number of hops or latency of the AP-AC stretch).

      More?

-mani

-----Original Message-----
From: lwapp-admin@frascone.com = [
mailto:lwapp-admin@frascone.com<= /A>] On Behalf = Of = Pat R. Calhoun
Sent: Tuesday, November 18, = 2003 5:25 AM
To: Rama Krishna Prasad; = Yang, Lily L; James Kempf; Paulo Francisco; Jim Murphy; Branislav = Meandzija; LWAPP
Subject: RE: [Lwapp] Another Way to Think about = CAPWAP

There are mainly three different types of data that need to go between AP and = AC.
Discovery related messages,  configuration/signaling information = and actual
data packets.  Data packet could be voice data and requires QoS. = TCP is not
a good transport to transfer this inform
ation. For discovery,
multicasting is required and TCP is not suitable. For control and = signaling data,
either TCP or UDP with application reliability can be adapted.

<PRC> For the most part you are correct, but it also depends on = the aggressiveness
requi
red for control messages. For instance, = if TCP's backoff algorithm could harm
the 802.11 service, then it may not be the right transport.

PatC

------_=_NextPart_001_01C3ADEE.4FDFBD61-- From esadot@avaya.com Tue Nov 18 16:17:48 2003 From: esadot@avaya.com (Sadot, Emek (Emek)) Date: Tue, 18 Nov 2003 18:17:48 +0200 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C3ADEF.81B6C7F5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable That's precisely against the light and centralizing-functionality = concepts. Simply put, instead of "only" encapsulating 802.11 frames and send them = over to the AC the AP shall inspect frames and performs lookup tables. = The AP becomes non-light in terms of Cpu-duties and memory space. Centralizing functionality is also spoiled - the AC will need to = download the entire rules list to all APs. Update rules would become an = issue as well, since distribution is needed now. Furthermore, complexity is added to the user notification scheme. CAPWAP = protocol will need to support AP to AC notification of such "rejecting = due to policy X" event. And last, saving "unnecessary packets, conserves bandwidth and CPU = cycles" is still to be proven, since distribution of policy rules to APs = and AP to AC notification demands the same resources.=20 Emek (BTW, allow traffic from a particular MAC address at the AP is = especially odd since STA's association and authentication are, in any = case, subject to the AC approval).=20 -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Tuesday, 18 November, 2003 5:01 PM To: Sadot, Emek (Emek); James Kempf; Paulo Francisco; Jim Murphy; = Branislav Meandzija; LWAPP Subject: RE: [Lwapp] Another Way to Think about CAPWAP Well, for instance, if you look at the LWAPP draft, you can tell the AP = to only allow 802.1x packets for a given mobile station. This minimizes = unnecessary packets to the AC, conserves bandwidth not to mention CPU = cycles in the AC. PatC -----Original Message----- From: Sadot, Emek (Emek) [ mailto:esadot@avaya.com] Sent: Tue 11/18/2003 6:58 AM To: Pat R. Calhoun; James Kempf; Paulo Francisco; Jim Murphy; Branislav = Meandzija; LWAPP Subject: RE: [Lwapp] Another Way to Think about CAPWAP What is the rational behind pushing policies to the AP? Doesn't = centralizing functionality at the AR level is one of the AR/AP = architecture motivations? Besides doesn't it contradict the "L" concept? Emek -----Original Message----- From: lwapp-admin@frascone.com [ mailto:lwapp-admin@frascone.com]On = Behalf Of Pat R. Calhoun Sent: Tuesday, 18 November, 2003 1:42 AM To: James Kempf; Paulo Francisco; Jim Murphy; Branislav Meandzija; LWAPP Subject: RE: [Lwapp] Another Way to Think about CAPWAP >LWAPP also consists of an in-band configuration protocol to the AP - allowing >a state machine to use the same control mechanism from the AC to the = AP. Is this to keep the state machine synchronized between the two sides? Or = is there some other reason for it? Multiple reasons. One is to push down policies (allow traffic for = a particular MAC address), while others are for configuration reasons (change channel = to x on radio y). PatC ------_=_NextPart_001_01C3ADEF.81B6C7F5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Another Way to Think about CAPWAP

That's precisely = against the light=20 and centralizing-functionality concepts.

Simply put, instead of = “only”=20 encapsulating 802.11 frames and send them over to the AC the AP shall = inspect=20 frames and performs lookup tables. The AP becomes non-light in terms of=20 Cpu-duties and memory space.

Centralizing = functionality is also=20 spoiled - the AC will need to download the entire rules list to all APs. Update = rules would=20 become an issue as well, since distribution is needed = now.

Furthermore, complexity = is added to=20 the user notification scheme. CAPWAP protocol will need to support AP to = AC=20 notification of such “rejecting due to policy=20 X” event.

And last,=20 saving “unnecessary = packets, conserves=20 bandwidth and CPU = cycles” is still to be proven, since = distribution of policy rules to APs and AP to AC = notification=20 demands the same resources.

Emek

(BTW, allow = traffic from a=20 particular MAC address at the AP is especially odd since STA’s = association and=20 authentication are, in any case, subject to the AC approval). =

-----Original=20 Message-----
From: Pat R. Calhoun=20 [mailto:pcalhoun@airespace.com]
Sent: Tuesday, 18 November, = 2003 5:01=20 PM
To: Sadot, Emek (Emek); James Kempf; Paulo Francisco; Jim = Murphy;=20 Branislav Meandzija; LWAPP
Subject: RE: [Lwapp] Another Way to = Think=20 about CAPWAP

Well, for instance, if you look at the LWAPP draft, = you can=20 tell the AP to only allow 802.1x packets for a given mobile station. = This=20 minimizes unnecessary packets to the AC, conserves bandwidth not to = mention=20 CPU cycles in the AC.

PatC

-----Original = Message-----
From:=20 Sadot, Emek (Emek) [mailto:esadot@avaya.com
]
Sent: = Tue=20 11/18/2003 6:58 AM
To: Pat R. Calhoun; James Kempf; Paulo = Francisco; Jim=20 Murphy; Branislav Meandzija; LWAPP
Subject: RE: [Lwapp] Another Way = to=20 Think about CAPWAP

What is the rational behind pushing policies = to the=20 AP? Doesn't centralizing functionality at the AR level is one of the = AR/AP=20 architecture motivations? Besides doesn't it contradict the "L"=20 concept?

Emek

-----Original Message-----
From:=20 lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com<= /A>]On=20 Behalf Of Pat R. Calhoun
Sent: Tuesday, 18 November, 2003 1:42 = AM
To:=20 James Kempf; Paulo Francisco; Jim Murphy; Branislav Meandzija;=20 LWAPP
Subject: RE: [Lwapp] Another Way to Think about=20 CAPWAP




>LWAPP also consists of an in-band = configuration=20 protocol to the AP -
allowing
>a state machine to use the = same=20 control mechanism from the AC to the AP.

Is this to keep the = state=20 machine synchronized between the two sides? Or is
there some other = reason=20 for it?

<PRC> Multiple reasons. One is to push down = policies=20 (allow traffic for a particular
MAC address), while others are for=20 configuration reasons (change channel to x on radio=20 = y).

PatC





------_=_NextPart_001_01C3ADEF.81B6C7F5-- From pcalhoun@airespace.com Tue Nov 18 16:31:40 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Tue, 18 Nov 2003 08:31:40 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: <55749BC69138654EBBC4C50BA4F55610599122@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3ADF1.71BDAA50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Simply put, instead of "only" encapsulating 802.11 frames and send them = over to the AC the AP shall inspect frames and performs lookup tables. = The AP becomes non-light in terms of Cpu-duties and memory space. So just using LWAPP as an *example*, there are very few policies = which are intended to guard the AC from unnecessary packets. So before = the Add-Mobile message is sent by the AC, the AP will only accept 802.11 = mac mgmt packets from the client. Once associated, the AC will send an = Add-Mobile to the AP with a specific policy. The policies are very = straight forward, allow everything, allow 802.1x, allow nothing. If you = believe that inspecting a SNAP protocol id is too heavy weight, then we = should discuss this, but personally, I like to conserve my AC as much as = I can. Centralizing functionality is also spoiled - the AC will need to = download the entire rules list to all APs. Update rules would become an = issue as well, since distribution is needed now. well, you are really overloading this. Look at the above process. = It's rather simple. Furthermore, complexity is added to the user notification scheme. CAPWAP = protocol will need to support AP to AC notification of such "rejecting = due to policy X" event. And last, saving "unnecessary packets, conserves bandwidth and CPU = cycles" is still to be proven, since distribution of policy rules to APs = and AP to AC notification demands the same resources.=20 Before I reply to this, I will let you reply to the above. Once I = understand your position I will respond. ------_=_NextPart_001_01C3ADF1.71BDAA50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Another Way to Think about CAPWAP

Simply put, instead of "only" encapsulating = 802.11 frames and send them over to the AC the AP shall inspect frames = and performs lookup tables. The AP becomes non-light in terms of = Cpu-duties and memory space.

<PRC> So just using LWAPP as an *example*, there are very few = policies which are intended to guard the AC from unnecessary packets. So = before the Add-Mobile message is sent by the AC, the AP will only accept = 802.11 mac mgmt packets from the client. Once associated, the AC will = send an Add-Mobile to the AP with a specific policy. The policies are = very straight forward, allow everything, allow 802.1x, allow nothing. If = you believe that inspecting a SNAP protocol id is too heavy weight, then = we should discuss this, but personally, I like to conserve my AC as much = as I can.


Centralizing functionality is also spoiled - the AC will need to = download the entire rules list to all APs. Update rules would become an = issue as well, since distribution is needed now.

<PRC> well, you are really overloading this. Look at the above = process. It's rather simple.

Furthermore, complexity is added to the user notification scheme. CAPWAP = protocol will need to support AP to AC notification of such = "rejecting due to policy X" event.

And last, saving "unnecessary packets, conserves bandwidth and CPU = cycles" is still to be proven, since distribution of policy rules = to APs and AP to AC notification demands the same resources.

<PRC> Before I reply to this, I will let you reply to the above. = Once I understand your position I will respond.

------_=_NextPart_001_01C3ADF1.71BDAA50-- From lily.l.yang@intel.com Tue Nov 18 20:50:26 2003 From: lily.l.yang@intel.com (Yang, Lily L) Date: Tue, 18 Nov 2003 12:50:26 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: <26BDFAFFB541B047B24179002EBE6D27155FDD@orsmsx410.jf.intel.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3AE15.982A0E73 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think separating the user data aggregation/forwarding function from the configuration/mgmt function is a good idea and it also allows more flexibility in the network topologies - e.g., there might be multiple routers for a given WLAN network, each of them takes on the responsibility of aggregating and forwarding data traffic for APs (& STAs), and there might be one or two (for redundancy) controller than runs the control plane functions for all the APs in the network. I believe this is also why AC (access controller) is a much better terminology than AR (Access router).=20 With this separation, CAPWAP can focus only on the control/provisioning part of this network. 802.11 management frames can be part of this communication if we decide to tunnel them directly.=20 =20 I also want to point out that a general in-band protocol is being developed at IETF ForCES (Forwarding and Control Element Separation) with a framework that separate the base protocol from the information element (which is called in Forwarding Element Model). The current architecture document has some high level introduction and analysis on ForCES in Section 5. But I agree with Jerome (and the current charter) that we should be focusing on the requirements and architecture at the moment, without too much assumptions on any specific protocol solution.=20 =20 -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf Of Jerome Moisand Sent: Tuesday, November 18, 2003 7:53 AM To: LWAPP Subject: RE: [Lwapp] Another Way to Think about CAPWAP =20 I've been monitoring this thread for a while. Quite a lively discussion... ;-) =20 I'm speaking as somebody with experience about large BRAS deployment (working for Juniper Networks), and thinking that it might a natural extension for a RAS system to act as an AR (as explained in the original LWAPP write-ups if I remember well). =20 I think we have to be very careful not to reinvent the wheel. =20 I absolutely agree with the view that discovery & configuration/signaling (what I would call a control plane) should be cleanly separate from a data plane (user data being forwarded). Such control/data separation has been proven a wise architectural construct in many many contexts... =20 I absolutely agree with that the data plane is very performance-sensititive (cf. multimedia/VoIP traffic down the road), and should be based on a STANDARD form of IP tunneling technique (there are more than enough to choose from). I'm not 100% sure encryption is an absolute requirement for such tunneling, but I can see why this might be interesting as an option. I would definitely let 802.11-specific encryption (WEP, TKIP, AES, etc) occur in the AP, since it's applicable only on the 802.11 (MAC) network segment, and requires very specific hardware. =20 So it seems to me that the main task here (after selecting one tunneling protocol or another - preferably a light one-) is to work on the control plane. Here we have a RAS-like device (the AR) controlling a light access device (the AP in this case). This is clearly a new concept, which may (but not necessarily) require a new protocol. Spelling out requirements for such "inband" control protocol should help refine the problem, before jumping to specifications. =20 I can't help but think that such RAS<->AccessDevice scenario is not specific to WiFi/802.11. Please read again the e-mail I sent to you guys a while ago on this topic... For your information, while you guys were meeting at IETF last week, there was a push in the DSL-Forum (also last week!) to have a similar control mechanism between a BRAS and a DSLAM (another form of a layer2 access device).=20 =20 So I tend to believe we should have a fairly generic control protocol, and then some form of information model on top of it to define technology-specific objects to be conveyed... I don't believe there would be that many policy objects for WiFi "light" APs. In this respect, the SNMP idea which was discussed is interesting, although this is likely at odds with performance and simplicity (notably on the AR/RAS side) requirements (SNMP proponents, please don't flame me, just expressing my view). Yet, thinking to the use of a management protocol for such "inband" control has definite merits, as long as it is "transactional-enough and simple-enough".=20 =20 Bottomline: let me suggest to cleanly separate control plane & data plane as a starting principle; then to not start much of yet-another-raging-protocol-debate, but come back to spelling out requirements first. =20 Tx Jerome =20 -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com]On Behalf Of Pat R. Calhoun Sent: Tuesday, November 18, 2003 8:25 AM To: Rama Krishna Prasad; Yang, Lily L; James Kempf; Paulo Francisco; Jim Murphy; Branislav Meandzija; LWAPP Subject: RE: [Lwapp] Another Way to Think about CAPWAP There are mainly three different types of data that need to go between AP and AC. Discovery related messages, configuration/signaling information and actual data packets. Data packet could be voice data and requires QoS. TCP is not a good transport to transfer this information. For discovery, multicasting is required and TCP is not suitable. For control and signaling data, either TCP or UDP with application reliability can be adapted. =09 For the most part you are correct, but it also depends on the aggressiveness required for control messages. For instance, if TCP's backoff algorithm could harm the 802.11 service, then it may not be the right transport. =09 PatC=20 ------_=_NextPart_001_01C3AE15.982A0E73 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Another Way to Think about CAPWAP

I think separating the user data = aggregation/forwarding function from the configuration/mgmt function is a good idea and it also = allows more flexibility in the network topologies – e.g., there might be multiple routers for a given WLAN network, each of them takes on the responsibility of aggregating and forwarding data traffic for APs (& = STAs), and there might be one or two (for redundancy) controller than runs the = control plane functions for all the APs in the network. I believe this is also = why AC (access controller) is a much better terminology than AR (Access = router).

With this separation, CAPWAP can = focus only on the control/provisioning part of this network. 802.11 management = frames can be part of this communication if we decide to tunnel them directly. =

 

I also want to point out that a = general in-band protocol is being developed at IETF ForCES (Forwarding and Control Element = Separation) with a framework that separate the base protocol from the information element (which is called in Forwarding Element Model). The = current architecture document has some high level introduction and analysis on = ForCES in Section 5. But I agree with Jerome (and the current charter) that we = should be focusing on the requirements and architecture at the moment, without = too much assumptions on any specific protocol solution.

 

-----Original = Message-----
From: = lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On = Behalf Of Jerome Moisand
Sent: Tuesday, November = 18, 2003 7:53 AM
To: LWAPP
Subject: RE: [Lwapp] = Another Way to Think about CAPWAP

 

I've been = monitoring this thread for a while. Quite a lively discussion...  = ;-)

 

I'm speaking as = somebody with experience about large BRAS deployment (working for Juniper = Networks), and thinking that it might a natural extension for a RAS system to act as an = AR (as explained in the original LWAPP write-ups if I remember = well).

 

I think we have = to be very careful not to reinvent the wheel.

 

I absolutely = agree with the view that discovery & configuration/signaling (what I would call = a control plane) should be cleanly separate from a data plane (user data = being forwarded). Such control/data separation has been proven a wise = architectural construct in many many contexts...

 

I absolutely = agree with that the data plane is very performance-sensititive (cf. multimedia/VoIP traffic down the road), and should be based on a STANDARD form of IP = tunneling technique (there are more than enough to choose from). I'm not 100% sure encryption is an absolute requirement for such tunneling, but I can see = why this might be interesting as an option. I would definitely let = 802.11-specific encryption (WEP, TKIP, AES, etc) occur in the AP, since it's applicable = only on the 802.11 (MAC) network segment, and requires very specific = hardware.

 

So it seems to = me that the main task here (after selecting one tunneling protocol or another - preferably a light one-) is to work on the control plane. Here we have a RAS-like device (the AR) controlling a light access device (the AP in = this case). This is clearly a new concept, which may (but not necessarily) = require a new protocol. Spelling out requirements for such "inband" = control protocol should help refine the problem, before jumping to = specifications.

 

I can't help but = think that such RAS<->AccessDevice scenario is not specific to = WiFi/802.11. Please read again the e-mail I sent to you guys a while ago on this = topic... For your information, while you guys were meeting at IETF last week, = there was a push in the DSL-Forum (also last week!) to have a similar control mechanism between a BRAS and a DSLAM (another form of a layer2 access = device).

 

So I tend to = believe we should have a fairly generic control protocol, and then some form of information model on top of it to define technology-specific objects to = be conveyed... I don't believe there would be that many policy objects for = WiFi "light" APs. In this respect, the SNMP idea which was = discussed is interesting, although this is likely at odds with performance and = simplicity (notably on the AR/RAS side) requirements (SNMP proponents, please don't = flame me, just expressing my view). Yet, thinking to the use of a management = protocol for such "inband" control has definite merits, as long as it = is "transactional-enough and simple-enough".

 

Bottomline: let = me suggest to cleanly separate control plane & data plane as a starting principle; then to not start much of yet-another-raging-protocol-debate, = but come back to spelling out requirements first.

 

Tx<= /p>

Jerome

 


-----Original Message-----
From: = lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com]On Behalf Of Pat R. Calhoun
Sent: Tuesday, November = 18, 2003 8:25 AM
To: Rama Krishna Prasad; = Yang, Lily L; James Kempf; Paulo Francisco; Jim Murphy; Branislav Meandzija; = LWAPP
Subject: RE: [Lwapp] = Another Way to Think about CAPWAP

There are mainly three different types of = data that need to go between AP and AC.
Discovery related messages,  configuration/signaling information = and actual
data packets.  Data packet could be voice data and requires QoS. = TCP is not
a good transport to transfer this information. For discovery,
multicasting is required and TCP is not suitable. For control and = signaling data,
either TCP or UDP with application reliability can be adapted.

<PRC> For the most part you are correct, but it also depends on = the aggressiveness
required for control messages. For instance, if TCP's backoff algorithm = could harm
the 802.11 service, then it may not be the right transport.

PatC

=00 ------_=_NextPart_001_01C3AE15.982A0E73-- From kempf@docomolabs-usa.com Tue Nov 18 22:32:49 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Tue, 18 Nov 2003 14:32:49 -0800 Subject: Architecture v.s. Protocol (was: Re: [Lwapp] Another Way to Think about CAPWAP) References: <26BDFAFFB541B047B24179002EBE6D27155FDD@orsmsx410.jf.intel.com> Message-ID: <086801c3ae23$e72f7000$956015ac@dclkempt40> >But I agree with Jerome (and the current charter) >that we should be focusing on the requirements and architecture at the >moment, without too much assumptions on any specific protocol solution. That is what the current charter says. If we want the WG to get chartered, we need to clarify the problem statement and work on refining the architecture. jak From bob@airespace.com Tue Nov 18 22:50:18 2003 From: bob@airespace.com (Bob O'Hara) Date: Tue, 18 Nov 2003 14:50:18 -0800 Subject: [Lwapp] Polishing the problem statement Message-ID: <55749BC69138654EBBC4C50BA4F556107336@AIREMAIL.airespace.com> After the discussion at the BoF, are there comments on the content of the problem statement that should be incorporated at this time? =20 -Bob Bob O'Hara 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 =20 From esadot@avaya.com Wed Nov 19 10:25:56 2003 From: esadot@avaya.com (Sadot, Emek (Emek)) Date: Wed, 19 Nov 2003 12:25:56 +0200 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C3AE87.849B5EA1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I see your point. I have considered "policy" in the wider context. Still I am not sure embedding policy, even straightforward, in the AP is = desirable. One may consider allow/deny/allow-802.1x-only as sufficient, = whereas other would like (for example) more granularity over 802.1x (i.e = allow/deny TLS/TTLS/MD5/etc) or differentiating authentication methods = (WEP/802.1x/etc'). Maybe it would be better to restrict policy to be enforced at the AC = than to open the door at the AP. More specific question: why having deny policy for a specific station = over rejecting its association in the first place? =20 Emek -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Tuesday, 18 November, 2003 6:32 PM To: Sadot, Emek (Emek); James Kempf; Paulo Francisco; Jim Murphy; = Branislav Meandzija; LWAPP Subject: RE: [Lwapp] Another Way to Think about CAPWAP Simply put, instead of "only" encapsulating 802.11 frames and send them = over to the AC the AP shall inspect frames and performs lookup tables. = The AP becomes non-light in terms of Cpu-duties and memory space. So just using LWAPP as an *example*, there are very few policies = which are intended to guard the AC from unnecessary packets. So before = the Add-Mobile message is sent by the AC, the AP will only accept 802.11 = mac mgmt packets from the client. Once associated, the AC will send an = Add-Mobile to the AP with a specific policy. The policies are very = straight forward, allow everything, allow 802.1x, allow nothing. If you = believe that inspecting a SNAP protocol id is too heavy weight, then we = should discuss this, but personally, I like to conserve my AC as much as = I can. Centralizing functionality is also spoiled - the AC will need to = download the entire rules list to all APs. Update rules would become an = issue as well, since distribution is needed now. well, you are really overloading this. Look at the above process. = It's rather simple. Furthermore, complexity is added to the user notification scheme. CAPWAP = protocol will need to support AP to AC notification of such "rejecting = due to policy X" event. And last, saving "unnecessary packets, conserves bandwidth and CPU = cycles" is still to be proven, since distribution of policy rules to APs = and AP to AC notification demands the same resources. Before I reply to this, I will let you reply to the above. Once I = understand your position I will respond. ------_=_NextPart_001_01C3AE87.849B5EA1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Another Way to Think about CAPWAP
I see your point. I have considered "policy" in the = wider=20 context.

Still I am not sure embedding policy, even = straightforward,=20 in the AP is desirable. One may = consider=20 allow/deny/allow-802.1x-only as sufficient, whereas other would like = (for=20 example) more granularity over 802.1x = (i.e=20 allow/deny TLS/TTLS/MD5/etc) or = differentiating=20 authentication methods (WEP/802.1x/etc').

Maybe it would be better to restrict policy to be=20 enforced at the AC than to open the door at the AP.

More specific question: why having deny policy for a = specific=20 station over rejecting its association = in the=20 first place?

 
Emek
-----Original Message-----
From: Pat R. Calhoun=20 [mailto:pcalhoun@airespace.com]
Sent: Tuesday, 18 November, = 2003=20 6:32 PM
To: Sadot, Emek (Emek); James Kempf; Paulo = Francisco; Jim=20 Murphy; Branislav Meandzija; LWAPP
Subject: RE: [Lwapp] = Another Way=20 to Think about CAPWAP


Simply put, instead of "only" encapsulating 802.11 = frames and=20 send them over to the AC the AP shall inspect frames and performs = lookup=20 tables. The AP becomes non-light in terms of Cpu-duties and memory=20 space.

<PRC> So just using LWAPP as an *example*, there = are very=20 few policies which are intended to guard the AC from unnecessary = packets. So=20 before the Add-Mobile message is sent by the AC, the AP will only = accept=20 802.11 mac mgmt packets from the client. Once associated, the AC will = send an=20 Add-Mobile to the AP with a specific policy. The policies are very = straight=20 forward, allow everything, allow 802.1x, allow nothing. If you believe = that=20 inspecting a SNAP protocol id is too heavy weight, then we should = discuss=20 this, but personally, I like to conserve my AC as much as I=20 can.


Centralizing functionality is also spoiled - the AC = will need=20 to download the entire rules list to all APs. Update rules would = become an=20 issue as well, since distribution is needed now.

<PRC> = well, you=20 are really overloading this. Look at the above process. It's rather=20 simple.

Furthermore, complexity is added to the user = notification=20 scheme. CAPWAP protocol will need to support AP to AC notification of = such=20 "rejecting due to policy X" event.

And last, saving = "unnecessary=20 packets, conserves bandwidth and CPU cycles" is still to be proven, = since=20 distribution of policy rules to APs and AP to AC notification demands = the same=20 resources.

<PRC> Before I reply to this, I will let you = reply to=20 the above. Once I understand your position I will=20 respond.

------_=_NextPart_001_01C3AE87.849B5EA1-- From esadot@avaya.com Wed Nov 19 10:52:32 2003 From: esadot@avaya.com (Sadot, Emek (Emek)) Date: Wed, 19 Nov 2003 12:52:32 +0200 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C3AE8B.3B9FACF7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IP in IP, along with any other non-L4 protocols (TCP/UDP) are not = desirable due to the possibility of crossing NAT device. Reassembling and fragmenting ability needs to be embedded in the AP and = AC as well. =20 Emek =20 ----- Original Message ----- From: "James Kempf" To: "Pat R. Calhoun" ; "Paulo Francisco" ; "Jim Murphy" ; "Branislav Meandzija" ; "LWAPP" Sent: Monday, November 17, 2003 3:11 PM Subject: Re: [Lwapp] Another Way to Think about CAPWAP > >There is also the tunnel setup protocol, which is what LWAPP basically > > is. > > So considering the alternatives, here is how they would set up: > > IP in IP - no setup protocol. > > IPsec - IKE for key exchange, then everything going between the two > endpoints to the indicated port is encrypted using ESP. If transport mode is > used, there's no tunnel overhead. One could also use the new BEET (Bound End > to End Tunnel) mode to reduce transport overhead for tunnel mode, but that > is currently somewhat controversial among IETF security folks. > > TLS over UDP - TLS to set up on the indicated port, then everything is > encrypted at the transport layer. > > L2 tunnel - no setup protocol (so far as I am aware, perhaps 802 has > something though). > > The charter requires an existing tunnel mechanism to be used, so two out of > the three would already have a mechanism. Perhaps there are more mechanisms > I'm missing? > > Or is there something else required to set up the tunnel besides agreeing on > a port number and encapsulation format? > > >LWAPP also consists of an in-band configuration protocol to the AP - > allowing > >a state machine to use the same control mechanism from the AC to the AP. > > Is this to keep the state machine synchronized between the two sides? Or is > there some other reason for it? > > jak > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp ------_=_NextPart_001_01C3AE8B.3B9FACF7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Another Way to Think about CAPWAP
IP in IP, along with any other = non-L4=20 protocols (TCP/UDP) are not desirable due to the possibility of crossing = NAT=20 device.
Reassembling=20 and fragmenting ability needs to be embedded in the AP = and AC as=20 well.
 
Emek
 
-----=20 Original Message -----
From: "James Kempf"=20 <kempf@docomolabs-usa.com>
To: "Pat R. Calhoun"=20 <pcalhoun@airespace.com>; "Paulo=20 Francisco"
<paulo@chantrynetworks.com>; "Jim=20 Murphy"
<jmurphy@trapezenetworks.com>; "Branislav=20 Meandzija"
<bran@arraycomm.com>; "LWAPP"=20 <lwapp@frascone.com>
Sent: Monday, = November 17,=20 2003=20 3:11 PM
Subject: Re: [Lwapp] Another Way to Think = about=20 CAPWAP


> >There is also the tunnel setup protocol, = which is=20 what LWAPP
basically
> > is.
>
> So considering = the=20 alternatives, here is how they would set up:
>
> IP in IP - = no setup=20 protocol.
>
> IPsec  - IKE for key exchange, then = everything=20 going between the two
> endpoints to the indicated port is = encrypted using=20 ESP. If transport
mode is
> used, there's no tunnel overhead. = One could=20 also use the new BEET
(Bound End
> to End Tunnel) mode to = reduce=20 transport overhead for tunnel mode, but
that
> is currently = somewhat=20 controversial among IETF security folks.
>
> TLS over UDP - = TLS to=20 set up on the indicated port, then everything is
> encrypted at = the=20 transport layer.
>
> L2 tunnel - no setup protocol (so far = as I am=20 aware, perhaps 802 has
> something though).
>
> The = charter=20 requires an existing tunnel mechanism to be used, so two
out = of
> the=20 three would already have a mechanism. Perhaps there are=20 more
mechanisms
> I'm missing?
>
> Or is there = something=20 else required to set up the tunnel besides
agreeing on
> a port = number=20 and encapsulation format?
>
> >LWAPP also consists of an = in-band=20 configuration protocol to the AP -
> allowing
> >a state = machine=20 to use the same control mechanism from the AC to = the
AP.
>
> Is=20 this to keep the state machine synchronized between the two sides?
Or = is
> there some other reason for=20 it?
>
>         =    =20 jak
>
> = _______________________________________________
>=20 Lwapp mailing list
> Lwapp@frascone.com
> http://mail.fras= cone.com/mailman/listinfo/lwapp

______________________________= _________________
Lwapp=20 mailing list
Lwapp@frascone.com
http://mail.fras= cone.com/mailman/listinfo/lwapp


------_=_NextPart_001_01C3AE8B.3B9FACF7-- From pcalhoun@airespace.com Wed Nov 19 13:48:44 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Wed, 19 Nov 2003 05:48:44 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: <55749BC69138654EBBC4C50BA4F5561083FF86@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3AEA4.217B46F4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I see your point. I have considered "policy" in the wider context. Still I am not sure embedding policy, even straightforward, in the AP is = desirable. One may consider allow/deny/allow-802.1x-only as sufficient, = whereas other would like (for example) more granularity over 802.1x (i.e = allow/deny TLS/TTLS/MD5/etc) or differentiating authentication methods = (WEP/802.1x/etc'). actually, WEP is a policy that is supported in a particular = protocol ;-). The issue here is that encryption is available and cheap = on the AP (it's part of the standard shipping 802.11 chips out there). = Doing it in the AC requires custom hardware - which is not ruled out, = but does complicate implementations significantly. So you can view a WEP = key for a station as a specific policy as well. Maybe it would be better to restrict policy to be enforced at the AC = than to open the door at the AP. See above - increases complexity and cost of AC for no reason. More specific question: why having deny policy for a specific station = over rejecting its association in the first place? Actually I added that one for free - it's not in any protocol that = I know of, but was an example. =20 PatC ------_=_NextPart_001_01C3AEA4.217B46F4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Another Way to Think about CAPWAP

I see your point. I have considered "policy" = in the wider context.

Still I am not sure embedding policy, even straightforward, in the AP is = desirable. One may consider allow/deny/allow-802.1x-only as sufficient, = whereas other would like (for example) more granularity over 802.1x (i.e = allow/deny TLS/TTLS/MD5/etc) or differentiating authentication methods = (WEP/802.1x/etc').

<PRC> actually, WEP is a policy that is supported in a particular = protocol ;-). The issue here is that encryption is available and cheap = on the AP (it's part of the standard shipping 802.11 chips out there). = Doing it in the AC requires custom hardware - which is not ruled out, = but does complicate implementations significantly. So you can view a WEP = key for a station as a specific policy as well.

Maybe it would be better to restrict policy to be enforced at the AC = than to open the door at the AP.

<PRC> See above - increases complexity and cost of AC for no = reason.

More specific question: why having deny policy for a specific station = over rejecting its association in the first place?

<PRC> Actually I added that one for free - it's not in any = protocol that I know of, but was an example.

PatC

------_=_NextPart_001_01C3AEA4.217B46F4-- From jmurphy@trpz.com Tue Nov 18 19:02:34 2003 From: jmurphy@trpz.com (Jim Murphy) Date: Tue, 18 Nov 2003 11:02:34 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP References: <55749BC69138654EBBC4C50BA4F55610599117@AIREMAIL.airespace.com> Message-ID: <3FBA6CCA.2020106@trpz.com> Pat R. Calhoun wrote: > There are mainly three different types of data that need to go between > AP and AC. > Discovery related messages, configuration/signaling information and > actual > data packets. Data packet could be voice data and requires QoS. TCP > is not > a good transport to transfer this information. For discovery, > multicasting is required and TCP is not suitable. For control and > signaling data, > either TCP or UDP with application reliability can be adapted. > > For the most part you are correct, but it also depends on the > aggressiveness > required for control messages. For instance, if TCP's backoff > algorithm could harm > the 802.11 service, then it may not be the right transport. > TCP is not what you want due to head of line blocking. Jim > > > PatC > From jmoisand@juniper.net Wed Nov 19 18:15:00 2003 From: jmoisand@juniper.net (Jerome Moisand) Date: Wed, 19 Nov 2003 13:15:00 -0500 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: Explain? TCP works real well as the transport for COPS, which is one of the most real-time & transactional control protocols which has been defined so far, I believe. And is used in real-life deployment for policy control with tens of policy decisions per second and the management of o(100k) policy objects. Not sure to see the fundamental difference (except that APs would clearly have much less policy/control objects to deal with). -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com]On Behalf Of Jim Murphy Sent: Tuesday, November 18, 2003 2:03 PM To: Pat R. Calhoun Cc: Rama Krishna Prasad; Yang, Lily L; James Kempf; Paulo Francisco; Jim Murphy; Branislav Meandzija; LWAPP Subject: Re: [Lwapp] Another Way to Think about CAPWAP Pat R. Calhoun wrote: > There are mainly three different types of data that need to go between > AP and AC. > Discovery related messages, configuration/signaling information and=20 > actual > data packets. Data packet could be voice data and requires QoS. TCP=20 > is not > a good transport to transfer this information. For discovery, > multicasting is required and TCP is not suitable. For control and=20 > signaling data, > either TCP or UDP with application reliability can be adapted. > > For the most part you are correct, but it also depends on the=20 > aggressiveness > required for control messages. For instance, if TCP's backoff=20 > algorithm could harm > the 802.11 service, then it may not be the right transport. > TCP is not what you want due to head of line blocking. Jim > > > PatC > _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From bob@airespace.com Wed Nov 19 18:37:41 2003 From: bob@airespace.com (Bob O'Hara) Date: Wed, 19 Nov 2003 10:37:41 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP Message-ID: <55749BC69138654EBBC4C50BA4F5561085510E@AIREMAIL.airespace.com> I see your point. I have considered "policy" in the wider context. Still I am not sure embedding policy, even straightforward, in the AP is desirable. One may consider allow/deny/allow-802.1x-only as sufficient, whereas other would like (for example) more granularity over 802.1x (i.e allow/deny TLS/TTLS/MD5/etc) or differentiating authentication methods (WEP/802.1x/etc'). actually, WEP is a policy that is supported in a particular protocol ;-). The issue here is that encryption is available and cheap on the AP (it's part of the standard shipping 802.11 chips out there). Doing it in the AC requires custom hardware - which is not ruled out, but does complicate implementations significantly. So you can view a WEP key for a station as a specific policy as well. > In addition to the points made by Pat, an AP before CAPWAP already implements many or all of these policies. Removing some of them will "lighten" the AP. Maybe it would be better to restrict policy to be enforced at the AC than to open the door at the AP. See above - increases complexity and cost of AC for no reason. > I think this is a very bad idea. Allowing unfiltered traffic to travel over an arbitrary number of links between the AP and AC is putting an unnecessary traffic load on those links that could easily be filtered at the edge. More specific question: why having deny policy for a specific station over rejecting its association in the first place? Actually I added that one for free - it's not in any protocol that I know of, but was an example. PatC=20 Bob O'Hara From cchaplin@sj.symbol.com Wed Nov 19 18:47:16 2003 From: cchaplin@sj.symbol.com (Clint Chaplin) Date: Wed, 19 Nov 2003 10:47:16 -0800 Subject: [Lwapp] Charter queries Message-ID: I'm coming late to this discussion; sorry. The point that is made below in #1 (split-AP) architecture is an interestin= g theoretical discussion. However, the fact is, there are already = shipping products that have made the decision to put most of the functional= ity in the AC. Was this a wise or correct decision? Hard to tell right = now. But it would be nice to make sure the various implementations = interoperated. Is there a procedure in IETF to go straight to standard status if there = already exists two interoperating independent implementations before IETF = work starts? Even if some people feel that the architecture is flawed? Clint (JOATMON) Chaplin >>> "Saravanan Govindan" 11/11/03 20:00:40 >>> Dear All, I just went through the CAPWAP charter, drafts and have a few fundamental questions. 1. Regarding the split-AP architecture, I am wondering if this is a viable long-term solution to the question of large wireless LANs. If the AC is to manage non-real time, data transport and authentication issues, it is = going to have to deal with a lot of functions/state for a lot of APs. This would increase the processing load, overhead and complexity at the AC. Would = such a model be scalable and therefore be easy to deploy and operate over the long-run? 2. I remember reading in a previous version of one of the CAPWAP I-Ds that APs are now starting to include some IP functionality. With such new capabilities, why not push for more functionality at the APs? Then each AP would have greater control of itself and this would be inherently = scalable. 3. In essence, greater functionality at the APs would lead to a distributed= architecture where each AP is in charge of itself. Of course this would = also give rise to the need for some means of collaboration between the APs. = Since APs are now IP devices (has this been decided as absolute?) their interaction becomes more of an IETF issue. Also, by allowing APs to manage themselves the need for an AC diminishes and therefore AP-AC security = issues become moot. 4. The problem statement mentions maintaining a consistent code base = running on all the APs. I got the impression that this is too restrictive. If standard control functions have been defined, then their implementions should not affect their actual functionality. 5. I am not sure I understood the issue of authorizing access points. If = it is about illegitimate APs connecting to a legitimate network (I am = assuming a wired link here) isn't this more of a physical security issue, i.e., one where the points of connections to the legitimate network are to be = secured? This also refers to the Rogue AP/AR issues in the LWAPP I-D. I look forward to your comments. Cheers, Saravanan _______________________________________________ Lwapp mailing list Lwapp@frascone.com=20 http://mail.frascone.com/mailman/listinfo/lwapp=20 ________________________________________________________________________ This email has been scanned for computer viruses. From jmurphy@trapezenetworks.com Wed Nov 19 18:45:51 2003 From: jmurphy@trapezenetworks.com (Jim Murphy) Date: Wed, 19 Nov 2003 10:45:51 -0800 Subject: [Lwapp] Another Way to Think about CAPWAP References: Message-ID: <3FBBBA5F.3090805@trapezenetworks.com> Jerome Moisand wrote: > Explain? > To the AC each station session is an independent state machine. The state machine moves from state to state as messages are passed between the station and the AC. With a datagram based protocol as LWAPP is currently specified, the loss of a packet will effect only the station associated with the lost packet. With a streaming protocol, and assuming a singe TCP session between the AC and AP, all stations are effected (blocked) by a single dropped packet. The effects of a dropped or late packet are more widespread with TCP. A separate TCP session per station does not scale well. This problem has been studied in great detail for carrying telephony signalling over IP networks. A protocol called SCTP was eventually developed to solve this problem. SCTP would be appropriate for this application as well. See sigtran for more information. Thanks, Jim > TCP works real well as the transport for COPS, which is one of the most > real-time & transactional control protocols which has been defined so > far, I believe. And is used in real-life deployment for policy control > with tens of policy decisions per second and the management of o(100k) > policy objects. > > Not sure to see the fundamental difference (except that APs would > clearly have much less policy/control objects to deal with). > > -----Original Message----- > From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com]On > Behalf Of Jim Murphy > Sent: Tuesday, November 18, 2003 2:03 PM > To: Pat R. Calhoun > Cc: Rama Krishna Prasad; Yang, Lily L; James Kempf; Paulo Francisco; Jim > Murphy; Branislav Meandzija; LWAPP > Subject: Re: [Lwapp] Another Way to Think about CAPWAP > > > > > Pat R. Calhoun wrote: > > >>There are mainly three different types of data that need to go between >> > >>AP and AC. >>Discovery related messages, configuration/signaling information and >>actual >>data packets. Data packet could be voice data and requires QoS. TCP >>is not >>a good transport to transfer this information. For discovery, >>multicasting is required and TCP is not suitable. For control and >>signaling data, >>either TCP or UDP with application reliability can be adapted. >> >> For the most part you are correct, but it also depends on the >>aggressiveness >>required for control messages. For instance, if TCP's backoff >>algorithm could harm >>the 802.11 service, then it may not be the right transport. >> >> > > TCP is not what you want due to head of line blocking. > > Jim > > >> >>PatC >> >> > > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > > From kempf@docomolabs-usa.com Wed Nov 19 19:15:36 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Wed, 19 Nov 2003 11:15:36 -0800 Subject: [Lwapp] Charter queries References: Message-ID: <0b0301c3aed1$8642aba0$956015ac@dclkempt40> > The point that is made below in #1 (split-AP) architecture is an interesting theoretical discussion. However, the fact is, there are already shipping products that have made the decision to put most of the functionality in the AC. Was this a wise or correct decision? Hard to tell right now. But it would be nice to make sure the various implementations interoperated. > > Is there a procedure in IETF to go straight to standard status if there already exists two interoperating independent implementations before IETF work starts? > No. Nothing goes "straight to standards status" in IETF. However, there are many precedents for vendors working on interoperablity outside of IETF then bringing the design to IETF for fine tuning and standardization. An example is GSMP (General Switch Management Protocol) http://www.ietf.org/html.charters/gsmp-charter.html. A vendor consortium worked to achieve an interoperable design, and even held interoperablity tests prior to bringing the work to IETF. The design work doesn't have to be done in IETF if vendors think they manage doing the interoperable design themselves. >Even if some people feel that the architecture is flawed? If the architecture is flawed, I would expect that the protocol design would quickly show that. If it didn't, the flaws would show up latest in the implementation, which is really too late. jak From mmani@avaya.com Wed Nov 19 20:18:32 2003 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Wed, 19 Nov 2003 13:18:32 -0700 Subject: [Lwapp] RE: [Seamoby] CARD and multiple ARs per AP? Message-ID: This discussion in SEAMOBY overlaps CAPWAP interest: This many-many mapping variant of AP->AR is of additional interest to CAPWAP which is about to get into the thick of varied AP->AR (it's termed AC) architecture discussions - hopefully soon. Is it in the interests of WiSPs to share a common AP infrastructure to facilitate uniform roaming while having agreements to route appropriate user traffic to relevant ACs? It does appear to make sense in dense deployments of 11b/11g. It seems like yet another case in point for policy enforcement in the AP dataplane with policy decisions delivered by ACs from mgmt. plane. -mani > -----Original Message----- > From: seamoby-admin@ietf.org [mailto:seamoby-admin@ietf.org] On Behalf Of > Jon-Olov Vatn > Sent: Tuesday, November 18, 2003 2:42 PM > To: seamoby@ietf.org > Subject: [Seamoby] CARD and multiple ARs per AP? >=20 > Hi! >=20 > I have a question regarding the CAR discovery protocol (CARD). >=20 > When I read the draft (draft-ietf-seamoby-card-protocol-04.txt) my > understanding was that it allows an AR to have multiple APs attached, > but not an AP to be attached to multiple ARs. > I this the case? (Or did I just not read it carefully enough?) >=20 > If this is the case, is this imposed structural limitation made > of some specific reason, e.g., for simplicity, or was it just > unintentional? (I hope you forgive me for having missed any prior > discussion on this matter.) >=20 > Background: > ----------- > I could think of two situations where one would like to have multiple > ARs per AP: if a WISP has two ARs for redundancy, or if several WISPs > are sharing an access infrastructure (my own interest concerns the > latter. This would lead to a many-to-many relationship between APs and > ARs and a L2 ID would no longer uniquely point to an AR. >=20 > Perhaps I should explain what I mean with shared access > infrastructures, since there are many ways to do it. If we consider > 802.11 WLANs with 802.1X support, and a set of WISPs sharing an access > infrastructure with briding APs (see the figure below) it is possible > to use VLAN (or other tunneling techniques) between the APs and ARs to > isolate the traffic for the different WISPs. The APs can map the > traffic to/from the USER hosts to the WISP by adding/removing the > appropriate VLAN tag. > (For those interested I have written a paper which gives some more > information about the architecture I anticipate): "A roaming > architecture for IP based mobile telephony in WLAN environments", > Stockholm Mobility Roundtable, 22-23 May 2003, Stockholm, > Sweden. Available at > http://www.it.kth.se/~vatn/research/roam-arch.pdf) >=20 > WISP BACKBONE NETWORKS > ^ ^ > | | > +--+--+ +--+--+ > | | | | > |WISP1| |WISP2| ... > | AR1 | | AR2 | > +--+--+ +--+--+ > | | Tunnels between each AP > ----+---+-------+--------+------- and AR, e.g., using > | | VLAN tagging > +--+--+ +--+--+ > | | | | > | AP1 | | AP2 | ... > | | | | > +--+--+ +--+--+ APs act as 802.1X authenticators > | | Map traffic of each USER to the > o o VLAN associated with its WISP. >=20 > o o > | | > +--+--+ +--+--+ > | | | | > |USER1| |USER2| ......... > | | | | > +-----+ +-----+ >=20 >=20 > Follow up question: > ------------------- > Perhaps you disagree to the whole idea of supporting the case with > multiple ARs per AP. Nevertheless, I have a follow-up question and it > concerns the usage of the "Context-ID" if one could have more than one > AR per AP. >=20 > The CARD draft uses the "Context-ID" field to map different > sub-options to a specific AR. Together with the "MATCH Status-Code > indication" the "Context-ID" can be used to avoid sending the CAR's > address and capability information multiple times if two or more L2 > IDs resolve to the same AR. > To enable for multiple ARs per AP I would suggest to use two context > fields instead of the single "Context-ID" field. By this one could > avoid sending one copy of each "L2 ID" sub-option for each attached > AR. One of the two contexts fields would be common to the all ARs > on the shared network ("LAN-context ID") and one is specific to the > individual ARs ("AR-context ID"). The Address sub-option would contain > both context ID fields, while "L2 ID" suboption would only contain > "LAN-context ID" and the "Capability Container" suboption would only > contain an "AR-context ID". > Would this be a good thing? >=20 > The "LAN-context ID" could perhaps be based on a MAC-address of one of > the attached ARs, using some election method similar to the "Root > bridge election of the Spanning Tree algorithm" or the "Designated > Router" election used by OSPF. >=20 > BW J-O >=20 >=20 > ---------------------------------------------------------------------- > Jon-Olov Vatn Email: vatn@it.kth.se > Royal Institute of Technology Address: KTH-IMIT > Dep. of Microelectronics and Isafjordsgatan 39 > Information Technology S-164 40 Kista SWEDEN > Telecommunication System Lab. Fax: +46 8 751 17 93 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby From gspsl@yahoo.com.sg Thu Nov 20 01:06:58 2003 From: gspsl@yahoo.com.sg (Saravanan Govindan) Date: Thu, 20 Nov 2003 09:06:58 +0800 Subject: [Lwapp] Lightweight definition? In-Reply-To: <55749BC69138654EBBC4C50BA4F5561085510E@AIREMAIL.airespace.com> Message-ID: <000601c3af02$993f1730$5b71510a@vivaldi> This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C3AF45.A766EB10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear All, 1. From the discussions over the past few days, I am of the view that not all of us have a consistent understanding of what "light" constitutes in terms of AP functionality. Are all APs out there now lightweight? If so, what are the functions cheaply available on them? If not, what is so expensive/complex that can be taken out and placed in the AC? I think deciding on this would help everyone focus on the broader issues. Cheers, Saravanan ------=_NextPart_000_0007_01C3AF45.A766EB10 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IjsBAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANMHCwAUAAkABgAAAAQADAEB A5AGAEgGAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAAYAAAATGlnaHR3ZWlnaHQgZGVmaW5pdGlvbj8AAgFxAAEAAAAWAAAAAcOvApjB kqCzTierRJyJsfppDo4Q9gAAAgEdDAEAAAAYAAAAU01UUDpHU1BTTEBZQUhPTy5DT00uU0cACwAB DgAAAABAAAYOAIzwdQKvwwECAQoOAQAAABgAAAAAAAAAhm7R+3GnD0uQmlhjMJWyKsKAAAADABQO AQAAAAsAHw4BAAAAAgEJEAEAAAATAgAADwIAAOwCAABMWkZ1xeBlxgMACgByY3BnMTI14jIDQ3Rl eAVBAQMB9/8KgAKkA+QHEwKAD/MAUARWPwhVB7IRJQ5RAwECAGNo4QrAc2V0MgYABsMRJfYzBEYT tzASLBEzCO8J97Y7GB8OMDURIgxgYwBQMwsJAWQzNhZQC6YgRMJlCsFBbGwsCqIKhCEKgDEuIEYD YSB0kGhlIGQEAGN1BBDmaQIgBCBvdhKBHsIKsApzBUBmB9FkYXlzICwgSSBhHqBvZl0es3YIkAfg HsBhBUBuvm8FQAdAAyAhkR9AIBPg+x/QIVAgBaAAgSBwCfAFQDx1bgSBIHAAcB8AbmcFIYJ3ImIi bGlnaIR0IiPjdGl0dQ6wbwQgC4AesASQbR+hIaBB9lAgkCSgYybAAiAHQCbQ/nkeUAcQI7Ei8SgA H6Em8J8esikxIqAH4CYTd2UmIuY/ITAhoHNvISAlswrAfx7gHsIoNgQgE9AdAAtQef0hUHYLcAtg AmAe4AIgHrK+bStzIqEr5QQAK7EgDsCucAnwAJAf0C8FoG0LUCsOwCJEYwORYixxYWvfCfAp0yUR IEALYGMJgCczuR7RQUMrcR6xC4BrHvBdBZBpJTQuoi/xdwhgbLMy8B7QbHAwQB/ReQIgvSyxbx8x LoUx8ANgYQSBpS/hcwpQcy4dikMe0Pck0R17BhByLfEooAuQHZMCfTuwAB4AQhABAAAAQAAAADw1 NTc0OUJDNjkxMzg2NTRFQkJDNEM1MEJBNEY1NTYxMDg1NTEwRUBBSVJFTUFJTC5haXJlc3BhY2Uu Y29tPgADAAlZAQAAAAsAAIAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwACgAggBgAAAAAA wAAAAAAAAEYAAAAAEIUAAAAAAAADAAeACCAGAAAAAADAAAAAAAAARgAAAABShQAAfW4BAB4ACYAI IAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABAAAADkuMAALABGACCAGAAAAAADAAAAAAAAARgAA AAAGhQAAAAAAAAMAEoAIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAACwAbgAggBgAAAAAAwAAA AAAAAEYAAAAADoUAAAAAAAADAByACCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMAHoAIIAYA AAAAAMAAAAAAAABGAAAAABiFAAAAAAAAAgH4DwEAAAAQAAAAhm7R+3GnD0uQmlhjMJWyKgIB+g8B AAAAEAAAAIZu0ftxpw9LkJpYYzCVsioCAfsPAQAAAJsAAAAAAAAAOKG7EAXlEBqhuwgAKypWwgAA bXNwc3QuZGxsAAAAAABOSVRB+b+4AQCqADfZbgAAAEM6XERvY3VtZW50cyBhbmQgU2V0dGluZ3Nc QWRtaW5pc3RyYXRvclxMb2NhbCBTZXR0aW5nc1xBcHBsaWNhdGlvbiBEYXRhXE1pY3Jvc29mdFxP dXRsb29rXG1haWxib3gucHN0AAADAP4PBQAAAAMADTT9NwAAAgF/AAEAAAAxAAAAMDAwMDAwMDA4 NjZFRDFGQjcxQTcwRjRCOTA5QTU4NjMzMDk1QjIyQUU0MDgyRTAwAAAAAAMABhBgZSaCAwAHEHAB AAADABAQAAAAAAMAERAAAAAAHgAIEAEAAABlAAAAREVBUkFMTCwxRlJPTVRIRURJU0NVU1NJT05T T1ZFUlRIRVBBU1RGRVdEQVlTLElBTU9GVEhFVklFV1RIQVROT1RBTExPRlVTSEFWRUFDT05TSVNU RU5UVU5ERVJTVEFORElORwAAAAARdg== ------=_NextPart_000_0007_01C3AF45.A766EB10-- From mmani@avaya.com Thu Nov 20 01:30:47 2003 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Wed, 19 Nov 2003 18:30:47 -0700 Subject: [Lwapp] Lightweight definition? Message-ID: The (initial) terminology was intended to indicate offloading of functions to the AC from the 'traditional AP'. Refer to definitions of MUST and MAY functions in the architecture doc. (http://www.ietf.org/internet-drafts/draft-mani-ietf-capwap-arch-00.txt) that discusses the AP-AC balance of functions. While split-AP is the starting reference; split-MAC architectures - adopted by some - is also discussed. Regards, -mani > -----Original Message----- > From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf > Of Saravanan Govindan > Sent: Wednesday, November 19, 2003 5:07 PM > To: 'LWAPP' > Subject: [Lwapp] Lightweight definition? >=20 > Dear All, > > 1. From the discussions over the past few days, I am of the view that not > all of us have a consistent understanding of what "light" constitutes in > terms of AP functionality. Are all APs out there now lightweight? If so, > what are the functions cheaply available on them? If not, what is so > expensive/complex that can be taken out and placed in the AC? I think > deciding on this would help everyone focus on the broader issues. >=20 > Cheers, >=20 > Saravanan From kempf@docomolabs-usa.com Thu Nov 20 16:56:10 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Thu, 20 Nov 2003 08:56:10 -0800 Subject: [Lwapp] Lightweight definition? References: <000601c3af02$993f1730$5b71510a@vivaldi> Message-ID: <0cbc01c3af87$33900c70$956015ac@dclkempt40> Is this question really important w.r.t. clarifying the technical aspects of the problem CAPWAP is trying to solve, and precisely defining a functional architecture for 802.11 access networks? jak ----- Original Message ----- From: "Saravanan Govindan" To: "'LWAPP'" Sent: Wednesday, November 19, 2003 5:06 PM Subject: [Lwapp] Lightweight definition? > Dear All, > > 1. From the discussions over the past few days, I am of the view that not > all of us have a consistent understanding of what "light" constitutes in > terms of AP functionality. Are all APs out there now lightweight? If so, > what are the functions cheaply available on them? If not, what is so > expensive/complex that can be taken out and placed in the AC? I think > deciding on this would help everyone focus on the broader issues. > > Cheers, > > Saravanan > From mmani@avaya.com Thu Nov 20 17:38:08 2003 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Thu, 20 Nov 2003 10:38:08 -0700 Subject: [Lwapp] Lightweight definition? Message-ID: It is important (and should not take long) to get away from the notion of 'lightweight'. The lightness is a side-effect. The main effect is the correct functional separations between AP & AC. The primary drivers are the need to solve the problems stated in the problem-statement draft. -mani > -----Original Message----- > From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf > Of James Kempf > Sent: Thursday, November 20, 2003 8:56 AM > To: gspsl@yahoo.com.sg; 'LWAPP' > Subject: Re: [Lwapp] Lightweight definition? >=20 > Is this question really important w.r.t. clarifying the technical aspects > of > the problem CAPWAP is trying to solve, and precisely defining a functional > architecture for 802.11 access networks? >=20 > jak >=20 > ----- Original Message ----- > From: "Saravanan Govindan" > To: "'LWAPP'" > Sent: Wednesday, November 19, 2003 5:06 PM > Subject: [Lwapp] Lightweight definition? >=20 >=20 > > Dear All, > > > > 1. From the discussions over the past few days, I am of the view that > not > > all of us have a consistent understanding of what "light" constitutes in > > terms of AP functionality. Are all APs out there now lightweight? If so, > > what are the functions cheaply available on them? If not, what is so > > expensive/complex that can be taken out and placed in the AC? I think > > deciding on this would help everyone focus on the broader issues. > > > > Cheers, > > > > Saravanan > > >=20 > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp From bran@arraycomm.com Thu Nov 20 18:15:09 2003 From: bran@arraycomm.com (Branislav Meandzija) Date: Thu, 20 Nov 2003 10:15:09 -0800 Subject: [Lwapp] Lightweight definition? Message-ID: <200311201815.hAKIFCft025361@lester.arraycomm.com> > = > It is important (and should not take long) to get away from the notion > of 'lightweight'. The lightness is a side-effect. > = > The main effect is the correct functional separations between AP & AC. I am not convinced that the functional separation is correct. An equally va= lid paradigm is traditional manager/agent. How do we measure "correctness" here? Branislav From kempf@docomolabs-usa.com Thu Nov 20 18:24:22 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Thu, 20 Nov 2003 10:24:22 -0800 Subject: [Lwapp] Lightweight definition? References: <200311201815.hAKIFCft025361@lester.arraycomm.com> Message-ID: <0e2601c3af93$853cbf30$956015ac@dclkempt40> > > It is important (and should not take long) to get away from the notion > > of 'lightweight'. The lightness is a side-effect. > > > > The main effect is the correct functional separations between AP & AC. > > I am not convinced that the functional separation is correct. An equally valid paradigm is > traditional manager/agent. How do we measure "correctness" here? > As far as architecture goes, I think it's not an issue of correctness as of coming up with a comprehensive definition of the functional entities in an 802.11 access network and how they are related. That's what a functional architecture is. The current draft does a pretty good job of defining the network reference architectures that vendors have implemented, but the functional architecture is somewhat thin (probably because it is not well defined in the 802.11 spec). It should be easier to do that since it is basically an engineering problem and shouldn't involve any value judgements. Even if vendors disagree on the network reference architecture (i.e. what functions go in what boxes) they should be able to agree on what the functions are, since the functions should be defined by the basic MAC and PHY functions of the 802.11 protocol. But I'm not sure if it is IETF's engineering problem, since the functional definition of an 802.11 access network is really something that IEEE should define. The current definition (in Section 5 of 8802-11-1999) is pretty vague. What is an ESS, for example? Or a portal? jak From mmani@avaya.com Thu Nov 20 18:34:46 2003 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Thu, 20 Nov 2003 11:34:46 -0700 Subject: [Lwapp] Lightweight definition? Message-ID: Let me try: approximately what makes sense in terms of real-time functions - that cannot tolerate unbound or not-so well-bound latencies is what I would characterize for correctness. I would agree that it does not apply to real-time functions. In the same breath I would also say some real-time placements in other than APs does not really mean incorrect - but may lead to constraints in topological separation between AP & AC. -mani > -----Original Message----- > From: Branislav Meandzija [mailto:bran@arraycomm.com] > Sent: Thursday, November 20, 2003 10:15 AM > To: Mani, Mahalingam (Mahalingam); James Kempf; gspsl@yahoo.com.sg; LWAPP > Subject: RE: [Lwapp] Lightweight definition? >=20 >=20 > > > > It is important (and should not take long) to get away from the notion > > of 'lightweight'. The lightness is a side-effect. > > > > The main effect is the correct functional separations between AP & AC. >=20 > I am not convinced that the functional separation is correct. An equally > valid paradigm is > traditional manager/agent. How do we measure "correctness" here? >=20 > Branislav >=20 From bran@arraycomm.com Thu Nov 20 18:52:59 2003 From: bran@arraycomm.com (Branislav Meandzija) Date: Thu, 20 Nov 2003 10:52:59 -0800 Subject: [Lwapp] Lightweight definition? Message-ID: <200311201853.hAKIr2ft007085@lester.arraycomm.com> Can you characterize "real-time" in this context and with regards to specif= ic functions considered? Branislav > -----Original Message----- > From: Mani, Mahalingam (Mahalingam) [mailto:mmani@avaya.com] > Sent: Thursday, November 20, 2003 10:35 AM > To: Branislav Meandzija; James Kempf; gspsl@yahoo.com.sg; LWAPP > Subject: RE: [Lwapp] Lightweight definition? > = > = > Let me try: approximately what makes sense in terms of real-time > functions - that cannot tolerate unbound or not-so = > well-bound latencies > is what I would characterize for correctness. I would agree = > that it does > not apply to real-time functions. > = > In the same breath I would also say some real-time placements in other > than APs does not really mean incorrect - but may lead to = > constraints in > topological separation between AP & AC. > = > -mani > > -----Original Message----- > > From: Branislav Meandzija [mailto:bran@arraycomm.com] > > Sent: Thursday, November 20, 2003 10:15 AM > > To: Mani, Mahalingam (Mahalingam); James Kempf; gspsl@yahoo.com.sg; > LWAPP > > Subject: RE: [Lwapp] Lightweight definition? > > = > > = > > > > > > It is important (and should not take long) to get away from the > notion > > > of 'lightweight'. The lightness is a side-effect. > > > > > > The main effect is the correct functional separations between AP & > AC. > > = > > I am not convinced that the functional separation is correct. An > equally > > valid paradigm is > > traditional manager/agent. How do we measure "correctness" here? > > = > > Branislav > > = > = > From mmani@avaya.com Thu Nov 20 19:06:24 2003 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Thu, 20 Nov 2003 12:06:24 -0700 Subject: [Lwapp] Lightweight definition? Message-ID: Real-time is what generically real-time means. Bounded response-time guarantees in general - failing which, for example, one may lapse opportunity a time-slot to acquire the wireless medium for transmission or risk acknowledging a frame on time. For details on what functions are characterized by that - I would refer to the architecture draft. -mani > -----Original Message----- > From: Branislav Meandzija [mailto:bran@arraycomm.com] > Sent: Thursday, November 20, 2003 10:53 AM > To: Mani, Mahalingam (Mahalingam); James Kempf; gspsl@yahoo.com.sg; LWAPP > Subject: RE: [Lwapp] Lightweight definition? >=20 >=20 > Can you characterize "real-time" in this context and with regards to > specific functions considered? >=20 > Branislav >=20 > > -----Original Message----- > > From: Mani, Mahalingam (Mahalingam) [mailto:mmani@avaya.com] > > Sent: Thursday, November 20, 2003 10:35 AM > > To: Branislav Meandzija; James Kempf; gspsl@yahoo.com.sg; LWAPP > > Subject: RE: [Lwapp] Lightweight definition? > > > > > > Let me try: approximately what makes sense in terms of real-time > > functions - that cannot tolerate unbound or not-so > > well-bound latencies > > is what I would characterize for correctness. I would agree > > that it does > > not apply to real-time functions. > > > > In the same breath I would also say some real-time placements in other > > than APs does not really mean incorrect - but may lead to > > constraints in > > topological separation between AP & AC. > > > > -mani > > > -----Original Message----- > > > From: Branislav Meandzija [mailto:bran@arraycomm.com] > > > Sent: Thursday, November 20, 2003 10:15 AM > > > To: Mani, Mahalingam (Mahalingam); James Kempf; gspsl@yahoo.com.sg; > > LWAPP > > > Subject: RE: [Lwapp] Lightweight definition? > > > > > > > > > > > > > > It is important (and should not take long) to get away from the > > notion > > > > of 'lightweight'. The lightness is a side-effect. > > > > > > > > The main effect is the correct functional separations between AP & > > AC. > > > > > > I am not convinced that the functional separation is correct. An > > equally > > > valid paradigm is > > > traditional manager/agent. How do we measure "correctness" here? > > > > > > Branislav > > > > > > > From bran@arraycomm.com Thu Nov 20 21:21:16 2003 From: bran@arraycomm.com (Branislav Meandzija) Date: Thu, 20 Nov 2003 13:21:16 -0800 Subject: [Lwapp] Lightweight definition? Message-ID: <200311202121.hAKLLKft023383@lester.arraycomm.com> Does any of the operations possibly considered for LWAPP depend on time-slot accurate response? Please let me know which one? If none, what response-time is targeted by the most performance sensitive operation? All I am saying her is lets be a bit more accurate when we use lofty terms and justify architectural decisions. Branislav > -----Original Message----- > From: Mani, Mahalingam (Mahalingam) [mailto:mmani@avaya.com] > Sent: Thursday, November 20, 2003 11:06 AM > To: Branislav Meandzija; James Kempf; gspsl@yahoo.com.sg; LWAPP > Subject: RE: [Lwapp] Lightweight definition? > = > = > Real-time is what generically real-time means. Bounded response-time > guarantees in general - failing which, for example, one may lapse > opportunity a time-slot to acquire the wireless medium for = > transmission > or > risk acknowledging a frame on time. > = > For details on what functions are characterized by that - I = > would refer > to the architecture draft. > = > -mani > > -----Original Message----- > > From: Branislav Meandzija [mailto:bran@arraycomm.com] > > Sent: Thursday, November 20, 2003 10:53 AM > > To: Mani, Mahalingam (Mahalingam); James Kempf; gspsl@yahoo.com.sg; > LWAPP > > Subject: RE: [Lwapp] Lightweight definition? > > = > > = > > Can you characterize "real-time" in this context and with regards to > > specific functions considered? > > = > > Branislav > > = > > > -----Original Message----- > > > From: Mani, Mahalingam (Mahalingam) [mailto:mmani@avaya.com] > > > Sent: Thursday, November 20, 2003 10:35 AM > > > To: Branislav Meandzija; James Kempf; gspsl@yahoo.com.sg; LWAPP > > > Subject: RE: [Lwapp] Lightweight definition? > > > > > > > > > Let me try: approximately what makes sense in terms of real-time > > > functions - that cannot tolerate unbound or not-so > > > well-bound latencies > > > is what I would characterize for correctness. I would agree > > > that it does > > > not apply to real-time functions. > > > > > > In the same breath I would also say some real-time placements in > other > > > than APs does not really mean incorrect - but may lead to > > > constraints in > > > topological separation between AP & AC. > > > > > > -mani > > > > -----Original Message----- > > > > From: Branislav Meandzija [mailto:bran@arraycomm.com] > > > > Sent: Thursday, November 20, 2003 10:15 AM > > > > To: Mani, Mahalingam (Mahalingam); James Kempf; > gspsl@yahoo.com.sg; > > > LWAPP > > > > Subject: RE: [Lwapp] Lightweight definition? > > > > > > > > > > > > > > > > > > It is important (and should not take long) to get = > away from the > > > notion > > > > > of 'lightweight'. The lightness is a side-effect. > > > > > > > > > > The main effect is the correct functional separations = > between AP > & > > > AC. > > > > > > > > I am not convinced that the functional separation is correct. An > > > equally > > > > valid paradigm is > > > > traditional manager/agent. How do we measure "correctness" here? > > > > > > > > Branislav > > > > > > > > > > > = > From gspsl@yahoo.com.sg Fri Nov 21 01:13:52 2003 From: gspsl@yahoo.com.sg (Saravanan Govindan) Date: Fri, 21 Nov 2003 09:13:52 +0800 Subject: [Lwapp] Lightweight definition? Message-ID: <000101c3afcc$ba692cf0$5b71510a@vivaldi> >> Is this question really important w.r.t. clarifying the technical aspects of the problem CAPWAP is trying to solve, and precisely defining a functional architecture for 802.11 access networks? The intent of my question was to determine which functions are to be centralized and thereby managed in concert for all APs. Understanding this would better help solve the technical issues of the CAPWAP problems. A major issue is to centrally control APs, for which knowing exactly what to control is important. In this regard, using a function's real-time or dynamic characteristic is a good metric to determine the placement for its control. Saravanan From pcalhoun@airespace.com Fri Nov 21 15:48:34 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Fri, 21 Nov 2003 07:48:34 -0800 Subject: [Lwapp] Lightweight definition? Message-ID: <55749BC69138654EBBC4C50BA4F5561083FFC1@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3B046.EBAB4238 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The intent of my question was to determine which functions are to = be centralized and thereby managed in concert for all APs. Understanding = this would better help solve the technical issues of the CAPWAP problems. A = major issue is to centrally control APs, for which knowing exactly what to = control is important. In this regard, using a function's real-time or dynamic characteristic is a good metric to determine the placement for its = control. So here is my take: AP: - All 802.11 control messages - 802.11 beacons - 802.11 probes are responded to locally but forwarded to the AC for = info - (optional) link layer encryption (e.g. WEP, TKIP, AES) - basic policy enforcement, meaning - default: allow 802.11 mac mgmt messages=20 - override 1: allow 802.11 data messages in the clear - override 2: allow 802.11 data messages encrypted (with an = associated key) - override 3: only allow 802.1x messages - Gathers basic (RF related) stats and responds to stat requests from = AP AC: - listens, but does not respond to probes (provides visibility) - 802.11 auth, assoc, disassoc and deauth messages - peforms all access control based on the above - Sends specific client policies to AP (see AP section) after assoc is = complete and optionally once more once 802.1x/WPA is complete - Sends configuration information down to the AP - Requests & gathers statistics from the AP I am probably missing some stuff, but the above is a good first attempt = at defining specific functional components. PatC ------_=_NextPart_001_01C3B046.EBAB4238 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Lightweight definition?

<SG> The intent of my question was to determine = which functions are to be
centralized and thereby managed in concert for all APs. Understanding = this
would better help solve the technical issues of the CAPWAP problems. A = major
issue is to centrally control APs, for which knowing exactly what to = control
is important. In this regard, using a function's real-time or = dynamic
characteristic is a good metric to determine the placement for its = control.

<PRC> So here is my take:

AP:
  - All 802.11 control messages
  - 802.11 beacons
  - 802.11 probes are responded to locally but forwarded to the AC = for info
  - (optional) link layer encryption (e.g. WEP, TKIP, AES)
  - basic policy enforcement, meaning
     - default: allow 802.11 mac mgmt messages
     - override 1: allow 802.11 data messages in the = clear
     - override 2: allow 802.11 data messages = encrypted (with an associated key)
     - override 3: only allow 802.1x messages
  - Gathers basic (RF related) stats and responds to stat requests = from AP

AC:
  - listens, but does not respond to probes (provides = visibility)
  - 802.11 auth, assoc, disassoc and deauth messages
  - peforms all access control based on the above
  - Sends specific client policies to AP (see AP section) after = assoc is complete
    and optionally once more once 802.1x/WPA is = complete
  - Sends configuration information down to the AP
  - Requests & gathers statistics from the AP

I am probably missing some stuff, but the above is a good first attempt = at defining
specific functional components.

PatC

------_=_NextPart_001_01C3B046.EBAB4238-- From pcalhoun@airespace.com Fri Nov 21 15:49:46 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Fri, 21 Nov 2003 07:49:46 -0800 Subject: [Lwapp] Lightweight definition? Message-ID: <55749BC69138654EBBC4C50BA4F5561083FFC2@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3B047.6B6AED05 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Does any of the operations possibly considered for LWAPP depend on time-slot accurate response? Please let me know which one? If none, what response-time is targeted by the most performance sensitive operation? All I am saying her is lets be a bit more accurate when we use lofty terms and justify architectural decisions. Unfortunately, the 802.11-1999 doesn't really define timing parameters, so it's largely implementation specific (read: you really have to be in the thick of it to be aware of the various client=20 behavior). However, it is probably fair to state that WiFi's=20 recommendation is as follows: 1. probes replies must be sent within 3 (or maybe it's 5) ms 2. All other MAC mgmt messages must be replied to in 100ms Of course, the beacon period is fixed, and typically configurable. However, beacons MUST be sent on the frequency advertised, so this can be considered VERY time sensitive. PatC ------_=_NextPart_001_01C3B047.6B6AED05 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Lightweight definition?

Does any of the operations possibly considered for = LWAPP depend on
time-slot accurate response? Please let me know which one? If none,
what response-time is targeted by the most performance sensitive
operation?

All I am saying her is lets be a bit more accurate when we use
lofty terms and justify architectural decisions.

<PRC> Unfortunately, the 802.11-1999 doesn't really define = timing
parameters, so it's largely implementation specific (read: you = really
have to be in the thick of it to be aware of the various client
behavior). However, it is probably fair to state that WiFi's
recommendation is as follows:

   1. probes replies must be sent within 3 (or maybe it's 5) = ms
   2. All other MAC mgmt messages must be replied to in = 100ms

Of course, the beacon period is fixed, and typically configurable.
However, beacons MUST be sent on the frequency advertised, so this
can be considered VERY time sensitive.

PatC

------_=_NextPart_001_01C3B047.6B6AED05-- From mmani@avaya.com Tue Nov 25 16:41:50 2003 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Tue, 25 Nov 2003 09:41:50 -0700 Subject: [Lwapp] Charter & Problem Statement. Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C3B373.06415824 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Bob O'Hara had enquired last week about feedback on Problem statement (at the meeting) which was a presentation on the draft. =20 The draft is available for a while now, (http://www.ietf.org/internet-drafts/draft-calhoun-capwap-problem-statem ent-00.txt) and the Charter was posted (before the Minneapolis meeting) to the list, (http://www.frascone.com/lwapp/CAPWAP-charter.txt ). =20 This is another reminder to provide any further comments. =20 Regards, -mani ------_=_NextPart_001_01C3B373.06415824 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Bob O’Hara had enquired last week about = feedback on Problem statement (at the meeting) which was a presentation on the = draft.

 

The draft is available for a while now, (http://www.ietf.org/internet-drafts/draft-calhoun-capwa= p-problem-statement-00.txt)

and the Charter was posted (before the = Minneapolis meeting) to the list, (http://www.fras= cone.com/lwapp/CAPWAP-charter.txt ).

 

This is another reminder to provide any further = comments.

 

Regards,

-mani

------_=_NextPart_001_01C3B373.06415824-- From crh@ubiqx.mn.org Wed Nov 26 04:52:05 2003 From: crh@ubiqx.mn.org (Christopher R. Hertel) Date: Tue, 25 Nov 2003 22:52:05 -0600 Subject: [Lwapp] Minutes In-Reply-To: References: Message-ID: <20031126045205.GA23574@Favog.ubiqx.mn.org> Folks, I took notes during the session in Minneapolis. I have not had time to transcribe them but I'm working on it. I'm afraid they'll be too little to late. Are they still of interest? Chris -)----- -- "Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X Samba Team -- http://www.samba.org/ -)----- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)----- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)----- crh@ubiqx.mn.org OnLineBook -- http://ubiqx.org/cifs/ -)----- crh@ubiqx.org From mmani@avaya.com Wed Nov 26 05:28:09 2003 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Tue, 25 Nov 2003 22:28:09 -0700 Subject: [Lwapp] Minutes Message-ID: Chris, Thanks for the notes. You can forward them to me/Dorothy. We will have them cleaned up and sent to be posted. We already have one from Lily Yang - the other scribe. Regards, -mani > -----Original Message----- > From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf > Of Christopher R. Hertel > Sent: Tuesday, November 25, 2003 8:52 PM > To: lwapp@frascone.com > Subject: [Lwapp] Minutes >=20 > Folks, >=20 > I took notes during the session in Minneapolis. I have not had time to > transcribe them but I'm working on it. I'm afraid they'll be too little > to late. Are they still of interest? >=20 > Chris -)----- >=20 > -- > "Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X > Samba Team -- http://www.samba.org/ -)----- Christopher R. Hertel > jCIFS Team -- http://jcifs.samba.org/ -)----- ubiqx development, uninq. > ubiqx Team -- http://www.ubiqx.org/ -)----- crh@ubiqx.mn.org > OnLineBook -- http://ubiqx.org/cifs/ -)----- crh@ubiqx.org > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp From vatn@it.kth.se Wed Nov 26 09:48:37 2003 From: vatn@it.kth.se (Jon-Olov Vatn) Date: Wed, 26 Nov 2003 10:48:37 +0100 Subject: [Lwapp] Re: [Seamoby] CARD and multiple ARs per AP? In-Reply-To: Message-ID: <200311260947.hAQ9lik03442@mail2.it.kth.se> 19 November 2003 "Mani, Mahalingam (Mahalingam)" wrote: > This discussion in SEAMOBY overlaps CAPWAP interest: > = > This many-many mapping variant of AP->AR is of additional interest to > CAPWAP which is about to get into the thick of varied AP->AR (it's > termed AC) architecture discussions - hopefully soon. > = > Is it in the interests of WiSPs to share a common AP infrastructure to > facilitate uniform roaming while having agreements to route appropriate= > user traffic to relevant ACs? It does appear to make sense in dense > deployments of 11b/11g. I can also imagine situations where the L2 infrastructure is owned by a third party, such as an appartment building association, and made available to multiple ISPs so that the individual customers do not have to sign-up with the same ISP. (This case is similar to the case with wired broadband access; the only difference would be that we now have WLAN APs attached to the shared L2 infrastructure). My wish would be that CARD would support architectures that make it easier for customers to change ISPs. Limiting the architecure to one AR per AP seems to prohibit some of the possibilities to establish such access networks. /J-O > = > It seems like yet another case in point for policy enforcement in the A= P > dataplane with policy decisions delivered by ACs from mgmt. plane. > = > -mani > > -----Original Message----- > > From: seamoby-admin@ietf.org [mailto:seamoby-admin@ietf.org] On Behal= f > Of > > Jon-Olov Vatn > > Sent: Tuesday, November 18, 2003 2:42 PM > > To: seamoby@ietf.org > > Subject: [Seamoby] CARD and multiple ARs per AP? > > = > > Hi! > > = > > I have a question regarding the CAR discovery protocol (CARD). > > = > > When I read the draft (draft-ietf-seamoby-card-protocol-04.txt) my > > understanding was that it allows an AR to have multiple APs attached,= > > but not an AP to be attached to multiple ARs. > > I this the case? (Or did I just not read it carefully enough?) > > = > > If this is the case, is this imposed structural limitation made > > of some specific reason, e.g., for simplicity, or was it just > > unintentional? (I hope you forgive me for having missed any prior > > discussion on this matter.) > > = > > Background: > > ----------- > > I could think of two situations where one would like to have multiple= > > ARs per AP: if a WISP has two ARs for redundancy, or if several WISPs= > > are sharing an access infrastructure (my own interest concerns the > > latter. This would lead to a many-to-many relationship between APs an= d > > ARs and a L2 ID would no longer uniquely point to an AR. > > = > > Perhaps I should explain what I mean with shared access > > infrastructures, since there are many ways to do it. If we consider > > 802.11 WLANs with 802.1X support, and a set of WISPs sharing an acces= s > > infrastructure with briding APs (see the figure below) it is possible= > > to use VLAN (or other tunneling techniques) between the APs and ARs t= o > > isolate the traffic for the different WISPs. The APs can map the > > traffic to/from the USER hosts to the WISP by adding/removing the > > appropriate VLAN tag. > > (For those interested I have written a paper which gives some more > > information about the architecture I anticipate): "A roaming > > architecture for IP based mobile telephony in WLAN environments", > > Stockholm Mobility Roundtable, 22-23 May 2003, Stockholm, > > Sweden. Available at > > http://www.it.kth.se/~vatn/research/roam-arch.pdf) > > = > > WISP BACKBONE NETWORKS > > ^ ^ > > | | > > +--+--+ +--+--+ > > | | | | > > |WISP1| |WISP2| ... > > | AR1 | | AR2 | > > +--+--+ +--+--+ > > | | Tunnels between each AP > > ----+---+-------+--------+------- and AR, e.g., using > > | | VLAN tagging > > +--+--+ +--+--+ > > | | | | > > | AP1 | | AP2 | ... > > | | | | > > +--+--+ +--+--+ APs act as 802.1X authenticators > > | | Map traffic of each USER to the > > o o VLAN associated with its WISP. > > = > > o o > > | | > > +--+--+ +--+--+ > > | | | | > > |USER1| |USER2| ......... > > | | | | > > +-----+ +-----+ > > = > > = > > Follow up question: > > ------------------- > > Perhaps you disagree to the whole idea of supporting the case with > > multiple ARs per AP. Nevertheless, I have a follow-up question and it= > > concerns the usage of the "Context-ID" if one could have more than on= e > > AR per AP. > > = > > The CARD draft uses the "Context-ID" field to map different > > sub-options to a specific AR. Together with the "MATCH Status-Code > > indication" the "Context-ID" can be used to avoid sending the CAR's > > address and capability information multiple times if two or more L2 > > IDs resolve to the same AR. > > To enable for multiple ARs per AP I would suggest to use two context > > fields instead of the single "Context-ID" field. By this one could > > avoid sending one copy of each "L2 ID" sub-option for each attached > > AR. One of the two contexts fields would be common to the all ARs > > on the shared network ("LAN-context ID") and one is specific to the > > individual ARs ("AR-context ID"). The Address sub-option would contai= n > > both context ID fields, while "L2 ID" suboption would only contain > > "LAN-context ID" and the "Capability Container" suboption would only > > contain an "AR-context ID". > > Would this be a good thing? > > = > > The "LAN-context ID" could perhaps be based on a MAC-address of one o= f > > the attached ARs, using some election method similar to the "Root > > bridge election of the Spanning Tree algorithm" or the "Designated > > Router" election used by OSPF. > > = > > BW J-O > > = > > = > > ---------------------------------------------------------------------= - > > Jon-Olov Vatn Email: vatn@it.kth.se > > Royal Institute of Technology Address: KTH-IMIT > > Dep. of Microelectronics and Isafjordsgatan 39 > > Information Technology S-164 40 Kista > SWEDEN > > Telecommunication System Lab. Fax: +46 8 751 17 93 > > = > > = > > = > > = > > = > > = > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby From mmani@avaya.com Thu Nov 27 01:41:59 2003 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Wed, 26 Nov 2003 18:41:59 -0700 Subject: [Lwapp] Problem Statement Draft and Charter. Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C3B487.A60CA6DC Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable The latest problem statement draft is available at =20 http://www.frascone.com/draft-calhoun-capwap-problem-statement-01.txt =20 =20 One minor change is to omit reference to the firmware update problem. =20 Charter document remains the same: http://www.frascone.com/lwapp/CAPWAP-charter.txt =20 =20 Regards, -mani =20 ------_=_NextPart_001_01C3B487.A60CA6DC Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

The latest problem statement draft is available = at

 

http://www.frascone.com/draft-calhoun-capwap-problem-statement-01.txt=

 

One minor change is = to omit reference to the firmware update problem.

 

Charter document = remains the same: http://www.fras= cone.com/lwapp/CAPWAP-charter.txt  

 

Regards,

-mani

 

------_=_NextPart_001_01C3B487.A60CA6DC-- From vatn@it.kth.se Thu Nov 27 05:49:02 2003 From: vatn@it.kth.se (Jon-Olov Vatn) Date: Thu, 27 Nov 2003 06:49:02 +0100 Subject: [Lwapp] Minor correction, draft-calhoun-capwap-problem-statement-01.txt Message-ID: <200311270548.hAR5mAk24194@mail2.it.kth.se> On page 4, conected =3D> connected I think the document looks great! = BW J-O From mmani@avaya.com Thu Nov 27 21:22:53 2003 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Thu, 27 Nov 2003 14:22:53 -0700 Subject: [Lwapp] Problem Statement Draft and Charter. Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C3B52C.9E2F4A96 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Fixed access to the documents: =20 Try the Problem statement draft now at: http://www.capwap.org/ draft-calhoun-capwap-problem-statement-01.txt=20 And the Charter document at: http://www.capwap.org/CAPWAP-charter.txt=20 =20 Thanks to Jan-Olov for pointing out the problems. =20 thanks, -mani =20 -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf Of Mani, Mahalingam (Mahalingam) Sent: Wednesday, November 26, 2003 5:42 PM To: lwapp@frascone.com Subject: [Lwapp] Problem Statement Draft and Charter. Importance: High =20 The latest problem statement draft is available at =20 http://www.frascone.com/draft-calhoun-capwap-problem-statement-01.txt =20 =20 One minor change is to omit reference to the firmware update problem. =20 Charter document remains the same: http://www.frascone.com/lwapp/CAPWAP-charter.txt =20 =20 Regards, -mani =20 ------_=_NextPart_001_01C3B52C.9E2F4A96 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Fixed access to the = documents:

 

Try the Problem statement draft now = at:

http://www.capwap.org/draft-calhoun-capwap-problem-statement-01.txt

And the Charter document = at:

http://www.capwap.org/C= APWAP-charter.txt

 

Thanks to Jan-Olov for pointing out = the problems.

 

thanks,

-mani

 

-----Original Message-----
From: = lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On = Behalf Of Mani, Mahalingam (Mahalingam)
Sent:
Wednesday, November 26, 2003 5:42 PM
To: = lwapp@frascone.com
Subject: [Lwapp] Problem = Statement Draft and Charter.
Importance: = High

 

The latest problem statement draft is available = at

 

http://www.frascone.com/draft-calhoun-capwap-problem-statement-01.txt=

 

One minor change is = to omit reference to the firmware update problem.

 

Charter document = remains the same: http://www.fras= cone.com/lwapp/CAPWAP-charter.txt  

 

Regards,

-mani

 

------_=_NextPart_001_01C3B52C.9E2F4A96--