From peyush.agarwal@st.com Mon Feb 2 06:57:16 2004 From: peyush.agarwal@st.com (Peyush AGARWAL) Date: Mon, 2 Feb 2004 12:27:16 +0530 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR In-Reply-To: <26BDFAFFB541B047B24179002EBE6D278CB1A7@orsmsx410.jf.intel.com> Message-ID: <002701c3e959$cb766140$0904b40a@dlh.st.com> This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C3E987.E52E9D40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit We can probably come out with the 'Interoperability Issues' between different Architectures, if we stick to a similar Architecture below: AC (SIMPLY ALWAYS HAVE ARCH-3) | |---------------- AP - ARCH 0 |---------------- AP - ARCH 1 |---------------- AP - ARCH 2 |---------------- AP - ARCH 3 The "Capability Negotiations" should now decide as what "subset" of ARCH-3 on AC shall be used based on the AP Architecture Regards, Peyush. -----Original Message----- From: Yang, Lily L [mailto:lily.l.yang@intel.com] Sent: Sunday, February 01, 2004 3:55 AM To: Pat R. Calhoun; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR I understand the concern. I don't know how much interoperability we can achieve either. But it seems like that is the market reality we are facing today. So we need to figure out what role, if there is a role, for IETF to do here to achieve any interoperability. I think that is why the charter calls for some architectural study first. The feasibility is still an open question to me. I believe even the standalone AP can still benefit from the existence of a centralized controller to achieve network-wide RF management and configuration. Of course, then it is not a strictly "standalone" AP any more, but it may still be a pretty fat AP, handling some local decisions (e.g., association) on its own, without forwarding every single packet to the controller. I would think IETF/CAPWPA can still play a role in such architecture. -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Saturday, January 31, 2004 2:01 PM To: Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR I'm deeply concerned about the concept of "architecture variants". What this smells like to me is having multiple different architectures that don't interoperate. I see this as adding complexity to the market (and more specifically to the end user), and hampering interoperability. Of course, we'll always have stand-alone APs... and I don't see why the IETF needs to be concerned about those. We should be focused on how to provide a scalable solution. my 2 cents, PatC -----Original Message----- From: capwap-admin@frascone.com on behalf of Yang, Lily L Sent: Fri 1/30/2004 10:07 AM To: Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR It is conceivable that AP could just stick to one architecture variant, depending on the target market, price point, etc., while AC might have more flexibility to support multiple variants, esp. if the functions required on AC for b is a superset for a., then supporting b means it can also support a -- but this could be grossly simplified view, so don't take it too literally. But there might be ways to accomplish some level of interoperability across the spectrum. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Peyush AGARWAL Sent: Thursday, January 29, 2004 10:02 PM To: 'Bob O'Hara'; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR That sounds good & informative. But again to make the things more clear; using Capability Negotiations is it possible that we have a topology where: AC is on ARCH - x and the APs present in the network are on ARCH - a, b, c (where a/b/c != x) ? If the answer is yes, I feel that one has to end up implementing everything in APs as well as ACs!! Regards, Peyush. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Bob O'Hara Sent: Wednesday, January 28, 2004 10:42 PM To: Peyush AGARWAL; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR Peyush, The negotiation between the AP and AR would not have anything to do with the 802.11 capabilities advertised in the 802.11 Beacon frame. The capabilities in the proposed negotiation between AP and AR would have to do with what functions are available at either end of that protocol exchange. This was included in the draft to address the various functional splits that are already present in the several products already in the market. One example of a function that might be part of this negotiation is which parts of the 802.11 MAC management functionality would be implemented in the AP and which parts would be implemented in the AR. There are examples of products in the market that implement all of the MAC management in the AR-equivalent device, some that move various parts of that to the AP, and some others that implement all of it in the AP. -Bob -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Peyush AGARWAL Sent: Wednesday, January 28, 2004 4:23 AM To: capwap@frascone.com Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Hi, The "Capabilities Negotiation" has been proposed in the Architecture draft (draft-mani-ietf-capwap-arch-00) with the intention of deciding 'the applicable API's between AP and AC'. The 802.11 'Beacons' already contains the information of the capabilities supported by the AP, therefore the requirement of 'capabilities negotiation' is not clear to me. Please clarify. Thanks in advance. Regards, Peyush. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap ------=_NextPart_000_0028_01C3E987.E52E9D40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 

We can = probably=20 come out with the 'Interoperability=20 Issues' between different = Architectures,=20  if we stick to a = similar=20 Architecture below:=20

  = AC (SIMPLY=20 ALWAYS HAVE ARCH-3)

         &nb= sp;     =20 |

         &nb= sp;     =20 |---------------- AP - ARCH 0

         &nb= sp;     =20 |---------------- AP - ARCH 1

         &nb= sp;     =20 |---------------- AP - ARCH 2

         &nb= sp;     =20 |---------------- AP - ARCH 3

The "Capability Negotiations" should now decide as what "subset" = of ARCH-3=20 on AC shall be used based on the AP Architecture

Regards,

Peyush.

 

-----Original Message-----
From: = Yang, Lily L=20 [mailto:lily.l.yang@intel.com]
Sent: Sunday, February 01, = 2004 3:55=20 AM
To: Pat R. Calhoun; Peyush AGARWAL; Bob O'Hara;=20 capwap@frascone.com
Subject: RE: [Capwap] Reg. Capabilities=20 Negotiation between AP - AR

I=20 understand the concern. I don’t know how much interoperability = we can achieve=20 either. But it seems like that is the market reality we are facing = today. So=20 we need to figure out what role, if there is a role, for IETF to do = here to=20 achieve any interoperability. I think that is why the charter calls = for some=20 architectural study first. The feasibility is still an open question = to=20 me.

 

I believe = even the=20 standalone AP can still benefit from the existence of a centralized = controller=20 to achieve network-wide RF management and configuration. Of course, = then it is=20 not a strictly “standalone” AP any more, but it may still = be a pretty fat AP,=20 handling some local decisions (e.g., association) on its own, without=20 forwarding every single packet to the controller. I would think = IETF/CAPWPA=20 can still play a role in such architecture.

 

-----Original=20 Message-----
From: = Pat R.=20 Calhoun [mailto:pcalhoun@airespace.com]
Sent: Saturday, January 31, = 2004 2:01=20 PM
To: Yang, Lily = L; Peyush=20 AGARWAL; Bob O'Hara; capwap@frascone.com
Subject: RE: [Capwap] Reg. = Capabilities=20 Negotiation between AP - AR

 

I'm = deeply=20 concerned about the concept of "architecture variants". What
this = smells=20 like to me is having multiple different architectures that
don't=20 interoperate. I see this as adding complexity to the market = (and
more=20 specifically to the end user), and hampering = interoperability.

Of=20 course, we'll always have stand-alone APs... and I don't see why = the
IETF=20 needs to be concerned about those. We should be focused on how = to
provide a=20 scalable solution.

my 2 cents,

PatC
-----Original=20 Message-----
From: capwap-admin@frascone.com on behalf of Yang, = Lily=20 L
Sent: Fri 1/30/2004 10:07 AM
To: Peyush AGARWAL; Bob O'Hara;=20 capwap@frascone.com
Subject: RE: [Capwap] Reg. Capabilities = Negotiation=20 between AP - AR

It is conceivable that AP could just stick to = one=20 architecture variant,
depending on the target market, price point, = etc.,=20 while AC might have
more flexibility to support multiple variants, = esp. if=20 the functions
required on AC for b is a superset for a., then = supporting b=20 means it
can also support a -- but this could be grossly simplified = view,=20 so
don't take it too literally. But there might be ways to = accomplish=20 some
level of interoperability across the = spectrum.

-----Original=20 Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m]=20 On
Behalf Of Peyush AGARWAL
Sent: Thursday, January 29, 2004 = 10:02=20 PM
To: 'Bob O'Hara'; capwap@frascone.com
Subject: RE: [Capwap] = Reg.=20 Capabilities Negotiation between AP - AR

That sounds good & = informative.

But again to make the things more clear; using = Capability=20 Negotiations
is it
possible that we have a topology=20 where:

        AC is on ARCH = - x=20 and
        the APs present in = the=20 network are on ARCH - a, b, c (where
a/b/c !=3D
x) ?

If = the answer=20 is yes, I feel that one has to end up implementing
everything
in = APs as=20 well as = ACs!!

Regards,
Peyush.





-----Original=20 Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m]=20 On
Behalf
Of Bob O'Hara
Sent: Wednesday, January 28, 2004 = 10:42=20 PM
To: Peyush AGARWAL; capwap@frascone.com
Subject: RE: [Capwap] = Reg.=20 Capabilities Negotiation between AP - AR


Peyush,

The = negotiation between the AP and AR would not have anything to do=20 with
the
802.11 capabilities advertised in the 802.11 Beacon=20 frame.  The
capabilities
in the proposed negotiation = between AP and=20 AR would have to do with what
functions are available at either end = of that=20 protocol exchange.  This
was
included in the draft to = address the=20 various functional splits that are
already present in the several = products=20 already in the market.

One example of a function that might be = part of=20 this negotiation is
which
parts of the 802.11 MAC management=20 functionality would be implemented in
the
AP and which parts = would be=20 implemented in the AR. There are examples of
products in the market = that=20 implement all of the MAC management in the
AR-equivalent device, = some that=20 move various parts of that to the AP,
and
some others that = implement all=20 of it in the AP.

 -Bob


-----Original=20 Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m]=20 On
Behalf
Of Peyush AGARWAL
Sent: Wednesday, January 28, 2004 = 4:23=20 AM
To: capwap@frascone.com
Subject: [Capwap] Reg. Capabilities=20 Negotiation between AP - AR


Hi,

The "Capabilities=20 Negotiation" has been proposed in the=20 Architecture
draft
(draft-mani-ietf-capwap-arch-00) with the = intention=20 of deciding 'the
applicable API's between AP and=20 AC'.
        The 802.11 = 'Beacons'=20 already contains the information of the
capabilities supported by = the AP,=20 therefore the requirement of
'capabilities
negotiation' is not = clear to=20 me. Please clarify.

Thanks in=20 = advance.

Regards,
Peyush.

______________________________= _________________
Capwap=20 mailing list
Capwap@frascone.com http://mail.fra= scone.com/mailman/listinfo/capwap
________________________________= _______________
Capwap=20 mailing list
Capwap@frascone.com http://mail.fra= scone.com/mailman/listinfo/capwap

____________________________= ___________________
Capwap=20 mailing list
Capwap@frascone.com
http://mail.fra= scone.com/mailman/listinfo/capwap
________________________________= _______________
Capwap=20 mailing list
Capwap@frascone.com
http://mail.fra= scone.com/mailman/listinfo/capwap

------=_NextPart_000_0028_01C3E987.E52E9D40-- From kempf@docomolabs-usa.com Mon Feb 2 17:04:41 2004 From: kempf@docomolabs-usa.com (James Kempf) Date: Mon, 2 Feb 2004 09:04:41 -0800 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR References: <002701c3e959$cb766140$0904b40a@dlh.st.com> Message-ID: <00e501c3e9ae$a67e9240$936015ac@dclkempt40> Peyush, I don't see there being separate functional architectures. Rather, I think that there needs to be one functional architecture in which there are specifically defined interfaces between functional components. The functional architecture is not, however, what is implemented directly. The difference between various vendors' products comes in how the functional architecture is cast into boxes in the network (sometimes call the network architecture). In some vendors' products particular interfaces will be open and the functional elements separated by these interfaces will be grouped and distributed into different network elements. In other vendors' products, that particular interface may be closed and the functional elements separated by the interface are grouped together into one single network element (i.e. the interface is a closed, internal one to the network element). If an interface is open, then it is where a protocol is defined, and can be standardized, either in IETF or IEEE. If it is closed, then there is no possibility of such a protocol. Since IEEE today has no reference architecture for network elements, there are various cuts on how the functional elements are grouped and distributed into boxes, with various protocols. The 'Interoperability Issues' needs to call out where there are interoperability problems between these boxes. Some vendors will have the same or slightly different cuts on where to define the interfaces, others may have radically different cuts. Exactly how to address those issues in protocol standardization is a further issue that needs to get worked out, but not at this phase, since the WG is just chartered to describe the current situation. Does this make sense? jak ----- Original Message ----- From: "Peyush AGARWAL" To: "'Yang, Lily L'" ; "'Pat R. Calhoun'" ; "'Bob O'Hara'" ; Sent: Sunday, February 01, 2004 10:57 PM Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR > > > We can probably come out with the 'Interoperability Issues' between > different Architectures, if we stick to a similar Architecture below: > > AC (SIMPLY ALWAYS HAVE ARCH-3) > > | > > |---------------- AP - ARCH 0 > > |---------------- AP - ARCH 1 > > |---------------- AP - ARCH 2 > > |---------------- AP - ARCH 3 > > The "Capability Negotiations" should now decide as what "subset" of ARCH-3 > on AC shall be used based on the AP Architecture > > Regards, > > Peyush. > > > > -----Original Message----- > From: Yang, Lily L [mailto:lily.l.yang@intel.com] > Sent: Sunday, February 01, 2004 3:55 AM > To: Pat R. Calhoun; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com > Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR > > > > I understand the concern. I don't know how much interoperability we can > achieve either. But it seems like that is the market reality we are facing > today. So we need to figure out what role, if there is a role, for IETF to > do here to achieve any interoperability. I think that is why the charter > calls for some architectural study first. The feasibility is still an open > question to me. > > > > I believe even the standalone AP can still benefit from the existence of a > centralized controller to achieve network-wide RF management and > configuration. Of course, then it is not a strictly "standalone" AP any > more, but it may still be a pretty fat AP, handling some local decisions > (e.g., association) on its own, without forwarding every single packet to > the controller. I would think IETF/CAPWPA can still play a role in such > architecture. > > > > -----Original Message----- > From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] > Sent: Saturday, January 31, 2004 2:01 PM > To: Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com > Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR > > > > I'm deeply concerned about the concept of "architecture variants". What > this smells like to me is having multiple different architectures that > don't interoperate. I see this as adding complexity to the market (and > more specifically to the end user), and hampering interoperability. > > Of course, we'll always have stand-alone APs... and I don't see why the > IETF needs to be concerned about those. We should be focused on how to > provide a scalable solution. > > my 2 cents, > > PatC > -----Original Message----- > From: capwap-admin@frascone.com on behalf of Yang, Lily L > Sent: Fri 1/30/2004 10:07 AM > To: Peyush AGARWAL; Bob O'Hara; capwap@frascone.com > Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR > > It is conceivable that AP could just stick to one architecture variant, > depending on the target market, price point, etc., while AC might have > more flexibility to support multiple variants, esp. if the functions > required on AC for b is a superset for a., then supporting b means it > can also support a -- but this could be grossly simplified view, so > don't take it too literally. But there might be ways to accomplish some > level of interoperability across the spectrum. > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Peyush AGARWAL > Sent: Thursday, January 29, 2004 10:02 PM > To: 'Bob O'Hara'; capwap@frascone.com > Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR > > That sounds good & informative. > > But again to make the things more clear; using Capability Negotiations > is it > possible that we have a topology where: > > AC is on ARCH - x and > the APs present in the network are on ARCH - a, b, c (where > a/b/c != > x) ? > > If the answer is yes, I feel that one has to end up implementing > everything > in APs as well as ACs!! > > Regards, > Peyush. > > > > > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf > Of Bob O'Hara > Sent: Wednesday, January 28, 2004 10:42 PM > To: Peyush AGARWAL; capwap@frascone.com > Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR > > > Peyush, > > The negotiation between the AP and AR would not have anything to do with > the > 802.11 capabilities advertised in the 802.11 Beacon frame. The > capabilities > in the proposed negotiation between AP and AR would have to do with what > functions are available at either end of that protocol exchange. This > was > included in the draft to address the various functional splits that are > already present in the several products already in the market. > > One example of a function that might be part of this negotiation is > which > parts of the 802.11 MAC management functionality would be implemented in > the > AP and which parts would be implemented in the AR. There are examples of > products in the market that implement all of the MAC management in the > AR-equivalent device, some that move various parts of that to the AP, > and > some others that implement all of it in the AP. > > -Bob > > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf > Of Peyush AGARWAL > Sent: Wednesday, January 28, 2004 4:23 AM > To: capwap@frascone.com > Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR > > > Hi, > > The "Capabilities Negotiation" has been proposed in the Architecture > draft > (draft-mani-ietf-capwap-arch-00) with the intention of deciding 'the > applicable API's between AP and AC'. > The 802.11 'Beacons' already contains the information of the > capabilities supported by the AP, therefore the requirement of > 'capabilities > negotiation' is not clear to me. Please clarify. > > Thanks in advance. > > Regards, > Peyush. > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ > Capwap mailing list > Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > > > From bran@arraycomm.com Mon Feb 2 18:19:03 2004 From: bran@arraycomm.com (Branislav Meandzija) Date: Mon, 2 Feb 2004 10:19:03 -0800 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Message-ID: <200402021821.i12ILLs5003875@lester.arraycomm.com> My comments in-line. Branislav -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On Behalf= Of Pat R. Calhoun Sent: Saturday, January 31, 2004 2:41 PM To: Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR I believe you are correct. It really boils down to one of three options: 1. Leave things as-is, 2. Implement a centralized network management component (what you are descr= ibing) 3. A centralized controller approach Of course, option 1 will always exist, and there are markets where this app= roach makes sense. As far as option 2, I believe that there are some pretty severe drawbacks. = For instance, RF management really needs access to RF information on a packet-by-packet b= asis. RF information is not just a single value (e.g. 1 is good), but really consists of various= measurements some of which are specific to each clients. It is possible for APs to constantly= be polled for this information and let a network manager run algorithms. However, I believe th= at for those of us that have lived through the dial-up NAS markets in the mid-90s, some may re= call the NASes that would be polled frequently for "user information", and the fact that these = events caused a severe CPU drain on the NASes. = ----- Times they are achangin! We have quite different processing and commun= ications capabilities Today. And even Yesterday, look at the cable modem RF MIB. ----- RF information is even more dynamic, and I suspect that there would be additional problems. There is also the issue where this option STILL requir= es that security information (specifically passwords for RADIUS, SNMP, etc) be stored in fla= sh, and this is a big concern for IT managers. Lastly, it seems like everyone (even the incum= bents are moving towards option 3). ----- Actually the opposite is true. The latest architectural solutions make= the BS autonomous. Nobody likes to pay for and maintain heavy infrastructure. ----- Obviously, I'm in favor of option 3. If you just look at the cellular marke= t, which evolved through the first two options, I believe that the current RAN approach of centraliz= ing functionality in the base station has made these networks scale. I believe that we would try to benefit from the lessons learned in both the= dial-up and the cellular networks here in CAPWAP. ----- I agree with that but with obviously a different conclusion. ----- PatC -----Original Message----- From: Yang, Lily L [mailto:lily.l.yang@intel.com] Sent: Sat 1/31/2004 2:24 PM To: Pat R. Calhoun; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR I understand the concern. I don't know how much interoperability we can achieve either. But it seems like that is the market reality we are facing today. So we need to figure out what role, if there is a role, for IETF to do here to achieve any interoperability. I think that is why the charter calls for some architectural study first. The feasibility is still an open question to me. I believe even the standalone AP can still benefit from the existence of a centralized controller to achieve network-wide RF management and configuration. Of course, then it is not a strictly "standalone" AP any more, but it may still be a pretty fat AP, handling some local decisions (e.g., association) on its own, without forwarding every single packet to the controller. I would think IETF/CAPWPA can still play a role in such architecture. -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Saturday, January 31, 2004 2:01 PM To: Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR I'm deeply concerned about the concept of "architecture variants". What this smells like to me is having multiple different architectures that don't interoperate. I see this as adding complexity to the market (and more specifically to the end user), and hampering interoperability. Of course, we'll always have stand-alone APs... and I don't see why the IETF needs to be concerned about those. We should be focused on how to provide a scalable solution. my 2 cents, PatC -----Original Message----- From: capwap-admin@frascone.com on behalf of Yang, Lily L Sent: Fri 1/30/2004 10:07 AM To: Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR It is conceivable that AP could just stick to one architecture variant, depending on the target market, price point, etc., while AC might have more flexibility to support multiple variants, esp. if the functions required on AC for b is a superset for a., then supporting b means it can also support a -- but this could be grossly simplified view, so don't take it too literally. But there might be ways to accomplish some level of interoperability across the spectrum. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Peyush AGARWAL Sent: Thursday, January 29, 2004 10:02 PM To: 'Bob O'Hara'; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR That sounds good & informative. But again to make the things more clear; using Capability Negotiations is it possible that we have a topology where: AC is on ARCH - x and the APs present in the network are on ARCH - a, b, c (where a/b/c !=3D x) ? If the answer is yes, I feel that one has to end up implementing everything in APs as well as ACs!! Regards, Peyush. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Bob O'Hara Sent: Wednesday, January 28, 2004 10:42 PM To: Peyush AGARWAL; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR Peyush, The negotiation between the AP and AR would not have anything to do with the 802.11 capabilities advertised in the 802.11 Beacon frame. The capabilities in the proposed negotiation between AP and AR would have to do with what functions are available at either end of that protocol exchange. This was included in the draft to address the various functional splits that are already present in the several products already in the market. One example of a function that might be part of this negotiation is which parts of the 802.11 MAC management functionality would be implemented in the AP and which parts would be implemented in the AR. There are examples of products in the market that implement all of the MAC management in the AR-equivalent device, some that move various parts of that to the AP, and some others that implement all of it in the AP. -Bob -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Peyush AGARWAL Sent: Wednesday, January 28, 2004 4:23 AM To: capwap@frascone.com Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Hi, The "Capabilities Negotiation" has been proposed in the Architecture draft (draft-mani-ietf-capwap-arch-00) with the intention of deciding 'the applicable API's between AP and AC'. The 802.11 'Beacons' already contains the information of the capabilities supported by the AP, therefore the requirement of 'capabilities negotiation' is not clear to me. Please clarify. Thanks in advance. Regards, Peyush. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From pcalhoun@airespace.com Mon Feb 2 18:28:03 2004 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Mon, 2 Feb 2004 10:28:03 -0800 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Message-ID: <55749BC69138654EBBC4C50BA4F55610ADC825@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E9BA.6B9C53EF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ok, I'll bite. Please explain to me how load balancing works using model 2 below when = the AP has a very finite amount of time to respond, and must make decisions = that require access to load information from surrounding APs. oh, and this has to scale. PatC -----Original Message----- From: Branislav Meandzija [mailto:bran@arraycomm.com] Sent: Mon 2/2/2004 10:19 AM To: Pat R. Calhoun; Yang, Lily L; Peyush AGARWAL; Bob O'Hara; = capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR =20 My comments in-line. Branislav -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On = Behalf Of Pat R. Calhoun Sent: Saturday, January 31, 2004 2:41 PM To: Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR I believe you are correct. It really boils down to one of three options: 1. Leave things as-is, 2. Implement a centralized network management component (what you are = describing) 3. A centralized controller approach Of course, option 1 will always exist, and there are markets where this = approach makes sense. As far as option 2, I believe that there are some pretty severe = drawbacks. For instance, RF management really needs access to RF information on a = packet-by-packet basis. RF information is not just a single value (e.g. 1 is good), but really consists of = various measurements some of which are specific to each clients. It is possible for APs to = constantly be polled for this information and let a network manager run algorithms. However, I believe = that for those of us that have lived through the dial-up NAS markets in the mid-90s, some may = recall the NASes that would be polled frequently for "user information", and the fact that = these events caused a severe CPU drain on the NASes.=20 ----- Times they are achangin! We have quite different processing and = communications capabilities Today. And even Yesterday, look at the cable modem RF MIB. ----- RF information is even more dynamic, and I suspect that there would be additional problems. There is also the issue where this option STILL = requires that security information (specifically passwords for RADIUS, SNMP, etc) be stored in = flash, and this is a big concern for IT managers. Lastly, it seems like everyone (even the = incumbents are moving towards option 3). ----- Actually the opposite is true. The latest architectural solutions = make the BS autonomous. Nobody likes to pay for and maintain heavy infrastructure. ----- Obviously, I'm in favor of option 3. If you just look at the cellular = market, which evolved through the first two options, I believe that the current RAN approach of = centralizing functionality in the base station has made these networks scale. I believe that we would try to benefit from the lessons learned in both = the dial-up and the cellular networks here in CAPWAP. ----- I agree with that but with obviously a different conclusion. ----- PatC -----Original Message----- From: Yang, Lily L [mailto:lily.l.yang@intel.com] Sent: Sat 1/31/2004 2:24 PM To: Pat R. Calhoun; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR I understand the concern. I don't know how much interoperability we can achieve either. But it seems like that is the market reality we are facing today. So we need to figure out what role, if there is a role, for IETF to do here to achieve any interoperability. I think that is why the charter calls for some architectural study first. The feasibility is still an open question to me. I believe even the standalone AP can still benefit from the existence of a centralized controller to achieve network-wide RF management and configuration. Of course, then it is not a strictly "standalone" AP any more, but it may still be a pretty fat AP, handling some local decisions (e.g., association) on its own, without forwarding every single packet to the controller. I would think IETF/CAPWPA can still play a role in such architecture. -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Saturday, January 31, 2004 2:01 PM To: Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR I'm deeply concerned about the concept of "architecture variants". What this smells like to me is having multiple different architectures that don't interoperate. I see this as adding complexity to the market (and more specifically to the end user), and hampering interoperability. Of course, we'll always have stand-alone APs... and I don't see why the IETF needs to be concerned about those. We should be focused on how to provide a scalable solution. my 2 cents, PatC -----Original Message----- From: capwap-admin@frascone.com on behalf of Yang, Lily L Sent: Fri 1/30/2004 10:07 AM To: Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR It is conceivable that AP could just stick to one architecture variant, depending on the target market, price point, etc., while AC might have more flexibility to support multiple variants, esp. if the functions required on AC for b is a superset for a., then supporting b means it can also support a -- but this could be grossly simplified view, so don't take it too literally. But there might be ways to accomplish some level of interoperability across the spectrum. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Peyush AGARWAL Sent: Thursday, January 29, 2004 10:02 PM To: 'Bob O'Hara'; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR That sounds good & informative. But again to make the things more clear; using Capability Negotiations is it possible that we have a topology where: AC is on ARCH - x and the APs present in the network are on ARCH - a, b, c (where a/b/c !=3D x) ? If the answer is yes, I feel that one has to end up implementing everything in APs as well as ACs!! Regards, Peyush. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Bob O'Hara Sent: Wednesday, January 28, 2004 10:42 PM To: Peyush AGARWAL; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR Peyush, The negotiation between the AP and AR would not have anything to do with the 802.11 capabilities advertised in the 802.11 Beacon frame. The capabilities in the proposed negotiation between AP and AR would have to do with what functions are available at either end of that protocol exchange. This was included in the draft to address the various functional splits that are already present in the several products already in the market. One example of a function that might be part of this negotiation is which parts of the 802.11 MAC management functionality would be implemented in the AP and which parts would be implemented in the AR. There are examples of products in the market that implement all of the MAC management in the AR-equivalent device, some that move various parts of that to the AP, and some others that implement all of it in the AP. -Bob -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Peyush AGARWAL Sent: Wednesday, January 28, 2004 4:23 AM To: capwap@frascone.com Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Hi, The "Capabilities Negotiation" has been proposed in the Architecture draft (draft-mani-ietf-capwap-arch-00) with the intention of deciding 'the applicable API's between AP and AC'. The 802.11 'Beacons' already contains the information of the capabilities supported by the AP, therefore the requirement of 'capabilities negotiation' is not clear to me. Please clarify. Thanks in advance. Regards, Peyush. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap ------_=_NextPart_001_01C3E9BA.6B9C53EF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Capwap] Reg. Capabilities Negotiation between AP - = AR

ok, I'll bite.

Please explain to me how load balancing works using model 2 below when = the
AP has a very finite amount of time to respond, and must make decisions = that
require access to load information from surrounding APs.

oh, and this has to scale.

PatC


-----Original Message-----
From: Branislav Meandzija [mailto:bran@arraycomm.com]
Sent: Mon 2/2/2004 10:19 AM
To: Pat R. Calhoun; Yang, Lily L; Peyush AGARWAL; Bob O'Hara; = capwap@frascone.com
Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR


My comments in-line.

Branislav
-----Original Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m]On Behalf Of Pat R. Calhoun
Sent: Saturday, January 31, 2004 2:41 PM
To: Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com
Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR


I believe you are correct. It really boils down to one of three = options:

1. Leave things as-is,
2. Implement a centralized network management component (what you are = describing)
3. A centralized controller approach

Of course, option 1 will always exist, and there are markets where this = approach
makes sense.

As far as option 2, I believe that there are some pretty severe = drawbacks. For instance,
RF management really needs access to RF information on a = packet-by-packet basis. RF information
is not just a single value (e.g. 1 is good), but really consists of = various measurements some
of which are specific to each clients. It is possible for APs to = constantly be polled for this
information and let a network manager run algorithms. However, I believe = that for those of us
that have lived through the dial-up NAS markets in the mid-90s, some may = recall the NASes that
would be polled frequently for "user information", and the = fact that these events caused a severe
CPU drain on the NASes.

-----
<BM> Times they are achangin! We have quite different processing = and communications capabilities Today. And
even Yesterday, look at the cable modem RF MIB.
-----
RF information is even more dynamic, and I suspect that there would = be
additional problems. There is also the issue where this option STILL = requires that security
information (specifically passwords for RADIUS, SNMP, etc) be stored in = flash, and this is a
big concern for IT managers. Lastly, it seems like everyone (even the = incumbents are moving towards
option 3).

-----
<BM> Actually the opposite is true. The latest architectural = solutions make the BS autonomous. Nobody likes
to pay for and maintain heavy infrastructure.
-----

Obviously, I'm in favor of option 3. If you just look at the cellular = market, which evolved through
the first two options, I believe that the current RAN approach of = centralizing functionality in the
base station has made these networks scale.

I believe that we would try to benefit from the lessons learned in both = the dial-up and the cellular
networks here in CAPWAP.
-----
<BM> I agree with that but with obviously a different = conclusion.
-----

PatC


-----Original Message-----
From: Yang, Lily L [mailto:lily.l.yang@intel.com] Sent: Sat 1/31/2004 2:24 PM
To: Pat R. Calhoun; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com
Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR

I understand the concern. I don't know how much interoperability we = can
achieve either. But it seems like that is the market reality we are
facing today. So we need to figure out what role, if there is a = role,
for IETF to do here to achieve any interoperability. I think that is = why
the charter calls for some architectural study first. The feasibility = is
still an open question to me.



I believe even the standalone AP can still benefit from the existence = of
a centralized controller to achieve network-wide RF management and
configuration. Of course, then it is not a strictly = "standalone" AP any
more, but it may still be a pretty fat AP, handling some local = decisions
(e.g., association) on its own, without forwarding every single = packet
to the controller. I would think IETF/CAPWPA can still play a role = in
such architecture.



-----Original Message-----
From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]=
Sent: Saturday, January 31, 2004 2:01 PM
To: Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com
Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR



I'm deeply concerned about the concept of "architecture = variants". What
this smells like to me is having multiple different architectures = that
don't interoperate. I see this as adding complexity to the market = (and
more specifically to the end user), and hampering interoperability.

Of course, we'll always have stand-alone APs... and I don't see why = the
IETF needs to be concerned about those. We should be focused on how = to
provide a scalable solution.

my 2 cents,

PatC
-----Original Message-----
From: capwap-admin@frascone.com on behalf of Yang, Lily L
Sent: Fri 1/30/2004 10:07 AM
To: Peyush AGARWAL; Bob O'Hara; capwap@frascone.com
Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR

It is conceivable that AP could just stick to one architecture = variant,
depending on the target market, price point, etc., while AC might = have
more flexibility to support multiple variants, esp. if the functions
required on AC for b is a superset for a., then supporting b means = it
can also support a -- but this could be grossly simplified view, so
don't take it too literally. But there might be ways to accomplish = some
level of interoperability across the spectrum.

-----Original Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On
Behalf Of Peyush AGARWAL
Sent: Thursday, January 29, 2004 10:02 PM
To: 'Bob O'Hara'; capwap@frascone.com
Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR

That sounds good & informative.

But again to make the things more clear; using Capability = Negotiations
is it
possible that we have a topology where:

        AC is on ARCH - x and
        the APs present in the = network are on ARCH - a, b, c (where
a/b/c !=3D
x) ?

If the answer is yes, I feel that one has to end up implementing
everything
in APs as well as ACs!!

Regards,
Peyush.





-----Original Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On
Behalf
Of Bob O'Hara
Sent: Wednesday, January 28, 2004 10:42 PM
To: Peyush AGARWAL; capwap@frascone.com
Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR


Peyush,

The negotiation between the AP and AR would not have anything to do = with
the
802.11 capabilities advertised in the 802.11 Beacon frame.  The
capabilities
in the proposed negotiation between AP and AR would have to do with = what
functions are available at either end of that protocol exchange.  = This
was
included in the draft to address the various functional splits that = are
already present in the several products already in the market.

One example of a function that might be part of this negotiation is
which
parts of the 802.11 MAC management functionality would be implemented = in
the
AP and which parts would be implemented in the AR. There are examples = of
products in the market that implement all of the MAC management in = the
AR-equivalent device, some that move various parts of that to the = AP,
and
some others that implement all of it in the AP.

 -Bob


-----Original Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On
Behalf
Of Peyush AGARWAL
Sent: Wednesday, January 28, 2004 4:23 AM
To: capwap@frascone.com
Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR


Hi,

The "Capabilities Negotiation" has been proposed in the = Architecture
draft
(draft-mani-ietf-capwap-arch-00) with the intention of deciding 'the
applicable API's between AP and AC'.
        The 802.11 'Beacons' already = contains the information of the
capabilities supported by the AP, therefore the requirement of
'capabilities
negotiation' is not clear to me. Please clarify.

Thanks in advance.

Regards,
Peyush.

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

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



------_=_NextPart_001_01C3E9BA.6B9C53EF-- From bran@arraycomm.com Mon Feb 2 19:08:58 2004 From: bran@arraycomm.com (Branislav Meandzija) Date: Mon, 2 Feb 2004 11:08:58 -0800 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Message-ID: <200402021911.i12JBGs5013270@lester.arraycomm.com> ok, I'll bite. No need to bite :-) Please explain to me how load balancing works using model 2 below when the AP has a very finite amount of time to respond, and must make decisions tha= t require access to load information from surrounding APs. What type of network are you referring to? Bellow you were making comm= ents about cellular networks and trends which IMHO are incorrect. In cellul= ar, there is a variety of technologies which can be based, for example, on = the BS simply sending to mobiles a load factor and leaving it up to mobiles= to decide which BS to pick. oh, and this has to scale. That scales very well. Branislav PatC -----Original Message----- From: Branislav Meandzija [mailto:bran@arraycomm.com] Sent: Mon 2/2/2004 10:19 AM To: Pat R. Calhoun; Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frasco= ne.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR My comments in-line. Branislav -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On Behalf= Of Pat R. Calhoun Sent: Saturday, January 31, 2004 2:41 PM To: Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR I believe you are correct. It really boils down to one of three options: 1. Leave things as-is, 2. Implement a centralized network management component (what you are descr= ibing) 3. A centralized controller approach Of course, option 1 will always exist, and there are markets where this app= roach makes sense. As far as option 2, I believe that there are some pretty severe drawbacks. = For instance, RF management really needs access to RF information on a packet-by-packet b= asis. RF information is not just a single value (e.g. 1 is good), but really consists of various= measurements some of which are specific to each clients. It is possible for APs to constantly= be polled for this information and let a network manager run algorithms. However, I believe th= at for those of us that have lived through the dial-up NAS markets in the mid-90s, some may re= call the NASes that would be polled frequently for "user information", and the fact that these = events caused a severe CPU drain on the NASes. ----- Times they are achangin! We have quite different processing and commun= ications capabilities Today. And even Yesterday, look at the cable modem RF MIB. ----- RF information is even more dynamic, and I suspect that there would be additional problems. There is also the issue where this option STILL requir= es that security information (specifically passwords for RADIUS, SNMP, etc) be stored in fla= sh, and this is a big concern for IT managers. Lastly, it seems like everyone (even the incum= bents are moving towards option 3). ----- Actually the opposite is true. The latest architectural solutions make= the BS autonomous. Nobody likes to pay for and maintain heavy infrastructure. ----- Obviously, I'm in favor of option 3. If you just look at the cellular marke= t, which evolved through the first two options, I believe that the current RAN approach of centraliz= ing functionality in the base station has made these networks scale. I believe that we would try to benefit from the lessons learned in both the= dial-up and the cellular networks here in CAPWAP. ----- I agree with that but with obviously a different conclusion. ----- PatC -----Original Message----- From: Yang, Lily L [mailto:lily.l.yang@intel.com] Sent: Sat 1/31/2004 2:24 PM To: Pat R. Calhoun; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR I understand the concern. I don't know how much interoperability we can achieve either. But it seems like that is the market reality we are facing today. So we need to figure out what role, if there is a role, for IETF to do here to achieve any interoperability. I think that is why the charter calls for some architectural study first. The feasibility is still an open question to me. I believe even the standalone AP can still benefit from the existence of a centralized controller to achieve network-wide RF management and configuration. Of course, then it is not a strictly "standalone" AP any more, but it may still be a pretty fat AP, handling some local decisions (e.g., association) on its own, without forwarding every single packet to the controller. I would think IETF/CAPWPA can still play a role in such architecture. -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Saturday, January 31, 2004 2:01 PM To: Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR I'm deeply concerned about the concept of "architecture variants". What this smells like to me is having multiple different architectures that don't interoperate. I see this as adding complexity to the market (and more specifically to the end user), and hampering interoperability. Of course, we'll always have stand-alone APs... and I don't see why the IETF needs to be concerned about those. We should be focused on how to provide a scalable solution. my 2 cents, PatC -----Original Message----- From: capwap-admin@frascone.com on behalf of Yang, Lily L Sent: Fri 1/30/2004 10:07 AM To: Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR It is conceivable that AP could just stick to one architecture variant, depending on the target market, price point, etc., while AC might have more flexibility to support multiple variants, esp. if the functions required on AC for b is a superset for a., then supporting b means it can also support a -- but this could be grossly simplified view, so don't take it too literally. But there might be ways to accomplish some level of interoperability across the spectrum. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Peyush AGARWAL Sent: Thursday, January 29, 2004 10:02 PM To: 'Bob O'Hara'; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR That sounds good & informative. But again to make the things more clear; using Capability Negotiations is it possible that we have a topology where: AC is on ARCH - x and the APs present in the network are on ARCH - a, b, c (where a/b/c !=3D x) ? If the answer is yes, I feel that one has to end up implementing everything in APs as well as ACs!! Regards, Peyush. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Bob O'Hara Sent: Wednesday, January 28, 2004 10:42 PM To: Peyush AGARWAL; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR Peyush, The negotiation between the AP and AR would not have anything to do with the 802.11 capabilities advertised in the 802.11 Beacon frame. The capabilities in the proposed negotiation between AP and AR would have to do with what functions are available at either end of that protocol exchange. This was included in the draft to address the various functional splits that are already present in the several products already in the market. One example of a function that might be part of this negotiation is which parts of the 802.11 MAC management functionality would be implemented in the AP and which parts would be implemented in the AR. There are examples of products in the market that implement all of the MAC management in the AR-equivalent device, some that move various parts of that to the AP, and some others that implement all of it in the AP. -Bob -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Peyush AGARWAL Sent: Wednesday, January 28, 2004 4:23 AM To: capwap@frascone.com Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Hi, The "Capabilities Negotiation" has been proposed in the Architecture draft (draft-mani-ietf-capwap-arch-00) with the intention of deciding 'the applicable API's between AP and AC'. The 802.11 'Beacons' already contains the information of the capabilities supported by the AP, therefore the requirement of 'capabilities negotiation' is not clear to me. Please clarify. Thanks in advance. Regards, Peyush. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From david.putzolu@intel.com Mon Feb 2 19:12:47 2004 From: david.putzolu@intel.com (Putzolu, David) Date: Mon, 2 Feb 2004 11:12:47 -0800 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Message-ID: <52D13A805349A249960B9943E5590BD8022CF069@orsmsx409.jf.intel.com> What is the current engineering practice for load balancing? If they are all model 3 (although I have to admit I am not totally clear on the difference between 2 and 3) then it would seem to be the right place to start. If they are a mix between 2 and 3, then the WG would need to decide whether to intentionally exclude some current solutions, or to come up with an architecture flexible enough to support both. Cheers, David Putzolu=20 ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun Sent: Monday, February 02, 2004 10:28 AM To: Branislav Meandzija; Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR =09 =09 ok, I'll bite. =09 Please explain to me how load balancing works using model 2 below when the AP has a very finite amount of time to respond, and must make decisions that require access to load information from surrounding APs. =09 oh, and this has to scale. =09 PatC =09 =09 -----Original Message----- From: Branislav Meandzija [mailto:bran@arraycomm.com] Sent: Mon 2/2/2004 10:19 AM To: Pat R. Calhoun; Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR =09 =09 My comments in-line. =09 Branislav -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On Behalf Of Pat R. Calhoun Sent: Saturday, January 31, 2004 2:41 PM To: Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR =09 =09 I believe you are correct. It really boils down to one of three options: =09 1. Leave things as-is, 2. Implement a centralized network management component (what you are describing) 3. A centralized controller approach =09 Of course, option 1 will always exist, and there are markets where this approach makes sense. =09 As far as option 2, I believe that there are some pretty severe drawbacks. For instance, RF management really needs access to RF information on a packet-by-packet basis. RF information is not just a single value (e.g. 1 is good), but really consists of various measurements some of which are specific to each clients. It is possible for APs to constantly be polled for this information and let a network manager run algorithms. However, I believe that for those of us that have lived through the dial-up NAS markets in the mid-90s, some may recall the NASes that would be polled frequently for "user information", and the fact that these events caused a severe CPU drain on the NASes. =09 ----- Times they are achangin! We have quite different processing and communications capabilities Today. And even Yesterday, look at the cable modem RF MIB. ----- RF information is even more dynamic, and I suspect that there would be additional problems. There is also the issue where this option STILL requires that security information (specifically passwords for RADIUS, SNMP, etc) be stored in flash, and this is a big concern for IT managers. Lastly, it seems like everyone (even the incumbents are moving towards option 3). =09 ----- Actually the opposite is true. The latest architectural solutions make the BS autonomous. Nobody likes to pay for and maintain heavy infrastructure. ----- =09 Obviously, I'm in favor of option 3. If you just look at the cellular market, which evolved through the first two options, I believe that the current RAN approach of centralizing functionality in the base station has made these networks scale. =09 I believe that we would try to benefit from the lessons learned in both the dial-up and the cellular networks here in CAPWAP. ----- I agree with that but with obviously a different conclusion. ----- =09 PatC =09 =09 -----Original Message----- From: Yang, Lily L [mailto:lily.l.yang@intel.com] Sent: Sat 1/31/2004 2:24 PM To: Pat R. Calhoun; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR =09 I understand the concern. I don't know how much interoperability we can achieve either. But it seems like that is the market reality we are facing today. So we need to figure out what role, if there is a role, for IETF to do here to achieve any interoperability. I think that is why the charter calls for some architectural study first. The feasibility is still an open question to me. =09 =09 =09 I believe even the standalone AP can still benefit from the existence of a centralized controller to achieve network-wide RF management and configuration. Of course, then it is not a strictly "standalone" AP any more, but it may still be a pretty fat AP, handling some local decisions (e.g., association) on its own, without forwarding every single packet to the controller. I would think IETF/CAPWPA can still play a role in such architecture. =09 =09 =09 -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Saturday, January 31, 2004 2:01 PM To: Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR =09 =09 =09 I'm deeply concerned about the concept of "architecture variants". What this smells like to me is having multiple different architectures that don't interoperate. I see this as adding complexity to the market (and more specifically to the end user), and hampering interoperability. =09 Of course, we'll always have stand-alone APs... and I don't see why the IETF needs to be concerned about those. We should be focused on how to provide a scalable solution. =09 my 2 cents, =09 PatC -----Original Message----- From: capwap-admin@frascone.com on behalf of Yang, Lily L Sent: Fri 1/30/2004 10:07 AM To: Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR =09 It is conceivable that AP could just stick to one architecture variant, depending on the target market, price point, etc., while AC might have more flexibility to support multiple variants, esp. if the functions required on AC for b is a superset for a., then supporting b means it can also support a -- but this could be grossly simplified view, so don't take it too literally. But there might be ways to accomplish some level of interoperability across the spectrum. =09 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Peyush AGARWAL Sent: Thursday, January 29, 2004 10:02 PM To: 'Bob O'Hara'; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR =09 That sounds good & informative. =09 But again to make the things more clear; using Capability Negotiations is it possible that we have a topology where: =09 AC is on ARCH - x and the APs present in the network are on ARCH - a, b, c (where a/b/c !=3D x) ? =09 If the answer is yes, I feel that one has to end up implementing everything in APs as well as ACs!! =09 Regards, Peyush. =09 =09 =09 =09 =09 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Bob O'Hara Sent: Wednesday, January 28, 2004 10:42 PM To: Peyush AGARWAL; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR =09 =09 Peyush, =09 The negotiation between the AP and AR would not have anything to do with the 802.11 capabilities advertised in the 802.11 Beacon frame. The capabilities in the proposed negotiation between AP and AR would have to do with what functions are available at either end of that protocol exchange. This was included in the draft to address the various functional splits that are already present in the several products already in the market. =09 One example of a function that might be part of this negotiation is which parts of the 802.11 MAC management functionality would be implemented in the AP and which parts would be implemented in the AR. There are examples of products in the market that implement all of the MAC management in the AR-equivalent device, some that move various parts of that to the AP, and some others that implement all of it in the AP. =09 -Bob =09 =09 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Peyush AGARWAL Sent: Wednesday, January 28, 2004 4:23 AM To: capwap@frascone.com Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR =09 =09 Hi, =09 The "Capabilities Negotiation" has been proposed in the Architecture draft (draft-mani-ietf-capwap-arch-00) with the intention of deciding 'the applicable API's between AP and AC'. The 802.11 'Beacons' already contains the information of the capabilities supported by the AP, therefore the requirement of 'capabilities negotiation' is not clear to me. Please clarify. =09 Thanks in advance. =09 Regards, Peyush. =09 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap =09 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap =09 =09 =09 =09 From pcalhoun@airespace.com Mon Feb 2 19:29:39 2004 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Mon, 2 Feb 2004 11:29:39 -0800 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Message-ID: <55749BC69138654EBBC4C50BA4F55610ADC82C@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E9C3.13E0D416 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please explain to me how load balancing works using model 2 below when = the AP has a very finite amount of time to respond, and must make decisions = that require access to load information from surrounding APs. What type of network are you referring to? Bellow you were making = comments about cellular networks and trends which IMHO are incorrect. In = cellular, there is a variety of technologies which can be based, for = example, on the BS simply sending to mobiles a load factor and leaving = it up to mobiles to decide which BS to pick. As far as I know, this is not the way things work today. The = network controls where the client goes, not the other way around. Also, = the behavior you are describing is exactly how APs work today, and I = think that most of us that are involved in this on a day to day basis = agree that this is not a workable system - otherwise, load balancing = really would work. PatC ------_=_NextPart_001_01C3E9C3.13E0D416 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Capwap] Reg. Capabilities Negotiation between AP - = AR

Please explain to me how load balancing works using = model 2 below when the
AP has a very finite amount of time to respond, and must make decisions = that
require access to load information from surrounding APs.

<BM> What type of network are you referring to? Bellow you were = making comments about cellular networks and trends which IMHO are = incorrect. In cellular, there is a variety of technologies which can be = based, for example, on the BS simply sending to mobiles a load factor = and leaving it up to mobiles to decide which BS to pick.

<PRC> As far as I know, this is not the way things work today. The = network controls where the client goes, not the other way around. Also, = the behavior you are describing is exactly how APs work today, and I = think that most of us that are involved in this on a day to day basis = agree that this is not a workable system - otherwise, load balancing = really would work.

PatC

------_=_NextPart_001_01C3E9C3.13E0D416-- From pcalhoun@airespace.com Mon Feb 2 19:31:12 2004 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Mon, 2 Feb 2004 11:31:12 -0800 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Message-ID: <55749BC69138654EBBC4C50BA4F55610ADC82D@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E9C3.364591FB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Model 2: Centralized management system polls the APs for MIB information = and make decisions. Model 3: Centralized controller sees all packets and does decisions in = real time. patC -----Original Message----- From: Putzolu, David [mailto:david.putzolu@intel.com] Sent: Mon 2/2/2004 11:12 AM To: Pat R. Calhoun; Branislav Meandzija; Yang, Lily L; Peyush AGARWAL; = Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR =20 What is the current engineering practice for load balancing? If they are all model 3 (although I have to admit I am not totally clear on the difference between 2 and 3) then it would seem to be the right place to start. If they are a mix between 2 and 3, then the WG would need to decide whether to intentionally exclude some current solutions, or to come up with an architecture flexible enough to support both. Cheers, David Putzolu=20 ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun Sent: Monday, February 02, 2004 10:28 AM To: Branislav Meandzija; Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR =09 =09 ok, I'll bite. =09 Please explain to me how load balancing works using model 2 below when the AP has a very finite amount of time to respond, and must make decisions that require access to load information from surrounding APs. =09 oh, and this has to scale. =09 PatC =09 =09 -----Original Message----- From: Branislav Meandzija [mailto:bran@arraycomm.com] Sent: Mon 2/2/2004 10:19 AM To: Pat R. Calhoun; Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR =09 =09 My comments in-line. =09 Branislav -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On Behalf Of Pat R. Calhoun Sent: Saturday, January 31, 2004 2:41 PM To: Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR =09 =09 I believe you are correct. It really boils down to one of three options: =09 1. Leave things as-is, 2. Implement a centralized network management component (what you are describing) 3. A centralized controller approach =09 Of course, option 1 will always exist, and there are markets where this approach makes sense. =09 As far as option 2, I believe that there are some pretty severe drawbacks. For instance, RF management really needs access to RF information on a packet-by-packet basis. RF information is not just a single value (e.g. 1 is good), but really consists of various measurements some of which are specific to each clients. It is possible for APs to constantly be polled for this information and let a network manager run algorithms. However, I believe that for those of us that have lived through the dial-up NAS markets in the mid-90s, some may recall the NASes that would be polled frequently for "user information", and the fact that these events caused a severe CPU drain on the NASes. =09 ----- Times they are achangin! We have quite different processing and communications capabilities Today. And even Yesterday, look at the cable modem RF MIB. ----- RF information is even more dynamic, and I suspect that there would be additional problems. There is also the issue where this option STILL requires that security information (specifically passwords for RADIUS, SNMP, etc) be stored in flash, and this is a big concern for IT managers. Lastly, it seems like everyone (even the incumbents are moving towards option 3). =09 ----- Actually the opposite is true. The latest architectural solutions make the BS autonomous. Nobody likes to pay for and maintain heavy infrastructure. ----- =09 Obviously, I'm in favor of option 3. If you just look at the cellular market, which evolved through the first two options, I believe that the current RAN approach of centralizing functionality in the base station has made these networks scale. =09 I believe that we would try to benefit from the lessons learned in both the dial-up and the cellular networks here in CAPWAP. ----- I agree with that but with obviously a different conclusion. ----- =09 PatC =09 =09 -----Original Message----- From: Yang, Lily L [mailto:lily.l.yang@intel.com] Sent: Sat 1/31/2004 2:24 PM To: Pat R. Calhoun; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR =09 I understand the concern. I don't know how much interoperability we can achieve either. But it seems like that is the market reality we are facing today. So we need to figure out what role, if there is a role, for IETF to do here to achieve any interoperability. I think that is why the charter calls for some architectural study first. The feasibility is still an open question to me. =09 =09 =09 I believe even the standalone AP can still benefit from the existence of a centralized controller to achieve network-wide RF management and configuration. Of course, then it is not a strictly "standalone" AP any more, but it may still be a pretty fat AP, handling some local decisions (e.g., association) on its own, without forwarding every single packet to the controller. I would think IETF/CAPWPA can still play a role in such architecture. =09 =09 =09 -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Saturday, January 31, 2004 2:01 PM To: Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR =09 =09 =09 I'm deeply concerned about the concept of "architecture variants". What this smells like to me is having multiple different architectures that don't interoperate. I see this as adding complexity to the market (and more specifically to the end user), and hampering interoperability. =09 Of course, we'll always have stand-alone APs... and I don't see why the IETF needs to be concerned about those. We should be focused on how to provide a scalable solution. =09 my 2 cents, =09 PatC -----Original Message----- From: capwap-admin@frascone.com on behalf of Yang, Lily L Sent: Fri 1/30/2004 10:07 AM To: Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR =09 It is conceivable that AP could just stick to one architecture variant, depending on the target market, price point, etc., while AC might have more flexibility to support multiple variants, esp. if the functions required on AC for b is a superset for a., then supporting b means it can also support a -- but this could be grossly simplified view, so don't take it too literally. But there might be ways to accomplish some level of interoperability across the spectrum. =09 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Peyush AGARWAL Sent: Thursday, January 29, 2004 10:02 PM To: 'Bob O'Hara'; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR =09 That sounds good & informative. =09 But again to make the things more clear; using Capability Negotiations is it possible that we have a topology where: =09 AC is on ARCH - x and the APs present in the network are on ARCH - a, b, c (where a/b/c !=3D x) ? =09 If the answer is yes, I feel that one has to end up implementing everything in APs as well as ACs!! =09 Regards, Peyush. =09 =09 =09 =09 =09 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Bob O'Hara Sent: Wednesday, January 28, 2004 10:42 PM To: Peyush AGARWAL; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR =09 =09 Peyush, =09 The negotiation between the AP and AR would not have anything to do with the 802.11 capabilities advertised in the 802.11 Beacon frame. The capabilities in the proposed negotiation between AP and AR would have to do with what functions are available at either end of that protocol exchange. This was included in the draft to address the various functional splits that are already present in the several products already in the market. =09 One example of a function that might be part of this negotiation is which parts of the 802.11 MAC management functionality would be implemented in the AP and which parts would be implemented in the AR. There are examples of products in the market that implement all of the MAC management in the AR-equivalent device, some that move various parts of that to the AP, and some others that implement all of it in the AP. =09 -Bob =09 =09 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Peyush AGARWAL Sent: Wednesday, January 28, 2004 4:23 AM To: capwap@frascone.com Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR =09 =09 Hi, =09 The "Capabilities Negotiation" has been proposed in the Architecture draft (draft-mani-ietf-capwap-arch-00) with the intention of deciding 'the applicable API's between AP and AC'. The 802.11 'Beacons' already contains the information of the capabilities supported by the AP, therefore the requirement of 'capabilities negotiation' is not clear to me. Please clarify. =09 Thanks in advance. =09 Regards, Peyush. =09 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap =09 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap =09 =09 =09 =09 ------_=_NextPart_001_01C3E9C3.364591FB Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Capwap] Reg. Capabilities Negotiation between AP - = AR

Model 2: Centralized management system polls the APs = for MIB information and make decisions.

Model 3: Centralized controller sees all packets and does decisions in = real time.

patC
-----Original Message-----
From: Putzolu, David [mailto:david.putzolu@intel.com]
Sent: Mon 2/2/2004 11:12 AM
To: Pat R. Calhoun; Branislav Meandzija; Yang, Lily L; Peyush AGARWAL; = Bob O'Hara; capwap@frascone.com
Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR

What is the current engineering practice for load balancing?

If they are all model 3 (although I have to admit I am not totally
clear on the difference between 2 and 3) then it would seem to be
the right place to start. If they are a mix between 2 and 3, then
the WG would need to decide whether to intentionally exclude some
current solutions, or to come up with an architecture flexible
enough to support both.

Cheers,
David Putzolu


________________________________

        From: = capwap-admin@frascone.com
[
mailto:capwap-admin@frascone.co= m] On Behalf Of Pat R. Calhoun
        Sent: Monday, February 02, = 2004 10:28 AM
        To: Branislav Meandzija; = Yang, Lily L; Peyush AGARWAL; Bob
O'Hara; capwap@frascone.com
        Subject: RE: [Capwap] Reg. = Capabilities Negotiation between AP -
AR
       
       

        ok, I'll bite.
       
        Please explain to me how load = balancing works using model 2
below when the
        AP has a very finite amount = of time to respond, and must make
decisions that
        require access to load = information from surrounding APs.
       
        oh, and this has to = scale.
       
        PatC
       
       
        -----Original = Message-----
        From: Branislav Meandzija [mailto:bran@arraycomm.com]
        Sent: Mon 2/2/2004 10:19 = AM
        To: Pat R. Calhoun; Yang, = Lily L; Peyush AGARWAL; Bob O'Hara;
capwap@frascone.com
        Subject: RE: [Capwap] Reg. = Capabilities Negotiation between AP -
AR
       
       
        My comments in-line.
       
        Branislav
        -----Original = Message-----
        From: = capwap-admin@frascone.com
[mailto:capwap-admin@frascone.co= m]On Behalf Of Pat R. Calhoun
        Sent: Saturday, January 31, = 2004 2:41 PM
        To: Yang, Lily L; Peyush = AGARWAL; Bob O'Hara;
capwap@frascone.com
        Subject: RE: [Capwap] Reg. = Capabilities Negotiation between AP -
AR
       
       
        I believe you are correct. It = really boils down to one of three
options:
       
        1. Leave things as-is,
        2. Implement a centralized = network management component (what
you are describing)
        3. A centralized controller = approach
       
        Of course, option 1 will = always exist, and there are markets
where this approach
        makes sense.
       
        As far as option 2, I believe = that there are some pretty severe
drawbacks. For instance,
        RF management really needs = access to RF information on a
packet-by-packet basis. RF information
        is not just a single value = (e.g. 1 is good), but really consists
of various measurements some
        of which are specific to each = clients. It is possible for APs to
constantly be polled for this
        information and let a network = manager run algorithms. However, I
believe that for those of us
        that have lived through the = dial-up NAS markets in the mid-90s,
some may recall the NASes that
        would be polled frequently = for "user information", and the fact
that these events caused a severe
        CPU drain on the NASes.
       
        -----
        <BM> Times they are = achangin! We have quite different processing
and communications capabilities Today. And
        even Yesterday, look at the = cable modem RF MIB.
        -----
        RF information is even more = dynamic, and I suspect that there
would be
        additional problems. There is = also the issue where this option
STILL requires that security
        information (specifically = passwords for RADIUS, SNMP, etc) be
stored in flash, and this is a
        big concern for IT managers. = Lastly, it seems like everyone
(even the incumbents are moving towards
        option 3).
       
        -----
        <BM> Actually the = opposite is true. The latest architectural
solutions make the BS autonomous. Nobody likes
        to pay for and maintain heavy = infrastructure.
        -----
       
        Obviously, I'm in favor of = option 3. If you just look at the
cellular market, which evolved through
        the first two options, I = believe that the current RAN approach
of centralizing functionality in the
        base station has made these = networks scale.
       
        I believe that we would try = to benefit from the lessons learned
in both the dial-up and the cellular
        networks here in CAPWAP.
        -----
        <BM> I agree with that = but with obviously a different
conclusion.
        -----
       
        PatC
       
       
        -----Original = Message-----
        From: Yang, Lily L [mailto:lily.l.yang@intel.com]         Sent: Sat 1/31/2004 2:24 = PM
        To: Pat R. Calhoun; Peyush = AGARWAL; Bob O'Hara;
capwap@frascone.com
        Subject: RE: [Capwap] Reg. = Capabilities Negotiation between AP -
AR
       
        I understand the concern. I = don't know how much interoperability
we can
        achieve either. But it seems = like that is the market reality we
are
        facing today. So we need to = figure out what role, if there is a
role,
        for IETF to do here to = achieve any interoperability. I think
that is why
        the charter calls for some = architectural study first. The
feasibility is
        still an open question to = me.
       
       
       
        I believe even the standalone = AP can still benefit from the
existence of
        a centralized controller to = achieve network-wide RF management
and
        configuration. Of course, = then it is not a strictly "standalone"
AP any
        more, but it may still be a = pretty fat AP, handling some local
decisions
        (e.g., association) on its = own, without forwarding every single
packet
        to the controller. I would = think IETF/CAPWPA can still play a
role in
        such architecture.
       
       
       
        -----Original = Message-----
        From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]=
        Sent: Saturday, January 31, = 2004 2:01 PM
        To: Yang, Lily L; Peyush = AGARWAL; Bob O'Hara;
capwap@frascone.com
        Subject: RE: [Capwap] Reg. = Capabilities Negotiation between AP -
AR
       
       
       
        I'm deeply concerned about = the concept of "architecture
variants". What
        this smells like to me is = having multiple different
architectures that
        don't interoperate. I see = this as adding complexity to the
market (and
        more specifically to the end = user), and hampering
interoperability.
       
        Of course, we'll always have = stand-alone APs... and I don't see
why the
        IETF needs to be concerned = about those. We should be focused on
how to
        provide a scalable = solution.
       
        my 2 cents,
       
        PatC
        -----Original = Message-----
        From: = capwap-admin@frascone.com on behalf of Yang, Lily L
        Sent: Fri 1/30/2004 10:07 = AM
        To: Peyush AGARWAL; Bob = O'Hara; capwap@frascone.com
        Subject: RE: [Capwap] Reg. = Capabilities Negotiation between AP -
AR
       
        It is conceivable that AP = could just stick to one architecture
variant,
        depending on the target = market, price point, etc., while AC
might have
        more flexibility to support = multiple variants, esp. if the
functions
        required on AC for b is a = superset for a., then supporting b
means it
        can also support a -- but = this could be grossly simplified view,
so
        don't take it too literally. = But there might be ways to
accomplish some
        level of interoperability = across the spectrum.
       
        -----Original = Message-----
        From: = capwap-admin@frascone.com
[mailto:capwap-admin@frascone.co= m] On
        Behalf Of Peyush AGARWAL
        Sent: Thursday, January 29, = 2004 10:02 PM
        To: 'Bob O'Hara'; = capwap@frascone.com
        Subject: RE: [Capwap] Reg. = Capabilities Negotiation between AP -
AR
       
        That sounds good & = informative.
       
        But again to make the things = more clear; using Capability
Negotiations
        is it
        possible that we have a = topology where:
       
        =         AC is on ARCH - x and
        =         the APs present in the = network are on ARCH - a, b, c
(where
        a/b/c !=3D
        x) ?
       
        If the answer is yes, I feel = that one has to end up implementing
        everything
        in APs as well as ACs!!
       
        Regards,
        Peyush.
       
       
       
       
       
        -----Original = Message-----
        From: = capwap-admin@frascone.com
[mailto:capwap-admin@frascone.co= m] On
        Behalf
        Of Bob O'Hara
        Sent: Wednesday, January 28, = 2004 10:42 PM
        To: Peyush AGARWAL; = capwap@frascone.com
        Subject: RE: [Capwap] Reg. = Capabilities Negotiation between AP -
AR
       
       
        Peyush,
       
        The negotiation between the = AP and AR would not have anything to
do with
        the
        802.11 capabilities = advertised in the 802.11 Beacon frame.  The
        capabilities
        in the proposed negotiation = between AP and AR would have to do
with what
        functions are available at = either end of that protocol exchange.
This
        was
        included in the draft to = address the various functional splits
that are
        already present in the = several products already in the market.
       
        One example of a function = that might be part of this negotiation
is
        which
        parts of the 802.11 MAC = management functionality would be
implemented in
        the
        AP and which parts would be = implemented in the AR. There are
examples of
        products in the market that = implement all of the MAC management
in the
        AR-equivalent device, some = that move various parts of that to
the AP,
        and
        some others that implement = all of it in the AP.
       
         -Bob
       
       
        -----Original = Message-----
        From: = capwap-admin@frascone.com
[mailto:capwap-admin@frascone.co= m] On
        Behalf
        Of Peyush AGARWAL
        Sent: Wednesday, January 28, = 2004 4:23 AM
        To: capwap@frascone.com
        Subject: [Capwap] Reg. = Capabilities Negotiation between AP - AR
       
       
        Hi,
       
        The "Capabilities = Negotiation" has been proposed in the
Architecture
        draft
        = (draft-mani-ietf-capwap-arch-00) with the intention of deciding
'the
        applicable API's between AP = and AC'.
        =         The 802.11 'Beacons' already = contains the information of
the
        capabilities supported by the = AP, therefore the requirement of
        'capabilities
        negotiation' is not clear to = me. Please clarify.
       
        Thanks in advance.
       
        Regards,
        Peyush.
       
        = _______________________________________________
        Capwap mailing list
        Capwap@frascone.com
http://mail.fra= scone.com/mailman/listinfo/capwap
        = _______________________________________________
        Capwap mailing list
        Capwap@frascone.com
http://mail.fra= scone.com/mailman/listinfo/capwap
       
        = _______________________________________________
        Capwap mailing list
        Capwap@frascone.com
        http://mail.fra= scone.com/mailman/listinfo/capwap
        = _______________________________________________
        Capwap mailing list
        Capwap@frascone.com
        http://mail.fra= scone.com/mailman/listinfo/capwap
       
       
       
       




------_=_NextPart_001_01C3E9C3.364591FB-- From kempf@docomolabs-usa.com Mon Feb 2 19:43:01 2004 From: kempf@docomolabs-usa.com (James Kempf) Date: Mon, 2 Feb 2004 11:43:01 -0800 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR References: <52D13A805349A249960B9943E5590BD8022CF069@orsmsx409.jf.intel.com> Message-ID: <01fd01c3e9c4$c549b630$936015ac@dclkempt40> David, I think there is no load balancing on APs that are designed according to the standard autonomous AP architecture (i.e. model 1), unless someone has come up with a product quite recently that uses a centralized management model (i.e. model 2). The LWAP vendors use model 3, i.e. the centralized controller approach. jak ----- Original Message ----- From: "Putzolu, David" To: "Pat R. Calhoun" ; "Branislav Meandzija" ; "Yang, Lily L" ; "Peyush AGARWAL" ; "Bob O'Hara" ; Sent: Monday, February 02, 2004 11:12 AM Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR > What is the current engineering practice for load balancing? > > If they are all model 3 (although I have to admit I am not totally > clear on the difference between 2 and 3) then it would seem to be > the right place to start. If they are a mix between 2 and 3, then > the WG would need to decide whether to intentionally exclude some > current solutions, or to come up with an architecture flexible > enough to support both. > > Cheers, > David Putzolu > > > ________________________________ > > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun > Sent: Monday, February 02, 2004 10:28 AM > To: Branislav Meandzija; Yang, Lily L; Peyush AGARWAL; Bob > O'Hara; capwap@frascone.com > Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - > AR > > > > ok, I'll bite. > > Please explain to me how load balancing works using model 2 > below when the > AP has a very finite amount of time to respond, and must make > decisions that > require access to load information from surrounding APs. > > oh, and this has to scale. > > PatC > > > -----Original Message----- > From: Branislav Meandzija [mailto:bran@arraycomm.com] > Sent: Mon 2/2/2004 10:19 AM > To: Pat R. Calhoun; Yang, Lily L; Peyush AGARWAL; Bob O'Hara; > capwap@frascone.com > Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - > AR > > > My comments in-line. > > Branislav > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com]On Behalf Of Pat R. Calhoun > Sent: Saturday, January 31, 2004 2:41 PM > To: Yang, Lily L; Peyush AGARWAL; Bob O'Hara; > capwap@frascone.com > Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - > AR > > > I believe you are correct. It really boils down to one of three > options: > > 1. Leave things as-is, > 2. Implement a centralized network management component (what > you are describing) > 3. A centralized controller approach > > Of course, option 1 will always exist, and there are markets > where this approach > makes sense. > > As far as option 2, I believe that there are some pretty severe > drawbacks. For instance, > RF management really needs access to RF information on a > packet-by-packet basis. RF information > is not just a single value (e.g. 1 is good), but really consists > of various measurements some > of which are specific to each clients. It is possible for APs to > constantly be polled for this > information and let a network manager run algorithms. However, I > believe that for those of us > that have lived through the dial-up NAS markets in the mid-90s, > some may recall the NASes that > would be polled frequently for "user information", and the fact > that these events caused a severe > CPU drain on the NASes. > > ----- > Times they are achangin! We have quite different processing > and communications capabilities Today. And > even Yesterday, look at the cable modem RF MIB. > ----- > RF information is even more dynamic, and I suspect that there > would be > additional problems. There is also the issue where this option > STILL requires that security > information (specifically passwords for RADIUS, SNMP, etc) be > stored in flash, and this is a > big concern for IT managers. Lastly, it seems like everyone > (even the incumbents are moving towards > option 3). > > ----- > Actually the opposite is true. The latest architectural > solutions make the BS autonomous. Nobody likes > to pay for and maintain heavy infrastructure. > ----- > > Obviously, I'm in favor of option 3. If you just look at the > cellular market, which evolved through > the first two options, I believe that the current RAN approach > of centralizing functionality in the > base station has made these networks scale. > > I believe that we would try to benefit from the lessons learned > in both the dial-up and the cellular > networks here in CAPWAP. > ----- > I agree with that but with obviously a different > conclusion. > ----- > > PatC > > > -----Original Message----- > From: Yang, Lily L [mailto:lily.l.yang@intel.com] > Sent: Sat 1/31/2004 2:24 PM > To: Pat R. Calhoun; Peyush AGARWAL; Bob O'Hara; > capwap@frascone.com > Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - > AR > > I understand the concern. I don't know how much interoperability > we can > achieve either. But it seems like that is the market reality we > are > facing today. So we need to figure out what role, if there is a > role, > for IETF to do here to achieve any interoperability. I think > that is why > the charter calls for some architectural study first. The > feasibility is > still an open question to me. > > > > I believe even the standalone AP can still benefit from the > existence of > a centralized controller to achieve network-wide RF management > and > configuration. Of course, then it is not a strictly "standalone" > AP any > more, but it may still be a pretty fat AP, handling some local > decisions > (e.g., association) on its own, without forwarding every single > packet > to the controller. I would think IETF/CAPWPA can still play a > role in > such architecture. > > > > -----Original Message----- > From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] > Sent: Saturday, January 31, 2004 2:01 PM > To: Yang, Lily L; Peyush AGARWAL; Bob O'Hara; > capwap@frascone.com > Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - > AR > > > > I'm deeply concerned about the concept of "architecture > variants". What > this smells like to me is having multiple different > architectures that > don't interoperate. I see this as adding complexity to the > market (and > more specifically to the end user), and hampering > interoperability. > > Of course, we'll always have stand-alone APs... and I don't see > why the > IETF needs to be concerned about those. We should be focused on > how to > provide a scalable solution. > > my 2 cents, > > PatC > -----Original Message----- > From: capwap-admin@frascone.com on behalf of Yang, Lily L > Sent: Fri 1/30/2004 10:07 AM > To: Peyush AGARWAL; Bob O'Hara; capwap@frascone.com > Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - > AR > > It is conceivable that AP could just stick to one architecture > variant, > depending on the target market, price point, etc., while AC > might have > more flexibility to support multiple variants, esp. if the > functions > required on AC for b is a superset for a., then supporting b > means it > can also support a -- but this could be grossly simplified view, > so > don't take it too literally. But there might be ways to > accomplish some > level of interoperability across the spectrum. > > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On > Behalf Of Peyush AGARWAL > Sent: Thursday, January 29, 2004 10:02 PM > To: 'Bob O'Hara'; capwap@frascone.com > Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - > AR > > That sounds good & informative. > > But again to make the things more clear; using Capability > Negotiations > is it > possible that we have a topology where: > > AC is on ARCH - x and > the APs present in the network are on ARCH - a, b, c > (where > a/b/c != > x) ? > > If the answer is yes, I feel that one has to end up implementing > everything > in APs as well as ACs!! > > Regards, > Peyush. > > > > > > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On > Behalf > Of Bob O'Hara > Sent: Wednesday, January 28, 2004 10:42 PM > To: Peyush AGARWAL; capwap@frascone.com > Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - > AR > > > Peyush, > > The negotiation between the AP and AR would not have anything to > do with > the > 802.11 capabilities advertised in the 802.11 Beacon frame. The > capabilities > in the proposed negotiation between AP and AR would have to do > with what > functions are available at either end of that protocol exchange. > This > was > included in the draft to address the various functional splits > that are > already present in the several products already in the market. > > One example of a function that might be part of this negotiation > is > which > parts of the 802.11 MAC management functionality would be > implemented in > the > AP and which parts would be implemented in the AR. There are > examples of > products in the market that implement all of the MAC management > in the > AR-equivalent device, some that move various parts of that to > the AP, > and > some others that implement all of it in the AP. > > -Bob > > > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On > Behalf > Of Peyush AGARWAL > Sent: Wednesday, January 28, 2004 4:23 AM > To: capwap@frascone.com > Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR > > > Hi, > > The "Capabilities Negotiation" has been proposed in the > Architecture > draft > (draft-mani-ietf-capwap-arch-00) with the intention of deciding > 'the > applicable API's between AP and AC'. > The 802.11 'Beacons' already contains the information of > the > capabilities supported by the AP, therefore the requirement of > 'capabilities > negotiation' is not clear to me. Please clarify. > > Thanks in advance. > > Regards, > Peyush. > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > From bran@arraycomm.com Mon Feb 2 19:44:13 2004 From: bran@arraycomm.com (Branislav Meandzija) Date: Mon, 2 Feb 2004 11:44:13 -0800 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Message-ID: <200402021946.i12JkWs5020324@lester.arraycomm.com> Please explain to me how load balancing works using model 2 below when the AP has a very finite amount of time to respond, and must make decisions tha= t require access to load information from surrounding APs. What type of network are you referring to? Bellow you were making comm= ents about cellular networks and trends which IMHO are incorrect. In cellul= ar, there is a variety of technologies which can be based, for example, on = the BS simply sending to mobiles a load factor and leaving it up to mobiles= to decide which BS to pick. As far as I know, this is not the way things work today. The network = controls where the client goes, not the other way around. Also, the behavio= r you are describing is exactly how APs work today, and I think that most o= f us that are involved in this on a day to day basis agree that this is not= a workable system - otherwise, load balancing really would work. That is why I said your claims regarding trends in cellular were incor= rect. Regarding APs, why don't you explain why mobile controlled solutions = don't work? Branislav From pcalhoun@airespace.com Mon Feb 2 19:57:12 2004 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Mon, 2 Feb 2004 11:57:12 -0800 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Message-ID: <55749BC69138654EBBC4C50BA4F55610ADC82F@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E9C6.BF679A4B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What type of network are you referring to? Bellow you were making = comments about cellular networks and trends which IMHO are incorrect. In = cellular, there is a variety of technologies which can be based, for = example, on the BS simply sending to mobiles a load factor and leaving = it up to mobiles to decide which BS to pick. As far as I know, this is not the way things work today. The = network controls where the client goes, not the other way around. Also, = the behavior you are describing is exactly how APs work today, and I = think that most of us that are involved in this on a day to day basis = agree that this is not a workable system - otherwise, load balancing = really would work. That is why I said your claims regarding trends in cellular were = incorrect. Regarding APs, why don't you explain why mobile controlled = solutions don't work? Sure. Let's just use the IETF as an example. you have a couple of = hundred of people, and the APs currently advertise their load (in some = proprietary fashion since there is no standard way to do this). The AP = currently advertises it's load and clients move based on this info.=20 So using the above, let's say AP1 only has 50% of the load of = other APs (of course, it doesn't actually know this, but the clients can = guess this based on what else it is hearing from other APs). So let's = say that 60% of the clients in the room gravitate towards AP1 in hopes = of getting better service (again, this is an automated process, not = something a user requests). Now, this creates an interesting problem = because the remaining APs in the room (let's say AP2 and AP3) are now = lightly loaded thanks to the gold-rush-like behavior that clients have. = So this behavior keeps occuring as clients are bouncing from AP to AP in = search of a better home.=20 Another interesting note here is that the load balancing decisions = are really made solely based the client's view of load, and really does = not factor in the network's resources and RF visibility. Ideally, a load = balancing decision is done based on load and RF connectivity, and the = latter can only be done if the load balancing decision is done while = understanding how the system sees the network (not just the AP). In any case, I think I've provided a sufficient amount of = justification here. If you really do believe that stand-alone APs work = fine, then I would urge you to speak to customers. PatC ------_=_NextPart_001_01C3E9C6.BF679A4B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Capwap] Reg. Capabilities Negotiation between AP - = AR

<BM> What type of network are you referring to? = Bellow you were making comments about cellular networks and trends which = IMHO are incorrect. In cellular, there is a variety of technologies = which can be based, for example, on the BS simply sending to mobiles a = load factor and leaving it up to mobiles to decide which BS to pick.

<PRC> As far as I know, this is not the way things work today. The = network controls where the client goes, not the other way around. Also, = the behavior you are describing is exactly how APs work today, and I = think that most of us that are involved in this on a day to day basis = agree that this is not a workable system - otherwise, load balancing = really would work.

<BM> That is why I said your claims regarding trends in cellular = were incorrect. Regarding APs, why don't you explain why mobile = controlled solutions don't work?

<PRC> Sure. Let's just use the IETF as an example. you have a = couple of hundred of people, and the APs currently advertise their load = (in some proprietary fashion since there is no standard way to do this). = The AP currently advertises it's load and clients move based on this = info.

<PRC> So using the above, let's say AP1 only has 50% of the load = of other APs (of course, it doesn't actually know this, but the clients = can guess this based on what else it is hearing from other APs). So = let's say that 60% of the clients in the room gravitate towards AP1 in = hopes of getting better service (again, this is an automated process, = not something a user requests). Now, this creates an interesting problem = because the remaining APs in the room (let's say AP2 and AP3) are now = lightly loaded thanks to the gold-rush-like behavior that clients have. = So this behavior keeps occuring as clients are bouncing from AP to AP in = search of a better home.

<PRC> Another interesting note here is that the load balancing = decisions are really made solely based the client's view of load, and = really does not factor in the network's resources and RF visibility. = Ideally, a load balancing decision is done based on load and RF = connectivity, and the latter can only be done if the load balancing = decision is done while understanding how the system sees the network = (not just the AP).

<PRC> In any case, I think I've provided a sufficient amount of = justification here. If you really do believe that stand-alone APs work = fine, then I would urge you to speak to customers.

PatC

------_=_NextPart_001_01C3E9C6.BF679A4B-- From kempf@docomolabs-usa.com Mon Feb 2 20:00:45 2004 From: kempf@docomolabs-usa.com (James Kempf) Date: Mon, 2 Feb 2004 12:00:45 -0800 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR References: <200402021946.i12JkWs5020324@lester.arraycomm.com> Message-ID: <022201c3e9c7$3f0287c0$936015ac@dclkempt40> > That is why I said your claims regarding trends in cellular were incorrect. Regarding APs, why don't you explain why mobile controlled solutions don't work? > Because the mobile doesn't have complete visibility into surrounding cells. It may only be able to hear a portion of other mobiles in the surrounding cells with 802.11. With other protocols, it may not be able to hear even those since it won't know the spreading codes (for CDMA for example) for other mobiles. Radio resource management requires some amount of network involvement. The centralized controller model is one example, another is a distributed RRM model, but, as far as I know, distributed RRM is a research topic. jak From bran@arraycomm.com Mon Feb 2 20:08:59 2004 From: bran@arraycomm.com (Branislav Meandzija) Date: Mon, 2 Feb 2004 12:08:59 -0800 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Message-ID: <200402022011.i12KBIs5025394@lester.arraycomm.com> What type of network are you referring to? Bellow you were making comm= ents about cellular networks and trends which IMHO are incorrect. In cellul= ar, there is a variety of technologies which can be based, for example, on = the BS simply sending to mobiles a load factor and leaving it up to mobiles= to decide which BS to pick. As far as I know, this is not the way things work today. The network = controls where the client goes, not the other way around. Also, the behavio= r you are describing is exactly how APs work today, and I think that most o= f us that are involved in this on a day to day basis agree that this is not= a workable system - otherwise, load balancing really would work. That is why I said your claims regarding trends in cellular were incor= rect. Regarding APs, why don't you explain why mobile controlled solutions = don't work? Sure. Let's just use the IETF as an example. you have a couple of hun= dred of people, and the APs currently advertise their load (in some proprie= tary fashion since there is no standard way to do this). The AP currently a= dvertises it's load and clients move based on this info. So using the above, let's say AP1 only has 50% of the load of other A= Ps (of course, it doesn't actually know this, but the clients can guess thi= s based on what else it is hearing from other APs). So let's say that 60% o= f the clients in the room gravitate towards AP1 in hopes of getting better = service (again, this is an automated process, not something a user requests= ). Now, this creates an interesting problem because the remaining APs in th= e room (let's say AP2 and AP3) are now lightly loaded thanks to the gold-ru= sh-like behavior that clients have. So this behavior keeps occuring as clie= nts are bouncing from AP to AP in search of a better home. Another interesting note here is that the load balancing decisions ar= e really made solely based the client's view of load, and really does not f= actor in the network's resources and RF visibility. Ideally, a load balanci= ng decision is done based on load and RF connectivity, and the latter can o= nly be done if the load balancing decision is done while understanding how = the system sees the network (not just the AP). In any case, I think I've provided a sufficient amount of justificati= on here. If you really do believe that stand-alone APs work fine, then I wo= uld urge you to speak to customers. Thanks for spelling out your view. I appreciate that. I disagree with = your justification. A mobile based balancing solution needs to be well thou= ght out but is obviously superior because of infrastructure cost and scalin= g. Perhaps this is something for us to note (may be as a variant of all thr= ee Model) and the IEEE to consider. = Branislav From Michael.G.Williams@nokia.com Mon Feb 2 20:14:15 2004 From: Michael.G.Williams@nokia.com (Michael.G.Williams@nokia.com) Date: Mon, 2 Feb 2004 12:14:15 -0800 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Message-ID: <59A36C4D2F9E7243BEB522274F72C3030148BE8D@mvebe001.americas.nokia.com> An observation... that load balancing is a good example of a service = that the AC brings to enhance the IEEE 802.11 system. It is not a = service defined (fully) within the IEEE 802.11 MAC layer. Perhaps the architectural possibilities are pretty broad, where you look = at the matrix of variations in distributing the MAC service layer across = the AP's & AC, even limiting that matrix to what is out there today. = Most of the vendors doing the network management model don't care how = the MAC is partitioned, on purpose. Services outside the IEEE 802.11 MAC (and MAC enhancements that are in = the works like .11{e,i,k}) include such services key distribution, load = balancing, system wide monitoring, STA control, VLAN management, etc = will be in addition to those architectural possibilities. The network = management oriented vendors may be able to do some of these effectively, = others they may be less effective. The work in this group may suggest = that some of these services need to be in the MAC layer, or have MAC = layer support to work effectively. An architectural taxonomy might be structured to indicate the list of = services, their interfaces, where they reside, and which are either: = best extensions to the MAC; or need both network support and MAC = extension; or are fully independent of the MAC. Hope this helps. Michael -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On Behalf Of ext James Kempf Sent: Monday, February 02, 2004 11:43 AM To: Putzolu, David; Pat R. Calhoun; Branislav Meandzija; Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: Re: [Capwap] Reg. Capabilities Negotiation between AP - AR David, I think there is no load balancing on APs that are designed according to = the standard autonomous AP architecture (i.e. model 1), unless someone has = come up with a product quite recently that uses a centralized management = model (i.e. model 2). The LWAP vendors use model 3, i.e. the centralized controller approach. jak ----- Original Message -----=20 From: "Putzolu, David" To: "Pat R. Calhoun" ; "Branislav Meandzija" ; "Yang, Lily L" ; "Peyush AGARWAL" ; "Bob O'Hara" ; Sent: Monday, February 02, 2004 11:12 AM Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR > What is the current engineering practice for load balancing? > > If they are all model 3 (although I have to admit I am not totally > clear on the difference between 2 and 3) then it would seem to be > the right place to start. If they are a mix between 2 and 3, then > the WG would need to decide whether to intentionally exclude some > current solutions, or to come up with an architecture flexible > enough to support both. > > Cheers, > David Putzolu > > > ________________________________ > > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun > Sent: Monday, February 02, 2004 10:28 AM > To: Branislav Meandzija; Yang, Lily L; Peyush AGARWAL; Bob > O'Hara; capwap@frascone.com > Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - > AR > > > > ok, I'll bite. > > Please explain to me how load balancing works using model 2 > below when the > AP has a very finite amount of time to respond, and must make > decisions that > require access to load information from surrounding APs. > > oh, and this has to scale. > > PatC > > > -----Original Message----- > From: Branislav Meandzija [mailto:bran@arraycomm.com] > Sent: Mon 2/2/2004 10:19 AM > To: Pat R. Calhoun; Yang, Lily L; Peyush AGARWAL; Bob O'Hara; > capwap@frascone.com > Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - > AR > > > My comments in-line. > > Branislav > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com]On Behalf Of Pat R. Calhoun > Sent: Saturday, January 31, 2004 2:41 PM > To: Yang, Lily L; Peyush AGARWAL; Bob O'Hara; > capwap@frascone.com > Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - > AR > > > I believe you are correct. It really boils down to one of three > options: > > 1. Leave things as-is, > 2. Implement a centralized network management component (what > you are describing) > 3. A centralized controller approach > > Of course, option 1 will always exist, and there are markets > where this approach > makes sense. > > As far as option 2, I believe that there are some pretty severe > drawbacks. For instance, > RF management really needs access to RF information on a > packet-by-packet basis. RF information > is not just a single value (e.g. 1 is good), but really consists > of various measurements some > of which are specific to each clients. It is possible for APs to > constantly be polled for this > information and let a network manager run algorithms. However, I > believe that for those of us > that have lived through the dial-up NAS markets in the mid-90s, > some may recall the NASes that > would be polled frequently for "user information", and the fact > that these events caused a severe > CPU drain on the NASes. > > ----- > Times they are achangin! We have quite different processing > and communications capabilities Today. And > even Yesterday, look at the cable modem RF MIB. > ----- > RF information is even more dynamic, and I suspect that there > would be > additional problems. There is also the issue where this option > STILL requires that security > information (specifically passwords for RADIUS, SNMP, etc) be > stored in flash, and this is a > big concern for IT managers. Lastly, it seems like everyone > (even the incumbents are moving towards > option 3). > > ----- > Actually the opposite is true. The latest architectural > solutions make the BS autonomous. Nobody likes > to pay for and maintain heavy infrastructure. > ----- > > Obviously, I'm in favor of option 3. If you just look at the > cellular market, which evolved through > the first two options, I believe that the current RAN approach > of centralizing functionality in the > base station has made these networks scale. > > I believe that we would try to benefit from the lessons learned > in both the dial-up and the cellular > networks here in CAPWAP. > ----- > I agree with that but with obviously a different > conclusion. > ----- > > PatC > > > -----Original Message----- > From: Yang, Lily L [mailto:lily.l.yang@intel.com] > Sent: Sat 1/31/2004 2:24 PM > To: Pat R. Calhoun; Peyush AGARWAL; Bob O'Hara; > capwap@frascone.com > Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - > AR > > I understand the concern. I don't know how much interoperability > we can > achieve either. But it seems like that is the market reality we > are > facing today. So we need to figure out what role, if there is a > role, > for IETF to do here to achieve any interoperability. I think > that is why > the charter calls for some architectural study first. The > feasibility is > still an open question to me. > > > > I believe even the standalone AP can still benefit from the > existence of > a centralized controller to achieve network-wide RF management > and > configuration. Of course, then it is not a strictly "standalone" > AP any > more, but it may still be a pretty fat AP, handling some local > decisions > (e.g., association) on its own, without forwarding every single > packet > to the controller. I would think IETF/CAPWPA can still play a > role in > such architecture. > > > > -----Original Message----- > From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] > Sent: Saturday, January 31, 2004 2:01 PM > To: Yang, Lily L; Peyush AGARWAL; Bob O'Hara; > capwap@frascone.com > Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - > AR > > > > I'm deeply concerned about the concept of "architecture > variants". What > this smells like to me is having multiple different > architectures that > don't interoperate. I see this as adding complexity to the > market (and > more specifically to the end user), and hampering > interoperability. > > Of course, we'll always have stand-alone APs... and I don't see > why the > IETF needs to be concerned about those. We should be focused on > how to > provide a scalable solution. > > my 2 cents, > > PatC > -----Original Message----- > From: capwap-admin@frascone.com on behalf of Yang, Lily L > Sent: Fri 1/30/2004 10:07 AM > To: Peyush AGARWAL; Bob O'Hara; capwap@frascone.com > Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - > AR > > It is conceivable that AP could just stick to one architecture > variant, > depending on the target market, price point, etc., while AC > might have > more flexibility to support multiple variants, esp. if the > functions > required on AC for b is a superset for a., then supporting b > means it > can also support a -- but this could be grossly simplified view, > so > don't take it too literally. But there might be ways to > accomplish some > level of interoperability across the spectrum. > > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On > Behalf Of Peyush AGARWAL > Sent: Thursday, January 29, 2004 10:02 PM > To: 'Bob O'Hara'; capwap@frascone.com > Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - > AR > > That sounds good & informative. > > But again to make the things more clear; using Capability > Negotiations > is it > possible that we have a topology where: > > AC is on ARCH - x and > the APs present in the network are on ARCH - a, b, c > (where > a/b/c !=3D > x) ? > > If the answer is yes, I feel that one has to end up implementing > everything > in APs as well as ACs!! > > Regards, > Peyush. > > > > > > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On > Behalf > Of Bob O'Hara > Sent: Wednesday, January 28, 2004 10:42 PM > To: Peyush AGARWAL; capwap@frascone.com > Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - > AR > > > Peyush, > > The negotiation between the AP and AR would not have anything to > do with > the > 802.11 capabilities advertised in the 802.11 Beacon frame. The > capabilities > in the proposed negotiation between AP and AR would have to do > with what > functions are available at either end of that protocol exchange. > This > was > included in the draft to address the various functional splits > that are > already present in the several products already in the market. > > One example of a function that might be part of this negotiation > is > which > parts of the 802.11 MAC management functionality would be > implemented in > the > AP and which parts would be implemented in the AR. There are > examples of > products in the market that implement all of the MAC management > in the > AR-equivalent device, some that move various parts of that to > the AP, > and > some others that implement all of it in the AP. > > -Bob > > > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On > Behalf > Of Peyush AGARWAL > Sent: Wednesday, January 28, 2004 4:23 AM > To: capwap@frascone.com > Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR > > > Hi, > > The "Capabilities Negotiation" has been proposed in the > Architecture > draft > (draft-mani-ietf-capwap-arch-00) with the intention of deciding > 'the > applicable API's between AP and AC'. > The 802.11 'Beacons' already contains the information of > the > capabilities supported by the AP, therefore the requirement of > 'capabilities > negotiation' is not clear to me. Please clarify. > > Thanks in advance. > > Regards, > Peyush. > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From bran@arraycomm.com Mon Feb 2 20:08:59 2004 From: bran@arraycomm.com (Branislav Meandzija) Date: Mon, 2 Feb 2004 12:08:59 -0800 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Message-ID: <200402022109.i12L92s5006645@lester.arraycomm.com> What type of network are you referring to? Bellow you were making comm= ents about cellular networks and trends which IMHO are incorrect. In cellul= ar, there is a variety of technologies which can be based, for example, on = the BS simply sending to mobiles a load factor and leaving it up to mobiles= to decide which BS to pick. As far as I know, this is not the way things work today. The network = controls where the client goes, not the other way around. Also, the behavio= r you are describing is exactly how APs work today, and I think that most o= f us that are involved in this on a day to day basis agree that this is not= a workable system - otherwise, load balancing really would work. That is why I said your claims regarding trends in cellular were incor= rect. Regarding APs, why don't you explain why mobile controlled solutions = don't work? Sure. Let's just use the IETF as an example. you have a couple of hun= dred of people, and the APs currently advertise their load (in some proprie= tary fashion since there is no standard way to do this). The AP currently a= dvertises it's load and clients move based on this info. So using the above, let's say AP1 only has 50% of the load of other A= Ps (of course, it doesn't actually know this, but the clients can guess thi= s based on what else it is hearing from other APs). So let's say that 60% o= f the clients in the room gravitate towards AP1 in hopes of getting better = service (again, this is an automated process, not something a user requests= ). Now, this creates an interesting problem because the remaining APs in th= e room (let's say AP2 and AP3) are now lightly loaded thanks to the gold-ru= sh-like behavior that clients have. So this behavior keeps occuring as clie= nts are bouncing from AP to AP in search of a better home. Another interesting note here is that the load balancing decisions ar= e really made solely based the client's view of load, and really does not f= actor in the network's resources and RF visibility. Ideally, a load balanci= ng decision is done based on load and RF connectivity, and the latter can o= nly be done if the load balancing decision is done while understanding how = the system sees the network (not just the AP). In any case, I think I've provided a sufficient amount of justificati= on here. If you really do believe that stand-alone APs work fine, then I wo= uld urge you to speak to customers. Thanks for spelling out your view. I appreciate that. I disagree with = your justification. A mobile based balancing solution needs to be well thou= ght out but is obviously superior because of infrastructure cost and scalin= g. Perhaps this is something for us to note (may be as a variant of all thr= ee Model) and the IEEE to consider. = Branislav From bran@arraycomm.com Mon Feb 2 20:28:47 2004 From: bran@arraycomm.com (Branislav Meandzija) Date: Mon, 2 Feb 2004 12:28:47 -0800 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Message-ID: <200402022109.i12L9Ms5006725@lester.arraycomm.com> > = > > That is why I said your claims regarding trends in = > cellular were > incorrect. Regarding APs, why don't you explain why mobile controlled > solutions don't work? > > > = > Because the mobile doesn't have complete visibility into = > surrounding cells. > It may only be able to hear a portion of other mobiles in the = > surrounding > cells with 802.11. With other protocols, it may not be able = > to hear even > those since it won't know the spreading codes (for CDMA for = > example) for > other mobiles. I was talking about the mobile receiving load information from the AP/BS. Mobile controlled, possibly networked assisted, solutions are far superior = because of cost and scalability. Branislav > = > Radio resource management requires some amount of network = > involvement. The > centralized controller model is one example, another is a = > distributed RRM > model, but, as far as I know, distributed RRM is a research topic. > = > jak > From kempf@docomolabs-usa.com Mon Feb 2 21:17:12 2004 From: kempf@docomolabs-usa.com (James Kempf) Date: Mon, 2 Feb 2004 13:17:12 -0800 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR References: <200402022109.i12L9Ms5006725@lester.arraycomm.com> Message-ID: <027b01c3e9d1$ecd562f0$936015ac@dclkempt40> > I was talking about the mobile receiving load information from the AP/BS. > Mobile controlled, possibly networked assisted, solutions are far superior because > of cost and scalability. > What is to prevent all the mobiles from deciding to switch to a lightly loaded AP, and having that AP then become overloaded? Without some kind of distributed load management algorithm, in which the mobiles communicate amongst themselves about who will switch to the new AP, load balancing only by the mobile can cause instablity. Certainly, the APs can filter the load information, and present different information to different mobiles, in order to influence the mobile's decision. Is that what you mean by "network assisted"? jak From pcalhoun@airespace.com Mon Feb 2 21:19:29 2004 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Mon, 2 Feb 2004 13:19:29 -0800 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Message-ID: <55749BC69138654EBBC4C50BA4F55610ADC834@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E9D2.70203FBD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > I was talking about the mobile receiving load information from the = AP/BS. > Mobile controlled, possibly networked assisted, solutions are far = superior because > of cost and scalability. Perhaps, but I have yet to see evidence of that in a shipping product, = while=20 network controlled is shipping today and works. Further, I'd like to = understand the cost issue. Are we stating that there will be a 50 cent tax on all = WLAN systems that include a centralized model, or some other cost that is = less obvious to me? PatC ------_=_NextPart_001_01C3E9D2.70203FBD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Capwap] Reg. Capabilities Negotiation between AP - = AR

> I was talking about the mobile receiving load = information from the AP/BS.
> Mobile controlled, possibly networked assisted, solutions are far = superior because
> of cost and scalability.

Perhaps, but I have yet to see evidence of that in a shipping product, = while
network controlled is shipping today and works. Further, I'd like to = understand
the cost issue. Are we stating that there will be a 50 cent tax on all = WLAN
systems that include a centralized model, or some other cost that is = less obvious
to me?

PatC

------_=_NextPart_001_01C3E9D2.70203FBD-- From pcalhoun@airespace.com Mon Feb 2 21:21:23 2004 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Mon, 2 Feb 2004 13:21:23 -0800 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Message-ID: <55749BC69138654EBBC4C50BA4F55610ADC835@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E9D2.BCCADDCD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >> I was talking about the mobile receiving load information from the = AP/BS. >> Mobile controlled, possibly networked assisted, solutions are far = superior >>because >> of cost and scalability. >> > >What is to prevent all the mobiles from deciding to switch to a lightly >loaded AP, and having that AP then become overloaded? Without some kind = of >distributed load management algorithm, in which the mobiles communicate >amongst themselves about who will switch to the new AP, load balancing = only >by the mobile can cause instablity. > >Certainly, the APs can filter the load information, and present = different >information to different mobiles, in order to influence the mobile's >decision. Is that what you mean by "network assisted"? Or more importantly, maybe I want to deny access to specific APs due to = load, and how does letting the mobile decide where it wants to go help me in = my policy decisions? Why should I trust that the mobile is running the = right algorithm and is therefore not trying to create load problems on the=20 infrastructure? PatC ------_=_NextPart_001_01C3E9D2.BCCADDCD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Capwap] Reg. Capabilities Negotiation between AP - = AR

>> I was talking about the mobile receiving load = information from the AP/BS.
>> Mobile controlled, possibly networked assisted, solutions are = far superior
>>because
>> of cost and scalability.
>>
>
>What is to prevent all the mobiles from deciding to switch to a = lightly
>loaded AP, and having that AP then become overloaded? Without some = kind of
>distributed load management algorithm, in which the mobiles = communicate
>amongst themselves about who will switch to the new AP, load = balancing only
>by the mobile can cause instablity.
>
>Certainly, the APs can filter the load information, and present = different
>information to different mobiles, in order to influence the = mobile's
>decision. Is that what you mean by "network assisted"?

Or more importantly, maybe I want to deny access to specific APs due to = load,
and how does letting the mobile decide where it wants to go help me in = my
policy decisions? Why should I trust that the mobile is running the = right
algorithm and is therefore not trying to create load problems on the
infrastructure?

PatC

------_=_NextPart_001_01C3E9D2.BCCADDCD-- From bran@arraycomm.com Mon Feb 2 22:02:08 2004 From: bran@arraycomm.com (Branislav Meandzija) Date: Mon, 2 Feb 2004 14:02:08 -0800 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Message-ID: <200402022202.i12M2Ds5017351@lester.arraycomm.com> > I was talking about the mobile receiving load information from the AP/BS.= > Mobile controlled, possibly networked assisted, solutions are far superio= r because > of cost and scalability. Perhaps, but I have yet to see evidence of that in a shipping product, whil= e network controlled is shipping today and works. Further, I'd like to unders= tand the cost issue. Are we stating that there will be a 50 cent tax on all WLAN= systems that include a centralized model, or some other cost that is less o= bvious to me? PatC = Regarding shipping product in cellular systems, there are several I am= aware of. Regarding cost, eliminating boxes in the access network does awa= y with the cost of that box. In large scale deployments the difference can = be enormous. Branislav From bran@arraycomm.com Mon Feb 2 22:04:28 2004 From: bran@arraycomm.com (Branislav Meandzija) Date: Mon, 2 Feb 2004 14:04:28 -0800 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Message-ID: <200402022204.i12M4Ws5017805@lester.arraycomm.com> > = > > I was talking about the mobile receiving load information = > from the AP/BS. > > Mobile controlled, possibly networked assisted, solutions = > are far superior > because > > of cost and scalability. > > > = > What is to prevent all the mobiles from deciding to switch to = > a lightly > loaded AP, and having that AP then become overloaded? Without = > some kind of > distributed load management algorithm, in which the mobiles = > communicate > amongst themselves about who will switch to the new AP, load = > balancing only > by the mobile can cause instablity. No need for the mobiles to communicate with each other. > = > Certainly, the APs can filter the load information, and = > present different > information to different mobiles, in order to influence the mobile's > decision. Is that what you mean by "network assisted"? That is one way of doing it. Branislav From JBinder@extremenetworks.com Mon Feb 2 22:40:30 2004 From: JBinder@extremenetworks.com (Jim Binder) Date: Mon, 2 Feb 2004 14:40:30 -0800 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Message-ID: <4C8B0EA487B9554D910B0587CD91395C0208F40A@sc-msexch-03.extremenetworks.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3E9DD.8FD856F0 Content-Type: text/plain You might be want to look at the IETF RAP drafts/rfcs' as well because it's was tasked with a very similar problem (if was originally focused on RSVP admission control problem) on making real-time policy decisions based on load and congestion of the network in both a dynamic and static config models. /jsb _____ From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Monday, February 02, 2004 11:31 AM To: Putzolu, David; Branislav Meandzija; Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR Model 2: Centralized management system polls the APs for MIB information and make decisions. Model 3: Centralized controller sees all packets and does decisions in real time. patC -----Original Message----- From: Putzolu, David [mailto:david.putzolu@intel.com ] Sent: Mon 2/2/2004 11:12 AM To: Pat R. Calhoun; Branislav Meandzija; Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR What is the current engineering practice for load balancing? If they are all model 3 (although I have to admit I am not totally clear on the difference between 2 and 3) then it would seem to be the right place to start. If they are a mix between 2 and 3, then the WG would need to decide whether to intentionally exclude some current solutions, or to come up with an architecture flexible enough to support both. Cheers, David Putzolu ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com ] On Behalf Of Pat R. Calhoun Sent: Monday, February 02, 2004 10:28 AM To: Branislav Meandzija; Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR ok, I'll bite. Please explain to me how load balancing works using model 2 below when the AP has a very finite amount of time to respond, and must make decisions that require access to load information from surrounding APs. oh, and this has to scale. PatC -----Original Message----- From: Branislav Meandzija [mailto:bran@arraycomm.com ] Sent: Mon 2/2/2004 10:19 AM To: Pat R. Calhoun; Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR My comments in-line. Branislav -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com ]On Behalf Of Pat R. Calhoun Sent: Saturday, January 31, 2004 2:41 PM To: Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR I believe you are correct. It really boils down to one of three options: 1. Leave things as-is, 2. Implement a centralized network management component (what you are describing) 3. A centralized controller approach Of course, option 1 will always exist, and there are markets where this approach makes sense. As far as option 2, I believe that there are some pretty severe drawbacks. For instance, RF management really needs access to RF information on a packet-by-packet basis. RF information is not just a single value (e.g. 1 is good), but really consists of various measurements some of which are specific to each clients. It is possible for APs to constantly be polled for this information and let a network manager run algorithms. However, I believe that for those of us that have lived through the dial-up NAS markets in the mid-90s, some may recall the NASes that would be polled frequently for "user information", and the fact that these events caused a severe CPU drain on the NASes. ----- Times they are achangin! We have quite different processing and communications capabilities Today. And even Yesterday, look at the cable modem RF MIB. ----- RF information is even more dynamic, and I suspect that there would be additional problems. There is also the issue where this option STILL requires that security information (specifically passwords for RADIUS, SNMP, etc) be stored in flash, and this is a big concern for IT managers. Lastly, it seems like everyone (even the incumbents are moving towards option 3). ----- Actually the opposite is true. The latest architectural solutions make the BS autonomous. Nobody likes to pay for and maintain heavy infrastructure. ----- Obviously, I'm in favor of option 3. If you just look at the cellular market, which evolved through the first two options, I believe that the current RAN approach of centralizing functionality in the base station has made these networks scale. I believe that we would try to benefit from the lessons learned in both the dial-up and the cellular networks here in CAPWAP. ----- I agree with that but with obviously a different conclusion. ----- PatC -----Original Message----- From: Yang, Lily L [mailto:lily.l.yang@intel.com ] Sent: Sat 1/31/2004 2:24 PM To: Pat R. Calhoun; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR I understand the concern. I don't know how much interoperability we can achieve either. But it seems like that is the market reality we are facing today. So we need to figure out what role, if there is a role, for IETF to do here to achieve any interoperability. I think that is why the charter calls for some architectural study first. The feasibility is still an open question to me. I believe even the standalone AP can still benefit from the existence of a centralized controller to achieve network-wide RF management and configuration. Of course, then it is not a strictly "standalone" AP any more, but it may still be a pretty fat AP, handling some local decisions (e.g., association) on its own, without forwarding every single packet to the controller. I would think IETF/CAPWPA can still play a role in such architecture. -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com ] Sent: Saturday, January 31, 2004 2:01 PM To: Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR I'm deeply concerned about the concept of "architecture variants". What this smells like to me is having multiple different architectures that don't interoperate. I see this as adding complexity to the market (and more specifically to the end user), and hampering interoperability. Of course, we'll always have stand-alone APs... and I don't see why the IETF needs to be concerned about those. We should be focused on how to provide a scalable solution. my 2 cents, PatC -----Original Message----- From: capwap-admin@frascone.com on behalf of Yang, Lily L Sent: Fri 1/30/2004 10:07 AM To: Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR It is conceivable that AP could just stick to one architecture variant, depending on the target market, price point, etc., while AC might have more flexibility to support multiple variants, esp. if the functions required on AC for b is a superset for a., then supporting b means it can also support a -- but this could be grossly simplified view, so don't take it too literally. But there might be ways to accomplish some level of interoperability across the spectrum. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com ] On Behalf Of Peyush AGARWAL Sent: Thursday, January 29, 2004 10:02 PM To: 'Bob O'Hara'; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR That sounds good & informative. But again to make the things more clear; using Capability Negotiations is it possible that we have a topology where: AC is on ARCH - x and the APs present in the network are on ARCH - a, b, c (where a/b/c != x) ? If the answer is yes, I feel that one has to end up implementing everything in APs as well as ACs!! Regards, Peyush. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com ] On Behalf Of Bob O'Hara Sent: Wednesday, January 28, 2004 10:42 PM To: Peyush AGARWAL; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR Peyush, The negotiation between the AP and AR would not have anything to do with the 802.11 capabilities advertised in the 802.11 Beacon frame. The capabilities in the proposed negotiation between AP and AR would have to do with what functions are available at either end of that protocol exchange. This was included in the draft to address the various functional splits that are already present in the several products already in the market. One example of a function that might be part of this negotiation is which parts of the 802.11 MAC management functionality would be implemented in the AP and which parts would be implemented in the AR. There are examples of products in the market that implement all of the MAC management in the AR-equivalent device, some that move various parts of that to the AP, and some others that implement all of it in the AP. -Bob -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com ] On Behalf Of Peyush AGARWAL Sent: Wednesday, January 28, 2004 4:23 AM To: capwap@frascone.com Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Hi, The "Capabilities Negotiation" has been proposed in the Architecture draft (draft-mani-ietf-capwap-arch-00) with the intention of deciding 'the applicable API's between AP and AC'. The 802.11 'Beacons' already contains the information of the capabilities supported by the AP, therefore the requirement of 'capabilities negotiation' is not clear to me. Please clarify. Thanks in advance. Regards, Peyush. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap ------_=_NextPart_001_01C3E9DD.8FD856F0 Content-Type: text/html RE: [Capwap] Reg. Capabilities Negotiation between AP - AR

You might be want to look at the IETF RAP drafts/rfcs’ as well because it’s was tasked with a very similar problem (if was originally focused on RSVP admission control problem) on making real-time policy decisions based on load and congestion of the network in both a dynamic and static config models.    

 

/jsb

 


From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]
Sent: Monday, February 02, 2004 11:31 AM
To: Putzolu, David; Branislav Meandzija; Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com
Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR

 

Model 2: Centralized management system polls the APs for MIB information and make decisions.

Model 3: Centralized controller sees all packets and does decisions in real time.

patC
-----Original Message-----
From: Putzolu, David [mailto:david.putzolu@intel.com]
Sent: Mon 2/2/2004 11:12 AM
To: Pat R. Calhoun; Branislav Meandzija; Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com
Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR

What is the current engineering practice for load balancing?

If they are all model 3 (although I have to admit I am not totally
clear on the difference between 2 and 3) then it would seem to be
the right place to start. If they are a mix between 2 and 3, then
the WG would need to decide whether to intentionally exclude some
current solutions, or to come up with an architecture flexible
enough to support both.

Cheers,
David Putzolu


________________________________

        From: capwap-admin@frascone.com
[mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun
        Sent: Monday, February 02, 2004 10:28 AM
        To: Branislav Meandzija; Yang, Lily L; Peyush AGARWAL; Bob
O'Hara; capwap@frascone.com
        Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP -
AR
       
       

        ok, I'll bite.
       
        Please explain to me how load balancing works using model 2
below when the
        AP has a very finite amount of time to respond, and must make
decisions that
        require access to load information from surrounding APs.
       
        oh, and this has to scale.
       
        PatC
       
       
        -----Original Message-----
        From: Branislav Meandzija [mailto:bran@arraycomm.com]
        Sent: Mon 2/2/2004 10:19 AM
        To: Pat R. Calhoun; Yang, Lily L; Peyush AGARWAL; Bob O'Hara;
capwap@frascone.com
        Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP -
AR
       
       
        My comments in-line.
       
        Branislav
        -----Original Message-----
        From: capwap-admin@frascone.com
[mailto:capwap-admin@frascone.com]On Behalf Of Pat R. Calhoun
        Sent: Saturday, January 31, 2004 2:41 PM
        To: Yang, Lily L; Peyush AGARWAL; Bob O'Hara;
capwap@frascone.com
        Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP -
AR
       
       
        I believe you are correct. It really boils down to one of three
options:
       
        1. Leave things as-is,
        2. Implement a centralized network management component (what
you are describing)
        3. A centralized controller approach
       
        Of course, option 1 will always exist, and there are markets
where this approach
        makes sense.
       
        As far as option 2, I believe that there are some pretty severe
drawbacks. For instance,
        RF management really needs access to RF information on a
packet-by-packet basis. RF information
        is not just a single value (e.g. 1 is good), but really consists
of various measurements some
        of which are specific to each clients. It is possible for APs to
constantly be polled for this
        information and let a network manager run algorithms. However, I
believe that for those of us
        that have lived through the dial-up NAS markets in the mid-90s,
some may recall the NASes that
        would be polled frequently for "user information", and the fact
that these events caused a severe
        CPU drain on the NASes.
       
        -----
        <BM> Times they are achangin! We have quite different processing
and communications capabilities Today. And
        even Yesterday, look at the cable modem RF MIB.
        -----
        RF information is even more dynamic, and I suspect that there
would be
        additional problems. There is also the issue where this option
STILL requires that security
        information (specifically passwords for RADIUS, SNMP, etc) be
stored in flash, and this is a
        big concern for IT managers. Lastly, it seems like everyone
(even the incumbents are moving towards
        option 3).
       
        -----
        <BM> Actually the opposite is true. The latest architectural
solutions make the BS autonomous. Nobody likes
        to pay for and maintain heavy infrastructure.
        -----
       
        Obviously, I'm in favor of option 3. If you just look at the
cellular market, which evolved through
        the first two options, I believe that the current RAN approach
of centralizing functionality in the
        base station has made these networks scale.
       
        I believe that we would try to benefit from the lessons learned
in both the dial-up and the cellular
        networks here in CAPWAP.
        -----
        <BM> I agree with that but with obviously a different
conclusion.
        -----
       
        PatC
       
       
        -----Original Message-----
        From: Yang, Lily L [mailto:lily.l.yang@intel.com]
        Sent: Sat 1/31/2004 2:24 PM
        To: Pat R. Calhoun; Peyush AGARWAL; Bob O'Hara;
capwap@frascone.com
        Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP -
AR
       
        I understand the concern. I don't know how much interoperability
we can
        achieve either. But it seems like that is the market reality we
are
        facing today. So we need to figure out what role, if there is a
role,
        for IETF to do here to achieve any interoperability. I think
that is why
        the charter calls for some architectural study first. The
feasibility is
        still an open question to me.
       
       
       
        I believe even the standalone AP can still benefit from the
existence of
        a centralized controller to achieve network-wide RF management
and
        configuration. Of course, then it is not a strictly "standalone"
AP any
        more, but it may still be a pretty fat AP, handling some local
decisions
        (e.g., association) on its own, without forwarding every single
packet
        to the controller. I would think IETF/CAPWPA can still play a
role in
        such architecture.
       
       
       
        -----Original Message-----
        From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]
        Sent: Saturday, January 31, 2004 2:01 PM
        To: Yang, Lily L; Peyush AGARWAL; Bob O'Hara;
capwap@frascone.com
        Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP -
AR
       
       
       
        I'm deeply concerned about the concept of "architecture
variants". What
        this smells like to me is having multiple different
architectures that
        don't interoperate. I see this as adding complexity to the
market (and
        more specifically to the end user), and hampering
interoperability.
       
        Of course, we'll always have stand-alone APs... and I don't see
why the
        IETF needs to be concerned about those. We should be focused on
how to
        provide a scalable solution.
       
        my 2 cents,
       
        PatC
        -----Original Message-----
        From: capwap-admin@frascone.com on behalf of Yang, Lily L
        Sent: Fri 1/30/2004 10:07 AM
        To: Peyush AGARWAL; Bob O'Hara; capwap@frascone.com
        Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP -
AR
       
        It is conceivable that AP could just stick to one architecture
variant,
        depending on the target market, price point, etc., while AC
might have
        more flexibility to support multiple variants, esp. if the
functions
        required on AC for b is a superset for a., then supporting b
means it
        can also support a -- but this could be grossly simplified view,
so
        don't take it too literally. But there might be ways to
accomplish some
        level of interoperability across the spectrum.
       
        -----Original Message-----
        From: capwap-admin@frascone.com
[mailto:capwap-admin@frascone.com] On
        Behalf Of Peyush AGARWAL
        Sent: Thursday, January 29, 2004 10:02 PM
        To: 'Bob O'Hara'; capwap@frascone.com
        Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP -
AR
       
        That sounds good & informative.
       
        But again to make the things more clear; using Capability
Negotiations
        is it
        possible that we have a topology where:
       
                AC is on ARCH - x and
                the APs present in the network are on ARCH - a, b, c
(where
        a/b/c !=
        x) ?
       
        If the answer is yes, I feel that one has to end up implementing
        everything
        in APs as well as ACs!!
       
        Regards,
        Peyush.
       
       
       
       
       
        -----Original Message-----
        From: capwap-admin@frascone.com
[mailto:capwap-admin@frascone.com] On
        Behalf
        Of Bob O'Hara
        Sent: Wednesday, January 28, 2004 10:42 PM
        To: Peyush AGARWAL; capwap@frascone.com
        Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP -
AR
       
       
        Peyush,
       
        The negotiation between the AP and AR would not have anything to
do with
        the
        802.11 capabilities advertised in the 802.11 Beacon frame.  The
        capabilities
        in the proposed negotiation between AP and AR would have to do
with what
        functions are available at either end of that protocol exchange.
This
        was
        included in the draft to address the various functional splits
that are
        already present in the several products already in the market.
       
        One example of a function that might be part of this negotiation
is
        which
        parts of the 802.11 MAC management functionality would be
implemented in
        the
        AP and which parts would be implemented in the AR. There are
examples of
        products in the market that implement all of the MAC management
in the
        AR-equivalent device, some that move various parts of that to
the AP,
        and
        some others that implement all of it in the AP.
       
         -Bob
       
       
        -----Original Message-----
        From: capwap-admin@frascone.com
[mailto:capwap-admin@frascone.com] On
        Behalf
        Of Peyush AGARWAL
        Sent: Wednesday, January 28, 2004 4:23 AM
        To: capwap@frascone.com
        Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR
       
       
        Hi,
       
        The "Capabilities Negotiation" has been proposed in the
Architecture
        draft
        (draft-mani-ietf-capwap-arch-00) with the intention of deciding
'the
        applicable API's between AP and AC'.
                The 802.11 'Beacons' already contains the information of
the
        capabilities supported by the AP, therefore the requirement of
        'capabilities
        negotiation' is not clear to me. Please clarify.
       
        Thanks in advance.
       
        Regards,
        Peyush.
       
        _______________________________________________
        Capwap mailing list
        Capwap@frascone.com
http://mail.frascone.com/mailman/listinfo/capwap
        _______________________________________________
        Capwap mailing list
        Capwap@frascone.com
http://mail.frascone.com/mailman/listinfo/capwap
       
        _______________________________________________
        Capwap mailing list
        Capwap@frascone.com
        http://mail.frascone.com/mailman/listinfo/capwap
        _______________________________________________
        Capwap mailing list
        Capwap@frascone.com
        http://mail.frascone.com/mailman/listinfo/capwap
       
       
       
       



------_=_NextPart_001_01C3E9DD.8FD856F0-- From pcalhoun@airespace.com Tue Feb 3 00:12:10 2004 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Mon, 2 Feb 2004 16:12:10 -0800 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Message-ID: <55749BC69138654EBBC4C50BA4F55610ADC83B@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E9EA.5DD11383 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Right, but the primary difference is the installed base of mobile = devices, and their existing behavior (meaning timing) cannot change. So = all these new "policy" decisions must be made completely transparent to = the mobiles, and without affecting connectivity. this, btw, is the challenge. PatC -----Original Message----- From: Jim Binder [mailto:JBinder@extremenetworks.com] Sent: Mon 2/2/2004 2:40 PM To: Pat R. Calhoun; Putzolu, David; Branislav Meandzija; Yang, Lily L; = Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR =20 You might be want to look at the IETF RAP drafts/rfcs' as well because = it's was tasked with a very similar problem (if was originally focused on = RSVP admission control problem) on making real-time policy decisions based on load and congestion of the network in both a dynamic and static config models. =20 =20 /jsb =20 _____ =20 From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]=20 Sent: Monday, February 02, 2004 11:31 AM To: Putzolu, David; Branislav Meandzija; Yang, Lily L; Peyush AGARWAL; = Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR =20 Model 2: Centralized management system polls the APs for MIB information = and make decisions. Model 3: Centralized controller sees all packets and does decisions in = real time. patC -----Original Message----- From: Putzolu, David [mailto:david.putzolu@intel.com ] Sent: Mon 2/2/2004 11:12 AM To: Pat R. Calhoun; Branislav Meandzija; Yang, Lily L; Peyush AGARWAL; = Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR What is the current engineering practice for load balancing? If they are all model 3 (although I have to admit I am not totally clear on the difference between 2 and 3) then it would seem to be the right place to start. If they are a mix between 2 and 3, then the WG would need to decide whether to intentionally exclude some current solutions, or to come up with an architecture flexible enough to support both. Cheers, David Putzolu ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com ] = On Behalf Of Pat R. Calhoun Sent: Monday, February 02, 2004 10:28 AM To: Branislav Meandzija; Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR =20 =20 ok, I'll bite. =20 Please explain to me how load balancing works using model 2 below when the AP has a very finite amount of time to respond, and must make decisions that require access to load information from surrounding APs. =20 oh, and this has to scale. =20 PatC =20 =20 -----Original Message----- From: Branislav Meandzija [mailto:bran@arraycomm.com ] Sent: Mon 2/2/2004 10:19 AM To: Pat R. Calhoun; Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR =20 =20 My comments in-line. =20 Branislav -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com ]On Behalf Of Pat R. Calhoun Sent: Saturday, January 31, 2004 2:41 PM To: Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR =20 =20 I believe you are correct. It really boils down to one of three options: =20 1. Leave things as-is, 2. Implement a centralized network management component (what you are describing) 3. A centralized controller approach =20 Of course, option 1 will always exist, and there are markets where this approach makes sense. =20 As far as option 2, I believe that there are some pretty severe drawbacks. For instance, RF management really needs access to RF information on a packet-by-packet basis. RF information is not just a single value (e.g. 1 is good), but really consists of various measurements some of which are specific to each clients. It is possible for APs to constantly be polled for this information and let a network manager run algorithms. However, I believe that for those of us that have lived through the dial-up NAS markets in the mid-90s, some may recall the NASes that would be polled frequently for "user information", and the fact that these events caused a severe CPU drain on the NASes. =20 ----- Times they are achangin! We have quite different processing and communications capabilities Today. And even Yesterday, look at the cable modem RF MIB. ----- RF information is even more dynamic, and I suspect that there would be additional problems. There is also the issue where this option STILL requires that security information (specifically passwords for RADIUS, SNMP, etc) be stored in flash, and this is a big concern for IT managers. Lastly, it seems like everyone (even the incumbents are moving towards option 3). =20 ----- Actually the opposite is true. The latest architectural solutions make the BS autonomous. Nobody likes to pay for and maintain heavy infrastructure. ----- =20 Obviously, I'm in favor of option 3. If you just look at the cellular market, which evolved through the first two options, I believe that the current RAN approach of centralizing functionality in the base station has made these networks scale. =20 I believe that we would try to benefit from the lessons learned in both the dial-up and the cellular networks here in CAPWAP. ----- I agree with that but with obviously a different conclusion. ----- =20 PatC =20 =20 -----Original Message----- From: Yang, Lily L [mailto:lily.l.yang@intel.com ] Sent: Sat 1/31/2004 2:24 PM To: Pat R. Calhoun; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR =20 I understand the concern. I don't know how much interoperability we can achieve either. But it seems like that is the market reality we are facing today. So we need to figure out what role, if there is a role, for IETF to do here to achieve any interoperability. I think that is why the charter calls for some architectural study first. The feasibility is still an open question to me. =20 =20 =20 I believe even the standalone AP can still benefit from the existence of a centralized controller to achieve network-wide RF management and configuration. Of course, then it is not a strictly "standalone" AP any more, but it may still be a pretty fat AP, handling some local decisions (e.g., association) on its own, without forwarding every single packet to the controller. I would think IETF/CAPWPA can still play a role in such architecture. =20 =20 =20 -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com ] Sent: Saturday, January 31, 2004 2:01 PM To: Yang, Lily L; Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR =20 =20 =20 I'm deeply concerned about the concept of "architecture variants". What this smells like to me is having multiple different architectures that don't interoperate. I see this as adding complexity to the market (and more specifically to the end user), and hampering interoperability. =20 Of course, we'll always have stand-alone APs... and I don't see why the IETF needs to be concerned about those. We should be focused on how to provide a scalable solution. =20 my 2 cents, =20 PatC -----Original Message----- From: capwap-admin@frascone.com on behalf of Yang, Lily L Sent: Fri 1/30/2004 10:07 AM To: Peyush AGARWAL; Bob O'Hara; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR =20 It is conceivable that AP could just stick to one architecture variant, depending on the target market, price point, etc., while AC might have more flexibility to support multiple variants, esp. if the functions required on AC for b is a superset for a., then supporting b means it can also support a -- but this could be grossly simplified view, so don't take it too literally. But there might be ways to accomplish some level of interoperability across the spectrum. =20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com ] = On Behalf Of Peyush AGARWAL Sent: Thursday, January 29, 2004 10:02 PM To: 'Bob O'Hara'; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR =20 That sounds good & informative. =20 But again to make the things more clear; using Capability Negotiations is it possible that we have a topology where: =20 AC is on ARCH - x and the APs present in the network are on ARCH - a, b, c (where a/b/c !=3D x) ? =20 If the answer is yes, I feel that one has to end up implementing everything in APs as well as ACs!! =20 Regards, Peyush. =20 =20 =20 =20 =20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com ] = On Behalf Of Bob O'Hara Sent: Wednesday, January 28, 2004 10:42 PM To: Peyush AGARWAL; capwap@frascone.com Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR =20 =20 Peyush, =20 The negotiation between the AP and AR would not have anything to do with the 802.11 capabilities advertised in the 802.11 Beacon frame. The capabilities in the proposed negotiation between AP and AR would have to do with what functions are available at either end of that protocol exchange. This was included in the draft to address the various functional splits that are already present in the several products already in the market. =20 One example of a function that might be part of this negotiation is which parts of the 802.11 MAC management functionality would be implemented in the AP and which parts would be implemented in the AR. There are examples of products in the market that implement all of the MAC management in the AR-equivalent device, some that move various parts of that to the AP, and some others that implement all of it in the AP. =20 -Bob =20 =20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com ] = On Behalf Of Peyush AGARWAL Sent: Wednesday, January 28, 2004 4:23 AM To: capwap@frascone.com Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR =20 =20 Hi, =20 The "Capabilities Negotiation" has been proposed in the Architecture draft (draft-mani-ietf-capwap-arch-00) with the intention of deciding 'the applicable API's between AP and AC'. The 802.11 'Beacons' already contains the information of the capabilities supported by the AP, therefore the requirement of 'capabilities negotiation' is not clear to me. Please clarify. =20 Thanks in advance. =20 Regards, Peyush. =20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap =20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap =20 =20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap =20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap =20 =20 =20 =20 =20 ------_=_NextPart_001_01C3E9EA.5DD11383 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Capwap] Reg. Capabilities Negotiation between AP - = AR

Right, but the primary difference is the installed = base of mobile devices, and their existing behavior (meaning timing) = cannot change. So all these new "policy" decisions must be = made completely transparent to the mobiles, and without affecting = connectivity.

this, btw, is the challenge.

PatC


-----Original Message-----
From: Jim Binder [mailto:JBinder@extremenetwork= s.com]
Sent: Mon 2/2/2004 2:40 PM
To: Pat R. Calhoun; Putzolu, David; Branislav Meandzija; Yang, Lily L; = Peyush AGARWAL; Bob O'Hara; capwap@frascone.com
Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR

You might be want to look at the IETF RAP drafts/rfcs' as well because = it's
was tasked with a very similar problem (if was originally focused on = RSVP
admission control problem) on making real-time policy decisions based = on
load and congestion of the network in both a dynamic and static = config
models.   



/jsb



  _____ 

From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]=
Sent: Monday, February 02, 2004 11:31 AM
To: Putzolu, David; Branislav Meandzija; Yang, Lily L; Peyush AGARWAL; = Bob
O'Hara; capwap@frascone.com
Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR



Model 2: Centralized management system polls the APs for MIB information = and
make decisions.

Model 3: Centralized controller sees all packets and does decisions in = real
time.

patC
-----Original Message-----
From: Putzolu, David [mailto:david.putzolu@intel.com
<
mailto:david.putzolu@intel.com> ]
Sent: Mon 2/2/2004 11:12 AM
To: Pat R. Calhoun; Branislav Meandzija; Yang, Lily L; Peyush AGARWAL; = Bob
O'Hara; capwap@frascone.com
Subject: RE: [Capwap] Reg. Capabilities Negotiation between AP - AR

What is the current engineering practice for load balancing?

If they are all model 3 (although I have to admit I am not totally
clear on the difference between 2 and 3) then it would seem to be
the right place to start. If they are a mix between 2 and 3, then
the WG would need to decide whether to intentionally exclude some
current solutions, or to come up with an architecture flexible
enough to support both.

Cheers,
David Putzolu


________________________________

        From: = capwap-admin@frascone.com
[
mailto:capwap-admin@frascone.co= m <mailto:capwap-admin@frascone.co= m> ] On
Behalf Of Pat R. Calhoun
        Sent: Monday, February 02, = 2004 10:28 AM
        To: Branislav Meandzija; = Yang, Lily L; Peyush AGARWAL; Bob
O'Hara; capwap@frascone.com
        Subject: RE: [Capwap] Reg. = Capabilities Negotiation between AP -
AR
      
      

        ok, I'll bite.
      
        Please explain to me how load = balancing works using model 2
below when the
        AP has a very finite amount = of time to respond, and must make
decisions that
        require access to load = information from surrounding APs.
      
        oh, and this has to = scale.
      
        PatC
      
      
        -----Original = Message-----
        From: Branislav Meandzija [mailto:bran@arraycomm.com
<mailto:bran@arraycomm.com> = ]
        Sent: Mon 2/2/2004 10:19 = AM
        To: Pat R. Calhoun; Yang, = Lily L; Peyush AGARWAL; Bob O'Hara;
capwap@frascone.com
        Subject: RE: [Capwap] Reg. = Capabilities Negotiation between AP -
AR
      
      
        My comments in-line.
      
        Branislav
        -----Original = Message-----
        From: = capwap-admin@frascone.com
[mailto:capwap-admin@frascone.co= m <mailto:capwap-admin@frascone.co= m> ]On
Behalf Of Pat R. Calhoun
        Sent: Saturday, January 31, = 2004 2:41 PM
        To: Yang, Lily L; Peyush = AGARWAL; Bob O'Hara;
capwap@frascone.com
        Subject: RE: [Capwap] Reg. = Capabilities Negotiation between AP -
AR
      
      
        I believe you are correct. It = really boils down to one of three
options:
      
        1. Leave things as-is,
        2. Implement a centralized = network management component (what
you are describing)
        3. A centralized controller = approach
      
        Of course, option 1 will = always exist, and there are markets
where this approach
        makes sense.
      
        As far as option 2, I believe = that there are some pretty severe
drawbacks. For instance,
        RF management really needs = access to RF information on a
packet-by-packet basis. RF information
        is not just a single value = (e.g. 1 is good), but really consists
of various measurements some
        of which are specific to each = clients. It is possible for APs to
constantly be polled for this
        information and let a network = manager run algorithms. However, I
believe that for those of us
        that have lived through the = dial-up NAS markets in the mid-90s,
some may recall the NASes that
        would be polled frequently = for "user information", and the fact
that these events caused a severe
        CPU drain on the NASes.
      
        -----
        <BM> Times they are = achangin! We have quite different processing
and communications capabilities Today. And
        even Yesterday, look at the = cable modem RF MIB.
        -----
        RF information is even more = dynamic, and I suspect that there
would be
        additional problems. There is = also the issue where this option
STILL requires that security
        information (specifically = passwords for RADIUS, SNMP, etc) be
stored in flash, and this is a
        big concern for IT managers. = Lastly, it seems like everyone
(even the incumbents are moving towards
        option 3).
      
        -----
        <BM> Actually the = opposite is true. The latest architectural
solutions make the BS autonomous. Nobody likes
        to pay for and maintain heavy = infrastructure.
        -----
      
        Obviously, I'm in favor of = option 3. If you just look at the
cellular market, which evolved through
        the first two options, I = believe that the current RAN approach
of centralizing functionality in the
        base station has made these = networks scale.
      
        I believe that we would try = to benefit from the lessons learned
in both the dial-up and the cellular
        networks here in CAPWAP.
        -----
        <BM> I agree with that = but with obviously a different
conclusion.
        -----
      
        PatC
      
      
        -----Original = Message-----
        From: Yang, Lily L [mailto:lily.l.yang@intel.com <mailto:lily.l.yang@intel.com>= ; ]
        Sent: Sat 1/31/2004 2:24 = PM
        To: Pat R. Calhoun; Peyush = AGARWAL; Bob O'Hara;
capwap@frascone.com
        Subject: RE: [Capwap] Reg. = Capabilities Negotiation between AP -
AR
      
        I understand the concern. I = don't know how much interoperability
we can
        achieve either. But it seems = like that is the market reality we
are
        facing today. So we need to = figure out what role, if there is a
role,
        for IETF to do here to = achieve any interoperability. I think
that is why
        the charter calls for some = architectural study first. The
feasibility is
        still an open question to = me.
      
      
      
        I believe even the standalone = AP can still benefit from the
existence of
        a centralized controller to = achieve network-wide RF management
and
        configuration. Of course, = then it is not a strictly "standalone"
AP any
        more, but it may still be a = pretty fat AP, handling some local
decisions
        (e.g., association) on its = own, without forwarding every single
packet
        to the controller. I would = think IETF/CAPWPA can still play a
role in
        such architecture.
      
      
      
        -----Original = Message-----
        From: Pat R. Calhoun [mailto:pcalhoun@airespace.com<= BR> <mailto:pcalhoun@airespace.com&= gt; ]
        Sent: Saturday, January 31, = 2004 2:01 PM
        To: Yang, Lily L; Peyush = AGARWAL; Bob O'Hara;
capwap@frascone.com
        Subject: RE: [Capwap] Reg. = Capabilities Negotiation between AP -
AR
      
      
      
        I'm deeply concerned about = the concept of "architecture
variants". What
        this smells like to me is = having multiple different
architectures that
        don't interoperate. I see = this as adding complexity to the
market (and
        more specifically to the end = user), and hampering
interoperability.
      
        Of course, we'll always have = stand-alone APs... and I don't see
why the
        IETF needs to be concerned = about those. We should be focused on
how to
        provide a scalable = solution.
      
        my 2 cents,
      
        PatC
        -----Original = Message-----
        From: = capwap-admin@frascone.com on behalf of Yang, Lily L
        Sent: Fri 1/30/2004 10:07 = AM
        To: Peyush AGARWAL; Bob = O'Hara; capwap@frascone.com
        Subject: RE: [Capwap] Reg. = Capabilities Negotiation between AP -
AR
      
        It is conceivable that AP = could just stick to one architecture
variant,
        depending on the target = market, price point, etc., while AC
might have
        more flexibility to support = multiple variants, esp. if the
functions
        required on AC for b is a = superset for a., then supporting b
means it
        can also support a -- but = this could be grossly simplified view,
so
        don't take it too literally. = But there might be ways to
accomplish some
        level of interoperability = across the spectrum.
      
        -----Original = Message-----
        From: = capwap-admin@frascone.com
[mailto:capwap-admin@frascone.co= m <mailto:capwap-admin@frascone.co= m> ] On
        Behalf Of Peyush AGARWAL
        Sent: Thursday, January 29, = 2004 10:02 PM
        To: 'Bob O'Hara'; = capwap@frascone.com
        Subject: RE: [Capwap] Reg. = Capabilities Negotiation between AP -
AR
      
        That sounds good & = informative.
      
        But again to make the things = more clear; using Capability
Negotiations
        is it
        possible that we have a = topology where:
      
            &= nbsp;   AC is on ARCH - x and
            &= nbsp;   the APs present in the network are on ARCH - a, b, = c
(where
        a/b/c !=3D
        x) ?
      
        If the answer is yes, I feel = that one has to end up implementing
        everything
        in APs as well as ACs!!
      
        Regards,
        Peyush.
      
      
      
      
      
        -----Original = Message-----
        From: = capwap-admin@frascone.com
[mailto:capwap-admin@frascone.co= m <mailto:capwap-admin@frascone.co= m> ] On
        Behalf
        Of Bob O'Hara
        Sent: Wednesday, January 28, = 2004 10:42 PM
        To: Peyush AGARWAL; = capwap@frascone.com
        Subject: RE: [Capwap] Reg. = Capabilities Negotiation between AP -
AR
      
      
        Peyush,
      
        The negotiation between the = AP and AR would not have anything to
do with
        the
        802.11 capabilities = advertised in the 802.11 Beacon frame.  The
        capabilities
        in the proposed negotiation = between AP and AR would have to do
with what
        functions are available at = either end of that protocol exchange.
This
        was
        included in the draft to = address the various functional splits
that are
        already present in the = several products already in the market.
      
        One example of a function = that might be part of this negotiation
is
        which
        parts of the 802.11 MAC = management functionality would be
implemented in
        the
        AP and which parts would be = implemented in the AR. There are
examples of
        products in the market that = implement all of the MAC management
in the
        AR-equivalent device, some = that move various parts of that to
the AP,
        and
        some others that implement = all of it in the AP.
      
         -Bob
      
      
        -----Original = Message-----
        From: = capwap-admin@frascone.com
[mailto:capwap-admin@frascone.co= m <mailto:capwap-admin@frascone.co= m> ] On
        Behalf
        Of Peyush AGARWAL
        Sent: Wednesday, January 28, = 2004 4:23 AM
        To: capwap@frascone.com
        Subject: [Capwap] Reg. = Capabilities Negotiation between AP - AR
      
      
        Hi,
      
        The "Capabilities = Negotiation" has been proposed in the
Architecture
        draft
        = (draft-mani-ietf-capwap-arch-00) with the intention of deciding
'the
        applicable API's between AP = and AC'.
            &= nbsp;   The 802.11 'Beacons' already contains the information = of
the
        capabilities supported by the = AP, therefore the requirement of
        'capabilities
        negotiation' is not clear to = me. Please clarify.
      
        Thanks in advance.
      
        Regards,
        Peyush.
      
        = _______________________________________________
        Capwap mailing list
        Capwap@frascone.com
http://mail.fra= scone.com/mailman/listinfo/capwap
<http://mail.fra= scone.com/mailman/listinfo/capwap>
        = _______________________________________________
        Capwap mailing list
        Capwap@frascone.com
http://mail.fra= scone.com/mailman/listinfo/capwap
<http://mail.fra= scone.com/mailman/listinfo/capwap>
      
        = _______________________________________________
        Capwap mailing list
        Capwap@frascone.com
        http://mail.fra= scone.com/mailman/listinfo/capwap
<http://mail.fra= scone.com/mailman/listinfo/capwap>
        = _______________________________________________
        Capwap mailing list
        Capwap@frascone.com
        http://mail.fra= scone.com/mailman/listinfo/capwap
<http://mail.fra= scone.com/mailman/listinfo/capwap>
      
      
      
      







------_=_NextPart_001_01C3E9EA.5DD11383-- From pcalhoun@airespace.com Tue Feb 3 00:13:30 2004 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Mon, 2 Feb 2004 16:13:30 -0800 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR Message-ID: <55749BC69138654EBBC4C50BA4F55610ADC83E@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E9EA.E1F3E77B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >>=20 >> Certainly, the APs can filter the load information, and=20 >> present different >> information to different mobiles, in order to influence the mobile's >> decision. Is that what you mean by "network assisted"? > >That is one way of doing it. While I appreciate your view, I would also like to have specifics on how this could work. Having designed (and shipped) products = in=20 this space, your proposal does not appear to work with 802.11 mobiles = (at least with the experiences I've had). PatC ------_=_NextPart_001_01C3E9EA.E1F3E77B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Capwap] Reg. Capabilities Negotiation between AP - = AR

>>
>> Certainly, the APs can filter the load information, and
>> present different
>> information to different mobiles, in order to influence the = mobile's
>> decision. Is that what you mean by "network = assisted"?
>
>That is one way of doing it.

While I appreciate your view, I would also like to have
specifics on how this could work. Having designed (and shipped) products = in
this space, your proposal does not appear to work with 802.11 mobiles = (at least
with the experiences I've had).

PatC

------_=_NextPart_001_01C3E9EA.E1F3E77B-- From Internet-Drafts@ietf.org Tue Feb 3 20:44:54 2004 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Tue, 03 Feb 2004 15:44:54 -0500 Subject: [Capwap] I-D ACTION:draft-ietf-capwap-problem-statement-00.txt Message-ID: <200402032044.PAA29902@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Control And Provisioning of Wireless Access Points Working Group of the IETF. Title : CAPWAP Problem Statement Author(s) : P. Calhoun Filename : draft-ietf-capwap-problem-statement-00.txt Pages : 9 Date : 2004-2-3 This document describes the Configuration and Provisioning for Wireless Access Points (CAPWAP) problem statement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-capwap-problem-statement-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-capwap-problem-statement-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-capwap-problem-statement-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-3145900.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-capwap-problem-statement-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-capwap-problem-statement-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-3145900.I-D@ietf.org> --OtherAccess-- --NextPart-- From matt.holdrege@verizon.net Wed Feb 4 00:40:06 2004 From: matt.holdrege@verizon.net (Matt Holdrege) Date: Tue, 03 Feb 2004 16:40:06 -0800 Subject: [Capwap] Reg. Capabilities Negotiation between AP - AR In-Reply-To: <59A36C4D2F9E7243BEB522274F72C3030148BE8D@mvebe001.americas .nokia.com> References: <59A36C4D2F9E7243BEB522274F72C3030148BE8D@mvebe001.americas.nokia.com> Message-ID: <6.0.1.1.2.20040203163829.01df3318@incoming.verizon.net> At 12:14 PM 2/2/2004, Michael.G.Williams@nokia.com wrote: >An observation... that load balancing is a good example of a service that >the AC brings to enhance the IEEE 802.11 system. It is not a service >defined (fully) within the IEEE 802.11 MAC layer. It's not the AC that brings this load balancing service (in an architectural sense), but rather the network. It could be an AC, or it could be a Mesh of AP's, or it could be... From peyush.agarwal@st.com Thu Feb 5 09:39:10 2004 From: peyush.agarwal@st.com (Peyush AGARWAL) Date: Thu, 5 Feb 2004 15:09:10 +0530 Subject: [Capwap] Reg CAPWAP Motivations Message-ID: <002201c3ebcb$e8f9f690$0904b40a@dlh.st.com> An Input for the CAPWAP Architecture document: --------------------------------------------- Based on the current Problem Statement draft, The "CAPWAP motivation" = (section 3.2) of the 'Architecure draft' can have two more headlines = appended to the list: + CONSISTENT CONFIGURATION: Distributing & Maintaining the configuration = to all the APs, will help the entire WLAN system to scale in a better = way and have consitency throughout the network. + SAFE INSTALLATION: The CAPWAP can address security issues by = preventing unauthorized installation of APs in the WLAN network. Regds, Peyush. ------------------- Software Engineer, STMicroelectronics WLAN BU, India.=20 ------------------- From peyush.agarwal@st.com Mon Feb 9 09:03:16 2004 From: peyush.agarwal@st.com (Peyush AGARWAL) Date: Mon, 9 Feb 2004 14:33:16 +0530 Subject: [Capwap] Reg. AP Function and Services Message-ID: <007f01c3eeeb$8eb779a0$0904b40a@dlh.st.com> Hello, Section 4.1.1 of the CAPWAP Architecture document specifies that the = "Radio Resource Management (RRM)" MUST be a part of AP. As far as I understand, RRM targets SME and MLME for 'Measurement = protocol' and 'Measurement policy' respectively. Since the Management = functionalities of the AP would be moved to the AC, RRN should be a part = of AC with minimal hooks in AP. Let me know your suggestions. Regards, Peyush. ---------------------- Software Engineer, STMicroelectronics, WLAN BU, Noida, India.=20 ---------------------- From kempf@docomolabs-usa.com Mon Feb 9 17:54:41 2004 From: kempf@docomolabs-usa.com (James Kempf) Date: Mon, 9 Feb 2004 09:54:41 -0800 Subject: [Capwap] Reg. AP Function and Services References: <007f01c3eeeb$8eb779a0$0904b40a@dlh.st.com> Message-ID: <022b01c3ef35$cb3948a0$936015ac@dclkempt40> Yes, I agree with this. AP provides the measurements, AC manages. jak ----- Original Message ----- From: "Peyush AGARWAL" To: Sent: Monday, February 09, 2004 1:03 AM Subject: [Capwap] Reg. AP Function and Services > Hello, > > Section 4.1.1 of the CAPWAP Architecture document specifies that the "Radio Resource Management (RRM)" MUST be a part of AP. > > As far as I understand, RRM targets SME and MLME for 'Measurement protocol' and 'Measurement policy' respectively. Since the Management functionalities of the AP would be moved to the AC, RRN should be a part of AC with minimal hooks in AP. > > Let me know your suggestions. > > Regards, > Peyush. > ---------------------- > Software Engineer, > STMicroelectronics, > WLAN BU, Noida, India. > ---------------------- > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > From mmani@avaya.com Wed Feb 11 02:55:14 2004 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Tue, 10 Feb 2004 19:55:14 -0700 Subject: [Capwap] FW: [802-11TECHNICAL] Call for Interest for Wireless LANs Next Generation submission March 2004 Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F04A.793E256E Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable This CFI is the parallel IEEE activity planned as part of CAPWAP-related coordination with IETF. =20 -mani -----Original Message----- From: owner-stds-802-11@listserv.ieee.org [mailto:owner-stds-802-11@listserv.ieee.org] On Behalf Of Teik-Kheong(TK) Tan Sent: Tuesday, February 10, 2004 12:06 AM To: STDS-802-11@listserv.ieee.org Subject: [802-11TECHNICAL] Call for Interest for Wireless LANs Next Generation submission March 2004 =20 Wireless LANs Next Generation committee will have 4 sessions at the March meeting in Orlando. In addiiton to our regular updates, we will also be discussing new topics such as the following: 1) AP Functional Definition. The purpose is to codify the functional architecture includng functional blocks, interfaces and information exchanges. This is to address a need identified by the IETF to help them address their CAPWAP work. If you have more questions, please direct them to Bob O'Hara.=20 2) Requirements for Next Generation Wireless LANs - per our last meeting, we discussed the importance of understanding such requirements and also looking at what is required to meet those requirements.=20 I would like to invite submissions and presentations related to the above topics. If you would like presentation slots, please let me know asap. Regards, tk (chair, WNG SC) =20 ________________________________________________________________________ _______=20 This message came from the IEEE 802.11 Technical Reflector. Information can be found at http://www.ieee802.org/11 ________________________________________________________________________ _______ ------_=_NextPart_001_01C3F04A.793E256E Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

This CFI is the parallel IEEE = activity planned as part of CAPWAP-related coordination with IETF.

 

-mani

-----Original = Message-----
From: owner-stds-802-11@listserv.ieee.org = [mailto:owner-stds-802-11@listserv.ieee.org] On Behalf Of = Teik-Kheong(TK) Tan
Sent:
Tuesday, February 10, 2004 12:06 = AM
To: = STDS-802-11@listserv.ieee.org
Subject: = [802-11TECHNICAL] Call for Interest for Wireless LANs Next Generation submission March = 2004

 

Wireless LANs = Next Generation committee will have 4 sessions at the March meeting in = Orlando. In addiiton = to our regular updates, we will also be  discussing new topics such as the following:

1) AP Functional Definition. The purpose is to codify the functional architecture = includng functional blocks, interfaces and information exchanges. This is to = address a need identified by the IETF to help them address their CAPWAP work. If = you have more questions, please direct them to Bob O'Hara.

2) Requirements = for Next Generation Wireless LANs - per our last meeting, we discussed the = importance of understanding such requirements and also looking at what is required to = meet those requirements.

I would like to = invite submissions and  presentations related to the above topics. If you = would like presentation slots, please let me know asap.

Regards,

tk (chair, = WNG = SC)

 

_________________________________________________________________________= ______

This message came from the IEEE 802.11 Technical Reflector. Information = can be found at http://www.ieee802.org/11 _________________________________________________________________________= ______ ------_=_NextPart_001_01C3F04A.793E256E-- From sarikaya@ieee.org Wed Feb 11 04:55:04 2004 From: sarikaya@ieee.org (Behcet Sarikaya) Date: Tue, 10 Feb 2004 20:55:04 -0800 Subject: [Capwap] I-D ACTION:draft-sarikaya-capwap-lwaphp-00.txt Message-ID: <4029B5A8.20004@yahoo.com> This is a multi-part message in MIME format. --------------090700020202030008050808 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Light Weight AP Handover Protocol (LWAPHP) Author(s) : K. Sidhu Filename : draft-sarikaya-capwap-lwaphp-00.txt Pages : 53 Date : 2004-2-5 This document describes the Light Weight Access Point Handover Protocol (LWAPHP) which is a protocol allowing the access router to anchor and manage 802.11 handovers of the stations between a collection of wireless Access Points. The protocol like IEEE's IAPP aims to ensure that a station is connected to a single access point and provides an efficient context transfer mechanism during handover using neighbor graphs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sarikaya-capwap-lwaphp-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-sarikaya-capwap-lwaphp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-sarikaya-capwap-lwaphp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------090700020202030008050808 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Light Weight AP Handover Protocol (LWAPHP)
	Author(s)	: K. Sidhu
	Filename	: draft-sarikaya-capwap-lwaphp-00.txt
	Pages		: 53
	Date		: 2004-2-5
	
This document describes the Light Weight Access Point Handover
   Protocol (LWAPHP) which is a protocol allowing the access router to
   anchor and  manage 802.11 handovers of the stations between a
   collection of wireless Access Points. The protocol like IEEE's IAPP
   aims to ensure that a station is connected to a single access point
   and provides an efficient context transfer mechanism during handover
   using neighbor graphs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sarikaya-capwap-lwaphp-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-sarikaya-capwap-lwaphp-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-sarikaya-capwap-lwaphp-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
<ftp://ftp.ietf.org/internet-drafts/draft-sarikaya-capwap-lwaphp-00.txt>

--------------090700020202030008050808-- From peyush.agarwal@st.com Wed Feb 11 09:59:28 2004 From: peyush.agarwal@st.com (Peyush AGARWAL) Date: Wed, 11 Feb 2004 15:29:28 +0530 Subject: [Capwap] Reg. AR Discovery Message-ID: <003b01c3f085$bd622bb0$0904b40a@dlh.st.com> Hi, Section 4.6 (Access Router Discovery) states - When a AP comes alive on a network it may authenticate and register = with "one or more ARs" it detects on the network it is connected to. In = some architectures today the ARs are the bridges they directly connect = to.=20 I have a concern on this: Assume that an AP got registered with two ACs. Now how do the ACs decide = as which AC will actually control the AP ? This is possible but at an extra cost of network traffic to decide and = then to update each AC. I suggest that an AP can register with more than one ACs, but there = should be one and only one AC (decided at the time of registration or = explicitly mentioned by the AP) that should be ACTIVE at that time for = that AP. We can keep the other ACs as 'backup - ACs' which would be = required when the ACTIVE AC fails; this adds one more feature to CAPWAP = - 'Reliability" ! Let me know your comments on this. Regards, Peyush. ---------------------------- Software Engineer, STMicroelectronics, WLAN BU, Noida, India.=20 ---------------------------- From mmani@avaya.com Wed Feb 11 20:10:57 2004 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Wed, 11 Feb 2004 13:10:57 -0700 Subject: [Capwap] Reg. AR Discovery Message-ID: Peyush, The AP will only actively communicate with/be controlled by one AC. The intent was to have functionality exactly as you suggest - the wordings were not rigorous enough. It was worded to imply the need to set the association ahead of time to optimize for switchover to another AC. I got a little ahead of myself there. We called it Availability. This is as much an artifact of the connectivity as of the associability (of an AP to one or more ACs). I agree; wordings will need to reflect that unambiguously.=20 Regards, -mani > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Peyush AGARWAL > Sent: Wednesday, February 11, 2004 1:59 AM > To: capwap@frascone.com > Subject: [Capwap] Reg. AR Discovery >=20 > Hi, >=20 > Section 4.6 (Access Router Discovery) states - > When a AP comes alive on a network it may authenticate and register > with "one or more ARs" it detects on the network it is connected to. > In some architectures today the ARs are the bridges they directly connect > to. >=20 > I have a concern on this: >=20 > Assume that an AP got registered with two ACs. Now how do the ACs decide > as which AC will actually control the AP ? > This is possible but at an extra cost of network traffic to decide and > then to update each AC. >=20 > I suggest that an AP can register with more than one ACs, but there > should be one and only one AC (decided at the time of registration or > explicitly mentioned by the AP) that should be ACTIVE at that time for > that AP. We can keep the other ACs as 'backup - ACs' which would be > required when the ACTIVE AC fails; this adds one more feature to CAPWAP - > 'Reliability" ! >=20 > Let me know your comments on this. >=20 > Regards, > Peyush. > ---------------------------- > Software Engineer, > STMicroelectronics, > WLAN BU, Noida, India. > ---------------------------- >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap From hcheng@psl.com.sg Thu Feb 12 01:17:21 2004 From: hcheng@psl.com.sg (Cheng Hong) Date: Thu, 12 Feb 2004 09:17:21 +0800 Subject: [Capwap] FW: I-D ACTION:draft-cheng-capwap-classifications-00.txt Message-ID: <016301c3f105$f9a7a570$4971510a@Palpatine> This is a multi-part message in MIME format. ------=_NextPart_000_0164_01C3F149.07CAE570 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Please find below a draft we submitted for the function classification = in the CAPWAP framework. Best regards Cheng=20 -----Original Message----- From: owner-ietf-announce@ietf.org [mailto:owner-ietf-announce@ietf.org] = On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, February 12, 2004 4:49 AM To: IETF-Announce: Subject: I-D ACTION:draft-cheng-capwap-classifications-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Functionality Classifications for Control and Provisioning of Wireless Access Points (CAPWAP) Author(s) : H. Cheng Filename : draft-cheng-capwap-classifications-00.txt Pages : 9 Date : 2004-2-11 =09 This document presents a means for classifying wireless local area=20 network (WLAN) functionality for the Control and Provisioning of=20 Wireless Access Points framework. It also puts forth the advantages=20 of using consistent classifications in dividing functionality between = the Access Controllers and Access Points that make up a WLAN. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cheng-capwap-classifications-00= .tx t To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the = message. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, = type "cd internet-drafts" and then "get draft-cheng-capwap-classifications-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-cheng-capwap-classifications-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_0164_01C3F149.07CAE570 Content-Type: Message/External-body; name="ATT00130.dat" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00130.dat" Content-Type: text/plain Content-ID: <2004-2-11160013.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-cheng-capwap-classifications-00.txt ------=_NextPart_000_0164_01C3F149.07CAE570 Content-Type: Message/External-body; name="draft-cheng-capwap-classifications-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-cheng-capwap-classifications-00.txt" Content-Type: text/plain Content-ID: <2004-2-11160013.I-D@ietf.org> ------=_NextPart_000_0164_01C3F149.07CAE570-- From Internet-Drafts@ietf.org Fri Feb 13 21:09:39 2004 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Fri, 13 Feb 2004 16:09:39 -0500 Subject: [Capwap] I-D ACTION:draft-ietf-capwap-arch-00.txt Message-ID: <200402132109.QAA03634@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Control And Provisioning of Wireless Access Points Working Group of the IETF. Title : Architecture for Control and Provisioning of Wireless Access Points(CAPWAP) Author(s) : B. O'Hara Filename : draft-ietf-capwap-arch-00.txt Pages : 35 Date : 2004-2-12 This document provides a taxonomy of the architectures employed in the existing 802.11 products in the market, by analyzing WLAN (Wireless LAN) functions and services and describing the different variants in distributing these functions and services among the architectural entities, esp. between the access points and access controller. This taxonomy will be utilized by the 802.11 Working Group as input to their task of defining the functional architecture of an access point. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-capwap-arch-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-capwap-arch-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-capwap-arch-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-13163022.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-capwap-arch-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-capwap-arch-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-13163022.I-D@ietf.org> --OtherAccess-- --NextPart-- From sgovindan@psl.com.sg Thu Feb 19 02:28:18 2004 From: sgovindan@psl.com.sg (Saravanan Govindan) Date: Thu, 19 Feb 2004 10:28:18 +0800 Subject: [Capwap] Functional classifications draft Message-ID: <000001c3f690$09fb1800$7871510a@jadefox> Dear All, Regarding the Functional Classifications draft (draft-ietf-capwap-classifications-00.txt), I think there is a need for flexibility in how functional splits are devised. The interface between APs and ACs need to be adaptable so as to accommodate this flexibility. I look forward to your comments. Cheers Saravanan --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.588 / Virus Database: 372 - Release Date: 13/02/2004 From pcalhoun@airespace.com Thu Feb 19 02:39:52 2004 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Wed, 18 Feb 2004 18:39:52 -0800 Subject: [Capwap] Functional classifications draft Message-ID: <55749BC69138654EBBC4C50BA4F55610ADCA75@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F691.BAAD505E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Regarding the Functional Classifications draft > (draft-ietf-capwap-classifications-00.txt), I think there is a need = for > flexibility in how functional splits are devised. The interface = between > APs and ACs need to be adaptable so as to accommodate this = flexibility.=20 Define flexibility. Typically flexibility and interoperability don't go = well together. PatC ------_=_NextPart_001_01C3F691.BAAD505E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Capwap] Functional classifications draft

> Regarding the Functional Classifications = draft
> (draft-ietf-capwap-classifications-00.txt), I think there is a need = for
> flexibility in how functional splits are devised. The interface = between
> APs and ACs need to be adaptable so as to accommodate this = flexibility.

Define flexibility. Typically flexibility and interoperability don't go = well
together.

PatC

------_=_NextPart_001_01C3F691.BAAD505E-- From sgovindan@psl.com.sg Thu Feb 19 04:12:05 2004 From: sgovindan@psl.com.sg (Saravanan Govindan) Date: Thu, 19 Feb 2004 12:12:05 +0800 Subject: [Capwap] Functional classifications draft In-Reply-To: <55749BC69138654EBBC4C50BA4F55610ADCA75@AIREMAIL.airespace.com> Message-ID: <000f01c3f69e$88cedd70$7871510a@jadefox> > Regarding the Functional Classifications draft > (draft-ietf-capwap-classifications-00.txt), I think there is a need for > flexibility in how functional splits are devised. The interface between > APs and ACs need to be adaptable so as to accommodate this flexibility. Define flexibility. Typically flexibility and interoperability don't go well together. [SG] Given that the various functions needed for WLAN are classified in a standard way and that the interfaces between them are established, APs and ACs that comply with these will be able to interoperate. This in turn leads to flexibility in the choice of devices. Flexible here does not mean that any AP needs to be compatible with any other AC. As long as both of them follow the standard classifications and interfaces, they allow for flexible deployment. Saravanan --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.588 / Virus Database: 372 - Release Date: 13/02/2004 From sgovindan@psl.com.sg Thu Feb 19 09:28:55 2004 From: sgovindan@psl.com.sg (Saravanan Govindan) Date: Thu, 19 Feb 2004 17:28:55 +0800 Subject: [Capwap] Functional classifications draft In-Reply-To: <55749BC69138654EBBC4C50BA4F55610ADCA75@AIREMAIL.airespace.com> Message-ID: <001201c3f6ca$cbdd71e0$7871510a@jadefox> > Regarding the Functional Classifications draft > (draft-ietf-capwap-classifications-00.txt), I think there is a need for > flexibility in how functional splits are devised. The interface between > APs and ACs need to be adaptable so as to accommodate this flexibility. Define flexibility. Typically flexibility and interoperability don't go well together. [SG] Having put more thought into it, I think the degree of flexibility need not be the same at APs and ACs. Any one of the devices can be more flexible thereby accommodating the other. For example, if we have one jigsaw piece that fits many shapes, there would not be any need to make the other pieces like the first one. The other pieces can be of some standard shapes and they will fit when placed with the first piece. So based on this analogy, a flexible AC may be able to accommodate different APs. It would not be necessary to have APs be as flexible as the AC. All this leads to the need for classifying the functions/shapes and the interfaces between them. Saravanan --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.588 / Virus Database: 372 - Release Date: 13/02/2004 From pcalhoun@airespace.com Thu Feb 19 13:30:14 2004 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Thu, 19 Feb 2004 05:30:14 -0800 Subject: [Capwap] Functional classifications draft Message-ID: <55749BC69138654EBBC4C50BA4F55610ADCA77@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F6ED.32C31B26 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >>=20 >>Define flexibility. Typically flexibility and interoperability don't = go >>well >>together. >> >[SG] Given that the various functions needed for WLAN are classified in >a standard way and that the interfaces between them are established, = APs >and ACs that comply with these will be able to interoperate. This in >turn leads to flexibility in the choice of devices. Flexible here does >not mean that any AP needs to be compatible with any other AC. As long >as both of them follow the standard classifications and interfaces, = they >allow for flexible deployment. Au contraire. I would argue that CAPWAP cannot be successful unless they have in fact come up with a protocol/architecture that does guarantee = that any AP is compatible with any AC (while providing the ability for = vendors to innovate). I suspect that my issue with your statement is solely based on the terminology you are using (and if so, my apologies), but my read of = your statement is that you stating that it is more important to allow a = variety of options (read: flexibility) in a protocol/architecture that will knowingly impede interoperability. I think that interoperability should be a higher priority item than = allowing for a myriad of options that will do nothing but confuse the consumer. PatC ------_=_NextPart_001_01C3F6ED.32C31B26 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Capwap] Functional classifications draft

>>
>>Define flexibility. Typically flexibility and interoperability = don't go
>>well
>>together.
>>
>[SG] Given that the various functions needed for WLAN are classified = in
>a standard way and that the interfaces between them are established, = APs
>and ACs that comply with these will be able to interoperate. This = in
>turn leads to flexibility in the choice of devices. Flexible here = does
>not mean that any AP needs to be compatible with any other AC. As = long
>as both of them follow the standard classifications and interfaces, = they
>allow for flexible deployment.

Au contraire. I would argue that CAPWAP cannot be successful unless = they
have in fact come up with a protocol/architecture that does guarantee = that
any AP is compatible with any AC (while providing the ability for = vendors
to innovate).

I suspect that my issue with your statement is solely based on
the terminology you are using (and if so, my apologies), but my read of = your
statement is that you stating that it is more important to allow a = variety
of options (read: flexibility) in a protocol/architecture that will
knowingly impede interoperability.

I think that interoperability should be a higher priority item than = allowing
for a myriad of options that will do nothing but confuse the = consumer.

PatC

------_=_NextPart_001_01C3F6ED.32C31B26-- From Dorothy.Gellert@nokia.com Thu Feb 19 22:11:11 2004 From: Dorothy.Gellert@nokia.com (Dorothy.Gellert@nokia.com) Date: Thu, 19 Feb 2004 14:11:11 -0800 Subject: [Capwap] Functional classifications draft Message-ID: <4D7B558499107545BB45044C63822DDE03F08295@mvebe001.americas.nokia.com> Hi Saravanan, At this point in the WG, the charter is specific to create an = architecture document describing current approaches to manage scalable = 802.11 network functionality. The problem we need to solve is that = there is no consistent way to centrally manage 802.11 networks, meaning = all 802.11 APs. =20 We can discuss this draft in terms of how it can contribute to this = work, otherwise its out of scope and we only have a short 6 month = charter. Classification within 802.11 in order to partition functionality is one = possible approach. Is this type of architecture currently deployed the = marketplace?=20 If so we need to clearly list interfaces, describe the needed = functionality at the network entities, and include this in the = architecture draft. Dorothy > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > Behalf Of ext Saravanan Govindan > Sent: Thursday, February 19, 2004 1:29 AM > To: capwap@frascone.com > Subject: RE: [Capwap] Functional classifications draft >=20 >=20 >=20 > > Regarding the Functional Classifications draft > > (draft-ietf-capwap-classifications-00.txt), I think there is a need > for > > flexibility in how functional splits are devised. The interface > between > > APs and ACs need to be adaptable so as to accommodate this > flexibility.=20 >=20 > Define flexibility. Typically flexibility and=20 > interoperability don't go > well > together. >=20 > [SG] Having put more thought into it, I think the degree of=20 > flexibility > need not be the same at APs and ACs. Any one of the devices=20 > can be more > flexible thereby accommodating the other. For example, if we have one > jigsaw piece that fits many shapes, there would not be any=20 > need to make > the other pieces like the first one. The other pieces can be of some > standard shapes and they will fit when placed with the first piece. So > based on this analogy, a flexible AC may be able to accommodate > different APs. It would not be necessary to have APs be as flexible as > the AC.=20 >=20 > All this leads to the need for classifying the=20 > functions/shapes and the > interfaces between them.=20 >=20 >=20 > Saravanan=20 >=20 > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.588 / Virus Database: 372 - Release Date: 13/02/2004 > =20 >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 From Dorothy.Gellert@nokia.com Thu Feb 19 22:25:02 2004 From: Dorothy.Gellert@nokia.com (Dorothy.Gellert@nokia.com) Date: Thu, 19 Feb 2004 14:25:02 -0800 Subject: [Capwap] WG Last Call on draft-ietf-capwap-problem-statement-00.txt Message-ID: <4D7B558499107545BB45044C63822DDE03F08296@mvebe001.americas.nokia.com> This is a CAPWAP WG Last call announcement for the CAPWAP Problem = Statement draft. The WG Last Call for this document will run until Tuesday, March 2nd. = The CAPWAP Problem statement is a WG item and has been posted since Feb = 3rd:=20 http://www.ietf.org/internet-drafts/draft-ietf-capwap-problem-statement-0= 0.txt In order to encourage comments, this is an explicit last call. Please = respond with the following in the subject line: - "I read it, here are my issues" - "I read it, I like it" - "I read it, I don't care" =20 We will discuss issues sent to the list during the CAPWAP f2f in Seoul. Thanks, Dorothy and Mani From sgovindan@psl.com.sg Fri Feb 20 03:13:01 2004 From: sgovindan@psl.com.sg (Saravanan Govindan) Date: Fri, 20 Feb 2004 11:13:01 +0800 Subject: [Capwap] Functional classifications draft In-Reply-To: <000901c3f75e$fc440ad0$7871510a@jadefox> Message-ID: <000a01c3f75f$73f58590$7871510a@jadefox> Au contraire. I would argue that CAPWAP cannot be successful unless they have in fact come up with a protocol/architecture that does guarantee that any AP is compatible with any AC (while providing the ability for vendors to innovate). [SG] I agree. My intent was that as long as APs and ACs follow some sort of standard classifications & interfaces for the WLAN functions, then they will be intercompatible. In essence, my emphasis is on the classifications. [/SG] I suspect that my issue with your statement is solely based on the terminology you are using (and if so, my apologies), but my read of your statement is that you stating that it is more important to allow a variety of options (read: flexibility) in a protocol/architecture that will knowingly impede interoperability. I think that interoperability should be a higher priority item than allowing for a myriad of options that will do nothing but confuse the consumer. [SG] Regarding any options, I am only saying that there should be a way to make them fit in the CAPWAP framework without depriving them. The flexibility I am trying to put out is based on compatibility. So, when we can have flexible ways of operating, it essentially leads to interoperability. I agree that we should avoid confusing the consumer. However, allowing for options is not necessarily confusion. It can also be thought of as choice. [/SG] Cheers Saravanan --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.588 / Virus Database: 372 - Release Date: 13/02/2004 From sgovindan@psl.com.sg Fri Feb 20 04:10:33 2004 From: sgovindan@psl.com.sg (Saravanan Govindan) Date: Fri, 20 Feb 2004 12:10:33 +0800 Subject: [Capwap] Functional classifications draft In-Reply-To: <4D7B558499107545BB45044C63822DDE03F08295@mvebe001.americas.nokia.com> Message-ID: <000b01c3f767$7ca2ebd0$7871510a@jadefox> Hi Dorothy, The aim of the Functional Classifications draft is to put forth the need for classifications for the purpose of centrally managing WLAN. I think this would help with addressing the issue at hand. With this in mind, it would be a good idea to include it in an architecture document. Regarding market deployments, I am sure that manufacturers would have some means of classification to help with partitioning. However I am not aware of anything particular that is wide-ranging. It is for this reason that I think we should pursue it. Cheers Saravanan > -----Original Message----- > From: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com] > Sent: 20 February 2004 06:11 > To: sgovindan@psl.com.sg; capwap@frascone.com > Subject: RE: [Capwap] Functional classifications draft > > Hi Saravanan, > > At this point in the WG, the charter is specific to create an architecture > document describing current approaches to manage scalable 802.11 network > functionality. The problem we need to solve is that there is no > consistent way to centrally manage 802.11 networks, meaning all 802.11 APs. > > We can discuss this draft in terms of how it can contribute to this work, > otherwise its out of scope and we only have a short 6 month charter. > > Classification within 802.11 in order to partition functionality is one > possible approach. Is this type of architecture currently deployed the > marketplace? > If so we need to clearly list interfaces, describe the needed > functionality at the network entities, and include this in the > architecture draft. > > Dorothy > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > > Behalf Of ext Saravanan Govindan > > Sent: Thursday, February 19, 2004 1:29 AM > > To: capwap@frascone.com > > Subject: RE: [Capwap] Functional classifications draft > > > > > > > > > Regarding the Functional Classifications draft > > > (draft-ietf-capwap-classifications-00.txt), I think there is a need > > for > > > flexibility in how functional splits are devised. The interface > > between > > > APs and ACs need to be adaptable so as to accommodate this > > flexibility. > > > > Define flexibility. Typically flexibility and > > interoperability don't go > > well > > together. > > > > [SG] Having put more thought into it, I think the degree of > > flexibility > > need not be the same at APs and ACs. Any one of the devices > > can be more > > flexible thereby accommodating the other. For example, if we have one > > jigsaw piece that fits many shapes, there would not be any > > need to make > > the other pieces like the first one. The other pieces can be of some > > standard shapes and they will fit when placed with the first piece. So > > based on this analogy, a flexible AC may be able to accommodate > > different APs. It would not be necessary to have APs be as flexible as > > the AC. > > > > All this leads to the need for classifying the > > functions/shapes and the > > interfaces between them. > > > > > > Saravanan > > > > --- > > Outgoing mail is certified Virus Free. > > Checked by AVG anti-virus system (http://www.grisoft.com). > > Version: 6.0.588 / Virus Database: 372 - Release Date: 13/02/2004 > > > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.588 / Virus Database: 372 - Release Date: 13/02/2004 > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.588 / Virus Database: 372 - Release Date: 13/02/2004 From Dorothy.Gellert@nokia.com Fri Feb 20 21:24:30 2004 From: Dorothy.Gellert@nokia.com (Dorothy.Gellert@nokia.com) Date: Fri, 20 Feb 2004 13:24:30 -0800 Subject: [Capwap] Functional classifications draft Message-ID: <4D7B558499107545BB45044C63822DDE0486E64A@mvebe001.americas.nokia.com> Hi Saravanan- You do present good ideas in this draft, but the architecture Work Item = we have been chartered with is to develop a "network architecture = taxonomy describing the current set of approaches to providing more support for scalable 802.11 = access networks." In our current 6 month charter we are not creating a new 802.11 network = architecture, this WG is a preliminary activity to that. =20 If there are current products available that split the 802.11 = functionality this way, then=20 we should include them in the architecture taxonomy Work Item. =20 -Dorothy > -----Original Message----- > From: ext Saravanan Govindan [mailto:sgovindan@psl.com.sg] > Sent: Thursday, February 19, 2004 8:11 PM > To: Gellert Dorothy (Nokia-ES/MtView); capwap@frascone.com > Subject: RE: [Capwap] Functional classifications draft >=20 >=20 >=20 > Hi Dorothy, >=20 > The aim of the Functional Classifications draft is to put=20 > forth the need > for classifications for the purpose of centrally managing=20 > WLAN. I think > this would help with addressing the issue at hand. With this=20 > in mind, it > would be a good idea to include it in an architecture document.=20 >=20 > Regarding market deployments, I am sure that manufacturers would have > some means of classification to help with partitioning.=20 > However I am not > aware of anything particular that is wide-ranging. It is for=20 > this reason > that I think we should pursue it. >=20 > Cheers >=20 > Saravanan >=20 >=20 >=20 > > -----Original Message----- > > From: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com] > > Sent: 20 February 2004 06:11 > > To: sgovindan@psl.com.sg; capwap@frascone.com > > Subject: RE: [Capwap] Functional classifications draft > >=20 > > Hi Saravanan, > >=20 > > At this point in the WG, the charter is specific to create an > architecture > > document describing current approaches to manage scalable 802.11 > network > > functionality. The problem we need to solve is that there is no > > consistent way to centrally manage 802.11 networks, meaning=20 > all 802.11 > APs. > >=20 > > We can discuss this draft in terms of how it can contribute to this > work, > > otherwise its out of scope and we only have a short 6 month charter. > >=20 > > Classification within 802.11 in order to partition functionality is > one > > possible approach. Is this type of architecture currently deployed > the > > marketplace? > > If so we need to clearly list interfaces, describe the needed > > functionality at the network entities, and include this in the > > architecture draft. > >=20 > > Dorothy > >=20 > > > -----Original Message----- > > > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com]On > > > Behalf Of ext Saravanan Govindan > > > Sent: Thursday, February 19, 2004 1:29 AM > > > To: capwap@frascone.com > > > Subject: RE: [Capwap] Functional classifications draft > > > > > > > > > > > > > Regarding the Functional Classifications draft > > > > (draft-ietf-capwap-classifications-00.txt), I think there is a > need > > > for > > > > flexibility in how functional splits are devised. The interface > > > between > > > > APs and ACs need to be adaptable so as to accommodate this > > > flexibility. > > > > > > Define flexibility. Typically flexibility and > > > interoperability don't go > > > well > > > together. > > > > > > [SG] Having put more thought into it, I think the degree of > > > flexibility > > > need not be the same at APs and ACs. Any one of the devices > > > can be more > > > flexible thereby accommodating the other. For example, if we have > one > > > jigsaw piece that fits many shapes, there would not be any > > > need to make > > > the other pieces like the first one. The other pieces can=20 > be of some > > > standard shapes and they will fit when placed with the=20 > first piece. > So > > > based on this analogy, a flexible AC may be able to accommodate > > > different APs. It would not be necessary to have APs be=20 > as flexible > as > > > the AC. > > > > > > All this leads to the need for classifying the > > > functions/shapes and the > > > interfaces between them. > > > > > > > > > Saravanan > > > > > > --- > > > Outgoing mail is certified Virus Free. > > > Checked by AVG anti-virus system (http://www.grisoft.com). > > > Version: 6.0.588 / Virus Database: 372 - Release Date: 13/02/2004 > > > > > > > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > >=20 > >=20 > > --- > > Incoming mail is certified Virus Free. > > Checked by AVG anti-virus system (http://www.grisoft.com). > > Version: 6.0.588 / Virus Database: 372 - Release Date: 13/02/2004 > >=20 >=20 > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.588 / Virus Database: 372 - Release Date: 13/02/2004 > =20 >=20 >=20 From isingh@chantrynetworks.com Mon Feb 23 04:05:31 2004 From: isingh@chantrynetworks.com (Inderpreet Singh) Date: Sun, 22 Feb 2004 23:05:31 -0500 Subject: [Capwap] capwap architecture comments Message-ID: <000201c3f9c2$544251f0$6601a8c0@toronto.chantrynetworks.com> Hi, I have read http://www.ietf.org/internet-drafts/draft-ietf-capwap-arch-00.txt and the following are my comments: High level comments on entire spec: - Need to take out any references to the LWAPP spec. First of all, it is an expired draft and since the charter is focused on architecture taxonomy it is not appropriate to mention specific protocols here (especially protocols that are not standard yet.). Specific section comments: 2.2 CAPWAP Motivation The draft notes that all of the benefits can be provided "by terminating the 802.11 management frames in the AR". Why mention that and be partial toward that specific type of implementation? There are other implementations of the architecture that accomplish the same thing and provide the same benefits without having to send all the 802.11 management frames back to the centralized controller. Are we not striving for the case of making the architecture document to be at least a little bit architecture and protocol agnostic? The last paragraph of this section also makes a pretty drastic assumption. If the split AP implementation (not split-AP architecture but split-AP implementation!) is the prevalent implementation of a given architecture, then the assumption is that the MAC of a new or different wireless technology is also inherently "splittable". It just so happens that the IEEE did not mandate the way 802.11 MAC should be implemented so some vendors took the liberty of arbitrarily splitting it. What's to say that such splitting will be possible for the MAC layers of other technologies. Either we go with not even mentioning what happens in the case of any other wireless technologies, in which case the benefits of an implementation only apply to 802.11 networks, or we say in the true spirit of the IETF that we are going to strive to be layer 2 agnostic (or wireless technology agnostic). I acknowledge the constraints of the capwap charter placed on us by the iesg, ie. to remain in the realm of 802.11 access, but the latter (wireless technology agnostic architecture) is my preference. Nevertheless, given the constraint of 802.11 only, let's not mention any benefits or disadvantages to other wireless technologies. 3.2.2 AP to AR Topologies I wanted to confirm that Figure 4 is the same as the figure given below. Why would there be any difference between a router and an L3 Cloud? As a matter of fact, why would even Figure 3 not be covered by my modified version of Figure 4 given below? (I just changed the word "router" with "L3 cloud") Further more the same comment applies to Figure 2. All you really need to do is depict an L2 Cloud. If you don't do that then another interpretation of the figures is that the AC/AR/AB must support all topological types at the same time. Which is fine. But lets make that clear on all topologies. --------------------------------------------------------------------- +-------+-------+ | + + AR + + | +-------+-------+ | --------+------ LAN | +-------+-------+ | <> | +-------+-------+ | -----+--+--+--- LAN | | +---+ +---+ | | +--+--+ +--+--+ | AP | | AP | +--+--+ +--+--+ 3.3 Access Router Discovery "The type of discovery protocol is also dependent on prior one-time Provisioning of AP (configuration)." If discovery includes authentication and registration of AP to AR then I agree that apriori provisioning of AP's is a dependency on the discovery mechanism. However, for large scalability this might be an issue. One would have to assume that regardless of the architecture, the AR-AP authentication and registration protocol would have to be the same. We went down this rat hole during the lwapp discovery and security discussion. If we are prepared to continue that rat hole race then let's bring it up here.or else take it out. The simple issue of Discovery here is L2 domain discovery or L3 domain discovery. This is the IETF so L3/IP discovery is most interesting. It should work on anything that carries IP. Why have a different discovery protocol for Layer 2. 3.3.3 Access Point Service Management "An adaptive RF management based on .. is needed to be driven from ACs (or at times a hierarchy of ACs)." The question is WHY? An adaptive RF management algorithm on a large scale WLAN can be driven from either the APs or the AC, however the notification, approval, frequency of change, limits to change (bounding the fluctuations) is what needs to be centralized in the AC. 3.3.5.2 Mutual Authentication of AP and AR "The Key Management protocol choices are governed by the worst-case specification of Lightweight AP (LAP) capabilities." Didn't quite understand this sentence since a new "capabilities" type was introduced and that got confusing. Are you saying that the Key Management protocol choices must take into consideration the constraints of an AP that are say part of ARCH3 (in which the AP is really nothing more than an RF antenna). It is more likely that it has the least amount of CPU cycles and would not be able to manage a compute intensive algorithm? Just wanted clarification. 4. Prior Work Let me say that this whole section reads like a protocol comparison as opposed to an architecture comparison. This is the main section that I believe requires a re-write and what needs to happen is a comparison of DIRAC with each architecture type that is described in the spec. Similarly, a comparison of ForCES with each architecture type. The draft is doing a DIRAC vs. LWAPP and ForCES vs. LWAPP. To quote another wlan infrastructure vendor "...cart before the horse..."! Having said that, section 4.2.2 is truly in the spirit of architecture comparison. Nevertheless the text reads as if to say that the "arbitrary L3 cloud" between AP and AR is a possibility to not be supported. As per my discussion about section 3.2.2 I want to go on record and say it MUST be supported. Let's get the discussion started. Thanks Inderpreet Singh From soohong.park@samsung.com Mon Feb 23 04:53:26 2004 From: soohong.park@samsung.com (S. Daniel Park) Date: Mon, 23 Feb 2004 13:53:26 +0900 Subject: [Capwap] WG Last Call on draft-ietf-capwap-problem-statement-00.txt In-Reply-To: <4D7B558499107545BB45044C63822DDE03F08296@mvebe001.americas.nokia.com> Message-ID: <08b501c3f9c8$f90bee70$67cadba8@LocalHost> - "I read it, I like it" By the way, I didn't find out " [1] " as reference in this draft. Seems to be removed before forwarding to the IESG... Daniel (Soohong Daniel Park) Mobile Platform Laboratory, Samsung Electronics. > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of > Dorothy.Gellert@nokia.com > Sent: Friday, February 20, 2004 7:25 AM > To: capwap@frascone.com > Subject: [Capwap] WG Last Call on > draft-ietf-capwap-problem-statement-00.txt > > > > This is a CAPWAP WG Last call announcement for the CAPWAP > Problem Statement draft. The WG Last Call for this document > will run until Tuesday, March 2nd. The CAPWAP Problem > statement is a WG item and has been posted since Feb 3rd: > http://www.ietf.org/internet-drafts/draft-ietf-capwap-problem-statement- 00.txt In order to encourage comments, this is an explicit last call. Please respond with the following in the subject line: - "I read it, here are my issues" - "I read it, I like it" - "I read it, I don't care" We will discuss issues sent to the list during the CAPWAP f2f in Seoul. Thanks, Dorothy and Mani _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From sgovindan@psl.com.sg Mon Feb 23 05:42:06 2004 From: sgovindan@psl.com.sg (Saravanan Govindan) Date: Mon, 23 Feb 2004 13:42:06 +0800 Subject: [Capwap] Functional classifications draft In-Reply-To: <4D7B558499107545BB45044C63822DDE0486E64A@mvebe001.americas.nokia.com> Message-ID: <001401c3f9cf$c5a1fd20$7871510a@jadefox> Hi Dorothy, The classifications described in the draft are based on current practice. So they are within the scope of the charter. Furthermore, the draft mentions that further classifications are possible based on which products are available. Details regarding this may be included later on. The draft puts forth an overview of how WLAN functions are organized. Since they are based on established protocol layering, they represent the fundamental approach to partitioning functions among WLAN entities. The autonomous AP that the charter refers to is based on this broad classification. As such, I feel that the classifications draft presents a base for functional partitioning. So they should be included in an architecture taxonomy document. Cheers Saravanan > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Dorothy.Gellert@nokia.com > Sent: 21 February 2004 05:25 > To: sgovindan@psl.com.sg; capwap@frascone.com > Subject: RE: [Capwap] Functional classifications draft > > Hi Saravanan- > > You do present good ideas in this draft, but the architecture Work Item we > have been chartered with is to develop a "network architecture taxonomy > describing the > current set of approaches to providing more support for scalable 802.11 > access networks." > > In our current 6 month charter we are not creating a new 802.11 network > architecture, this WG > is a preliminary activity to that. > > If there are current products available that split the 802.11 > functionality this way, then > we should include them in the architecture taxonomy Work Item. > > -Dorothy > > > > -----Original Message----- > > From: ext Saravanan Govindan [mailto:sgovindan@psl.com.sg] > > Sent: Thursday, February 19, 2004 8:11 PM > > To: Gellert Dorothy (Nokia-ES/MtView); capwap@frascone.com > > Subject: RE: [Capwap] Functional classifications draft > > > > > > > > Hi Dorothy, > > > > The aim of the Functional Classifications draft is to put > > forth the need > > for classifications for the purpose of centrally managing > > WLAN. I think > > this would help with addressing the issue at hand. With this > > in mind, it > > would be a good idea to include it in an architecture document. > > > > Regarding market deployments, I am sure that manufacturers would have > > some means of classification to help with partitioning. > > However I am not > > aware of anything particular that is wide-ranging. It is for > > this reason > > that I think we should pursue it. > > > > Cheers > > > > Saravanan > > > > > > > > > -----Original Message----- > > > From: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com] > > > Sent: 20 February 2004 06:11 > > > To: sgovindan@psl.com.sg; capwap@frascone.com > > > Subject: RE: [Capwap] Functional classifications draft > > > > > > Hi Saravanan, > > > > > > At this point in the WG, the charter is specific to create an > > architecture > > > document describing current approaches to manage scalable 802.11 > > network > > > functionality. The problem we need to solve is that there is no > > > consistent way to centrally manage 802.11 networks, meaning > > all 802.11 > > APs. > > > > > > We can discuss this draft in terms of how it can contribute to this > > work, > > > otherwise its out of scope and we only have a short 6 month charter. > > > > > > Classification within 802.11 in order to partition functionality is > > one > > > possible approach. Is this type of architecture currently deployed > > the > > > marketplace? > > > If so we need to clearly list interfaces, describe the needed > > > functionality at the network entities, and include this in the > > > architecture draft. > > > > > > Dorothy > > > > > > > -----Original Message----- > > > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com]On > > > > Behalf Of ext Saravanan Govindan > > > > Sent: Thursday, February 19, 2004 1:29 AM > > > > To: capwap@frascone.com > > > > Subject: RE: [Capwap] Functional classifications draft > > > > > > > > > > > > > > > > > Regarding the Functional Classifications draft > > > > > (draft-ietf-capwap-classifications-00.txt), I think there is a > > need > > > > for > > > > > flexibility in how functional splits are devised. The interface > > > > between > > > > > APs and ACs need to be adaptable so as to accommodate this > > > > flexibility. > > > > > > > > Define flexibility. Typically flexibility and > > > > interoperability don't go > > > > well > > > > together. > > > > > > > > [SG] Having put more thought into it, I think the degree of > > > > flexibility > > > > need not be the same at APs and ACs. Any one of the devices > > > > can be more > > > > flexible thereby accommodating the other. For example, if we have > > one > > > > jigsaw piece that fits many shapes, there would not be any > > > > need to make > > > > the other pieces like the first one. The other pieces can > > be of some > > > > standard shapes and they will fit when placed with the > > first piece. > > So > > > > based on this analogy, a flexible AC may be able to accommodate > > > > different APs. It would not be necessary to have APs be > > as flexible > > as > > > > the AC. > > > > > > > > All this leads to the need for classifying the > > > > functions/shapes and the > > > > interfaces between them. > > > > > > > > > > > > Saravanan > > > > > > > > --- > > > > Outgoing mail is certified Virus Free. > > > > Checked by AVG anti-virus system (http://www.grisoft.com). > > > > Version: 6.0.588 / Virus Database: 372 - Release Date: 13/02/2004 > > > > > > > > > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > > > > > --- > > > Incoming mail is certified Virus Free. > > > Checked by AVG anti-virus system (http://www.grisoft.com). > > > Version: 6.0.588 / Virus Database: 372 - Release Date: 13/02/2004 > > > > > > > --- > > Outgoing mail is certified Virus Free. > > Checked by AVG anti-virus system (http://www.grisoft.com). > > Version: 6.0.588 / Virus Database: 372 - Release Date: 13/02/2004 > > > > > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.592 / Virus Database: 375 - Release Date: 18/02/2004 > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.592 / Virus Database: 375 - Release Date: 18/02/2004 From sgovindan@psl.com.sg Wed Feb 25 02:38:01 2004 From: sgovindan@psl.com.sg (Saravanan Govindan) Date: Wed, 25 Feb 2004 10:38:01 +0800 Subject: [Capwap] I read it, here is my issue - WG Last Call on draft-ietf-capwap-problem-statement-00.txt In-Reply-To: <4D7B558499107545BB45044C63822DDE03F08296@mvebe001.americas.nokia.com> Message-ID: <000101c3fb48$6329b280$7871510a@jadefox> Dear All, This is my comment regarding the CAPWAP Problem Statement draft: 1. The Problem Statement section (2) does not seem to recognize that the incompatibilities arising due to different types of functionality splits is an issue to be addressed. We would be more true to the purpose if this is explicitly included to be a CAPWAP concern. Cheers Saravanan --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.593 / Virus Database: 376 - Release Date: 20/02/2004 From starsu@sait.samsung.co.kr Wed Feb 25 04:47:24 2004 From: starsu@sait.samsung.co.kr (Sung Hyuck Lee) Date: Wed, 25 Feb 2004 13:47:24 +0900 Subject: [Capwap] [FYI] IETF Seoul meeting Message-ID: DQpEZWFyIGFsbCwgDQoNCiBJRVRGIFNlb3VsIG1lZXRpbmcgaXMgY29taW5nICAuLi4NCiBIb3dl dmVyLCBJZiB5b3UgZGlkIG5vdCBtYWtlIGFueSByZXNlcnZhdGlvbiBmb3IgYWNjb21tb2RhdGlv biB5ZXQsIA0KIHBsZWFzZSBsZXQgbWUga25vdy4gSSBjYW4gaGVscCB0aGUgZm9sa3Mgd2hvIGhh dmUgbm90IGZvdW5kIGFuIA0KIGFwcHJvcHJpYXRlIGhvdGVsLiANCg0KIHAucy4gVGhpcyBtYWls IGlzIG5vdCBhZC4NCg0KIFJlZ2FyZHMsDQoNCiBTdW5nLUh5dWNrIExlZQ0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCk5QVEcsIGktTmV0d29ya2luZyBMYWIuDQpTYW1zdW5nIEFkdmFuY2VkIEluc3RpdHV0ZSBv ZiBUZWNobm9sb2d5IChTQUlUKQ0KIA0KVGVsOiArODItMzEtMjgwLTk1ODUNCkZheDogKzgyLTMx LTI4MC05NTY5DQpDZWxsdWxhcjogKzgyLTExLTkwMzktMjYxNQ0KZS1tYWlsOiBzdGFyc3UubGVl QHNhbXN1bmcuY29tDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogDQogDQogDQogDQogDQogDQogDQogDQog DQogDQogDQogDQogDQogDQogDQoNCiA= From sgovindan@psl.com.sg Wed Feb 25 09:52:12 2004 From: sgovindan@psl.com.sg (Saravanan Govindan) Date: Wed, 25 Feb 2004 17:52:12 +0800 Subject: [Capwap] Comments on architecture draft Message-ID: <000001c3fb85$0b184d30$7871510a@jadefox> Dear All, These are some comments regarding the CAPWAP architecture draft. 1. The motivation section (2.2) does not recognize the incompatibilities in the split AP architecture. Today, different manufacturers use different ways of splitting functionality. For example, one firm sells APs with encryption/decryption features and corresponding ACs without this. Another firm puts security at the ACs and sells APs without them. As such, APs designed for one type of controller are not compatible with other controllers. I feel this should also serve to motivate the efforts of the WG. 2. Section 2.2 again, ("All of the above can be provided..."), the split AP approach seems to imply a certain way of splitting. However manufacturers follow different types of splits - some choose to realize real-time components at an AC so as to achieve wider scope of benefits. Based on available specifications, there are firms that include transmit power control at the AP and others that place them at the AC. On a more drastic case, one firm centralizes the entire MAC at the AC. This implication about the split AP approach should therefore be removed. It would be better to just say it is one where 802.11 protocol components are divided between AP and AC. 3. Sections 3.1.1 and 3.1.2 mandate which WLAN services go where and this is tantamount to defining how to split WLAN functionality. It has to be realized that there are merits to other means of splitting functions too. And CAPWAP should be able to accommodate these differences. It would be better to remove these restrictions. Alternatively, they may be included as part of one of the architectures in Section 2.3. 4. Regarding the capabilities negotiation section (3.3.2), it requires that only if 'the architectural types match' will an AP be able to register with an AC. This does not seem to fulfill CAPWAP's goal of striving for compatibility. Such a requirement limits interoperability to only those devices of a particular architecture type. This is too restrictive. Cross-architectural compatibilities have to be realized as part of CAPWAP too. Cheers Saravanan --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.594 / Virus Database: 377 - Release Date: 24/02/2004 From esadot@avaya.com Wed Feb 25 15:46:41 2004 From: esadot@avaya.com (Sadot, Emek (Emek)) Date: Wed, 25 Feb 2004 17:46:41 +0200 Subject: [Capwap] WG Last Call on draft-ietf-capwap-problem-statement-00.txt Message-ID: I read it, I like it. Emek -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On = Behalf Of Dorothy.Gellert@nokia.com Sent: Friday, 20 February, 2004 12:25 AM To: capwap@frascone.com Subject: [Capwap] WG Last Call on = draft-ietf-capwap-problem-statement-00.txt This is a CAPWAP WG Last call announcement for the CAPWAP Problem = Statement draft. The WG Last Call for this document will run until Tuesday, March 2nd. = The CAPWAP Problem statement is a WG item and has been posted since Feb = 3rd:=20 http://www.ietf.org/internet-drafts/draft-ietf-capwap-problem-statement-0= 0.txt In order to encourage comments, this is an explicit last call. Please = respond with the following in the subject line: - "I read it, here are my issues" - "I read it, I like it" - "I read it, I don't care" =20 We will discuss issues sent to the list during the CAPWAP f2f in Seoul. Thanks, Dorothy and Mani _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From Dorothy.Gellert@nokia.com Wed Feb 25 19:03:13 2004 From: Dorothy.Gellert@nokia.com (Dorothy.Gellert@nokia.com) Date: Wed, 25 Feb 2004 11:03:13 -0800 Subject: [Capwap] Architecture design team announcement & mission stmt Message-ID: <4D7B558499107545BB45044C63822DDE03F082A6@mvebe001.americas.nokia.com> All, We have a WG item to deliver an architecture taxonomy that documents = current market architectures to control and manage 802.11 APs. Since we = are limited to a short 6 month charter, we are establishing a design = team to ensure this goal is met. Unless there are concerns regarding = this approach, we will go forward with it.=20 The mission statement for the design team is to deliver an architecture = taxonomy draft according to the CAPWAP Charter: 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 entities in each approach do, - Describe the advantages and disadvantages of each approach for scalable 802.11 access network deployment and management. - contain a threat analysis that describes the security threats = involved in each network architectural approach. This work will evolve WG item draft-ietf-capwap-arch-00.txt. Lily Yang, = co-author of the draft, will lead the architecture design team. Regular = reports will be posted to the capwap mailing list after each meeting of = the design team. Major issues will also be brought to the list and = decided based on WG consensus. The output of the design team is = subject to the approval and modification of the WG. If anyone is interested in working on the CAPWAP architecture draft and = has the time to contribute over the next 6 months please contact Mani = and I by Tuesday, March 3rd. We will discuss the design team further = at the Seoul IETF meeting. Regards, Dorothy & Mani From mandrade@arubanetworks.com Wed Feb 25 19:59:01 2004 From: mandrade@arubanetworks.com (Merwyn Andrade) Date: Wed, 25 Feb 2004 11:59:01 -0800 Subject: [Capwap] Architecture design team announcement & mission stmt Message-ID: TWFuaS9Eb3JvdGh5L0xpbHkNCk5vdyB0aGF0IHRoZSBncm91cCBoYXMgY29uc3RyYWluZWQgaXQn cyBlZmZvcnRzIHRvIGFyY2hpdGVjdHVyYWwgdGF4b25vbXkgd2Ugd291bGQgbGlrZSB0byBvZmZl ciBhIHZvbHVudGVlciBmcm9tIEFydWJhIHRvIGpvaW4gaW4gb24gdGhlIG1lZXRpbmdzL2Rpc2N1 c3Npb25zIHRvd2FyZHMgZnVydGhlcmluZyB0aGlzIGVmZm9ydCBieSBzaGFyaW5nIGxlc3NvbnMg bGVhcm50IGFuZCBvdXIgZXhwZXJ0aXNlIGluIHRoaXMgc3BhY2UuLg0KUGFydGhhIE5hcmFzaW1o YW4gZnJvbSBBcnViYSBpcyBhbHNvIGNjOmVkIG9uIHRoaXMgbWVzc2FnZS4NClBsZWFzZSBhY2tu b3dsZWRnZSBhbmQgZmVlbCBmcmVlIHRvIGdldCBpbiB0b3VjaCB3aXRoIFBhcnRoYSBkaXJlY3Rs eSB0byBhZHZpc2Ugb24gbG9naXN0aWNzL2NhbGxzIGV0Yy4NCiANCkNoZWVycw0KTWVydg0KDQoJ LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJRnJvbTogY2Fwd2FwLWFkbWluQGZyYXNjb25l LmNvbSBbbWFpbHRvOmNhcHdhcC1hZG1pbkBmcmFzY29uZS5jb21dIE9uIEJlaGFsZiBPZiBEb3Jv dGh5LkdlbGxlcnRAbm9raWEuY29tIA0KCVNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjUsIDIw MDQgMTE6MDMgQU0gDQoJVG86IGNhcHdhcEBmcmFzY29uZS5jb20gDQoJQ2M6IG1tYW5pQGF2YXlh LmNvbSANCglTdWJqZWN0OiBbQ2Fwd2FwXSBBcmNoaXRlY3R1cmUgZGVzaWduIHRlYW0gYW5ub3Vu Y2VtZW50ICYgbWlzc2lvbiBzdG10IA0KDQoJQWxsLCANCg0KCVdlIGhhdmUgYSBXRyBpdGVtIHRv IGRlbGl2ZXIgYW4gYXJjaGl0ZWN0dXJlIHRheG9ub215IHRoYXQgZG9jdW1lbnRzIGN1cnJlbnQg bWFya2V0IGFyY2hpdGVjdHVyZXMgdG8gY29udHJvbCBhbmQgbWFuYWdlIDgwMi4xMSBBUHMuICBT aW5jZSB3ZSBhcmUgbGltaXRlZCB0byBhIHNob3J0IDYgbW9udGggY2hhcnRlciwgd2UgYXJlIGVz dGFibGlzaGluZyBhIGRlc2lnbiB0ZWFtIHRvIGVuc3VyZSB0aGlzIGdvYWwgaXMgbWV0LiBVbmxl c3MgdGhlcmUgYXJlIGNvbmNlcm5zIHJlZ2FyZGluZyB0aGlzIGFwcHJvYWNoLCB3ZSB3aWxsIGdv IGZvcndhcmQgd2l0aCBpdC4gDQoNCglUaGUgbWlzc2lvbiBzdGF0ZW1lbnQgZm9yIHRoZSBkZXNp Z24gdGVhbSBpcyB0byBkZWxpdmVyIGFuIGFyY2hpdGVjdHVyZSB0YXhvbm9teSBkcmFmdCBhY2Nv cmRpbmcgdG8gdGhlIENBUFdBUCBDaGFydGVyOiANCglUaGUgbmV0d29yayBhcmNoaXRlY3R1cmUg dGF4b25vbXkgd2lsbDogDQoJICAgICAgICAtIERlc2NyaWJlIHRoZSBjdXJyZW50IHNldCBvZiBh cHByb2FjaGVzIChpbmNsdWRpbmcgdGhlIA0KCSAgICAgICAgdHJhZGl0aW9uYWwgYXV0b25vbW91 cyBBUCBhcmNoaXRlY3R1cmUpIHRvIHBhcnRpdGlvbmluZyANCgkgICAgICAgIDgwMi4xMSBhY2Nl c3MgbmV0d29yayBmdW5jdGlvbmFsaXR5IGJldHdlZW4gbmV0d29yayANCgkgICAgICAgIGVudGl0 aWVzLCANCgkgICAgICAgIC0gTGlzdCB3aGF0IHRoZSBpbnRlcmZhY2VzIGJldHdlZW4gdGhlIG5l dHdvcmsgZW50aXRpZXMgDQoJICAgICAgICBhcmUgaW4gZWFjaCBhcHByb2FjaCwgDQoJICAgICAg ICAtIEF0IGEgZnVuY3Rpb25hbCBsZXZlbCwgZGVzY3JpYmUgd2hhdCB0aGUgcHJvdG9jb2xzIG9u IA0KCSAgICAgICAgdGhlIGludGVyZmFjZXMgYmV0d2VlbiB0aGUgbmV0d29yayBlbnRpdGllcyBp biBlYWNoIA0KCSAgICAgICAgYXBwcm9hY2ggZG8sIA0KCSAgICAgICAgLSBEZXNjcmliZSB0aGUg YWR2YW50YWdlcyBhbmQgZGlzYWR2YW50YWdlcyBvZiBlYWNoIA0KCSAgICAgICAgYXBwcm9hY2gg Zm9yIHNjYWxhYmxlIDgwMi4xMSBhY2Nlc3MgbmV0d29yayBkZXBsb3ltZW50IA0KCSAgICAgICAg YW5kIG1hbmFnZW1lbnQuIA0KCSAgICAgICAgLSBjb250YWluIGEgdGhyZWF0IGFuYWx5c2lzIHRo YXQgZGVzY3JpYmVzIHRoZSBzZWN1cml0eSB0aHJlYXRzIGludm9sdmVkIGluIGVhY2ggDQoJICAg ICAgICBuZXR3b3JrIGFyY2hpdGVjdHVyYWwgYXBwcm9hY2guIA0KDQoJVGhpcyB3b3JrIHdpbGwg ZXZvbHZlIFdHIGl0ZW0gZHJhZnQtaWV0Zi1jYXB3YXAtYXJjaC0wMC50eHQuICBMaWx5IFlhbmcs IGNvLWF1dGhvciBvZiB0aGUgZHJhZnQsIHdpbGwgbGVhZCB0aGUgYXJjaGl0ZWN0dXJlIGRlc2ln biB0ZWFtLiAgUmVndWxhciByZXBvcnRzIHdpbGwgYmUgcG9zdGVkIHRvIHRoZSBjYXB3YXAgbWFp bGluZyBsaXN0IGFmdGVyIGVhY2ggbWVldGluZyBvZiB0aGUgZGVzaWduIHRlYW0uICBNYWpvciBp c3N1ZXMgd2lsbCBhbHNvIGJlIGJyb3VnaHQgdG8gdGhlIGxpc3QgYW5kIGRlY2lkZWQgYmFzZWQg b24gV0cgY29uc2Vuc3VzLiAgIFRoZSBvdXRwdXQgb2YgdGhlIGRlc2lnbiB0ZWFtIGlzIHN1Ympl Y3QgdG8gdGhlIGFwcHJvdmFsIGFuZCBtb2RpZmljYXRpb24gb2YgdGhlIFdHLg0KDQoJSWYgYW55 b25lIGlzIGludGVyZXN0ZWQgaW4gd29ya2luZyBvbiB0aGUgQ0FQV0FQIGFyY2hpdGVjdHVyZSBk cmFmdCBhbmQgaGFzIHRoZSB0aW1lIHRvIGNvbnRyaWJ1dGUgb3ZlciB0aGUgbmV4dCA2IG1vbnRo cyBwbGVhc2UgY29udGFjdCBNYW5pIGFuZCBJIGJ5IFR1ZXNkYXksIE1hcmNoIDNyZC4gICBXZSB3 aWxsIGRpc2N1c3MgdGhlIGRlc2lnbiB0ZWFtIGZ1cnRoZXIgYXQgdGhlIFNlb3VsIElFVEYgbWVl dGluZy4NCg0KCVJlZ2FyZHMsIA0KCURvcm90aHkgJiBNYW5pIA0KDQoNCglfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyANCglDYXB3YXAgbWFpbGluZyBsaXN0 IA0KCUNhcHdhcEBmcmFzY29uZS5jb20gDQoJaHR0cDovL21haWwuZnJhc2NvbmUuY29tL21haWxt YW4vbGlzdGluZm8vY2Fwd2FwIA0KDQo= From kempf@docomolabs-usa.com Thu Feb 26 01:07:31 2004 From: kempf@docomolabs-usa.com (James Kempf) Date: Wed, 25 Feb 2004 17:07:31 -0800 Subject: [Capwap] capwap architecture comments References: <000201c3f9c2$544251f0$6601a8c0@toronto.chantrynetworks.com> Message-ID: <033501c3fc05$1310a5c0$1e6115ac@dclkempt40> Inderpreet, Thanx for your comments. If you have attended 802.11 meetings at all, you know that one requirement for making changes in a document is that the proposer provide text and references to the text in the document they believe must be changed. While this is not required by IETF, it certainly does make the job of the editor easier. It is much faster if you propose the text you believe addresses your concerns. Trying to extract that from your comments is difficult. The only direct substitution I can see in the below is your proposal to substitute the figure you've provided for Fig. 4. jak ----- Original Message ----- From: "Inderpreet Singh" To: Sent: Sunday, February 22, 2004 8:05 PM Subject: [Capwap] capwap architecture comments > Hi, > > I have read > http://www.ietf.org/internet-drafts/draft-ietf-capwap-arch-00.txt and > the following are my comments: > > High level comments on entire spec: > > - Need to take out any references to the LWAPP spec. First of > all, it is an expired draft and since the charter is focused on > architecture taxonomy it is not appropriate to mention specific > protocols here (especially protocols that are not standard yet.). > > Specific section comments: > > 2.2 CAPWAP Motivation > > The draft notes that all of the benefits can be provided "by > terminating the 802.11 management frames in the AR". Why mention that > and be partial toward that specific type of implementation? There are > other implementations of the architecture that accomplish the same thing > and provide the same benefits without having to send all the 802.11 > management frames back to the centralized controller. Are we not > striving for the case of making the architecture document to be at least > a little bit architecture and protocol agnostic? > > The last paragraph of this section also makes a pretty drastic > assumption. If the split AP implementation (not split-AP architecture > but split-AP implementation!) is the prevalent implementation of a given > architecture, then the assumption is that the MAC of a new or different > wireless technology is also inherently "splittable". It just so happens > that the IEEE did not mandate the way 802.11 MAC should be implemented > so some vendors took the liberty of arbitrarily splitting it. What's to > say that such splitting will be possible for the MAC layers of other > technologies. Either we go with not even mentioning what happens in the > case of any other wireless technologies, in which case the benefits of > an implementation only apply to 802.11 networks, or we say in the true > spirit of the IETF that we are going to strive to be layer 2 agnostic > (or wireless technology agnostic). I acknowledge the constraints of the > capwap charter placed on us by the iesg, ie. to remain in the realm of > 802.11 access, but the latter (wireless technology agnostic > architecture) is my preference. Nevertheless, given the constraint of > 802.11 only, let's not mention any benefits or disadvantages to other > wireless technologies. > > 3.2.2 AP to AR Topologies > > I wanted to confirm that Figure 4 is the same as the figure > given below. Why would there be any difference between a router and an > L3 Cloud? As a matter of fact, why would even Figure 3 not be covered > by my modified version of Figure 4 given below? (I just changed the word > "router" with "L3 cloud") Further more the same comment applies to > Figure 2. All you really need to do is depict an L2 Cloud. If you > don't do that then another interpretation of the figures is that the > AC/AR/AB must support all topological types at the same time. Which is > fine. But lets make that clear on all topologies. > > --------------------------------------------------------------------- > > > +-------+-------+ > | + + AR + + | > +-------+-------+ > | > --------+------ LAN > | > +-------+-------+ > | <> | > +-------+-------+ > | > -----+--+--+--- LAN > | | > +---+ +---+ > | | > +--+--+ +--+--+ > | AP | | AP | > +--+--+ +--+--+ > > > > 3.3 Access Router Discovery > > "The type of discovery protocol is also dependent on prior one-time > Provisioning of AP (configuration)." > > If discovery includes authentication and registration of AP to AR then I > agree that apriori provisioning of AP's is a dependency on the discovery > mechanism. However, for large scalability this might be an issue. One > would have to assume that regardless of the architecture, the AR-AP > authentication and registration protocol would have to be the same. We > went down this rat hole during the lwapp discovery and security > discussion. If we are prepared to continue that rat hole race then > let's bring it up here.or else take it out. The simple issue of > Discovery here is L2 domain discovery or L3 domain discovery. This is > the IETF so L3/IP discovery is most interesting. It should work on > anything that carries IP. Why have a different discovery protocol for > Layer 2. > > 3.3.3 Access Point Service Management > > "An adaptive RF management based on .. is needed to be driven from ACs > (or at times a hierarchy of ACs)." > > The question is WHY? An adaptive RF management algorithm on a large > scale WLAN can be driven from either the APs or the AC, however the > notification, approval, frequency of change, limits to change (bounding > the fluctuations) is what needs to be centralized in the AC. > > 3.3.5.2 Mutual Authentication of AP and AR > > "The Key Management protocol choices are governed by the worst-case > specification of Lightweight AP (LAP) capabilities." > > Didn't quite understand this sentence since a new "capabilities" > type was introduced and that got confusing. Are you saying that the Key > Management protocol choices must take into consideration the constraints > of an AP that are say part of ARCH3 (in which the AP is really nothing > more than an RF antenna). It is more likely that it has the least > amount of CPU cycles and would not be able to manage a compute intensive > algorithm? Just wanted clarification. > > 4. Prior Work > > Let me say that this whole section reads like a protocol > comparison as opposed to an architecture comparison. This is the main > section that I believe requires a re-write and what needs to happen is a > comparison of DIRAC with each architecture type that is described in the > spec. Similarly, a comparison of ForCES with each architecture type. > The draft is doing a DIRAC vs. LWAPP and ForCES vs. LWAPP. To quote > another wlan infrastructure vendor "...cart before the horse..."! > > Having said that, section 4.2.2 is truly in the spirit of architecture > comparison. Nevertheless the text reads as if to say that the > "arbitrary L3 > cloud" between AP and AR is a possibility to not be supported. As per > my discussion about section 3.2.2 I want to go on record and say it MUST > be supported. > > Let's get the discussion started. > > Thanks > > Inderpreet Singh > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > From Dorothy.Gellert@nokia.com Thu Feb 26 01:26:04 2004 From: Dorothy.Gellert@nokia.com (Dorothy.Gellert@nokia.com) Date: Wed, 25 Feb 2004 17:26:04 -0800 Subject: [Capwap] Architecture design team announcement & mission stmt Message-ID: <4D7B558499107545BB45044C63822DDE03F082A9@mvebe001.americas.nokia.com> Hi Everyone- Note that the Architecture design team does not replace the capwap = mailing list as a source of input for comments and text to the = architecture draft. The Design Team will take input from the mailing = list and is subject to WG group consensus, as are all work items. Thanks, Dorothy > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > Behalf Of ext=20 > Sent: Wednesday, February 25, 2004 11:03 AM > To: capwap@frascone.com > Cc: mmani@avaya.com > Subject: [Capwap] Architecture design team announcement & mission stmt >=20 >=20 >=20 > All, >=20 > We have a WG item to deliver an architecture taxonomy that=20 > documents current market architectures to control and manage=20 > 802.11 APs. Since we are limited to a short 6 month charter,=20 > we are establishing a design team to ensure this goal is met.=20 > Unless there are concerns regarding this approach, we will go=20 > forward with it.=20 >=20 > The mission statement for the design team is to deliver an=20 > architecture taxonomy draft according to the CAPWAP Charter: > 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 entities in each > approach do, > - Describe the advantages and disadvantages of each > approach for scalable 802.11 access network deployment > and management. > - contain a threat analysis that describes the security=20 > threats involved in each > network architectural approach. >=20 > This work will evolve WG item draft-ietf-capwap-arch-00.txt. =20 > Lily Yang, co-author of the draft, will lead the architecture=20 > design team. Regular reports will be posted to the capwap=20 > mailing list after each meeting of the design team. Major=20 > issues will also be brought to the list and decided based on=20 > WG consensus. The output of the design team is subject to=20 > the approval and modification of the WG. > If anyone is interested in working on the CAPWAP architecture=20 > draft and has the time to contribute over the next 6 months=20 > please contact Mani and I by Tuesday, March 3rd. We will=20 > discuss the design team further at the Seoul IETF meeting. >=20 > Regards, > Dorothy & Mani >=20 >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 From mmani@avaya.com Thu Feb 26 01:27:27 2004 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Wed, 25 Feb 2004 18:27:27 -0700 Subject: FW: RE: [Capwap] capwap architecture comments Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C3FC07.B205D88E Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I am resending (a truncated email) of the response that I sent some days back (blocked by the list since it exceeded 40K) =20 -mani -----Original Message----- From: Mani, Mahalingam (Mahalingam)=20 Sent: Monday, February 23, 2004 7:30 PM To: 'Inderpreet Singh'; 'capwap@frascone.com' Subject: RE: [Capwap] capwap architecture comments =20 Inderpreet, =20 Find inline responses (due to my past history with the draft) to many of your comments (thanks). I will leave it to current authors to opine further. =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= =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= =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=3D From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Inderpreet Singh Sent: Sunday, February 22, 2004 8:06 PM To: capwap@frascone.com Subject: [Capwap] capwap architecture comments =20 Hi,=20 =20 I have read http://www.ietf.org/internet-drafts/draft-ietf-capwap-arch-00.txt and the following are my comments: =20 High level comments on entire spec: =20 - Need to take out any references to the LWAPP spec. [Mani, Mahalingam (Mahalingam)] [...] =20 [Mani, Mahalingam (Mahalingam)] agreed. =20 Specific section comments: =20 2.2 CAPWAP Motivation =20 [Mani, Mahalingam (Mahalingam)] one of the goals of the draft is to summarize architectural taxonomy of today. Therefore, it is fair to mention=20 the characteristic of each architecture that will be summarized. =20 The draft notes that all of the benefits can be provided "by terminating the 802.11 management frames in the AR". Why mention that =20 [Mani, Mahalingam (Mahalingam)] it does not say shall - it mentions 'can'. =20 and be partial toward that specific type of implementation? There are [Mani, Mahalingam (Mahalingam)]=20 [Mani, Mahalingam (Mahalingam)] how does it amount to being partial when the description allows for other implementation as well? =20 other implementations of the architecture that accomplish the same thing and provide the same benefits without having to send all the 802.11 management frames back to the centralized controller. Are we not striving for the case of making the architecture document to be at least a little bit architecture and protocol agnostic? [Mani, Mahalingam (Mahalingam)]=20 [Mani, Mahalingam (Mahalingam)] the draft is protocol-agnostic. The first goal of the draft is to capture the arch. taxonomy. If and when as a result of the exercise there transpires a viable CAPWAP architecture - that will be informative. Therefore the contention of partiality is thus far ill-founded. =20 The last paragraph of this section also makes a pretty drastic assumption. [...]. It just so happens =20 [Mani, Mahalingam (Mahalingam)]=20 [Mani, Mahalingam (Mahalingam)] Split-AP does not always imply split-MAC for all architectures. If that's the case the following argument is valid. =20 that the IEEE did not mandate the way 802.11 MAC should be implemented so some vendors took the liberty of arbitrarily splitting it. What's to say that such splitting will be possible for the MAC layers of other =20 [Mani, Mahalingam (Mahalingam)] Granted we can't make such sweeping assertion. However, the assertion here's not about MAC-splits. [Mani, Mahalingam (Mahalingam)] the charter explicitly excludes inclusion of other wireless technologies in the exercise. Therefore, this is concern is misplaced. =20 technologies. Either we go with not even mentioning what happens in the case of any other wireless technologies, in which case the benefits of an implementation only apply to 802.11 networks, or we say in the true spirit of the IETF that we are going to strive to be layer 2 agnostic (or wireless technology agnostic[...]. =20 [Mani, Mahalingam (Mahalingam)] by the same token - the mere mention of split-AP does not preclude an implication of split-MAC though we desist from discussing such a case - given the charter scope - yes. =20 [mani]Therefore, after all the debate that has taken place so far on this matter - IESG has chartered a current course for this WG. The current work will adhere to the charter. That's not to say that IESG is not having its ears to the ground to sense any unanimity in calls for wireless-agnosticity. Nevertheless, that's out of scope of the current (brief) charter. =20 3.2.2 AP to AR Topologies =20 [Mani, Mahalingam (Mahalingam)] [...] =20 3.3 Access Router Discovery =20 "The type of discovery protocol is also dependent on prior one-time Provisioning of AP (configuration)." =20 If discovery includes authentication and registration of AP to AR then I agree that apriori provisioning of AP's is a dependency on the discovery mechanism. However, for large scalability this might be an issue. One would have to assume that regardless of the architecture, the AR-AP authentication and registration protocol would have to be the same. We =20 [Mani, Mahalingam (Mahalingam)]=20 [Mani, Mahalingam (Mahalingam)] that may very well be. Could you expand a little more on what you mean by the protocols having to be the same while admitting that registration & authentication are needed? The one-time provisioning referred to is an install-time provisioning - not per-registration provisioning. =20 went down this rat hole during the lwapp discovery and security discussion. If we are prepared to continue that rat hole race then let's bring it up here.or else take it out. [...]. Why have a different discovery protocol for Layer 2. =20 [Mani, Mahalingam (Mahalingam)] This draft - inasmuch as it records architecture taxonomy - will go so far as asserting the need for discovery - be it L2 or L3 - depending on topology. =20 3.3.3 Access Point Service Management =20 "An adaptive RF management based on .. is needed to be driven from ACs (or at times a hierarchy of ACs)." =20 The question is WHY? An adaptive RF management algorithm on a large scale WLAN can be driven from either the APs or the AC, however the =20 [Mani, Mahalingam (Mahalingam)] agreed. an adaptive RF management driven from an AP is limited to that AP. The spirit of the statement is to assert the benefit ACs bring in the ability to normalizing the scope across a broader RF domain. =20 notification, approval, frequency of change, limits to change (bounding the fluctuations) is what needs to be centralized in the AC. =20 [Mani, Mahalingam (Mahalingam)] do they not constitute RF management? =20 3.3.5.2 Mutual Authentication of AP and AR =20 "The Key Management protocol choices are governed by the worst-case specification of Lightweight AP (LAP) capabilities." =20 [...]. Are you saying that the Key Management protocol choices must take into consideration the constraints of an AP that are say part of ARCH3 (in which the AP is really nothing more than an RF antenna). It is more likely that it has the least amount of CPU cycles and would not be able to manage a compute intensive algorithm?[...] =20 [Mani, Mahalingam (Mahalingam)]=20 [Mani, Mahalingam (Mahalingam)] that's right. =20 4. Prior Work =20 [Mani, Mahalingam (Mahalingam)] [...] Let's get the discussion started. =20 Thanks =20 Inderpreet Singh =20 =20 [Mani, Mahalingam (Mahalingam)] -mani=20 ------_=_NextPart_001_01C3FC07.B205D88E Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

I am resending (a truncated email) = of the response that I sent some days back (blocked by the list since it = exceeded 40K)

 

-mani

-----Original = Message-----
From: Mani, Mahalingam = (Mahalingam)
Sent:
Monday, February 23, 2004 7:30 PM
To: 'Inderpreet Singh'; 'capwap@frascone.com'
Subject: RE: [Capwap] = capwap architecture comments

 

Inderpreet,

 

Find inline responses (due to my past history with the draft) to many of your comments (thanks). I will leave it to current authors to opine = further.

 

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=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=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=3D

From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On Behalf Of Inderpreet Singh

Sent: Sunday, February 22, 2004 8:06 PM

To: capwap@frascone.com

Subject: [Capwap] capwap architecture comments

 

Hi,

 

I have read http://www.ietf.org/internet-drafts/draft-ietf-capwap-arch-00.txt and the following are my comments:

 

High level comments on entire spec:

 

      - Need to take out any references to the LWAPP spec.  [Mani, Mahalingam (Mahalingam)] […]

 

[Mani, Mahalingam (Mahalingam)] agreed.

 

Specific section comments:

 

2.2 CAPWAP Motivation

 

[Mani, Mahalingam (Mahalingam)] one of the goals of the draft is to summarize architectural taxonomy of today. Therefore, it is fair to mention =

the characteristic of each architecture that will be = summarized.

 

      The draft notes that all of the benefits can be provided "by = terminating the 802.11 management frames in the AR".  Why mention = that

 

[Mani, Mahalingam (Mahalingam)] it does not say shall - it mentions = 'can'.

 

and be partial toward that specific type of implementation?  There = are

[Mani, Mahalingam (Mahalingam)] =

[Mani, Mahalingam (Mahalingam)] how does it amount to being partial when the description allows for other implementation as well?

 

other implementations of the architecture that accomplish the same thing and = provide the same benefits without having to send all the 802.11 management = frames back to the centralized controller.  Are we not striving for the case of = making the architecture document to be at least a little bit architecture and = protocol agnostic?

[Mani, Mahalingam (Mahalingam)] =

[Mani, Mahalingam (Mahalingam)] the draft is protocol-agnostic. The first goal = of the draft is to capture the arch. taxonomy. If and when as a result of the = exercise there transpires a viable CAPWAP architecture - that will be = informative. Therefore the contention of partiality is thus far = ill-founded.

 

      The last paragraph of this section also makes a pretty drastic assumption.  […].  It just so happens

 

[Mani, Mahalingam (Mahalingam)]

[Mani, Mahalingam (Mahalingam)] Split-AP does not always imply split-MAC for = all architectures. If that's the case the following argument is = valid.

 

that the IEEE did not mandate the way 802.11 MAC should be implemented so = some vendors took the liberty of arbitrarily splitting it.  What's to = say that such splitting will be possible for the MAC layers of = other

 

[Mani, Mahalingam (Mahalingam)] Granted we can't make such sweeping assertion. However, the assertion here's not about MAC-splits. [Mani, Mahalingam = (Mahalingam)] the charter explicitly excludes inclusion of other wireless technologies = in the exercise. Therefore, this is concern is misplaced.

 

technologies.  Either we go with not even mentioning what happens in the case of any = other wireless technologies, in which case the benefits of an implementation = only apply to 802.11 networks, or we say in the true spirit of the IETF that = we are going to strive to be layer 2 agnostic (or wireless technology = agnostic[…].

 

[Mani, Mahalingam (Mahalingam)] by the same token - the mere mention of = split-AP does not preclude an implication of split-MAC though we desist from = discussing such a case - given the charter scope - yes.

 

[mani]Therefore, after all the debate that has taken place so far on this matter - IESG = has chartered a current course for this WG. The current work will adhere to = the charter. That's not to say that IESG is not having its ears to the = ground to sense any unanimity in calls for wireless-agnosticity. Nevertheless, = that's out of scope of the current (brief) charter.

 

3.2.2 AP to AR Topologies

 

[Mani, = Mahalingam (Mahalingam)] […]

 

3.3 Access Router Discovery

 

"The type of discovery protocol is also dependent on prior one-time = Provisioning of AP (configuration)."

 

If discovery includes authentication and registration of AP to AR then I agree that = apriori provisioning of AP's is a dependency on the discovery mechanism.  = However, for large scalability this might be an issue.  One would have to = assume that regardless of the architecture, the AR-AP authentication and = registration protocol would have to be the same.  We

 

[Mani, Mahalingam (Mahalingam)]

[Mani, Mahalingam (Mahalingam)] that may very well be. Could you expand a = little more on what you mean by the protocols having to be the same while admitting = that registration & authentication are needed? The one-time provisioning referred to is an install-time provisioning - not per-registration provisioning.

 

went down this rat hole during the lwapp discovery and security = discussion.  If we are prepared to continue that rat hole race then let's bring it up = here.or else take it out.  […].  Why have a different discovery protocol for Layer 2.

 

[Mani, Mahalingam (Mahalingam)] This draft - inasmuch as it records = architecture taxonomy - will go so far as asserting the need for discovery - be it L2 or L3 - depending on topology.

 

3.3.3 Access Point Service Management

 

"An adaptive RF management based on .. is needed to be driven from ACs (or = at times a hierarchy of ACs)."

 

The question is WHY?  An adaptive RF management algorithm on a large = scale WLAN can be driven from either the APs or the AC, however = the

 

[Mani, Mahalingam (Mahalingam)] agreed. an adaptive RF management driven from = an AP is limited to that AP. The spirit of the statement is to assert the benefit = ACs bring in the ability to normalizing the scope across a broader RF = domain.

 

notification, approval, frequency of change, limits to change (bounding the = fluctuations) is what needs to be centralized in the AC.

 

[Mani, Mahalingam (Mahalingam)] do they not constitute RF = management?

 

3.3.5.2 Mutual Authentication of AP and AR

 

   "The Key Management protocol choices are governed by the = worst-case

   specification of Lightweight AP (LAP) = capabilities."

 

      […].  Are you saying that the Key Management protocol choices = must take into consideration the constraints of an AP that are say part of = ARCH3 (in which the AP is really nothing more than an RF antenna).  It is = more likely that it has the least amount of CPU cycles and would not be able = to manage a compute intensive algorithm?[…]

 

[Mani, Mahalingam (Mahalingam)]

[Mani, Mahalingam (Mahalingam)] that's right.

 

4. Prior Work

 

[Mani, = Mahalingam (Mahalingam)] […]

Let's get the discussion started.

 

Thanks

 

Inderpreet Singh

 

 

[Mani, Mahalingam (Mahalingam)] -mani 

------_=_NextPart_001_01C3FC07.B205D88E-- From sgovindan@psl.com.sg Thu Feb 26 01:44:52 2004 From: sgovindan@psl.com.sg (Saravanan Govindan) Date: Thu, 26 Feb 2004 09:44:52 +0800 Subject: [Capwap] Architecture design team announcement & mission stmt In-Reply-To: <4D7B558499107545BB45044C63822DDE03F082A6@mvebe001.americas.nokia.com> Message-ID: <000201c3fc0a$20eecfa0$7871510a@jadefox> Hi Dorothy, Mani, I am interested in working on the architecture taxonomy draft. Cheers Saravanan > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Dorothy.Gellert@nokia.com > Sent: 26 February 2004 03:03 > To: capwap@frascone.com > Cc: mmani@avaya.com > Subject: [Capwap] Architecture design team announcement & mission stmt > > All, > > We have a WG item to deliver an architecture taxonomy that documents > current market architectures to control and manage 802.11 APs. Since we > are limited to a short 6 month charter, we are establishing a design team > to ensure this goal is met. Unless there are concerns regarding this > approach, we will go forward with it. > > The mission statement for the design team is to deliver an architecture > taxonomy draft according to the CAPWAP Charter: > 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 entities in each > approach do, > - Describe the advantages and disadvantages of each > approach for scalable 802.11 access network deployment > and management. > - contain a threat analysis that describes the security threats > involved in each > network architectural approach. > > This work will evolve WG item draft-ietf-capwap-arch-00.txt. Lily Yang, > co-author of the draft, will lead the architecture design team. Regular > reports will be posted to the capwap mailing list after each meeting of > the design team. Major issues will also be brought to the list and > decided based on WG consensus. The output of the design team is subject > to the approval and modification of the WG. > If anyone is interested in working on the CAPWAP architecture draft and > has the time to contribute over the next 6 months please contact Mani and > I by Tuesday, March 3rd. We will discuss the design team further at the > Seoul IETF meeting. > > Regards, > Dorothy & Mani > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.594 / Virus Database: 377 - Release Date: 24/02/2004 > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.594 / Virus Database: 377 - Release Date: 24/02/2004 From isingh@chantrynetworks.com Thu Feb 26 03:12:04 2004 From: isingh@chantrynetworks.com (Inderpreet Singh) Date: Wed, 25 Feb 2004 22:12:04 -0500 Subject: [Capwap] capwap architecture comments In-Reply-To: Message-ID: <006301c3fc16$59387c60$c7f21cac@toronto.chantrynetworks.com> My comments embedded preceded with ">>"=20 ----=A0 [Mani, Mahalingam (Mahalingam)] one of the goals of the draft is to summarize architectural taxonomy of today. Therefore, it is fair to mention the characteristic of each architecture that will be summarized. >>agreed. Since the beginning (in Vienna) you will notice that I have pushed for lucid differentiation between=20 >>"architecture", "protocol" and "implementation". You will notice that my comments are mostly focused in areas=20 >>where the three have been intermixed. =A0=A0=A0=A0=A0 The draft notes that all of the benefits can be provided = "by terminating the 802.11 management frames in the AR".=A0 Why mention that =A0 [Mani, Mahalingam (Mahalingam)] it does not say shall - it mentions 'can'. >>Agreed, but why mention "can" at all? It can be done by splitting the AP, it can be done by splitting the MAC,=20 >>it can be done by no splitting at all and providing an informational interface to a controller. >> >>Instead I propose we say something like: "All of the above benefits are provided by a variety of different=20 >>implementations today. For example, some vendors have decided to split the implementation of the 802.11 MAC while=20 >>others have decided to set up information exchanges between AP and AC and yet others have relied on terminating the=20 >>802.11 data packets at the AC. The common thread in all of these implementations is that the architecture is >>focused around the fact that the control and provisioning mechanisms that enable these benefits are centralized in >>an AC". =20 [Mani, Mahalingam (Mahalingam)] how does it amount to being partial when the description allows for other implementation as well? =A0 [Mani, Mahalingam (Mahalingam)] the draft is protocol-agnostic. The first goal of the draft is to capture the arch. taxonomy. If and when as a result of the exercise there transpires a viable CAPWAP architecture - that will be informative. Therefore the contention of partiality is thus far ill-founded. =A0 >>Maybe the implication of partiality and bias towards a specific protocol was not intended by the authors. But=20 >>the draft is far from protocol agnostic. I think you have agreed with me above that we should not mention a=20 >>specific protocol in the taxonomy doc. [Mani, Mahalingam (Mahalingam)]=20 [Mani, Mahalingam (Mahalingam)] Split-AP does not always imply split-MAC for all architectures. If that's the case the following argument is valid. =A0 that the IEEE did not mandate the way 802.11 MAC should be implemented so some vendors took the liberty of arbitrarily splitting it.=A0 What's = to say that such splitting will be possible for the MAC layers of other =A0 [Mani, Mahalingam (Mahalingam)] Granted we can't make such sweeping assertion. However, the assertion here's not about MAC-splits. [Mani, Mahalingam (Mahalingam)] the charter explicitly excludes inclusion of other wireless technologies in the exercise. Therefore, this is concern is misplaced. >>I read the text and read an assertion being made that the MAC split approach will enable future wireless >>technologies to easily integrate under a CAPWAP umbrella because all you have to do is put a protocol header on the=20 >>different wireless technology's non-realtime packets. If that is not the case, then I take back my concern. It is=20 >>possible, and imho better, to create an abstract interface between AP and AC to enable future wireless technologies >>to take advantage of a centralized approach. But that discussion is out of scope. =A0 [Mani, Mahalingam (Mahalingam)] by the same token - the mere mention of split-AP does not preclude an implication of split-MAC though we desist from discussing such a case - given the charter scope - yes. =A0 [mani]Therefore, after all the debate that has taken place so far on this matter - IESG has chartered a current course for this WG. The current work will adhere to the charter. That's not to say that IESG is not having its ears to the ground to sense any unanimity in calls for wireless-agnosticity. Nevertheless, that's out of scope of the current (brief) charter. >> agreed. So let's take out the following=20 >> "Adding support to CAPWAP for other wireless technologies then >> becomes a task of encapsulating the new frames and adding a new >> control module to the AR to handle the new technology. Presumably, >> the LWAPP protocol and CAPWAP architecture will need little change, >> if any." 3.3 Access Router Discovery =A0 "The type of discovery protocol is also dependent on prior one-time Provisioning of AP (configuration)." =A0 If discovery includes authentication and registration of AP to AR then I agree that apriori provisioning of AP's is a dependency on the discovery mechanism.=A0 However, for large scalability this might be an issue.=A0 = One would have to assume that regardless of the architecture, the AR-AP authentication and registration protocol would have to be the same.=A0 = We =A0 [Mani, Mahalingam (Mahalingam)]=20 [Mani, Mahalingam (Mahalingam)] that may very well be. Could you expand a little more on what you mean by the protocols having to be the same while admitting that registration & authentication are needed? The one-time provisioning referred to is an install-time provisioning - not per-registration provisioning. =A0 >>Sorry I wasn=92t clear in my description here. All I am saying is = that Discovery takes place before the AP-AC=20 >>authentication, registration and configuration. Therefore, I don't see the need for a dependency of prior one-time=20 >>provisioning of AP on discovery. The only possible one-time provisioning is for security credentials (ie. digital=20 >>cert) of the AP which is required during the auth. phase, not discovery phase. I am proposing text to the effect=20 >>of: "The type of discovery protocol should be independent of the prior one-time provisioning requirements of the=20 >>AP.". I basically do not agree that the discovery mechanism is dependent on provisioning requirements. [Mani, Mahalingam (Mahalingam)] This draft - inasmuch as it records architecture taxonomy - will go so far as asserting the need for discovery - be it L2 or L3 - depending on topology. >> agreed. But why mention L2 discovery at all? =A0 3.3.3 Access Point Service Management =A0 "An adaptive RF management based on .. is needed to be driven from ACs (or at times a hierarchy of ACs)." =A0 The question is WHY?=A0 An adaptive RF management algorithm on a large scale WLAN can be driven from either the APs or the AC, however the [Mani, Mahalingam (Mahalingam)] agreed. an adaptive RF management driven from an AP is limited to that AP. The spirit of the statement is to assert the benefit ACs bring in the ability to normalizing the scope across a broader RF domain. =A0 notification, approval, frequency of change, limits to change (bounding the fluctuations) is what needs to be centralized in the AC. =A0 [Mani, Mahalingam (Mahalingam)] do they not constitute RF management? =A0 >>understood the spirit. There are implementations out there that drive the RF management from the APs and where the >>algorithms are multi-AP aware and affecting. However, the control of the group of AP's and the behavior of=20 >>the RF management algorithms are controlled and monitored by the AC or AC's. So I propose we write it this way: "An=20 >>adaptive RF management based on dynamic systemic monitoring, as well as power and frequency management is needed to=20 >>be controlled and monitored from ACs (or at times a hierarchy of ACs)." This gets us away from the assumption that=20 >>the RF management algorithms need to run centrally. Thanks Inderpreet=20 From sgovindan@psl.com.sg Thu Feb 26 08:23:33 2004 From: sgovindan@psl.com.sg (Saravanan Govindan) Date: Thu, 26 Feb 2004 16:23:33 +0800 Subject: [Capwap] Comments on architecture draft In-Reply-To: <000001c3fb85$0b184d30$7871510a@jadefox> Message-ID: <000401c3fc41$d2a246f0$7871510a@jadefox> Dear All, Taking the advice from a previous posting, I am including changes that reflect my previous comments on the CAPWAP architecture draft. > 1. The motivation section (2.2) does not recognize the incompatibilities > in the split AP architecture. Today, different manufacturers use > different ways of splitting functionality. For example, one firm sells > APs with encryption/decryption features and corresponding ACs without > this. Another firm puts security at the ACs and sells APs without them. > As such, APs designed for one type of controller are not compatible with > other controllers. I feel this should also serve to motivate the efforts > of the WG. Section 2.2, Paragraph 1 "A new architecture is emerging in the 802.11 market that moves much of the functions that would reside in a traditional access point (AP) to a centralized access router (AR). <> Some of the benefits that come out of this new architecture include:" > 2. Section 2.2 again, ("All of the above can be provided..."), the split > AP approach seems to imply a certain way of splitting. However > manufacturers follow different types of splits - some choose to realize > real-time components at an AC so as to achieve wider scope of benefits. > Based on available specifications, there are firms that include transmit > power control at the AP and others that place them at the AC. On a more > drastic case, one firm centralizes the entire MAC at the AC. This > implication about the split AP approach should therefore be removed. It > would be better to just say it is one where 802.11 protocol components > are divided between AP and AC. Section 2.2, Paragraph 6 "All of the above can be provided by terminating the 802.11 management frames in the AR. This approach is commonly referred to as Split AP, where <>" > 3. Sections 3.1.1 and 3.1.2 mandate which WLAN services go where and > this is tantamount to defining how to split WLAN functionality. It has > to be realized that there are merits to other means of splitting > functions too. And CAPWAP should be able to accommodate these > differences. It would be better to remove these restrictions. > Alternatively, they may be included as part of one of the architectures > in Section 2.3. > > 4. Regarding the capabilities negotiation section (3.3.2), it requires > that only if 'the architectural types match' will an AP be able to > register with an AC. This does not seem to fulfill CAPWAP's goal of > striving for compatibility. Such a requirement limits interoperability > to only those devices of a particular architecture type. This is too > restrictive. Cross-architectural compatibilities have to be realized as > part of CAPWAP too. Section 3.3.2 "An AP performs AR discovery in its network neighborhood. Upon having discovered available ARs the AP enters into a capabilities exchange phase with the candidate ACs. <> the AP registers with the AC and configures itself based on the policies it derives from the AC after mutually authenticating with the AC. The capabilities negotiated will decide the applicable API's between AP and AC." 5. I feel that architectural description (Section 2.3) needs to be preceded by a section on the classifications of WLAN functions. Since the differences in architectures relate to the differences in where functions are located, classifications serve as a base point. The Functional Classifications document will be applicable here. Cheers Saravanan --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.594 / Virus Database: 377 - Release Date: 24/02/2004 From soohong.park@samsung.com Fri Feb 27 04:37:35 2004 From: soohong.park@samsung.com (S. Daniel Park) Date: Fri, 27 Feb 2004 13:37:35 +0900 Subject: [Capwap] Architecture design team announcement & mission stmt In-Reply-To: <4D7B558499107545BB45044C63822DDE03F082A6@mvebe001.americas.nokia.com> Message-ID: <00a601c3fceb$6c1c3d50$67cadba8@LocalHost> I am not sure it is a stuff of capwap architecture but I'd ask capwap about default SSID and security aspect. Basically current APs have its default SSID from the manufacturer, so attackers can use these default SSIDs to attempt to penetrate APs that are stilll in their default configuration. Isn't it a security concern of capwap ? Thanks in advance ! - Daniel (Soohong Daniel Park) - Mobile Platform Laboratory, SAMSUNG Electronics. > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of > Dorothy.Gellert@nokia.com > Sent: Thursday, February 26, 2004 4:03 AM > To: capwap@frascone.com > Cc: mmani@avaya.com > Subject: [Capwap] Architecture design team announcement & mission stmt > > > All, > > We have a WG item to deliver an architecture taxonomy that > documents current market architectures to control and manage > 802.11 APs. Since we are limited to a short 6 month charter, > we are establishing a design team to ensure this goal is met. > Unless there are concerns regarding this approach, we will go > forward with it. > > The mission statement for the design team is to deliver an > architecture taxonomy draft according to the CAPWAP Charter: > 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 entities in each > approach do, > - Describe the advantages and disadvantages of each > approach for scalable 802.11 access network deployment > and management. > - contain a threat analysis that describes the security > threats involved in each > network architectural approach. > > This work will evolve WG item draft-ietf-capwap-arch-00.txt. > Lily Yang, co-author of the draft, will lead the architecture > design team. Regular reports will be posted to the capwap > mailing list after each meeting of the design team. Major > issues will also be brought to the list and decided based on > WG consensus. The output of the design team is subject to > the approval and modification of the WG. > If anyone is interested in working on the CAPWAP architecture > draft and has the time to contribute over the next 6 months > please contact Mani and I by Tuesday, March 3rd. We will > discuss the design team further at the Seoul IETF meeting. > > Regards, > Dorothy & Mani > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > From pcalhoun@airespace.com Fri Feb 27 14:43:37 2004 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Fri, 27 Feb 2004 06:43:37 -0800 Subject: [Capwap] Architecture design team announcement & mission stmt Message-ID: <55749BC69138654EBBC4C50BA4F55610010CA085@AIREMAIL.airespace.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3FD40.15A05A53 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This doesn't sound to me like it belongs in the CAPWAP charter - This is = clearly an IEEE issue. =20 And now my personal opinion. Hiding SSIDs is not a security scheme... in = fact, it just barely makes it more difficult to get onto a network. =20 PatC ________________________________ From: capwap-admin@frascone.com on behalf of S. Daniel Park Sent: Thu 2/26/2004 8:37 PM To: Dorothy.Gellert@nokia.com; capwap@frascone.com Cc: mmani@avaya.com; 'S. Daniel Park' Subject: RE: [Capwap] Architecture design team announcement & mission = stmt I am not sure it is a stuff of capwap architecture but I'd ask capwap about default SSID and security aspect. Basically current APs have its default SSID from the manufacturer, so attackers can use these default SSIDs to attempt to penetrate APs that are stilll in their default configuration. Isn't it a security concern of capwap ? Thanks in advance ! - Daniel (Soohong Daniel Park) - Mobile Platform Laboratory, SAMSUNG Electronics. > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of > Dorothy.Gellert@nokia.com > Sent: Thursday, February 26, 2004 4:03 AM > To: capwap@frascone.com > Cc: mmani@avaya.com > Subject: [Capwap] Architecture design team announcement & mission stmt > > > All, > > We have a WG item to deliver an architecture taxonomy that > documents current market architectures to control and manage > 802.11 APs. Since we are limited to a short 6 month charter, > we are establishing a design team to ensure this goal is met. > Unless there are concerns regarding this approach, we will go > forward with it. > > The mission statement for the design team is to deliver an > architecture taxonomy draft according to the CAPWAP Charter: > 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 entities in each > approach do, > - Describe the advantages and disadvantages of each > approach for scalable 802.11 access network deployment > and management. > - contain a threat analysis that describes the security > threats involved in each > network architectural approach. > > This work will evolve WG item draft-ietf-capwap-arch-00.txt.=20 > Lily Yang, co-author of the draft, will lead the architecture > design team. Regular reports will be posted to the capwap > mailing list after each meeting of the design team. Major > issues will also be brought to the list and decided based on > WG consensus. The output of the design team is subject to > the approval and modification of the WG. > If anyone is interested in working on the CAPWAP architecture > draft and has the time to contribute over the next 6 months > please contact Mani and I by Tuesday, March 3rd. We will > discuss the design team further at the Seoul IETF meeting. > > Regards, > Dorothy & Mani > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap ------_=_NextPart_001_01C3FD40.15A05A53 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= RE: [Capwap] Architecture design team announcement & mission = stmt=0A= =0A= =0A=
=0A=
This doesn't = sound to me like =0A= it belongs in the CAPWAP charter - This is clearly an IEEE = issue.
=0A=
 
=0A=
And now my personal opinion. = Hiding SSIDs =0A= is not a security scheme... in fact, it just barely makes it more = difficult to =0A= get onto a network.
=0A=
 
=0A=
PatC
=0A=

=0A=
=0A= From: capwap-admin@frascone.com on = behalf of S. =0A= Daniel Park
Sent: Thu 2/26/2004 8:37 PM
To: =0A= Dorothy.Gellert@nokia.com; capwap@frascone.com
Cc: = mmani@avaya.com; =0A= 'S. Daniel Park'
Subject: RE: [Capwap] Architecture design = team =0A= announcement & mission stmt

=0A=

=0A=

I am not sure it is a stuff of capwap architecture but =0A= I'd
ask capwap about default SSID and security = aspect.

Basically =0A= current APs have its default SSID from the
manufacturer, so attackers = can use =0A= these default SSIDs
to attempt to penetrate APs that are stilll in = their =0A= default
configuration. Isn't it a security concern of capwap = ?

Thanks =0A= in advance !


- Daniel (Soohong Daniel Park)
- Mobile = Platform =0A= Laboratory, SAMSUNG Electronics.

> -----Original = Message-----
> =0A= From: capwap-admin@frascone.com
> [mailto:capwap-admin@frascone.co= m] On =0A= Behalf Of
> Dorothy.Gellert@nokia.com
> Sent: Thursday, = February 26, =0A= 2004 4:03 AM
> To: capwap@frascone.com
> Cc: = mmani@avaya.com
> =0A= Subject: [Capwap] Architecture design team announcement & mission =0A= stmt
>
>
> All,
>
> We have a WG item to = deliver =0A= an architecture taxonomy that
> documents current market = architectures to =0A= control and manage
> 802.11 APs.  Since we are limited to a = short 6 =0A= month charter,
> we are establishing a design team to ensure this = goal is =0A= met.
> Unless there are concerns regarding this approach, we will =0A= go
> forward with it.
>
> The mission statement for = the design =0A= team is to deliver an
> architecture taxonomy draft according to = the =0A= CAPWAP Charter:
> The network architecture taxonomy will:
> =0A=       - Describe the current set of approaches =0A= (including the
>       traditional = autonomous AP =0A= architecture) to partitioning
>       = 802.11 =0A= access network functionality between network
> =0A=       entities,
> =       =0A= - List what the interfaces between the network entities
> =0A=       are in each approach,
> =0A=       - At a functional level, describe what = the =0A= protocols on
>       the interfaces = between the =0A= network entities in each
>       approach =0A= do,
>       - Describe the advantages and =0A= disadvantages of each
>       approach = for =0A= scalable 802.11 access network deployment
> =       =0A= and management.
>       - contain a = threat =0A= analysis that describes the security
> threats involved in = each
> =0A=       network architectural = approach.
>
> =0A= This work will evolve WG item = draft-ietf-capwap-arch-00.txt. 
> Lily =0A= Yang, co-author of the draft, will lead the architecture
> design =0A= team.  Regular reports will be posted to the capwap
> mailing = list =0A= after each meeting of the design team.  Major
> issues will = also be =0A= brought to the list and decided based on
> WG = consensus.   The =0A= output of the design team is subject to
> the approval and = modification of =0A= the WG.
> If anyone is interested in working on the CAPWAP =0A= architecture
> draft and has the time to contribute over the next = 6 =0A= months
> please contact Mani and I by Tuesday, March = 3rd.   We =0A= will
> discuss the design team further at the Seoul IETF =0A= meeting.
>
> Regards,
> Dorothy & =0A= Mani
>
>
> =0A= _______________________________________________
> Capwap mailing =0A= list
> Capwap@frascone.com
> http://mail.fra= scone.com/mailman/listinfo/capwap
>

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

=0A= =0A= =0A= ------_=_NextPart_001_01C3FD40.15A05A53-- From lily.l.yang@intel.com Fri Feb 27 15:28:30 2004 From: lily.l.yang@intel.com (Yang, Lily L) Date: Fri, 27 Feb 2004 07:28:30 -0800 Subject: [Capwap] capwap architecture comments Message-ID: <26BDFAFFB541B047B24179002EBE6D271560E3@orsmsx410.jf.intel.com> Hi, Inderpreet -- Inderpreet -- Thanks so much for all the thoughtful and detailed comments on the draft.=20 I am currently traveling out of the country this week and next week, and so have not had much time to catch up on email until tonight. That is why I have not responded earlier. As you and other people pointed out, this draft has not been fully updated to reflect the most recent development in CAPWAP WG -- it was initially written several months back, admittedly in a bit of hurry -- that is why you still find lots of explicit references to LWAPP and implicit assumptions based on LWAPP. Now that it is made clear to us that the initial focus of this group is to look at architecture only, we should certainly make sure we put the horse back in front of the cart! I believe significant work is needed for this draft to get to where we want to be in six months, as dictated by the charter. In my mind, this draft might be a good spring board to get some discussions going, but we are still early enough in the process that I would not hesitate to start from a clean sheet of paper if that is how people feel like doing. So I would encourage everyone to take a step back and don't hesitate to make constructive, even if drastic, change to the draft. See my own comments below between tags ... .=20 Lily -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Inderpreet Singh Sent: Sunday, February 22, 2004 8:06 PM To: capwap@frascone.com Subject: [Capwap] capwap architecture comments Hi,=20 I have read http://www.ietf.org/internet-drafts/draft-ietf-capwap-arch-00.txt and the following are my comments: High level comments on entire spec: - Need to take out any references to the LWAPP spec. First of all, it is an expired draft and since the charter is focused on architecture taxonomy it is not appropriate to mention specific protocols here (especially protocols that are not standard yet.). =20 Agree. Specific section comments: 2.2 CAPWAP Motivation The draft notes that all of the benefits can be provided "by terminating the 802.11 management frames in the AR". Why mention that and be partial toward that specific type of implementation? There are other implementations of the architecture that accomplish the same thing and provide the same benefits without having to send all the 802.11 management frames back to the centralized controller. Are we not striving for the case of making the architecture document to be at least a little bit architecture and protocol agnostic? =20 I also agree that "terminating the 802.11 management frames in the AR" is the assumption made by LWAPP but more discussion is warranted there. Besides, that really is a protocol decision, but not an architectural one. So we should take it out in this draft. The last paragraph of this section also makes a pretty drastic assumption. If the split AP implementation (not split-AP architecture but split-AP implementation!) is the prevalent implementation of a given architecture, then the assumption is that the MAC of a new or different wireless technology is also inherently "splittable". It just so happens that the IEEE did not mandate the way 802.11 MAC should be implemented so some vendors took the liberty of arbitrarily splitting it. What's to say that such splitting will be possible for the MAC layers of other technologies. Either we go with not even mentioning what happens in the case of any other wireless technologies, in which case the benefits of an implementation only apply to 802.11 networks, or we say in the true spirit of the IETF that we are going to strive to be layer 2 agnostic (or wireless technology agnostic). I acknowledge the constraints of the capwap charter placed on us by the iesg, ie. to remain in the realm of 802.11 access, but the latter (wireless technology agnostic architecture) is my preference. Nevertheless, given the constraint of 802.11 only, let's not mention any benefits or disadvantages to other wireless technologies. while I strongly believe control and provisioning is also needed in other radio technologies beyond 802.11, I don't object to the idea of focusing on 802.11 first before anything else in this WG. On the other hand, since we are on the subject, I would argue that "splittability" is NOT such an essential and special concept to 802.11 only. What is essential here is really just the concept of "centralized decision making" -- which is really not that special to 802.11 at all. The debate of distributed (autonomous) decision making versus centralized control is so old and familiar that I believe the pros and cons of each approach is well understood in principles and applicable in many settings (social or technological). But of course, the devil is always in the details and so we still need to figure out a lot of the specifics here. Typically and predictably, a combination of these two approaches wins over either of the extreme approach -- maybe that is where the "split" concept comes in -- how you combine the two approaches means how you split the responsibility between a centralized entity and local entity. Ok. I would concede that if we want to use "split" concept as the essential foundation, I would then argue, it is definitely not special to 802.11 only. But it maybe true that the best way to "split" 802.11 is indeed different from how you would "split" 802.16 control functions. That being said, I would support of staying clear of mentioning the unknown benefit or disadvantages to other wireless technologies in this draft.=20 BTW, I don't really understand what distinction you are referring to between "split-AP architecture" and "split-AP implementation".=20 3.2.2 AP to AR Topologies I wanted to confirm that Figure 4 is the same as the figure given below. Why would there be any difference between a router and an L3 Cloud? As a matter of fact, why would even Figure 3 not be covered by my modified version of Figure 4 given below? (I just changed the word "router" with "L3 cloud") Further more the same comment applies to Figure 2. All you really need to do is depict an L2 Cloud. If you don't do that then another interpretation of the figures is that the AC/AR/AB must support all topological types at the same time. Which is fine. But lets make that clear on all topologies. =09 --------------------------------------------------------------------- +-------+-------+ | + + AR + + | +-------+-------+ | --------+------ LAN | +-------+-------+ | <> | +-------+-------+ | -----+--+--+--- LAN | | +---+ +---+ | | +--+--+ +--+--+ | AP | | AP | +--+--+ +--+--+ I think you are right that a cloud is what we really meant here.=20 3.3 Access Router Discovery Just a general comment: I think 3.3 section needs a lot of rework and re-organization, well, like the rest of the document.=20 "The type of discovery protocol is also dependent on prior one-time Provisioning of AP (configuration)." If discovery includes authentication and registration of AP to AR then I agree that apriori provisioning of AP's is a dependency on the discovery mechanism. However, for large scalability this might be an issue. One would have to assume that regardless of the architecture, the AR-AP authentication and registration protocol would have to be the same. We went down this rat hole during the lwapp discovery and security discussion. If we are prepared to continue that rat hole race then let's bring it up here.or else take it out. The simple issue of Discovery here is L2 domain discovery or L3 domain discovery. This is the IETF so L3/IP discovery is most interesting. It should work on anything that carries IP. Why have a different discovery protocol for Layer 2. The key question in my mind is: What is the impact of architecture variants on the discovery of AC, if any? 3.3.3 Access Point Service Management "An adaptive RF management based on .. is needed to be driven from ACs (or at times a hierarchy of ACs)." The question is WHY? An adaptive RF management algorithm on a large scale WLAN can be driven from either the APs or the AC, however the notification, approval, frequency of change, limits to change (bounding the fluctuations) is what needs to be centralized in the AC. Again, I think we were getting ahead of ourselves here, by making assumptions that this document should not be making. 3.3.5.2 Mutual Authentication of AP and AR "The Key Management protocol choices are governed by the worst-case specification of Lightweight AP (LAP) capabilities." Didn't quite understand this sentence since a new "capabilities" type was introduced and that got confusing. Are you saying that the Key Management protocol choices must take into consideration the constraints of an AP that are say part of ARCH3 (in which the AP is really nothing more than an RF antenna). It is more likely that it has the least amount of CPU cycles and would not be able to manage a compute intensive algorithm? Just wanted clarification. I would let Mani or Bob comment on this one. 4. Prior Work Let me say that this whole section reads like a protocol comparison as opposed to an architecture comparison. This is the main section that I believe requires a re-write and what needs to happen is a comparison of DIRAC with each architecture type that is described in the spec. Similarly, a comparison of ForCES with each architecture type. The draft is doing a DIRAC vs. LWAPP and ForCES vs. LWAPP. To quote another wlan infrastructure vendor "...cart before the horse..."! That is fair assessment, because at the time of writing this, I was thinking of both architectures and protocols. So we need to rewrite for sure. Having said that, section 4.2.2 is truly in the spirit of architecture comparison. Nevertheless the text reads as if to say that the "arbitrary L3 cloud" between AP and AR is a possibility to not be supported. As per my discussion about section 3.2.2 I want to go on record and say it MUST be supported. "arbitrary" is a scary word to me. There might be some dependency between topological assumptions and architectural implications here. For example, if it is truly arbitrarily large L3 cloud between AC and AP, ARCH3 might not be feasible, due to the delay etc. We've gone through similar debate in ForCES, and it is a compromise for the WG to settle on "close-proximity" first, but most people agree to it, due to security and complexity considerations. Sounds like you have strong motivations to support arbitrary L3 cloud, I would love to understand this more. Let's get the discussion started. Thanks Inderpreet Singh _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From lily.l.yang@intel.com Fri Feb 27 16:33:21 2004 From: lily.l.yang@intel.com (Yang, Lily L) Date: Fri, 27 Feb 2004 08:33:21 -0800 Subject: [Capwap] Comments on architecture draft Message-ID: <26BDFAFFB541B047B24179002EBE6D271560E5@orsmsx410.jf.intel.com> Saravanan -- The intent of this document is=20 1) to recognize the variants in split AP architectures 2) and hence to motivate the need to understand all these different variants 3) and understand the implication on interoperability. Your comments give me the impression that all these didn't come across at all, then I must admit we probably did a rather poor job of conveying these intents. As I indicated in my other email reply to Inderpreet, I do expect some significant work here, so feedback like this is very helpful.=20 Lily -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan Sent: Wednesday, February 25, 2004 1:52 AM To: capwap@frascone.com Subject: [Capwap] Comments on architecture draft Dear All, These are some comments regarding the CAPWAP architecture draft.=20 1. The motivation section (2.2) does not recognize the incompatibilities in the split AP architecture. Today, different manufacturers use different ways of splitting functionality. For example, one firm sells APs with encryption/decryption features and corresponding ACs without this. Another firm puts security at the ACs and sells APs without them. As such, APs designed for one type of controller are not compatible with other controllers. I feel this should also serve to motivate the efforts of the WG. 2. Section 2.2 again, ("All of the above can be provided..."), the split AP approach seems to imply a certain way of splitting. However manufacturers follow different types of splits - some choose to realize real-time components at an AC so as to achieve wider scope of benefits. Based on available specifications, there are firms that include transmit power control at the AP and others that place them at the AC. On a more drastic case, one firm centralizes the entire MAC at the AC. This implication about the split AP approach should therefore be removed. It would be better to just say it is one where 802.11 protocol components are divided between AP and AC.=20 3. Sections 3.1.1 and 3.1.2 mandate which WLAN services go where and this is tantamount to defining how to split WLAN functionality. It has to be realized that there are merits to other means of splitting functions too. And CAPWAP should be able to accommodate these differences. It would be better to remove these restrictions. Alternatively, they may be included as part of one of the architectures in Section 2.3. 4. Regarding the capabilities negotiation section (3.3.2), it requires that only if 'the architectural types match' will an AP be able to register with an AC. This does not seem to fulfill CAPWAP's goal of striving for compatibility. Such a requirement limits interoperability to only those devices of a particular architecture type. This is too restrictive. Cross-architectural compatibilities have to be realized as part of CAPWAP too. Cheers Saravanan --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.594 / Virus Database: 377 - Release Date: 24/02/2004 =20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap