

Network Working Group                                         P. Calhoun
Internet-Draft                                                 B. O'Hara
Expires: June 11, 2004                                          S. Kelly
                                                                 R. Suri
                                                               Airespace
                                                               D. Funato
                                                         DoCoMo USA Labs
                                                            M. Vakulenko
                                                     Legra Systems, Inc.
                                                              A. Johnson
                                                              T. Neilson
                                                               S. Boyden
                                                                K. Sidhu
                                                                    UNBC
                                                       December 12, 2003


               Light Weight Access Point Protocol (LWAPP)
               draft-calhoun-seamoby-lwapp-handover-04-2

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 June 11, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

   While conventional wisdom has it that wireless Access Points are



Calhoun, et al.          Expires June 11, 2004                  [Page 1]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


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

   An addition was made to this document in December of 2003. Andrew
   Johnson, Sean Boyden, Tyler Neilson, and Kiranjit Sidhu worked on a
   fast handover protocol for the LWAPP standard and included it as a
   section in this document. The addition of this section will provide
   an in depth look at how a fast handover could be implemented.

































Calhoun, et al.          Expires June 11, 2004                  [Page 2]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  6
   1.1   Conventions used in this document  . . . . . . . . . . . . .  8
   2.    Protocol Overview  . . . . . . . . . . . . . . . . . . . . .  9
   3.    Definitions  . . . . . . . . . . . . . . . . . . . . . . . . 11
   4.    LWAPP Packet Format  . . . . . . . . . . . . . . . . . . . . 12
   4.1   LWAPP Message Format . . . . . . . . . . . . . . . . . . . . 12
   4.1.1 Flags Field  . . . . . . . . . . . . . . . . . . . . . . . . 12
   4.1.2 VER field  . . . . . . . . . . . . . . . . . . . . . . . . . 12
   4.1.3 RID  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   4.1.4 Reserved . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   4.1.5 Length . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   4.1.6 Control/Status . . . . . . . . . . . . . . . . . . . . . . . 12
   4.1.7 Payload  . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   4.2   LWAPP Control Messages . . . . . . . . . . . . . . . . . . . 14
   4.2.1 LWAPP State Machine  . . . . . . . . . . . . . . . . . . . . 14
   4.2.2 Control Message Format . . . . . . . . . . . . . . . . . . . 15
   4.2.3 Control Channel Management . . . . . . . . . . . . . . . . . 17
   4.2.4 AR Configuration . . . . . . . . . . . . . . . . . . . . . . 22
   4.2.5 Mobile Session Management  . . . . . . . . . . . . . . . . . 27
   4.2.6 Firmware Management  . . . . . . . . . . . . . . . . . . . . 29
   5.    LWAPP Message Elements . . . . . . . . . . . . . . . . . . . 31
   5.1   Result Code  . . . . . . . . . . . . . . . . . . . . . . . . 32
   5.2   AR Address . . . . . . . . . . . . . . . . . . . . . . . . . 32
   5.3   AP Payload . . . . . . . . . . . . . . . . . . . . . . . . . 32
   5.4   AP Name  . . . . . . . . . . . . . . . . . . . . . . . . . . 33
   5.5   AR Payload . . . . . . . . . . . . . . . . . . . . . . . . . 34
   5.6   AP WLAN Radio Configuration  . . . . . . . . . . . . . . . . 34
   5.7   Rate Set . . . . . . . . . . . . . . . . . . . . . . . . . . 36
   5.8   Multi-domain Capability  . . . . . . . . . . . . . . . . . . 36
   5.9   MAC Operation  . . . . . . . . . . . . . . . . . . . . . . . 37
   5.10  Tx Power Level . . . . . . . . . . . . . . . . . . . . . . . 38
   5.11  Direct Sequence Control  . . . . . . . . . . . . . . . . . . 39
   5.12  OFDM Control . . . . . . . . . . . . . . . . . . . . . . . . 39
   5.13  Supported Rates  . . . . . . . . . . . . . . . . . . . . . . 40
   5.14  Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
   5.15  Administrative State . . . . . . . . . . . . . . . . . . . . 41
   5.16  Delete WLAN  . . . . . . . . . . . . . . . . . . . . . . . . 41
   5.17  AR Name  . . . . . . . . . . . . . . . . . . . . . . . . . . 42
   5.18  Image Download . . . . . . . . . . . . . . . . . . . . . . . 42
   5.19  Image Data . . . . . . . . . . . . . . . . . . . . . . . . . 42
   5.20  Location Data  . . . . . . . . . . . . . . . . . . . . . . . 42
   5.21  Statistics Timer . . . . . . . . . . . . . . . . . . . . . . 43
   5.22  Statistics . . . . . . . . . . . . . . . . . . . . . . . . . 43
   5.23  Antenna  . . . . . . . . . . . . . . . . . . . . . . . . . . 45
   5.24  Certificate  . . . . . . . . . . . . . . . . . . . . . . . . 45
   5.25  Session ID . . . . . . . . . . . . . . . . . . . . . . . . . 45



Calhoun, et al.          Expires June 11, 2004                  [Page 3]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


   5.26  Session Key Payload  . . . . . . . . . . . . . . . . . . . . 46
   5.27  WLAN Payload . . . . . . . . . . . . . . . . . . . . . . . . 46
   5.28  Vendor Specific Payload  . . . . . . . . . . . . . . . . . . 47
   5.29  Tx Power . . . . . . . . . . . . . . . . . . . . . . . . . . 47
   5.30  Add Mobile . . . . . . . . . . . . . . . . . . . . . . . . . 48
   5.31  Delete Mobile  . . . . . . . . . . . . . . . . . . . . . . . 49
   5.32  Mobile Session Key . . . . . . . . . . . . . . . . . . . . . 49
   6.    LWAPP Configuration Variables  . . . . . . . . . . . . . . . 51
   6.1   MaxDiscoveryInterval . . . . . . . . . . . . . . . . . . . . 51
   6.2   MaxDiscoveries . . . . . . . . . . . . . . . . . . . . . . . 51
   6.3   SilentInterval . . . . . . . . . . . . . . . . . . . . . . . 51
   6.4   NeighborDeadInterval . . . . . . . . . . . . . . . . . . . . 51
   6.5   EchoInterval . . . . . . . . . . . . . . . . . . . . . . . . 51
   6.6   DiscoveryInterval  . . . . . . . . . . . . . . . . . . . . . 52
   7.    LWAPP Transport Layer  . . . . . . . . . . . . . . . . . . . 53
   7.1   Layer 2  . . . . . . . . . . . . . . . . . . . . . . . . . . 53
   7.1.1 Source Address . . . . . . . . . . . . . . . . . . . . . . . 53
   7.1.2 Destination Address  . . . . . . . . . . . . . . . . . . . . 53
   7.1.3 Ethertype  . . . . . . . . . . . . . . . . . . . . . . . . . 53
   7.1.4 AR Discovery . . . . . . . . . . . . . . . . . . . . . . . . 53
   7.1.5 Extended LWAPP Message Format  . . . . . . . . . . . . . . . 53
   7.2   Layer 3  . . . . . . . . . . . . . . . . . . . . . . . . . . 54
   7.2.1 Framing  . . . . . . . . . . . . . . . . . . . . . . . . . . 55
   7.2.2 Fragmentation/Reassembly . . . . . . . . . . . . . . . . . . 55
   7.2.3 Multiplexing . . . . . . . . . . . . . . . . . . . . . . . . 55
   7.2.4 AR Discovery . . . . . . . . . . . . . . . . . . . . . . . . 55
   8.    Handoff Addition to LWAPP  . . . . . . . . . . . . . . . . . 57
   8.1   Handoff Init (Hoff-Init) . . . . . . . . . . . . . . . . . . 57
   8.1.1 Sending Hoff-Init  . . . . . . . . . . . . . . . . . . . . . 57
   8.1.2 Receiving Hoff-Init  . . . . . . . . . . . . . . . . . . . . 57
   8.2   Hoff-Context-Request . . . . . . . . . . . . . . . . . . . . 58
   8.2.1 Sending Hoff-Context-Request . . . . . . . . . . . . . . . . 58
   8.2.2 Receiving Hoff-Context-Request . . . . . . . . . . . . . . . 58
   8.3   Hoff-Context-Reply . . . . . . . . . . . . . . . . . . . . . 59
   8.3.1 Sending Hoff-Context-Reply . . . . . . . . . . . . . . . . . 59
   8.3.2 Receiving Hoff-Context-Reply . . . . . . . . . . . . . . . . 59
   8.4   Hoff-Init-Reply  . . . . . . . . . . . . . . . . . . . . . . 59
   8.4.1 Sending Hoff-Init-Reply  . . . . . . . . . . . . . . . . . . 60
   8.4.2 Receiving Hoff-Init-Reply  . . . . . . . . . . . . . . . . . 60
   8.5   Hoff-CachedContext . . . . . . . . . . . . . . . . . . . . . 60
   8.5.1 Sending Hoff-CachedContext . . . . . . . . . . . . . . . . . 60
   8.6   Hoff-CachedContext-Reply . . . . . . . . . . . . . . . . . . 61
   8.6.1 Sending Hoff-CachedContext-Reply . . . . . . . . . . . . . . 61
   8.6.2 Receiving Hoff-CachedContext-Reply . . . . . . . . . . . . . 62
   8.7   Hoff-CachedContext-Update  . . . . . . . . . . . . . . . . . 62
   8.7.1 Sending Hoff-CachedContext-Update  . . . . . . . . . . . . . 62
   8.7.2 Receiving Hoff-CachedContext-Update  . . . . . . . . . . . . 62
   8.8   Hoff-CachedContext-New . . . . . . . . . . . . . . . . . . . 63



Calhoun, et al.          Expires June 11, 2004                  [Page 4]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


   8.8.1 Sending Hoff-CachedContext-New . . . . . . . . . . . . . . . 63
   8.8.2 Receiving a Hoff-CachedContext-New . . . . . . . . . . . . . 63
   8.9   Hoff-CachedContext-Drop  . . . . . . . . . . . . . . . . . . 63
   8.9.1 Sending Hoff-CachedContext-Drop  . . . . . . . . . . . . . . 64
   8.9.2 Receiving a Hoff-CachedContext-Drop  . . . . . . . . . . . . 64
   8.10  Figures for Handoff addition to LWAPP  . . . . . . . . . . . 64
   9.    Light Weight Access Protocol Constants . . . . . . . . . . . 69
   10.   Security Considerations  . . . . . . . . . . . . . . . . . . 70
   11.   IPR Statement  . . . . . . . . . . . . . . . . . . . . . . . 71
         References . . . . . . . . . . . . . . . . . . . . . . . . . 72
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 72
   A.    Session Key Generation . . . . . . . . . . . . . . . . . . . 75
   A.1   Securing AP-AR communications  . . . . . . . . . . . . . . . 75
   A.2   Authenticated Key Exchange . . . . . . . . . . . . . . . . . 76
   A.3   Refreshing Cryptographic Keys  . . . . . . . . . . . . . . . 77
         Intellectual Property and Copyright Statements . . . . . . . 79



































Calhoun, et al.          Expires June 11, 2004                  [Page 5]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 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
   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



Calhoun, et al.          Expires June 11, 2004                  [Page 6]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


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





Calhoun, et al.          Expires June 11, 2004                  [Page 7]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


1.1 Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [7].














































Calhoun, et al.          Expires June 11, 2004                  [Page 8]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 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) [8], 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 June 11, 2004                  [Page 9]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


   collected by the AP.


















































Calhoun, et al.          Expires June 11, 2004                 [Page 10]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


3. Definitions

   This Document uses terminology defined in [8]
















































Calhoun, et al.          Expires June 11, 2004                 [Page 11]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 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 June 11, 2004                 [Page 12]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 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 June 11, 2004                 [Page 13]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 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
      used by the AR to push specific mobile policies to the AP.

   Firmware Management: Messages in this category are used by the AR to
      push a new firmware image down to the AP.


4.2.1 LWAPP State Machine

   The LWAPP Control Messages are used to communicate between the AR and
   the AP. The following state diagram represents the lifecycle of an
   AP-AR session:


















