Network Working Group
`Internet-Draft
`Expires: December 27, 2003
`
`P. Calhoun
`B. O'Hara
`S. Kelly
`R. Suri
`Airespace
`D. Funato
`DoCoMo USA Labs
`M. Vakulenko
`Legra Systems, Inc.
`June 28, 2003
`
`Light Weight Access Point Protocol (LWAPP)
`draft-calhoun-seamoby-lwapp-03
`
`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 December 27, 2003.
`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
` functions that are performed by routers or switches in wired networks
` in addition to bridging between wired and wireless networks. For
` example, in 802.11 networks, Access Points can function as Network
`
`Calhoun, et al.
`
`Expires December 27, 2003
`
`[Page 1]
`
`Exhibit 1006
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000001
`
`

`

`Internet-Draft Light Weight Access Point Protocol (LWAPP) June 2003
`
`
` Access Servers. For this reason, Access Points have IP addresses and
` can function as IP devices.
`
` This document describes the Light Weight Access Point Protocol which
` is a protocol allowing a router or switch to interoperably control
` and manage a collection of wireless Access Points. The protocol is
` independent of wireleess Layer 2 technology, but an 802.11 binding is
` provided.
`
`Table of Contents
`
` 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 7
` 1.1 Conventions used in this document . . . . . . . . . . . 9
` 2. Protocol Overview . . . . . . . . . . . . . . . . . . . 10
` 3. Definitions . . . . . . . . . . . . . . . . . . . . . . 12
` 4. LWAPP Packet Format . . . . . . . . . . . . . . . . . . 13
` 4.1 LWAPP Message Format . . . . . . . . . . . . . . . . . . 13
` 4.1.1 Flags Field . . . . . . . . . . . . . . . . . . . . . . 13
` 4.1.2 VER field . . . . . . . . . . . . . . . . . . . . . . . 13
` 4.1.3 RID . . . . . . . . . . . . . . . . . . . . . . . . . . 13
` 4.1.4 Reserved . . . . . . . . . . . . . . . . . . . . . . . . 13
` 4.1.5 Length . . . . . . . . . . . . . . . . . . . . . . . . . 13
` 4.1.6 Control/Status . . . . . . . . . . . . . . . . . . . . . 13
` 4.1.6.1 Status . . . . . . . . . . . . . . . . . . . . . . . . . 14
` 4.1.6.1.1 RSSI . . . . . . . . . . . . . . . . . . . . . . . . . . 14
` 4.1.6.1.2 SNR . . . . . . . . . . . . . . . . . . . . . . . . . . 14
` 4.1.6.2 Control . . . . . . . . . . . . . . . . . . . . . . . . 14
` 4.1.7 Payload . . . . . . . . . . . . . . . . . . . . . . . . 15
` 4.2 LWAPP Control Messages . . . . . . . . . . . . . . . . . 15
` 4.2.1 LWAPP State Machine . . . . . . . . . . . . . . . . . . 15
` 4.2.2 Control Message Format . . . . . . . . . . . . . . . . . 16
` 4.2.2.1 Message Type . . . . . . . . . . . . . . . . . . . . . . 16
` 4.2.2.2 Sequence Number . . . . . . . . . . . . . . . . . . . . 17
` 4.2.2.3 Msg Element Length . . . . . . . . . . . . . . . . . . . 17
` 4.2.2.4 Session ID . . . . . . . . . . . . . . . . . . . . . . . 17
` 4.2.2.5 Message Element[0..N] . . . . . . . . . . . . . . . . . 17
` 4.2.3 Control Channel Management . . . . . . . . . . . . . . . 18
` 4.2.3.1 Discovery Requests . . . . . . . . . . . . . . . . . . . 18
` 4.2.3.1.1 Sending Discovery Requests . . . . . . . . . . . . . . . 18
` 4.2.3.1.2 Format of a Discovery Request . . . . . . . . . . . . . 19
` 4.2.3.1.3 Receiving Discovery Requests . . . . . . . . . . . . . . 19
` 4.2.3.2 Discovery Reply . . . . . . . . . . . . . . . . . . . . 19
` 4.2.3.2.1 Sending Discovery Replies . . . . . . . . . . . . . . . 19
` 4.2.3.2.2 Format of a Discovery Reply . . . . . . . . . . . . . . 19
` 4.2.3.2.3 Receiving Discovery Replies . . . . . . . . . . . . . . 19
` 4.2.3.3 Join Request . . . . . . . . . . . . . . . . . . . . . . 20
` 4.2.3.3.1 Sending Join Requests . . . . . . . . . . . . . . . . . 20
` 4.2.3.3.2 Format of a Join Request . . . . . . . . . . . . . . . . 20
`
`
`
`Calhoun, et al. Expires December 27, 2003 [Page 2]
`
`
`
`
`Exhibit 1006
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000002
`
`

`

