From brunner@ccrle.nec.de Mon Oct 6 08:04:21 2003 From: brunner@ccrle.nec.de (Marcus Brunner) Date: Mon, 6 Oct 2003 07:04:21 -0000 (GMT) Subject: [Lwapp] capwap charter comments from iab and iesg In-Reply-To: References: Message-ID: <3434.10.1.1.83.1065423861.squirrel@yamato.ccrle.nec.de> If I understand the concerns right there the following: - It seams that there are concerns regarding the IEEE/IETF coordination. An IEEE review does not hurt and could be included into the charter. - secure download I never have been keen on standardizing - the one on re-use of other IETF protocols had to come up anyway, I assume this can be discussed. I am meanwhile convinced that at least the AP configuration/control protocol is new. What are the further steps? Marcus > the following are charter review comments from the iab and iesg. > > randy > > --- > > To: Randy Bush > cc: iesg , iab > Subject: Re: trial baloon - capwap > Date: Mon, 29 Sep 2003 08:26:22 -0400 > > I have not been following this effort at all. But my read of the > charter, it has vague written all over it. Hmm, one needs to read the > problem statement ID. Assuming it is representative and is pretty good > description of the actual problem, I can see the need for work in this > space. > > Some general thoughts. > > Isn't the AR/AP functionality split IEEE business? Why is it to become > IETF business? And what is the scope of the problem that IETF will > need to solve? (I can live with the IETF deciding the split, so long > as IEEE is OK with us owning this part of the problem - though it > seems a bit odd for us to take this on.) > > Note: how is this really different than layer 2 switches, that > presumably have many of the same issue with regards to > functionality/split/mangement/etc.? > > Note: For a long while, I've had trouble understanding whether an AP > is an L2 or an L3 thingie. That is important, because IMO, L2 stuff > generally isn't IETF business. But folk in many camps seem to talk > about APs as if they were L3 thingies, even though this has not been > clear to me. The problem statement seems to say they are L3 > thingies. And the need for the IETF to be involved is then presumably > that IP protocols will be used in preference to L2 protocols, even > though a lot of what those protocols carry will be L2-specific stuff. > > Note: one reason I am concerned about the AP vs. AR differences is > that if APs are IP devices and a part of the general architecture, > folk become tempted to have clients distinguish between APs and > ARs. This (IMO) complicates clients/protocols, maybe in ways we don't > like. This sort of thing is to some extent assumed by groups like > seamoby and/or fast handoffs in MIP and temps folk greatly when > looking for optimizations... > >> As the size and complexity of IEEE 802.11 wireless networks have >> increased, problems in the deployment, management, and usability of >> these networks have become evident. >> draft-calhoun-capwap-problem-statement-00.txt describes some of >> those problems. In addition, security considerations have become >> increasingly important as IEEE 802.11 networks have been deployed >> in situations where their use in accessing sensitive data must be >> restricted for business or other reasons. > > I don't immediately see this in the problem statement. Discussion > there seem to be restricted to making sure APs are authenticated > before being allowed to join the network. Is this item about replacing > WAP with something better? (I can read it this way...) > >> While there are many >> possible approaches to solving these problems, most of them involve >> IP-level protocols in some fashion. To the extent changes to >> existing IETF protocols are necessary or new IP-level protocols >> must be standardized to facilitate interoperability, this work is >> an appropriate topic for the IETF. > >> [ note that the last sentence makes no sense to me. i suspect that >> there is an s/IETF/IEEE/ needed somewhere in it. ] > > My take is that there will need to be MIB (or related) work, maybe > secure download (which would be an IETF issue at L3). I guess I see > potential work items here, but I'd be a bit concerned that any work > done is done generically (e.g., secure download) and not just for this > effort. But this will conflict with "need solution yesterday". > >> The charter of the CAPWAP Working Group is to investigate and >> design a protocol for the purpose of simplifying the deployment, >> management, and usability of IEEE 802.11 wireless networks for >> Internet use. > > Wording seems to presume new protocols are needed. Case needs to be > made, IMO. > >> The Working Group will attempt to utilize existing >> IETF protocols where possible, but will engage in new design if >> necessary. The Working Group's designs will focus on the "split >> AP" architecture. The split AP architecture centralizes processing >> of access point (AP) management functions, such as inter-AP >> configuration and control, and non-realtime host functions, such as >> data transport and host authentication, in a management entity, >> typically an access router (AR). The IEEE 802.11 APs continue to >> perform real-time host functions. The split AP architecture does >> not involve any changes in IEEE 802.11 standards, since the IEEE >> 802.11 specification says nothing about the architecture of the >> IEEE 802.11 access point. This new architecture has been adopted >> by many manufacturers, each with some variation. Creating an >> interoperable protocol between the AP and the AR will benefit the >> network operator community by allowing operators to build networks >> with equipment from a variety of conforming vendors. > > Seems to be that one of the highest priority (and possibly most > contentious) things to get done is get agreement on the functionality > split. Until this is done, it will remain unclear what protocols are > needed. > >> Specific Working Group work items are: >> - Clear problem statement and description of the split AP >> architecture, > > Seems OK to me. > >> - CAPWAP security requirements, defining the needs for security >> between the AP and the AR both for host data transport and for >> AP-AR signalling and control, > > Not sure why "host data transport" is included here. Will user data be > tunneled in IP protocols? Fine with me, but this seems like an odd > thing to do at this level. I.e., I wouldn't have assumed this is a > desired starting point. > >> - A protocol for implementing the split AP architecture, >> including the following functionality: > > I'd remove all of this from the charter until the previous work has > been done. > >> . Discovery of ARs by APs (this work should point to existing >> IETF standards, if possible) > > Indeed, I wonder how this relates to the device discoery BOF that > wasn't held last time around (and for which the propoents have been > completely silent since the Vienna...) > >> . Auto-organization of APs and ARs into a managed wireless >> access network, including failover if an AR should fail, >> . A tunneling protocol for IEEE 802.11 non-realtime >> host-related signalling and data between the AP and the AR, >> . Support for configuration of the AP by the AR, including >> secure download and booting of code to the AP (some aspects >> of this task may involve existing IETF standards), >> . Security for both tunneled host data and AR-AP signaling, as >> necessary to address the requirements (this work may involve >> utilizing existing IETF standards). > > Again, I'd leave this all out until the split/problem statement are > mostly done. > >> The intent of the CAPWAP Working Group is to complete the protocol >> specification as quickly as prudently possible and to serve as a >> forum for discussion of issues found when testing interoperability, >> in typical IETF fashion. > > Here is the dilemma. Needed Yesterday. > >> While not specifically a work item, the Working Group will attempt >> to make all designs as independent of the IEEE 802.11 radio >> protocol as possible, so that the protocol might, in the future be >> used with other radio protocols. However, in any situation where a >> tradeoff between simplicity/speed of design completion and >> extensibility is required, the Working Group will opt for the >> former. > > Seems like an odd thing to write into the charter. Seems like an item > that people will be able to use to shut people up who raise issues > about basic design tradeoffs. > >> The Working Group will also co-ordinate closely with the >> IEEE 802.11 WG. > >> Specific non-goals of this work are: > >> - Support for general, inter-subnet micromobility, >> - Interoperable APIs for downloaded AP code images, >> - Any IP-layer work that would require changes to the IEEE 802.11 >> MAC layer, >> - Dependence on yet to be approved IEEE 802.11 work or drafts, >> - Support for an inter-AP communication protocol, like IEEE >> 802.11f, >> - Direct joint development of protocols with the IEEE 802.11 WG. > >> Working Group protocol documents and the security requirements will >> be sent to the Security Area Advisory Group (SAAG) for review prior >> to submission to the IESG. > >> Goals and Milestones: > >> Mar 2004 Complete problem statement draft and architecture >> description and submit to IESG for publication as >> Informational. > >> Mar 2004 Complete security requirements and submit to SAAG for >> review. Submit to IESG for publication as Informational >> when SAAG review is complete. > > Seems like a good time for recharter/recheck. > >> Nov 2004 First draft of CAPWAP protocol complete and ready for >> review. > >> Mar 2005 Complete CAPWAP protocol and submit to SAAG for review. >> Submit to IESG for publication as Proposed Standard when >> SAAG review is complete. > > Just to be clear, this protocol seems to have been needed yesterday, > and speed is more important than anything else according to some of > the charter wording. Yet, I see a (probably realistic) target of > almost 2 years from now. I hope everyone is on the same page here. > > > --- > > > To: randy@psg.com, iesg@ietf.org > Cc: iab@ietf.org > Subject: Re: trial baloon - capwap > Date: Mon, 29 Sep 2003 08:28:46 -0700 > >> The split AP architecture does >> not involve any changes in IEEE 802.11 standards, since the IEEE >> 802.11 specification says nothing about the architecture of the >> IEEE 802.11 access point. > > This isn't really true. There are quite a few assumptions about Access > Point behavior made in IEEE 802.11, although they are mostly not explict. > It is true that an AP may not conform to the classic Bridge Architecture > of > IEEE 802.1D, but much of the behavior needs to be equivalent for things > like > VLAN tagging/untagging to work properly. > > One thing that is very clear about the IEEE 802.11 architecture is that > the > AP is *not* required to be an "Access Router", and that an AP needs to be > able to perform functions like VLAN tagging and untagging like an 802.1D > bridge would, not a router. So I am concerned that this little sentence > hides some major mis-understandings about the function of an IEEE 802.11 > which will come back to bite us later. > >> This new architecture has been adopted >> by many manufacturers, each with some variation. Creating an >> interoperable protocol between the AP and the AR will benefit the >> network operator community by allowing operators to build networks >> with equipment from a variety of conforming vendors. > > This is not true in general. 802.11 APs have so many proprietary aspects > that I doubt that a single protocol could enable interoperability across > the > board. For example, many APs have proprietary Inter-Access Point > Protocols > (IAPPs); others do proprietary communication between the STA and AP; > still > others have proprietary fast handoff schemes. > >> >> Specific Working Group work items are: >> - Clear problem statement and description of the split AP >> architecture, > > It's hard for me to see how work on 802.11 AP architecture belongs in the > IETF, unless there is some kind of review process with IEEE to make sure > it > makes sense. It's been hard enough to get architectural agreement with > IEEE > 802.11. > >> - CAPWAP security requirements, defining the needs for security >> between the AP and the AR both for host data transport and for >> AP-AR signalling and control, > >> - A protocol for implementing the split AP architecture, >> including the following functionality: > >> . Discovery of ARs by APs (this work should point to existing >> IETF standards, if possible) > >> . Auto-organization of APs and ARs into a managed wireless >> access network, including failover if an AR should fail, > >> . A tunneling protocol for IEEE 802.11 non-realtime >> host-related signalling and data between the AP and the AR, > > Doesn't the IETF have enough tunneling protocol already? > > >> . Support for configuration of the AP by the AR, including >> secure download and booting of code to the AP (some aspects >> of this task may involve existing IETF standards), > > It's hard for me to see why this WG should be allowed to do any work on > the boot problem. > >> . Security for both tunneled host data and AR-AP signaling, as >> necessary to address the requirements (this work may involve >> utilizing existing IETF standards). >> >> The intent of the CAPWAP Working Group is to complete the protocol >> specification as quickly as prudently possible and to serve as a >> forum for discussion of issues found when testing interoperability, >> in typical IETF fashion. >> >> While not specifically a work item, the Working Group will attempt >> to make all designs as independent of the IEEE 802.11 radio >> protocol as possible, so that the protocol might, in the future be >> used with other radio protocols. However, in any situation where a >> tradeoff between simplicity/speed of design completion and >> extensibility is required, the Working Group will opt for the >> former. The Working Group will also co-ordinate closely with the >> IEEE 802.11 WG. >> >> Specific non-goals of this work are: >> >> - Support for general, inter-subnet micromobility, >> - Interoperable APIs for downloaded AP code images, >> - Any IP-layer work that would require changes to the IEEE 802.11 >> MAC layer, >> - Dependence on yet to be approved IEEE 802.11 work or drafts, >> - Support for an inter-AP communication protocol, like IEEE >> 802.11f, >> - Direct joint development of protocols with the IEEE 802.11 WG. > > Is review of CAPWAG work by IEEE 802.11 precluded? I would certainly hope > not. > > > > --- > > > To: randy@psg.com > Cc: iesg@ietf.org, iab@ietf.org > Subject: Re: trial baloon - capwap > Date: Mon, 29 Sep 2003 08:58:02 -0700 > >>Isn't the AR/AP functionality split IEEE business? > > Yes, it is. > >>(I can live with the IETF deciding the split, so long >>as IEEE is OK with us owning this part of the problem - though it >>seems a bit odd for us to take this on.) > > It's a quagmire because IEEE 802.11-1999 didn't adequately specify the > required architecture of the "MAC entities" on the wired and wireless > sides. > For example, does the AP have distinct MAC addresses on the DS and WM > ports, and if not, how is the relay function and VLAN tagging/untagging > function specified in IEEE 802.1D carried out? Since APs don't run > spanning > tree or implement learning according to IEEE 802.1D, clearly something > else > is going on. One has to dig into the SDL in IEEE 802.11-1999 to figure > out > exactly what that is -- 802.11 AP learning is handled via the > Association/Reassociation exchanges. But when security is added, things > can't quite work this way because those exchanges are unsecured, but the > 4-way handshake is secure. Therefore you can't send multicast > "Association" > announcements on the wired side until the 4-way handshake completes, and > there is an implicit assuming that learning table entries need to be > delayed, etc. > > IEEE 802.11 is having a devil of a time getting all this specified to the > point that IEEE 802.1 can understand how an AP works and the IEEE 802.11 > specs are internally consistent. If IEEE 802 has questions about how > this > works (e.g. we had to have an hour discussion with Mick Seaman just to > convince him that it was possible to do VLAN tagging/untagging and > pre-authentication together correctly) I doubt IETF can contribute much > other than confusion. > >>Note: how is this really different than layer 2 switches, that >>presumably have many of the same issue with regards to >>functionality/split/mangement/etc.? > > It's different because an AP is *not* a bridge as defined in IEEE 802.1D. > >>Note: For a long while, I've had trouble understanding whether an AP >>is an L2 or an L3 thingie. > > It doesn't fit cleanly into either category. It is not a classic L2 > bridge, > since it doesn't conform to IEEE 802.1D, and uses IEEE 802.11 management > frames for functions that would be accomplished via IEEE 802 data frames > in > 802.1D. At the same time, some 802.11 APs do include bridge functionality > such as spanning tree. Similarly, an IEEE 802.11-1999 AP is not a router, > although many implementations do include routing and/or NAT functionality. > >>The problem statement seems to say they are L3 thingies. > > Yes, it seems to assume that -- and doubt that IEEE 802 would agree. > >>And the need for the IETF to be involved is then presumably >>that IP protocols will be used in preference to L2 protocols, even >>though a lot of what those protocols carry will be L2-specific stuff. > > This is not sufficient justification because IEEE 802 WGs such as 802.11f > *can* specify IP protocols. After all, IAPP runs over IP. > >>This (IMO) complicates clients/protocols, maybe in ways we don't >>like. This sort of thing is to some extent assumed by groups like >>seamoby and/or fast handoffs in MIP and temps folk greatly when >>looking for optimizations... > > Yes, I think this could be very damaging. We'd effectively have two > competing AP architectures before IEEE 802.11 can even agree on what the > L2 > architecture is. There has already been talk about setting up a competing > group in IEEE 802.11 > >>I don't immediately see this in the problem statement. Discussion >>there seem to be restricted to making sure APs are authenticated >>before being allowed to join the network. Is this item about replacing >>WAP with something better? (I can read it this way...) > > It will inevitably interact with IEEE 802.11i security. And > authenticating > APs to the network is already something specified in IEEE 802.11f. > >>My take is that there will need to be MIB (or related) work, maybe >>secure download (which would be an IETF issue at L3). I guess I see >>potential work items here, but I'd be a bit concerned that any work >>done is done generically (e.g., secure download) and not just for this >>effort. But this will conflict with "need solution yesterday". > > Yup. I'd prefer to see work on "secure download" explicitly excluded from > the charter. > >>Wording seems to presume new protocols are needed. Case needs to be >>made, IMO. > > Yes. > >>Seems to be that one of the highest priority (and possibly most >>contentious) things to get done is get agreement on the functionality >>split. Until this is done, it will remain unclear what protocols are >>needed. > > Yes. Why don't they just focus on an architecture/framework document? > >> > Specific Working Group work items are: >> > - Clear problem statement and description of the split AP >> > architecture, >> >>Seems OK to me. > > Yes. > >>Not sure why "host data transport" is included here. Will user data be >>tunneled in IP protocols? Fine with me, but this seems like an odd >>thing to do at this level. I.e., I wouldn't have assumed this is a >>desired starting point. > > On the criticisms of the CAPWAP approach is that it isn't clear why the > tunneling needs to occur from an AP to a remote AR multiple hops away. If > it is only a single hop, why won't L2 encapsulation suffice? Is L3 being > used here solely to justify doing work in the IETF, or is there a > technical > reason for the choice? The IEEE 802.11 folks seem convinced that L2 is > the > way to go. > >>I'd remove all of this from the charter until the previous work has >>been done. > > Yes. It's the only hope of achieving focus. > >>Indeed, I wonder how this relates to the device discoery BOF that >>wasn't held last time around (and for which the propoents have been >>completely silent since the Vienna...) > > Answer: it overlaps. We already have proposals for 4 different discovery > protocols to handle this, between IETF (DDP, CARD), and IEEE (LLDP, > LINKSEC > discovery). No way shoudl this be included in the charter. > >>Again, I'd leave this all out until the split/problem statement are >>mostly done. > > Yes. > >>Seems like an odd thing to write into the charter. Seems like an item >>that people will be able to use to shut people up who raise issues >>about basic design tradeoffs. > > Yes, I think that's the intent. > >>The Working Group will also co-ordinate closely with the IEEE 802.11 WG. > > I'd like more detail on the coordination. Are we proposing that the > architecture document be reviewed by IEEE 802.11? > >>Just to be clear, this protocol seems to have been needed yesterday, >>and speed is more important than anything else according to some of >>the charter wording. Yet, I see a (probably realistic) target of >>almost 2 years from now. I hope everyone is on the same page here. > > This seems like the kind of problem that neither the IEEE nor the IETF can > handle well. It's very likely that multiple proprietary solutions will be > shipped by the time this effort gathers any steam. And the IETF/IEEE > split > will guarantee multiple competing standards in this area. > > End result: everyone can claim conformance to a "standard" with no real > interoperability. > > > --- > > > Date: Mon, 29 Sep 2003 10:19:14 -0700 > To: Randy Bush , iesg > Cc: iab > Subject: Re: trial baloon - capwap > > high level thought: > > Split AP is another sushi truck control protocol - in the Internet, but > not > of the Internet. > > The justifications for doing it in the IETF would be: > - it's important for the Internet, because so many clients are 802.11 > wireless (doesn't convince me) > - it's important to be interoperable between vendors, so a standard is > needed (seems OK, but doesn't bias IEEE/IETF choice of venue) > - IETF has more expertise in doing this (for some definiton of "this") > than > IEEE (seems doubtful) > > The last effort that tried for something in nearly the same space was > FORCES, I think. What's the relationship (if any) between what was learned > there and this effort? > > Nit - one thing is for certain: calling the thing that does weird stuff > with Access Points an Access Router is a biasing of the architecture > that's > completely uncalled-for. No way you should require the net's access router > and AP controller to be on the same box. > > -30- > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > --------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 Mobile: +49 (0) 163 275 17 43 personal home page: http://www.brubers.org/marcus ----------------------------------------- This email was sent using SquirrelMail. "Webmail for nuts!" http://squirrelmail.org/ From pcalhoun@airespace.com Mon Oct 6 14:11:45 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Mon, 6 Oct 2003 06:11:45 -0700 Subject: [Lwapp] capwap charter comments from iab and iesg Message-ID: <40301581B2962B448690A023EF16DFE1014B289D@bsn-mail-01.bstormnetworks.com> > What are the further steps? We are working with the IESG to come up with a charter that everyone = feels comfortable with. Stay tuned. PatC From soohong.park@samsung.com Thu Oct 9 03:11:16 2003 From: soohong.park@samsung.com (Soohong Daniel Park) Date: Thu, 09 Oct 2003 11:11:16 +0900 Subject: [Lwapp] Can we use a LWAPP now ? In-Reply-To: <40301581B2962B448690A023EF16DFE1014B289D@bsn-mail-01.bstormnetworks.com> Message-ID: <00b901c38e0a$9ee74680$b7cbdba8@daniel> Hello CAPWAP As I wrote subject line, I am wondering we can use a LWAPP now. In order word, can we buy a AP supported by LWAPP ? My intention is that I would like to use this protocol as fast handover method... http://www.ietf.org/internet-drafts/draft-park-dna-fastra-lwapp-00.txt Is it possible to get LWAPP software ? Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics From lily.l.yang@intel.com Fri Oct 10 17:59:47 2003 From: lily.l.yang@intel.com (Yang, Lily L) Date: Fri, 10 Oct 2003 09:59:47 -0700 Subject: [Lwapp] Meeting at Minneapolis? Message-ID: <26BDFAFFB541B047B24179002EBE6D2714FFFF@orsmsx410.jf.intel.com> Is this group going to meet at Minneapolis? I am trying to decide my = departure flight time on that Friday and I want to know if it will end = up meeting on Friday again like last time.=20 From sgoswami@umich.edu Sat Oct 18 18:45:41 2003 From: sgoswami@umich.edu (sgoswami@umich.edu) Date: Sat, 18 Oct 2003 13:45:41 -0400 Subject: [Lwapp] IPR Question Message-ID: <1066499141.3f917c4548101@carrierpigeon.mail.umich.edu> LWAPP addresses a much needed issue in WLAN management. WLAN management is being addressed by 20+ companies doing "WLAN Switch". A number companies are using the same approach as LWAPP in a broad sense. Have the authors or anyone else have done any form of investigation on how many patents (or patent applications) LWAPP can potentially overlap ? Subrata Goswami From mmani@avaya.com Tue Oct 21 05:10:28 2003 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Mon, 20 Oct 2003 22:10:28 -0600 Subject: [Lwapp] NOTE: CAPWAP Agenda and TimeSlot for Minneapolis meeting. Message-ID: All, Find appended the proposed agenda for the Minneapolis CAPWAP BoF = (again). The intent is to clearly state and justify the motivations and arrive at = an architecture for CAPWAP by way of clarifying the questions raised on = the proposed charter. Thus arrive at a clear charter consensus. Although the set time comes to an hour we have further requested = additional time for more discussions (given that Vienna discussions ran = over 2.5 hours). Good news: Outlook is good for getting a longer timeslot. Sober News: once again the BoF may meet on Friday - due to multiple = conflicts. Those who have made arrangements for earlier departure - do reconsider. Also suggested http://www.ietf.org/internet-drafts/draft-calhoun-capwap-problem-statemen= t-00.txt besides the reading material suggested below. Stay tuned for updates. 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 Chairs: Mahalingam Mani(mmani@avaya.com) =A0=A0=A0=A0=A0=A0=A0 Dorothy Gellert (dorothy.gellert@nokia.com) Agenda =A0=A0 Agenda Bashing - 5min =A0=A0 Update since Vienna Meeting - July 2003 (10 min.) =A0=A0 Architecture Draft (5 min.) =A0=A0 Discussion on Architecture Specification (20 min.) =A0=A0 Review of Proposed Charter (20 min.) =A0 Not to conflict with: Mobile IP, Seamoby, AAA, radext and EAP =A0 Description =A0 Conventional IETF wisdom has it that wireless access points for = non-provisioned wireless media are no more than simple Layer 2 bridges = that transparently forward packets between the wired and wireless links. = While this is indeed their primary function, in reality, higher layer = functions have been gradually migrating into such access points. An = example is network access server functionality. Managing this = functionality, its interaction between access points, and between access = points and access routers has become increasingly difficult. Because = some of the functions involve exchange of Layer 2 information, IETF has = traditionally maintained that it is "Not Our Problem". On the other = hand, because many of the functions either use or provide services with = a Layer 3 component, the relevant Layer 2 standardization bodies (such = as IEEE for 802.11) have been reluctant to step forward and own the = problem either. =A0 Recently, next generation 802.11 network infrastructure (also referred = to as WLAN switches) have seen significant interest in the market. = Several companies, both startups and incumbents in the WLAN space, have = announced, or are shipping products. Most of these products have a = similar architecture which simplifies control and management of access = points, but does not remove the problem of managing the interaction with = the IP network. Given the interest in the market for such solutions, = there is no doubt that standardizing the interface between the AP and = the controller (or WLAN switch) would benefit the Internet community. = Would defining a new Layer 2 independent protocol to manage wireless = access points both dynamically and statically help? Can existing IETF = solutions contribute, and, if so, is there any Layer 2 independent work = that IETF might do to adapt those solutions to the problem space? =A0 Wireless access points also have additional security needs that are ill = met by regarding them as simple Layer 2 bridges. Because such access = points are easy to deploy by design, security provisioning is difficult = to achieve. How does the network provider's router verify that a = particular access point is authorized to be on the network? Wireless = access points are also being called upon to provide increasingly more = complex security for hosts, approaching that provided by the highly = provisioned wireless media in cellular networks. Can the implementation = of these functions be simplified by centralizing the intelligence and = distributing the RF interfaces? =A0 This BoF also responds to concerns and questions raised by IESG and IAB = in validating the charter and hopes to have clear response (by way of = architecture doc.) on many other issues raised in the mailing list. =A0 The goal is to arrive at a clear consensus on problem scope and arrive = at a Charter agreement. =A0 READING LIST: =A0 CAPWAP Architecture: = http://www.ietf.org/internet-drafts/draft-mani-ietf-capwap-arch-00.txt = (submitted Oct 20) Lightweight Access Point Protocol = http://www.ietf.org/internet-drafts/draft-calhoun-seamoby-lwapp-03.txt Lightweight Access Point Protocol Security Requirements = http://www.ietf.org/internet-drafts/draft-kelly-ietf-lwapp-sec-00.txt MAILING LIST: List:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 lwapp@frascone.com Subscribe:=A0=A0=A0=A0=A0=A0=A0=A0=A0 lwapp-request@frascone.com Body:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 subscribe in Subject = line Archive:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = http://mail.frascone.com/pipermail/public/lwapp/ From mmani@avaya.com Tue Oct 21 05:16:48 2003 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Mon, 20 Oct 2003 22:16:48 -0600 Subject: [Lwapp] IPR Question Message-ID: Subrata, IETF is engaged in design & development of protocols. The proposed LWAPProtocol carries IPR declarations known to authors. I would expect that all other claims related to the protocol, if any, should and would be brought up by those aware of such. -mani > -----Original Message----- > From: sgoswami@umich.edu [mailto:sgoswami@umich.edu] > Sent: Saturday, October 18, 2003 10:46 AM > To: lwapp@frascone.com > Subject: [Lwapp] IPR Question >=20 > LWAPP addresses a much needed issue in WLAN management. WLAN management > is > being addressed by 20+ companies doing "WLAN Switch". A number companies > are > using the same approach as LWAPP in a broad sense. Have the authors or > anyone > else have done any form of investigation on how many patents (or patent > applications) LWAPP can potentially overlap ? >=20 > Subrata Goswami > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp From sgoswami@umich.edu Tue Oct 21 06:47:42 2003 From: sgoswami@umich.edu (sgoswami@umich.edu) Date: Tue, 21 Oct 2003 01:47:42 -0400 Subject: [Lwapp] IPR Question In-Reply-To: References: Message-ID: <1066715262.3f94c87ec304a@carrierpigeon.mail.umich.edu> Hi Mani, in an ideal world with no financial consequences everyone would come forward during the pre-standard process itself. How would you/IETF handle an IP claim after standardization ? Apologize for being on the dark in these procedures. Subrata Quoting "Mani, Mahalingam (Mahalingam)" : > Subrata, > > IETF is engaged in design & development of protocols. The proposed > LWAPProtocol carries IPR declarations known to authors. I would expect > that all other claims related to the protocol, if any, should and would > be brought up by those aware of such. > > -mani > > -----Original Message----- > > From: sgoswami@umich.edu [mailto:sgoswami@umich.edu] > > Sent: Saturday, October 18, 2003 10:46 AM > > To: lwapp@frascone.com > > Subject: [Lwapp] IPR Question > > > > LWAPP addresses a much needed issue in WLAN management. WLAN > management > > is > > being addressed by 20+ companies doing "WLAN Switch". A number > companies > > are > > using the same approach as LWAPP in a broad sense. Have the authors or > > anyone > > else have done any form of investigation on how many patents (or > patent > > applications) LWAPP can potentially overlap ? > > > > Subrata Goswami > > _______________________________________________ > > Lwapp mailing list > > Lwapp@frascone.com > > http://mail.frascone.com/mailman/listinfo/lwapp > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > From pcalhoun@airespace.com Tue Oct 21 13:24:01 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Tue, 21 Oct 2003 05:24:01 -0700 Subject: [Lwapp] IPR Question Message-ID: <40301581B2962B448690A023EF16DFE1014B2A9C@bsn-mail-01.bstormnetworks.com> This is a topic for the general IETF mailing list, not this one. PatC -----Original Message----- From: lwapp-admin@frascone.com on behalf of sgoswami@umich.edu Sent: Mon 10/20/2003 10:47 PM To: Mani, Mahalingam (Mahalingam) Cc: lwapp@frascone.com Subject: RE: [Lwapp] IPR Question Hi Mani, in an ideal world with no financial consequences everyone would = come forward during the pre-standard process itself. How would you/IETF = handle an IP claim after standardization ? Apologize for being on the dark in these procedures. Subrata Quoting "Mani, Mahalingam (Mahalingam)" : > Subrata, >=20 > IETF is engaged in design & development of protocols. The proposed > LWAPProtocol carries IPR declarations known to authors. I would expect > that all other claims related to the protocol, if any, should and = would > be brought up by those aware of such. >=20 > -mani > > -----Original Message----- > > From: sgoswami@umich.edu [mailto:sgoswami@umich.edu] > > Sent: Saturday, October 18, 2003 10:46 AM > > To: lwapp@frascone.com > > Subject: [Lwapp] IPR Question > >=20 > > LWAPP addresses a much needed issue in WLAN management. WLAN > management > > is > > being addressed by 20+ companies doing "WLAN Switch". A number > companies > > are > > using the same approach as LWAPP in a broad sense. Have the authors = or > > anyone > > else have done any form of investigation on how many patents (or > patent > > applications) LWAPP can potentially overlap ? > >=20 > > Subrata Goswami > > _______________________________________________ > > Lwapp mailing list > > Lwapp@frascone.com > > http://mail.frascone.com/mailman/listinfo/lwapp > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp >=20 _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From bob@airespace.com Tue Oct 21 16:27:32 2003 From: bob@airespace.com (Bob O'Hara) Date: Tue, 21 Oct 2003 08:27:32 -0700 Subject: [Lwapp] Draft of architecture spec available Message-ID: <40301581B2962B448690A023EF16DFE101882257@bsn-mail-01.bstormnetworks.com> Draft 00 of the CAPWAP architecture document has been submitted to the IETF. Until it is available from an official location, you may obtain it at the following URL: http://www.airespace.com/ietf/draft-mani-ietf-capwap-arch-00.txt. -Bob Bob O'Hara Airespace, Inc. 110 Nortech Parkway San Jose, CA 95134-2307 Phone: +1 408 635 2025 Mobile: +1 408 218 4025 Fax: +1 408 635 2020 email: bob@airespace.com =20 From randy@psg.com Tue Oct 21 18:10:39 2003 From: randy@psg.com (Randy Bush) Date: Tue, 21 Oct 2003 12:10:39 -0500 Subject: [Lwapp] IPR Question References: <1066715262.3f94c87ec304a@carrierpigeon.mail.umich.edu> Message-ID: > Hi Mani, in an ideal world with no financial consequences everyone would > come forward during the pre-standard process itself. How would you/IETF > handle an IP claim after standardization ? very nastily. trust me. the proces is pretty well documented. for the latest see draft-ietf-ipr-technology-rights-11.txt randy From kempf@docomolabs-usa.com Tue Oct 21 22:20:13 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Tue, 21 Oct 2003 14:20:13 -0700 Subject: [Lwapp] IPR Question References: <1066715262.3f94c87ec304a@carrierpigeon.mail.umich.edu> Message-ID: <018401c39819$1fd6a1b0$0a6015ac@dclkempt40> It is a requirement whenever a draft with IPR is published that a statement about the status of the IPR be posted to the IETF IPR web page (available off of http://www.ietf.org). The draft must also contain boilerplate stating that this has been done, but the claims should not be in the draft. Failure to do so will result in the draft not being considered for standards track. WG chairs have wide latitude in how to treat drafts with IPR in them, but, as a practical matter, most WGs try to avoid IPR-encumbered designs unless the IPR statement grants a free license (typically phrased as "the IPR will not be enforced if the proposal becomes standard"), though this is by no means required. I believe a statement on IPR associated with LWAPP was posted to the IETF Web page sometime back (Pat can correct me if I am wrong). jak ----- Original Message ----- From: To: "Mani, Mahalingam (Mahalingam)" Cc: Sent: Monday, October 20, 2003 10:47 PM Subject: RE: [Lwapp] IPR Question > Hi Mani, in an ideal world with no financial consequences everyone would come > forward during the pre-standard process itself. How would you/IETF handle an IP > claim after standardization ? Apologize for being on the dark in these > procedures. > > Subrata > > > > Quoting "Mani, Mahalingam (Mahalingam)" : > > > Subrata, > > > > IETF is engaged in design & development of protocols. The proposed > > LWAPProtocol carries IPR declarations known to authors. I would expect > > that all other claims related to the protocol, if any, should and would > > be brought up by those aware of such. > > > > -mani > > > -----Original Message----- > > > From: sgoswami@umich.edu [mailto:sgoswami@umich.edu] > > > Sent: Saturday, October 18, 2003 10:46 AM > > > To: lwapp@frascone.com > > > Subject: [Lwapp] IPR Question > > > > > > LWAPP addresses a much needed issue in WLAN management. WLAN > > management > > > is > > > being addressed by 20+ companies doing "WLAN Switch". A number > > companies > > > are > > > using the same approach as LWAPP in a broad sense. Have the authors or > > > anyone > > > else have done any form of investigation on how many patents (or > > patent > > > applications) LWAPP can potentially overlap ? > > > > > > Subrata Goswami > > > _______________________________________________ > > > Lwapp mailing list > > > Lwapp@frascone.com > > > http://mail.frascone.com/mailman/listinfo/lwapp > > _______________________________________________ > > Lwapp mailing list > > Lwapp@frascone.com > > http://mail.frascone.com/mailman/listinfo/lwapp > > > > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > From sgoswami@umich.edu Tue Oct 21 22:30:38 2003 From: sgoswami@umich.edu (sgoswami@umich.edu) Date: Tue, 21 Oct 2003 17:30:38 -0400 Subject: [Lwapp] IPR Question Message-ID: <1066771838.3f95a57e107c6@carrierpigeon.mail.umich.edu> I think I need to clarify the issue. The issue is not with the IP claims of people/vendor's participating in the LWAPP standardization process, but with people/vendor who are not (voluntarily or involuntarily) that may have IP with which LWAPP overlaps. Currently it is a hypothetical situation. Subrata Quoting James Kempf : > It is a requirement whenever a draft with IPR is published that a statement > about the status of the IPR be posted to the IETF IPR web page (available > off of http://www.ietf.org). The draft must also contain boilerplate stating > that this has been done, but the claims should not be in the draft. Failure > to do so will result in the draft not being considered for standards track. > WG chairs have wide latitude in how to treat drafts with IPR in them, but, > as a practical matter, most WGs try to avoid IPR-encumbered designs unless > the IPR statement grants a free license (typically phrased as "the IPR will > not be enforced if the proposal becomes standard"), though this is by no > means required. > > I believe a statement on IPR associated with LWAPP was posted to the IETF > Web page sometime back (Pat can correct me if I am wrong). > > jak > > ----- Original Message ----- > From: > To: "Mani, Mahalingam (Mahalingam)" > Cc: > Sent: Monday, October 20, 2003 10:47 PM > Subject: RE: [Lwapp] IPR Question > > > > Hi Mani, in an ideal world with no financial consequences everyone would > come > > forward during the pre-standard process itself. How would you/IETF handle > an IP > > claim after standardization ? Apologize for being on the dark in these > > procedures. > > > > Subrata > > > > > > > > Quoting "Mani, Mahalingam (Mahalingam)" : > > > > > Subrata, > > > > > > IETF is engaged in design & development of protocols. The proposed > > > LWAPProtocol carries IPR declarations known to authors. I would expect > > > that all other claims related to the protocol, if any, should and would > > > be brought up by those aware of such. > > > > > > -mani > > > > -----Original Message----- > > > > From: sgoswami@umich.edu [mailto:sgoswami@umich.edu] > > > > Sent: Saturday, October 18, 2003 10:46 AM > > > > To: lwapp@frascone.com > > > > Subject: [Lwapp] IPR Question > > > > > > > > LWAPP addresses a much needed issue in WLAN management. WLAN > > > management > > > > is > > > > being addressed by 20+ companies doing "WLAN Switch". A number > > > companies > > > > are > > > > using the same approach as LWAPP in a broad sense. Have the authors or > > > > anyone > > > > else have done any form of investigation on how many patents (or > > > patent > > > > applications) LWAPP can potentially overlap ? > > > > > > > > Subrata Goswami > > > > _______________________________________________ > > > > Lwapp mailing list > > > > Lwapp@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/lwapp > > > _______________________________________________ > > > Lwapp mailing list > > > Lwapp@frascone.com > > > http://mail.frascone.com/mailman/listinfo/lwapp > > > > > > > > > _______________________________________________ > > Lwapp mailing list > > Lwapp@frascone.com > > http://mail.frascone.com/mailman/listinfo/lwapp > > > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > From sgoswami@umich.edu Tue Oct 21 22:31:54 2003 From: sgoswami@umich.edu (sgoswami@umich.edu) Date: Tue, 21 Oct 2003 17:31:54 -0400 Subject: Fwd: Re: [Lwapp] IPR Question Message-ID: <1066771914.3f95a5ca62794@carrierpigeon.mail.umich.edu> I think I need to clarify the issue. The issue is not with the IP claims of people/vendor's participating in the LWAPP standardization process, but with people/vendor who are not (voluntarily or involuntarily) that may have IP with which LWAPP overlaps. Currently it is a hypothetical situation. Subrata Quoting James Kempf : > It is a requirement whenever a draft with IPR is published that a statement > about the status of the IPR be posted to the IETF IPR web page (available > off of http://www.ietf.org). The draft must also contain boilerplate stating > that this has been done, but the claims should not be in the draft. Failure > to do so will result in the draft not being considered for standards track. > WG chairs have wide latitude in how to treat drafts with IPR in them, but, > as a practical matter, most WGs try to avoid IPR-encumbered designs unless > the IPR statement grants a free license (typically phrased as "the IPR will > not be enforced if the proposal becomes standard"), though this is by no > means required. > > I believe a statement on IPR associated with LWAPP was posted to the IETF > Web page sometime back (Pat can correct me if I am wrong). > > jak > > ----- Original Message ----- > From: > To: "Mani, Mahalingam (Mahalingam)" > Cc: > Sent: Monday, October 20, 2003 10:47 PM > Subject: RE: [Lwapp] IPR Question > > > > Hi Mani, in an ideal world with no financial consequences everyone would > come > > forward during the pre-standard process itself. How would you/IETF handle > an IP > > claim after standardization ? Apologize for being on the dark in these > > procedures. > > > > Subrata > > > > > > > > Quoting "Mani, Mahalingam (Mahalingam)" : > > > > > Subrata, > > > > > > IETF is engaged in design & development of protocols. The proposed > > > LWAPProtocol carries IPR declarations known to authors. I would expect > > > that all other claims related to the protocol, if any, should and would > > > be brought up by those aware of such. > > > > > > -mani > > > > -----Original Message----- > > > > From: sgoswami@umich.edu [mailto:sgoswami@umich.edu] > > > > Sent: Saturday, October 18, 2003 10:46 AM > > > > To: lwapp@frascone.com > > > > Subject: [Lwapp] IPR Question > > > > > > > > LWAPP addresses a much needed issue in WLAN management. WLAN > > > management > > > > is > > > > being addressed by 20+ companies doing "WLAN Switch". A number > > > companies > > > > are > > > > using the same approach as LWAPP in a broad sense. Have the authors or > > > > anyone > > > > else have done any form of investigation on how many patents (or > > > patent > > > > applications) LWAPP can potentially overlap ? > > > > > > > > Subrata Goswami > > > > _______________________________________________ > > > > Lwapp mailing list > > > > Lwapp@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/lwapp > > > _______________________________________________ > > > Lwapp mailing list > > > Lwapp@frascone.com > > > http://mail.frascone.com/mailman/listinfo/lwapp > > > > > > > > > _______________________________________________ > > Lwapp mailing list > > Lwapp@frascone.com > > http://mail.frascone.com/mailman/listinfo/lwapp > > > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > ----- End forwarded message ----- From kempf@docomolabs-usa.com Tue Oct 21 22:41:01 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Tue, 21 Oct 2003 14:41:01 -0700 Subject: [Lwapp] IPR Question References: <1066771838.3f95a57e107c6@carrierpigeon.mail.umich.edu> Message-ID: <02c701c3981c$09020760$0a6015ac@dclkempt40> > I think I need to clarify the issue. The issue is not with the IP claims of > people/vendor's participating in the LWAPP standardization process, but with > people/vendor who are not (voluntarily or involuntarily) that may have IP with > which LWAPP overlaps. Currently it is a hypothetical situation. > As a hypothetical situation, I can't give you an answer. I'd suggest you check the IETF IPR document Randy referred you to if you want any further information. jak > Subrata > > Quoting James Kempf : > > > It is a requirement whenever a draft with IPR is published that a statement > > about the status of the IPR be posted to the IETF IPR web page (available > > off of http://www.ietf.org). The draft must also contain boilerplate stating > > that this has been done, but the claims should not be in the draft. Failure > > to do so will result in the draft not being considered for standards track. > > WG chairs have wide latitude in how to treat drafts with IPR in them, but, > > as a practical matter, most WGs try to avoid IPR-encumbered designs unless > > the IPR statement grants a free license (typically phrased as "the IPR will > > not be enforced if the proposal becomes standard"), though this is by no > > means required. > > > > I believe a statement on IPR associated with LWAPP was posted to the IETF > > Web page sometime back (Pat can correct me if I am wrong). > > > > jak > > > > ----- Original Message ----- > > From: > > To: "Mani, Mahalingam (Mahalingam)" > > Cc: > > Sent: Monday, October 20, 2003 10:47 PM > > Subject: RE: [Lwapp] IPR Question > > > > > > > Hi Mani, in an ideal world with no financial consequences everyone would > > come > > > forward during the pre-standard process itself. How would you/IETF handle > > an IP > > > claim after standardization ? Apologize for being on the dark in these > > > procedures. > > > > > > Subrata > > > > > > > > > > > > Quoting "Mani, Mahalingam (Mahalingam)" : > > > > > > > Subrata, > > > > > > > > IETF is engaged in design & development of protocols. The proposed > > > > LWAPProtocol carries IPR declarations known to authors. I would expect > > > > that all other claims related to the protocol, if any, should and would > > > > be brought up by those aware of such. > > > > > > > > -mani > > > > > -----Original Message----- > > > > > From: sgoswami@umich.edu [mailto:sgoswami@umich.edu] > > > > > Sent: Saturday, October 18, 2003 10:46 AM > > > > > To: lwapp@frascone.com > > > > > Subject: [Lwapp] IPR Question > > > > > > > > > > LWAPP addresses a much needed issue in WLAN management. WLAN > > > > management > > > > > is > > > > > being addressed by 20+ companies doing "WLAN Switch". A number > > > > companies > > > > > are > > > > > using the same approach as LWAPP in a broad sense. Have the authors or > > > > > anyone > > > > > else have done any form of investigation on how many patents (or > > > > patent > > > > > applications) LWAPP can potentially overlap ? > > > > > > > > > > Subrata Goswami > > > > > _______________________________________________ > > > > > Lwapp mailing list > > > > > Lwapp@frascone.com > > > > > http://mail.frascone.com/mailman/listinfo/lwapp > > > > _______________________________________________ > > > > Lwapp mailing list > > > > Lwapp@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/lwapp > > > > > > > > > > > > > _______________________________________________ > > > Lwapp mailing list > > > Lwapp@frascone.com > > > http://mail.frascone.com/mailman/listinfo/lwapp > > > > > > > _______________________________________________ > > Lwapp mailing list > > Lwapp@frascone.com > > http://mail.frascone.com/mailman/listinfo/lwapp > > > > > From john.loughney@nokia.com Wed Oct 22 00:43:58 2003 From: john.loughney@nokia.com (john.loughney@nokia.com) Date: Wed, 22 Oct 2003 02:43:58 +0300 Subject: [Lwapp] IPR Question Message-ID: Hi Subrata, > I think I need to clarify the issue. The issue is not with the IP = claims of > people/vendor's participating in the LWAPP standardization process, = but with > people/vendor who are not (voluntarily or involuntarily) that may have = IP with > which LWAPP overlaps. Currently it is a hypothetical situation. I do not believe that the IETF or even most SDOs have any ability to=20 handle this kind of situation. Practically, there is nothing that I can see that can be done to avoid this kind of situation. br, John From mmani@avaya.com Wed Oct 22 04:39:00 2003 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Tue, 21 Oct 2003 21:39:00 -0600 Subject: [Lwapp] IPR Question Message-ID: Subrata, As suggested by my colleague - I would refer you to RFC2026 for details at this time. Further, its applicability may evolve as IPR WG work progresses. -mani > -----Original Message----- > From: sgoswami@umich.edu [mailto:sgoswami@umich.edu] > Sent: Monday, October 20, 2003 10:48 PM > To: Mani, Mahalingam (Mahalingam) > Cc: lwapp@frascone.com > Subject: RE: [Lwapp] IPR Question >=20 > Hi Mani, in an ideal world with no financial consequences everyone would > come > forward during the pre-standard process itself. How would you/IETF handle > an IP > claim after standardization ? Apologize for being on the dark in these > procedures. >=20 > Subrata >=20 >=20 >=20 > Quoting "Mani, Mahalingam (Mahalingam)" : >=20 > > Subrata, > > > > IETF is engaged in design & development of protocols. The proposed > > LWAPProtocol carries IPR declarations known to authors. I would expect > > that all other claims related to the protocol, if any, should and would > > be brought up by those aware of such. > > > > -mani > > > -----Original Message----- > > > From: sgoswami@umich.edu [mailto:sgoswami@umich.edu] > > > Sent: Saturday, October 18, 2003 10:46 AM > > > To: lwapp@frascone.com > > > Subject: [Lwapp] IPR Question > > > > > > LWAPP addresses a much needed issue in WLAN management. WLAN > > management > > > is > > > being addressed by 20+ companies doing "WLAN Switch". A number > > companies > > > are > > > using the same approach as LWAPP in a broad sense. Have the authors or > > > anyone > > > else have done any form of investigation on how many patents (or > > patent > > > applications) LWAPP can potentially overlap ? > > > > > > Subrata Goswami > > > _______________________________________________ > > > Lwapp mailing list > > > Lwapp@frascone.com > > > http://mail.frascone.com/mailman/listinfo/lwapp > > _______________________________________________ > > Lwapp mailing list > > Lwapp@frascone.com > > http://mail.frascone.com/mailman/listinfo/lwapp > > >=20 From mmani@avaya.com Wed Oct 22 20:28:09 2003 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Wed, 22 Oct 2003 13:28:09 -0600 Subject: [Lwapp] UPDATE: CAPWAP Agenda and TimeSlot for Minneapolis meeting. Message-ID: Agenda for more Slot-Time has been approved. The session will be on Friday 11/14 - to accommodate IEEE conflicts. -mani [...] From Internet-Drafts@ietf.org Wed Oct 22 23:33:45 2003 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Wed, 22 Oct 2003 18:33:45 -0400 Subject: [Lwapp] I-D ACTION:draft-mani-capwap-arch-00.txt Message-ID: <200310222233.SAA02229@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Architecture for Control and Provisioning of Wireless Access Points(CAPWAP) Author(s) : M. Mani, et. al. Filename : draft-mani-capwap-arch-00.txt Pages : 34 Date : 2003-10-22 While conventional wisdom has it that Wireless Access Points are strictly Layer 2 bridges, such devices today perform some higher layer functions of routers or switches in wired Infrastructure in addition to bridging the wired and wireless networks. For example, in 802.11 networks, Access Points can function as Network Access Servers. For this reason, Access Points have IP addresses and can function as IP devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mani-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-mani-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-mani-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: <2003-10-22182622.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mani-capwap-arch-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mani-capwap-arch-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-22182622.I-D@ietf.org> --OtherAccess-- --NextPart-- From mmani@avaya.com Fri Oct 24 16:44:26 2003 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Fri, 24 Oct 2003 09:44:26 -0600 Subject: [Lwapp] CAPWAP BoF Update. Message-ID: In The draft agenda posted http://www.ietf.org/meetings/agenda_58.html The CAPWAP BoF has a 9-11:30am slot. http://www.ietf.org/ietf/03nov/capwap.txt Read the appendage as the modified agenda (which should be updated on = the above webpage soon). 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=3D =A0 Agenda =A0=A0 Agenda Bashing - 5 min., =A0=A0 Update since Vienna Meeting - July 2003 (10 min.) =A0=A0 Architecture Draft (10 min.) =A0=A0 Review of Problem Statement =A0=A0 Discussion on Architecture Specification =A0=A0 Review of Proposed Charter =A0 Not to conflict with: Mobile IP, Seamoby, AAA, radext, SEND and EAP =A0 Description =A0 Conventional IETF wisdom has it that wireless access points for = non-provisioned wireless media are no more than simple Layer 2 bridges = that transparently forward packets between the wired and wireless links. = While this is indeed their primary function, in reality, higher layer = functions have been gradually migrating into such access points. An = example is network access server functionality. Managing this = functionality, its interaction between access points, and between access = points and access routers has become increasingly difficult. Because = some of the functions involve exchange of Layer 2 information, IETF has = traditionally maintained that it is "Not Our Problem". On the other = hand, because many of the functions either use or provide services with = a Layer 3 component, the relevant Layer 2 standardization bodies (such = as IEEE for 802.11) have been reluctant to step forward and own the = problem either. =A0 Recently, next generation 802.11 network infrastructure (also referred = to as WLAN switches) have seen significant interest in the market. = Several companies, both startups and incumbents in the WLAN space, have = announced, or are shipping products. Most of these products have a = similar architecture which simplifies control and management of access = points, but does not remove the problem of managing the interaction with = the IP network. Given the interest in the market for such solutions, = there is no doubt that standardizing the interface between the AP and = the controller (or WLAN switch) would benefit the Internet community. = Would defining a new Layer 2 independent protocol to manage wireless = access points both dynamically and statically help? Can existing IETF = solutions contribute, and, if so, is there any Layer 2 independent work = that IETF might do to adapt those solutions to the problem space? =A0 Wireless access points also have additional security needs that are ill = met by regarding them as simple Layer 2 bridges. Because such access = points are easy to deploy by design, security provisioning is difficult = to achieve. How does the network provider's router verify that a = particular access point is authorized to be on the network? Wireless = access points are also being called upon to provide increasingly more = complex security for hosts, approaching that provided by the highly = provisioned wireless media in cellular networks. Can the implementation = of these functions be simplified by centralizing the intelligence and = distributing the RF interfaces? =A0 This BoF also responds to concerns and questions raised by IESG and IAB = in validating the charter and hopes to have clear response (by way of = architecture doc.) on many other issues raised in the mailing list. =A0 The goal is to arrive at a clear consensus on problem scope and arrive = at a Charter agreement. =A0 READING LIST: CAPWAP Problem Statement: = http://www.ietf.org/internet-drafts/draft-calhoun-capwap-problem-statemen= t-00.txt =A0 CAPWAP Architecture: = http://www.ietf.org/internet-drafts/draft-mani-ietf-capwap-arch-00.txt =A0 Lightweight Access Point Protocol = http://www.ietf.org/internet-drafts/draft-calhoun-seamoby-lwapp-03.txt Lightweight Access Point Protocol Security Requirements = http://www.ietf.org/internet-drafts/draft-kelly-ietf-lwapp-sec-00.txt =A0 MAILING LIST: List:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 lwapp@frascone.com Subscribe:=A0=A0=A0=A0=A0=A0=A0=A0=A0 lwapp-request@frascone.com Body:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 subscribe in Subject = line Archive:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = http://mail.frascone.com/pipermail/public/lwapp/