Calhoun, et al.          Expires June 11, 2004                 [Page 14]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


                      +------+(--------------------------------\
                      | Idle |                                 |
                      +------+                                 |
                         /        +---------+--)+------------+ |
                        /         |   Run   |   | Key Update | |
                       v          +---------+(--+------------+ |
              +-----------+         ^  |   |                   |
              | Discovery |         |  v   \----------->+-------+
              +-----------+        +-----------+        | Reset |
               | ^    \        /--)| Configure |        +-------+
               v |     \      /    +-----------+            ^
         +---------+    v    /                              |
         | Sulking |   +------+             +------------+  |
         +---------+   | Join |------------)| Image Data |--/
                       +------+             +------------+

                     Figure 3: LWAPP State Machine

   Each of the states above correspond to an LWAPP control message
   type,defined later in this document.

4.2.2 Control Message Format

   All LWAPP control messages are sent encapsulated within the LWAPP
   header (see Section 4.1) with the following header values:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Msg Type   |    Seq Num    |      Msg Element Length       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Session ID                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Msg Element [0..N]       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


4.2.2.1 Message Type

   The Message Type field identifies the function of the LWAPP control
   message. The valid values for Message Type are the following:

           Description                       Value
           Discovery Request                    1
           Discovery Reply                      2
           Join Request                         3
           Join Reply                           4
           Configure Request                    5



Calhoun, et al.          Expires June 11, 2004                 [Page 15]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


           Configure Response                   6
           Configuration Update Request         7
           Configuration Update Response        8
           Statistics Report                    9
           Statistics Report Response          10
           Reserved                         11-16
           Echo Request                        17
           Echo Response                       18
           Image Data Request                  19
           Image Data Response                 20
           Reset Request                       21
           Reset Response                      22
           Key Update Request                  23
           Key Update Response                 24
           Reserved                         25-26
           Key Update Trigger                  27



4.2.2.2 Sequence Number

   The Sequence Number Field is an identifier value to match request/
   response packet exchanges.  When an LWAPP packet with a request
   message type is received, the value of the sequence number field is
   copied into the corresponding response packet.

4.2.2.3 Msg Element Length

   The Length field indicates the number of bytes following the Session
   ID field.

4.2.2.4 Session ID

   The Session ID is a 32-bit unsigned integer that is used to identify
   the security context for encrypted exchanges between the AP and the
   AR.

4.2.2.5 Message Element[0..N]

   The message element(s) carry the information pertinent to each of the
   control message types.  The total length of the message elements is
   indicated in the Msg Element Length field.

   The format of a message element uses the standard TLV format shown
   here:

      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



Calhoun, et al.          Expires June 11, 2004                 [Page 16]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Type     |             Length            |   Value ...   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where Type identifies the character of the information carried in the
   Value field and Length indicates the number of bytes in the Value
   field.

   The LWAPP message elements are defined in Section 5

4.2.3 Control Channel Management

   The Control Channel Management messages are used by the AP and AR to
   create and maintain a channel of communication on which various other
   commands may be transmitted, such as configuration, firmware update,
   etc.

4.2.3.1 Discovery Requests

   The Discovery Request is used by the AP to automatically discovery
   potential ARs available in the network. An AP must transmit this
   command even if it has a statically configured AR, as it is a
   required step in the LWAPP state machine.

4.2.3.1.1 Sending Discovery Requests

   Discovery Requests MUST be sent by an AP in the Discover state after
   waiting for a random delay less than MaxDiscoveryInterval, after an
   AP first comes up or is (re)initialized.  An AP MUST send no more
   than a maximum of MaxDiscoveries discoveries, waiting for a random
   delay less than MaxDiscoveryInterval between each successive
   discovery.

   This is to prevent an explosion of AP Discoveries.  An example of
   this occurring would be when many APs are powered on at the same
   time.

   Discovery requests MUST be sent by an AP when no echo responses are
   received for NeighborDeadInterval and the AP returns to the discover
   state.  Discovery requests are sent after NeighborDeadInterval, they
   MUST be sent after waiting for a random delay less than
   MaxDiscoveryInterval.  An AP MAY send up to a maximum of
   MaxDiscoveries discoveries, waiting for a random delay less than
   MaxDiscoveryInterval between each successive discovery.

   If a discovery response is not received after sending the maximum
   number of discovery requests, the AP enters the Sulking state and
   MUST wait for an interval equal to SilentInterval before sending



Calhoun, et al.          Expires June 11, 2004                 [Page 17]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


   further discovery requests.

   The Discovery Request message may be sent as a unicast, broadcast or
   multicast message.

   TODO: Specify exponential backoff of discovery requests.

4.2.3.1.2 Format of a Discovery Request

   The Discovery Request carries the following message elements:

       AP Payload
       Radio Payload (one for each radio in the AP)


4.2.3.1.3 Receiving Discovery Requests

   Upon receiving a discovery request, the AR will respond with a
   Discovery Reply sent to the address in the source address of the
   received discovery request.

4.2.3.2 Discovery Reply

   The Discovery Reply is a mechanism by which an AR advertises its
   services to requesting APs.

4.2.3.2.1 Sending Discovery Replies

   Discovery Replies are sent by an AR after receiving a Discovery
   Request.

4.2.3.2.2 Format of a Discovery Reply

   The Discovery Reply carries the following message elements:

       AR Payload
       AR Name Payload


4.2.3.2.3 Receiving Discovery Replies

   When an AP receives a Discovery Reply, it MUST wait for an interval
   not less than DiscoveryInterval for receipt of additional discovery
   replies. After the DiscoveryInterval elapses, the AP enters the
   Joining state and will select one of the ARs that sent a discovery
   reply and send a Join Request to that AR.





Calhoun, et al.          Expires June 11, 2004                 [Page 18]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


4.2.3.3 Join Request

   The Join Request is used by an AP to inform an AR that it wishes to
   provide services through it.

4.2.3.3.1 Sending Join Requests

   Join Requests are sent by an AP in the Joining state after receiving
   one or more Discovery Replies. The Join Request is also used as an
   MTU discovery mechanism by the AP. The AP issues a Join Request with
   a Test message element, bringing the total size of the message to
   exceed MTU.

   The initial Join Request is padded with the Test message element to
   1596 bytes. If a Join Reply is received, the AP can forward frames
   without requiring any fragmentation. If no Join Reply is received, it
   issues a second Join Request padded with the Test Payload to a total
   of 1500 bytes. The AP continues to cycle from large (1596) to small
   (1500) packets until a Join Reply has been received, or until both
   packets sizes have been retransmitted 3 times. If the Join Reply is
   not received after the maximum number of retransmissions, the AP MUST
   abandon the AR and restart the discovery phase.

4.2.3.3.2 Format of a Join Request

   The Join Request carries the following message elements:

       AR Address Payload
       AP Payload
       AP Name Payload
       Location Data
       Radio Payload (one for each radio)
       Certificate
       Session ID
       Test


4.2.3.3.3 Receiving Join Requests

   When an AR receives a Join Request it will respond with a Join Reply.
   The AR validates the certificate found in the request. If valid, the
   AR generates a session key which will be used to secure the control
   frames it exchanges with the AP. When the AR issues the Join Reply,
   the AR creates a context for the session with the AP.

   Details on the key generation is found in appendix A.





Calhoun, et al.          Expires June 11, 2004                 [Page 19]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


4.2.3.4 Join Reply

   The Join Reply is sent by the AR to indicate to an AP whether it is
   capable and willing to provide service to it.

4.2.3.4.1 Sending Join Replies

   Join Replies are sent by the AR after receiving a Join Request. Once
   the Join Reply has been sent, the heartbeat timer is initiated for
   the session. Expiration of the timer will result in delete of the
   AR-AP session. The timer is refreshed upon receipt of the Echo
   Request.

4.2.3.4.2 Format of a Join Reply

   The Join Reply carries the following message elements:

       Result Code
       Certificate
       Session Key


4.2.3.4.3 Receiving Join Replies

   When an AP receives a Join Reply it enters the Joined state and
   initiates the Configure Request to the AR to which it is now joined.
   Upon entering the Joined state, the AP begins timing an interval
   equal to NeighborDeadInterval. Expiration of the timer will result in
   the transmission of the Echo Request.

4.2.3.5 Echo Request

   The Echo Request message is a keepalive mechanism for the LWAPP
   control message.

4.2.3.5.1 Sending Echo Requests

   Echo Requests are sent by an AP in the Join or Run state to determine
   the state of the connection between the AP and the AR.

4.2.3.5.2 Format of a Echo Request

   The Echo Request carries no message elements.

4.2.3.5.3 Receiving Echo Requests

   When an AR receives an Echo Request it responds with a Echo Response.




Calhoun, et al.          Expires June 11, 2004                 [Page 20]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


4.2.3.6 Echo Response

   The Echo Response acknowledges the Echo Request.

4.2.3.6.1 Sending Echo Responses

   Echo Responses are sent by an AR after receiving an Echo Request.

4.2.3.6.2 Format of a Echo Response

   The Echo Response carries no message elements.

4.2.3.6.3 Receiving Echo Responses

   When an AP receives an Echo Response it resets the timer that is
   timing the NeighborDeadInterval.  If the NeighborDeadInterval timer
   expires prior to receiving an Echo Response, the AP enters the
   Discovery state.

4.2.3.7 Key Update Request

   The Key Update Request updates the LWAPP session key used to secure
   messages between the AP and the AR.

4.2.3.7.1 Sending Key Update Requests

   Key Update Requests are sent by an AP in the Run state to update a
   session key. The Session ID message element MUST include a new
   session identifier.

4.2.3.7.2 Format of a Key Update Request

   The Key Update Request carries the following message elements:

       Session ID


4.2.3.7.3 Receiving Key Update Requests

   When a AR receives a Key Update Request it generates a new key (see
   appendix A) and responds with a Key Update Response.

4.2.3.8 Key Update Response

   The Key Update Response updates the LWAPP session key used to secure
   messages between the AP and the AR, and acknowledges the Key Update
   Request.




Calhoun, et al.          Expires June 11, 2004                 [Page 21]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


4.2.3.8.1 Sending Key Update Responses

   Key Update Responses are sent by a AR after receiving a Key Update
   Request. The Key Update Responses is secured using public key
   cryptography.

4.2.3.8.2 Format of a Key Update Response

   The Key Update Response carries the following message elements:

       Session Key


4.2.3.8.3 Receiving Key Update Responses

   When an AP receives a Key Update Response it will use the information
   contained in the Session Key message element to determine the keying
   material used to encrypt the LWAPP communications between the AP and
   the AR.

4.2.3.9 Key Update Trigger

   The Key Update Trigger is used by the AR to request that a Key Update
   Request be initiated by the AP.

4.2.3.9.1 Sending Key Update Trigger

   Key Update Requests are sent by an AR in the Run state to inform the
   AP to initiate a Key Update Request message.

4.2.3.9.2 Format of a Key Update Trigger

   The Key Update Request carries the following message elements:

       Session ID


4.2.3.9.3 Receiving Key Update Trigger

   When a AP receives a Key Update Trigger it generates a key Update
   Request.

4.2.4 AR Configuration

   The AR Configuration messages are used by the LWAPP peers to exchange
   and push configuration as well as for the AR to retrieve statistics
   from the AP.




Calhoun, et al.          Expires June 11, 2004                 [Page 22]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


4.2.4.1 Configure Request

   The Configure Request message is sent by an AP to send its current
   configuration to its AR.

4.2.4.1.1 Sending Configure Requests

   Configure Requests are sent by an AP after receiving a Join Reply.

4.2.4.1.2 Format of a Configure Request

   The Configure Request carries the following message elements:

       Administrative State (for the AP)
       AR Name
       Administrative State (for each radio)
       AP WLAN Radio Configuration (for each radio)
       Multi-domain Capability (for each radio)
       MAC Operation (for each radio)
       PHY TX Power (for each radio)
       PHY TX Power Level (for each Radio)
       PHY DSSS Payload or PHY OFDM Payload (for each radio)
       Antenna (for each radio)
       Supported Rates (for each radio)


4.2.4.1.3 Receiving Configure Requests

   When an AR receives a Configure Request it will act upon the content
   of the packet and respond to the AP with a Configure Response.

4.2.4.2 Configure Response

   The Configure Response message is sent by an AR and provides an
   opportunity for the AR to override an AP's configuration.

4.2.4.2.1 Sending Configure Responses

   Configure Responses are sent by an AR after receiving a Configure
   Request.