`Internet-Draft Light Weight Access Point Protocol (LWAPP) June 2003
`
`
` 4.2.3.3.3 Receiving Join Requests . . . . . . . . . . . . . . . . 20
` 4.2.3.4 Join Reply . . . . . . . . . . . . . . . . . . . . . . . 21
` 4.2.3.4.1 Sending Join Replies . . . . . . . . . . . . . . . . . . 21
` 4.2.3.4.2 Format of a Join Reply . . . . . . . . . . . . . . . . . 21
` 4.2.3.4.3 Receiving Join Replies . . . . . . . . . . . . . . . . . 21
` 4.2.3.5 Echo Request . . . . . . . . . . . . . . . . . . . . . . 21
` 4.2.3.5.1 Sending Echo Requests . . . . . . . . . . . . . . . . . 21
` 4.2.3.5.2 Format of a Echo Request . . . . . . . . . . . . . . . . 21
` 4.2.3.5.3 Receiving Echo Requests . . . . . . . . . . . . . . . . 22
` 4.2.3.6 Echo Response . . . . . . . . . . . . . . . . . . . . . 22
` 4.2.3.6.1 Sending Echo Responses . . . . . . . . . . . . . . . . . 22
` 4.2.3.6.2 Format of a Echo Response . . . . . . . . . . . . . . . 22
` 4.2.3.6.3 Receiving Echo Responses . . . . . . . . . . . . . . . . 22
` 4.2.3.7 Key Update Request . . . . . . . . . . . . . . . . . . . 22
` 4.2.3.7.1 Sending Key Update Requests . . . . . . . . . . . . . . 22
` 4.2.3.7.2 Format of a Key Update Request . . . . . . . . . . . . . 22
` 4.2.3.7.3 Receiving Key Update Requests . . . . . . . . . . . . . 22
` 4.2.3.8 Key Update Response . . . . . . . . . . . . . . . . . . 23
` 4.2.3.8.1 Sending Key Update Responses . . . . . . . . . . . . . . 23
` 4.2.3.8.2 Format of a Key Update Response . . . . . . . . . . . . 23
` 4.2.3.8.3 Receiving Key Update Responses . . . . . . . . . . . . . 23
` 4.2.3.9 Key Update Trigger . . . . . . . . . . . . . . . . . . . 23
` 4.2.3.9.1 Sending Key Update Trigger . . . . . . . . . . . . . . . 23
` 4.2.3.9.2 Format of a Key Update Trigger . . . . . . . . . . . . . 23
` 4.2.3.9.3 Receiving Key Update Trigger . . . . . . . . . . . . . . 23
` 4.2.4 AR Configuration . . . . . . . . . . . . . . . . . . . . 24
` 4.2.4.1 Configure Request . . . . . . . . . . . . . . . . . . . 24
` 4.2.4.1.1 Sending Configure Requests . . . . . . . . . . . . . . . 24
` 4.2.4.1.2 Format of a Configure Request . . . . . . . . . . . . . 24
` 4.2.4.1.3 Receiving Configure Requests . . . . . . . . . . . . . . 24
` 4.2.4.2 Configure Response . . . . . . . . . . . . . . . . . . . 24
` 4.2.4.2.1 Sending Configure Responses . . . . . . . . . . . . . . 24
` 4.2.4.2.2 Format of a Configure Response . . . . . . . . . . . . . 25
` 4.2.4.2.3 Receiving Configure Responses . . . . . . . . . . . . . 25
` 4.2.4.3 Configuration Update Request . . . . . . . . . . . . . . 25
` 4.2.4.3.1 Sending Configuration Update Requests . . . . . . . . . 25
` 4.2.4.3.2 Format of a Configure Update Request . . . . . . . . . . 25
` 4.2.4.3.3 Receiving Configuration Update Requests . . . . . . . . 26
` 4.2.4.4 Configuration Update Response . . . . . . . . . . . . . 26
` 4.2.4.4.1 Sending Configuration Update Responses . . . . . . . . . 26
` 4.2.4.4.2 Format of a Configuration Update Response . . . . . . . 26
` 4.2.4.4.3 Receiving Configure Update Responses . . . . . . . . . . 26
` 4.2.4.5 Statistics Report . . . . . . . . . . . . . . . . . . . 26
` 4.2.4.5.1 Sending Statistics Reports . . . . . . . . . . . . . . . 26
` 4.2.4.5.2 Format of a Statistics Report . . . . . . . . . . . . . 26
` 4.2.4.5.3 Receiving Statistics Report . . . . . . . . . . . . . . 27
` 4.2.4.6 Statistics Response . . . . . . . . . . . . . . . . . . 27
` 4.2.4.6.1 Sending Statistics Responses . . . . . . . . . . . . . . 27
`
`
`
`Calhoun, et al. Expires December 27, 2003 [Page 3]
`
`
`
`
`Exhibit 1006
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000003
`
`

`

`Internet-Draft Light Weight Access Point Protocol (LWAPP) June 2003
`
`
` 4.2.4.6.2 Format of a Statistics Response . . . . . . . . . . . . 27
` 4.2.4.6.3 Receiving Statistics Responses . . . . . . . . . . . . . 27
` 4.2.4.7 Reset Request . . . . . . . . . . . . . . . . . . . . . 27
` 4.2.4.7.1 Sending Reset Requests . . . . . . . . . . . . . . . . . 27
` 4.2.4.7.2 Format of a Reset Request . . . . . . . . . . . . . . . 27
` 4.2.4.7.3 Receiving Reset Requests . . . . . . . . . . . . . . . . 27
` 4.2.4.8 Reset Response . . . . . . . . . . . . . . . . . . . . . 27
` 4.2.4.8.1 Sending Reset Responses . . . . . . . . . . . . . . . . 27
` 4.2.4.8.2 Format of a Reset Response . . . . . . . . . . . . . . . 28
` 4.2.4.8.3 Receiving Reset Responses . . . . . . . . . . . . . . . 28
` 4.2.5 Mobile Session Management . . . . . . . . . . . . . . . 28
` 4.2.5.1 Add Mobile Request . . . . . . . . . . . . . . . . . . . 28
` 4.2.5.1.1 Sending Add Mobile Requests . . . . . . . . . . . . . . 28
` 4.2.5.1.2 Format of a Add Mobile Request . . . . . . . . . . . . . 28
` 4.2.5.1.3 Receiving Add Mobile Requests . . . . . . . . . . . . . 29
` 4.2.5.2 Add Mobile Response . . . . . . . . . . . . . . . . . . 29
` 4.2.5.2.1 Sending Add Mobile Response . . . . . . . . . . . . . . 29
` 4.2.5.2.2 Format of a Add Mobile Response . . . . . . . . . . . . 29
` 4.2.5.2.3 Receiving Add Mobile Response . . . . . . . . . . . . . 29
` 4.2.5.3 Delete Mobile Request . . . . . . . . . . . . . . . . . 29
` 4.2.5.3.1 Sending Delete Mobile Requests . . . . . . . . . . . . . 29
` 4.2.5.3.2 Format of a Delete Mobile Request . . . . . . . . . . . 30
` 4.2.5.3.3 Receiving Delete Mobile Requests . . . . . . . . . . . . 30
` 4.2.5.4 Delete Mobile Response . . . . . . . . . . . . . . . . . 30
` 4.2.5.4.1 Sending Delete Mobile Response . . . . . . . . . . . . . 30
` 4.2.5.4.2 Format of a Delete Mobile Response . . . . . . . . . . . 30
` 4.2.5.4.3 Receiving Delete Mobile Response . . . . . . . . . . . . 30
` 4.2.6 Firmware Management . . . . . . . . . . . . . . . . . . 30
` 4.2.6.1 Image Data Request . . . . . . . . . . . . . . . . . . . 30
` 4.2.6.1.1 Sending Image Data Requests . . . . . . . . . . . . . . 31
` 4.2.6.1.2 Format of a Image Data Request . . . . . . . . . . . . . 31
` 4.2.6.1.3 Receiving Image Data Requests . . . . . . . . . . . . . 31
` 4.2.6.2 Image Data Response . . . . . . . . . . . . . . . . . . 31
` 4.2.6.2.1 Sending Image Data Response . . . . . . . . . . . . . . 31
` 4.2.6.2.2 Format of an Image Data Response . . . . . . . . . . . . 31
` 4.2.6.2.3 Receiving Image Data Responses . . . . . . . . . . . . . 31
` 5. LWAPP Message Elements . . . . . . . . . . . . . . . . . 32
` 5.1 Result Code . . . . . . . . . . . . . . . . . . . . . . 33
` 5.2 AR Address . . . . . . . . . . . . . . . . . . . . . . . 33
` 5.3 AP Payload . . . . . . . . . . . . . . . . . . . . . . . 33
` 5.4 AP Name . . . . . . . . . . . . . . . . . . . . . . . . 34
` 5.5 AR Payload . . . . . . . . . . . . . . . . . . . . . . . 35
` 5.6 AP WLAN Radio Configuration . . . . . . . . . . . . . . 35
` 5.7 Rate Set . . . . . . . . . . . . . . . . . . . . . . . . 37
` 5.8 Multi-domain Capability . . . . . . . . . . . . . . . . 37
` 5.9 MAC Operation . . . . . . . . . . . . . . . . . . . . . 38
` 5.10 Tx Power Level . . . . . . . . . . . . . . . . . . . . . 39
` 5.11 Direct Sequence Control . . . . . . . . . . . . . . . . 40
`
`
`
`Calhoun, et al. Expires December 27, 2003 [Page 4]
`
`
`
`
`Exhibit 1006
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000004
`
`

`

