CAPWAP Arch-Draft Issues IETF 59, Seoul 4 March 2004.

Slides:



Advertisements
Similar presentations
802.1AF - directions define requirements to find and create connections in terms of Discovery - Authentication - Enable 1.Discover of what can be done.
Advertisements

Extended Service Set (ESS) Mesh Network Daniela Maniezzo.
Doc.: IEEE /481r3 Submission May 2004 Lily Yang, Steve Shellhammer, IntelSlide 1 Thoughts on AP Functional Descriptions L. Lily Yang Steve Shellhammer.
Doc.: IEEE /604r0 Submission May 2004 Darwin Engwer, Nortel Networks; Lily Yang, Intel Corp.Slide 1 AP Functional Descriptions Update Darwin Engwer,
CAPWAP Architecture draft-mani-ietf-capwap-arch-00 Mahalingam Mani Avaya Bob O’Hara Airespace Lily Yang Intel.
Doc.: IEEE /250r2 Submission March 2004 Lily Yang, IETF CAPWAP Design Team EditorSlide WLAN Architectural Considerations for IETF CAPWAP.
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Application Considerations in Handover Date Submitted: July, 15, 2004 Presented at.
69th IETF Chicago IETF BMWG WLAN Switch Benchmarking Tarunesh Ahuja, Tom Alexander, Scott Bradner, Sanjay Hooda, Jerry Perser, Muninder Sambi.
1 Capwap issues.PPT / DD-MM-YYYY / Initials CAPWAP Issues.
CAPWAP BOF Control And Provisioning of Wireless Access Points James Kempf DoCoMo Labs USA Dorothy Stanley Agere Systems WAP!
IEEE Wireless LAN Standard
66th IETF Meeting Montreal IETF BMWG WLAN Switch & Mesh Benchmarking Jerry Perser
67th IETF San Diego IETF BMWG WLAN Switch Benchmarking Jerry Perser, Tom Alexander, Muninder Singh Sambi,
Wireless Network Security. Wireless Security Overview concerns for wireless security are similar to those found in a wired environment concerns for wireless.
Light Weight Access Point Protocol (LWAPP) IETF 57 Pat Calhoun, Airespace.
Wireless and Security CSCI 5857: Encoding and Encryption.
CAPWAP related draft-shao-opsawg-capwap-hybridmac-00 draft-chen-opsawg-capwap-extension-00 draft-zhang-opsawg-capwap-eap-00.
Doc.: IEEE /0981r1 TGs Reference Architecture Considerations September 6, 2004 Tricci So & W. Steven Conner.Slide 1 TGs ESS Mesh System Reference.
Profiling Metadata Specifications David Massart, EUN Budapest, Hungary – Nov. 2, 2009.
CAPWAP Overview Saag Presentation 65 th IETF 23 March 2006 Scott G. Kelly T. Charles Clancy
1 Path-decoupled signaling - towards a BOF in SF NSIS working group context Path-decoupled signalling - definition –Path-oriented.
CAPWAP Overview SAAG Presentation 65 th IETF 23 March 2006 Scott G. Kelly T. Charles Clancy
Status of CAPWAP Architecture Draft Lily Yang Intel Corp. March 3, th IETF meeting.
Doc.: IEEE /0498r0 Submission April 2008 Eldad Perahia, Intel CorporationSlide 1 Modifications to the 60GHz PAR & 5 C’s Proposal Date:
Yang Shi (Richard), Yong Zhang IETF 74 th 26 March 2009, San Francisco CAPWAP WG MIB Drafts Report.
Doc.: IEEE /0638r0 Submission May 2004 Bernard Aboba, MicrosoftSlide 1 Network Selection Bernard Aboba Microsoft
Doc.: IEEE /595r2 Submission May 2002 Lily Yang, Tyan-Shu JouSlide 1 Mesh Relevance in CAPWAP and AP Functional Descriptions L. Lily Yang (Intel.
Status Update of CAPWAP Architecture Taxonomy Lily Yang (Editor) Intel Corp. August 4, th IETF meeting.
CAPWAP Taxonomy Recommendations Pat R. Calhoun, Cisco Systems Bob O’Hara, Cisco Systems Inderpreet Singh, Chantry Networks.
Lecture 24 Wireless Network Security
March 2006 CAPWAP Protocol Specification Update March 2006
Doc.: IEEE 11-04/0319r0 Submission March 2004 W. Steven Conner, Intel Corporation Slide 1 Architectural Considerations and Requirements for ESS.
The mandate of this working group is to facilitate effective service interoperability utilizing SIP in heterogeneous network environments as noted below.
62 nd IETF – CAPWAP Working Group1 CAPWAP Objectives Saravanan Govindan March 2005.
Issue #138 CAPWAP WG Meeting IETF 68, Prague. Issue 138 #138: Support and Negotiation of WTP data encryption in the CAPWAP protocol Proposed solution.
CAPWAP Working Group MIB documents IETF 65 David T. Perkins.
Privecsg Privacy Recommendation PAR Proposal Date: [ ] Authors: NameAffiliationPhone Juan Carlos ZúñigaInterDigital
Doc.: IEEE /0371r0 Submission May 2005 S. McCann & E. Hepworth, Siemens Roke ManorSlide 1 IEEE 802 Architecture Issues Notice: This document has.
IETF #65 Network Discovery and Selection Problem draft-ietf-eap-netsel-problem-04 Farooq Bari Jouni Korhonen.
Doc.: IEEE /084r0 Submission March 2000 David Skellern, RadiataSlide 1 Comments by P WLAN WG on P WPAN High Rate Study Group PAR 7.
PMIPv6 inter-working with WiFi Access Authentication draft-liebsch-netext-pmip6-authiwk M. Liebsch, S.Gundavelli, P.Seite IETF83, NETEXT WG March 2012.
Re-cap & Next Steps Mahalingam Mani. The WG Now and from Now The main deliverables have progressed close to completion for this charter Problem statement.
Issue EAPoL-Key message generation at WTP or AC Issue 199, summarized as:...the WTP maintains the KeyRSC while the AC requires this information to.
1 IETF 91, 10 Nov 2014draft-behringer-anima-reference-model-00.txt A Reference Model for Autonomic Networking draft-behringer-anima-reference-model-00.txt.
Franco Travostino and Admela Jukan jukan at uiuc.edu June 30, 2005 GGF 14, Chicago Grid Network Services Architecture (GNSA) draft-ggf-ghpn-netserv-2.
IEEE Wireless LAN Standard
Hybrid-MAC Model for CAPWAP draft-ietf-opsawg-capwap-hybridmac-00 Presenting: Hui Deng:
Doc.: IEEE /0103r0 Submission January 2004 Jesse Walker, Intel CorporationSlide 1 Some LB 62 Motions January 14, 2003.
© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 1 © 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential.
Shi Yang David T. Perkins IETF 70th 3 Dec 2007, Vancouver
Mesh Relevance in CAPWAP and AP Functional Descriptions
IETF Liaison Report November 2003 Dorothy Stanley – Agere Systems
Proposal for IEEE solution
WLAN Mesh in CAPWAP Architecture
Network Selection Bernard Aboba Microsoft
P802.11aq Waiver Request Additional Information
CAPWAP Architectural Requirements on
Mesh Relevance in CAPWAP and AP Functional Descriptions
IETF Liaison Report November 2004 Dorothy Stanley – Agere Systems
WLAN Mesh in CAPWAP Architecture
Mesh Relevance in CAPWAP and AP Functional Descriptions
AP Function Classification & Requirements
AP Functional Needs of CAPWAP
Network Selection Bernard Aboba Microsoft
Thoughts on AP Functional Descriptions
Thoughts on AP Functional Descriptions
WLAN Architectural Considerations for IETF CAPWAP
WLAN Architectural Considerations for IETF CAPWAP
AP-AC communications and Functional Architecture
The Need for an AP Functional Description
Presentation transcript:

CAPWAP Arch-Draft Issues IETF 59, Seoul 4 March 2004

#1: Data-forwarding Datapath should not be required to traverse AC. This draft (on architectural taxonomy) does not require data forwarding through AC. But it does intend to include description of architectural variant(s) which do(es)

#2: CAPWAP focus CAPWAP is too narrowly focused on IEEE The WG has gone through enough analysis to justify the identified need in WLAN space. –This alone calls for enough interface clarity in architecture. Need to minimize scope to limit complexity and reach consensus across SDOs and vendors any shortcomings to the approach may be argued through drafts articulated well enough to justify it.

3#: CAPWAP & Routing CAPWAP is about distributed routing. CAPWAP is intended to describe ability to monitor, control and provision AP elements across a RF/wireless domain. Routing between APs & Network Infrastructure is an optional consequence.

#4: Capabilities negotiation Capabilities negotiation described in architecture draft – how does it help interoperability? The intent is to deduce functional capabilities APs (and AC combine to) provide. No clear answers yet. While outside scope of the charter now – this is the basis of exercise to agree on a AP & AC interworking.

#5: Capabilities Will this lead to implementing all variants in APs and ACs? Capabilities are intended to identify the scope of AP functions. Taken together with IEEE work on AP functions should lead to a well defined functional balance

#6: Terminology – AC, AR, AB The usage of AB, AR and AC are inconsistent with the definition of terms Fix definition & usage. –Access Controller (AC) - can be an AB or an AR. Signifies the control plane rather than datapath –AB - Access Bridge only applies to controllers that are capable of direct-connect or L2 connected. –AR - Access Router applies to controllers that are capable of L3/IP connect.

#7: AP & AR name How do APs and ACs know each other’s names in CAPWAP? For an entity to be managed it needs to have an identity Current CAPWAP draft does not discuss namespace Identity must be authenticated (such as a subjectname in a cert.) and reliably securely provisioned. The taxonomy will try to describe current schemes.

#8: Interoperability How do we get to an interoperable WLAN backend? –Is it by defining one reference WLAN model? –Is there only one possible model that’s right? –What is the route to CAPWAP? all-embracing – all APs to all ACs? Identify one functional distribution approach that’s scalable? By defining functions that CAPWAP wants to decentralize and arriving at the right distribution of functions preserving IEEE WLAN semantics More?

#9: RRM Distribution Where should RRM (Radio Resource Management) reside? AP provides measurements, AC manages The draft to expand on RRM approaches and their Pros & Cons

#10: AC registration AP should be authenticating to only one AC. the Discovery section describes it being authenticated to more than one available AC The AP will actively be associated to only one AC at a time – managed by one instance of AC. It may be capable of registering with another upon an AC failure.

#11: Distribution & Integration “every AP is its own, isolated ESS and no APs actually implement the architecture described in the standard” How should distribution and integration be ‘distributed’ to scale?

#12: TSN, TKIP, RSN confuses TSN & TKIP PSK can be used in TSN, RSN RSN is based on RSNA-only BSS; TSN can be a mix of WEP, TKIP, RSNA capable devices.

#13: Motivation section seems to prefer one type of data-forwarding. appears to imply other wireless technologies MAC are splittable. Neither are implied. Data forwarding requirement through AC is not mandated. The mention of split does not make any assumptions about MAC- split vs. AP split: it means functional split. The section will be restructured to reflect taxonomy goals.

#14: ForCES, DIRAC etc. Comparison of ForCES, DIRAC to LWAPP is premature. This section of document, while less significant to the current charter, is discussing prior art. The intent is to reference possible relevant work already done. Comparisons to LWAPP currently may be removed. –However, LWAPP as now adopted by some vendors may be another prior art (not draft submitted to IETF) to discuss, besides other open protocols/architectures.

#1: PS draft Issue Incompatibilities arising due to different types of functional splits is an issue to be addressed