From florent.bersani@rd.francetelecom.fr Wed Mar 3 08:47:43 2004 From: florent.bersani@rd.francetelecom.fr (Florent Bersani) Date: Wed, 03 Mar 2004 09:47:43 +0100 Subject: [Capwap] What about other ongoing activity at IEEE 802.11? Message-ID: <40459BAF.6010209@rd.francetelecom.fr> My question after Dorothy's presentation this afternoon on the IEEE 802/IETF liaison was: what about the Management of Wireless Device Study Group that has been set up within .11 at the January 2004 Vancouver IEEE 802 interim meeting (see e.g. IEEE 802 document 11-03-0950-01-0wng-need-managed-ieee-802-11-devices.ppt)? We discussed this question briefly with Dorothy and she should provide you with more insights than I can ;-) From florent.bersani@rd.francetelecom.fr Wed Mar 3 10:04:30 2004 From: florent.bersani@rd.francetelecom.fr (Florent Bersani) Date: Wed, 03 Mar 2004 11:04:30 +0100 Subject: [Capwap] Slides presented at IETF 59 Message-ID: <4045ADAE.4080809@rd.francetelecom.fr> Are they please available somewhere? From mmani@avaya.com Wed Mar 3 11:46:38 2004 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Wed, 3 Mar 2004 04:46:38 -0700 Subject: [Capwap] RE: Slides presented at IETF 59 Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C40115.300831D9 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2Ugd2lsbCB0cnkgdG8gZ2V0IHRoZW0gc29vbiBvbiB0byB3d3cuY2Fwd2FwLm9yZyAtIGFuZCBs ZXQgdGhlIGxpc3Qga25vdyB3aGVuIGRvbmUuDQotbWFuaQ0KDQoJLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0gDQoJRnJvbTogRmxvcmVudCBCZXJzYW5pIFttYWlsdG86ZmxvcmVudC5iZXJzYW5p QHJkLmZyYW5jZXRlbGVjb20uZnJdIA0KCVNlbnQ6IFdlZCAzLzMvMjAwNCAyOjA0IEFNIA0KCVRv OiBNYW5pLCBNYWhhbGluZ2FtIChNYWhhbGluZ2FtKTsgZG9yb3RoeS5nZWxsZXJ0QG5va2lhLmNv bSANCglDYzogY2Fwd2FwQGZyYXNjb25lLmNvbSANCglTdWJqZWN0OiBTbGlkZXMgcHJlc2VudGVk IGF0IElFVEYgNTkNCgkNCgkNCg0KCUFyZSB0aGV5IHBsZWFzZSBhdmFpbGFibGUgc29tZXdoZXJl Pw0KCQ0KDQo= ------_=_NextPart_001_01C40115.300831D9 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPgo8IURPQ1RZUEUgSFRNTCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgMy4yLy9F TiI+CjxIVE1MPgo8SEVBRD4KCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMgRXhj aGFuZ2UgU2VydmVyIHZlcnNpb24gNi4wLjY0ODcuMSI+CjxUSVRMRT5TbGlkZXMgcHJlc2VudGVk IGF0IElFVEYgNTk8L1RJVExFPgo8L0hFQUQ+CjxCT0RZIGRpcj1sdHI+CjxESVY+V2Ugd2lsbCB0 cnkgdG8gZ2V0IHRoZW0gc29vbiBvbiB0byA8QSAKaHJlZj0iaHR0cDovL3d3dy5jYXB3YXAub3Jn Ij53d3cuY2Fwd2FwLm9yZzwvQT4gLSBhbmQgbGV0IHRoZSBsaXN0IGtub3cgd2hlbiAKZG9uZS48 L0RJVj4KPERJVj4tbWFuaTwvRElWPgo8QkxPQ0tRVU9URSBkaXI9bHRyIHN0eWxlPSJNQVJHSU4t UklHSFQ6IDBweCI+CiAgPERJVj48Rk9OVCBzaXplPTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0gPEJSPjxCPkZyb206PC9CPiBGbG9yZW50IEJlcnNhbmkgCiAgW21haWx0bzpmbG9yZW50LmJl cnNhbmlAcmQuZnJhbmNldGVsZWNvbS5mcl0gPEJSPjxCPlNlbnQ6PC9CPiBXZWQgMy8zLzIwMDQg CiAgMjowNCBBTSA8QlI+PEI+VG86PC9CPiBNYW5pLCBNYWhhbGluZ2FtIChNYWhhbGluZ2FtKTsg CiAgZG9yb3RoeS5nZWxsZXJ0QG5va2lhLmNvbSA8QlI+PEI+Q2M6PC9CPiBjYXB3YXBAZnJhc2Nv bmUuY29tIAogIDxCUj48Qj5TdWJqZWN0OjwvQj4gU2xpZGVzIHByZXNlbnRlZCBhdCBJRVRGIDU5 PEJSPjxCUj48L0ZPTlQ+PC9ESVY+CiAgPFA+PEZPTlQgc2l6ZT0yPkFyZSB0aGV5IHBsZWFzZSBh dmFpbGFibGUgCnNvbWV3aGVyZT88QlI+PC9GT05UPjwvUD48L0JMT0NLUVVPVEU+Cgo8L0JPRFk+ CjwvSFRNTD4= ------_=_NextPart_001_01C40115.300831D9-- From dstanley@agere.com Thu Mar 4 02:31:30 2004 From: dstanley@agere.com (Dorothy Stanley) Date: Wed, 03 Mar 2004 20:31:30 -0600 Subject: [Capwap] What about other ongoing activity at IEEE 802.11? References: <40459BAF.6010209@rd.francetelecom.fr> Message-ID: <40469502.2090008@agere.com> --------------020504080008050605090904 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Florent and all, Below is additional information on the "Wireless Network Management" WNM Study Group. The formation of this WNM study group was approved at the January IEEE 802.11 meeting, with the following purpose (per 11-04-0024-01-0wng-wng-sc-report.ppt): The proposed Study Group will evaluate the need to enable external network management entities (managed service providers, company IT personnel, hot spot providers, applications developers, etc.) to extend the management of the wired networks through to the wireless extension attached to those networks. Once evaluated, it is expected that a PAR and a 5 Criteria document will be written and submitted to the IEEE 802.11 Working Group so that a Task Group can be formed. This is a logical extension to the work now underway in Task Group "k". The SG will meet in March, to begin discussion. Document 03-0950, which you referenced, contains a list of topics which may be considered, including Channel (frequency - APs & clients) Reset the Devices Remotely Antenna Selection Load Balancing Access to Client Power Control Rogue Handling Service Handling Enable mechanisms already in dot 11 to outside entities (TGh) Client Roaming Dynamic Adaptation of clients/AP Enable Interference Mitigation All of the above with some way to do security Documents presented in the WNG SG will be posted and available (together with all other IEEE 802.11 SG and WG documents) on the http://802wirelessworld.com/index.jsp website. Your participation in the SG is welcome. Thanks, Dorothy Florent Bersani wrote: > My question after Dorothy's presentation this afternoon on the IEEE > 802/IETF liaison was: what about the Management of Wireless Device > Study Group that has been set up within .11 at the January 2004 > Vancouver IEEE 802 interim meeting (see e.g. IEEE 802 document > 11-03-0950-01-0wng-need-managed-ieee-802-11-devices.ppt)? > > We discussed this question briefly with Dorothy and she should provide > you with more insights than I can ;-) > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap -- ---------------- Dorothy Stanley Agere Systems 2000 North Naperville Rd. Naperville, IL 60566 630-979-1572 (Phone, Fax) 630-222-6753 (Cell) --------------020504080008050605090904 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Florent and all,

Below is additional information on the "Wireless Network Management" WNM
Study Group. The formation of this WNM study group was approved at the January IEEE
802.11 meeting, with the following purpose (per 11-04-0024-01-0wng-wng-sc-report.ppt):

The proposed Study Group will evaluate the need to enable external network management entities (managed service providers, company IT personnel, hot spot providers, applications developers, etc.) to extend the management of the wired networks through to the wireless extension attached to those networks. Once evaluated, it is expected that a PAR and a 5 Criteria document will be written and submitted to the IEEE 802.11 Working Group so that a Task Group can be formed. This is a logical extension to the work now underway in Task Group “k”.

The SG will meet in March, to begin discussion. Document 03-0950, which you referenced, contains a list of
topics which may be considered, including
 Channel (frequency – APs & clients)
 Reset the Devices Remotely
 Antenna Selection
 Load Balancing
 Access to Client Power Control
 Rogue Handling 
 Service Handling
 Enable mechanisms already in dot 11 to outside entities (TGh)
 Client Roaming
 Dynamic Adaptation of clients/AP
 Enable Interference Mitigation
 All of the above with some way to do security


Documents presented in the WNG SG will be posted and available (together with all
other IEEE 802.11 SG and WG documents) on the
http://802wirelessworld.com/index.jsp website.

Your participation in the SG is welcome.

Thanks,

Dorothy

Florent Bersani wrote:
My question after Dorothy's presentation this afternoon on the IEEE 802/IETF liaison was: what about the Management of Wireless Device Study Group that has been set up within .11 at the January 2004 Vancouver IEEE 802 interim meeting (see e.g. IEEE 802 document 11-03-0950-01-0wng-need-managed-ieee-802-11-devices.ppt)?

We discussed this question briefly with Dorothy and she should provide you with more insights than I can ;-)

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

-- 
----------------
Dorothy Stanley
Agere Systems
2000 North Naperville Rd. 
Naperville, IL 60566
630-979-1572 (Phone, Fax)
630-222-6753 (Cell)

--------------020504080008050605090904-- From matt.holdrege@verizon.net Thu Mar 4 04:12:16 2004 From: matt.holdrege@verizon.net (Matt Holdrege) Date: Wed, 03 Mar 2004 20:12:16 -0800 Subject: [Capwap] draft minutes Message-ID: <6.0.1.1.2.20040303201005.01e48e90@incoming.verizon.net> --=====================_42839990==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Below are the draft minutes. All mistakes are my own. Most people failed to= =20 identify themselves at the microphone so if I didn't recognize them, I put= =20 a ? in front of their comment. -Matt Holdrege matt@strixsystems.com Control and Provisioning of Wireless Access Points WG (capwap) Wednesday, March 3 at 1530-1730 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D CHAIRS: Mahalingam Mani(mmani@avaya.com) Dorothy Gellert(dorothy.gellert@nokia.com) IEEE Liaison: Dorothy Stanley (dstanley@agere.com) Technical Advisor: Bob O'Hara (bohara@airespace.com) AGENDA: Agenda Bashing: 5 min. Problem Statement Draft Presentation & Discussions: 15 minutes Architecture Design team: 15 minutes Architecture Draft Presentation: 15 minutes Summary of January IEEE 802.11 meeting: 10 minutes Upcoming IEEE 802.11 meeting: 10 minutes Current Issues list: 20 minutes Functionality Classification for CAPWAP draft: 15 minutes Open Discussions & Next Steps: 15 minutes Reading List: Capwap Problem=20 Statement:=20 Capwap=20 Architecture:=20 Functionality Classifications for CAPWAP:=20 Mailing List: List: capwap@frascone.com Subscribe: capwap-request@frascone.com Body: subscribe in Subject line Archive: Reported by Matt Holdrege Changes since IETF 58 (see slides) Any comments on last call for the problem statement Ajit? =96 questions on problem statement. What about mobility triggers?=20 Deriving the privacy function that the access point provides? Dorothy =96 we are not chartered to address mobility, but security will be= =20 addressed. Russ Housley: Need more than just one sentence on the security in the=20 problem statement. What security concerns will be addressed by solving this= =20 problem? Pat Calhoun =96 This document talks about the problems that people are= having=20 today. Russ: I=92ll think about it. ? Why are we considering 802.11? Dorothy: We are taking a small scope at this time in order to accomplish=20 something with IEEE. After this effort is complete, we can think about=20 re-chartering to take on other work besides 802.11. Mani: We are just working on 802.11 deployments to get an understanding of= =20 what the IETF and IEEE responsibilities are before we take on other=20 technologies. Dorothy: Russ will provide more info on security issues for the document. Milestones: (see slide) Rohan Mahy: This seems very optimistic. It was agreed that it is optimistic but we need to sync up with the IEEE=20 and they are being aggressive with AP definitions. Burt Wijnen: Plenty of people have signed up with the design team and the=20 IEEE has committed to review this document. There were no more comments on the milestones. Architecture taxonomy design team: (See slides) The team has 12 members and there were about 7 present in the meeting. Expert review (see slide) Lily Yang: Architecture draft. (see slides) Questions on the speculations made? Yes there were many speculations but=20 they will be addressed by the design team. Charlie: Given that each data point is encumbered by vendor implementation,= =20 it=92s going to be hard to come to consensus on each data point. Mani: Why the AP functionalities are split and why people are making the=20 choices on splits? Pat C: We should make it useful and easy for the vendors to apply their=20 solutions to the taxonomy. ? Could you be more specific on how this taxonomy relates to layer 3? Pat: What we show is that the access points can be split at layer 2 or=20 layer 3. Arvid: The proposed architecture needs to be scrutinized by the design team. Lily: This is only an input document to the design team. ? There is a danger by letting the vendors simply submit their=20 architectures to the document. Dorothy: We are only taking a market survey to make sure we understand the= =20 market. We are not changing the basis of the document. Bob O=92Hara: The design team is more of a detective team that will create a= =20 catalogue of the architectures. We will not design new architectures. Burt: The design team shall present their work to the WG via the mailing= list. ? Suggest to publish a template? The March 17th date is too aggressive to submit comments. The design team=20 will be receptive beyond that date. Dorothy Stanley IEEE status: (see slides) Burt: A good input to our document will be a list of functions that don=92t= =20 exist in the IEEE document. Hopefully the IEEE will accept these=20 definitions in their documents. And we hope that the IEEE will ask for=20 clarifications as needed. Also, the expert review is independent of the=20 call for interested parties. We need to show what is missing from the IEEE. We hear that we need a more= =20 complete definition of an AP and we need a dialogue on this. After this group concludes with taxonomy we will decide together with the=20 IETF on future steps. Maybe we need a flexible AP/AC protocol. Maybe=20 something else. From the .11 perspective there may not be a definitive architecture,=20 rather there will be many. We will work jointly IEEE/IETF to develop these= =20 architectures. Mani: Current architecture issues: (See Slides) ? Will we define policy enforcement points? Pat C: That is an 802.11 function and we won=92t address such functions. Parvid: Are we splitting the control function and bearer function? Pat C: we are defining architectures that work either way. Parvid: Is this a restriction for phase one or is the in the charter? We=20 should be cautious to not preclude future work on other technologies such=20 as CDMA or GSM, etc. James Kempf: We may take some future work in the IRTF and try to include=20 certain other IETF WG=92s. ? James said that if we look at anything other than 802.11 it should be=20 research and I totally disagree. The other link-layer technologies are the= =20 same model and we should include them here rather than relegate them to=20 research. James: Some technologies fit and others don=92t. ? 1X and .16 give us the same architecture. James: The difficulties are in the details. Pat: Where do you draw the line? There are a lot of radio protocols out=20 there and we can=92t take them all on. Dorothy: Our charter is focused on 802.11 only. Burt: We have fully discussed this on the mailing list and we have to focus= =20 on 802.11 for now. You are free to write a similar taxonomy document for=20 other radio technologies and compare them to what this group does. Indpreet Singh: Why can=92t the AP have bindings with multiple AC=92s? Pat: We should include this capability for fast-failover Dorothy: These comments were from previous work and they are simply input=20 points for our work. The architecture draft is limited to what is in the=20 charter. The problem statement does not exclude other architectures such as= =20 autonomous AP=92s. Hong Cheng: Capwap functional classifications: (see slides) Bob: What options need to be negotiated on each end. If we have too many=20 options on both sides won=92t that impede interoperability. Cheng: Some functions cannot be split, but there are a limited set of=20 functions that can be split and we need to declare them. Bob: If I want to develop an AP don=92t I need to implement all the optional= =20 functions? Lily: The AC should implement everything and the AP can make the choice of= =20 what to implement. Saravanan Govindan: You don=92t need to implement everything. We just want a= =20 list of classifications such as what we have in the draft. Parvid: Is there a requirement for backward compatibility. Dorothy: There is no requirement at this time. --=====================_42839990==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Below are the draft minutes. All mistakes are my own. Most people failed to identify themselves at the microphone so if I didn't recognize them, I put a ? in front of their comment.

