From Marcus Brunner Tue Sep 9 17:16:24 2003 From: Marcus Brunner (Marcus Brunner) Date: Tue, 09 Sep 2003 18:16:24 +0200 Subject: [Lwapp] Proposed WG Charter In-Reply-To: <035501c36e62$c1622170$956015ac@dclkempt40> References: <035501c36e62$c1622170$956015ac@dclkempt40> Message-ID: <31987936.1063131384@[10.1.1.130]> Looks good. Except It seams there is an inconsistency or an easily misunderstood topic with the code download? After reading it twice I got the point and it is fine for my. Marcus > . 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), [...] > Specific nongoals of this work are: [...] > - Interoperable APIs for downloaded AP code images, -------------------------------------- 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 From esadot@avaya.com Wed Sep 10 12:36:08 2003 From: esadot@avaya.com (Sadot, Emek (Emek)) Date: Wed, 10 Sep 2003 14:36:08 +0300 Subject: [Lwapp] Proposed WG Charter Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C3778F.BA47F4D7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, The proposed charter looks as a mixture of AP/AR protocol definition and = AP/AR architecture. In my opinion the working group charter should break = up the protocol versus architecture definition. - AP to AR protocol charter: search for a protocol that will not limit = any AP/AR architecture flavor, starting of very light AP (e.g. only = antenna) all the way up to AP with capabilities bordering = legacy/traditional AP. - AP to AR architecture/capability charter: focus on defining 2 (3 top) = AP/AR architectures. Suggest using capability discovery to map the = supported AP capabilities. Security consideration work - draft = draft-kelly-ietf-lwapp-sec-00 - has taken the first important step in = drawing the capability line between AP and AR. Nailing 2 to 3 AP/AR architecture/capabilities at this stage will make = AP to AR interoperability feasible. Conversely standardizing the = protocol, leaving capability loose - having many APs flavors - will ruin = the effort of connecting different vendors' AP and AR. Emek -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: 29 August, 2003 10:22 PM To: LWAPP Subject: [Lwapp] Proposed WG Charter Folks, Below is a charter for the WG that Dorothy and I would like to propose = to Randy. Please send comments if you have any. jak +++++++++++++++++++++++++++++++++++++++++++++++ Control and Provisioning of Wireless Access Points (CAPWAP) =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 Area: ----- OPS Chairs: -------=20 TBD Mailing List: -------------=20 List: lwapp@frascone.com Subscribe: lwapp-request@frascone.com Body: subscribe in Subject line Archive: http://mail.frascone.com/pipermail/public/lwapp/ Description of Working Group: ----------------------------- As the size and complexity of IEEE 802.11 wireless networks has = increased, problems in the deployment, management, and usability of these networks = have become evident. 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. 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. 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. 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 collection of vendors. Specific Working Group work items are: - Clear problem statement and description of the split AP = architecture, - 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, . 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). The intent of the CAPWAP Working Group is to complete the protocol specification as quickly as possible and to serve as a forum for facilitating the testing of 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 nongoals 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. 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. _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp ------_=_NextPart_001_01C3778F.BA47F4D7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Lwapp] Proposed WG Charter

All,

The proposed charter looks as = a mixture of AP/AR protocol definition and AP/AR architecture. In my = opinion the working group charter should break up the protocol versus = architecture definition.

- AP to AR protocol charter: = search for a protocol that will not limit any AP/AR architecture flavor, = starting of very light AP (e.g. only antenna) all the way up to AP with = capabilities bordering legacy/traditional AP.

- AP to AR = architecture/capability charter: focus on defining 2 (3 top) AP/AR = architectures. Suggest using capability discovery to map the supported = AP capabilities. Security consideration work - draft = draft-kelly-ietf-lwapp-sec-00 - has taken the first important step in = drawing the capability line between AP and AR.

Nailing 2 to 3 AP/AR = architecture/capabilities at this stage will make AP to AR = interoperability feasible. Conversely standardizing the protocol, = leaving capability loose - having many APs flavors - will ruin the = effort of connecting different vendors’ AP and = AR.

Emek

-----Original Message-----

From: James Kempf [mailto:kempf@docomolabs-usa.com<= /A>]

Sent: 29 August, 2003 10:22 PM

To: LWAPP

Subject: [Lwapp] Proposed WG Charter


Folks,

Below is a charter for the WG that Dorothy and I would like to = propose to

Randy. Please send comments if you have any.

           = jak

+++++++++++++++++++++++++++++++++++++++++++++++

Control and Provisioning of Wireless Access Points = (CAPWAP)

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

Area:

-----

OPS

Chairs:

-------

TBD

Mailing List:

-------------

List:          &= nbsp;    lwapp@frascone.com

Subscribe:     = lwapp-request@frascone.com

Body:          &= nbsp; subscribe in Subject line

Archive:        http://mail.fra= scone.com/pipermail/public/lwapp/

Description of Working Group:

-----------------------------

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

problems in the deployment, management, and usability of these = networks have

become evident. 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. 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.

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. 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 = collection of

vendors.

Specific Working Group work items are:

  - Clear problem statement and description of the split AP = architecture,

  - 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,

    . 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).

The intent of the CAPWAP Working Group is to complete the = protocol

specification as quickly as possible and to serve as a forum = for

facilitating the testing of 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 nongoals 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.

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.




_______________________________________________

Lwapp mailing list

Lwapp@frascone.com

http://mail.fras= cone.com/mailman/listinfo/lwapp

------_=_NextPart_001_01C3778F.BA47F4D7-- From Marcus Brunner Wed Sep 10 12:51:37 2003 From: Marcus Brunner (Marcus Brunner) Date: Wed, 10 Sep 2003 13:51:37 +0200 Subject: [Lwapp] Proposed WG Charter In-Reply-To: References: Message-ID: <14154683.1063201897@[10.1.1.130]> --On Mittwoch, 10. September 2003 14:36 +0300 "Sadot, Emek (Emek)" wrote: > All, > > The proposed charter looks as a mixture of AP/AR protocol definition and > AP/AR architecture. In my opinion the working group charter should break > up the protocol versus architecture definition. > > - AP to AR protocol charter: search for a protocol that will not limit > any AP/AR architecture flavor, starting of very light AP (e.g. only > antenna) all the way up to AP with capabilities bordering > legacy/traditional AP. my take on this is lets start with a light one first, and allow for vendor-specifics. More capabilities can be supported later. > > - AP to AR architecture/capability charter: focus on defining 2 (3 top) > AP/AR architectures. Suggest using capability discovery to map the > supported AP capabilities. Security consideration work - draft > draft-kelly-ietf-lwapp-sec-00 - has taken the first important step in > drawing the capability line between AP and AR. > > Nailing 2 to 3 AP/AR architecture/capabilities at this stage will make AP > to AR interoperability feasible. Conversely standardizing the protocol, > leaving capability loose - having many APs flavors - will ruin the effort > of connecting different vendors' AP and AR. My assumption is that AP-AR from the same vendor always will run some vendor-specifics between them anyway, but having the basic functionality standardized they at least somehow run together. Marcus > Emek > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 29 August, 2003 10:22 PM > To: LWAPP > Subject: [Lwapp] Proposed WG Charter > > > Folks, > > Below is a charter for the WG that Dorothy and I would like to propose to > Randy. Please send comments if you have any. > > jak > > +++++++++++++++++++++++++++++++++++++++++++++++ > Control and Provisioning of Wireless Access Points (CAPWAP) > =============================================== > > Area: > ----- > OPS > > Chairs: > ------- > TBD > > Mailing List: > ------------- > List: lwapp@frascone.com > Subscribe: lwapp-request@frascone.com > Body: subscribe in Subject line > Archive: http://mail.frascone.com/pipermail/public/lwapp/ > > Description of Working Group: > ----------------------------- > As the size and complexity of IEEE 802.11 wireless networks has increased, > problems in the deployment, management, and usability of these networks > have become evident. 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. 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. > > 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. 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 collection of vendors. > > Specific Working Group work items are: > > - Clear problem statement and description of the split AP architecture, > - 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, > . 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). > > The intent of the CAPWAP Working Group is to complete the protocol > specification as quickly as possible and to serve as a forum for > facilitating the testing of 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 nongoals 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. > > 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. > > > > > _______________________________________________ > 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 From pcalhoun@airespace.com Wed Sep 10 14:01:40 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Wed, 10 Sep 2003 06:01:40 -0700 Subject: [Lwapp] Proposed WG Charter Message-ID: <40301581B2962B448690A023EF16DFE1014B25CD@bsn-mail-01.bstormnetworks.com> PiBUaGUgcHJvcG9zZWQgY2hhcnRlciBsb29rcyBhcyBhIG1peHR1cmUgb2YgQVAvQVIgcHJvdG9j b2wgZGVmaW5pdGlvbiBhbmQNCj4gQVAvQVIgYXJjaGl0ZWN0dXJlLiBJbiBteSBvcGluaW9uIHRo ZSB3b3JraW5nIGdyb3VwIGNoYXJ0ZXIgc2hvdWxkIGJyZWFrDQo+IHVwIHRoZSBwcm90b2NvbCB2 ZXJzdXMgYXJjaGl0ZWN0dXJlIGRlZmluaXRpb24uDQo+DQo+IC0gQVAgdG8gQVIgcHJvdG9jb2wg Y2hhcnRlcjogc2VhcmNoIGZvciBhIHByb3RvY29sIHRoYXQgd2lsbCBub3QgbGltaXQNCj4gYW55 IEFQL0FSIGFyY2hpdGVjdHVyZSBmbGF2b3IsIHN0YXJ0aW5nIG9mIHZlcnkgbGlnaHQgQVAgKGUu Zy4gb25seQ0KPiBhbnRlbm5hKSBhbGwgdGhlIHdheSB1cCB0byBBUCB3aXRoIGNhcGFiaWxpdGll cyBib3JkZXJpbmcNCj4gbGVnYWN5L3RyYWRpdGlvbmFsIEFQLg0KDQpteSB0YWtlIG9uIHRoaXMg aXMgbGV0cyBzdGFydCB3aXRoIGEgbGlnaHQgb25lIGZpcnN0LCBhbmQgYWxsb3cgZm9yDQp2ZW5k b3Itc3BlY2lmaWNzLiBNb3JlIGNhcGFiaWxpdGllcyBjYW4gYmUgc3VwcG9ydGVkIGxhdGVyLg0K DQo8UFJDPiBJIGFncmVlIHdpdGggTWFyY3VzLiBEZWZpbmluZyBhIG51bWJlciBvZiBhcmNoaXRl Y3R1cmUsIHByb2R1Y3QgY29tYmluYXRpb25zIGlzDQpndWFyYW50ZWUgdG8ga2VlcCB1cyBnb2lu ZyBmb3IgYSBmZXcgeWVhcnMuIFdlIG5lZWQgdG8gbmFpbCBkb3duIG9uZSBwYXJ0aWN1bGFyIGFy Y2hpdGVjdHVyZQ0KYW5kIHJ1biB3aXRoIGl0Lg0KDQo+DQo+IC0gQVAgdG8gQVIgYXJjaGl0ZWN0 dXJlL2NhcGFiaWxpdHkgY2hhcnRlcjogZm9jdXMgb24gZGVmaW5pbmcgMiAoMyB0b3ApDQo+IEFQ L0FSIGFyY2hpdGVjdHVyZXMuIFN1Z2dlc3QgdXNpbmcgY2FwYWJpbGl0eSBkaXNjb3ZlcnkgdG8g bWFwIHRoZQ0KPiBzdXBwb3J0ZWQgQVAgY2FwYWJpbGl0aWVzLiBTZWN1cml0eSBjb25zaWRlcmF0 aW9uIHdvcmsgLSBkcmFmdA0KPiBkcmFmdC1rZWxseS1pZXRmLWx3YXBwLXNlYy0wMCAtIGhhcyB0 YWtlbiB0aGUgZmlyc3QgaW1wb3J0YW50IHN0ZXAgaW4NCj4gZHJhd2luZyB0aGUgY2FwYWJpbGl0 eSBsaW5lIGJldHdlZW4gQVAgYW5kIEFSLg0KDQo8UFJDPiBBZ2Fpbiwgd2UgbmVlZCB0byBlbnN1 cmUgaW50ZXJvcGVyYWJpbGl0eSwgYW5kIGRlZmluaW5nIGEgbXVsdGl0dWRlIG9mDQphcmNoaXRl Y3R1cmVzIGRvZXMgbm90IHNhdGlzZnkgdGhpcyByZXF1aXJlbWVudC4NCiANCj4NCj4gTmFpbGlu ZyAyIHRvIDMgQVAvQVIgYXJjaGl0ZWN0dXJlL2NhcGFiaWxpdGllcyBhdCB0aGlzIHN0YWdlIHdp bGwgbWFrZSBBUA0KPiB0byBBUiBpbnRlcm9wZXJhYmlsaXR5IGZlYXNpYmxlLiBDb252ZXJzZWx5 IHN0YW5kYXJkaXppbmcgdGhlIHByb3RvY29sLA0KPiBsZWF2aW5nIGNhcGFiaWxpdHkgbG9vc2Ug LSBoYXZpbmcgbWFueSBBUHMgZmxhdm9ycyAtIHdpbGwgcnVpbiB0aGUgZWZmb3J0DQo+IG9mIGNv bm5lY3RpbmcgZGlmZmVyZW50IHZlbmRvcnMnIEFQIGFuZCBBUi4NCg0KTXkgYXNzdW1wdGlvbiBp cyB0aGF0IEFQLUFSIGZyb20gdGhlIHNhbWUgdmVuZG9yIGFsd2F5cyB3aWxsIHJ1biBzb21lDQp2 ZW5kb3Itc3BlY2lmaWNzIGJldHdlZW4gdGhlbSBhbnl3YXksIGJ1dCBoYXZpbmcgdGhlIGJhc2lj IGZ1bmN0aW9uYWxpdHkNCnN0YW5kYXJkaXplZCB0aGV5IGF0IGxlYXN0IHNvbWVob3cgcnVuIHRv Z2V0aGVyLg0KDQo8UFJDPiBDb3JyZWN0LiBBIHN0YW5kYXJkcy1iYXNlZCBwcm90b2NvbCB3aWxs IGd1YXJhbnRlZSBpbnRlcm9wZXJhYmlsaXR5Lg0KV2hldGhlciBzb21lIHZlbmRvcnMgImV4dGVu ZCIgdGhlIHByb3RvY29sIG9yIG5vdCBpcyBjbGVhcmx5IG91dCBvZiBzY29wZQ0Kb2YgdGhlIFdH LCBidXQgYXMgd2l0aCBhbnkgb3RoZXIgcHJvdG9jb2wsIHdlIGtub3cgaXQgd2lsbCBoYXBwZW4u DQogDQpQYXRDDQogDQo= From lefko@trapezenetworks.com Wed Sep 10 15:31:06 2003 From: lefko@trapezenetworks.com (Martin Lefkowitz) Date: Wed, 10 Sep 2003 07:31:06 -0700 Subject: [Lwapp] Proposed WG Charter In-Reply-To: <40301581B2962B448690A023EF16DFE1014B25CD@bsn-mail-01.bstor mnetworks.com> Message-ID: <5.1.0.14.2.20030910071801.01d663f0@mail.trpz.com> At 06:01 AM 9/10/2003 -0700, Pat R. Calhoun wrote: >content-class: urn:content-classes:message >Content-Type: text/plain; > charset="utf-8" > > > The proposed charter looks as a mixture of AP/AR protocol definition and > > AP/AR architecture. In my opinion the working group charter should break > > up the protocol versus architecture definition. > > > > - AP to AR protocol charter: search for a protocol that will not limit > > any AP/AR architecture flavor, starting of very light AP (e.g. only > > antenna) all the way up to AP with capabilities bordering > > legacy/traditional AP. > >my take on this is lets start with a light one first, and allow for >vendor-specifics. More capabilities can be supported later. > > I agree with Marcus. Defining a number of architecture, product >combinations is >guarantee to keep us going for a few years. We need to nail down one >particular architecture >and run with it. There are varying degrees of "light AP." I believe a protocol could be defined that takes this into account. What needs to be done is to find the lowest common denominator for all the conceivable architectures, and work with that. The fun begins when it conflicts with necessary requirements. Hopefully there wont be too many conflicts. I vote for leaving any discussion of architectures out of the document as much as possible. > > > > - AP to AR architecture/capability charter: focus on defining 2 (3 top) > > AP/AR architectures. Suggest using capability discovery to map the > > supported AP capabilities. Security consideration work - draft > > draft-kelly-ietf-lwapp-sec-00 - has taken the first important step in > > drawing the capability line between AP and AR. > > Again, we need to ensure interoperability, and defining a multitude of >architectures does not satisfy this requirement. Defining any architecture doesn't satisfy the requirement for interoperability and inhibits vendors, hardware and system, to truly distinguish themselves. > > > > > Nailing 2 to 3 AP/AR architecture/capabilities at this stage will make AP > > to AR interoperability feasible. Conversely standardizing the protocol, > > leaving capability loose - having many APs flavors - will ruin the effort > > of connecting different vendors' AP and AR. > >My assumption is that AP-AR from the same vendor always will run some >vendor-specifics between them anyway, but having the basic functionality >standardized they at least somehow run together. > > Correct. A standards-based protocol will guarantee interoperability. >Whether some vendors "extend" the protocol or not is clearly out of scope >of the WG, but as with any other protocol, we know it will happen. What is the basic functionality that is acceptable for multivendor AP's to work in a system? Marty From kempf@docomolabs-usa.com Wed Sep 10 18:42:52 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Wed, 10 Sep 2003 10:42:52 -0700 Subject: [Lwapp] Proposed WG Charter References: <5.1.0.14.2.20030910071801.01d663f0@mail.trpz.com> Message-ID: <019901c377c2$f5c31730$956015ac@dclkempt40> > What is the basic functionality that is acceptable for multivendor AP's to > work in a system? > This is the key point. The problem statement/architecture work item is intended to clarify this. Currently, draft-calhoun-capwap-problem-statement discusses the problem statement only, additional work would be needed to clarify the functionality. jak From lefko@trapezenetworks.com Wed Sep 10 19:33:55 2003 From: lefko@trapezenetworks.com (Martin Lefkowitz) Date: Wed, 10 Sep 2003 11:33:55 -0700 Subject: [Lwapp] Proposed WG Charter In-Reply-To: <019901c377c2$f5c31730$956015ac@dclkempt40> References: <5.1.0.14.2.20030910071801.01d663f0@mail.trpz.com> Message-ID: <5.1.0.14.2.20030910112759.01e31a28@mail.trpz.com> At 10:42 AM 9/10/2003 -0700, James Kempf wrote: > > What is the basic functionality that is acceptable for multivendor AP's to > > work in a system? > > > >This is the key point. The problem statement/architecture work item is >intended to clarify this. Currently, draft-calhoun-capwap-problem-statement >discusses the problem statement only, additional work would be needed to >clarify the functionality. If it does not wind up in the specification as normative, if at all, and the collection of different architectures described, that we can think of in this day and age, can be general enough so as not to inhibit future architectures when/if they become feasible, then I agree. Otherwise it is my feeling that it would lead to less innovation, or less interoperability. Marty From pcalhoun@airespace.com Wed Sep 10 19:48:16 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Wed, 10 Sep 2003 11:48:16 -0700 Subject: [Lwapp] Proposed WG Charter Message-ID: <40301581B2962B448690A023EF16DFE1014B25DF@bsn-mail-01.bstormnetworks.com> PiBJZiBpdCBkb2VzIG5vdCB3aW5kIHVwIGluIHRoZSBzcGVjaWZpY2F0aW9uIGFzIG5vcm1hdGl2 ZSwgaWYgYXQgYWxsLCBhbmQNCj4gdGhlIGNvbGxlY3Rpb24gb2YgZGlmZmVyZW50IGFyY2hpdGVj dHVyZXMgZGVzY3JpYmVkLCAgdGhhdCB3ZSBjYW4gdGhpbmsgb2YNCj4gaW4gdGhpcyBkYXkgYW5k IGFnZSwgY2FuIGJlIGdlbmVyYWwgZW5vdWdoIHNvIGFzIG5vdCB0byBpbmhpYml0IGZ1dHVyZQ0K PiBhcmNoaXRlY3R1cmVzIHdoZW4vaWYgdGhleSBiZWNvbWUgZmVhc2libGUsIHRoZW4gSSBhZ3Jl ZS4NCj4gDQo+IE90aGVyd2lzZSBpdCBpcyBteSBmZWVsaW5nIHRoYXQgaXQgd291bGQgbGVhZCB0 byBsZXNzIGlubm92YXRpb24sIG9yIGxlc3MNCj4gaW50ZXJvcGVyYWJpbGl0eS4NCg0KQ291bGQg eW91IHBlcmhhcHMgcHJvdmlkZSBtZSB3aXRoIGNvbmNyZXRlIGV4YW1wbGVzIG9mIHdoYXQgeW91 J2QgbGlrZSB0byBzZWU/DQogDQpQYXRDDQo= From lefko@trapezenetworks.com Thu Sep 11 19:03:14 2003 From: lefko@trapezenetworks.com (Martin Lefkowitz) Date: Thu, 11 Sep 2003 11:03:14 -0700 Subject: [Lwapp] Proposed WG Charter In-Reply-To: <40301581B2962B448690A023EF16DFE1014B25DF@bsn-mail-01.bstor mnetworks.com> Message-ID: <5.1.0.14.2.20030911104323.018626c0@mail.trpz.com> The security paper was easier because you didn't get into issues about split 802.11 MLME functions over the wire, but this is coming. I believe you can't assume the MLME is on either side of the wire, and for example things like powersave, and QOS (that mudpuddle) functionality could be split almost anywhere. What I am worried about is that if you describe one or two architectures, with the next generation of chipsets, and innovations, we will be inhibited by this. Am I wrong? Concrete example...hmmmm. This is a tough one.... But, I don't agree with Marcus's proposal to start with only the light weight architecture. Marty At 11:48 AM 9/10/2003 -0700, Pat R. Calhoun wrote: > > If it does not wind up in the specification as normative, if at all, and > > the collection of different architectures described, that we can think of > > in this day and age, can be general enough so as not to inhibit future > > architectures when/if they become feasible, then I agree. > > > > Otherwise it is my feeling that it would lead to less innovation, or less > > interoperability. > >Could you perhaps provide me with concrete examples of what you'd like to see? > >PatC From esadot@avaya.com Sun Sep 14 07:38:54 2003 From: esadot@avaya.com (Sadot, Emek (Emek)) Date: Sun, 14 Sep 2003 09:38:54 +0300 Subject: [Lwapp] Proposed WG Charter Message-ID: VmVuZG9yIHNwZWNpZmljIGlzIGNsZWFybHkgbm90IHRoZSBhbnN3ZXIgZm9yIG11bHRpcGxlIGFy Y2hpdGVjdHVyZXMgLSBvYnZpb3VzbHkgaXQgd291bGQgd29yayBvbmx5IGlmIEFQLUFSIGFyZSBm cm9tIHRoZSBzYW1lIHZlbmRvci4gU3VnZ2VzdGlvbiBvbmUgcGFydGljdWxhciBhcmNoaXRlY3R1 cmUgaXMgdG9vIGluZGljYXRpdmUsIGxlYXZpbmcgbm8gc3BhY2UgZm9yIGlubm92YXRpb25zIGFu ZCBjb21wZXRpdGlvbi4gU3VnZ2VzdGluZyAiYW55IiBhcmNoaXRlY3R1cmUgZ3VhcmFudGVlIHdh c3Rpbmcgb3VyIHRpbWUuDQpNeSB0YWtlIG9uIHRoaXMgaXMgbGV0cyBpZGVudGlmeSBhIGZldyBh cmNoaXRlY3R1cmUgYXMgYSBwYXJ0IG9mIHRoZSBncm91cCBjaGFydGVyLCBwcm92aWRpbmcgYSBt ZWNoYW5pc20gZm9yIEFQIHRvIGFkdmVydGlzZSBpdCBjYXBhYmlsaXRpZXMuDQoNCkVtZWsNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFBhdCBSLiBDYWxob3VuIFttYWlsdG86 cGNhbGhvdW5AYWlyZXNwYWNlLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgMTAgU2VwdGVtYmVyLCAy MDAzIDQ6MDIgUE0NClRvOiBNYXJjdXMgQnJ1bm5lcjsgU2Fkb3QsIEVtZWsgKEVtZWspOyBsd2Fw cEBmcmFzY29uZS5jb20NClN1YmplY3Q6IFJFOiBbTHdhcHBdIFByb3Bvc2VkIFdHIENoYXJ0ZXIN Cg0KDQo+IFRoZSBwcm9wb3NlZCBjaGFydGVyIGxvb2tzIGFzIGEgbWl4dHVyZSBvZiBBUC9BUiBw cm90b2NvbCBkZWZpbml0aW9uIGFuZA0KPiBBUC9BUiBhcmNoaXRlY3R1cmUuIEluIG15IG9waW5p b24gdGhlIHdvcmtpbmcgZ3JvdXAgY2hhcnRlciBzaG91bGQgYnJlYWsNCj4gdXAgdGhlIHByb3Rv Y29sIHZlcnN1cyBhcmNoaXRlY3R1cmUgZGVmaW5pdGlvbi4NCj4NCj4gLSBBUCB0byBBUiBwcm90 b2NvbCBjaGFydGVyOiBzZWFyY2ggZm9yIGEgcHJvdG9jb2wgdGhhdCB3aWxsIG5vdCBsaW1pdA0K PiBhbnkgQVAvQVIgYXJjaGl0ZWN0dXJlIGZsYXZvciwgc3RhcnRpbmcgb2YgdmVyeSBsaWdodCBB UCAoZS5nLiBvbmx5DQo+IGFudGVubmEpIGFsbCB0aGUgd2F5IHVwIHRvIEFQIHdpdGggY2FwYWJp bGl0aWVzIGJvcmRlcmluZw0KPiBsZWdhY3kvdHJhZGl0aW9uYWwgQVAuDQoNCm15IHRha2Ugb24g dGhpcyBpcyBsZXRzIHN0YXJ0IHdpdGggYSBsaWdodCBvbmUgZmlyc3QsIGFuZCBhbGxvdyBmb3IN CnZlbmRvci1zcGVjaWZpY3MuIE1vcmUgY2FwYWJpbGl0aWVzIGNhbiBiZSBzdXBwb3J0ZWQgbGF0 ZXIuDQoNCjxQUkM+IEkgYWdyZWUgd2l0aCBNYXJjdXMuIERlZmluaW5nIGEgbnVtYmVyIG9mIGFy Y2hpdGVjdHVyZSwgcHJvZHVjdCBjb21iaW5hdGlvbnMgaXMNCmd1YXJhbnRlZSB0byBrZWVwIHVz IGdvaW5nIGZvciBhIGZldyB5ZWFycy4gV2UgbmVlZCB0byBuYWlsIGRvd24gb25lIHBhcnRpY3Vs YXIgYXJjaGl0ZWN0dXJlDQphbmQgcnVuIHdpdGggaXQuDQoNCj4NCj4gLSBBUCB0byBBUiBhcmNo aXRlY3R1cmUvY2FwYWJpbGl0eSBjaGFydGVyOiBmb2N1cyBvbiBkZWZpbmluZyAyICgzIHRvcCkN Cj4gQVAvQVIgYXJjaGl0ZWN0dXJlcy4gU3VnZ2VzdCB1c2luZyBjYXBhYmlsaXR5IGRpc2NvdmVy eSB0byBtYXAgdGhlDQo+IHN1cHBvcnRlZCBBUCBjYXBhYmlsaXRpZXMuIFNlY3VyaXR5IGNvbnNp ZGVyYXRpb24gd29yayAtIGRyYWZ0DQo+IGRyYWZ0LWtlbGx5LWlldGYtbHdhcHAtc2VjLTAwIC0g aGFzIHRha2VuIHRoZSBmaXJzdCBpbXBvcnRhbnQgc3RlcCBpbg0KPiBkcmF3aW5nIHRoZSBjYXBh YmlsaXR5IGxpbmUgYmV0d2VlbiBBUCBhbmQgQVIuDQoNCjxQUkM+IEFnYWluLCB3ZSBuZWVkIHRv IGVuc3VyZSBpbnRlcm9wZXJhYmlsaXR5LCBhbmQgZGVmaW5pbmcgYSBtdWx0aXR1ZGUgb2YNCmFy Y2hpdGVjdHVyZXMgZG9lcyBub3Qgc2F0aXNmeSB0aGlzIHJlcXVpcmVtZW50Lg0KIA0KPg0KPiBO YWlsaW5nIDIgdG8gMyBBUC9BUiBhcmNoaXRlY3R1cmUvY2FwYWJpbGl0aWVzIGF0IHRoaXMgc3Rh Z2Ugd2lsbCBtYWtlIEFQDQo+IHRvIEFSIGludGVyb3BlcmFiaWxpdHkgZmVhc2libGUuIENvbnZl cnNlbHkgc3RhbmRhcmRpemluZyB0aGUgcHJvdG9jb2wsDQo+IGxlYXZpbmcgY2FwYWJpbGl0eSBs b29zZSAtIGhhdmluZyBtYW55IEFQcyBmbGF2b3JzIC0gd2lsbCBydWluIHRoZSBlZmZvcnQNCj4g b2YgY29ubmVjdGluZyBkaWZmZXJlbnQgdmVuZG9ycycgQVAgYW5kIEFSLg0KDQpNeSBhc3N1bXB0 aW9uIGlzIHRoYXQgQVAtQVIgZnJvbSB0aGUgc2FtZSB2ZW5kb3IgYWx3YXlzIHdpbGwgcnVuIHNv bWUNCnZlbmRvci1zcGVjaWZpY3MgYmV0d2VlbiB0aGVtIGFueXdheSwgYnV0IGhhdmluZyB0aGUg YmFzaWMgZnVuY3Rpb25hbGl0eQ0Kc3RhbmRhcmRpemVkIHRoZXkgYXQgbGVhc3Qgc29tZWhvdyBy dW4gdG9nZXRoZXIuDQoNCjxQUkM+IENvcnJlY3QuIEEgc3RhbmRhcmRzLWJhc2VkIHByb3RvY29s IHdpbGwgZ3VhcmFudGVlIGludGVyb3BlcmFiaWxpdHkuDQpXaGV0aGVyIHNvbWUgdmVuZG9ycyAi ZXh0ZW5kIiB0aGUgcHJvdG9jb2wgb3Igbm90IGlzIGNsZWFybHkgb3V0IG9mIHNjb3BlDQpvZiB0 aGUgV0csIGJ1dCBhcyB3aXRoIGFueSBvdGhlciBwcm90b2NvbCwgd2Uga25vdyBpdCB3aWxsIGhh cHBlbi4NCiANClBhdEMNCiANCg== From esadot@avaya.com Sun Sep 14 07:46:52 2003 From: esadot@avaya.com (Sadot, Emek (Emek)) Date: Sun, 14 Sep 2003 09:46:52 +0300 Subject: [Lwapp] Proposed WG Charter Message-ID: A concrete example - how about security paper ARCH1 and ARCH2? My take = is that the protocol should support both. The working group should not = choose one architecture, rather it should allow both to exists. It would = be up to the AR to support both flavors. Emek -----Original Message----- From: Martin Lefkowitz [mailto:lefko@trapezenetworks.com] Sent: Thursday, 11 September, 2003 9:03 PM To: lwapp@frascone.com Subject: RE: [Lwapp] Proposed WG Charter The security paper was easier because you didn't get into issues about=20 split 802.11 MLME functions over the wire, but this is coming. I believe = you can't assume the MLME is on either side of the wire, and for example = things like powersave, and QOS (that mudpuddle) functionality could be=20 split almost anywhere. What I am worried about is that if you describe = one=20 or two architectures, with the next generation of chipsets, and=20 innovations, we will be inhibited by this. Am I wrong? Concrete example...hmmmm. This is a tough one.... But, I don't agree = with=20 Marcus's proposal to start with only the light weight architecture. Marty At 11:48 AM 9/10/2003 -0700, Pat R. Calhoun wrote: > > If it does not wind up in the specification as normative, if at all, = and > > the collection of different architectures described, that we can = think of > > in this day and age, can be general enough so as not to inhibit = future > > architectures when/if they become feasible, then I agree. > > > > Otherwise it is my feeling that it would lead to less innovation, or = less > > interoperability. > >Could you perhaps provide me with concrete examples of what you'd like = to see? > >PatC _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From Marcus Brunner Mon Sep 15 11:51:35 2003 From: Marcus Brunner (Marcus Brunner) Date: Mon, 15 Sep 2003 12:51:35 +0200 Subject: [Lwapp] Proposed WG Charter In-Reply-To: References: Message-ID: <9209232.1063630295@[10.1.1.130]> My fear is that having several architectures might add to the complexity of the protocol. I am fine supporting different architectures, if there is no compromise on keeping the thing simple. Marcus --On Sonntag, 14. September 2003 09:46 +0300 "Sadot, Emek (Emek)" wrote: > A concrete example - how about security paper ARCH1 and ARCH2? My take is > that the protocol should support both. The working group should not > choose one architecture, rather it should allow both to exists. It would > be up to the AR to support both flavors. > > Emek > > -----Original Message----- > From: Martin Lefkowitz [mailto:lefko@trapezenetworks.com] > Sent: Thursday, 11 September, 2003 9:03 PM > To: lwapp@frascone.com > Subject: RE: [Lwapp] Proposed WG Charter > > > The security paper was easier because you didn't get into issues about > split 802.11 MLME functions over the wire, but this is coming. I believe > you can't assume the MLME is on either side of the wire, and for example > things like powersave, and QOS (that mudpuddle) functionality could be > split almost anywhere. What I am worried about is that if you describe > one or two architectures, with the next generation of chipsets, and > innovations, we will be inhibited by this. > > Am I wrong? > > Concrete example...hmmmm. This is a tough one.... But, I don't agree > with Marcus's proposal to start with only the light weight architecture. > > Marty > > > At 11:48 AM 9/10/2003 -0700, Pat R. Calhoun wrote: >> > If it does not wind up in the specification as normative, if at all, >> > and the collection of different architectures described, that we can >> > think of in this day and age, can be general enough so as not to >> > inhibit future architectures when/if they become feasible, then I >> > agree. >> > >> > Otherwise it is my feeling that it would lead to less innovation, or >> > less interoperability. >> >> Could you perhaps provide me with concrete examples of what you'd like >> to see? >> >> PatC > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp -------------------------------------- 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 From anwars@avaya.com Mon Sep 15 18:24:33 2003 From: anwars@avaya.com (Siddiqui, Anwar A (Anwar)) Date: Mon, 15 Sep 2003 13:24:33 -0400 Subject: FW: [Lwapp] Proposed WG Charter Message-ID: Jak, Appologies for being late in responding to the CAPWAP Charter discussion = ... Vienna CAPWAP BOF proposed "Configuration and monitoring of wireless = link by CAPWAP manager" as part of the WG charter. But in the proposed charter below though I = see AP configuration being=20 covered, I do not see monitoring as part of the Charter below! I feel we = should do that specially=20 because there are plenty of solution existing within IETF that can be = used and an industry wide support=20 would help the operation and deployment. Any comments? Thanks Anwar -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: 29 August, 2003 10:22 PM To: LWAPP Subject: [Lwapp] Proposed WG Charter Folks, Below is a charter for the WG that Dorothy and I would like to propose = to Randy. Please send comments if you have any. jak +++++++++++++++++++++++++++++++++++++++++++++++ Control and Provisioning of Wireless Access Points (CAPWAP) =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 Area: ----- OPS Chairs: -------=20 TBD Mailing List: -------------=20 List: lwapp@frascone.com Subscribe: lwapp-request@frascone.com Body: subscribe in Subject line Archive: http://mail.frascone.com/pipermail/public/lwapp/ Description of Working Group: ----------------------------- As the size and complexity of IEEE 802.11 wireless networks has = increased, problems in the deployment, management, and usability of these networks = have become evident. 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. 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. 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. 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 collection of vendors. Specific Working Group work items are: - Clear problem statement and description of the split AP = architecture, - 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, . 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). The intent of the CAPWAP Working Group is to complete the protocol specification as quickly as possible and to serve as a forum for facilitating the testing of 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 nongoals 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. 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. _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From jmoisand@juniper.net Wed Sep 17 22:03:36 2003 From: jmoisand@juniper.net (Jerome Moisand) Date: Wed, 17 Sep 2003 17:03:36 -0400 Subject: [Lwapp] LWAPP/CAPWAP charter => my two cents Message-ID: Sorry if this comes as a duplicate for some of guys who happen to be on = the "seamoby" list... -----Original Message----- From: Jerome Moisand =20 Sent: Wednesday, September 17, 2003 12:16 PM To: 'seamoby@ietf.org' Subject: LWAPP/CAPWAP charter =3D> my two cents Folks, The lwapp/capwap discussion has been raised to my attention by several = industry players. I am catching up on this topic, and didn't have an = opportunity to attend the corresponding BOF at the last IETF meeting, so = pardon me if some topics I mention were already discussed. I do see the point of distributing processing between an 802.11 Access = Point and some "controlling & aggregation device", based on multiple = experiences with the deployment of HotSpots services by carriers. Which = usually express a desire to lower the capex/opex for the gear located in = the HotSpots, leveraging on more semi-centralized smarts in a = "controlling & aggregation device". Which could be viewed as a NAS = (Network Access Server). So my first comment is: let's make sure the problem statement includes = topologies for carrier-based services (HotSpots being only one = incarnation of this) as well as topologies for private WLAN within an = enterprise site or a campus. But this is probably obvious for you guys. Next, I'd like to point out (hoping to not be disruptive, but maybe I = will!) that this problem seems to be only one incarnation of a larger = problem. The more general problem I'd see is the case of a lightweigh = (usually layer2 "+", but not always) access device which requires some = level of inband control by a "controlling & aggregation" (usually layer = 3 "+") NAS device of some sort, which is itself likely somewhat driven = by a policy/AAA server of some sort. The aggregation is typically hub-like, a controlling device aggregating = X lite access devices, with some hierarchical layer2 connectivity (or = sometimes a layer3 tunnel). And then the capex and opex goals strike = again, exactly like in the 802.11 space. And betting on external OSS = systems to directly control the "lite" access devices is usually a = non-starter (doesn't scale, doesn't allow fast sub-second policy = decisions).=20 Let me give a few examples (which are carrier-oriented, because it's my = area of expertise, but I'm sure there is more): a) in the DSL world, the DSL residential gateway (a CPE) is becoming = more than a simple modem (look at the recent work in the DSL-Forum), but = actually a service point. Yet one would like to keep it low capex/opex, = which may spell out an inband control protocol from a BRAS/NAS system to = push some form of policy/service rules, or pull some form of topology = information. b) again, in the DSL world, you can make a similar case between DSLAMs = and BRAS systems. For similar reasons, including multicast scenarios and = access topology discovery.=20 c) in the same vein, the cable Docsis world ended up specifying an = inband control protocol between Cable Modems (which are clearly more = than modems!) an Cable Modem Termination Systems (CMTS). This was done = at the MAC layer, which always made me cringe. I'm not saying IETF = should revolutionize this specific cable space (too late!), but just = making a point that the problem is bigger than a specific access = technology area. d) more generally, whatever the broadband access technology (DSL, Cable, = Metro-Ethernet, PON, Fixed Wireless, etc), one will likely always find a = couple of service-related parameters & mechanisms that would benefit = from some inband control mechanism from a "controlling & aggregation = device". And will always find benefits in some form of auto-discovery of = the access topology. And in some cases, may find some necessary linkage = with authentication/authorization dynamic processes and the various = access devices being involved.=20 e) again, I'm no expert here, but I can venture a guess that in the = enterprise/campus space, there are similar "wireline" scenarios in = addition to the WLAN scenario. Heck, there isn't that much difference = between a wireless LAN and a wireline LAN... So let me suggest to possibly explore a wider scope for such an inband = control protocol, taking some of the fundamental ideas behind = lwapp/capwap, but extending it to a more generic mechanism. This = mechanism would of course require a generic framework (and protocol or = set of protocols), but then allow technology-specific extensions (a form = of information model, I would venture to guess) to address peculiarities = of DSL, 802,11, PON, etc. This topic obviously deserves more detailed discussion to find a good = balance, not go out-of-bounds, nor get too narrow... Not so easy! ;-) Thoughts? Feedback? Tx Jerome Moisand Juniper Networks From hcheng@psl.com.sg Mon Sep 22 07:34:29 2003 From: hcheng@psl.com.sg (Cheng Hong) Date: Mon, 22 Sep 2003 14:34:29 +0800 Subject: [Lwapp] Proposed WG Charter In-Reply-To: <035501c36e62$c1622170$956015ac@dclkempt40> Message-ID: Hi Jak, > - Dependence on yet to be approved IEEE 802.11 work or drafts, Would like to have some clarification on this. What is the definiation of the approved IEEE802.11 work or draft? Approved by who? Also, if during the WG's time frame, new drafts was approved by IEEE, should the drafts in CAPWAP be modified accordingly? BR Cheng > -----Original Message----- > From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com]On > Behalf Of James Kempf > Sent: Saturday, August 30, 2003 3:22 AM > To: LWAPP > Subject: [Lwapp] Proposed WG Charter > > > Folks, > > Below is a charter for the WG that Dorothy and I would like to propose to > Randy. Please send comments if you have any. > > jak > > +++++++++++++++++++++++++++++++++++++++++++++++ > Control and Provisioning of Wireless Access Points (CAPWAP) > =============================================== > > Area: > ----- > OPS > > Chairs: > ------- > TBD > > Mailing List: > ------------- > List: lwapp@frascone.com > Subscribe: lwapp-request@frascone.com > Body: subscribe in Subject line > Archive: http://mail.frascone.com/pipermail/public/lwapp/ > > Description of Working Group: > ----------------------------- > As the size and complexity of IEEE 802.11 wireless networks has increased, > problems in the deployment, management, and usability of these > networks have > become evident. 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. 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. > > 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. 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 collection of > vendors. > > Specific Working Group work items are: > > - Clear problem statement and description of the split AP architecture, > - 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, > . 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). > > The intent of the CAPWAP Working Group is to complete the protocol > specification as quickly as possible and to serve as a forum for > facilitating the testing of 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 nongoals 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. > > 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. > > > > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > From pcalhoun@airespace.com Mon Sep 22 13:29:18 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Mon, 22 Sep 2003 05:29:18 -0700 Subject: [Lwapp] Proposed WG Charter Message-ID: <40301581B2962B448690A023EF16DFE1014B26DC@bsn-mail-01.bstormnetworks.com> The CAPWAP protocol should be able to handle any IEEE protocol with = minimal (or no) configuration other than defining where the functions = reside. However, if the architecture is as defined in the LWAPP = specification, then any non real-time function belongs in the AR and no = additional documentation is required (other than if we wish to clarify). PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Sun 9/21/2003 11:34 PM To: James Kempf; LWAPP Cc:=09 Subject: RE: [Lwapp] Proposed WG Charter Hi Jak, > - Dependence on yet to be approved IEEE 802.11 work or drafts, Would like to have some clarification on this. What is the definiation = of the approved IEEE802.11 work or draft? Approved by who? Also, if during the WG's time frame, new drafts was approved by IEEE, = should the drafts in CAPWAP be modified accordingly? BR Cheng > -----Original Message----- > From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com]On > Behalf Of James Kempf > Sent: Saturday, August 30, 2003 3:22 AM > To: LWAPP > Subject: [Lwapp] Proposed WG Charter > > > Folks, > > Below is a charter for the WG that Dorothy and I would like to propose = to > Randy. Please send comments if you have any. > > jak > > +++++++++++++++++++++++++++++++++++++++++++++++ > Control and Provisioning of Wireless Access Points (CAPWAP) > = =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 > > Area: > ----- > OPS > > Chairs: > ------- > TBD > > Mailing List: > ------------- > List: lwapp@frascone.com > Subscribe: lwapp-request@frascone.com > Body: subscribe in Subject line > Archive: http://mail.frascone.com/pipermail/public/lwapp/ > > Description of Working Group: > ----------------------------- > As the size and complexity of IEEE 802.11 wireless networks has = increased, > problems in the deployment, management, and usability of these > networks have > become evident. 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. 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. > > 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. 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 collection = of > vendors. > > Specific Working Group work items are: > > - Clear problem statement and description of the split AP = architecture, > - 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, > . 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). > > The intent of the CAPWAP Working Group is to complete the protocol > specification as quickly as possible and to serve as a forum for > facilitating the testing of 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 nongoals 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. > > 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. > > > > > _______________________________________________ > 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 bob@airespace.com Mon Sep 22 18:27:45 2003 From: bob@airespace.com (Bob O'Hara) Date: Mon, 22 Sep 2003 10:27:45 -0700 Subject: [Lwapp] Proposed WG Charter Message-ID: <40301581B2962B448690A023EF16DFE10139B0F3@bsn-mail-01.bstormnetworks.com> Cheng, I believe that the only one that can "approve" an IEEE standard is the IEEE Standards Board. The list of approved IEEE standards and amendments is 802.11-1999, 802.11a-1999, 802.11b-1999, 802.11d-2001, 802.11g-2003, and 802.11h-2003. Recommended Practice 802.11F-2003 is also approved. I cannot speak for the WG, but I would presume that the WG would decide to include, or not, a newly approved IEEE 802.11 standard on a case by case basis, dependent on both the impact of such inclusion or exclusion on the market acceptance of the resultant IETF standard and the work to incorporate support for the newly approved IEEE 802.11 standard. -Bob O'Hara =20 -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg]=20 Sent: Sunday, September 21, 2003 11:34 PM To: James Kempf; LWAPP Subject: RE: [Lwapp] Proposed WG Charter Hi Jak, > - Dependence on yet to be approved IEEE 802.11 work or drafts, Would like to have some clarification on this. What is the definiation of the approved IEEE802.11 work or draft? Approved by who? Also, if during the WG's time frame, new drafts was approved by IEEE, should the drafts in CAPWAP be modified accordingly? BR Cheng > -----Original Message----- > From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com]On > Behalf Of James Kempf > Sent: Saturday, August 30, 2003 3:22 AM > To: LWAPP > Subject: [Lwapp] Proposed WG Charter > > > Folks, > > Below is a charter for the WG that Dorothy and I would like to propose to > Randy. Please send comments if you have any. > > jak > > +++++++++++++++++++++++++++++++++++++++++++++++ > Control and Provisioning of Wireless Access Points (CAPWAP) > = =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 > > Area: > ----- > OPS > > Chairs: > ------- > TBD > > Mailing List: > ------------- > List: lwapp@frascone.com > Subscribe: lwapp-request@frascone.com > Body: subscribe in Subject line > Archive: http://mail.frascone.com/pipermail/public/lwapp/ > > Description of Working Group: > ----------------------------- > As the size and complexity of IEEE 802.11 wireless networks has increased, > problems in the deployment, management, and usability of these > networks have > become evident. 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. 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. > > 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. 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 collection of > vendors. > > Specific Working Group work items are: > > - Clear problem statement and description of the split AP architecture, > - 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, > . 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). > > The intent of the CAPWAP Working Group is to complete the protocol > specification as quickly as possible and to serve as a forum for > facilitating the testing of 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 nongoals 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. > > 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. > > > > > _______________________________________________ > 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 hcheng@psl.com.sg Tue Sep 23 03:36:59 2003 From: hcheng@psl.com.sg (Cheng Hong) Date: Tue, 23 Sep 2003 10:36:59 +0800 Subject: [Lwapp] Proposed WG Charter In-Reply-To: <40301581B2962B448690A023EF16DFE10139B0F3@bsn-mail-01.bstormnetworks.com> Message-ID: Hi Bob, Thanks for the reply. As you listed out, the 802.11e and 802.11i are not yet approved. But if these two standards are managed to get through within a few IEEE meetings, would that affect the work at CAPWAP? As Pat pointed out the main implication maybe just where the functions reside. I think the issue is whether we should consider these implications now, or left them to when those standards are get approved? Although the 11e and 11i are not approved standards, the architecture and main functions are somehow stable now. So, it may be better for us also take into account of some generic requirements from them now. BR Cheng > -----Original Message----- > From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com]On > Behalf Of Bob O'Hara > Sent: Tuesday, September 23, 2003 1:28 AM > To: LWAPP > Subject: RE: [Lwapp] Proposed WG Charter > > > Cheng, > > I believe that the only one that can "approve" an IEEE standard is the > IEEE Standards Board. The list of approved IEEE standards and > amendments is 802.11-1999, 802.11a-1999, 802.11b-1999, 802.11d-2001, > 802.11g-2003, and 802.11h-2003. Recommended Practice 802.11F-2003 is > also approved. > > I cannot speak for the WG, but I would presume that the WG would decide > to include, or not, a newly approved IEEE 802.11 standard on a case by > case basis, dependent on both the impact of such inclusion or exclusion > on the market acceptance of the resultant IETF standard and the work to > incorporate support for the newly approved IEEE 802.11 standard. > > -Bob O'Hara > > > -----Original Message----- > From: Cheng Hong [mailto:hcheng@psl.com.sg] > Sent: Sunday, September 21, 2003 11:34 PM > To: James Kempf; LWAPP > Subject: RE: [Lwapp] Proposed WG Charter > > > Hi Jak, > > > - Dependence on yet to be approved IEEE 802.11 work or drafts, > > Would like to have some clarification on this. What is the definiation > of > the approved IEEE802.11 work or draft? Approved by who? > > Also, if during the WG's time frame, new drafts was approved by IEEE, > should > the drafts in CAPWAP be modified accordingly? > > BR > > Cheng > > > -----Original Message----- > > From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com]On > > Behalf Of James Kempf > > Sent: Saturday, August 30, 2003 3:22 AM > > To: LWAPP > > Subject: [Lwapp] Proposed WG Charter > > > > > > Folks, > > > > Below is a charter for the WG that Dorothy and I would like to propose > to > > Randy. Please send comments if you have any. > > > > jak > > > > +++++++++++++++++++++++++++++++++++++++++++++++ > > Control and Provisioning of Wireless Access Points (CAPWAP) > > =============================================== > > > > Area: > > ----- > > OPS > > > > Chairs: > > ------- > > TBD > > > > Mailing List: > > ------------- > > List: lwapp@frascone.com > > Subscribe: lwapp-request@frascone.com > > Body: subscribe in Subject line > > Archive: http://mail.frascone.com/pipermail/public/lwapp/ > > > > Description of Working Group: > > ----------------------------- > > As the size and complexity of IEEE 802.11 wireless networks has > increased, > > problems in the deployment, management, and usability of these > > networks have > > become evident. 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. 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. > > > > 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. 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 collection > of > > vendors. > > > > Specific Working Group work items are: > > > > - Clear problem statement and description of the split AP > architecture, > > - 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, > > . 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). > > > > The intent of the CAPWAP Working Group is to complete the protocol > > specification as quickly as possible and to serve as a forum for > > facilitating the testing of 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 nongoals 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. > > > > 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. > > > > > > > > > > _______________________________________________ > > 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 dmolnar@eecs.harvard.edu Tue Sep 23 07:18:30 2003 From: dmolnar@eecs.harvard.edu (David Molnar) Date: Tue, 23 Sep 2003 02:18:30 -0400 (EDT) Subject: [Lwapp] Proposed WG Charter In-Reply-To: References: Message-ID: On Tue, 23 Sep 2003, Cheng Hong wrote: > As you listed out, the 802.11e and 802.11i are not yet approved. But if > these two standards are managed to get through within a few IEEE meetings, > would that affect the work at CAPWAP? I don't think 802.11i would significantly affect the CAPWAP work any more than WPA does now. Both offer security for data traffic tunneled from AP to AR, but do not offer security for control traffic between AP and AR. We would still need to specify some means of securing this traffic, especially when the CAPWAP/LWAPP protocol is routed over multiple networks. For more details, check out the discussion Scott and I have of ARCH1 and ARCH2 in the security requirements draft at http://www.ietf.org/internet-drafts/draft-kelly-ietf-lwapp-sec-00.txt -David Molnar Legra Systems From kempf@docomolabs-usa.com Fri Sep 26 22:08:26 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Fri, 26 Sep 2003 14:08:26 -0700 Subject: [Lwapp] Recommended Reading:Research Work on Split AP Architecture Message-ID: <02e901c38472$5408b1e0$956015ac@dclkempt40> There is a paper in this year's Mobicom that presents an independently researched architecture for wireless access network routers. The paper is written from the point of view of extending the router functionality down to the AP rather than the AP functionality to the router, but the principle is the same. They make a good argument about why APs in this architecture need to be upgradable. Interestingly, although they did not implement wireless frame tunneling from the AP to the router, they do allow the uplink and downlink paths in their implementation (they use the Linux Click modular router framework) to be separate to serve different wireless protocol needs. Thus, one could implement frame tunneling if required for a particular radio link. The demonstrate three applications: fast IPv6 handover, removing head of line blocking using FEC, and policing. Since the paper is primarily focusing on demonstrating the new architecture, they don't consider security at all, one defect. Here's the reference: Zerfos, P., Zhong, G., Cheng, J., Luo, H., Lu, S., and Li, J.J., "DIRAC: A Software-based Wireless Router System," Proceedings of Mobicom 2003, pp. 230-244, 2003. jak From lily.l.yang@intel.com Fri Sep 26 23:22:38 2003 From: lily.l.yang@intel.com (Yang, Lily L) Date: Fri, 26 Sep 2003 15:22:38 -0700 Subject: [Lwapp] Recommended Reading:Research Work on Split AP Architecture Message-ID: <26BDFAFFB541B047B24179002EBE6D2714FF28@orsmsx410.jf.intel.com> I've had many conversations with the authors (a group led by Dr. Songwu = Lu from UCLA) about their work and the architecture similarity with = CAPWAP. As James pointed out, in their approach, 802.11 is terminated at = the APs but statistics/events/configuration from 802.11 is=20 abstracted and sent via their protocol (similar to LWAPP) between APs = and ARs. This potentially can be a more extensible solution (that is, = extensible to other radio technologies) than terminating 802.11 all the = way at ARs.=20 But I am not sure I would agree that their approach is extending the = router functionality down to AP rather than the AP to AR. In their = approach, AP remains L2 bridge device while L3 intelligence is moved and = aggregated at AR. So the end goal is the same as LWAPP. Petros -- Did I summarize it right? What do you think? Lily > -----Original Message----- > From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com]On > Behalf Of James Kempf > Sent: Friday, September 26, 2003 2:08 PM > To: LWAPP > Cc: Randy Bush > Subject: [Lwapp] Recommended Reading:Research Work on Split AP > Architecture >=20 >=20 > There is a paper in this year's Mobicom that presents an independently > researched architecture for wireless access network routers.=20 > The paper is > written from the point of view of extending the router=20 > functionality down to > the AP rather than the AP functionality to the router, but=20 > the principle is > the same. They make a good argument about why APs in this=20 > architecture need > to be upgradable. Interestingly, although they did not=20 > implement wireless > frame tunneling from the AP to the router, they do allow the=20 > uplink and > downlink paths in their implementation (they use the Linux=20 > Click modular > router framework) to be separate to serve different wireless=20 > protocol needs. > Thus, one could implement frame tunneling if required for a=20 > particular radio > link. The demonstrate three applications: fast IPv6 handover,=20 > removing head > of line blocking using FEC, and policing. Since the paper is primarily > focusing on demonstrating the new architecture, they don't=20 > consider security > at all, one defect. >=20 > Here's the reference: Zerfos, P., Zhong, G., Cheng, J., Luo,=20 > H., Lu, S., and > Li, J.J., "DIRAC: A Software-based Wireless Router System,"=20 > Proceedings of > Mobicom 2003, pp. 230-244, 2003. >=20 > jak >=20 > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp >=20 From pcalhoun@airespace.com Sat Sep 27 00:12:26 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Fri, 26 Sep 2003 16:12:26 -0700 Subject: [Lwapp] Recommended Reading:Research Work on Split AP Architecture Message-ID: <40301581B2962B448690A023EF16DFE1014B27A3@bsn-mail-01.bstormnetworks.com> That is one approach, but what you end up doing is re-creating the = 802.11 mac management protocol in another format, and having the AP send = these frames up to the AR. Clearly, it is much more efficient, and = expeditious, to simply have the AP forward the already defined messages = to the AR. Yes, the end goal is the same. PatC -----Original Message----- From: Yang, Lily L [mailto:lily.l.yang@intel.com] Sent: Fri 9/26/2003 3:22 PM To: James Kempf; LWAPP Cc: Randy Bush; Petros Zerfos; Songwu Lu Subject: RE: [Lwapp] Recommended Reading:Research Work on Split AP = Architecture I've had many conversations with the authors (a group led by Dr. Songwu = Lu from UCLA) about their work and the architecture similarity with = CAPWAP. As James pointed out, in their approach, 802.11 is terminated at = the APs but statistics/events/configuration from 802.11 is=20 abstracted and sent via their protocol (similar to LWAPP) between APs = and ARs. This potentially can be a more extensible solution (that is, = extensible to other radio technologies) than terminating 802.11 all the = way at ARs.=20 But I am not sure I would agree that their approach is extending the = router functionality down to AP rather than the AP to AR. In their = approach, AP remains L2 bridge device while L3 intelligence is moved and = aggregated at AR. So the end goal is the same as LWAPP. Petros -- Did I summarize it right? What do you think? Lily > -----Original Message----- > From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com]On > Behalf Of James Kempf > Sent: Friday, September 26, 2003 2:08 PM > To: LWAPP > Cc: Randy Bush > Subject: [Lwapp] Recommended Reading:Research Work on Split AP > Architecture >=20 >=20 > There is a paper in this year's Mobicom that presents an independently > researched architecture for wireless access network routers.=20 > The paper is > written from the point of view of extending the router=20 > functionality down to > the AP rather than the AP functionality to the router, but=20 > the principle is > the same. They make a good argument about why APs in this=20 > architecture need > to be upgradable. Interestingly, although they did not=20 > implement wireless > frame tunneling from the AP to the router, they do allow the=20 > uplink and > downlink paths in their implementation (they use the Linux=20 > Click modular > router framework) to be separate to serve different wireless=20 > protocol needs. > Thus, one could implement frame tunneling if required for a=20 > particular radio > link. The demonstrate three applications: fast IPv6 handover,=20 > removing head > of line blocking using FEC, and policing. Since the paper is primarily > focusing on demonstrating the new architecture, they don't=20 > consider security > at all, one defect. >=20 > Here's the reference: Zerfos, P., Zhong, G., Cheng, J., Luo,=20 > H., Lu, S., and > Li, J.J., "DIRAC: A Software-based Wireless Router System,"=20 > Proceedings of > Mobicom 2003, pp. 230-244, 2003. >=20 > jak >=20 > _______________________________________________ > 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 kempf@docomolabs-usa.com Sat Sep 27 00:23:33 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Fri, 26 Sep 2003 16:23:33 -0700 Subject: [Lwapp] Recommended Reading:Research Work on Split AP Architecture References: <40301581B2962B448690A023EF16DFE1014B27A3@bsn-mail-01.bstormnetworks.com> Message-ID: <038b01c38485$345f1830$956015ac@dclkempt40> I don't have the impression from the article that they are duplicating 8022.11 mac. They have a protocol in TLV format that sends four classes of messages: statistics, events, actions or registration. The statistics corresponds to Statistics Report in LWAPP, events and actions correspond to messages like Add Mobile or Configuration Update, and registration corresponds to something like Discovery/Join. Unfortunately, they don't go into much detail about exactly what the messages are, so it is hard to tell. jak ----- Original Message ----- From: "Pat R. Calhoun" To: "Yang, Lily L" ; "James Kempf" ; "LWAPP" Cc: "Randy Bush" ; "Petros Zerfos" ; "Songwu Lu" Sent: Friday, September 26, 2003 4:12 PM Subject: RE: [Lwapp] Recommended Reading:Research Work on Split AP Architecture > That is one approach, but what you end up doing is re-creating the 802.11 mac management protocol in another format, and having the AP send these frames up to the AR. Clearly, it is much more efficient, and expeditious, to simply have the AP forward the already defined messages to the AR. > > Yes, the end goal is the same. > > PatC > -----Original Message----- > From: Yang, Lily L [mailto:lily.l.yang@intel.com] > Sent: Fri 9/26/2003 3:22 PM > To: James Kempf; LWAPP > Cc: Randy Bush; Petros Zerfos; Songwu Lu > Subject: RE: [Lwapp] Recommended Reading:Research Work on Split AP Architecture > I've had many conversations with the authors (a group led by Dr. Songwu Lu from UCLA) about their work and the architecture similarity with CAPWAP. As James pointed out, in their approach, 802.11 is terminated at the APs but statistics/events/configuration from 802.11 is > abstracted and sent via their protocol (similar to LWAPP) between APs and ARs. This potentially can be a more extensible solution (that is, extensible to other radio technologies) than terminating 802.11 all the way at ARs. > But I am not sure I would agree that their approach is extending the router functionality down to AP rather than the AP to AR. In their approach, AP remains L2 bridge device while L3 intelligence is moved and aggregated at AR. So the end goal is the same as LWAPP. > > Petros -- Did I summarize it right? What do you think? > > Lily > > > -----Original Message----- > > From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com]On > > Behalf Of James Kempf > > Sent: Friday, September 26, 2003 2:08 PM > > To: LWAPP > > Cc: Randy Bush > > Subject: [Lwapp] Recommended Reading:Research Work on Split AP > > Architecture > > > > > > There is a paper in this year's Mobicom that presents an independently > > researched architecture for wireless access network routers. > > The paper is > > written from the point of view of extending the router > > functionality down to > > the AP rather than the AP functionality to the router, but > > the principle is > > the same. They make a good argument about why APs in this > > architecture need > > to be upgradable. Interestingly, although they did not > > implement wireless > > frame tunneling from the AP to the router, they do allow the > > uplink and > > downlink paths in their implementation (they use the Linux > > Click modular > > router framework) to be separate to serve different wireless > > protocol needs. > > Thus, one could implement frame tunneling if required for a > > particular radio > > link. The demonstrate three applications: fast IPv6 handover, > > removing head > > of line blocking using FEC, and policing. Since the paper is primarily > > focusing on demonstrating the new architecture, they don't > > consider security > > at all, one defect. > > > > Here's the reference: Zerfos, P., Zhong, G., Cheng, J., Luo, > > H., Lu, S., and > > Li, J.J., "DIRAC: A Software-based Wireless Router System," > > Proceedings of > > Mobicom 2003, pp. 230-244, 2003. > > > > jak > > > > _______________________________________________ > > Lwapp mailing list > > Lwapp@frascone.com > > http://mail.frascone.com/mailman/listinfo/lwapp > > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > > > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > > From pcalhoun@airespace.com Sat Sep 27 00:25:45 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Fri, 26 Sep 2003 16:25:45 -0700 Subject: [Lwapp] Recommended Reading:Research Work on Split AP Architecture Message-ID: <40301581B2962B448690A023EF16DFE1014B27A4@bsn-mail-01.bstormnetworks.com> Right, so add mobile is in fact a duplication of a MAC mgmt message. It = also sounds like the AP is involved in the access/policy decision = process, which does not provide many of the benefits of having this = function centralized (e.g. security, load balancing). PatC -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Fri 9/26/2003 4:23 PM To: Pat R. Calhoun; Yang, Lily L; LWAPP Cc: Randy Bush; Petros Zerfos; Songwu Lu Subject: Re: [Lwapp] Recommended Reading:Research Work on Split AP = Architecture I don't have the impression from the article that they are duplicating 8022.11 mac. They have a protocol in TLV format that sends four classes = of messages: statistics, events, actions or registration. The statistics corresponds to Statistics Report in LWAPP, events and actions correspond = to messages like Add Mobile or Configuration Update, and registration corresponds to something like Discovery/Join. Unfortunately, they don't = go into much detail about exactly what the messages are, so it is hard to = tell. jak ----- Original Message -----=20 From: "Pat R. Calhoun" To: "Yang, Lily L" ; "James Kempf" ; "LWAPP" Cc: "Randy Bush" ; "Petros Zerfos" ; "Songwu Lu" Sent: Friday, September 26, 2003 4:12 PM Subject: RE: [Lwapp] Recommended Reading:Research Work on Split AP Architecture > That is one approach, but what you end up doing is re-creating the = 802.11 mac management protocol in another format, and having the AP send these frames up to the AR. Clearly, it is much more efficient, and = expeditious, to simply have the AP forward the already defined messages to the AR. > > Yes, the end goal is the same. > > PatC > -----Original Message----- > From: Yang, Lily L [mailto:lily.l.yang@intel.com] > Sent: Fri 9/26/2003 3:22 PM > To: James Kempf; LWAPP > Cc: Randy Bush; Petros Zerfos; Songwu Lu > Subject: RE: [Lwapp] Recommended Reading:Research Work on Split AP Architecture > I've had many conversations with the authors (a group led by Dr. = Songwu Lu from UCLA) about their work and the architecture similarity with CAPWAP. = As James pointed out, in their approach, 802.11 is terminated at the APs = but statistics/events/configuration from 802.11 is > abstracted and sent via their protocol (similar to LWAPP) between APs = and ARs. This potentially can be a more extensible solution (that is, = extensible to other radio technologies) than terminating 802.11 all the way at ARs. > But I am not sure I would agree that their approach is extending the router functionality down to AP rather than the AP to AR. In their = approach, AP remains L2 bridge device while L3 intelligence is moved and = aggregated at AR. So the end goal is the same as LWAPP. > > Petros -- Did I summarize it right? What do you think? > > Lily > > > -----Original Message----- > > From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com]On > > Behalf Of James Kempf > > Sent: Friday, September 26, 2003 2:08 PM > > To: LWAPP > > Cc: Randy Bush > > Subject: [Lwapp] Recommended Reading:Research Work on Split AP > > Architecture > > > > > > There is a paper in this year's Mobicom that presents an = independently > > researched architecture for wireless access network routers. > > The paper is > > written from the point of view of extending the router > > functionality down to > > the AP rather than the AP functionality to the router, but > > the principle is > > the same. They make a good argument about why APs in this > > architecture need > > to be upgradable. Interestingly, although they did not > > implement wireless > > frame tunneling from the AP to the router, they do allow the > > uplink and > > downlink paths in their implementation (they use the Linux > > Click modular > > router framework) to be separate to serve different wireless > > protocol needs. > > Thus, one could implement frame tunneling if required for a > > particular radio > > link. The demonstrate three applications: fast IPv6 handover, > > removing head > > of line blocking using FEC, and policing. Since the paper is = primarily > > focusing on demonstrating the new architecture, they don't > > consider security > > at all, one defect. > > > > Here's the reference: Zerfos, P., Zhong, G., Cheng, J., Luo, > > H., Lu, S., and > > Li, J.J., "DIRAC: A Software-based Wireless Router System," > > Proceedings of > > Mobicom 2003, pp. 230-244, 2003. > > > > jak > > > > _______________________________________________ > > Lwapp mailing list > > Lwapp@frascone.com > > http://mail.frascone.com/mailman/listinfo/lwapp > > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > > > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > > From kempf@docomolabs-usa.com Sat Sep 27 00:31:13 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Fri, 26 Sep 2003 16:31:13 -0700 Subject: [Lwapp] Recommended Reading:Research Work on Split AP Architecture References: <40301581B2962B448690A023EF16DFE1014B27A4@bsn-mail-01.bstormnetworks.com> Message-ID: <039501c38486$478cf4d0$956015ac@dclkempt40> Add Mobile is in LWAPP, Section 4.2.5.1 of the LWAPP draft, so I'm not sure I understand your point. Are you saying that LWAPP duplicates mac signaling??? Anyway, I don't know for sure that they have an Add Mobile, but it would sound like a logical action that the AR would tell the AP to do, like in LWAPP, and therefore fall under the "actions" category of message for their protocol. Perhaps one of the authors wants to comment. I agree that centralizing Add Mobile is necessary for security and load balancing. I believe these are also reasons for data frame tunneling (another being handover performance). jak > Right, so add mobile is in fact a duplication of a MAC mgmt message. It also sounds like the AP is involved in the access/policy decision process, which does not provide many of the benefits of having this function centralized (e.g. security, load balancing). > > PatC > > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Fri 9/26/2003 4:23 PM > To: Pat R. Calhoun; Yang, Lily L; LWAPP > Cc: Randy Bush; Petros Zerfos; Songwu Lu > Subject: Re: [Lwapp] Recommended Reading:Research Work on Split AP Architecture > I don't have the impression from the article that they are duplicating > 8022.11 mac. They have a protocol in TLV format that sends four classes of > messages: statistics, events, actions or registration. The statistics > corresponds to Statistics Report in LWAPP, events and actions correspond to > messages like Add Mobile or Configuration Update, and registration > corresponds to something like Discovery/Join. Unfortunately, they don't go > into much detail about exactly what the messages are, so it is hard to tell. > > jak > > > ----- Original Message ----- > From: "Pat R. Calhoun" > To: "Yang, Lily L" ; "James Kempf" > ; "LWAPP" > Cc: "Randy Bush" ; "Petros Zerfos" ; > "Songwu Lu" > Sent: Friday, September 26, 2003 4:12 PM > Subject: RE: [Lwapp] Recommended Reading:Research Work on Split AP > Architecture > > > > That is one approach, but what you end up doing is re-creating the 802.11 > mac management protocol in another format, and having the AP send these > frames up to the AR. Clearly, it is much more efficient, and expeditious, to > simply have the AP forward the already defined messages to the AR. > > > > Yes, the end goal is the same. > > > > PatC > > -----Original Message----- > > From: Yang, Lily L [mailto:lily.l.yang@intel.com] > > Sent: Fri 9/26/2003 3:22 PM > > To: James Kempf; LWAPP > > Cc: Randy Bush; Petros Zerfos; Songwu Lu > > Subject: RE: [Lwapp] Recommended Reading:Research Work on Split AP > Architecture > > I've had many conversations with the authors (a group led by Dr. Songwu Lu > from UCLA) about their work and the architecture similarity with CAPWAP. As > James pointed out, in their approach, 802.11 is terminated at the APs but > statistics/events/configuration from 802.11 is > > abstracted and sent via their protocol (similar to LWAPP) between APs and > ARs. This potentially can be a more extensible solution (that is, extensible > to other radio technologies) than terminating 802.11 all the way at ARs. > > But I am not sure I would agree that their approach is extending the > router functionality down to AP rather than the AP to AR. In their approach, > AP remains L2 bridge device while L3 intelligence is moved and aggregated at > AR. So the end goal is the same as LWAPP. > > > > Petros -- Did I summarize it right? What do you think? > > > > Lily > > > > > -----Original Message----- > > > From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com]On > > > Behalf Of James Kempf > > > Sent: Friday, September 26, 2003 2:08 PM > > > To: LWAPP > > > Cc: Randy Bush > > > Subject: [Lwapp] Recommended Reading:Research Work on Split AP > > > Architecture > > > > > > > > > There is a paper in this year's Mobicom that presents an independently > > > researched architecture for wireless access network routers. > > > The paper is > > > written from the point of view of extending the router > > > functionality down to > > > the AP rather than the AP functionality to the router, but > > > the principle is > > > the same. They make a good argument about why APs in this > > > architecture need > > > to be upgradable. Interestingly, although they did not > > > implement wireless > > > frame tunneling from the AP to the router, they do allow the > > > uplink and > > > downlink paths in their implementation (they use the Linux > > > Click modular > > > router framework) to be separate to serve different wireless > > > protocol needs. > > > Thus, one could implement frame tunneling if required for a > > > particular radio > > > link. The demonstrate three applications: fast IPv6 handover, > > > removing head > > > of line blocking using FEC, and policing. Since the paper is primarily > > > focusing on demonstrating the new architecture, they don't > > > consider security > > > at all, one defect. > > > > > > Here's the reference: Zerfos, P., Zhong, G., Cheng, J., Luo, > > > H., Lu, S., and > > > Li, J.J., "DIRAC: A Software-based Wireless Router System," > > > Proceedings of > > > Mobicom 2003, pp. 230-244, 2003. > > > > > > jak > > > > > > _______________________________________________ > > > Lwapp mailing list > > > Lwapp@frascone.com > > > http://mail.frascone.com/mailman/listinfo/lwapp > > > > > _______________________________________________ > > Lwapp mailing list > > Lwapp@frascone.com > > http://mail.frascone.com/mailman/listinfo/lwapp > > > > > > > > _______________________________________________ > > Lwapp mailing list > > Lwapp@frascone.com > > http://mail.frascone.com/mailman/listinfo/lwapp > > > > > > > > > > From pcalhoun@airespace.com Sat Sep 27 00:35:39 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Fri, 26 Sep 2003 16:35:39 -0700 Subject: [Lwapp] Recommended Reading:Research Work on Split AP Architecture Message-ID: <40301581B2962B448690A023EF16DFE1014B27A5@bsn-mail-01.bstormnetworks.com> Add Mobile is in LWAPP, Section 4.2.5.1 of the LWAPP draft, so I'm not = sure I understand your point. Are you saying that LWAPP duplicates mac signaling??? In LWAPP, the AP "tunnels" the 802.11 MAC mgmt messages, such as = the Auth and Association messages. This is used by the AR as a trigger = for requesting access on behalf of the mobile device. The AR then sends = back an access policy to the AP, via the Add Mobile message. PatC From mmani@avaya.com Sat Sep 27 00:46:58 2003 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Fri, 26 Sep 2003 17:46:58 -0600 Subject: [Lwapp] Recommended Reading:Research Work on Split AP Architecture Message-ID: The LWAPP also defines a "mobile session key" message. As opposed to the centralized function abstracted to the AR below; this one suggests still leaving that in the AP. Therefore, LWAPP draft is catering to at least two of these architecture types (mappable to ARCH2 and ARCH1 respectively as defined in lwapp-sec-00 -mani > -----Original Message----- > From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] > Sent: Friday, September 26, 2003 4:36 PM > To: James Kempf; Yang, Lily L; LWAPP > Cc: Randy Bush; Petros Zerfos; Songwu Lu > Subject: RE: [Lwapp] Recommended Reading:Research Work on Split AP > Architecture >=20 > Add Mobile is in LWAPP, Section 4.2.5.1 of the LWAPP draft, so I'm not > sure > I understand your point. Are you saying that LWAPP duplicates mac > signaling??? >=20 > In LWAPP, the AP "tunnels" the 802.11 MAC mgmt messages, such as the > Auth and Association messages. This is used by the AR as a trigger for > requesting access on behalf of the mobile device. The AR then sends back > an access policy to the AP, via the Add Mobile message. >=20 > PatC > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp From randy@psg.com Mon Sep 29 21:07:31 2003 From: randy@psg.com (Randy Bush) Date: Mon, 29 Sep 2003 13:07:31 -0700 Subject: [Lwapp] capwap charter comments from iab and iesg Message-ID: 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-