4.2.4.2.2 Format of a Configure Response

   The Configure Response carries the following message elements:

   	Result Code
       AP WLAN Radio Configuration (for each radio)
       Operational Rate Set (for each radio)



Calhoun, et al.          Expires June 11, 2004                 [Page 23]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


       Multi-domain Capability (for each radio)
       MAC Operation (for each radio)
       PHY Tx Power (for each Radio)
       PHY DSSS or PHY OFDM Payload (for each radio)
       Antenna (for each radio)


4.2.4.2.3 Receiving Configure Responses

   When an AP receives a Configure Response it acts upon the content of
   the packet, as appropriate.

4.2.4.3 Configuration Update Request

   The Configuration Update Request is a message initiated by the AR to
   update the configuration of an AP while in the Run state.

4.2.4.3.1 Sending Configuration Update Requests

   Configure Update Requests are sent by the AR to provision the AP
   while in the Run state. This is used to modify the configuration of
   the AP while it is operational.

4.2.4.3.2 Format of a Configure Update Request

   The Configure Command Request carries any message elements, except
   the following:

       Result Code                         1
       AR Address                          2
       AP Payload                          3
       AR Payload                          5
       AP WLAN Radio Configuration         7
       Reserved                           16
   	Test                               17
       Reserved                        18-24
       AR Name                            30
       Image Download                     31
       Image Data                         32
       Statistics                         37
       Reserved                        38-42
       Certificate                        43
       Session Key                        45
       Reserved                        46-49







Calhoun, et al.          Expires June 11, 2004                 [Page 24]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


4.2.4.3.3 Receiving Configuration Update Requests

   When an AR receives a Configuration Update Request it will respond
   with a Configuration Update Reply, with the appropriate Result Code.

4.2.4.4 Configuration Update Response

   The Configuration Update Response is the acknowledgement message for
   the Configuration Update Request.

4.2.4.4.1 Sending Configuration Update Responses

   Configuration Update Responses are sent by an AP after receiving a
   Configuration Update Request.

4.2.4.4.2 Format of a Configuration Update Response

   The Configuration Update Response carries the following message
   elements:

        Result Code                        1


4.2.4.4.3 Receiving Configure Update Responses

   When an AR receives a Configure Update Response it knows that the
   configuration was accepted (or not) by the AP.

4.2.4.5 Statistics Report

   Statistics Reports are used for statistics collection at the AR.

4.2.4.5.1 Sending Statistics Reports

   Statistics Reports are sent by an AP periodically, based on the
   configuration, to transfer statistics to the AR.

4.2.4.5.2 Format of a Statistics Report

   The Statistics Report carries the following message elements:

       Statistics


4.2.4.5.3 Receiving Statistics Report

   When an AR receives a Statistics Report it will respond with a
   Statistics Response.



Calhoun, et al.          Expires June 11, 2004                 [Page 25]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


4.2.4.6 Statistics Response

   Statistics Response acknowledges the Statistics Report.

4.2.4.6.1 Sending Statistics Responses

   Statistics Responses are sent by an AR after receiving a Statistics
   Report.

4.2.4.6.2 Format of a Statistics Response

   The Statistics Response carries no message elements.

4.2.4.6.3 Receiving Statistics Responses

   The Statistics Response is simply an acknowledgement of the
   Statistics Report.

4.2.4.7 Reset Request

   The Reset Request is used to cause an AP to reboot.

4.2.4.7.1 Sending Reset Requests

   Reset Requests are sent by an AR to cause an AP to reinitialize its
   operation.

4.2.4.7.2 Format of a Reset Request

   The Reset Request carries no message elements.

4.2.4.7.3 Receiving Reset Requests

   When an AP receives a Reset Request it will respond with a Reset
   Response and then reinitialize itself.

4.2.4.8 Reset Response

   The Reset Response acknowledges the Reset Request.

4.2.4.8.1 Sending Reset Responses

   Reset Responses are sent by an AP after receiving a Reset Request.

4.2.4.8.2 Format of a Reset Response

   The Reset Response carries no message elements.  Its purpose is to
   acknowledge the receipt of the Reset Request.



Calhoun, et al.          Expires June 11, 2004                 [Page 26]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


4.2.4.8.3 Receiving Reset Responses

   When an AR receives a Reset Response it is notified that the AP will
   now reinitialize its operation.

4.2.5 Mobile Session Management

   Messages in this section are used by the AR to create session state
   on the APs.

4.2.5.1 Add Mobile Request

   The Add Mobile Request is used by the AR to inform an AP that it
   should forward traffic from a particular mobile station. The add
   mobile request may also include specific security parameters that
   must be enforced by the AP for the particular mobile.

4.2.5.1.1 Sending Add Mobile Requests

   When the AR sends an Add Mobile Request, it includes any security
   parameters that may be required. Further, if the AR's policy is that
   802.1X (or WPA) is required, it must set the 802.1X only bit in the
   Add Mobile message element. An AR that wishes to update a mobile's
   policy on an AP may be done by simply sending a new Add Mobile
   Request message.

   If 802.1X (or WPA) was established with the mobile station, the AR
   will need to push a session key the AP must use for encrypting all
   traffic to the mobile, which is included in the Mobile Session Key
   message element.

4.2.5.1.2 Format of a Add Mobile Request

   When sent by the AP, the Add Mobile Request contains the following
   message elements:

       Add Mobile
       Mobile Session Key


4.2.5.1.3 Receiving Add Mobile Requests

   When an AP receives an Add Mobile Request, it must first override any
   existing state it may have for the mobile station in question. The
   latest Add Mobile Request overrides any previously received messages.
   If the Add Mobile message element's 802.1X Only bit is set, the AP
   MUST only allow 802.1X packets to be forwarded to the AR, and must
   drop any other messages. The AP will be notified via an Add Mobile



Calhoun, et al.          Expires June 11, 2004                 [Page 27]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


   when it may accept other messages via a new Add Mobile Request from
   the AR.

   If the Mobile Session Key message element was present, the AP MUST
   add the key to its session key table to ensure that all future
   packets to the mobile are encrypted using the new key.

4.2.5.2 Add Mobile Response

   The Add Mobile Response is used to acknowledge a previously received
   Add Mobile Request, and includes a Result Code message element which
   indicates whether an error occured on the AP.

4.2.5.2.1 Sending Add Mobile Response

   Add Mobile Response are seny by the AP as a response to the Add
   Mobile Request.

4.2.5.2.2 Format of a Add Mobile Response

   The Add Mobile Response includes the following message element:

       Result Code


4.2.5.2.3 Receiving Add Mobile Response

   This message requires no special processing, and is only used to
   acknowledge the Add Mobile Request.

4.2.5.3 Delete Mobile Request

   The Delete Mobile Request is used by the AR to inform the AP to
   terminate service to a particular mobile station.

4.2.5.3.1 Sending Delete Mobile Requests

   The AR sends the Delete Mobile Request when it determines that
   service to the mobile must be terminated. This could occur for
   various reasons, including for administrative reaons, as a result of
   the fact that the mobile has roamed to another AP, etc.

4.2.5.3.2 Format of a Delete Mobile Request

   The Delete Mobile Request message must include the following message
   element:

       Delete Mobile



Calhoun, et al.          Expires June 11, 2004                 [Page 28]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


4.2.5.3.3 Receiving Delete Mobile Requests

   When an AP receives the Delete Mobile Request, it must immediately
   terminate service to the mobiel station. Any future packets received
   from the Mobile must result in a deauthenticate message, as specified
   in xxxxx

4.2.5.4 Delete Mobile Response

   The Delete Mobile Response is used to acknowledge a Delete Mobile
   Request.

4.2.5.4.1 Sending Delete Mobile Response

   This message requires no special processing, and is only used to
   acknowledge the Delete Mobile Request.

4.2.5.4.2 Format of a Delete Mobile Response

   The Delete Mobile Response message includes the following message
   element:

       Result Code


4.2.5.4.3 Receiving Delete Mobile Response

   No special processing is required for this packet by the AR.

4.2.6 Firmware Management

   The Firmware Management messages are used by the AR to ensure that
   the image being run on each AP is valid.

4.2.6.1 Image Data Request

   The Image Data Request is used to update firmware on the AP.

4.2.6.1.1 Sending Image Data Requests

   Image Data Requests are exchanged between the AP and the AR to
   download a new program image to an AP.

4.2.6.1.2 Format of a Image Data Request

   When sent by the AP, the Image Data Request contains the following
   message elements:




Calhoun, et al.          Expires June 11, 2004                 [Page 29]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


       Image Download

   When sent by the AR, the Image Data Request contains the following
   message elements:

       Image Data


4.2.6.1.3 Receiving Image Data Requests

   When an AP or AR receives an Image Data Request it will respond with
   a Image Data Response.

4.2.6.2 Image Data Response

   The Image Data Response acknowledges the Image Data Request.

4.2.6.2.1 Sending Image Data Response

   Image Data Responses are sent in response to Image Data Request. Its
   purpose is to acknowledge the receipt of the Image Data Request
   packet.

4.2.6.2.2 Format of an Image Data Response

   The Image Data Response carries no message elements.

4.2.6.2.3 Receiving Image Data Responses

   No action is necessary.





















Calhoun, et al.          Expires June 11, 2004                 [Page 30]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


5. LWAPP Message Elements

   As previously specified, the LWAPP messages MAY include a message
   element. The supported message elements are defined in this section.

   The allowable values for the Type field are the following:

       Description                       Type
       Result Code                         1
       AR Address                          2
       AP Payload                          3
       AP Name                             4
       AR Payload                          5
       Reserved                            6
       AP WLAN Radio Configuration         7
       Rate Set                            8
       Multi-domain capability             9
       MAC Operation                      10
       Reserved                           11
       Tx Power Level                     12
       Direct Sequence Control            13
       OFDM Control                       14
       Supported Rates                    15
       Reserved                           16
       Test                               17
       Reserved                        18-25
       Administrative State               26
       Delete WLAN                        27
       Reserved                        28-29
       AR Name                            30
       Image Download                     31
       Image Data                         32
       Reserved                           33
       Location Data                      34
       Reserved                           35
       Statistics Timer                   36
       Statistics                         37
       Reserved                        38-42
       Certificate                        43
       Session                            44
       Session key                        45
       Reserved                        46-49
       WLAN Payload                       50
       Vendor Specific                    51
       Tx Power                           52
       Add Mobile                         53
       Delete Mobile                      54
       Mobile Session key                 55



Calhoun, et al.          Expires June 11, 2004                 [Page 31]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


5.1 Result Code

   The result code message element value is a 32-bit integer value,
   indicating the result of the request operation corresponding to the
   sequence number in the message.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Result Code                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Result Code:  The following values are supported

      0  Success

      1  Failure


5.2 AR Address

   The AR address message element is used to communicate the identity of
   the AR. The value contains two fields, as shown.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Reserved    |                  MAC Address                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 MAC Address                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Reserved:  MUST be set to zero

   Mac Address:  The MAC Address of the AR


5.3 AP Payload

   The AP payload message element is used by the AP to communicate it's
   current hardware/firmware configuration. The value contains the
   following fields.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Hardware   Version                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Calhoun, et al.          Expires June 11, 2004                 [Page 32]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


     |                      Software   Version                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Boot   Version                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Max Radios  | Radios in use |    Encryption Capabilities    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Hardware Version:  A 32-bit integer representing the AP's hardware
      version number

   Software Version:  A 32-bit integer representing the AP's Firmware
      version number

   Boot Version:  A 32-bit integer representing the AP's boot loader's
      version number

   Max Radios:  An 8-bit value representing the number of radios (where
      each radio is identified via the RID field) supported by the AP

   Radios in use:  An 8-bit value representing the number of radios
      present in the AP

   Encryption Capabilities:  This 16-bit field is used by the AP to
      communicate it's capabilities to the AR. Since most APs support
      link layer encryption, the AR may opt to make use of these
      services. This bitfield supports the following values:

      1 - Encrypt WEP 104:  All packets to/from the mobile station must
         be encrypted using standard 104 bit WEP.

      2 - Encrypt WEP 40:  All packets to/from the mobile station must
         be encrypted using standard 40 bit WEP.

      3 - Encrypt WEP 128:  All packets to/from the mobile station must
         be encrypted using standard 128 bit WEP.

      4 - Encrypt AES-CCM 128:  All packets to/from the mobile station
         must be encrypted using 128 bit AES CCM [10].

      5 - Encrypt TKIP-MIC:  All packets to/from the mobile station must
         be encrypted using TKIP and authenticated using Michael [9].