-Matt Holdrege       &nbs= p;  matt@strixsystems.com


Control and Provisioning of Wireless Access Points WG (capwap)

 

Wednesday, March 3 at 1530-1730

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D

 

CHAIRS: Mahalingam Mani(mmani@avaya.com)

        Dorothy
Gellert(dorothy.gellert@nokia.com)

 

IEEE Liaison: Dorothy Stanley (dstanley@agere.com)

Technical Advisor: Bob O'Hara (bohara@airespace.com)

 

 

AGENDA:

 

Agenda
Bashing:           &n=
bsp;            =
            &nbs=
p;  
5 min.

 

Problem Statement Draft Presentation & Discussions:   15
minutes=20

 

Architecture Design
team:            =
;            &nb=
sp;   
15 minutes

 

Architecture Draft
Presentation:          &nb=
sp;          
15  minutes

 

Summary of January IEEE 802.11
meeting:           &n=
bsp;  
10 minutes

 

Upcoming IEEE 802.11
meeting:           &n=
bsp;            
10 minutes

 

Current Issues
list:            =
;            &nb=
sp;        
20 minutes

 

Functionality Classification for CAPWAP
draft:        15 minutes=20

 

Open Discussions & Next
Steps:           &nbs=
p;           
15 minutes

 

 

Reading List:

 

Capwap Problem Statement: 
<http://www.ietf.org/internet-drafts/draft-ietf-capwap-pr=
oblem-statement-00.txt>

Capwap Architecture: 
<http://www.ietf.org/internet-drafts/draft-ietf-capwap-ar=
ch-00.txt>

Functionality Classifications for CAPWAP:
<http://www.ietf.org/internet-drafts/draft-cheng-capwap-c=
lassifications-00.txt>

 

 

Mailing List:

 

List:            =
;  
capwap@frascone.com

Subscribe:         
capwap-request@frascone.com

Body:            =
;  
subscribe in Subject line

Archive:           
<http://mail.frascone.com/pipermail/public/capwap/>=
;

Reported by Matt Holdrege   <matt@strixsystems.com>
 
Changes since IETF 58 (see slides)
Any comments on last call for the problem statement
Ajit? =96 questions on problem statement. What about mobility triggers? Deriving the privacy function that the access point provides?
Dorothy =96 we are not chartered to address mobility, but security will be addressed.
 
Russ Housley: Need more than just one sentence on the security in the problem statement. What security concerns will be addressed by solving this problem?
 
Pat Calhoun =96 This document talks about the problems that people are having today.
 
Russ:  I=92ll think about it.
 
? Why are we considering 802.11?
 
Dorothy: We are taking a small scope at this time in order to accomplish something with IEEE. After this effort is complete, we can think about re-chartering to take on other work besides 802.11.
 
Mani: We are just working on 802.11 deployments to  get an understanding of what the IETF and IEEE responsibilities are before we take on other technologies.
 
Dorothy: Russ will provide more info on security issues for the document.
 
Milestones: (see slide)
 
Rohan Mahy: This seems very optimistic.
 
It was agreed that it is optimistic but we need to sync up with the IEEE and they are being aggressive with AP definitions.
 
Burt Wijnen: Plenty of people have signed up with the design team and the IEEE has committed to review this document.
 
There were no more comments on the milestones.
 
Architecture taxonomy design team: (See slides)
 
The team has 12 members and there were about 7 present in the meeting.
 
Expert review (see slide)
 
Lily Yang: Architecture draft. (see slides)
 
Questions on the speculations made? Yes there were many speculations but they will be addressed by the design team.
 
Charlie: Given that each data point is encumbered by vendor implementation, it=92s going to be hard to come to consensus on each data point.
 
Mani: Why the AP functionalities are split and why people are making the choices on splits?
 
Pat C: We should make it useful and easy for the vendors to apply their solutions to the taxonomy.
 
? Could you be more specific on how this taxonomy relates to layer 3?
 
Pat: What we show is that the access points can be split at layer 2 or layer 3.
 
Arvid: The proposed architecture needs to be scrutinized by the design team.
 
Lily: This is only an input document to the design team.
 
? There is a danger by letting the vendors simply submit their architectures to the document.
 
Dorothy: We are only taking a market survey to make sure we understand the market. We are not changing the basis of the document.
 
Bob O=92Hara: The design team is more of a detective team that will create a catalogue of the architectures. We will not design new architectures.
 
Burt: The design team shall present their work to the WG via the mailing list.
 
? Suggest to publish a template?
 
The March 17th date is too aggressive to submit comments. The design team will be receptive beyond that date.
 
Dorothy Stanley IEEE status:  (see slides)
 
Burt: A good input to our document will be a list of functions that don=92t exist in the IEEE document. Hopefully the IEEE will accept these definitions in their documents. And we hope that the IEEE will ask for clarifications as needed. Also, the expert review is independent of the call for interested parties.
 
We need to show what is missing from the IEEE. We hear that we need a more complete definition of an AP and we need a dialogue on this.
 
After this group concludes with taxonomy we will decide together with the IETF on future steps. Maybe we need a flexible AP/AC protocol. Maybe something else.
 
From the .11 perspective there may not be a definitive architecture, rather there will be many. We will work jointly IEEE/IETF to develop these architectures.
 
Mani: Current architecture issues: (See Slides)
 
? Will we define policy enforcement points?
 
Pat C: That is an 802.11 function and we won=92t address such functions.
 
Parvid:  Are we splitting the control function and bearer function?
 
Pat C: we are defining architectures that work either way.
 
Parvid: Is this a restriction for phase one or is the in the charter? We should be cautious to not preclude future work on other technologies such as CDMA or GSM, etc.
 
James Kempf: We may take some future work in the IRTF and try to include certain other IETF WG=92s.
 
? James said that if we look at anything other than 802.11 it should be research and I totally disagree. The other link-layer technologies are the same model and we should include them here rather than relegate them to research.
 
James: Some technologies fit and others don=92t.
 
? 1X and .16 give us the same architecture.
 
James: The difficulties are in the details.
 
Pat: Where do you draw the line? There are a lot of radio protocols out there and we can=92t take them all on.
 
Dorothy: Our charter is focused on 802.11 only.
 
Burt: We have fully discussed this on the mailing list and we have to focus on 802.11 for now. You are free to write a similar taxonomy document for other radio technologies and compare them to what this group does.
 
Indpreet Singh: Why can=92t the AP have bindings with multiple AC=92s?
 
Pat: We should include this capability for fast-failover
 
Dorothy: These comments were from previous work and they are simply input points for our work. The architecture draft is limited to what is in the charter. The problem statement does not exclude other architectures such as autonomous AP=92s.
 
Hong Cheng: Capwap functional classifications: (see slides)
 
Bob: What options need to be negotiated on each end. If we have too many options on both sides won=92t that impede interoperability.
 
Cheng: Some functions cannot be split, but there are a limited set of functions that can be split and we need to declare them.
 
Bob: If I want to develop an AP don=92t I need to implement all the optional functions?
 
Lily: The AC should implement everything and the AP can make the choice of what to implement.
 
Saravanan Govindan: You don=92t need to implement everything. We just want a list of classifications such as what we have in the draft.
 
Parvid: Is there a requirement for backward compatibility.
 
Dorothy: There is no requirement at this time.
 
 

--=====================_42839990==.ALT-- From cchaplin@sj.symbol.com Thu Mar 4 17:56:26 2004 From: cchaplin@sj.symbol.com (Clint Chaplin) Date: Thu, 04 Mar 2004 09:56:26 -0800 Subject: [Capwap] draft minutes Message-ID: It is unclear from the minutes which Dorothy was speaking..... Clint (JOATMON) Chaplin >>> Matt Holdrege 3/3/04 20:12:16 >>> Below are the draft minutes. All mistakes are my own. Most people failed = to=20 identify themselves at the microphone so if I didn't recognize them, I = put=20 a ? in front of their comment. -Matt Holdrege matt@strixsystems.com=20 Control and Provisioning of Wireless Access Points WG (capwap) Wednesday, March 3 at 1530-1730 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D CHAIRS: Mahalingam Mani(mmani@avaya.com) Dorothy Gellert(dorothy.gellert@nokia.com) IEEE Liaison: Dorothy Stanley (dstanley@agere.com) Technical Advisor: Bob O'Hara (bohara@airespace.com) AGENDA: Agenda Bashing: 5 min. Problem Statement Draft Presentation & Discussions: 15 minutes Architecture Design team: 15 minutes Architecture Draft Presentation: 15 minutes Summary of January IEEE 802.11 meeting: 10 minutes Upcoming IEEE 802.11 meeting: 10 minutes Current Issues list: 20 minutes Functionality Classification for CAPWAP draft: 15 minutes Open Discussions & Next Steps: 15 minutes Reading List: Capwap Problem=20 Statement:=20 Capwap=20 Architecture:=20 Functionality Classifications for CAPWAP:=20 Mailing List: List: capwap@frascone.com=20 Subscribe: capwap-request@frascone.com=20 Body: subscribe in Subject line Archive: Reported by Matt Holdrege Changes since IETF 58 (see slides) Any comments on last call for the problem statement Ajit? =96 questions on problem statement. What about mobility triggers?=20 Deriving the privacy function that the access point provides? Dorothy =96 we are not chartered to address mobility, but security will = be=20 addressed. Russ Housley: Need more than just one sentence on the security in the=20 problem statement. What security concerns will be addressed by solving = this=20 problem? Pat Calhoun =96 This document talks about the problems that people are = having=20 today. Russ: I=92ll think about it. ? Why are we considering 802.11? Dorothy: We are taking a small scope at this time in order to accomplish=20= something with IEEE. After this effort is complete, we can think about=20 re-chartering to take on other work besides 802.11. Mani: We are just working on 802.11 deployments to get an understanding = of=20 what the IETF and IEEE responsibilities are before we take on other=20 technologies. Dorothy: Russ will provide more info on security issues for the document. Milestones: (see slide) Rohan Mahy: This seems very optimistic. It was agreed that it is optimistic but we need to sync up with the = IEEE=20 and they are being aggressive with AP definitions. Burt Wijnen: Plenty of people have signed up with the design team and = the=20 IEEE has committed to review this document. There were no more comments on the milestones. Architecture taxonomy design team: (See slides) The team has 12 members and there were about 7 present in the meeting. Expert review (see slide) Lily Yang: Architecture draft. (see slides) Questions on the speculations made? Yes there were many speculations = but=20 they will be addressed by the design team. Charlie: Given that each data point is encumbered by vendor implementation,= =20 it=92s going to be hard to come to consensus on each data point. Mani: Why the AP functionalities are split and why people are making = the=20 choices on splits? Pat C: We should make it useful and easy for the vendors to apply their=20 solutions to the taxonomy. ? Could you be more specific on how this taxonomy relates to layer 3? Pat: What we show is that the access points can be split at layer 2 or=20 layer 3. Arvid: The proposed architecture needs to be scrutinized by the design = team. Lily: This is only an input document to the design team. ? There is a danger by letting the vendors simply submit their=20 architectures to the document. Dorothy: We are only taking a market survey to make sure we understand = the=20 market. We are not changing the basis of the document. Bob O=92Hara: The design team is more of a detective team that will create = a=20 catalogue of the architectures. We will not design new architectures. Burt: The design team shall present their work to the WG via the mailing = list. ? Suggest to publish a template? The March 17th date is too aggressive to submit comments. The design = team=20 will be receptive beyond that date. Dorothy Stanley IEEE status: (see slides) Burt: A good input to our document will be a list of functions that = don=92t=20 exist in the IEEE document. Hopefully the IEEE will accept these=20 definitions in their documents. And we hope that the IEEE will ask for=20 clarifications as needed. Also, the expert review is independent of the=20 call for interested parties. We need to show what is missing from the IEEE. We hear that we need a = more=20 complete definition of an AP and we need a dialogue on this. After this group concludes with taxonomy we will decide together with = the=20 IETF on future steps. Maybe we need a flexible AP/AC protocol. Maybe=20 something else. From the .11 perspective there may not be a definitive architecture,=20 rather there will be many. We will work jointly IEEE/IETF to develop = these=20 architectures. Mani: Current architecture issues: (See Slides) ? Will we define policy enforcement points? Pat C: That is an 802.11 function and we won=92t address such functions. Parvid: Are we splitting the control function and bearer function? Pat C: we are defining architectures that work either way. Parvid: Is this a restriction for phase one or is the in the charter? = We=20 should be cautious to not preclude future work on other technologies = such=20 as CDMA or GSM, etc. James Kempf: We may take some future work in the IRTF and try to include=20= certain other IETF WG=92s. ? James said that if we look at anything other than 802.11 it should be=20 research and I totally disagree. The other link-layer technologies are = the=20 same model and we should include them here rather than relegate them to=20 research. James: Some technologies fit and others don=92t. ? 1X and .16 give us the same architecture. James: The difficulties are in the details. Pat: Where do you draw the line? There are a lot of radio protocols out=20 there and we can=92t take them all on. Dorothy: Our charter is focused on 802.11 only. Burt: We have fully discussed this on the mailing list and we have to = focus=20 on 802.11 for now. You are free to write a similar taxonomy document = for=20 other radio technologies and compare them to what this group does. Indpreet Singh: Why can=92t the AP have bindings with multiple AC=92s? Pat: We should include this capability for fast-failover Dorothy: These comments were from previous work and they are simply = input=20 points for our work. The architecture draft is limited to what is in = the=20 charter. The problem statement does not exclude other architectures such = as=20 autonomous AP=92s. Hong Cheng: Capwap functional classifications: (see slides) Bob: What options need to be negotiated on each end. If we have too = many=20 options on both sides won=92t that impede interoperability. Cheng: Some functions cannot be split, but there are a limited set of=20 functions that can be split and we need to declare them. Bob: If I want to develop an AP don=92t I need to implement all the = optional=20 functions? Lily: The AC should implement everything and the AP can make the choice = of=20 what to implement. Saravanan Govindan: You don=92t need to implement everything. We just want = a=20 list of classifications such as what we have in the draft. Parvid: Is there a requirement for backward compatibility. Dorothy: There is no requirement at this time. ________________________________________________________________________ This email has been scanned for computer viruses. From mmani@avaya.com Thu Mar 4 22:04:37 2004 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Thu, 4 Mar 2004 15:04:37 -0700 Subject: [Capwap] draft minutes Message-ID: Clint, I have clarified this way for now. we will fix the final submission to IETF proceedings in the full minutes. Thanks for pointing out. -mani [...] > Changes since IETF 58 (see slides) > Any comments on last call for the problem statement > Ajit? - questions on problem statement. What about mobility triggers? > Deriving the privacy function that the access point provides? > Dorothy Gellert - we are not chartered to address mobility, but security will be > addressed. >=20 [...]=20 > Dorothy G: We are taking a small scope at this time in order to accomplish > something with IEEE. After this effort is complete, we can think about > re-chartering to take on other work besides 802.11. >=20 > Mani: We are just working on 802.11 deployments to get an understanding > of > what the IETF and IEEE responsibilities are before we take on other > technologies. >=20 > Dorothy G: Russ will provide more info on security issues for the document. >=20 [...] >=20 > Lily: This is only an input document to the design team. >=20 > ? There is a danger by letting the vendors simply submit their > architectures to the document. >=20 > Dorothy G: We are only taking a market survey to make sure we understand the > market. We are not changing the basis of the document. >=20 > Bob O'Hara: The design team is more of a detective team that will create a > catalogue of the architectures. We will not design new architectures. >=20 > Burt: The design team shall present their work to the WG via the mailing > list. >=20 > ? Suggest to publish a template? >=20 > The March 17th date is too aggressive to submit comments. The design team > will be receptive beyond that date. >=20 > Dorothy Stanley IEEE status: (see slides) >=20 [...] > Pat: Where do you draw the line? There are a lot of radio protocols out > there and we can't take them all on. >=20 > Dorothy G: Our charter is focused on 802.11 only. >=20 > Burt: We have fully discussed this on the mailing list and we have to > focus > on 802.11 for now. You are free to write a similar taxonomy document for > other radio technologies and compare them to what this group does. >=20 > Indpreet Singh: Why can't the AP have bindings with multiple AC's? >=20 > Pat: We should include this capability for fast-failover >=20 > Dorothy G: These comments were from previous work and they are simply input > points for our work. The architecture draft is limited to what is in the > charter. The problem statement does not exclude other architectures such > as > autonomous AP's. >=20 > Hong Cheng: Capwap functional classifications: (see slides) >=20 [...] >=20 > Dorothy G: There is no requirement at this time. >=20 >=20 >=20 >=20 > ________________________________________________________________________ > This email has been scanned for computer viruses. > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap From mmani@avaya.com Thu Mar 4 22:16:14 2004 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Thu, 4 Mar 2004 15:16:14 -0700 Subject: [Capwap] IETF59 session presentation materials. Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C40236.4EBBA341 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable The materials are now posted in www.capwap.org . (www.capwap.org/ietf59). They are still in Powerpoint format. When submitted to IETF (as part of IETF59 proceedings) - they will be available in html form. =20 -mani =20 ------_=_NextPart_001_01C40236.4EBBA341 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

