draft-grace-manet-mmbdp-00.txt

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

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


                 Mobile Mesh Border Discovery Protocol
                     draft-grace-manet-mmbdp-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 Border Discovery Protocol (MMBDP) enables a mobile
   adhoc network to utilize a fixed/wired network for dissemination of
   routing information and for forwarding of data. MMBDP 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
   Routing Protocol (MMRP). Together, these protocols provide a
   flexible, extensible mobile adhoc networking capability.


1.  Introduction

   In environments where some nodes in a mobile adhoc network may have a
   connection to a fixed network, the opportunity exists to utilize flow
   that exists outside of the mobile cloud. Leveraging this collateral
   flow has a couple of important benefits. First, it can prevent
   partitions from occurring in the mobile adhoc network, thus improving
   the likelihood that mobile users can communicate. Second, since
   wireless networks are typically bandwidth constrained, it allows
   traffic from the wireless links to be offloaded to the higher
   capacity wired network.

   If two or more nodes in a mobile adhoc network each have a connection



Grace                                                   [Page 1]

INTERNET-DRAFT    Mobile Mesh Border Discovery Protocol22 September 2000


   into a fixed network (let's call these nodes "border" routers), then
   the opportunity exists for mobile nodes to communicate with other
   mobile nodes across the fixed network. This can be accomplished by
   setting up tunnels between the border routers across the fixed
   network. The Mobile Mesh Border Discovery Protocol (MMBDP) is
   intended to run on a wired ( or fixed network ) interface and enables
   a border router to discover other border routers. This information
   can then be used to setup tunnels amongst the border routers. These
   tunnels can then be leveraged by a mobile adhoc routing protocol to
   disseminate topology information as well as to forward packets.

   MMBDP 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 Routing Protocol (MMRP). 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.

   The process of setting up a tunnel with a peer creates a new IP
   interface on a border router; this interface is a point-to-point
   tunnel interface that tunnels all packets sent on it to the peer.
   MMBDP requires that tunneled packets be formatted as specified in RFC
   2784 - Generic Routing Encapsulation.

   After discovering a peer and setting up a tunnel to it, an
   implementation of MMBDP starts the Mobile Mesh Link Discovery
   Protocol on the tunnel interface. MMBDP then adds the tunnel
   interface to the Mobile Mesh Routing Protocol. The tunnel interface
   appears to MMLDP and MMRP to be just another IP interface; the fact
   that it is a tunnel interface is not exposed. MMLDP discovers
   "virtual links" from the tunnel interfaces of other border routers
   and reports them and their associated costs to MMRP. MMRP includes in
   its LSP the IP address of the tunnel interface and its associated
   links and link costs. Thus, MMRP computes least cost paths that can
   include both wireless links and "virtual links".

   By configuring MMLDP to report the cost of the "virtual links" to be
   much less than the cost of a wireless link, routes between wireless
   nodes that traverse the wired/fixed network will be preferred over
   those that don't. Thus, the goal of offloading traffic from the
   bandwidth constrained wireless links to the higher capacity wired
   links is achieved.








Grace                                                   [Page 2]

INTERNET-DRAFT    Mobile Mesh Border Discovery Protocol22 September 2000


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

   Only IP interfaces to fixed networks SHOULD participate in the MMBDP
   protocol; IP interfaces to adhoc networks MUST NOT participate in the
   MMBDP protocol.

   An IP interface participating in the MMBRP protocol MUST periodically
   send a "Border Advertisement" message once every AD_PERIOD seconds.
   The Border Advertisement message is a UDP datagram and MUST be sent
   to a configurable multicast group address. The multicast group
   address SHOULD be the same for all potential border routers. The UDP
   port number is also configurable and SHOULD be the same for all
   potential border routers.  In the future, it may be desirable to
   obtain a well-known multicast group address and/or port number for
   this protocol.

   A Border Advertisment 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=200  |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   When an interface receives a Border Advertisement message from a
   source address (indicated in the IP header) that it has not received
   one from in the previous configurable DEAD_INTERVAL, an
   implementation MUST setup a point-to-point tunnel to the newly
   discovered border router; this results in the creation of a new
   tunnel interface. The tunnel MUST perform encapsulation/decapsulation
   of all packets using Generic Routing Encapsulation as specified in
   [RFC2784]. Using GRE terminology, the source address of the "Delivery
   Header" MUST be the IP address of the local interface participating
   in the MMBDP protocol. The destination address of the "Delivery
   Header" MUST be the source address, as indicated in the IP header, of
   the remote interface that sent the Border Advertisement message. The
   source address assigned to the "Payload packet" header (ie. the
   tunnel interface address ) MAY be a special test address drawn from



Grace                                                   [Page 3]

INTERNET-DRAFT    Mobile Mesh Border Discovery Protocol22 September 2000


   the 192.168.X.X or 10.X.X.X address blocks.

   All tunnel interfaces on a single system that are created by an MMBDP
   implementation MUST share the same tunnel address; these addresses
   MUST be unique across systems. The sharing of a single tunnel
   interface address on a system simplifies the problem of assigning
   unique addresses. For example, in a network with N border routers,
   there are N*(N-1) tunnel interfaces; assigning a unique address to
   each of these interfaces would require additional complexity.

   After discovering a new border router and setting up a tunnel to it,
   an implementation MUST start the Mobile Mesh Link Discovery Protocol
   on the corresponding tunnel interface. After this step, an
   implementation MUST add the tunnel interface to the Mobile Mesh
   Routing Protocol.

   If a Border Advertisement message for a border router which is
   declared to be up is not received within a DEAD_INTERVAL, the
   implementation MUST assume that the border router is no longer
   reachable. The implementation MUST remove the tunnel interface from
   the Mobile Mesh Routing Protocol. Then, an implementation MUST stop
   the Mobile Mesh Link Discovery Protocol on the tunnel interface.
   Finally, the implementation MUST delete the tunnel.


3.  Configurable Parameters

   The following are configurable parameters:
    - AD_PERIOD
    - DEAD_INTERVAL

   These parameters should be set to reasonable positive values and may
   be non-integral. 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 departed
   border routers.

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


4.  Security Considerations

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



Grace                                                   [Page 4]

INTERNET-DRAFT    Mobile Mesh Border Discovery Protocol22 September 2000


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.

   [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., Traina, P.,
             "Generic Routing Encapsulation (GRE)", RFC 2784,
             March 2000.


6.  Author's Address

   Kevin H. Grace
   The MITRE Corporation
   202 Burlington Road
   Bedford, MA  01730
   [phone]
   EMail: [e-mail]
































Grace                                                   [Page 5]