DECLARATION
`
`I, Alexa Morris, based on my personal knowledge and information, hereby declare as
`
`follows:
`
`1.
`
`I am Managing Director of the IETF Administration LLC and have held that
`
`position since the LLC was formed in August 2018. Prior to that, starting on January 1, 2008, I
`
`was the Executive Director of the Internet Engineering Task Force, which was an activity of the
`
`Internet Society. Since the business of IETF did not change in any materially relevant manner
`
`with the formation of the LLC, I will collectively refer to both the activity and the LLC as IETF.
`
`2.
`
`One ofmy responsibilities with IETF has been to act as the custodian of Internet-
`
`Drafts and records relating to Internet-Drafts. I am familiar with the record keeping practices
`
`relating to Internet-Drafts, including the creation and maintenance of such records.
`
`3.
`
`I hereby declare that all statements made herein are of my own knowledge and
`
`information contained in the business records of IETF and are true, and that all statements made
`
`on information and belief are believed to be true; and further that these statements were made
`
`with the knowledge that willful false statements may be punishable by fine or imprisonment, or
`
`both, under Section I 001 of Title 18 of the United States Code.
`
`4.
`
`If depositions regarding the information in this declaration are required, the
`
`deposition should be taken by phone or videoconference or, if it must be in person, should be in
`
`California.
`
`5.
`
`Since 1998, it has been the regular practice of the IETF to publish Internet-Drafts
`
`and make them available to the public on its website at www.ietf.org (the IETF website). The
`
`IETF maintains copies of Internet-Drafts in the ordinary course of its regularly conducted
`
`activities.
`
`

`

`6.
`
`Any Internet-Draft published on the IETF website was reasonably accessible to
`
`the public and was disseminated or otherwise available to the extent that persons interested and
`
`ordinarily skilled in the subject matter or art exercising reasonable diligence could have located
`
`it. In particular, the Internet-Drafts were indexed and searchable on the IETF website.
`
`7.
`
`Internet-Drafts are posted to an IETF online directory. When an Internet-Draft is
`
`published, an announcement of its publication that describes the Internet-Draft is disseminated.
`
`Typically, that dated announcement is made within 24 hours of the publication of the Internet(cid:173)
`
`Draft The announcement is kept in the IETF email archive and the date is affixed automatically.
`
`8.
`
`The records of posting the Internet-Drafts in the IETF online repository are kept
`
`in the course of the IETF's regularly conducted activity and ordinary course of business. The
`
`records are made pursuant to established procedures and are relied upon by the IETF in the
`
`performance of its functions.
`
`9.
`
`It is the regular practice of the IETF to make and keep the records in the online
`
`repository.
`
`10.
`
`Exhibit 1 is a true and correct copy of an announcement of the publication of
`
`draft-calhoun-seamoby-lwapp-O'I, titled "Light Weight Access Point Protocol (L WAPP)." I
`
`have determined that an announcement of the publication of this Internet-Draft was made on July
`
`3, 2003. Therefore, based on the normal practice of the IETF, that Internet-Draft was reasonably
`
`available to the public within 24 hours of that announcement. At that time, the Internet-Draft
`
`would have been disseminated or otherwise available to the extent that persons interested and
`
`ordinarily skilled in the subject matter or art, exercising reasonable diligence, could have located
`
`it.
`
`DECLARATION OF ALEXA MORRIS
`
`2
`
`

`

`11.
`
`Exhibit 2 is a true and correct copy of an announcement of the publication of
`
`draft-mani-capwap-arch-00, titled "Architecture for Control and Provisioning of Wireless Access
`
`Points (CAPW AP)." I have determined that an announcement of the publication of this Internet(cid:173)
`
`Draft was made on October 22, 2003. Therefore, based on the normal practice of the IETF, that
`
`Internet-Draft was reasonably available to the public within 24 hours of that announcement. At
`
`that time, the Internet-Draft would have been disseminated or otherwise available to the extent
`
`that persons interested and ordinarily skilled in the subject matter or art, exercising reasonable
`
`diligence, could have located it.
`
`Pursuant to Section 1746 of Title 28 of United States Code, I declare under penalty of
`
`perjury under the laws of the United States of America that the foregoing is true and correct and
`
`that the foregoing is based upon personal knowledge and information and is believed to be true.
`
`Date:
`
`4866-4349-3491
`
`By: __ ~~-~·~----------
`~~
`
`DECLARATION OF ALEXA MORRIS
`
`3
`
`

`

