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 (781) 271-8388 EMail: kgrace@mitre.org Grace [Page 5]