The materials are now posted in www.capwap.org. (www.capwap.org/ietf59). They = are still in Powerpoint format. When submitted to IETF (as part of IETF59 = proceedings) – they will be available in html form.

 

-mani

 

------_=_NextPart_001_01C40236.4EBBA341-- From mmani@avaya.com Mon Mar 8 18:15:47 2004 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Mon, 8 Mar 2004 11:15:47 -0700 Subject: [Capwap] CAPWAP arch draft: Design Team Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C40539.615BB64C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 The Seoul meeting concluded with, among other things, a consensus on design team (proposed earlier on the list). The purpose of the design team is to facilitate a broad capture of prevalent architectures as part of the taxonomy effort. To quote from Dorothy's related proposal for DT: =20 > The mission statement for the design team is to deliver an > architecture taxonomy draft according to the CAPWAP Charter: > The network architecture taxonomy will: > - Describe the current set of approaches (including the > traditional autonomous AP architecture) to partitioning > 802.11 access network functionality between network > entities, > - List what the interfaces between the network entities > are in each approach, > - At a functional level, describe what the protocols on > the interfaces between the network entities in each > approach do, > - Describe the advantages and disadvantages of each > approach for scalable 802.11 access network deployment > and management. > - contain a threat analysis that describes the security=20 > threats involved in each > network architectural approach. >=20 =20 This will be used to build on the architecture draft and to help identify AP functions and the way they are (not) balanced in APs and monitored, provisioned, controlled and managed. =20 The constitution of the team has been listed and can be found in the CAPWAP presentation posted: http://www.capwap.org/ietf59/capwap-ietf59-chairs.ppt =20 To facilitate consistency and expedite the taxonomy sections - it was suggested to frame a template for the Design Team Members to describe from their perspectives. Lily Yang, leading the DT, will be sending it to the list for comments. Lily will also summarize the mode of operation of the DT (including DT mailing list archive - which are viewable by all). =20 Regards, -Mani & DorothyG ------_=_NextPart_001_01C40539.615BB64C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

The Seoul meeting = concluded with, among other things, a consensus on design team (proposed earlier = on the list). The purpose of the design team is to facilitate a broad capture = of prevalent architectures as part of the taxonomy effort.

To quote from Dorothy’s related proposal for = DT:

 

> The mission = statement for the design team is to deliver an

> architecture = taxonomy draft according to the CAPWAP Charter:

> The network architecture taxonomy will:

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

> =     traditional autonomous AP architecture) to partitioning

> =     802.11 access network functionality between network

> =     entities,

> =     - List what the interfaces between the network entities

> =     are in each approach,

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

> =     the interfaces between the network entities in each

> =     approach do,

> =     - Describe the advantages and disadvantages of each

> =     approach for scalable 802.11 access network deployment

> =     and management.

> =     - contain a threat analysis that describes the security

> threats = involved in each

> =     network architectural approach.

> =

 

This will be used to build on the architecture draft = and to help identify AP functions and the way they are (not) balanced in APs = and monitored, provisioned, controlled and managed.

 

The constitution of the team has been listed and can = be found in the CAPWAP presentation posted:

http://www= .capwap.org/ietf59/capwap-ietf59-chairs.ppt

 

To facilitate consistency and expedite the taxonomy = sections – it was suggested to frame a template for the Design = Team

Members to describe from their perspectives. Lily = Yang, leading the DT, will be sending it to the list for comments. Lily will also = summarize the mode of operation of the DT (including DT mailing list archive = – which are viewable by all).

 

Regards,

-Mani & DorothyG

------_=_NextPart_001_01C40539.615BB64C-- From lily.l.yang@intel.com Mon Mar 8 20:00:42 2004 From: lily.l.yang@intel.com (Yang, Lily L) Date: Mon, 8 Mar 2004 12:00:42 -0800 Subject: [Capwap] CAPWAP arch draft: Design Team Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE0A452B@orsmsx408.jf.intel.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C40548.09756CC4 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C40548.09756CC4" ------_=_NextPart_002_01C40548.09756CC4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, everyone - =20 Attached you will see a simple template that you can use to submit a brief (1-2 page long) text file that describes some key points in the particular WLAN architecture that you have developed or deployed (as a vendor or service provider, or as a research project - please also indicate of which you are submitting). The text description can be sent to me and the chairs directly, or to the list. Due to the short timeline the CAPWAP group is chartered to do its work, we request that you submit the text no later than March 24, 2004. The design team would use these data as input to the taxonomy document that we will start working on very soon. =20 The design team has its own mailing list now and all the discussions would be archived and accessible to the WG.=20 =20 General information about the mailing list is at: =20 http://mail.frascone.com/mailman/listinfo/capwap-dt =20 You are welcome to check it out. We will be having our first design team meeting (via teleconference) this Wed. I will report out the meeting minutes to the WG mailing list after the meeting. =20 Thank you all for your attention, =20 Lily =20 =20 =20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Mani, Mahalingam (Mahalingam) Sent: Monday, March 08, 2004 10:16 AM To: capwap@frascone.com Subject: [Capwap] CAPWAP arch draft: Design Team =20 All, =20 The Seoul meeting concluded with, among other things, a consensus on design team (proposed earlier on the list). The purpose of the design team is to facilitate a broad capture of prevalent architectures as part of the taxonomy effort. To quote from Dorothy's related proposal for DT: =20 > The mission statement for the design team is to deliver an > architecture taxonomy draft according to the CAPWAP Charter: > The network architecture taxonomy will: > - Describe the current set of approaches (including the > traditional autonomous AP architecture) to partitioning > 802.11 access network functionality between network > entities, > - List what the interfaces between the network entities > are in each approach, > - At a functional level, describe what the protocols on > the interfaces between the network entities in each > approach do, > - Describe the advantages and disadvantages of each > approach for scalable 802.11 access network deployment > and management. > - contain a threat analysis that describes the security=20 > threats involved in each > network architectural approach. >=20 =20 This will be used to build on the architecture draft and to help identify AP functions and the way they are (not) balanced in APs and monitored, provisioned, controlled and managed. =20 The constitution of the team has been listed and can be found in the CAPWAP presentation posted: http://www.capwap.org/ietf59/capwap-ietf59-chairs.ppt =20 To facilitate consistency and expedite the taxonomy sections - it was suggested to frame a template for the Design Team Members to describe from their perspectives. Lily Yang, leading the DT, will be sending it to the list for comments. Lily will also summarize the mode of operation of the DT (including DT mailing list archive - which are viewable by all). =20 Regards, -Mani & DorothyG ------_=_NextPart_002_01C40548.09756CC4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, everyone = –

 

Attached you will see a simple = template that you can use to submit a brief (1-2 page long) text file that = describes some key points in the particular WLAN architecture that you have = developed or deployed (as a vendor or service provider, or as a research project = – please also indicate of which you are submitting). The text description = can be sent to me and the chairs directly, or to the list. Due to the short = timeline the CAPWAP group is chartered to do its work, we request that you submit = the text no later than March 24, = 2004. The design team would use these data as input to the = taxonomy document that we will start working on very soon.

 

The design team has its own mailing list now and all the discussions would = be archived and accessible to the WG.

 

General information about = the mailing list is at:

 

  http://mail.= frascone.com/mailman/listinfo/capwap-dt

 

You are welcome to check it = out. We will be having our first design team meeting (via teleconference) this = Wed. I will report out the meeting minutes to the WG mailing list after the = meeting.

 

Thank you all for your = attention,

 

Lily

 

 

 

-----Original = Message-----
From: = capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Mani, Mahalingam (Mahalingam)
Sent:
Monday, March 08, 2004 10:16 = AM
To: = capwap@frascone.com
Subject: [Capwap] CAPWAP = arch draft: Design Team

 

All,

 

The Seoul meeting concluded with, among other things, a consensus on design team (proposed earlier on the list). The purpose of the design team is to facilitate a = broad capture of prevalent architectures as part of the taxonomy = effort.

To quote from = Dorothy’s related proposal for DT:

 

> The mission statement for the design team is to deliver = an

> architecture taxonomy draft according to the CAPWAP = Charter:

> The network architecture taxonomy will:

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

>     traditional autonomous AP architecture) to = partitioning

>     802.11 access network functionality between = network

>     entities,

>     - List what the interfaces between the network = entities

>     are in each approach,

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

>     the interfaces between the network entities in = each

>     approach do,

>     - Describe the advantages and disadvantages of = each

>     approach for scalable 802.11 access network = deployment

>     and management.

>     - contain a threat analysis that describes the = security

> threats involved in each

>     network architectural approach.

>

 

This will be used to build = on the architecture draft and to help identify AP functions and the way they = are (not) balanced in APs and monitored, provisioned, controlled and = managed.

 

The constitution of the = team has been listed and can be found in the CAPWAP presentation = posted:

http://www= .capwap.org/ietf59/capwap-ietf59-chairs.ppt

 

To facilitate consistency = and expedite the taxonomy sections – it was suggested to frame a = template for the Design Team

Members to describe from = their perspectives. Lily Yang, leading the DT, will be sending it to the list = for comments. Lily will also summarize the mode of operation of the DT = (including DT mailing list archive – which are viewable by = all).

 

Regards,

-Mani & = DorothyG

