Network Working Group
`Internet-Draft
`Expires: April 19, 2004
`
`M. Mani
`Avaya Inc.
`B. O'Hara
`Airespace
`L. Yang
`Intel Corp.
`October 20, 2003
`
`Architecture for Control and Provisioning of Wireless Access
`Points(CAPWAP)
`draft-mani-ietf-capwap-arch-00
`
`Status of this Memo
`
` This document is an Internet-Draft and is in full conformance with
` all provisions of Section 10 of RFC2026.
`
` Internet-Drafts are working documents of the Internet Engineering
` Task Force (IETF), its areas, and its working groups. Note that other
` groups may also distribute working documents as Internet-Drafts.
`
` Internet-Drafts are draft documents valid for a maximum of six months
` and may be updated, replaced, or obsoleted by other documents at any
` time. It is inappropriate to use Internet-Drafts as reference
` material or to cite them other than as "work in progress."
`
` The list of current Internet-Drafts can be accessed at http://
` www.ietf.org/ietf/1id-abstracts.txt.
`
` The list of Internet-Draft Shadow Directories can be accessed at
` http://www.ietf.org/shadow.html.
`
` This Internet-Draft will expire on April 19, 2004.
`
`Copyright Notice
`
` Copyright (C) The Internet Society (2003). All Rights Reserved.
`
`Abstract
`
` While conventional wisdom has it that Wireless Access Points are
` strictly Layer 2 bridges, such devices today perform some higher
` layer functions of routers or switches in wired Infrastructure in
` addition to bridging the wired and wireless networks. For example,
` in 802.11 networks, Access Points can function as Network Access
` Servers. For this reason, Access Points have IP addresses and can
` function as IP devices.
`
`Mani, et al.
`
`Expires April 19, 2004
`
`[Page 1]
`
`Exhibit 1008
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000001
`
`

`

`Internet-Draft CAPWAPA October 2003
`
` This Document analyzes WLAN (Wireless LAN) functions and services;
` and describes a flexible balance of such AP (Access Point) functions
` as allowed in the Standards and practiced in the industry, to be
` meaningfully split between lightweight Access Point (LAP) framework
` and AP Controllers or AR (Access Router) framework managing them.
`
`Table of Contents
`
` 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
` 1.1 Conventions used in this document . . . . . . . . . . . . . 4
` 1.2 CAPWAP Purpose and Scope . . . . . . . . . . . . . . . . . . 4
` 1.3 Document Organization . . . . . . . . . . . . . . . . . . . 4
` 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
` 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7
` 3.1 The IEEE 802.11 in Brief . . . . . . . . . . . . . . . . . . 7
` 3.2 CAPWAP Motivation . . . . . . . . . . . . . . . . . . . . . 9
` 3.3 AP to AR Network Topology Considerations . . . . . . . . . . 10
` 4. CAPWAP Component Architecture . . . . . . . . . . . . . . . 12
` 4.1 WLAN functions and Services . . . . . . . . . . . . . . . . 12
` 4.1.1 Access Point Functions and Services . . . . . . . . . . . . 14
` 4.1.2 Access Controller Functions and Services . . . . . . . . . . 14
` 4.1.3 Other Conventional WLAN Functions and Services . . . . . . . 15
` 4.1.4 Architectural Trends . . . . . . . . . . . . . . . . . . . . 15
` 4.2 CAPWAP Network Topology . . . . . . . . . . . . . . . . . . 16
` 4.2.1 Functional Distribution of WLAN Services . . . . . . . . . . 16
` 4.2.2 AP to AR Topologies . . . . . . . . . . . . . . . . . . . . 16
` 4.3 CAPWAP Security . . . . . . . . . . . . . . . . . . . . . . 18
` 4.3.1 WLAN Security . . . . . . . . . . . . . . . . . . . . . . . 19
` 4.3.2 Mutual Authentication of AP and AR . . . . . . . . . . . . . 20
` 4.3.3 Path Security of AP and AR . . . . . . . . . . . . . . . . . 21
` 4.4 AP Provisioning . . . . . . . . . . . . . . . . . . . . . . 21
` 4.4.1 AP Identity . . . . . . . . . . . . . . . . . . . . . . . . 21
` 4.4.2 AP Configuration . . . . . . . . . . . . . . . . . . . . . . 21
` 4.4.3 Access Router Availability . . . . . . . . . . . . . . . . . 21
` 4.5 Access Point Service Management . . . . . . . . . . . . . . 22
` 4.5.1 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . 22
` 4.5.2 Control . . . . . . . . . . . . . . . . . . . . . . . . . . 22
` 4.6 Access Router Discovery . . . . . . . . . . . . . . . . . . 23
` 4.6.1 Access Router Availability . . . . . . . . . . . . . . . . . 23
` 4.6.2 Capabilities Negotiation . . . . . . . . . . . . . . . . . . 23
` 4.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 24
` 5. Prior Work . . . . . . . . . . . . . . . . . . . . . . . . . 25
` 5.1 DIRAC . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
` 5.2 ForCES . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
` 5.2.1 Similarities in Objectives and Architectural
` Considerations . . . . . . . . . . . . . . . . . . . . . . . 26
` 5.2.2 Overlap in Topology Considerations . . . . . . . . . . . . . 27
` 5.2.3 Differences in Design Approach . . . . . . . . . . . . . . . 27
`
`Mani, et al. Expires April 19, 2004 [Page 2]
`
`Exhibit 1008
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000002
`
`

`

