NEMO Working Group M. Tsukada Internet-Draft R. Kuntz Expires: April 20, 2006 T. Ernst Keio University / WIDE October 17, 2005 Analysis of Multiple Mobile Routers Cooperation draft-tsukada-nemo-mr-cooperation-analysis-00.txt 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 April 20, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document is an analysis of multiple Mobile Routers Cooperation in the context of network mobility support (NEMO) in IPv6. Our objective is to identify when cooperation between MRs is needed and what information must be exchanged. Tsukada, et al. Expires April 20, 2006 [Page 1] Internet-Draft Analysis of Multiple MRs Cooperation October 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Objectives, Motivations and Assumptions . . . . . . . . . . . 3 2.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Sample Scenarios . . . . . . . . . . . . . . . . . . . . . 4 2.2.1 Mobile Network in a Personal Area Network . . . . . . 4 2.2.2 Mobile Network in a Vehicle . . . . . . . . . . . . . 5 2.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6 3. Points Of Failure . . . . . . . . . . . . . . . . . . . . . . 7 3.1 MR Failure (B) . . . . . . . . . . . . . . . . . . . . . . 8 3.2 HA Failure (D) . . . . . . . . . . . . . . . . . . . . . . 8 3.3 NEMO Tunnel Failure (C) . . . . . . . . . . . . . . . . . 9 3.4 NEMO-Link Failure (A) . . . . . . . . . . . . . . . . . . 9 4. Requirements Analysis . . . . . . . . . . . . . . . . . . . . 9 4.1 NEMO Tunnel Discovery . . . . . . . . . . . . . . . . . . 10 4.2 Ingress Filtering Discovery . . . . . . . . . . . . . . . 12 4.3 MR State Discovery . . . . . . . . . . . . . . . . . . . . 12 4.4 Link Characteristics Discovery . . . . . . . . . . . . . . 13 4.5 MNP Relay . . . . . . . . . . . . . . . . . . . . . . . . 13 4.6 Split NEMO Discovery . . . . . . . . . . . . . . . . . . . 14 4.7 Policy Discovery . . . . . . . . . . . . . . . . . . . . . 14 5. Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1 Mobility Approach . . . . . . . . . . . . . . . . . . . . 14 5.1.1 Binding Information Sharing . . . . . . . . . . . . . 14 5.1.2 Link Characteristics Sharing . . . . . . . . . . . . . 16 5.1.3 Policy Sharing . . . . . . . . . . . . . . . . . . . . 16 5.2 Standard approach . . . . . . . . . . . . . . . . . . . . 16 6. Security Consideration . . . . . . . . . . . . . . . . . . . . 16 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 19 Tsukada, et al. Expires April 20, 2006 [Page 2] Internet-Draft Analysis of Multiple MRs Cooperation October 2005 1. Introduction Network mobility support is necessary for groups of computers moving together and requiring access to the Internet, such as networks of sensors or access networks deployed in vehicles. NEMO Basic Support (or NEMO in short [2]) has been specified to address this need. In some situations, the mobile network may be multihomed, that is either when a mobile router is multihomed or when several mobile routers are being used to attach the same mobile network to the Internet [5]. This brings a number of benefits [6] including for instance the possibility to face the lack of coverage of a particular technology, to increase the Internet connectivity and to choose the best path in terms of delay, bandwidth or price. In theory, the simultaneous use of multiple Mobile Routers (MRs) improves the overall Internet connectivity offered to the Mobile Network Nodes (MNN) located in the mobile network, because multiple paths to the Internet are available. However, in practice, it cannot be realized using NEMO basic support only. One of the reasons is that an MR in a mobile network does not know when another Internet connectivity (provided by another MR) is available. Some of the issues are outlined in [5] and cooperation between MRs is advocated, but we need to further detail the problem before we can bring a solution for such a cooperation between MRs. At first we describe in section Section 2 the motivations and scenarios for using multiple MRs. Then, in Section 3 we detail the problems or limitations caused by the use of multiple MRs to connect a NEMO to the Internet. From this problem description, we are able to list a number of requirements in Section 4 and finally we discuss in Section 5 potential approaches for MR cooperation. 2. Objectives, Motivations and Assumptions 2.1 Objectives The objectives of this document are: o To analyze further the cases where multiple MRs are available in the NEMO (cases (n,*,*) as categorized in [5]). o To pave the way for a comprehensive solution to the issues applying to such a multihomed NEMO configuration. o To clarify the MR cooperation issues and to list the required mechanisms for MR cooperation. Tsukada, et al. Expires April 20, 2006 [Page 3] Internet-Draft Analysis of Multiple MRs Cooperation October 2005 o To discuss possible approaches. 2.2 Sample Scenarios 2.2.1 Mobile Network in a Personal Area Network In a Personal Area Network (PAN), both a mobile phone and a PDA are acting as MRs and connecting the mobile network to the Internet (Figure 1). The MRs have different access technologies. A GPRS interface is provided by the mobile phone, and an IEEE802.11g interface is shipped with the PDA. Some MNNs such as a portable game player and a small PC are connected to the PAN. These MNNs may communicate with Correspondent Nodes (CN) with different needs in terms of cost, efficiency, bandwidth requirement, delay, etc. For example, a network game played on the portable game player may require less delay and higher bandwidth than browsing on the PC. In this case, the traffic of the network game could use IEEE802.11g access available on the PDA, whereas the web access could use both GPRS and IEEE802.11g. The use of multiple MRs simultaneously allows to increase the bandwidth and to improve the access redundancy for the MNNs located in the mobile network. However, the current NEMO Basic Support does not provide any solution to share the connectivities among several MRs. We thus consider that there is a need for MRs cooperation. __________________________ / \ | Internet | \__________________________/ | | __|__ ____|___ GPRS| IEEE802.11g| ______|_____ __|__ |mobile phone| | PDA | |____________| |_____| ______|___________________|____ __|__ Personal Area Network | MNN |_ |_____| | |_____| Figure 1: Mobile Network in a Personal Area Network Tsukada, et al. Expires April 20, 2006 [Page 4] Internet-Draft Analysis of Multiple MRs Cooperation October 2005 2.2.2 Mobile Network in a Vehicle We are assuming network of sensors and computers deployed in vehicles as shown in Figure 2. There are several MNNs in a vehicle and the vehicle network is connected to the Internet via two in-vehicle MRs. One is a powerful MR that provides high-bandwidth to the MNN. As it may consume some energy, it is only switched on when the car is started. When the car is turned off, this MR is switched off. The other MR is a low-power, low-cost and low-bandwidth MR that is used as a backup while the vehicle is stopped (ie when the engine is off) or when the main MR sustains some failures. The use of multiple MRs allows to access anytime the sensible information of the car. Some cooperation between those MRs would allow to ensure that a path is always available from and to the MNNs. ______________________________ / \ | Internet | \______________________________/ | | __|__ ____|__ GPRS| 3G| ______|________ ______|________ | Backup | | Main | | in-vehicle MR | | in-vehicle MR | |_______________| |_______________| ____|_______________________|___ __|__ __|__ | MNN |_ | MNN |_ |_____| | |_____| | |_____| |_____| Figure 2: Mobile Network in a Vehicle 2.3 Benefits The benefits of Mobile Routers cooperation in the (n,*,*) cases are the same as the multihoming benefits detailed in [6]: 1. Permanent and Ubiquitous Access / Redundancy / Fault-Recovery: When a tunnel fails on an MR, MNNs can not communicate with their correspondents, and conversely. If MRs cooperate with each other, communication can be recovered via the other MR relaying the failed one. There are thus more chances to maintain a permanent connectivity to the Internet. Tsukada, et al. Expires April 20, 2006 [Page 5] Internet-Draft Analysis of Multiple MRs Cooperation October 2005 2. Load Sharing / Load Balancing / Preference Settings / Increased Bandwidth / Bi-casting: When several tunnels are available simultaneously, traffic can be spread among several MRs, either by sharing the communication flows between MRs, or bicasting (n-casting) packets. In addition, and provided enough information about the available paths and their characteristics (link efficiency, cost, etc), packets could be routed according to preferences set up by the users or the applications. 2.4 Assumptions Following the taxonomy proposed in [5], we will concentrate the analysis taking into account all the topologies where multiple MRs are available in the same NEMO. This includes all the (n,*,*) cases, namely: 1. (n,1,1): Multiple MRs, Single HA, Single MNP 2. (n,1,n): Multiple MRs, Single HA, Multiple MNPs 3. (n,n,1): Multiple MRs, Multiple HAs, Single MNP 4. (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs We assume that tunnels are set up using NEMO Basic Support and some extensions to support multiple binding registrations, as currently investigated by the Monami6 WG. Three configurations can be divided when multiple MRs are connecting the same NEMO to the Internet, as shown in Figure 3. These MRs connecting the same NEMO are referred to as "neighbor MRs" in some parts of the present document. In the (n,1,*) case, all (MR,HA) tunnels end up at the same HA. In the (n,n,*) case, either all (MR,HA) tunnels may end up at different HAs in a "pair tunnel" type or tunnels may be established between each MR and several HAs in "mesh like" type. Tsukada, et al. Expires April 20, 2006 [Page 6] Internet-Draft Analysis of Multiple MRs Cooperation October 2005 (n, 1, *) type _____ _____ | MR1 |-----------| | |_____| | | _____ | HA1 | | MR2 | | | |_____|-----------|_____| _____ _____ _____ _____ | MR1 |-----------| | | MR1 |-----------| HA1 | |_____|--+ | HA1 | |_____| |_____| | +-----|_____| _____ _____ | | _____ | MR2 | | HA2 | _____ +--|-----| | |_____|-----------|_____| | MR2 |-----+ | HA2 | |_____|-----------|_____| (n, n, *) pair tunnel type (n, n, *) mesh tunnel type Figure 3: Tunnel Topology Type Nested NEMOs are out of scope of the present study, and we don't make any assumption about the specific NEMO topology. MRs may be connected to one another on a single NEMO-link, but the NEMO could also be made of several NEMO-links, with MRs on independent NEMO- links. 3. Points Of Failure Some of the issues are outlined in [5] and cooperation between MRs is recommended, but we need to further detail the problem before we can bring a solution for such a cooperation between MRs. We will make this study from a failure point of view, i.e. by investigating the potential points of failure and remedy to act upon these failures. There are four points of failure that may affect the way multiple MRs are supported. These are illustrated on Figure 4: (A) on the NEMO- link, (B) on the MR, (C) on the (MR,HA) tunnel and (D) on the HA. Tsukada, et al. Expires April 20, 2006 [Page 7] Internet-Draft Analysis of Multiple MRs Cooperation October 2005 (A) (B) (C) (D) * * _________*_______ * * _*_ | * | _*_ * | * |===================*==============| * | _ |-----|MR | MR-HA tunnel * | |HA | | |_|--| |_*_| |_________*_______| |_*_|----| * * * * NEMO-link MRs Internet HAs home link Figure 4: Failure Analysis 3.1 MR Failure (B) The failure of the MR could happen when the MR is down or when it is isolated from the other MRs. (e.g. all interfaces are down). As a result, the failed MR becomes unreachable and thus unable to communicate with other MRs and HAs. All tunnels established by this MR would be disrupted (see point (B) on Figure 4). In addition, the failure may affect the MR which was advertising an MNP, which may cause some MNNs to renumber. A mechanism is needed to detect the failure of the MR and to redirect the traffic over an alternative tunnel (possibly newly established) between another MR and the same or another HA. It may also be necessary to relay the MNP that was advertised by the failed MR. 3.2 HA Failure (D) The failure of the HA could happen when the HA is down or when it is isolated from the Internet, for instance when the access network where the interface that connects it to the Internet fails or if the fault occurs at the edge of the network. As a result, the HA becomes unreachable (see point (D) on Figure 4). As a result, the failed HA is unable to communicate with MRs and other HAs. The HA can not be used to register the Care-of Addresses, all tunnels established with this HA would be disrupted, and packets could not be redirected from the CNs to the mobile network anymore. In addition, the MNPs registered by the MRs on this HA become unreachable, and the MRs cannot return home. A mechanism is needed to detect the failure of the HA and to redirect the traffic over an alternative tunnel (possibly newly established) between the same MR and another HA. Tsukada, et al. Expires April 20, 2006 [Page 8] Internet-Draft Analysis of Multiple MRs Cooperation October 2005 3.3 NEMO Tunnel Failure (C) Events happening between the MR and its HA (see point (C) on Figure 4) could cause the tunnel to be disrupted: e.g. one egress interface of the MR may fail, the access router may fail, the access network may be disconnected from the Internet, or the home link may fail. The MR can not send Binding Updates nor receive incoming packets from the HA through this specific tunnel. However the MR may still be able to communicate with its peer HAs via other paths and other tunnels could established on another egress interface or via the other MR. A mechanism is needed to detect the tunnel failure and to redirect all the traffic over an alternative tunnel (possibly newly established), between the same or another (HA, MR) pair. 3.4 NEMO-Link Failure (A) Events happening between two MRs on the same NEMO may cause two MRs to be disconnected: e.g. the ingress interface of an MR may fail, or the link connecting the two MRs may fail (a cable or hub if Ethernet is used, of some radio interferences when a wireless technology is used). Each MR may continue to send Binding Updates to its HA. No established tunnel may be affected but the failure may cause the NEMO to split. As a result, the incoming packets to the mobile network may not reach the MNN the packet is bound to. Also, Multiple MRs connected to this NEMO-Link will not be able to communicate via this link anymore. A mechanism is therefore needed to detect the link failure and to act upon it. 4. Requirements Analysis Path selection in multihomed NEMO is complex because there are several steps to determine a path. We thus classify the steps for path selection as follows (see Figure 5): (A) MNNs select the exit MRs as default routers, (B) the MRs select a path to the HAs, (C) the HAs select a path to the mobile network and (D) the CN select a path to the HAs. In the face of the failures highlighted previously, the path may need to be redirected from an MR to another. If the failure happens on the HA or the NEMO Tunnel, this redirection may be done in Tsukada, et al. Expires April 20, 2006 [Page 9] Internet-Draft Analysis of Multiple MRs Cooperation October 2005 cooperation between the former MR to the new MR. If the failure happens on the MR or the NEMO-link, this redirection may be done by the new MR alone. The MNNs may send the packets to their default MR or they may have the ability to choose the MR, but in any case, the ultimate choice of the exit bi-directional tunnel falls on MRs hands. This choice could be made based on the source and destination address in the packet, or based on other parameters such as the availability of tunnels. For such selection to be made efficiently, MRs need to share information about the tunnels existing on the other MRs, the state of the MR, and other characteristics. _ _ _ _ | | ---> |_| ---> <--- |_| <--- | | | | (A) _ (B) (C) _ (D) | | | | ---> |_| ---> <--- |_| <--- | | | | _ _ | | |_| ---> |_| ---> <--- |_| <--- |_| MNN MRs Internet HAs Internet CN Figure 5: Path Selection The exchange of information will help each MR to determine the network conditions and available Internet accesses. As the NEMO and tunnel infrastructures may change over time, it is mandatory that such information be regularly exchanged or that the exchange is triggered by an MR when a change is detected. 4.1 NEMO Tunnel Discovery Each MR must be aware of the tunnels established at other MRs with their respective HAs in order to know which paths are available to route packets to the Internet. Both MRs and HAs should be aware of all NEMO tunnels between MRs and a HA(s) irrespectively of the administrative domain of the HA. A NEMO tunnel discovery mechanism is therefore required. For example, in Figure 6 below, let's see what tunnels are seen simply using NEMO Basic Support: o In the (n,1,*) type, HA1 would be aware of tunnel (A) and (B), whereas MR1 would only be aware of tunnel (A) and MR2 of tunnel (B). MR1 is unaware of tunnel (B) and MR2 is unaware of tunnel (A). Tsukada, et al. Expires April 20, 2006 [Page 10] Internet-Draft Analysis of Multiple MRs Cooperation October 2005 o In the (n,n,*) pair tunnel type, MR1 and HA1 would be aware of tunnel (C) and MR2 and HA2 would be aware of tunnel (D). However, MR1 and HA1 are unaware of tunnel (D) and MR2 and HA2 are unaware of tunnel (C). o In the (n,n,*) mesh tunnel type, MR1 would be aware of tunnels (E) and (G) whereas MR2 would be aware of tunnel (F) and (H). MR1 is unaware of tunnel (F) and (H) whereas MR2 is unaware of tunnels (E) and (G). (n, 1, *) type _____ _____ | MR1 |----(A)-----| | |_____| | | _____ | HA1 | | MR2 | | | |_____|----(B)-----|_____| (n, n, *) mesh tunnel type (n,n,*) pair tunnel type _____ _____ _____ _____ | MR1 |---------(E)---| | | MR1 |----(C)----| HA1 | |_____|--+ | HA1 | |_____| |_____| | +---(F)---|_____| _____ _____ | | _____ | MR2 | | HA2 | _____ +--|---(G)---| | |_____|----(D)----|_____| | MR2 |-----+ | HA2 | |_____|---------(H)---|_____| Figure 6: NEMO Tunnel Discovery The tunnels which need to be discovered are summarized in the matrix below. Mark [X] stands for a node (MR or HA) that cannot be aware of the tunnel only using NEMO Basic Support. Tsukada, et al. Expires April 20, 2006 [Page 11] Internet-Draft Analysis of Multiple MRs Cooperation October 2005 (n,1,*) type (n,n,*) pair tunnel type (n,n,*) mesh tunnel type +=============+ +=============+ +=====================+ | |(A)|(B)| | |(C)|(D)| | |(E)|(F)|(G)|(H)| +=============+ +=============+ +=====================+ | MR1 | | X | | MR1 | | X | | MR1 | X | | X | | +-----+---+---+ +-----+---+---+ +-----+---+---+---+---+ | MR2 | X | | | MR2 | X | | | MR2 | | X | | X | +-----+---+---+ +-----+---+---+ +-----+---+---+---+---+ | HA1 | | | | HA1 | | X | | HA1 | X | X | | | +=============+ +-----+---+---+ +-----+---+---+---+---+ | HA2 | X | | | HA2 | | | X | X | +=============+ +=====================+ Figure 7: NEMO Tunnel Discovery Matrix 4.2 Ingress Filtering Discovery Due to ingress filtering (see [5]), each MR has to know which address range can be authorized over a specific (MR,HA) tunnel. For doing so, the knowledge of the multihomed NEMO configuration an MR belongs to, i.e. (x,y,z) case, and to know the (MR,HA) tunnel topology type as described in Section 2.4 are necessary. For example, in Figure 6 above, let's see what existing tunnels are valid: o In (n,n,n) pair tunnels type, MR1-HA1 and MR2-HA2 tunnels are available. Sessions between MNN and CN may not be directed from a tunnel to the other without breaking sessions because both tunnels end up at a different HA. o In (n,n,n) mesh tunnels type, all possible tunnels, MR1-HA1, MR1- HA2, MR2-HA1 and MR2-HA2 tunnels are available. Sessions between MNN and CNs can be changed from MR1-HA1 tunnel to MR2-HA1 tunnel because both tunnels end up at a same HA, so ingress filtering doesn't occur. However, traffic may not be redirected to MR1-HA2 or MR2-HA2. 4.3 MR State Discovery Each MR must be aware of its neighbor MRs' state. In case an MR is down, this would avoid one MR to attempt cooperation with a failed neighbor. This would also allow to trigger a relaying mechanism for the failed MR. In case an MR recovers from a failure, this would allow to return to the initial state of the NEMO, and to stop any Tsukada, et al. Expires April 20, 2006 [Page 12] Internet-Draft Analysis of Multiple MRs Cooperation October 2005 relaying mechanisms that was set up before the MR failed. By exchanging crucial information via the NEMO-link, each MR will be able to discover when a neighbor MR has failed or recovered, and to take some decisions to setup or stop a relaying mechanism. The MR state discovery mechanism should not assume any specific configuration of the NEMO. It should work either for MRs on the same NEMO-link, or for MRs on distinct NEMO-links as shown on Figure 8. However, in the latter case, special care must be taken so that such discovery mechanism does not introduce loops or complexity. MR1 MR2 MR3 __|_______________| |________________|__ NEMO-link1 NEMO2-link2 Figure 8: MRs Discovery Between Different NEMO-links 4.4 Link Characteristics Discovery A MR usually connects to the access networks using wireless technologies that may have different characteristics (e.g. link quality, bandwidth, delay and cost). Sharing some of such link metrics among the MRs will help to perform a decision in the path selection mechanism. The following information can be interesting to select an access link on an MR: o Available bandwidth / Used bandwidth o Expected delay (RTT) to the HA o SNR (Signal to Noise Ratio) o Security mechanisms The protocol used to exchange such metrics should be easily extensible as new wireless technologies may bring new interesting link metrics in the future. 4.5 MNP Relay A recovery mechanisms is needed to continue advertising an MNP upon a failure happening on an MR, a HA or a NEMO-link which affects the advertisement of an MNP. Tsukada, et al. Expires April 20, 2006 [Page 13] Internet-Draft Analysis of Multiple MRs Cooperation October 2005 4.6 Split NEMO Discovery When an MR notices that one of its neighbor MR is unreachable, it may be due to a failure or because the NEMO-link has split. A mechanism is thus necessary to be able to distinguish when a split occurs. The mechanism should also solve the Prefix Ownership issue as described in [5]. 4.7 Policy Discovery Policies are used to divide flows among several available paths according to the flow type, the port number, the destination address etc. For the packets sent from the mobile network, multiple MRs need to work with the same policies in order to take the same and coherent decisions. Thus a mechanism to synchronize policies among the MRs is mandatory. Policies should be exchanged using a standardized format among the MRs as they may use different OS or policy processing tools. 5. Approaches In this section we investigate possible approaches to meet the requirements outlined in the previous section. One approach is to share mobility related information, and another to use standard protocols. The way to exchange information among neighbor MR may be different if the MRs are located on the same link or in two different links (connected via a router or another MR). In the former case, sending the information to the all-router multicast address or to the targeted MR's link local address will allow the MRs to exchange information even if they are not on the same IP network. In the latter case, a new mechanism to exchange the information between the networks will be needed. 5.1 Mobility Approach 5.1.1 Binding Information Sharing MRs that are in the same mobile network can share among them the state of their binding information as well as some other important items, namely: o Care-of Address / Prefix Length By exchanging their Care-of Address(es) (with the prefix length), Tsukada, et al. Expires April 20, 2006 [Page 14] Internet-Draft Analysis of Multiple MRs Cooperation October 2005 different MRs will able to detect that they are connecting to same access network. It is (usually) not interesting that several MRs connect to same access network regarding to redundancy, bandwidth or battery purposes. The MRs may able to turn off the interfaces that are connected to the same access network except for one interface. o Home Address / Prefix Length By exchanging their Home Address(es) (with the prefix length), different MRs can know the home link of a specific MR, since the Home Address is built from the the MR's home link's prefix. o Mobile Network Prefix / Prefix Length With the MNP and its prefix length, the MRs can know which MRs are advertising the same MNP to the NEMO. This could help to solve the Prefix Ownership issue (as described in [5]) when a mobile network where several MRs advertise the same MNP splits. o HA address With the HA address, MRs can know where a specific tunnel ends. Thanks to this information, when a communication has to be diverted from one tunnel to another, ingress filtering can be avoided by choosing efficiently the new tunnel. o Ingress interface's link-local address By exchanging their link local address, MRs on the same link can communicate directly via the NEMO-link, even if they are on two different IPv6 networks. o Ingress interface's global address By exchanging their global address, MRs that are on the same mobile network but not on the same link may be able to communicate via the NEMO-link. o Binding Lifetime With the binding lifetime, each MR knows when other's MRs binding information have expired and can thus easily remove deprecated information. o MR Identification (MR ID) MR should be distinguished by an unique identifier. This ID must Tsukada, et al. Expires April 20, 2006 [Page 15] Internet-Draft Analysis of Multiple MRs Cooperation October 2005 not be duplicated in a same mobile network. o Tunnel Identification (tunnel ID) Tunnel Identification is necessary to be able to distinguish the multiple available path on a single MR. This ID must be unique on the same MR. Those information can be maintained with the MR Identification and the Tunnel Identification as key of the information database. 5.1.2 Link Characteristics Sharing The parameters exchanged should be bound to the tunnel ID and the MR ID. [8] is a solution that falls into this approach. It attempts to propose a link metric message exchange solution which allows MNNs to select the MR with the best link quality. 5.1.3 Policy Sharing Each policy exchanged should be bound to a tunnel ID and an MR ID. The path for incoming packets to the mobile network may be selected by the HA. In this document we focus on MRs cooperation, however it is recommended to share the same solution about policy sharing for both the MR-MR and MR-HA cases. 5.2 Standard approach The standard approach would use or extend existing protocols to fit the requirements, such as: o A routing protocol to announce and propagate the available path to the Internet inside the NEMO. Metrics such as described in Section 5.1.2 could also be exchanged in this way. o Neighbor Discovery to discover the neighbor MRs located in the same link. o A prefix delegation mechanism for the MRs to deal with the MNPs advertised in the NEMO. 6. Security Consideration Security considerations are out of scope of the present document, Tsukada, et al. Expires April 20, 2006 [Page 16] Internet-Draft Analysis of Multiple MRs Cooperation October 2005 since we do not discuss specific solutions. 7. Conclusion In this document, we investigated the issues for NEMO configurations with multiple MRs. We have listed a number of requirements that should be met for MNNs and MRs to choose the most appropriate exit tunnel and to recover from a failure of the MR, the HA, the tunnel itself or the NEMO-link between MRs. We have started to investigate potential approaches and we outline one which is based on the exchange of mobility binding information, and a standard one using existing network routing protocols, router advertisement and prefix delegation mechanisms. 8. Acknowledgement The authors would like to thank the Nautilus6 members for the initial discussions that has motivated the writing of this draft. 9. References [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [3] Ernst, T., "Network Mobility Support Goals and Requirements", draft-ietf-nemo-requirements-04 (work in progress), February 2005. [4] Ernst, T. and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-03 (work in progress), February 2005. [5] Ng, C., Paik, E., Ernst, T., and M. Bagnulo, "Analysis of Multihoming in Network Mobility Support", draft-ietf-nemo-multihoming-issues-03 (work in progress), July 2005. [6] Ernst, T., "Goals and Benefits of Multihoming", draft-ernst-generic-goals-and-benefits-01 (work in progress), February 2005. [7] Wakikawa, R., Uehara, K., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", draft-wakikawa-mobileip-multiplecoa-04 (work in progress), Tsukada, et al. Expires April 20, 2006 [Page 17] Internet-Draft Analysis of Multiple MRs Cooperation October 2005 June 2005. [8] Morioka, H., "Mobile Router Cooperation Protocol", draft-morioka-nemo-mrcoop-00 (work in progress), July 2005. Authors' Addresses Manabu Tsukada Keio University / WIDE Jun Murai Lab., Keio University. K-square Town Campus, 1488-8 Ogura, Saiwa-Ku Kawasaki, Kanagawa 212-0054 Japan Phone: +81-44-580-1600 Fax: +81-44-580-1437 Email: tu-ka@sfc.wide.ad.jp URI: http://www.sfc.wide.ad.jp/~tu-ka/ Romain Kuntz Keio University / WIDE Jun Murai Lab., Keio University. K-square Town Campus, 1488-8 Ogura, Saiwa-Ku Kawasaki, Kanagawa 212-0054 Japan Phone: +81-44-580-1600 Fax: +81-44-580-1437 Email: kuntz@sfc.wide.ad.jp URI: http://www.sfc.wide.ad.jp/~kuntz/ Thierry Ernst Keio University / WIDE Jun Murai Lab., Keio University. K-square Town Campus, 1488-8 Ogura, Saiwa-Ku Kawasaki, Kanagawa 212-0054 Japan Phone: +81-44-580-1600 Fax: +81-44-580-1437 Email: ernst@sfc.wide.ad.jp URI: http://www.sfc.wide.ad.jp/~ernst/ Tsukada, et al. Expires April 20, 2006 [Page 18] Internet-Draft Analysis of Multiple MRs Cooperation October 2005 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 (2005). 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. Tsukada, et al. Expires April 20, 2006 [Page 19]