=00 ------_=_NextPart_002_01C40548.09756CC4-- ------_=_NextPart_001_01C40548.09756CC4 Content-Type: text/plain; name="CAPWAP_arch_template.txt" Content-Transfer-Encoding: base64 Content-Description: CAPWAP_arch_template.txt Content-Disposition: attachment; filename="CAPWAP_arch_template.txt" Tm90ZToNClBsZWFzZSB3cml0ZSB5b3VyIGNvbnRyaWJ1dGlvbiBpbiBhIHRleHQgZmlsZSwgYW5k IGxpbWl0IGl0IHRvIHR3byBwYWdlcyBhdCBtb3N0LiAgDQpQbGVhc2Ugc2VuZCB5b3VyIGNvbnRy aWJ1dGlvbiB0byB0aGUgZm9sbG93aW5nIGJ5IE1hcmNoIDI0LCAyMDA0Og0KTGlseSBZYW5nIChs aWx5LmwueWFuZ0BpbnRlbC5jb20pOiBkZXNpZ24gdGVhbSBlZGl0b3INCk1hbmksIE1haGFsaW5n YW0gKG1tYW5pQGF2YXlhLmNvbSk6IFdHIGNvLWNoYWlyDQpEb3JvdGh5IEdlbGxlcnQgKERvcm90 aHkuR2VsbGVydEBub2tpYS5jb20pOiBXRyBjby1jaGFpcg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0gdGVtcGxhdGUgc3RhcnRzIGhlcmUgLS0tLS0tLS0tLS0tLS0tLQ0KDQpjb250 cmlidXRpb24gdGVtcGxhdGUgZm9yIFdMQU4gYXJjaGl0ZWN0dXJlIHN1cnZleSANCg0KKDEpIERl c2lnbiBjb25zaWRlcmF0aW9ucyAmIHJlcXVpcmVtZW50czogDQoNCnBsZWFzZSBicmllZmx5IGRl c2NyaWJlIHlvdXIgZGVzaWduIHByaW5jaXBsZXMgZm9yIHRoaXMgYXJjaGl0ZWN0dXJlLg0KDQoo MikgV0xBTiBmdW5jdGlvbnMgc3VwcG9ydGVkOg0KDQpQbGVhc2UgbGlzdCB0aGUgZnVuY3Rpb25z IHN1cHBvcnRlZCBpbiB0aGlzIFdMQU4gYnJpZWZseSwgYnV0IHBsZWFzZSBkbyBub3Qgc2VuZCB1 cyB0aGUgZW50aXJlIGRhdGEgc2hlZXQuIA0KRXhhbXBsZXMgb2YgV0xBTiBmdW5jdGlvbnMgaW5j bHVkZXMgdGhlIFNUQSBzZXJ2aWNlcywgRGlzdHJpYnV0ZWQgU3lzdGVtIFNlcnZpY2VzIChhcyBk ZWZpbmVkIGJ5IDgwMi4xMSksIA0KcmFkaW8gcmVzb3VyY2UgbWFuYWdlbWVudCBhbmQgY29udHJv bCwgQVAgbG9hZCBiYWxhbmNpbmcsIG1vYmlsaXR5IHN1cHBvcnQsIFdMQU4gbmV0d29yayB3aWRl IHNlY3VyaXR5IGZ1bmN0aW9ucyANCihpbmNsdWRpbmcgYXV0aGVudGljYXRpb24sIGVuY3J5cHRp b24gZm9yIHByaXZhY3kgYW5kIGludGVncml0eSwgZXRjLikgYW5kIGFueSBvdGhlcnMgbm90IGxp c3RlZCBoZXJlIGJ1dCBkZWVtZWQgDQppbXBvcnRhbnQgaW4geW91ciBkZXNpZ24uDQoNCigzKSBU aGUgZnVuY3Rpb25hbCBhcmNoaXRlY3R1cmUgdG8gaW1wbGVtZW50IHRoZSBmdW5jdGlvbnMgZGVz Y3JpYmVkIGFib3ZlOiB3aGV0aGVyIGl0IGlzIGJ5IGF1dG9ub21vdXMgQVANCmFyY2hpdGVjdHVy ZSwgb3IgInNwbGl0IiBhcmNoaXRlY3R1cmUuIEZvciBzcGxpdCBhcmNoaXRlY3R1cmUsIHBsZWFz ZSBwcm92aWRlIHRoZSBmdW5jdGlvbmFsIG1hcHBpbmcgDQpvZiBXTEFOIGZ1bmN0aW9ucyBvbnRv IHRoZSBBUCBhbmQgQUMgLS0gd2l0aCBqdXN0IGVub3VnaCBkZXRhaWxzIHRoYXQgaGVscCB1cyB1 bmRlcnN0YW5kIHRoZSBraW5kcyBvZiBmdW5jdGlvbmFsDQppbnRlcmZhY2UgbmVjZXNzYXJ5IGJl dHdlZW4gdGhlIHR3by4NCg0KKDQpIFRoZSBwcm90b2NvbCB1c2VkIGluIGJldHdlZW4gQVAgYW5k IEFDLiANCg0KKDUpIFRoZSB0b3BvbG9naWNhbCBhc3N1bXB0aW9ucyBiZXR3ZWVuIEFQIGFuZCBB QyAoaXMgaXQgZGlyZWN0bHkgY29ubmVjdGVkLCBMMiBzd2l0Y2hlZCwgDQpvciBMMyByb3V0ZWQ/ KSAtLSB0aGlzIGFsc28gaGVscHMgdXMgdG8gdW5kZXJzdGFuZCB0aGUgZGVwbG95bWVudCBzY2Vu YXJpb3MuDQoNCig2KSBTZWN1cml0eSB0aHJlYXQgYW5hbHlzaXM6IHdoYXQga2luZHMgb2YgdGhy ZWF0IGludHJvZHVjZWQgYnkgdGhlIHNwbGl0IGFyY2hpdGVjdHVyZSwNCmFuZCBob3cgdGhhdCBh cmUgYWRkcmVzc2VkLg0KDQooNykgUHJvcyBhbmQgQ29ucyBvZiB0aGlzIGFyY2hpdGVjdHVyZSwg ZXNwLiBpbiByZWxhdGlvbiB0byB0aGUgZm91ciBwcm9ibGVtcyBkZXNjcmliZWQgaW4gdGhlIENB UFdBUA0KcHJvYmxlbSBzdGF0ZW1lbnQuIFBsZWFzZSBrZWVwIHRoZSBhbmFseXNpcyBhdCB0ZWNo bmljYWwgaW5zdGVhZCBvZiBtYXJrZXRpbmcgbGV2ZWwuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSB0ZW1wbGF0ZSBlbmRzIGhlcmUgLS0tLS0tLS0tLS0tLS0tLQ0K ------_=_NextPart_001_01C40548.09756CC4-- From mmani@avaya.com Mon Mar 8 22:32:46 2004 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Mon, 8 Mar 2004 15:32:46 -0700 Subject: [Capwap] Followup: CAPWAP arch draft: Design Team Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C4055D.47B952FC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The DT mailing list membership is to facilitate design team activities. This list archive is open to all for review - using the following URL: http://mail.frascone.com/pipermail/capwap-dt/ =20 -mani ------_=_NextPart_001_01C4055D.47B952FC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The DT mailing list membership is = to facilitate design team activities. This list archive is open to all for = review - using the following URL:

http://mail.frasco= ne.com/pipermail/capwap-dt/

 

-mani

------_=_NextPart_001_01C4055D.47B952FC-- From mmani@avaya.com Wed Mar 10 01:34:06 2004 From: mmani@avaya.com (Mani, Mahalingam (Mahalingam)) Date: Tue, 9 Mar 2004 18:34:06 -0700 Subject: [Capwap] RE: kicking off CAPWAP design team Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C4063F.C71A8E48 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a few observations that may help staying on course: =20 For sure - if an AP architecture does not offer interfaces to provide or facilitate AP-AC style management we document them as such - per the same charter requirement of doing justice to the taxonomy analysis. That such class of candidate arch. put themselves out of court may be documented when summarizing on them. Again - that's merely informational given the current charter. =20 Conversely - If a 'traditional' AP - as Peyush suggested - offers interfaces over 'traditional' APs (given the fact APs' firmware may be upgraded) to facilitate such management - then that becomes an inclusive category of candidates for multivendor Interoperability considerations =20 If you have better text to articulate the intent of the charter - feel free. =20 Also inline... =20 -mani -----Original Message----- From: Parviz Yegani [mailto:pyegani@cisco.com]=20 Sent: Tuesday, March 09, 2004 5:01 PM To: Dorothy.Gellert@nokia.com; lily.l.yang@intel.com; VLin@extremenetworks.com; bohara@airespace.com; isingh@chantrynetworks.com; jmurphy@trapezenetworks.com; matt.holdrege@verizon.net; partha@arubanetworks.com; peyush.agarwal@st.com; Sadot, Emek (Emek); dhetheri@rovingplanet.com; pzerfos@CS.UCLA.EDU; capwap@frascone.com Cc: Mani, Mahalingam (Mahalingam) Subject: RE: kicking off CAPWAP design team =20 At 09:36 AM 3/9/2004 -0800, Dorothy.Gellert@nokia.com wrote: Hi Parviz- =20 Lily's definition is correct and should be something you are familar with. You also have the wrong charter. What you list was from the BOF, and has been replaced. The new charter is at: http://www.ietf.org/html.charters/capwap-charter.html. No, I don't have the wrong charter. The highlighted text in my previous email (appended below) was taken from the problem statement draft which is part of the current charter. So, the question I raised is still valid. -Parviz =20 I'm posting this response to the mailing list to make sure others are aware that the charter has been updated since the BOF last year. =20 Thanks, Dorothy =20 -----Original Message-----=20 From: ext Parviz Yegani [mailto:pyegani@cisco.com]=20 Sent: Tuesday, March 09, 2004 1:23 AM=20 To: Yang, Lily L; Gellert Dorothy (Nokia-ES/MtView); VLin@extremenetworks.com; bohara@airespace.com; isingh@chantrynetworks.com; jmurphy@trapezenetworks.com; matt.holdrege@verizon.net; partha@arubanetworks.com; peyush.agarwal@st.com; esadot@avaya.com; dhetheri@rovingplanet.com; pzerfos@CS.UCLA.EDU=20 Cc: mmani@avaya.com=20 Subject: RE: kicking off CAPWAP design team At 11:17 PM 3/8/2004 -0800, Yang, Lily L wrote: This is the conventional WLAN architecture where each AP is self-contained without any infrastructure support so there is no AC in such architecture. Or you can say, the AP itself is AC as well.=20 Ok. In this conventional WLAN architecture (fat AP model) the AP-AC interface is not exposed, therefore, there is no need=20 [Mani, Mahalingam (Mahalingam)] not a question of no need. This class of devices is not a candidate for that. As part of the DT effort - we should focus on categorizing as such and move on. That may not preclude instances of to develop a protocol in IETF for that. Right? If so, then how would this help solve inter-operability problem=20 [Mani, Mahalingam (Mahalingam)] it does not. between multi-=20 vendor equipment as claimed by the WG charter (see highlighted text below)? [Mani, Mahalingam (Mahalingam)] see above. "Current implementations are proprietary and not interoperable. A taxonomy of the architectures employed in the existing products in the market will provide the basis of an output document to be provided to the IEEE 802.11 Working Group. This taxonomy will be utilized by the 802.11 Working Group as input to their task of defining the functional architecture of an access point. The functional architecture, including description of detailed functional blocks, interfaces, and information flow, will be reviewed by CAPWAP to determine if further work is needed to apply or develop standard protocols providing for multi-vendor interoperable implementations of WLANs built from devices that adhere to the newly appearing hierarchical architecture utilizing a functional split between an access point and an access controller." [Mani, Mahalingam (Mahalingam)] read in fragments - statements can get colored differently :-). However, even then the statement is valid. It does not say all-vendor (or all-arch.). =20 -mani [...] ------_=_NextPart_001_01C4063F.C71A8E48 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just a few observations that may = help staying on course:

 

For sure – if an AP = architecture does not offer interfaces to provide or facilitate AP-AC style = management we document them as such – per the same charter requirement of doing = justice to the taxonomy analysis. That such class of candidate arch. put = themselves out of court may be documented when summarizing on them. Again – = that’s merely informational given the current charter.

 

Conversely - If a = ‘traditional’ AP – as Peyush suggested – offers interfaces over = ‘traditional’ APs (given the fact APs’ firmware may be upgraded) to facilitate = such management – then that becomes an inclusive category of candidates = for multivendor

Interoperability = considerations

 

If you have better text to = articulate the intent of the charter – feel free.

 

Also = inline…

 

-mani

-----Original Message-----
From: Parviz Yegani [mailto:pyegani@cisco.com]
Sent:
Tuesday, March 09, 2004 5:01 = PM
To: = Dorothy.Gellert@nokia.com; lily.l.yang@intel.com; VLin@extremenetworks.com; bohara@airespace.com; isingh@chantrynetworks.com; jmurphy@trapezenetworks.com; matt.holdrege@verizon.net; partha@arubanetworks.com; = peyush.agarwal@st.com; Sadot, Emek (Emek); dhetheri@rovingplanet.com; pzerfos@CS.UCLA.EDU; capwap@frascone.com
Cc: Mani, Mahalingam = (Mahalingam)
Subject: RE: kicking off = CAPWAP design team

 

At 09:36 AM 3/9/2004 -0800, = Dorothy.Gellert@nokia.com wrote:

Hi Parviz-
 
Lily's definition is correct and should be something = you are familar with.   You also have the wrong charter.  What = you list was from the BOF, and has been replaced.  The new charter is = at:  http://www= .ietf.org/html.charters/capwap-charter.html.


No, I don't have the wrong charter. The highlighted text in my previous = email (appended below) was taken from the problem statement draft which is = part of the current charter. So, the question I raised is still valid.

-Parviz


 
I'm posting this response to the mailing = list to make sure others are aware that the charter has been updated since the = BOF last year.
 
Thanks,
Dorothy
 

-----Original Message----- =

From: ext Parviz Yegani = [mailto:pyegani@cisco.com]

Sent: Tuesday, March 09, 2004 1:23 = AM =

To: Yang, Lily L; Gellert = Dorothy (Nokia-ES/MtView); VLin@extremenetworks.com; bohara@airespace.com; isingh@chantrynetworks.com; jmurphy@trapezenetworks.com; matt.holdrege@verizon.net; partha@arubanetworks.com; = peyush.agarwal@st.com; esadot@avaya.com; dhetheri@rovingplanet.com; pzerfos@CS.UCLA.EDU =

Cc: mmani@avaya.com =

Subject: RE: kicking off CAPWAP design team

At 11:17 PM 3/8/2004 -0800, = Yang, Lily L wrote:


This is the = conventional WLAN architecture where each AP is self-contained without any = infrastructure support so there is no AC in such architecture. Or you can say, the AP = itself is AC as well.

Ok. In this conventional WLAN architecture = (fat AP model) the AP-AC interface is not exposed, therefore, there is no need =

[Mani, Mahalingam (Mahalingam)] not a question of no = need. This class of devices is not a candidate for that. As part of the DT effort = – we should focus on categorizing as such and move on. That may not = preclude instances of

to develop a protocol in IETF for that. = Right? If so, then how would this help solve inter-operability problem =

[Mani, Mahalingam (Mahalingam)] it does = not.

between multi-

vendor equipment as claimed by the WG charter (see highlighted text = below)?

[Mani, Mahalingam (Mahalingam)] =  see above.

"Current implementations are proprietary = and not interoperable.  A taxonomy of the architectures employed in the = existing products in the market will provide the basis of an output document to = be provided to the IEEE 802.11 Working Group.  This taxonomy will be = utilized by the 802.11 Working Group as input to their task of defining the = functional architecture of an access point.  The functional architecture, = including description of detailed functional blocks, interfaces, and information = flow, will be reviewed by CAPWAP to determine if further work is needed to = apply or develop standard protocols = providing for multi-vendor interoperable implementations of WLANs built from devices = that adhere to the newly appearing hierarchical architecture utilizing a = functional split between an access point and an access controller."

[Mani, Mahalingam (Mahalingam)] read in fragments = – statements can get colored differently J= . However, even then the statement is valid. It does not say all-vendor (or = all-arch.).

 

-mani


[…]