`Internet-Draft CAPWAPA October 2003
`
` 5.2.4 Differences in the Functionality Controlled . . . . . . . . 27
` 5.2.5 Similarties in Security Requirements . . . . . . . . . . . . 27
` 5.2.6 Difference in Operation Scope . . . . . . . . . . . . . . . 28
` 5.2.7 Comparision in Protocols . . . . . . . . . . . . . . . . . . 28
` 6. Security Considerations . . . . . . . . . . . . . . . . . . 29
` 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
` References . . . . . . . . . . . . . . . . . . . . . . . . . 31
` Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 32
` Intellectual Property and Copyright Statements . . . . . . . 33
`
`Mani, et al. Expires April 19, 2004 [Page 3]
`
`Exhibit 1008
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000003
`
`

`

`Internet-Draft CAPWAPA October 2003
`
`1. Introduction
`
`1.1 Conventions used in this document
`
` The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
` "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
` document are to be interpreted as described in RFC 2119 [7].
`
`1.2 CAPWAP Purpose and Scope
`
` The purpose of CAPWAP work is to define the framework reflecting the
` architectural trend that delegates and aggregates selected WLAN
` functions and services from APs to ARs to enhance WLAN resource
` management. On the basis of such definition CAPWAP aims to provide a
` secure protocol to enable AP-to-AR communications and AP provisioning
` & management.
`
`1.3 Document Organization
`
` Overview section describes the IEEE 802.11 WLAN architecture and
` services in brief followed by AP-AR network topological
` considerations leading to CAPWAP motivation.
`
` Subsequent section describes the CAPWAP architecture and its
` components.
`
` The section that follows discusses related research work and an
` applicable standards topology.
`
` The document concludes with Security Considerations which are also
` discussed in Architecture.
`
`Mani, et al. Expires April 19, 2004 [Page 4]
`
`Exhibit 1008
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000004
`
`

`

