draft-ietf-nemo-multihoming-issues-01.txt   draft-ietf-nemo-multihoming-issues-02.txt 
NEMO Working Group C. Ng NEMO Working Group C. Ng
Internet-Draft Panasonic Singapore Labs Internet-Draft Panasonic Singapore Labs
Expires: April 25, 2005 E. Paik Expires: August 25, 2005 E. Paik
KT KT
T. Ernst T. Ernst
WIDE at Keio University WIDE at Keio University
October 25, 2004 February 21, 2005
Analysis of Multihoming in Network Mobility Support Analysis of Multihoming in Network Mobility Support
draft-ietf-nemo-multihoming-issues-01 draft-ietf-nemo-multihoming-issues-02
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 25, 2005. This Internet-Draft will expire on August 25, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document is an analysis of multihoming in the context of network This document is an analysis of multihoming in the context of network
mobility (NEMO). As there are many situations in which mobile mobility (NEMO). As there are many situations in which mobile
networks may be multihomed, a taxonomy is proposed to classify the networks may be multihomed, a taxonomy is proposed to classify the
possible configurations. We also describe possible deployment possible configurations. We also describe possible deployment
scenarios and we attempt to identify issues that arise when mobile scenarios and we attempt to identify issues that arise when mobile
networks are multihomed while mobility supports is taken care by NEMO networks are multihomed while mobility supports is taken care by NEMO
Basic Support. Basic Support.
skipping to change at page 2, line 32 skipping to change at page 2, line 33
3. Deployment Scenarios and Prerequisites . . . . . . . . . . . . 12 3. Deployment Scenarios and Prerequisites . . . . . . . . . . . . 12
3.1 Deployment Scenarios . . . . . . . . . . . . . . . . . . . 12 3.1 Deployment Scenarios . . . . . . . . . . . . . . . . . . . 12
3.2 Prerequisites . . . . . . . . . . . . . . . . . . . . . . 13 3.2 Prerequisites . . . . . . . . . . . . . . . . . . . . . . 13
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 15 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 15
4.1 Path Survival . . . . . . . . . . . . . . . . . . . . . . 15 4.1 Path Survival . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Path Selection . . . . . . . . . . . . . . . . . . . . . . 15 4.2 Path Selection . . . . . . . . . . . . . . . . . . . . . . 15
4.3 Ingress Filtering . . . . . . . . . . . . . . . . . . . . 16 4.3 Ingress Filtering . . . . . . . . . . . . . . . . . . . . 16
4.4 Failure Detection . . . . . . . . . . . . . . . . . . . . 18 4.4 Failure Detection . . . . . . . . . . . . . . . . . . . . 18
4.5 Media Detection . . . . . . . . . . . . . . . . . . . . . 19 4.5 Media Detection . . . . . . . . . . . . . . . . . . . . . 19
4.6 HA Synchronization . . . . . . . . . . . . . . . . . . . . 19 4.6 HA Synchronization . . . . . . . . . . . . . . . . . . . . 20
4.7 MR Synchronization . . . . . . . . . . . . . . . . . . . . 19 4.7 MR Synchronization . . . . . . . . . . . . . . . . . . . . 20
4.8 Prefix Delegation . . . . . . . . . . . . . . . . . . . . 20 4.8 Prefix Delegation . . . . . . . . . . . . . . . . . . . . 21
4.9 Multiple Bindings/Registrations . . . . . . . . . . . . . 20 4.9 Multiple Bindings/Registrations . . . . . . . . . . . . . 21
4.10 Source Address Selection . . . . . . . . . . . . . . . . . 20 4.10 Source Address Selection . . . . . . . . . . . . . . . . . 21
4.11 Impact on the Routing Infrastructure . . . . . . . . . . . 21 4.11 Impact on the Routing Infrastructure . . . . . . . . . . . 22
4.12 Nested Mobile Networks . . . . . . . . . . . . . . . . . . 21 4.12 Nested Mobile Networks . . . . . . . . . . . . . . . . . . 22
4.13 Split Mobile Networks . . . . . . . . . . . . . . . . . . 21 4.13 Split Mobile Networks . . . . . . . . . . . . . . . . . . 22
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26
A. Alternative Classifications Approach . . . . . . . . . . . . . 26 A. Alternative Classifications Approach . . . . . . . . . . . . . 27
A.1 Ownership-Oriented Approach . . . . . . . . . . . . . . . 26 A.1 Ownership-Oriented Approach . . . . . . . . . . . . . . . 27
A.1.1 ISP Model . . . . . . . . . . . . . . . . . . . . . . 26 A.1.1 ISP Model . . . . . . . . . . . . . . . . . . . . . . 27
A.1.2 Subscriber/Provider Model . . . . . . . . . . . . . . 27 A.1.2 Subscriber/Provider Model . . . . . . . . . . . . . . 28
A.2 Problem-Oriented Approach . . . . . . . . . . . . . . . . 29 A.2 Problem-Oriented Approach . . . . . . . . . . . . . . . . 30
B. Nested Tunneling for Fault Tolerance . . . . . . . . . . . . . 30 B. Nested Tunneling for Fault Tolerance . . . . . . . . . . . . . 31
B.1 Detecting Presence of Alternate Routes . . . . . . . . . . 30 B.1 Detecting Presence of Alternate Routes . . . . . . . . . . 31
B.2 Re-Establishment of Bi-Directional Tunnels . . . . . . . . 30 B.2 Re-Establishment of Bi-Directional Tunnels . . . . . . . . 31
B.2.1 Using Alternate Egress Interface . . . . . . . . . . . 31 B.2.1 Using Alternate Egress Interface . . . . . . . . . . . 32
B.2.2 Using Alternate Mobile Router . . . . . . . . . . . . 31 B.2.2 Using Alternate Mobile Router . . . . . . . . . . . . 32
B.3 To Avoid Tunneling Loop . . . . . . . . . . . . . . . . . 32 B.3 To Avoid Tunneling Loop . . . . . . . . . . . . . . . . . 33
C. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 33 C. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . 35 Intellectual Property and Copyright Statements . . . . . . . . 36
1. Introduction 1. Introduction
The goals and objectives of Network Mobility Support (NEMO) are The design goals and objectives of Network Mobility Support (NEMO)
identified in [1] while the terminology is being described in [2] and are identified in [1] while the terminology is being described in [2]
[3]. NEMO Basic Support [4] is the solution proposed by the NEMO and [3]. NEMO Basic Support [4] is the solution proposed by the NEMO
Working Group to provide continuous Internet connectivity to nodes Working Group to provide continuous Internet connectivity to nodes
located in a mobile network. This solutions basically solves the located in a mobile network. This solutions basically solves the
problem by setting up bi-directional tunnels between the mobile problem by setting up bi-directional tunnels between the mobile
routers (MRs) connecting the mobile network to the Internet and their routers (MRs) connecting the mobile network to the Internet and their
respective Home Agents (HAs), much how this is done in Mobile IPv6 respective Home Agents (HAs), much how this is done in Mobile IPv6
[5], the solution for host mobility. NEMO Basic Support is [5], the solution for host mobility. NEMO Basic Support is
transparent to nodes located behind the mobile router (i.e. the transparent to nodes located behind the mobile router (i.e. the
mobile network nodes, or MNNs) and as such doesn't require MNNs to mobile network nodes, or MNNs) and as such doesn't require MNNs to
take any action in the mobility management. take any action in the mobility management.
We note that mobile networks are typically connected by means of However, mobile networks are typically connected by means of wireless
wireless and thus less reliable links. In addition, there could be and thus less reliable links; there could also be many nodes behind
many nodes behind the MR, so a loss of connectivity or a failure to the MR. A loss of connectivity or a failure to connect to the
connect to the Internet has a more significant impact than for a Internet has thus a more significant impact than for a single node.
single node. Real-life scenarios as illustrated in [6] demonstrate Real-life scenarios as illustrated in [6] demonstrate that providing
that providing a permanent access to mobile networks such as vehicles a permanent access to mobile networks such as vehicles typically
typically require the use of several interfaces and technologies require the use of several interfaces and technologies since the
since the mobile network may be moving in distant geographical mobile network may be moving in distant geographical locations where
locations where different access technologies are provided and different access technologies are provided and governed by distinct
governed by distinct access control policies. access control policies.
The purpose of this memo is to investigate issues related to such a
bi-directional tunneling mechanism when mobile networks are
multihomed, i.e. when there is more than one point of attachment
between the mobile network and the Internet. This arises either when
a MR has multiple egress interfaces, or the mobile network has
multiple MRs or is associated with multiple HAs, or multiple prefixes
are advertised down to the mobile network (see definitions in [3]).
As specified by R.12 in section 5 of [1], the NEMO WG must ensure 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 that NEMO Basic Support does not prevent mobile networks to be
multihomed. Using NEMO Basic Support, this translates into having multihomed, i.e. when there is more than one point of attachment
multiple bi-directional tunnels between the mobile network and its between the mobile network and the Internet (see definitions in
HA(s), and may result into multiple MNPs being advertised to the [3]).. This arises either when a MR has multiple egress interfaces.
MNNs. However, NEMO Basic Support does not specify any particular Using NEMO Basic Support, this translates into having multiple
mechanism to manage multiple bi-directional tunnels. The objective bi-directional tunnels between the mobile network and its HA(s), and
of this memo is thus three-folds: may result into multiple MNPs being advertised to the MNNs. However,
NEMO Basic Support does not specify any particular mechanism to
o to capture issues for deploying a multihomed mobile network, 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 which multihoming configurations are useful,
o to identify issues that may prevent useful multihomed o to identify issues that may prevent useful multihomed
configurations to be supported under the operation of NEMO Basic configurations to be supported under the operation of NEMO Basic
Support. It doesn't mean that those not supported will not work 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 with NEMO Basic Support, just that it is up to the implementors to
make it work (hopefully issues discussed in this memo will be make it work (hopefully issues discussed in this memo will be
helpful to these implementors). helpful to these implementors).
skipping to change at page 5, line 22 skipping to change at page 5, line 15
their benefits, and requirements to meet these benefits are their benefits, and requirements to meet these benefits are
illustrated in Section 3. Following this, we study the general illustrated in Section 3. Following this, we study the general
issues in Section 4, and we conclude with an evaluation of NEMO Basic issues in Section 4, and we conclude with an evaluation of NEMO Basic
Support for multihomed configurations. Alternative classifications Support for multihomed configurations. Alternative classifications
are outlined in the Appendix. are outlined in the Appendix.
In order to understand this memo, the reader is expected to be In order to understand this memo, the reader is expected to be
familiar with the above cited documents, i.e. with the NEMO familiar with the above cited documents, i.e. with the NEMO
terminology as defined in [2] (section 3) and [3], Goals and Benefits terminology as defined in [2] (section 3) and [3], Goals and Benefits
of Multihoming [6], Goals and Requirements of Network Mobility of Multihoming [6], Goals and Requirements of Network Mobility
Support [1], and the NEMO Basic Support specification [4]. The Support [1], and the NEMO Basic Support specification [4]. Goals and
readers are reminded when describing the issues, we implicitly have benefits for multihoming as discussed in [6] are applicable to fixed
an IPv6 environment in mind (as NEMO Basic Support [4] is for IPv6), nodes, mobile nodes, fixed networks and mobile networks.
though some of the issues are independent of IP version.
Note that goals and benefits for multihoming as discussed in [6] is This document considers multihoming only from the IPv6 point of view.
applicable to fixed nodes, mobile nodes, fixed networks and mobile
networks, so we won't re-state the motivations in the present memo.
2. Classification 2. Classification
Various discussions on the topic of multihoming issues in NEMO have Various discussions on the topic of multihoming issues in NEMO have
been carried out on the mailing list and at IETF meetings. As there been carried out on the mailing list and at IETF meetings. As there
are several configurations in which mobile networks are multihomed, are several configurations in which mobile networks are multihomed,
there is a need to classify them into a clearly defined taxonomy. there is a need to classify them into a clearly defined taxonomy.
This can be done in various ways. Three approaches have been This can be done in various ways. Three approaches have been
proposed on the NEMO mailing list. These are, namely, (i) the proposed on the NEMO mailing list. These are, namely, (i) the
Configuration-Oriented Approach, (ii) the Ownership-Oriented Configuration-Oriented Approach, (ii) the Ownership-Oriented
skipping to change at page 7, line 8 skipping to change at page 7, line 8
z=N implies that multiple MNPs are 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 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 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 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 the sub-sections below, a total of 8 possible configurations can be
identified. identified.
One thing the reader has to keep in mind is that in each of the 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 following 8 cases, the MR may be multihomed if either (i) multiple
prefixes are advertised on the home link, (ii) multiple prefixes are prefixes are advertised (on the home link, or on the visited link),
advertised on the visited link, or (iii) the MR is equipped with or (ii) the MR is equipped with multiple interfaces. In such a case,
multiple interfaces. In such a case, the MR would have a combination the MR would have a combination of Home Address / Care-of Address
of Home Address / Care-of Address pairs. Issues pertaining to a pairs. Issues pertaining to a multihomed MR are also addressed in
multihomed MR are also addressed in the companion document [7]. the companion document [7].
A simplified analysis of multihoming configuration in NEMO Basic A simplified analysis of multihoming configuration in NEMO Basic
Support using the same classification can be found in [8]. Support using the same classification can be found in [8].
2.1 (1,1,1): Single MR, Single HA, Single MNP 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. 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. 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 A bi-directional tunnel may be established between each pair of Home
Address / Care-of address if the MR is itself multihomed. Address / Care-of address if the MR is itself multihomed.
skipping to change at page 9, line 41 skipping to change at page 9, line 41
_ | | |-| _ _ | | |-| _
|_|-| _ |-|_____| | _ |-|_| |_|-| _ |-|_____| | _ |-|_|
|-|_|-| |-|_|-| |-|_|-| |-|_|-|
p<- | | p<- | |
MNNs MR1 Internet AR HA MNNs MR1 Internet AR HA
Figure 5: (n,1,1): Multiple MRs, 1 HA, 1 MNP Figure 5: (n,1,1): Multiple MRs, 1 HA, 1 MNP
2.6 (n,1,n): Multiple MRs, Single HA, Multiple MNPs 2.6 (n,1,n): Multiple MRs, Single HA, Multiple MNPs
The (n,1,n) mobile network has more than one MR advertising different The (n,1,n) mobile network has more than one MR; multiple global
global routes and different MNPs. However, these MRs are associated routes and different MNPs are advertised by the MRs.
to the same HA.
Each MR may be itself multihomed, and MNNs are generally multihomed Each MR may be itself multihomed, and MNNs are generally multihomed
since they would configure an address on each MNP announced on the since they would configure an address on each MNP announced on the
link they are attached to. link they are attached to.
MR2 MR2
p2<-_ | p2<-_ |
_ |-|_|-| _____ _ |-|_|-| _____
|_|-| |-| | |_|-| |-| |
_ | | |-| _ _ | | |-| _
|_|-| _ |-|_____| | _ |-|_| |_|-| _ |-|_____| | _ |-|_|
|-|_|-| |-|_|-| |-|_|-| |-|_|-|
p1<- | | p1<- | |
MNNs MR1 Internet AR HA MNNs MR1 Internet AR HA
Figure 6: (n,1,n): Multiple MRs, 1 HA, multiple MNPs Figure 6: (n,1,n): Multiple MRs, 1 HA, multiple MNPs
2.7 (n,n,1): Multiple MRs, Multiple HAs, Single MNP 2.7 (n,n,1): Multiple MRs, Multiple HAs, Single MNP
The (n,n,1) mobile network has more than one MR advertising different The (n,n,1) mobile network has more than one MR advertising multiple
global routes. The mobile network is associated with multiple HAs at global routes. The mobile network is associated with multiple HAs at
any one time. No assumptions are made on whether or not the HAs any one time. No assumptions are made on whether or not the HAs
belongs to the same administrative domain. However, the MRs belongs to the same administrative domain. However, the MRs
advertises the same MNP. advertises the same MNP.
Each MR may be itself multihomed whereas MNNs are (usually) not Each MR may be itself multihomed whereas MNNs are (usually) not
multihomed since they would configure a single address on the single multihomed since they would configure a single address on the single
MNP announced on the link they are attached to. MNP announced on the link they are attached to.
MR2 AR HA2 MR2 AR HA2
skipping to change at page 12, line 41 skipping to change at page 12, line 41
are offered by independent ISPs, this is a S/mP-(1,n,n) [for are offered by independent ISPs, this is a S/mP-(1,n,n) [for
the meaning of this abbreviation, see Appendix A.1]. the meaning of this abbreviation, see Appendix A.1].
Benefits: Ubiquity, Redundancy/Fault-Recovery, Load Sharing, Benefits: Ubiquity, Redundancy/Fault-Recovery, Load Sharing,
Preference Settings Preference Settings
x=N: Multihomed mobile networks with multiple MRs x=N: Multihomed mobile networks with multiple MRs
o Example 1: a train with one MR in each car, all served by the 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 same HA, thus a (n,1,*). Alternatively, the train company
might be forced to use different ISP when the train go to might be forced to use different ISPs when the train go to
different locations, thus it is a (n,n,n). different locations, thus it is a (n,n,n).
Benefits: Load Sharing, Redundancy/Fault-Recovery, Ubiquity Benefits: Load Sharing, Redundancy/Fault-Recovery, Ubiquity
o Example 2: W-PAN with a GPRS_enabled phone and a WiFi-enabled 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 PDA. This is a S/mP-(n,n,n) if the two access technologies are
subscribed separately. subscribed separately.
Benefits: Ubiquity, Redundancy/Fault-Recovery, Preference Benefits: Ubiquity, Redundancy/Fault-Recovery, Preference
Settings Settings
skipping to change at page 13, line 15 skipping to change at page 13, line 15
o Most single ISP cases in above examples. o Most single ISP cases in above examples.
y=N: Multihomed mobile networks with multiple HAs y=N: Multihomed mobile networks with multiple HAs
o Most multiple ISP cases in above examples. o Most multiple ISP cases in above examples.
o Example: a transatlantic flight with a HA in each continent. o Example: a transatlantic flight with a HA in each continent.
This is a (1,n,1) network if there is only one MR. This is a (1,n,1) network if there is only one MR.
Benefits: Ubiquity (reduced delay, shortest path) Benefits: Ubiquity, Preferences (reduced delay, shortest path)
z=1: Multihomed mobile networks with a single MNP z=1: Multihomed mobile networks with a single MNP
o Most single ISP cases in above examples. o Most single ISP cases in above examples.
z=N: Multihomed mobile networks with multiple MNPs z=N: Multihomed mobile networks with multiple MNPs
o Most multiple ISP cases in above examples. o Most multiple ISP cases in above examples.
o Example: a car with a prefix taken from home (personal traffic 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 transit on this prefix and is paid by the owner) and one that
belongs to the car manufacturer (maintenance traffic is paid by belongs to the car manufacturer (maintenance traffic is paid by
the car-manufacturer). This will typically be a (1,1,n). the car-manufacturer). This will typically be a (1,1,n) or a
(1,n,n,).
Benefits: preference settings Benefits: Preference Settings
3.2 Prerequisites 3.2 Prerequisites
In this section, we try to define the requirements in order to In this section, we try to define the requirements in order to
fulfill the expected multihoming benefits as detailed in [6]. fulfill the expected multihoming benefits as detailed in [6].
At least one bi-directional tunnel must be available at any point in 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 time between the mobile network and the fixed network to meet all
expectations. But for most goals to be effective, multiple tunnels expectations. But for most goals to be effective, multiple tunnels
must be maintained simultaneously: must be maintained simultaneously:
skipping to change at page 15, line 7 skipping to change at page 15, line 7
Implicitly, multiple tunnels must be maintained simultaneously if Implicitly, multiple tunnels must be maintained simultaneously if
preferences are set for deciding which of the available preferences are set for deciding which of the available
bi-directional tunnels should be used. A mechanism must be bi-directional tunnels should be used. A mechanism must be
provided to the user/application about the availability of provided to the user/application about the availability of
multiple bi-direction tunnels, and perhaps also to set the multiple bi-direction tunnels, and perhaps also to set the
preference. The preference may reside in the mobile router or preference. The preference may reside in the mobile router or
mobile network nodes (using [9] for instance). mobile network nodes (using [9] for instance).
4. Problem Statement 4. Problem Statement
In order to reach the multihoming benefits, multiple tunnels may be In order to meet the multihoming benefits, multiple tunnels may be
maintained simultaneously (e.g. load balancing, load sharing) or not maintained simultaneously (e.g. load balancing, load sharing) or not
(e.g. redundancy) between the mobile network and the fixed network. (e.g. redundancy) between the mobile network and the fixed network.
In some cases, it may be necessary to divert packets from a (perhaps In some cases, it may be necessary to divert packets from a (perhaps
failed) bi-directional tunnel to an alternative (perhaps newly failed) bi-directional tunnel to an alternative (perhaps newly
established) bi-directional tunnel (i.e. for matters of fault established) bi-directional tunnel (i.e. for matters of fault
recovery, preferences), or to split traffic between multiple tunnel recovery, preferences), or to split traffic between multiple tunnel
(load sharing, load balancing). (load sharing, load balancing).
For doing so, the issues discussed below must be addressed, For doing so, the issues discussed below must be addressed,
preferably dynamically. For each issue, we also investigate preferably dynamically. For each issue, we also investigate
potential ways to solve the problem. potential ways to solve the problem and recommend which IETF WG(s)
should look into these issues.
4.1 Path Survival 4.1 Path Survival
Internet connectivity is guaranteed for all MNNs as long as at least Internet connectivity is guaranteed for all MNNs as long as at least
one bi-directional tunnel is maintained between the mobile network one bi-directional tunnel is maintained between the mobile network
and the fixed Internet. When an alternative tunnel must be found to 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 substitute for the failed one, the loss of one tunnel to the Internet
may result in broken sessions. In this case, new transport sessions may result in broken sessions. In this case, new transport sessions
will have to be established over the alternate tunnel if no mechanism will have to be established over the alternate tunnel if no mechanism
is provided to make this change transparent at layers above layer 3. is provided to make this change transparent at layers above layer 3.
In the (1,1,1) case specifically, packets are always transmitted The tunnel can be changed transparently to the MNNs if mechanisms
to/from the same MR's ingress interface, i.e. independently of MR's such as MMI [10] are brought to the MR.
links connectivity status. The tunnel can be changed transparently
to the MNNs if mechanisms such as those studied in [10] are brought For instance, in the (1,1,1) case specifically, packets are always
to the MR. 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 4.2 Path Selection
When multiple bi-directional tunnels are available and possibly used When multiple bi-directional tunnels are available and possibly used
simultaneously, the mode of operation may be either primary-secondary simultaneously, the mode of operation may be either primary-secondary
(one tunnel is precedent over the others and used as the default (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, 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 tunnel has precedence over one another, they are used with the same
priority). This questions which bi-directional tunnel would be priority). This questions which bi-directional tunnel would be
selected, and based on which parameter (e.g. type of flow that goes selected, and based on which parameter (e.g. type of flow that goes
skipping to change at page 16, line 22 skipping to change at page 16, line 28
in the (*,*,n) cases (see Section 4.10 of the present memo). 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 o The user or the application: e.g. in case where a user wants to
select a particular access technology among the available select a particular access technology among the available
technologies for reasons of cost or data rate. technologies for reasons of cost or data rate.
o A combination of any of the above: a hybrid mechanism should be 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 also available, e.g. one in which the HA, the MR, and/or the MNNs
are coordinated to select the path. 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 4.3 Ingress Filtering
Ingress filtering mechanisms may drop the outgoing packets when Ingress filtering mechanisms may drop the outgoing packets when
multiple bi-directional tunnels end up at different HAs. This could multiple bi-directional tunnels end up at different HAs. This could
occur if different MNPs are handled by different home agents. If particularly occur if different MNPs are handled by different home
packet with a source address configured from a specific MNP is agents. If packet with a source address configured from a specific
tunnelled to a home agent that does not handle that specific MNP, the MNP is tunnelled to a home agent that does not handle that specific
packet may be discarded due to ingress filtering (either by the home MNP the packet may be discarded due to ingress filtering (either by
agent or by a border gateway in the home network). the home agent or by a border gateway in the home network).
As an example of how this could happen, consider the deployment As an example of how this could happen, consider the deployment
scenario illustrated in Figure 9. In Figure 9, the mobile network scenario illustrated in Figure 9. In Figure 9, the mobile network
has two mobile routers MR1 and MR2, with home agents HA1 and HA2 has two mobile routers MR1 and MR2, with home agents HA1 and HA2
respectively. Two bi-directional tunnels are established are respectively. Two bi-directional tunnels are established are
established between the two pairs. Each mobile router advertises a established between the two pairs. Each mobile router advertises a
different MNP (P1 and P2). MNP P1 is registered to HA1, and MNP P2 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 is registered to HA2. Thus, MNNs should be free to auto-configure
their addresses on any of P1 or P2. Ingress filtering could thus their addresses on any of P1 or P2. Ingress filtering could thus
happen in two cases: happen in two cases:
skipping to change at page 18, line 5 skipping to change at page 18, line 17
| +-----+ +----+ | | +-----+ | +-----+ +----+ | | +-----+
IP: +-----+ | | | Prefix: P1 IP: +-----+ | | | Prefix: P1
P1.MNN or | MNN |--+ | Internet | P1.MNN or | MNN |--+ | Internet |
P2.MNN +-----+ | | | Prefix: P2 P2.MNN +-----+ | | | Prefix: P2
| +-----+ +----+ | | +-----+ | +-----+ +----+ | | +-----+
+--| MR2 |--| AR |--| |---| HA2 | +--| MR2 |--| AR |--| |---| HA2 |
Prefix: P2 +-----+ +----+ +----------+ +-----+ Prefix: P2 +-----+ +----+ +----------+ +-----+
Figure 9: An (n,n,n) mobile network 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 4.4 Failure Detection
It is expected for faults to occur more readily at the edge of the 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 network (i.e. the mobile nodes), due to the use of wireless
connections. Efficient fault detection mechanisms are necessary to connections. Efficient fault detection mechanisms are necessary to
recover in timely fashion. In order for fault recovery to work, the recover in timely fashion. In order for fault recovery to work, the
MRs and HAs must first possess a means to detect failures: 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 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 from access routers, or other layer-2 trigger mechanisms to detect
faults, e.g. [13] or [14]. (For a related issue, see Section faults, e.g. [13] or [14]. (For a related issue, see
4.5.) Section 4.5.)
o On the HA's side, it is more difficult for HAs to detect tunnel 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 failures. For an ISP deployment model, the HAs and MRs can use
proprietary methods (such as constant transmission of heartbeat proprietary methods (such as constant transmission of heartbeat
signals) to detect failures and check tunnel liveness. In the S/P signals) to detect failures and check tunnel liveness. In the S/P
model (see Appendix A.2), a lack of standardized "tunnel liveness" model (see Appendix A.2), a lack of standardized "tunnel liveness"
protocol means that it is harder to detect failures. protocol means that it is harder to detect failures.
A possible method is for the MRs to send binding updates more A possible method is for the MRs to send binding updates more
regularly with shorter Lifetime values. Similarly, HAs can return regularly with shorter Lifetime values. Similarly, HAs can return
skipping to change at page 18, line 40 skipping to change at page 19, line 20
however may lead to more traffic and processing overhead, since however may lead to more traffic and processing overhead, since
binding updates sent to HAs must be protected (and possibly binding updates sent to HAs must be protected (and possibly
encrypted) with security associations. encrypted) with security associations.
There are other failure modes to consider as well, such as failure at 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 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. link or node along the path from the mobile router to the home agent.
By the nature of the routing infrastructure, failure of intermediate By the nature of the routing infrastructure, failure of intermediate
nodes or links are recovered by the the routing infrastructure by nodes or links are recovered by the the routing infrastructure by
choosing a different route. For those failures that can't be choosing a different route. For those failures that can't be
receovered (such a failure of the access router), a heartbeadt receovered (such a failure of the access router), a heartbeat
protocol or the use of small-lifetime binding updates described above protocol or the use of small-lifetime binding updates described above
can also be used to detect tunnel failures. 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 4.5 Media Detection
In order to achieve benefits such as ubiquity or fault recovery, it In order to achieve benefits such as ubiquity or fault recovery, it
is necessary for mobile router to detect the availability of network is necessary for mobile router to detect the availability of network
media. This may be achieved using layer 2 triggers [13], or other media. This may be achieved using layer 2 triggers [13], or other
mechanism developed/recommended by the Detecting Network Attachment mechanism developed/recommended by the Detecting Network Attachment
(DNA) Working Group. (DNA) Working Group.
This is related to Section 4.4, since the ability to detect media This is related to Section 4.4, since the ability to detect media
availability would often implies the ability to detect media availability would often implies the ability to detect media
skipping to change at page 19, line 38 skipping to change at page 20, line 26
The implications of this aspect needs further exploration. Certain The implications of this aspect needs further exploration. Certain
level of HA co-ordination may be required. A possible approach is to level of HA co-ordination may be required. A possible approach is to
adopt a HA synchronization mechanism such as that described in [15] adopt a HA synchronization mechanism such as that described in [15]
and [16]. Such synchronization might also be necessary in a (*,n,*) and [16]. Such synchronization might also be necessary in a (*,n,*)
mobile network, when a MR sends binding update messages to only one mobile network, when a MR sends binding update messages to only one
HA (instead of all HAs). In such cases, the binding update HA (instead of all HAs). In such cases, the binding update
information might have to be synchronized betweeen HAs. The mode of information might have to be synchronized betweeen HAs. The mode of
synchoronization may be either primary-secondary or peer-to-peer. synchoronization may be either primary-secondary or peer-to-peer.
See also Section 4.7. 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 4.7 MR Synchronization
In the (n,*,*) mobile network, different MRs may need to be In the (n,*,*) mobile network, different MRs may need to be
synchronized in order to take common decisions. The mode of synchronized in order to take common decisions. The mode of
synchoronization may be either primary-secondary or peer-to-peer. synchoronization may be either primary-secondary or peer-to-peer.
This may include: This may include:
o In the (n,*,1) case, advertising the same MNP (see also "prefix o In the (n,*,1) case, advertising the same MNP (see also "prefix
delegation" in Section 4.8). delegation" in Section 4.8).
o In the (n,*,n) case, a MR relaying the advertisement of the MNP o In the (n,*,n) case, a MR relaying the advertisement of the MNP
from another failed MR. from another failed MR.
o In the (n,*,*) cases, relaying between MRs everything that needs o In the (n,*,*) cases, relaying between MRs everything that needs
to be relayed, such as data packets, creating a tunnel from the to be relayed, such as data packets, creating a tunnel from the
ingress interface, etc. 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.
4.8 Prefix Delegation 4.8 Prefix Delegation
In the (*,*,1) mobile network, the same MNP must be advertised to the In the (*,*,1) mobile network, the same MNP must be advertised to the
MNNs through different paths. This questions how to perform prefix MNNs through different paths. This questions how to perform prefix
delegation: delegation:
o For the (*,n,1) mobile network, how multiple HAs would delegate 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 the same MNP to the mobile network. For doing so, the HAs may be
somehow configured to advertise the same MNP. (see also "HA somehow configured to advertise the same MNP. (see also "HA
Synchronization" in Section 4.6). Synchronization" in Section 4.6).
o For the (n,*,n) mobile network, how multiple mobile routers would o For the (n,*,n) mobile network, how multiple mobile routers would
be synchronized to advertise the same MNP down the NEMO-link. For be synchronized to advertise the same MNP down the NEMO-link. For
doing so, the MRs may be somehow configured to advertise the same doing so, the MRs may be somehow configured to advertise the same
MNP (see also "MR Synchronization" in Section 4.7). MNP (see also "MR Synchronization" in Section 4.7).
This could be configured manually, or dynamically. Alternatively, This could be configured manually, or dynamically. Alternatively,
prefix delegation mechanisms [17][18] could be used to ensure all prefix delegation mechanisms [17][18] could be used to ensure all
routers advertise the same MNP. 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 4.9 Multiple Bindings/Registrations
When a MR is configured with multiple Care-of Addresses, it is often 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. 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 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 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 Home Address". This is better discussed in [7]. It is sufficient to
note that solutions like [19] can solve this. note that solutions like [19] can solve this.
skipping to change at page 21, line 5 skipping to change at page 21, line 52
multiple addresses. Source address selection mechanisms are needed multiple addresses. Source address selection mechanisms are needed
to decide which address to choose from. to decide which address to choose from.
It may be desirable for MNN to be able to acquire "preference" It may be desirable for MNN to be able to acquire "preference"
information on each MNP from the MRs. This allows default address information on each MNP from the MRs. This allows default address
selection mechanism such as that specified in [9] to be used. selection mechanism such as that specified in [9] to be used.
Further exploration on setting such "preference" information in Further exploration on setting such "preference" information in
Router Advertisement based on performance of the bi-directional Router Advertisement based on performance of the bi-directional
tunnel might prove to be useful. tunnel might prove to be useful.
This is a general issue faced by any node when offered multiple
prefixes. It is recommended that the issue be examined by other WG
(such as IPv6).
4.11 Impact on the Routing Infrastructure 4.11 Impact on the Routing Infrastructure
In the (1,n,1) case with HAs located in distinct ISPs/ASs, multiple 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 routes directed to the mobile network may be advertised in the
Internet. Although this may provide shorter paths, it also adds Internet. Although this may provide shorter paths, it would add a
burden to routing tables as multiple routes to the same prefix are burden to routing tables as multiple routes to the same prefix are
injected into the routing infrastructure. Such issues are injected into the routing infrastructure.
investigated in the MULTI6 working group at the IETF.
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 4.12 Nested Mobile Networks
When a multihomed mobile network is nested within another mobile When a multihomed mobile network is nested within another mobile
network, it can result in very complex topologies. For instance, a network, it can result in very complex topologies. For instance, a
nested mobile network may be attached two different root-MRs, thus nested mobile network may be attached two different root-MRs, thus
the aggregated network no longer forms a simple tree structure. As the aggregated network no longer forms a simple tree structure. As
such, a solution to prevent an infinite loop must be provided. 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 4.13 Split Mobile Networks
When a (n,*,1) network splits, (i.e. the two MRs split themselves 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 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 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 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 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 either be forcibly removed from one (or all) MRs, or the implementors
must not allow a (n,*,1) network to split. must not allow a (n,*,1) network to split.
A possible approach to solving this problem is described in [20]. 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.
5. Conclusion 5. Conclusion
This document is an analysis of multihoming in the context of network This document is an analysis of multihoming in the context of network
mobility. The purpose of this memo is to investigate issues related mobility. The purpose of this memo is to investigate issues related
to such a bi-directional tunneling mechanism when mobile networks are to such a bi-directional tunneling mechanism when mobile networks are
multihomed. multihomed.
Several issues that might impact the deployment of NEMO with Several issues that might impact the deployment of NEMO with
multihoming capabilities were identified in Section 4. They include: multihoming capabilities were identified in Section 4. They include
:
1. Path Survival 1. Path Survival
2. Path Availability 2. Path Availability
3. Ingress Filtering 3. Ingress Filtering
4. Failure Detection 4. Failure Detection
5. Media Detection 5. Media Detection
skipping to change at page 23, line 9 skipping to change at page 24, line 9
should be completed by a thorough threat analysis of multihoming should be completed by a thorough threat analysis of multihoming
configurations of mobile network. We will add security threat issues configurations of mobile network. We will add security threat issues
here as and when they are encountered, such as those described in here as and when they are encountered, such as those described in
[21]. We also encourage interested people to contribute to this [21]. We also encourage interested people to contribute to this
part. part.
6. Acknowledgments 6. Acknowledgments
The authors would like to thank people who have given valuable The authors would like to thank people who have given valuable
comments on various multihoming issues on the mailing list, and also comments on various multihoming issues on the mailing list, and also
those who have suggested directions in the 56th - 60th IETF Meetings. those who have suggested directions in the 56th - 61st IETF Meetings.
Sincere gratitude is also extended to Marcelo Bagnulo Braun for his Sincere gratitude is also extended to Marcelo Bagnulo Braun for his
extensive review and comments on the -00 version of this draft. The extensive review and comments on the -00 version of this draft. The
initial evaluation of NEMO Basic Support is a contribution from initial evaluation of NEMO Basic Support is a contribution from
Julien Charbon. Julien Charbon.
7 References 7. References
[1] Ernst, T., "Network Mobility Support Goals and Requirements", [1] Ernst, T., "Network Mobility Support Goals and Requirements",
draft-ietf-nemo-requirements-03 (work in progress), October Internet-Draft draft-ietf-nemo-requirements-04, February 2005.
2004.
[2] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC [2] Manner, J. and M. Kojo, "Mobility Related Terminology",
3753, June 2004. RFC 3753, June 2004.
[3] Ernst, T. and H. Lach, "Network Mobility Support Terminology", [3] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-02 (work in progress), October Internet-Draft draft-ietf-nemo-terminology-03, February 2005.
2004.
[4] Devarapalli, V., "Network Mobility (NEMO) Basic Support [4] Devarapalli, V., Wakikawa, R., Petrescu, A. and P. Thubert,
Protocol", draft-ietf-nemo-basic-support-03 (work in progress), "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
June 2004. January 2005.
[5] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in [5] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[6] Ernst, T., Montavont, N., Wakikawa, R. and E-K. Paik, "Goals [6] Ernst, T., Montavont, N. and R. Wakikawa, "Goals and Benefits
and Benefits of Multihoming", of Multihoming",
draft-ernst-generic-goals-and-benefits-00 (work in progress), Internet-Draft draft-ernst-generic-goals-and-benefits-01,
July 2004. February 2005.
[7] Montavont, N., Wakikawa, R. and T. Ernst, "Analysis of [7] Montavont, N., Wakikawa, R. and T. Ernst, "Analysis of
Multihoming in Mobile IPv6", Multihoming in Mobile IPv6",
draft-montavont-mobileip-multihoming-pb-statement-01 (work in , January 2005.
progress), Feb 2004.
[8] Ernst, T. and J. Charbon, "Multihoming with NEMO Basic [8] Ernst, T. and J. Charbon, "Multihoming with NEMO Basic
Support", Proceedings First International Conference on Mobile Support", Proceedings First International Conference on Mobile
Computing and Ubiquitous Networking (ICMU), January 2004. Computing and Ubiquitous Networking (ICMU), January 2004.
[9] Draves, R., "Default Address Selection for Internet Protocol [9] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003. version 6 (IPv6)", RFC 3484, February 2003.
[10] Montavont, N., Noel, T. and M. Kassi-Lahlou, "MIPv6 for [10] Montavont, N., Noel, T. and M. Kassi-Lahlou, "MIPv6 for
Multiple Interfaces", draft-montavont-mobileip-mmi-02 (work in Multiple Interfaces",
progress), October 2003. Internet-Draft draft-montavont-mobileip-mmi-00, July 2002.
[11] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery [11] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998. for IP Version 6 (IPv6)", RFC 2461, December 1998.
[12] Draves, R. and D. Thaler, "Default Router Preferences and [12] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", draft-ietf-ipv6-router-selection-06 More-Specific Routes",
(work in progress), October 2004. Internet-Draft draft-ietf-ipv6-router-selection-06, October
2004.
[13] Yegin, A., "Link-layer Hints for Detecting Network [13] Yegin, A., "Link-layer Hints for Detecting Network
Attachments", draft-yegin-dna-l2-hints-01 (work in progress), Attachments", Internet-Draft draft-yegin-dna-l2-hints-01,
February 2004. February 2004.
[14] Yegin, A., "Supporting Optimized Handover for IP Mobility [14] Yegin, A., "Supporting Optimized Handover for IP Mobility
-Requirements for Underlying Systems", -Requirements for Underlying Systems",
draft-manyfolks-l2-mobilereq-02 (work in progress), July 2002. Internet-Draft draft-manyfolks-l2-mobilereq-02, July 2002.
[15] Wakikawa, R., Devarapalli, V. and P. Thubert, "Inter Home [15] Wakikawa, R., Devarapalli, V. and P. Thubert, "Inter Home
Agents Protocol (HAHA)", draft-wakikawa-mip6-nemo-haha-01 (work Agents Protocol (HAHA)",
in progress), February 2004. Internet-Draft draft-wakikawa-mip6-nemo-haha-01, February 2004.
[16] Koh, B., Ng, C. and J. Hirano, "Dynamic Inter Home Agent [16] Koh, B., Ng, C. and J. Hirano, "Dynamic Inter Home Agent
Protocol", draft-koh-mip6-nemo-dhap-00 (work in progress), July Protocol", Internet-Draft draft-koh-mip6-nemo-dhap-00, July
2004. 2004.
[17] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix [17] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix
Delegation", RFC 3769, June 2004. Delegation", RFC 3769, June 2004.
[18] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO", [18] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO",
draft-droms-nemo-dhcpv6-pd-01 (work in progress), February Internet-Draft draft-droms-nemo-dhcpv6-pd-01, February 2004.
2004.
[19] Wakikawa, R., "Multiple Care-of Addresses Registration", [19] Wakikawa, R., Uehara, K., Ernst, T. and K. Nagami, "Multiple
draft-wakikawa-mobileip-multiplecoa-03 (work in progress), July Care-of Addresses Registration",
2004. Internet-Draft draft-wakikawa-mobileip-multiplecoa-04, February
2005.
[20] Kumazawa, M., "Token based Duplicate Network Detection for [20] Kumazawa, M., "Token based Duplicate Network Detection for
split mobile network (Token based DND)", split mobile network (Token based DND)",
draft-kumazawa-nemo-tbdnd-01 (work in progress), October 2004. Internet-Draft draft-kumazawa-nemo-tbdnd-01, October 2004.
[21] Choi, S., "Threat for Multi-homed Mobile Networks", [21] Choi, S., "Threat for Multi-homed Mobile Networks",
draft-cho-nemo-threat-multihoming-00 (work in progress), Internet-Draft draft-cho-nemo-threat-multihoming-00, February
February 2004. 2004.
Authors' Addresses Authors' Addresses
Chan-Wah Ng Chan-Wah Ng
Panasonic Singapore Laboratories Pte Ltd Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #06-3530 Blk 1022 Tai Seng Ave #06-3530
Tai Seng Industrial Estate Tai Seng Industrial Estate
Singapore 534415 Singapore 534415
SG SG
Phone: +65 65505420 Phone: +65 65505420
EMail: cwng@psl.com.sg Email: cwng@psl.com.sg
Eun Kyoung Paik Eun Kyoung Paik
KT KT
Portable Internet Team, Convergence Lab., KT Portable Internet Team, Convergence Lab., KT
17 Woomyeon-dong, Seocho-gu 17 Woomyeon-dong, Seocho-gu
Seoul 137-792 Seoul 137-792
Korea Korea
Phone: +82-2-526-5233 Phone: +82-2-526-5233
Fax: +82-2-526-5200 Fax: +82-2-526-5200
EMail: euna@kt.co.kr Email: euna@kt.co.kr
URI: http://mmlab.snu.ac.kr/~eun/ URI: http://mmlab.snu.ac.kr/~eun/
Thierry Ernst Thierry Ernst
WIDE at Keio University WIDE at Keio University
Jun Murai Lab., Keio University. Jun Murai Lab., Keio University.
K-square Town Campus, 1488-8 Ogura, Saiwa-Ku K-square Town Campus, 1488-8 Ogura, Saiwa-Ku
Kawasaki, Kanagawa 212-0054 Kawasaki, Kanagawa 212-0054
Japan Japan
Phone: +81-44-580-1600 Phone: +81-44-580-1600
Fax: +81-44-580-1437 Fax: +81-44-580-1437
EMail: ernst@sfc.wide.ad.jp Email: ernst@sfc.wide.ad.jp
URI: http://www.sfc.wide.ad.jp/~ernst/ URI: http://www.sfc.wide.ad.jp/~ernst/
Appendix A. Alternative Classifications Approach Appendix A. Alternative Classifications Approach
A.1 Ownership-Oriented Approach A.1 Ownership-Oriented Approach
An alternative approach to classifying multihomed mobile network is An alternative approach to classifying multihomed mobile network is
proposed by Erik Nordmark (Sun Microsystems) by breaking the proposed by Erik Nordmark (Sun Microsystems) by breaking the
classification of multihomed network based on ownership. This is classification of multihomed network based on ownership. This is
more of a tree-like top-down classification. Starting from the more of a tree-like top-down classification. Starting from the
skipping to change at page 29, line 19 skipping to change at page 30, line 19
configuration or ownership. With this approach, there is a set of 4 configuration or ownership. With this approach, there is a set of 4
categories based on two orthogonal parameters: the number of HAs, and categories based on two orthogonal parameters: the number of HAs, and
the number of MNPs advertised. Since the two parameters are the number of MNPs advertised. Since the two parameters are
orthogonal, the categories are not mutually exclusive. The four orthogonal, the categories are not mutually exclusive. The four
categories are: categories are:
o Tarzan: Single HA for Different Care-of Addresses of Same MNP o Tarzan: Single HA for Different Care-of Addresses of Same MNP
This is the case where one mobile router registers different This is the case where one mobile router registers different
Care-of Addresses to the same home agent for the same subnet 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,n) prefix. This is equivalent to the case of y=1, i.e. the (1,1,*)
mobile network. mobile network.
o JetSet: Multiple HAs for Different Care-of Addresses of Same MNP o JetSet: Multiple HAs for Different Care-of Addresses of Same MNP
This is the case where the mobile router registers different This is the case where the mobile router registers different
Care-of Addresses to different home agents for the same subnet 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,*) prefix. This is equivalent to the case of y=n, i.e. the (1,n,*)
mobile network. mobile network.
o Shinkansen: Single MNP Advertised by MR(s) o Shinkansen: Single MNP Advertised by MR(s)
This is the case where one MNP is announced by different MRs. This is the case where one MNP is announced by different MRs.
This is equivalent to the case of z=n, i.e. the (1,*,n) mobile This is equivalent to the case of x=n and z=1, i.e. the (n,*,1)
network. mobile network.
o DoubleBed: Multiple MNPs Advertised by MR(s) o DoubleBed: Multiple MNPs Advertised by MR(s)
This is the case where more than one MNPs are announced by the This is the case where more than one MNPs are announced by the
different MRs. This is equivalent to the case of z=n, i.e. the different MRs. This is equivalent to the case of x=n and z=n,
(n,*,n) mobile network. i.e. the (n,*,n) mobile network.
Appendix B. Nested Tunneling for Fault Tolerance Appendix B. Nested Tunneling for Fault Tolerance
In order to utilize the additional robustness provided by In order to utilize the additional robustness provided by
multihoming, MRs that employ bi-directional tunneling with their HAs multihoming, MRs that employ bi-directional tunneling with their HAs
should dynamically change their tunnel exit points depending on the should dynamically change their tunnel exit points depending on the
link status. For instance, if a MR detects that one of its egress 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 interface is down, it should detect if any other alternate route to
the global Internet exists. This alternate route may be provided by the global Internet exists. This alternate route may be provided by
any other MRs connected to one of its ingress interfaces that has an any other MRs connected to one of its ingress interfaces that has an
skipping to change at page 33, line 13 skipping to change at page 34, line 13
things are back to square one). things are back to square one).
Appendix C. Change Log Appendix C. Change Log
o This draft is an update of draft-ng-nemo-multihoming-issues-03.txt o This draft is an update of draft-ng-nemo-multihoming-issues-03.txt
which is itself a merge of 3 previous drafts which is itself a merge of 3 previous drafts
draft-ng-nemo-multihoming-issues-02.txt, draft-ng-nemo-multihoming-issues-02.txt,
draft-eun-nemo-multihoming-problem-statement-00.txt, and draft-eun-nemo-multihoming-problem-statement-00.txt, and
draft-charbon-nemo-multihoming-evaluation-00.txt 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: o Changes from draft-ietf-nemo-multihoming-issues-00 to -01:
* Replaced NEMO-Prefix with MNP as decided by the WG at 60th IETF * 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 * Addressed Issue #1 in Section 1: Added a note to remind readers
that IPv6 is implicitly assumed that IPv6 is implicitly assumed
* Addressed Issue #3 in Section 2.3: Removed text on assumption * Addressed Issue #3 in Section 2.3: Removed text on assumption
* Addressed Issue #6 in Section 3.1: Added benefits * Addressed Issue #6 in Section 3.1: Added benefits
skipping to change at page 33, line 40 skipping to change at page 34, line 47
* Addressed Issue #10: New Section 4.5 on media detection * Addressed Issue #10: New Section 4.5 on media detection
* Addressed Issue #11 in Section 4.11: modified text * Addressed Issue #11 in Section 4.11: modified text
o Changes from draft-ng-multihoming-issues-03 to o Changes from draft-ng-multihoming-issues-03 to
draft-ietf-nemo-multihoming-issues-00: draft-ietf-nemo-multihoming-issues-00:
* Expanded "Problem Statement" (Section 4) * Expanded "Problem Statement" (Section 4)
* Merged "Evaluation" Section into "Problem Statement" (Section * Merged "Evaluation" Section into "Problem Statement"
4) (Section 4)
* Cleaned up description in "Classification" (Section 2), and * Cleaned up description in "Classification" (Section 2), and
clearly indicate in each classification, what are the clearly indicate in each classification, what are the
multihomed entities multihomed entities
* Re-organized "Deployment Scenarios and Prerequisites"
* Re-organized "Deployment Scenarios and Prerequisites" (Section (Section 3), and created the "Prerequisites" sub-section.
3), and created the "Prerequisites" sub-section.
o Changes from draft-ng-multihoming-issues-02 to o Changes from draft-ng-multihoming-issues-02 to
draft-ng-multihoming-issues-03: draft-ng-multihoming-issues-03:
* Merged with draft-eun-nemo-multihoming-problem-statement (see * Merged with draft-eun-nemo-multihoming-problem-statement (see
"Problem Statement" (Section 4)) "Problem Statement" (Section 4))
* Included conclusions from * Included conclusions from
draft-charbon-nemo-multihoming-evaluation-00 draft-charbon-nemo-multihoming-evaluation-00
skipping to change at page 35, line 41 skipping to change at page 36, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/