draft-grace-manet-mmldp-00.txt

美国Mitre做的关于无线Mesh网络路由协议的一套软件源码

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
   [phone]
   EMail: [e-mail]











































Grace                                                   [Page 5]