5.4 AP Name

   The AP name message element value is a variable length byte string.
   The string is NOT zero terminated.




Calhoun, et al.          Expires June 11, 2004                 [Page 33]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


5.5 AR Payload

   The AR payload message element is used by the AR to communicate it's
   current state. The value contains the following fields.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Reserved    |                 Hardware  Version ...         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     HW Ver    |                 Software  Version ...         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     SW Ver    |            Stations           |     Limit     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Limit     |            Radios             |   Max Radio   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Max Radio   |
     +-+-+-+-+-+-+-+-+

   Hardware Version:  A 32-bit integer representing the AP's hardware
      version number

   Software Version:  A 32-bit integer representing the AP's Firmware
      version number

   Stations:  A 16-bit integer representing number of mobile stations
      currently associated with the AR

   Limit:  A 16-bit integer representing the maximum number of stations
      supported by the AR

   Radios:  A 16-bit integer representing the number of APs currently
      attached to the AR

   Max Radio:  A 16-bit integer representing the maximum number of APs
      supported by the AR


5.6 AP WLAN Radio Configuration

   The AP WLAN radio configuration is used by the AR to configure a
   Radio on the AP. The message element value contains the following
   fields.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |    Reserved   |        Occupancy Limit        |



Calhoun, et al.          Expires June 11, 2004                 [Page 34]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    CFP Per    |      CFP Maximum Duration     |     BSS ID    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            BSS ID                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     BSS ID    |        Beacon Period          |    DTIM Per   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Country String                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Radio ID:  An 8-bit value representing the radio to configure

   Reserved:  MUST be set to zero

   Occupancy Limit:  This attribute indicates the maximum amount of
      time, in TU, that a point coordinator MAY control the usage of the
      wireless medium without relinquishing control for long enough to
      allow at least one instance of DCF access to the medium.  The
      default value of this attribute SHOULD be 100, and the maximum
      value SHOULD be 1000

   CFP Period:  The attribute describes the number of DTIM intervals
      between the start of CFPs

   CFP Maximum Duration:  The attribute describes the maximum duration
      of the CFP in TU that MAY be generated by the PCF

   BSSID:  The WLAN Radio's MAC Address

   Beacon Period:  This attribute specifies the number of TU that a
      station uses for scheduling Beacon transmissions. This value is
      transmitted in Beacon and Probe Response frames

   DTIM Period:  This attribute specifies the number of beacon intervals
      that elapses between transmission of Beacons frames containing a
      TIM element whose DTIM Count field is 0. This value is transmitted
      in the DTIM Period field of Beacon frames

   Country Code:  This attribute identifies the country in which the
      station is operating. The first two octets of this string is the
      two character country code as described in document ISO/IEC 3166-
      1.  The third octet MUST be one of the following:

      1. an ASCII space character, if the regulations under which the
         station is operating encompass all environments in the country,






Calhoun, et al.          Expires June 11, 2004                 [Page 35]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


      2. an ASCII 'O' character, if the regulations under which the
         station is operating are for an Outdoor environment only, or

      3. an ASCII 'I' character, if the regulations under which the
         station is operating are for an Indoor environment only


5.7 Rate Set

   The rate set message element value is sent by the AR and contains the
   supported operational rates. It contains the following fields.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |                   Rate Set                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Radio ID:  An 8-bit value representing the radio to configure

   Rate Set:  The AR generates the Rate Set that the AP is to include in
      it's Beacon and Probe messages


5.8 Multi-domain Capability

   The multi-domain capability message element is used by the AR to
   inform the AP of regulatory limits. The value contains the following
   fields.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |    Reserved   |        First Channel #        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Number of Channels      |       Max Tx Power Level      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Radio ID:  An 8-bit value representing the radio to configure

   Reserved:  MUST be set to zero

   First Channnel #:  This attribute indicates the value of the lowest
      channel number in the subband for the associated domain country
      string.






Calhoun, et al.          Expires June 11, 2004                 [Page 36]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


   Number of Channels:  This attribute indicates the value of the total
      number of channels allowed in the subband for the associated
      domain country string.

   Max Tx Power Level:  This attribute indicates the maximum transmit
      power, in dBm, allowed in the subband for the associated domain
      country string.


5.9 MAC Operation

   The MAC operation message element is sent by the AR to set the 802.11
   MAC parameters on the AP. The value contains the following fields.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |    Reserved   |         RTS Threshold         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Short Retry  |  Long Retry   |    Fragmentation Threshold    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Tx MSDU Lifetime                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Rx MSDU Lifetime                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Radio ID:  An 8-bit value representing the radio to configure

   Reserved:  MUST be set to zero

   RTS Threshold:  This attribute indicates the number of octets in an
      MPDU, below which an RTS/CTS handshake MUST NOT be performed. An
      RTS/CTS handshake MUST be performed at the beginning of any frame
      exchange sequence where the MPDU is of type Data or Management,
      the MPDU has an individual address in the Address1 field, and the
      length of the MPDU is greater than this threshold. Setting this
      attribute to be larger than the maximum MSDU size MUST have the
      effect of turning off the RTS/CTS handshake for frames of Data or
      Management type transmitted by this STA. Setting this attribute to
      zero MUST have the effect of turning on the RTS/CTS handshake for
      all frames of Data or Management type transmitted by this STA. The
      default value of this attribute MUST be 2347

   Short Retry:  This attribute indicates the maximum number of
      transmission attempts of a frame, the length of which is less than
      or equal to RTSThreshold, that MUST be made before a failure
      condition is indicated. The default value of this attribute MUST
      be 7



Calhoun, et al.          Expires June 11, 2004                 [Page 37]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


   Long Retry:  This attribute indicates the maximum number of
      transmission attempts of a frame, the length of which is greater
      than dot11RTSThreshold, that MUST be made before a failure
      condition is indicated. The default value of this attribute MUST
      be 4

   Fragmentation Threshold:  This attribute specifies the current
      maximum size, in octets, of the MPDU that MAY be delivered to the
      PHY. An MSDU MUST be broken into fragments if its size exceeds the
      value of this attribute after adding MAC headers and trailers. An
      MSDU or MMPDU MUST be fragmented when the resulting frame has an
      individual address in the Address1 field, and the length of the
      frame is larger than this threshold. The default value for this
      attribute MUST be the lesser of 2346 or the aMPDUMaxLength of the
      attached PHY and MUST never exceed the lesser of 2346 or the
      aMPDUMaxLength of the attached PHY. The value of this attribute
      MUST never be less than 256

   Tx MSDU Lifetime:  This attribute speficies the elapsed time in TU,
      after the initial transmission of an MSDU, after which further
      attempts to transmit the MSDU MUST be terminated. The default
      value of this attribute MUST be 512

   Rx MSDU Lifetime:  This attribute specifies the elapsed time in TU,
      after the initial reception of a fragmented MMPDU or MSDU, after
      which further attempts to reassemble the MMPDU or MSDU MUST be
      terminated. The default value MUST be 512


5.10 Tx Power Level

   The Tx power level message element is sent by the AP and contains the
   different power levels supported. The value contains the following
   fields.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |   Num Levels  |        Power Level [n]        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Radio ID:  An 8-bit value representing the radio to configure

   Num Levels:  The number of power level attributes

   Power Level:  Each power level fields contains a supported power
      level, in mW.




Calhoun, et al.          Expires June 11, 2004                 [Page 38]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


5.11 Direct Sequence Control

   The direct sequence control message element is a bi-directional
   element. When sent by the AP, it contains the current state. When
   sent by the AR, the AP MUST adhere to the values. This element is
   only used for 802.11b radios. The value has the following fields.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |    Reserved   | Current Chan  |  Current CCA  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Energy Detect Threshold                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Radio ID:  An 8-bit value representing the radio to configure

   Reserved:  MUST be set to zero

   Current Channel:  This attribute contains the current operating
      frequency channel of the DSSS PHY.

   Current CCA:  The current CCA method in operation.   Valid values
      are:

      1 - energy detect only (edonly)

      2 - carrier sense only (csonly)

      4 - carrier sense and energy detect (edandcs)

      8 - carrier sense with timer (cswithtimer)

      16 - high rate carrier sense and energy detect (hrcsanded)

   Energy Detect Threshold The current Energy Detect Threshold being
      used by the DSSS PHY


5.12 OFDM Control

   The OFDM control message element is a bi-directional element. When
   sent by the AP, it contains the current state. When sent by the AR,
   the AP MUST adhere to the values. This element is only used for
   802.11a radios. The value contains the following fields.

      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



Calhoun, et al.          Expires June 11, 2004                 [Page 39]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |    Reserved   | Current Chan  |  Band Support |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         TI Threshold                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Radio ID:  An 8-bit value representing the radio to configure

   Reserved:  MUST be set to zero

   Current Channel:  This attribute contains the current operating
      frequency channel of the OFDM PHY.

   Band Supported:  The capability of the OFDM PHY implementation to
      operate in the three U-NII bands. Coded as an integer value of a
      three bit field as follows:

      Bit 0 - capable of operating in the lower (5.15-5.25 GHz) U-NII
         band

      Bit 1 - capable of operating in the middle (5.25-5.35 GHz) U-NII
         band

      Bit 2 - capable of operating in the upper (5.725-5.825 GHz) U-NII
         band

      For example, for an implementation capable of operating in the
      lower and mid bands this attribute would take the value

   TI Threshold:  The Threshold being used to detect a busy medium
      (frequency). CCA MUST report a busy medium upon detecting the RSSI
      above this threshold


5.13 Supported Rates

   The supported rates message element is sent by the AP to indicate the
   rates that it supports. The value contains the following fields.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |                 Supported Rates               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+







Calhoun, et al.          Expires June 11, 2004                 [Page 40]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


   Radio ID:  An 8-bit value representing the radio

   Supported Rates:  The AP includes the Supported Rates that it's
      hardware supports. The format is identical to the Rate Set message
      element


5.14 Test

   The test message element is used as padding to perform MTU discovery,
   and MAY contain any value, of any length.

5.15 Administrative State

   The administrative event message element is used to communicate the
   state of a particular radio. The value contains the following fields.

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |  Admin State  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Radio ID:  An 8-bit value representing the radio to configure

   Admin State:  An 8-bit value representing the administrative state of
      the radio. The following values are supported:

      0 - Enabled

      1 - Disabled


5.16 Delete WLAN

   The delete WLAN message element is used to inform the AP that a
   previously created WLAN is to be deleted. The value contains the
   following fields.

      0                   1                   2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |            WLAN ID            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+







Calhoun, et al.          Expires June 11, 2004                 [Page 41]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


   Radio ID:  An 8-bit value representing the radio

   WLAN ID:  A 16-bit value specifying the WLAN Identifier


5.17 AR Name

   The AR name message element contains an ASCII representation of the
   AR's identity. The value is a variable length byte string.  The
   string is NOT zero terminated.

5.18 Image Download

   The image download message element is sent by the AP to the AR and
   contains the image filename. The value is a variable length byte
   string. The string is NOT zero terminated.

5.19 Image Data

   The image data message element value contains the following fields.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Opcode    |           Checksum            |  Image Data   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Image Data …                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Opcode:  An 8-bit value representing the transfer opcode. The
      following values are supported:

      3 - Image data is included

      5 - An error occurred. Transfer is aborted

   Checksum:  A 16-bit value containing a checksum of the image data
      that follows

   Image Data:  A variable length firmward data


5.20 Location Data

   The location data message element is a variable length byte string
   containing user defined location information (e.g. “Next to
   Fridge”). The string is NOT zero terminated.




Calhoun, et al.          Expires June 11, 2004                 [Page 42]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


5.21 Statistics Timer

   The statistics timer message element value is used by the AR to
   inform the AP of the frequency which it expects to receive updated
   statistics.

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Statistics Timer       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Statistics Timer:  A 16-bit unsigned integer indicating the time, in
      seconds


