INTERNET-DRAFT K. Grace IETF MANET Working Group The MITRE Corporation Expiration: 22 March 2001 22 September 2000 Mobile Mesh Link Discovery Protocol draft-grace-manet-mmldp-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. Abstract The Mobile Mesh Link Discovery Protocol (MMLDP) provides a media independent mechanism for discovering neighbors in a mobile adhoc network, and is capable of determining whether links are unidirectional or bidirectional. MMLDP is one protocol in a set of related Mobile Mesh protocols that also includes the Mobile Mesh Routing Protocol (MMRP) and the Mobile Mesh Border Discovery Protocol (MMBDP). Together, these protocols provide a flexible, extensible mobile adhoc networking capability. 1. Introduction The Mobile Mesh Link Discovery Protocol (MMLDP) enables wireless nodes to learn of neighbors on a per IP interface basis. Link discovery in a mobile adhoc network can be accomplished through several alternative mechanisms, however, MMLDP provides a simple straight forward approach and is independent of media type. MMLDP detects when an interface has a new neighbor and when a neighbor is no longer present. These events can then be utilized by other protocols and software running on the node such as those performing mobile adhoc routing. Additionally, MMLDP is able to determine whether a link is bidirectional or uni-directional, thus enabling an Grace [Page 1] INTERNET-DRAFT Mobile Mesh Link Discovery Protocol 22 September 2000 adhoc routing protocol to leverage uni-directional links if desired. MMLDP is one protocol in a set of related Mobile Mesh protocols that also includes the Mobile Mesh Routing Protocol (MMRP) and the Mobile Mesh Border Discovery Protocol (MMBDP). Each of these are described in separate Internet Drafts. An aesthetically pleasing aspect of these protocols is that they each contain only a single message type. This form of simplicity, we believe, will enable others to easily understand and implement the protocols. By keeping the functions of link discovery and adhoc routing separate, we enable flexibility and extensibility. For example, an alternative mechanism for discovering links could be implemented without causing changes to the adhoc routing protocol. Alternatively, the same link discovery mechanism, such as MMLDP, could be utilized by several different adhoc routing protocols. 2. Protocol Description 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]. An IP interface running MMLDP MUST periodically broadcast a Hello message once every HELLO_PERIOD seconds. The Hello message is a UDP datagram and MUST be sent to the limited IP broadcast address 255.255.255.255. The UDP port number is configurable and SHOULD be the same for all adhoc network interfaces. In the future, it may be desirable to obtain a well-known port number for this protocol. A Hello message 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version = 1 | Msg Type = 1 | # Neighbors | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Interface Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Interface Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The "Version" field enables future extensions to the protocol message and currently MUST be set to 1. Grace [Page 2] INTERNET-DRAFT Mobile Mesh Link Discovery Protocol 22 September 2000 The "Msg Type" field helps to ensure that non-Hello messages can be identified as such and it MUST be set to 1. The Hello message also includes a list of neighbor interface addresses from which Hello messages were received on the interface within the last DEAD_INTERVAL seconds. A neighbor interface address is an IPv4 32 bit address. The "# Neighbors" field indicates how many neighbor interface addresses are included in the Hello message. This neighbor interface address list SHOULD be used by recipients to determine whether the link from the sender is bi-directional or uni- directional. If a receiving interface finds its own address included in the neighbor interface address list of a Hello message, this implies there is a bidirectional link between them. Conversely, if the address of the interface that receives a Hello message is not included in the neighbor interface address list, this implies the link is uni-directional from the interface sending the Hello message to the receiving interface. Interfaces SHOULD ignore the reception of their own Hello messages and MUST not include their own address in their own Hello's neighbor address list. An implementation of MMLDP uses some unspecified mechanism to report link events to local clients. Whether an interface reports uni- directional links or only bi-directional links SHOULD be a configurable parameter of an implementation. An implementation of MMLDP MUST assign a metric to each reported link. The link metric can then be used by an adhoc routing protocol to compute least cost paths. MMLDP does not specify what the metric represents nor how it is computed. A few possible choices for the metric include: a constant value, a value based on the data rate of the link, or a value based upon the signal quality of the link. Other choices are possible too and the choice is intentionally left to the implementation. If an interface reports uni-directional links, then whenever it receives a Hello from another node's interface that it does not have a link from, it SHOULD report the new link. An implementation MAY choose to use additional information such as signal strength or stability before deciding to report a new link. If an interface only reports bi-directional links, then it MUST check a neighbor list within the received Hello message for the address of the receiving interface. It MUST report that a link went down if it changes from bi-directional to uni-directional; similarly, it SHOULD report that a link came up if it changes from uni-directional to bi- Grace [Page 3] INTERNET-DRAFT Mobile Mesh Link Discovery Protocol 22 September 2000 directional. If a Hello message for a link which is declared to be up is not received within a DEAD_INTERVAL, the interface MUST report that the link is down. 3. Configurable Parameters The following are configurable parameters: - HELLO_PERIOD - DEAD_INTERVAL These parameters should be set to reasonable positive values and may be non-integer. Factors which may or may not influence these values include the data rates of the links involved, anticipated network size, mobility rates, transmission ranges, desire to minimize overhead, and desire to reduce delay in detecting new or broken links. All interfaces participating on the same media SHOULD have the same values for these configurable parameters. In addition, the UDP port number to which all packets are sent and received is configurable. 4. Security Considerations MMLDP does not specify any particular security mechanism. Since the information learned through link discovery may be utilized by adhoc routing protocols, it is important to ensure that in environments requiring security, adequate mechanisms are employed to authenticate messages. IPSec may provide a reasonable solution for these environments. 5. References [RFC2119] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, March 1997. Grace [Page 4] INTERNET-DRAFT Mobile Mesh Link Discovery Protocol 22 September 2000 6. Author's Address Kevin H. Grace The MITRE Corporation 202 Burlington Road Bedford, MA 01730 (781) 271-8388 EMail: kgrace@mitre.org Grace [Page 5]