| TOC |
|
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 4, 2006.
Copyright © The Internet Society (2005).
This document is an analysis of multihoming in the context of network mobility (NEMO) in IPv6. As there are many situations in which mobile networks may be multihomed, a taxonomy is proposed to classify the possible configurations. The possible deployment scenarios of multihomed mobile networks are described together with the associated issues when network mobility is supported by RFC 3963 (NEMO Basic Support). Issues are classified according to the Working Group which is the best chartered to solve them.
1.
Introduction
2.
Classification
2.1.
(1,1,1): Single MR, Single HA, Single MNP
2.2.
(1,1,n): Single MR, Single HA, Multiple MNPs
2.3.
(1,n,1): Single MR, Multiple HAs, Single MNP
2.4.
(1,n,n): Single MR, Multiple HAs, Multiple MNPs
2.5.
(n,1,1): Multiple MRs, Single HA, Single MNP
2.6.
(n,1,n): Multiple MRs, Single HA, Multiple MNPs
2.7.
(n,n,1): Multiple MRs, Multiple HAs, Single MNP
2.8.
(n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs
3.
Deployment Scenarios and Prerequisites
3.1.
Deployment Scenarios
3.2.
Prerequisites
4.
Multihoming Issues
4.1.
Fault Tolerance
4.1.1.
Failure Detection
4.1.2.
Path Exploration
4.1.3.
Path Selection
4.1.4.
Re-Homing
4.2.
Ingress Filtering
4.3.
HA Synchronization
4.4.
MR Synchronization
4.5.
Prefix Delegation
4.6.
Multiple Bindings/Registrations
4.7.
Source Address Selection
4.8.
Loop Prevention in Nested Mobile Networks
4.9.
Prefix Ownership
4.10.
Preference Settings
5.
Recommendations to the Working Group
6.
Conclusion
7.
IANA Considerations
8.
Security Considerations
9.
Acknowledgments
10.
References
10.1.
Normative References
10.2.
Informative References
Appendix A.
Alternative Classifications Approach
A.1.
Ownership-Oriented Approach
A.1.1.
ISP Model
A.1.2.
Subscriber/Provider Model
A.2.
Problem-Oriented Approach
Appendix B.
Nested Tunneling for Fault Tolerance
B.1.
Detecting Presence of Alternate Routes
B.2.
Re-Establishment of Bi-Directional Tunnels
B.2.1.
Using Alternate Egress Interface
B.2.2.
Using Alternate Mobile Router
B.3.
To Avoid Tunneling Loop
B.4.
Points of Considerations
Appendix C.
Change Log
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
The design goals and objectives of Network Mobility Support (NEMO) in IPv6 are identified in [1] (Ernst, T., “Network Mobility Support Goals and Requirements,” October 2005.) while the terminology is being described in [2] (Manner, J. and M. Kojo, “Mobility Related Terminology,” June 2004.) and [3] (Ernst, T. and H. Lach, “Network Mobility Support Terminology,” October 2005.). NEMO Basic Support (RFC 3963) [4] (Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, “Network Mobility (NEMO) Basic Support Protocol,” January 2005.) is the solution proposed by the NEMO Working Group to provide continuous Internet connectivity to nodes located in an IPv6 mobile network, e.g. like in an in-vehicle embedded IP network. The NEMO Basic Support solution basically solves the problem by setting up bi-directional tunnels between the mobile routers (MRs) connecting the mobile network to the Internet and their respective Home Agents (HAs), much how this is done in Mobile IPv6 [5] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.), the solution for host mobility support. NEMO Basic Support is transparent to nodes located behind the mobile router (i.e. the mobile network nodes, or MNNs) and as such does not require MNNs to take any action in the mobility management.
However, mobile networks are typically connected by means of wireless and thus less reliable links; there could also be many nodes behind the MR. A loss of connectivity or a failure to connect to the Internet has thus a more significant impact than for a single mobile node. Scenarios illustrated in [6] (Ernst, T., Montavont, N., Wakikawa, R., Paik, E., Ng, C., Kuladinithi, K., and T. Noel, “Goals and Benefits of Multihoming,” October 2005.) demonstrate that providing a permanent access to mobile networks such as vehicles typically require the use of several interfaces and technologies since the mobile network may be moving in distant geographical locations where different access technologies are provided and governed by distinct access control policies.
As specified by R.12 in section 5 of [1] (Ernst, T., “Network Mobility Support Goals and Requirements,” October 2005.), the NEMO WG must ensure that NEMO Basic Support does not prevent mobile networks to be multihomed, i.e. when there is more than one point of attachment between the mobile network and the Internet (see definitions in [3] (Ernst, T. and H. Lach, “Network Mobility Support Terminology,” October 2005.)). This arises either:
Using NEMO Basic Support, this would translate into having multiple bi-directional tunnels between the MR(s) and the corresponding HA, and may result into multiple MNPs available to the MNNs. However, NEMO Basic Support does not specify any particular mechanism to manage multiple bi-directional tunnels. The objective of this memo is thus multi-folded:
In order to reach these objectives, a taxonomy to classify the possible multihomed configurations is described in Section 2 (Classification). Deployment scenarios, their benefits, and requirements to meet these benefits are illustrated in Section 3 (Deployment Scenarios and Prerequisites). Following this, the related issues are studied in Section 4 (Multihoming Issues). The issues are then summarized in a matrix for each of the deployment scenario, and recommendations are made on which of the issues should be worked on and where in Section 5 (Recommendations to the Working Group). This memo concludes with an evaluation of NEMO Basic Support for multihomed configurations. Alternative classifications are outlined in the Appendix.
The readers should note that this document considers multihoming only from the point of view of an IPv6 environment. In order to understand this memo, the reader is expected to be familiar with the above cited documents, i.e. with the NEMO terminology as defined in [2] (Manner, J. and M. Kojo, “Mobility Related Terminology,” June 2004.) (section 3) and [3] (Ernst, T. and H. Lach, “Network Mobility Support Terminology,” October 2005.), Goals and Benefits of Multihoming [6] (Ernst, T., Montavont, N., Wakikawa, R., Paik, E., Ng, C., Kuladinithi, K., and T. Noel, “Goals and Benefits of Multihoming,” October 2005.), Goals and Requirements of Network Mobility Support [1] (Ernst, T., “Network Mobility Support Goals and Requirements,” October 2005.), and the NEMO Basic Support specification [4] (Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, “Network Mobility (NEMO) Basic Support Protocol,” January 2005.). Goals and benefits of multihoming as discussed in [6] (Ernst, T., Montavont, N., Wakikawa, R., Paik, E., Ng, C., Kuladinithi, K., and T. Noel, “Goals and Benefits of Multihoming,” October 2005.) are applicable to fixed nodes, mobile nodes, fixed networks and mobile networks.
| TOC |
As there are several configurations in which mobile networks are multihomed, there is a need to classify them into a clearly defined taxonomy. This can be done in various ways. A Configuration-Oriented taxonomy is described in this section. Two other taxonomies, namely, the Ownership-Oriented Approach, and the Problem-Oriented Approach are outlined in Appendix A.1 (Ownership-Oriented Approach) and Appendix A.2 (Problem-Oriented Approach).
Multihomed configurations can be classified depending on how many mobile routers are present, how many egress interfaces, Care-of Address (CoA) and Home Addresses (HoA) the mobile routers have, how many prefixes (MNPs) are available to the mobile network nodes, etc. We use three key parameters to differentiate the multihomed configurations. Using these parameters, each configuration is referred by the 3-tuple (x,y,z), where 'x', 'y', 'z' are defined as follows:
- x=1
- implies a mobile network has only a single MR, presumably multihomed.
- x=n
- implies a mobile network has more than one MR.
- y=1
- implies that a single HA is assigned to the mobile network.
- y=n
- implies that multiple HAs are assigned to the mobile network.
- z=1
- implies that a single MNP is available in the NEMO.
- z=N
- implies that multiple MNPs are available in the NEMO
It can be seen that the above three parameters are fairly orthogonal to one another. Thus different values of 'x', 'y' and 'z' result into different combinations of the 3-tuple (x,y,z).
As described in the sub-sections below, a total of 8 possible configurations can be identified. One thing the reader has to keep in mind is that in each of the following 8 cases, the MR may be multihomed if either (i) multiple prefixes are available (on the home link, or on the visited link), or (ii) the MR is equipped with multiple interfaces. In such a case, the MR would have multiple Home Address / Care-of Address pairs. Issues pertaining to a multihomed MR are also addressed in [7] (Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. Kuladinithi, “Analysis of Multihoming in Mobile IPv6,” October 2005.). In addition, the readers should also keep in mind that when "MNP(s) is/are available in the NEMO", the MNP(s) may either be explicitly announced by the MR via router advertisement, or made available through Dynamic Host Configuration Protocol (DHCP).
| TOC |
The (1,1,1) mobile network has only one MR, it is associated with a single HA, and a single MNP is available in the NEMO. To fall into a multihomed configuration, at least one of the following conditions must hold:
A bi-directional tunnel would then be established between each pair of Home Address / Care-of Address.
Regarding MNNs, they are (usually) not multihomed since they would configure a single global address from the single MNP available on the link they are attached to.
_____
_ p _ | |
|_|-|<-_ |-|_|-| |-| _
_ |-|_|=| |_____| | _ |-|_|
|_|-| | |-|_|-|
|
MNNs MR AR Internet AR HA
| Figure 1: (1,1,1): 1 MR, 1 HA, 1 MNP |
| TOC |
The (1,1,n) mobile network has only one MR, it is associated with a single HA and two or more MNPs are available in the NEMO.
The MR may be itself multihomed, as detailed in Section 2.1 ((1,1,1): Single MR, Single HA, Single MNP). In such a case, a bi-directional tunnel would be established between each pair of Home Address / Care-of Address.
Regarding MNNs, they are multihomed because several MNPs are available on the link they are attached to. The MNNs would then configure a global address with each MNP available on the link.
_____
_ p1,p2 _ | |
|_|-|<-_ |-|_|-| |-| _
_ |-|_|=| |_____| | _ |-|_|
|_|-| | |-|_|-|
|
MNNs MR AR Internet AR HA
| Figure 2: (1,1,n): 1 MR, 1 HA, multiple MNPs |
| TOC |
The (1,n,1) mobile network has only one MR and a single MNP is available in the NEMO. The MR, however, is associated with multiple HAs, possibly one HA per Home Address, or one HA per egress interface.
The NEMO is multihomed since it has multiple HAs, but in addition the conditions detailed in Section 2.1 ((1,1,1): Single MR, Single HA, Single MNP) may also hold for the MR. A bi-directional tunnel would then be established between each pair of Home Address / Care-of Address.
Regarding MNNs, they are (usually) not multihomed since they would configure a single global address from the single MNP available on the link they are attached to.
AR HA2
_ |
|-|_|-| _
_____ | |-|_|
_ p _ | |-|
|_|-|<-_ |-|_|-| |
_ |-|_|=| |_____|-| _
|_|-| | | _ |-|_|
|-|_|-|
|
MNNs MR AR Internet AR HA1
| Figure 3: (1,n,1): 1 MR, multiple HAs, 1 MNP |
| TOC |
The (1,n,n) mobile network has only one MR. However, the MR is associated with multiple HAs, possibly one per Home Address (or one HA per egress interface), and more than one MNP is available in the NEMO.
The MR is multihomed since it has multiple HAs, but in addition the conditions detailed in Section 2.1 ((1,1,1): Single MR, Single HA, Single MNP) may also hold. A bi-directional tunnel would then be established between each pair of Home Address / Care-of Address.
Regarding MNNs, they are generally multihomed since they would configure a global address from each MNP available on the link they are attached to.
AR HA2
_ | _
_____ |-|_|-|-|_|
_ p1,p2 _ | |-| |
|_|-|<-_ |-|_|-| | _
_ |-|_|=| |_____|-| _ |-|_|
|_|-| | |-|_|-|
| |
MNNs MR AR Internet AR HA1
| Figure 4: (1,n,n): 1 MR, multiple HAs, multiple MNPs |
| TOC |
The (n,1,1) mobile network has more than one MR advertising global routes. However, the MR(s) are associated with as single HA, and there in a single MNP available in the NEMO.
The NEMO is multihomed since it has multiple MRs, but in addition the conditions detailed in Section 2.1 ((1,1,1): Single MR, Single HA, Single MNP) may also hold for each MR. A bi-directional tunnel would then be established between each pair of Home Address / Care-of Address.
Regarding MNNs, they are (usually) not multihomed since they would configure a single global address from the single MNP available on the link they are attached to.
MR2
p<-_ |
_ |-|_|-| _____
|_|-| |-| |
_ | | |-| _
|_|-| _ |-|_____| | _ |-|_|
|-|_|-| |-|_|-|
p<- | |
MNNs MR1 Internet AR HA
| Figure 5: (n,1,1): Multiple MRs, 1 HA, 1 MNP |
| TOC |
The (n,1,n) mobile network has more than one MR; multiple global routes are advertised by the MRs and multiple MNPs are available within the NEMO.
The NEMO is multihomed since it has multiple MRs, but in addition the conditions detailed in Section 2.1 ((1,1,1): Single MR, Single HA, Single MNP) may also hold for each MR. A bi-directional tunnel would then be established between each pair of Home Address / Care-of Address.
Regarding MNNs, they are generally multihomed since they would configure a global address from each MNP available on the link they are attached to.
MR2
p2<-_ |
_ |-|_|-| _____
|_|-| |-| |
_ | | |-| _
|_|-| _ |-|_____| | _ |-|_|
|-|_|-| |-|_|-|
p1<- | |
MNNs MR1 Internet AR HA
| Figure 6: (n,1,n): Multiple MRs, 1 HA, multiple MNPs |
| TOC |
The (n,n,1) mobile network has more than one MR advertising multiple global routes. The mobile network is simultaneously associated with multiple HAs and a single MNP is available in the NEMO.
The NEMO is multihomed since it has multiple MRs and HAs, but in addition the conditions detailed in Section 2.1 ((1,1,1): Single MR, Single HA, Single MNP) may also hold for each MR. A bi-directional tunnel would then be established between each pair of Home Address / Care-of Address.
Regarding MNNs, they are (usually) not multihomed since they would configure a single global address from the single MNP available on the link they are attached to.
MR2 AR HA2
p _ |
<-_ | |-|_|-| _
_ |-|_|-| _____ | |-|_|
|_|-| |-| |-|
_ | | |
|_|-| _ |-|_____|-| _
|-|_|-| | _ |-|_|
<- | |-|_|-|
p |
MNNs MR1 Internet AR HA1
| Figure 7: (n,n,1): Multiple MRs, Multiple HAs, 1 MNP |
| TOC |
The (n,n,n) mobile network has multiple MRs advertising different global routes. The mobile network is simultaneously associated with more than one HA and multiple MNPs are available in the NEMO.
The NEMO is multihomed since it has multiple MRs and HAs, but in addition the conditions detailed in Section 2.1 ((1,1,1): Single MR, Single HA, Single MNP) may also hold for each MR. A bi-directional tunnel would then be established between each pair of Home Address / Care-of Address.
Regarding MNNs, they are generally multihomed since they would configure a global address from each MNP available on the link they are attached to.
MR2 AR HA2
p2 _ |
<-_ | |-|_|-| _
_ |-|_|-| _____ | |-|_|
|_|-| |-| |-|
_ | | |
|_|-| _ |-|_____|-| _
|-|_|-| | _ |-|_|
<- | |-|_|-|
p1 |
MNNs MR1 Internet AR HA1
| Figure 8: (n,n,n): Multiple MRs, HAs, and MNPs |
| TOC |
The following generic goals and benefits of multihoming are discussed in [6] (Ernst, T., Montavont, N., Wakikawa, R., Paik, E., Ng, C., Kuladinithi, K., and T. Noel, “Goals and Benefits of Multihoming,” October 2005.):
These benefits are now illustrated from a NEMO perspective with a typical instance scenario for each case in the taxonomy. We then discuss the prerequisites to fulfill these.
| TOC |
- x=1:
- Multihomed mobile networks with a single MR
- o
- Example: an MR with dual/multiple access interfaces (e.g. 802.11 and GPRS capabilities). This is a (1,1,*) if both accesses are subscribed to the same ISP. If the two accesses are offered by independent ISPs, this is a (1,n,n)
Benefits: Ubiquitous Access, Reliability, Load Sharing, Preference Settings, Aggregate Bandwidth
- x=N:
- Multihomed mobile networks with multiple MRs
- o
- Example 1: a train with one MR in each car, all served by the same HA, thus a (n,1,*). Alternatively, the train company might be forced to use different ISPs when the train go to different locations, thus it is a (n,n,n).
Benefits: Load Sharing, Reliability, Ubiquitous Access, Aggregate Bandwidth- o
- Example 2: W-PAN with a GPRS-enabled phone and a WiFi-enabled PDA. This is a (n,n,n) if the two access technologies are subscribed separately.
Benefits: Ubiquitous Access, Reliability, Preference Settings, Aggregate Bandwidth
- y=1:
- Multihomed mobile networks with a single HA
- o
- Most single ISP cases in above examples.
- y=N:
- Multihomed mobile networks with multiple HAs
- o
- Most multiple ISP cases in above examples.
- o
- Example: a transatlantic flight with a HA in each continent. This is a (1,n,1) network if there is only one MR.
Benefits: Ubiquity, Preferences (reduced delay, shortest path), Reliability
- z=1:
- Multihomed mobile networks with a single MNP
- o
- Most single ISP cases in above examples.
- z=N:
- Multihomed mobile networks with multiple MNPs
- o
- Most multiple ISP cases in above examples.
- o
- Example: a car with a prefix taken from home (personal traffic transit on this prefix and is paid by the owner) and one that belongs to the car manufacturer (maintenance traffic is paid by the car-manufacturer). This will typically be a (1,1,n) or a (1,n,n,).
Benefits: Preference Settings
| TOC |
In this section, requirements are started in order to comply with the expected benefits of multihoming as detailed in [6] (Ernst, T., Montavont, N., Wakikawa, R., Paik, E., Ng, C., Kuladinithi, K., and T. Noel, “Goals and Benefits of Multihoming,” October 2005.).
At least one bi-directional tunnel must be available at any point in time between the mobile network and the fixed network to meet all expectations. But for most goals to be effective, multiple tunnels must be maintained simultaneously:
| TOC |
As discussed in the previous section, multiple bi-directional tunnels need to be maintained either sequentially (e.g. for fault tolerance) or simultaneously (e.g. for load sharing).
In some cases, it may be necessary to divert packets from a (perhaps failed) bi-directional tunnel to an alternative (perhaps newly established) bi-directional tunnel (i.e. for matters of fault recovery, preferences), or to split traffic between multiple tunnels (load sharing, load balancing).
So, depending on the configuration under consideration, the issues discussed below may need to be addressed, sometimes dynamically. For each issue, potential ways to solve the problem are investigated and an a recommendation is made on which IETF WG(s) should look into these issues.
| TOC |
One of the goals of multihoming is the provision of fault tolerance capabilities. In order to provide such features, a set of tasks need to be performed, including: failure detection, alternative available path exploration, path selection, re-homing of established communications. These are also discussed in [8] (Arkko, J., “Failure Detection and Locator Pair Exploration Design for IPv6 Multihoming,” October 2005.) and [9] (Beijnum, I., “Shim6 Reachability Detection,” July 2005.) by the Shim6 WG. In the following sub-sections, we look at these issues in the specific context of NEMO, rather than the general Shim6 perspective in [8] (Arkko, J., “Failure Detection and Locator Pair Exploration Design for IPv6 Multihoming,” October 2005.) [9] (Beijnum, I., “Shim6 Reachability Detection,” July 2005.). In addition, in some scenarios, it may also be required to provide the mechanisms for coordination between different HAs (see Section 4.3 (HA Synchronization)) and also the coordination between different MRs (see Section 4.4 (MR Synchronization)).
| TOC |
It is expected for faults to occur more readily at the edge of the network (i.e. the mobile nodes), due to the use of wireless connections. Efficient fault detection mechanisms are necessary to recover in timely fashion. Depending on the NEMO configuration considered, the failure protection domain greatly varies. In some configurations, the protection domain provided by NEMO multihoming is limited to the links between the MR(s) and the HA(s). In other configurations, the protection domain allows to recover from failures in other parts of the path, so an end to end failure detection mechanism is required.
Below are detailed which failure detection capabilities are required for each configuration:
Most of the above cases involve the detection of tunnel failures between HA(s) and MR(s). This is no different from the case of failure detection between a mobile host and its HA(s). As such, a solution for MIPv6 should apply to NEMO as well. For the case of (n,*,*), a MR synchronization solution (see Section 4.4 (MR Synchronization)) should be able to compliment a MIPv6 failure detection solution to achieve the desired functionality for NEMO.
In order for fault recovery to work, the MRs and HAs must first possess a means to detect failures:
A possible method is for the MRs to send binding updates more regularly with shorter Lifetime values. Similarly, HAs can return binding acknowledgment messages with smaller Lifetime values, thus forcing the MRs to send binding updates more frequently. These binding updates can be used to emulate "tunnel heartbeats". This however may lead to more traffic and processing overhead, since binding updates sent to HAs must be protected (and possibly encrypted) with security associations.
| TOC |
Once a failure in the currently used path is detected, alternative paths need to be explored in order to identify an available one. This process is closely related to failure detection in the sense that paths being explored need to be alternative paths to the one that has failed. There are, however, subtle but significant differences between path exploration and failure detection. Failure detection occurs on the currently used path while path exploration occurs on the alternative paths (not on the one currently being used for exchanging packets). Although both path exploration and failure detection are likely to rely on a reachability or keepalive test exchange, failure detection also relies on other information, such as upper layer information (e.g. positive or negative feedback form TCP), lower layer information (e.g. an interface is down), and network layer information (e.g. as an address being deprecated or ICMP error message).
Basically, the same cases as in the analysis of the failure detection (Section 4.1.1 (Failure Detection)) issue are identified:
Most of the above cases involve the path exploration of tunnels between HA(s) and MR(s). This is no different from the case of path exploration between a mobile host and its HA(s). As such, a solution for MIPv6 should apply to NEMO as well. For the case of (n,*,*), a MR synchronization solution (see Section 4.4 (MR Synchronization)) should be able to compliment a MIPv6 path exploration solution to achieve the desired functionality for NEMO.
In order to perform path exploration, it is sometimes also necessary for the mobile router to detect the availability of network media. This may be achieved using layer 2 triggers [10] (Yegin, A., “Link-layer Event Notifications for Detecting Network Attachments,” July 2005.), or other mechanism developed/recommended by the Detecting Network Attachment (DNA) Working Group [11] (Narayanan, S., “Detecting Network Attachment in IPv6 - Best Current Practices for hosts.,” July 2005.)[14] (Narayanan, S., “Detecting Network Attachment in IPv6 - Best Current Practices for Routers,” July 2005.). This is related to Section 4.1.1 (Failure Detection), since the ability to detect media availability would often implies the ability to detect media un-availability.
| TOC |
A path selection mechanism is required to select among the multiple available paths. Depending on the NEMO multihoming configuration involved, the differences between the paths may affect only the part between the HA and the MR, or they may affect the full end-to-end path. In addition, depending on the configuration, path selection may be performed by the HA(s), the MR(s) or the hosts themselves through address selection, as will be described in details next.
The multiple available paths may differ on the tunnel between the MR and the HA used to carry traffic to/from the NEMO. In this case, path selection is performed by the MR and the intra-NEMO routing system for traffic flowing from the NEMO, and path selection is performed by the HA and intra-Home Network routing system for traffic flowing to the NEMO.
Alternatively, the multiple paths available may differ in more than just the tunnel between the MR and the HA, since the usage of different prefixes may result in using different providers, hence in completely different paths between the involved endpoints. In this case, besides the mechanisms presented in the previous case, additional mechanisms for the end-to-end path selection may be needed. This mechanism may be closely related to source address selection mechanisms within the hosts, since selecting a given address implies selecting a given prefix, which is associated with a given ISP serving one of the home networks.
A dynamic path selection mechanism is thus needed so that this path could be selected by:
When multiple bi-directional tunnels are available and possibly used simultaneously, the mode of operation may be either primary-secondary (one tunnel is precedent over the others and used as the default tunnel, while the other serves as a back-up) or peer-to-peer (no tunnel has precedence over one another, they are used with the same priority). This questions which of the bi-directional tunnels would be selected, and based on which of the parameters (e.g. type of flow that goes into/out of the mobile network).
The mechanisms for the selection among the different tunnels between the MR(s) and the HA(s) seems to be quite NEMO/MIPv6 specific. For (1,*,*) cases, they are no different from the case of path selection between a mobile host and its HA(s). As such, a solution for MIPv6 should apply to NEMO as well. For the case of (n,*,*), a MR synchronization solution (see Section 4.4 (MR Synchronization)) should be able to compliment a MIPv6 path selection solution to achieve the desired functionality for NEMO. The mechanisms for selecting among different end-to-end paths based on address selection are similar to the ones used in other multihoming scenarios, as those considered by Shim6 (e.g. [16] (Bagnulo, M. and J. Arkko, “Functional decomposition of the multihoming protocol,” July 2005.)).
| TOC |
After an outage has been detected and an available alternative path has been identified, a re-homing event takes place, diverting the existing communications from one path to the other. Similar to the previous items involved in this process, the re-homing procedure heavily varies depending on the NEMO multihoming configuration.
| TOC |
Ingress filtering mechanisms [17] (Ferguson, P. and D. Senie, “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing,” May 2000.)[18] (Baker, F. and P. Savola, “Ingress Filtering for Multihomed Networks,” March 2004.) may drop the outgoing packets when multiple bi-directional tunnels end up at different HAs. This could particularly occur if different MNPs are handled by different HAs. If a packet with a source address configured from a specific MNP is tunnelled to a home agent that does not handle that specific MNP the packet may be discarded either by the home agent or by a border gateway in the home network.
The ingress filtering compatibility issue is heavily dependent on the particular NEMO multihoming configuration:
As an example of how this could happen, consider the deployment scenario illustrated in Figure 9 (An (n,n,n) mobile network): the mobile network has two mobile routers MR1 and MR2, with home agents HA1 and HA2 respectively. Two bi-directional tunnels are established between the two pairs. Each mobile router advertises a different MNP (P1 and P2 respectively). MNP P1 is registered to HA1, and MNP P2 is registered to HA2. Thus, MNNs should be free to auto-configure their addresses on any of P1 or P2. Ingress filtering could thus happen in two cases:
Prefix: P1 +-----+ +----+ +----------+ +-----+
+--| MR1 |--| AR |--| |---| HA1 |
| +-----+ +----+ | | +-----+
IP: +-----+ | | | Prefix: P1
P1.MNN or | MNN |--+ | Internet |
P2.MNN +-----+ | | | Prefix: P2
| +-----+ +----+ | | +-----+
+--| MR2 |--| AR |--| |---| HA2 |
Prefix: P2 +-----+ +----+ +----------+ +-----+
| Figure 9: An (n,n,n) mobile network |
Possible solutions to the ingress filtering incompatibility problem may be based on the following approaches:
The ingress filtering incompatibilities problems that appear in some NEMO multihoming configurations are similar to those considered in Shim6 (eg. see [19] (Huitema, C., “Ingress filtering compatibility for IPv6 multihomed sites,” September 2005.)).
| TOC |
In the (*,n,*) mobile networks, a single MNP would be registered at different HAs. This gives rise to the following cases:
This may pose a problem in the routing infrastructure as a whole if the HAs are located in different administrative domains. The implications of this aspect needs further exploration. Certain level of HA co-ordination may be required. A possible approach is to adopt a HA synchronization mechanism such as that described in [20] (Wakikawa, R., Devarapalli, V., and P. Thubert, “Inter Home Agents Protocol (HAHA),” February 2004.) and [21] (Koh, B., Ng, C., and J. Hirano, “Dynamic Inter Home Agent Protocol,” July 2004.). Such synchronization might also be necessary in a (*,n,*) mobile network, when a MR sends binding update messages to only one HA (instead of all HAs). In such cases, the binding update information might have to be synchronized between HAs. The mode of synchronization may be either primary-secondary or peer-to-peer. In addition, when MNP is delegated to the MR (see Section 4.5 (Prefix Delegation)), some level of co-ordination between the HAs may also be necessary.
This issue is a general mobility issue that will also have to be dealt with by Mobile IPv6 as well as NEMO Basic Support. It is recommended that the Monami6 WG take this issue into consideration.
| TOC |
In the (n,*,*) mobile network, different MRs may need to be synchronized in order to take common decisions, such as:
However, there is no known standardized protocols for this kind of router-to-router synchronization. Without such synchronization, it may not be possible for a (n,*,*) mobile network to achieve various multihoming goals, such as fault tolerance.
Such a synchronization mechanism can be primary-secondary (i.e. a master MR, with the other MRs as backup) or peer-to-peer (i.e. there is no clear administrative hierarchy between the MRs). The need for such mechanism is general in the sense that a multi-router site in the fixed network would require the same level of router synchronization. It is recommended that the issue be looked at in the IPv6 or Shim6 WG, and the NEMO WG to contribute any NEMO specific requirement.
| TOC |
In the (*,*,1) mobile network, the same MNP must be advertised to the MNNs through different paths. There is, however, no synchronization mechanism available to achieve this. Particularly,
Prefix delegation mechanisms [22] (Miyakawa, S. and R. Droms, “Requirements for IPv6 Prefix Delegation,” June 2004.)[23] (Droms, R. and P. Thubert, “DHCPv6 Prefix Delegation for NEMO,” April 2005.)[24] (Kniveton, T. and P. Thubert, “Mobile Network Prefix Delegation,” August 2005.) could be used to ensure all routers advertise the same MNP. The WG should consider their application to a multihomed mobile network.
| TOC |
When a MR is configured with multiple Care-of Addresses, it is often necessary for it to bind these Care-of Addresses to the same MNP.
This is a generic mobility issue, since Mobile IPv6 nodes face a similar problem. This issue is discussed in [7] (Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. Kuladinithi, “Analysis of Multihoming in Mobile IPv6,” October 2005.). It is sufficient to note that solutions like [25] (Wakikawa, R., “Multiple Care-of Addresses Registration,” June 2005.) can solve this for both Mobile IPv6 and NEMO Basic Support. This issue should be dealt with in the Monami6 WG.
| TOC |
In the (*,*,n) mobile networks, MNNs would be configured with multiple addresses. Source address selection mechanisms are needed to decide which address to choose from. In addition, source address selection may be closely related to path selection procedures (see Section 4.1.3 (Path Selection)) and re-homing techniques (see Section 4.1.4 (Re-Homing)).
However, currently available source address selection mechanisms do not allow MNNs to acquire sufficient information to select their source addresses intelligently (such as based on the traffic condition associated with the home network of each MNP). It may be desirable for MNNs to be able to acquire "preference" information on each MNP from the MRs. This would allow default address selection mechanisms such as those specified in [26] (Draves, R., “Default Address Selection for Internet Protocol version 6 (IPv6),” February 2003.) to be used. Further exploration on setting such "preference" information in Router Advertisement based on performance of the bi-directional tunnel might prove to be useful.
This is a general issue faced by any node when offered multiple prefixes. It is recommended that the issue be examined by other WG (such as IPv6).
| TOC |
When a multihomed mobile network is nested within another mobile network, it can result in very complex topologies. For instance, a nested mobile network may be attached to two different root-MRs, thus the aggregated network no longer forms a simple tree structure. As such, a solution to prevent an infinite loop of multiple mobile routers must be provided.
This problem is specific to NEMO Basic Support. It is recommended that the NEMO WG standardizes a solution to solve this problem (such as the use of a tree-spanning algorithm, or [27] (Thubert, P., “Nested Nemo Tree Discovery,” July 2005.)).
| TOC |
When a (n,*,1) network splits, (i.e. the two MRs split themselves up), MRs on distinct links may try to register the only available MNP. This cannot be allowed, as the HA has no way to know which node with an address configured from that MNP is attached to which MR. Some mechanism must be present for the MNP to either be forcibly removed from one (or all) MRs, or the implementors must not allow a (n,*,1) network to split.
A possible approach to solving this problem is described in [28] (Kumazawa, M., “Token based Duplicate Network Detection for split mobile network (Token based DND),” July 2005.).
This problem is specific to NEMO Basic Support. However, it is unclear whether there is sufficient deployment scenario for this problem to occur. It is recommended that the NEMO WG standardizes a solution to solve this problem if there is sufficient vendor/operator interest, or specifies that the split of a (n,*,1) network cannot be allowed without a router renumbering.
| TOC |
When a mobile network is multihomed, the MNNs may be able to enjoy the benefits of multihoming, such as to choose among the available paths based on cost, transmission delays, bandwidth, etc. However, in some cases, such a choice is not made available to the MNNs. Particularly,
A mechanism that allows the MNN to indicate its preference for a given traffic might be helpful. In addition, there may also be a need to exchange some information between the MRs and the MNNs. This problem is general in the sense that any IPv6 nodes may wish to influence the routing decision done by the upstream routers. Such mechanism is currently being explored by various WGs, such as the NSIS and IPFIX WGs. It is also possible that a Shim6 layer in the MNNs may possess such capability. It is recommended that vendors or operators to investigate into the solutions developed by these WGs when providing multihoming capabilities to mobile networks.
| TOC |
Several issues that might impact the deployment of NEMO with
multihoming capabilities were identified in Section 4 (Multihoming Issues).
These are shown in the matrix below,
for each of the eight multihoming configurations, together with indications of the WG(s)
in which each issue is the most likely to be solved.
+=================================================================+
| # of MRs: | 1 | 1 | 1 | 1 | n | n | n | n |
| # of HAs: | 1 | 1 | n | n | 1 | 1 | n | n |
| # of Prefixes: | 1 | n | 1 | n | 1 | n | 1 | n |
+=================================================================+
| Fault Tolerance | * | * | * | * | * | * | * | * |
+---------------------------------+---+---+---+---+---+---+---+---+
| Failure Detection |N/M|N/M|N/M|N/M|N/M|N/M| N | S |
+---------------------------------+---+---+---+---+---+---+---+---+
| Path Exploration |N/M|N/M|N/M|N/M|N/M|N/M| N | S |
+---------------------------------+---+---+---+---+---+---+---+---+
| Path Selection | N |S/N| N |S/N| N |S/N| N |S/N|
+---------------------------------+---+---+---+---+---+---+---+---+
| Re-Homing |N/M| S |N/M| S |N/M| S |N/M| S |
+---------------------------------+---+---+---+---+---+---+---+---+
| Ingress Filtering | . | . | . | t | . | . | . | N |
+---------------------------------+---+---+---+---+---+---+---+---+
| HA Synchronization | . | . |N/M|N/M| . | . |N/M|N/M|
+---------------------------------+---+---+---+---+---+---+---+---+
| MR Synchronization | . | . | . | . | G | G | G | G |
+---------------------------------+---+---+---+---+---+---+---+---+
| Prefix Delegation | . | . | N | N | N | N | N | N |
+---------------------------------+---+---+---+---+---+---+---+---+
| Multiple Binding/Registrations | M | M | M | M | M | M | M | M |
+---------------------------------+---+---+---+---+---+---+---+---+
| Source Address Selection | . | G | . | G | . | G | . | G |
+---------------------------------+---+---+---+---+---+---+---+---+
| Loop Prevention in Nested NEMO | N | N | N | N | N | N | N | N |
+---------------------------------+---+---+---+---+---+---+---+---+
| Prefix Ownership | . | . | . | . | N | . | N | . |
+---------------------------------+---+---+---+---+---+---+---+---+
| Preference Settings | G | G | G | G | G | G | G | G |
+=================================================================+
N - NEMO Specific M - MIPv6 Specific G - Generic IPv6
S - SHIM6 WG D - DNA WG
. - Not an Issue t - trivial
* - Fault Tolerance is a combination of Failure Detection, Path
Exploration, Path Selection, and Re-Homing
| Figure 10: Matrix of NEMO Multihoming Issues |
The above matrix serves to identify which issues are NEMO-specific, and which concern other Working Groups. The readers are reminded that this matrix is a simplification of Section 4 (Multihoming Issues) as subtle details are not represented in Figure 10 (Matrix of NEMO Multihoming Issues).
As can be seen from Figure 10 (Matrix of NEMO Multihoming Issues), the following have some concerns which are specific to NEMO: Failure Detection, Path Exploration, Path Selection, Re-Homing, Ingress Filtering, HA Synchronization, Prefix Delegation, Loop Prevention in Nested NEMO, and Prefix Ownership. Based on the authors' best knowledge of the possible deployments of NEMO, it is recommended that:
| TOC |
This memo is an analysis of multihoming in the context of network mobility under the operation of NEMO Basic Support. The purpose of this memo is to investigate issues related to such a bi-directional tunneling mechanism when mobile networks are multihomed. For doing so, a taxonomy was proposed to classify the mobile networks in eight possible multihomed configurations. The issue were explained and were then summarized in a table showing under which multihoming configuration it applies, and which IETF working group is the best chartered to solve it. This analysis will be helpful to extend the existing standards to support multihoming and to implementors of NEMO Basic Support and multihoming-related mechanisms.
| TOC |
This is an informational document and does not require any IANA action.
| TOC |
This is an informational document where the multihoming configurations under the operation of NEMO Basic Support are analyzed. Security considerations of these multihoming configurations, should they be different from those that concern NEMO Basic Support, must be considered by forthcoming solutions.
| TOC |
The authors would like to thank people who have given valuable comments on various multihoming issues on the mailing list, and also those who have suggested directions in the 56th - 61st IETF Meetings. The initial evaluation of NEMO Basic Support is a contribution from Julien Charbon.
| TOC |
| TOC |
| [1] | Ernst, T., “Network Mobility Support Goals and Requirements,” draft-ietf-nemo-requirements-05 (work in progress), October 2005. |
| [2] | Manner, J. and M. Kojo, “Mobility Related Terminology,” RFC 3753, June 2004. |
| [3] | Ernst, T. and H. Lach, “Network Mobility Support Terminology,” draft-ietf-nemo-terminology-04 (work in progress), October 2005. |
| [4] | Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, “Network Mobility (NEMO) Basic Support Protocol,” RFC 3963, January 2005. |
| [5] | Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” RFC 3775, June 2004. |
| TOC |
| [6] | Ernst, T., Montavont, N., Wakikawa, R., Paik, E., Ng, C., Kuladinithi, K., and T. Noel, “Goals and Benefits of Multihoming,” draft-multihoming-generic-goals-and-benefits-02 (work in progress), October 2005. |
| [7] | Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. Kuladinithi, “Analysis of Multihoming in Mobile IPv6,” draft-montavont-mobileip-multihoming-pb-statement-05 (work in progress), October 2005. |
| [8] | Arkko, J., “Failure Detection and Locator Pair Exploration Design for IPv6 Multihoming,” draft-ietf-shim6-failure-detection-01 (work in progress), October 2005. |
| [9] | Beijnum, I., “Shim6 Reachability Detection,” draft-ietf-shim6-reach-detect-00 (work in progress), July 2005. |
| [10] | Yegin, A., “Link-layer Event Notifications for Detecting Network Attachments,” draft-ietf-dna-link-information-02 (work in progress), July 2005. |
| [11] | Narayanan, S., “Detecting Network Attachment in IPv6 - Best Current Practices for hosts.,” draft-ietf-dna-hosts-01 (work in progress), July 2005. |
| [12] | Yegin, A., “Link-layer Hints for Detecting Network Attachments,” draft-yegin-dna-l2-hints-01 (work in progress), February 2004. |
| [13] | Yegin, A., “Supporting Optimized Handover for IP Mobility -Requirements for Underlying Systems,” draft-manyfolks-l2-mobilereq-02 (work in progress), July 2002. |
| [14] | Narayanan, S., “Detecting Network Attachment in IPv6 - Best Current Practices for Routers,” draft-ietf-dna-routers-00 (work in progress), July 2005. |
| [15] | Narten, T., Nordmark, E., and W. Simpson, “Neighbor Discovery for IP Version 6 (IPv6),” RFC 2461, December 1998 (TXT, HTML, XML). |
| [16] | Bagnulo, M. and J. Arkko, “Functional decomposition of the multihoming protocol,” draft-ietf-shim6-functional-dec-00 (work in progress), July 2005. |
| [17] | Ferguson, P. and D. Senie, “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing,” BCP 38, RFC 2827, May 2000. |
| [18] | Baker, F. and P. Savola, “Ingress Filtering for Multihomed Networks,” BCP 84, RFC 3704, March 2004. |
| [19] | Huitema, C., “Ingress filtering compatibility for IPv6 multihomed sites,” draft-huitema-shim6-ingress-filtering-00 (work in progress), September 2005. |
| [20] | Wakikawa, R., Devarapalli, V., and P. Thubert, “Inter Home Agents Protocol (HAHA),” draft-wakikawa-mip6-nemo-haha-01 (work in progress), February 2004. |
| [21] | Koh, B., Ng, C., and J. Hirano, “Dynamic Inter Home Agent Protocol,” draft-koh-mip6-nemo-dhap-00 (work in progress), July 2004. |
| [22] | Miyakawa, S. and R. Droms, “Requirements for IPv6 Prefix Delegation,” RFC 3769, June 2004. |
| [23] | Droms, R. and P. Thubert, “DHCPv6 Prefix Delegation for NEMO,” draft-droms-nemo-dhcpv6-pd-02 (work in progress), April 2005. |
| [24] | Kniveton, T. and P. Thubert, “Mobile Network Prefix Delegation,” draft-ietf-nemo-prefix-delegation-00 (work in progress), August 2005. |
| [25] | Wakikawa, R., “Multiple Care-of Addresses Registration,” draft-wakikawa-mobileip-multiplecoa-04 (work in progress), June 2005. |
| [26] | Draves, R., “Default Address Selection for Internet Protocol version 6 (IPv6),” RFC 3484, February 2003. |
| [27] | Thubert, P., “Nested Nemo Tree Discovery,” draft-thubert-tree-discovery-02 (work in progress), July 2005. |
| [28] | Kumazawa, M., “Token based Duplicate Network Detection for split mobile network (Token based DND),” draft-kumazawa-nemo-tbdnd-02 (work in progress), July 2005. |
| TOC |
| TOC |
An alternative approach to classifying multihomed mobile network is proposed by Erik Nordmark (Sun Microsystems) by breaking the classification of multihomed network based on ownership. This is more of a tree-like top-down classification. Starting from the control and ownership of the HA(s) and MR(s), there are two different possibilities: either (i) the HA(s) and MR(s) are controlled by a single entity, or (ii) the HA(s) and MR(s) are controlled by separate entities. We called the first possibility the 'ISP Model', and the second the 'Subscriber/Provider Model'.
| TOC |
The case of the HA(s) and MR(s) are controlled by the same entity can be best illustrated as an Internet Service Provider (ISP) installing mobile routers on trains, ships or planes. It is up to the ISP to deploy a certain configuration of mobile network; all 8 configurations as described in the Configuration-Oriented Approach are possible. In the remaining portion of this document, when specifically referring to a mobile network configuration that is controlled by a single entity, we will add an 'ISP' prefix: for example: ISP-(1,1,1) or ISP-(1,N,N).
When the HA(s) and MR(s) are controlled by a single entity (such as an ISP), the ISP can decide whether it wants to assign one or multiple MNPs to the mobile network just like it can make the same decision for any other link in its network (wired or otherwise). In any case, the ISP will make the routing between the mobile networks and its core routers (such as the HAs) work. This include not introducing any aggregation between the HAs which will filter out routing announcements for the MNP(es).
To such ends, the ISP has various means and mechanisms. For one, the ISP can run its Interior Gateway Protocol (IGP) over bi-directional tunnels between the MR(s) and HA(s). Alternatively, static routes may be used with the tunnels. When static routes are used, a mechanism to test "tunnel liveness" might be necessary to avoid maintaining stale routes. Such "tunnel liveness" may be tested by sending heartbeats signals from MR(s) to the HA(s). A possibility is to simulate heartbeats using Binding Updates messages by controlling the "Lifetime" field of the Binding Acknowledgment message to force the MR to send Binding Update messages at regular interval. However, a more appropriate tool might be the Binding Refresh Request message, though conformance to the Binding Refresh Request message may be less strictly enforced in implementations since it serves a somewhat secondary role when compared to Binding Update messages.
| TOC |
The case of the HA(s) and MR(s) are controlled by the separate entities can be best illustrated with a subscriber/provider model, where the MRs belongs to a single subscriber and subscribes to one or more ISPs for HA services. There is two sub-categories in this case: when the subscriber subscribes to a single ISP, and when the subscriber subscribes to multiple ISPs. In the remaining portion of this document, when specifically referring to a mobile network configuration that is in the subscriber/provider model where the subscriber subscribes to only one ISP, we will add an 'S/P' prefix: for example: S/P-(1,1,1) or S/P-(1,n,n). When specifically referring to a mobile network configuration that is in the subscriber/provider model where the subscriber subscribes to multiple ISPs, we will add an 'S/mP' prefix: for example: S/mP-(1,1,1) or S/mP-(1,n,n).
Not all 8 configurations are likely to be deployed for the S/P and S/mP models. For instance, it is unlikely to foresee a S/mP-(*,1,1) mobile network where there is only a single HA. For the S/P model, the following configurations are likely to be deployed:
For the S/mP model, the following configurations are likely to be deployed:
When the HA(s) and MR(s) are controlled by different entities, it is more likely the scenario where the MR is controlled by one entity (i.e. the subscriber), and the MR is establishing multiple bi-directional tunnels to one or more HA(s) provided by one or more ISP(s). In such case, it is unlikely for the ISP to run IGP over the bi-directional tunnel, since ISP would most certainly wish to retain full control of its routing domain.
| TOC |
A third approach is proposed by Pascal Thubert (Cisco System). This focused on the problems of multihomed mobile networks rather than the configuration or ownership. With this approach, there is a set of 4 categories based on two orthogonal parameters: the number of HAs, and the number of MNPs advertised. Since the two parameters are orthogonal, the categories are not mutually exclusive. The four categories are:
| TOC |
In order to utilize the additional robustness provided by multihoming, MRs that employ bi-directional tunneling with their HAs should dynamically change their tunnel exit points depending on the link status. For instance, if a MR detects that one of its egress interface is down, it should detect if any other alternate route to the global Internet exists. This alternate route may be provided by any other MRs connected to one of its ingress interfaces that has an independent route to the global Internet, or by another active egress interface the MR itself possess. If such an alternate route exists, the MR should re-establish the bi-directional tunnel using this alternate route.
In the remaining part of this Appendix, we will attempt to investigate methods of performing such re-establishment of bi-directional tunnels. This method of tunnel re-establishment is particularly useful for the (*,n,n) NEMO configuration. The method described is by no means complete and merely serves as a suggestion on how to approach the problem. It is also not the objective to specify a new protocol specifically tailored to provide this form of re- establishments. Instead, we will limit ourselves to currently available mechanisms specified in Mobile IPv6 [5] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) and Neighbor Discovery in IPv6 [15] (Narten, T., Nordmark, E., and W. Simpson, “Neighbor Discovery for IP Version 6 (IPv6),” December 1998.).
| TOC |
To actively utilize the robustness provided by multihoming, a MR must first be capable of detecting alternate routes. This can be manually configured into the MR by the administrators if the configuration of the mobile network is relatively static. It is however highly desirable for MRs to be able to discover alternate routes automatically for greater flexibility.
The case where a MR possesses multiple egress interface (bound to the same HA or otherwise) should be trivial, since the MR should be able to "realize" it has multiple routes to the global Internet.
In the case where multiple MRs are on the mobile network, each MR has to detect the presence of other MR. A MR can do so by listening for Router Advertisement message on its *ingress* interfaces. When a MR receives a Router Advertisement message with a non-zero Router Lifetime field from one of its ingress interfaces, it knows that another MR which can provide an alternate route to the global Internet is present in the mobile network.
| TOC |
When a MR detects that the link by which its current bi-directional tunnel with its HA is using is down, it needs to re-establish the bi-directional tunnel using an alternate route detected. We consider two separate cases here: firstly, the alternate route is provided by another egress interface that belongs to the MR; secondly, the alternate route is provided by another MR connected to the mobile network. We refer to the former case as an alternate route provided by an alternate egress interface, and the latter case as an alternate route provided by an alternate MR.
| TOC |
When an egress interface of a MR loses the connection to the global Internet, the MR can make use of its alternate egress interface should it possess multiple egress interfaces. The most direct way to do so is for the mobile router to send a binding update to the home agent of the failed interface using the Care-of Address assigned to the alternate interface in order to re-establish the bi-directional tunneling using the Care-of Address on the alternate egress interface. After a successful binding update, the MR encapsulates outgoing packets through the bi-directional tunnel using the alternate egress interface.
The idea is to use the global address (most likely a Care-of Address) assigned to an alternate egress interface as the new (back-up) Care-of Address of the mobile router to re-establish the bi-directional tunneling with its home agent.
| TOC |
When the MR loses a connection to the global Internet, the MR can utilize a route provided by an alternate MR (if one exists) to re-establish the bi-directional tunnel with its HA. First, the MR has to obtain a Care-of Address from the alternate MR (i.e. attaches itself to the alternate MR). Next, it sends binding update to its HA using the Care-of Address obtained from the alternate MR. From then on, the MR can encapsulates outgoing packets through the bi-directional tunnel using via the alternate MR.
The idea is to obtain a Care-of Address from the alternate MR and use this as the new (back-up) Care-of Address of the MR to re-establish the bi-directional tunneling with its HA.
Note that every packet sent between MNNs and their correspondent nodes will experience two levels of encapsulation. First level of tunneling occurs between a MR which the MNN uses as its default router and the MR's HA. The second level of tunneling occurs between the alternate MR and its HA.
| TOC |
The method of re-establishing the bi-directional tunnel as described in Appendix B.2 (Re-Establishment of Bi-Directional Tunnels) may lead to infinite loops of tunneling. This happens when two MRs on a mobile network lose connection to the global Internet at the same time and each MR tries to re-establish bi-directional tunnel using the other MR. We refer to this phenomenon as tunneling loop.
One approach to avoid tunneling loop is for a MR that has lost connection to the global Internet to insert an option into the Router Advertisement message it broadcasts periodically. This option serves to notify other MRs on the link that the sender no longer provides global connection. Note that setting a zero Router Lifetime field will not work well since it will cause MNNs that are attached to the MR to stop using the MR as their default router too (in which case, things are back to square one).
| TOC |
This method of using tunnel re-establishments is by no means a complete solution. There are still points to consider to develop it into a fully functional solution. For instance, in Appendix B.1 (Detecting Presence of Alternate Routes), it was suggested that MR detects the presence of other MRs using Router Advertisements. However, Router Advertisements are link scoped, so when there is more than one link, some information may be lost. For instance, suppose a case where there is three MRs and three different prefixes and each MR is in a different link with regular routers in between. Suppose now that only a single MR is working, how do the other MRs identify which prefix they have to use to configure the new CoA? In this case, there are three prefixes being announced and a MR whose link has failed, knows that his prefix is not to be used, but it has not enough information to decide which one of the other two prefixes to use to configure the new CoA. In such cases, a mechanism is needed to allow a MR to withdraw its own prefix when it discovers that its link is no longer working.
| TOC |
| TOC |
| Chan-Wah Ng | |
| Panasonic Singapore Laboratories Pte Ltd | |
| Blk 1022 Tai Seng Ave #06-3530 | |
| Tai Seng Industrial Estate | |
| Singapore 534415 | |
| SG | |
| Phone: | +65 65505420 |
| Email: | chanwah.ng@sg.panasonic.com |
| Eun Kyoung Paik | |
| KT | |
| Portable Internet Team, Convergence Lab., KT | |
| 17 Woomyeon-dong, Seocho-gu | |
| Seoul 137-792 | |
| Korea | |
| Phone: | +82-2-526-5233 |
| Fax: | +82-2-526-5200 |
| Email: | euna@kt.co.kr |
| URI: | http://mmlab.snu.ac.kr/~eun/ |
| 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/ |
| Marcelo Bagnulo | |
| Universidad Carlos III de Madrid | |
| Av. Universidad, 30 | |
| Leganes, Madrid 28911 | |
| Spain | |
| Phone: | +34 91624 8837 |
| Email: | marcelo@it.uc3m.es |
| TOC |
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.
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 © 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.
Funding for the RFC Editor function is currently provided by the Internet Society.