`Internet-Draft CAPWAPA October 2003
`
`2. Terminology
`
` LWAP: Lightweight Access Point
`
` AB/AR: Access Bridges/Routers
`
` AC: Access Controllers
`
` AP: access point
`
` BSS: basic service set
`
` ESS: extended service set
`
` SSID: service set identifier
`
` WLAN: wireless local area network
`
` RSN: robust security network
`
` TSN: transition security network
`
` PMK: pair-wise master key
`
` PTK: pair-wise transient key
`
` TK: temporal key
`
` GMK: group master key
`
` GTK: group transient key
`
` KCK: key confirmation key
`
` KEK: key encryption key
`
` PSK: pre-shared key
`
` WEP: wired equivalent privacy
`
` Throughout the document the terminologies of AR (Access Router), AC
` (Access Controller) and AB (Access Bridge) are used synonymously in
` contexts of allowable network topology arguments. In other cases the
` distinction is called out explicityl.
`
` However, at the outset AC is to be assumed the generic term for the
` entity with which an AP registers or associates - which terms will
` be qualified later in the CAPWAP architecture sections (Section 4).
`
`Mani, et al. Expires April 19, 2004 [Page 5]
`
`Exhibit 1008
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000005
`
`

`

`Internet-Draft CAPWAPA October 2003
`
` AR is called out in the context that the Access Controller that an AP
` associates with is over an allowed L3 cloud between the wired network
` backend of APs and the ACs.
`
` Access Bridge (or WLAN switch) is called out in the context of such
` network cloud or connectivity may be over a predominantly L2 network.
`
` It may be observed in following sections that the proposed
` architecture chooses to stay agnostic and equivalent to either
` Network Protocol and focuses on the interface and generic
` encapsulation that shall allow for both. The Protocol MAY end up
` specifying merely for IP.
`
`Mani, et al. Expires April 19, 2004 [Page 6]
`
`Exhibit 1008
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000006
`
`

`

`Internet-Draft CAPWAPA October 2003
`
`3. Overview
`
` Prior to setting out on details, a snapshot of WLAN standards are in
` order to put the CAPWAP motivation and standardization benefits in
` perspective, particularly when the required interfaces appear in the
` landscape bordering L2 and L3 standards scope.
`
`3.1 The IEEE 802.11 in Brief
`
` The IEEE 802.11 standard for wireless local area networks [1]
` specifies a MAC protocol, several PHYs, and a MAC management
` protocol. Each of these operates over the air, between two or more
` 802.11 devices. 802.11 also describes how mobile devices can
` associate together into a basic service set (BSS), the rough
` equivalent of a single broadcast domain or a segment of a bridged
` Ethernet LAN. A BSS is identified by a common service set identifier
` (SSID) or name. An SSID is an arbitrary byte string, up to 32 bytes
` long, though most implementations utilize ASCII strings for
` readability. 802.11 also describes the functionality of a specific
` device, called an access point (AP), that translates frames between
` mobile 802.11 devices and hosts on a wired network. When more than
` one AP is connected via a broadcast layer 2 network and all are using
` the same SSID, an extended service set (ESS) is created. An ESS is
` also similar to a single broadcast domain, where a mobile device
` associated with one AP can successfully ARP for the address of a
` mobile device associated with any other AP in the ESS. Within an
` ESS, a mobile station can roam from one AP to another through only
` layer 2 transitions coordinated by the 802.11 MAC management
` protocol. Higher layer protocols, including IP are unaware that the
` network attachment point of the mobile device has moved.
`
` The 802.11 working group is currently proceeding on work related to
` layer 2 security and quality of service. The 802.11i task group is
` addressing the security issues of the original 802.11 standard in the
` areas of authentication and encryption. This work refers to other
` standards, including 802.1X Port Based Access Control [14] and the
` Extensible Authentication Protocol [9]. The 802.11e task group is
` addressing layer 2 quality of service items through extending the
` access method, frame definitions, and MAC management protocol of the
` original standard. This work refers to the 802.1Q [15] standard.
`
` 802.11 PHYs are wireless, by definition, and principally use radio
` technology for communication. An aspect of an 802.11 WLAN that is
` not addressed by the standard is the necessity to manage the
` self-interference of one AP when operating on a radio channel equal
` to or near the radio channel of another AP within reception range.
` Managing self-interference within the WLAN involves both measurement
` of the level of interference, as well as control of the transmit
`
`Mani, et al. Expires April 19, 2004 [Page 7]
`
`Exhibit 1008
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000007
`
`

`

`Internet-Draft CAPWAPA October 2003
`
` power and transmitting channel in each of the APs. Work currently in
` process in the 802.11k task group is addressing the issue of radio
` resource measurement, which will provide the information on level of
` interference, among other things.
`
` Some definitions of 802.11 terminology is in order, since it is
` unique to the 802.11 standard.
`
` * "Distribution" is the service of forwarding MSDUs for an
` associated station by an AP. As it is described in 802.11,
` distribution by an AP is providing sufficient information to
` enable a frame received from an associated station to be
` successfully delivered to its proper destination. For the most
` part, this involves translating the frame format from 802.11 to
` Ethernet (typically) and removing any SNAP encapsulation that was
` applied to the 802.11 frame, due to its lack of an equivalent to
` the Ethertype field. This is similar to standard bridging, except
` that 802.11 APs are not 802.1D bridges. APs typically do not
` implement spanning tree protocols or algorithms. They are
` considered to be edge devices, connected only to leaf nodes with
` no further bridging taking place down stream from them. This is
` not always a valid assumption and can sometimes result in
` unanticipated bridging loops.
`
` * "Integration" is a concept unique to 802.11 that is a result of
` the underlying architecture. 802.11 considers that the individual
` APs that make up a WLAN, an extended service set (ESS) in 802.11
` terminology, are connected by a closed system, called the
` distribution system. Only frames that are "within" the ESS are
` carried by the distribution system. This includes frames that are
` moving from one AP to another for delivery to a mobile station,
` frames received from outside the ESS for delivery to a mobile
` station, and frames from a mobile station to be delivered outside
` the ESS. Connecting the closed distribution system to the outside
` world is a "portal". The portal is the single point at which the
` distribution system exchanges frames with the network outside of
` the ESS.
`
` The problem with the 802.11 architecture, or maybe just with the AP
` implementations, is that AP implementations do not adhere to this
` architecture. An AP typically implements both the distribution and
` integration services, and the portal function, inside the skin of the
` AP. In this sense, every AP is its own, isolated ESS and no APs
` actually implement the architecture described in the standard. When
` a set of APs is connected together to create a WLAN, what is actually
` created is a set of independent ESSs that happen to communicate, in
` spite of the implementation.
`
`Mani, et al. Expires April 19, 2004 [Page 8]
`
`Exhibit 1008
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000008
`
`

`

`Internet-Draft CAPWAPA October 2003
`
` In addition to the 802.11 standard, the 802.11 working group produced
` a recommended practice for inter-AP communication, 802.11F [12]. The
` recommended practice describes the use of a new application protocol,
` the Inter-AP Protocol (IAPP), carried on UDP or TCP. It permits APs
` to exchange information about roaming mobile devices, including an
` envelope for general context transfer purposes, and to push layer 2
` keying information to neighboring APs in preparation for the roaming
` of mobile devices to those neighboring APs. The recommended practice
` specifies the use of 802.2 XID frames for updating layer 2 devices
` when a mobile device's point of attachment to the network has changed
` due to a roaming event. 802.11F also specifies the use of RADIUS for
` the authentication of one AP to another and, along with portions of
` the IAPP protocol, to establish secure IAPP packets exchanged between
` participating APs.
`
` The IAPP is not applicable to this architecture, though it may be
` implemented in the access controller for communication with other
` access controllers as 802.11 intended it to be used between
` individual APs. It is not applicable within the CAPWAP architecture
` because, presumably, the communications defined by CAPWAP would be
` internal to the access controller and not require such a protocol to
` be utilized.
`
`3.2 CAPWAP Motivation
`
` As evidenced over the past few months, there is overwhelming support
` in the market for a new WLAN architecture. This architecture moves
` much of the functions that would reside in a traditional access point
` (AP) to a centralized access router (AR). Some of the benefits that
` come out of this new architecture include:
`
` o Ease of Use: By centrally managing a WLAN as a system rather than
` as a series of discrete components, management and control of the
` WLAN is much easier
`
` o Increased Security: Having a centralized AR enforce policies and
` being able to detect potential threats across a much larger RF
` domain increases the security of the network.
`
` o Enhanced Mobility: By terminating the WLAN "management" protocol
` in the AR, these messages may be used as "mobility triggers",
` providing mobility across an RF domain without the need for any
` client software.
`
` o Quality of Service: By allowing the centralized AR manage the RF
` links, offers systemic perspective to perform efficient load
` balancing across multiple Access Points - thus increasing the
` efficiency of the wireless network. It also offers scope to have
`
`Mani, et al. Expires April 19, 2004 [Page 9]
`
`Exhibit 1008
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000009
`
`

`

`Internet-Draft CAPWAPA October 2003
`
` higher layer applications influence roaming and placement policies
` in a streamlined manner.
`
` All of the above can be providing by terminating the 802.11
` management frames in the AR. This approach is also commonly referred
` to as Split AP, where the real-time components of the 802.11 protocol
` are handled in the Access Point, while the access control components
` of the 802.11 protocol terminate in the Access Router.
`
` Having a module in the AR that understands 802.11 management frames
` and 802.11 WLANs will provide much better control and optimization of
` the WLAN operation than will an abstract, protocol-agnostic control
` module. Adding support to CAPWAP/LWAPP for other wireless
` technologies then becomes a task of encapsulating the new frames and
` adding a new control module to the AR to handle the new technology.
` Presumably, the LWAPP protocol and CAPWAP architecture will need
` little, if any change.
`
`3.3 AP to AR Network Topology Considerations
`
` APs and ARs are linked directly as required by some architectures.
` Among such classifications
`
` 1. ARCH0: The classic AP is at one of the spectrum interfaces to the
` Infrastructure Network cloud with no specific connectivity to a
` controller. In this case the AP can be considered to have a
` self-contained controller possibly communicating with other APs
` in the ESS to form a WDS.
`
` 2. ARCH1: APs which defer all WLAN functions other than real-time
` services (Section 4.1) create a vastly different paradigm of
` vertical (real-time frontend AP and aggregated backend AC)
` functional distribution calling for a trust model between the two
` and a discovery process of AC by AP. The latter (discovery) is
` accentuated when the connectivity is through a cloud and there's
` potential for m-to-n correspondence of AP-AR.
`
` 3. ARCH2: APs which tend to shift some normally real-time functions
` as well to the backend with benefits such as extending OTA
` (over-the-air) protection for AP-AR thus allowing for an extended
` Trust Model for client data.
`
` 4. ARCH3: There's the case which carries (3) to render the AC as a
` single "AP-switch" treating all connected APs as smart antennae.
`
` While, at the outset, the architectures seem at wider variance, the
` varied market requirements of
`
`Mani, et al. Expires April 19, 2004 [Page 10]
`
`Exhibit 1008
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000010
`
`

`

`Internet-Draft CAPWAPA October 2003
`
` 1. deployment scope
`
` 2. scalability
`
` 3. performance and
`
` 4. end-end security demands
`
` seem to allow for all such architectures to have a role with varying
` scope and limitations. This further underscores the argument to
` provide a negotiable interface protocol.
`
`Mani, et al. Expires April 19, 2004 [Page 11]
`
`Exhibit 1008
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000011
`
`

`

