autoconf P. Hofmann Internet-Draft DoCoMo Euro-Labs Expires: September 2, 2006 March 1, 2006 Multihop Radio Access Network (MRAN) Protocol Specification draft-hofmann-autoconf-mran-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. 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. This Internet-Draft will expire on September 2, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document presents an IPv6-based protocol for the interconnection of ad hoc networks and the Internet. The protocol enables mobile nodes in ad hoc networks to communicate with correspondent nodes in the Internet. Hofmann Expires September 2, 2006 [Page 1] Internet-Draft MRAN March 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Message and Table Formats . . . . . . . . . . . . . . . . . . 8 3.1. Internet Gateway Advertisement (GW_ADV) . . . . . . . . . 8 3.2. Internet Gateway Solicitation (GW_SOL) . . . . . . . . . . 9 3.3. Solicited Internet Gateway Advertisement (SOL_GW_ADV) . . 9 3.4. Mobile Node Registration (MN_REG) . . . . . . . . . . . . 10 3.5. Mobile Node Registration Acknowledgement (MN_REG_ACK) . . 10 3.6. Gateway Table . . . . . . . . . . . . . . . . . . . . . . 11 3.7. Mobile Node Table . . . . . . . . . . . . . . . . . . . . 11 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Internet Gateway Discovery . . . . . . . . . . . . . . . . 12 4.1.1. Proactive Discovery Mode . . . . . . . . . . . . . . . 12 4.1.2. Reactive Discovery Mode . . . . . . . . . . . . . . . 12 4.1.3. Hybrid Discovery Mode . . . . . . . . . . . . . . . . 13 4.1.4. Gateway Table Maintenance . . . . . . . . . . . . . . 13 4.1.5. Applicability of Gateway Discovery Modes . . . . . . . 13 4.2. Internet Gateway Selection . . . . . . . . . . . . . . . . 14 4.3. Address Autoconfiguration . . . . . . . . . . . . . . . . 14 4.4. Mobile Node Registration . . . . . . . . . . . . . . . . . 14 4.5. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 15 4.6. Multihop Handovers . . . . . . . . . . . . . . . . . . . . 16 5. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 22 Hofmann Expires September 2, 2006 [Page 2] Internet-Draft MRAN March 2006 1. Introduction Connecting mobile ad hoc networks (MANET) with the Internet is useful for several application scenarios. It enables mobile nodes (MN) in ad hoc networks to access services in the Internet or to communicate with correspondent nodes (CN) outside of their ad hoc network. The connection of MANETs and the Internet is provided by an entity that is part of both networks, e.g., a router that has a wireless interface for communication with MNs and a wired interface for connection to a fixed IP-based network. This entity is referred to as Internet gateway (GW). An Internet GW is able to communicate with MNs by running the same MANET routing protocol as the MNs. An example of a MANET with Internet connection is shown in Figure 1. ------ | CN | ------ | | ---------------------- | Internet | ---------------------- | | | | ------ ------ | GW | | GW | ------ ------ | | | | ------ ------ | MN | | MN | ------ ------ | | | | ------ ------ ------ | MN |--| MN |--| MN | ------ ------ ------ Figure 1 The connection of a MN in a MANET with a CN in the Internet comprises three major steps: Internet GW discovery, address autoconfiguration, and packet forwarding. In case a MN discovers more than one GW, it selects the most appropriate one based on certain rules. Next, the MN obtains a topologically correct prefix or address from it's preferred GW for communication with the CN. This is necessary as MANETs usually employ a flat addressing scheme that allows MNs to use any arbitrary address for communication with other MNs. Finally, the Hofmann Expires September 2, 2006 [Page 3] Internet-Draft MRAN March 2006 communication can start and packets are forwarded from the MN through the MANET via the GW to the CN and vice versa. The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.1. Requirements The MANET routing protocol and the Internet connection protocol should be able to operate independently. On the one hand, the Internet connection protocol should be able to run on top of any routing protocol. This allows to use the Internet connection protocol in application scenarios with different MANET routing protocols. On the other hand, the operation of the Internet connection protocol should not affect the MANET routing protocol. For instance, a change of a MN's global address should not necessitate an update of routes in the ad hoc network, resulting in high routing overhead. This is of particular importance if nodes are highly mobile and change their Internet GW frequently. The connection of MANET and Internet via multiple GWs should be supported. MNs should be able to detect if multiple GWs are available. If this is the case, MNs should be able to select the most appropriate GW. Furthermore, MNs should be able to maintain a connection with a particular GW, i.e., packets sent by this MN should not be forwarded to a different GW. This can be important for authentication, authorization, and accounting (AAA) reasons or if selected GWs provide certain services or quality thereof. The Internet connection protocol should provide different GW discovery modes to enable an adaptation to different application scenarios (i.e., number of MNs and GWs, mobility pattern, MANET routing protocol type) to limit signaling overhead. The connection between a MN and the Internet should be maintained while the MN is moving. If the connection between the MN and its current GW is lost (e.g., due to a route failure) the Internet connection protocol should initiate the reestablishment of the connection with the Internet via an alternative GW ("multihop handover"). Again, this is important if nodes are highly mobile. Finally, the Internet connection protocol should support partitioning and merging of MANETs. Based on these requirements we propose the Multihop Radio Access Network (MRAN) protocol. Hofmann Expires September 2, 2006 [Page 4] Internet-Draft MRAN March 2006 1.2. Assumptions MNs and GWs use local addresses for communication within the MANET. The local address may be autoconfigured as described in, e.g., [I-D.jeong-adhoc-ip-addr-autoconf]. Routing is performed by a MANET routing protocol, e.g., [I-D.clausen- manet-olsrv2] or [I-D.ietf-manet-dymo]. A flooding protocol (e.g., [I-D.perkins-manet-bcast]) is used for broadcasting certain MRAN control messages. Alternatively, the flooding funtionality may be provided by the MANET routing protocol. 1.3. Terminology Internet gateway An Internet gateway (GW) connects a MANET with the Internet. Therefore, GWs must be able to communicate with nodes of the MANET and with nodes in the Internet. Mobile node All other nodes of the MANET are mobile nodes (MN). Correspondent node A node in the Internet that communicates with a MN in the MANET is a correspondent node (CN). Local address MNs and GWs use local addresses to communicate within the MANET. Global address MNs use a global address to communicate with their CN. Hofmann Expires September 2, 2006 [Page 5] Internet-Draft MRAN March 2006 2. Overview The operation of the MRAN protocol is composed of several functions: Internet GW discovery, GW selection, address autoconfiguration, registration, packet forwarding, and multihop handovers. The MRAN protocol provides three different modes of Internet GW discovery. This ensures that the protocol can be efficiently used in various different application scenarios. In proactive mode, all GWs periodically broadcast advertisement messages. MNs in proactive mode that require Internet access have to wait until they receive such a message. In reactive discovery mode, MNs only attempt to discover available GWs if required (e.g., if a DNS request is supposed to be sent to the Internet). If a MN requires access to the Internet and has no information about available GWs, it broadcasts a GW solicitation message. If a GW receives such a message from a MN, it returns a solicited GW advertisement message per unicast. Finally, hybrid Internet GW discovery is a combination of proactive and reactive discovery. The GW is in proactive mode and the MN is in reactive mode. All GW advertisement messages contain the GW's globally valid prefix of length 64 bit. If a MN wants to connect to the Internet and has information about multiple GWs, it selects the closest GW with respect to number of hops. However, other or additional metrics may be used for the GW selection as well. If a MN has selected a GW, it uses the selected GW's prefix and its own EUI-64 to autoconfigure a global address. It may subsequently perform a duplicate address detection (DAD). A registration of MNs with GWs is required to enable GWs to appropriately forward packets from the Internet to the MNs. If a MN has created a global address, it registers with the selected GW. Therefore, it sends a registration request message to the GW. When receiving such a message, a GW returns a registration acknowledgment message to the MN. If the MN receives this message, the registration was successful and the MN repeats the registration periodically. MNs in reactive GW discovery mode queue payload packets during the GW discovery and registration process. The registration may be used for other purposes as well, e.g., AAA. Payload packets are tunneled between MNs and GWs in both directions. On the one hand, using tunnels for sending packets from the MNs to the GWs enables MNs to explicitly select their preferred GW. On the other hand, using tunnels for sending packets from GWs to MNs allows using only local addresses instead of global addresses for intra- MANET communication. This approach "decouples" the operation of Hofmann Expires September 2, 2006 [Page 6] Internet-Draft MRAN March 2006 MANET routing and MRAN protocol as no rerouting needs to be performed if any MN changes its global address after having connected to a new GW. This helps limiting the routing overhead particularly in highly mobile networks. If a MN is disconnected from its current GW (e.g., because the route to the GW has failed) while communicating with a CN in the Internet, it has to discover, select, and register with another GW. This is a "forced" multihop handover. However, a MN may also select a new GW for optimization reasons, e.g., if it knows another GW that is closer than the current one. The MN then performs the registration with the new GW while it is still connected to the old one. This is an "optimizing" multihop handover. Optimizing handovers are much faster than forced handovers. Furthermore, optimizing handovers increase the reliability of the route between MN and GW. This reduces the frequency of forced handovers. Hence, optimizing handovers increase the system performance, particularly by reducing the packet loss. Hofmann Expires September 2, 2006 [Page 7] Internet-Draft MRAN March 2006 3. Message and Table Formats This Section defines the format of the MRAN control messages and the tables required for the protocol operation. 3.1. Internet Gateway Advertisement (GW_ADV) All GWs in proactive mode periodically broadcast this message. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message type | Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | GW's local address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message type: 1 Reserved: Filled with zeros, ignored by receiver Lifetime: The lifetime of this advertisement Sequence number: Initialized to zero for the first and increased by one for each new advertisement by the GW Prefix: Advertised prefix of GW with length 64 bit Hofmann Expires September 2, 2006 [Page 8] Internet-Draft MRAN March 2006 3.2. Internet Gateway Solicitation (GW_SOL) MNs in reactive mode broadcast this message to discover available GWs. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | MN's local address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message type: 2 Reserved: Filled with zeros, ignored by receiver Sequence number: Initialized to zero for the first and increased by one for each new solicitation by the MN 3.3. Solicited Internet Gateway Advertisement (SOL_GW_ADV) GWs return this message on reception of a MN's GW_SOL message. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message type: 3 Reserved: Filled with zeros, ignored by receiver Prefix: Advertised prefix of GW with length 64 bit Hofmann Expires September 2, 2006 [Page 9] Internet-Draft MRAN March 2006 3.4. Mobile Node Registration (MN_REG) MNs send this message to register with their selected GW. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message type | Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | MN's global address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message type: 4 Reserved: Filled with zeros, ignored by receiver Lifetime: The time in seconds for how long the mobile node wants to register with the Internet GW 3.5. Mobile Node Registration Acknowledgement (MN_REG_ACK) GWs return this message to the MN if the registration was successful. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message type | Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message type: 5 Reserved: Filled with zeros, ignored by receiver Lifetime: The time in seconds specifying for how long the registration is valid Hofmann Expires September 2, 2006 [Page 10] Internet-Draft MRAN March 2006 3.6. Gateway Table MNs maintain a gateway (GW) table to store information about available GWs. An entry of the GW table contains the following information. +------------------------------+ | GW's local address | +------------------------------+ | GW's prefix | +------------------------------+ | GW expiration time | +------------------------------+ | Registration expiration time | +------------------------------+ MNs also need to keep track of their current status, i.e., whether they are connected (i.e., registered) to any GW and, if so, to which GW they are connected. 3.7. Mobile Node Table GWs maintain a mobile node (MN) table to store information about MNs that have a valid registration. An entry of the MN table contains the following information. +------------------------------+ | MN's local address | +------------------------------+ | MN's global address | +------------------------------+ | Registration expiration time | +------------------------------+ Hofmann Expires September 2, 2006 [Page 11] Internet-Draft MRAN March 2006 4. Protocol Operation The operation of the MRAN protocol is composed of several functions: Internet GW discovery, GW selection, address autoconfiguration, registration, packet forwarding, and multihop handovers. The details of the protocol operation are described in the following. 4.1. Internet Gateway Discovery The MRAN protocol provides three different modes of Internet GW discovery. 4.1.1. Proactive Discovery Mode In proactive mode, all GWs MUST periodically broadcast advertisement (GW_ADV) messages advertising their service in a certain time interval (GW_ADV_INTERVAL). The hop limit of the messages SHOULD be set to NET_DIAMETER. MNs that require Internet access have to wait until they receive a GW_ADV message. 4.1.2. Reactive Discovery Mode In reactive discovery mode, MNs only attempt to discover available GWs if required (e.g., if a DNS request is supposed to be sent to the Internet). If a MN requires access to the Internet and has no information about available GWs, it MUST broadcast a GW solicitation (GW_SOL) message. The hop limit of this messages SHOULD be set to NET_DIAMETER. If the MN does not receive a SOL_GW_ADV message within a certain time period (GW_SOL_TIMEOUT), it SHOULD resend a limited number (GW_SOL_RETRIES) of GW_SOL messages until it receives a SOL_GW_ADV message. The timeout for the second solicitation message is 2 x GW_SOL_TIMEOUT, for the third 3 x GW_SOL_TIMEOUT, etc. This backoff algorithm reduces the flooding overhead in the MANET. The MN MAY additionally employ the expanding ring search technique (as described in [RFC3561]) to further reduce the flooding overhead. If the MN does not receive any SOL_GW_ADV message, the GW discovery has failed. GWs in reactive mode MUST NOT send any packets unless they receive a GW_SOL message. If a GW receives a GW_SOL message from a MN, it MUST return a solicited GW advertisement (SOL_GW_ADV) message per unicast, using the MN's local address. The hop limit of this message SHOULD be set to NET_DIAMETER. Payload packets that are supposed to be sent to the CN in the Internet SHOULD be queued during the reactive GW discovery for a maximum duration of PKT_QUEUE_LIFETIME to limit packet loss. Hofmann Expires September 2, 2006 [Page 12] Internet-Draft MRAN March 2006 4.1.3. Hybrid Discovery Mode Hybrid Internet GW discovery is a combination of proactive and reactive discovery. The GW is in proactive mode and the MN is in reactive mode. Hence, the MN only initiates the GW discovery if it requires Internet access and has not received any GW_ADV messages recently. To reduce the signaling overhead in hybrid GW discovery mode, either the hop limit of GW_ADV messages SHOULD be set to a value lower than NET_DIAMETER or the interval of GW_ADV messages SHOULD be set to a value higher than GW_ADV_INTERVAL, or both. 4.1.4. Gateway Table Maintenance MNs MUST maintain a table listing all valid GWs. A table entry is created when a MN receives a GW_ADV or SOL_GW_ADV message. An entry contains the GW's local address, prefix, the GW expiration time, and the registration expiration time (registration is described in Section 4.4). The GW expiration time is the reception time of the last GW_ADV message plus the advertised GW_ADV_LIFETIME. It is updated each time a new advertisement from the same GW is received. Entries created on reception of a SOL_GW_ADV message do not expire, hence the GW expiration time is set to infinity (represented by an integer of maximum value). A GW table entry MUST be removed if it has expired or if the registration with the respective GW has failed. If a MN is currently connected to a GW and the route between MN and this GW fails, the respective GW table entry SHOULD be removed. If a MN is currently connected to a GW and the registration with this GW expires, the respective GW table entry MAY be removed. If a MN is in reactive GW discovery mode and currently connected to a GW, it SHOULD remove all entries in the GW table with GW expiration time set to infinity except the entry of the current GW. This ensures removing stale information. 4.1.5. Applicability of Gateway Discovery Modes The preferred GW discovery mechanism should be carefully selected depending on the actual application scenario. The first important aspect is that the GW discovery mode should be consistent with the MANET routing protocol type, i.e., proactive GW discovery should be used together with a proactive routing protocol [I-D.clausen-manet- olsrv2] and reactive GW discovery together with a reactive MANET routing protocol [I-D.ietf-manet-dymo]. Hofmann Expires September 2, 2006 [Page 13] Internet-Draft MRAN March 2006 Another important aspect is the control overhead generated by the MRAN protocol. It is well known that flooding of messages generates the largest amount of control overhead, while overhead caused by unicast control messages is negligible. MRAN control messages are flooded by either GWs in proactive mode or MNs in reactive mode that need to discover a GW. The suitability of the different GW discovery modes hence depends on the ratio of GWs to MNs that require Internet access, and on the node mobility. For instance, if a large and highly mobile MANET is connected to a few GWs, the proactive GW discovery is advantageous. The hybrid GW discovery mode might be a good tradeoff for large networks or for networks whose characteristics are not known a priori. The last aspect is the targeted user application. Real-time applications can hardly cope with high packet delay or jitter. Hence, it does not make sense to employ reactive GW discovery with packet queuing in this case. 4.2. Internet Gateway Selection If a MN needs to connect to the Internet and has information about multiple GWs in its GW table, it SHOULD select the closest GW with respect to number of hops. However, other or additional metrics may be used for the GW selection as well. If a MN in proactive GW discovery needs Internet connection and does not have any GW table entry, it MUST select the first GW it receives a GW_SOL message from. If a MN in reactive GW discovery mode needs an Internet connection and does not have information about available GWs, it MUST originate a GW_SOL message. The MN SHOULD select the first GW it receives a SOL_GW_ADV from, but it MAY wait a short time (GW_SELECT_DEFER) before selecting a GW to consider the case that a SOL_GW_ADV from a better suited GW is received later. 4.3. Address Autoconfiguration If a MN has selected a GW, it MUST use the selected GW's prefix and its own EUI-64 [RFC3513] to autoconfigure a global address. It MAY subsequently perform a duplicate address detection (DAD). 4.4. Mobile Node Registration A registration of MNs with GWs is required to enable GWs to appropriately forward packets from the Internet to the MNs (see Section 4.5). It may however be used for other purposes as well, e.g., authentication, authorization, and accounting (AAA). Hofmann Expires September 2, 2006 [Page 14] Internet-Draft MRAN March 2006 If a MN has created a global address, it registers with the selected GW. Therefore, it sends a registration request (MN_REG) message to the GW, containing the MN's global address and a lifetime field specifying for how long the MN wants to register with the GW. The lifetime SHOULD be set to MN_REG_LIFETIME. If the MN does not receive an acknowledgment within a certain time (MN_REG_TIMEOUT), it SHOULD resend a limited number (MN_REG_RETRIES) of registration request messages until it receives a MN_REG_ACK message. If the MN does not receive any MN_REG_ACK message after MN_REG_DURATION, the registration has failed and the MN MUST remove the respective GW table entry. It SHOULD subsequently select a new GW or perform GW discovery if required. When receiving a MN_REG message, a GW MUST return a registration acknowledgment (MN_REG_ACK) message to the MN including the granted lifetime of the registration. The granted lifetime SHOULD be the lifetime requested by the MN. GWs MUST maintain a table listing all MNs that currently have a valid registration. An entry of the MN table is created on reception of a MN_REG message and contains the respective MN's local address, global address, and the registration expiration time. The registration expiration time is the reception time of the last MN_REG message plus the granted lifetime of the registration. An entry is updated each time a MN_REG message from the same MN is received. A MN table entry MUST be removed by GWs if the registration of the respective MN has expired. If the MN eventually receives the MN_REG_ACK message, the registration was successful and the MN SHOULD repeat the registration periodically with an interval of MN_REG_INTERVAL. The periodical registration with the current GW MUST be stopped if either the MN selects a new GW or the GW table entry of the respective GW has been removed. If the MN is in reactive GW discovery mode, it SHOULD queue payload packets during the registration process. If the MN is in proactive GW discovery mode, it SHOULD always maintain a registration with a GW even if Internet connection currently is not required. This avoids unnecessary delays in case a payload packet needs to be sent to a CN in the Internet. 4.5. Packet Forwarding Payload packets are tunneled between MNs and GWs in both directions, achieved by either IP-in-IP encapsulation [RFC2473] or using a routing extension header [RFC2460]. On the one hand, using tunnels Hofmann Expires September 2, 2006 [Page 15] Internet-Draft MRAN March 2006 for sending packets from the MNs to the GWs enables MNs to explicitly select their preferred GW, e.g., a GW that provides a certain service quality. On the other hand, using tunnels for sending packets from GWs to MNs allows using only local addresses instead of global addresses for intra-MANET communication. This approach "decouples" the operation of MANET routing and MRAN protocol as no rerouting needs to be performed if any MN changes its global address after having connected to a new GW. This helps limiting the routing overhead particularly in highly mobile networks. GWs must maintain tunnels to each MN with a valid registration. The destination address of the inner IP header is the global address of the MN. The destination address of the outer header is the local address of the MN. A GW MUST establish a tunnel to a MN after reception of a MN_REG message and MUST remove it when the respective MN table entry has expired. Simultaneously, MNs must maintain a tunnel to their current GW. The destination address of the inner IP header is the global address of the CN, whereas the destination address of the outer header is the local address of the GW. A MN MUST establish a tunnel to a GW after reception of a MN_REG_ACK message. If the MN is in reactive GW discovery mode and has any payload packets in its queue, it MUST subsequently forward them to the Internet. The tunnel MUST be removed if either a new GW is selected or the respective GW table entry has been removed. 4.6. Multihop Handovers If a MN is disconnected from its current GW (i.e., the GW table entry or registration has expired or route to GW has failed) while communicating with a CN in the Internet, it SHOULD discover, select and register with another GW. This is a "forced" multihop handover. The delay of the forced handover is mainly composed of the delays of GW discovery (if necessary) and registration process. However, a MN MAY also decide to select a new GW for optimization reasons, e.g., if it knows another GW that is closer than the current one. The MN SHOULD then perform the registration with the new GW while it is still connected to the old one. This is an "optimizing" multihop handover. The delay of optimizing handovers is composed of the delay of changing the global address and the tunnel only. Thus, optimizing handovers are much faster than forced handovers. Furthermore, optimizing handovers increase the reliability of the route between MN and GW. This reduces the frequency of forced handovers. Hence, optimizing handovers increase the system performance, particularly by reducing the packet loss [HBP06]. However, optimizing handovers are only possible with proactive (or Hofmann Expires September 2, 2006 [Page 16] Internet-Draft MRAN March 2006 hybrid) GW discovery. MNs SHOULD stay connected to their current GW for a minimum duration (OPT_HO_DEFER) before performing an optimizing handover to another GW. This reduces the impact of handovers on IP mobility protocols (e.g., Mobile IPv6 [RFC3775]) that might run on top. Hofmann Expires September 2, 2006 [Page 17] Internet-Draft MRAN March 2006 5. Protocol Parameters The recommended values for the protocol parameters are listed below. Parameter Value --------- ----- NET_DIAMETER 35 NODE_TRAVERSAL_TIME 40 ms NET_TRAVERSAL_TIME 3 * NODE_TRAVERSAL_TIME * NET_DIAMETER / 2 GW_ADV_LIFETIME 3,000 ms GW_ADV_INTERVAL GW_ADV_LIFETIME * 0.9 GW_SOL_TIMEOUT 2 * NET_TRAVERSAL_TIME GW_SOL_RETRIES 2 GW_SOL_DURATION (GW_SOL_RETRIES + 1) * (GW_SOL_RETRIES + 2) * GW_SOL_TIMEOUT / 2 GW_SELECT_DEFER NODE_TRAVERSAL_TIME * NET_DIAMETER MN_REG_LIFETIME 30,000 ms MN_REG_TIMEOUT 2 * NET_TRAVERSAL_TIME MN_REG_RETRIES 5 MN_REG_DURATION (MN_REG_RETRIES + 1) * MN_REG_TIMEOUT PKT_QUEUE_LIFETIME GW_SOL_DURATION + MN_REG_DURATION OPT_HO_DEFER 10,000 ms The parameter NET_DIAMETER MAY be adapted to the actual network size. Hofmann Expires September 2, 2006 [Page 18] Internet-Draft MRAN March 2006 6. Security Considerations Possible security threats imposed by the proposed protocol are not addressed. 7. IANA Considerations There are no IANA considerations. 8. Acknowledgments The author would like to thank Christian Prehofer and Christian Bettstetter for their valuable comments on the design and evaluation of the MRAN protocol and for the support in composing this document. Hofmann Expires September 2, 2006 [Page 19] Internet-Draft MRAN March 2006 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. 9.2. Informative References [HBP06] Hofmann, P., Bettstetter, C., and C. Prehofer, "Performance Impact of Multihop Handovers in an IP-based Multihop Radio Access Network", accepted for ACM SIGMOBILE Mobile Computing and Communications Review (MC2R) 2006. [I-D.clausen-manet-olsrv2] Clausen, T., "The Optimized Link-State Routing Protocol version 2", draft-clausen-manet-olsrv2-01 (work in progress), September 2005. [I-D.ietf-manet-dymo] Chakeres, I., "Dynamic MANET On-demand (DYMO) Routing", draft-ietf-manet-dymo-03 (work in progress), October 2005. [I-D.jeong-adhoc-ip-addr-autoconf] Jeong, J., "Ad Hoc IP Address Autoconfiguration", draft-jeong-adhoc-ip-addr-autoconf-06 (work in progress), January 2006. [I-D.perkins-manet-bcast] Perkins, C., "IP Flooding in Ad hoc Mobile Networks", draft-perkins-manet-bcast-02 (work in progress), June 2005. [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- Demand Distance Vector (AODV) Routing", RFC 3561, July 2003. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Hofmann Expires September 2, 2006 [Page 20] Internet-Draft MRAN March 2006 Author's Address Philipp Hofmann DoCoMo Communications Laboratories Europe GmbH Landsberger Str. 312 Munich 80687 Germany Phone: +49-89-56824-218 Email: hofmann@docomolab-euro.com URI: www.docomoeurolabs.de Hofmann Expires September 2, 2006 [Page 21] Internet-Draft MRAN March 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Hofmann Expires September 2, 2006 [Page 22]