draft-ietf-nemo-multihoming-issues-03.txt   draft-ietf-nemo-multihoming-issues-04.txt 
NEMO Working Group C. Ng NEMO Working Group C. Ng
Internet-Draft Panasonic Singapore Labs Internet-Draft Panasonic Singapore Labs
Expires: January 19, 2006 E. Paik Expires: April 27, 2006 E. Paik
KT KT
T. Ernst T. Ernst
WIDE at Keio University Keio University / WIDE
M. Bagnulo M. Bagnulo
UC3M UC3M
July 18, 2005 October 24, 2005
Analysis of Multihoming in Network Mobility Support Analysis of Multihoming in Network Mobility Support
draft-ietf-nemo-multihoming-issues-03 draft-ietf-nemo-multihoming-issues-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
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 January 19, 2006. This Internet-Draft will expire on April 27, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). 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) in IPv6. As there are many situations in which mobility (NEMO) in IPv6. As there are many situations in which
mobile networks may be multihomed, a taxonomy is proposed to classify mobile networks may be multihomed, a taxonomy is proposed to classify
skipping to change at page 2, line 15 skipping to change at page 2, line 15
multihomed mobile networks are described together with the associated multihomed mobile networks are described together with the associated
issues when network mobility is supported by RFC 3963 (NEMO Basic issues when network mobility is supported by RFC 3963 (NEMO Basic
Support). Issues are classified according to the Working Group which Support). Issues are classified according to the Working Group which
is the best chartered to solve them. is the best chartered to solve them.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Classification . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Classification . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1 (1,1,1): Single MR, Single HA, Single MNP . . . . . . . . 7 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.2. (1,1,n): Single MR, Single HA, Multiple MNPs . . . . . . . 7
2.3 (1,n,1): Single MR, Multiple HAs, Single MNP . . . . . . . 8 2.3. (1,n,1): Single MR, Multiple HAs, Single MNP . . . . . . . 8
2.4 (1,n,n): Single MR, Multiple HAs, Multiple MNPs . . . . . 9 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.5. (n,1,1): Multiple MRs, Single HA, Single MNP . . . . . . . 9
2.6 (n,1,n): Multiple MRs, Single HA, Multiple MNPs . . . . . 10 2.6. (n,1,n): Multiple MRs, Single HA, Multiple MNPs . . . . . 10
2.7 (n,n,1): Multiple MRs, Multiple HAs, Single MNP . . . . . 10 2.7. (n,n,1): Multiple MRs, Multiple HAs, Single MNP . . . . . 10
2.8 (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs . . . . 11 2.8. (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs . . . . 11
3. Deployment Scenarios and Prerequisites . . . . . . . . . . . . 13
3.1 Deployment Scenarios . . . . . . . . . . . . . . . . . . . 13
3.2 Prerequisites . . . . . . . . . . . . . . . . . . . . . . 14
4. Multihoming Issues . . . . . . . . . . . . . . . . . . . . . . 16 3. Deployment Scenarios and Prerequisites . . . . . . . . . . . . 12
4.1 Fault Tolerance . . . . . . . . . . . . . . . . . . . . . 16 3.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . . 12
4.1.1 Failure Detection . . . . . . . . . . . . . . . . . . 16 3.2. Prerequisites . . . . . . . . . . . . . . . . . . . . . . 13
4.1.2 Path Exploration . . . . . . . . . . . . . . . . . . . 18
4.1.3 Path Selection . . . . . . . . . . . . . . . . . . . . 19
4.1.4 Re-Homing . . . . . . . . . . . . . . . . . . . . . . 20
4.2 Ingress Filtering . . . . . . . . . . . . . . . . . . . . 21
4.3 Media Detection . . . . . . . . . . . . . . . . . . . . . 22
4.4 HA Synchronization . . . . . . . . . . . . . . . . . . . . 23
4.5 MR Synchronization . . . . . . . . . . . . . . . . . . . . 23
4.6 Prefix Delegation . . . . . . . . . . . . . . . . . . . . 24
4.7 Multiple Bindings/Registrations . . . . . . . . . . . . . 24
4.8 Source Address Selection . . . . . . . . . . . . . . . . . 24
4.9 Loop Prevention in Nested Mobile Networks . . . . . . . . 25
4.10 Prefix Ownership . . . . . . . . . . . . . . . . . . . . . 25
5. Matrix [Issues,(x,y,z) Configuration] . . . . . . . . . . . . 26 4. Multihoming Issues . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Fault Tolerance . . . . . . . . . . . . . . . . . . . . . 15
4.1.1. Failure Detection . . . . . . . . . . . . . . . . . . 15
4.1.2. Path Exploration . . . . . . . . . . . . . . . . . . . 17
4.1.3. Path Selection . . . . . . . . . . . . . . . . . . . . 18
4.1.4. Re-Homing . . . . . . . . . . . . . . . . . . . . . . 20
4.2. Ingress Filtering . . . . . . . . . . . . . . . . . . . . 20
4.3. HA Synchronization . . . . . . . . . . . . . . . . . . . . 22
4.4. MR Synchronization . . . . . . . . . . . . . . . . . . . . 22
4.5. Prefix Delegation . . . . . . . . . . . . . . . . . . . . 23
4.6. Multiple Bindings/Registrations . . . . . . . . . . . . . 23
4.7. Source Address Selection . . . . . . . . . . . . . . . . . 24
4.8. Loop Prevention in Nested Mobile Networks . . . . . . . . 24
4.9. Prefix Ownership . . . . . . . . . . . . . . . . . . . . . 24
4.10. Preference Settings . . . . . . . . . . . . . . . . . . . 25
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 27 5. Recommendations to the Working Group . . . . . . . . . . . . . 26
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29
10.1 Normative References . . . . . . . . . . . . . . . . . . . 28 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
10.2 Informative References . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.1. Normative References . . . . . . . . . . . . . . . . . . . 30
10.2. Informative References . . . . . . . . . . . . . . . . . . 30
A. Alternative Classifications Approach . . . . . . . . . . . . . 32 Appendix A. Alternative Classifications Approach . . . . . . . . 33
A.1 Ownership-Oriented Approach . . . . . . . . . . . . . . . 32 A.1. Ownership-Oriented Approach . . . . . . . . . . . . . . . 33
A.1.1 ISP Model . . . . . . . . . . . . . . . . . . . . . . 32 A.1.1. ISP Model . . . . . . . . . . . . . . . . . . . . . . 33
A.1.2 Subscriber/Provider Model . . . . . . . . . . . . . . 33 A.1.2. Subscriber/Provider Model . . . . . . . . . . . . . . 34
A.2 Problem-Oriented Approach . . . . . . . . . . . . . . . . 35 A.2. Problem-Oriented Approach . . . . . . . . . . . . . . . . 36
B. Nested Tunneling for Fault Tolerance . . . . . . . . . . . . . 36 Appendix B. Nested Tunneling for Fault Tolerance . . . . . . . . 37
B.1 Detecting Presence of Alternate Routes . . . . . . . . . . 36 B.1. Detecting Presence of Alternate Routes . . . . . . . . . . 37
B.2 Re-Establishment of Bi-Directional Tunnels . . . . . . . . 36 B.2. Re-Establishment of Bi-Directional Tunnels . . . . . . . . 38
B.2.1 Using Alternate Egress Interface . . . . . . . . . . . 37 B.2.1. Using Alternate Egress Interface . . . . . . . . . . . 38
B.2.2 Using Alternate Mobile Router . . . . . . . . . . . . 37 B.2.2. Using Alternate Mobile Router . . . . . . . . . . . . 38
B.3 To Avoid Tunneling Loop . . . . . . . . . . . . . . . . . 38 B.3. To Avoid Tunneling Loop . . . . . . . . . . . . . . . . . 39
B.4. Points of Considerations . . . . . . . . . . . . . . . . . 39
C. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 40
Intellectual Property and Copyright Statements . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
Intellectual Property and Copyright Statements . . . . . . . . . . 44
1. Introduction 1. Introduction
The design goals and objectives of Network Mobility Support (NEMO) in The design goals and objectives of Network Mobility Support (NEMO) in
IPv6 are identified in [1] while the terminology is being described IPv6 are identified in [1] while the terminology is being described
in [2] and [3]. NEMO Basic Support (RFC 3963) [4] is the solution in [2] and [3]. NEMO Basic Support (RFC 3963) [4] is the solution
proposed by the NEMO Working Group to provide continuous Internet proposed by the NEMO Working Group to provide continuous Internet
connectivity to nodes located in an IPv6 mobile network, e.g. like in connectivity to nodes located in an IPv6 mobile network, e.g. like in
an in-vehicle embedded IP network. The NEMO Basic Support solution an in-vehicle embedded IP network. The NEMO Basic Support solution
basically solves the problem by setting up bi-directional tunnels basically solves the problem by setting up bi-directional tunnels
between the mobile routers (MRs) connecting the mobile network to the between the mobile routers (MRs) connecting the mobile network to the
Internet and their respective Home Agents (HAs), much how this is Internet and their respective Home Agents (HAs), much how this is
done in Mobile IPv6 [5], the solution for host mobility support. done in Mobile IPv6 [5], the solution for host mobility support.
NEMO Basic Support is transparent to nodes located behind the mobile 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 router (i.e. the mobile network nodes, or MNNs) and as such does not
require MNNs to take any action in the mobility management. require MNNs to take any action in the mobility management.
However, mobile networks are typically connected by means of wireless However, mobile networks are typically connected by means of wireless
and thus less reliable links; there could also be many nodes behind 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 the MR. A loss of connectivity or a failure to connect to the
Internet has thus a more significant impact than for a single mobile Internet has thus a more significant impact than for a single mobile
node. Scenarios illustrated in [6] demonstrate that providing a node. Scenarios illustrated in [6] demonstrate that providing a
permanent access to mobile networks such as vehicles typically permanent access to mobile networks such as vehicles typically
require the use of several interfaces and technologies since the require the use of several interfaces and technologies since the
mobile network may be moving in distant geographical locations where mobile network may be moving in distant geographical locations where
skipping to change at page 5, line 27 skipping to change at page 5, line 27
issues. issues.
o to decide which issues are worth to be solved, and to determine o to decide which issues are worth to be solved, and to determine
which WG should address each of the issues that are worth solving. which WG should address each of the issues that are worth solving.
In order to reach these objectives, a taxonomy to classify the In order to reach these objectives, a taxonomy to classify the
possible multihomed configurations is described in Section 2. possible multihomed configurations is described in Section 2.
Deployment scenarios, their benefits, and requirements to meet these Deployment scenarios, their benefits, and requirements to meet these
benefits are illustrated in Section 3. Following this, the related benefits are illustrated in Section 3. Following this, the related
issues are studied in Section 4. The issues are then summarized in a issues are studied in Section 4. The issues are then summarized in a
matrix for each of the deployment scenario (Section 5). This memo matrix for each of the deployment scenario, and recommendations are
concludes with an evaluation of NEMO Basic Support for multihomed made on which of the issues should be worked on and where in
configurations. Alternative classifications are outlined in the Section 5. This memo concludes with an evaluation of NEMO Basic
Appendix. Support for multihomed configurations. Alternative classifications
are outlined in the Appendix.
The readers should note that this document considers multihoming only The readers should note that this document considers multihoming only
from the point of view of an IPv6 environment. In order to from the point of view of an IPv6 environment. In order to
understand this memo, the reader is expected to be familiar with the understand this memo, the reader is expected to be familiar with the
above cited documents, i.e. with the NEMO terminology as defined in above cited documents, i.e. with the NEMO terminology as defined in
[2] (section 3) and [3], Goals and Benefits of Multihoming [6], Goals [2] (section 3) and [3], Goals and Benefits of Multihoming [6], Goals
and Requirements of Network Mobility Support [1], and the NEMO Basic and Requirements of Network Mobility Support [1], and the NEMO Basic
Support specification [4]. Goals and benefits of multihoming as Support specification [4]. Goals and benefits of multihoming as
discussed in [6] are applicable to fixed nodes, mobile nodes, fixed discussed in [6] are applicable to fixed nodes, mobile nodes, fixed
networks and mobile networks. networks and mobile networks.
skipping to change at page 6, line 44 skipping to change at page 6, line 44
y=n implies that multiple HAs are assigned to the mobile network. y=n implies that multiple HAs are assigned to the mobile network.
o 'z' indicates the number of MNPs available within the NEMO, where: o 'z' indicates the number of MNPs available within the NEMO, where:
z=1 implies that a single MNP is available in the NEMO. z=1 implies that a single MNP is available in the NEMO.
z=N implies that multiple MNPs are available in the NEMO z=N implies that multiple MNPs are available in the NEMO
It can be seen that the above three parameters are fairly orthogonal 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' result
to different combinations of the 3-tuple (x,y,z). into different combinations of the 3-tuple (x,y,z).
As described in the sub-sections below, a total of 8 possible As described in the sub-sections below, a total of 8 possible
configurations can be identified. One thing the reader has to keep configurations can be identified. One thing the reader has to keep
in mind is that in each of the following 8 cases, the MR may be in mind is that in each of the following 8 cases, the MR may be
multihomed if either (i) multiple prefixes are available (on the home multihomed if either (i) multiple prefixes are available (on the home
link, or on the visited link), or (ii) the MR is equipped with link, or on the visited link), or (ii) the MR is equipped with
multiple interfaces. In such a case, the MR would have multiple Home multiple interfaces. In such a case, the MR would have multiple Home
Address / Care-of Address pairs. Issues pertaining to a multihomed Address / Care-of Address pairs. Issues pertaining to a multihomed
MR are also addressed in [7]. In addition, the readers should also MR are also addressed in [7]. In addition, the readers should also
keep in mind that when "MNP(s) is/are available in the NEMO", the keep in mind that when "MNP(s) is/are available in the NEMO", the
MNP(s) may either be explicitly announced by the MR via router MNP(s) may either be explicitly announced by the MR via router
advertisement, or mad available through Dynamic Host Configuration advertisement, or made available through Dynamic Host Configuration
Protocol (DHCP). Protocol (DHCP).
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, it is associated with a The (1,1,1) mobile network has only one MR, it is associated with a
single HA, and a single MNP is available in the NEMO. To fall into a single HA, and a single MNP is available in the NEMO. To fall into a
multihomed configuration, at least one of the following conditions multihomed configuration, at least one of the following conditions
must hold: must hold:
o The MR has multiple interfaces, or o The MR has multiple interfaces, or
o Multiple global prefixes are available on the visited link, or o Multiple global prefixes are available on the visited link, or
skipping to change at page 7, line 43 skipping to change at page 7, line 43
_____ _____
_ p _ | | _ p _ | |
|_|-|<-_ |-|_|-| |-| _ |_|-|<-_ |-|_|-| |-| _
_ |-|_|=| |_____| | _ |-|_| _ |-|_|=| |_____| | _ |-|_|
|_|-| | |-|_|-| |_|-| | |-|_|-|
| |
MNNs MR AR Internet AR HA MNNs MR AR Internet AR HA
Figure 1: (1,1,1): 1 MR, 1 HA, 1 MNP Figure 1: (1,1,1): 1 MR, 1 HA, 1 MNP
2.2 (1,1,n): Single MR, Single HA, Multiple MNPs 2.2. (1,1,n): Single MR, Single HA, Multiple MNPs
The (1,1,n) mobile network has only one MR, it is associated with a The (1,1,n) mobile network has only one MR, it is associated with a
single HA and two or more MNPs are available in the NEMO. single HA and two or more MNPs are available in the NEMO.
The MR may be itself multihomed, as detailed in Section 2.1. In such The MR may be itself multihomed, as detailed in Section 2.1. In such
a case, a bi-directional tunnel would be established between each a case, a bi-directional tunnel would be established between each
pair of Home Address / Care-of Address. pair of Home Address / Care-of Address.
Regarding MNNs, they are multihomed because several MNPs are Regarding MNNs, they are multihomed because several MNPs are
available on the link they are attached to. The MNNs would then available on the link they are attached to. The MNNs would then
skipping to change at page 8, line 19 skipping to change at page 8, line 19
_____ _____
_ p1,p2 _ | | _ p1,p2 _ | |
|_|-|<-_ |-|_|-| |-| _ |_|-|<-_ |-|_|-| |-| _
_ |-|_|=| |_____| | _ |-|_| _ |-|_|=| |_____| | _ |-|_|
|_|-| | |-|_|-| |_|-| | |-|_|-|
| |
MNNs MR AR Internet AR HA MNNs MR AR Internet AR HA
Figure 2: (1,1,n): 1 MR, 1 HA, multiple MNPs Figure 2: (1,1,n): 1 MR, 1 HA, multiple MNPs
2.3 (1,n,1): Single MR, Multiple HAs, Single MNP 2.3. (1,n,1): Single MR, Multiple HAs, Single MNP
The (1,n,1) mobile network has only one MR and a single MNP is The (1,n,1) mobile network has only one MR and a single MNP is
available in the NEMO. The MR, however, is associated with multiple available in the NEMO. The MR, however, is associated with multiple
HAs, possibly one HA per Home Address, or one HA per egress HAs, possibly one HA per Home Address, or one HA per egress
interface. interface.
The NEMO is multihomed since it has multiple HAs, but in addition the The NEMO is multihomed since it has multiple HAs, but in addition the
conditions detailed in Section 2.1 may also hold for the MR. A bi- conditions detailed in Section 2.1 may also hold for the MR. A bi-
directional tunnel would then be established between each pair of directional tunnel would then be established between each pair of
Home Address / Care-of Address. Home Address / Care-of Address.
skipping to change at page 9, line 5 skipping to change at page 8, line 49
_ p _ | |-| _ p _ | |-|
|_|-|<-_ |-|_|-| | |_|-|<-_ |-|_|-| |
_ |-|_|=| |_____|-| _ _ |-|_|=| |_____|-| _
|_|-| | | _ |-|_| |_|-| | | _ |-|_|
|-|_|-| |-|_|-|
| |
MNNs MR AR Internet AR HA1 MNNs MR AR Internet AR HA1
Figure 3: (1,n,1): 1 MR, multiple HAs, 1 MNP Figure 3: (1,n,1): 1 MR, multiple HAs, 1 MNP
2.4 (1,n,n): Single MR, Multiple HAs, Multiple MNPs 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 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 associated with multiple HAs, possibly one per Home Address (or one
HA per egress interface), and more than one MNP is available in the HA per egress interface), and more than one MNP is available in the
NEMO. NEMO.
The MR is multihomed since it has multiple HAs, but in addition the The MR is multihomed since it has multiple HAs, but in addition the
conditions detailed in Section 2.1 may also hold. A bi-directional conditions detailed in Section 2.1 may also hold. A bi-directional
tunnel would then be established between each pair of Home Address / tunnel would then be established between each pair of Home Address /
Care-of Address. Care-of Address.
skipping to change at page 9, line 33 skipping to change at page 9, line 28
_____ |-|_|-|-|_| _____ |-|_|-|-|_|
_ p1,p2 _ | |-| | _ p1,p2 _ | |-| |
|_|-|<-_ |-|_|-| | _ |_|-|<-_ |-|_|-| | _
_ |-|_|=| |_____|-| _ |-|_| _ |-|_|=| |_____|-| _ |-|_|
|_|-| | |-|_|-| |_|-| | |-|_|-|
| | | |
MNNs MR AR Internet AR HA1 MNNs MR AR Internet AR HA1
Figure 4: (1,n,n): 1 MR, multiple HAs, multiple MNPs Figure 4: (1,n,n): 1 MR, multiple HAs, multiple MNPs
2.5 (n,1,1): Multiple MRs, Single HA, Single MNP 2.5. (n,1,1): Multiple MRs, Single HA, Single MNP
The (n,1,1) mobile network has more than one MR advertising global The (n,1,1) mobile network has more than one MR advertising global
routes. However, the MR(s) are associated with as single HA, and routes. However, the MR(s) are associated with as single HA, and
there in a single MNP available in the NEMO. there in a single MNP available in the NEMO.
The NEMO is multihomed since it has multiple MRs, but in addition the The NEMO is multihomed since it has multiple MRs, but in addition the
conditions detailed in Section 2.1 may also hold for each MR. A bi- conditions detailed in Section 2.1 may also hold for each MR. A bi-
directional tunnel would then be established between each pair of directional tunnel would then be established between each pair of
Home Address / Care-of Address. Home Address / Care-of Address.
skipping to change at page 10, line 17 skipping to change at page 10, line 17
_ |-|_|-| _____ _ |-|_|-| _____
|_|-| |-| | |_|-| |-| |
_ | | |-| _ _ | | |-| _
|_|-| _ |-|_____| | _ |-|_| |_|-| _ |-|_____| | _ |-|_|
|-|_|-| |-|_|-| |-|_|-| |-|_|-|
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; multiple global The (n,1,n) mobile network has more than one MR; multiple global
routes are advertised by the MRs and multiple MNPs are available routes are advertised by the MRs and multiple MNPs are available
within the NEMO. within the NEMO.
The NEMO is multihomed since it has multiple MRs, but in addition the The NEMO is multihomed since it has multiple MRs, but in addition the
conditions detailed in Section 2.1 may also hold for each MR. A bi- conditions detailed in Section 2.1 may also hold for each MR. A bi-
directional tunnel would then be established between each pair of directional tunnel would then be established between each pair of
Home Address / Care-of Address. Home Address / Care-of Address.
skipping to change at page 10, line 44 skipping to change at page 10, line 44
_ |-|_|-| _____ _ |-|_|-| _____
|_|-| |-| | |_|-| |-| |
_ | | |-| _ _ | | |-| _
|_|-| _ |-|_____| | _ |-|_| |_|-| _ |-|_____| | _ |-|_|
|-|_|-| |-|_|-| |-|_|-| |-|_|-|
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 multiple The (n,n,1) mobile network has more than one MR advertising multiple
global routes. The mobile network is simultaneously associated with global routes. The mobile network is simultaneously associated with
multiple HAs and a single MNP is available in the NEMO. multiple HAs and a single MNP is available in the NEMO.
The NEMO is multihomed since it has multiple MRs and HAs, but in The NEMO is multihomed since it has multiple MRs and HAs, but in
addition the conditions detailed in Section 2.1 may also hold for addition the conditions detailed in Section 2.1 may also hold for
each MR. A bi-directional tunnel would then be established between each MR. A bi-directional tunnel would then be established between
each pair of Home Address / Care-of Address. each pair of Home Address / Care-of Address.
skipping to change at page 11, line 26 skipping to change at page 11, line 24
|_|-| |-| |-| |_|-| |-| |-|
_ | | | _ | | |
|_|-| _ |-|_____|-| _ |_|-| _ |-|_____|-| _
|-|_|-| | _ |-|_| |-|_|-| | _ |-|_|
<- | |-|_|-| <- | |-|_|-|
p | p |
MNNs MR1 Internet AR HA1 MNNs MR1 Internet AR HA1
Figure 7: (n,n,1): Multiple MRs, Multiple HAs, 1 MNP Figure 7: (n,n,1): Multiple MRs, Multiple HAs, 1 MNP
2.8 (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs 2.8. (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs
The (n,n,n) mobile network has multiple MRs advertising different The (n,n,n) mobile network has multiple MRs advertising different
global routes. The mobile network is simultaneously associated with global routes. The mobile network is simultaneously associated with
more than one HA and multiple MNPs are available in the NEMO. more than one HA and multiple MNPs are available in the NEMO.
The NEMO is multihomed since it has multiple MRs and HAs, but in The NEMO is multihomed since it has multiple MRs and HAs, but in
addition the conditions detailed in Section 2.1 may also hold for addition the conditions detailed in Section 2.1 may also hold for
each MR. A bi-directional tunnel would then be established between each MR. A bi-directional tunnel would then be established between
each pair of Home Address / Care-of Address. each pair of Home Address / Care-of Address.
skipping to change at page 13, line 12 skipping to change at page 12, line 12
Figure 8: (n,n,n): Multiple MRs, HAs, and MNPs Figure 8: (n,n,n): Multiple MRs, HAs, and MNPs
3. Deployment Scenarios and Prerequisites 3. Deployment Scenarios and Prerequisites
The following generic goals and benefits of multihoming are discussed The following generic goals and benefits of multihoming are discussed
in [6]: in [6]:
1. Permanent and Ubiquitous Access 1. Permanent and Ubiquitous Access
2. Redundancy/Fault-Recovery 2. Reliability
3. Load Sharing 3. Load Sharing
4. Load Balancing 4. Load Balancing/Flow Distribution
5. Preference Settings 5. Preference Settings
6. Aggregate Bandwidth
These benefits are now illustrated from a NEMO perspective with a These benefits are now illustrated from a NEMO perspective with a
typical instance scenario for each case in the taxonomy. We then typical instance scenario for each case in the taxonomy. We then
discuss the prerequisites to fulfill these. discuss the prerequisites to fulfill these.
3.1 Deployment Scenarios 3.1. Deployment Scenarios
x=1: Multihomed mobile networks with a single MR x=1: Multihomed mobile networks with a single MR
o Example: an MR with dual/multiple access interfaces (e.g. 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 802.11 and GPRS capabilities). This is a (1,1,*) if both
accesses are subscribed to the same ISP. If the two accesses 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 are offered by independent ISPs, this is a (1,n,n)
the meaning of this abbreviation, see Appendix A.1].
Benefits: Ubiquity, Redundancy/Fault-Recovery, Load Sharing, Benefits: Ubiquitous Access, Reliability, Load Sharing,
Preference Settings Preference Settings, Aggregate Bandwidth
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 ISPs 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, Reliability, Ubiquitous Access,
Aggregate Bandwidth
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 (n,n,n) if the two access technologies are
subscribed separately. subscribed separately.
Benefits: Ubiquity, Redundancy/Fault-Recovery, Preference Benefits: Ubiquitous Access, Reliability, Preference Settings,
Settings Aggregate Bandwidth
y=1: Multihomed mobile networks with a single HA y=1: Multihomed mobile networks with a single HA
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, Preferences (reduced delay, shortest path) Benefits: Ubiquity, Preferences (reduced delay, shortest path),
Reliability
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) or a the car-manufacturer). This will typically be a (1,1,n) or a
(1,n,n,). (1,n,n,).
Benefits: Preference Settings Benefits: Preference Settings
3.2 Prerequisites 3.2. Prerequisites
In this section, requirements are started in order to comply with the In this section, requirements are started in order to comply with the
expected benefits of multihoming as detailed in [6]. expected benefits of multihoming 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:
o Permanent and Ubiquitous Access: o Permanent and Ubiquitous Access:
At least one bi-directional tunnel must be available at any point At least one bi-directional tunnel must be available at any point
in time. in time.
o Redundancy and Fault-Recovery: o Reliability:
Both the inbound and outbound traffic must be transmitted or Both the inbound and outbound traffic must be transmitted or
diverted over another bi-directional tunnel once a bi-directional diverted over another bi-directional tunnel once a bi-directional
tunnel is broken or disrupted. It should be noted that the tunnel is broken or disrupted. It should be noted that the
provision of fault tolerance capabilities does not necessarily provision of fault tolerance capabilities does not necessarily
require the existence of multiple bi-directional tunnels require the existence of multiple bi-directional tunnels
simultaneously. simultaneously.
o Load Sharing and Load Balancing: o Load Sharing and Load Balancing:
skipping to change at page 16, line 5 skipping to change at page 14, line 34
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 bi- preferences are set for deciding which of the available bi-
directional tunnels should be used. To allow user/application to directional tunnels should be used. To allow user/application to
set the preference, a mechanism should be provided to the user/ set the preference, a mechanism should be provided to the user/
application for the notification of the availability of multiple application for the notification of the availability of multiple
bi-directional tunnels, and perhaps also to set preferences. bi-directional tunnels, and perhaps also to set preferences.
Similar mechanism should also be provided to network Similar mechanism should also be provided to network
administrators for the administration of the preferences. administrators for the administration of the preferences.
o Aggregate Bandwidth:
Multiple tunnels must be maintained simultaneously in order to
have an increase in the total aggregated bandwidth available to
the mobile network.
4. Multihoming Issues 4. Multihoming Issues
As discussed in the previous section, multiple bi-directional tunnels As discussed in the previous section, multiple bi-directional tunnels
need to be maintained either simultaneously (e.g. for load sharing) need to be maintained either sequentially (e.g. for fault tolerance)
or sequentially (e.g. for fault tolerance) or simultaneously (e.g. for load sharing).
In some cases, it may be necessary to divert packets from a (perhaps 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 tunnels recovery, preferences), or to split traffic between multiple tunnels
(load sharing, load balancing). (load sharing, load balancing).
So, depending on the configuration under consideration, the issues So, depending on the configuration under consideration, the issues
discussed below may need to be addressed, sometimes dynamically. For discussed below may need to be addressed, sometimes dynamically. For
each issue, potential ways to solve the problem are investigated and each issue, potential ways to solve the problem are investigated and
an a recommendation is made on which IETF WG(s) should look into an a recommendation is made on which IETF WG(s) should look into
these issues. these issues.
4.1 Fault Tolerance 4.1. Fault Tolerance
One of the goals of multihoming is the provision of fault tolerance One of the goals of multihoming is the provision of fault tolerance
capabilities. In order to provide such features, a set of tasks need capabilities. In order to provide such features, a set of tasks need
to be performed, including: failure detection, alternative available to be performed, including: failure detection, alternative available
path exploration, path selection, re-homing of established path exploration, path selection, re-homing of established
communications. These are also discussed in [8] [9]. In the communications. These are also discussed in [8] and [9] by the Shim6
following sub-sections, we look at these issues in the specific WG. In the following sub-sections, we look at these issues in the
context of NEMO, rather than the general Multi6/Shim6 perspective in specific context of NEMO, rather than the general Shim6 perspective
[8] [9]. In addition, in some scenarios, it may also be required to in [8] [9]. In addition, in some scenarios, it may also be required
provide the mechanisms for coordination between different HAs (see to provide the mechanisms for coordination between different HAs (see
Section 4.4) and also the coordination between different MRs (see Section 4.3) and also the coordination between different MRs (see
Section 4.5). Section 4.4).
4.1.1 Failure Detection 4.1.1. 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. Depending on the NEMO configuration recover in timely fashion. Depending on the NEMO configuration
considered, the failure protection domain greatly varies. In some considered, the failure protection domain greatly varies. In some
configurations, the protection domain provided by NEMO multihoming is configurations, the protection domain provided by NEMO multihoming is
limited to the links between the MR(s) and the HA(s). In other limited to the links between the MR(s) and the HA(s). In other
configurations, the protection domain allows to recover from failures configurations, the protection domain allows to recover from failures
in other parts of the path, so an end to end failure detection in other parts of the path, so an end to end failure detection
mechanism is required. mechanism is required.
Below are detailed which failure detection capabilities are required Below are detailed which failure detection capabilities are required
for each configuration: for each configuration:
o For the (1,1,*) cases, multiple paths are available between a o For the (1,1,*) cases, multiple paths are available between a
single MR and a single HA. All the traffic from and to the NEMO single MR and a single HA. All the traffic from and to the NEMO
flows through these MR and HA. Failure detection mechanisms need flows through these MR and HA. Failure detection mechanisms need
only to be executed between these two devices. This is a NEMO only to be executed between these two devices. This is a NEMO/
specific issue (MIPv6?). MIPv6 specific issue.
o For the (n,1,*) cases, there is a single HA, so all the traffic o For the (n,1,*) cases, there is a single HA, so all the traffic
from and to the NEMO will flow through it. The failure detection from and to the NEMO will flow through it. The failure detection
mechanisms need to be able to detect failure in the path between mechanisms need to be able to detect failure in the path between
the used MR and the only HA. Hence, the failure detection the used MR and the only HA. Hence, the failure detection
mechanism needs only to involve the HA and the MRs. This is a mechanism needs only to involve the HA and the MRs. This is a
NEMO specific issue (MIPv6?). NEMO/MIPv6 specific issue.
o For the (n,n,*) cases, there are multiple paths between the o For the (n,n,*) cases, there are multiple paths between the
different HAs and the different MRs. Moreover, the HAs may be different HAs and the different MRs. Moreover, the HAs may be
located in different networks, and have different Internet access located in different networks, and have different Internet access
links. This implies that changing the HA used, may not only allow links. This implies that changing the HA used may not only allow
to recover from failures in the link between the HA and the MR but recovering from failures in the link between the HA and the MR,
also from other failure modes, affecting other parts of the path. but also from other failure modes, affecting other parts of the
In this case, an end to end failure detection mechanism would path. In this case, an end-to-end failure detection mechanism
provide additional protection. However, a higher number of would provide additional protection. However, a higher number of
failures is likely in the link between the HA and the MR, so it failures is likely to occur in the link between the HA and the MR,
may be reasonable to provide optimized failure detection so it may be reasonable to provide optimized failure detection
mechanisms for this failure mode even in this scenario, as it is mechanisms for this failure mode. The (n,n,1) case, however,
considered next. The (n,n,1) case, however, seems to be pretty seems to be pretty NEMO specific, because of the absence of
NEMO specific, because of the absence of multiple prefixes. The multiple prefixes. The (n,n,n) case is hybrid, since for those
(n,n,n) case is hybrid, since for those cases that selecting a cases when selecting a different prefix results in a change of
different prefix results in a change of path, the SHIM/multi6 path, the Shim6 protocols (such as those discussed in [8]) may be
protocols may be useful. The other cases, are NEMO specific. useful. The other cases are NEMO specific.
Most of the above cases involve the detection of tunnel failures
between HA(s) and MR(s). This is no different from the case of
failure detection between a mobile host and its HA(s). As such, a
solution for MIPv6 should apply to NEMO as well. For the case of
(n,*,*), a MR synchronization solution (see Section 4.4) should be
able to compliment a MIPv6 failure detection solution to achieve the
desired functionality for NEMO.
In order for fault recovery to work, the MRs and HAs must first In order for fault recovery to work, the MRs and HAs must first
possess a means to detect failures: possess a means to detect failures:
o On the MR's side, the MR can rely on router advertisements from o On the MR's side, the MR can rely on router advertisements from
access routers, or other layer-2 trigger mechanisms to detect access routers, or other layer-2 trigger mechanisms to detect
faults, e.g. [10], [11], [12] or [13]. (For a related issue, see faults, e.g. [10], [11], [12] or [13].
Section 4.3.)
o On the HA's side, it is more difficult to detect tunnel failures. o On the HA's side, it is more difficult to detect tunnel failures.
For an ISP deployment model, the HAs and MRs can use proprietary For an ISP deployment model, the HAs and MRs can use proprietary
methods (such as constant transmission of heartbeat signals) to methods (such as constant transmission of heartbeat signals) to
detect failures and check tunnel liveness. In the S/P model (see detect failures and check tunnel liveness. In the subscriber
Appendix A.2), a lack of standardized "tunnel liveness" protocol model (see Appendix A.2: S/P model), a lack of standardized
means that it is harder to detect failures. "tunnel liveness" 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
binding acknowledgment messages with smaller Lifetime values, thus binding acknowledgment messages with smaller Lifetime values, thus
forcing the MRs to send binding updates more frequently. These forcing the MRs to send binding updates more frequently. These
binding updates can be used to emulate "tunnel heartbeats". This binding updates can be used to emulate "tunnel heartbeats". This
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.
4.1.2 Path Exploration 4.1.2. Path Exploration
Once a failure in the currently used path is detected, alternative Once a failure in the currently used path is detected, alternative
paths need to be explored in order to identify an available one. paths need to be explored in order to identify an available one.
This process is closely related to failure detection in the sense This process is closely related to failure detection in the sense
that paths being explored need to be alternative paths to the one that paths being explored need to be alternative paths to the one
that has failed. There are, however, subtle but significant that has failed. There are, however, subtle but significant
differences between path exploration and failure detection. Failure differences between path exploration and failure detection. Failure
detection occurs on the currently used path while path exploration detection occurs on the currently used path while path exploration
occurs in alternative paths (not in the one currently being used for occurs on the alternative paths (not on the one currently being used
exchanging packets). Although both path exploration and failure for exchanging packets). Although both path exploration and failure
detection are likely to rely on a reachability or keepalive test detection are likely to rely on a reachability or keepalive test
exchange, failure detection also relies on other information, such as exchange, failure detection also relies on other information, such as
upper layer information (e.g. positive or negative feedback form upper layer information (e.g. positive or negative feedback form
TCP), lower layer information (e.g. an interface is down), and TCP), lower layer information (e.g. an interface is down), and
network layer information (e.g. as an address being deprecated or network layer information (e.g. as an address being deprecated or
ICMP error message). ICMP error message).
Basically, the same cases as in the analysis of the failure detection Basically, the same cases as in the analysis of the failure detection
(Section 4.1.1) issue are identified: (Section 4.1.1) issue are identified:
o For the (1,1,*) cases, multiple paths are available between a o For the (1,1,*) cases, multiple paths are available between a
single MR and a single HA. The existing paths between the HA and single MR and a single HA. The existing paths between the HA and
the MR need to be explored to identify an available one. The the MR need to be explored to identify an available one. The
mechanism involves only the HA and the MR. This is a NEMO mechanism involves only the HA and the MR. This is a NEMO/MIPv6
specific issue (MIPv6?). specific issue.
o For the (n,1,*) cases, there is a single HA, so all the traffic o For the (n,1,*) cases, there is a single HA, so all the traffic
from and to the NEMO will flow through it. The available from and to the NEMO will flow through it. The available
alternative paths are the different ones between the different MRs alternative paths are the different ones between the different MRs
and the HA. The path exploration mechanism needs only to involve and the HA. The path exploration mechanism needs only to involve
the HA and the MRs. This is a NEMO specific issue (MIPv6?). the HA and the MRs. This is a NEMO/MIPv6 specific issue.
o For the (n,n,*) cases, there are multiple paths between the o For the (n,n,*) cases, there are multiple paths between the
different HAs and the different MRs. In this case, alternative different HAs and the different MRs. In this case, alternative
paths may be routed completely independently one from each other. paths may be routed completely independently one from each other.
In this case, an end to end path exploration mechanism would be An end-to-end path exploration mechanism would be able to discover
able to discover if any of the end to end paths is available. if any of the end-to-end paths is available. The (n,n,1) case,
However, a higher number of failures is likely in the link between however, seems to be pretty NEMO specific, because of the absence
the HA and the MR, so it may be reasonable to provide optimized of multiple prefixes. The (n,n,n) case is hybrid, since for those
path exploration mechanism for this failure mode even in this cases that selecting a different prefix result in a change of
scenario. The (n,n,1) case, however, seems to be pretty NEMO path, the Shim6 protocols (such as [9]) may be useful. The other
specific, because of the absence of multiple prefixes. The cases, are NEMO specific.
(n,n,n) case is hybrid, since for those cases that selecting a
different prefix result in a change of path, the SHIM/multi6
protocols may be useful. The other cases, are NEMO specific.
4.1.3 Path Selection Most of the above cases involve the path exploration of tunnels
between HA(s) and MR(s). This is no different from the case of path
exploration between a mobile host and its HA(s). As such, a solution
for MIPv6 should apply to NEMO as well. For the case of (n,*,*), a
MR synchronization solution (see Section 4.4) should be able to
compliment a MIPv6 path exploration solution to achieve the desired
functionality for NEMO.
In order to perform path exploration, it is sometimes also necessary
for the mobile router to detect the availability of network media.
This may be achieved using layer 2 triggers [10], or other mechanism
developed/recommended by the Detecting Network Attachment (DNA)
Working Group [11][14]. This is related to Section 4.1.1, since the
ability to detect media availability would often implies the ability
to detect media un-availability.
4.1.3. Path Selection
A path selection mechanism is required to select among the multiple A path selection mechanism is required to select among the multiple
available paths. Depending on the NEMO multihoming configuration available paths. Depending on the NEMO multihoming configuration
involved, the differences between the paths may affect only the part involved, the differences between the paths may affect only the part
between the HA and the MR or may affect the full end to end path. between the HA and the MR, or they may affect the full end-to-end
Related to this, depending on the configuration, path selection may path. In addition, depending on the configuration, path selection
be performed by the HA(s), the MR(s) or the hosts themselves through may be performed by the HA(s), the MR(s) or the hosts themselves
address selection, as it will be presented next. through address selection, as will be described in details next.
In the (*,*,1) cases, the multiple available paths mostly differ on The multiple available paths may differ on the tunnel between the MR
the tunnel between the MR and the HA used to carry traffic to/from and the HA used to carry traffic to/from the NEMO. In this case,
the NEMO. In this case, path selection is performed by the MR and path selection is performed by the MR and the intra-NEMO routing
the intra-NEMO routing system for traffic flowing from the NEMO, and system for traffic flowing from the NEMO, and path selection is
path selection is performed by the HA and intra-Home Network routing performed by the HA and intra-Home Network routing system for traffic
system for traffic flowing to the NEMO, as it is presented next. flowing to the NEMO.
Alternatively, the multiple paths available may differ in more than
just the tunnel between the MR and the HA, since the usage of
different prefixes may result in using different providers, hence in
completely different paths between the involved endpoints. In this
case, besides the mechanisms presented in the previous case,
additional mechanisms for the end-to-end path selection may be
needed. This mechanism may be closely related to source address
selection mechanisms within the hosts, since selecting a given
address implies selecting a given prefix, which is associated with a
given ISP serving one of the home networks.
A dynamic path selection mechanism is thus needed so that this path A dynamic path selection mechanism is thus needed so that this path
could be selected by: could be selected by:
o The HA: it should be able to select the path based on some o The HA: it should be able to select the path based on some
information recorded in the binding cache. information recorded in the binding cache.
o The MR: it should be able to select the path based on router o The MR: it should be able to select the path based on router
advertisements received on both its egress interfaces or on its advertisements received on both its egress interfaces or on its
ingress interfaces for the (n,*,*) case. ingress interfaces for the (n,*,*) case.
In the (*,*,n) cases, the multiple paths available may differ in more
than just the tunnel between the MR and the HA, since the usage of
different prefixes may result in using different providers, hence in
completely different paths between the involved endpoints. In this
case, besides the mechanisms presented in the previous case,
additional mechanisms for the end to end path selection may be
needed. This mechanism may be closely related to source address
selection mechanisms within the hosts, since selecting a given
address implies selecting a given prefix, which is associated with a
given ISP serving one of the home networks.
In this case we need to consider additional mechanisms for path
selection based on:
o The MNN: it should be able to select the path based on "Default o The MNN: it should be able to select the path based on "Default
Router Selection" (see [Section 6.3.6. Default Router Selection] Router Selection" (see [Section 6.3.6. Default Router Selection]
[14]) in the (n,*,*) case or based on "Source Address Selection" [15]) in the (n,*,*) case or based on "Source Address Selection"
in the (*,*,n) cases (see Section 4.8 of the present memo). in the (*,*,n) cases (see Section 4.7 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.
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 of the bi-directional tunnels would
selected, and based on which parameter (e.g. type of flow that goes be selected, and based on which of the parameters (e.g. type of flow
into/out of the mobile network). that goes into/out of the mobile network).
The mechanisms for the selection among the different tunnels between The mechanisms for the selection among the different tunnels between
the MR(s) and the HA(s) seems to be quite NEMO specific. The the MR(s) and the HA(s) seems to be quite NEMO/MIPv6 specific. For
mechanisms for selecting among different end to end paths based on (1,*,*) cases, they are no different from the case of path selection
address selection are similar to the ones used in other multihoming between a mobile host and its HA(s). As such, a solution for MIPv6
scenarios, as those considered by Shim6/multi6 (e.g. [15]). should apply to NEMO as well. For the case of (n,*,*), a MR
synchronization solution (see Section 4.4) should be able to
compliment a MIPv6 path selection solution to achieve the desired
functionality for NEMO. The mechanisms for selecting among different
end-to-end paths based on address selection are similar to the ones
used in other multihoming scenarios, as those considered by Shim6
(e.g. [16]).
4.1.4 Re-Homing 4.1.4. Re-Homing
After an outage has been detected and an available alternative path After an outage has been detected and an available alternative path
has been identified, a re-homing event takes place, diverting the has been identified, a re-homing event takes place, diverting the
existent communications from one path to the other. Similar to the existing communications from one path to the other. Similar to the
previous items involved in this process, the re-homing procedure previous items involved in this process, the re-homing procedure
heavily varies depending on the NEMO multihoming configuration. heavily varies depending on the NEMO multihoming configuration.
o For the (*,*,1) configurations, the re-homing procedure involves o For the (*,*,1) configurations, the re-homing procedure involves
only the MR(s) and the HA(s). The re-homing procedure may involve only the MR(s) and the HA(s). The re-homing procedure may involve
the exchange of additional BU messages. the exchange of additional BU messages. These mechanisms are
shared between NEMO Basic Support and MIPv6.
These mechanisms are shared between NEMO Basic Support and MIPv6.
o For the (*,*,n) cases, in addition to the previous mechanisms, end o For the (*,*,n) cases, in addition to the previous mechanisms, end
to end mechanisms may be required. Such mechanisms may involve to end mechanisms may be required. Such mechanisms may involve
some form of end to end signaling or may simply rely on using some form of end to end signaling or may simply rely on using
different addresses for the communication. different addresses for the communication. The involved
mechanisms may be similar to those required for re-homing Shim6
The involved mechanisms may be similar to those required for re- communications (e.g. [16]).
homing Shim6/multi6 communications (e.g. [15]).
4.2 Ingress Filtering 4.2. Ingress Filtering
Ingress filtering mechanisms [16][17] may drop the outgoing packets Ingress filtering mechanisms [17][18] may drop the outgoing packets
when multiple bi-directional tunnels end up at different HAs. This when multiple bi-directional tunnels end up at different HAs. This
could particularly occur if different MNPs are handled by different could particularly occur if different MNPs are handled by different
home agents. If a packet with a source address configured from a HAs. If a packet with a source address configured from a specific
specific MNP is tunnelled to a home agent that does not handle that MNP is tunnelled to a home agent that does not handle that specific
specific MNP the packet may be discarded either by the home agent or MNP the packet may be discarded either by the home agent or by a
by a border gateway in the home network. border gateway in the home network.
The ingress filtering compatibility issue is heavily dependent on the The ingress filtering compatibility issue is heavily dependent on the
particular NEMO multihoming configuration: particular NEMO multihoming configuration:
o For the (*,*,1) cases, there is not such an issue, since there is o For the (*,*,1) cases, there is not such an issue, since there is
a single MNP. a single MNP.
o For the (*,1,n) cases, there is not such a problem since there is o For the (*,1,n) cases, there is not such a problem, since there is
a single HA, accepting all the MNPs. a single HA, accepting all the MNPs.
o (*,n,n) are the cases where the ingress filtering presents some o (*,n,n) are the cases where the ingress filtering presents some
difficulties. In the (1,n,n) case the problem is simplified difficulties. In the (1,n,n) case, the problem is simplified
because all the traffic from and to the NEMO is routed through a because all the traffic from and to the NEMO is routed through a
single MR. Such configuration allows the MR to properly route single MR. Such configuration allows the MR to properly route
packets respecting the constraints imposed by ingress filtering. packets respecting the constraints imposed by ingress filtering.
The more complex case is the (n,n,n) case. A simplified case The more complex case is the (n,n,n) case. A simplified case
occurs when all the prefixes are accepted by all the HAs, so that occurs when all the prefixes are accepted by all the HAs, so that
no problems occur with the ingress filtering. However, this no problems occur with the ingress filtering. However, this
cannot be always assumed, resulting in the problem described cannot be always assumed, resulting in the problem described
below. below.
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: the mobile network has two mobile
has two mobile routers MR1 and MR2, with home agents HA1 and HA2 routers MR1 and MR2, with home agents HA1 and HA2 respectively. Two
respectively. Two bi-directional tunnels are established between the bi-directional tunnels are established between the two pairs. Each
two pairs. Each mobile router advertises a different MNP (P1 and mobile router advertises a different MNP (P1 and P2 respectively).
P2). MNP P1 is registered to HA1, and MNP P2 is registered to HA2. MNP P1 is registered to HA1, and MNP P2 is registered to HA2. Thus,
Thus, MNNs should be free to auto-configure their addresses on any of MNNs should be free to auto-configure their addresses on any of P1 or
P1 or P2. Ingress filtering could thus happen in two cases: P2. Ingress filtering could thus happen in two cases:
o If the two tunnels are available, MNN cannot forward packet with o If the two tunnels are available, MNN cannot forward packet with
source address equals P1.MNN to MR2. This would cause ingress source address equals P1.MNN to MR2. This would cause ingress
filtering at HA2 to occur (or even at MR2). This is contrary to filtering at HA2 to occur (or even at MR2). This is contrary to
normal Neighbor Discovery [14] practice that an IPv6 node is free normal Neighbor Discovery [15] practice that an IPv6 node is free
to choose any router as its default router regardless of the to choose any router as its default router regardless of the
prefix it chooses to use. prefix it chooses to use.
o If the tunnel to HA1 is broken, packets would be sent through the o If the tunnel to HA1 is broken, packets that would normally be
tunnel to HA1 are diverted through the tunnel to HA2. If HA2 (or sent through the tunnel to HA1 should be diverted through the
some border gateway in the domain of HA2) performs ingress tunnel to HA2. If HA2 (or some border gateway in the domain of
filtering, packets with source address configured from MNP P1 may HA2) performs ingress filtering, packets with source address
be discarded. configured from MNP P1 may be discarded.
Prefix: P1 +-----+ +----+ +----------+ +-----+
+--| MR1 |--| AR |--| |---| HA1 |
| +-----+ +----+ | | +-----+
IP: +-----+ | | | Prefix: P1
P1.MNN or | MNN |--+ | Internet |
P2.MNN +-----+ | | | Prefix: P2
| +-----+ +----+ | | +-----+
+--| MR2 |--| AR |--| |---| HA2 |
Prefix: P2 +-----+ +----+ +----------+ +-----+
Figure 9: An (n,n,n) mobile network
Possible solutions to the ingress filtering incompatibility problem Possible solutions to the ingress filtering incompatibility problem
may be based on the following approaches: may be based on the following approaches:
o Some form of source address dependent routing, whether host-based o Some form of source address dependent routing, whether host-based
and/or router-based where the prefix contained in the source and/or router-based where the prefix contained in the source
address of the packet is considered when deciding which exit address of the packet is considered when deciding which exit
router to use when forwarding the packet. router to use when forwarding the packet.
o The usage of nested tunnels for (*,n,n) cases. Appendix B o The usage of nested tunnels for (*,n,n) cases. Appendix B
describes one such approach. describes one such approach.
o Deprecating those prefixes associated to non-available exit o Deprecating those prefixes associated to non-available exit
routers routers
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
The ingress filtering incompatibilities problems that appear in some The ingress filtering incompatibilities problems that appear in some
NEMO multihoming configurations are similar to those considered in NEMO multihoming configurations are similar to those considered in
Shim6/multi6. Shim6 (eg. see [19]).
4.3 Media Detection
In order to achieve benefits such as ubiquity or fault recovery, it
is necessary for the mobile router to detect the availability of
network media. This may be achieved using layer 2 triggers [10], or
other mechanism developed/recommended by the Detecting Network
Attachment (DNA) Working Group [11][18].
This is related to Section 4.1.1, since the ability to detect media
availability would often implies the ability to detect media un-
availability.
4.4 HA Synchronization 4.3. HA Synchronization
In the (*,n,*) mobile networks, a single MNP would be registered at In the (*,n,*) mobile networks, a single MNP would be registered at
different HAs. This gives rise to the following cases: different HAs. This gives rise to the following cases:
o Only one HA may actively advertise a route to the MNP, o Only one HA may actively advertise a route to the MNP,
o Multiple HAs at different domains may advertise a route to the o Multiple HAs at different domains may advertise a route to the
same MNP same MNP.
This may pose a problem in the routing infrastructure as a whole if This may pose a problem in the routing infrastructure as a whole if
the HAs are located in different administrative domains. The the HAs are located in different administrative domains. The
implications of this aspect needs further exploration. Certain level implications of this aspect needs further exploration. Certain level
of HA co-ordination may be required. A possible approach is to adopt of HA co-ordination may be required. A possible approach is to adopt
a HA synchronization mechanism such as that described in [19] and a HA synchronization mechanism such as that described in [20] and
[20]. Such synchronization might also be necessary in a (*,n,*) [21]. 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 between HAs. The mode of information might have to be synchronized between HAs. The mode of
synchronization may be either primary-secondary or peer-to-peer. In synchronization may be either primary-secondary or peer-to-peer. In
addition, when MNP is delegated to the MR (see Section 4.6), some addition, when MNP is delegated to the MR (see Section 4.5), some
level of co-ordination between the HAs may also be neceesary. level of co-ordination between the HAs may also be necessary.
This issue is a general mobility issue that will also have to be This issue is a general mobility issue that will also have to be
dealt with Mobile IPv6. This issue should be dealt within a dealt with by Mobile IPv6 as well as NEMO Basic Support. It is
potentially forthcoming Monami6 WG. recommended that the Monami6 WG take this issue into consideration.
4.5 MR Synchronization 4.4. 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, such as:
synchronization 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 o advertising the same MNP in the (n,*,1) mobile network (see also
delegation" in Section 4.6). "prefix delegation" in Section 4.5);
o In the (n,*,n) case, a MR relaying the advertisement of the MNP o one MR relaying the advertisement of the MNP from another failed
from another failed MR. MR in the (n,*,n) mobile network; and
o relaying between MRs everything that needs to be relayed, such as
data packets, creating a tunnel from the ingress interface, etc,
in the (n,*,*) mobile network.
o In the (n,*,*) cases, relaying between MRs everything that needs However, there is no known standardized protocols for this kind of
to be relayed, such as data packets, creating a tunnel from the router-to-router synchronization. Without such synchronization, it
ingress interface, etc. may not be possible for a (n,*,*) mobile network to achieve various
multihoming goals, such as fault tolerance.
This problem is general in the sense that a multi-router site in the Such a synchronization mechanism can be primary-secondary (i.e. a
fixed network would require the same level of router synchronization. master MR, with the other MRs as backup) or peer-to-peer (i.e. there
It is recommended that the issue be looked at in the IPv6 or Shim6 is no clear administrative hierarchy between the MRs). The need for
WG, and the NEMO WG to contribute any NEMO specific requirement. such mechanism is general in the sense that a multi-router site in
the fixed network would require the same level of router
synchronization. It is recommended that the issue be looked at in
the IPv6 or Shim6 WG, and the NEMO WG to contribute any NEMO specific
requirement.
4.6 Prefix Delegation 4.5. 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. There is, however, no synchronization
delegation: mechanism available to achieve this. Particularly,
o For the (*,n,1) mobile network, how multiple HAs would delegate o for the (*,n,1) mobile network, how can multiple HAs delegate the
the same MNP to the mobile network. For doing so, the HAs may be 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.4). Synchronization" in Section 4.3).
o For the (n,*,n) mobile network, how multiple mobile routers would o for the (n,*,1) mobile network, how can multiple MRs be
be synchronized to advertise the same MNP down the NEMO-link. For 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.5). MNP (see also "MR Synchronization" in Section 4.4).
This could be configured manually, or dynamically. Alternatively,
prefix delegation mechanisms [21] [22] could be used to ensure all
routers advertise the same MNP.
Prefix delegation is currently being explored in the NEMO WG. Should Prefix delegation mechanisms [22][23][24] could be used to ensure all
the WG decides to standardize a prefix delegation mechanism, the WG routers advertise the same MNP. The WG should consider their
should also consider its application to a multihomed mobile network. application to a multihomed mobile network.
4.7 Multiple Bindings/Registrations 4.6. 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 mobility issue, since Mobile IPv6 nodes face a This is a generic mobility issue, since Mobile IPv6 nodes face a
similar problem. This issue is discussed in [7]. It is sufficient similar problem. This issue is discussed in [7]. It is sufficient
to note that solutions like [23] can solve this for both Mobile IPv6 to note that solutions like [25] can solve this for both Mobile IPv6
and NEMO Basic Support. This issue should be dealt within a and NEMO Basic Support. This issue should be dealt with in the
potentially forthcoming Monami6 WG. Monami6 WG.
4.8 Source Address Selection 4.7. Source Address Selection
In the (*,*,n) mobile networks, MNNs would be configured with In the (*,*,n) mobile networks, MNNs would be configured with
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. In addition, source address
selection may be closely related to path selection procedures (see
In addition, source address selection may be closely related to path Section 4.1.3) and re-homing techniques (see Section 4.1.4).
selection procedures (see Section 4.1.3) and re-homing techniques
(see Section 4.1.4).
It may be desirable for MNNs to be able to acquire "preference" However, currently available source address selection mechanisms do
information on each MNP from the MRs. This would allow default not allow MNNs to acquire sufficient information to select their
address selection mechanisms such as these specified in [24] to be source addresses intelligently (such as based on the traffic
used. Further exploration on setting such "preference" information condition associated with the home network of each MNP). It may be
in Router Advertisement based on performance of the bi-directional desirable for MNNs to be able to acquire "preference" information on
tunnel might prove to be useful. each MNP from the MRs. This would allow default address selection
mechanisms such as those specified in [26] 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 This is a general issue faced by any node when offered multiple
prefixes. It is recommended that the issue be examined by other WG prefixes. It is recommended that the issue be examined by other WG
(such as IPv6). (such as IPv6).
4.9 Loop Prevention in Nested Mobile Networks 4.8. Loop Prevention in 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 to 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 of multiple mobile such, a solution to prevent an infinite loop of multiple mobile
routers must be provided. routers must be provided.
This problem is specific to NEMO Basic Support. It is recommended This problem is specific to NEMO Basic Support. It is recommended
that the NEMO WG standardizes a solution to solve this problem (such that the NEMO WG standardizes a solution to solve this problem (such
as the use of a tree-spanning algorithm, or [25]). as the use of a tree-spanning algorithm, or [27]).
4.10 Prefix Ownership 4.9. Prefix Ownership
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), MRs on distinct links may try to register the only available up), MRs on distinct links may try to register the only available
MNP. This cannot be allowed, as the HA has no way to know which node MNP. This cannot be allowed, as the HA has no way to know which node
with an address configured from that MNP is attached to which MR. with an address configured from that MNP is attached to which MR.
Some mechanism must be present for the MNP to either be forcibly 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 removed from one (or all) MRs, or the implementors must not allow a
(n,*,1) network to split. (n,*,1) network to split.
A possible approach to solving this problem is described in [26]. A possible approach to solving this problem is described in [28].
This problem is specific to NEMO Basic Support. It is recommended This problem is specific to NEMO Basic Support. However, it is
that the NEMO WG standardizes a solution to solve this problem, or unclear whether there is sufficient deployment scenario for this
specifies that the split of a (n,*,1) network cannot be allowed problem to occur. It is recommended that the NEMO WG standardizes a
without a router renumbering. solution to solve this problem if there is sufficient vendor/operator
interest, or specifies that the split of a (n,*,1) network cannot be
allowed without a router renumbering.
5. Matrix [Issues,(x,y,z) Configuration] 4.10. Preference Settings
When a mobile network is multihomed, the MNNs may be able to enjoy
the benefits of multihoming, such as to choose among the available
paths based on cost, transmission delays, bandwidth, etc. However,
in some cases, such a choice is not made available to the MNNs.
Particularly,
o In the (*,*,n) mobile network, the MNNs can influence the path by
source address selection (see Section 4.1.3, Section 4.7).
o In the (n,*,*) mobile network, the MNNs can influence the path by
default router selection (see Section 4.1.3).
o In the (1,*,1) mobile network, the MNNs cannot influence the path
selection.
A mechanism that allows the MNN to indicate its preference for a
given traffic might be helpful. In addition, there may also be a
need to exchange some information between the MRs and the MNNs. This
problem is general in the sense that any IPv6 nodes may wish to
influence the routing decision done by the upstream routers. Such
mechanism is currently being explored by various WGs, such as the
NSIS and IPFIX WGs. It is also possible that a Shim6 layer in the
MNNs may possess such capability. It is recommended that vendors or
operators to investigate into the solutions developed by these WGs
when providing multihoming capabilities to mobile networks.
5. Recommendations to the Working Group
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. These are multihoming capabilities were identified in Section 4. These are
shown in the matrix below, for each of the eight multihoming shown in the matrix below, for each of the eight multihoming
configurations, together with indications of the WG(s) in which each configurations, together with indications of the WG(s) in which each
issue is the most likely to be solved. issue is the most likely to be solved.
+=================================================================+ +=================================================================+
| # of MRs: | 1 | 1 | 1 | 1 | n | n | n | n | | # of MRs: | 1 | 1 | 1 | 1 | n | n | n | n |
| # of HAs: | 1 | 1 | n | n | 1 | 1 | n | n | | # of HAs: | 1 | 1 | n | n | 1 | 1 | n | n |
skipping to change at page 26, line 30 skipping to change at page 26, line 30
| Failure Detection |N/M|N/M|N/M|N/M|N/M|N/M| N | S | | Failure Detection |N/M|N/M|N/M|N/M|N/M|N/M| N | S |
+---------------------------------+---+---+---+---+---+---+---+---+ +---------------------------------+---+---+---+---+---+---+---+---+
| Path Exploration |N/M|N/M|N/M|N/M|N/M|N/M| N | S | | Path Exploration |N/M|N/M|N/M|N/M|N/M|N/M| N | S |
+---------------------------------+---+---+---+---+---+---+---+---+ +---------------------------------+---+---+---+---+---+---+---+---+
| Path Selection | N |S/N| N |S/N| N |S/N| N |S/N| | Path Selection | N |S/N| N |S/N| N |S/N| N |S/N|
+---------------------------------+---+---+---+---+---+---+---+---+ +---------------------------------+---+---+---+---+---+---+---+---+
| Re-Homing |N/M| S |N/M| S |N/M| S |N/M| S | | Re-Homing |N/M| S |N/M| S |N/M| S |N/M| S |
+---------------------------------+---+---+---+---+---+---+---+---+ +---------------------------------+---+---+---+---+---+---+---+---+
| Ingress Filtering | . | . | . | t | . | . | . | N | | Ingress Filtering | . | . | . | t | . | . | . | N |
+---------------------------------+---+---+---+---+---+---+---+---+ +---------------------------------+---+---+---+---+---+---+---+---+
| Media Detection | D | D | D | D | D | D | D | D |
+---------------------------------+---+---+---+---+---+---+---+---+
| HA Synchronization | . | . |N/M|N/M| . | . |N/M|N/M| | HA Synchronization | . | . |N/M|N/M| . | . |N/M|N/M|
+---------------------------------+---+---+---+---+---+---+---+---+ +---------------------------------+---+---+---+---+---+---+---+---+
| MR Synchronization | . | . | . | . | G | G | G | G | | MR Synchronization | . | . | . | . | G | G | G | G |
+---------------------------------+---+---+---+---+---+---+---+---+ +---------------------------------+---+---+---+---+---+---+---+---+
| Prefix Delegation | . | . | N | N | N | N | N | N | | Prefix Delegation | . | . | N | N | N | N | N | N |
+---------------------------------+---+---+---+---+---+---+---+---+ +---------------------------------+---+---+---+---+---+---+---+---+
| Multiple Binding/Registrations | M | M | M | M | M | M | M | M | | Multiple Binding/Registrations | M | M | M | M | M | M | M | M |
+---------------------------------+---+---+---+---+---+---+---+---+ +---------------------------------+---+---+---+---+---+---+---+---+
| Source Address Selection | . | G | . | G | . | G | . | G | | Source Address Selection | . | G | . | G | . | G | . | G |
+---------------------------------+---+---+---+---+---+---+---+---+ +---------------------------------+---+---+---+---+---+---+---+---+
| Loop Prevention in Nested NEMO | N | N | N | N | N | N | N | N | | Loop Prevention in Nested NEMO | N | N | N | N | N | N | N | N |
+---------------------------------+---+---+---+---+---+---+---+---+ +---------------------------------+---+---+---+---+---+---+---+---+
| Prefix Ownership | . | . | . | . | N | . | N | . | | Prefix Ownership | . | . | . | . | N | . | N | . |
+---------------------------------+---+---+---+---+---+---+---+---+
| Preference Settings | G | G | G | G | G | G | G | G |
+=================================================================+ +=================================================================+
N - NEMO Specific M - MIPv6 Specific G - Generic IPv6 N - NEMO Specific M - MIPv6 Specific G - Generic IPv6
S - SHIM6 WG D - DNA WG S - SHIM6 WG D - DNA WG
. - Not an Issue t - trivial . - Not an Issue t - trivial
* - Fault Tolerance is a combination of Failure Detection, Path * - Fault Tolerance is a combination of Failure Detection, Path
Exploration, Path Selection, and Re-Homing Exploration, Path Selection, and Re-Homing
Figure 10: Matrix of NEMO Multihoming Issues
The above matrix serves to identify which issues are NEMO-specific,
and which concern other Working Groups. The readers are reminded
that this matrix is a simplification of Section 4 as subtle details
are not represented in Figure 10.
As can be seen from Figure 10, the following have some concerns which
are specific to NEMO: Failure Detection, Path Exploration, Path
Selection, Re-Homing, Ingress Filtering, HA Synchronization, Prefix
Delegation, Loop Prevention in Nested NEMO, and Prefix Ownership.
Based on the authors' best knowledge of the possible deployments of
NEMO, it is recommended that:
o Failure Detection, Path Exploration, Path Selection, and Re-Homing
be worked on by the Monami6 WG
Although Path Selection is reflected in Figure 10 as NEMO-
Specific, the technical consideration of the problem is believed
to be quite similar to the selection of multiple paths in mobile
nodes. As such, we would recommend that such issues be taken into
consideration by the Monami6 WG. In addition, a Shim6 mechanism
is expected to be useful for the issues of Path Selection and Re-
Homing. It is thus our recommendation that the NEMO WG would re-
evaluate the applicability of mechanisms developed by the Shim6
and Monami6 WGs when they are available.
o Ingress Filtering on the (n,n,n) configuration be solved by the
NEMO WG
This problem is clearly defined, and can be solved by the WG.
Deployment of the (n,n,n) NEMO can be envisioned on vehicles for
mass transportation (such as buses, trains) where different
service providers may install their own mobile routers on the
vehicle/vessel.
It should be noted that the Shim6 WG may be developing a mechanism
for overcoming ingress filtering in a more general sense. We thus
recommend that the NEMO WG to concentrate only on the (n,n,n)
configuration should the WG decide to work on this issue.
o Home Agent Synchronization and Multiple Bindings/Registrations be
worked on by the Monami6 WG
These are problems that will be addressed by the Monami6 WG, and
it is believed that a solution that applies to mobile hosts would
applies to mobile routers running the NEMO Basic Support protocol.
o Prefix Delegation be reviewed and checked by the NEMO WG
There is already a WG draft providing prefix delegation
functionality to NEMO Basic Support. The WG should review the
draft and verified that it addresses any concern a multihomed NEMO
might have, as discussed in Section 4.5.
o Loop Prevention in Nested NEMO be worked on by the NEMO WG
Having a loop in nested NEMO is a real and serious problem,
especially when connections are wireless (therefore there is no
physical structure to avoid loops).
o Prefix Ownership should be considered by the vendors and operators
The problem of Prefix Ownership only occurs when a mobile network
with multiple MRs and a single MNP can arbitrarily join and split.
Vendors and operators of mobile networks are encouraged to input
their views on the applicability of deploying such kind of mobile
networks.
6. Conclusion 6. Conclusion
This memo is an analysis of multihoming in the context of network This memo is an analysis of multihoming in the context of network
mobility under the operation of NEMO Basic Support. The purpose of mobility under the operation of NEMO Basic Support. The purpose of
this memo is to investigate issues related to such a bi-directional this memo is to investigate issues related to such a bi-directional
tunneling mechanism when mobile networks are multihomed. For doing tunneling mechanism when mobile networks are multihomed. For doing
so, a taxonomy was proposed to classify the mobile networks in eight so, a taxonomy was proposed to classify the mobile networks in eight
possible multihomed configurations. The issue were explained and possible multihomed configurations. The issue were explained and
were then summarized in a table showing under which multihoming were then summarized in a table showing under which multihoming
configuration it applies, and which IETF working group is the best configuration it applies, and which IETF working group is the best
skipping to change at page 28, line 7 skipping to change at page 30, line 7
9. Acknowledgments 9. 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 - 61st IETF Meetings. those who have suggested directions in the 56th - 61st IETF Meetings.
The initial evaluation of NEMO Basic Support is a contribution from The initial evaluation of NEMO Basic Support is a contribution from
Julien Charbon. Julien Charbon.
10. References 10. References
10.1 Normative References 10.1. Normative References
[1] Ernst, T., "Network Mobility Support Goals and Requirements", [1] Ernst, T., "Network Mobility Support Goals and Requirements",
draft-ietf-nemo-requirements-04 (work in progress), draft-ietf-nemo-requirements-05 (work in progress),
February 2005. October 2005.
[2] Manner, J. and M. Kojo, "Mobility Related Terminology", [2] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 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-03 (work in progress), draft-ietf-nemo-terminology-04 (work in progress), October 2005.
February 2005.
[4] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, [4] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005. 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.
10.2 Informative References 10.2. Informative References
[6] Ernst, T., "Goals and Benefits of Multihoming", [6] Ernst, T., Montavont, N., Wakikawa, R., Paik, E., Ng, C.,
draft-multihoming-generic-goals-and-benefits-00 (work in Kuladinithi, K., and T. Noel, "Goals and Benefits of
progress), February 2004. Multihoming", draft-multihoming-generic-goals-and-benefits-02
(work in progress), October 2005.
[7] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. [7] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K.
Kuladinithi, "Analysis of Multihoming in Mobile IPv6", Kuladinithi, "Analysis of Multihoming in Mobile IPv6",
draft-montavont-mobileip-multihoming-pb-statement-04 (work in draft-montavont-mobileip-multihoming-pb-statement-05 (work in
progress), June 2005. progress), October 2005.
[8] Arkko, J., "Failure Detection and Locator Selection Design [8] Arkko, J., "Failure Detection and Locator Pair Exploration
Considerations", draft-ietf-shim6-failure-detection-00 (work in Design for IPv6 Multihoming",
progress), July 2005. draft-ietf-shim6-failure-detection-01 (work in progress),
October 2005.
[9] Beijnum, I., "Shim6 Reachability Detection", [9] Beijnum, I., "Shim6 Reachability Detection",
draft-ietf-shim6-reach-detect-00 (work in progress), July 2005. draft-ietf-shim6-reach-detect-00 (work in progress), July 2005.
[10] Yegin, A., "Link-layer Event Notifications for Detecting [10] Yegin, A., "Link-layer Event Notifications for Detecting
Network Attachments", draft-ietf-dna-link-information-01 (work Network Attachments", draft-ietf-dna-link-information-02 (work
in progress), February 2005. in progress), July 2005.
[11] Narayanan, S., "Detecting Network Attachment in IPv6 - Best [11] Narayanan, S., "Detecting Network Attachment in IPv6 - Best
Current Practices for hosts.", draft-ietf-dna-hosts-00 (work in Current Practices for hosts.", draft-ietf-dna-hosts-01 (work in
progress), April 2005. progress), July 2005.
[12] Yegin, A., "Link-layer Hints for Detecting Network [12] Yegin, A., "Link-layer Hints for Detecting Network
Attachments", draft-yegin-dna-l2-hints-01 (work in progress), Attachments", draft-yegin-dna-l2-hints-01 (work in progress),
February 2004. February 2004.
[13] Yegin, A., "Supporting Optimized Handover for IP Mobility [13] 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. draft-manyfolks-l2-mobilereq-02 (work in progress), July 2002.
[14] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery [14] Narayanan, S., "Detecting Network Attachment in IPv6 - Best
Current Practices for Routers", draft-ietf-dna-routers-00 (work
in progress), July 2005.
[15] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998. for IP Version 6 (IPv6)", RFC 2461, December 1998.
[15] Bagnulo, M. and J. Arkko, "Functional decomposition of the [16] Bagnulo, M. and J. Arkko, "Functional decomposition of the
multihoming protocol", draft-ietf-shim6-functional-dec-00 (work multihoming protocol", draft-ietf-shim6-functional-dec-00 (work
in progress), July 2005. in progress), July 2005.
[16] Ferguson, P. and D. Senie, "Network Ingress Filtering: [17] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[17] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [18] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
[18] Narayanan, S., "Detecting Network Attachment in IPv6 - Best [19] Huitema, C., "Ingress filtering compatibility for IPv6
Current Practices for Routers", draft-ietf-dna-routers-00 (work multihomed sites", draft-huitema-shim6-ingress-filtering-00
in progress), July 2005. (work in progress), September 2005.
[19] Wakikawa, R., Devarapalli, V., and P. Thubert, "Inter Home [20] Wakikawa, R., Devarapalli, V., and P. Thubert, "Inter Home
Agents Protocol (HAHA)", draft-wakikawa-mip6-nemo-haha-01 (work Agents Protocol (HAHA)", draft-wakikawa-mip6-nemo-haha-01 (work
in progress), February 2004. in progress), February 2004.
[20] Koh, B., Ng, C., and J. Hirano, "Dynamic Inter Home Agent [21] Koh, B., Ng, C., and J. Hirano, "Dynamic Inter Home Agent
Protocol", draft-koh-mip6-nemo-dhap-00 (work in progress), Protocol", draft-koh-mip6-nemo-dhap-00 (work in progress),
July 2004. July 2004.
[21] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix [22] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix
Delegation", RFC 3769, June 2004. Delegation", RFC 3769, June 2004.
[22] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO", [23] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO",
draft-droms-nemo-dhcpv6-pd-02 (work in progress), April 2005. draft-droms-nemo-dhcpv6-pd-02 (work in progress), April 2005.
[23] Wakikawa, R., Uehara, K., Ernst, T., and K. Nagami, "Multiple [24] Kniveton, T. and P. Thubert, "Mobile Network Prefix
Care-of Addresses Registration", Delegation", draft-ietf-nemo-prefix-delegation-00 (work in
progress), August 2005.
[25] Wakikawa, R., "Multiple Care-of Addresses Registration",
draft-wakikawa-mobileip-multiplecoa-04 (work in progress), draft-wakikawa-mobileip-multiplecoa-04 (work in progress),
June 2005. June 2005.
[24] Draves, R., "Default Address Selection for Internet Protocol [26] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003. version 6 (IPv6)", RFC 3484, February 2003.
[25] Thubert, P., "Nested Nemo Tree Discovery", [27] Thubert, P., "Nested Nemo Tree Discovery",
draft-thubert-tree-discovery-02 (work in progress), July 2005. draft-thubert-tree-discovery-02 (work in progress), July 2005.
[26] Kumazawa, M., "Token based Duplicate Network Detection for [28] Kumazawa, M., "Token based Duplicate Network Detection for
split mobile network (Token based DND)", split mobile network (Token based DND)",
draft-kumazawa-nemo-tbdnd-02 (work in progress), July 2005. draft-kumazawa-nemo-tbdnd-02 (work in progress), July 2005.
[27] Choi, S., "Threat for Multi-homed Mobile Networks",
draft-cho-nemo-threat-multihoming-00 (work in progress),
February 2004.
[28] Montavont, N., Noel, T., and M. Kassi-Lahlou, "MIPv6 for
Multiple Interfaces", draft-montavont-mobileip-mmi-00 (work in
progress), July 2002.
[29] Draves, R. and D. Thaler, "Default Router Preferences and More-
Specific Routes", draft-ietf-ipv6-router-selection-07 (work in
progress), January 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: chanwah.ng@sg.panasonic.com
Eun Kyoung Paik
KT
Portable Internet Team, Convergence Lab., KT
17 Woomyeon-dong, Seocho-gu
Seoul 137-792
Korea
Phone: +82-2-526-5233
Fax: +82-2-526-5200
Email: euna@kt.co.kr
URI: http://mmlab.snu.ac.kr/~eun/
Thierry Ernst
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/
Marcelo Bagnulo
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 8837
Email: marcelo@it.uc3m.es
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
control and ownership of the HA(s) and MR(s), there are two different 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 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 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 entities. We called the first possibility the 'ISP Model', and the
second the 'Subscriber/Provider Model'. second the 'Subscriber/Provider Model'.
A.1.1 ISP Model A.1.1. ISP Model
The case of the HA(s) and MR(s) are controlled by the same entity can 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 be best illustrated as an Internet Service Provider (ISP) installing
mobile routers on trains, ships or planes. It is up to the ISP to mobile routers on trains, ships or planes. It is up to the ISP to
deploy a certain configuration of mobile network; all 8 deploy a certain configuration of mobile network; all 8
configurations as described in the Configuration-Oriented Approach configurations as described in the Configuration-Oriented Approach
are possible. In the remaining portion of this document, when are possible. In the remaining portion of this document, when
specifically referring to a mobile network configuration that is specifically referring to a mobile network configuration that is
controlled by a single entity, we will add an 'ISP' prefix: for controlled by a single entity, we will add an 'ISP' prefix: for
example: ISP-(1,1,1) or ISP-(1,N,N). example: ISP-(1,1,1) or ISP-(1,N,N).
skipping to change at page 33, line 6 skipping to change at page 34, line 6
maintaining stale routes. Such "tunnel liveness" may be tested by maintaining stale routes. Such "tunnel liveness" may be tested by
sending heartbeats signals from MR(s) to the HA(s). A possibility is sending heartbeats signals from MR(s) to the HA(s). A possibility is
to simulate heartbeats using Binding Updates messages by controlling to simulate heartbeats using Binding Updates messages by controlling
the "Lifetime" field of the Binding Acknowledgment message to force the "Lifetime" field of the Binding Acknowledgment message to force
the MR to send Binding Update messages at regular interval. However, the MR to send Binding Update messages at regular interval. However,
a more appropriate tool might be the Binding Refresh Request message, a more appropriate tool might be the Binding Refresh Request message,
though conformance to the Binding Refresh Request message may be less though conformance to the Binding Refresh Request message may be less
strictly enforced in implementations since it serves a somewhat strictly enforced in implementations since it serves a somewhat
secondary role when compared to Binding Update messages. secondary role when compared to Binding Update messages.
A.1.2 Subscriber/Provider Model A.1.2. Subscriber/Provider Model
The case of the HA(s) and MR(s) are controlled by the separate The case of the HA(s) and MR(s) are controlled by the separate
entities can be best illustrated with a subscriber/provider model, entities can be best illustrated with a subscriber/provider model,
where the MRs belongs to a single subscriber and subscribes to one or 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: more ISPs for HA services. There is two sub-categories in this case:
when the subscriber subscribes to a single ISP, and when the when the subscriber subscribes to a single ISP, and when the
subscriber subscribes to multiple ISPs. In the remaining portion of subscriber subscribes to multiple ISPs. In the remaining portion of
this document, when specifically referring to a mobile network this document, when specifically referring to a mobile network
configuration that is in the subscriber/provider model where the configuration that is in the subscriber/provider model where the
subscriber subscribes to only one ISP, we will add an 'S/P' prefix: subscriber subscribes to only one ISP, we will add an 'S/P' prefix:
skipping to change at page 35, line 5 skipping to change at page 36, line 5
Multiple MNPs Multiple MNPs
When the HA(s) and MR(s) are controlled by different entities, it is 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 more likely the scenario where the MR is controlled by one entity
(i.e. the subscriber), and the MR is establishing multiple bi- (i.e. the subscriber), and the MR is establishing multiple bi-
directional tunnels to one or more HA(s) provided by one or more 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 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 bi-directional tunnel, since ISP would most certainly wish to retain
full control of its routing domain. full control of its routing domain.
A.2 Problem-Oriented Approach A.2. Problem-Oriented Approach
A third approach is proposed by Pascal Thubert (Cisco System). This A third approach is proposed by Pascal Thubert (Cisco System). This
focused on the problems of multihomed mobile networks rather than the focused on the problems of multihomed mobile networks rather than the
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
skipping to change at page 36, line 19 skipping to change at page 37, line 19
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
independent route to the global Internet, or by another active egress independent route to the global Internet, or by another active egress
interface the MR itself possess. If such an alternate route exists, interface the MR itself possess. If such an alternate route exists,
the MR should re-establish the bi-directional tunnel using this the MR should re-establish the bi-directional tunnel using this
alternate route. alternate route.
In the remaining part of this section, we will attempt to investigate In the remaining part of this Appendix, we will attempt to
methods of performing such re-establishment of bi-directional investigate methods of performing such re-establishment of bi-
tunnels. This method of tunnel re-estblishment is particularly directional tunnels. This method of tunnel re-establishment is
useful for the (*,n,n) NEMO configuration. It is not the objective particularly useful for the (*,n,n) NEMO configuration. The method
of this memo to specify a new protocol specifically tailored to described is by no means complete and merely serves as a suggestion
provide this form of re- establishments. Instead, we will limit on how to approach the problem. It is also not the objective to
ourselves to currently available mechanisms specified in Mobile IPv6 specify a new protocol specifically tailored to provide this form of
[5] and Neighbor Discovery in IPv6 [14]. re- establishments. Instead, we will limit ourselves to currently
available mechanisms specified in Mobile IPv6 [5] and Neighbor
Discovery in IPv6 [15].
B.1 Detecting Presence of Alternate Routes B.1. Detecting Presence of Alternate Routes
To actively utilize the robustness provided by multihoming, a MR must To actively utilize the robustness provided by multihoming, a MR must
first be capable of detecting alternate routes. This can be manually first be capable of detecting alternate routes. This can be manually
configured into the MR by the administrators if the configuration of configured into the MR by the administrators if the configuration of
the mobile network is relatively static. It is however highly the mobile network is relatively static. It is however highly
desirable for MRs to be able to discover alternate routes desirable for MRs to be able to discover alternate routes
automatically for greater flexibility. automatically for greater flexibility.
The case where a MR possesses multiple egress interface (bound to the 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 same HA or otherwise) should be trivial, since the MR should be able
to "realize" it has multiple routes to the global Internet. to "realize" it has multiple routes to the global Internet.
In the case where multiple MRs are on the mobile network, each MR has 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 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 Router Advertisement message on its *ingress* interfaces. When a MR
receives a Router Advertisement message with a non-zero Router receives a Router Advertisement message with a non-zero Router
Lifetime field from one of its ingress interfaces, it knows that Lifetime field from one of its ingress interfaces, it knows that
another MR which can provide an alternate route to the global another MR which can provide an alternate route to the global
Internet is present in the mobile network. Internet is present in the mobile network.
B.2 Re-Establishment of Bi-Directional Tunnels B.2. Re-Establishment of Bi-Directional Tunnels
When a MR detects that the link by which its current bi-directional 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- tunnel with its HA is using is down, it needs to re-establish the bi-
directional tunnel using an alternate route detected. We consider directional tunnel using an alternate route detected. We consider
two separate cases here: firstly, the alternate route is provided by two separate cases here: firstly, the alternate route is provided by
another egress interface that belongs to the MR; secondly, the another egress interface that belongs to the MR; secondly, the
alternate route is provided by another MR connected to the mobile alternate route is provided by another MR connected to the mobile
network. We refer to the former case as an alternate route provided network. We refer to the former case as an alternate route provided
by an alternate egress interface, and the latter case as an alternate by an alternate egress interface, and the latter case as an alternate
route provided by an alternate MR. route provided by an alternate MR.
B.2.1 Using Alternate Egress Interface B.2.1. Using Alternate Egress Interface
When an egress interface of a MR loses the connection to the global When an egress interface of a MR loses the connection to the global
Internet, the MR can make use of its alternate egress interface Internet, the MR can make use of its alternate egress interface
should it possess multiple egress interfaces. The most direct way to 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 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 agent of the failed interface using the Care-of Address assigned to
the alternate interface in order to re-establish the bi-directional the alternate interface in order to re-establish the bi-directional
tunneling using the Care-of Address on the alternate egress tunneling using the Care-of Address on the alternate egress
interface. After a successful binding update, the MR encapsulates interface. After a successful binding update, the MR encapsulates
outgoing packets through the bi-directional tunnel using the outgoing packets through the bi-directional tunnel using the
alternate egress interface. alternate egress interface.
The idea is to use the global address (most likely a Care-of Address) 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) assigned to an alternate egress interface as the new (back-up)
Care-of Address of the mobile router to re-establish the bi- Care-of Address of the mobile router to re-establish the bi-
directional tunneling with its home agent. directional tunneling with its home agent.
B.2.2 Using Alternate Mobile Router B.2.2. Using Alternate Mobile Router
When the MR loses a connection to the global Internet, the MR can 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- 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 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 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 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 using the Care-of Address obtained from the alternate MR. From then
on, the MR can encapsulates outgoing packets through the bi- on, the MR can encapsulates outgoing packets through the bi-
directional tunnel using via the alternate MR. directional tunnel using via the alternate MR.
The idea is to obtain a Care-of Address from the alternate MR and use 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 this as the new (back-up) Care-of Address of the MR to re-establish
the bi-directional tunneling with its HA. the bi-directional tunneling with its HA.
Note that every packet sent between MNNs and their correspondent Note that every packet sent between MNNs and their correspondent
nodes will experience two levels of encapsulation. First level of nodes will experience two levels of encapsulation. First level of
tunneling occurs between a MR which the MNN uses as its default 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 router and the MR's HA. The second level of tunneling occurs between
the alternate MR and its HA. the alternate MR and its HA.
B.3 To Avoid Tunneling Loop B.3. To Avoid Tunneling Loop
The method of re-establishing the bi-directional tunnel as described The method of re-establishing the bi-directional tunnel as described
in Appendix B.2 may lead to infinite loops of tunneling. This in Appendix B.2 may lead to infinite loops of tunneling. This
happens when two MRs on a mobile network lose connection to the 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 global Internet at the same time and each MR tries to re-establish
bi-directional tunnel using the other MR. We refer to this bi-directional tunnel using the other MR. We refer to this
phenomenon as tunneling loop. phenomenon as tunneling loop.
One approach to avoid tunneling loop is for a MR that has lost 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 connection to the global Internet to insert an option into the Router
Advertisement message it broadcasts periodically. This option serves Advertisement message it broadcasts periodically. This option serves
to notify other MRs on the link that the sender no longer provides to notify other MRs on the link that the sender no longer provides
global connection. Note that setting a zero Router Lifetime field global connection. Note that setting a zero Router Lifetime field
will not work well since it will cause MNNs that are attached to the 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, MR to stop using the MR as their default router too (in which case,
things are back to square one). things are back to square one).
B.4. Points of Considerations
This method of using tunnel re-establishments is by no means a
complete solution. There are still points to consider to develop it
into a fully functional solution. For instance, in Appendix B.1, it
was suggested that MR detects the presence of other MRs using Router
Advertisements. However, Router Advertisements are link scoped, so
when there is more than one link, some information may be lost. For
instance, suppose a case where there is three MRs and three different
prefixes and each MR is in a different link with regular routers in
between. Suppose now that only a single MR is working, how do the
other MRs identify which prefix they have to use to configure the new
CoA? In this case, there are three prefixes being announced and a MR
whose link has failed, knows that his prefix is not to be used, but
it has not enough information to decide which one of the other two
prefixes to use to configure the new CoA. In such cases, a mechanism
is needed to allow a MR to withdraw its own prefix when it discovers
that its link is no longer working.
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-03 to -04:
* Updated Section 3: "Deployment Scenarios and Prerequisites"
* Modifications to Section 4:
+ Removed "Media Detection" and moved the relevant concerns to
"Path Exploration"
+ Added new "Preference Settings" issue
+ Various text clean-ups in mopst of the sub-sections
* Modifications to Section 5:
+ Changed Section 5: "Matrix" to "Recommendations to the
Working Group"
+ Identifies which are the issues that are important, and made
recommendations as to how to resolve these multihoming
issues
* Addressed Issue #12: Added Appendix B.4: "Points of
Considerations" to document the concerns raised for this tunnel
re-eatblishment mechanism.
o Changes from draft-ietf-nemo-multihoming-issues-02 to -03: o Changes from draft-ietf-nemo-multihoming-issues-02 to -03:
* Enlisted Marcelo Bagnulo as co-author * Enlisted Marcelo Bagnulo as co-author
* Restructuring of Section 4: * Restructuring of Section 4:
+ Re-named 'Path Survival' to 'Fault Tolerance' + Re-named 'Path Survival' to 'Fault Tolerance'
+ Moved 'Path Failure Detection' and 'Path Selection' as sub- + Moved 'Path Failure Detection' and 'Path Selection' as sub-
issues of 'Fault Tolerance' issues of 'Fault Tolerance'
skipping to change at page 39, line 45 skipping to change at page 41, line 22
* Minor updates on references. * 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 Sect 2.3: Removed text on assumption
* Addressed Issue #6 in Section 3.1: Added benefits * Addressed Issue #6 in Sect 3.1 "Deployment Scenarios": Added
benefits
* Addressed Issue #7 in Section 3.2: Modified text * Addressed Issue #7 in Sect 3.2 "Prerequisites": Modified text
* Addressed Issue #9 in Section 4.2: Modified text * Addressed Issue #9 in Sect 4.3 "Ingress Filtering": Modified
* Addressed Issue #10 in Section 4.1.1: Added paragraph on other text
* Addressed Issue #10 in Sect 4.4: Added paragraph on other
failure modes failure modes
* Addressed Issue #10: New Section 4.3 on media detection * Addressed Issue #10: New Sect 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 Section 4: "Problem Statement"
* Merged "Evaluation" Section into "Problem Statement" * Merged "Evaluation" Section into Section 4: "Problem Statement"
(Section 4)
* Cleaned up description in "Classification" (Section 2), and * Cleaned up description in Section 2: "Classification", 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 Section 2: "Deployment Scenarios and
(Section 3), and created the "Prerequisites" sub-section. Prerequisites", 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)) Section 4: "Problem Statement")
* Included conclusions from * Included conclusions from
draft-charbon-nemo-multihoming-evaluation-00 draft-charbon-nemo-multihoming-evaluation-00
* Re-organized some part of "Benefits/Issues of Multihoming in * Re-organized some part of "Benefits/Issues of Multihoming in
NEMO" to "Problem Statement" (Section 4) NEMO" to Section 4: "Problem Statement"
* Removed lots of text to be in sync with [6]. * Removed lots of text to be in sync with [6].
* Title changed from "Multihoming Issues in NEMO Basic Support" * Title changed from "Multihoming Issues in NEMO Basic Support"
to "Analysis of Multihoming in NEMO" to "Analysis of Multihoming in NEMO"
* Changed (w,x,y) to (x,y,z) in taxonomy. * Changed (w,x,y) to (x,y,z) in taxonomy.
* Moved alternative approaches of classification to Appendix * Moved alternative approaches of classification to Appendix
* Creation of this Change-Log itself ;-) * Creation of this Change-Log itself ;-)
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: chanwah.ng@sg.panasonic.com
Eun Kyoung Paik
KT
Portable Internet Team, Convergence Lab., KT
17 Woomyeon-dong, Seocho-gu
Seoul 137-792
Korea
Phone: +82-2-526-5233
Fax: +82-2-526-5200
Email: euna@kt.co.kr
URI: http://mmlab.snu.ac.kr/~eun/
Thierry Ernst
Keio University / WIDE
Jun Murai Lab., Keio University.
K-square Town Campus, 1488-8 Ogura, Saiwa-Ku
Kawasaki, Kanagawa 212-0054
Japan
Phone: +81-44-580-1600
Fax: +81-44-580-1437
Email: ernst@sfc.wide.ad.jp
URI: http://www.sfc.wide.ad.jp/~ernst/
Marcelo Bagnulo
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 8837
Email: marcelo@it.uc3m.es
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 158 change blocks. 
410 lines changed or deleted 579 lines changed or added

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