`Internet-Draft Light Weight Access Point Protocol (LWAPP) June 2003
`
`
` 5.12 OFDM Control . . . . . . . . . . . . . . . . . . . . . . 40
` 5.13 Supported Rates . . . . . . . . . . . . . . . . . . . . 41
` 5.14 Test . . . . . . . . . . . . . . . . . . . . . . . . . . 42
` 5.15 Administrative State . . . . . . . . . . . . . . . . . . 42
` 5.16 Delete WLAN . . . . . . . . . . . . . . . . . . . . . . 42
` 5.17 AR Name . . . . . . . . . . . . . . . . . . . . . . . . 43
` 5.18 Image Download . . . . . . . . . . . . . . . . . . . . . 43
` 5.19 Image Data . . . . . . . . . . . . . . . . . . . . . . . 43
` 5.20 Location Data . . . . . . . . . . . . . . . . . . . . . 43
` 5.21 Statistics Timer . . . . . . . . . . . . . . . . . . . . 43
` 5.22 Statistics . . . . . . . . . . . . . . . . . . . . . . . 44
` 5.23 Antenna . . . . . . . . . . . . . . . . . . . . . . . . 45
` 5.24 Certificate . . . . . . . . . . . . . . . . . . . . . . 46
` 5.25 Session ID . . . . . . . . . . . . . . . . . . . . . . . 46
` 5.26 Session Key Payload . . . . . . . . . . . . . . . . . . 46
` 5.27 WLAN Payload . . . . . . . . . . . . . . . . . . . . . . 47
` 5.28 Vendor Specific Payload . . . . . . . . . . . . . . . . 48
` 5.29 Tx Power . . . . . . . . . . . . . . . . . . . . . . . . 48
` 5.30 Add Mobile . . . . . . . . . . . . . . . . . . . . . . . 49
` 5.31 Delete Mobile . . . . . . . . . . . . . . . . . . . . . 50
` 5.32 Mobile Session Key . . . . . . . . . . . . . . . . . . . 50
` 6. LWAPP Configuration Variables . . . . . . . . . . . . . 52
` 6.1 MaxDiscoveryInterval . . . . . . . . . . . . . . . . . . 52
` 6.2 MaxDiscoveries . . . . . . . . . . . . . . . . . . . . . 52
` 6.3 SilentInterval . . . . . . . . . . . . . . . . . . . . . 52
` 6.4 NeighborDeadInterval . . . . . . . . . . . . . . . . . . 52
` 6.5 EchoInterval . . . . . . . . . . . . . . . . . . . . . . 52
` 6.6 DiscoveryInterval . . . . . . . . . . . . . . . . . . . 53
` 7. LWAPP Transport Layer . . . . . . . . . . . . . . . . . 54
` 7.1 Layer 2 . . . . . . . . . . . . . . . . . . . . . . . . 54
` 7.1.1 Source Address . . . . . . . . . . . . . . . . . . . . . 54
` 7.1.2 Destination Address . . . . . . . . . . . . . . . . . . 54
` 7.1.3 Ethertype . . . . . . . . . . . . . . . . . . . . . . . 54
` 7.1.4 AR Discovery . . . . . . . . . . . . . . . . . . . . . . 54
` 7.1.5 Extended LWAPP Message Format . . . . . . . . . . . . . 54
` 7.1.5.1 Flags Field . . . . . . . . . . . . . . . . . . . . . . 55
` 7.1.5.2 C Bit . . . . . . . . . . . . . . . . . . . . . . . . . 55
` 7.1.5.3 F Bit . . . . . . . . . . . . . . . . . . . . . . . . . 55
` 7.1.5.4 L Bit . . . . . . . . . . . . . . . . . . . . . . . . . 55
` 7.1.5.5 Fragment ID . . . . . . . . . . . . . . . . . . . . . . 55
` 7.2 Layer 3 . . . . . . . . . . . . . . . . . . . . . . . . 55
` 7.2.1 Framing . . . . . . . . . . . . . . . . . . . . . . . . 56
` 7.2.2 Fragmentation/Reassembly . . . . . . . . . . . . . . . . 56
` 7.2.3 Multiplexing . . . . . . . . . . . . . . . . . . . . . . 56
` 7.2.4 AR Discovery . . . . . . . . . . . . . . . . . . . . . . 56
` 8. Light Weight Access Protocol Constants . . . . . . . . . 58
` 9. Security Considerations . . . . . . . . . . . . . . . . 59
` 10. IPR Statement . . . . . . . . . . . . . . . . . . . . . 60
`
`
`
`Calhoun, et al. Expires December 27, 2003 [Page 5]
`
`
`
`
`Exhibit 1006
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000005
`
`

