draft-grace-manet-mmrp-00.txt

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

INTERNET-DRAFT                                                  K. Grace
IETF MANET Working Group                           The MITRE Corporation
Expiration: 22 March 2001                              22 September 2000


                      Mobile Mesh Routing Protocol
                     draft-grace-manet-mmrp-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 Routing Protocol (MMRP) is a robust, scalable,
   efficient mobile adhoc routing protocol based upon the "link state"
   approach. MMRP is one protocol in a set of related Mobile Mesh
   protocols that also includes the Mobile Mesh Link Discovery Protocol
   (MMLDP) and the Mobile Mesh Border Discovery Protocol (MMBDP).
   Together, these protocols provide a flexible, extensible mobile adhoc
   networking capability.


1.  Introduction

   The Mobile Mesh Routing Protocol (MMRP) is a robust, scalable, and
   efficient mobile adhoc routing protocol based upon the "link state"
   approach. A node periodically broadcasts its own Link State Packet
   (LSP) on each interface participating in the protocol. LSP's are
   relayed by nodes, thus allowing each node to have full topology
   information for the entire adhoc network. From its topology database,
   a node is able to compute least cost unicast routes to all other
   nodes in the mobile adhoc network.

   An LSP indicates for each interface on the router, the addresses of
   neighbor interfaces that have links to it, and the associated cost of



Grace                                                   [Page 1]

INTERNET-DRAFT        Mobile Mesh Routing Protocol     22 September 2000


   these links.  Also in the LSP are a list of "External Route
   Advertisements" which enable the node to advertise routes into the
   mobile adhoc cloud for destinations that are "outside" of the mobile
   adhoc cloud.  One use of this mechanism is to allow routers
   possessing a wired connection to a fixed network to advertise a
   default route. This provides a mechanism for allowing mobile nodes to
   gain external connectivity. Also, this mechanism can be used by a
   wireless router to advertise a route for a collection of hosts which
   are directly connected to it.

   To enhance scalability, MMRP performs a technique known as fish-eye
   routing in which the resolution of a node's map of the network
   decreases as a function of hop distance from the node. This is
   achieved by decreasing the rate at which LSP's propagate across the
   network as they get farther away from their source. This effectively
   decreases the overhead associated with disseminating topology
   information. Also, this allows more recent LSP's to "catch up" and
   overwrite older LSP's as they propagate.

   MMRP is one protocol in a set of related Mobile Mesh protocols that
   also includes the Mobile Mesh Link Discovery Protocol (MMLDP) 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.


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

   A node participating in the MMRP protocol MUST periodically broadcast
   its LSP message once every UPDATE_PERIOD seconds. The LSP 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 nodes that desire participation in the adhoc
   network. In the future, it may be desirable to obtain a well-known
   port number for this protocol.










Grace                                                   [Page 2]

INTERNET-DRAFT        Mobile Mesh Routing Protocol     22 September 2000


   An LSP 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 = 2 |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Router Id                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Sequence Number                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Age               |           Hop Count           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         # Interfaces          |       # External Routes       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Local Interface Address                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           # Neighbors         |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Neighbor Interface Address                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Neighbor Interface Metric                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Neighbor Interface Address                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Neighbor Interface Metric                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                     ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    External Route Address                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Netmask                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Metric                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     ...
   The "Version" field enables future extensions to the protocol message
   and currently MUST be set to 1.

   The "Msg Type" field helps to ensure that non-LSP messages can be
   identified as such and it MUST be set to 2.

   The "Router Id" field is a globally unique number that identifies the



Grace                                                   [Page 3]

INTERNET-DRAFT        Mobile Mesh Routing Protocol     22 September 2000


   source of the LSP; this field MAY be set to one of the source node's
   IP interface addresses. This field MUST remain the same value across
   all LSP's sourced by a node. A relay node MUST NOT alter this field.

   The "Sequence Number" is used to distinguish a more recent LSP from
   an older one; this field MUST be incremented by one each time a node
   sends its own LSP. A relay node MUST NOT alter this field.

   The "Age" field indicates for how many seconds the LSP is valid
   before it MUST be discarded. A source node MUST set this field to the
   configurable parameter MAX_AGE. A relay node MUST decrement this
   field by the number of seconds the LSP has been stored at the relay
   prior to sending. This field takes on integer values representing
   whole seconds.

   The "Hop Count" indicates how many hops from the source the LSP has
   traveled. This field MUST be set to 0 by the source. A relay node
   MUST increment this field by one upon receiving the LSP.

   The "# Interfaces" field indicates how many interfaces on the source
   node are participating in the MMRP protocol. Each of these interfaces
   MUST have its address and associated list of neighbor interface
   addresses included in the LSP. A relay node MUST NOT alter this
   field.

   The "# External Routes" field indicates how many external route
   advertisements from the source node are included in the LSP. A relay
   node MUST NOT alter this field.

   Following the "#External Routes" field is a list of the source node's
   participating local interface addresses and their associated lists of
   neighbors. All addresses are 32 bit IPv4 addresses. All addresses
   listed in the LSP MUST be unique across the entire network. Each list
   of neighbors contains a "# Neighbors" field that MUST be set to the
   number of neighbors contained in the subsequent neighbor list. Each
   entry in the list of neighbors contains a "Neighbor Interface
   Address" and a "Neighbor Interface Metric". The "Neighbor Interface
   Metric" reflects the cost of the link from the neighbor interface to
   the source node's local interface. The link may or may not be
   bidirectional, however, all nodes MUST assume that it is
   unidirectional from the neighbor interface to the source node's local
   interface. MMRP does not specify a policy for how metrics should be
   assigned to links. Rather, it relies on whatever performs link
   discovery to provide a metric associated with each reported link. A
   relay node MUST NOT alter this list.

   Following the list of local interface addresses and their associated
   lists of neighbors, is a list of the source node's external route



Grace                                                   [Page 4]