Internet Area WG R.K. Kelsey
Internet-Draft Ember Corporation
Intended status: Standards Track March 07, 2012
Expires: September 06, 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 06, 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 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

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

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.

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

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

5. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type       |    Length     |    Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	    

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.

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

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

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

	    

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

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

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

 IP source address
 IP destination address
 auxiliary security header

	    

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:

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 1.1. The randomization factor is included to minimize synchronization of messages transmitted.

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.

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:

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

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

9. Acknowledgements

TODO.

10. IANA Considerations

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

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.

12. References

12.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[AES] National Institute of Standards and Technology, "Specification for the Advanced Encryption Standard (AES)", FIPS 197, November 2001.
[IEEE802154] Institute of Electrical and Electronics Engineers, "Wireless Personal Area Networks", IEEE Standard 802.15.4-2006, 2006.

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.

Author's Address

Richard Kelsey Ember Corporation 25 Thomson Place Boston, Massachusetts 02210 USA Phone: +1 617 951 1225 EMail: richard.kelsey@ember.com