tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 5412

 
 
 

Lightweight Access Point Protocol

Part 2 of 5, p. 20 to 39
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 20 
3.  LWAPP Transport Layers

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

Top      Up      ToC       Page 21 
3.1.  LWAPP Transport Header

   All LWAPP protocol packets are encapsulated using a common header
   format, regardless of the transport used to carry the frames.
   However, certain flags are not applicable for a given transport, and
   it is therefore necessary to refer to the specific transport section
   in order to determine which flags are valid.

       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 |C|F|L|    Frag ID    |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Status/WLANs         |   Payload...  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.1.1.  VER Field

   A 2-bit field that contains the version of LWAPP used in this packet.
   The value for this document is 0.

3.1.2.  RID Field

   A 3-bit field that contains the Radio ID number for this packet.
   WTPs with multiple radios but a single MAC address use this field to
   indicate which radio is associated with the packet.

3.1.3.  C Bit

   The control message 'C' bit indicates whether this packet carries a
   data or control message.  When this bit is zero (0), the packet
   carries an LWAPP data message in the payload (see Section 4.1).  When
   this bit is one (1), the packet carries an LWAPP control message as
   defined in Section 4.2 for consumption by the addressed destination.

3.1.4.  F Bit

   The Fragment 'F' bit indicates whether this packet is a fragment.
   When this bit is one (1), the packet is a fragment and MUST be
   combined with the other corresponding fragments to reassemble the
   complete information exchanged between the WTP and AC.

Top      Up      ToC       Page 22 
3.1.5.  L Bit

   The Not Last '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 the WTP and AC.  When this bit is 1, the
   packet is not the last fragment.  When this bit is 0, the packet is
   the last fragment.

3.1.6.  Fragment ID

   An 8-bit field whose value is assigned to each group of fragments
   making up a complete set.  The Fragment ID space is managed
   individually for every WTP/AC pair.  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 per frame.

3.1.7.  Length

   The 16-bit length field contains the number of bytes in the Payload.
   The field is encoded as an unsigned number.  If the LWAPP packet is
   encrypted, the length field includes the Advanced Encryption Standard
   Counter with CBC-MAC (AES-CCM) MIC (see Section 10.2 for more
   information).

3.1.8.  Status and WLANS

   The interpretation of this 16-bit field is binding-specific.  Refer
   to the transport portion of the binding for a wireless technology for
   the specification.

3.1.9.  Payload

   This field contains the header for an LWAPP data message or LWAPP
   control message, followed by the data associated with that message.

3.2.  Using IEEE 802.3 MAC as LWAPP Transport

   This section describes how the LWAPP protocol is provided over native
   Ethernet frames.  An LWAPP packet is formed from the MAC frame
   header, followed by the LWAPP message header.  The following figure
   provides an example of the frame formats used when LWAPP is used over
   the IEEE 802.3 transport.

Top      Up      ToC       Page 23 
      Layer 2 LWAPP Data Frame
      +-----------------------------------------------------------+
      | MAC Header | LWAPP Header [C=0] | Forwarded Data ...      |
      +-----------------------------------------------------------+

      Layer 2 LWAPP Control Frame
      +---------------------------------------------------+
      | MAC Header | LWAPP Header [C=1] | Control Message |
      +---------------------------------------------------+
      | Message Elements ... |
      +----------------------+

3.2.1.  Framing

   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.

   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.

   Ethertype

   The Ethertype field is set to 0x88bb.

3.2.2.  AC Discovery

   When run over IEEE 802.3, LWAPP messages are distributed to a
   specific MAC-level broadcast domain.  The AC discovery mechanism used
   with this transport is for a WTP to transmit a Discovery Request
   message to a broadcast destination MAC address.  The ACs will receive
   this message and reply based on their policy.

3.2.3.  LWAPP Message Header Format over IEEE 802.3 MAC Transport

   All of the fields described in Section 3.1 are used when LWAPP uses
   the IEEE 802.3 MAC transport.

Top      Up      ToC       Page 24 
3.2.4.  Fragmentation/Reassembly

   Fragmentation at the MAC layer is managed using the F, L, and Frag ID
   fields of the LWAPP message header.  The LWAPP protocol only allows a
   single packet to be fragmented into 2, which is sufficient for a
   frame that exceeds MTU due to LWAPP encapsulation.  When used with
   Layer 2 (Ethernet) transport, both fragments MUST include the LWAPP
   header.

3.2.5.  Multiplexing

   LWAPP control messages and data messages are distinguished by the 'C'
   bit in the LWAPP message header.

3.3.  Using IP/UDP as LWAPP Transport

   This section defines how LWAPP makes use of IP/UDP transport between
   the WTP and the AC.  When this transport is used, the MAC layer is
   controlled by the IP stack, and there are therefore no special MAC-
   layer requirements.  The following figure provides an example of the
   frame formats used when LWAPP is used over the IP/UDP transport.  IP
   stacks can be either IPv4 or IPv6.

      Layer 3 LWAPP Data Frame
      +--------------------------------------------+
      | MAC Header | IP | UDP | LWAPP Header [C=0] |
      +--------------------------------------------+
      |Forwarded Data ... |
      +-------------------+

      Layer 3 LWAPP Control Frame
      +--------------------------------------------+
      | MAC Header | IP | UDP | LWAPP Header [C=1] |
      +--------------------------------------------+
      | Control Message | Message Elements ... |
      +-----------------+----------------------+

3.3.1.  Framing

   Communication between the WTP and AC is established according to the
   standard UDP client/server model.  The connection is initiated by the
   WTP (client) to the well-known UDP port of the AC (server) used for
   control messages.  This UDP port number of the AC is 12222 for LWAPP
   data and 12223 for LWAPP control frames.

Top      Up      ToC       Page 25 
3.3.2.  AC Discovery

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

   As the WTP attempts to establish communication with the AC, it sends
   the Discovery Request message and receives the corresponding response
   message from the AC.  The WTP must send the Discovery Request message
   to either the limited broadcast IP address (255.255.255.255), a well
   known multicast address, or the unicast IP address of the AC.  Upon
   receipt of the message, the AC issues a Discovery Response message to
   the unicast IP address of the WTP, regardless of whether a Discovery
   Request was sent as a broadcast, multicast, or unicast message.

   Whether the WTP uses a limited IP broadcast, multicast or unicast IP
   address is implementation-dependent.

   In order for a WTP to transmit a Discovery Request to a unicast
   address, the WTP must first obtain the IP address of the AC.  Any
   static configuration of an AC's IP address on the WTP non-volatile
   storage is implementation-dependent.  However, additional dynamic
   schemes are possible: for example:

   DHCP:  A comma-delimited, ASCII-encoded list of AC IP addresses is
          embedded inside a DHCP vendor-specific option 43 extension.
          An example of the actual format of the vendor-specific payload
          for IPv4 is of the form "10.1.1.1, 10.1.1.2".

    DNS:  The DNS name "LWAPP-AC-Address" MAY be resolvable to one or
          more AC addresses.

3.3.3.  LWAPP Message Header Format over IP/UDP Transport

   All of the fields described in Section 3.1 are used when LWAPP uses
   the IPv4/UDP or IPv6/UDP transport, with the following exceptions.

3.3.3.1.  F Bit

   This flag field is not used with this transport, and MUST be set to
   zero.

3.3.3.2.  L Bit

   This flag field is not used with this transport, and MUST be set to
   zero.

Top      Up      ToC       Page 26 
3.3.3.3.  Frag ID

   This field is not used with this transport, and MUST be set to zero.

3.3.4.  Fragmentation/Reassembly for IPv4

   When LWAPP is implemented at L3, the transport layer uses IP
   fragmentation to fragment and reassemble LWAPP messages that are
   longer than the MTU size used by either the WTP or AC.  The details
   of IP fragmentation are covered in [8].  When used with the IP
   transport, only the first fragment would include the LWAPP header.

3.3.5.  Fragmentation/Reassembly for IPv6

   IPv6 does MTU discovery so fragmentation and re-assembly is not
   necessary for UDP packets.

3.3.6.  Multiplexing

   LWAPP messages convey control information between WTP and AC, as well
   as binding specific data frames or binding specific management
   frames.  As such, LWAPP messages need to be multiplexed in the
   transport sub-layer and be delivered to the proper software entities
   in the endpoints of the protocol.  However, the 'C' bit is still used
   to differentiate between data and control frames.

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

   As part of the Join procedure, the WTP and AC may negotiate different
   IP Addresses for data or control messages.  The IP address returned
   in the AP Manager Control IP Address message element is used to
   inform the WTP with the IP address to which it must send all control
   frames.  The AP Manager Data IP Address message element MAY be
   present only if the AC has a different IP address that the WTP is to
   use to send its data LWAPP frames.

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

4.  LWAPP Packet Definitions

   This section contains the packet types and format.  The LWAPP
   protocol is designed to be transport-agnostic by specifying packet
   formats for both MAC frames and IP packets.  An LWAPP packet consists
   of an LWAPP Transport Layer packet header followed by an LWAPP
   message.

Top      Up      ToC       Page 27 
   Transport details can be found in Section 3.

4.1.  LWAPP Data Messages

   An LWAPP data message is a forwarded wireless frame.  When forwarding
   wireless frames, the sender simply encapsulates the wireless frame in
   an LWAPP data packet, using the appropriate transport rules defined
   in Section 3.

   In the event that the encapsulated frame would exceed the transport
   layer's MTU, the sender is responsible for the fragmentation of the
   frame, as specified in the transport-specific section of Section 3.

   The actual format of the encapsulated LWAPP data frame is subject to
   the rules defined under the specific wireless technology binding.

4.2.  LWAPP Control Messages Overview

   The LWAPP Control protocol provides a control channel between the WTP
   and the AC.  The control channel is the series of control messages
   between the WTP and AC, associated with a session ID and key.
   Control messages are divided into the following distinct message
   types:

   Discovery:  LWAPP Discovery messages are used to identify potential
      ACs, their load and capabilities.

   Control Channel Management:  Messages that fall within this
      classification are used for the discovery of ACs by the WTPs as
      well as the establishment and maintenance of an LWAPP control
      channel.

   WTP Configuration:  The WTP Configuration messages are used by the AC
      to push a specific configuration to the WTPs with which it has a
      control channel.  Messages that deal with the retrieval of
      statistics from the WTP also fall in this category.

   Mobile Session Management:  Mobile Session Management messages are
      used by the AC to push specific mobile policies to the WTP.

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

   Control Channel, WTP Configuration, and Mobile Session Management
   MUST be implemented.  Firmware Management MAY be implemented.

   In addition, technology-specific bindings may introduce new control
   channel commands that depart from the above list.

Top      Up      ToC       Page 28 
4.2.1.  Control Message Format

   All LWAPP control messages are sent encapsulated within the LWAPP
   header (see Section 3.1).  Immediately following the header is the
   LWAPP control header, which has 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Message Type |    Seq Num    |      Msg Element Length       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Session ID                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Msg Element [0..N]       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.2.1.1.  Message Type

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

                  Description                       Value
                  Discovery Request                    1
                  Discovery Response                   2
                  Join Request                         3
                  Join Response                        4
                  Join ACK                             5
                  Join Confirm                         6
                  Unused                             7-9
                  Configure Request                   10
                  Configure Response                  11
                  Configuration Update Request        12
                  Configuration Update Response       13
                  WTP Event Request                   14
                  WTP Event Response                  15
                  Change State Event Request          16
                  Change State Event Response         17
                  Unused                           18-21
                  Echo Request                        22
                  Echo Response                       23
                  Image Data Request                  24
                  Image Data Response                 25
                  Reset Request                       26
                  Reset Response                      27
                  Unused                           28-29
                  Key Update Request                  30
                  Key Update Response                 31
                  Primary Discovery Request           32

Top      Up      ToC       Page 29 
                  Primary Discovery Response          33
                  Data Transfer Request               34
                  Data Transfer Response              35
                  Clear Config Indication             36
                  WLAN Config Request                 37
                  WLAN Config Response                38
                  Mobile Config Request               39
                  Mobile Config Response              40

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

   When an LWAPP control frame is sent, its internal sequence number
   counter is monotonically incremented, ensuring that no two requests
   pending have the same sequence number.  This field will wrap back to
   zero.

4.2.1.3.  Message Element Length

   The length field indicates the number of bytes following the Session
   ID field.  If the LWAPP packet is encrypted, the length field
   includes the AES-CCM MIC (see Section 10.2 for more information).

4.2.1.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 WTP and the
   AC.  Note that a Session ID is a random value that MUST be unique
   between a given AC and any of the WTPs with which it may be
   communicating.

4.2.1.5.  Message Element [0..N]

   The message element(s) carry the information pertinent to each of the
   control message types.  Every control message in this specification
   specifies which message elements are permitted.

4.2.2.  Message Element Format

   The message element is used to carry information pertinent to a
   control message.  Every message element is identified by the Type
   field, whose numbering space is managed via IANA (see Section 16).
   The total length of the message elements is indicated in the Message
   Element Length field.

Top      Up      ToC       Page 30 
   All of the message element definitions in this document use a diagram
   similar to the one below in order to depict their formats.  Note that
   in order to simplify this specification, these diagrams do not
   include the header fields (Type and Length).  However, in each
   message element description, the header's field values will be
   defined.

   Note that additional message elements may be defined in separate IETF
   documents.

   The format of a message element uses the 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Type     |             Length            |   Value ...   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where Type (8 bits) identifies the character of the information
   carried in the Value field and Length (16 bits) indicates the number
   of bytes in the Value field.

4.2.2.1.  Generic Message Elements

   This section includes message elements that are not bound to a
   specific control message.

4.2.2.1.1.  Vendor Specific

   The Vendor-Specific Payload is used to communicate vendor-specific
   information between the WTP and the AC.  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...    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   104 for Vendor Specific

   Length:   >= 7

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

Top      Up      ToC       Page 31 
   Element ID:   A 16-bit Element Identifier that is managed by the
      vendor.

   Value:   The value associated with the vendor-specific element.

4.2.3.  Quality of Service

   It is recommended that LWAPP control messages be sent by both the AC
   and the WTP with an appropriate Quality-of-Service precedence value,
   ensuring that congestion in the network minimizes occurrences of
   LWAPP control channel disconnects.  Therefore, a Quality-of-Service-
   enabled LWAPP device should use:

   802.1P:   The precedence value of 7 SHOULD be used.

   DSCP:   The Differentiated Services Code Point (DSCP) tag value of 46
           SHOULD be used.

5.  LWAPP Discovery Operations

   The Discovery messages are used by a WTP to determine which ACs are
   available to provide service, as well as the capabilities and load of
   the ACs.

5.1.  Discovery Request

   The Discovery Request is used by the WTP to automatically discover
   potential ACs available in the network.  A WTP must transmit this
   command even if it has a statically configured AC, as it is a
   required step in the LWAPP state machine.

   Discovery Requests MUST be sent by a WTP in the Discover state after
   waiting for a random delay less of than MaxDiscoveryInterval, after a
   WTP first comes up or is (re)initialized.  A WTP 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 WTP Discoveries.  An example of
   this occurring would be when many WTPs are powered on at the same
   time.

   Discovery Requests MUST be sent by a WTP when no Echo Responses are
   received for NeighborDeadInterval and the WTP returns to the Idle
   state.  Discovery Requests are sent after NeighborDeadInterval, they
   MUST be sent after waiting for a random delay less than

Top      Up      ToC       Page 32 
   MaxDiscoveryInterval.  A WTP 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 WTP enters the Sulking state and
   MUST wait for an interval equal to SilentInterval before sending
   further Discovery Requests.

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

   Upon receiving a Discovery Request, the AC will respond with a
   Discovery Response sent to the address in the source address of the
   received Discovery Request.

   The following subsections define the message elements that MUST be
   included in this LWAPP operation.

5.1.1.  Discovery Type

   The Discovery message element is used to configure a WTP to operate
   in a specific mode.

       0
       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      | Discovery Type|
      +-+-+-+-+-+-+-+-+

   Type:   58 for Discovery Type

   Length:   1

   Discovery Type:   An 8-bit value indicating how the AC was
      discovered.  The following values are supported:

      0 -  Broadcast

      1 -  Configured

Top      Up      ToC       Page 33 
5.1.2.  WTP Descriptor

   The WTP Descriptor message element is used by the WTP to communicate
   its 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                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Software   Version                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Boot   Version                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Max Radios  | Radios in use |    Encryption Capabilities    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   3 for WTP Descriptor

   Length:   16

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

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

   Boot Version:   A 32-bit integer representing the WTP'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 WTP.

   Radios in Use:   An 8-bit value representing the number of radios
      present in the WTP.

   Encryption Capabilities:   This 16-bit field is used by the WTP to
      communicate its capabilities to the AC.  Since most WTPs support
      link-layer encryption, the AC may make use of these services.
      There are binding-dependent encryption capabilites.  A WTP that
      does not have any encryption capabilities would set this field to
      zero (0).  Refer to the specific binding for the specification.

Top      Up      ToC       Page 34 
5.1.3.  WTP Radio Information

   The WTP Radio Information message element is used to communicate the
   radio information in a specific slot.  The Discovery Request MUST
   include one such message element per radio in the WTP.  The Radio-
   Type field is used by the AC in order to determine which technology-
   specific binding is to be used with the WTP.

   The value contains two fields, as shown:

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

   Type:   4 for WTP Radio Information

   Length:   2

   Radio ID:   The Radio Identifier, typically refers to some interface
      index on the WTP.

   Radio Type:   The type of radio present.  The following values are
      supported:

      1 - 802.11bg:   An 802.11bg radio.

      2 - 802.11a:   An 802.11a radio.

      3 - 802.16:   An 802.16 radio.

      4 - Ultra Wideband:   A UWB radio.

      7 - all:   Used to specify all radios in the WTP.

5.2.  Discovery Response

   The Discovery Response is a mechanism by which an AC advertises its
   services to requesting WTPs.

   Discovery Responses are sent by an AC after receiving a Discovery
   Request.

Top      Up      ToC       Page 35 
   When a WTP receives a Discovery Response, it MUST wait for an
   interval not less than DiscoveryInterval for receipt of additional
   Discovery Responses.  After the DiscoveryInterval elapses, the WTP
   enters the Joining state and will select one of the ACs that sent a
   Discovery Response and send a Join Request to that AC.

   The following subsections define the message elements that MUST be
   included in this LWAPP operation.

5.2.1.  AC Address

   The AC Address message element is used to communicate the identity of
   the AC.  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                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   2 for AC Address

   Length:   7

   Reserved:   MUST be set to zero

   MAC Address:   The MAC address of the AC

5.2.2.  AC Descriptor

   The AC Descriptor message element is used by the AC to communicate
   its 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   |    Security   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 36 
   Type:   6 for AC Descriptor

   Length:   17

   Reserved:   MUST be set to zero

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

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

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

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

   Radios:   A 16-bit integer representing the number of WTPs currently
      attached to the AC.

   Max Radio:   A 16-bit integer representing the maximum number of WTPs
      supported by the AC.

   Security:   An 8-bit bitmask specifying the security schemes
      supported by the AC.  The following values are supported (see
      Section 10):

      1 -  X.509 Certificate-Based

      2 -  Pre-Shared Secret

5.2.3.  AC Name

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

       0
       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      | Name ...
      +-+-+-+-+-+-+-+-+

   Type:   31 for AC Name

   Length:   > 0

Top      Up      ToC       Page 37 
   Name:   A variable-length ASCII string containing the AC's name.

5.2.4.  WTP Manager Control IPv4 Address

   The WTP Manager Control IPv4 Address message element is sent by the
   AC to the WTP during the discovery process and is used by the AC to
   provide the interfaces available on the AC, and their current load.
   This message element is useful for the WTP to perform load balancing
   across multiple interfaces.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           IP Address                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           WTP Count           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   99 for WTP Manager Control IPv4 Address

   Length:   6

   IP Address:   The IP address of an interface.

   WTP Count:   The number of WTPs currently connected to the interface.

5.2.5.  WTP Manager Control IPv6 Address

   The WTP Manager Control IPv6 Address message element is sent by the
   AC to the WTP during the discovery process and is used by the AC to
   provide the interfaces available on the AC, and their current load.
   This message element is useful for the WTP to perform load balancing
   across multiple interfaces.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           IP Address                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           IP Address                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           IP Address                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           IP Address                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           WTP Count           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 38 
   Type:   137 for WTP Manager Control IPv6 Address

   Length:   6

   IP Address:   The IP address of an interface.

   WTP Count:   The number of WTPs currently connected to the interface.

5.3.  Primary Discovery Request

   The Primary Discovery Request is sent by the WTP in order to
   determine whether its preferred (or primary) AC is available.

   Primary Discovery Requests are sent by a WTP when it has a primary AC
   configured, and is connected to another AC.  This generally occurs as
   a result of a failover, and is used by the WTP as a means to discover
   when its primary AC becomes available.  As a consequence, this
   message is only sent by a WTP when it is in the Run state.

   The frequency of the Primary Discovery Requests should be no more
   often than the sending of the Echo Request message.

   Upon receiving a Discovery Request, the AC will respond with a
   Primary Discovery Response sent to the address in the source address
   of the received Primary Discovery Request.

   The following subsections define the message elements that MUST be
   included in this LWAPP operation.

5.3.1.  Discovery Type

   The Discovery Type message element is defined in Section 5.1.1.

5.3.2.  WTP Descriptor

   The WTP Descriptor message element is defined in Section 5.1.2.

5.3.3.  WTP Radio Information

   A WTP Radio Information message element must be present for every
   radio in the WTP.  This message element is defined in Section 5.1.3.

5.4.  Primary Discovery Response

   The Primary Discovery Response is a mechanism by which an AC
   advertises its availability and services to requesting WTPs that are
   configured to have the AC as its primary AC.

Top      Up      ToC       Page 39 
   Primary Discovery Responses are sent by an AC after receiving a
   Primary Discovery Request.

   When a WTP receives a Primary Discovery Response, it may opt to
   establish an LWAPP connection to its primary AC, based on the
   configuration of the WTP Fallback Status message element on the WTP.

   The following subsections define the message elements that MUST be
   included in this LWAPP operation.

5.4.1.  AC Descriptor

   The Discovery Type message element is defined in Section 5.2.2.

5.4.2.  AC Name

   The AC Name message element is defined in Section 5.2.3.

5.4.3.  WTP Manager Control IPv4 Address

   A WTP Radio Information message element MAY be present for every
   radio in the WTP that is reachable via IPv4.  This message element is
   defined in Section 5.2.4.

5.4.4.  WTP Manager Control IPv6 Address

   A WTP Radio Information message element must be present for every
   radio in the WTP that is reachable via IPv6.  This message element is
   defined in Section 5.2.5.



(page 39 continued on part 3)

Next RFC Part