Status Update of CAPWAP Architecture Taxonomy

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

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 IEEEIETF comments and rewrote
  section on distributed arch.
• July
• More comments and discussion at the mailing list
• V04 incorporated above comments)
• Aug

4
Design Team

• Lily Yang (Intel, Editor)
• Petros Zerfos (UCLA)
• Sadot, Emek (Avaya)
• Ajit Sanzgiri (Cisco Systems)
• Bob OHara (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)

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

6
16 Architecture Survey Submissions

• 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

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
8
Autonomous Architecture Traditional WLAN
Architecture
STA 5
STA 1
STA2
STA 3
STA 4
AP
AP
AP
External Network

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

9
Centralized Architecture
STA 5
STA2
STA 1
STA 3
STA 4
WTP
WTP
WTP
Access Controller (AC)
External Network

• WTP AC together implements AP functions
• Advantages of AC
• centralized controller(s) gt manageability for
  large networks
• network wide visibility gt better coordination
  across the network
• Challenges
• no standard way of splitting AP functions onto
  WTP and AC

Current State of Art No interoperability
10
From Autonomous to Centralized
AP Functionality
MAC
PHY
Control Config
Autonomous (1)
WTP
Local MAC (5)
MAC
PHY
Control Config
WTP
AC
Split MAC (6)
Real Time MAC
PHY
Non RT MAC
Control Config
WTP
AC
Real Time MAC
PHY
Non RT MAC
Control Config
Remote MAC (1)
AC
WTP
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
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
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
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?

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,
)
16
Design Team Mission Accomplished (almost)THANK
YOU

• Lily Yang (Intel, Editor)
• Petros Zerfos (UCLA)
• Sadot, Emek (Avaya)
• Ajit Sanzgiri (Cisco Systems)
• Bob OHara (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)