`

`Internet-Draft Light Weight Access Point Protocol (LWAPP) June 2003
`
`
` References . . . . . . . . . . . . . . . . . . . . . . . 61
` Authors' Addresses . . . . . . . . . . . . . . . . . . . 61
` A. Session Key Generation . . . . . . . . . . . . . . . . . 63
` A.1 Securing AP-AR communications . . . . . . . . . . . . . 63
` A.2 Authenticated Key Exchange . . . . . . . . . . . . . . . 64
` A.3 Refreshing Cryptographic Keys . . . . . . . . . . . . . 65
` Full Copyright Statement . . . . . . . . . . . . . . . . 67
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Calhoun, et al. Expires December 27, 2003 [Page 6]
`
`
`
`
`Exhibit 1006
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000006
`
`

`

`Internet-Draft Light Weight Access Point Protocol (LWAPP) June 2003
`
`
`1. Introduction
`
` Current wireless Access Points (AP) perform functions that require IP
` level service, and so they are not strictly Layer 2 devices,
` conventional wisdom to the contrary notwithstanding. However, unlike
` wired network elements, Access Points require an additional set of
` management and control functions related to their primary function of
` bridging between the wireless and wired medium. The details of how
` these functions are implemented are naturally dependent on the
` particular Layer 2 wireless protocol, but in many cases the overall
` control and management functions themselves are generic and could
` apply to any wireless Layer 2 protocol. Today, protocols for
` managing access points are either Layer 2 specific or non-existent
` (if the Access Points are self-contained). The emergence of simple
` Access Points in 802.11 that are managed by a router or switch (also
` known as an Access router, or AR) suggests that having a
` standardized, interoperable protocol could radically simplify the
` deployment and management of wireless networks, a trend that could
` become more important in new wireless Layer 2 protocols. Such a
` protocol could also better support interoperability between Layer 2
` devices supporting different wireless Layer 2 technologies, allowing
` smoother intertechnology handovers.
`
` LWAPP assumes a network configuration that consists of multiple APs
` connected either via layer 2 (Ethernet), or layer 3 (IP) to an AR.
` The APs can be considered as remote RF interfaces, being controlled
` by the AR (see Figure 1). The AP forwards all 802.11 frames received
` to the AR via the LWAPP protocol, which processes the frames.
` Similarly, packets from authorized mobiles are forwarded by the AP to
` the AR via this protocol.
`
` ---------------------------------------------------------------------
`
`
` +-+ 802.11frames +-+
` | |--------------------------------| |
` | | +-+ | |
` | |--------------| |---------------| |
` | | 802.11 PHY/ | | LWAPP | |
` | | MAC sublayer | | | |
` +-+ +-+ +-+
` STA AP AR
`
` Figure 1: LWAPP Architecture
`
` ---------------------------------------------------------------------
`
` Security is another aspect of Access Point management that is not
`
`
`
`Calhoun, et al. Expires December 27, 2003 [Page 7]
`
`
`
`
`Exhibit 1006
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000007
`
`

`

