Internet DRAFT - draft-grace-manet-mmldp
draft-grace-manet-mmldp
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]