------_=_NextPart_001_01C4063F.C71A8E48-- From lily.l.yang@intel.com Thu Mar 11 19:13:00 2004 From: lily.l.yang@intel.com (Yang, Lily L) Date: Thu, 11 Mar 2004 11:13:00 -0800 Subject: [Capwap] First Design Team Teleconference (03/10/2004) Meeting Minutes Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE0A45A4@orsmsx408.jf.intel.com> Hi, everyone -- The design team had its first meeting via audio-conference yesterday = (March 10, 2004, 7:30-9:00am). The one and half hour meeting was very = useful in my opinion, getting the group on the same page as to what we = are chartered to do and what are the steps to take to get there. We = spent most of the time clarifying what should be included in the = architecture survey. I will be updating the template very soon to = reflect the consensus that the template language should be generic = enough to accomodate all different kinds of WLAN architectures (not = limiting to "split" architecture). The current task for the DT is the same as for the rest of the WG -- = write and submit an architecture description that would be input into = the architecture taxonomy document. See the detailed minutes below. Thanks, Lily -------------------------------------------------------------------------= ------- CAPWAP DT teleconference meeting minutes March 10, 2004 7:30am-9:00am (Pacific Time) Attendees (11 total):=20 Dorothy G. (co-chair, dropped out about 10 minutes early),=20 Lily Y. (Editor, scribe), Partha N., Petros Z., Emek S., Inderpreet S., = Matt H., Jim M., Victor L., Peyush A., Ajit (in place of Parviz) 0) Round table introduction:=20 Everyone on the call introduced himself/herself briefly to the rest of = the group. We had people outside of the DT on the call at the beginning = of the teleconf, Dorothy G. reinforced the guideline that this = teleconference is reserved for the DT members (to be productive and make = progress), while the meeting minutes will be sent to the entire CAPWAP = WG mailing list for others to see what is going on in these meetings. 1) IETF 59th meeting summary:=20 Dorothy G. gave a brief summary of the IETF meeting: DT was officially = put in place with 12 members; the charter is to do architecture = taxonomy, not protocol development; the first step is to solicit = architecture survey input from the whole WG; the taxonomy would be = reviewed by experts in both IEEE and IETF. 2) Discuss any issues on the architecture survey, template and = individual plan/status Issues come up during the discussion: * Question: Is it restrictive to split architecture only? What about = mesh architecture? The charter seems to be very inclusive, taxonomy = should include all the WLAN architectures in the practice today. After some discussion, it is agreed that all architectures including = mesh should be part of the taxonomy. * Question: The current language in the template seems to assume split = architecture as it asks about the functional split and interface between = AP and AC etc. How does mesh architecture map to that? Answer: It is agreed that the language is indeed not generic enough, but = it is not meant to be exclusive.=20 * The CAPWAP problem statement seems assume split architecture = implicitly? It is clarified that the problem statement identifies 4 = problems but those four problems might be addressed by architectures = other than "split" architecture. So that should be described in the = survey. * How should we define the AP functions, as in 802.11 standard, or as in = vendors' offering? After the discussion, it is clarified that we do not = have any clear definitions yet. Each vendor or architecture has its own = definition of the various network entities, and that should be described = as such in the survey. After all the survey data come in, common = definitions might emerge, or we might find it useful to define CAPWAP = terminologies.=20 * The template asks for some description of the functional interface. = Some vendor might be a little uneasy on that because they may have their = own secret sauce that they do not want to disclose. We agree that = companies policy should be respected, and vendors just disclose high = level information that they are comfortable in disclosing.=20 * There is concern that if the information is too high level, it might = not be too useful. It is acknowledged that the process might call for a = few iteration. * Question: Is this 802.11 only?=20 Answer: YES. CAPWAP group is chartered with looking at 802.11 = architectures only.=20 * Concern over the schedule: March 24 seems too aggresive as people may = need to go through internal process with their company before they can = submit such information to public. It is pointed out that March 24 is = already better than the inital date of March 17, and since there is = strong desire to make progress, it is best to stick to the date, and = submit as much as you can. It is important to show progress. * Poll of the architecture contribution in the DT: Not everyone in the = DT belongs to a vendor that has a WLAN offering. So only those who do = are expected to submit the survey. More than half of the team said they = will submit (Partha, Emek, Inderpreet, Matt, Jim, and Petros on DIRAC). = It is also fair for a vendor to submit multiple architectures if they = have multiple offerings in the market.=20 3) Discuss IEEE WNG call for interest in March meeting and Lily's = presentation on behalf of CAPWAP DT Lily walked through the slides. She pointed out that mesh architecture = was initially included in the slides but later pulled out for several = reasons. First of all, the mesh architecture was never discussed much in = the IETF meetings or even the mailing list. Since this presentation is = on behalf of CAPWAP DT, we want to stick to what has been discueed at = IETF. Secondly, the purpose of this presentation is to show IEEE the = kinds of problem space CAPWAP is dealing with and the interoperability = issues vendors are facing. There are enough issues to show even without = complicating the picture with mesh. We don't want distraction with this = first presentation. We can always follow up later with more data, once = the survey is complete.=20 So people agree that discussion of mesh in this IEEE presentation is too = premature and should be left out for now. Question about the next step slide: If we are supposed to have the = taxonomy by April and send that in for expert review, what do we do = after April? The answer is we will need to incorporate comments from the = expert review during the whole process. 4) DT working plan and logistics: draft creation tool; meeting/teleconf = schedule; editing plan Draft tool: xml2rfc is recommended. Lily would send out information on = that. Lily suggested that everyone install it and play with it. Next meeting: Several people would be IEEE next week, and should meet = face to face. Next teleconference is agreed to be March 25 (Thursday, = right after the submission deadline) 7:00am PST. Lily would schedule a = bridge. Editing plan: At any given time, only one person should have the editing = token of the master document. But it is expected that people can work on = different pieces of the document and integrate later. So it is expected = that everyone in the DT be ready to contribute in draft writing and = editing. From lily.l.yang@intel.com Sun Mar 21 06:33:35 2004 From: lily.l.yang@intel.com (Yang, Lily L) Date: Sat, 20 Mar 2004 22:33:35 -0800 Subject: [Capwap] reminder: please submit your architecture survey by March 24 (this Wed) Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE0A4628@orsmsx408.jf.intel.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C40F0E.6FEC0676 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C40F0E.6FEC0676" ------_=_NextPart_002_01C40F0E.6FEC0676 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all - =20 Just a reminder that the architecture survey is due this coming Wed (March 24).=20 The design team has a very tight schedule to produce the architecture taxonomy draft by early April and so it is extremely important that receive all the survey input by the deadline! =20 Here I attached the template again, in case you missed it last time. =20 Thank you for your attention to this important deadline! =20 Lily =20 =20 ------_=_NextPart_002_01C40F0E.6FEC0676 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, all –

 

Just a reminder that the architecture survey is due = this coming Wed (March 24).

The design team has a very tight schedule to produce = the architecture taxonomy draft by early April and so it is extremely important that = receive all the survey input by the deadline!

 

Here I attached the template again, in case you = missed it last time.

 

Thank you for your attention to this important = deadline!

 

Lily

 

 