`Internet-Draft Light Weight Access Point Protocol (LWAPP) June 2003
`
`
` well served by existing solutions. Provisioning Access Points with
` security credentials, and managing which Access Points are authorized
` to provide service are today handled by proprietary solutions.
` Allowing these functions to be performed from a centralized router or
` switch in an interoperable fashion increases managability and allows
` network operators to more tightly control their wireless network
` infrastructure. Further, since the interface between the AP and the
` AR is point-to-point, it is now possible to centralize user or
` station (STA) authentication (such as 802.1x, see Figure 2) as well
` as policy enforcement functions, without the risk of 802.11 leakage
` into the network.
`
` ---------------------------------------------------------------------
`
`
` +-+ EAPOL frames +-+ EAP/RADIUS +-+
` | |--------------------------------| |--------------| |
` | | +-+ | | | |
` | |--------------| |---------------| |--------------| |
` | | 802.11 PHY/ | | LWAPP | | | |
` | | MAC sublayer | | | | | |
` +-+ +-+ +-+ +-+
` STA AP AR AAA
`
` Figure 2: 802.1X Authentication in the AR
`
` ---------------------------------------------------------------------
`
` This document describes the Light Weight Access Point Protocol
` (LWAPP), an inter-operable IP protocol allowing an AR to manage a
` collection of APs. The protocol is defined to be independent of
` Layer 2 technology, but an 802.11 binding is provided for use in
` growing 802.11 wireless LAN networks.
`
` Goals
`
` The following are goals for this protocol:
`
` 1. Reduction of the amount of protocol code being executed at the
` light weight AP, to apply the computing resource of the AP to the
` application of wireless access, rather than bridge forwarding and
` filtering. This makes the most efficient use of the computing
` power available in APs that are the subject of severe cost
` pressure.
`
` 2. Centralization of the bridging, forwarding, authentication,
` encryption and policy enforcement functions for a WLAN, to apply
` the capabilities of network processing silicon to the WLAN, as it
`
`
`
`Calhoun, et al. Expires December 27, 2003 [Page 8]
`
`
`
`
`Exhibit 1006
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000008
`
`