5.22 Statistics

   The statistics message element is sent by the AP to transmit it's
   current statistics. The value contains the following fields.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |               Tx Fragment Count               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Tx Fragment Cnt|               Multicast Tx Count              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Mcast Tx Cnt  |                  Failed Count                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Failed Count  |                  Retry Count                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Retry Count  |             Multiple Retry Count              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Multi Retry Cnt|             Frame Duplicate Count             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Frame Dup Cnt |               RTS Success Count               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |RTS Success Cnt|               RTS Failure Count               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |RTS Failure Cnt|               ACK Failure Count               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |ACK Failure Cnt|               Rx Fragment Count               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Rx Fragment Cnt|               Multicast RX Count              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Mcast Rx Cnt  |                FCS Error  Count               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Calhoun, et al.          Expires June 11, 2004                 [Page 43]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


     | FCS Error  Cnt|                 Tx Frame Count                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Tx Frame Cnt  |                   Reserved                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Reserved   |
     +-+-+-+-+-+-+-+-+

   Radio ID:  An 8-bit value representing the radio

   Tx Fragment Count:  A 32-bit value representing the number of
      fragmented  frames transmitted.

   Multicast Tx Count:  A 32-bit value representing the number of
      multicast frames transmitted.

   Failed Count:  A 32-bit value representing the transmit excessive
      retries.

   Retry Count:  A 32-bit value representing the number of transmit
      retries.

   Multiple Retry Count:  A 32-bit value representing the number of
      transmits that required more than one retry.

   Frame Duplicate Count:  A 32-bit value representing the duplicate
      frames received.

   RTS Success Count:  A 32-bit value representing the number of
      successful Ready To Send (RTS).

   RTS Failure Count:  A 32-bit value representing the failed RTS.

   ACK Failure Count:  A 32-bit value representing the number of failed
      acknowledgements.

   Rx Fragment Count:  A 32-bit value representing the number of
      fragmented frames received.

   Multicast RX Count:  A 32-bit value representing the number of
      multicast frames received.

   FCS Error Count:  A 32-bit value representing the number of FCS
      failures.

   Reserved:  MUST be set to zero






Calhoun, et al.          Expires June 11, 2004                 [Page 44]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


5.23 Antenna

   The antenna message element is communicated by the AP to the AR to
   provide information on the antennas available. The AR MAY use this
   element to reconfigure the AP's antennas. The value contains the
   following fields.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |   Diversity   |   Reserved    |  Antenna Cnt  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Antenna Selection [0..N]                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Radio ID:  An 8-bit value representing the radio

   Diversity:  An 8-bit value specifying whether the antenna is to
      provide receive diversity. The following values are supported:

      0 - Disabled

      1 - Enabled (may only be true if the antenna can be used as a
         receive antenna)

   Reserved:  MUST be set to zero

   Antenna Count:  An 8-bit value specifying the number of Antenna
      Selection fields.

   Antenna Selection:  A 32-bit value representing the antenna type. The
      following values are supported:

      1 - Sectorized (Left)

      2 - Sectorized (Right)

      3 - Omni


5.24 Certificate

   The certificate message element value is a byte string containing a
   DER-encoded x.509v3 certificate.

5.25 Session ID

   The session ID message element value contains a randomly generated



Calhoun, et al.          Expires June 11, 2004                 [Page 45]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


   [5] unsigned 32-bit integer.

5.26 Session Key Payload

   The Session Key Payload message element is sent by the AR to the AP
   and includes the randomly generated session key, which is used to
   protect the LWAPP control messages. More details are available in
   appedix A. The value contains the following fields.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Session ID                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Session Key                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Session Key                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Session Key                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Session Key                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Session ID:  A 32-bit value representing the session which this
      session key is related to

   Session Key:  A 128-bit value randomly generated session key [5]


5.27 WLAN Payload

   The WLAN payload message element is used by the AR to define a
   wireless LAN on the AP. The value contains the following 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |         WLAN Capability       |    WLAN ID    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    WLAN ID    |         SSID ...                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Radio ID:  An 8-bit value representing the radio

   WLAN Capability:  A 16-bit value containing the capabilities to be
      advertised by the AP within the Probe and Beacon messages.





Calhoun, et al.          Expires June 11, 2004                 [Page 46]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


   WLAN ID:  A 16-bit value specifying the WLAN Identifier

   SSID:  The SSID attribute is a variable length byte string containing
      the SSID to be advertised by the AP.  The string is NOT zero
      terminated.


5.28 Vendor Specific Payload

   The Vendor Specific Payload is used to communicate vendor specific
   information between the AP and the AR. The value contains the
   following 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Vendor Identifier                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Element ID           |   Value...    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vendor Identifier:  A 32-bit value containing the IANA assigned
      “SMI Network Management Private Enterprise Codes [6]

   Element ID:  A 16-bit Element Idenfier which is managed by the
      vendor.

   Element ID:  Value The value associated with the vendor specific
      element.


5.29 Tx Power

   The Tx power message element value is bi-directional. When sent by
   the AP, it contains the current power level of the radio in question.
   When sent by the AR, it contains the power level the AP MUST adhere
   to.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |    Reserved   |        Current Tx Power       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Radio ID:  An 8-bit value representing the radio to configure






Calhoun, et al.          Expires June 11, 2004                 [Page 47]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


   Reserved:  MUST be set to zero

   Current Tx Power:  This attribute contains the transmit output power
      in mW


5.30 Add Mobile

   The Add Mobile message element is used by the AR to inform the AP
   that it should allow traffic from/to a particular mobile station.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |        Association ID         |  MAC Address  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          MAC Address                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  MAC Address  | Preamble Mode |   WLAN ID     |Supported Rates|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Supported Rates                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  802.1X Only  |
     +-+-+-+-+-+-+-+-+

   Radio ID:  An 8-bit value representing the radio

   Association ID:  A 16-bit value specifying the 802.11 Association
      Identifier

   MAC Address:  The mobile station's MAC Address

   Preamble Mode:  This field is set by the AR to inform the AP whether
      short or long preamble should be used with the mobile station. The
      following values are supported:

      0 - Long Preamble:  Long preamble is to be used by the AP when
         communicating with the mobile station.

      1 - Short Preamble:  Short preamble is to be used by the AP when
         communicating with the mobile station.

   WLAN ID:  A 16-bit value specifying the WLAN Identifier

   Supported Rates:  The supported rates to be used with the mobile
      station.





Calhoun, et al.          Expires June 11, 2004                 [Page 48]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


   802.1X Only:  The AR sets this field to one (1) during the
      authentication phase to inform the AP to only allow EAP frames
      through.


5.31 Delete Mobile

   The Delete Mobile message element is used by the AR to inform an AP
   that it should no longer provide service to a particular mobile
   station.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |                  MAC Address                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  MAC Address                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Radio ID:  An 8-bit value representing the radio

   MAC Address:  The mobile station's MAC Address


5.32 Mobile Session Key

   The Mobile Session Key Payload message element is sent when the AR
   determines that encryption of a mobile station must be performed in
   the AP. This message element MUST NOT be present without the Add
   Mobile (see Section 5.30)message element, and MUST NOT be sent if the
   AP had not specifically advertised support for the requested
   encryption scheme (see Section 5.3).

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Mac Address                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Mac Address          |       Encryption Policy       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Encryption Policy       |        Session Key...         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MAC Address:  The mobile station's MAC Address

   Encryption Policy:  The policy field informs the AP how to handle
      packets from/to the mobile station. The following values are
      supported:



Calhoun, et al.          Expires June 11, 2004                 [Page 49]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


      0 - Encrypt WEP 104:  All packets to/from the mobile station must
         be encrypted using standard 104 bit WEP.

      1 - Clear Text:  All packets to/from the mobile station do not
         require any additional crypto processing by the AP.

      2 - Encrypt WEP 40:  All packets to/from the mobile station must
         be encrypted using standard 40 bit WEP.

      3 - Encrypt WEP 128:  All packets to/from the mobile station must
         be encrypted using standard 128 bit WEP.

      4 - Encrypt AES-CCM 128:  All packets to/from the mobile station
         must be encrypted using 128 bit AES CCM [10].

      5 - Encrypt TKIP-MIC:  All packets to/from the mobile station must
         be encrypted using TKIP and authenticated using Michael [9].

   Session Key:  The session key the AP is to use when encrypting
      traffic to/from the mobile station.































Calhoun, et al.          Expires June 11, 2004                 [Page 50]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


6. LWAPP Configuration Variables

   An AP or AR that implements LWAPP discovery MUST allow for the
   following variables to be configured by system management; default
   values are specified so as to make it unnecessary to configure any of
   these variables in many cases.

6.1 MaxDiscoveryInterval

   The maximum time allowed between sending discovery requests from the
   interface, in seconds. Must be no less than 2 seconds and no greater
   than 180 seconds.

   Default: 20 seconds.

6.2 MaxDiscoveries

   The maximum number of discovery requests that will be sent after an
   AP boots.

   Default: 10

6.3 SilentInterval

   The minimum time, in seconds, an AP MUST wait after failing to
   receive any responses to its discovery requests, before it MAY again
   send discovery requests.

   Default: 30

6.4 NeighborDeadInterval

   The minimum time, in seconds, an AP MUST wait without having received
   echo replies to its echo responses, before the destination for the
   echo replies may be considered dead.  Must be no less than
   2*EchoInterval seconds and no greater than 240 seconds.

   Default: 60

6.5 EchoInterval

   The minimum time, in seconds, between sending echo requests to the AR
   with which the AP has joined.

   Default: 30






Calhoun, et al.          Expires June 11, 2004                 [Page 51]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


6.6 DiscoveryInterval

   The minimum time, in seconds, that an AP MUST wait after receiving a
   discovery reply, before sending a join request.

   Default: 5













































Calhoun, et al.          Expires June 11, 2004                 [Page 52]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


7. LWAPP Transport Layer

   The LWAPP protocol can operate at layer 2 or 3. For layer 2 support,
   the LWAPP frames are carried in a native Ethernet frame. As such, the
   protocol is not routable and depends upon layer 2 connectivity
   between the AP and the AR. Layer 3 support is provided by
   encapsulating the LWAPP frames within UDP.

7.1 Layer 2

   This section describes how the LWAPP protocol is provided over native
   ethernet frames. All LWAPP frames are encapsulated within 802.3
   frames, whose fields are defined below.

7.1.1 Source Address

   A MAC address belonging to the interface from which this message is
   sent.  If multiple source addresses are configured on an interface,
   then the one chosen is implementation dependent.

7.1.2 Destination Address

   A MAC address belonging to the interface to which this message is to
   be sent.  This destination address MAY be either an individual
   address or a multicast address, if more than one destination
   interface is intended.

7.1.3 Ethertype

   The Ethertype field is set to 0x88bb.

7.1.4 AR Discovery

   When run over Ethernet, the LWAPP protocol is restricted to a
   specific Ethernet segment. The AR discovery mechanism used with this
   transport is for the Discovery Request message to be transmitted to a
   broadcast address. The ARs will receive this message and reply based
   on their policy.

7.1.5 Extended LWAPP Message Format

   When LWAPP is run over a layer 2 interface, the base LWAPP header is
   extended to include fields that are only useful when run over this
   transport. The following figure and associated text describes the new
   fields.

      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



Calhoun, et al.          Expires June 11, 2004                 [Page 53]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |VER| RID |C|F|L|    Frag ID    |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Ctl/Stat           |   Payload...  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


7.1.5.1 Flags Field

   The first byte contains several flag fields. The following flags are
   only used when LWAPP is run over a layer 2 interface:

7.1.5.2 C Bit

   The C bit indicates whether this packet carries data or control
   information.  When this bit is 0, the packet carries an encapsulated
   data frame.  When this bit is 1, the packet carries control
   information for consumption by the addressed destination.

7.1.5.3 F Bit

   The F bit indicates whether this packet is a fragment.  When this bit
   is 1, the packet is a fragment and MUST be combined with the other
   corresponding fragments to reassemble the complete information
   exchanged between the AP and AR.

7.1.5.4 L Bit

   The L bit is valid only if the 'F' bit is set and indicates whether
   the packet contains the last fragment of a fragmented exchange
   between AP and AR.  When this bit is 1, the packet is not the last
   fragment.  When this bit is 0, the packet is the last fragment.

7.1.5.5 Fragment ID

   The Fragment ID is a value assigned to each group of fragments making
   up a complete set.  The value of Fragment ID is incremented with each
   new set of fragments.  The Fragment ID wraps to zero after the
   maximum value has been used to identify a set of fragments. LWAPP
   only supports up to 2 fragments.

7.2 Layer 3

   This section defines how LWAPP makes use of UDP transport between the
   AP and the AR.






Calhoun, et al.          Expires June 11, 2004                 [Page 54]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


7.2.1 Framing

   Communication between AP and AR is established according to the
   standard UDP client/server model. The connection is initiated by the
   AP (client) to the well-known UDP port of the AR (server) used for
   control messages. This UDP port number of the AR is TBD.

7.2.2 Fragmentation/Reassembly

   When LWAPP is implemented at L3, the transport layer uses IP
   fragmentation to fragment and reassemble LWAPP messages that are
   longer than MTU size used by either AP or AR. The details of IP
   fragmentation are covered in [3].

   [ed: IP fragmentation may raise security concerns and bring
   additional configuration requirements for certain firewalls and NATs.
   One alternative is to re-use the layer 2 (application layer)
   fragmentation reassembly. Comments are welcomed.]

7.2.3 Multiplexing

   LWAPP messages convey control information between AP and AR, as well
   as, 802.11 data frames or 802.11 management frames. As such, LWAPP
   messages needs to be multiplexed in the transport sub-layer and be
   delivered to the proper software entities in the endpoints of the
   protocol.

   In case of Layer 3 connection, multiplexing is achieved by use of
   different UDP ports for control and data packets.

   As part of Join procedure, the AP and AR may negotiate different UDP
   ports, as well as, different IP addresses for data or session
   management messages. [ed: details on how to communicate this
   information in the protocol is still missing].

   In the event the AP and AR are separated by a NAT, with the AP using
   private IP address space, it is the responsibility of the NAT to
   manage appropriate UDP port mapping.

7.2.4 AR Discovery

   When LWAPP is run over routed IP network, the AP and the AR do not
   need to reside in the same IP subnet (broadcast domain). However, in
   the event the peers reside on separate IP subnets, there must exist a
   mechanism for the AP to discover the AR.

   As the AP attempts to establish communication with the AR, it sends
   the Discovery Request message and receives the corresponding reply



Calhoun, et al.          Expires June 11, 2004                 [Page 55]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


   message from the AR. The AP may send the Discovery Request message to
   either limited broadcast IP address (255.255.255.255) or to the
   unicast IP address of the AR. Upon receipt of the message, the AR
   issues a Discovery Reply message to the IP address of the AP,
   regardless of whether Discovery Request was sent as a broadcast or
   unicast message.

   Whether the AP uses a limited IP broadcast or unicast IP address is
   implementation dependent.

   In order for the AP to use a unicast address, it must first obtain
   the IP address of the AR. The configuration of the AR's address in
   the AP is implementation dependent and outside the scope of this
   document. However, some possibilities is to make use of a vendor
   specific DHCP option, DNS name resolution, or even static
   provisioning of the AR's IP address in non-volatile storage.



































Calhoun, et al.          Expires June 11, 2004                 [Page 56]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


8. Handoff Addition to LWAPP

   A Handoff occurs when a mobile station moves from one Acces Point
   (AP) to another AP. This move could happen because of a number of
   reason such as the weakening of the strength of the signal from the
   current AP. During the handoff process, management frames are
   exchanged between station (STA) and the AP. We are considering the
   case for LWAPP where most of the management is done through the
   Access Router (AR) and AP are kept as lightweight as possible.
   Context information also changes hand between the old AP to the new
   AP via the AR.

   For the implementation of the handoff protocol we have discussed
   context caching as well, something similar to the lines of IAPP
   version. There are two main cases when a handoff takes place:
   Re-Association of Mobile Station when context information not
   available at new AP, Re-Association of Mobile Station when context
   already exists at new AP

8.1 Handoff Init (Hoff-Init)

   This message is used by an AP to inform the AR that a STA has
   requested a re-association with it via an 802.11 re-associate
   request.  The Hoff-Init message (as described in Sending Hoff-Init)
   is used in the non-cached scenario.

8.1.1 Sending Hoff-Init

   When the AP receives an 802.11 re-associate requests, it first
   performs any authentication necessary.  The AP will then check to see
   if it has cached information on the STA, if it does not then sends
   the Hoff-Init message to the AR.  If cached information does exist, a
   Hoff-CachedContext message is generated.

   The message contains the STA id of the mobile, and the id of the AP
   the STA used to be associated with.

   {Hoff-Init, STA id, old AP id}

8.1.2 Receiving Hoff-Init

   When an AR receives a Hoff-Init it first checks that the STA id is
   one that is authorized to use the network.  This step will actually
   optional, and will usually be skipped as any STA which has access to
   the network already and is making a valid re-associate request has
   already been authorised on the original associate request.  In the
   case where additional authentication is required though, it would
   happen here.  If authentication is not granted to the STA a



Calhoun, et al.          Expires June 11, 2004                 [Page 57]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


   Hoff-Init-Reply is returned to the AP indicating failure
   (HOFF-NOAUTH).  The AR also checks if the last AP the STA says it was
   associated with matches the routing table.  If it does not, the AR
   sends a Hoff-Init-Reply indicating failure (HOFF-BADASSOC). If this
   check reveals that the STA did not have a previous association within
   the AR routing table a Hoff-Init-Reply failure with HOFF-NOASSOC is
   sent, this will require the STA to attempt a fresh association.  If
   the AP the STA is attempting to re-associate with is the AP which the
   AR has currently associated (for routing), then we send a
   Hoff-Init-Reply with HOFF-STALE to indicate a stale handoff.  Sources
   of this stale move could be packet delay on the IP network, which
   could cause a situation where the old Hoff-Init was delayed meanwhile
   the station timed-out and attempted to re-associate again and
   succeeded.

   With each unique (STA id, old AP id) pair received in a Hoff-Init
   message, increment a counter for that pair.  If this counter exceeds
   a certain operator-defined threshold within an operator-defined
   timeframe, a Hoff-Init-Reply is generated indicating how long it
   should be ignored (in seconds), and denoted as HOFF-IGNORE.  This
   should prevent excess network traffic due to a malicious or
   malfunctioning STA.

   If none of these conditions are met, the AR send a
   Hoff-Context-Request to the indicated previous AP.

   See Fig 3

8.2 Hoff-Context-Request

   This message is generated by an AR and sent to the AP a STA has
   indicated it was previously associated with.  It requests any stored
   context for that mobile.

   The message contains the STA id for which the context is desired.

   {Hoff-Context-Request, STA id}

8.2.1 Sending Hoff-Context-Request

   When the received Hoff-Init passes the tests at the AR, it considers
   it a valid initiation request and generates this message for the
   indicated previous AP.

8.2.2 Receiving Hoff-Context-Request

   When an AP receives a Hoff-Context-Request, it checks to see what
   context it has for the mobile indicated by STA id.



Calhoun, et al.          Expires June 11, 2004                 [Page 58]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


   If such context exists, the Hoff-Context-Reply is generated and sent
   to the AP.  The context in this message may be null.  It is possible
   for the operator to define the action when no context is found.  One
   option is to merely send a Hoff-Context-Reply with a null context
   field, so the AR and new AP could rebuild the context.  The second
   option is to indicate failure in the Hoff-Context-Reply.  This may be
   desirable if it is guaranteed that the AP should have context.  If
   this context is missing, it could indicate a malfunctioning AP or
   other problems.

8.3 Hoff-Context-Reply

   The Hoff-Context-Reply encapsulates the requested STA context.  It
   contains the mobile Id, the sending AP id and the context.

   {Hoff-Context-Reply, STA id, AP id, context block}

8.3.1 Sending Hoff-Context-Reply

   The necessary conditions for sending this message is outlined in
   section Receiving Hoff-Context-Request. At this time the AP changes
   the status of the STA to cached (to signify not-connected).

8.3.2 Receiving Hoff-Context-Reply

   On receiving this message the AR matches the context to the
   corresponding Hoff-Init message using the STA id and sending AP id.
   The AR appends any context it contains for that mobile (e.g. session
   key) and encapsulates both into a successful Hoff-Init-Reply if the
   Hoff-Context-Reply indicates success, if not it generates a
   Hoff-Init-Reply indicating failure (HOFF-NOCXT) and in both cases in
   sends the message immediately to the AP.  If the Hoff-Context-Reply
   indicated success the AR adds the pair (Old AP, new AP) to the
   neighbour list which signifies that they are physical neighbours.
   The list of neighbours can also be constructed as a graph with APs as
   vertices and connections as edges, but is probably easily stored (and
   discussed) as a list of pairs.

   See Fig 5

8.4 Hoff-Init-Reply

   This message is generated to inform the AP the STA is attempting to
   re-associate with whether or not to accept the re-association
   request.

   The format of the reply contains:




Calhoun, et al.          Expires June 11, 2004                 [Page 59]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


   {Hoff-Init-Reply, STA id, AR context block, AP context block}

   as well as the necessary status bits.

8.4.1 Sending Hoff-Init-Reply

   Covered in section Receiving Hoff-Context-Reply, message generated in
   response to the Hoff-Context-Reply.

8.4.2 Receiving Hoff-Init-Reply

   When the AP receives a Hoff-Init-Reply, there are two possibilities:

   1.  Success indicated:  incorporate received context into locally
       stored context and indicate to STA that it may re-associate.

   2.  Failure indicated: inform STA that it may not associate (if
       required).

   On success the AP will construct a Hoff-CachedContext-Update message
   and send it to the AR.

   See Fig 1

8.5 Hoff-CachedContext

   This message is used by an AP to inform the AR that a STA has
   requested a re-association with it via an 802.11 re-associate
   request.  It is used in the scenario where the AP already has cached
   context information for the STA.

8.5.1 Sending Hoff-CachedContext

   As described in Sending Hoff-Init if the AP finds the STA as cached
   it will send a Hoff-CachedContext message to the AR.  This indicates
   that the STA was previously associated with one of the APs known
   neighbours.

   The message contains the STA id of the mobile, and the id of the AP
   the STA used to be associated with.

   {Hoff-CachedContext, STA id, old AP id}

   As receiving Hoff-CachedContext is the cached parallel to receiving
   the non-cached Hoff-Init, it follows that the procedure is very
   similar. When an AR receives a Hoff-CachedContext it may need to do
   some authentication.  As in Receiving Hoff-Init the step is optional,
   and is even less likely to be required here then in the Hoff-Init



Calhoun, et al.          Expires June 11, 2004                 [Page 60]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


   case.  In the case where additional authentication is required
   though, it would happen here.  If authentication is not granted to
   the STA a Hoff-CachedContext-Reply is returned to the AP indicating
   failure (HOFF-NOAUTH).  The AR also checks if the last AP the STA
   says it was associated with matches the routing table.  If it does
   not, the AR sends a Hoff-Init-Reply indicating failure
   (HOFF-BADASSOC).  If this check reveals that the STA did not have a
   previous association within the AR routing table a Hoff-Init-Reply
   failure with HOFF-NOASSOC, both of these types of failure (BADASSOC,
   and NOASSOC) will also indicate that there is a problem somewhere,
   but dealing with that error can be operator defined.  It may be valid
   to keep a count of these errors, and remove the neighbour pair from
   the neighbour graph if a operator defined number of these errors
   occur.  If the AP the STA is attempting to re-associate with is the
   AP which the AR has currently associated (for routing), then we send
   a Hoff-CachedContext-Reply with HOFF-STALE to indicate a stale
   handoff.

   Again, as with the Hoff-Init messages, with each unique (STA id, old
   AP id) pair received in a Hoff-CachedContext message, increment a
   counter for that pair.  If this counter exceeds a certain
   operator-defined threshold within an operator-defined timeframe, a
   Hoff-CachedContext-Reply is generated indicating how long it should
   be ignored (in seconds), and denoted as HOFF-IGNORE.  This should
   prevent excess network traffic due to a malicious or malfunctioning
   STA.

   If everything checks out, a successful Hoff-CachedContext-Reply is
   generated.

   See Fig 4

8.6 Hoff-CachedContext-Reply

   This message is generated by an AR and sent to the AP which a STA is
   trying to associate with.  The message contains the STA id.

8.6.1 Sending Hoff-CachedContext-Reply

   In the case of failure as determined in Receiving Hoff-CachedContext
   the Hoff-CachedContext-Reply will be sent indicating failure,
   otherwise it informs the AP that the that the mobile can be asserted
   as currently active. The format of the reply is:

   {Hoff-CachedContext-Reply, STA id}

   as well as the necessary status bits.




Calhoun, et al.          Expires June 11, 2004                 [Page 61]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


8.6.2 Receiving Hoff-CachedContext-Reply

   When the AP receives this message it can immediately change the
   status of the STA to active, and based on cached context communicate
   immediately. During this phase, some small changes to cached entry
   may be required (such as allocation of new radio frequency); in most
   cases, this should not be necessary.  After the mobile is connected
   (active) and communicating successfully, the AP sends a
   Hoff-CachedContext-Update message to the AR.

   See Fig 2

8.7 Hoff-CachedContext-Update

   This message will contain all the cached information from the STA as
   well as a flag indicating if any of the cached information was
   changed during the re-association.  In the case where the mobile was
   not previously cached (message generated after Receiving
   Hoff-Init-Reply) the changed flag will be marked true.  As the
   handover has already occurred, and this is setting up the fast
   handovers in the future, the Hoff-CachedContext-Update message can be
   processed at a lower priority to that of the other Hoff messages.

8.7.1 Sending Hoff-CachedContext-Update

   Hoff-CachedContext-Update is sent from the new AP to the AR. It will
   be sent as defined in Sending Hoff-CachedContext-Reply and Sending
   Hoff-Init-Reply, and indicates that the mobile as been successfully
   added to the AP, and is used to propagate new cached information for
   the STA.  The Format is:

   {Hoff-CachedContext-Update, STA id, context block}

   as well as the necessary status bits.

8.7.2 Receiving Hoff-CachedContext-Update

   When the AR receives this message the proactive caching procedure is
   started.  The AR will first see if any of the cached information has
   changed (based on the flag within the message).  If there have been
   changes the AR will send a Hoff-CachedContext-New to all APs which
   are neighbours (as defined in the AR list) of the new AP, including
   the pervious AP.  If the context has not changed then the list of APs
   which get the Hoff-CachedContext-New is all the APs which are
   neighbours of the new AP, but were not neighbours of the old access
   point (again including the old AP).

   After sending out the Hoff-CachedContext-New messages, the AR finds



Calhoun, et al.          Expires June 11, 2004                 [Page 62]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


   all the APs which were neighbours of the old AP, but not neighbours
   of the new AP (not including the new AP).  This list receives a
   multicast containing the Hoff-CachedContext-Drop message.

   An operator defined option can be introduced at this step which
   allows providers to specify how many levels of neighbours (that is
   neighbours of neighbours) it wishes to push the cached context to.
   More likely then any varying level of neighbours however, some
   providers may want all possibly connected APs to have cached context
   on all STAs, in which case ‘all levels of neighbours’ could be
   selected.  If a network has areas without coverage, or the full graph
   has not been set up, providers may even want to be able to select
   ‘all APs’.  As a default however, only one level of neighbours
   should be selected, but the option of no caching should also be
   introduced.

8.8 Hoff-CachedContext-New

   This message contains all the up to date information for the mobile,
   and also includes that the STAs status is cached.

8.8.1 Sending Hoff-CachedContext-New

   As described in Receiving Hoff-CachedContext-Update the
   Hoff-CachedContext-New message is generated at the AR and sent to
   neighbours of the new AP, with the exact list to be determined based
   on the Hoff-CachedContext-Update message. Changes in the cached
   context require that the message be sent to all neighbours, and no
   change in the context allows the message to be sent to only new
   neighbours.  In both cases the message should be sent to the old AP.
   The Format is:

   {Hoff-CachedContext-New, STA id, context block}

8.8.2 Receiving a Hoff-CachedContext-New

   When an AP receives the Hoff-CachedContext-New message it finds the
   entry within its table, which matches the STA id in the message and
   it, overwrites the current entry with the information from the
   Hoff-CachedContext-New message.  In the case of the old AP, this will
   update the status to cached. For all other APs (and the old AP) this
   will insure that the cached context is up to date, and it accurately
   reflects the STAs which are currently associated with neighbouring
   APs.

8.9 Hoff-CachedContext-Drop

   This Message contains a STA id.



Calhoun, et al.          Expires June 11, 2004                 [Page 63]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


8.9.1 Sending Hoff-CachedContext-Drop

   As with the Hoff-CachedContext-New the Hoff-CachedContext-Drop is
   defined within Receiving Hoff-CachedContext-Update, and is sent to
   APs which are no longer neighbouring the STA.  That is any AP which
   is a neighbour of the Old AP, but not a neighbour of the new AP will
   get this message.

   The Format is:

   {Hoff-CachedContext-Drop, STA id}

8.9.2 Receiving a Hoff-CachedContext-Drop

   The AP removes the identified STA context from its cache.  A check
   can be done to ensure that the STA context is in the cache first, and
   that it is not currently associated with the AP in question.

   In addition to the above procedures incorporating options for
   removing APs from the neighbour list is required.  In the case that
   an AP is known to be disconnected it should obviously be removed from
   all neighbour relationships.  Having neighbours expiring would be a
   good addition as it would help to eliminate pairs of APs (edges)
   which are either created in error, or were created from one time use.
   Having neighbours expire based on time, such as every week would be a
   good default option. Neighbour removal based on number of handovers
   would be a good addition as well.  The theory that only the handovers
   that occur every week are important within the proactive caching
   scheme might have some merit to particular applications.  In the same
   token, having only the last 1000 handovers may be advantages in
   different scenarios.

8.10 Figures for Handoff addition to LWAPP


   NAP    New AP
   OAP    Old AP
   ONAP   Old Neighbour AP
   NNAP   New Neighbour AP

   STA         NAP         AR        OAP       ONAP        NNAP
    |   RARq    |           |         |          |           |
    |---------->|           |         |          |           |
    |           |     H-I   |         |          |           |
    |           |---------->|         |          |           |
    |           |           |AU       |          |           |
    |           |           |  H-C-Rq |          |           |
    |           |           |-------->|          |           |



Calhoun, et al.          Expires June 11, 2004                 [Page 64]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


    |           |           |  H-C-R  |          |           |
    |           |           |<--------|          |           |
    |           |   H-I-R   |         |          |           |
    |           |<----------|         |          |           |
    |   RAR     |           |NA       |          |           |
    |<----------|           |         |          |           |
    |           |  H-CC-U   |         |          |           |
    |           |---------->|         |          |           |
    |           |           |         |          |  H-CC-N   |
    |           |           |-------->+----------+---------->|
    |           |           |         |  H-CC-D  |           |
    |           |           |---------+--------->|           |
    |           |           |         |          |           |

   1) RARq   RE-ASSOSIATE REQUEST
   2) H-I    Hoff-Init
      AU     Authentication Occurs
   3) H-C-Rq Hoff-Context-Request
   4) H-C-R  Hoff-Context-Reply
   5) H-I-R  Hoff-Init-Reply
      NA     Pair (NAP, OAP) added to Neighbour list
   6) RAR    RE-ASSOSIATE RESPONSE
   7) H-CC-U Hoff-CachedContex-Update
   8) H-CC-N Hoff-CachedContex-New (to OAP and all NNAP)
   9) H-CC-D Hoff-CachedContex-Drop (to all ONAP)
   Fig 1. Success in scenario where STA is not cached at AP



   NAP    New AP
   OAP    Old AP
   ONAP   Old Neighbour AP
   NNAP   New Neighbour AP


   STA         NAP         AR        OAP       ONAP        NNAP
    |   RARq    |           |         |          |           |
    |---------->|           |         |          |           |
    |           |   H-CC    |         |          |           |
    |           |---------->|         |          |           |
    |           |           |AU       |          |           |
    |           |   H-CC-R  |         |          |           |
    |           |<----------|         |          |           |
    |   RAR     |           |         |          |           |
    |<----------|           |         |          |           |
    |           |  H-CC-U   |         |          |           |
    |           |---------->|         |          |           |
    |           |           |         |          |  H-CC-N   |



Calhoun, et al.          Expires June 11, 2004                 [Page 65]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


    |           |           |-------->+----------+---------->|
    |           |           |         |  H-CC-D  |           |
    |           |           |---------+--------->|           |
    |           |           |         |          |           |


   1) RARq   RE-ASSOSIATE REQUEST
   2) H-CC   Hoff-CachedContext
      AU     Authentication Occurs
   3) H-CC-R Hoff-CachedContext-Reply
   4) RAR    RE-ASSOSIATE RESPONSE
   5) H-CC-U Hoff-CachedContex-Update
   6) H-CC-N Hoff-CachedContex-New (to OAP and all NNAP)
   7) H-CC-D Hoff-CachedContex-Drop (to all ONAP)

   Fig 2. Success in scenario where STA is cached at AP



   NAP    New AP
   OAP    Old AP
   ONAP   Old Neighbour AP
   NNAP   New Neighbour AP


   STA         NAP         AR        OAP       ONAP        NNAP
    |   RARq    |           |         |          |           |
    |---------->|           |         |          |           |
    |           |     H-I   |         |          |           |
    |           |---------->|         |          |           |
    |           |           |AU       |          |           |
    |           |   H-I-R   |         |          |           |
    |           |<----------|         |          |           |
    |   RAR     |           |         |          |           |
    |<----------|           |         |          |           |
    |           |           |         |          |           |

   1) RARq   RE-ASSOSIATE REQUEST
   2) H-I    Hoff-Init
      AU     Authentication Occurs
   5) H-I-R  Hoff-Init-Reply {NOAUTH, BADASSOC, NOASSOC, IGNORE}
   6) RAR    RE-ASSOSIATE RESPONSE FAIL

   Fig 3. Failure of types NOAUTH, BADASSOC, NOASSOC, or IGNORE
          non cached scenario






Calhoun, et al.          Expires June 11, 2004                 [Page 66]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


   NAP    New AP
   OAP    Old AP
   ONAP   Old Neighbour AP
   NNAP   New Neighbour AP


   STA         NAP         AR        OAP       ONAP        NNAP
    |   RARq    |           |         |          |           |
    |---------->|           |         |          |           |
    |           |   H-CC    |         |          |           |
    |           |---------->|         |          |           |
    |           |           |AU       |          |           |
    |           |   H-CC-R  |         |          |           |
    |           |<----------|         |          |           |
    |   RAR     |           |         |          |           |
    |<----------|           |         |          |           |
    |           |           |         |          |           |


   1) RARq   RE-ASSOSIATE REQUEST
   2) H-CC   Hoff-CachedContext
      AU     Authentication Occurs
   3) H-CC-R Hoff-CachedContext-Reply {NOAUTH, BADASSOC, NOASSOC, IGNORE}
   4) RAR    RE-ASSOSIATE RESPONSE FAIL

   Fig 4. Failure of types NOAUTH, BADASSOC, NOASSOC, or IGNORE
          cached scenario



   NAP    New AP
   OAP    Old AP
   ONAP   Old Neighbour AP
   NNAP   New Neighbour AP


   STA         NAP         AR        OAP       ONAP        NNAP
    |   RARq    |           |         |          |           |
    |---------->|           |         |          |           |
    |           |     H-I   |         |          |           |
    |           |---------->|         |          |           |
    |           |           |AU       |          |           |
    |           |           |  H-C-Rq |          |           |
    |           |           |-------->|          |           |
    |           |           |  H-C-R  |          |           |
    |           |           |<--------|          |           |
    |           |   H-I-R   |         |          |           |
    |           |<----------|         |          |           |



Calhoun, et al.          Expires June 11, 2004                 [Page 67]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


    |   RAR     |           |         |          |           |
    |<----------|           |         |          |           |

   1) RARq   RE-ASSOSIATE REQUEST
   2) H-I    Hoff-Init
      AU     Authentication Occurs
   3) H-C-Rq Hoff-Context-Request
   4) H-C-R  Hoff-Context-Reply {FAIL, NULL}
   5) H-I-R  Hoff-Init-Reply NOCXT
   6) RAR    RE-ASSOSIATE RESPONSE FAIL

   Fig 5. Failure of type NOCXT in cached scenario







































Calhoun, et al.          Expires June 11, 2004                 [Page 68]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


9. Light Weight Access Protocol Constants

   MAX_RESPONSE_DELAY                   2 seconds

   MAX_SOLICITATION_DELAY               1 second

   SOLICITATION_INTERVAL                3 seconds

   MAX_SOLICITATIONS                    3 transmissions










































Calhoun, et al.          Expires June 11, 2004                 [Page 69]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


10. Security Considerations

   LWAPP uses public key cryptography to ensure trust between the AP and
   the AR. During the Join phase, the AR generates a session key, which
   is used to secure all future control messages. The AP does not
   participate in the key generation, but public key cryptography is
   used to authenticate the resulting key material. A secured delivery
   mechanism to place the certificate in the devices is required. In
   order to maximize session key security, the AP and AR periodically
   update the session keys, which are encrypted using public key
   cryptography. This ensures that a potentially previously compromised
   key does not affect the security of communication with new key
   material.

   One question that periodically arises is why the Join Request is not
   signed. It was felt that requiring a signature in this messages was
   not required for the following reasons:

   1. The Join Request is replayable, so requiring a signature doesn't
      provide much protection unless the switches keep track of all
      previous Join Requests from a given AP. One alternative would have
      been to add a timestamp, but this introduces clock synchronization
      issues. Further, authentication occurs in a later exchange anyway
      (see point 2 below).

   2. The AP is authenticated by virtue of the fact that it can decrypt
      and then use the session keys (encrypted with its own public key),
      so it *is* ultimately authenticated.

   3. A signed Join Request provides a potential Denial of Service
      attack on the AR, which would have to authenticate each
      (potentially malicious) message.



















Calhoun, et al.          Expires June 11, 2004                 [Page 70]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


11. IPR Statement

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document. For more information consult the online list of claimed
   rights.

   Please refer to http://www.ietf.org/ietf/IPR for more information.











































Calhoun, et al.          Expires June 11, 2004                 [Page 71]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


References

   [1]   "Advanced Encryption Standard (AES)", November 2001, <FIPS PUB
         197>.

   [2]   "Counter with CBC-MAC (CCM)", January 2003, <ftp://ftp.isi.edu/
         internet-drafts/draft-housley-ccm-mode-02.txt>.

   [3]   "IP DATAGRAM REASSEMBLY ALGORITHMS", July 1992, <ftp://
         ftp.isi.edu/in-notes/rfc815>.

   [4]   "Key words for use in RFCs to Indicate Requirement Levels",
         March 1997, <ftp://ftp.isi.edu/in-notes/rfc2119>.

   [5]   "Randomness Recommendations for Security", December 1994,
         <ftp://ftp.isi.edu/in-notes/rfc1750>.

   [6]   "Assigned Numbers: RFC 1700 is Replaced by an On-line
         Database", January 2002, <ftp://ftp.isi.edu/in-notes/rfc3232>.

   [7]   "The Internet Standards Process Revision 3", October 1996,
         <ftp://ftp.isi.edu/in-notes/rfc2026>.

   [8]   "Mobility Related Terminology", April 2003, <ftp://ftp.isi.edu/
         internet-drafts/draft-ietf-seamoby-terminology-04.txt>.

   [9]   "WiFi Protected Access (WPA) rev 1.6", April 2003.

   [10]  "IEEE Std 802.11i/3.0: Specification for Enhanced Security",
         November 2003.


Authors' Addresses

   Pat R. Calhoun
   Airespace
   110 Nortech Parkway
   San Jose, CA  95134

   Phone: +1 408-635-2000
   EMail: pcalhoun@airespace.com










Calhoun, et al.          Expires June 11, 2004                 [Page 72]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


   Bob O'Hara
   Airespace
   110 Nortech Parkway
   San Jose, CA  95134

   Phone: +1 408-635-2025
   EMail: bob@airespace.com


   Scott Kelly
   Airespace
   110 Nortech Parkway
   San Jose, CA  95134

   Phone: +1 408-635-2022
   EMail: skelly@airespace.com


   Rohit Suri
   Airespace
   110 Nortech Parkway
   San Jose, CA  95134

   Phone: +1 408-635-2026
   EMail: rsuri@airespace.com


   Daichi Funato
   DoCoMo USA Labs
   180 Metro Drive, Suite 300
   San Jose, CA  95110

   Phone: +1 408-451-4736
   EMail: funato@docomolabs-usa.com


   Michael Vakulenko
   Legra Systems, Inc.
   3 Burlington Woods Drive
   Burlington, MA  01803

   Phone: +1 781-272-8400
   EMail: michaelv@legra.com








Calhoun, et al.          Expires June 11, 2004                 [Page 73]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


   Andrew Johnson
   UNBC
   2550 Laurier Cres.
   Prince George, BC  V2M2B5

   Phone: +1 250-561-2202
   EMail: johnsona@unbc.ca


   Tyler Neilson
   UNBC
   450 Burden st.
   Prince George, BC  V2M2H3

   Phone: +1 250-563-7765
   EMail: neilsont@unbc.ca


   Sean Boyden
   UNBC

   EMail: boydens@unbc.ca


   Kiranjit Sidhu
   UNBC

   EMail: sidhuk@unbc.ca























Calhoun, et al.          Expires June 11, 2004                 [Page 74]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


Appendix A. Session Key Generation

   Note: This version only defines a certificate based mechanism to
   secure traffic between the AP and the AR. A shared-secret mechanism
   will be added in a future version.

A.1 Securing AP-AR communications

   While it is generally straightforward to produce network
   installations in which the communications medium between the AP and
   AR is not accessible to the casual user (e.g. these LAN segments are
   isolated, no RJ45 or other access ports exist between the AP and the
   AR), this will not always be the case. Furthermore, a determined
   attacker may resort to various more sophisticated monitoring and/or
   access techniques, thereby compromising the integrity of this
   connection.

   In general, a certain level of threat on the local (wired) LAN is
   expected and accepted in most computing environments. That is, it is
   expected that in order to provide users with an acceptable level of
   service and maintain reasonable productivity levels, a certain amount
   of risk must be tolerated. It is generally believed that a certain
   perimeter is maintained around such LANs, that an attacker must have
   access to the building(s) in which such LANs exist, and that they
   must be able to "plug in" to the LAN in order to access the network.

   With these things in mind, we can begin to assess the general
   security requirements for AR-AP communications. While an in-depth
   security analysis of threats and risks to these communication is
   beyond the scope of this document, some discussion of the motivation
   for various security-related design choices is useful. The
   assumptions driving the security design thus far include the
   following:

   o  AP-AR communications take place over a wired connection which may
      be accessible to a sophisticated attacker

   o  access to this connection is not trivial for an outsider (i.e.
      someone who does not "belong" in the building) to access

   o  if authentication and/or privacy of end to end traffic for which
      the AP and AR are intermediaries is required, this may be provided
      via IPsec.

   o  privacy and authentication for at least some AP-AR control traffic
      is required (e.g. WEP keys for user sessions, passed from AR to
      AP)




Calhoun, et al.          Expires June 11, 2004                 [Page 75]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


   o  the AR can be trusted to generate strong cryptographic keys

   AR-AP traffic can be considered to consist of two types: data traffic
   (e.g. from or to an end user), and control traffic which is strictly
   between the AR and AP. Since data traffic may be secured using Ipsec
   (or some other end-to-end security mechanism), we confine our
   solution to control traffic. The resulting security consists of two
   components: an authenticated key exchange, and control traffic
   security encapsulation. The security encapsulation is accomplished
   using CCM, described in [2]. This encapsulation provides for strong
   AES-based authentication and encryption. The exchange of
   cryptographic keys used for CCM is described below.

A.2 Authenticated Key Exchange

   The AR and AP accomplish mutual authentication and a cryptographic
   key exchange in a single round trip using the JOIN request/response
   pair. To accomplish this, the AP includes its identity certificate
   (see Section 5.24) and a randomly-generated session ID (see Section
   5.25) which functions as a cryptographic nonce in the JOIN request.
   The AR verifies the AP's certificate, and replies with its own
   identity certificate, and a signed concatenation of the session ID
   and and encrypted cryptographic session key. This exchange is
   detailed below.

   Before proceeding, we define the following notation:

   o  Kpriv - the private key of a public-private key pair.

   o  Kpub - the public key of the pair

   o  M - a clear-text message

   o  C - a cipher-text message.

   o  PKCS1(z) - the PKCS#1 encapsulation of z

   o  E-x{Kpriv, M} - encryption of M using X's private key

   o  E-x{Kpub, M} - encryption of M using X's public key

   o  S-x{M} - a digital signature over M produced by X

   o  V-x{S-x, M} - verification of X's digital signature over M

   o  D-x{Kpriv, C} - decryption of C using X's private key





Calhoun, et al.          Expires June 11, 2004                 [Page 76]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


   o  D-x{Kpub, C} - decryption of C using X's public key

   o  Certificate-AR - AR's Certificate

   o  Certificate-AP - AP's Certificate

   When the AR receives the SessionID value along with the AP's
   certificate, it constructs the reply payload as follows:

   o  Randomly generate enough key material to produce an encryption key
      and an authentication hash key (xx bytes in length). [TBD:
      detailed key material generation instructions]

   o  Compute C1 = E-ap{ Kpub , PKCS1(KeyMaterial)}; this encrypts the
      PKCS#1-encoded key material with the public key of the AP, so that
      only the AP can decrypt it and determine the session keys.

   o  Compute S1 = S-ar{SessionID|C1}; this computes the AR's digital
      signature over the concatenation of the nonce and the encrypted
      key material, and can be verified using the public key of the AR,
      "proving" that the AR produced this; this forms the basis of trust
      for the AP with respect to the source of the session keys.

   o  AR sends (Certificate-AR, C1, S1, SessionID) to AP

   o  AP verifies that SessionID matches an outstanding request

   o  AP verifies authenticity of Certificate-AR

   o  AP computes V-ar{S1, SessionID|C1}, verifying the AR's signature
      over the session identifier and the encrypted key material

   o  AP computes PKCS1(KeyMaterial) = D-ar{ Kpriv , C1}, decrypting the
      session keys using its private key; since these were encrypted
      with the AP's public key, only the AP can successfully decrypt
      this.

      KeyMaterial is divided into the encryption key and the HMAC key
      [TBD: say how] From this point on, all control protocol payloads
      between the AP and AR are encrypted and authenticated. The related
      payloads are described in the sections above.


A.3 Refreshing Cryptographic Keys

   Since AR-AP associations will tend to be relatively long-lived, it is
   sensible to periodically refresh the encryption and authentication
   keys; this is referred to as "rekeying". When the key lifetime



Calhoun, et al.          Expires June 11, 2004                 [Page 77]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


   reaches 95% of the configured value, the rekeying will proceed as
   follows:

   o  AP generates a fresh SessionID value, and constructs a TLV payload
      of type SESSION which contains new SessionID and sends it in
      KEY-UPDATE message to AR.

   o  When the AR receives KEY-UPDATE request with SessionID it
      constructs the reply payload as follows:

      i) Randomly generate enough key material to produce an encryption
         key and an authentication hash key (xx bytes in length).
         [TBD:detailed key material generation instructions]

      ii) Compute C1 = E-ap{ Kpub , PKCS1(KeyMaterial)}; this encrypts
         the PKCS#1-encoded key material with the public key of the AP,
         so that only the AP can decrypt it and determine the session
         keys.

      iii) Compute S1 = S-ar{SessionID|C1}; this computes the AR's
         digital signature over the concatenation of the sessionId and
         the encrypted key material, and can be verified using the
         public key of the AR, "proving" that the AR produced this; this
         forms the basis of trust for the AP with respect to the source
         of the session keys.

      iv) AR then sends a KEY-UPDATE-RSP message to the AP using the new
         session values.

   o  AP must maintain session state for the original SessionID and keys
      until it receives the KEY-UPDATE-RSP, at which time it clears the
      old session.

   o  If AP does not receive the KEY-UPDATE-RSP within a reasonable
      period of time (1 minute?), it will resend the original request
      and reset its response timer.  If no response occurs by the time
      the original session expires, the AP will delete the new and old
      session information, and initiate the DISCOVER process anew.













Calhoun, et al.          Expires June 11, 2004                 [Page 78]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Calhoun, et al.          Expires June 11, 2004                 [Page 79]

Internet-Draft    Light Weight Access Point Protocol (LWAPP)  December 2003


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Calhoun, et al.          Expires June 11, 2004                 [Page 80]