`Exhibit 1
`Exhibit 1
`
`Exhibit 1016
`Hewlett Packard Enterprise Companyv. Sovereign Peak Ventures, LLC
`Page 000004
`
`

`

`7/31/23, 11:09 AM
`
`ietf.org/proceedings/57/I-D/draft-calhoun-seamoby-lwapp-03.txt
`
`Network Working Group P. Calhoun
`Internet-Draft B. O'Hara
`Expires: December 27, 2003 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]
`
`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
`https://www.ietf.org/proceedings/57/I-D/draft-calhoun-seamoby-lwapp-03.txt
`
`1/58
`
`

`

`ietf.org/proceedings/57/I-D/draft-calhoun-seamoby-lwapp-03.txt
`7/31/23, 11:09 AM
` 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]
`
`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
`https://www.ietf.org/proceedings/57/I-D/draft-calhoun-seamoby-lwapp-03.txt
`
`2/58
`
`

`

`ietf.org/proceedings/57/I-D/draft-calhoun-seamoby-lwapp-03.txt
`7/31/23, 11:09 AM
` 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]
`
`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
`https://www.ietf.org/proceedings/57/I-D/draft-calhoun-seamoby-lwapp-03.txt
`
`3/58
`
`

`

`ietf.org/proceedings/57/I-D/draft-calhoun-seamoby-lwapp-03.txt
`7/31/23, 11:09 AM
` 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]
`
`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
`https://www.ietf.org/proceedings/57/I-D/draft-calhoun-seamoby-lwapp-03.txt
`
`4/58
`
`

`

`ietf.org/proceedings/57/I-D/draft-calhoun-seamoby-lwapp-03.txt
`7/31/23, 11:09 AM
` 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]
`
`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
`
`https://www.ietf.org/proceedings/57/I-D/draft-calhoun-seamoby-lwapp-03.txt
`
`5/58
`
`

`

`7/31/23, 11:09 AM
`
`ietf.org/proceedings/57/I-D/draft-calhoun-seamoby-lwapp-03.txt
`
`Calhoun, et al. Expires December 27, 2003 [Page 6]
`
`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
`
`https://www.ietf.org/proceedings/57/I-D/draft-calhoun-seamoby-lwapp-03.txt
`
`6/58
`
`

`

`7/31/23, 11:09 AM
`
`ietf.org/proceedings/57/I-D/draft-calhoun-seamoby-lwapp-03.txt
`
`Calhoun, et al. Expires December 27, 2003 [Page 7]
`
`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]
`
`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
`https://www.ietf.org/proceedings/57/I-D/draft-calhoun-seamoby-lwapp-03.txt
`
`7/58
`
`

`

`ietf.org/proceedings/57/I-D/draft-calhoun-seamoby-lwapp-03.txt
`7/31/23, 11:09 AM
` 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]
`
`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.
`https://www.ietf.org/proceedings/57/I-D/draft-calhoun-seamoby-lwapp-03.txt
`
`8/58
`
`

`

`7/31/23, 11:09 AM
`
`ietf.org/proceedings/57/I-D/draft-calhoun-seamoby-lwapp-03.txt
`
` 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]
`
`Internet-Draft Light Weight Access Point Protocol (LWAPP) June 2003
`
` collected by the AP.
`
`https://www.ietf.org/proceedings/57/I-D/draft-calhoun-seamoby-lwapp-03.txt
`
`9/58
`
`

`

`7/31/23, 11:09 AM
`
`ietf.org/proceedings/57/I-D/draft-calhoun-seamoby-lwapp-03.txt
`
`Calhoun, et al. Expires December 27, 2003