`Internet-Draft CAPWAPA October 2003
`
`4. CAPWAP Component Architecture
`
` Given the preliminary outline of the three primary architecture types
` (and a fourth variant) in Section 3.3 the predominant architectural
` components are presented in three perspectives:
`
` 1. Functional & Service-based (WLAN standards)
`
` 2. Architectural Split
`
` 3. Topological
`
` This is required as a means to realize the way the three aspects are
` inter-dependent.
`
` The Figure 1 illustrates the basic outline of communications
` architecture between AP & AC.
`
` | _ |
` | Control/Provisioning ( )-|----Security
` |<------------------------|-|>|
` | Status/Download (_) |
` | |
` | _ |
` | Data ( )-|----Security
` |<------------------------|-|>|
` | Forwarding (_) |
` | |
` | |
` | Discovery |
` |<--------------------------->|
` | |
` | |
` | |
` +------+ +--------+
` |Light | | Access |
` |Weight| | Router |
` | AP | | |
` +------+ +--------+
`
` Figure 1: Basic Communications Framework
`
`4.1 WLAN functions and Services
`
` The IEEE 802.11 standard [1] says very little about the functionality
`
`Mani, et al. Expires April 19, 2004 [Page 12]
`
`Exhibit 1008
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000012
`
`

`

`Internet-Draft CAPWAPA October 2003
`
` required of an AP. There is some discussion of the AP at a block
` diagram level, in the General Description in clause 5 of the
` standard. There, an AP is described as containing functional blocks
` for 802.11 station services and for distribution system services.
` Station services consist of the following four services:
`
` a) Authentication
`
` b) Deauthentication
`
` c) Privacy
`
` d) MSDU Delivery
`
` Distribution system services consist of the following five services:
`
` a) Association
`
` b) Disassociation
`
` c) Distribution
`
` d) Integration
`
` e) Reassociation
`
` There are additional services that are required of an AP, that are
` described in the MAC Layer Management Entity (MLME) in clause 11.
` These additional management services are
`
` a) Beaconing
`
` b) Synchronization
`
` c) Power Management
`
` Other functionality that is not described, except implicitly in the
` MIB, is control and management of the radio-related functions of an
` AP. These include:
`
` a) Channel Assignment
`
` b) Transmit Power Control
`
` c) Clear Channel Assessment
`
`Mani, et al. Expires April 19, 2004 [Page 13]
`
`Exhibit 1008
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000013
`
`

`

`Internet-Draft CAPWAPA October 2003
`
` d) Radio Resource Measurement (work currently under way in IEEE
` 802.11k)
`
` The 802.11h [13] amendment to the base 802.11 standard specifies the
` operation of a MAC management protocol to accomplish the requirements
` of some regulatory bodies (principally in Europe, but expanding to
` others) in these areas:
`
` a) RADAR detection
`
` b) Transmit Power Control
`
` c) Dynamic Channel Selection
`
`4.1.1 Access Point Functions and Services
`
` The services that MUST be in a lightweight AP are those that are
` directly related to the real-time aspects of the 802.11 MAC protocol
` and those related to the radio nature of an 802.11 AP. These
` functions are:
`
` a) Privacy
`
` b) MSDU Delivery
`
` c) Beaconing
`
` d) Synchronization
`
` e) Power Management
`
` f) Channel Assignment
`
` g) Transmit Power Control
`
` h) Clear Channel Assignment
`
` i) Radio Resource Measurement
`
` j) RADAR detection
`
`4.1.2 Access Controller Functions and Services
`
` The functions that MAY be moved from the lightweight AP and located
` in the AR are those dealing with the management and control aspects
` of an 802.11 AP. These are the distribution system services, in
`
`Mani, et al. Expires April 19, 2004 [Page 14]
`
`Exhibit 1008
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000014
`
`

`

`Internet-Draft CAPWAPA October 2003
`
` addition to authentication and deauthentication services. These
` functions are:
`
` a) Authentication
`
` b) Deauthentication
`
` c) Association
`
` d) Disassociation
`
` e) Reassociation
`
` f) Distribution
`
` g) Integration
`
` h) Dynamic Channel Selection
`
` i) Dynamic Control of transmit power
`
`4.1.3 Other Conventional WLAN Functions and Services
`
` "Heavy" Access Points being the bridge to the wired world MAY (and
` normally do) also support various services and protocols that provide
` seamless connectivity of WLAN clients to the wired network such as
`
` a) Port and Protocol-based VLANs
`
` b) SNMP
`
` c) QoS (DiffServ and 802.1Q) mapping
`
` d) IP routing
`
` e) DHCP relay/server
`
` f) RADIUS client/proxy
`
` g) MobileIP (client proxy)
`
` Based on the definition of lightweight access points these services
` SHOULD qualify for offloading to the AR.
`
`4.1.4 Architectural Trends
`
`Mani, et al. Expires April 19, 2004 [Page 15]
`
`Exhibit 1008
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000015
`
`

`

`Internet-Draft CAPWAPA October 2003
`
`4.2 CAPWAP Network Topology
`
` The CAPWAP network topology primarily consists of the WLAN topology
` and the AP-AC (AP-AR) topology.
`
` The WLAN topology is straightforward and is as described in Overview
` section. This is not of much current interest as the relevant portal
` variants of WLAN are applicable equally to all new AP-AC topologies.
`
`4.2.1 Functional Distribution of WLAN Services
`
` Functional distribution of WLAN services described in earlier
` sub-sections are partly an artifact of the architecture types
` ARCH0-3. However, they may result in AP-AC topological constraints.
` Such constraints include direct connectivity to the AC being required
` and in most cases mandate L2 connectivity.
`
`4.2.2 AP to AR Topologies
`
` CAPWAP assumes that the AR and AP are within the same administrative
` domain, i.e. they are owned/controlled by the same entity. CAPWAP
` makes no topological assumptions beyond these, meaning there are
` several topologies which must be considered for our purposes.
`
` ---------------------------------------------------------------------
`
` -------+------ LAN
` |
` +-------+-------+
` | + + AR + + |
` +----+-----+----+
` | |
` +---+ +---+
` | |
` +--+--+ +--+--+
` | AP | | AP |
` +--+--+ +--+--+
`
` ---------------------------------------------------------------------
`
` Figure 2: Directly Connected
`
`Mani, et al. Expires April 19, 2004 [Page 16]
`
`Exhibit 1008
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000016
`
`

`

`Internet-Draft CAPWAPA October 2003
`
` ---------------------------------------------------------------------
`
` -------+------ LAN
` |
` +-------+-------+
` | + + AR + + |
` +----+-----+----+
` | |
` +---+ +---+
` | |
` +--+--+ +-----+-----+
` | AP | | Switch |
` +--+--+ +---+-----+-+
` | |
` +--+--+ +----+
` | AP | |
` +--+--+ +--+---+
` | host |
` +------+
`
` ---------------------------------------------------------------------
`
` Figure 3: Switched Connections
`
`Mani, et al. Expires April 19, 2004 [Page 17]
`
`Exhibit 1008
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000017
`
`

`

`Internet-Draft CAPWAPA October 2003
`
` ---------------------------------------------------------------------
`
` +-------+-------+
` | + + AR + + |
` +-------+-------+
` |
` --------+------ LAN
` |
` +-------+-------+
` | router |
` +-------+-------+
` |
` -----+--+--+--- LAN
` | |
` +---+ +---+
` | |
` +--+--+ +--+--+
` | AP | | AP |
` +--+--+ +--+--+
`
` ---------------------------------------------------------------------
`
` Figure 4: Routed Connections
`
`4.3 CAPWAP Security
`
` The CAPWAP architecture spans more than the topology over the air.
` IEEE 802.11 (and now 802.11i) describes the single-hop security
` over-the-air.
`
` The resulting security scheme only protects the data frames
` (multicast, broadcast and unicast) between stations and AP.
`
` This leaves a security gap in the CAPWAP topology between AP and AC
` (AR).
`
` As discussed earlier security of control and management traffic
` between the AP and AR subsystem, needs to be secured, failing which
` control of AP can be compromised.
`
` In addition there may be explicit requirements to secure the data
` flow between AP and AR segm