INTERNET-DRAFT                                                  K. GraceIETF MANET Working Group                           The MITRE CorporationExpiration: 22 March 2001                              22 September 2000                  Mobile Mesh Link Discovery Protocol                     draft-grace-manet-mmldp-00.txtStatus 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 anGrace                                                   [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 20006.  Author's Address   Kevin H. Grace   The MITRE Corporation   202 Burlington Road   Bedford, MA  01730   (781) 271-8388   EMail: kgrace@mitre.orgGrace                                                   [Page 5]