`

`Internet-Draft Light Weight Access Point Protocol (LWAPP) June 2003
`
`
` has already been applied to wired LANs.
`
` 3. Providing a generic encapsulation and transport mechanism, the
` protocol may be applied to other access protocols in the future.
`
` The LWAPP protocol concerns itself solely on the interface between
` the AP and the AR. Inter-AR, or mobile to AR communication is
` strictly outside the scope of this document.
`
`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 [8].
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Calhoun, et al. Expires December 27, 2003 [Page 9]
`
`
`
`
`Exhibit 1006
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000009
`
`

`

`Internet-Draft Light Weight Access Point Protocol (LWAPP) June 2003
`
`
`2. Protocol Overview
`
` LWAPP is a generic protocol defining how Light-Weight Access Points
` communicate with Access Routers. Access Points and Access Routers
` may be connected either by means of Layer 2 network or by means of a
` routed IP network.
`
` LWAPP messages and procedures defined in this document apply for both
` transports unless specified otherwise. the transport independence is
` achieved via the LWAPP Transport Layer (LTL), which is defined in
` section Section 7. LTL defines the framing, fragmentation/
` reassembly, and multiplexing services to LWAPP for each transport.
`
` The Light Weight Access Protocol (LWAPP) begins with a discovery
` phase, whereby the APs send a Discovery Request frame, causing any
` Access Router (AR) [9], receiving that frame to respond with a
` Discovery Reply. From the Discovery Replies received, an Access
` Point (AP) will select an AR with which to associate, using the Join
` Request and Join Reply. The Join Request also provides an MTU
` discovery mechanism, to determine whether there is support for the
` transport of jumbo frames between the AP and it's AR. If support for
` jumbo frames is not present, the LWAPP frames will be fragmented to
` the maximum length discovered to be supported by the layer 2 network.
`
` Once the AP and the AR have joined, a configuration exchange is
` accomplished that will upgrade the version of the code running on the
` AP to match that of the AR, if necessary, and will provision the APs.
` The provisioning of APs includes the typical name (802.11 Service Set
` Identifier, SSID), and security parameters, the data rates to be
` advertised as well as the radio channel (channels, if the AP is
` capable of operating more than one 802.11 MAC and PHY simultaneously)
` to be used. Finally, the APs are enabled for operation.
`
` When the AP and AR have one or more WLANs provisioned and enabled,
` the LWAPP encapsulates the 802.11 Data and Management frames, to
` transport them between the AP and AR. LWAPP will fragment its
` packets, if the size of the encapsulated 802.11 Data or Management
` frames causes the resultant LWAPP packet to exceed the MTU supported
` between the AP and AR. Fragmented LWAPP packets are reassembled to
` reconstitute the original encapsulated payload.
`
` In addition to the functions thus far described, LWAPP also provides
` for the delivery of commands from the AR to the AP for the management
` of 802.11 devices that are communicating with the AP. This may
` include the creation of local data structures in the AP for the
` 802.11 devices and the collection of statistical information about
` the communication between the AP and the 802.11 devices. LWAPP
` provides the ability for the AR to obtain any statistical information
`
`
`
`Calhoun, et al. Expires December 27, 2003 [Page 10]
`
`
`
`
`Exhibit 1006
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000010
`
`

`

`Internet-Draft Light Weight Access Point Protocol (LWAPP) June 2003
`
`
` collected by the AP.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Calhoun, et al. Expires December 27, 2003 [Page 11]
`
`
`
`
`Exhibit 1006
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000011
`
`

`

`Internet-Draft Light Weight Access Point Protocol (LWAPP) June 2003
`
`
`3. Definitions
`
` This Document uses terminology defined in [9]
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Calhoun, et al. Expires December 27, 2003 [Page 12]
`
`
`
`
`Exhibit 1006
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000012
`
`

`

`Internet-Draft Light Weight Access Point Protocol (LWAPP) June 2003
`
`
`4. LWAPP Packet Format
`
` This section contains the general packet header format. The LWAPP
` protocol is designed to be transport agnostic. Transport details can
` be found in the section entitled Section 7.
`
`4.1 LWAPP Message Format
`
` 0 1 2 3
` 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` |VER| RID | Reserved | Length |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Ctl/Stat | Payload... |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
`
`4.1.1 Flags Field
`
` The first byte contains several flag fields.
`
`4.1.2 VER field
`
` The VER field identifies the LWAPP protocol version carried in this
` packet. For this version of the protocol, the value of this field is
` 0.
`
`4.1.3 RID
`
` The RID field contains the Radio Identifier. For APs that contain
` more than one radio, this field is used to idenfity each Radio.
`
`4.1.4 Reserved
`
` The reserved field MUST be set to zero unless these bits are defined
` for use with a specific transport (see Section 7.1).
`
`4.1.5 Length
`
` The value of this field is unsigned and indicates the number of bytes
` in the Payload field.
`
`4.1.6 Control/Status
`
` The interpretation of this field depends on the direction of
` transmission of the packet.
`
`
`
`
`
`Calhoun, et al. Expires December 27, 2003 [Page 13]
`
`
`
`
`Exhibit 1006
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000013
`
`

`

`Internet-Draft Light Weight Access Point Protocol (LWAPP) June 2003
`
`
`4.1.6.1 Status
`
` When an LWAPP packet is transmitted from an AP to a AR, this field
` indicates link layer information associated with the frame. When the
` C bit is 0, this field is transmitted as zero and ignored on
` reception.
`
` For 802.11, the signal strength and signal to noise ratio with which
` an 802.11 frame was received, encoded in the following manner:
`
` 0 1
` 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | RSSI | SNR |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
`
`4.1.6.1.1 RSSI
`
` RSSI is a signed, 8-bit value. It is the received signal strength
` indication, in dBm.
`
`4.1.6.1.2 SNR
`
` SNR is a signed, 8-bit value. It is the signal to noise ratio of the
` received 802.11 frame, in dB.
`
`4.1.6.2 Control
`
` When an LWAPP packet is transmitted from an AR to an AP, this field
` indicates on which WLANs the encapsulated 802.11 frame is to be
` transmitted. For unicast packets, this field is not used by the AP,
` but for broadcast or multicast packets, the AP may require this
` information if it provides encryption services.
`
` Given that a single broadcast or multicast packet may need to be sent
` to multiple wireless LANs (presumably each with a different broadcast
` key), this field must be a bit field. The bit position indicates the
` WLAN ID (see Section 5.27) the frame is to be transmitted to.
`
` The Control field is encoded in the following manner:
`
` 0 1
` 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | WLAN ID(s) |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
`
`
`
`Calhoun, et al. Expires December 27, 2003 [Page 14]
`
`
`
`
`Exhibit 1006
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000014
`
`

`

`Internet-Draft Light Weight Access Point Protocol (LWAPP) June 2003
`
`
`4.1.7 Payload
`
` The Payload field contains data equal in size to the value of the
` Length field, found within the LWAPP header.
`
`4.2 LWAPP Control Messages
`
` The LWAPP Control protocol provides a communication channel between
` the AP and the AR and falls into the following distinct messages
` types:
`
` Control Channel Management: Messages that fall within this
` classification are used for the discovery of ARs by the APs as
` well as the establishment and maintenance of an LWAPP control
` channel.
`
` AR Configuration: The AR Configuration messages are used by the AR to
` push a specific configuration to the APs it has a control channel
` with. Messages that deal with the retrieval of statistics from
` the AP also fall in this category.
`
` Mobile Session Management: Mobile session management messages are
`