=00 ------_=_NextPart_002_01C40F0E.6FEC0676-- ------_=_NextPart_001_01C40F0E.6FEC0676 Content-Type: text/plain; name="CAPWAP_arch_template.txt" Content-Transfer-Encoding: base64 Content-Description: CAPWAP_arch_template.txt Content-Disposition: attachment; filename="CAPWAP_arch_template.txt" Tm90ZToNClBsZWFzZSB3cml0ZSB5b3VyIGNvbnRyaWJ1dGlvbiBpbiBhIHRleHQgZmlsZSwgYW5k IGxpbWl0IGl0IHRvIHR3byBwYWdlcyBhdCBtb3N0LiAgDQpQbGVhc2Ugc2VuZCB5b3VyIGNvbnRy aWJ1dGlvbiB0byB0aGUgZm9sbG93aW5nIGJ5IE1hcmNoIDI0LCAyMDA0Og0KTGlseSBZYW5nIChs aWx5LmwueWFuZ0BpbnRlbC5jb20pOiBkZXNpZ24gdGVhbSBlZGl0b3INCk1hbmksIE1haGFsaW5n YW0gKG1tYW5pQGF2YXlhLmNvbSk6IFdHIGNvLWNoYWlyDQpEb3JvdGh5IEdlbGxlcnQgKERvcm90 aHkuR2VsbGVydEBub2tpYS5jb20pOiBXRyBjby1jaGFpcg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0gdGVtcGxhdGUgc3RhcnRzIGhlcmUgLS0tLS0tLS0tLS0tLS0tLQ0KDQpjb250 cmlidXRpb24gdGVtcGxhdGUgZm9yIFdMQU4gYXJjaGl0ZWN0dXJlIHN1cnZleSANCg0KKDEpIERl c2lnbiBjb25zaWRlcmF0aW9ucyAmIHJlcXVpcmVtZW50czogDQoNCnBsZWFzZSBicmllZmx5IGRl c2NyaWJlIHlvdXIgZGVzaWduIHByaW5jaXBsZXMgZm9yIHRoaXMgYXJjaGl0ZWN0dXJlLg0KDQoo MikgV0xBTiBmdW5jdGlvbnMgc3VwcG9ydGVkOg0KDQpQbGVhc2UgbGlzdCB0aGUgZnVuY3Rpb25z IHN1cHBvcnRlZCBpbiB0aGlzIFdMQU4gYnJpZWZseSwgYnV0IHBsZWFzZSBkbyBub3Qgc2VuZCB1 cyB0aGUgZW50aXJlIGRhdGEgc2hlZXQuIA0KRXhhbXBsZXMgb2YgV0xBTiBmdW5jdGlvbnMgaW5j bHVkZXMgdGhlIFNUQSBzZXJ2aWNlcywgRGlzdHJpYnV0ZWQgU3lzdGVtIFNlcnZpY2VzIChhcyBk ZWZpbmVkIGJ5IDgwMi4xMSksIA0KcmFkaW8gcmVzb3VyY2UgbWFuYWdlbWVudCBhbmQgY29udHJv bCwgQVAgbG9hZCBiYWxhbmNpbmcsIG1vYmlsaXR5IHN1cHBvcnQsIFdMQU4gbmV0d29yayB3aWRl IHNlY3VyaXR5IGZ1bmN0aW9ucyANCihpbmNsdWRpbmcgYXV0aGVudGljYXRpb24sIGVuY3J5cHRp b24gZm9yIHByaXZhY3kgYW5kIGludGVncml0eSwgZXRjLikgYW5kIGFueSBvdGhlcnMgbm90IGxp c3RlZCBoZXJlIGJ1dCBkZWVtZWQgDQppbXBvcnRhbnQgaW4geW91ciBkZXNpZ24uDQoNCigzKSBU aGUgZnVuY3Rpb25hbCBhcmNoaXRlY3R1cmUgdG8gaW1wbGVtZW50IHRoZSBmdW5jdGlvbnMgZGVz Y3JpYmVkIGFib3ZlOiB3aGV0aGVyIGl0IGlzIGJ5IGF1dG9ub21vdXMgQVANCmFyY2hpdGVjdHVy ZSwgb3IgInNwbGl0IiBhcmNoaXRlY3R1cmUuIEZvciBzcGxpdCBhcmNoaXRlY3R1cmUsIHBsZWFz ZSBwcm92aWRlIHRoZSBmdW5jdGlvbmFsIG1hcHBpbmcgDQpvZiBXTEFOIGZ1bmN0aW9ucyBvbnRv IHRoZSBBUCBhbmQgQUMgLS0gd2l0aCBqdXN0IGVub3VnaCBkZXRhaWxzIHRoYXQgaGVscCB1cyB1 bmRlcnN0YW5kIHRoZSBraW5kcyBvZiBmdW5jdGlvbmFsDQppbnRlcmZhY2UgbmVjZXNzYXJ5IGJl dHdlZW4gdGhlIHR3by4NCg0KKDQpIFRoZSBwcm90b2NvbCB1c2VkIGluIGJldHdlZW4gQVAgYW5k IEFDLiANCg0KKDUpIFRoZSB0b3BvbG9naWNhbCBhc3N1bXB0aW9ucyBiZXR3ZWVuIEFQIGFuZCBB QyAoaXMgaXQgZGlyZWN0bHkgY29ubmVjdGVkLCBMMiBzd2l0Y2hlZCwgDQpvciBMMyByb3V0ZWQ/ KSAtLSB0aGlzIGFsc28gaGVscHMgdXMgdG8gdW5kZXJzdGFuZCB0aGUgZGVwbG95bWVudCBzY2Vu YXJpb3MuDQoNCig2KSBTZWN1cml0eSB0aHJlYXQgYW5hbHlzaXM6IHdoYXQga2luZHMgb2YgdGhy ZWF0IGludHJvZHVjZWQgYnkgdGhlIHNwbGl0IGFyY2hpdGVjdHVyZSwNCmFuZCBob3cgdGhhdCBh cmUgYWRkcmVzc2VkLg0KDQooNykgUHJvcyBhbmQgQ29ucyBvZiB0aGlzIGFyY2hpdGVjdHVyZSwg ZXNwLiBpbiByZWxhdGlvbiB0byB0aGUgZm91ciBwcm9ibGVtcyBkZXNjcmliZWQgaW4gdGhlIENB UFdBUA0KcHJvYmxlbSBzdGF0ZW1lbnQuIFBsZWFzZSBrZWVwIHRoZSBhbmFseXNpcyBhdCB0ZWNo bmljYWwgaW5zdGVhZCBvZiBtYXJrZXRpbmcgbGV2ZWwuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSB0ZW1wbGF0ZSBlbmRzIGhlcmUgLS0tLS0tLS0tLS0tLS0tLQ0K ------_=_NextPart_001_01C40F0E.6FEC0676-- From lily.l.yang@intel.com Mon Mar 22 21:34:19 2004 From: lily.l.yang@intel.com (Yang, Lily L) Date: Mon, 22 Mar 2004 13:34:19 -0800 Subject: [Capwap] links for architecture survey contributions Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE0A4642@orsmsx408.jf.intel.com> Hi, all -- We are posting all the architecture survey contributions on the followng = page. So far we got only one submission. Please submit as early as possible. http://www.capwap.org/architecture/ Thanks, Lily From lily.l.yang@intel.com Mon Mar 22 23:07:45 2004 From: lily.l.yang@intel.com (Yang, Lily L) Date: Mon, 22 Mar 2004 15:07:45 -0800 Subject: [Capwap] links for architecture survey contributions Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE0A464B@orsmsx408.jf.intel.com> Some of you pointed out the formatting problem with the contribution = text. It is now fixed. Happy Reading. > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > Behalf Of Yang, Lily L > Sent: Monday, March 22, 2004 1:34 PM > To: Capwap (E-mail) > Subject: [Capwap] links for architecture survey contributions >=20 >=20 > Hi, all -- >=20 > We are posting all the architecture survey contributions on=20 > the followng page. So far we got only one submission. > Please submit as early as possible. >=20 > http://www.capwap.org/architecture/ >=20 > Thanks, > Lily > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 From lily.l.yang@intel.com Tue Mar 23 22:40:09 2004 From: lily.l.yang@intel.com (Yang, Lily L) Date: Tue, 23 Mar 2004 14:40:09 -0800 Subject: [Capwap] More contributions for architecture survey have been posted Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE0A4670@orsmsx408.jf.intel.com> at http://www.capwap.org/architecture/ Please check out this link frequently for the next two days, as more = contributions are constantly being added. From lily.l.yang@intel.com Wed Mar 24 19:09:28 2004 From: lily.l.yang@intel.com (Yang, Lily L) Date: Wed, 24 Mar 2004 11:09:28 -0800 Subject: [Capwap] Reminder: last day to submit architecture survey contribution Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE0A4685@orsmsx408.jf.intel.com> Please send your contribution in by 5pm, PST, today.=20 The design team will start working on the taxonomy document first thing = tomorrow morning (7am PST) via teleconference.=20 So far we've had 10 contributions submitted already. See them all here = at: www.capwap.org/architecture Lily From lily.l.yang@intel.com Wed Mar 24 21:04:45 2004 From: lily.l.yang@intel.com (Yang, Lily L) Date: Wed, 24 Mar 2004 13:04:45 -0800 Subject: [Capwap] Reminder: last day to submit architecture survey contribution Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE0A4688@orsmsx408.jf.intel.com> Yes. Your contribution is most welcome. > -----Original Message----- > From: fodil@6wind.com [mailto:fodil@6wind.com] > Sent: Wednesday, March 24, 2004 12:15 PM > To: Yang, Lily L > Cc: capwap@frascone.com > Subject: Re: [Capwap] Reminder: last day to submit architecture survey > contribution >=20 >=20 > Hi all, > I get interest in CAPWAP working group since first BOF IN Vienna. > I currently work on network management for public WLAN (hotspot) using > programmable access equipments (router / swicth). > I would ask you, if the CapWap group is interested in new > architectures for the access equipments management, that are based on > using some policy management principles. >=20 > REGARDS >=20 > > Please send your contribution in by 5pm, PST, today. > > The design team will start working on the taxonomy document=20 > first thing > > tomorrow morning (7am PST) via teleconference. > > > > So far we've had 10 contributions submitted already. See=20 > them all here > > at: www.capwap.org/architecture > > > > > > Lily > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap >=20 >=20 >=20 >=20 From Elena.Demaria@TILAB.COM Thu Mar 25 13:29:04 2004 From: Elena.Demaria@TILAB.COM (Demaria Elena) Date: Thu, 25 Mar 2004 14:29:04 +0100 Subject: [Capwap] A question on draft-ietf-capwap-arch-00 Message-ID: <6ECEC1E214F2E342814ABB1ED10E7955010563DA@EXC2K01B.cselt.it> Hi all, I have some questions on draft-ietf-capwap-arch-00. In section 2.1 it is stated that AP implementations do not adhere to the standard in the sense that each AP is an isolated ESS. This implies that the DS is not present and that the AP implements also the Integration Service. Which is the function in an Access Point that implements the Integration Service? Is it possible with the current implementation of an AP to create an ESS formed by more than one BSS? How? Reading the definition of integration service it isn't clear in which sense integration is considered unique to 802.11: can someone explain this statement? Thanks, Elena ==================================================================== CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to MailAdmin@tilab.com. Thank you ==================================================================== From bob@airespace.com Thu Mar 25 16:10:48 2004 From: bob@airespace.com (Bob O'Hara) Date: Thu, 25 Mar 2004 08:10:48 -0800 Subject: [Capwap] A question on draft-ietf-capwap-arch-00 Message-ID: <55749BC69138654EBBC4C50BA4F556100147606D@AIREMAIL.airespace.com> Elena, The 802.11 integration function is that which exchanges frames between an 802.11 station and a host that is not an 802.11 station in the same ESS. So, every time an 802.11 station communicates with its default gateway, for example, the integration function is invoked. There are differences of opinion as to whether the "current" APs (by which I assume that you mean the classic, stand-alone AP) actually implement an ESS that consists of more than one BSS. My opinion is that they don't. In my opinion, the classic AP invokes the integration function on every frame it exchanges with any host that is not an 802.11 station that is associated locally at the AP. There is no differentiation made between a host that is at another AP using the same SSID as the local AP and a host that is not an 802.11 station, at all. This indicates that the ESS consists of only the BSS at the local AP. I don't know if the integration function is unique to 802.11. However, it is used by 802.11 to indicate that there should be some point (or possibly points) at which the 802.11 ESS connects to other networks. At this point, the translation to other frame formats takes place and the transparency of movement of the 802.11 station in the ESS is terminated. -Bob =20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Demaria Elena Sent: Thursday, March 25, 2004 5:29 AM To: capwap@frascone.com Subject: [Capwap] A question on draft-ietf-capwap-arch-00 Hi all, I have some questions on draft-ietf-capwap-arch-00.=20 In section 2.1 it is stated that AP implementations do not adhere to the standard in the sense that each AP is an isolated ESS. This implies that the DS is not present and that the AP implements also the Integration Service. Which is the function in an Access Point that implements the Integration Service?=20 Is it possible with the current implementation of an AP to create an ESS formed by more than one BSS? How? Reading the definition of integration service it isn't clear in which sense integration is considered unique to 802.11: can someone explain this statement? Thanks, Elena =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From kempf@docomolabs-usa.com Thu Mar 25 17:04:51 2004 From: kempf@docomolabs-usa.com (James Kempf) Date: Thu, 25 Mar 2004 09:04:51 -0800 Subject: [Capwap] A question on draft-ietf-capwap-arch-00 References: <55749BC69138654EBBC4C50BA4F556100147606D@AIREMAIL.airespace.com> Message-ID: <00b201c4128b$49b74c40$366115ac@dcml.docomolabsusa.com> Bob, The 802.11 integration function is that which exchanges frames between an 802.11 station and a host that is not an 802.11 station in the same ESS. So, every time an 802.11 station communicates with its default gateway, for example, the integration function is invoked. jak>> I think you mean "node" and not "host". In the IP architecture, host and router functions are different. A gateway is a router. Node covers both, so it would cover a host that is connected up to the 802.3 LAN between the gateway and the wireless terminal, in addition to the router. Sorry for being so pendantic... There are differences of opinion as to whether the "current" APs (by which I assume that you mean the classic, stand-alone AP) actually implement an ESS that consists of more than one BSS. My opinion is that they don't. In my opinion, the classic AP invokes the integration function on every frame it exchanges with any host that is not an 802.11 station that is associated locally at the AP. There is no differentiation made between a host that is at another AP using the same SSID as the local AP and a host that is not an 802.11 station, at all. This indicates that the ESS consists of only the BSS at the local AP. I don't know if the integration function is unique to 802.11. However, it is used by 802.11 to indicate that there should be some point (or possibly points) at which the 802.11 ESS connects to other networks. At this point, the translation to other frame formats takes place and the transparency of movement of the 802.11 station in the ESS is terminated. jak>> The problem I've had with understanding this is that it doesn't map well to where the MAC/PHY layers terminate. The 802.11 MAC/PHY on an autonomous AP terminate at the AP, since that is where the translation from radio/802.11 is made to whatever wired PHY link/802.3. How does the MAC/PHY termination point relate to the integration function? jak From soohong.park@samsung.com Sat Mar 27 00:35:21 2004 From: soohong.park@samsung.com (S. Daniel Park) Date: Sat, 27 Mar 2004 09:35:21 +0900 Subject: [Capwap] Comparison between IAPP and LWAPP Message-ID: <00d201c41393$62c27d50$67cadba8@LocalHost> I don't have any objection on the CAPWAP working group, it's my personal concern...sorry it's too stupid...^.^ After I attended IEEE 802 Plenary last week, I felt that many IEEE guys didn't favourable to the LWAPP approach, they proposed and said that current mechanism IAPP was able to provide LWAPP functions between AC and AP as well. From my aspect, I am in favour of LWAPP, however I'd want to see and make sense what differences (or pros and cons) are between IAPP and LWAPP. Please clarify this concern if valuable... Regards - Daniel (Soohong Daniel Park) - Mobile Platform Laboratory, SAMSUNG Electronics. From lily.l.yang@intel.com Sun Mar 28 02:43:09 2004 From: lily.l.yang@intel.com (Yang, Lily L) Date: Sat, 27 Mar 2004 18:43:09 -0800 Subject: [Capwap] A question on draft-ietf-capwap-arch-00 Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE0CDB73@orsmsx408.jf.intel.com> I would agree that it is pretty hard to get straight answers for these questions just from the 802.11 spec.=20 To look for answer to James's question, I looked up the definition of "integration service" in the spec: "The service that enables delivery of medium access control (MAC) service data units (MSDUs) between the distribution system (DS) and an existing, non-IEEE 802.11 local area network (via a portal)." So according to that, integration is what a portal does, bridging between DS and non-IEEE 802.11 LAN.=20 I find it puzzling that it is defined as between DS and non-IEEE 802.11 LAN. It almost implies that DS itself must be 802.11, even though the spec said elsewhere that DSM can be anything, can be different from WM. So I would think that Bob's statement that each AP implements an ESS by itself actually reflects what the spec said at the first place. So the vendors are implementing as the standard said! Even though, it probably is not what the typical interpretation of what ESS is. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf Sent: Thursday, March 25, 2004 9:05 AM To: Bob O'Hara; Demaria Elena; capwap@frascone.com Subject: Re: [Capwap] A question on draft-ietf-capwap-arch-00 Bob, The 802.11 integration function is that which exchanges frames between an 802.11 station and a host that is not an 802.11 station in the same ESS. So, every time an 802.11 station communicates with its default gateway, for example, the integration function is invoked. jak>> I think you mean "node" and not "host". In the IP architecture, host and router functions are different. A gateway is a router. Node covers both, so it would cover a host that is connected up to the 802.3 LAN between the gateway and the wireless terminal, in addition to the router. Sorry for being so pendantic... There are differences of opinion as to whether the "current" APs (by which I assume that you mean the classic, stand-alone AP) actually implement an ESS that consists of more than one BSS. My opinion is that they don't. In my opinion, the classic AP invokes the integration function on every frame it exchanges with any host that is not an 802.11 station that is associated locally at the AP. There is no differentiation made between a host that is at another AP using the same SSID as the local AP and a host that is not an 802.11 station, at all. This indicates that the ESS consists of only the BSS at the local AP. I don't know if the integration function is unique to 802.11. However, it is used by 802.11 to indicate that there should be some point (or possibly points) at which the 802.11 ESS connects to other networks. At this point, the translation to other frame formats takes place and the transparency of movement of the 802.11 station in the ESS is terminated. jak>> The problem I've had with understanding this is that it doesn't map well to where the MAC/PHY layers terminate. The 802.11 MAC/PHY on an autonomous AP terminate at the AP, since that is where the translation from radio/802.11 is made to whatever wired PHY link/802.3. How does the MAC/PHY termination point relate to the integration function? jak _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From lily.l.yang@intel.com Wed Mar 31 04:36:50 2004 From: lily.l.yang@intel.com (Yang, Lily L) Date: Tue, 30 Mar 2004 20:36:50 -0800 Subject: [Capwap] [Capwap-DT] DT teleconference minutes 03/30/2004 and some important issues that we are discussing Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE0CDB85@orsmsx408.jf.intel.com> Hi, all=20 The design team had a teleconference this morning 8am. Below you can find the minutes. The design team has been working very hard since last week to analyze the data provided by all the architecture survey contributors (THANK YOU ALL!). We will have daily teleconference for the next few days to iron out some critical issues. The current focus is to work out a functional mapping matrix that has a logical 802.11 function on each row and each architecture contributor on each column, and a mapping indication of which function is implemented by which. Once we reached some rough consensus on the matrix, we can post it to the web site for you to see and comment. Another thing being discussed several times is terminology. I would like to get some feedback from the mailing list here. So let me explain what we are up to first. The most confusing terms is, maybe surprisingly to some people -- "AP"! When people talk about AP, it can mean one of two things, but often times it is not clear which one they mean. One meaning is that physical box with antenna sticking out to which stations associate with. There is another meaning, esp. when people say "AP functions": they don't mean the functions implemented on one such physical box. They mean the logical functions which can be implemented in one box (and hence autonomous AP architecture) or in a network (like the combination of thin AP and AC) or whatever. So we believe further qualification is needed when we talk about AP or AP functions. Or, it is also suggested that, new terminology should be introduced to clarify the ambiguity.=20 Some suggestions are: avoid using "AP functions", instead, use "802.11 functions" to mean the set of logical functions for 802.11 WLAN. Then use more explicit and different terms to refer to physical boxes (network elements). Here are a few suggestions for the physical boxes: 1) For the controller, Access Controller (AC) seems to stick now. 2) For the box that implements 802.11 PHY and receives/transmits the STA traffic: we can call it Wireless Termination Point (WTP), or thin AP or controlled AP (when it is in split architecture), or standalone AP or fat AP(when in autonomous architecture), or mesh AP (when in mesh).=20 So feel free to comment or suggest.=20 Thank you! Lily ----------------- teleconference minutes ------------------ CAPWAP Design Team teleconference minutes=20 03/30/2004 Attendees (10): Ajit (in place of Parviz), Partha, Petros, Emek, Inderpreet, Jim, Victor, Bob, Dave, Mani (chair) Discussions: * Brief discussion about Cisco participation in DT: Parviz couldn't join today's meeting and so asked Ajit to cover for him. Ajit indicated that they would resolve the issue today as who will be staying and participating in the DT. Everyone agreed that it is more beneficial and productive if we have consistent DT participations. * Status of the taxonomy: Lily, Peyush, Petros and Emek have written some form of text for the intro section and Split AP, Split AC, but it is still very raw. Need comments on overall structure and whether it is on the right direction, not on the editorial level yet. Terminology is still missing. The matrix has been filled up by most contributors, and is expanded now. Need to discuss whether all the info there is relevant to the interoperability issue. One thing that some people noted and questioned is the divide between split MAC and split AC. * Discussion about matrix: Petros pointed out that there are largely two kinds of functions we are dealing with in the matrix, one is 802.11 defined services (related to MAC management frames), another is value-added services (like mobility support, VoIP support) which are very high level. Lily asked the question whether the value-added services are being impacted by the interface between AP and AC. If not, there is no point in considering them in the CAPWAP context. We should only document functions/services that are relevant to the interface definition down the road. Vendors can still retain their own implementaion internal to those value-added services. After some discussion, it is agreed that we can safely remove the value-added functions that don't directly impact interface issue in the matrix and just focus on those functions that need interface support, like the 802.11 services, plus configuration and management functions.=20 * Discussion on mesh architecture: It is considered valid but different architecture from the rest of the split architectures. Jim pointed out that the interesting part to CAPWAP is that there might still be an AC in the mesh architecture that would also require similar interface as AP-AC interface. Partha asserted that for mesh architecture, we should only document the logical functions for mesh, but no physical mapping to devices. Mani sussgested that this is something we can defer for further study as well. So most people agree that we don't have enough data points for mesh right now, and we should focus on the split which we seem to understand more and come back to mesh later. * Discussion about terminology: Conceptually, people agree that we have the logical concept of AP functions (802.11 services, according to 802.11 spec). These functions are not asscociated with any particular physical boxes. They can be implemented within one box, or over multiple boxes by a network. As for the physical boxes, we have a few proposals on the table: standalone AP in the autonomous architecture; thin APs (or WTPs -- Wireless Termination Points, or Controlled AP) and AC (Access Controller) in the split architecture; mesh APs (for the distributed mesh architecture). Much discussion is whether we should use "thin AP" or "WTP". Bob expressed his ambivalent view which a few people also concurred that there are pros and cons for each. Using a new terminology (like WTP) might be a hard sell and might not stick, but if we define it clearly, it gives people a chance to unload some of their assumptions associated with existing terms and hence avoid the confusion. On the other hand, the industry has been using these terms like APs and thin APs that are more familiar to them. It is pointed out that no matter what we decide and put in the draft, a larger community will review and comment and debate.=20 * Working plan: daily teleconference will be scheduled for 8am for the rest of the week to give a forum to resync and discuss. The task for today is to work out the details on matrix. Once we do that, we can work on text after that. If a line item needs both AP and AC, it might be an indication that finer granularity is needed to break it apart. Make your suggestions over email. _______________________________________________ Capwap-DT mailing list Capwap-DT@frascone.com http://mail.frascone.com/mailman/listinfo/capwap-dt From kempf@docomolabs-usa.com Wed Mar 31 19:17:36 2004 From: kempf@docomolabs-usa.com (James Kempf) Date: Wed, 31 Mar 2004 11:17:36 -0800 Subject: [Capwap] [Capwap-DT] DT teleconference minutes 03/30/2004 and some important issues that we are discussing References: <2AF68A477DD44C4EBCBE338C24E7A9EE0CDB85@orsmsx408.jf.intel.com> Message-ID: <016b01c41754$d3c98e70$5b6115ac@dcml.docomolabsusa.com> Lilly, I think the confusion over the term AP here might be between whether it is a functional entity or a network/physical entity (i.e. the box that implements a collection of functional entities). I think some people may want to use the term for both, which I think it might be a good idea to avoid. Since the WG is primarily concerned with functional architecture and not network reference architecture, if the term AP applies to a network entity, it would not appear in the taxonomy document. My sense is that it does, in fact, apply to the network entity, and that people do tend to mean "the box with the antenna on it" when they talk about an AP (at least, that's what I mean when I talk about an AP). Because the different vendors put different functional entities into "the box with the antenna on it", it might not be easy to get agreement on exactly what the term AP means. I think using AC for the access controller is a good idea, and I think "Wireless Termination Point" (WTP) sounds like a good term for where the wireless PHY terminates, for the functional entities. I would avoid any term that has AP in it for the functional entities, and stick to that for the network entity. I would also avoid any terms involving fat, thin, etc. Even Autonomous AP suggests a particular network reference architecture, and therfore probably doesn't belong in a functional architecture document. A term that encompasses the AC and WTP might be something like "802.11 Access Network". The Autonomous AP architecture doesn't support this, but some others, like the split MAC approach, do. jak ----- Original Message ----- From: "Yang, Lily L" To: Sent: Tuesday, March 30, 2004 8:36 PM Subject: [Capwap] [Capwap-DT] DT teleconference minutes 03/30/2004 and some important issues that we are discussing Hi, all The design team had a teleconference this morning 8am. Below you can find the minutes. The design team has been working very hard since last week to analyze the data provided by all the architecture survey contributors (THANK YOU ALL!). We will have daily teleconference for the next few days to iron out some critical issues. The current focus is to work out a functional mapping matrix that has a logical 802.11 function on each row and each architecture contributor on each column, and a mapping indication of which function is implemented by which. Once we reached some rough consensus on the matrix, we can post it to the web site for you to see and comment. Another thing being discussed several times is terminology. I would like to get some feedback from the mailing list here. So let me explain what we are up to first. The most confusing terms is, maybe surprisingly to some people -- "AP"! When people talk about AP, it can mean one of two things, but often times it is not clear which one they mean. One meaning is that physical box with antenna sticking out to which stations associate with. There is another meaning, esp. when people say "AP functions": they don't mean the functions implemented on one such physical box. They mean the logical functions which can be implemented in one box (and hence autonomous AP architecture) or in a network (like the combination of thin AP and AC) or whatever. So we believe further qualification is needed when we talk about AP or AP functions. Or, it is also suggested that, new terminology should be introduced to clarify the ambiguity. Some suggestions are: avoid using "AP functions", instead, use "802.11 functions" to mean the set of logical functions for 802.11 WLAN. Then use more explicit and different terms to refer to physical boxes (network elements). Here are a few suggestions for the physical boxes: 1) For the controller, Access Controller (AC) seems to stick now. 2) For the box that implements 802.11 PHY and receives/transmits the STA traffic: we can call it Wireless Termination Point (WTP), or thin AP or controlled AP (when it is in split architecture), or standalone AP or fat AP(when in autonomous architecture), or mesh AP (when in mesh). So feel free to comment or suggest. Thank you! Lily ----------------- teleconference minutes ------------------ CAPWAP Design Team teleconference minutes 03/30/2004 Attendees (10): Ajit (in place of Parviz), Partha, Petros, Emek, Inderpreet, Jim, Victor, Bob, Dave, Mani (chair) Discussions: * Brief discussion about Cisco participation in DT: Parviz couldn't join today's meeting and so asked Ajit to cover for him. Ajit indicated that they would resolve the issue today as who will be staying and participating in the DT. Everyone agreed that it is more beneficial and productive if we have consistent DT participations. * Status of the taxonomy: Lily, Peyush, Petros and Emek have written some form of text for the intro section and Split AP, Split AC, but it is still very raw. Need comments on overall structure and whether it is on the right direction, not on the editorial level yet. Terminology is still missing. The matrix has been filled up by most contributors, and is expanded now. Need to discuss whether all the info there is relevant to the interoperability issue. One thing that some people noted and questioned is the divide between split MAC and split AC. * Discussion about matrix: Petros pointed out that there are largely two kinds of functions we are dealing with in the matrix, one is 802.11 defined services (related to MAC management frames), another is value-added services (like mobility support, VoIP support) which are very high level. Lily asked the question whether the value-added services are being impacted by the interface between AP and AC. If not, there is no point in considering them in the CAPWAP context. We should only document functions/services that are relevant to the interface definition down the road. Vendors can still retain their own implementaion internal to those value-added services. After some discussion, it is agreed that we can safely remove the value-added functions that don't directly impact interface issue in the matrix and just focus on those functions that need interface support, like the 802.11 services, plus configuration and management functions. * Discussion on mesh architecture: It is considered valid but different architecture from the rest of the split architectures. Jim pointed out that the interesting part to CAPWAP is that there might still be an AC in the mesh architecture that would also require similar interface as AP-AC interface. Partha asserted that for mesh architecture, we should only document the logical functions for mesh, but no physical mapping to devices. Mani sussgested that this is something we can defer for further study as well. So most people agree that we don't have enough data points for mesh right now, and we should focus on the split which we seem to understand more and come back to mesh later. * Discussion about terminology: Conceptually, people agree that we have the logical concept of AP functions (802.11 services, according to 802.11 spec). These functions are not asscociated with any particular physical boxes. They can be implemented within one box, or over multiple boxes by a network. As for the physical boxes, we have a few proposals on the table: standalone AP in the autonomous architecture; thin APs (or WTPs -- Wireless Termination Points, or Controlled AP) and AC (Access Controller) in the split architecture; mesh APs (for the distributed mesh architecture). Much discussion is whether we should use "thin AP" or "WTP". Bob expressed his ambivalent view which a few people also concurred that there are pros and cons for each. Using a new terminology (like WTP) might be a hard sell and might not stick, but if we define it clearly, it gives people a chance to unload some of their assumptions associated with existing terms and hence avoid the confusion. On the other hand, the industry has been using these terms like APs and thin APs that are more familiar to them. It is pointed out that no matter what we decide and put in the draft, a larger community will review and comment and debate. * Working plan: daily teleconference will be scheduled for 8am for the rest of the week to give a forum to resync and discuss. The task for today is to work out the details on matrix. Once we do that, we can work on text after that. If a line item needs both AP and AC, it might be an indication that finer granularity is needed to break it apart. Make your suggestions over email. _______________________________________________ Capwap-DT mailing list Capwap-DT@frascone.com http://mail.frascone.com/mailman/listinfo/capwap-dt _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From lily.l.yang@intel.com Wed Mar 31 21:22:19 2004 From: lily.l.yang@intel.com (Yang, Lily L) Date: Wed, 31 Mar 2004 13:22:19 -0800 Subject: [Capwap] [Capwap-DT] DT teleconference minutes 03/30/2004 and some important issues that we are discussing Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE0CDB90@orsmsx408.jf.intel.com> James -- I agree that the confusion is largely due to the ambiguity between logical function entity and the network/physical entity. I also like the "802.11 Access Network". But, unless I misunderstand what you said, it concerns me when you said "the WG is primarily concerned with functional architecture and not network reference architecture...". I have to disagree. I thought we are chartered to look at both (functional architecture and network architecture) and document that in the taxonomy. For example, one of the thing we are trying to work out is the functional mapping matrix. It encompasses two things: it contains a list of basic 802.11 functions and CAPWAP (control, config, etc.) functions; it also document how each vendor map those functions onto the network entities (WTP or AC). So the former is about the functional aspect, but the later is the network architecture aspect. We need to document both in this taxonomy. Now what I (personally) would like to see down the road, once we have this taxonomy reviewed by IETF and IEEE, is that IEEE can focus on the functional aspect and IETF would focus on the network architecture and protocol aspect. Let me know what you think. I want to get this right so that I can make sure the taxonomy is on the right track. Thanks, Lily -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com]=20 Sent: Wednesday, March 31, 2004 11:18 AM To: Yang, Lily L; capwap@frascone.com Subject: Re: [Capwap] [Capwap-DT] DT teleconference minutes 03/30/2004 and some important issues that we are discussing Lilly, I think the confusion over the term AP here might be between whether it is a functional entity or a network/physical entity (i.e. the box that implements a collection of functional entities). I think some people may want to use the term for both, which I think it might be a good idea to avoid. Since the WG is primarily concerned with functional architecture and not network reference architecture, if the term AP applies to a network entity, it would not appear in the taxonomy document. My sense is that it does, in fact, apply to the network entity, and that people do tend to mean "the box with the antenna on it" when they talk about an AP (at least, that's what I mean when I talk about an AP). Because the different vendors put different functional entities into "the box with the antenna on it", it might not be easy to get agreement on exactly what the term AP means. I think using AC for the access controller is a good idea, and I think "Wireless Termination Point" (WTP) sounds like a good term for where the wireless PHY terminates, for the functional entities. I would avoid any term that has AP in it for the functional entities, and stick to that for the network entity. I would also avoid any terms involving fat, thin, etc. Even Autonomous AP suggests a particular network reference architecture, and therfore probably doesn't belong in a functional architecture document. A term that encompasses the AC and WTP might be something like "802.11 Access Network". The Autonomous AP architecture doesn't support this, but some others, like the split MAC approach, do. jak ----- Original Message -----=20 From: "Yang, Lily L" To: Sent: Tuesday, March 30, 2004 8:36 PM Subject: [Capwap] [Capwap-DT] DT teleconference minutes 03/30/2004 and some important issues that we are discussing Hi, all The design team had a teleconference this morning 8am. Below you can find the minutes. The design team has been working very hard since last week to analyze the data provided by all the architecture survey contributors (THANK YOU ALL!). We will have daily teleconference for the next few days to iron out some critical issues. The current focus is to work out a functional mapping matrix that has a logical 802.11 function on each row and each architecture contributor on each column, and a mapping indication of which function is implemented by which. Once we reached some rough consensus on the matrix, we can post it to the web site for you to see and comment. Another thing being discussed several times is terminology. I would like to get some feedback from the mailing list here. So let me explain what we are up to first. The most confusing terms is, maybe surprisingly to some people -- "AP"! When people talk about AP, it can mean one of two things, but often times it is not clear which one they mean. One meaning is that physical box with antenna sticking out to which stations associate with. There is another meaning, esp. when people say "AP functions": they don't mean the functions implemented on one such physical box. They mean the logical functions which can be implemented in one box (and hence autonomous AP architecture) or in a network (like the combination of thin AP and AC) or whatever. So we believe further qualification is needed when we talk about AP or AP functions. Or, it is also suggested that, new terminology should be introduced to clarify the ambiguity. Some suggestions are: avoid using "AP functions", instead, use "802.11 functions" to mean the set of logical functions for 802.11 WLAN. Then use more explicit and different terms to refer to physical boxes (network elements). Here are a few suggestions for the physical boxes: 1) For the controller, Access Controller (AC) seems to stick now. 2) For the box that implements 802.11 PHY and receives/transmits the STA traffic: we can call it Wireless Termination Point (WTP), or thin AP or controlled AP (when it is in split architecture), or standalone AP or fat AP(when in autonomous architecture), or mesh AP (when in mesh). So feel free to comment or suggest. Thank you! Lily ----------------- teleconference minutes ------------------ CAPWAP Design Team teleconference minutes 03/30/2004 Attendees (10): Ajit (in place of Parviz), Partha, Petros, Emek, Inderpreet, Jim, Victor, Bob, Dave, Mani (chair) Discussions: * Brief discussion about Cisco participation in DT: Parviz couldn't join today's meeting and so asked Ajit to cover for him. Ajit indicated that they would resolve the issue today as who will be staying and participating in the DT. Everyone agreed that it is more beneficial and productive if we have consistent DT participations. * Status of the taxonomy: Lily, Peyush, Petros and Emek have written some form of text for the intro section and Split AP, Split AC, but it is still very raw. Need comments on overall structure and whether it is on the right direction, not on the editorial level yet. Terminology is still missing. The matrix has been filled up by most contributors, and is expanded now. Need to discuss whether all the info there is relevant to the interoperability issue. One thing that some people noted and questioned is the divide between split MAC and split AC. * Discussion about matrix: Petros pointed out that there are largely two kinds of functions we are dealing with in the matrix, one is 802.11 defined services (related to MAC management frames), another is value-added services (like mobility support, VoIP support) which are very high level. Lily asked the question whether the value-added services are being impacted by the interface between AP and AC. If not, there is no point in considering them in the CAPWAP context. We should only document functions/services that are relevant to the interface definition down the road. Vendors can still retain their own implementaion internal to those value-added services. After some discussion, it is agreed that we can safely remove the value-added functions that don't directly impact interface issue in the matrix and just focus on those functions that need interface support, like the 802.11 services, plus configuration and management functions. * Discussion on mesh architecture: It is considered valid but different architecture from the rest of the split architectures. Jim pointed out that the interesting part to CAPWAP is that there might still be an AC in the mesh architecture that would also require similar interface as AP-AC interface. Partha asserted that for mesh architecture, we should only document the logical functions for mesh, but no physical mapping to devices. Mani sussgested that this is something we can defer for further study as well. So most people agree that we don't have enough data points for mesh right now, and we should focus on the split which we seem to understand more and come back to mesh later. * Discussion about terminology: Conceptually, people agree that we have the logical concept of AP functions (802.11 services, according to 802.11 spec). These functions are not asscociated with any particular physical boxes. They can be implemented within one box, or over multiple boxes by a network. As for the physical boxes, we have a few proposals on the table: standalone AP in the autonomous architecture; thin APs (or WTPs -- Wireless Termination Points, or Controlled AP) and AC (Access Controller) in the split architecture; mesh APs (for the distributed mesh architecture). Much discussion is whether we should use "thin AP" or "WTP". Bob expressed his ambivalent view which a few people also concurred that there are pros and cons for each. Using a new terminology (like WTP) might be a hard sell and might not stick, but if we define it clearly, it gives people a chance to unload some of their assumptions associated with existing terms and hence avoid the confusion. On the other hand, the industry has been using these terms like APs and thin APs that are more familiar to them. It is pointed out that no matter what we decide and put in the draft, a larger community will review and comment and debate. * Working plan: daily teleconference will be scheduled for 8am for the rest of the week to give a forum to resync and discuss. The task for today is to work out the details on matrix. Once we do that, we can work on text after that. If a line item needs both AP and AC, it might be an indication that finer granularity is needed to break it apart. Make your suggestions over email. _______________________________________________ Capwap-DT mailing list Capwap-DT@frascone.com http://mail.frascone.com/mailman/listinfo/capwap-dt _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From kempf@docomolabs-usa.com Wed Mar 31 21:29:29 2004 From: kempf@docomolabs-usa.com (James Kempf) Date: Wed, 31 Mar 2004 13:29:29 -0800 Subject: [Capwap] [Capwap-DT] DT teleconference minutes 03/30/2004 and some important issues that we are discussing References: <2AF68A477DD44C4EBCBE338C24E7A9EE0CDB90@orsmsx408.jf.intel.com> Message-ID: <006101c41767$3fd0b7d0$6b6115ac@dcml.docomolabsusa.com> Lilly, You're right, the charter does say network architecture taxomomy. Sorry for the confusion. jak ----- Original Message ----- From: "Yang, Lily L" To: "James Kempf" ; Sent: Wednesday, March 31, 2004 1:22 PM Subject: RE: [Capwap] [Capwap-DT] DT teleconference minutes 03/30/2004 and some important issues that we are discussing James -- I agree that the confusion is largely due to the ambiguity between logical function entity and the network/physical entity. I also like the "802.11 Access Network". But, unless I misunderstand what you said, it concerns me when you said "the WG is primarily concerned with functional architecture and not network reference architecture...". I have to disagree. I thought we are chartered to look at both (functional architecture and network architecture) and document that in the taxonomy. For example, one of the thing we are trying to work out is the functional mapping matrix. It encompasses two things: it contains a list of basic 802.11 functions and CAPWAP (control, config, etc.) functions; it also document how each vendor map those functions onto the network entities (WTP or AC). So the former is about the functional aspect, but the later is the network architecture aspect. We need to document both in this taxonomy. Now what I (personally) would like to see down the road, once we have this taxonomy reviewed by IETF and IEEE, is that IEEE can focus on the functional aspect and IETF would focus on the network architecture and protocol aspect. Let me know what you think. I want to get this right so that I can make sure the taxonomy is on the right track. Thanks, Lily -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, March 31, 2004 11:18 AM To: Yang, Lily L; capwap@frascone.com Subject: Re: [Capwap] [Capwap-DT] DT teleconference minutes 03/30/2004 and some important issues that we are discussing Lilly, I think the confusion over the term AP here might be between whether it is a functional entity or a network/physical entity (i.e. the box that implements a collection of functional entities). I think some people may want to use the term for both, which I think it might be a good idea to avoid. Since the WG is primarily concerned with functional architecture and not network reference architecture, if the term AP applies to a network entity, it would not appear in the taxonomy document. My sense is that it does, in fact, apply to the network entity, and that people do tend to mean "the box with the antenna on it" when they talk about an AP (at least, that's what I mean when I talk about an AP). Because the different vendors put different functional entities into "the box with the antenna on it", it might not be easy to get agreement on exactly what the term AP means. I think using AC for the access controller is a good idea, and I think "Wireless Termination Point" (WTP) sounds like a good term for where the wireless PHY terminates, for the functional entities. I would avoid any term that has AP in it for the functional entities, and stick to that for the network entity. I would also avoid any terms involving fat, thin, etc. Even Autonomous AP suggests a particular network reference architecture, and therfore probably doesn't belong in a functional architecture document. A term that encompasses the AC and WTP might be something like "802.11 Access Network". The Autonomous AP architecture doesn't support this, but some others, like the split MAC approach, do. jak ----- Original Message ----- From: "Yang, Lily L" To: Sent: Tuesday, March 30, 2004 8:36 PM Subject: [Capwap] [Capwap-DT] DT teleconference minutes 03/30/2004 and some important issues that we are discussing Hi, all The design team had a teleconference this morning 8am. Below you can find the minutes. The design team has been working very hard since last week to analyze the data provided by all the architecture survey contributors (THANK YOU ALL!). We will have daily teleconference for the next few days to iron out some critical issues. The current focus is to work out a functional mapping matrix that has a logical 802.11 function on each row and each architecture contributor on each column, and a mapping indication of which function is implemented by which. Once we reached some rough consensus on the matrix, we can post it to the web site for you to see and comment. Another thing being discussed several times is terminology. I would like to get some feedback from the mailing list here. So let me explain what we are up to first. The most confusing terms is, maybe surprisingly to some people -- "AP"! When people talk about AP, it can mean one of two things, but often times it is not clear which one they mean. One meaning is that physical box with antenna sticking out to which stations associate with. There is another meaning, esp. when people say "AP functions": they don't mean the functions implemented on one such physical box. They mean the logical functions which can be implemented in one box (and hence autonomous AP architecture) or in a network (like the combination of thin AP and AC) or whatever. So we believe further qualification is needed when we talk about AP or AP functions. Or, it is also suggested that, new terminology should be introduced to clarify the ambiguity. Some suggestions are: avoid using "AP functions", instead, use "802.11 functions" to mean the set of logical functions for 802.11 WLAN. Then use more explicit and different terms to refer to physical boxes (network elements). Here are a few suggestions for the physical boxes: 1) For the controller, Access Controller (AC) seems to stick now. 2) For the box that implements 802.11 PHY and receives/transmits the STA traffic: we can call it Wireless Termination Point (WTP), or thin AP or controlled AP (when it is in split architecture), or standalone AP or fat AP(when in autonomous architecture), or mesh AP (when in mesh). So feel free to comment or suggest. Thank you! Lily ----------------- teleconference minutes ------------------ CAPWAP Design Team teleconference minutes 03/30/2004 Attendees (10): Ajit (in place of Parviz), Partha, Petros, Emek, Inderpreet, Jim, Victor, Bob, Dave, Mani (chair) Discussions: * Brief discussion about Cisco participation in DT: Parviz couldn't join today's meeting and so asked Ajit to cover for him. Ajit indicated that they would resolve the issue today as who will be staying and participating in the DT. Everyone agreed that it is more beneficial and productive if we have consistent DT participations. * Status of the taxonomy: Lily, Peyush, Petros and Emek have written some form of text for the intro section and Split AP, Split AC, but it is still very raw. Need comments on overall structure and whether it is on the right direction, not on the editorial level yet. Terminology is still missing. The matrix has been filled up by most contributors, and is expanded now. Need to discuss whether all the info there is relevant to the interoperability issue. One thing that some people noted and questioned is the divide between split MAC and split AC. * Discussion about matrix: Petros pointed out that there are largely two kinds of functions we are dealing with in the matrix, one is 802.11 defined services (related to MAC management frames), another is value-added services (like mobility support, VoIP support) which are very high level. Lily asked the question whether the value-added services are being impacted by the interface between AP and AC. If not, there is no point in considering them in the CAPWAP context. We should only document functions/services that are relevant to the interface definition down the road. Vendors can still retain their own implementaion internal to those value-added services. After some discussion, it is agreed that we can safely remove the value-added functions that don't directly impact interface issue in the matrix and just focus on those functions that need interface support, like the 802.11 services, plus configuration and management functions. * Discussion on mesh architecture: It is considered valid but different architecture from the rest of the split architectures. Jim pointed out that the interesting part to CAPWAP is that there might still be an AC in the mesh architecture that would also require similar interface as AP-AC interface. Partha asserted that for mesh architecture, we should only document the logical functions for mesh, but no physical mapping to devices. Mani sussgested that this is something we can defer for further study as well. So most people agree that we don't have enough data points for mesh right now, and we should focus on the split which we seem to understand more and come back to mesh later. * Discussion about terminology: Conceptually, people agree that we have the logical concept of AP functions (802.11 services, according to 802.11 spec). These functions are not asscociated with any particular physical boxes. They can be implemented within one box, or over multiple boxes by a network. As for the physical boxes, we have a few proposals on the table: standalone AP in the autonomous architecture; thin APs (or WTPs -- Wireless Termination Points, or Controlled AP) and AC (Access Controller) in the split architecture; mesh APs (for the distributed mesh architecture). Much discussion is whether we should use "thin AP" or "WTP". Bob expressed his ambivalent view which a few people also concurred that there are pros and cons for each. Using a new terminology (like WTP) might be a hard sell and might not stick, but if we define it clearly, it gives people a chance to unload some of their assumptions associated with existing terms and hence avoid the confusion. On the other hand, the industry has been using these terms like APs and thin APs that are more familiar to them. It is pointed out that no matter what we decide and put in the draft, a larger community will review and comment and debate. * Working plan: daily teleconference will be scheduled for 8am for the rest of the week to give a forum to resync and discuss. The task for today is to work out the details on matrix. Once we do that, we can work on text after that. If a line item needs both AP and AC, it might be an indication that finer granularity is needed to break it apart. Make your suggestions over email. _______________________________________________ Capwap-DT mailing list Capwap-DT@frascone.com http://mail.frascone.com/mailman/listinfo/capwap-dt _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From lily.l.yang@intel.com Wed Mar 31 21:32:37 2004 From: lily.l.yang@intel.com (Yang, Lily L) Date: Wed, 31 Mar 2004 13:32:37 -0800 Subject: [Capwap] [Capwap-DT] DT teleconference minutes 03/30/2004 and some important issues that we are discussing Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE5C413F@orsmsx408.jf.intel.com> Thanks. Good to know we are doing the right thing :-) -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com]=20 Sent: Wednesday, March 31, 2004 1:29 PM To: Yang, Lily L; capwap@frascone.com Subject: Re: [Capwap] [Capwap-DT] DT teleconference minutes 03/30/2004 and some important issues that we are discussing Lilly, You're right, the charter does say network architecture taxomomy. Sorry for the confusion. jak ----- Original Message -----=20 From: "Yang, Lily L" To: "James Kempf" ; Sent: Wednesday, March 31, 2004 1:22 PM Subject: RE: [Capwap] [Capwap-DT] DT teleconference minutes 03/30/2004 and some important issues that we are discussing James -- I agree that the confusion is largely due to the ambiguity between logical function entity and the network/physical entity. I also like the "802.11 Access Network". But, unless I misunderstand what you said, it concerns me when you said "the WG is primarily concerned with functional architecture and not network reference architecture...". I have to disagree. I thought we are chartered to look at both (functional architecture and network architecture) and document that in the taxonomy. For example, one of the thing we are trying to work out is the functional mapping matrix. It encompasses two things: it contains a list of basic 802.11 functions and CAPWAP (control, config, etc.) functions; it also document how each vendor map those functions onto the network entities (WTP or AC). So the former is about the functional aspect, but the later is the network architecture aspect. We need to document both in this taxonomy. Now what I (personally) would like to see down the road, once we have this taxonomy reviewed by IETF and IEEE, is that IEEE can focus on the functional aspect and IETF would focus on the network architecture and protocol aspect. Let me know what you think. I want to get this right so that I can make sure the taxonomy is on the right track. Thanks, Lily -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, March 31, 2004 11:18 AM To: Yang, Lily L; capwap@frascone.com Subject: Re: [Capwap] [Capwap-DT] DT teleconference minutes 03/30/2004 and some important issues that we are discussing Lilly, I think the confusion over the term AP here might be between whether it is a functional entity or a network/physical entity (i.e. the box that implements a collection of functional entities). I think some people may want to use the term for both, which I think it might be a good idea to avoid. Since the WG is primarily concerned with functional architecture and not network reference architecture, if the term AP applies to a network entity, it would not appear in the taxonomy document. My sense is that it does, in fact, apply to the network entity, and that people do tend to mean "the box with the antenna on it" when they talk about an AP (at least, that's what I mean when I talk about an AP). Because the different vendors put different functional entities into "the box with the antenna on it", it might not be easy to get agreement on exactly what the term AP means. I think using AC for the access controller is a good idea, and I think "Wireless Termination Point" (WTP) sounds like a good term for where the wireless PHY terminates, for the functional entities. I would avoid any term that has AP in it for the functional entities, and stick to that for the network entity. I would also avoid any terms involving fat, thin, etc. Even Autonomous AP suggests a particular network reference architecture, and therfore probably doesn't belong in a functional architecture document. A term that encompasses the AC and WTP might be something like "802.11 Access Network". The Autonomous AP architecture doesn't support this, but some others, like the split MAC approach, do. jak ----- Original Message -----=20 From: "Yang, Lily L" To: Sent: Tuesday, March 30, 2004 8:36 PM Subject: [Capwap] [Capwap-DT] DT teleconference minutes 03/30/2004 and some important issues that we are discussing Hi, all The design team had a teleconference this morning 8am. Below you can find the minutes. The design team has been working very hard since last week to analyze the data provided by all the architecture survey contributors (THANK YOU ALL!). We will have daily teleconference for the next few days to iron out some critical issues. The current focus is to work out a functional mapping matrix that has a logical 802.11 function on each row and each architecture contributor on each column, and a mapping indication of which function is implemented by which. Once we reached some rough consensus on the matrix, we can post it to the web site for you to see and comment. Another thing being discussed several times is terminology. I would like to get some feedback from the mailing list here. So let me explain what we are up to first. The most confusing terms is, maybe surprisingly to some people -- "AP"! When people talk about AP, it can mean one of two things, but often times it is not clear which one they mean. One meaning is that physical box with antenna sticking out to which stations associate with. There is another meaning, esp. when people say "AP functions": they don't mean the functions implemented on one such physical box. They mean the logical functions which can be implemented in one box (and hence autonomous AP architecture) or in a network (like the combination of thin AP and AC) or whatever. So we believe further qualification is needed when we talk about AP or AP functions. Or, it is also suggested that, new terminology should be introduced to clarify the ambiguity. Some suggestions are: avoid using "AP functions", instead, use "802.11 functions" to mean the set of logical functions for 802.11 WLAN. Then use more explicit and different terms to refer to physical boxes (network elements). Here are a few suggestions for the physical boxes: 1) For the controller, Access Controller (AC) seems to stick now. 2) For the box that implements 802.11 PHY and receives/transmits the STA traffic: we can call it Wireless Termination Point (WTP), or thin AP or controlled AP (when it is in split architecture), or standalone AP or fat AP(when in autonomous architecture), or mesh AP (when in mesh). So feel free to comment or suggest. Thank you! Lily ----------------- teleconference minutes ------------------ CAPWAP Design Team teleconference minutes 03/30/2004 Attendees (10): Ajit (in place of Parviz), Partha, Petros, Emek, Inderpreet, Jim, Victor, Bob, Dave, Mani (chair) Discussions: * Brief discussion about Cisco participation in DT: Parviz couldn't join today's meeting and so asked Ajit to cover for him. Ajit indicated that they would resolve the issue today as who will be staying and participating in the DT. Everyone agreed that it is more beneficial and productive if we have consistent DT participations. * Status of the taxonomy: Lily, Peyush, Petros and Emek have written some form of text for the intro section and Split AP, Split AC, but it is still very raw. Need comments on overall structure and whether it is on the right direction, not on the editorial level yet. Terminology is still missing. The matrix has been filled up by most contributors, and is expanded now. Need to discuss whether all the info there is relevant to the interoperability issue. One thing that some people noted and questioned is the divide between split MAC and split AC. * Discussion about matrix: Petros pointed out that there are largely two kinds of functions we are dealing with in the matrix, one is 802.11 defined services (related to MAC management frames), another is value-added services (like mobility support, VoIP support) which are very high level. Lily asked the question whether the value-added services are being impacted by the interface between AP and AC. If not, there is no point in considering them in the CAPWAP context. We should only document functions/services that are relevant to the interface definition down the road. Vendors can still retain their own implementaion internal to those value-added services. After some discussion, it is agreed that we can safely remove the value-added functions that don't directly impact interface issue in the matrix and just focus on those functions that need interface support, like the 802.11 services, plus configuration and management functions. * Discussion on mesh architecture: It is considered valid but different architecture from the rest of the split architectures. Jim pointed out that the interesting part to CAPWAP is that there might still be an AC in the mesh architecture that would also require similar interface as AP-AC interface. Partha asserted that for mesh architecture, we should only document the logical functions for mesh, but no physical mapping to devices. Mani sussgested that this is something we can defer for further study as well. So most people agree that we don't have enough data points for mesh right now, and we should focus on the split which we seem to understand more and come back to mesh later. * Discussion about terminology: Conceptually, people agree that we have the logical concept of AP functions (802.11 services, according to 802.11 spec). These functions are not asscociated with any particular physical boxes. They can be implemented within one box, or over multiple boxes by a network. As for the physical boxes, we have a few proposals on the table: standalone AP in the autonomous architecture; thin APs (or WTPs -- Wireless Termination Points, or Controlled AP) and AC (Access Controller) in the split architecture; mesh APs (for the distributed mesh architecture). Much discussion is whether we should use "thin AP" or "WTP". Bob expressed his ambivalent view which a few people also concurred that there are pros and cons for each. Using a new terminology (like WTP) might be a hard sell and might not stick, but if we define it clearly, it gives people a chance to unload some of their assumptions associated with existing terms and hence avoid the confusion. On the other hand, the industry has been using these terms like APs and thin APs that are more familiar to them. It is pointed out that no matter what we decide and put in the draft, a larger community will review and comment and debate. * Working plan: daily teleconference will be scheduled for 8am for the rest of the week to give a forum to resync and discuss. The task for today is to work out the details on matrix. Once we do that, we can work on text after that. If a line item needs both AP and AC, it might be an indication that finer granularity is needed to break it apart. Make your suggestions over email. _______________________________________________ Capwap-DT mailing list Capwap-DT@frascone.com http://mail.frascone.com/mailman/listinfo/capwap-dt _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap