RE: [Lwapp] Problem Statement Draft and Charter.

From bran@arraycomm.com Tue Dec 2 04:28:24 2003 From: bran@arraycomm.com (Branislav Meandzija) Date: Mon, 1 Dec 2003 20:28:24 -0800 Subject: [Lwapp] Problem Statement Draft and Charter. Message-ID: <200312020428.hB24SYft016091@lester.arraycomm.com> This is a multi-part message in MIME format ---------175816c5175816c5 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I looked at the problem statement which is very nice and clear but IMHO mor= e appropriate for a standards group dedicated to 802.11 infrastructure stan= dardization (something like 3GPP2 for CDMA 2000) and not the IETF. Is there= such a body? = The IETF could assist such efforts by standardizing 802.11 MIBs, PIBs, or L= DAP schema. If this is not sufficient, then generic requirements should be = formulated that are not well addressed by the current set of IETF protocols= and should be addressed in the context of other security, management work,= etc. Otherwise we can start similar efforts for 802.16, 802.20, etc. Branislav -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com]On Behalf= Of Mani, Mahalingam (Mahalingam) Sent: Thursday, November 27, 2003 1:23 PM To: Mani, Mahalingam (Mahalingam); lwapp@frascone.com Subject: RE: [Lwapp] Problem Statement Draft and Charter. Importance: High 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/CAPWAP-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 Behal= f 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.frascone.com/lwapp/CAPWAP-c= harter.txt = Regards, -mani ---------175816c5175816c5 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

I = looked at the problem statement which is very nice and clear but IMHO = more = appropriate for a standards group dedicated to 802.11 infrastructure = standardization (something like 3GPP2 for CDMA 2000) and not the IETF. Is t= here = such a body?

The = IETF could assist such efforts by standardizing 802.11 MIBs, PIBs, or LDAP = = schema. If this is not sufficient, then generic requirements should be = formulated that are not well addressed by the current set of IETF protocols= and = should be addressed in the context of other security, management work,= = etc.

Otherwise we can start similar efforts for 802.16, 802.20, = etc.

Branislav

-----Original Message-----
From: lwapp-admin@frascone.= com = [mailto:lwapp-admin@frascone.com]On Behalf Of Mani, Mahalingam = (Mahalingam)
Sent: Thursday, November 27, 2003 1:23 PM
To= : = Mani, Mahalingam (Mahalingam); lwapp@frascone.com
Subject: RE: = = [Lwapp] Problem Statement Draft and Charter.
Importance: = High

Fixed access t= o the = documents:

=

Try the Proble= m = statement draft now at:

http://www.capwap.org/draft-calhoun-capwap-problem-stateme= nt-01.txt =

And the Charte= r = 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 statemen= t 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 re= mains = the same: http://www.fras= cone.com/lwapp/CAPWAP-charter.txt =

= ;

Regards,

-mani=

---------175816c5175816c5-- From pcalhoun@airespace.com Tue Dec 2 13:55:40 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Tue, 2 Dec 2003 05:55:40 -0800 Subject: [Lwapp] Problem Statement Draft and Charter. Message-ID: <55749BC69138654EBBC4C50BA4F556108400C7@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3B8DC.571822AE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I looked at the problem statement which is very nice and clear but IMHO = more appropriate for a standards group dedicated to 802.11 = infrastructure standardization (something like 3GPP2 for CDMA 2000) and = not the IETF. Is there such a body?=20 IEEE, but we've already had this conversation many times. moving = on... The IETF could assist such efforts by standardizing 802.11 MIBs, PIBs, = or LDAP schema. If this is not sufficient, then generic requirements = should be formulated that are not well addressed by the current set of = IETF protocols and should be addressed in the context of other security, = management work, etc. Inter-SDO standardization has never been very successful and is = very difficult to organize. Otherwise we can start similar efforts for 802.16, 802.20, etc. We have already agreed to limit the scope to 802.11. If the = resulting work is successful, and we are done, we can look at tackling = other technologies. ------_=_NextPart_001_01C3B8DC.571822AE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Problem Statement Draft and Charter.
I looked at the problem statement which is very nice = and clear but IMHO more appropriate for a standards group dedicated to = 802.11 infrastructure standardization (something like 3GPP2 for CDMA = 2000) and not the IETF. Is there such a body?

<PRC> IEEE, but we've already had this conversation many times. = moving on...

The IETF could assist such efforts by standardizing 802.11 MIBs, PIBs, = or LDAP schema. If this is not sufficient, then generic requirements = should be formulated that are not well addressed by the current set of = IETF protocols and should be addressed in the context of other security, = management work, etc.

<PRC> Inter-SDO standardization has never been very successful and = is very difficult to organize.

Otherwise we can start similar efforts for 802.16, 802.20, = etc.

<PRC> We have already agreed to limit the scope to 802.11. If the = resulting work is successful, and we are done, we can look at tackling = other technologies.
------_=_NextPart_001_01C3B8DC.571822AE-- From bran@arraycomm.com Tue Dec 2 17:19:37 2003 From: bran@arraycomm.com (Branislav Meandzija) Date: Tue, 2 Dec 2003 09:19:37 -0800 Subject: [Lwapp] Problem Statement Draft and Charter. Message-ID: <200312021719.hB2HJvft024484@lester.arraycomm.com> This is a multi-part message in MIME format ---------11b1617111b16171 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Problem Statement Draft and Charter. ----- The IETF could assist such efforts by standardizing 802.11 MIBs, PIBs, or= LDAP schema. If this is not sufficient, then generic requirements should b= e formulated that are not well addressed by the current set of IETF protoco= ls and should be addressed in the context of other security, management wor= k, etc. Inter-SDO standardization has never been very successful and is ver= y difficult to organize. = [bran] The AAA and mobility groups are working extremely well together wi= th 3GPP, 3GPP2 and the IEEE. = Otherwise we can start similar efforts for 802.16, 802.20, etc. We have already agreed to limit the scope to 802.11. If the resulti= ng work is successful, and we are done, we can look at tackling other techn= ologies. = [bran] That would be analogous to defining a new IP protocol specific to= a particular layer 2, lets say 802.3. Branislav ---------11b1617111b16171 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Problem Statement Draft and Charter.=

<= FONT = face=3DTahoma>-----
The IETF could assist such efforts by = standardizing 802.11 MIBs, PIBs, or LDAP schema. If this is not sufficien= t, = then generic requirements should be formulated that are not well addresse= d by = the current set of IETF protocols and should be addressed in the context = of = other security, management work, etc.

<PRC> Inter-SDO = standardization has never been very successful and is very difficult to = organize.

= [bran] The AAA and mobility groups are = working = extremely well together with 3GPP, 3GPP2 and the = IEEE.

Otherwise we can start similar effor= ts = for 802.16, 802.20, etc.

<PRC> We have already agreed = to = limit the scope to 802.11. If the resulting work is successful, and we ar= e = done, we can look at tackling other technologies.

= [bran]  That would be analogous to= defining = a new IP protocol specific to a particular layer 2, lets say = 802.3.

&= nbsp;

Branislav

---------11b1617111b16171-- From pcalhoun@airespace.com Tue Dec 2 17:53:13 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Tue, 2 Dec 2003 09:53:13 -0800 Subject: [Lwapp] Problem Statement Draft and Charter. Message-ID: <55749BC69138654EBBC4C50BA4F556108400D3@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3B8FD.280BE443 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The IETF could assist such efforts by standardizing 802.11 MIBs, PIBs, = or LDAP schema. If this is not sufficient, then generic requirements = should be formulated that are not well addressed by the current set of = IETF protocols and should be addressed in the context of other security, = management work, etc. Inter-SDO standardization has never been very successful and is = very difficult to organize. =20 [bran] The AAA and mobility groups are working extremely well together = with 3GPP, 3GPP2 and the IEEE.=20 I didn't say impossible, I said difficult. Further, we've = already discussed why this belongs in the IETF numerous=20 times both in face to face meetings as well as over the list. = We have thumbs up from the IEEE leadership on this, and=20 they have provided some very talented people to help with the = interactions. So if your comment is that the IEEE and=20 the IETF is incorrect, and you have specific reasons why this = belongs in a specific SDO, then please speak up. So far=20 you've been rather vague about where (any SDO other than = IETF), and why (because). BTW, 3GPP and 3GPP2 have their hands full with GSM and CDMA, = respectively. WiFi is not an SDO and IEEE agrees this is an IETF problem. Otherwise we can start similar efforts for 802.16, 802.20, etc. We have already agreed to limit the scope to 802.11. If the = resulting work is successful, and we are done, we can look at tackling = other technologies. =20 [bran] That would be analogous to defining a new IP protocol specific = to a particular layer 2, lets say 802.3. There is absolutely nothing wrong with trying to solve a very = specific market need, and this is the direction that the (proposed) WG has taken, at the request of the IESG. ------_=_NextPart_001_01C3B8FD.280BE443 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Problem Statement Draft and Charter.

The IETF could assist such efforts by = standardizing 802.11 MIBs, PIBs, or LDAP schema. If this is not = sufficient, then generic requirements should be formulated that are not = well addressed by the current set of IETF protocols and should be = addressed in the context of other security, management work, etc.

<PRC> Inter-SDO standardization has never been very = successful and is very difficult to organize.

[bran] The AAA and mobility groups are working extremely well = together with 3GPP, 3GPP2 and the IEEE.

<PRC-2> I didn't say impossible, I said difficult. Further, = we've already discussed why this belongs in the IETF numerous
          times both in = face to face meetings as well as over the list. We have thumbs up from = the IEEE leadership on this, and
          they have = provided some very talented people to help with the interactions. So if = your comment is that the IEEE and
          the IETF is = incorrect, and you have specific reasons why this belongs in a specific = SDO, then please speak up. So far
          you've been = rather vague about where (any SDO other than IETF), and why = (because).

<PRC> BTW, 3GPP and 3GPP2 have their hands full with GSM = and CDMA, respectively. WiFi is not an SDO and IEEE agrees this
        is an IETF problem.

Otherwise we can start similar efforts for 802.16, 802.20, = etc.

<PRC> We have already agreed to limit the scope to 802.11. = If the resulting work is successful, and we are done, we can look at = tackling other technologies.

[bran] That would be analogous to defining a new IP = protocol specific to a particular layer 2, lets say 802.3.

<PRC-2> There is absolutely nothing wrong with trying to = solve a very specific market need, and this is the direction that
          the (proposed) WG = has taken, at the request of the IESG.

------_=_NextPart_001_01C3B8FD.280BE443-- From bran@arraycomm.com Tue Dec 2 20:34:32 2003 From: bran@arraycomm.com (Branislav Meandzija) Date: Tue, 2 Dec 2003 12:34:32 -0800 Subject: [Lwapp] Problem Statement Draft and Charter. Message-ID: <200312022035.hB2KZ3ft004695@lester.arraycomm.com> This is a multi-part message in MIME format ---------4a062bb74a062bb7 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable The IETF could assist such efforts by standardizing 802.11 MIBs, PIBs, or= LDAP schema. If this is not sufficient, then generic requirements should b= e formulated that are not well addressed by the current set of IETF protoco= ls and should be addressed in the context of other security, management wor= k, etc. Inter-SDO standardization has never been very successful and is ver= y difficult to organize. = [bran] The AAA and mobility groups are working extremely well together wi= th 3GPP, 3GPP2 and the IEEE. I didn't say impossible, I said difficult. Further, we've already= discussed why this belongs in the IETF numerous times both in face to face meetings as well as over the list. We = have thumbs up from the IEEE leadership on this, and they have provided some very talented people to help with the int= eractions. So if your comment is that the IEEE and the IETF is incorrect, and you have specific reasons why this bel= ongs in a specific SDO, then please speak up. So far you've been rather vague about where (any SDO other than IETF), a= nd why (because). BTW, 3GPP and 3GPP2 have their hands full with GSM and CDMA, respec= tively. WiFi is not an SDO and IEEE agrees this is an IETF problem. = [bran] Sounds good to me and I like doing it here but I disagree that 802.= 11 infrastructure is the IETF's problem. Otherwise we can start similar efforts for 802.16, 802.20, etc. We have already agreed to limit the scope to 802.11. If the resulti= ng work is successful, and we are done, we can look at tackling other techn= ologies. = [bran] That would be analogous to defining a new IP protocol specific to= a particular layer 2, lets say 802.3. There is absolutely nothing wrong with trying to solve a very spe= cific market need, and this is the direction that the (proposed) WG has taken, at the request of the IESG. [bran] I have no problem with solving a specific market need within this u= mbrella. But, let's do it please in an architecturally sound way where we d= on't end up with a soup of standards which nobody cares about. To avoid tha= t, we would approach creation of new protocols more conservatively and make= due with the existing set. Or, did the IESG also agree to create a new IE= TF management protocol specific to 802.11? My guess would be no. Branislav ---------4a062bb74a062bb7 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Problem Statement Draft and Charter.=
I----= -Original = Message-----
From: Pat R. Calhoun = [mailto:pcalhoun@airespace.com]
Sent: Tuesday, December 02, 2003 = 9:53 = AM
To: Branislav Meandzija; Mani, Mahalingam (Mahalingam); = lwapp@frascone.com
Subject: RE: [Lwapp] Problem Statement Draft a= nd = Charter.

The IETF could assist such efforts by standardiz= ing = 802.11 MIBs, PIBs, or LDAP schema. If this is not sufficient, then generi= c = requirements should be formulated that are not well addressed by the curr= ent = set of IETF protocols and should be addressed in the context of other = security, management work, etc.

<PRC> Inter-SDO = standardization has never been very successful and is very difficult to = organize.

[bran] The AAA and mobility groups ar= e = working extremely well together with 3GPP, 3GPP2 and the IEEE.

&nb= sp; = <PRC-2> I didn't say impossible, I said difficult. Further, we've = already discussed why this belongs in the IETF = numerous
          times = both = in face to face meetings as well as over the list. We have thumbs up from= the = IEEE leadership on this, = and
          they have = provided some very talented people to help with the interactions. So if y= our = comment is that the IEEE = and
          the IETF is= = incorrect, and you have specific reasons why this belongs in a specific S= DO, = then please speak up. So = far
          you've been= = rather vague about where (any SDO other than IETF), and why = (because).

<PRC> BTW, 3GPP and 3GPP2 have their hands= full = with GSM and CDMA, respectively. WiFi is not an SDO and IEEE agrees = this
        is an IETF = problem.

= [bran] I didn't suggest 3GPP or 3GPP2 b= ut just = named them as examples of SDOs which work well with the IETF. I woul= = disagree that 802.11 infrastructure is the IETF's problem = but

Otherwise we = can = start similar efforts for 802.16, 802.20, etc.

<PR= C> = We have already agreed to limit the scope to 802.11. If the resulting wor= k is = successful, and we are done, we can look at tackling other = technologies.

[bran] That would be analog= ous = to defining a new IP protocol specific to a particular layer 2, lets say = = 802.3.

<PRC-2> There is absolutely nothing wrong with= = trying to solve a very specific market need, and this is the direction = that
          the (propo= sed) = WG has taken, at the request of the IESG.

[b= ran] I&nbs= p; have no = problem with solving a specific market need within this umbrella. But, le= t's = do it please in an architecturally sound way where we don't end up w= ith a = soup of standards which nobody cares about. To avoid that, we would appro= ach = creation of new protocols more conservatively and make due with the exist= ing = set.

Or, did the= IESG also = agree to create a new IETF management protocol specific to = 802.11?

Branislav

---------4a062bb74a062bb7-- From mmani@avaya.com Tue Dec 2 22:22:22 2003 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Tue, 2 Dec 2003 15:22:22 -0700 Subject: [Lwapp] Problem Statement Draft and Charter. Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C3B922.C1B65497 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Branislav, =20 I would like to understand what you mean by 802.11 infrastructure. If you meant 802.11 MAC layer protocols - CAPWAP does not attempt (re-inventing) that - very much along the lines of principles of not re-inventing protocols. =20 More inline. =20 -----Original Message----- From: Branislav Meandzija [mailto:bran@arraycomm.com]=20 Sent: Tuesday, December 02, 2003 12:35 PM To: Pat R. Calhoun; Mani, Mahalingam (Mahalingam); lwapp@frascone.com Subject: RE: [Lwapp] Problem Statement Draft and Charter. =20 I-----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Tuesday, December 02, 2003 9:53 AM To: Branislav Meandzija; Mani, Mahalingam (Mahalingam); lwapp@frascone.com Subject: RE: [Lwapp] Problem Statement Draft and Charter. =20 The IETF could assist such efforts by standardizing 802.11 MIBs, PIBs, or LDAP schema. If this is not sufficient, then generic requirements should be formulated that are not well addressed by the current set of IETF protocols and should be addressed in the context of other security, management work, etc. Inter-SDO standardization has never been very successful and is very difficult to organize. =20 [bran] The AAA and mobility groups are working extremely well together with 3GPP, 3GPP2 and the IEEE. I didn't say impossible, I said difficult. Further, we've already discussed why this belongs in the IETF numerous times both in face to face meetings as well as over the list. We have thumbs up from the IEEE leadership on this, and they have provided some very talented people to help with the interactions. So if your comment is that the IEEE and the IETF is incorrect, and you have specific reasons why this belongs in a specific SDO, then please speak up. So far you've been rather vague about where (any SDO other than IETF), and why (because). BTW, 3GPP and 3GPP2 have their hands full with GSM and CDMA, respectively. WiFi is not an SDO and IEEE agrees this is an IETF problem. =20 [bran] I didn't suggest 3GPP or 3GPP2 but just named them as examples of SDOs which work well with the IETF. I woul disagree that 802.11 infrastructure is the IETF's problem but=20 [Mani, Mahalingam (Mahalingam)] 802.11 infrastructure is a new interesting terminology. CAPWAP is attempting defining solution for the 802.11 linkage to IP infrastructure. Otherwise we can start similar efforts for 802.16, 802.20, etc. We have already agreed to limit the scope to 802.11. If the resulting work is successful, and we are done, we can look at tackling other technologies. =20 [bran] That would be analogous to defining a new IP protocol specific to a particular layer 2, lets say 802.3. There is absolutely nothing wrong with trying to solve a very specific market need, and this is the direction that the (proposed) WG has taken, at the request of the IESG. [bran] I have no problem with solving a specific market need within this umbrella. But, let's do it please in an architecturally sound way where we don't end up with a soup of standards which nobody cares about. To avoid that, we would approach creation of new protocols more conservatively and make due with the existing set. =20 Or, did the IESG also agree to create a new IETF management protocol specific to 802.11? [Mani, Mahalingam (Mahalingam)] IESG has suggested, so far, to focus on articulating the problem and architecture. It is far from taking a position on protocol choice this early. That will be putting the cart before the horse - although it is an effective way to initiate discussions on the problem. Branislav =20 [Mani, Mahalingam (Mahalingam)] -mani ------_=_NextPart_001_01C3B922.C1B65497 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Problem Statement Draft and Charter.

Branislav,

I would like to understand what you = mean by 802.11 infrastructure. If you meant 802.11 MAC layer protocols = – CAPWAP does not attempt (re-inventing) that – very much along the = lines of principles of not re-inventing protocols.

More inline.

-----Original Message-----
From: Branislav Meandzija [mailto:bran@arraycomm.com]
Sent: Tuesday, December = 02, 2003 12:35 PM
To: Pat R. Calhoun; Mani, Mahalingam (Mahalingam); lwapp@frascone.com
Subject: RE: [Lwapp] = Problem Statement Draft and Charter.

I-----Original Message-----
From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]
Sent: Tuesday, December = 02, 2003 9:53 AM
To: Branislav Meandzija; = Mani, Mahalingam (Mahalingam); lwapp@frascone.com
Subject: RE: [Lwapp] = Problem Statement Draft and Charter.

The IETF could assist such efforts by standardizing 802.11 MIBs, PIBs, = or LDAP schema. If this is not sufficient, then generic requirements should be formulated that are not well addressed by the current set of IETF = protocols and should be addressed in the context of other security, management work, = etc.

<PRC> Inter-SDO standardization has never been very = successful and is very difficult to organize.

[bran] The AAA and mobility groups are working extremely well = together with 3GPP, 3GPP2 and the IEEE.

<PRC-2> I didn't say impossible, I said difficult. Further, = we've already discussed why this belongs in the IETF numerous
          times both in = face to face meetings as well as over the list. We have thumbs up from the IEEE leadership on this, and
          they have = provided some very talented people to help with the interactions. So if your comment = is that the IEEE and
          the IETF is = incorrect, and you have specific reasons why this belongs in a specific SDO, then = please speak up. So far
          you've been = rather vague about where (any SDO other than IETF), and why (because).

<PRC> BTW, 3GPP and 3GPP2 have their hands full with GSM = and CDMA, respectively. WiFi is not an SDO and IEEE agrees this
        is an IETF problem.

[bran] I didn't suggest 3GPP or 3GPP2 = but just named them as examples of SDOs which work well with the = IETF. I woul disagree that 802.11 infrastructure is the IETF's problem = but

[Mani, Mahalingam (Mahalingam)] 802.11 infrastructure is a new interesting terminology. CAPWAP is attempting defining solution for the 802.11 = linkage to IP infrastructure.

Otherwise we can start similar efforts for 802.16, 802.20, = etc.

<PRC> We have already agreed to limit the scope to 802.11. = If the resulting work is successful, and we are done, we can look at tackling = other technologies.

[bran] That would be analogous to defining a new IP = protocol specific to a particular layer 2, lets say 802.3.

<PRC-2> There is absolutely nothing wrong with trying to = solve a very specific market need, and this is the direction that
          the (proposed) WG = has taken, at the request of the IESG.

[bran] I have no problem with = solving a specific market need within this umbrella. But, let's do it = please in an architecturally sound way where we don't end up with a soup of standards = which nobody cares about. To avoid that, we would approach creation of new = protocols more conservatively and make due with the existing = set.

Or, did the IESG also agree to create a new IETF = management protocol specific to 802.11?

[Mani, Mahalingam (Mahalingam)] IESG has suggested, so far, to focus on = articulating the problem and architecture. It is far from taking a position on = protocol choice this early.

That = will be putting the cart before the horse – although it is an effective way to = initiate discussions on the problem.

Branislav

[Mani, Mahalingam (Mahalingam)] -mani

------_=_NextPart_001_01C3B922.C1B65497-- From bran@arraycomm.com Tue Dec 2 22:59:04 2003 From: bran@arraycomm.com (Branislav Meandzija) Date: Tue, 2 Dec 2003 14:59:04 -0800 Subject: [Lwapp] Problem Statement Draft and Charter. Message-ID: <200312022259.hB2Mxaft007239@lester.arraycomm.com> This is a multi-part message in MIME format ---------6c8670396c867039 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Problem Statement Draft and Charter.Mani, 802.11 infrastructure to me is the physical/software/standard environment t= hat facilitates the deployment of the 802.11 standard (e.g. the suggested A= C). But in any case, as there seem to be be at least two fundamentally differen= t ways of looking at this problem domain, it would be nicer and wiser to pr= oceed with solving the problem in both directions at least initially, and t= hen see which approach is more promising once we have concrete technical pr= oposals. So, it would be nice to now create high-level technical solution a= lternatives for the problems that you have compiled. Branislav -----Original Message----- From: Mani, Mahalingam (Mahalingam) [mailto:mmani@avaya.com] Sent: Tuesday, December 02, 2003 2:22 PM To: Branislav Meandzija; Pat R. Calhoun; lwapp@frascone.com Subject: RE: [Lwapp] Problem Statement Draft and Charter. Branislav, I would like to understand what you mean by 802.11 infrastructure. If you= meant 802.11 MAC layer protocols =96 CAPWAP does not attempt (re-inventing= ) that =96 very much along the lines of principles of not re-inventing prot= ocols. More inline. -----Original Message----- From: Branislav Meandzija [mailto:bran@arraycomm.com] = Sent: Tuesday, December 02, 2003 12:35 PM To: Pat R. Calhoun; Mani, Mahalingam (Mahalingam); lwapp@frascone.com Subject: RE: [Lwapp] Problem Statement Draft and Charter. I-----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Tuesday, December 02, 2003 9:53 AM To: Branislav Meandzija; Mani, Mahalingam (Mahalingam); lwapp@frascone.co= m Subject: RE: [Lwapp] Problem Statement Draft and Charter. The IETF could assist such efforts by standardizing 802.11 MIBs, PIBs= , or LDAP schema. If this is not sufficient, then generic requirements shou= ld be formulated that are not well addressed by the current set of IETF pro= tocols and should be addressed in the context of other security, management= work, etc. Inter-SDO standardization has never been very successful and is= very difficult to organize. = [bran] The AAA and mobility groups are working extremely well togethe= r with 3GPP, 3GPP2 and the IEEE. I didn't say impossible, I said difficult. Further, we've alr= eady discussed why this belongs in the IETF numerous times both in face to face meetings as well as over the list.= We have thumbs up from the IEEE leadership on this, and they have provided some very talented people to help with the= interactions. So if your comment is that the IEEE and the IETF is incorrect, and you have specific reasons why this= belongs in a specific SDO, then please speak up. So far you've been rather vague about where (any SDO other than IETF= ), and why (because). BTW, 3GPP and 3GPP2 have their hands full with GSM and CDMA, re= spectively. WiFi is not an SDO and IEEE agrees this is an IETF problem. = [bran] I didn't suggest 3GPP or 3GPP2 but just named them as examples o= f SDOs which work well with the IETF. I woul disagree that 802.11 infrastru= cture is the IETF's problem but = [Mani, Mahalingam (Mahalingam)] 802.11 infrastructure is a new interest= ing terminology. CAPWAP is attempting defining solution for the 802.11 link= age to IP infrastructure. Otherwise we can start similar efforts for 802.16, 802.20, etc. We have already agreed to limit the scope to 802.11. If the res= ulting work is successful, and we are done, we can look at tackling other t= echnologies. = [bran] That would be analogous to defining a new IP protocol specifi= c to a particular layer 2, lets say 802.3. There is absolutely nothing wrong with trying to solve a very= specific market need, and this is the direction that the (proposed) WG has taken, at the request of the IESG. [bran] I have no problem with solving a specific market need within th= is umbrella. But, let's do it please in an architecturally sound way where = we don't end up with a soup of standards which nobody cares about. To avoid= that, we would approach creation of new protocols more conservatively and = make due with the existing set. = Or, did the IESG also agree to create a new IETF management protocol sp= ecific to 802.11? [Mani, Mahalingam (Mahalingam)] IESG has suggested, so far, to focus on= articulating the problem and architecture. It is far from taking a positio= n on protocol choice this early. That will be putting the cart before the horse =96 although it is an ef= fective way to initiate discussions on the problem. Branislav = [Mani, Mahalingam (Mahalingam)] -mani ---------6c8670396c867039 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Problem Statement Draft and Charter.=
Mani,

802.11 = infrastructure to me is the physical/software/standard environment that = facilitates the deployment of the 802.11 standard (e.g. the suggested = = AC).

But in = any case, as there seem to be be at least two fundamentally different ways = of = looking at this problem domain, it would be nicer and wiser to proceed with= = solving the problem in both directions at least initially, and then see whi= ch = approach is more promising once we have concrete technical proposals. So, i= t = would be nice to now create high-level technical solution alternatives for = the = problems that you have compiled.

Branislav

-----Original Message-----
From:<= /B> = Mani, Mahalingam (Mahalingam) [mailto:mmani@avaya.com]
Sent: Tues= day, = December 02, 2003 2:22 PM
To: Branislav Meandzija; Pat R. Calhoun= ; = lwapp@frascone.com
Subject: RE: [Lwapp] Problem Statement Draft a= nd = Charter.

Branislav,

=

I would like t= o = understand what you mean by 802.11 infrastructure. If you meant 802.11 MA= C = layer protocols =96 CAPWAP does not attempt (re-inventing) that =96 very = much = along the lines of principles of not re-inventing protocols.

=

More = inline.

=

-----Original = Message-----
From: Bra= nislav = Meandzija [mailto:bran@arraycomm.com]
Sent: Tuesday, December 02, 2003 1= 2:35 = PM
To: Pat R. Calhoun;= Mani, = Mahalingam (Mahalingam); lwapp@frascone.com
Subject: RE: [Lwapp] Problem State= ment = Draft and Charter.

I-----Original = Message-----
From: Pat= R. = Calhoun [mailto:pcalhoun@airespace.com]
Sent: Tuesday, December 02, 2003 9= :53 = AM
To: Branislav Meand= zija; = Mani, Mahalingam (Mahalingam); lwapp@frascone.com
Subject: RE: [Lwapp] Problem State= ment = Draft and Charter.

= The IETF could assist such efforts by standardizing 802.11 MIBs, PIBs, = or = LDAP schema. If this is not sufficient, then generic requirements shoul= d be = formulated that are not well addressed by the current set of IETF proto= cols = and should be addressed in the context of other security, management wo= rk, = etc.

<PRC> Inter-SDO standardization has never been= very = successful and is very difficult to organize.

= = [bran] The AAA and mobility groups are working extremely well together = with = 3GPP, 3GPP2 and the IEEE.

<PRC-2> I didn't say = impossible, I said difficult. Further, we've already discussed why this= = belongs in the IETF = numerous
          time= s = both in face to face meetings as well as over the list. We have thumbs = up = from the IEEE leadership on this, = and
          they have= = provided some very talented people to help with the interactions. So if= your = comment is that the IEEE = and
          the IETF = is = incorrect, and you have specific reasons why this belongs in a specific= SDO, = then please speak up. So = far
          you've be= en = rather vague about where (any SDO other than IETF), and why = (because).

<PRC> BTW, 3GPP and 3GPP2 have their han= ds = full with GSM and CDMA, respectively. WiFi is not an SDO and IEEE agree= s = this
        is an IETF = problem.

[bran] = I = didn't suggest 3GPP or 3GPP2 but just named them as examples of SDOs wh= ich = work well with the IETF. I woul disagree that 802.11 = infrastructure is the IETF's problem but

[Mani, = Mahalingam (Mahalingam)] 802.11 infrastructure is a new interesting = terminology. CAPWAP is attempting defining solution for the 802.11 link= age = to IP infrastructure.

<= /FONT>
Otherwise we can st= art = similar efforts for 802.16, 802.20, etc.

<PRC>= ; We = have already agreed to limit the scope to 802.11. If the resulting work= is = successful, and we are done, we can look at tackling other = technologies.

[bran] That would be anal= ogous = to defining a new IP protocol specific to a particular layer 2, lets sa= y = 802.3.

<PRC-2> There is absolutely nothing wrong wi= th = trying to solve a very specific market need, and this is the direction = = that
          the = (proposed) WG has taken, at the request of the = IESG.

[bran] = I = have no problem with solving a specific market need within this umbrell= a. = But, let's do it please in an architecturally sound way where we d= on't = end up with a soup of standards which nobody cares about. To avoid that= , we = would approach creation of new protocols more conservatively and make d= ue = with the existing set.

Or, did the = IESG = also agree to create a new IETF management protocol specific to = 802.11?

[Mani, = Mahalingam (Mahalingam)] IESG has suggested, so far, to focus on = articulating the problem and architecture. It is far from taking a posi= tion = on protocol choice this early.

That = will be putting the cart before the horse =96 although it is an effecti= ve way = to initiate discussions on the problem.

Branislav

[Mani, = Mahalingam (Mahalingam)] = -mani
---------6c8670396c867039-- From pcalhoun@airespace.com Tue Dec 2 23:54:29 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Tue, 2 Dec 2003 15:54:29 -0800 Subject: [Lwapp] Problem Statement Draft and Charter. Message-ID: <55749BC69138654EBBC4C50BA4F556108400EE@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3B92F.ACC3EAC4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable But in any case, as there seem to be be at least two fundamentally = different ways of looking at this problem domain, it would be nicer and = wiser to proceed with solving the problem in both directions at least = initially, and then see which approach is more promising once we have = concrete technical proposals. So, it would be nice to now create = high-level technical solution alternatives for the problems that you = have compiled. So the way the IETF works is for you to propose text for the = draft. patC ------_=_NextPart_001_01C3B92F.ACC3EAC4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Problem Statement Draft and Charter.
But in any case, as there seem to be be at least two = fundamentally different ways of looking at this problem domain, it would = be nicer and wiser to proceed with solving the problem in both = directions at least initially, and then see which approach is more = promising once we have concrete technical proposals. So, it would be = nice to now create high-level technical solution alternatives for the = problems that you have compiled.

<PRC> So the way the IETF works is for you to propose text for the = draft.

patC
------_=_NextPart_001_01C3B92F.ACC3EAC4-- From bran@arraycomm.com Wed Dec 3 00:10:02 2003 From: bran@arraycomm.com (Branislav Meandzija) Date: Tue, 2 Dec 2003 16:10:02 -0800 Subject: [Lwapp] Problem Statement Draft and Charter. Message-ID: <200312030010.hB30AZft006972@lester.arraycomm.com> This is a multi-part message in MIME format ---------1a3f2bd31a3f2bd3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Problem Statement Draft and Charter. -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Tuesday, December 02, 2003 3:54 PM To: Branislav Meandzija; Mani, Mahalingam (Mahalingam); lwapp@frascone.co= m Subject: RE: [Lwapp] Problem Statement Draft and Charter. But in any case, as there seem to be be at least two fundamentally differ= ent ways of looking at this problem domain, it would be nicer and wiser to = proceed with solving the problem in both directions at least initially, and= then see which approach is more promising once we have concrete technical = proposals. So, it would be nice to now create high-level technical solution= alternatives for the problems that you have compiled. So the way the IETF works is for you to propose text for the draft.= [bran] Or anybody else interested :-) Branislav = ---------1a3f2bd31a3f2bd3 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Problem Statement Draft and Charter.=

-----Original Message-----
From: Pat R. Calhoun = [mailto:pcalhoun@airespace.com]
Sent: Tuesday, December 02, 200= 3 = 3:54 PM
To: Branislav Meandzija; Mani, Mahalingam (Mahalingam);= = lwapp@frascone.com
Subject: RE: [Lwapp] Problem Statement Draft= and = Charter.

But in any case, as there seem to be be at least two = fundamentally different ways of looking at this problem domain, it would = be = nicer and wiser to proceed with solving the problem in both directions at= = least initially, and then see which approach is more promising once we ha= ve = concrete technical proposals. So, it would be nice to now create high-lev= el = technical solution alternatives for the problems that you have = compiled.

<PRC> So the way the IETF works is for you to prop= ose = text for the draft.

[bran] Or anybody else interested = :-)

Branislav
---------1a3f2bd31a3f2bd3-- From cchaplin@sj.symbol.com Wed Dec 3 19:03:12 2003 From: cchaplin@sj.symbol.com (Clint Chaplin) Date: Wed, 03 Dec 2003 11:03:12 -0800 Subject: [Lwapp] Problem Statement Draft and Charter. Message-ID: It may be that 802.11 itself will become the appropriate place for something like this. 802.11 is not limited by anything external (LMSC, IEEE SA) to just Layer 1 and Layer 2, only 802.11's charter itself is the limiting factor. There is a possible push to expand 802.11's charter upwards. If that happens, then this effort could very well fit there. Clint (JOATMON) Chaplin >>> Branislav Meandzija 12/1/03 20:28:24 >>> I looked at the problem statement which is very nice and clear but IMHO more appropriate for a standards group dedicated to 802.11 infrastructure standardization (something like 3GPP2 for CDMA 2000) and not the IETF. Is there such a body? The IETF could assist such efforts by standardizing 802.11 MIBs, PIBs, or LDAP schema. If this is not sufficient, then generic requirements should be formulated that are not well addressed by the current set of IETF protocols and should be addressed in the context of other security, management work, etc. Otherwise we can start similar efforts for 802.16, 802.20, etc. Branislav -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com]On Behalf Of Mani, Mahalingam (Mahalingam) Sent: Thursday, November 27, 2003 1:23 PM To: Mani, Mahalingam (Mahalingam); lwapp@frascone.com Subject: RE: [Lwapp] Problem Statement Draft and Charter. Importance: High 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/CAPWAP-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.frascone.com/lwapp/CAPWAP-charter.txt Regards, -mani ________________________________________________________________________ This email has been scanned for computer viruses. From mmani@avaya.com Thu Dec 11 20:22:36 2003 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Thu, 11 Dec 2003 13:22:36 -0700 Subject: [Lwapp] Comments Invited: Charter Refined. Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C3C024.8432C502 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Following intense deliberations in and between IESG and IAB - the following refined charter has been proposed. In my opinion this is a generalized abstraction of the one discussed in Minneapolis - sans external references (they are abstracted inline) and with a cleaner assertions of the problems - from first principles. =20 It appears to take a step back and urges a look at available architectural taxonomy without (split-AP et al) architectural presumptions - though the split is the prime reason for the BoF initiative. =20 By and large the charter and description track the problem statement but in a generic manner earlier proposed work. =20 Comments are welcome. =20 Regards, -mani =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= Proposed charter = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Control and Provisioning of Wireless Access Points BOF (CAPWAP) =20 DESCRIPTION: As the size and complexity of IEEE 802.11 wireless networks has=20 increased, problems in the deployment, management, and usability of=20 these networks have become evident. Access points (APs) typically=20 require complex management at the IP level. As the number of APs=20 increases, the number of devices requiring complex management=20 increases, in some cases, doubling the number of IP devices requiring=20 management in a provider's network. In addition, because APs have no=20 visibility beyond their own cell, a variety of problems ensue in large=20 scale 802.11 networks. Load balancing between APs, dead cell detection,=20 and correlating patterns of usage between APs to detect attacks are difficult to impossible. Finally, because each AP acts as its own Network Access Server (NAS), a network provider is faced with the prospect of moving from a situation where the NAS is a few machines with dialup access in a machine room to a=20 situation where hundreds or perhaps thousands of devices scattered across a wide geographic area have NAS functionality. Maintaining security on such a wide collection of devices is a difficult challenge. =20 In recent attempts to solve these problems, various vendors have=20 introduced products that redistribute the functionality of 802.11 APs=20 in various ways. However, because the 802.11 access network functional=20 architecture is incompletely specified, the network interfaces between=20 network entities in different vendors' products are defined in=20 incompatible ways. As a result, the protocols between the network entities in different products are not interoperable. =20 CHARTER: As a first step, the CAPWAP Working Group will develop a problem=20 statement and network architecture taxonomy describing the current set=20 of approaches to providing more support for scalable 802.11 access=20 networks. The problem statement will describe, at a high level, what=20 the deployment, management, and usability concerns are with 802.11=20 networks based on the traditional autonomous AP architecture, and will=20 link those concerns to specific technical aspects of the autonomous AP architecture. The network architecture taxonomy will: =20 - Describe the current set of approaches (including the traditional autonomous AP architecture) to partitioning 802.11 access network functionality between network entities, - List what the interfaces between the network entities are in each approach, - At a functional level, describe what the protocols on the interfaces between the network entites in each approach do, - Describe the advantages and disadvantages of each approach for scalable 802.11 access network deployment and management. =20 Additionally, the architecture document will contain a threat analysis=20 that describes the security threats involved in each network=20 architectural approach. =20 Specific Working Group deliverables are: =20 - A problem statement document, - A network architecture taxonomy document including threat analysis. =20 Specific non-goals of this work are: - Any work requiring revising the 802.11 access network functional architecture =20 The CAPWAP WG will maintain a close working liaison with relevant=20 working groups in IEEE 802.11 and IEEE 802.1. Working Group documents=20 will be sent to an expert review board for review prior to submission=20 to the IESG. In order to facilitate quick completion of this work, the=20 Working Group charter will expire 9 months after it is approved by the=20 IESG, at which time the Working Group can either petition the IESG for a continuation or recharter for further work on the=20 interoperability problem. =20 Goals and Milestones: Feb 2004: Last call for problem statement draft. Mar 2004 Discuss last call comments for problem statement at IETF 59. Mar 2004: Last Call for architecture description document. Apr 2004: Submit problem statement to IESG for publication approval. May 2004: Architecture document to expert review. Aug 2004 Discuss last call comments at IETF 60. Aug 2004: Submit architecture document to IESG for publication approval. Sep 2004: Re-charter =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Dend charter = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 ------_=_NextPart_001_01C3C024.8432C502 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Following intense deliberations in and between IESG = and IAB – the following refined charter has been = proposed.

In my opinion this is a generalized abstraction of = the one discussed in Minneapolis – sans external = references (they are abstracted inline) and with a cleaner assertions of the = problems - from first principles.

It appears to take a step back and urges a look at = available architectural taxonomy without (split-AP et al) architectural = presumptions – though the split is the prime reason for the BoF = initiative.

By and large the charter and description track the = problem statement but in a generic manner earlier proposed = work.

Comments are welcome.

Regards,

-mani

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Proposed charter =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Control and Provisioning of Wireless Access = Points BOF (CAPWAP)

DESCRIPTION:

As the size and complexity of IEEE 802.11 = wireless networks has

increased, problems in the deployment, = management, and usability of

these networks have become evident. Access = points (APs) typically

require complex management at the IP level. = As the number of APs

increases, the number of devices requiring = complex management

increases, in some cases, doubling the number = of IP devices requiring

management in a provider's network. In = addition, because APs have no

visibility beyond their own cell, a variety = of problems ensue in large

scale 802.11 networks. Load balancing between = APs, dead cell detection,

and correlating patterns of usage between APs = to detect attacks are

difficult to impossible. Finally, because = each AP acts as its

own Network Access Server (NAS), a network = provider is faced

with the prospect of moving from a situation = where the NAS is

a few machines with dialup access in a = machine room to a

situation where hundreds or perhaps thousands = of devices

scattered across a wide geographic area have = NAS functionality.

Maintaining security on such a wide = collection of devices is a

difficult challenge.

In recent attempts to solve these problems, = various vendors have

introduced products that redistribute the functionality of 802.11 APs

in various ways. However, because the 802.11 = access network functional

architecture is incompletely specified, the = network interfaces between

network entities in different vendors' = products are defined in

incompatible ways. As a result, the protocols between the network

entities in different products are not interoperable.

CHARTER:

As a first step, the CAPWAP Working Group = will develop a problem

statement and network architecture taxonomy describing the current set

of approaches to providing more support for = scalable 802.11 access

networks. The problem statement will = describe, at a high level, what

the deployment, management, and usability = concerns are with 802.11

networks based on the traditional autonomous = AP architecture, and will

link those concerns to specific technical = aspects of the autonomous AP

architecture. The network architecture = taxonomy will:

- Describe the current set of = approaches (including the

    traditional autonomous AP architecture) to partitioning

    802.11 access network functionality between network

    = entities,

- List what the interfaces between the network entities

    are in each = approach,

- At a functional level, describe what = the protocols on

    the interfaces between the network entites in each

    approach = do,

- Describe the advantages and = disadvantages of each

    approach for scalable = 802.11 access network deployment

    and = management.

Additionally, the architecture document will = contain a threat analysis

that describes the security threats involved = in each network

architectural approach.

Specific Working Group deliverables = are:

    - A problem statement = document,

    - A network architecture = taxonomy document including

      threat = analysis.

Specific non-goals of this work = are:

    - Any work requiring = revising the 802.11 access network

      functional architecture

The CAPWAP WG will maintain a close working = liaison with relevant

working groups in IEEE 802.11 and IEEE 802.1. Working Group documents

will be sent to an expert review board for = review prior to submission

to the IESG. In order to facilitate quick = completion of this work, the

Working Group charter will expire 9 months = after it is approved by the

IESG, at which time the Working Group can = either petition the IESG

for a continuation or recharter for further = work on the

interoperability problem.

Goals and Milestones:

Feb 2004: Last call for problem statement draft.

Mar 2004 Discuss last call comments for problem statement

            at IETF 59.

Mar 2004: Last Call for = architecture description document.

Apr 2004: Submit problem = statement to IESG for publication

            approval.

May 2004: Architecture document = to expert review.

Aug 2004 Discuss last call comments at IETF 60.

Aug 2004: Submit architecture = document to IESG for publication

            approval.

Sep 2004: = Re-charter

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Dend charter = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

------_=_NextPart_001_01C3C024.8432C502-- From sgoswami@umich.edu Thu Dec 11 22:09:11 2003 From: sgoswami@umich.edu (s. goswami) Date: Thu, 11 Dec 2003 17:09:11 -0500 (EST) Subject: [Lwapp] Comments Invited: Charter Refined. In-Reply-To: References: Message-ID: Hi, a few simple questions. 1. Is there any reason for limiting a layer 3+ protocol to just one layer 2 protocol (802.11). Looks like a very narrow and short sighted goal. Is the charter of LWAPP solely to patch up the big holes left by 802.11 stemming from use well beyond designed limits. 2. If it is very specific to 802.11 than should it not be done umder the aegis of IEEE or an independent forum along the line of DSL Forum ? 3. Is IP going to be used in LWAPP or is it optional ? Subrata On Thu, 11 Dec 2003, Mani, Mahalingam (Mahalingam) wrote: > Following intense deliberations in and between IESG and IAB - the > following refined charter has been proposed. > > In my opinion this is a generalized abstraction of the one discussed in > Minneapolis - sans external references (they are abstracted inline) and > with a cleaner assertions of the problems - from first principles. > > > > It appears to take a step back and urges a look at available > architectural taxonomy without (split-AP et al) architectural > presumptions - though the split is the prime reason for the BoF > initiative. > > > > By and large the charter and description track the problem statement but > in a generic manner earlier proposed work. > > > > Comments are welcome. > > > > Regards, > > -mani > > ========================= Proposed charter ==================== > > Control and Provisioning of Wireless Access Points BOF (CAPWAP) > > > > DESCRIPTION: > > As the size and complexity of IEEE 802.11 wireless networks has > > increased, problems in the deployment, management, and usability of > > these networks have become evident. Access points (APs) typically > > require complex management at the IP level. As the number of APs > > increases, the number of devices requiring complex management > > increases, in some cases, doubling the number of IP devices requiring > > management in a provider's network. In addition, because APs have no > > visibility beyond their own cell, a variety of problems ensue in large > > scale 802.11 networks. Load balancing between APs, dead cell detection, > > and correlating patterns of usage between APs to detect attacks are > > difficult to impossible. Finally, because each AP acts as its > > own Network Access Server (NAS), a network provider is faced > > with the prospect of moving from a situation where the NAS is > > a few machines with dialup access in a machine room to a > > situation where hundreds or perhaps thousands of devices > > scattered across a wide geographic area have NAS functionality. > > Maintaining security on such a wide collection of devices is a > > difficult challenge. > > > > In recent attempts to solve these problems, various vendors have > > introduced products that redistribute the functionality of 802.11 APs > > in various ways. However, because the 802.11 access network functional > > architecture is incompletely specified, the network interfaces between > > network entities in different vendors' products are defined in > > incompatible ways. As a result, the protocols between the network > > entities in different products are not interoperable. > > > > CHARTER: > > As a first step, the CAPWAP Working Group will develop a problem > > statement and network architecture taxonomy describing the current set > > of approaches to providing more support for scalable 802.11 access > > networks. The problem statement will describe, at a high level, what > > the deployment, management, and usability concerns are with 802.11 > > networks based on the traditional autonomous AP architecture, and will > > link those concerns to specific technical aspects of the autonomous AP > > architecture. The network architecture taxonomy will: > > > > - Describe the current set of approaches (including the > > traditional autonomous AP architecture) to partitioning > > 802.11 access network functionality between network > > entities, > > - List what the interfaces between the network entities > > are in each approach, > > - At a functional level, describe what the protocols on > > the interfaces between the network entites in each > > approach do, > > - Describe the advantages and disadvantages of each > > approach for scalable 802.11 access network deployment > > and management. > > > > Additionally, the architecture document will contain a threat analysis > > that describes the security threats involved in each network > > architectural approach. > > > > Specific Working Group deliverables are: > > > > - A problem statement document, > > - A network architecture taxonomy document including > > threat analysis. > > > > Specific non-goals of this work are: > > - Any work requiring revising the 802.11 access network > > functional architecture > > > > The CAPWAP WG will maintain a close working liaison with relevant > > working groups in IEEE 802.11 and IEEE 802.1. Working Group documents > > will be sent to an expert review board for review prior to submission > > to the IESG. In order to facilitate quick completion of this work, the > > Working Group charter will expire 9 months after it is approved by the > > IESG, at which time the Working Group can either petition the IESG > > for a continuation or recharter for further work on the > > interoperability problem. > > > > Goals and Milestones: > > Feb 2004: Last call for problem statement draft. > > Mar 2004 Discuss last call comments for problem statement > > at IETF 59. > > Mar 2004: Last Call for architecture description document. > > Apr 2004: Submit problem statement to IESG for publication > > approval. > > May 2004: Architecture document to expert review. > > Aug 2004 Discuss last call comments at IETF 60. > > Aug 2004: Submit architecture document to IESG for publication > > approval. > > Sep 2004: Re-charter > > ================end charter ======================= > > > > From Dorothy.Gellert@nokia.com Thu Dec 11 22:37:51 2003 From: Dorothy.Gellert@nokia.com (Dorothy.Gellert@nokia.com) Date: Thu, 11 Dec 2003 14:37:51 -0800 Subject: [Lwapp] Comments Invited: Charter Refined. Message-ID: <4D7B558499107545BB45044C63822DDE03F0821D@mvebe001.americas.nokia.com> Hi Subrata- Let me address the first 2 comments... =20 The IESG recommended limiting the charter to 802.11 to establish a = working relationship with IEEE and narrow our focus to ensure we get a = work done to meet the market need in a timely fashion. The charter = exists for 9 months to address problem statement and architecture only, = after which we can re-charter and revisit this issue. Does that sound fair? Dorothy > -----Original Message----- > From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com]On > Behalf Of ext s. goswami > Sent: Thursday, December 11, 2003 2:09 PM > Cc: lwapp@frascone.com > Subject: Re: [Lwapp] Comments Invited: Charter Refined. >=20 >=20 >=20 > Hi, a few simple questions. >=20 > 1. Is there any reason for limiting a layer 3+ protocol to just > one layer 2 protocol (802.11). Looks like a very narrow and > short sighted goal. Is the charter of LWAPP solely to patch up > the big holes left by 802.11 stemming from use well > beyond designed limits. >=20 > 2. If it is very specific to 802.11 than should it not be done > umder the aegis of IEEE or an independent forum along the > line of DSL Forum ? >=20 > 3. Is IP going to be used in LWAPP or is it optional ? >=20 >=20 > Subrata >=20 > On Thu, 11 Dec 2003, Mani, Mahalingam (Mahalingam) wrote: >=20 > > Following intense deliberations in and between IESG and IAB - the > > following refined charter has been proposed. > > > > In my opinion this is a generalized abstraction of the one=20 > discussed in > > Minneapolis - sans external references (they are =20 > abstracted inline) and > > with a cleaner assertions of the problems - from first principles. > > > > > > > > It appears to take a step back and urges a look at available > > architectural taxonomy without (split-AP et al) architectural > > presumptions - though the split is the prime reason for the BoF > > initiative. > > > > > > > > By and large the charter and description track the problem=20 > statement but > > in a generic manner earlier proposed work. > > > > > > > > Comments are welcome. > > > > > > > > Regards, > > > > -mani > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= Proposed charter = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Control and Provisioning of Wireless Access Points BOF (CAPWAP) > > > > > > > > DESCRIPTION: > > > > As the size and complexity of IEEE 802.11 wireless networks has > > > > increased, problems in the deployment, management, and usability of > > > > these networks have become evident. Access points (APs) typically > > > > require complex management at the IP level. As the number of APs > > > > increases, the number of devices requiring complex management > > > > increases, in some cases, doubling the number of IP devices=20 > requiring > > > > management in a provider's network. In addition, because APs have no > > > > visibility beyond their own cell, a variety of problems=20 > ensue in large > > > > scale 802.11 networks. Load balancing between APs, dead=20 > cell detection, > > > > and correlating patterns of usage between APs to detect attacks are > > > > difficult to impossible. Finally, because each AP acts as its > > > > own Network Access Server (NAS), a network provider is faced > > > > with the prospect of moving from a situation where the NAS is > > > > a few machines with dialup access in a machine room to a > > > > situation where hundreds or perhaps thousands of devices > > > > scattered across a wide geographic area have NAS functionality. > > > > Maintaining security on such a wide collection of devices is a > > > > difficult challenge. > > > > > > > > In recent attempts to solve these problems, various vendors have > > > > introduced products that redistribute the functionality of=20 > 802.11 APs > > > > in various ways. However, because the 802.11 access network=20 > functional > > > > architecture is incompletely specified, the network=20 > interfaces between > > > > network entities in different vendors' products are defined in > > > > incompatible ways. As a result, the protocols between the network > > > > entities in different products are not interoperable. > > > > > > > > CHARTER: > > > > As a first step, the CAPWAP Working Group will develop a problem > > > > statement and network architecture taxonomy describing the=20 > current set > > > > of approaches to providing more support for scalable 802.11 access > > > > networks. The problem statement will describe, at a high level, what > > > > the deployment, management, and usability concerns are with 802.11 > > > > networks based on the traditional autonomous AP=20 > architecture, and will > > > > link those concerns to specific technical aspects of the=20 > autonomous AP > > > > architecture. The network architecture taxonomy will: > > > > > > > > - Describe the current set of approaches (including the > > > > traditional autonomous AP architecture) to partitioning > > > > 802.11 access network functionality between network > > > > entities, > > > > - List what the interfaces between the network entities > > > > are in each approach, > > > > - At a functional level, describe what the protocols on > > > > the interfaces between the network entites in each > > > > approach do, > > > > - Describe the advantages and disadvantages of each > > > > approach for scalable 802.11 access network deployment > > > > and management. > > > > > > > > Additionally, the architecture document will contain a=20 > threat analysis > > > > that describes the security threats involved in each network > > > > architectural approach. > > > > > > > > Specific Working Group deliverables are: > > > > > > > > - A problem statement document, > > > > - A network architecture taxonomy document including > > > > threat analysis. > > > > > > > > Specific non-goals of this work are: > > > > - Any work requiring revising the 802.11 access network > > > > functional architecture > > > > > > > > The CAPWAP WG will maintain a close working liaison with relevant > > > > working groups in IEEE 802.11 and IEEE 802.1. Working Group=20 > documents > > > > will be sent to an expert review board for review prior to=20 > submission > > > > to the IESG. In order to facilitate quick completion of=20 > this work, the > > > > Working Group charter will expire 9 months after it is=20 > approved by the > > > > IESG, at which time the Working Group can either petition the IESG > > > > for a continuation or recharter for further work on the > > > > interoperability problem. > > > > > > > > Goals and Milestones: > > > > Feb 2004: Last call for problem statement draft. > > > > Mar 2004 Discuss last call comments for problem statement > > > > at IETF 59. > > > > Mar 2004: Last Call for architecture description document. > > > > Apr 2004: Submit problem statement to IESG for publication > > > > approval. > > > > May 2004: Architecture document to expert review. > > > > Aug 2004 Discuss last call comments at IETF 60. > > > > Aug 2004: Submit architecture document to IESG for publication > > > > approval. > > > > Sep 2004: Re-charter > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Dend charter = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp >=20 From kempf@docomolabs-usa.com Thu Dec 11 22:57:58 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Thu, 11 Dec 2003 14:57:58 -0800 Subject: [Lwapp] Comments Invited: Charter Refined. References: Message-ID: <02b801c3c03a$38a32d00$666015ac@dclkempt40> Subrata, I believe the intent of the charter is to develop a clearly written specification of the network architecture(1) assumed by the vendors of various AP products(2). Once that is accomplished, the areas of non-interoperability between the vendors' products should become clear, and the vendors should be in a position to discuss designing a protocol that would, in fact, be interoperable, either in the IETF (if the IESG decides to recharter) or elsewhere. I believe going through this exercise for 802.11 is going to be a daunting challenge, trying to generalize it to another wireless protocol at this time is probably expecting more than could be accomplished in a reasonable time frame. As for having the work done in another forum, the first step doesn't involve any protocol design, but if the vendors want to take the work somewhere else, I think the IESG would be most happy to see it disappear from their agenda. Frankly, I think the IETF is a good place for this work, because it will require the vendors to come to concensus on what the open interfaces are in the network architecture, and the IETF is a pretty good place for forging concensus. With regard to whether IP is used, the assumption is that IP will be used at some point, or another protocol (like L2TP) with which IETF has design experience, and most of the vendors do use IP in their APs in some form now. If an IETF protocol will not be used, then clearly IETF is not the right place for the work. jak (1) By "network architecture" I mean a clustering of functional entities into network boxes (==products) with interfaces between them. The interfaces are where network protocols are defined. If the interfaces and protocols are standardized, then the interfaces and protocols are open and interoperable between vendors' products. (2) Note that this is not confined to so-called "lightweight" access points, because there are vendors with customers out there who believe that the autonomous access point model is valid, and autonomous access points are likely to always be an easier model for home and small office use. At this time, it is not clear (at least to me) what such an interface would look like between an autonomous access point and a access point controller (switch or router) but I know that some of the split-AP vendors' products do support this mode of operation. ----- Original Message ----- From: "s. goswami" Cc: Sent: Thursday, December 11, 2003 2:09 PM Subject: Re: [Lwapp] Comments Invited: Charter Refined. > > Hi, a few simple questions. > > 1. Is there any reason for limiting a layer 3+ protocol to just > one layer 2 protocol (802.11). Looks like a very narrow and > short sighted goal. Is the charter of LWAPP solely to patch up > the big holes left by 802.11 stemming from use well > beyond designed limits. > > 2. If it is very specific to 802.11 than should it not be done > umder the aegis of IEEE or an independent forum along the > line of DSL Forum ? > > 3. Is IP going to be used in LWAPP or is it optional ? > > > Subrata > > On Thu, 11 Dec 2003, Mani, Mahalingam (Mahalingam) wrote: > > > Following intense deliberations in and between IESG and IAB - the > > following refined charter has been proposed. > > > > In my opinion this is a generalized abstraction of the one discussed in > > Minneapolis - sans external references (they are abstracted inline) and > > with a cleaner assertions of the problems - from first principles. > > > > > > > > It appears to take a step back and urges a look at available > > architectural taxonomy without (split-AP et al) architectural > > presumptions - though the split is the prime reason for the BoF > > initiative. > > > > > > > > By and large the charter and description track the problem statement but > > in a generic manner earlier proposed work. > > > > > > > > Comments are welcome. > > > > > > > > Regards, > > > > -mani > > > > ========================= Proposed charter ==================== > > > > Control and Provisioning of Wireless Access Points BOF (CAPWAP) > > > > > > > > DESCRIPTION: > > > > As the size and complexity of IEEE 802.11 wireless networks has > > > > increased, problems in the deployment, management, and usability of > > > > these networks have become evident. Access points (APs) typically > > > > require complex management at the IP level. As the number of APs > > > > increases, the number of devices requiring complex management > > > > increases, in some cases, doubling the number of IP devices requiring > > > > management in a provider's network. In addition, because APs have no > > > > visibility beyond their own cell, a variety of problems ensue in large > > > > scale 802.11 networks. Load balancing between APs, dead cell detection, > > > > and correlating patterns of usage between APs to detect attacks are > > > > difficult to impossible. Finally, because each AP acts as its > > > > own Network Access Server (NAS), a network provider is faced > > > > with the prospect of moving from a situation where the NAS is > > > > a few machines with dialup access in a machine room to a > > > > situation where hundreds or perhaps thousands of devices > > > > scattered across a wide geographic area have NAS functionality. > > > > Maintaining security on such a wide collection of devices is a > > > > difficult challenge. > > > > > > > > In recent attempts to solve these problems, various vendors have > > > > introduced products that redistribute the functionality of 802.11 APs > > > > in various ways. However, because the 802.11 access network functional > > > > architecture is incompletely specified, the network interfaces between > > > > network entities in different vendors' products are defined in > > > > incompatible ways. As a result, the protocols between the network > > > > entities in different products are not interoperable. > > > > > > > > CHARTER: > > > > As a first step, the CAPWAP Working Group will develop a problem > > > > statement and network architecture taxonomy describing the current set > > > > of approaches to providing more support for scalable 802.11 access > > > > networks. The problem statement will describe, at a high level, what > > > > the deployment, management, and usability concerns are with 802.11 > > > > networks based on the traditional autonomous AP architecture, and will > > > > link those concerns to specific technical aspects of the autonomous AP > > > > architecture. The network architecture taxonomy will: > > > > > > > > - Describe the current set of approaches (including the > > > > traditional autonomous AP architecture) to partitioning > > > > 802.11 access network functionality between network > > > > entities, > > > > - List what the interfaces between the network entities > > > > are in each approach, > > > > - At a functional level, describe what the protocols on > > > > the interfaces between the network entites in each > > > > approach do, > > > > - Describe the advantages and disadvantages of each > > > > approach for scalable 802.11 access network deployment > > > > and management. > > > > > > > > Additionally, the architecture document will contain a threat analysis > > > > that describes the security threats involved in each network > > > > architectural approach. > > > > > > > > Specific Working Group deliverables are: > > > > > > > > - A problem statement document, > > > > - A network architecture taxonomy document including > > > > threat analysis. > > > > > > > > Specific non-goals of this work are: > > > > - Any work requiring revising the 802.11 access network > > > > functional architecture > > > > > > > > The CAPWAP WG will maintain a close working liaison with relevant > > > > working groups in IEEE 802.11 and IEEE 802.1. Working Group documents > > > > will be sent to an expert review board for review prior to submission > > > > to the IESG. In order to facilitate quick completion of this work, the > > > > Working Group charter will expire 9 months after it is approved by the > > > > IESG, at which time the Working Group can either petition the IESG > > > > for a continuation or recharter for further work on the > > > > interoperability problem. > > > > > > > > Goals and Milestones: > > > > Feb 2004: Last call for problem statement draft. > > > > Mar 2004 Discuss last call comments for problem statement > > > > at IETF 59. > > > > Mar 2004: Last Call for architecture description document. > > > > Apr 2004: Submit problem statement to IESG for publication > > > > approval. > > > > May 2004: Architecture document to expert review. > > > > Aug 2004 Discuss last call comments at IETF 60. > > > > Aug 2004: Submit architecture document to IESG for publication > > > > approval. > > > > Sep 2004: Re-charter > > > > ================end charter ======================= > > > > > > > > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > From sgoswami@umich.edu Fri Dec 12 01:42:24 2003 From: sgoswami@umich.edu (s. goswami) Date: Thu, 11 Dec 2003 20:42:24 -0500 (EST) Subject: [Lwapp] Comments Invited: Charter Refined. In-Reply-To: <4D7B558499107545BB45044C63822DDE03F0821D@mvebe001.americas.nokia.com> References: <4D7B558499107545BB45044C63822DDE03F0821D@mvebe001.americas.nokia.com> Message-ID: On Thu, 11 Dec 2003 Dorothy.Gellert@nokia.com wrote: > Hi Subrata- > > Let me address the first 2 comments... > > The IESG recommended limiting the charter to 802.11 to establish a working relationship with IEEE and narrow our focus to ensure we get a work done to meet the market need in a timely fashion. The charter exists for 9 months to address problem statement and architecture only, after which we can re-charter and revisit this issue. > > Does that sound fair? Sure there is a first time for everything - fairnes is subjective I guess, unless you treat all possible Layer 2 protocols equally. Is there any reason IESG wants to exclude 802.15.3 from the same WG ? > > Dorothy > > > > -----Original Message----- > > From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com]On > > Behalf Of ext s. goswami > > Sent: Thursday, December 11, 2003 2:09 PM > > Cc: lwapp@frascone.com > > Subject: Re: [Lwapp] Comments Invited: Charter Refined. > > > > > > > > Hi, a few simple questions. > > > > 1. Is there any reason for limiting a layer 3+ protocol to just > > one layer 2 protocol (802.11). Looks like a very narrow and > > short sighted goal. Is the charter of LWAPP solely to patch up > > the big holes left by 802.11 stemming from use well > > beyond designed limits. > > > > 2. If it is very specific to 802.11 than should it not be done > > umder the aegis of IEEE or an independent forum along the > > line of DSL Forum ? > > > > 3. Is IP going to be used in LWAPP or is it optional ? > > > > > > Subrata > > > > On Thu, 11 Dec 2003, Mani, Mahalingam (Mahalingam) wrote: > > > > > Following intense deliberations in and between IESG and IAB - the > > > following refined charter has been proposed. > > > > > > In my opinion this is a generalized abstraction of the one > > discussed in > > > Minneapolis - sans external references (they are > > abstracted inline) and > > > with a cleaner assertions of the problems - from first principles. > > > > > > > > > > > > It appears to take a step back and urges a look at available > > > architectural taxonomy without (split-AP et al) architectural > > > presumptions - though the split is the prime reason for the BoF > > > initiative. > > > > > > > > > > > > By and large the charter and description track the problem > > statement but > > > in a generic manner earlier proposed work. > > > > > > > > > > > > Comments are welcome. > > > > > > > > > > > > Regards, > > > > > > -mani > > > > > > ========================= Proposed charter ==================== > > > > > > Control and Provisioning of Wireless Access Points BOF (CAPWAP) > > > > > > > > > > > > DESCRIPTION: > > > > > > As the size and complexity of IEEE 802.11 wireless networks has > > > > > > increased, problems in the deployment, management, and usability of > > > > > > these networks have become evident. Access points (APs) typically > > > > > > require complex management at the IP level. As the number of APs > > > > > > increases, the number of devices requiring complex management > > > > > > increases, in some cases, doubling the number of IP devices > > requiring > > > > > > management in a provider's network. In addition, because APs have no > > > > > > visibility beyond their own cell, a variety of problems > > ensue in large > > > > > > scale 802.11 networks. Load balancing between APs, dead > > cell detection, > > > > > > and correlating patterns of usage between APs to detect attacks are > > > > > > difficult to impossible. Finally, because each AP acts as its > > > > > > own Network Access Server (NAS), a network provider is faced > > > > > > with the prospect of moving from a situation where the NAS is > > > > > > a few machines with dialup access in a machine room to a > > > > > > situation where hundreds or perhaps thousands of devices > > > > > > scattered across a wide geographic area have NAS functionality. > > > > > > Maintaining security on such a wide collection of devices is a > > > > > > difficult challenge. > > > > > > > > > > > > In recent attempts to solve these problems, various vendors have > > > > > > introduced products that redistribute the functionality of > > 802.11 APs > > > > > > in various ways. However, because the 802.11 access network > > functional > > > > > > architecture is incompletely specified, the network > > interfaces between > > > > > > network entities in different vendors' products are defined in > > > > > > incompatible ways. As a result, the protocols between the network > > > > > > entities in different products are not interoperable. > > > > > > > > > > > > CHARTER: > > > > > > As a first step, the CAPWAP Working Group will develop a problem > > > > > > statement and network architecture taxonomy describing the > > current set > > > > > > of approaches to providing more support for scalable 802.11 access > > > > > > networks. The problem statement will describe, at a high level, what > > > > > > the deployment, management, and usability concerns are with 802.11 > > > > > > networks based on the traditional autonomous AP > > architecture, and will > > > > > > link those concerns to specific technical aspects of the > > autonomous AP > > > > > > architecture. The network architecture taxonomy will: > > > > > > > > > > > > - Describe the current set of approaches (including the > > > > > > traditional autonomous AP architecture) to partitioning > > > > > > 802.11 access network functionality between network > > > > > > entities, > > > > > > - List what the interfaces between the network entities > > > > > > are in each approach, > > > > > > - At a functional level, describe what the protocols on > > > > > > the interfaces between the network entites in each > > > > > > approach do, > > > > > > - Describe the advantages and disadvantages of each > > > > > > approach for scalable 802.11 access network deployment > > > > > > and management. > > > > > > > > > > > > Additionally, the architecture document will contain a > > threat analysis > > > > > > that describes the security threats involved in each network > > > > > > architectural approach. > > > > > > > > > > > > Specific Working Group deliverables are: > > > > > > > > > > > > - A problem statement document, > > > > > > - A network architecture taxonomy document including > > > > > > threat analysis. > > > > > > > > > > > > Specific non-goals of this work are: > > > > > > - Any work requiring revising the 802.11 access network > > > > > > functional architecture > > > > > > > > > > > > The CAPWAP WG will maintain a close working liaison with relevant > > > > > > working groups in IEEE 802.11 and IEEE 802.1. Working Group > > documents > > > > > > will be sent to an expert review board for review prior to > > submission > > > > > > to the IESG. In order to facilitate quick completion of > > this work, the > > > > > > Working Group charter will expire 9 months after it is > > approved by the > > > > > > IESG, at which time the Working Group can either petition the IESG > > > > > > for a continuation or recharter for further work on the > > > > > > interoperability problem. > > > > > > > > > > > > Goals and Milestones: > > > > > > Feb 2004: Last call for problem statement draft. > > > > > > Mar 2004 Discuss last call comments for problem statement > > > > > > at IETF 59. > > > > > > Mar 2004: Last Call for architecture description document. > > > > > > Apr 2004: Submit problem statement to IESG for publication > > > > > > approval. > > > > > > May 2004: Architecture document to expert review. > > > > > > Aug 2004 Discuss last call comments at IETF 60. > > > > > > Aug 2004: Submit architecture document to IESG for publication > > > > > > approval. > > > > > > Sep 2004: Re-charter > > > > > > ================end charter ======================= > > > > > > > > > > > > > > _______________________________________________ > > 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 mmani@avaya.com Fri Dec 12 14:30:11 2003 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Fri, 12 Dec 2003 07:30:11 -0700 Subject: [Lwapp] Comments Invited: Charter Refined. Message-ID: Subrata, Here is an assessment of the situation: IETF(IESG) is treading carefully in what currently it views could be a sub-IP matter. Past experience wants IESG to make this a manageable problem to solve and succeed. To that effect it is in the process of convincing itself where and (more importantly) how this problem sits. Until IESG is fully convinced about the positioning of the problem and until we articulate the architectural taxonomy it is fair to say that the notion of exclusion is irrelevant.=20 If the problem area is similar for other wireless technologies there's time to argue such inclusion after this phase of charter. Just another alternate thought: If they are so similar - if done right - they could be incremental extensions to whatever protocol/std. results from this effort. Regards, -mani > -----Original Message----- [...] > > > > Does that sound fair? > Sure there is a first time for everything - fairnes is subjective I guess, > unless you treat all possible Layer 2 protocols equally. >=20 > Is there any reason IESG wants to exclude 802.15.3 from the same WG ? >=20 > > > > Dorothy > > > > [...] From sgoswami@umich.edu Fri Dec 12 16:10:52 2003 From: sgoswami@umich.edu (s. goswami) Date: Fri, 12 Dec 2003 11:10:52 -0500 (EST) Subject: [Lwapp] Comments Invited: Charter Refined. In-Reply-To: References: Message-ID: Hi Mani, thanks for the details, but I do not agree with your claim that it is possible to retrofit a strait-jacket protocol to become a more generic one. By the way, both .11 and .15.3 are last meter solutions, both uses the 2.4G ISM band, both uses FHSS, both have the entity called Access Point. On the other hand they have dissimilarities (in node discovery, ad-hoc networking, application stacks) which can not potentially be handled by a protocol custom fit to .11. Subrata On Fri, 12 Dec 2003, Mani, Mahalingam (Mahalingam) wrote: > Subrata, > > Here is an assessment of the situation: IETF(IESG) is treading carefully > in what currently it views could be a sub-IP matter. Past experience > wants IESG to make this a manageable problem to solve and succeed. > > To that effect it is in the process of convincing itself where and (more > importantly) how this problem sits. Until IESG is fully convinced about > the positioning of the problem and until we articulate the architectural > taxonomy it is fair to say that the notion of exclusion is irrelevant. > > If the problem area is similar for other wireless technologies there's > time to argue such inclusion after this phase of charter. > > Just another alternate thought: If they are so similar - if done right - > they could be incremental extensions to whatever protocol/std. results > from this effort. > > Regards, > -mani > > -----Original Message----- > [...] > > > > > > Does that sound fair? > > Sure there is a first time for everything - fairnes is subjective I > guess, > > unless you treat all possible Layer 2 protocols equally. > > > > Is there any reason IESG wants to exclude 802.15.3 from the same WG ? > > > > > > > > Dorothy > > > > > > > [...] > From bob@airespace.com Fri Dec 12 17:32:30 2003 From: bob@airespace.com (Bob O'Hara) Date: Fri, 12 Dec 2003 09:32:30 -0800 Subject: [Lwapp] Comments Invited: Charter Refined. Message-ID: <55749BC69138654EBBC4C50BA4F5561096D9A8@AIREMAIL.airespace.com> While the 802.11 standard describes a FHSS PHY in the original standard, it has not been updated to higher data rates and is definitely not what the world knows as "Wi-Fi". Recent cordless phones also use the 2.4GHz ISM band, but I do not see you calling for us to include them in our investigations. Saying that two access protocols are similar because they use a similar radio technology is pretty lame. =20 I also note that you conspicuously avoid including 802.15.1 in your request to add things to the CAPWAP plate. That also meets all of your stated points of similarity with 802.11. As Jim, Dorothy, and Mani have stated, the IESG/IAB want to keep this problem manageable, with the hope that a solution is determined in the near term. Opening it up to 2 (or dozens) of other access protocols is directly counter to this desire. Where would you draw the line, at 2 protocols, 802.11 and your favorite? Why not every wireless protocol? We might get done in 2010. -Bob =20 -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf Of s. goswami Sent: Friday, December 12, 2003 8:11 AM To: Mani, Mahalingam (Mahalingam) Cc: lwapp@frascone.com Subject: RE: [Lwapp] Comments Invited: Charter Refined. Hi Mani, thanks for the details, but I do not agree with your claim that it is possible to retrofit a strait-jacket protocol to become a more generic one. By the way, both .11 and .15.3 are last meter solutions, both uses the 2.4G ISM band, both uses FHSS, both have the entity called Access Point. On the other hand they have dissimilarities (in node discovery, ad-hoc networking, application stacks) which can not potentially be handled by a protocol custom fit to .11. Subrata On Fri, 12 Dec 2003, Mani, Mahalingam (Mahalingam) wrote: > Subrata, > > Here is an assessment of the situation: IETF(IESG) is treading carefully > in what currently it views could be a sub-IP matter. Past experience > wants IESG to make this a manageable problem to solve and succeed. > > To that effect it is in the process of convincing itself where and (more > importantly) how this problem sits. Until IESG is fully convinced about > the positioning of the problem and until we articulate the architectural > taxonomy it is fair to say that the notion of exclusion is irrelevant. > > If the problem area is similar for other wireless technologies there's > time to argue such inclusion after this phase of charter. > > Just another alternate thought: If they are so similar - if done right - > they could be incremental extensions to whatever protocol/std. results > from this effort. > > Regards, > -mani > > -----Original Message----- > [...] > > > > > > Does that sound fair? > > Sure there is a first time for everything - fairnes is subjective I > guess, > > unless you treat all possible Layer 2 protocols equally. > > > > Is there any reason IESG wants to exclude 802.15.3 from the same WG ? > > > > > > > > Dorothy > > > > > > > [...] > _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From sgoswami@umich.edu Fri Dec 12 18:48:31 2003 From: sgoswami@umich.edu (s. goswami) Date: Fri, 12 Dec 2003 13:48:31 -0500 (EST) Subject: [Lwapp] Comments Invited: Charter Refined. In-Reply-To: <55749BC69138654EBBC4C50BA4F5561096D9A8@AIREMAIL.airespace.com> References: <55749BC69138654EBBC4C50BA4F5561096D9A8@AIREMAIL.airespace.com> Message-ID: See my comments in-line On Fri, 12 Dec 2003, Bob O'Hara wrote: > While the 802.11 standard describes a FHSS PHY in the original standard, > it has not been updated to higher data rates and is definitely not what > the world knows as "Wi-Fi". Recent cordless phones also use the 2.4GHz > ISM band, but I do not see you calling for us to include them in our > investigations. Saying that two access protocols are similar because > they use a similar radio technology is pretty lame. > I am not sure what you are saying here Mr. O'Hara. Are you saying you want to include 2.4GHz cordless phones too in LWAPP charter ? Sure you can if you want, which cordelss specification you want to include ? I would say that is a great idea. But, I was giving the example of 802.15.3 as it is very similar to 802.11 in usages. > I also note that you conspicuously avoid including 802.15.1 in your > request to add things to the CAPWAP plate. That also meets all of your > stated points of similarity with 802.11. > See my bits above. I have not excluded 802.15.1 , in fact I think it should be included in the LWAPP charter. > As Jim, Dorothy, and Mani have stated, the IESG/IAB want to keep this > problem manageable, with the hope that a solution is determined in the > near term. Opening it up to 2 (or dozens) of other access protocols is > directly counter to this desire. Where would you draw the line, at 2 > protocols, 802.11 and your favorite? Why not every wireless protocol? > We might get done in 2010. > If it is only for one particular layer 2 protocol, then it would look to me to be more suitable for one or two RFCs rather than a whole WG. As .11 has some notion of "mobility" such RFC's may be done in the MIPv4 group (or other groups such as IPSEC) - just a suggestion. > -Bob > Subrata > > -----Original Message----- > From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On > Behalf Of s. goswami > Sent: Friday, December 12, 2003 8:11 AM > To: Mani, Mahalingam (Mahalingam) > Cc: lwapp@frascone.com > Subject: RE: [Lwapp] Comments Invited: Charter Refined. > > > > Hi Mani, thanks for the details, but I do not agree with your > claim that it is possible to retrofit a strait-jacket protocol > to become a more generic one. > > By the way, both .11 and .15.3 are last meter solutions, both > uses the 2.4G ISM band, both uses FHSS, both have the entity > called Access Point. On the other hand they have dissimilarities > (in node discovery, ad-hoc networking, application stacks) which > can not potentially be handled by a protocol custom fit to .11. > > Subrata > > > On Fri, 12 Dec 2003, Mani, Mahalingam (Mahalingam) wrote: > > > Subrata, > > > > Here is an assessment of the situation: IETF(IESG) is treading > carefully > > in what currently it views could be a sub-IP matter. Past experience > > wants IESG to make this a manageable problem to solve and succeed. > > > > To that effect it is in the process of convincing itself where and > (more > > importantly) how this problem sits. Until IESG is fully convinced > about > > the positioning of the problem and until we articulate the > architectural > > taxonomy it is fair to say that the notion of exclusion is irrelevant. > > > > If the problem area is similar for other wireless technologies there's > > time to argue such inclusion after this phase of charter. > > > > Just another alternate thought: If they are so similar - if done right > - > > they could be incremental extensions to whatever protocol/std. results > > from this effort. > > > > Regards, > > -mani > > > -----Original Message----- > > [...] > > > > > > > > Does that sound fair? > > > Sure there is a first time for everything - fairnes is subjective I > > guess, > > > unless you treat all possible Layer 2 protocols equally. > > > > > > Is there any reason IESG wants to exclude 802.15.3 from the same WG > ? > > > > > > > > > > > Dorothy > > > > > > > > > > [...] > > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > From simon@instant802.com Sat Dec 13 00:07:43 2003 From: simon@instant802.com (Simon Barber) Date: Fri, 12 Dec 2003 16:07:43 -0800 Subject: [Lwapp] Comments Invited: Charter Refined. Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C3C10D.21A2E141 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The IEEE TGk is dedicated to providing a remote measurement interface for 802.11. There is also some work going on in the IEEE to establish a new TG to study remote control of access points and clients. This seems to be a direct overlap with the essence of this proposed charter. =20 If the charter were limited to specifically address split-MAC architectures the group's focus would be tighter, and there would be less overlap with work that is going on in the IEEE. =20 Simon Barber -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf Of Mani, Mahalingam (Mahalingam) Sent: Thursday, December 11, 2003 12:23 PM To: lwapp@frascone.com Subject: [Lwapp] Comments Invited: Charter Refined. Following intense deliberations in and between IESG and IAB - the following refined charter has been proposed. In my opinion this is a generalized abstraction of the one discussed in Minneapolis - sans external references (they are abstracted inline) and with a cleaner assertions of the problems - from first principles. =20 It appears to take a step back and urges a look at available architectural taxonomy without (split-AP et al) architectural presumptions - though the split is the prime reason for the BoF initiative. =20 By and large the charter and description track the problem statement but in a generic manner earlier proposed work. =20 Comments are welcome. =20 Regards, -mani =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= Proposed charter = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Control and Provisioning of Wireless Access Points BOF (CAPWAP) =20 DESCRIPTION: As the size and complexity of IEEE 802.11 wireless networks has=20 increased, problems in the deployment, management, and usability of=20 these networks have become evident. Access points (APs) typically=20 require complex management at the IP level. As the number of APs=20 increases, the number of devices requiring complex management=20 increases, in some cases, doubling the number of IP devices requiring=20 management in a provider's network. In addition, because APs have no=20 visibility beyond their own cell, a variety of problems ensue in large=20 scale 802.11 networks. Load balancing between APs, dead cell detection,=20 and correlating patterns of usage between APs to detect attacks are difficult to impossible. Finally, because each AP acts as its own Network Access Server (NAS), a network provider is faced with the prospect of moving from a situation where the NAS is a few machines with dialup access in a machine room to a=20 situation where hundreds or perhaps thousands of devices scattered across a wide geographic area have NAS functionality. Maintaining security on such a wide collection of devices is a difficult challenge. =20 In recent attempts to solve these problems, various vendors have=20 introduced products that redistribute the functionality of 802.11 APs=20 in various ways. However, because the 802.11 access network functional=20 architecture is incompletely specified, the network interfaces between=20 network entities in different vendors' products are defined in=20 incompatible ways. As a result, the protocols between the network entities in different products are not interoperable. =20 CHARTER: As a first step, the CAPWAP Working Group will develop a problem=20 statement and network architecture taxonomy describing the current set=20 of approaches to providing more support for scalable 802.11 access=20 networks. The problem statement will describe, at a high level, what=20 the deployment, management, and usability concerns are with 802.11=20 networks based on the traditional autonomous AP architecture, and will=20 link those concerns to specific technical aspects of the autonomous AP architecture. The network architecture taxonomy will: =20 - Describe the current set of approaches (including the traditional autonomous AP architecture) to partitioning 802.11 access network functionality between network entities, - List what the interfaces between the network entities are in each approach, - At a functional level, describe what the protocols on the interfaces between the network entites in each approach do, - Describe the advantages and disadvantages of each approach for scalable 802.11 access network deployment and management. =20 Additionally, the architecture document will contain a threat analysis=20 that describes the security threats involved in each network=20 architectural approach. =20 Specific Working Group deliverables are: =20 - A problem statement document, - A network architecture taxonomy document including threat analysis. =20 Specific non-goals of this work are: - Any work requiring revising the 802.11 access network functional architecture =20 The CAPWAP WG will maintain a close working liaison with relevant=20 working groups in IEEE 802.11 and IEEE 802.1. Working Group documents=20 will be sent to an expert review board for review prior to submission=20 to the IESG. In order to facilitate quick completion of this work, the=20 Working Group charter will expire 9 months after it is approved by the=20 IESG, at which time the Working Group can either petition the IESG for a continuation or recharter for further work on the=20 interoperability problem. =20 Goals and Milestones: Feb 2004: Last call for problem statement draft. Mar 2004 Discuss last call comments for problem statement at IETF 59. Mar 2004: Last Call for architecture description document. Apr 2004: Submit problem statement to IESG for publication approval. May 2004: Architecture document to expert review. Aug 2004 Discuss last call comments at IETF 60. Aug 2004: Submit architecture document to IESG for publication approval. Sep 2004: Re-charter =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Dend charter = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 ------_=_NextPart_001_01C3C10D.21A2E141 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
The=20 IEEE TGk is dedicated to providing a remote measurement interface = for=20 802.11. There is also some work going on in the IEEE to establish a new = TG to=20 study remote control of access points and clients. This seems to be a = direct=20 overlap with the essence of this proposed charter.

If the=20 charter were limited to specifically address split-MAC architectures the = group's=20 focus would be tighter, and there would be less overlap with work that = is going=20 on in the IEEE.

Simon=20 Barber

-----Original Message-----
From:=20 lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On = Behalf Of=20 Mani, Mahalingam (Mahalingam)
Sent: Thursday, December = 11, 2003=20 12:23 PM
To: lwapp@frascone.com
Subject: [Lwapp] = Comments=20 Invited: Charter Refined.

Following intense = deliberations in=20 and between IESG and IAB – the following refined charter has = been=20 proposed.

In my opinion this is a=20 generalized abstraction of the one discussed in Minneapolis – sans=20 external references (they are abstracted inline) and with a = cleaner=20 assertions of the problems - from first principles.

It appears to take a = step back and=20 urges a look at available architectural taxonomy without (split-AP et = al)=20 architectural presumptions – though the split is the prime = reason for the BoF=20 initiative.

By and large the charter = and=20 description track the problem statement but in a generic manner = earlier=20 proposed work.

Comments are=20 welcome.

Regards,

-mani

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Proposed=20 charter = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Control and = Provisioning=20 of Wireless Access Points BOF (CAPWAP)

DESCRIPTION:

As the size and = complexity=20 of IEEE 802.11 wireless networks has

increased, = problems in the=20 deployment, management, and usability of

these networks = have become=20 evident. Access points (APs) typically

require complex = management=20 at the IP level. As the number of APs

increases, the = number of=20 devices requiring complex management

increases, in = some cases,=20 doubling the number of IP devices requiring

management in a = provider's=20 network. In addition, because APs have no

visibility = beyond their=20 own cell, a variety of problems ensue in large

scale 802.11 = networks.=20 Load balancing between APs, dead cell detection,

and correlating = patterns=20 of usage between APs to detect attacks are

difficult to = impossible.=20 Finally, because each AP acts as its

own Network = Access Server=20 (NAS), a network provider is faced

with the = prospect of=20 moving from a situation where the NAS is

a few machines = with dialup=20 access in a machine room to a

situation where = hundreds=20 or perhaps thousands of devices

scattered across = a wide=20 geographic area have NAS functionality.

Maintaining = security on=20 such a wide collection of devices is a

difficult=20 challenge.

In recent = attempts to=20 solve these problems, various vendors have

introduced = products that=20 redistribute the functionality of 802.11 APs

in various ways. = However,=20 because the 802.11 access network functional

architecture is=20 incompletely specified, the network interfaces between =

network entities = in=20 different vendors' products are defined in

incompatible = ways. As a=20 result, the protocols between the network

entities in = different=20 products are not interoperable.

CHARTER:

As a first step, = the=20 CAPWAP Working Group will develop a problem

statement and = network=20 architecture taxonomy describing the current set

of approaches to = providing=20 more support for scalable 802.11 access

networks. The = problem=20 statement will describe, at a high level, what

the deployment,=20 management, and usability concerns are with 802.11

networks based = on the=20 traditional autonomous AP architecture, and will

link those = concerns to=20 specific technical aspects of the autonomous AP

architecture. = The network=20 architecture taxonomy will:

- = Describe the=20 current set of approaches (including the

   =20 traditional autonomous AP architecture) to = partitioning

    802.11=20 access network functionality between network

   =20 entities,

- List = what the=20 interfaces between the network entities

    are in=20 each approach,

- At a = functional=20 level, describe what the protocols on

    the=20 interfaces between the network entites in each

   =20 approach do,

- = Describe the=20 advantages and disadvantages of each

   =20 approach for scalable 802.11 access network = deployment

    and=20 management.

Additionally, = the=20 architecture document will contain a threat analysis =

that describes = the=20 security threats involved in each network

architectural=20 approach.

Specific Working = Group=20 deliverables are:

    - A=20 problem statement document,

    - A=20 network architecture taxonomy document including

     =20 threat analysis.

Specific = non-goals of this=20 work are:

    - Any=20 work requiring revising the 802.11 access network

     =20 functional architecture

The CAPWAP WG = will=20 maintain a close working liaison with relevant

working groups = in IEEE=20 802.11 and IEEE 802.1. Working Group documents

will be sent to = an expert=20 review board for review prior to submission

to the IESG. In = order to=20 facilitate quick completion of this work, the

Working Group = charter will=20 expire 9 months after it is approved by the

IESG, at which = time the=20 Working Group can either petition the IESG

for a = continuation or=20 recharter for further work on the

interoperability = problem.

Goals and=20 Milestones:

Feb = 2004: Last=20 call for problem statement draft.

Mar = 2004 =20 Discuss last call comments for problem statement

            = at IETF 59.

Mar = 2004: Last=20 Call for architecture description document.

Apr = 2004:=20 Submit problem statement to IESG for publication

            = approval.

May = 2004:=20 Architecture document to expert review.

Aug = 2004 =20 Discuss last call comments at IETF 60.

Aug = 2004:=20 Submit architecture document to IESG for publication

            = approval.

Sep = 2004:=20 Re-charter

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Dend charter=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

------_=_NextPart_001_01C3C10D.21A2E141-- From bob@airespace.com Sat Dec 13 00:15:00 2003 From: bob@airespace.com (Bob O'Hara) Date: Fri, 12 Dec 2003 16:15:00 -0800 Subject: [Lwapp] Comments Invited: Charter Refined. Message-ID: <55749BC69138654EBBC4C50BA4F5561096D9F1@AIREMAIL.airespace.com> Simon, I believe that you are misinterpreting the scope of work for 802.11 TGk and the as yet unapproved 802.11 study group you mention. Both are dealing only with over the air communications, information retrieval from a mobile station by an access point, and (possibly) control of mobile stations remotely from an access point. There has been no contemplation of control and provisioning of access points in a WLAN as a system in 802.11. This work has no overlap with the current or possible future expanded charter of CAPWAP. -Bob =20 -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf Of Simon Barber Sent: Friday, December 12, 2003 4:08 PM To: Mani, Mahalingam (Mahalingam); lwapp@frascone.com Subject: RE: [Lwapp] Comments Invited: Charter Refined. The IEEE TGk is dedicated to providing a remote measurement interface for 802.11. There is also some work going on in the IEEE to establish a new TG to study remote control of access points and clients. This seems to be a direct overlap with the essence of this proposed charter. If the charter were limited to specifically address split-MAC architectures the group's focus would be tighter, and there would be less overlap with work that is going on in the IEEE. Simon Barber -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf Of Mani, Mahalingam (Mahalingam) Sent: Thursday, December 11, 2003 12:23 PM To: lwapp@frascone.com Subject: [Lwapp] Comments Invited: Charter Refined. Following intense deliberations in and between IESG and IAB - the following refined charter has been proposed. In my opinion this is a generalized abstraction of the one discussed in Minneapolis - sans external references (they are abstracted inline) and with a cleaner assertions of the problems - from first principles. It appears to take a step back and urges a look at available architectural taxonomy without (split-AP et al) architectural presumptions - though the split is the prime reason for the BoF initiative. By and large the charter and description track the problem statement but in a generic manner earlier proposed work. Comments are welcome. Regards, -mani =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= Proposed charter = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Control and Provisioning of Wireless Access Points BOF (CAPWAP) DESCRIPTION: As the size and complexity of IEEE 802.11 wireless networks has=20 increased, problems in the deployment, management, and usability of=20 these networks have become evident. Access points (APs) typically=20 require complex management at the IP level. As the number of APs=20 increases, the number of devices requiring complex management=20 increases, in some cases, doubling the number of IP devices requiring=20 management in a provider's network. In addition, because APs have no=20 visibility beyond their own cell, a variety of problems ensue in large=20 scale 802.11 networks. Load balancing between APs, dead cell detection,=20 and correlating patterns of usage between APs to detect attacks are difficult to impossible. Finally, because each AP acts as its own Network Access Server (NAS), a network provider is faced with the prospect of moving from a situation where the NAS is a few machines with dialup access in a machine room to a=20 situation where hundreds or perhaps thousands of devices scattered across a wide geographic area have NAS functionality. Maintaining security on such a wide collection of devices is a difficult challenge. In recent attempts to solve these problems, various vendors have=20 introduced products that redistribute the functionality of 802.11 APs=20 in various ways. However, because the 802.11 access network functional=20 architecture is incompletely specified, the network interfaces between=20 network entities in different vendors' products are defined in=20 incompatible ways. As a result, the protocols between the network entities in different products are not interoperable. CHARTER: As a first step, the CAPWAP Working Group will develop a problem=20 statement and network architecture taxonomy describing the current set=20 of approaches to providing more support for scalable 802.11 access=20 networks. The problem statement will describe, at a high level, what=20 the deployment, management, and usability concerns are with 802.11=20 networks based on the traditional autonomous AP architecture, and will=20 link those concerns to specific technical aspects of the autonomous AP architecture. The network architecture taxonomy will: - Describe the current set of approaches (including the traditional autonomous AP architecture) to partitioning 802.11 access network functionality between network entities, - List what the interfaces between the network entities are in each approach, - At a functional level, describe what the protocols on the interfaces between the network entites in each approach do, - Describe the advantages and disadvantages of each approach for scalable 802.11 access network deployment and management. Additionally, the architecture document will contain a threat analysis=20 that describes the security threats involved in each network=20 architectural approach. Specific Working Group deliverables are: - A problem statement document, - A network architecture taxonomy document including threat analysis. Specific non-goals of this work are: - Any work requiring revising the 802.11 access network functional architecture The CAPWAP WG will maintain a close working liaison with relevant=20 working groups in IEEE 802.11 and IEEE 802.1. Working Group documents=20 will be sent to an expert review board for review prior to submission=20 to the IESG. In order to facilitate quick completion of this work, the=20 Working Group charter will expire 9 months after it is approved by the=20 IESG, at which time the Working Group can either petition the IESG for a continuation or recharter for further work on the=20 interoperability problem. Goals and Milestones: Feb 2004: Last call for problem statement draft. Mar 2004 Discuss last call comments for problem statement at IETF 59. Mar 2004: Last Call for architecture description document. Apr 2004: Submit problem statement to IESG for publication approval. May 2004: Architecture document to expert review. Aug 2004 Discuss last call comments at IETF 60. Aug 2004: Submit architecture document to IESG for publication approval. Sep 2004: Re-charter =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Dend charter = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From kempf@docomolabs-usa.com Sat Dec 13 00:36:33 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Fri, 12 Dec 2003 16:36:33 -0800 Subject: [Lwapp] Comments Invited: Charter Refined. References: Message-ID: <037901c3c111$2843c280$666015ac@dclkempt40> Simon, The charter is only to develop a taxonomy of network architectures that characterize the existing 802.11 products, for purposes of determining where points of non-interoperability lie. There is nothing about protocol development. You did not say specifically what the new TG is doing, but the work proposed in the charter says nothing about developing protocols on a remote measuring interface, so I have some difficulty seeing how it would overlap with TGk. Also, it is entirely possible, though not of course certain, that the architectural taxonomy is as far as IETF goes with the work, and afterwards it is turned over to IEEE as a requirements document for them to do the actual protocol design. So, in that sense, the work would be complimentary. As for addressing the split-MAC architecture, the charter does address the split-MAC architecture, in so far as it is a major component of existing 802.11 network architectures and uses IETF protocols in its interfaces. Having the charter only address the split-MAC architecture would make the work politically polarizing, and thereby more difficult to achieve concensus. We've seen that already on the list, with argument about exactly what "lightweight" means. In addition, autonomous access points will always be an important part of the deployment mix, if only for small and home offices. Addressing how autonomous access points interoperate with split-MAC networks, from an architectural standpoint, could be important down the line when protocol development occurs, since some users of autonomous access point products may want to upgrade to split-MAC products. jak ----- Original Message ----- From: "Simon Barber" To: "Mani, Mahalingam (Mahalingam)" ; Sent: Friday, December 12, 2003 4:07 PM Subject: RE: [Lwapp] Comments Invited: Charter Refined. The IEEE TGk is dedicated to providing a remote measurement interface for 802.11. There is also some work going on in the IEEE to establish a new TG to study remote control of access points and clients. This seems to be a direct overlap with the essence of this proposed charter. If the charter were limited to specifically address split-MAC architectures the group's focus would be tighter, and there would be less overlap with work that is going on in the IEEE. Simon Barber -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf Of Mani, Mahalingam (Mahalingam) Sent: Thursday, December 11, 2003 12:23 PM To: lwapp@frascone.com Subject: [Lwapp] Comments Invited: Charter Refined. Following intense deliberations in and between IESG and IAB - the following refined charter has been proposed. In my opinion this is a generalized abstraction of the one discussed in Minneapolis - sans external references (they are abstracted inline) and with a cleaner assertions of the problems - from first principles. It appears to take a step back and urges a look at available architectural taxonomy without (split-AP et al) architectural presumptions - though the split is the prime reason for the BoF initiative. By and large the charter and description track the problem statement but in a generic manner earlier proposed work. Comments are welcome. Regards, -mani ========================= Proposed charter ==================== Control and Provisioning of Wireless Access Points BOF (CAPWAP) DESCRIPTION: As the size and complexity of IEEE 802.11 wireless networks has increased, problems in the deployment, management, and usability of these networks have become evident. Access points (APs) typically require complex management at the IP level. As the number of APs increases, the number of devices requiring complex management increases, in some cases, doubling the number of IP devices requiring management in a provider's network. In addition, because APs have no visibility beyond their own cell, a variety of problems ensue in large scale 802.11 networks. Load balancing between APs, dead cell detection, and correlating patterns of usage between APs to detect attacks are difficult to impossible. Finally, because each AP acts as its own Network Access Server (NAS), a network provider is faced with the prospect of moving from a situation where the NAS is a few machines with dialup access in a machine room to a situation where hundreds or perhaps thousands of devices scattered across a wide geographic area have NAS functionality. Maintaining security on such a wide collection of devices is a difficult challenge. In recent attempts to solve these problems, various vendors have introduced products that redistribute the functionality of 802.11 APs in various ways. However, because the 802.11 access network functional architecture is incompletely specified, the network interfaces between network entities in different vendors' products are defined in incompatible ways. As a result, the protocols between the network entities in different products are not interoperable. CHARTER: As a first step, the CAPWAP Working Group will develop a problem statement and network architecture taxonomy describing the current set of approaches to providing more support for scalable 802.11 access networks. The problem statement will describe, at a high level, what the deployment, management, and usability concerns are with 802.11 networks based on the traditional autonomous AP architecture, and will link those concerns to specific technical aspects of the autonomous AP architecture. The network architecture taxonomy will: - Describe the current set of approaches (including the traditional autonomous AP architecture) to partitioning 802.11 access network functionality between network entities, - List what the interfaces between the network entities are in each approach, - At a functional level, describe what the protocols on the interfaces between the network entites in each approach do, - Describe the advantages and disadvantages of each approach for scalable 802.11 access network deployment and management. Additionally, the architecture document will contain a threat analysis that describes the security threats involved in each network architectural approach. Specific Working Group deliverables are: - A problem statement document, - A network architecture taxonomy document including threat analysis. Specific non-goals of this work are: - Any work requiring revising the 802.11 access network functional architecture The CAPWAP WG will maintain a close working liaison with relevant working groups in IEEE 802.11 and IEEE 802.1. Working Group documents will be sent to an expert review board for review prior to submission to the IESG. In order to facilitate quick completion of this work, the Working Group charter will expire 9 months after it is approved by the IESG, at which time the Working Group can either petition the IESG for a continuation or recharter for further work on the interoperability problem. Goals and Milestones: Feb 2004: Last call for problem statement draft. Mar 2004 Discuss last call comments for problem statement at IETF 59. Mar 2004: Last Call for architecture description document. Apr 2004: Submit problem statement to IESG for publication approval. May 2004: Architecture document to expert review. Aug 2004 Discuss last call comments at IETF 60. Aug 2004: Submit architecture document to IESG for publication approval. Sep 2004: Re-charter ================end charter ======================= From simon@instant802.com Sat Dec 13 00:44:03 2003 From: simon@instant802.com (Simon Barber) Date: Fri, 12 Dec 2003 16:44:03 -0800 Subject: [Lwapp] Comments Invited: Charter Refined. Message-ID: The project authorization request for the TGk group says: " 12. Scope of Proposed Project This project will define Radio Resource Measurement enhancements to provide mechanisms to higher layers for radio and network measurements. 13. Purpose of Proposed Project: To define measurements and develop mechanisms to provide 802.11 wireless network measurement information to higher layers and new applications.=20 15. Are there other standards or projects with a similar scope?=20 Yes, with explanation below Explanation:=20 IETF SNMP The IETF has had a standard for years called the "Simple Network Management Protocol (SNMP)" for access of data about the wired, non-mobile network. The MIBs for this protocol have been defined and allocated. The wireless LAN technologies inject new requirements that include location, mobility, varying power levels, varying signal strength, etc. The IETF has not adequately addressed these requirements for SNMP. " TGk is both about adding new measurements, and extending information about existing measurements and the new ones to upper layers - this includes remote access. The current TGk draft contains a MIB to allow remote access to many measurements. I expect the proposed control group to offer remote control services, as well as extending the 802.11 protocol itself to allow these remote control services to extend over the wireless link. This is something that a standard developed within the IETF could not do. Simon -----Original Message----- From: Bob O'Hara [mailto:bob@airespace.com]=20 Sent: Friday, December 12, 2003 4:15 PM To: Simon Barber; Mani, Mahalingam (Mahalingam); lwapp@frascone.com Subject: RE: [Lwapp] Comments Invited: Charter Refined. Simon, I believe that you are misinterpreting the scope of work for 802.11 TGk and the as yet unapproved 802.11 study group you mention. Both are dealing only with over the air communications, information retrieval from a mobile station by an access point, and (possibly) control of mobile stations remotely from an access point. There has been no contemplation of control and provisioning of access points in a WLAN as a system in 802.11. This work has no overlap with the current or possible future expanded charter of CAPWAP. -Bob =20 -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf Of Simon Barber Sent: Friday, December 12, 2003 4:08 PM To: Mani, Mahalingam (Mahalingam); lwapp@frascone.com Subject: RE: [Lwapp] Comments Invited: Charter Refined. The IEEE TGk is dedicated to providing a remote measurement interface for 802.11. There is also some work going on in the IEEE to establish a new TG to study remote control of access points and clients. This seems to be a direct overlap with the essence of this proposed charter. If the charter were limited to specifically address split-MAC architectures the group's focus would be tighter, and there would be less overlap with work that is going on in the IEEE. Simon Barber -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf Of Mani, Mahalingam (Mahalingam) Sent: Thursday, December 11, 2003 12:23 PM To: lwapp@frascone.com Subject: [Lwapp] Comments Invited: Charter Refined. Following intense deliberations in and between IESG and IAB - the following refined charter has been proposed. In my opinion this is a generalized abstraction of the one discussed in Minneapolis - sans external references (they are abstracted inline) and with a cleaner assertions of the problems - from first principles. It appears to take a step back and urges a look at available architectural taxonomy without (split-AP et al) architectural presumptions - though the split is the prime reason for the BoF initiative. By and large the charter and description track the problem statement but in a generic manner earlier proposed work. Comments are welcome. Regards, -mani =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= Proposed charter = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Control and Provisioning of Wireless Access Points BOF (CAPWAP) DESCRIPTION: As the size and complexity of IEEE 802.11 wireless networks has=20 increased, problems in the deployment, management, and usability of=20 these networks have become evident. Access points (APs) typically=20 require complex management at the IP level. As the number of APs=20 increases, the number of devices requiring complex management=20 increases, in some cases, doubling the number of IP devices requiring=20 management in a provider's network. In addition, because APs have no=20 visibility beyond their own cell, a variety of problems ensue in large=20 scale 802.11 networks. Load balancing between APs, dead cell detection,=20 and correlating patterns of usage between APs to detect attacks are difficult to impossible. Finally, because each AP acts as its own Network Access Server (NAS), a network provider is faced with the prospect of moving from a situation where the NAS is a few machines with dialup access in a machine room to a=20 situation where hundreds or perhaps thousands of devices scattered across a wide geographic area have NAS functionality. Maintaining security on such a wide collection of devices is a difficult challenge. In recent attempts to solve these problems, various vendors have=20 introduced products that redistribute the functionality of 802.11 APs=20 in various ways. However, because the 802.11 access network functional=20 architecture is incompletely specified, the network interfaces between=20 network entities in different vendors' products are defined in=20 incompatible ways. As a result, the protocols between the network entities in different products are not interoperable. CHARTER: As a first step, the CAPWAP Working Group will develop a problem=20 statement and network architecture taxonomy describing the current set=20 of approaches to providing more support for scalable 802.11 access=20 networks. The problem statement will describe, at a high level, what=20 the deployment, management, and usability concerns are with 802.11=20 networks based on the traditional autonomous AP architecture, and will=20 link those concerns to specific technical aspects of the autonomous AP architecture. The network architecture taxonomy will: - Describe the current set of approaches (including the traditional autonomous AP architecture) to partitioning 802.11 access network functionality between network entities, - List what the interfaces between the network entities are in each approach, - At a functional level, describe what the protocols on the interfaces between the network entites in each approach do, - Describe the advantages and disadvantages of each approach for scalable 802.11 access network deployment and management. Additionally, the architecture document will contain a threat analysis=20 that describes the security threats involved in each network=20 architectural approach. Specific Working Group deliverables are: - A problem statement document, - A network architecture taxonomy document including threat analysis. Specific non-goals of this work are: - Any work requiring revising the 802.11 access network functional architecture The CAPWAP WG will maintain a close working liaison with relevant=20 working groups in IEEE 802.11 and IEEE 802.1. Working Group documents=20 will be sent to an expert review board for review prior to submission=20 to the IESG. In order to facilitate quick completion of this work, the=20 Working Group charter will expire 9 months after it is approved by the=20 IESG, at which time the Working Group can either petition the IESG for a continuation or recharter for further work on the=20 interoperability problem. Goals and Milestones: Feb 2004: Last call for problem statement draft. Mar 2004 Discuss last call comments for problem statement at IETF 59. Mar 2004: Last Call for architecture description document. Apr 2004: Submit problem statement to IESG for publication approval. May 2004: Architecture document to expert review. Aug 2004 Discuss last call comments at IETF 60. Aug 2004: Submit architecture document to IESG for publication approval. Sep 2004: Re-charter =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Dend charter = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From bob@airespace.com Sat Dec 13 01:36:11 2003 From: bob@airespace.com (Bob O'Hara) Date: Fri, 12 Dec 2003 17:36:11 -0800 Subject: [Lwapp] Comments Invited: Charter Refined. Message-ID: <55749BC69138654EBBC4C50BA4F5561096D9FF@AIREMAIL.airespace.com> Simon, Your citation of the PAR for 802.11k simply supports my statements. Thank you. The scope is to define measurements that enable mechanisms in higher layers. CAPWAP is just such a higher layer. This is entirely in concert with the stated scope of 802.11k. The purpose cited is simply a reiteration of the scope, define measurements and develop mechanisms to export those measurements to higher layers. There is absolutely nothing in either the scope or purpose that overlap with CAPWAP. CAPWAP might, in part, make use of the measurements exported via 802.11k. This is synergy, not conflict. Your expectations about the future work of an 802.11 control group is pure speculation at this point, as there is not yet even a draft of the PAR for that group. -Bob =20 -----Original Message----- From: Simon Barber [mailto:simon@instant802.com]=20 Sent: Friday, December 12, 2003 4:44 PM To: Bob O'Hara; Mani, Mahalingam (Mahalingam); lwapp@frascone.com Subject: RE: [Lwapp] Comments Invited: Charter Refined. The project authorization request for the TGk group says: " 12. Scope of Proposed Project This project will define Radio Resource Measurement enhancements to provide mechanisms to higher layers for radio and network measurements. 13. Purpose of Proposed Project: To define measurements and develop mechanisms to provide 802.11 wireless network measurement information to higher layers and new applications.=20 15. Are there other standards or projects with a similar scope?=20 Yes, with explanation below Explanation:=20 IETF SNMP The IETF has had a standard for years called the "Simple Network Management Protocol (SNMP)" for access of data about the wired, non-mobile network. The MIBs for this protocol have been defined and allocated. The wireless LAN technologies inject new requirements that include location, mobility, varying power levels, varying signal strength, etc. The IETF has not adequately addressed these requirements for SNMP. " TGk is both about adding new measurements, and extending information about existing measurements and the new ones to upper layers - this includes remote access. The current TGk draft contains a MIB to allow remote access to many measurements. I expect the proposed control group to offer remote control services, as well as extending the 802.11 protocol itself to allow these remote control services to extend over the wireless link. This is something that a standard developed within the IETF could not do. Simon -----Original Message----- From: Bob O'Hara [mailto:bob@airespace.com]=20 Sent: Friday, December 12, 2003 4:15 PM To: Simon Barber; Mani, Mahalingam (Mahalingam); lwapp@frascone.com Subject: RE: [Lwapp] Comments Invited: Charter Refined. Simon, I believe that you are misinterpreting the scope of work for 802.11 TGk and the as yet unapproved 802.11 study group you mention. Both are dealing only with over the air communications, information retrieval from a mobile station by an access point, and (possibly) control of mobile stations remotely from an access point. There has been no contemplation of control and provisioning of access points in a WLAN as a system in 802.11. This work has no overlap with the current or possible future expanded charter of CAPWAP. -Bob =20 -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf Of Simon Barber Sent: Friday, December 12, 2003 4:08 PM To: Mani, Mahalingam (Mahalingam); lwapp@frascone.com Subject: RE: [Lwapp] Comments Invited: Charter Refined. The IEEE TGk is dedicated to providing a remote measurement interface for 802.11. There is also some work going on in the IEEE to establish a new TG to study remote control of access points and clients. This seems to be a direct overlap with the essence of this proposed charter. If the charter were limited to specifically address split-MAC architectures the group's focus would be tighter, and there would be less overlap with work that is going on in the IEEE. Simon Barber -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf Of Mani, Mahalingam (Mahalingam) Sent: Thursday, December 11, 2003 12:23 PM To: lwapp@frascone.com Subject: [Lwapp] Comments Invited: Charter Refined. Following intense deliberations in and between IESG and IAB - the following refined charter has been proposed. In my opinion this is a generalized abstraction of the one discussed in Minneapolis - sans external references (they are abstracted inline) and with a cleaner assertions of the problems - from first principles. It appears to take a step back and urges a look at available architectural taxonomy without (split-AP et al) architectural presumptions - though the split is the prime reason for the BoF initiative. By and large the charter and description track the problem statement but in a generic manner earlier proposed work. Comments are welcome. Regards, -mani =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= Proposed charter = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Control and Provisioning of Wireless Access Points BOF (CAPWAP) DESCRIPTION: As the size and complexity of IEEE 802.11 wireless networks has=20 increased, problems in the deployment, management, and usability of=20 these networks have become evident. Access points (APs) typically=20 require complex management at the IP level. As the number of APs=20 increases, the number of devices requiring complex management=20 increases, in some cases, doubling the number of IP devices requiring=20 management in a provider's network. In addition, because APs have no=20 visibility beyond their own cell, a variety of problems ensue in large=20 scale 802.11 networks. Load balancing between APs, dead cell detection,=20 and correlating patterns of usage between APs to detect attacks are difficult to impossible. Finally, because each AP acts as its own Network Access Server (NAS), a network provider is faced with the prospect of moving from a situation where the NAS is a few machines with dialup access in a machine room to a=20 situation where hundreds or perhaps thousands of devices scattered across a wide geographic area have NAS functionality. Maintaining security on such a wide collection of devices is a difficult challenge. In recent attempts to solve these problems, various vendors have=20 introduced products that redistribute the functionality of 802.11 APs=20 in various ways. However, because the 802.11 access network functional=20 architecture is incompletely specified, the network interfaces between=20 network entities in different vendors' products are defined in=20 incompatible ways. As a result, the protocols between the network entities in different products are not interoperable. CHARTER: As a first step, the CAPWAP Working Group will develop a problem=20 statement and network architecture taxonomy describing the current set=20 of approaches to providing more support for scalable 802.11 access=20 networks. The problem statement will describe, at a high level, what=20 the deployment, management, and usability concerns are with 802.11=20 networks based on the traditional autonomous AP architecture, and will=20 link those concerns to specific technical aspects of the autonomous AP architecture. The network architecture taxonomy will: - Describe the current set of approaches (including the traditional autonomous AP architecture) to partitioning 802.11 access network functionality between network entities, - List what the interfaces between the network entities are in each approach, - At a functional level, describe what the protocols on the interfaces between the network entites in each approach do, - Describe the advantages and disadvantages of each approach for scalable 802.11 access network deployment and management. Additionally, the architecture document will contain a threat analysis=20 that describes the security threats involved in each network=20 architectural approach. Specific Working Group deliverables are: - A problem statement document, - A network architecture taxonomy document including threat analysis. Specific non-goals of this work are: - Any work requiring revising the 802.11 access network functional architecture The CAPWAP WG will maintain a close working liaison with relevant=20 working groups in IEEE 802.11 and IEEE 802.1. Working Group documents=20 will be sent to an expert review board for review prior to submission=20 to the IESG. In order to facilitate quick completion of this work, the=20 Working Group charter will expire 9 months after it is approved by the=20 IESG, at which time the Working Group can either petition the IESG for a continuation or recharter for further work on the=20 interoperability problem. Goals and Milestones: Feb 2004: Last call for problem statement draft. Mar 2004 Discuss last call comments for problem statement at IETF 59. Mar 2004: Last Call for architecture description document. Apr 2004: Submit problem statement to IESG for publication approval. May 2004: Architecture document to expert review. Aug 2004 Discuss last call comments at IETF 60. Aug 2004: Submit architecture document to IESG for publication approval. Sep 2004: Re-charter =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Dend charter = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From lefko@trpz.com Sun Dec 14 01:07:51 2003 From: lefko@trpz.com (Martin Lefkowitz) Date: Sat, 13 Dec 2003 17:07:51 -0800 Subject: [Lwapp] Comments Invited: Charter Refined. In-Reply-To: <55749BC69138654EBBC4C50BA4F5561096D9FF@AIREMAIL.airespace. com> Message-ID: <5.1.0.14.2.20031213170100.020d2548@mail.trpz.com> Providing the measurements to upper layers is overlap if you think that the switch part of the architecture is an upper layer from the radio. It does smell like an upper layer to me... I can't see how a group in IEEE will be much different no matter how it's sliced. Marty At 05:36 PM 12/12/2003 -0800, Bob O'Hara wrote: >Simon, > >Your citation of the PAR for 802.11k simply supports my statements. >Thank you. The scope is to define measurements that enable mechanisms >in higher layers. CAPWAP is just such a higher layer. This is entirely >in concert with the stated scope of 802.11k. The purpose cited is >simply a reiteration of the scope, define measurements and develop >mechanisms to export those measurements to higher layers. There is >absolutely nothing in either the scope or purpose that overlap with >CAPWAP. CAPWAP might, in part, make use of the measurements exported >via 802.11k. This is synergy, not conflict. > >Your expectations about the future work of an 802.11 control group is >pure speculation at this point, as there is not yet even a draft of the >PAR for that group. > > -Bob > > >-----Original Message----- >From: Simon Barber [mailto:simon@instant802.com] >Sent: Friday, December 12, 2003 4:44 PM >To: Bob O'Hara; Mani, Mahalingam (Mahalingam); lwapp@frascone.com >Subject: RE: [Lwapp] Comments Invited: Charter Refined. > > >The project authorization request for the TGk group says: > >" >12. Scope of Proposed Project >This project will define Radio Resource Measurement enhancements to >provide mechanisms to higher layers for radio and network measurements. > >13. Purpose of Proposed Project: >To define measurements and develop mechanisms to provide 802.11 wireless >network measurement information to higher layers and new applications. > > >15. Are there other standards or projects with a similar scope? >Yes, with explanation below >Explanation: >IETF SNMP >The IETF has had a standard for years called the "Simple Network >Management Protocol (SNMP)" for access of data about the wired, >non-mobile network. The MIBs for this protocol have been defined and >allocated. The wireless LAN technologies inject new requirements that >include location, mobility, varying power levels, varying signal >strength, etc. The IETF has not adequately addressed these requirements >for SNMP. > >" > >TGk is both about adding new measurements, and extending information >about existing measurements and the new ones to upper layers - this >includes remote access. The current TGk draft contains a MIB to allow >remote access to many measurements. > >I expect the proposed control group to offer remote control services, as >well as extending the 802.11 protocol itself to allow these remote >control services to extend over the wireless link. This is something >that a standard developed within the IETF could not do. > >Simon > > > >-----Original Message----- >From: Bob O'Hara [mailto:bob@airespace.com] >Sent: Friday, December 12, 2003 4:15 PM >To: Simon Barber; Mani, Mahalingam (Mahalingam); lwapp@frascone.com >Subject: RE: [Lwapp] Comments Invited: Charter Refined. > > >Simon, > >I believe that you are misinterpreting the scope of work for 802.11 TGk >and the as yet unapproved 802.11 study group you mention. Both are >dealing only with over the air communications, information retrieval >from a mobile station by an access point, and (possibly) control of >mobile stations remotely from an access point. There has been no >contemplation of control and provisioning of access points in a WLAN as >a system in 802.11. This work has no overlap with the current or >possible future expanded charter of CAPWAP. > > -Bob > >-----Original Message----- >From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On >Behalf Of Simon Barber >Sent: Friday, December 12, 2003 4:08 PM >To: Mani, Mahalingam (Mahalingam); lwapp@frascone.com >Subject: RE: [Lwapp] Comments Invited: Charter Refined. > > >The IEEE TGk is dedicated to providing a remote measurement interface >for 802.11. There is also some work going on in the IEEE to establish a >new TG to study remote control of access points and clients. This seems >to be a direct overlap with the essence of this proposed charter. > >If the charter were limited to specifically address split-MAC >architectures the group's focus would be tighter, and there would be >less overlap with work that is going on in the IEEE. > >Simon Barber >-----Original Message----- >From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On >Behalf Of Mani, Mahalingam (Mahalingam) >Sent: Thursday, December 11, 2003 12:23 PM >To: lwapp@frascone.com >Subject: [Lwapp] Comments Invited: Charter Refined. > > >Following intense deliberations in and between IESG and IAB - the >following refined charter has been proposed. In my opinion this is a >generalized abstraction of the one discussed in Minneapolis - sans >external references (they are abstracted inline) and with a cleaner >assertions of the problems - from first principles. > >It appears to take a step back and urges a look at available >architectural taxonomy without (split-AP et al) architectural >presumptions - though the split is the prime reason for the BoF >initiative. > >By and large the charter and description track the problem statement but >in a generic manner earlier proposed work. > >Comments are welcome. > >Regards, >-mani >========================= Proposed charter ==================== Control >and Provisioning of Wireless Access Points BOF (CAPWAP) > >DESCRIPTION: >As the size and complexity of IEEE 802.11 wireless networks has >increased, problems in the deployment, management, and usability of >these networks have become evident. Access points (APs) typically >require complex management at the IP level. As the number of APs >increases, the number of devices requiring complex management >increases, in some cases, doubling the number of IP devices requiring >management in a provider's network. In addition, because APs have no >visibility beyond their own cell, a variety of problems ensue in large >scale 802.11 networks. Load balancing between APs, dead cell detection, >and correlating patterns of usage between APs to detect attacks are >difficult to impossible. Finally, because each AP acts as its own >Network Access Server (NAS), a network provider is faced with the >prospect of moving from a situation where the NAS is a few machines with >dialup access in a machine room to a >situation where hundreds or perhaps thousands of devices scattered >across a wide geographic area have NAS functionality. Maintaining >security on such a wide collection of devices is a difficult challenge. > >In recent attempts to solve these problems, various vendors have >introduced products that redistribute the functionality of 802.11 APs >in various ways. However, because the 802.11 access network functional >architecture is incompletely specified, the network interfaces between >network entities in different vendors' products are defined in >incompatible ways. As a result, the protocols between the network >entities in different products are not interoperable. > >CHARTER: >As a first step, the CAPWAP Working Group will develop a problem >statement and network architecture taxonomy describing the current set >of approaches to providing more support for scalable 802.11 access >networks. The problem statement will describe, at a high level, what >the deployment, management, and usability concerns are with 802.11 >networks based on the traditional autonomous AP architecture, and will >link those concerns to specific technical aspects of the autonomous AP >architecture. The network architecture taxonomy will: > > - Describe the current set of approaches (including the > traditional autonomous AP architecture) to partitioning > 802.11 access network functionality between network > entities, > - List what the interfaces between the network entities > are in each approach, > - At a functional level, describe what the protocols on > the interfaces between the network entites in each > approach do, > - Describe the advantages and disadvantages of each > approach for scalable 802.11 access network deployment > and management. > >Additionally, the architecture document will contain a threat analysis >that describes the security threats involved in each network >architectural approach. > >Specific Working Group deliverables are: > > - A problem statement document, > - A network architecture taxonomy document including > threat analysis. > >Specific non-goals of this work are: > - Any work requiring revising the 802.11 access network > functional architecture > >The CAPWAP WG will maintain a close working liaison with relevant >working groups in IEEE 802.11 and IEEE 802.1. Working Group documents >will be sent to an expert review board for review prior to submission >to the IESG. In order to facilitate quick completion of this work, the >Working Group charter will expire 9 months after it is approved by the >IESG, at which time the Working Group can either petition the IESG for a >continuation or recharter for further work on the >interoperability problem. > >Goals and Milestones: > Feb 2004: Last call for problem statement draft. > Mar 2004 Discuss last call comments for problem statement > at IETF 59. > Mar 2004: Last Call for architecture description document. Apr 2004: >Submit problem statement to IESG for publication > approval. > May 2004: Architecture document to expert review. > Aug 2004 Discuss last call comments at IETF 60. > Aug 2004: Submit architecture document to IESG for publication > approval. > Sep 2004: Re-charter >================end charter ======================= >_______________________________________________ >Lwapp mailing list >Lwapp@frascone.com >http://mail.frascone.com/mailman/listinfo/lwapp >_______________________________________________ >Lwapp-external mailing list >Lwapp-external@mailman.trpz.com >http://mailman/mailman/listinfo/lwapp-external From Michael.G.Williams@nokia.com Mon Dec 15 19:54:12 2003 From: Michael.G.Williams@nokia.com (Michael.G.Williams@nokia.com) Date: Mon, 15 Dec 2003 11:54:12 -0800 Subject: [Lwapp] Comments Invited: Charter Refined. Message-ID: <59A36C4D2F9E7243BEB522274F72C303FD0500@mvebe001.americas.nokia.com> Agree with Bob, if the reference was to Harry's proposal, it's too early = to say if there is overlap and it shouldn't derail anything CAPWAP is = doing for now. In general, it's not helpful to worry about the existing/possible = overlap with IEEE. Instead it would be best to get on with the = architectural work. If there is overlap it will be discovered in course = and sorted out. It wouldn't be surprising that the concepts emerging here will = facilitate standards on both IEEE & IETF side that need to deal with L2 = & L3 in them. Michael -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com]On Behalf Of ext Martin Lefkowitz Sent: Saturday, December 13, 2003 5:08 PM To: lwapp@frascone.com Subject: RE: [Lwapp] Comments Invited: Charter Refined. Providing the measurements to upper layers is overlap if you think that = the=20 switch part of the architecture is an upper layer from the radio. It = does=20 smell like an upper layer to me... I can't see how a group in IEEE will be much different no matter how = it's=20 sliced. Marty At 05:36 PM 12/12/2003 -0800, Bob O'Hara wrote: >Simon, > >Your citation of the PAR for 802.11k simply supports my statements. >Thank you. The scope is to define measurements that enable mechanisms >in higher layers. CAPWAP is just such a higher layer. This is = entirely >in concert with the stated scope of 802.11k. The purpose cited is >simply a reiteration of the scope, define measurements and develop >mechanisms to export those measurements to higher layers. There is >absolutely nothing in either the scope or purpose that overlap with >CAPWAP. CAPWAP might, in part, make use of the measurements exported >via 802.11k. This is synergy, not conflict. > >Your expectations about the future work of an 802.11 control group is >pure speculation at this point, as there is not yet even a draft of the >PAR for that group. > > -Bob > > >-----Original Message----- >From: Simon Barber [mailto:simon@instant802.com] >Sent: Friday, December 12, 2003 4:44 PM >To: Bob O'Hara; Mani, Mahalingam (Mahalingam); lwapp@frascone.com >Subject: RE: [Lwapp] Comments Invited: Charter Refined. > > >The project authorization request for the TGk group says: > >" >12. Scope of Proposed Project >This project will define Radio Resource Measurement enhancements to >provide mechanisms to higher layers for radio and network measurements. > >13. Purpose of Proposed Project: >To define measurements and develop mechanisms to provide 802.11 = wireless >network measurement information to higher layers and new applications. > > >15. Are there other standards or projects with a similar scope? >Yes, with explanation below >Explanation: >IETF SNMP >The IETF has had a standard for years called the "Simple Network >Management Protocol (SNMP)" for access of data about the wired, >non-mobile network. The MIBs for this protocol have been defined and >allocated. The wireless LAN technologies inject new requirements that >include location, mobility, varying power levels, varying signal >strength, etc. The IETF has not adequately addressed these = requirements >for SNMP. > >" > >TGk is both about adding new measurements, and extending information >about existing measurements and the new ones to upper layers - this >includes remote access. The current TGk draft contains a MIB to allow >remote access to many measurements. > >I expect the proposed control group to offer remote control services, = as >well as extending the 802.11 protocol itself to allow these remote >control services to extend over the wireless link. This is something >that a standard developed within the IETF could not do. > >Simon > > > >-----Original Message----- >From: Bob O'Hara [mailto:bob@airespace.com] >Sent: Friday, December 12, 2003 4:15 PM >To: Simon Barber; Mani, Mahalingam (Mahalingam); lwapp@frascone.com >Subject: RE: [Lwapp] Comments Invited: Charter Refined. > > >Simon, > >I believe that you are misinterpreting the scope of work for 802.11 TGk >and the as yet unapproved 802.11 study group you mention. Both are >dealing only with over the air communications, information retrieval >from a mobile station by an access point, and (possibly) control of >mobile stations remotely from an access point. There has been no >contemplation of control and provisioning of access points in a WLAN as >a system in 802.11. This work has no overlap with the current or >possible future expanded charter of CAPWAP. > > -Bob > >-----Original Message----- >From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On >Behalf Of Simon Barber >Sent: Friday, December 12, 2003 4:08 PM >To: Mani, Mahalingam (Mahalingam); lwapp@frascone.com >Subject: RE: [Lwapp] Comments Invited: Charter Refined. > > >The IEEE TGk is dedicated to providing a remote measurement interface >for 802.11. There is also some work going on in the IEEE to establish a >new TG to study remote control of access points and clients. This seems >to be a direct overlap with the essence of this proposed charter. > >If the charter were limited to specifically address split-MAC >architectures the group's focus would be tighter, and there would be >less overlap with work that is going on in the IEEE. > >Simon Barber >-----Original Message----- >From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On >Behalf Of Mani, Mahalingam (Mahalingam) >Sent: Thursday, December 11, 2003 12:23 PM >To: lwapp@frascone.com >Subject: [Lwapp] Comments Invited: Charter Refined. > > >Following intense deliberations in and between IESG and IAB - the >following refined charter has been proposed. In my opinion this is a >generalized abstraction of the one discussed in Minneapolis - sans >external references (they are abstracted inline) and with a cleaner >assertions of the problems - from first principles. > >It appears to take a step back and urges a look at available >architectural taxonomy without (split-AP et al) architectural >presumptions - though the split is the prime reason for the BoF >initiative. > >By and large the charter and description track the problem statement = but >in a generic manner earlier proposed work. > >Comments are welcome. > >Regards, >-mani >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Proposed charter = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Control >and Provisioning of Wireless Access Points BOF (CAPWAP) > >DESCRIPTION: >As the size and complexity of IEEE 802.11 wireless networks has >increased, problems in the deployment, management, and usability of >these networks have become evident. Access points (APs) typically >require complex management at the IP level. As the number of APs >increases, the number of devices requiring complex management >increases, in some cases, doubling the number of IP devices requiring >management in a provider's network. In addition, because APs have no >visibility beyond their own cell, a variety of problems ensue in large >scale 802.11 networks. Load balancing between APs, dead cell detection, >and correlating patterns of usage between APs to detect attacks are >difficult to impossible. Finally, because each AP acts as its own >Network Access Server (NAS), a network provider is faced with the >prospect of moving from a situation where the NAS is a few machines = with >dialup access in a machine room to a >situation where hundreds or perhaps thousands of devices scattered >across a wide geographic area have NAS functionality. Maintaining >security on such a wide collection of devices is a difficult challenge. > >In recent attempts to solve these problems, various vendors have >introduced products that redistribute the functionality of 802.11 APs >in various ways. However, because the 802.11 access network functional >architecture is incompletely specified, the network interfaces between >network entities in different vendors' products are defined in >incompatible ways. As a result, the protocols between the network >entities in different products are not interoperable. > >CHARTER: >As a first step, the CAPWAP Working Group will develop a problem >statement and network architecture taxonomy describing the current set >of approaches to providing more support for scalable 802.11 access >networks. The problem statement will describe, at a high level, what >the deployment, management, and usability concerns are with 802.11 >networks based on the traditional autonomous AP architecture, and will >link those concerns to specific technical aspects of the autonomous AP >architecture. The network architecture taxonomy will: > > - Describe the current set of approaches (including the > traditional autonomous AP architecture) to partitioning > 802.11 access network functionality between network > entities, > - List what the interfaces between the network entities > are in each approach, > - At a functional level, describe what the protocols on > the interfaces between the network entites in each > approach do, > - Describe the advantages and disadvantages of each > approach for scalable 802.11 access network deployment > and management. > >Additionally, the architecture document will contain a threat analysis >that describes the security threats involved in each network >architectural approach. > >Specific Working Group deliverables are: > > - A problem statement document, > - A network architecture taxonomy document including > threat analysis. > >Specific non-goals of this work are: > - Any work requiring revising the 802.11 access network > functional architecture > >The CAPWAP WG will maintain a close working liaison with relevant >working groups in IEEE 802.11 and IEEE 802.1. Working Group documents >will be sent to an expert review board for review prior to submission >to the IESG. In order to facilitate quick completion of this work, the >Working Group charter will expire 9 months after it is approved by the >IESG, at which time the Working Group can either petition the IESG for = a >continuation or recharter for further work on the >interoperability problem. > >Goals and Milestones: > Feb 2004: Last call for problem statement draft. > Mar 2004 Discuss last call comments for problem statement > at IETF 59. > Mar 2004: Last Call for architecture description document. Apr = 2004: >Submit problem statement to IESG for publication > approval. > May 2004: Architecture document to expert review. > Aug 2004 Discuss last call comments at IETF 60. > Aug 2004: Submit architecture document to IESG for publication > approval. > Sep 2004: Re-charter >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Dend charter = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >_______________________________________________ >Lwapp mailing list >Lwapp@frascone.com >http://mail.frascone.com/mailman/listinfo/lwapp >_______________________________________________ >Lwapp-external mailing list >Lwapp-external@mailman.trpz.com >http://mailman/mailman/listinfo/lwapp-external _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From bwijnen@lucent.com Tue Dec 16 22:51:00 2003 From: bwijnen@lucent.com (Wijnen, Bert (Bert)) Date: Tue, 16 Dec 2003 23:51:00 +0100 Subject: [Lwapp] Comments Invited: Charter Refined. Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155032D965A@nl0006exch001u.nl.lucent.com> I'd like to make sure people understand. See my comments inline > -----Original Message----- > From: Mani, Mahalingam (Mahalingam) [mailto:mmani@avaya.com] > Sent: donderdag 11 december 2003 21:23 > To: lwapp@frascone.com > Subject: [Lwapp] Comments Invited: Charter Refined. > > Following intense deliberations in and between IESG and IAB - > the following refined charter has been proposed. > In my opinion this is a generalized abstraction of the one > discussed in Minneapolis - sans external references (they are > abstracted inline) and with a cleaner assertions of the > problems - from first principles. > > It appears to take a step back and urges a look at available > architectural taxonomy without (split-AP et al) architectural > presumptions - though the split is the prime reason for the > BoF initiative. > I hope it is clear from this charter that the split-AP architecture can and should also be included. But also the traditional automomous AP. We want to see all functional blocks and how they interact. We want to understand the interfaces and the pros and cons of various approaches. We want to see the threat analysis of the various approaches. In two words: architectural taxonmy. Bert > By and large the charter and description track the problem > statement but in a generic manner earlier proposed work. > > Comments are welcome. > > Regards, > -mani > ========================= Proposed charter ==================== > Control and Provisioning of Wireless Access Points BOF (CAPWAP) > > DESCRIPTION: > As the size and complexity of IEEE 802.11 wireless networks has > increased, problems in the deployment, management, and usability of > these networks have become evident. Access points (APs) typically > require complex management at the IP level. As the number of APs > increases, the number of devices requiring complex management > increases, in some cases, doubling the number of IP devices requiring > management in a provider's network. In addition, because APs have no > visibility beyond their own cell, a variety of problems ensue > in large > scale 802.11 networks. Load balancing between APs, dead cell > detection, > and correlating patterns of usage between APs to detect attacks are > difficult to impossible. Finally, because each AP acts as its > own Network Access Server (NAS), a network provider is faced > with the prospect of moving from a situation where the NAS is > a few machines with dialup access in a machine room to a > situation where hundreds or perhaps thousands of devices > scattered across a wide geographic area have NAS functionality. > Maintaining security on such a wide collection of devices is a > difficult challenge. > > In recent attempts to solve these problems, various vendors have > introduced products that redistribute the functionality of 802.11 APs > in various ways. However, because the 802.11 access network > functional > architecture is incompletely specified, the network > interfaces between > network entities in different vendors' products are defined in > incompatible ways. As a result, the protocols between the network > entities in different products are not interoperable. > > CHARTER: > As a first step, the CAPWAP Working Group will develop a problem > statement and network architecture taxonomy describing the > current set > of approaches to providing more support for scalable 802.11 access > networks. The problem statement will describe, at a high level, what > the deployment, management, and usability concerns are with 802.11 > networks based on the traditional autonomous AP architecture, > and will > link those concerns to specific technical aspects of the autonomous AP > architecture. The network architecture taxonomy will: > > - Describe the current set of approaches (including the > traditional autonomous AP architecture) to partitioning > 802.11 access network functionality between network > entities, > - List what the interfaces between the network entities > are in each approach, > - At a functional level, describe what the protocols on > the interfaces between the network entites in each > approach do, > - Describe the advantages and disadvantages of each > approach for scalable 802.11 access network deployment > and management. > > Additionally, the architecture document will contain a threat > analysis > that describes the security threats involved in each network > architectural approach. > > Specific Working Group deliverables are: > > - A problem statement document, > - A network architecture taxonomy document including > threat analysis. > > Specific non-goals of this work are: > - Any work requiring revising the 802.11 access network > functional architecture > > The CAPWAP WG will maintain a close working liaison with relevant > working groups in IEEE 802.11 and IEEE 802.1. Working Group documents > will be sent to an expert review board for review prior to submission > to the IESG. In order to facilitate quick completion of this > work, the > Working Group charter will expire 9 months after it is > approved by the > IESG, at which time the Working Group can either petition the IESG > for a continuation or recharter for further work on the > interoperability problem. > > Goals and Milestones: > Feb 2004: Last call for problem statement draft. > Mar 2004 Discuss last call comments for problem statement > at IETF 59. > Mar 2004: Last Call for architecture description document. > Apr 2004: Submit problem statement to IESG for publication > approval. > May 2004: Architecture document to expert review. > Aug 2004 Discuss last call comments at IETF 60. > Aug 2004: Submit architecture document to IESG for publication > approval. > Sep 2004: Re-charter > ================end charter ======================= > From dave@frascone.com Wed Dec 17 17:27:45 2003 From: dave@frascone.com (David Frascone) Date: Wed, 17 Dec 2003 11:27:45 -0600 Subject: [Capwap] testing Message-ID: <20031217172745.GG5979@frascone.com> Test, please ignore. -- David Frascone A cat will go "quack" - if you squeeze it hard enough. From dave@frascone.com Wed Dec 17 17:28:08 2003 From: dave@frascone.com (David Frascone) Date: Wed, 17 Dec 2003 11:28:08 -0600 Subject: [Capwap] test, please ignore Message-ID: <20031217172807.GH5979@frascone.com> -- David Frascone Confucius say: Man who run behind truck get exhausted. From dave@frascone.com Wed Dec 17 17:32:50 2003 From: dave@frascone.com (David Frascone) Date: Wed, 17 Dec 2003 11:32:50 -0600 Subject: [Capwap] List Name Change Message-ID: <20031217173250.GI5979@frascone.com> As you can probably tell from the previous two test mails, the lwapp mailing list has been renamed to "capwap". The old addresses (lwapp@frascone.com), will continue to work for a while. The old web links will also work for a while. The new list address is capwap@frascone.com, and the new list URL is http://mail.frascone.com/listinfo/capwap. Please update your address books and bookmarks accordingly. Please also let me know if you notice any problems associated with this transition. -Dave -- David Frascone I like to think of myself as a divide overflow. From bwijnen@lucent.com Wed Dec 17 23:01:15 2003 From: bwijnen@lucent.com (Wijnen, Bert (Bert)) Date: Thu, 18 Dec 2003 00:01:15 +0100 Subject: [Capwap] List Name Change Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155032D9927@nl0006exch001u.nl.lucent.com> > As you can probably tell from the previous two test mails, the lwapp > mailing list has been renamed to "capwap". The old addresses > (lwapp@frascone.com), will continue to work for a while. The old web > links will also work for a while. > > The new list address is capwap@frascone.com, and the new list URL is > http://mail.frascone.com/listinfo/capwap. Please update your address > books and bookmarks accordingly. > The above libnk does not work. the one at the bottom does! > Please also let me know if you notice any problems associated > with this > transition. > > -Dave > > > -- > David Frascone > > I like to think of myself as a divide overflow. > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > This one works, Bert From dave@frascone.com Thu Dec 18 03:17:04 2003 From: dave@frascone.com (David Frascone) Date: Wed, 17 Dec 2003 21:17:04 -0600 Subject: [Capwap] List Name Change In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155032D9927@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B155032D9927@nl0006exch001u.nl.lucent.com> Message-ID: <20031218031704.GG2224@frascone.com> On Thursday, 18 Dec 2003, Wijnen, Bert (Bert) wrote: > > > The above libnk does not work. > > the one at the bottom does! Yup, it was a typo. Perhaps I should have cut-and pasted it, rather than trying to type it from memory :) -Dave -- David Frascone Marriage is one of the chief causes of divorce. From bwijnen@lucent.com Fri Dec 19 13:08:16 2003 From: bwijnen@lucent.com (Wijnen, Bert (Bert)) Date: Fri, 19 Dec 2003 14:08:16 +0100 Subject: [Capwap] CAPWAP charter status Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155032D9CD4@nl0006exch001u.nl.lucent.com> IESG yesterday agreed that the charter discussed on the list (over last week) can be sent to IETF-announce for community review. So you can expect to see that review message to show up in the next few days. It will be on IESG agenda again on Jan 8th to discuss community comments/input (if any). Thanks, Bert From austin.j.hawthorne@citigroup.com Mon Dec 22 21:27:38 2003 From: austin.j.hawthorne@citigroup.com (Hawthorne, Austin J [IT]) Date: Mon, 22 Dec 2003 16:27:38 -0500 Subject: [Capwap] Station Data Implications in a Centralized/Tunneled LWAPP Model Message-ID: <159DF57E62CDD5118FCA0002A51352B00C507494@EXCHNY36.ny.ssmb.com> Hello all....I am rather new to this list but have been snooping around for a little while in an attempt to get caught up to speed with the latest developments in WLAN design and architecture considerations. After reading some of the presentations and the current drafts (specifically draft-calhoun-seamoby-lwapp-03), I have some concerns about the impact the implementation of a WLAN, designed around LWAPP, would have on the underlying network. I am hoping some of you may be able to answer some of my questions...assuming some of my concerns have been considered already (and possible have not been clarified in the draft as of yet)...or if they have not been addressed yet, to possible explore possibilities to resolve them. So, let me get to the nuts and bolts of it.....my concerns stem from the concept of "centralization of the bridging, forwarding, authentication, encryption, and policy enforcement.....". While the draft has gone through great lengths to define the control and management of the "lightweight AP", I believe much has been left out with regards to the client data handling and the implications the tunneling has on the underlying network as well as how certain packets/frames are handled via the tunneling mechanism. Specifically the impact multicast and broadcast traffic have directly on the network and network design when being tunneled via LWAPP. Knowing that LWAPP can be an overlay on top of an existing L2 or L3 (or both) network, the impact of how LWAPP handles mcast/bcast could vary....but the relevance of the argument is the same regardless. >From my interpretation of the draft, all client traffic (I am skipping over all the control and management traffic) is encapsulated in an LWAPP header as well as a new L2 header (if bridging) or L3 header that are addressed with the tunnel endpoints (AP and AR) accordingly. I walk through my concerns in a couple of scenarios. Scenario #1: In an L2 environment with the AP and AR (bridging AR) situated as such: Multiple_AP<---->L2_Closet_Switch<---->L2_Aggregation_Switch<---->Router ^ ^ ^ ^ Multiple_AP<---->L2_Closet_Switch<----------| | | | | |--AR--| Desktop<-------->L2_Closet_Switch<-------------| In this environment, the current draft lends me to believe that the AR could receive a bcast from a wired desktop or station off an AP and will deliver this bcast to every other AP via a unicast frame to each AP separately....so if I have 100+ APs on one L2 segment, that means that 1 bcast frame gets sent out up to 100+ times (assuming all APs share the same VLAN for station traffic) thereby multiplying my traffic on the network by as much. The same scenario applies to mcast...assuming the AR has the capability to snoop IGMP, it could keep track of APs that have stations that want a specific mcast stream, but if multiple APs require the stream, I am back to the issue with the bandwidth multiplication due to the tunneling of station traffic to each AP. (disclaimer....i realize that the same VLAN for 100+ APs might be extreme, but one possible design solution would be to put users on different subnets, but extend these subnets to all APs in a building...so that a user would roam at L2 from AP to AP instead of introducing mobile-IP within a building/campus). Scenario #2: In an L2/L3 environment with the AP and AR (routing AR) situated as such: Multiple_AP<---->L2_Closet_Switch<---->L2_Aggregation_Switch<---->Router<--- >AR ^ Multiple_AP<---->L2_Closet_Switch<----------| In this environment if an AR gets a tunneled bcast/mcast from a station and must turn it around to stations on the same subset of APs, this is turned around via multiple unicast packets thereby multiplying my traffic on that LAN. In both of these environments, I am assuming I understood the draft correctly and that these frames are being sent via unicast addressed frames/packets to each AP separately. If I am wrong and the tunnel header uses broadcast/multicast addresses on the underlying L2 subnet (directed broadcast for IP), then another concern exists when APs that do not have stations needing that traffic (i.e., AP does not have a station associated to VLAN 'x' or subscribed to mcast group x.x.x.x) still receive the traffic (whether or not they broadcast on the wireless side is another story...but I don't consider that a concern, because I assume the AP would drop it). This could severely impact station tput on the 10/100M links to/from the AP. Another issue not explored yet is the generic bandwidth restrictions this model places on the underlying network. We have the possibility of an AP operating on possibly multiple radios (for example, and AP has a channel for 802.11a and a channel for 802.11g). This presents the possibility that one AP could be introducing upwards of 60~70Mbps to the AR. Provisioning the underlying network (specifically a centralized AR model in a large L3 network) to handle this traffic could become cumbersome and not efficient (specifically when we consider the bcast/mcast again). Without spelling out every scenario, I think my point is clear. With a LWAPP tunnel overlay on top of existing/new L2/L3 topologies, I loss some visibility into some protocol mechanisms that could be used for traffic engineering the underlying network....for example, 802.1Q header, IGMP group membership reports, etc. With "heavyweight APs" I have the capability to possibly design a VLAN environment using GVRP, turn on IGMP snooping, use directed broadcasts, etc. But then I am back to the management and control issue. One solution would be to have a hybrid scenario....use LWAPP for control and management, but allow client data frames traverse the network natively with an option to tunnel the client data frames to the AR (in case of mobile-IP or dedicated VLAN for higher risk users). This would cause the AP to be classed as "middle-weight"...the encryption, forwarding, etc...would be handled at the AP. Is this a possibility? Some of you may consider these non-issues, but I have been struggling with the concepts presented so far and need some constructive feedback on why they would be "non-issues". I must admit, that currently I am on the fence with regards to which WLAN AP architecture ("lightweight AP" vs. "heavyweight AP") fills my needs the most (speaking from a enterprise network engineering point of view). I understand the concerns with the management and control of the potentially large number of "heavyweight APs" that could be deployed to satisfy requirements, but I also have these concerns that centralizing everything will have. I am very curious on hearing your thoughts on this.... Thanks and Regards, Austin From hbims@airflownetworks.com Tue Dec 23 18:59:51 2003 From: hbims@airflownetworks.com (Harry Bims) Date: Tue, 23 Dec 2003 10:59:51 -0800 Subject: [Capwap] RE: Capwap digest, Vol 1 #134 - 1 msg Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C3C986.F18BE373 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable >From my perspective, the AR can perform all of the traffic engineering = functions that you are looking for, since it has global knowledge of = where all wireless LAN clients are located. However, one can always = devise a scenario in which the packet multiplication required to support = bcast/mcast packets could overwhelm the network, despite all efforts at = traffic engineering. At some point, the answer is to upgrade to a = faster pipe for your network links. Harry -----Original Message----- From: capwap-request@frascone.com [mailto:capwap-request@frascone.com] Sent: Tue 12/23/2003 10:00 AM To: capwap@frascone.com Cc:=09 Subject: Capwap digest, Vol 1 #134 - 1 msg Send Capwap mailing list submissions to capwap@frascone.com To subscribe or unsubscribe via the World Wide Web, visit http://mail.frascone.com/mailman/listinfo/capwap or, via email, send a message with subject or body 'help' to capwap-request@frascone.com You can reach the person managing the list at capwap-admin@frascone.com When replying, please edit your Subject line so it is more specific than "Re: Contents of Capwap digest..." Today's Topics: 1. Station Data Implications in a Centralized/Tunneled LWAPP Model = (Hawthorne, Austin J [IT]) --__--__-- Message: 1 From: "Hawthorne, Austin J [IT]" To: "'capwap@frascone.com'" Date: Mon, 22 Dec 2003 16:27:38 -0500 Subject: [Capwap] Station Data Implications in a Centralized/Tunneled = LWAPP Model Hello all....I am rather new to this list but have been snooping around = for a little while in an attempt to get caught up to speed with the latest developments in WLAN design and architecture considerations. After = reading some of the presentations and the current drafts (specifically draft-calhoun-seamoby-lwapp-03), I have some concerns about the impact = the implementation of a WLAN, designed around LWAPP, would have on the underlying network. I am hoping some of you may be able to answer some = of my questions...assuming some of my concerns have been considered already (and possible have not been clarified in the draft as of yet)...or if = they have not been addressed yet, to possible explore possibilities to = resolve them.=20 So, let me get to the nuts and bolts of it.....my concerns stem from the concept of "centralization of the bridging, forwarding, authentication, encryption, and policy enforcement.....". While the draft has gone = through great lengths to define the control and management of the "lightweight = AP", I believe much has been left out with regards to the client data = handling and the implications the tunneling has on the underlying network as well = as how certain packets/frames are handled via the tunneling mechanism. Specifically the impact multicast and broadcast traffic have directly on = the network and network design when being tunneled via LWAPP. Knowing that LWAPP can be an overlay on top of an existing L2 or L3 (or both) = network, the impact of how LWAPP handles mcast/bcast could vary....but the = relevance of the argument is the same regardless. =20 >From my interpretation of the draft, all client traffic (I am skipping = over all the control and management traffic) is encapsulated in an LWAPP = header as well as a new L2 header (if bridging) or L3 header that are addressed with the tunnel endpoints (AP and AR) accordingly. I walk through my concerns in a couple of scenarios. Scenario #1: In an L2 environment with the AP and AR (bridging AR) = situated as such: Multiple_AP<---->L2_Closet_Switch<---->L2_Aggregation_Switch<---->Router ^ ^ ^ ^ =20 Multiple_AP<---->L2_Closet_Switch<----------| | | | | |--AR--| Desktop<-------->L2_Closet_Switch<-------------| In this environment, the current draft lends me to believe that the AR = could receive a bcast from a wired desktop or station off an AP and will = deliver this bcast to every other AP via a unicast frame to each AP = separately....so if I have 100+ APs on one L2 segment, that means that 1 bcast frame gets sent out up to 100+ times (assuming all APs share the same VLAN for = station traffic) thereby multiplying my traffic on the network by as much. The = same scenario applies to mcast...assuming the AR has the capability to snoop IGMP, it could keep track of APs that have stations that want a specific mcast stream, but if multiple APs require the stream, I am back to the = issue with the bandwidth multiplication due to the tunneling of station = traffic to each AP. (disclaimer....i realize that the same VLAN for 100+ APs might = be extreme, but one possible design solution would be to put users on = different subnets, but extend these subnets to all APs in a building...so that a = user would roam at L2 from AP to AP instead of introducing mobile-IP within a building/campus). Scenario #2: In an L2/L3 environment with the AP and AR (routing AR) situated as such: Multiple_AP<---->L2_Closet_Switch<---->L2_Aggregation_Switch<---->Router<= --- >AR ^ =20 Multiple_AP<---->L2_Closet_Switch<----------| =20 =20 In this environment if an AR gets a tunneled bcast/mcast from a station = and must turn it around to stations on the same subset of APs, this is = turned around via multiple unicast packets thereby multiplying my traffic on = that LAN. In both of these environments, I am assuming I understood the draft correctly and that these frames are being sent via unicast addressed frames/packets to each AP separately. If I am wrong and the tunnel = header uses broadcast/multicast addresses on the underlying L2 subnet (directed broadcast for IP), then another concern exists when APs that do not have stations needing that traffic (i.e., AP does not have a station = associated to VLAN 'x' or subscribed to mcast group x.x.x.x) still receive the = traffic (whether or not they broadcast on the wireless side is another = story...but I don't consider that a concern, because I assume the AP would drop it). = This could severely impact station tput on the 10/100M links to/from the AP.=20 Another issue not explored yet is the generic bandwidth restrictions = this model places on the underlying network. We have the possibility of an = AP operating on possibly multiple radios (for example, and AP has a channel = for 802.11a and a channel for 802.11g). This presents the possibility that = one AP could be introducing upwards of 60~70Mbps to the AR. Provisioning = the underlying network (specifically a centralized AR model in a large L3 network) to handle this traffic could become cumbersome and not = efficient (specifically when we consider the bcast/mcast again). Without spelling out every scenario, I think my point is clear. With a LWAPP tunnel overlay on top of existing/new L2/L3 topologies, I loss = some visibility into some protocol mechanisms that could be used for traffic engineering the underlying network....for example, 802.1Q header, IGMP = group membership reports, etc. With "heavyweight APs" I have the capability = to possibly design a VLAN environment using GVRP, turn on IGMP snooping, = use directed broadcasts, etc. But then I am back to the management and = control issue. =20 One solution would be to have a hybrid scenario....use LWAPP for control = and management, but allow client data frames traverse the network natively = with an option to tunnel the client data frames to the AR (in case of = mobile-IP or dedicated VLAN for higher risk users). This would cause the AP to be classed as "middle-weight"...the encryption, forwarding, etc...would be handled at the AP. Is this a possibility? Some of you may consider these non-issues, but I have been struggling = with the concepts presented so far and need some constructive feedback on why they would be "non-issues". I must admit, that currently I am on the = fence with regards to which WLAN AP architecture ("lightweight AP" vs. "heavyweight AP") fills my needs the most (speaking from a enterprise network engineering point of view). I understand the concerns with the management and control of the potentially large number of "heavyweight = APs" that could be deployed to satisfy requirements, but I also have these concerns that centralizing everything will have. I am very curious on hearing your thoughts on this.... Thanks and Regards,=20 Austin --__--__-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap End of Capwap Digest ------_=_NextPart_001_01C3C986.F18BE373 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IjQSAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAJgAAAFJFOiBDYXB3YXAgZGlnZXN0 LCBWb2wgMSAjMTM0IC0gMSBtc2cAmwoBBYADAA4AAADTBwwAFwAKADsAMwACAHcBASCAAwAOAAAA 0wcMABcACgA7ADMAAgB3AQEJgAEAIQAAADBFRDIzMTBGRTQ1M0MzNEE4NTlENUQzMzg1Mjc2MTNG ABAHAQOQBgAcGgAANwAAAAMAJgAAAAAAAwA2AAAAAABAADkAc+OL8YbJwwEeAD0AAQAAAAUAAABS RTogAAAAAAIBRwABAAAAOgAAAGM9dXM7YT0gO3A9QWlyZmxvd05ldHdvcmtzO2w9RVhDSEFOR0Ux LTAzMTIyMzE4NTk1MVotMzUzNgAAAB4ASQABAAAAIgAAAENhcHdhcCBkaWdlc3QsIFZvbCAxICMx MzQgLSAxIG1zZwAAAEAATgAAvTqWfsnDAR4AWgABAAAAHAAAAGNhcHdhcC1yZXF1ZXN0QGZyYXNj b25lLmNvbQACAVsAAQAAAFUAAAAAAAAAgSsfpL6jEBmdbgDdAQ9UAgAAAABjYXB3YXAtcmVxdWVz dEBmcmFzY29uZS5jb20AU01UUABjYXB3YXAtcmVxdWVzdEBmcmFzY29uZS5jb20AAAAAAgFcAAEA AAAhAAAAU01UUDpDQVBXQVAtUkVRVUVTVEBGUkFTQ09ORS5DT00AAAAAHgBdAAEAAAAcAAAAY2Fw d2FwLXJlcXVlc3RAZnJhc2NvbmUuY29tAAIBXgABAAAAVQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QC AAAAAGNhcHdhcC1yZXF1ZXN0QGZyYXNjb25lLmNvbQBTTVRQAGNhcHdhcC1yZXF1ZXN0QGZyYXNj b25lLmNvbQAAAAACAV8AAQAAACEAAABTTVRQOkNBUFdBUC1SRVFVRVNUQEZSQVNDT05FLkNPTQAA AAAeAGYAAQAAAAUAAABTTVRQAAAAAB4AZwABAAAAHAAAAGNhcHdhcC1yZXF1ZXN0QGZyYXNjb25l LmNvbQAeAGgAAQAAAAUAAABTTVRQAAAAAB4AaQABAAAAHAAAAGNhcHdhcC1yZXF1ZXN0QGZyYXNj b25lLmNvbQAeAHAAAQAAACIAAABDYXB3YXAgZGlnZXN0LCBWb2wgMSAjMTM0IC0gMSBtc2cAAAAC AXEAAQAAABsAAAABw8l+vp6uQITkQFpLTI+57cvaqMcRAAHjZOgAHgB0AAEAAAAUAAAAY2Fwd2Fw QGZyYXNjb25lLmNvbQAeABoMAQAAAAsAAABIYXJyeSBCaW1zAAAeAB0OAQAAACIAAABDYXB3YXAg ZGlnZXN0LCBWb2wgMSAjMTM0IC0gMSBtc2cAAAACAQkQAQAAAP0SAAD5EgAACCYAAExaRnX1GSxf AwAKAHJjcGcxMjXiMgNDdGV4BUEBAwH3/wqAAqQD5AcTAoAP8wBQBFY/CFUHshElDlEDAQIAY2jh CsBzZXQyBgAGwxEl9jMERhO3MBIsETMI7wn3tjsYHw4wNREiDGBjAFAzCwkBZDM2FlALpiBGQQNh IG15IHAEkHMBHXBjdGl2ZSwgiHRoZRDAUiBjA5E7HXECEHIdIAdAAyBvZrEeM3RyYQEgDeAgCfAe ZwuACeAFECCwIGZ1Xm4d0QIgBCAeQGEFQHmXCGAfYBggIBewb2shI98FsB4gAJAhgB5gaQVAE+AV BCBnF7BiB0Aga25ob3dsCYBnHmAfsXd/HlAioR9yA/AYICUgBBFM9EFOHqBsCJACMAQgIpSDHrAO sGQuICBIJQB+ZR4AI3ECIB5gHrIHQHfsYXkEIAEAdgQAJfEjkP0j0G4KwCGwI/ADoCWwDeBmaB4z CrBjaxQgHTB1vmwd4AtQDeAiICGxIBggNHF1JmFkHjArAHN1JHBwF8EgYh6wc3T8L20uoivlBCAF oCxwLcB2byjBJbFsHSAeQiDgdPp3BbBrHiABAB2gJAAl9H8BERfBJ4EFQCAvILAoUUGtBUBzA3Ar 0W8LgHQeJH8AcSigBcAEAC3SLiAJwGH3AQAt0ipwZi6xEoEx0B1wPyNCIkIFwDEVIsALgGtzLi4K ogqECoBICsByees5ejl0LTuiTwUQIMEksXpNJqFhJVA7ozl0HPI6ywyCHqFwKbBwLS1SB5C8dEAD UCRABaAg4C4FoN0dIFsAwAMQLeA6Pk8/WF5dOXQGYAIwPeRUClAgEQ4gLzIzQ6AwMDNZQ3AwOkPw EMBNOXRUz0BgPfk/Kzl0Q2M95EJF2HViah3BPeRDQJMp8Dc8ED7xHiBWBvBDcCAjIDEzNCAtSfFt c/5nOXpCoS3ASNVAEiEiJzCzLyEuEGJtBAEhtG85dd9FX0ZqRLZNIgTyYiVhBcDfIXBQ6CogKnAe QlcFsDABxFdpNsFXZWIeICohiyQAThloAkBwOi8u4N1AIS4/OlVTA4EvTOILgL0CEC9AhDl0I2JS cmVAEv8jgUuyKnAHgTyyJkEeQE0iV0gyUXIG4GQdUCcwgXDeJ03vQL9PjwqAWSJhHrL/GCAA0CuV HYEtIQOBPMAhIm8eQkzjIiBcHy02sE1gbrtdrzm2Vx5QLTILUHkhIf8eIAtQX8AqQQmAJAE4Q0gF /zkCHmA0oCPyNhEEYCKhHaIfBpAN4Dl0IgEDoCJSZb46EiECMCdTH7FI2y5rwNYiOo9FAWQpwCcE IEUQ+THQY3M94DmJKGBDcChQNlMBkC0DRCIgKnBJbe8stwQgKyEqcEMnUTMgJzDqegmAL0NAbiDg JSEm0HBXQVBQBdAEcQMgKD06MHceQAWwIOAeIEF1CVciIEo/8ElUXSn5OuxfX3WUOXo8hWoQGvMP PYVp0HNPdFUiIDxhsXQDLmouE+B4hUBo4Ncd4AnACGBwP7I+RLdp0PYnTs8DcCd54Xzve/dvsatq AXLQbh4gMhRARAWQA4CQQ/M2OjI3OjPyOEpgMDVD8EesP/BI1P5dby9wP3FPcls5eyaAF7DzH2Jr wS5JH2AdIDMgHkE/OHIH4C3hHkA2EUzjYnX/JBIeAC6ACeEjkCTwbbEhMf8KwAhgS8EfITl0KnAn MAJA/yUgK0KN4YViKXECQFjQBTHPLeElUAVAHrB1Z1TwNmH/LdMdcC2xWjNhUygRLsA5dL8qASaA bbAHgCdiKyFXJuLvMaE8EI6CWXFyE9Ax4R3Q/whwKTEhwVNhiZEhsjRCAYB/EoFfsUlAILA5dDSj H7VwvxggWUGD1CeBS8EeQmMIcN8YIAIwKfAzISdxKGi2H3G7OnWZ8y2a4XigIXAtFBBziWAkkHkt KaEuMIHwM/4pHiCJQItTNKM/cSPQBKD/J4EG4IshHkIHcCvxnzM5dP+fkSUgkrIs9B+xKnCTQjGD /5PBLbGMhXJzHiAxQC/yi1P/LSGgB4yxBJBlgzEGKFGJQ/94oIwzl1YiUgDAHVBRUQGg/43hNvI1 tJdVOXQdQV1TlbP/a8AkQC4QY0GnCB1BnmeLWNuVFqKSbJaCOnUolAIuQP9Ngahii1Mk8C5xrTML YAaBfwiQLcArIR5CmfMfYGqjef0UIClrwQWxBpAeMjp1r9z/NrCZ8CahLbGygR4hKwCvR/8OwAtQ aHKvREyBHeAHkS3hf5ghBvAeAGk2WNAoUErrb/8eICUgLEEeYI+CikMw8Ysg35jUBuFqlCQAiQIu rBo3Yb8dIANSn/ieYwUxH7EiKqH3heShJx5CYgUQJUBlox8hfymwCyBlo3oQHkECMCzVLPc5dAnw BQB5BTDDEpPzLkB/LMEdUAnwHyEj0JKyvKMi/yhRZQCOMrGIJDMpEh5Ae5H/j/A5dAnBIiElICCw HkA2I/8BAWeSmTMCIQNgAyCUAmDD+6DTH6YiJzCP8SigzIIQwPxQIsNFiUBRUCcxi3EsYP8rgSQy i6MlILHxnxJaMxgg/mcLETYjmTMnMynwhFJpof5kTJKNJZkFoJKE1x/jhoP/ISIkMqRUUaGlPrIS KKAfgf8kQLOVJQAeoASQAZArIS9V/i8/MQeCIpLR4y2xUnbUWPcHgBPRAwBzuRBCRZqJn0r/LGMv A7uzA2A2sC8DMxaLU/9JQBggHdDdAaRa1ldLwTiW/5OVJbEDoFFQYROGhlJycnP9KFFLJPFhFGHm cnQesqgi/6FhKMELYOCkbbChcwOgDsBbVxMhQEwUQAWxTEQQKPtbAx5AKTEHuIefhh+x19K/cnTZ xGhBLqMuky/FdgrA/nmJAosSHkImcu5gI8FX9fsfxArAZ6swmbI2Eh5RPLD/NMHQNCaSKFE5ehz2 NREEkH+YEaEYsYfCQR+B0SUzFij9iUNzIwAuMCEiMDKNJR+B/8pPy1gzFepANhHDsVzQLhD/kYKx MwOR7GWWkfg31ucqYf+KAukx/PRzILMhwQbqQOlk//71IgMikrTXbnSQ99RUIJH+ZDTzmkFykJPz HoDqQF/Q3y/QwfNlgKYzKbBsOPDH9f8dMb6JnrKFYy/RZfEfoiqW/TlcUyqmSiBqEISA/EQUQPcY oCogDoBuy6OQ9wRHcyD3wQYEo1QRdSgS/VcuEBPQpW4LTSx0ZV9ykDw7ojI+6TBfQxewFBFfU+fP 4RPQETdBZxhx0FAhov0SK1KfEfg2btEVjxafFxX+XhgDGEMYZxAvET8SSBvk/nxu0ByBHKMcwhUP Hn8fj78clTugBLAcYX+V2VBr6AH/G9cazxvZHFI5egsBinMLmf81RJl7yRLQgTTBLeHN9gET/wyj DWAv0x104FHM0ItxUpD/7aS+A1KQz+AtopORIhLpUv8uwKEm6FMERc/g+MFy8SsB/40VinPtpNCx klHugLJAibP/BEHkclKQovDeJNkTMGNf0v8EQWYwOYEOoQWBa8FggKA157MwnaVEMDArzSHVE8ey ++kxZjBnJpYBMdlAqNEBBP9KACtm8dKPgddlmELPk5A0fzWD07DZQq7wqxb4sjXSc/fOwLbR8YdW k1KM8S02aTX/+raJslOwW2Dd42V0rALfZr/VNdZWP7HHcc5ypjFU8ZX/lvUKNp0RzhG3w+1Dqtop pf/OwibzXNCoULdi3RFQwYwC+c11R02jcWgB7gTYwGVg/99S2LCyQjXSAROdxJh2ARN/BfCZwVKQ aLztQ72hX7Ft/ybQixKzIT/lDML+QF0y4EH38XROFaZjYkoi0LVhoA9w36AlkPdRUA0gz+Bk0AE/ 5f/C1WtQXWDQptRYCJKD1d9m91v2MwWmMShrYAjAsMA7EfpyiQJpX6KGEilIPSw1h+9jQI/yqCDD VXhOEdlATmT/x7KvR5OVuDGLIIQCo6SoIfe1wjoiZjBy1RNrYPbQrdHvktCW9WcQ6mFzTmRc8QOR //ByZjFiFaiTPBWFY4sQjjD/lrI0MwEFYIMCNe4T3tEr8f/NEOkxK8MEQdCxBEHKAL2x//8QvEP5 UlTg3JDbMpywjjF8LUlysM/ihWIddGU2L7+b8N2AdACysAlvCnMyCtH9Cvcv6ZELnwyte5Ho4wSx /5b1DnWyEg9/Gc8i/xKvE7/3FMJ2ch10PgSwHX96vxcv/3vGdA91HxuP8sZ7z4Ifgvv/JO8l/E6y LgINYDkioaHj5/3toy9NpCvFLUaUAam1YJD/KYGZgGTwSSGMhZBimHbVNf9ao2IRddFKVSbS8VHx Uoox/w7HirTkck73MfbYlT9fQG//5apbEG0LCwHqApeVY4GFSf9icaZjO3emYNWjiMBIMNLk/5nz voYnUeBz0sQpdGOB2Rm/44Q5w+RyMfYBrdkUL5CH3zLvM/KmQTTypoF3b8E74f/S1QMl/PpgkS/x 3taH4N34/7Tl1R/pBGIUWHLgUg7G3sj7PcJq8Ckm0wsSMQSsReiU9/3B40JKl2RFELRC3+JhtR+L VgNQDsDldvaYaS5l/i4m0ARBq6DZUavWiJrykB5vTPAOqNCxPXMneCf/LQOMocPQt0DkQUUGuqBx gfnoIHgutEMOQdOw+MEqxvcC4990gLQo4zExE+nRr4L/8IFCUN7IpSUsMvJyDlHJ0N/xQqlWmAHu g06CSYC0q6D8bidJMmkgucEA9qnGTmH/4GDCYGOB9zE7gsakBEFnJP+dIOgRI7Bs8ELy6MAG5u4i /2OA+CEz8d1mVmdgUqUlW4DaL1uBTc9AygBr0JLZAe8r4QykBaCECkGpZVITr3Pv6KAIUOnQ5EF5 prHxVcuA/wNQCnDfwFNYnTHfYN+w07b/wIZqgC7xXfBY0O/QpQ/WKP0FoVfZorWFXgRHhOhE5nD/ 7/XccDPBVfPYcV4UkWfx8f//EAkh9xA9wuigbKEoEPXRfw0i7KL+QtuCA1I9wYC0OOAwMi4xMTGx DSHUG/4g1UQAEMA1XfCdMZZSzj//N/M2QcXl5pFfpmnKCEAF8IcFMGDRSnA2MH43w/DeYvugUZYE sAWhUG/A5HD/XjCJEEYFopXMj/cQTMb4sf9CUUcgJ3GSgFnCDTPLNGTj91jQ8NA2YTOAtOplP0FF EH/sxITkknbahu4A8eEnMG3/2uBgwOaC+bLHI/bS9lK2Zf/gi6rD/eC8Optxh6n6IFjg+m5s/Fdw UToSTMH4wFXz/2KyMLMIxlDia0IGIJJBA8P/jcJYwP8AWSDNoXBSa5X8lP8DJfgSWNAw4YTRLOJK cKpT32xS/oRvQizRXxBvDdCjEP9Q4n8RczHmgYC03hJHdWnB/4sh5oLX4K+QsOD5gVrA1iL9qnBt N9Xah2CRjxA9wrX7/wpADdFJwApwRhXfT82AWTH70pvVQ1GiJVDhSNGz1E1Fv10w5vJrUCzwdzBe AHJiYpV14GPw5iKiMXZ56hD7XCM10SI1Bkb/gLTQ916VH4bgPXOFSmzQDeJHVlL/SPGKI4kR/7NI Ew3hJtBgke+7hacFuAgBx0JisakDUQ/+bUxg69BdMUxycRGp0Wnh3mw0hVIioDGECk82UV8P8+R0 KxNoeafQucDup1ky/74S8dQ9wg7ViTkN905k4QH+b/RwWMDoQquQctCG4Jrl/5JxLzFjgUGKRCDK MC8w6ZL3cFGOZS2hcFaUUbGh1Cbz/xd/3RiugWTwRUErIEphaof/z8WpsC7wYSBUcXLxPXdrUP9c MOqhbiAssGCE11dnJL30v3CVKKOY9VjQnVJzEiI7sPedEGrBAwQiWTFTEm3wsuD+eRtTqOA9wdvy CbMB8lkwv1+WgLTktHMBWkRYM0nKdLtlAc6JP20b5oJKYXk6EJ8N0UJQ6kpjga+Abi3Gw99idTUV 2uCq4U4BdXcQVeN/GngEM6niG1DXx3LxZeFm/9wA52StUfe0vEIw4cohS0H/YVBy8FFTX2IS4DHH 6aHalv4iLxgmgKBBQpGc0zuwFpH/+VSKMGFymcGgk8wFYVCp8X9SaXcy3BJosbbQksBwcFf7WwJw 0nJCwH+QpyGKMBKgPCgiVFBcMQMHA6B2c/ttBQKtIrSwkrDtsFvxt/CfrUJG1GqAifHgcmFrccL7 iFUzMnIy8KpwXIUZZvua//AESmGPMPRgwCKXl6FGqdX/qqFwVRWuDoqVNV3xYwHKMPvhA+MUbubT aYICrzHG+XqfvJDHgcfwivR3YXNmt/D9dzBxZUBdIpZjL9RZsGXh/wPmChZIh/lU4YZxwu5Ta0L/ MWJkcRJyk/yWwu5jOgHKQP9s0AjSojH8Ay2h6rJ4kFwx/8vlqnAT0oQK15DTYMRR02L+Ujx0qODF i4nhccCECoC0+XaAX19fFIQKXzBgj2Gf+2JZgLRDBIAn8AFASfAEwe9qUe3AiMBjakCa4bLQ2cGW LuZxKWV0wuA6L4fg32RB/eBl2WdDSfEvZLJxwM/6gGyBY+Jd/wpFcRGNAZ1jxUQmQMnRae8KfW1w AAAAHgA1EAEAAABHAAAAPEI3QkFGNkNEMzY4MzRFNDc4M0VFRjk2QUZFODlFNjFGMDFBQ0QxQGV4 Y2hhbmdlMS5haXJmbG93bmV0d29ya3MuY29tPgAAHgBHEAEAAAAPAAAAbWVzc2FnZS9yZmM4MjIA AAsA8hABAAAAHwDzEAEAAABcAAAAUgBFACUAMwBBACAAQwBhAHAAdwBhAHAAIABkAGkAZwBlAHMA dAAsACAAVgBvAGwAIAAxACAAJQAyADMAMQAzADQAIAAtACAAMQAgAG0AcwBnAC4ARQBNAEwAAAAL APYQAAAAAEAABzA93ypMhsnDAUAACDByCpPxhsnDAQMA3j/kBAAAAwDxPwkAAAAeAPg/AQAAAAsA AABIYXJyeSBCaW1zAAACAfk/AQAAAGUAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089 QUlSRkxPV05FVFdPUktTL09VPUZJUlNUIEFETUlOSVNUUkFUSVZFIEdST1VQL0NOPVJFQ0lQSUVO VFMvQ049SEFSUllCAAAAAB4A+j8BAAAAFQAAAFN5c3RlbSBBZG1pbmlzdHJhdG9yAAAAAAIB+z8B AAAAHgAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAuAAAAAwD9P+QEAAADABlAAAAAAAMA GkAAAAAAAwAdQAAAAAADAB5AAAAAAB4AMEABAAAABwAAAEhBUlJZQgAAHgAxQAEAAAAHAAAASEFS UllCAAAeADJAAQAAABwAAABjYXB3YXAtcmVxdWVzdEBmcmFzY29uZS5jb20AHgAzQAEAAAAcAAAA Y2Fwd2FwLXJlcXVlc3RAZnJhc2NvbmUuY29tAB4AOEABAAAABwAAAEhBUlJZQgAAHgA5QAEAAAAC AAAALgAAAAsAKQAAAAAACwAjAAAAAAADAAYQ0AIrJQMABxBwGgAAAwAQEAAAAAADABEQAAAAAB4A CBABAAAAZQAAAEZST01NWVBFUlNQRUNUSVZFLFRIRUFSQ0FOUEVSRk9STUFMTE9GVEhFVFJBRkZJ Q0VOR0lORUVSSU5HRlVOQ1RJT05TVEhBVFlPVUFSRUxPT0tJTkdGT1IsU0lOQ0VJVEhBU0cAAAAA AgF/AAEAAABHAAAAPEI3QkFGNkNEMzY4MzRFNDc4M0VFRjk2QUZFODlFNjFGMDFBQ0QxQGV4Y2hh bmdlMS5haXJmbG93bmV0d29ya3MuY29tPgAAieY= ------_=_NextPart_001_01C3C986.F18BE373-- From austin.j.hawthorne@citigroup.com Tue Dec 23 19:50:17 2003 From: austin.j.hawthorne@citigroup.com (Hawthorne, Austin J [IT]) Date: Tue, 23 Dec 2003 14:50:17 -0500 Subject: [Capwap] RE: Capwap digest, Vol 1 #134 - 1 msg Message-ID: <159DF57E62CDD5118FCA0002A51352B00C5074A1@EXCHNY36.ny.ssmb.com> Harry,=20 Thanks for the reply.... The AR could perform all these functions, but they are transparent to = the underlying network in which the traffic is tunneled over to get to = the AR....so it cannot implement these capabilities to "traffic = engineer" the underlying network. I guess this is really a matter of perspective on the design principles = involved in designing a network to use LWAPP for WLAN traffic. In most = cases the AP will be thought of as just another access medium (typically = an alternative to the wired FastE port) into the network. In the LWAPP = design the destination networks (for station traffic) could possibly be = the same networks that are being used as transport for the tunneled = traffic. Also, their is no local switching at the AP for stations that = reside on the same AP. If I can make an analogy, the LWAPP design (hub = and spoke, tunneled traffic, etc...) as it stands today looks more of a = remote access solution such as IPSEC VPN. But the difference is the = solution being sought from WLAN and its associated design = characteristics...for example, with IPSEC VPN I would not typically use = it as a solution for connecting LAN traffic between two or more = 'remote-sites' with the same L3 subnet (because of the bandwidth = required, traffic patterns, etc...), but this is what is being defined = with LWAPP (each AP analogous to the 'remote-site' and having stations = on the same L3 subnet). I don't believe it is a case of devising the one-off scenario where this = is an issue, it is a matter of realizing the different network = topologies where LWAPP/WLAN will be deployed and ensuring the protocol = compliments their respective challenges. It appears to me that the = LWAPP defined so far would be adequate in a hot-spot/hotelling type = application where traffic can be tunneled to a centralized point and = forwarded onto the internet after that point....but in an = enterprise/campus environment, where WiFi access is being looked at as = an alternative to wired access for laptops (among other applications), = the defined protocol so far holds many inefficiencies (as I described = earlier) because of the traffic patterns involved with the applications = being used at the laptop. The enterprise/campus environment has the = same management and control concerns for the AP, but also has these = traffic pattern concerns as well. It would be better served to have the = station traffic placed onto the underlying network natively rather than = tunneled. Austin -----Original Message----- From: Harry Bims [mailto:hbims@airflownetworks.com] Sent: Tuesday, December 23, 2003 2:00 PM To: capwap@frascone.com Subject: RE: Capwap digest, Vol 1 #134 - 1 msg >From my perspective, the AR can perform all of the traffic engineering = functions that you are looking for, since it has global knowledge of = where all wireless LAN clients are located. However, one can always = devise a scenario in which the packet multiplication required to support = bcast/mcast packets could overwhelm the network, despite all efforts at = traffic engineering. At some point, the answer is to upgrade to a = faster pipe for your network links. Harry -----Original Message----- From: capwap-request@frascone.com [mailto:capwap-request@frascone.com] Sent: Tue 12/23/2003 10:00 AM To: capwap@frascone.com Cc:=09 Subject: Capwap digest, Vol 1 #134 - 1 msg Send Capwap mailing list submissions to capwap@frascone.com To subscribe or unsubscribe via the World Wide Web, visit http://mail.frascone.com/mailman/listinfo/capwap or, via email, send a message with subject or body 'help' to capwap-request@frascone.com You can reach the person managing the list at capwap-admin@frascone.com When replying, please edit your Subject line so it is more specific than "Re: Contents of Capwap digest..." Today's Topics: 1. Station Data Implications in a Centralized/Tunneled LWAPP Model = (Hawthorne, Austin J [IT]) --__--__-- Message: 1 From: "Hawthorne, Austin J [IT]" To: "'capwap@frascone.com'" Date: Mon, 22 Dec 2003 16:27:38 -0500 Subject: [Capwap] Station Data Implications in a Centralized/Tunneled = LWAPP Model Hello all....I am rather new to this list but have been snooping around = for a little while in an attempt to get caught up to speed with the latest developments in WLAN design and architecture considerations. After = reading some of the presentations and the current drafts (specifically draft-calhoun-seamoby-lwapp-03), I have some concerns about the impact = the implementation of a WLAN, designed around LWAPP, would have on the underlying network. I am hoping some of you may be able to answer some = of my questions...assuming some of my concerns have been considered already (and possible have not been clarified in the draft as of yet)...or if = they have not been addressed yet, to possible explore possibilities to = resolve them.=20 So, let me get to the nuts and bolts of it.....my concerns stem from the concept of "centralization of the bridging, forwarding, authentication, encryption, and policy enforcement.....". While the draft has gone = through great lengths to define the control and management of the "lightweight = AP", I believe much has been left out with regards to the client data = handling and the implications the tunneling has on the underlying network as well = as how certain packets/frames are handled via the tunneling mechanism. Specifically the impact multicast and broadcast traffic have directly on = the network and network design when being tunneled via LWAPP. Knowing that LWAPP can be an overlay on top of an existing L2 or L3 (or both) = network, the impact of how LWAPP handles mcast/bcast could vary....but the = relevance of the argument is the same regardless. =20 >From my interpretation of the draft, all client traffic (I am skipping = over all the control and management traffic) is encapsulated in an LWAPP = header as well as a new L2 header (if bridging) or L3 header that are addressed with the tunnel endpoints (AP and AR) accordingly. I walk through my concerns in a couple of scenarios. Scenario #1: In an L2 environment with the AP and AR (bridging AR) = situated as such: Multiple_AP<---->L2_Closet_Switch<---->L2_Aggregation_Switch<---->Router ^ ^ ^ ^ =20 Multiple_AP<---->L2_Closet_Switch<----------| | | | | |--AR--| Desktop<-------->L2_Closet_Switch<-------------| In this environment, the current draft lends me to believe that the AR = could receive a bcast from a wired desktop or station off an AP and will = deliver this bcast to every other AP via a unicast frame to each AP = separately....so if I have 100+ APs on one L2 segment, that means that 1 bcast frame gets sent out up to 100+ times (assuming all APs share the same VLAN for = station traffic) thereby multiplying my traffic on the network by as much. The = same scenario applies to mcast...assuming the AR has the capability to snoop IGMP, it could keep track of APs that have stations that want a specific mcast stream, but if multiple APs require the stream, I am back to the = issue with the bandwidth multiplication due to the tunneling of station = traffic to each AP. (disclaimer....i realize that the same VLAN for 100+ APs might = be extreme, but one possible design solution would be to put users on = different subnets, but extend these subnets to all APs in a building...so that a = user would roam at L2 from AP to AP instead of introducing mobile-IP within a building/campus). Scenario #2: In an L2/L3 environment with the AP and AR (routing AR) situated as such: Multiple_AP<---->L2_Closet_Switch<---->L2_Aggregation_Switch<---->Router<= --- >AR ^ =20 Multiple_AP<---->L2_Closet_Switch<----------| =20 =20 In this environment if an AR gets a tunneled bcast/mcast from a station = and must turn it around to stations on the same subset of APs, this is = turned around via multiple unicast packets thereby multiplying my traffic on = that LAN. In both of these environments, I am assuming I understood the draft correctly and that these frames are being sent via unicast addressed frames/packets to each AP separately. If I am wrong and the tunnel = header uses broadcast/multicast addresses on the underlying L2 subnet (directed broadcast for IP), then another concern exists when APs that do not have stations needing that traffic (i.e., AP does not have a station = associated to VLAN 'x' or subscribed to mcast group x.x.x.x) still receive the = traffic (whether or not they broadcast on the wireless side is another = story...but I don't consider that a concern, because I assume the AP would drop it). = This could severely impact station tput on the 10/100M links to/from the AP.=20 Another issue not explored yet is the generic bandwidth restrictions = this model places on the underlying network. We have the possibility of an = AP operating on possibly multiple radios (for example, and AP has a channel = for 802.11a and a channel for 802.11g). This presents the possibility that = one AP could be introducing upwards of 60~70Mbps to the AR. Provisioning = the underlying network (specifically a centralized AR model in a large L3 network) to handle this traffic could become cumbersome and not = efficient (specifically when we consider the bcast/mcast again). Without spelling out every scenario, I think my point is clear. With a LWAPP tunnel overlay on top of existing/new L2/L3 topologies, I loss = some visibility into some protocol mechanisms that could be used for traffic engineering the underlying network....for example, 802.1Q header, IGMP = group membership reports, etc. With "heavyweight APs" I have the capability = to possibly design a VLAN environment using GVRP, turn on IGMP snooping, = use directed broadcasts, etc. But then I am back to the management and = control issue. =20 One solution would be to have a hybrid scenario....use LWAPP for control = and management, but allow client data frames traverse the network natively = with an option to tunnel the client data frames to the AR (in case of = mobile-IP or dedicated VLAN for higher risk users). This would cause the AP to be classed as "middle-weight"...the encryption, forwarding, etc...would be handled at the AP. Is this a possibility? Some of you may consider these non-issues, but I have been struggling = with the concepts presented so far and need some constructive feedback on why they would be "non-issues". I must admit, that currently I am on the = fence with regards to which WLAN AP architecture ("lightweight AP" vs. "heavyweight AP") fills my needs the most (speaking from a enterprise network engineering point of view). I understand the concerns with the management and control of the potentially large number of "heavyweight = APs" that could be deployed to satisfy requirements, but I also have these concerns that centralizing everything will have. I am very curious on hearing your thoughts on this.... Thanks and Regards,=20 Austin --__--__-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap End of Capwap Digest From bwijnen@lucent.com Tue Dec 23 19:57:29 2003 From: bwijnen@lucent.com (Wijnen, Bert (Bert)) Date: Tue, 23 Dec 2003 20:57:29 +0100 Subject: [Capwap] FW: WG Review: Control and Provisioning of Wireless Access Points (capwap) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155033D2CC2@nl0006exch001u.nl.lucent.com> In case any one is not subscribed to IETF-Announce! Thanks, Bert -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: maandag 22 december 2003 19:28 Cc: new-work@ietf.org Subject: WG Review: Control and Provisioning of Wireless Access Points (capwap) A new IETF working group has been proposed in the Operations and Management Area. The IESG has not made any determination as yet. The following description was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by January 7th, 2004. Control and Provisioning of Wireless Access Points (capwap) ----------------------------------------------------------- Current Status: Proposed Working Group Mailing Lists: General Discussion: capwap@frascone.com To Subscribe: http://mail.frascone.com/mailman/listinfo/capwap Archive: http://mail.frascone.com/pipermail/capwap/ Description: As the size and complexity of IEEE 802.11 wireless networks has increased, problems in the deployment, management, and usability of these networks have become evident. Access points (APs) typically require complex management at the IP level. As the number of APs increases, the number of devices requiring complex management increases, in some cases, doubling the number of IP devices requiring management in a provider's network. In addition, because APs have no visibility beyond their own cell, a variety of problems ensue in large scale 802.11 networks. Load balancing between APs, dead cell detection, and correlating patterns of usage between APs to detect attacks are difficult to impossible. Finally, because each AP acts as its own Network Access Server (NAS), a network provider is faced with the prospect of moving from a situation where the NAS is a few machines with dialup access in a machine room to a situation where hundreds or perhaps thousands of devices scattered across a wide geographic area have NAS functionality. Maintaining security on such a wide collection of devices is a difficult challenge. In recent attempts to solve these problems, various vendors have introduced products that redistribute the functionality of 802.11 APs in various ways. However, because the 802.11 access network functional architecture is incompletely specified, the network interfaces between network entities in different vendors' products are defined in incompatible ways. As a result, the protocols between the network entities in different products are not interoperable. Charter: As a first step, the CAPWAP Working Group will develop a problem statement and network architecture taxonomy describing the current set of approaches to providing more support for scalable 802.11 access networks. The problem statement will describe, at a high level, what the deployment, management, and usability concerns are with 802.11 networks based on the traditional autonomous AP architecture, and will link those concerns to specific technical aspects of the autonomous AP architecture. The network architecture taxonomy will: - Describe the current set of approaches (including the traditional autonomous AP architecture) to partitioning 802.11 access network functionality between network entities, - List what the interfaces between the network entities are in each approach, - At a functional level, describe what the protocols on the interfaces between the network entites in each approach do, - Describe the advantages and disadvantages of each approach for scalable 802.11 access network deployment and management. Additionally, the architecture document will contain a threat analysis that describes the security threats involved in each network architectural approach. Specific Working Group deliverables are: - A problem statement document, - A network architecture taxonomy document including threat analysis. Specific non-goals of this work are: - Any work requiring revising the 802.11 access network functional architecture The CAPWAP WG will maintain a close working liaison with relevant working groups in IEEE 802.11 and IEEE 802.1. Working Group documents will be sent to an expert review board for review prior to submission to the IESG. In order to facilitate quick completion of this work, the Working Group charter will expire 9 months after it is approved by the IESG, at which time the Working Group can either petition the IESG for a continuation or recharter for further work on the interoperability problem. Goals and Milestones: Feb 2004: Last call for problem statement draft. Mar 2004: Discuss last call comments for problem statement at IETF 59. Mar 2004: Last Call for architecture description document. Apr 2004: Submit problem statement to IESG for publication approval. May 2004: Architecture document to expert review. Aug 2004: Discuss last call and expert review comments at IETF 60. Aug 2004: Submit architecture document to IESG for publication approval. Sep 2004: Close WG or Re-charter From mmani@avaya.com Mon Dec 29 08:50:23 2003 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Mon, 29 Dec 2003 01:50:23 -0700 Subject: [Capwap] Station Data Implications in a Centralized/Tunneled LWAPP Model Message-ID: Austin, Your questions are sort of centered around the LWAPP draft. The CAPWAP list has since then progressed towards focusing on general architectural taxonomy beyond what goes to make lightweight APs. This consideration that allows for a (L2 or L3) network cloud between the AP and AR is another case in point to take a bottom-up approach to viewing the possible architectural options out there. There's an architecture draft that explores the taxonomy. While the initial version is not comprehensive - the next revision aims to be. I would also suggest you refer to the current proposed charter (refer to mailing list archive or the posting Bert did after yours) and view the draft you are referring to in that light. The perspective has gone beyond looking at 'lightweight AP' towards a CAPWAP model. Some architectures fit varied administrative/network-topology requirements better than others. In short - while it is useful to provide for client data traffic to be secured and forwarded to AC (to enable such traffic to be handled based on policies) I do not see this as a required approach by default. The choice of (collectively/selectively) tunneling client data would be governed by configuration and policy enforced at the AP and AC. This, again, would be influenced by architecture indirectly (ARCH1, ARCH2) and AP-AC topology directly. Regards, -mani > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Hawthorne, Austin J [IT] > Sent: Monday, December 22, 2003 1:28 PM > To: 'capwap@frascone.com' > Subject: [Capwap] Station Data Implications in a Centralized/Tunneled > LWAPP Model >=20 > Hello all....I am rather new to this list but have been snooping around > for > a little while in an attempt to get caught up to speed with the latest > developments in WLAN design and architecture considerations. After > reading > some of the presentations and the current drafts (specifically > draft-calhoun-seamoby-lwapp-03), I have some concerns about the impact the > implementation of a WLAN, designed around LWAPP, would have on the > underlying network. I am hoping some of you may be able to answer some of > my questions...assuming some of my concerns have been considered already > (and possible have not been clarified in the draft as of yet)...or if they > have not been addressed yet, to possible explore possibilities to resolve > them. >=20 > So, let me get to the nuts and bolts of it.....my concerns stem from the > concept of "centralization of the bridging, forwarding, authentication, > encryption, and policy enforcement.....". While the draft has gone > through > great lengths to define the control and management of the "lightweight > AP", > I believe much has been left out with regards to the client data handling > and the implications the tunneling has on the underlying network as well > as > how certain packets/frames are handled via the tunneling mechanism. > Specifically the impact multicast and broadcast traffic have directly on > the > network and network design when being tunneled via LWAPP. Knowing that > LWAPP can be an overlay on top of an existing L2 or L3 (or both) network, > the impact of how LWAPP handles mcast/bcast could vary....but the > relevance > of the argument is the same regardless. >=20 > From my interpretation of the draft, all client traffic (I am skipping > over > all the control and management traffic) is encapsulated in an LWAPP header > as well as a new L2 header (if bridging) or L3 header that are addressed > with the tunnel endpoints (AP and AR) accordingly. I walk through my > concerns in a couple of scenarios. >=20 > Scenario #1: In an L2 environment with the AP and AR (bridging AR) > situated > as such: >=20 > Multiple_AP<---->L2_Closet_Switch<---->L2_Aggregation_Switch<---->Router > ^ ^ ^ ^ > Multiple_AP<---->L2_Closet_Switch<----------| | | | > | |--AR--| > Desktop<-------->L2_Closet_Switch<-------------| >=20 > In this environment, the current draft lends me to believe that the AR > could > receive a bcast from a wired desktop or station off an AP and will deliver > this bcast to every other AP via a unicast frame to each AP > separately....so > if I have 100+ APs on one L2 segment, that means that 1 bcast frame gets > sent out up to 100+ times (assuming all APs share the same VLAN for > station > traffic) thereby multiplying my traffic on the network by as much. The > same > scenario applies to mcast...assuming the AR has the capability to snoop > IGMP, it could keep track of APs that have stations that want a specific > mcast stream, but if multiple APs require the stream, I am back to the > issue > with the bandwidth multiplication due to the tunneling of station traffic > to > each AP. (disclaimer....i realize that the same VLAN for 100+ APs might > be > extreme, but one possible design solution would be to put users on > different > subnets, but extend these subnets to all APs in a building...so that a > user > would roam at L2 from AP to AP instead of introducing mobile-IP within a > building/campus). >=20 > Scenario #2: In an L2/L3 environment with the AP and AR (routing AR) > situated as such: >=20 > Multiple_AP<---->L2_Closet_Switch<---->L2_Aggregation_Switch<---->Router <- > -- > >AR > ^ > Multiple_AP<---->L2_Closet_Switch<----------| >=20 >=20 > In this environment if an AR gets a tunneled bcast/mcast from a station > and > must turn it around to stations on the same subset of APs, this is turned > around via multiple unicast packets thereby multiplying my traffic on that > LAN. >=20 > In both of these environments, I am assuming I understood the draft > correctly and that these frames are being sent via unicast addressed > frames/packets to each AP separately. If I am wrong and the tunnel header > uses broadcast/multicast addresses on the underlying L2 subnet (directed > broadcast for IP), then another concern exists when APs that do not have > stations needing that traffic (i.e., AP does not have a station associated > to VLAN 'x' or subscribed to mcast group x.x.x.x) still receive the > traffic > (whether or not they broadcast on the wireless side is another story...but > I > don't consider that a concern, because I assume the AP would drop it). > This > could severely impact station tput on the 10/100M links to/from the AP. >=20 > Another issue not explored yet is the generic bandwidth restrictions this > model places on the underlying network. We have the possibility of an AP > operating on possibly multiple radios (for example, and AP has a channel > for > 802.11a and a channel for 802.11g). This presents the possibility that > one > AP could be introducing upwards of 60~70Mbps to the AR. Provisioning the > underlying network (specifically a centralized AR model in a large L3 > network) to handle this traffic could become cumbersome and not efficient > (specifically when we consider the bcast/mcast again). >=20 > Without spelling out every scenario, I think my point is clear. With a > LWAPP tunnel overlay on top of existing/new L2/L3 topologies, I loss some > visibility into some protocol mechanisms that could be used for traffic > engineering the underlying network....for example, 802.1Q header, IGMP > group > membership reports, etc. With "heavyweight APs" I have the capability to > possibly design a VLAN environment using GVRP, turn on IGMP snooping, use > directed broadcasts, etc. But then I am back to the management and > control > issue. >=20 > One solution would be to have a hybrid scenario....use LWAPP for control > and > management, but allow client data frames traverse the network natively > with > an option to tunnel the client data frames to the AR (in case of mobile-IP > or dedicated VLAN for higher risk users). This would cause the AP to be > classed as "middle-weight"...the encryption, forwarding, etc...would be > handled at the AP. Is this a possibility? >=20 > Some of you may consider these non-issues, but I have been struggling with > the concepts presented so far and need some constructive feedback on why > they would be "non-issues". I must admit, that currently I am on the > fence > with regards to which WLAN AP architecture ("lightweight AP" vs. > "heavyweight AP") fills my needs the most (speaking from a enterprise > network engineering point of view). I understand the concerns with the > management and control of the potentially large number of "heavyweight > APs" > that could be deployed to satisfy requirements, but I also have these > concerns that centralizing everything will have. >=20 > I am very curious on hearing your thoughts on this.... >=20 > Thanks and Regards, >=20 > Austin > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap From pekkas@netcore.fi Mon Dec 22 21:23:18 2003 From: pekkas@netcore.fi (Pekka Savola) Date: Mon, 22 Dec 2003 23:23:18 +0200 (EET) Subject: [Capwap] Re: WG Review: Control and Provisioning of Wireless Access Points (capwap) In-Reply-To: <200312221828.NAA28933@ietf.org> Message-ID: On Mon, 22 Dec 2003, The IESG wrote: > In recent attempts to solve these problems, various vendors have > introduced products that redistribute the functionality of 802.11 > APs in various ways. However, because the 802.11 access network > functional architecture is incompletely specified, the network > interfaces between network entities in different vendors' > products are defined in incompatible ways. As a result, the > protocols between the network entities in different products are > not interoperable. The main thing I'm concerned at this point is whether these vendors may have claimed IPR on these protocols, and whether this might interfere with the work of this potential WG. Has this been discussed? (mainly editorial comment): > Finally, because each AP acts as its own Network Access Server > (NAS), a network provider is faced with the prospect of moving s/acts/may act/ ? (why would every AP need to be a NAS?) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From pcalhoun@airespace.com Wed Dec 31 14:58:11 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Wed, 31 Dec 2003 06:58:11 -0800 Subject: [Capwap] Re: WG Review: Control and Provisioning of Wireless Access Points (capwap) Message-ID: <55749BC69138654EBBC4C50BA4F55610ADC380@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3CFAF.1D6A3533 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >> In recent attempts to solve these problems, various vendors have = >> introduced products that redistribute the functionality of = 802.11 >> APs in various ways. However, because the 802.11 access network >> functional architecture is incompletely specified, the network >> interfaces between network entities in different vendors' >> products are defined in incompatible ways. As a result, the >> protocols between the network entities in different products are >> not interoperable. > > The main thing I'm concerned at this point is whether these vendors=20 > may have claimed IPR on these protocols, and whether this might=20 > interfere with the work of this potential WG. > > Has this been discussed? http://www.ietf.org/ietf/IPR/airespace-ipr-draft-calhoun-seamoby-lwapp.tx= t > (mainly editorial comment): >> Finally, because each AP acts as its own Network Access Server >> (NAS), a network provider is faced with the prospect of moving > > s/acts/may act/ ? (why would every AP need to be a NAS?) That's just reality. APs do 802.1X, which means that they have to have=20 RADIUS configuration. They need to be configured, which means (some) = have SNMP. Since they are an access device, they also have access policies (e.g. mac/user filters). etc. For all intents and purposes, it's a full fledged NAS. Of course, it's rather scary to think that all of the security information above is now readily available in non-locked down environments (unlike = switches/routers/ NASes, RF require that they be scattered around a building and sometimes they are just attached to a wall or ceiling) - but that's another issue = :( PatC ------_=_NextPart_001_01C3CFAF.1D6A3533 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Capwap] Re: WG Review: Control and Provisioning of Wireless = Access Points (capwap)
>>      In recent = attempts to solve these problems, various vendors have
>>      introduced products that = redistribute the functionality of 802.11
>>      APs in various ways. However, = because the 802.11 access network
>>      functional architecture is = incompletely specified, the network
>>      interfaces between network = entities in different vendors'
>>      products are defined in = incompatible ways. As a result, the
>>      protocols between the network = entities in different products are
>>      not interoperable.
>
> The main thing I'm concerned at this point is whether these = vendors
> may have claimed IPR on these protocols, and whether this might
> interfere with the work of this potential WG.
>
> Has this been discussed?
http://www.ietf.org/ietf/IPR/airespace-ipr-draft-calhoun-seamo= by-lwapp.txt

> (mainly editorial comment):
>>      Finally, because each AP acts as = its own Network Access Server
>>      (NAS), a network provider is = faced with the prospect of moving
>
> s/acts/may act/ ? (why would every AP need to be a NAS?)
That's just reality. APs do 802.1X, which means that they have to = have
RADIUS configuration. They need to be configured, which means (some) = have
SNMP. Since they are an access device, they also have access = policies
(e.g. mac/user filters). etc.

For all intents and purposes, it's a full fledged NAS. Of course, = it's
rather scary to think that all of the security information above is = now
readily available in non-locked down environments (unlike = switches/routers/
NASes, RF require that they be scattered around a building and = sometimes
they are just attached to a wall or ceiling) - but that's another issue = :(

PatC

------_=_NextPart_001_01C3CFAF.1D6A3533-- From pcalhoun@airespace.com Wed Dec 31 15:28:20 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Wed, 31 Dec 2003 07:28:20 -0800 Subject: [Capwap] Re: WG Review: Control and Provisioning of Wireless Access Points (capwap) Message-ID: <55749BC69138654EBBC4C50BA4F55610ADC382@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3CFB2.B8B65D90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > On Wed, 31 Dec 2003, Pat R. Calhoun wrote: > > > The main thing I'm concerned at this point is whether these = vendors=20 > > > may have claimed IPR on these protocols, and whether this might=20 > > > interfere with the work of this potential WG. > > > > > > Has this been discussed? > > > > = http://www.ietf.org/ietf/IPR/airespace-ipr-draft-calhoun-seamoby-lwapp.tx= t >=20 > That's good enough for me, at least, but what is the situation with=20 > the other represented vendors (etc.) who already have solutions on the = > table? It might not hurt to ask each of them explicitly.. Actually there are explicit rules about disclosing any IPR already in = place see section 10 of http://www.ietf.org/rfc/rfc2026.txt. So there is no = need to ask each explicitely, it's just part of the rules if they play. > > > (mainly editorial comment): > > >> Finally, because each AP acts as its own Network Access = Server > > >> (NAS), a network provider is faced with the prospect of = moving > > > > > > s/acts/may act/ ? (why would every AP need to be a NAS?) > > > > That's just reality. APs do 802.1X, which means that they have to = have=20 > > RADIUS configuration. [...] >=20 > No, APs _may_ do 802.1X. Those which are of interest to this WG most > probably will. But you're making a generalization that every AP does. = =20 > That eats the credibility of these statements. > Take e.g. the APs deployed at the IETF meetings. I don't think there=20 > will be 802.1X used on those in a very, very long time (if ever). sigh. Even though we are not USING 802.1x at the IETF meetings, the APs that = were used did in fact support 802.1X. While you may be right that I may be = generalizing (for instance VERY low cost consumer APs may not have 802.1X support), = AP vendor now actually have to support WPA in order to get WiFi = certification.=20 Again, while WPA does have a comsumer mode (pre-shared keys), any vendor = that plans to participate in enterprise networking will include 802.1X. I would also argue that CAPWAP is really concerned with larger scale = WLAN=20 deployments so I think it is fair to assume that for the purposes of the = discussions on this list, the AP/NAS comparison is a fair statement. PatC ------_=_NextPart_001_01C3CFB2.B8B65D90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Capwap] Re: WG Review: Control and Provisioning of Wireless = Access Points (capwap)
> On Wed, 31 Dec 2003, Pat R. Calhoun wrote:
> > > The main thing I'm concerned at this point is whether = these vendors
> > > may have claimed IPR on these protocols, and whether this = might
> > > interfere with the work of this potential WG.
> > >
> > > Has this been discussed?
> >
> > http://www.ietf.org/ietf/IPR/airespace-ipr-draft-calhoun-seamo= by-lwapp.txt
>
> That's good enough for me, at least, but what is the situation = with
> the other represented vendors (etc.) who already have solutions on = the
> table? It might not hurt to ask each of them explicitly..

Actually there are explicit rules about disclosing any IPR already in = place
see section 10 of http://www.ietf.org/rfc/rfc2= 026.txt. So there is no need to
ask each explicitely, it's just part of the rules if they play.

> > > (mainly editorial comment):
> > >>      Finally, because each = AP acts as its own Network Access Server
> > >>      (NAS), a network = provider is faced with the prospect of moving
> > >
> > > s/acts/may act/ ? (why would every AP need to be a = NAS?)
> >
> > That's just reality. APs do 802.1X, which means that they have = to have
> > RADIUS configuration. [...]
>
> No, APs _may_ do 802.1X. Those which are of interest to this = WG most
> probably will. But you're making a generalization that every = AP does.
> That eats the credibility of these statements.

> Take e.g. the APs deployed at the IETF meetings. I don't = think there
> will be 802.1X used on those in a very, very long time (if = ever).

sigh.

Even though we are not USING 802.1x at the IETF meetings, the APs that = were
used did in fact support 802.1X. While you may be right that I may be = generalizing
(for instance VERY low cost consumer APs may not have 802.1X support), = AP
vendor now actually have to support WPA in order to get WiFi = certification.
Again, while WPA does have a comsumer mode (pre-shared keys), any vendor = that
plans to participate in enterprise networking will include 802.1X.

I would also argue that CAPWAP is really concerned with larger scale = WLAN
deployments so I think it is fair to assume that for the purposes of = the
discussions on this list, the AP/NAS comparison is a fair statement.

PatC
------_=_NextPart_001_01C3CFB2.B8B65D90-- From pekkas@netcore.fi Wed Dec 31 15:13:26 2003 From: pekkas@netcore.fi (Pekka Savola) Date: Wed, 31 Dec 2003 17:13:26 +0200 (EET) Subject: [Capwap] Re: WG Review: Control and Provisioning of Wireless Access Points (capwap) In-Reply-To: <55749BC69138654EBBC4C50BA4F55610ADC380@AIREMAIL.airespace.com> Message-ID: On Wed, 31 Dec 2003, Pat R. Calhoun wrote: > > The main thing I'm concerned at this point is whether these vendors > > may have claimed IPR on these protocols, and whether this might > > interfere with the work of this potential WG. > > > > Has this been discussed? > > http://www.ietf.org/ietf/IPR/airespace-ipr-draft-calhoun-seamoby-lwapp.txt That's good enough for me, at least, but what is the situation with the other represented vendors (etc.) who already have solutions on the table? It might not hurt to ask each of them explicitly.. > > (mainly editorial comment): > >> Finally, because each AP acts as its own Network Access Server > >> (NAS), a network provider is faced with the prospect of moving > > > > s/acts/may act/ ? (why would every AP need to be a NAS?) > > That's just reality. APs do 802.1X, which means that they have to have > RADIUS configuration. [...] No, APs _may_ do 802.1X. Those which are of interest to this WG most probably will. But you're making a generalization that every AP does. That eats the credibility of these statements. Take e.g. the APs deployed at the IETF meetings. I don't think there will be 802.1X used on those in a very, very long time (if ever). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From kempf@docomolabs-usa.com Wed Dec 31 17:48:06 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Wed, 31 Dec 2003 09:48:06 -0800 Subject: [Capwap] Re: WG Review: Control and Provisioning of Wireless Access Points (capwap) References: Message-ID: <008101c3cfc6$3f461e60$5b6015ac@dclkempt40> Pekka, Regarding IPR, the proposed WG charter is only to do an architectural taxonomy. As such, I don't think there would be any IPR (except of course on the contents of the document, which belongs to ISOC). Whether or not the WG is rechartered to actually do protocol work depends on the outcome of the architectural taxonomy work, and any IPR issues would naturally need to be revisited at that time. jak ----- Original Message ----- From: "Pekka Savola" To: Cc: Sent: Monday, December 22, 2003 1:23 PM Subject: [Capwap] Re: WG Review: Control and Provisioning of Wireless Access Points (capwap) > On Mon, 22 Dec 2003, The IESG wrote: > > > In recent attempts to solve these problems, various vendors have > > introduced products that redistribute the functionality of 802.11 > > APs in various ways. However, because the 802.11 access network > > functional architecture is incompletely specified, the network > > interfaces between network entities in different vendors' > > products are defined in incompatible ways. As a result, the > > protocols between the network entities in different products are > > not interoperable. > > The main thing I'm concerned at this point is whether these vendors > may have claimed IPR on these protocols, and whether this might > interfere with the work of this potential WG. > > Has this been discussed? > > (mainly editorial comment): > > Finally, because each AP acts as its own Network Access Server > > (NAS), a network provider is faced with the prospect of moving > > s/acts/may act/ ? (why would every AP need to be a NAS?) > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >