| RE: comment about LWAPP and other wireless technologies | <– Date –> <– Thread –> |
From: Sadot, Emek (Emek) (esadot avaya.com)
|
|
| Date: Mon, 8 Aug 2005 15:47:04 -0400 (EDT) | |
Pat, Thanks pointing it out. However, I think that the fact that, at time, all Split arch. vendors incorporated the DS at the AC shouldn't discourage the group from structuring a protocol that can comprehensively support various applications. The IETF mandate working group to satisfy market requirements not to create a protocol to support existent products, that at time may not have been mature enough. Regards, Emek -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun [at] cisco.com] Sent: Monday, August 08, 2005 10:02 AM To: Sadot, Emek (Emek); Nehru Bhandaru; Yuval Cohen; Bob O'Hara (boohara); capwap [at] frascone.com Subject: RE: [Capwap] comment about LWAPP and other wireless technologies I will point you to figure 12 in the taxonomy document. In ALL six cases the Split MAC architectures handle both the DS and the IS functions in the AC. So I wonder why we should consider creating a protocol for which no products would use? Let's keep this simple and focus on market need. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: capwap-admin [at] frascone.com > [mailto:capwap-admin [at] frascone.com] On Behalf Of Sadot, Emek (Emek) > Sent: Thursday, August 04, 2005 11:12 PM > To: Pat Calhoun (pacalhou); Nehru Bhandaru; Yuval Cohen; Bob O'Hara > (boohara); capwap [at] frascone.com > Subject: RE: [Capwap] comment about LWAPP and other wireless > technologies > > I respectfully disagree with the assumption that Split MAC is define > as *all* AP functions in the AC, and in particular the DS. This issue > was exhausted in the list. If my memory server me right the key > arguments in favor of offload the DS to the WTP were: > - CAPWAP is a control protocol, has nothing to do with data flow > - Avoid hammering the AC with data traffic > - Shortest path for data packets > > Regards, > Emek > > -----Original Message----- > From: capwap-admin [at] frascone.com > [mailto:capwap-admin [at] frascone.com] On Behalf Of Pat Calhoun (pacalhou) > Sent: Wednesday, August 03, 2005 9:57 AM > To: Nehru Bhandaru; Yuval Cohen; Bob O'Hara (boohara); > capwap [at] frascone.com > Subject: RE: [Capwap] comment about LWAPP and other wireless > technologies > > So this would be an argument for local bridging and tunneling of 802.3 > frames in local mode. I think that would be a good compromise. I > believe that changing the basic fundamentals of Split MAC, which means > *all* AP functions are performed in the AC (possibly including > encryption), would be a mistake. > > The taxonomy recommendation already recommends that Local MAC be the > "mandatory" mode, but if the WG agrees, we could make changes to allow > for tunneling of traffic in an 802.3 mode. > > Pat Calhoun > CTO, Wireless Networking Business Unit Cisco Systems > > > > > -----Original Message----- > > From: capwap-admin [at] frascone.com > > [mailto:capwap-admin [at] frascone.com] On Behalf Of Nehru Bhandaru > > Sent: Wednesday, August 03, 2005 5:39 AM > > To: Yuval Cohen; Bob O'Hara (boohara); capwap [at] frascone.com > > Subject: RE: [Capwap] comment about LWAPP and other wireless > > technologies > > > > > > All, > > > > IMHO supporting the case where 802.11 <-> 802.3 conversion > is done at > > the WTP and 802.3 is transported to AC is important to leverage > > existing silicon in the data path at the AC. This can be > accomplished > > in many ways in CAPWAP - one option that seems to be under > debate is > > to consider this as a mode of Split MAC. > > > > Another, something I like better and not very complicated, is to > > consider this an Local MAC option where the integration/portal > > function of 802.11 AP is at the AC. With this model, LWAPP control > > protocol (in the Local MAC case) could negotiate the > encapsulation for > > the data path to the portal. This could be GRE, LWAPP(L2/L3) or > > whatever - with inner payload of 802.3. RSSI/SNR/etc values can be > > obtained from the encapsulation header... > > > > Split MAC could carry 802.11 only in the data path. > > > > - Nehru > > > > -----Original Message----- > > From: capwap-admin [at] frascone.com > > [mailto:capwap-admin [at] frascone.com] On > > Behalf Of Yuval Cohen > > Sent: Wednesday, August 03, 2005 5:55 AM > > To: Bob O'Hara (boohara); capwap [at] frascone.com > > Subject: RE: [Capwap] comment about LWAPP and other wireless > > technologies > > > > Bob, > > the discussion is not only about local MAC but also about split > > MAC. The > > local MAC was given just as an example. > > For reasons provided before, I see also a lot of sense in using > > 802.3 > > frames also in the split MAC case, where you do the distribution > > function (based on 802.3 frame switching) within the AC > > Since in any case you need to add the 802.11 specific > info (like > > RSSI), > > I'd rather see it within the LWAPP tunnel header so I > can choose > > if to > > take it from there or not and keep the frame 802.3. > This will give > > the > > most flexibility for those implementations that need the extra > > info and > > for those looking into simple implementations not requiring > > processing > > the extra info or allowing processing in the WTP > > > > I would like to hear more opinions on the WG mailing list as to > > how > > important it is to support this also in split MAC case > > > > Yuval > > > > > > > > > > > > -----Original Message----- > > From: capwap-admin [at] frascone.com > > [mailto:capwap-admin [at] frascone.com] On > > Behalf Of Bob O'Hara (boohara) > > Sent: Wednesday, August 03, 2005 11:49 AM > > To: capwap [at] frascone.com > > Subject: RE: [Capwap] comment about LWAPP and other wireless > > technologies > > > > I guess I fail to see what this controversy is all about. > > If you want > > to forward 802.3 frames from the WTP, you are using the > local MAC > > variant supported by LWAPP. In fact, that is what the taxonomy > > draft > > specifies. > > > > If all you have in your AC is Ethernet switch silicon > on the data > > path, > > this is the only reasonable implementation. To say > that another > > option > > is necessary to support conversion of 802.11 frames to > > 802.3 frames in > > the WTP in split MAC mode, separate the 802.11-specific > > information and > > forward the 802.3 frames and separated 802.11 information about > > those > > forwarded 802.3 frames in LWAPP packets is ridiculous. > > Just because you > > have a hammer, doesn't mean that everything else in the > world is a > > nail. > > > > It seems that this is a tremendous complication to the > AC, which > > now > > needs to correlate this separated information. This correlation > > operation was not necessary when the 802.11 frames were > forwarded > > directly, since the frames and their information > arrived whole and > > together. > > > > In order to reduce the computing load on the AC to correlate the > > separated information, the WTP could send only summarized > > information. > > Of course, this reduces the amount of information > available to the > > AC, > > without justification. > > > > -Bob > > > > -----Original Message----- > > From: capwap-admin [at] frascone.com > > [mailto:capwap-admin [at] frascone.com] On > > Behalf Of Michael Vakulenko > > Sent: Wednesday, August 03, 2005 12:27 AM > > To: Pat Calhoun (pacalhou) > > Cc: Yuval Cohen; Tal Anker; capwap [at] frascone.com > > Subject: RE: [Capwap] comment about LWAPP and other wireless > > technologies > > > > Pat, > > > > Your question is independent of whether CAPWAP tunnels 802.3 or > > 802.11 frame. Signal strength field does not present in > > 802.11 frame > > headers. Having tunnel 802.11 frames doesn't solve the problem. > > > > Thanks, > > > > -- Michael V. > > > > At 08:46 AM 8/3/2005, Pat Calhoun \(pacalhou\) wrote: > > >Yuval, > > > > > >I'd like to comment on your point about having the WTP process > > the > > >information, and provide a digested version of the > information. > > How > > >would you propose that the WTP represent the changes in signal > > strength > > >(which occur in real time) to the AC - and how > frequent would you > > >propose these updates be made? Would this be a packet > that hits > > the > > >control processor, because if so, then I have some serious > > scaling > > >concerns. > > > > > >That said, I think that in the end we need the > evaluation team to > > make > > a > > >recommendation on a protocol, and then let the WG > decide. If the > > WG > > >decides that two separate protocol formats would be > better than > > one, > > >then we can go down that path (and make sure that we make one > > mandatory > > >to implement). > > > > > >Pat Calhoun > > >CTO, Wireless Networking Business Unit > > >Cisco Systems > > > > > > > > > > > > > -----Original Message----- > > > > From: Yuval Cohen [mailto:YuvalC [at] marvell.com] > > > > Sent: Tuesday, August 02, 2005 3:18 PM > > > > To: Pat Calhoun (pacalhou) > > > > Cc: Tal Anker; capwap [at] frascone.com > > > > Subject: RE: [Capwap] comment about LWAPP and other wireless > > > > technologies > > > > > > > > Pat, > > > > While the control path is usually implemented in CPU, the > > > > data path in some cases is realized in silicon. Processing > > > > 802.11 frames may add to complexity and cost. > > > > > > > > I agree that in some cases, there is a need for the WTP to > > > > send the 802.11 frame, as in the case of centralized crypto > > > > (although that may conflict with HCCA) but for those > > > > implementations not requiring that and in > particular local AP > > > > case, there is no real need for 802.11 frame > reaching the AC. > > > > The extra info within the 802.11 frame can be processed > > > > within the WTP and provided to the AC if needed via the > > > > control plane, possibly after some digestion. > > > > Using 802.3 frames only, will keep the implementation simple > > > > and will enable a large install base of existing switches to > > > > become AC with just software upgrade. This will aid wide > > > > adoption of LDAP. > > > > > > > > > > > > My recommendation is that LWAPP will not limit the frame > > > > format to 802.11 only but rather allow two formats, either > > > > 802.11 or 802.3. > > > > > > > > Yuval > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: capwap-admin [at] frascone.com > > > > [mailto:capwap-admin [at] frascone.com] On Behalf Of Pat Calhoun > > (pacalhou) > > > > Sent: Wednesday, August 03, 2005 12:16 AM > > > > To: Tal Anker; capwap [at] frascone.com > > > > Subject: RE: [Capwap] comment about LWAPP and other wireless > > > > technologies > > > > > > > > Tal, > > > > > > > > Thanks for the e-mail. > > > > > > > > I believe that I understand your point, but I would argue > > > > that the AC will have to be modified to support a new > > > > technology, and that upgrading the code in the data path is > > > > really no more difficult than the control path. If an > > > > implementation exists that does not allow for upgrade, then > > > > it is limiting its market. > > > > > > > > I would argue that include "technology specific" information > > > > piggy backed within the LWAPP data frame would be hard to > > > > achieve, because we cannot predict what this information > > > > would end up being. For instance, > > > > 802.11 has the concept of a BSSID, while 802.16 has > something > > > > different (and has additional information). So how would you > > > > map 802.11 QoS field into a field that may not match with > > 802.16s? > > > > > > > > If one were to need to extend the piggy backed header, then > > > > this would require changes to the data path anyhow. Further, > > > > certain features will require changes to the data path, for > > > > instance the introduction of 802.11i centralized encryption > > > > requires that the data path perform AES-CCMP, and 802.11e > > > > requires specific quality of service queuing and policing. > > > > > > > > So while I understand the point raised, I firmly > believe that > > > > transporting the native frame provides the AC with > all of the > > > > information for the specific technology, and allows it to > > > > provide differentiated services based on the information > > > > present - vs. limiting it to what generic information would > > > > be in this piggy backed header. > > > > > > > > Pat Calhoun > > > > CTO, Wireless Networking Business Unit > > > > Cisco Systems > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: capwap-admin [at] frascone.com > > > > > [mailto:capwap-admin [at] frascone.com] On Behalf Of Tal Anker > > > > > Sent: Tuesday, August 02, 2005 7:47 AM > > > > > To: capwap [at] frascone.com > > > > > Subject: [Capwap] comment about LWAPP and other wireless > > > > technologies > > > > > > > > > > Resending this (it seems the first attempt fails... > > > > > appologies if you receive duplicate copies...). > > > > > > > > > > Hi, > > > > > while going over the LWAPP draft and on the objecives of > > > > CAPWAP there > > > > > seems to be a CAPWAP objective that may not be fully > > > > achieved with the > > > > > current LWAPP spec. > > > > > The LWAPP specification requires that the 802.11 frames > > would be > > > > > encapsulated by the WTP and sent to the AC for processing. > > > > > The benefit from doing this is having the original info > > > > carried in the > > > > > .11 frame available to the AC. > > > > > However, this requires the AC to process the native 802.11 > > > > frames; an > > > > > operation that will probably be done in some HW component. > > > > My concern > > > > > is that one of the CAPWAP objectives was to be applicable > > > > not only to > > > > > 802.11 but for various wireless technologies. As a result > > the > > LWAPP > > > > > should also be applicable no only for 802.11... (as it > > > > indeed states > > > > > in the beginning of the LWAPP draft). However > mandating that > > the > > > > > wireless media frames would be sent to the AC in their > > > > original format > > > > > would make this objective harder to achieve... When a new > > wireless > > > > > media type would be introduced, the AC would have to be > > somehow > > > > > adapted to process the data frames (not only the control > > > > frames that > > > > > can obviously be processed in the AC cpu...). > > > > > This means either a HW change (or if the AC is using NP > > > > then an NP SW > > > > > upgrade). > > > > > What seems reasonable to do is to add the OPTION for > > > > sending the data > > > > > frames to the AC using the media type tha tthe WTP is > > > > connected to the > > > > > AC with. Meaning - to convert the frame in the WTP and to > > > > send it to > > > > > the AC for instance using 802.3 ethernet > frames... This way > > > > when a new > > > > > wireless technology is inroduced to the AC all that needs > > > > to be done > > > > > is updating the SW of the AC. > > > > > > > > > > As for loosing the specific media information that was in > > the > > > > > 802.11 header - this info can be collected by the WTP and > > > > be sent to > > > > > the AC using LWAPP protocol messages... > > > > > > > > > > Supporting both the current LWAPP suggestion (sending the > > original > > > > > 802.11 frames to the AC) AND the option to > convert to the AC > > media > > > > > type will allow LWAPP to comply to the "future wireless > > > > technologies" > > > > > objective... > > > > > > > > > > - Tal > > > > > > > > > > > > > > > > > > > ===================================================================== > > > > > Tal Anker, PhD. > > > > > DANSS - Distributed Algorithms, Networking and Secure > > Systems > > Group. > > > > > The School of Engineering and Computer Science, The hebrew > > > > University > > > > > of Jerusalem, Israel. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Capwap mailing list > > > > > Capwap [at] frascone.com > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap [at] frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > >_______________________________________________ > > >Capwap mailing list > > >Capwap [at] frascone.com > > >http://mail.frascone.com/mailman/listinfo/capwap > > > > _______________________________________________ > > Capwap mailing list > > Capwap [at] frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ > > Capwap mailing list > > Capwap [at] frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > pjXX&_ whm~rr+-wƩ > > j~rr > > > pjXX&_ whm~rr+-wƩ > > jXX&wh~rr+w >
- RE: comment about LWAPP and other wireless technologies, (continued)
- RE: comment about LWAPP and other wireless technologies Yuval Cohen, August 3 2005
- RE: comment about LWAPP and other wireless technologies Sadot, Emek (Emek), August 4 2005
- RE: comment about LWAPP and other wireless technologies Sadot, Emek (Emek), August 4 2005
- RE: comment about LWAPP and other wireless technologies Pat Calhoun (pacalhou), August 8 2005
- RE: comment about LWAPP and other wireless technologies Sadot, Emek (Emek), August 8 2005
Results generated by Tiger Technologies using MHonArc.