NEMO Working Group C. Ng
Internet-Draft Panasonic Singapore Labs
Expires: August 25, 2005 E. Paik
KT
T. Ernst
WIDE at Keio University
February 21, 2005
Analysis of Multihoming in Network Mobility Support
draft-ietf-nemo-multihoming-issues-02
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 August 25, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document is an analysis of multihoming in the context of network
mobility (NEMO). As there are many situations in which mobile
networks may be multihomed, a taxonomy is proposed to classify the
Ng, et al. Expires August 25, 2005 [Page 1]
Internet-Draft Analysis of Multihoming in NEMO February 2005
possible configurations. We also describe possible deployment
scenarios and we attempt to identify issues that arise when mobile
networks are multihomed while mobility supports is taken care by NEMO
Basic Support.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Classification . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1 (1,1,1): Single MR, Single HA, Single MNP . . . . . . . . 7
2.2 (1,1,n): Single MR, Single HA, Multiple MNPs . . . . . . . 7
2.3 (1,n,1): Single MR, Multiple HAs, Single MNP . . . . . . . 8
2.4 (1,n,n): Single MR, Multiple HAs, Multiple MNPs . . . . . 8
2.5 (n,1,1): Multiple MRs, Single HA, Single MNP . . . . . . . 9
2.6 (n,1,n): Multiple MRs, Single HA, Multiple MNPs . . . . . 9
2.7 (n,n,1): Multiple MRs, Multiple HAs, Single MNP . . . . . 10
2.8 (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs . . . . 10
3. Deployment Scenarios and Prerequisites . . . . . . . . . . . . 12
3.1 Deployment Scenarios . . . . . . . . . . . . . . . . . . . 12
3.2 Prerequisites . . . . . . . . . . . . . . . . . . . . . . 13
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 15
4.1 Path Survival . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Path Selection . . . . . . . . . . . . . . . . . . . . . . 15
4.3 Ingress Filtering . . . . . . . . . . . . . . . . . . . . 16
4.4 Failure Detection . . . . . . . . . . . . . . . . . . . . 18
4.5 Media Detection . . . . . . . . . . . . . . . . . . . . . 19
4.6 HA Synchronization . . . . . . . . . . . . . . . . . . . . 20
4.7 MR Synchronization . . . . . . . . . . . . . . . . . . . . 20
4.8 Prefix Delegation . . . . . . . . . . . . . . . . . . . . 21
4.9 Multiple Bindings/Registrations . . . . . . . . . . . . . 21
4.10 Source Address Selection . . . . . . . . . . . . . . . . . 21
4.11 Impact on the Routing Infrastructure . . . . . . . . . . . 22
4.12 Nested Mobile Networks . . . . . . . . . . . . . . . . . . 22
4.13 Split Mobile Networks . . . . . . . . . . . . . . . . . . 22
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26
A. Alternative Classifications Approach . . . . . . . . . . . . . 27
A.1 Ownership-Oriented Approach . . . . . . . . . . . . . . . 27
Ng, et al. Expires August 25, 2005 [Page 2]
Internet-Draft Analysis of Multihoming in NEMO February 2005
A.1.1 ISP Model . . . . . . . . . . . . . . . . . . . . . . 27
A.1.2 Subscriber/Provider Model . . . . . . . . . . . . . . 28
A.2 Problem-Oriented Approach . . . . . . . . . . . . . . . . 30
B. Nested Tunneling for Fault Tolerance . . . . . . . . . . . . . 31
B.1 Detecting Presence of Alternate Routes . . . . . . . . . . 31
B.2 Re-Establishment of Bi-Directional Tunnels . . . . . . . . 31
B.2.1 Using Alternate Egress Interface . . . . . . . . . . . 32
B.2.2 Using Alternate Mobile Router . . . . . . . . . . . . 32
B.3 To Avoid Tunneling Loop . . . . . . . . . . . . . . . . . 33
C. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . 36
Ng, et al. Expires August 25, 2005 [Page 3]
Internet-Draft Analysis of Multihoming in NEMO February 2005
1. Introduction
The design goals and objectives of Network Mobility Support (NEMO)
are identified in [1] while the terminology is being described in [2]
and [3]. NEMO Basic Support [4] is the solution proposed by the NEMO
Working Group to provide continuous Internet connectivity to nodes
located in a mobile network. This solutions 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], the solution for host mobility. NEMO Basic Support is
transparent to nodes located behind the mobile router (i.e. the
mobile network nodes, or MNNs) and as such doesn't 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 node.
Real-life scenarios as illustrated in [6] 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], 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]).. This arises either when a MR has multiple egress interfaces.
Using NEMO Basic Support, this translates into having multiple
bi-directional tunnels between the mobile network and its HA(s), and
may result into multiple MNPs being advertised 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 three-folds:
o to identify which multihoming configurations are useful,
o to identify issues that may prevent useful multihomed
configurations to be supported under the operation of NEMO Basic
Support. It doesn't mean that those not supported will not work
with NEMO Basic Support, just that it is up to the implementors to
make it work (hopefully issues discussed in this memo will be
helpful to these implementors).
For doing so, a taxonomy to classify the possible multihomed
Ng, et al. Expires August 25, 2005 [Page 4]
Internet-Draft Analysis of Multihoming in NEMO February 2005
configurations is described in Section 2. Deployment scenarios,
their benefits, and requirements to meet these benefits are
illustrated in Section 3. Following this, we study the general
issues in Section 4, and we conclude with an evaluation of NEMO Basic
Support for multihomed configurations. Alternative classifications
are outlined in the Appendix.
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] (section 3) and [3], Goals and Benefits
of Multihoming [6], Goals and Requirements of Network Mobility
Support [1], and the NEMO Basic Support specification [4]. Goals and
benefits for multihoming as discussed in [6] are applicable to fixed
nodes, mobile nodes, fixed networks and mobile networks.
This document considers multihoming only from the IPv6 point of view.
Ng, et al. Expires August 25, 2005 [Page 5]
Internet-Draft Analysis of Multihoming in NEMO February 2005
2. Classification
Various discussions on the topic of multihoming issues in NEMO have
been carried out on the mailing list and at IETF meetings. 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. Three approaches have been
proposed on the NEMO mailing list. These are, namely, (i) the
Configuration-Oriented Approach, (ii) the Ownership-Oriented
Approach, and (iii) the Problem-Oriented Approach. As the WG
consensus seems to have converged to the Configuration-Oriented
Approach, we only describe this approach here. The other two
approaches are outlined in Appendix A.1 and Appendix A.2.
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 advertised to the mobile network nodes, etc.
For doing so, we use three key parameters differentiating different
multihomed configurations. With these parameters, we can refer to
each configuration by the 3-tuple (x,y,z), where 'x', 'y', 'z' are
defined as follows:
o 'x' indicates the number of MRs where:
x=1 implies a mobile network has only a single MR, presumably
multihomed.
x=N implies a mobile network has more than one MR.
o 'y' indicates the number of HAs associated with the entire mobile
network, where:
y=1 implies that a single HA is assigned to the mobile network.
y=N implies that multiple HAs (possibly in different
administrative domains) are assigned to the mobile network.
o 'z' indicates the number of MNPs announced to MNNs, where:
z=1 implies that a single MNP is advertised to the MNNs.
z=N implies that multiple MNPs are advertised to the MNNs.
It can be seen that the above three parameters are fairly orthogonal
to one another. Thus different values of 'x', 'y' and 'z' give rise
to different combinations of the 3-tuple (x,y,z). As described in
the sub-sections below, a total of 8 possible configurations can be
Ng, et al. Expires August 25, 2005 [Page 6]
Internet-Draft Analysis of Multihoming in NEMO February 2005
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 advertised (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 a combination of Home Address / Care-of Address
pairs. Issues pertaining to a multihomed MR are also addressed in
the companion document [7].
A simplified analysis of multihoming configuration in NEMO Basic
Support using the same classification can be found in [8].
2.1 (1,1,1): Single MR, Single HA, Single MNP
The (1,1,1) mobile network has only one MR advertising a single MNP.
In addition, the MR is associated with only one HA at any one time.
A bi-directional tunnel may be established between each pair of Home
Address / Care-of address if the MR is itself multihomed.
The MR may be multihomed and MNNs are (usually) not multihomed since
they would configure a single address on the single MNP announced 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
2.2 (1,1,n): Single MR, Single HA, Multiple MNPs
The (1,1,n) mobile network has only one MR, which is associated to
only one HA at any one time. However, two or more MNPs are
advertised to the mobile network nodes.
The MR may be itself multihomed, and MNNs are multihomed if several
MNPs are advertised on the link they are attached to. If that
conditions holds, MNNs would configure an address with each MNP
announced on the link.
Ng, et al. Expires August 25, 2005 [Page 7]
Internet-Draft Analysis of Multihoming in NEMO February 2005
_____
_ p1,p2 _ | |
|_|-|<-_ |-|_|-| |-| _
_ |-|_|=| |_____| | _ |-|_|
|_|-| | |-|_|-|
|
MNNs MR AR Internet AR HA
Figure 2: (1,1,n): 1 MR, 1 HA, multiple MNPs
2.3 (1,n,1): Single MR, Multiple HAs, Single MNP
The (1,n,1) mobile network has only one MR advertising a single MNP.
The MR, however, is associated to multiple HAs, possibly one HA per
Home Address, or one HA per egress interface.
The MR may be multihomed whereas MNNs are (usually) not multihomed
since they would configure a single address on the single MNP
announced 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
2.4 (1,n,n): Single MR, Multiple HAs, Multiple MNPs
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 the MR advertises more than one MNP on
its ingress interfaces. No assumption is made on whether or not the
HAs belongs to the same administrative domain.
The MR may be multihomed, and the MNNs are generally multihomed since
they would configure an address on each MNP announced on the link
they are attached to.
Ng, et al. Expires August 25, 2005 [Page 8]
Internet-Draft Analysis of Multihoming in NEMO February 2005
AR HA2
_ | _
_____ |-|_|-|-|_|
_ p1,p2 _ | |-| |
|_|-|<-_ |-|_|-| | _
_ |-|_|=| |_____|-| _ |-|_|
|_|-| | |-|_|-|
| |
MNNs MR AR Internet AR HA1
Figure 4: (1,n,n): 1 MR, multiple HAs, multiple MNPs
2.5 (n,1,1): Multiple MRs, Single HA, Single MNP
The (n,1,1) mobile network has more than one MR advertising global
routes. These MRs, however, advertise the same MNP and are
associated with the same HA.
Each MR may be itself multihomed, whereas MNNs are (usually) not
multihomed since they would configure a single address on the single
MNP announced 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
2.6 (n,1,n): Multiple MRs, Single HA, Multiple MNPs
The (n,1,n) mobile network has more than one MR; multiple global
routes and different MNPs are advertised by the MRs.
Each MR may be itself multihomed, and MNNs are generally multihomed
since they would configure an address on each MNP announced on the
link they are attached to.
Ng, et al. Expires August 25, 2005 [Page 9]
Internet-Draft Analysis of Multihoming in NEMO February 2005
MR2
p2<-_ |
_ |-|_|-| _____
|_|-| |-| |
_ | | |-| _
|_|-| _ |-|_____| | _ |-|_|
|-|_|-| |-|_|-|
p1<- | |
MNNs MR1 Internet AR HA
Figure 6: (n,1,n): Multiple MRs, 1 HA, multiple MNPs
2.7 (n,n,1): Multiple MRs, Multiple HAs, Single MNP
The (n,n,1) mobile network has more than one MR advertising multiple
global routes. The mobile network is associated with multiple HAs at
any one time. No assumptions are made on whether or not the HAs
belongs to the same administrative domain. However, the MRs
advertises the same MNP.
Each MR may be itself multihomed whereas MNNs are (usually) not
multihomed since they would configure a single address on the single
MNP announced 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
2.8 (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs
The (n,n,n) mobile network has multiple MRs advertising different
global routes and different MNPs. The mobile network is associated
with more than one HA at any one time. No assumptions is made on
whether or not the HA belongs to the same administrative domain.
Each MR may be itself multihomed and MNNs are generally multihomed
Ng, et al. Expires August 25, 2005 [Page 10]
Internet-Draft Analysis of Multihoming in NEMO February 2005
since they would configure an address on each MNP announced 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
Ng, et al. Expires August 25, 2005 [Page 11]
Internet-Draft Analysis of Multihoming in NEMO February 2005
3. Deployment Scenarios and Prerequisites
The following generic goals and benefits of multihoming are discussed
in a companion document [6]:
1. Permanent and Ubiquitous Access
2. Redundancy/Fault-Recovery
3. Load Sharing
4. Load Balancing
5. Preference Settings
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.
3.1 Deployment Scenarios
x=1: Multihomed mobile network with a single MR
o Example: an MR with dual/multiple access interfaces (e.g.
802.11 and GPRS capabilities). This is a S/P-(1,1,*) if both
accesses are subscribed to the same ISP. If the two accesses
are offered by independent ISPs, this is a S/mP-(1,n,n) [for
the meaning of this abbreviation, see Appendix A.1].
Benefits: Ubiquity, Redundancy/Fault-Recovery, Load Sharing,
Preference Settings
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, Redundancy/Fault-Recovery, Ubiquity
o Example 2: W-PAN with a GPRS_enabled phone and a WiFi-enabled
PDA. This is a S/mP-(n,n,n) if the two access technologies are
subscribed separately.
Benefits: Ubiquity, Redundancy/Fault-Recovery, Preference
Settings
Ng, et al. Expires August 25, 2005 [Page 12]
Internet-Draft Analysis of Multihoming in NEMO February 2005
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)
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
3.2 Prerequisites
In this section, we try to define the requirements in order to
fulfill the expected multihoming benefits as detailed in [6].
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:
o Permanent and Ubiquitous Access:
At least one bi-directional tunnel must be available at any point
in time.
Ng, et al. Expires August 25, 2005 [Page 13]
Internet-Draft Analysis of Multihoming in NEMO February 2005
o Redundancy and Fault-Recovery:
Both the inbound and outbound traffic must be transmitted or
diverted over another bi-directional tunnel once a bi-directional
tunnel is broken or disrupted.
o Load Sharing and Load Balancing:
Multiple tunnels must be maintained simultaneously.
o Preference Settings:
Implicitly, multiple tunnels must be maintained simultaneously if
preferences are set for deciding which of the available
bi-directional tunnels should be used. A mechanism must be
provided to the user/application about the availability of
multiple bi-direction tunnels, and perhaps also to set the
preference. The preference may reside in the mobile router or
mobile network nodes (using [9] for instance).
Ng, et al. Expires August 25, 2005 [Page 14]
Internet-Draft Analysis of Multihoming in NEMO February 2005
4. Problem Statement
In order to meet the multihoming benefits, multiple tunnels may be
maintained simultaneously (e.g. load balancing, load sharing) or not
(e.g. redundancy) between the mobile network and the fixed network.
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 tunnel
(load sharing, load balancing).
For doing so, the issues discussed below must be addressed,
preferably dynamically. For each issue, we also investigate
potential ways to solve the problem and recommend which IETF WG(s)
should look into these issues.
4.1 Path Survival
Internet connectivity is guaranteed for all MNNs as long as at least
one bi-directional tunnel is maintained between the mobile network
and the fixed Internet. When an alternative tunnel must be found to
substitute for the failed one, the loss of one tunnel to the Internet
may result in broken sessions. In this case, new transport sessions
will have to be established over the alternate tunnel if no mechanism
is provided to make this change transparent at layers above layer 3.
The tunnel can be changed transparently to the MNNs if mechanisms
such as MMI [10] are brought to the MR.
For instance, in the (1,1,1) case specifically, packets are always
transmitted to/from the same MR's ingress interface, i.e.
independently of MR's links connectivity status.
This is a general problem faced by any node with multiple egress
paths. It is recommended that this issue be considered by other WGs
(such as IPv6, Multi6), and NEMO WG to contribute any NEMO specific
requirements.
4.2 Path Selection
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 bi-directional tunnel would be
selected, and based on which parameter (e.g. type of flow that goes
into/out of the mobile network).
Ng, et al. Expires August 25, 2005 [Page 15]
Internet-Draft Analysis of Multihoming in NEMO February 2005
A dynamic path selection mechanism is thus needed so that this path
could be selected by:
o The HA: it should be able to select the path based on some
information recorded in the binding cache.
o The MR: it should be able to select the path based on router
advertisements received on both its egress interfaces or on its
ingress interfaces for the (n,*,*) case.
o The MNN: it should be able to select the path based on "Default
Router Selection" (see [Section 6.3.6. Default Router Selection]
[11]) in the (n,*,*) case or based on "Source Address Selection"
in the (*,*,n) cases (see Section 4.10 of the present memo).
o The user or the application: e.g. in case where a user wants to
select a particular access technology among the available
technologies for reasons of cost or data rate.
o A combination of any of the above: a hybrid mechanism should be
also available, e.g. one in which the HA, the MR, and/or the MNNs
are coordinated to select the path.
This is a general problem faced by any node with multiple egress
paths. It is recommended that this issue be considered by other WGs
(such as IPv6, Multi6), and NEMO WG to contribute any NEMO specific
requirements.
4.3 Ingress Filtering
Ingress filtering mechanisms 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 home
agents. If 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 due to ingress filtering (either by
the home agent or by a border gateway in the home network).
As an example of how this could happen, consider the deployment
scenario illustrated in Figure 9. In Figure 9, the mobile network
has two mobile routers MR1 and MR2, with home agents HA1 and HA2
respectively. Two bi-directional tunnels are established are
established between the two pairs. Each mobile router advertises a
different MNP (P1 and P2). 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:
Ng, et al. Expires August 25, 2005 [Page 16]
Internet-Draft Analysis of Multihoming in NEMO February 2005
o If the two tunnels are available, MNN cannot forward packet with
source address equals P1.MNN to MR2. This would cause ingress
filtering at HA2 to occur (or even at MR2). This is contrary to
normal Neighbor Discovery [11] practice that an IPv6 node is free
to choose any router as its default router regardless of the
prefix it chooses to use. A simple solution is to require all
MNNs to set their default router to the MR that advertises the MNP
the MNNs configured their addresses from. If such requirement is
not placed on mobile network nodes, then a multihoming solution
for mobile networks must address this problem. For a possible
approach, see [12]. However, this is not enough to maintain
connectivity if a tunnel fails (see Section 4.1 for a discussion
of this issue).
o If the tunnel to HA1 is broken, packets would be sent through the
tunnel to HA1 are diverted through the tunnel to HA2. If HA2 (or
some border gateway in the domain of HA2) performs ingress
filtering, packets with source address configured from MNP P1 may
be discarded. It should be noted that this problem may be faced
by any (*,n,n) mobile network, even if MR1 and MR2 are in fact the
same entity in Figure 9.
To avoid ingress filtering mechanisms dropping packets in such
situations, MR(s) can stop advertising P1. This would prevent MNNs
from using the address auto-configured on this prefix. However, such
a method suffers from the following two limitations:
o Switching addresses is time consuming since nodes have to wait for
addresses to get deprecated [9].
o Switching addresses force transport sessions without multihoming
capabilities (such as TCP) to terminate, and be re-established
using the alternative source address. Transport sessions with
multihoming capabilities (such as SCTP) may be able to continue
without disruption (see also Section 4.1)
Although one way to avoid the long wait for address deprecation by
sending a router advertisement with zero Lifetime, the
termination/disruption of transport sessions may render this solution
unattractive. It is possible to overcome these limitations by using
nested tunnels. Appendix B describes one such approach.
Ng, et al. Expires August 25, 2005 [Page 17]
Internet-Draft Analysis of Multihoming in NEMO February 2005
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
It is recommended that the NEMO specific issue of ingress filtering
be tackled by the NEMO WG, either through the standardization of the
technique described in Appendix B, or by specifying a statement to
define the mobile router behavior with respect to fault recovery in
an (*,n,n) mobile network.
4.4 Failure Detection
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. In order for fault recovery to work, the
MRs and HAs must first possess a means to detect failures:
o On the MR's side, the MR can also rely on router advertisements
from access routers, or other layer-2 trigger mechanisms to detect
faults, e.g. [13] or [14]. (For a related issue, see
Section 4.5.)
o On the HA's side, it is more difficult for HAs to detect tunnel
failures. For an ISP deployment model, the HAs and MRs can use
proprietary methods (such as constant transmission of heartbeat
signals) to detect failures and check tunnel liveness. In the S/P
model (see Appendix A.2), a lack of standardized "tunnel liveness"
protocol means that it is harder to detect failures.
Ng, et al. Expires August 25, 2005 [Page 18]
Internet-Draft Analysis of Multihoming in NEMO February 2005
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.
There are other failure modes to consider as well, such as failure at
home agent, failure at access routers, or in general failure of a
link or node along the path from the mobile router to the home agent.
By the nature of the routing infrastructure, failure of intermediate
nodes or links are recovered by the the routing infrastructure by
choosing a different route. For those failures that can't be
receovered (such a failure of the access router), a heartbeat
protocol or the use of small-lifetime binding updates described above
can also be used to detect tunnel failures.
This is a general problem faced by all nodes communicating with a
peer. It is recommended that NEMO WG adopts any failure detection
mechansim standardized in the IETF, and, should the need arise,adapts
such mechanism specifically for detecting tunnel failures.
4.5 Media Detection
In order to achieve benefits such as ubiquity or fault recovery, it
is necessary for mobile router to detect the availability of network
media. This may be achieved using layer 2 triggers [13], or other
mechanism developed/recommended by the Detecting Network Attachment
(DNA) Working Group.
This is related to Section 4.4, since the ability to detect media
availability would often implies the ability to detect media
in-availability.
Ng, et al. Expires August 25, 2005 [Page 19]
Internet-Draft Analysis of Multihoming in NEMO February 2005
4.6 HA Synchronization
In the (*,n,1) mobile networks, a single MNP would be registered at
different HAs. This gives rise to the following issues:
o Only one HA may actively advertise a route to the MNP.
o Multiple HAs at different domains may advertise a route to the
same MNP
This may pose a problem in the routing infrastructure as a whole.
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 [15]
and [16]. 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 betweeen HAs. The mode of
synchoronization may be either primary-secondary or peer-to-peer.
See also Section 4.7.
This problem is general in the sense that Mobile IPv6 will have to
consider similar issues. It is recommended that the issue be looked
at in one of the Mobile IP WG, and NEMO WG to contribute any NEMO
specific requirements.
4.7 MR Synchronization
In the (n,*,*) mobile network, different MRs may need to be
synchronized in order to take common decisions. The mode of
synchoronization may be either primary-secondary or peer-to-peer.
This may include:
o In the (n,*,1) case, advertising the same MNP (see also "prefix
delegation" in Section 4.8).
o In the (n,*,n) case, a MR relaying the advertisement of the MNP
from another failed MR.
o In the (n,*,*) cases, relaying between MRs everything that needs
to be relayed, such as data packets, creating a tunnel from the
ingress interface, etc.
This problem is general in the sense that a multi-router site would
require the same level of router synchronization as well. It is
recommended that the issue be looked at in IPv6 or Multi6 WG, and
NEMO WG to contribute any NEMO specific requirements.
Ng, et al. Expires August 25, 2005 [Page 20]
Internet-Draft Analysis of Multihoming in NEMO February 2005
4.8 Prefix Delegation
In the (*,*,1) mobile network, the same MNP must be advertised to the
MNNs through different paths. This questions how to perform prefix
delegation:
o For the (*,n,1) mobile network, how multiple HAs would delegate
the same MNP to the mobile network. For doing so, the HAs may be
somehow configured to advertise the same MNP. (see also "HA
Synchronization" in Section 4.6).
o For the (n,*,n) mobile network, how multiple mobile routers would
be synchronized to advertise the same MNP down the NEMO-link. For
doing so, the MRs may be somehow configured to advertise the same
MNP (see also "MR Synchronization" in Section 4.7).
This could be configured manually, or dynamically. Alternatively,
prefix delegation mechanisms [17][18] could be used to ensure all
routers advertise the same MNP.
Prefix delegation is currently being explored in the NEMO WG. Should
the WG decides to standardize a prefix delegation mechanism, the WG
should also consider its application to a multihomed mobile network.
4.9 Multiple Bindings/Registrations
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 issue, since Mobile IPv6 nodes face a similar
problem if they wish to bind multiple Care-of Addresses to the same
Home Address". This is better discussed in [7]. It is sufficient to
note that solutions like [19] can solve this.
4.10 Source Address Selection
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.
It may be desirable for MNN to be able to acquire "preference"
information on each MNP from the MRs. This allows default address
selection mechanism such as that specified in [9] 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
Ng, et al. Expires August 25, 2005 [Page 21]
Internet-Draft Analysis of Multihoming in NEMO February 2005
prefixes. It is recommended that the issue be examined by other WG
(such as IPv6).
4.11 Impact on the Routing Infrastructure
In the (1,n,1) case with HAs located in distinct ISPs/ASs, multiple
routes directed to the mobile network may be advertised in the
Internet. Although this may provide shorter paths, it would add a
burden to routing tables as multiple routes to the same prefix are
injected into the routing infrastructure.
Such issues are investigated in the MULTI6 working group at the IETF,
and the NEMO WG should adopt solutions designed there whenever
appropriate.
4.12 Nested Mobile Networks
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 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 WG. It is recommended that the NEMO
WG standardizes a solution to solve this problem (such as the use of
a tree-spanning algorithm).
4.13 Split Mobile Networks
When a (n,*,1) network splits, (i.e. the two MRs split themselves
up), the only available MNP will then be registered by two different
MRs on different links. 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 [20].
This problem is specific to NEMO WG. It is recommended that the NEMO
WG standardizes a solution to solve this problem, or specifies that
the split of a (n,*,1) network cannot be allowed without a router
renumbering.
Ng, et al. Expires August 25, 2005 [Page 22]
Internet-Draft Analysis of Multihoming in NEMO February 2005
5. Conclusion
This document is an analysis of multihoming in the context of network
mobility. The purpose of this memo is to investigate issues related
to such a bi-directional tunneling mechanism when mobile networks are
multihomed.
Several issues that might impact the deployment of NEMO with
multihoming capabilities were identified in Section 4. They include
:
1. Path Survival
2. Path Availability
3. Ingress Filtering
4. Failure Detection
5. Media Detection
6. HA Synchronization
7. MR Synchronization
8. Prefix Delegation
9. Multiple Binding/Registrations
10. Source Address Selection
11. Imapct on the Routing Infrastructure
12. Nested Mobile Networks
13. Split Mobile Networks.
This study is a work in progress and need to be improved by a
thorough study of each individual issues. Particularly, this memo
should be completed by a thorough threat analysis of multihoming
configurations of mobile network. We will add security threat issues
here as and when they are encountered, such as those described in
[21]. We also encourage interested people to contribute to this
part.
Ng, et al. Expires August 25, 2005 [Page 23]
Internet-Draft Analysis of Multihoming in NEMO February 2005
6. Acknowledgments
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.
Sincere gratitude is also extended to Marcelo Bagnulo Braun for his
extensive review and comments on the -00 version of this draft. The
initial evaluation of NEMO Basic Support is a contribution from
Julien Charbon.
7. References
[1] Ernst, T., "Network Mobility Support Goals and Requirements",
Internet-Draft draft-ietf-nemo-requirements-04, February 2005.
[2] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[3] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
Internet-Draft draft-ietf-nemo-terminology-03, February 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.
[6] Ernst, T., Montavont, N. and R. Wakikawa, "Goals and Benefits
of Multihoming",
Internet-Draft draft-ernst-generic-goals-and-benefits-01,
February 2005.
[7] Montavont, N., Wakikawa, R. and T. Ernst, "Analysis of
Multihoming in Mobile IPv6",
Internet-Draft draft-montavont-mobileip-multihoming-pb-statement-03
, January 2005.
[8] Ernst, T. and J. Charbon, "Multihoming with NEMO Basic
Support", Proceedings First International Conference on Mobile
Computing and Ubiquitous Networking (ICMU), January 2004.
[9] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003.
[10] Montavont, N., Noel, T. and M. Kassi-Lahlou, "MIPv6 for
Multiple Interfaces",
Ng, et al. Expires August 25, 2005 [Page 24]
Internet-Draft Analysis of Multihoming in NEMO February 2005
Internet-Draft draft-montavont-mobileip-mmi-00, July 2002.
[11] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[12] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes",
Internet-Draft draft-ietf-ipv6-router-selection-06, October
2004.
[13] Yegin, A., "Link-layer Hints for Detecting Network
Attachments", Internet-Draft draft-yegin-dna-l2-hints-01,
February 2004.
[14] Yegin, A., "Supporting Optimized Handover for IP Mobility
-Requirements for Underlying Systems",
Internet-Draft draft-manyfolks-l2-mobilereq-02, July 2002.
[15] Wakikawa, R., Devarapalli, V. and P. Thubert, "Inter Home
Agents Protocol (HAHA)",
Internet-Draft draft-wakikawa-mip6-nemo-haha-01, February 2004.
[16] Koh, B., Ng, C. and J. Hirano, "Dynamic Inter Home Agent
Protocol", Internet-Draft draft-koh-mip6-nemo-dhap-00, July
2004.
[17] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix
Delegation", RFC 3769, June 2004.
[18] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO",
Internet-Draft draft-droms-nemo-dhcpv6-pd-01, February 2004.
[19] Wakikawa, R., Uehara, K., Ernst, T. and K. Nagami, "Multiple
Care-of Addresses Registration",
Internet-Draft draft-wakikawa-mobileip-multiplecoa-04, February
2005.
[20] Kumazawa, M., "Token based Duplicate Network Detection for
split mobile network (Token based DND)",
Internet-Draft draft-kumazawa-nemo-tbdnd-01, October 2004.
[21] Choi, S., "Threat for Multi-homed Mobile Networks",
Internet-Draft draft-cho-nemo-threat-multihoming-00, February
2004.
Ng, et al. Expires August 25, 2005 [Page 25]
Internet-Draft Analysis of Multihoming in NEMO February 2005
Authors' Addresses
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: cwng@psl.com.sg
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
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/
Ng, et al. Expires August 25, 2005 [Page 26]
Internet-Draft Analysis of Multihoming in NEMO February 2005
Appendix A. Alternative Classifications Approach
A.1 Ownership-Oriented Approach
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'.
A.1.1 ISP Model
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
Ng, et al. Expires August 25, 2005 [Page 27]
Internet-Draft Analysis of Multihoming in NEMO February 2005
secondary role when compared to Binding Update messages.
A.1.2 Subscriber/Provider Model
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:
o S/P-(1,1,1): Single Provider, Single MR, Single HA, Single MNP
o S/P-(1,1,n): Single Provider, Single MR, Single HA, Multiple MNPs
o S/P-(1,n,1): Single Provider, Single MR, Multiple HAs, Single MNP
o S/P-(1,n,n): Single Provider, Single MR, Multiple HAs, Multiple
MNPs
o S/P-(n,n,1): Single Provider, Multiple MRs, Single HA, Single MNP
o S/P-(n,1,n): Single Provider, Multiple MRs, Single HA, Multiple
MNPs
o S/P-(n,n,1): Single Provider, Multiple MRs, Multiple HAs, Single
MNP
o S/P-(n,n,n): Single Provider, Multiple MRs, Multiple HAs, Multiple
MNPs
For the S/mP model, the following configurations are likely to be
deployed:
o S/mP-(1,n,1): Multiple Providers, Single MR, Multiple HAs, Single
Ng, et al. Expires August 25, 2005 [Page 28]
Internet-Draft Analysis of Multihoming in NEMO February 2005
MNP
o S/mP-(1,n,n): Multiple Providers, Single MR, Multiple HAs,
Multiple MNPs
o S/mP-(n,n,n): Multiple Providers, Multiple MRs, Multiple HAs,
Multiple MNPs
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.
Ng, et al. Expires August 25, 2005 [Page 29]
Internet-Draft Analysis of Multihoming in NEMO February 2005
A.2 Problem-Oriented Approach
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:
o Tarzan: Single HA for Different Care-of Addresses of Same MNP
This is the case where one mobile router registers different
Care-of Addresses to the same home agent for the same subnet
prefix. This is equivalent to the case of y=1, i.e. the (1,1,*)
mobile network.
o JetSet: Multiple HAs for Different Care-of Addresses of Same MNP
This is the case where the mobile router registers different
Care-of Addresses to different home agents for the same subnet
prefix. This is equivalent to the case of y=n, i.e. the (1,n,*)
mobile network.
o Shinkansen: Single MNP Advertised by MR(s)
This is the case where one MNP is announced by different MRs.
This is equivalent to the case of x=n and z=1, i.e. the (n,*,1)
mobile network.
o DoubleBed: Multiple MNPs Advertised by MR(s)
This is the case where more than one MNPs are announced by the
different MRs. This is equivalent to the case of x=n and z=n,
i.e. the (n,*,n) mobile network.
Ng, et al. Expires August 25, 2005 [Page 30]
Internet-Draft Analysis of Multihoming in NEMO February 2005
Appendix B. Nested Tunneling for Fault Tolerance
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 section, we will attempt to investigate
methods of performing such re-establishment of bi-directional
tunnels. It is not the objective of this memo 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] and Neighbor
Discovery in IPv6 [11].
B.1 Detecting Presence of Alternate Routes
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.
B.2 Re-Establishment of Bi-Directional Tunnels
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
Ng, et al. Expires August 25, 2005 [Page 31]
Internet-Draft Analysis of Multihoming in NEMO February 2005
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.
B.2.1 Using Alternate Egress Interface
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.
B.2.2 Using Alternate Mobile Router
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.
Ng, et al. Expires August 25, 2005 [Page 32]
Internet-Draft Analysis of Multihoming in NEMO February 2005
B.3 To Avoid Tunneling Loop
The method of re-establishing the bi-directional tunnel as described
in Appendix B.2 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).
Ng, et al. Expires August 25, 2005 [Page 33]
Internet-Draft Analysis of Multihoming in NEMO February 2005
Appendix C. Change Log
o This draft is an update of draft-ng-nemo-multihoming-issues-03.txt
which is itself a merge of 3 previous drafts
draft-ng-nemo-multihoming-issues-02.txt,
draft-eun-nemo-multihoming-problem-statement-00.txt, and
draft-charbon-nemo-multihoming-evaluation-00.txt
o Changes from draft-ietf-nemo-multihoming-issues-01 to -02:
* Added recommendations/suggestion of which WG each issue should
be addressed as pointed out in 61st IETF.
* Minor updates on references.
o Changes from draft-ietf-nemo-multihoming-issues-00 to -01:
* Replaced NEMO-Prefix with MNP as decided by the WG at 60th IETF
* Addressed Issue #1 in Section 1: Added a note to remind readers
that IPv6 is implicitly assumed
* Addressed Issue #3 in Section 2.3: Removed text on assumption
* Addressed Issue #6 in Section 3.1: Added benefits
* Addressed Issue #7 in Section 3.2: Modified text
* Addressed Issue #9 in Section 4.3: Modified text
* Addressed Issue #10 in Section 4.4: Added paragraph on other
failure modes
* Addressed Issue #10: New Section 4.5 on media detection
* Addressed Issue #11 in Section 4.11: modified text
o Changes from draft-ng-multihoming-issues-03 to
draft-ietf-nemo-multihoming-issues-00:
* Expanded "Problem Statement" (Section 4)
* Merged "Evaluation" Section into "Problem Statement"
(Section 4)
* Cleaned up description in "Classification" (Section 2), and
clearly indicate in each classification, what are the
multihomed entities
Ng, et al. Expires August 25, 2005 [Page 34]
Internet-Draft Analysis of Multihoming in NEMO February 2005
* Re-organized "Deployment Scenarios and Prerequisites"
(Section 3), and created the "Prerequisites" sub-section.
o Changes from draft-ng-multihoming-issues-02 to
draft-ng-multihoming-issues-03:
* Merged with draft-eun-nemo-multihoming-problem-statement (see
"Problem Statement" (Section 4))
* Included conclusions from
draft-charbon-nemo-multihoming-evaluation-00
* Re-organized some part of "Benefits/Issues of Multhoming in
NEMO" to "Problem Statement" (Section 4)
* Removed lots of text to be in sync with [6].
* Title changed from "Multihoming Issues in NEMO Basic Support"
to "Analysis of Multihoming in NEMO"
* Changed (w,x,y) to (x,y,z) in taxonomy.
* Moved alternative approaches of classification to Appendix
* Creation of this Change-Log itself ;-)
Ng, et al. Expires August 25, 2005 [Page 35]
Internet-Draft Analysis of Multihoming in NEMO February 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Ng, et al. Expires August 25, 2005 [Page 36]
