1 / 16

Status Update of CAPWAP Architecture Taxonomy

Status Update of CAPWAP Architecture Taxonomy. Lily Yang (Editor) Intel Corp. August 4, 2004 60 th IETF meeting. Overview. What happened since last IETF? Learning from the taxonomy work (v04) Conclusions. Draft History Since 59 th IETF. March:

claudiam
Download Presentation

Status Update of CAPWAP Architecture Taxonomy

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Status Update ofCAPWAPArchitecture Taxonomy Lily Yang (Editor) Intel Corp. August 4, 2004 60th IETF meeting

  2. Overview • What happened since last IETF? • Learning from the taxonomy work (v04) • Conclusions 60th IETF: CAPWAP Arch. Taxonomy

  3. Draft History Since 59th IETF • March: • V00: minor revision from the individual draft • 59th IETF at Seoul: Design Team (12 people) • Architecture Survey (14 submissions) • Presented to IEEE 802.11, started discussion on AP Functional Description • April: major rewrite of the draft • v01: basic outline of the architecture landscapes, adopting Matrix for data representation • V02: refinement of text and draft organization • May: • IEEE 802.11 review (50+ comments) • IETF CAPWAP WG mailing list comments • IEEE 802.11 WG approved formation of new SG for AP Functional Description • June: • 2 more survey submissions (mesh vendors) • V03: incorporated IEEE+IETF comments and rewrote section on distributed arch. • July: • More comments and discussion at the mailing list • V04:incorporated above comments) • Aug: • Received comments from security review • Plan to do v05 next week: incorporate comments from above • Ready for WG last call => Informational RFC 60th IETF: CAPWAP Arch. Taxonomy

  4. Design Team • Lily Yang (Intel, Editor) • Petros Zerfos (UCLA) • Sadot, Emek (Avaya) • Ajit Sanzgiri (Cisco Systems) • Bob O’Hara (AireSpace) • Dave Hetherington (Roving Planet) • Inderpreet Singh (Chantry Networks) • Jim Murphy (Trapeze Networks) • Matt Holdrege (Strix Systems) • Partha Narasimhan (Aruba Wireless Networks) • Peyush AGARWAL (STMicroelectronics) • Victor Lin (Extreme Networks) 60th IETF: CAPWAP Arch. Taxonomy

  5. Architecture Survey Template • Design considerations & requirements • WLAN functions supported • The functional architecture to implement the functions described • The protocol used between network entities • Network connectivity assumptions (L2 or L3) • Security Analysis • Pros and Cons 60th IETF: CAPWAP Arch. Taxonomy

  6. AireSpace Aruba Wireless Networks Avaya Chantry Networks Cisco Sytems Cranite Systems Extreme Networks, Instant802 Intoto Janusys Networks Nortel Networks Panasonic Strix Systems Symbol Trapeze UCLA 16 Architecture Survey Submissions 60th IETF: CAPWAP Arch. Taxonomy

  7. CAPWAP Architecture Taxonomy Autonomous Architecture * Self-contained controller 802.11 WLAN Architectures Centralized Architecture * Centralized controller Distributed Architecture * Distributed control across multiple nodes Categorized Largely by Control Plane Characteristics 60th IETF: CAPWAP Arch. Taxonomy

  8. Autonomous Architecture: Traditional WLAN Architecture STA 5 STA 1 STA2 STA 3 STA 4 • Autonomous (standalone) AP: “fat” and self-contained AP • No explicit infrastructure support for “wireless” • Each AP provides most of the WLAN functions including “distribution”, “integration” and other L3 services within itself. AP AP AP External Network 60th IETF: CAPWAP Arch. Taxonomy

  9. Centralized Architecture STA 5 STA2 STA 1 STA 3 STA 4 • “WTP + AC” together implements AP functions • Advantages of AC: • centralized controller(s) => manageability for large networks • network wide visibility => better coordination across the network • Challenges: • no standard way of splitting AP functions onto WTP and AC WTP WTP WTP Access Controller (AC) External Network Current State of Art: No interoperability 60th IETF: CAPWAP Arch. Taxonomy

  10. From Autonomous to Centralized AP Functionality PHY MAC Control & Config Autonomous (1) WTP Local MAC (5) PHY MAC Control & Config WTP AC Split MAC (6) PHY Real Time MAC Non RT MAC Control & Config WTP AC PHY Real Time MAC Non RT MAC Control & Config Remote MAC (1) AC WTP 60th IETF: CAPWAP Arch. Taxonomy

  11. Functional Distribution Matrix for Local MAC Arch7 Arch8 Arch9 Arch10 Arch11 ----- ----- ----- ------ ------ connectivity L3 L3 L3 L3 L3 802.11 mgmt termination WTP WTP WTP WTP WTP 802.11 control termination WTP WTP WTP WTP WTP 802.11 data aggregation AC AC WTP AC WTP 60th IETF: CAPWAP Arch. Taxonomy

  12. Functional Distribution Matrix for Split MAC Arch1 Arch2 Arch3 Arch4 Arch5 Arch6 ----- ----- ----- ------ ------ ------ connectivity L3 L3 L3 L2 L3 L3 802.11 mgmt termination AC AC AC AC AC/WTP AC 802.11 control termination WTP WTP WTP WTP WTP WTP 802.11 data aggregation AC AC AC AC AC AC Different than Local MAC Same as Local MAC 60th IETF: CAPWAP Arch. Taxonomy

  13. From Centralized to Distributed: Mesh Example • Data plane: de-centralized, multi-hop • Control plane: can be either • Centralized, or • Distributed (via peer-to-peer mesh interface), or • Hybrid STA 5 STA 1 STA2 STA 3 STA 4 WTP #2 WTP #1 WTP #3 AC Portal External Network 60th IETF: CAPWAP Arch. Taxonomy

  14. Summary • 3 distinct architecture families: • Autonomous (traditional) • Centralized (current generation) • Distributed (emerging, 802.11 TGs) • Among the centralized architecture family: 3 sub-categories • Remote MAC: severe constraints on AC-WTP inter-connection & WTP capability • Local MAC: there exists enough commonality that should make cross-vendor interoperability feasible. • Split MAC: cross-vendor interoperability should also be feasible. • Harder question: Interoperability across architectures (e.g. between local MAC & Split MAC)? • Is it necessary? • Is it feasible? • Next Steps: • Define the exact interoperability scope for the protocol(s) • Target architecture(s) • If multiple architectures: Same or different protocols? 60th IETF: CAPWAP Arch. Taxonomy

  15. Proposed Next Steps Sept IESG review for Informational RFC publication Aug V05: WG Last call Re-charter for Protocol work: define the scope for interoperability Protocol Proposal(s) (architecture assumptions, Protocol requirements, …) 60th IETF: CAPWAP Arch. Taxonomy

  16. Design Team Mission Accomplished (almost)THANK YOU • Lily Yang (Intel, Editor) • Petros Zerfos (UCLA) • Sadot, Emek (Avaya) • Ajit Sanzgiri (Cisco Systems) • Bob O’Hara (AireSpace) • Dave Hetherington (Roving Planet) • Inderpreet Singh (Chantry Networks) • Jim Murphy (Trapeze Networks) • Matt Holdrege (Strix Systems) • Partha Narasimhan (Aruba Wireless Networks) • Peyush AGARWAL (STMicroelectronics) • Victor Lin (Extreme Networks) 60th IETF: CAPWAP Arch. Taxonomy

More Related