| 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 January 2, 2006.
Copyright © The Internet Society (2005).
This document describes the tests performed and results obtained with multihomed mobile networks managed by NEMO Basic Support. We have particularly analyzed mobile networks with multiple mobile routers and mobile networks with multiple NEMO-Prefixes.
1.
Introduction
2.
Testing Environment
3.
Case (1,1,1): Single MR, Single HA, Single Prefix
3.1
Scenario
3.2
Results
3.2.1
Using interface preferences
3.2.2
Using Multiple Care-of Addresses registration
3.3
Conclusion
4.
Case (1,1,2): Single MR, Single HA, Multiple NEMO-Prefixes
4.1
Scenario
4.2
Results
4.2.1
Using interface preferences
4.2.2
Using Multiple Care-of Addresses registration
4.3
Potential problems and solutions
5.
Case (1,2,1): Single MR, Multiple HAs, Single NEMO-Prefix
5.1
Scenario
5.2
Results
5.3
Potential problems and solutions
6.
Case (1,2,2): Single MR, Multiple HAs, Multiple NEMO-Prefixes
6.1
Scenario
6.2
Results
6.3
Potential problems and solutions
7.
Case (2,1,1): Multiple MRs, Single HA, Single NEMO-Prefix
7.1
Scenario
7.2
Results
7.2.1
With both MRs in a foreign network
7.2.2
With MR2 at home and MR1 in a foreign network
7.3
Potential problems and solutions
8.
Case (2,1,2): Multiple MRs, Single HA, Multiple NEMO-Prefixes
8.1
Scenario
8.2
Results
8.2.1
With both MRs in a foreign network
8.2.2
With MR2 at home and MR1 in a foreign network
8.3
Potential problems and solutions
9.
Case (2,2,1): Multiple MRs, Multiple HAs, Single NEMO-Prefix
9.1
Scenario
9.2
Results
9.3
Potential problems and solutions
10.
Case (2,2,2): Multiple MRs, Multiple HAs, Multiple NEMO-Prefixes
10.1
Scenario
10.2
Results
10.3
Potential problems and solutions
11.
Conclusions
12.
Changes
12.1
Changes from version 01 to 02
12.2
Changes from version 00 to 01
13.
References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
In this document we study the support of multihoming in the NEMO [12] (IETF, “The NEMO Working Group,” July 2005.) context. We present the results of tests performed on NEMO Basic support [8] (Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, “Network Mobility (NEMO) Basic Support Protocol,” January 2005.) with multihoming configurations. We discuss the potential problems that may prevent to combine multihoming with NEMO Basic Support. We also make some recommendations to solve issues in case of mobile router failures.
Our tests follow the spirit of the analysis of multihoming in NEMO described in [3] (Ernst, T., “Analysis of Multihoming in Network Mobility Support,” February 2005.) [19] (Ernst, T. and J. Charbon, “Multihoming with NEMO Basic Support,” January 2004.). The terminology used is this memo is defined in [9] (Manner, J. and M. Kojo, “Mobility Related Terminology,” June 2004.) and [2] (Ernst, T. and H. Lach, “Network Mobility Support Terminology,” February 2005.) whereas the multihomed configurations are classified according to the taxonomy defined in [3] (Ernst, T., “Analysis of Multihoming in Network Mobility Support,” February 2005.).
We first give a short description of our testbed and implementations used before describing our tests on distinct configurations, following the same order of the classification defined in [3] (Ernst, T., “Analysis of Multihoming in Network Mobility Support,” February 2005.). Some configurations remain to be tested.
| TOC |
The multihoming tests were performed on the indoor testbed of the Nautilus6 Project [10] (WIDE, “The Nautilus6 Project,” July 2005.). The indoor testbed allows us to test protocols under development. It is composed of two mobile routers and two home agents, each running NEMO Basic Support on NetBSD 1.6.2 or Debian GNU/Linux with kernel 2.6.8.1. Several LFNs are located in each mobile network. Additionaly, the mobile routers can periodically change their point of attachment to the Internet thanks to an emulator that allows to switch between the mobile router's home network and four foreign networks.
At the moment, three NEMO Basic Support implementations are freely available:
Please note that each of these implementations are still work in progress.
In the tests presented in this document, we used both SHISA and NEPL. Those implementations are currently under progress. However we confirm that communication between MRs works well. Nested mobility is also working: first nested level of VMN and VMR can communicate with other internet nodes. We also have successfully tested interoperability between those implementations [18] (Kuntz, R., “NEMO Basic Support implementation tests at the 6th IPv6 TAHI Interoperability Test Event,” January 2005.). The case (1,1,1) presented below describes a little bit further each implementation capabilities.
| TOC |
We are interested in multihomed mobile networks advertising multiple NEMO-prefixes, but this case is a good scenario to test each implementation capabilities.
_
CN|_|---| _ _____
|-|_|-| |
_ | |
_ | p1 __ |-|_|-| |-|
|_|-| <- | |-CoA1--| | | | _ |-
|------| | | | |-|_|-|
| |__|-CoA2--| _ | | |
|-|_|-|_____|
LFN MR ARs Internet HA Home Network
(1,1,1) Simple Mobile Network
The MR has two egress interfaces and advertises one NEMO-Prefix on its ingress interface to the mobile network. The MR has only one home address and can either use an interface preference mechanism to bind either CoA1 or CoA2 to this HoA at the home agent, or use multiple care-of addresses (MCoA) registration [4] (Wakikawa, R., “Multiple Care-of Addresses Registration,” June 2005.) to bind both care-of addresses to its home address at the home agent. The HA acts as the default gateway on the home link.
The MR uses only one egress interface at the same time. We can put a preference on each interface. The mobile router uses the available interface which has the highest preference, and binds its care-of address to its home address at the home agent. If the running interface fails, then another interface can be automatically chosen and the binding updated at the home agent, transparently for all the communications coming from or going through the MR.
In this test, both egress interfaces are connected to a foreign network. If the mobile router supports interface preferences mechanism, then it can recover when the active interface fails by using the other interface. The mobile router sends a binding update via the newly activated interface to bind its new CoA to the MR's HoA at the home agent. Both HA and MR updates the tunnel endpoints, the interface change is done transparently for both the MR and LFN's communications.
With MCoA registration [4] (Wakikawa, R., “Multiple Care-of Addresses Registration,” June 2005.), the MR can bind each interface's CoA to the same HoA at the home agent. A binding identifier (BID) is defined for each CoA, the MR can then send each flow (defined by policies such as protocol, ports, destination address etc.) to one specific interface according to its BID. With MCoA registration, the MR can get benefit from multiple paths to the Internet, such as load sharing, load balancing, and failure recovery.
In this test, both egress interfaces are connected to a foreign network. If both the mobile router and its home agent support MCoA registration, then the mobile network can recover from an interface failure on the MR: if the mobile router and the home agent can dynamically adapt the flow policies, the other active interface can be used to send all the flows that were sent to the failed interface.
On a multihomed mobile router, interface preference mechanisms or multiple care-of addresses registration can be used to recover from an interface failure. MCoA registration allows to get full benefits of the multiple paths to the Internet.
At the moment, only SHISA on BSD operating systems implements interface preferences mechanisms and MCoA registration. Those features are still under development on NEPL for Linux operating system. As all (1,*,*) tests require at least interface preference mechanisms, only SHISA will be used for (1,*,*) tests, but both SHISA and NEPL will be used for (2,*,*) tests.
| TOC |
_
CN|_|---| _ _____
|-|_|-| |
_ | |
_ | p1 __ |-|_|-| |-|
|_|-| <- | |-CoA1--| | | | _ |-
|------| | | | |-|_|-|
| <- |__|-CoA2--| _ | | |
p2 |-|_|-|_____|
LFN MR ARs Internet HA Home Network
(1,1,2) Multihomed Mobile Network
The MR has two egress interfaces and advertises two different NEMO-Prefixes on its ingress interface(s) to the mobile network. The MR has only one home address. In this test, we can expect to register both NEMO-prefixes for one care-of address at a time (using interface preferences) at the home agent, or, if we use MCoA registration, to register both NEMO-Prefixes for both care-of addresses at the same time at the home agent. The HA acts as the default gateway on the home link.
The MR uses only one egress interface at the same time and registers the CoA it uses at the home agent. Both MNPs are registered with a single BU for one CoA.
As for the (1,1,1) case, the MR can recover if the active interface fails by using the other interface. In that case the MR sends a BU with both MNPs to bind the CoA of the newly activated interface to the MR's HoA at the home agent.
Two MNPs are advertised inside the mobile network. The LFNs can configure two IPv6 addresses from these prefixes, and are reachable via both addresses. The mobile router only use one interface as the same time, and binds both MNPs to the same care-of address. Thus, as long as one egress interface is usable on the MR, all LFNs are reachable at both addresses.
The MR binds each interface's CoA to the same HoA at the home agent thanks to MCoA registration.
In this test, we have defined some simple policies as followed: the mobile router sends all traffic with source address built from MNP p1 to one interface, and all traffic with source address built from MNP p2 to the other interface. We have defined the same policies on the home agent for the destination address of the packets. In that case each class of traffic uses a different MR-HA tunnel. If one of the MR's egress interface fails, the mobile router and the home agent need to dynamically adapt the policies to redirect some traffic from the failed interface to the other active one.
If we bind more than one care-of address to the same home address at the home agent (with MCoA registration), we need to select which path to use for each flow. This can be done with policies defined by the user of the mobile router, or using profile management as described in [20] (Lucian, S., Bonnin, J-M., Guillouard, K., and B. Stevant, “Towards a Highly Adaptable User-Centric Terminal Architecture,” September 2004.).
If one of the MR's egress interface fails, the MR and the HA must be able to dynamically adapt its routing policies to redirect all the traffic from the failed interface to another active one.
Two MNPs are advertised on the mobile network. The LFNs can configure two addresses and have to choose one of them when they initiate a communication with a correspondent. No ingress filtering issues should happen if the MR and the HA are properly configured to route the traffic from both MNPs.
| TOC |
_
CN|_|---| _ _____
|-|_|-| |
_ | |
_ | p1 __ |-|_|-| |-| _
|_|-| <- | |-CoA1--| | | | _ |-|1|
|------| | | | |-|_|-| _
| |__|-CoA2--| _ | | |-|2|
|-|_|-|_____|
LFN MR ARs Internet AR Home Network with 2 HAs
(1,2,1) Multihomed Mobile Network
The MR has two egress interfaces and advertises one NEMO-Prefix on its ingress interface to the mobile network. Registering the same MNP to two different home agents raises an issue: each HA has to advertise a route to the MNP, which is a problem if each HA is in a different domain. In this test we configure both HAs on the same home link. They do not act as a gateway to the Internet. We can have several scenario:
At the moment the MR cannot register to multiple home agents that are on the same home link. Thus we cannot test any of the scenario described previously. This will be for a later session, when implementation will allow that.
We can at least raise the following issues that may happen in such case. In the case of multiple home addresses, how the mobile router would choose it when initiating communications? This problem would be the same on a host operating Mobile IPv6 and is also discussed in [7] (Montavont, N., Wakikawa, R., and T. Ernst, “Analysis of Multihoming in Mobile IPv6,” June 2005.). Also, as only one MNP is registered by the MR on two different home agents, two different routes to the MNP are available, via two home agents.
However the benefits we can get from such topology are interesting:
| TOC |
_ | _
CN|_|---| _ _____ |-|1|-|
|-|_|-| |-| |-
_ | |
_ | p1 __ |-|_|-| |-|
|_|-| <- | |-CoA1--| | | | _ |-
|------| | | | |-|2|-|
| <- |__|-CoA2--| _ | | |
p2 |-|_|-|_____|
LFN MR ARs Internet HAs Home Network
(1,2,2) Multihomed Mobile Network
The MR has two egress interfaces and advertises two NEMO-Prefixes on its ingress interface(s) to the mobile network. Each home agent are in in a different network. Both MRs' interfaces are in a foreign network. The MR has two home addresses and registers one HoA and one MNP per home agent. The LFNs can configure two IPv6 addresses, one from each MNP advertised in the mobile network. Each HA acts as the default gateway on its home link.
Each MR's egress interface has one HoA/CoA/MNP registered to one HA. If one of the MR's egress interface fails, both the MR and LFNs are not reachable anymore to the address built from the prefix that is related to this interface. If the MR does not redirect the flow from the failed egress interface to the other one, the LFNs' communications are broken and LFNs cannot reach the Internet anymore if they use the address built from the prefix associated to the failed interface as source address.
Two MNPs are advertised in the mobile network, thus LFNs can be multihomed. All packets go through one MR, so ingress filtering should not happen on the MR side. If the MR always sends the packets to the home agent which is related to the prefix that the source address is built from, no ingress filtering should happen on the HA side.
However, in case of failures and to keep transparency for the LFNs, The MR could redirect the packets to another active interface. In such a case, ingress filtering can occur at the home agent, which may drop packets with a source address different from what it is allowed to receive from the MR. Also, redirecting the packets from one interface to another would only recover one way of the communications, as the other way would still take the path via the failed interface. The MR could then move the tunnel endpoint from the failed interface to the active one: the active interface would have to manage two home addresses, and two tunnels to two different home agents.
In case of MR's interface failure, the LFN may have to change the source address it uses to send its datas. If so, all ongoing communications would be reset as TCP connections cannot survive to IP address change.
| TOC |
We will first test with both MRs in foreign networks:
_
CN|_|---| _ _____
|-|_|-| |
_ | |
| <-p1 ___ |-|_|-| |-|
_ |------|_1_|-CoA1--| | | | _ |-
|_|-| ___ | | |-|_|-|
|------|_2_|-CoA2--| _ | | |
<-p1 |-|_|-|_____|
LFN MRs ARs Internet HA Home Network
(2,1,1) Multihomed Mobile Network
both MRs in foreign networks
Each MR (MR1 and MR2) has one egress interface and advertises the same NEMO-Prefix p1 on the mobile network. When the HA receives a BU with a MNP that is already in binding cache from another MR, it creates a new entry in the binding cache. The home agent thus has two binding cache entries: one for HoA1/CoA1/p1, and one for HoA2/CoA2/p1. The HA acts as the default gateway on the home link.
Notes:
We will then test with one MR in a foreign network, and the second MR at home. The mobile router that is at home does not register to its home agent:
_
CN|_|---| _ _____
|-|_|-| |
_ | |
| <-p1 ___ |-|_|-| |-|
_ |------|_1_|-CoA1--| |_____| | _ |
|_|-| ___ |-|_|-|
|------|_2_|---------------------------|
<-p1
LFN MRs ARs Internet HA Home Network
(2,1,1) Multihomed Mobile Network
MR2 at home, MR1 in foreign network
Notes:
The LFN's default router is MR1 and HA forwards packets to the mobile network via MR1.
If MR1's egress interface fails, the home agent is able to route packets to the MNP via MR2. Once the binding cache entry and the routes relative to MR1 are deleted on the home agent, it is able to choose the other MR to reach the mobile network. If the implementation or the operating system cannot handle multiple routes to the same MNP, the HA may have to wait to receive a BU from MR2 to build a new route to the MNP. As the LFN still uses MR1 as default router, it cannot reach the Internet. In our case we configured MR1 to start sending router advertisements with a lifetime set to 0, to force the LFN to choose another default router.
If MR1's ingress fails, the LFN is able to change its default router, but the home agent may still use the failed MR as entry point of the mobile network.
If we shutdown MR1, or if both ingress and egress interfaces fails, the HA chooses MR2 to forward packets to the mobile network (once the binding cache entry and the routes relative to MR1 have been deleted) and the LFNs choose MR2 as default router. In this scenario, we can get a stable configuration without any manual operations.
If LFN's default router is MR1 and HA forwards packets to the mobile network via MR2, the path for the communication between a CN and a LFN is asymmetrical, but it does not bring any new issues to the previous cases.
We have first tested with a static route installed on the HA to the MNP via the MR that is at home. According to the implementation, the static route is preferred to the route installed by the mobility daemon via the MR that is in foreign network, or the contrary. This can raise several issues: if the static route is preferred, then if the MR that is at home fails, the MR in foreign network will never be used by the home agent as an entry point to the mobile network, unless we manually delete the static route on the home agent. If the route installed by the mobility daemon is preferred, then the mobile router that is at home will never be used as an entry point to the mobile network.
We then have tested using a routing protocol (RIPNG using the ZEBRA routing software) between the MR that is at home and the home agent. In that case, on both operating systems, the home agent prefers a route installed by the mobility daemon rather than a route installed by ZEBRA from RIPNG announces. Then, the mobile router that is in foreign network is always used as an entry point to the mobile network by the home agent. However, if that MR fails, the route installed from RIPNG announces is used and the mobile network can still be reachable by correspondents.
We then modified ZEBRA in order that the home agent prefers a route installed from RIPNG announces rather than from the mobility daemon. In that case, all the traffic to the mobile network is sent through the MR that is in its home network. If this MR fails, it takes some time before the HA uses the route installed by the mobility daemon: with RIPNG, routes are considered as expired once 180 seconds elapse from the last time the timeout was initialized. Then the route entry is still present in the routing table during 120 seconds with a metric set to 16 (infinity).
On the LFN side, it could be useful that it chooses the MR that is at home as default router. The MR in foreign network could advertise RA with a lifetime set to 0 or use ICMP redirects as long as the other MR is at home and alive. This would need some cooperation protocol between MRs.
Regarding to these tests, we can discuss about:
| TOC |
_
CN|_|---| _ _____
|-|_|-| |
_ | |
| <-p1 ___ |-|_|-| |-|
_ |------|_1_|-CoA1--| | | | _ |-
|_|-| ___ | | |-|_|-|
|------|_2_|-CoA2--| _ | | |
<-p2 |-|_|-|_____|
LFN MRs ARs Internet HA Home Network
(2,1,2) Multihomed Mobile Network
Each MR (MR1 and MR2) has one egress interface and advertises different NEMO-Prefixes p1 and p2 on the mobile network. The home agent has two binding cache entries: one for HoA1/CoA1/p1, and one for HoA2/CoA2/p2. The HA acts as the default gateway on the home link.
Notes:
First, the LFN uses the address built from the MNP p1 advertised by MR1 as source address, and uses MR1 as default router. If a CN communicates with the LFN using its address built from the MNP p1 as destination address, the communication is symmetric. But if a CN communicates with the LFN using its address built from the MNP p2 as destination address, the communication path is asymmetrical. Ingress filtering can occur on MR1 if it does not allow to forward packets whose source address is not built from the MNP p1.
When the ingress or egress interface fails on MR2:
One way for the CN to reach the LFN is to change the destination address, but the CN must be aware that the LFN is reachable via two addresses, and address change would break all ongoing TCP communications.
Another way is that the HA forwards all packets via the HA-MR1 tunnel. For this idea, the HA must be aware that MR1 and MR2 belong to the same mobile network. The HA must also be aware when one of MR2's interface fails: if MR2's egress interface fails, the binding cache entry on the HA will be deleted when its lifetime expires. But the HA has currently no way to know when MR2's ingress interface fails.
When the ingress interface fails on MR1:
If MR1's egress interface fails, the LFN cannot be aware of the failure and will go on using MR1 as default router. Thus the LFN is not reachable anymore to any of its addresses. One solution could be that MR1 advertises RA with a lifetime set to 0 or to send ICMP redirects to force the LFN to change its default router. Then LFN could be at least reachable on its address built from the prefix advertised by MR2.
Now, the LFN uses the address built from the MNP p1 advertised by MR1 as source address, and uses MR2 as default router.
Behavior will be basically the same as above, because instead of having two different entries in the binding cache and two routes towards a MR-HA tunnel, the home agent will have one entry in binding cache for MR1 that is in foreign network, one route to the MNP p1 towards the MR1-HA tunnel, and one route to the MNP p2 via MR2 created by a dynamic routing protocol. A mechanism for the home agent and the LFN to prefer the MR that is at home could be useful, as discussed in section 7.3. The mechanisms to reduce the MRs' failures seen in the case (2,1,1) can also apply here.
The LFN may use the address built from one of the prefix as a source address and use the MR that advertises the other prefix as default router. In this case we do not have ingress filtering issues on the HA because packets from the LFN are encapsulated by the MR and forwarded to the HA, and we only have one home agent for both MRs. However ingress filtering may happen on the mobile router if it filters the packets whose addresses are built from a prefix the MR is not configured to serve.
Communications between a LFN and a CN can be asymmetrical in some cases, regarding to the LFN's default router and the address it uses to communicate with a CN.
In case of one of the MR failure, if the home agent knows that both NEMO-prefixes are for the same mobile network, it can use the other MR to reach the mobile network. MR1 could advertise to the HA the NEMO-prefix that MR2 advertised (and conversely), so the HA would have two binding cache entries and routes for the same prefixes, and would be able to use a similar solution than for the (2,1,1) case.
With some policy mechanisms, the LFN could send packets with source address built from the MNP p1 to MR1, and packets with source address built from the MNP p2 to MR2. This could avoid ingress filtering issues at the MR and the LFN could always reach or be reachable to one of its address if one of the MR's interface fails.
In any cases, as raised in [3] (Ernst, T., “Analysis of Multihoming in Network Mobility Support,” February 2005.), section 4.3, if the LFN changes its source address it used to send packets, ongoing transport sessions without multihoming capabilities (such as TCP) are terminated.
| TOC |
_
CN|_|---| _ _____
|-|_|-| |
_ | |
| <-p1 ___ |-|_|-| |-| _
_ |------|_1_|-CoA1--| | | | _ |-|1|
|_|-| ___ | | |-|_|-| _
|------|_2_|-CoA2--| _ | | |-|2|
<-p1 |-|_|-|_____|
LFN MRs ARs Internet AR Home Network with 2 HAs
(2,2,1) Multihomed Mobile Network
Each MR (MR1 and MR2) has one egress interface and advertises the same NEMO-Prefix p1 on the mobile network. Registering the same MNP to two different home agents raise one issue: each HA has to advertise a route to the MNP, which is a problem if each HA is in a different domain. In this test we configure both HAs on the same home link. They do not act as a gateway to the Internet. Both HAs advertise a route to the MNP thanks to a dynamic routing protocol. The access router on the home link can then build a route to the MNP via one of the home agent.
If one of the MR's egress interface fails, the HA where the MR is registered will delete the corresponding binding cache entry once its lifetime has expired, and remove the route installed by the mobility daemon. As the HA is configured to announce kernel routes with the dynamic routing protocol, the route to the MNP will not be announced anymore. The AR will be able to change its default route to the MNP via the other HA if needed. Thus the mobile network will still be reachable. However, the LFN's default router may be the MR whose egress interface failed. The failed MR should then advertise RA with a lifetime set to 0 or send ICMP redirects when it detects a failure on its egress interface.
If one of the MR's ingress interface fails, the LFN will be able to choose the other MR as default router if needed. However, if all the traffic to the MNP is forwarded by the access router to the HA whose MR's ingress interface has failed, the mobile network will be unreachable from the Internet. So, the MR whose ingress interface has failed should deregister to its HA (at least as mobile router, but it can still act as a mobile host). The HA would thus delete the route to the MNP via the MR, and the same mechanism as above could apply.
If one MR is in its home network, and the other MR is in a foreign network, it may be better that all traffic goes through the MR that is at home. Both HAs will have a route to the same MNP:
If the HA that has both routes prefers the route built by the dynamic routing protocol to the one built by the mobility daemon, then whatever the AR chooses as next hop to the MNP, all traffic will go through the MR that is at home.
How do the both home agents will delegate the same prefix to different MRs? This is a prefix delegation issue. If we delegate a prefix to different MRs manually, they will face a problem when the MRs are split into different mobile networks.
| TOC |
_ | _
CN|_|---| _ _____ |-|1|-|
|-|_|-| |-| |-
_ | |
| <-p1 ___ |-|_|-| |-|
_ |------|_1_|-CoA1--| | | | _ |-
|_|-| ___ | | |-|2|-|
|------|_2_|-CoA2--| _ | | |
<-p2 |-|_|-|_____|
LFN MRs ARs Internet HAs Home Networks
(2,2,2) Multihomed Mobile Network
Each MR (MR1 and MR2) has one egress interface and advertises a different NEMO-Prefix on the mobile network. They register to a different home agent. Each home agent acts as the default gateway on its home link.
If each MR takes care of one prefix, and registers to a different HA, there is nothing to add about the problems we can face if we have ingress or egress interface failures on one MR. However, solutions to the problem are more complex since there are two HAs: for instance, one MR may have problem to register the other MR's MNP to the other HA (as suggested in section 8.3) due to access control and security issues.
As raised in [3] (Ernst, T., “Analysis of Multihoming in Network Mobility Support,” February 2005.), if one MR takes care of more than one prefix, problems issued from this configuration can be decomposed into problems from others cases, especially (2,1,2).
As raised in [3] (Ernst, T., “Analysis of Multihoming in Network Mobility Support,” February 2005.) section 4.3, when the two tunnels between MRs and HAs end at different home agents, and each HA registers a different NEMO-Prefix, ingress filtering may occur at the HA. According to [8] (Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, “Network Mobility (NEMO) Basic Support Protocol,” January 2005.) section 9, the HA must check whether the source address of the inner IPv6 header is a topologically correct address with respect to the IPv6 prefixes used in the mobile network. A solution to this problem could be source address switching on the LFN or nested tunnels, as described in [3] (Ernst, T., “Analysis of Multihoming in Network Mobility Support,” February 2005.) appendix B.
| TOC |
This document investigates the issues for practical deployment of NEMO basic support. It focuses on technical issues as well as implementation issues from multiple MRs, multiple HAs and multiple MNPs topologies. The tests we performed are work in progress. We are testing other cases and check if additional issues appear with the topologies presented in this document.
| TOC |
Added test cases (1,1,1), (1,1,2), (1,2,2), (2,2,1).
Updated test cases (1,2,1), (2,1,1), (2,1,2), (2,2,2).
Some tests now support Multiple Care-of Addresses registration.
Updated References list.
Editorial changes
Added some text about existing NEMO Basic Support implementations.
Updated References list.
| TOC |
| [1] | Ernst, T., “Network Mobility Support Goals and Requirements,” draft-ietf-nemo-requirements-04 (work in progress), February 2005. |
| [2] | Ernst, T. and H. Lach, “Network Mobility Support Terminology,” draft-ietf-nemo-terminology-03 (work in progress), February 2005. |
| [3] | Ernst, T., “Analysis of Multihoming in Network Mobility Support,” draft-ietf-nemo-multihoming-issues-02 (work in progress), February 2005. |
| [4] | Wakikawa, R., “Multiple Care-of Addresses Registration,” draft-wakikawa-mobileip-multiplecoa-04 (work in progress), June 2005. |
| [5] | Ernst, T., “Goals and Benefits of Multihoming,” draft-ernst-generic-goals-and-benefits-01 (work in progress), February 2005. |
| [6] | Thubert, P., Wakikawa, R., and V. Devarapalli, “NEMO Home Network models,” draft-ietf-nemo-home-network-models-04 (work in progress), June 2005. |
| [7] | Montavont, N., Wakikawa, R., and T. Ernst, “Analysis of Multihoming in Mobile IPv6,” draft-montavont-mobileip-multihoming-pb-statement-04 (work in progress), June 2005. |
| [8] | Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, “Network Mobility (NEMO) Basic Support Protocol,” RFC 3963, January 2005. |
| [9] | Manner, J. and M. Kojo, “Mobility Related Terminology,” RFC 3753, June 2004. |
| [10] | WIDE, “The Nautilus6 Project,” URL http://www.nautilus6.org, July 2005. |
| [11] | WIDE, “The KAME Project,” URL http://www.kame.net, July 2005. |
| [12] | IETF, “The NEMO Working Group,” URL http://www.ietf.org/html.charters/nemo-charter.html, July 2005. |
| [13] | Mitsuya, K., “Nautilus6 NEMO Basic Support implementation,” Implementation Report http://www.nautilus6.org/implementation/atlantis.html, July 2004. |
| [14] | WIDE, “The WIDE Project,” URL http://www.wide.ad.jp/, July 2005. |
| [15] | WIDE, “SHISA, an implementation of MIPv6/NEMO,” URL http://www.mobileip.jp/, July 2005. |
| [16] | Go-Core and Nautilus6, “NEPL, NEMO Platform for Linux,” URL http://www.mobile-ipv6.org/, July 2005. |
| [17] | Go-Core, “MIPL, Mobile IPv6 for Linux,” URL http://www.mobile-ipv6.org/, July 2005. |
| [18] | Kuntz, R., “NEMO Basic Support implementation tests at the 6th IPv6 TAHI Interoperability Test Event,” Interoperability tests report http://www.nautilus6.org/doc/tc-nemo-tahi-interop-20050207-KuntzR.txt, January 2005. |
| [19] | Ernst, T. and J. Charbon, “Multihoming with NEMO Basic Support,” Proceedings First International Conference on Mobile Computing and Ubiquitous Networking (ICMU), January 2004. |
| [20] | Lucian, S., Bonnin, J-M., Guillouard, K., and B. Stevant, “Towards a Highly Adaptable User-Centric Terminal Architecture,” Proceedings 7th International Symposium on Wireless Personal Multimedia Communication (WPMC04), September 2004. |
| TOC |
| Romain Kuntz | |
| WIDE at Keio University | |
| 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/ |
| Manabu Tsukada | |
| WIDE at Keio University | |
| 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/ |
| 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/ |
| Ernst Thierry | |
| WIDE at Keio University | |
| 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/ |
| Koshiro Mitsuya | |
| WIDE at Keio University | |
| 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: | mitsuya@sfc.wide.ad.jp |
| URI: | http://www.sfc.wide.ad.jp/~mitsuya/ |
| 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.