throbber
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
`

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket