Skip to main content

Mesh Link Establishment
draft-kelsey-intarea-mesh-link-establishment-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Richard Kelsey
Last updated 2012-03-07
RFC stream (None)
Formats
Reviews
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-kelsey-intarea-mesh-link-establishment-02
Internet Area WG                                               R. Kelsey
Internet-Draft                                         Ember Corporation
Intended status: Standards Track                           March 7, 2012
Expires: September 8, 2012

                        Mesh Link Establishment
            draft-kelsey-intarea-mesh-link-establishment-02

Abstract

   This document defines the mesh link establishment (MLE) protocol for
   establishing and configuring links in an ad hoc mesh radio network.
   Effective mesh networking using radio links requires identifying,
   configuring, and securing usable links to neighboring devices.  In an
   ad hoc mesh network a device's neighbors may come and go as the
   network's membership and physical environment change.  Newly usable
   links need to be identified and configured automatically, where
   configuration values can include link-layer addresses, transmit and
   receive modes, security parameters, and so forth.  MLE includes the
   option of securing the configuration messages themselves, as link-
   layer security may not be available prior to configuration.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on September 8, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of

Kelsey                  Expires September 8, 2012               [Page 1]
Internet-Draft           Mesh Link Establishment              March 2012

   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Message Formats  . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Values . . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.1.  Source Address . . . . . . . . . . . . . . . . . . . . . .  8
     5.2.  Mode . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.3.  Timeout  . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.4.  Challenge  . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.5.  Response . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.6.  Replay Counter . . . . . . . . . . . . . . . . . . . . . . 10
     5.7.  Link Quality . . . . . . . . . . . . . . . . . . . . . . . 10
     5.8.  Param  . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   6.  Message transmission . . . . . . . . . . . . . . . . . . . . . 13
   7.  Processing of incoming messages  . . . . . . . . . . . . . . . 15
   8.  Application to 802.15.4  . . . . . . . . . . . . . . . . . . . 16
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 21
     12.2. Informative References . . . . . . . . . . . . . . . . . . 21
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22

Kelsey                  Expires September 8, 2012               [Page 2]
Internet-Draft           Mesh Link Establishment              March 2012

1.  Introduction

   The configuration of individual links in an ad hoc mesh network can
   fall into a gap between standards.  Link layer standards typically
   deal with individual links and networking standards assume that the
   links are up and running.  In an ad hoc mesh network a device's
   neighbors may come and go as the network's membership and physical
   environment change, requiring that new links be configured
   automatically.  The required configuration information can include
   link layer addressing, transmit and receive modes, wake/sleep cycles,
   and so on.  Security configuration is particularly important, as the
   link layer may not be able to secure packets until after the link
   itself has been configured.

   MLE can be used to configure individual links and to distribute
   configuration values that are shared across a network.  MLE messages
   are sent using UDP.  Per-link configuration uses one-hop messages
   with link-local addresses.  Network-wide configuration uses
   multicasts and requires some form of multi-hop multicast forwarding.

   Link parameters can be unicast between two neighboring nodes, as when
   configuring a particular link, or multicast to all neighbors, in
   order to advertise to new neighbors or to efficiently transmit
   updated values.

   One of the most important properties of a radio link, how well the
   two neighbors hear each other, often cannot be determined
   unilaterally by either node.  Many radio links are asymmetric, where
   messages traveling one way across the link are received more or less
   reliably than messages traveling in the opposite direction.  There is
   a chicken and egg problem here.  It is a waste of effort to configure
   a link that does not have sufficient two-way reliability to be
   useful, but the two-way reliability cannot be determined without
   exchanging messages over the link.  MLE resolves this by allowing a
   node to periodically multicast an estimate of the quality of its
   links.  This allows a node to determine if it has a usable radio link
   to a neighbor without first configuring that link.

1.1.  Requirements Language

   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 [RFC2119].

Kelsey                  Expires September 8, 2012               [Page 3]
Internet-Draft           Mesh Link Establishment              March 2012

2.  Terminology

   ETX                 Expected Transmission Count; the number of
                       transmission attempts required to send a packet
                       over a particular link.  Defined to be the
                       product of the IDR values for both directions.  A
                       perfect link has an ETX of 1, less than perfect
                       links have higher ETX values.

   Frame counter       A value that is incremented with each new secured
                       message.  Used with [CCM] to ensure that no two
                       messages are secured using the same key and nonce
                       pair.  In 802.15.4 the same counter is used as
                       both a frame counter and a replay counter.

   IDR                 Inverse Delivery Ration; the number of
                       transmission attempts divided by the number of
                       successful transmissions in a given direction
                       over a link.

   Replay counter      A message value that is incremented with each new
                       transmission.  Incoming messages whose counter
                       value is the same or lower as that in an earlier
                       message are discarded.

Kelsey                  Expires September 8, 2012               [Page 4]
Internet-Draft           Mesh Link Establishment              March 2012

3.  Overview

   MLE is a means of transmitting link configuration values.  An MLE
   message is one of:

   Link configuration  A one-hop unicast sent as part of establishing a
                       link with one particular neighbor.

   Advertisement       A one-hop multicast that advertise a node's link
                       quality estimates to its neighbors.

   Update              A multicast that updates a shared configuration
                       value.

   If negotiation is required, establishment of a link may require an
   exchange of two or more unicast messages.  The only multiple-message
   exchange in the MLE protocol performs liveness determination (replay
   counter initialization).

Kelsey                  Expires September 8, 2012               [Page 5]
Internet-Draft           Mesh Link Establishment              March 2012

4.  Message Formats

   MLE messages consist of a command and a series of type-length-value
   parameters.  MLE messages can be secured using Advanced Encryption
   Standard 128 [AES] in Counter with CBC-MAC Mode [CCM] for data
   authentication and encryption.

   The security data is formatted as an auxiliary security header as
   specified in [IEEE802154].  There are two exceptions to this: a
   security header with security level of 0 does not contain a frame
   counter, and when frame counters are included they are in big-endian
   form.  This first exception avoids the need to include a frame
   counter when security is being provided by the link layer.  The
   second is to conform with normal IETF practice.  Otherwise, the
   presence and length of the frame counter, key identifier, and MIC
   follow [IEEE802154].

   If MLE security is in use each device MUST maintain an outgoing
   frame/replay counter for use in securing outgoing packets in
   compliance with [CCM].  MLE does not include a method for configuring
   its own frame counters and so does not provide complete protection
   against replayed MLE packets.

   MLE security MUST NOT use any key that is being used by the link (or
   any other) layer MLE security MAY use a key derived using a
   cryptographic hash from a key being used at the link layer.  Other
   than the above requirements, the distribution or derivation of the
   key(s) used for MLE security is outside the scope of this document.

                <message> := <version>
                             <security-data>
                             <command-id>
                             <tlv>*
                             <mic>?

                <security-data> := <security-control-field>
                                   <frame-counter>?
                                   <key-identifier>?

   The version field is one byte in length and has the value 0.

   The defined command IDs are:

   0    Link Request.  A request to establish a link to a neighbor.

Kelsey                  Expires September 8, 2012               [Page 6]
Internet-Draft           Mesh Link Establishment              March 2012

   1    Link Accept.  Accept a requested link.

   2    Link Accept and Request.  Accept a requested link and request
        initialization in the other direction.

   3    Link Reject.  Reject a link request.

   4    Advertisement.  Inform neighbors of a device's link state.

   5    Update.  Informs of changes to link parameters shared by all
        nodes in a network.

   (values to be confirmed by IANA) The first four (Link Request, Link
   Accept, Link Accept and Request, and Link Reject) are collectively
   referred to as link configuration messages.

Kelsey                  Expires September 8, 2012               [Page 7]
Internet-Draft           Mesh Link Establishment              March 2012

5.  Values

   Values are encoded using a type-length-value format, where the type
   and length are one byte each and the length field contains the length
   of the value in bytes.  There are no alignment requirements and no
   padding.

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

5.1.  Source Address

      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 = 0    |    Length     |    Source Address ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length              Length of the Address field in octets.

   Source Address      A link-layer address assigned to the source of
                       the message.

   A given radio interface may have multiple link-layer addresses.  This
   TLV is used to communicate any source address(es) that is not
   included in the message by the link layer itself.

5.2.  Mode

      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 = 1    |    Length     |    Mode ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length              Length of the Mode field in octets.

Kelsey                  Expires September 8, 2012               [Page 8]
Internet-Draft           Mesh Link Establishment              March 2012

   Mode                Mode configuration of this link.  The possible
                       values are specific to the link layer in use.

   Mode information can include such things as the senders listening
   schedule, whether it will poll for messages, and so forth.

5.3.  Timeout

      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 = 2    |    Length     |                Timeout
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length              4

   Timeout             The expected maximum interval between
                       transmissions by the sender in seconds.

   This allows the receiver to more accurately timeout a link to a
   neighbor that polls for its incoming messages.

5.4.  Challenge

      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 = 3    |     Length    |    Challenge ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length              Length of the Challenge field in octets.

   Challenge           A random value used to determine the freshness of
                       any reply to this message.

   An important part of replay protection is determining if a newly-
   heard neighbor is actually present or is a set of recorded messages.
   This is done by sending a random challenge value to the neighbor and
   then receiving that same value in a Response TLV sent by the
   neighbor.

Kelsey                  Expires September 8, 2012               [Page 9]
Internet-Draft           Mesh Link Establishment              March 2012

5.5.  Response

      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 = 4    |     Length    |    Response ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length              Length of the Response field in octets.

   Response            The challenge value echoed back to the original
                       sender (in network order).

5.6.  Replay Counter

      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 = 5    |     Length    |    Replay Counter ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length              Length of the Replay Counter field in octets.

   Response            The sender's current outgoing link-layer Replay
                       Counter.

5.7.  Link Quality

     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 = 6    |     Length    |C| Res | Size  | Neighbor Data ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length              Length of following values in octets (1 + (size +
                       3) * number-of-neighbors).

   C                   Complete: 1 if the message includes all
                       neighboring routers for which the source has link
                       quality data.  Multicast Link Quality TLVs
                       normally contain complete information; a unicast
                       to a particular neighbor would normally contain

Kelsey                  Expires September 8, 2012              [Page 10]
Internet-Draft           Mesh Link Establishment              March 2012

                       only that neighbor's link quality and would not
                       have the C flag set.

   Res                 Reserved.

   Size                The size in octets of the included neighbor
                       addresses, minus 1.  This supports addresses of
                       lengths 1 to 16.

   Neighbor Data       A sequence of neighbor records, each containing
                       an "established" flag, the estimated incoming
                       link reliability (IDR), and the neighbor's link-
                       layer address.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |I|O| reserved  | Incoming IDR  |    Neighbor Address ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   I(ncoming)          Set if the sender has configured its link with
                       this neighbor and will accept incoming messages
                       from them.

   O(utgoing)          Set if the sender believes that the neighbor has
                       configured its link with the sender and will
                       accept incoming messages from the sender.  This
                       flag is set if the sender has sent a Link Accept
                       message to the neighbor and cleared if the sender
                       has subsequently received a Link Quality TLV from
                       the neighbor with the sender's I flag cleared.

   Incoming IDR        The estimated inverse delivery ratio of messages
                       sent by the neighbor to the source of this
                       message.  To allow for fractional IDR, the value
                       encoded is multiplied by 32.  A perfect link,
                       with an actual IDR of 1, would have an Incoming
                       IDR of 0x20.  A value of 0xFF indicates that the
                       link is unusable.

   Address             A link-layer address of a neighbor.

   The I and O flags are used to facilitate the two-way use of links
   between neighboring routers.  They are advisory only; a node may send
   a message to a neighbor regardless of the state of the most recently
   seen corresponding I bit from that neighbor.  Similarly, a node may

Kelsey                  Expires September 8, 2012              [Page 11]
Internet-Draft           Mesh Link Establishment              March 2012

   unilaterally discard a configured link without informing the neighbor
   of its intention.

   A node that does not have a link configured to a neighbor but
   receives a Link Quality TLV from that neighbor with the node's O flag
   set SHOULD send an MLE message with a Link Quality TLV with that
   neighbor's I bit cleared.  This message may either be a regular
   multicast Advertisement or a unicast to that neighbor containing only
   a single Neighbor Data record.

5.8.  Param

      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 = 7    |     Length    | Parameter ID  |     Delay
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                                     |     Value ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length              Length of the Value field in octets plus 5.

   Parameter ID        The ID of the parameter to be changed.

   Delay               The delay before setting the parameter, in
                       milliseconds.  This gives time for the Update
                       message carrying the Param TLV to propagate
                       throughout the network.

   Value               The new value of the parameter.

   Update messages SHOULD contain only Param TLVs.

   The defined Parameter IDs are:

   0    Channel

   1    PAN ID

   2    Permit Joining

   (values to be confirmed by IANA)

Kelsey                  Expires September 8, 2012              [Page 12]
Internet-Draft           Mesh Link Establishment              March 2012

6.  Message transmission

   Messages SHOULD be sent using UDP port XXXX (value to be assigned by
   IANA).  Link configuration and advertisement messages MUST be sent
   with an IP Hop Limit of 255, either to a link-local unicast address
   or to the link-local all-nodes (FF02::2) or all-routers (FF02::1)
   multicast addresses.  Update messages MAY be sent as are link
   configuration or advertisement messages, or MAY be sent to a site-
   local all-MLE-nodes multicast address (to be assigned by IANA).

   Outgoing messages SHOULD be secured using the procedure specified in
   [AES] and [CCM] using the auxiliary security header as described in
   [IEEE802154].  Key choice is outside the scope of this document.  The
   authenticated data consists of the following three values
   concatenated together:

                          IP source address
                          IP destination address
                          auxiliary security header

   The secured data consists of the messages body following the
   auxiliary security header (the command ID and TLVs).

   A message sent in response to a multicast request, such as a
   multicast Link Request, MUST be delayed by a random time between 0
   and MAX_RESPONSE_DELAY_TIME seconds.

   MAX_RESPONSE_DELAY_TIME  1 second

   If no response is received to a request, the request MAY be
   retransmitted.  Because MLE messages do not require complex
   processing and are not relayed, a simple timeout scheme is used for
   retransmitting.  This is based on the retransmission mechanism used
   in DHCPv6 RFC 3315 [RFC3315], simplified to use a single, fixed
   timeout.

      Parameter       Default   Description
      -------------------------------------------------------
      URT               1 sec   Unicast Retransmission timeout.
      MRT               5 sec   Multicast Retransmission timeout.
      MRC               3       Maximum retransmission count.

   For each transmission the appropriate URT or MRT value is multiplied
   by a random number chosen with a uniform distribution between 0.9 and

Kelsey                  Expires September 8, 2012              [Page 13]
Internet-Draft           Mesh Link Establishment              March 2012

   1.1.  The randomization factor is included to minimize
   synchronization of messages transmitted.

Kelsey                  Expires September 8, 2012              [Page 14]
Internet-Draft           Mesh Link Establishment              March 2012

7.  Processing of incoming messages

   Any incoming link configuration or advertisement message, or an
   incoming update sent to a link-local address, whose IP Hop Limit is
   not 255 may have been forwarded by a router and MUST be discarded.

   Incoming update messages that contain TLVs other than Param TLVs
   SHOULD be ignored.

   Unsecured incoming messages SHOULD be ignored.  Secured incoming
   messages are decrypted and authenticated using the procedures
   specified in [AES] and [CCM], with security material obtained from
   the auxiliary security header as described in [IEEE802154].  The key
   source may be obtained either from the link layer source address or
   from the auxiliary security header.

   A device SHOULD maintain a separate incoming frame/replay counter for
   each neighbor.  Any message received with a frame/replay counter the
   same or lower than that of a previously received and authenticated
   message from the same source MUST be discarded.  Messages for which
   no previous frame/replay counter are available are not discarded and
   the counter value SHOULD be saved for comparison with later messages.

Kelsey                  Expires September 8, 2012              [Page 15]
Internet-Draft           Mesh Link Establishment              March 2012

8.  Application to 802.15.4

   This section describes how MLE could be used in an 802.15.4-based
   LoWPAN.  This section is not normative.  The values that may need to
   be communicated to configure an 802.15.4 include:

   o  Long (64-bit) and short (16-bit) addresses.

   o  Capability data byte, especially the Device Type and Receiver On
      When Idle fields.

   o  Initialization of AES-CCM frame counters (which are also used as
      replay counters).

   A device wishing to establish a link to a neighbor would send a Link
   Request message containing the following:

   o  Source Address TLV, containing the sender's short (16-bit) MAC
      address.  It is assumed that the sender's long (64-bit) MAC
      address is used as the MAC source address of the message.

   o  Mode TLV, containing the sender's Capability data byte.

   o  Timeout TLV, if the sender is an rxOffWhenIdle device.

   o  Challenge TLV, whose size is determined by the network
      configuration.

   If the neighbor has sufficient resources to maintain an additional
   link, it would respond with a Link Accept message containing the same
   TLVs (with its own values), but with a Response TLV in place of the
   Challenge TLV and with an added Replay Counter TLV.  If the neighbor
   also required a liveness check, it would include its own challenge,
   and use the Link Accept And Request message type.

   If a node receives a secured 802.15.4 unicast from a neighbor for
   whom it does not have link configuration data, the receiving node
   should respond with a Link Reject message to inform the neighbor that
   the link is not configured.

   Nodes could also send out periodic advertisements containing the
   incoming and outgoing ETX values for their neighbors.  These would be
   used to choose likely candidates for link establishment and to
   determine if existing links continued to provide sufficient two-way
   reliability.

   Because link configuration and advertisement messages are used to
   establish 802.15.4 security they should not be secured at the

Kelsey                  Expires September 8, 2012              [Page 16]
Internet-Draft           Mesh Link Establishment              March 2012

   802.15.4 layer.

   Update messages may be sent to change the channel, PAN ID, and/or
   permit joining flags on all nodes.  The permit joining flag normally
   defaults to false; to avoid permanently enabling joining, the value
   of permit joining parameter should be the number of seconds for which
   the permit joining flag should be turned on, and not just true or
   false.

Kelsey                  Expires September 8, 2012              [Page 17]
Internet-Draft           Mesh Link Establishment              March 2012

9.  Acknowledgements

   TODO.

Kelsey                  Expires September 8, 2012              [Page 18]
Internet-Draft           Mesh Link Establishment              March 2012

10.  IANA Considerations

   TODO: UDP port and registries for the command, TLV, and Parameter ID
   identifiers.

Kelsey                  Expires September 8, 2012              [Page 19]
Internet-Draft           Mesh Link Establishment              March 2012

11.  Security Considerations

   IN PROGRESS

   Some MLE messages are necessarily sent unsecured.  Implementations
   must take care to use information data from unsecured messages
   appropriately.  In particular, information from unsecured messages
   should not be used to modify any stored information obtained from
   secured messages.

Kelsey                  Expires September 8, 2012              [Page 20]
Internet-Draft           Mesh Link Establishment              March 2012

12.  References

12.1.  Normative References

   [AES]      National Institute of Standards and Technology,
              "Specification for the Advanced Encryption Standard
              (AES)", FIPS 197, November 2001.

   [CCM]      National Institute of Standards and Technology,
              "Recommendation for Block Cipher Modes of Operation: The
              CCM Mode for Authentication and Confidentiality", SP 800-
              38C, May 2004.

   [IEEE802154]
              Institute of Electrical and Electronics Engineers,
              "Wireless Personal Area Networks", IEEE Standard 802.15.4-
              2006, 2006.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

12.2.  Informative References

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

Kelsey                  Expires September 8, 2012              [Page 21]
Internet-Draft           Mesh Link Establishment              March 2012

Author's Address

   Richard Kelsey
   Ember Corporation
   25 Thomson Place
   Boston, Massachusetts  02210
   USA

   Phone: +1 617 951 1225
   Email: richard.kelsey@ember.com

Kelsey                  Expires September 8, 2012              [Page 22]