MANET Autoconfiguration (AUTOCONF) K. Mase Internet-Draft Y. Owada Expires: November 19, 2006 Niigata University May 18, 2006 Gateway Aggregation Protocol (GAP) for Mobile Ad Hoc Networks draft-mase-autoconf-gap-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. 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 November 19, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract We consider Internet connectivity of a mobile ad hoc network (MANET), where two or more fixed or mobile nodes (MNs) may have a wired or wireless interface to the fixed Internet in addition to the wireless interface for the MANET. The points of attachment of MNs to the Internet are termed as "Access Routers (ARs)," A stationary MN, that has wired connection with the Internet may become an AR itself. Typically, only a single AR is used as the Internet Gateway (IGW). In rare occasions, two or more IGWs may be used, but the number of Mase & Owada Expires November 19, 2006 [Page 1] Internet-Draft GAP May 2006 the IGWs is kept minimized. This feature is called "Gateway Aggregation." MANET routing protocol runs on the ARs and IGWs and routing control messages and data packets of the MANET are tunneled between an MN and its associated AR, between an AR and its selected IGW and between an IGW and its peer IGW. The IGW advertises the network prefix for the MNs to configure their global care-of- addresses. A MN configures its care-of-address with prefix advertised by one of the IGWs. Once it obtains its global address, it does not have to change it during its stay in the MANET. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Message and Table Formats . . . . . . . . . . . . . . . . . . 9 4.1. Internet Gateway Advertisement (IGW_ADV) . . . . . . . . . 9 4.2. MN/AR/IGW Registration (MN_REG/AR_REG/IGW_REG) . . . . . . 11 4.3. MN/AR/IGW Registration Acknowledgement (MN_REG_ACK/AR_REG_ACK/IGW_REG_ACK) . . . . . . . . . . . 11 4.4. AR-IGW Table . . . . . . . . . . . . . . . . . . . . . . . 12 4.5. MN-IGW Table . . . . . . . . . . . . . . . . . . . . . . . 13 4.6. AR Table . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.7. Peer IGW Table . . . . . . . . . . . . . . . . . . . . . . 14 4.8. MN table . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 16 5.1. IGW Advertisement . . . . . . . . . . . . . . . . . . . . 16 5.2. MN registration . . . . . . . . . . . . . . . . . . . . . 16 5.3. MN Table Maintenance . . . . . . . . . . . . . . . . . . . 16 5.4. IGW discovery and selection . . . . . . . . . . . . . . . 17 5.5. AR-IGW Table Maintenance . . . . . . . . . . . . . . . . . 17 5.6. AR registration . . . . . . . . . . . . . . . . . . . . . 17 5.7. AR Table Maintenance . . . . . . . . . . . . . . . . . . . 18 5.8. IGW registration . . . . . . . . . . . . . . . . . . . . . 18 5.9. Peer IGW Table Maintenance . . . . . . . . . . . . . . . . 18 5.10. Tunneling between an MN and its associated AR, between an AR, and an IGW and between IGWs . . . . . . . . 19 5.11. MN-IGW Table Maintenance . . . . . . . . . . . . . . . . . 19 5.12. Address Autoconfiguration . . . . . . . . . . . . . . . . 19 5.13. Packet forwarding . . . . . . . . . . . . . . . . . . . . 19 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . . . 27 Mase & Owada Expires November 19, 2006 [Page 2] Internet-Draft GAP May 2006 1. Introduction Mobile ad hoc networks (MANETs) may have temporary or continuous Internet connectivity so that the mobile nodes (MNs) can exchange data packets with the nodes in the Internet (Internet nodes). In the simplest case, a single MN also has the wired or wireless interface to the Internet and works as the Internet Gateway (IGW). It thus advertises the network prefix for the MNs to configure their care-of- addresses. In more complex cases, multiple nodes in the MANET may have an interface to the Internet and work as the IGW. In this case, each IGW advertises its network prefix to the MNs and an MN needs to select its IGW, when receiving gateway information from two or more IGWs [2], [3]. Typically, a node should select the closest IGW in terms of the number of hops for communication efficiency. It is, therefore, desirable for the node to re-select a different IGW, when the current IGW is not appropriate as the result of roaming. The node, then, needs to configure its new care-of-address based on the network prefix advertised by the new IGW. However, firstly it is not convenient for the node to change its IP address frequently for the purpose of maintaining its communication sessions. Secondly, it takes some time for the MANET to reconstruct routes in which this nodes is directly (as the source or destination) or indirectly (as the relay nodes) involved. With regard to the first issue, no previously proposed methods can completely avoid the possibility of address change. With regard to the second issue, two approaches have been recently proposed. In the first approach, each node configures multiple care-of-addresses based on the received prefixes and advertises all of them throughout the MANET so that the routing protocol maintains all routes to the multiple addresses [4]. When a node changes its address to one of the advertised addresses, all other nodes already have maintained the route to this address. In the second approach, data packets are tunneled between the MNs and the selected GWs in both directions. MANET-local address is used for forwarding packets within the MANET [5]. As the result, no route reconstruction needs to be performed when any MANET node changes its global address. In this document, we propose a novel method, called "Gateway Aggregation Protocol (GAP)" to realize the Internet connectivity of a MANET, where the number of IGWs are kept minimized and the nodes in the MANET do not have to change their care-of-IP addresses regardless of roaming, solving the two issues mentioned above simultaneously. Note that registration mechanisms and the related descriptions given in this document are mostly inspired by [5]. The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Mase & Owada Expires November 19, 2006 [Page 3] Internet-Draft GAP May 2006 document are to be interpreted as described in [1]. Mase & Owada Expires November 19, 2006 [Page 4] Internet-Draft GAP May 2006 2. Terminology MANET Mobile ad hoc network MN A node located inside a MANET. Internet node A node located within the Internet (outside MANET). Internet gateway (IGW) A router which provides Internet connectivity for MNs. This router is located within the Internet. Access router (AR) The point of attachment of an MN to the Internet. MANET-local address A unique-local address having scope that is limited to the MANET. Global address A node's IP address in the Internet, typically resolvable from a DNS name. The address identifies the mobile node, and is used for communication to the Internet. It can also be used for communication within the MANET. IGW information The gateway's IP routing prefix, prefix length, and lifetime. IGW advertisement A message to disseminate IGW information to a MANET. Mase & Owada Expires November 19, 2006 [Page 5] Internet-Draft GAP May 2006 3. Overview We consider a MANET that MAY have one or more MNs, that have a wired or wireless interface to the fixed Internet in addition to the wireless interface to the MNs. The points of attachment of MNs to the Internet are termed as "Access Routers (ARs)," A stationary MN, that has wired connection with the Internet MAY become an AR itself. In the conventional methods, any MN is qualified to be an Internet gateway (IGW). On the other hand, in this document, only a part of ARs MAY work as the IGWs. Specifically, an AR MAY work as the IGW for outbound (from the MANET to the Internet) traffic but MUST not work as the IGW for inbound (from the Internet to the MANET) traffic, except when it has been selected as the IGW. When An AR itself communicates as the source or destination with the Internet nodes, it SHOULD directly send and receive packets to and from the Internet nodes without depending on the IGW, since they are directly attached to the Internet. Typically, a single IGW is used for a MANET, even if multiple ARs exist. This feature is called "Gateway Aggregation." In rare occasions, two or more IGWs MAY be used, but the number of the IGWs SHOULD be kept minimized. It is assumed that each MN has configured a MANET-local address. A MN needs a globally routable address (care-of-address) with prefix advertised by one of the IGWs so that it can receive data packets from an Internet node. To this aim, messages such as IGW advertisement can be used. Unlike the conventional methods, MANET routing protocol runs not only on MNs but on ARs /IGWs as well and routing control messages and data packets within the MANET are tunneled between MNs and ARs/IGWs in both directions, that can be achieved by IP-in -IP encapsulation [6]. IGWs advertise their prefixes and ARs in turn forward them to the MNs. Upon receiving the prefix from an IGW, an MN configures its care-of-address and can receive packets from an Internet node through the IGW. In the proposed method, multiple ARs connected to the same MANET SHOULD select the same IGW in the distributed-fashion. When an AR starts to work, it first monitors whether there are existing IGWs serving the MANET based on the IGW information it receives through the MANET. If it is the case, it selects one of the existing IGWs and establishes a tunnel with the selected IGW through the Internet. Otherwise, it becomes the IGW itself. In this architecture, MNs, that are attached to the Internet, are not directly used as the IGWs unlike the conventional Internet access architecture of the MANET and, therefore, a communication path between a MN and an Internet node may be longer since it has to pass through the selected IGW. However, it is natural that MNs exist in a geographically limited area and this path overhead can be negligible. Mase & Owada Expires November 19, 2006 [Page 6] Internet-Draft GAP May 2006 It is possible that two or more ARs in the same MANET simultaneously start IGW selection. In this case, each AR may select itself as IGW. As the results, a single MANET has multiple IGWs. It is also possible that two independent MANETs, each of which has a different IGW, merges to form a single connected MANET. In either case, the mutiple IGWs can be aware of each other by receiving each other's IGW advertisements through the MANET. In this case, they establish a tunnel to each other so that they are neighbors of each other in the MANET. Each IGW has its own prefix and distributes its IGW advertisements within the MANET. An MN may configure its care-of- address using the prefix advertised by one of the IGWs. It then can continue to use this care-of-address throughout the MANET and no address change is required. There are notable differences between the conventional methods [2]-[5] and the GAP. First, in conventional methods, an MN with attachment to the Internet is simultaneously an IGW. On the other hand, in GAP, IGW is selected from ARs and the number of the IGWs is kept minimized. In the ideal case, only a single IGW is used to disseminate its own prefix. Second, in conventional method, an MN may change its global address for communication efficiency under multiple IGWs environment and special care must be taken to suppress route reconstruction [4], [5], giving rise to overhead within the MANET. On the other hand, in the GAP, an MN does not have to change its global address, once assigned, even if multiple IGWs exist and AR selection is automatically performed by making best use of the MANET routing protocol. As the result, no route reconstruction occurs. This benefit is brought at the cost of overhead within the Internet (possible detours and tunneling). This shift of the overhead for suppressing route reconstruction from within MANET to within the Internet is beneficial since bandwidth resource in the MANET is more expensive than that in the Internet. A procedure of global address configuration of a node is presented in Fig. 1. Mase & Owada Expires November 19, 2006 [Page 7] Internet-Draft GAP May 2006 +----------+ +----+ | Attached | +----+ +-----+ +-----+ | MN | | MN | | AP | | IGW | | IGW | +----+ +----------+ +----+ +-----+ +-----+ | Configure a| | | IGW_REG | Configure a| global | | |<--------->| NANET local| address | | |IGW_REG_ACK| address | | MN_REG | |<--------->| | +----------->| | | | | MN_REG_ACK | | | | |<-----------+ | | | | | IGW_ADV | | | | |<-----------+ IGW_ADV | | | |<-----------+<----------+ | | | AR_REG | | | | +----------->| | | | | AR_REG_ACK | | | | |<-----------+ | | IGW_ADV | | | | |<------------+<------------------------+ | Configure a| | | | | global | | | | | address | | | | | | | | | | Figure 1: A procedure of global address configuration of a node. Mase & Owada Expires November 19, 2006 [Page 8] Internet-Draft GAP May 2006 4. Message and Table Formats This section defines the format of the GAP control messages and the tables required for the protocol operation. 4.1. Internet Gateway Advertisement (IGW_ADV) All IGWs periodically broadcast this message. Mase & Owada Expires November 19, 2006 [Page 9] Internet-Draft GAP May 2006 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 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IGW's global 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 IGW Prefix: Advertised prefix of IGW with length 64 bit Mase & Owada Expires November 19, 2006 [Page 10] Internet-Draft GAP May 2006 4.2. MN/AR/IGW Registration (MN_REG/AR_REG/IGW_REG) MNs/ARs/IGWs send this message to register with their selected AR/ IGW/peer IGWs. 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/AR's/IGW's global address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message type: 2 Reserved: Filled with zeros, ignored by receiver Lifetime: The time in seconds for how long the MN/AR/IGW wants to register with the IGW 4.3. MN/AR/IGW Registration Acknowledgement (MN_REG_ACK/AR_REG_ACK/ IGW_REG_ACK) ARs/IGWs/peer IGWs return this message to the MN/AR/peer IGW if the registration was successful. Mase & Owada Expires November 19, 2006 [Page 11] Internet-Draft GAP May 2006 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: 3 Reserved: Filled with zeros, ignored by receiver Lifetime: The time in seconds specifying for how long the registration is valid 4.4. AR-IGW Table ARs maintain an AR-IGW table to store information about available IGWs. An entry of the AR-IGW table contains the following information. Mase & Owada Expires November 19, 2006 [Page 12] Internet-Draft GAP May 2006 +------------------------------+ | IGW's golbal address | +------------------------------+ | IGW's prefix | +------------------------------+ | IGW expiration time | +------------------------------+ | Registration expiration time | +------------------------------+ ARs also need to keep track of their current status, i.e., whether they are connected (i.e., registered) to any IGW and, if so, to which AR-IGW they are connected. 4.5. MN-IGW Table MNs maintain an MN-IGW table to store information about available IGWs. An entry of the MN-IGW table contains the following information. +------------------------------+ | IGW's golbal address | +------------------------------+ | IGW's prefix | +------------------------------+ | Sequence Number | +------------------------------+ | IGW expiration time | +------------------------------+ Mase & Owada Expires November 19, 2006 [Page 13] Internet-Draft GAP May 2006 MNs also need to keep track of their current status, i.e., whether they are connected (i.e., registered) to any IGW and, if so, to which IGW they are connected. 4.6. AR Table IGWs maintain an AR table to store information about ARs that have a valid registration. An entry of the AR table contains the following information. +------------------------------+ | AR's global address | +------------------------------+ | Registration expiration time | +------------------------------+ 4.7. Peer IGW Table IGWs maintain a peer IGW table to store information about IGWs that have a valid registration. An entry of the peer IGW table contains the following information. +------------------------------+ |Peer IGW's global address | +------------------------------+ | Registration expiration time | Mase & Owada Expires November 19, 2006 [Page 14] Internet-Draft GAP May 2006 +------------------------------+ 4.8. MN table ARs maintain an MN table to store information about MNs that have a valid registration. An entry of the MN table contains the following information. +------------------------------+ | MN's global address | +------------------------------+ | Registration expiration time | +------------------------------+ Mase & Owada Expires November 19, 2006 [Page 15] Internet-Draft GAP May 2006 5. Protocol Operation 5.1. IGW Advertisement An IGW, that has one or more entries in the AR table, MUST periodically disseminate the Internet gateway advertisement (IGW_ADV) messages containing IGW prefix, sequence number and lifetime (IGW_ADV_LIFETIME) in a certain time interval (IGW_ADV_INTERVAL). The hop limit of the messages SHOULD be set to NET_DIAMETER. When an MN/AR/IGW receives a new IGW_ADV messages, it rebroadcasts it. A new IGW_ADV message means a message with greater sequence number than received for a given IGW. An efficient flooding protocol such as [7] MAY be used to disseminate IGW_ADV messages. 5.2. MN registration When an MN attaches to a new AR, it acquires a global routable address (care-of -address) from the visited network. An MN sends a registration request (MN_REG) message including its global address and registration lifetime to its AR. The lifetime SHOULD be set to MN_REG_LIFETIME. If it does not receive the registration acknowledgement (MN_REG_ACK) message within a certain time (MN_REG_TIMEOUT), it SHOULD resend a limited number (MN_REG_RETRIES) of registration request messages until it receives an MN_REG_ACK message. If the MN 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 MUST be stopped if the MN gets disconnected from the AR and the AR table entry was removed. If the MN does not receive any MN_REG_ACK messages after MN_REG_DURATION, the registration has failed and the MN MUST remove the corresponding AR table entry. When receiving an MN_REG message, the AR MUST return an 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. 5.3. MN Table Maintenance An AR MUST maintain a table listing all MNs that currently have a valid registration. An entry of the MN table is created on reception of an MN_REG message and contains the respective MN's 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 an MN_REG message from the same MN is received. An MN table entry MUST be removed by the AR if the registration of the respective MN has expired. Mase & Owada Expires November 19, 2006 [Page 16] Internet-Draft GAP May 2006 5.4. IGW discovery and selection Each AR is in charge of discovering an IGW. In principle, a single IGW SHOULD be used throughout the MANET. When an AR creates the MN table, it MUST discover an IGW. It first checks whether an existing IGW is available or not. That is, if it has received the Internet gateway advertisement (IGW_ADV) messages containing IGW prefix, sequence number and lifetime (IGW_ADV_LIFETIME) from one or more existing IGWs for the MANET, it selects one of them as its IGW. Otherwise, the AR selects itself as IGW. An AR MAY select itself as the IGW, although there are one or more existing IGWs used for the MANET. For example, if two or more ARs try to discover an IGW, almost simultaneously, they may become the IGWs, respectively. 5.5. AR-IGW Table Maintenance An AR with the MN table MUST maintain a table listing all valid IGWs. A table entry is created when an AR receives an IGW_ADV. An entry contains the IGW's global address, IGW prefix, the IGW expiration time and the registration expiration time (registration is described in Section 5.6). The IGW expiration time is the reception time of the last IGW_ADV message plus the advertised IGW_ADV_LIFETIME. It is updated each time a new advertisement from the same IGW is received. An AR-IGW table entry MUST be removed if it has expired. If an AR loses its MN table, the IGW table MAY be removed. 5.6. AR registration An AR sends a registration request (AR_REG) message including its global address and registration lifetime to the selected IGW. The lifetime SHOULD be set to AR_REG_LIFETIME. If it does not receive the registration acknowledgement (AR_REG_ACK) message within a certain time (AR_REG_TIMEOUT), it SHOULD resend a limited number (AR_REG_RETRIES) of registration request messages until it receives an AR_REG_ACK message. If the AR receives the AR_REG_ACK message, the registration was successful and the AR SHOULD repeat the registration periodically with an interval of AR_REG_INTERVAL. The periodical registration MUST be stopped if the IGW table entry was removed. If the AR does not receive any AR_REG_ACK messages after AR_REG_DURATION, the registration has failed and the AR MUST remove the corresponding IGW table entry. It SHOULD subsequently select a new IGW. When receiving an AR_REG message, the IGW MUST return an AR_REG_ACK message to the AR including the granted lifetime of the registration. The granted lifetime SHOULD be the lifetime requested by the AR. Mase & Owada Expires November 19, 2006 [Page 17] Internet-Draft GAP May 2006 5.7. AR Table Maintenance An IGW MUST maintain a table listing all ARs that currently have a valid registration. An entry of the AR table is created on reception of an AR_REG message and contains the respective AR's global address and the registration expiration time. The registration expiration time is the reception time of the last AR_REG message plus the granted lifetime of the registration. An entry is updated each time an AR_REG message from the same AR is received. An AR table entry MUST be removed by the IGW if the registration of the respective AR has expired. 5.8. IGW registration When an IGW discover other IGW (peer IGW) by receiving the IGW_ADV messages from that IGW, it sends a registration request (IGW_REG) message including its global address and registration lifetime to the peer IGW. The lifetime SHOULD be set to IGW_REG_LIFETIME. If it does not receive the registration acknowledgement (IGW_REG_ACK) message within a certain time (IGW_REG_TIMEOUT), it SHOULD resend a limited number (IGW_REG_RETRIES) of registration request messages until it receives an IGW_REG_ACK message. If the IGW receives the IGW_REG_ACK message, the registration was successful and the IGW SHOULD repeat the registration periodically with an interval of IGW_REG_INTERVAL. The periodical registration MUST be stopped if its AR table entry was removed. If the IGW does not receive any IGW_REG_ACK messages after IGW_REG_DURATION, the registration has failed and the IGW MUST remove the corresponding peer IGW table entry. When receiving an IGW_REG message, the IGW MUST return an IGW_REG_ACK message to the peer IGW including the granted lifetime of the registration. The granted lifetime SHOULD be the lifetime requested by the IGW. 5.9. Peer IGW Table Maintenance An IGW MUST maintain a table listing all peer IGWs that currently have a valid registration. An entry of the peer IGW table is created on reception of an IGW_REG message and contains the respective IGW's global address and the registration expiration time. The registration expiration time is the reception time of the last IGW_REG message plus the granted lifetime of the registration. An entry is updated each time an IGW_REG message from the same IGW is received. A peer IGW table entry MUST be removed by the IGW if the registration of the respective IGW has expired. Mase & Owada Expires November 19, 2006 [Page 18] Internet-Draft GAP May 2006 5.10. Tunneling between an MN and its associated AR, between an AR, and an IGW and between IGWs ARs and IGWs work as the member of the MANET and MANET routing protocol runs both on ARs and IGWs. When an registration between an MN and its associated AR, an AR and an IGW or between a peer of IGWs is established, routing control messages and data packets within the MANET are tunneled between them in both directions, that can be achieved by IP-in -IP encapsulation [6]. 5.11. MN-IGW Table Maintenance MNs that require Internet access have to wait until they receive an IGW_ADV messages from any IGWs. When an MN without an MN-IGW table entry receives an IGW_ADV message, an MN-IGW table entry is created, that contains the IGW's global address, IGW prefix, sequence number and the IGW expiration time. The IGW expiration time is the reception time of the last IGW_ADV message plus the advertised IGW_ADV_LIFTIME. It is updated each time a new advertisement with the same prefix is received, where a new advertisement means one with sequence number greater than that in the table entry. An MN-IGW table entry MUST be removed if it has expired. 5.12. Address Autoconfiguration If an MN needs to connect to the Internet and has information about an IGW in its IGW table, it MUST use one of the IGW prefixes to autoconfigure its global address. It does not have to change its global address in the MANET. 5.13. Packet forwarding Once an MN obtains a global address from an IGW, it may exchange data with the Internet nodes by making best use of the IGW. Note that ARs, that exist on the way to and from the IGW, are automatically selected by the routing protocol. Outgoing data packets received by the AR MAY be directly forwarded to the Internet without passing the corresponding IGW. Mase & Owada Expires November 19, 2006 [Page 19] Internet-Draft GAP May 2006 6. Protocol Parameters Parameter Value --------- ----- NET_DIAMETER 35 NODE_TRAVERSAL_TIME 40 ms NET_TRAVERSAL_TIME 3 * NODE_TRAVERSAL_TIME * NET_DIAMETER / 2 IGW_ADV_LIFETIME 3,000 ms IGW_ADV_INTERVAL GW_ADV_LIFETIME * 0.9 MN_REG_LIFETIME 30,000 ms MN_REG_TIME 40 ms MN_REG_RETRLES 3 MN_REG_DURATIOW (MN_REG_RETRIES+1) * MN_REG_TIMEOUT MN_REG_INTERVAL MN_REG_LIFETIME * 0.9 AR_REG_LIFETIME 30,000 ms AR_REG_TIMEOUT 2 * NET_TRAVERSAL_TIME AR_REG_RETRIES 5 AR_REG_DURATION (MN_REG_RETRIES + 1) * MN_REG_TIMEOUT AR_REG_INTERUAL AR_REG_LIFETIME * 0.9 IGW_REG_LIFETIME 30,000 ms Mase & Owada Expires November 19, 2006 [Page 20] Internet-Draft GAP May 2006 IGW_REG_TIMEOUT 2 * NET_TRAVERSAL_TIME IGW_REG_RETRIES 5 IGW_REG_DURATION (MN_REG_RETRIES + 1) * MN_REG_TIMEOUT IGW_REG_INTERUAL IGW_REG_LIFETIME * 0.9 The parameter NET_DIAMETER MAY be adapted to the actual network size. Mase & Owada Expires November 19, 2006 [Page 21] Internet-Draft GAP May 2006 7. IANA Considerations This document has no actions for IANA Mase & Owada Expires November 19, 2006 [Page 22] Internet-Draft GAP May 2006 8. Security Considerations This document does not specify any special security measure. Mase & Owada Expires November 19, 2006 [Page 23] Internet-Draft GAP May 2006 9. Acknowledgements This work was funded by Strategic Information and Communications R&D Promotion Programme (SCOPE), Ministry of Internal Affairs and Communications, Japan. Mase & Owada Expires November 19, 2006 [Page 24] Internet-Draft GAP May 2006 10. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Wakikawa, R., J. T. Malinen, C. E. Perkins, A. Nilsson, and A. J. Tuominen, "Global Connectivity for Mobile Ad Hoc Networks", draft-wakikawa-manet-globalv6-04 (work in progress,) July 2005. [3] Jelger, C., T. Noel, and A. Fre, "Gateway and Address Autoconfiguration for IPv6 Ad Hoc Networks", draft-jelger-manet-gateway-autoconf-v6-02 (work in progress,), April 2004. [4] Ruffino, S. and P. Stupar, "Automatic Configuration of IPv6 Addresses for noes in a MANET with Mutiple Gateways", draft-ruffino-manet-autoconf-multigw-01 (work in progress), December, 2005. [5] Hofmann, P., "Multihop Radio Access Network (MRAN) Protocol Specification", draft-hofmann-autoconf-mran-00 (work in progress), March 2006. [6] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [7] Macker, J., "Simplified Multicast Forwarding for MANET", draft-ietf-manet-smf-01 (work in progress), June 2005. Mase & Owada Expires November 19, 2006 [Page 25] Internet-Draft GAP May 2006 Authors' Addresses Kenichi Mase Graduate School of Science and Technology, Niigata University Phone: +81 25 262 7446 Email: mase@ie.niigata-u.ac.jp URI: http://www.net.ie.niigata-u.ac.jp/ Yasunori Owada Graduate School of Science and Technology, Niigata University Phone: +81 70 5458 7470 Email: yowada@net.ie.niigata-u.ac.jp URI: http://www.net.ie.niigata-u.ac.jp/~yowada/ Mase & Owada Expires November 19, 2006 [Page 26] Internet-Draft GAP May 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. Mase & Owada Expires November 19, 2006 [Page 27]