draft-grace-manet-mmrp-00.txt

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


INTERNET-DRAFT        Mobile Mesh Routing Protocol     22 September 2000


   advertisements. Each entry in the external route advertisement list
   contains an "External Route Address", a "Netmask", and a "Metric".
   Similar to entries in an IP route table, the "External Route Address"
   is logically AND'd with "Netmask" to define a range of IP addresses.
   "Metric" specifies the cost from the node to reach the range of IP
   addresses. External route advertisements enable a node to advertise
   routes into the mobile adhoc cloud for destinations that are
   "outside" of the mobile adhoc cloud. A relay node MUST NOT alter this
   list.

   Each node maintains a database containing the most recent LSP from
   each source. When a node receives an LSP it performs the following
   processing:

   - If the node's router id is the same as the "Router Id" field, it
     discards the message and is done processing.

   - If the "Age" field is 0, it discards the message and is done
     processing.

   - It increments the "Hop Count" field by 1.

   - It computes a delay that will be imposed on the LSP before it
     is relayed as:
                                                     hops
     delay = Max(MIN_TX_DELAY,Min(MAX_TX_DELAY,ALPHA^    ))

     where hops is the number of hops the LSP has traveled from its
     source, MIN_TX_DELAY and MAX_TX_DELAY are the configurable minimum
     and maximum delays, respectively, that will be imposed before
     relaying an LSP, and ALPHA is a configurable parameter which
     controls the rate at which the imposed delay grows as a function of
     the number of hops from the source.

     To avoid possible synchronization of relayed LSP's, jitter is added
     to the computed "delay". The jitter MUST be a random number
     uniformly distributed between 0 and (0.5 * delay). The actual time,
     then, when a node MUST relay the LSP is:

     txTime = currentTime + delay + jitter

   - If the node does not have an LSP in its database from the source,
     the node inserts the LSP into its database and remembers that the
     LSP needs to be relayed at the computed "txTime" and is done
     processing.

   - If the sequence number of the received LSP is greater than the
     sequence number of the stored LSP



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


        OR
     if the sequence number of the received LSP is equal to the sequence
     number of the stored LSP and the hop count of the received LSP is
     less than the hop count of the stored LSP
        THEN
     the received LSP replaces the stored LSP and the node remembers the
     earlier of the "txTime" of the received LSP and the "txTime" of the
     replaced LSP.

   When a stored LSP's "txTime" arrives, the node MUST relay the LSP.

   A node MUST ensure that LSP's are not stored for longer than their
   Age field. Also, when a node relays an LSP, it MUST ensure that the
   Age field has been diminished by the amount of delay imposed by the
   node. One method for achieving these rules is to periodically
   decrement the Age field of all stored LSP's. If an Age field reaches
   zero, the LSP is removed from the database and discarded.

   At a minimum, a node MUST compute least cost routes and update its IP
   routing table once every UPDATE_PERIOD. The node MAY use any suitable
   algorithm such as Djykstra for the computation of least cost routes.

   An implementation MUST provide a mechanism that allows IP interfaces
   to be dynamically added and removed from the router without having to
   restart the router. This feature is important since it enables new IP
   interfaces to be utilized without causing the router to lose its LSP
   database. Also, if the router is a "border" router (ie. has a
   connection to a fixed network that is running the Mobile Mesh Border
   Discovery Protocol ), then any tunnel interfaces that are created by
   MMBDP can be readily added to the router.

   In order to simplify the task of assigning IP addresses, the tunnel
   interfaces created by MMBDP, for a single system, share a common IP
   address.  Since an LSP in MMRP identifies a router's interface solely
   by its IP address, it would be ambiguous for an LSP to list each
   MMBDP created tunnel interface separately. However, since packets
   sent/received on any of the tunnel interfaces are actually
   sent/received on the same fixed network interface, it is reasonable
   to aggregate all the tunnel interfaces and their respective neighbor
   lists into a single interface entry in the LSP. Therefore, an
   implementation of MMRP MUST aggregate local interfaces sharing a
   common address into a single local interface entry in its LSP. The
   neighbor list associated with this entry MUST contain the union of
   the neighbor addresses from the individual tunnel interfaces'
   neighbor lists.






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


3.  Configurable Parameters

   The following are configurable parameters and their valid range of
   values:

    Parameter       Valid Range
     ALPHA          1.0 <= ALPHA <= 2.0
     MIN_TX_DELAY       >= 0 and <= MAX_TX_DELAY
     MAX_TX_DELAY       >= 0 and >= MIN_TX_DELAY
     MAX_AGE            >  0
     UPDATE_PERIOD      >  0

   Note, for ALPHA=1.0, the delay imposed by each node is independent of
   the number of hops; this is equivalent to traditional flooding.

   Due to the widely varying capabilities of wireless devices, MMRP does
   not recommend any default values. 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 discovering
   routes.

   In addition, the UDP port number to which all packets are sent and
   received is configurable.


4.  Security Considerations

   MMRP does not specify any particular security mechanism. 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 7]

INTERNET-DRAFT        Mobile Mesh Routing 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 8]