Network Working Group C. Ng
Request for Comments: 4980 Panasonic Singapore Labs
Category: Informational T. Ernst
INRIA
E. Paik
KT
M. Bagnulo
UC3M
October 2007
Network Working Group C. Ng
Request for Comments: 4980 Panasonic Singapore Labs
Category: Informational T. Ernst
INRIA
E. Paik
KT
M. Bagnulo
UC3M
October 2007
Analysis of Multihoming in Network Mobility Support
网络移动性保障中的多宿分析
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Abstract
摘要
This document is an analysis of multihoming in the context of network mobility (NEMO) in IPv6. As there are many situations in which mobile networks may be multihomed, a taxonomy is proposed to classify the possible configurations. The possible deployment scenarios of multihomed mobile networks are described together with the associated issues when network mobility is supported by RFC 3963 (NEMO Basic Support). Recommendations are offered on how to address these issues.
本文档是在IPv6中的网络移动（NEMO）环境下对多宿进行的分析。由于在许多情况下移动网络可能是多址的，因此提出了一种分类法来对可能的配置进行分类。当RFC 3963（NEMO基本支持）支持网络移动性时，描述了多宿移动网络的可能部署场景以及相关问题。就如何解决这些问题提出了建议。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Classification . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. (1,1,1): Single MR, Single HA, Single MNP . . . . . . . . 6
2.2. (1,1,n): Single MR, Single HA, Multiple MNPs . . . . . . . 6
2.3. (1,n,1): Single MR, Multiple HAs, Single MNP . . . . . . . 7
2.4. (1,n,n): Single MR, Multiple HAs, Multiple MNPs . . . . . 8
2.5. (n,1,1): Multiple MRs, Single HA, Single MNP . . . . . . . 8
2.6. (n,1,n): Multiple MRs, Single HA, Multiple MNPs . . . . . 9
2.7. (n,n,1): Multiple MRs, Multiple HAs, Single MNP . . . . . 9
2.8. (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Classification . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. (1,1,1): Single MR, Single HA, Single MNP . . . . . . . . 6
2.2. (1,1,n): Single MR, Single HA, Multiple MNPs . . . . . . . 6
2.3. (1,n,1): Single MR, Multiple HAs, Single MNP . . . . . . . 7
2.4. (1,n,n): Single MR, Multiple HAs, Multiple MNPs . . . . . 8
2.5. (n,1,1): Multiple MRs, Single HA, Single MNP . . . . . . . 8
2.6. (n,1,n): Multiple MRs, Single HA, Multiple MNPs . . . . . 9
2.7. (n,n,1): Multiple MRs, Multiple HAs, Single MNP . . . . . 9
2.8. (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs . . . . 10
3. Deployment Scenarios and Prerequisites . . . . . . . . . . . . 11
3.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . . 11
3.2. Prerequisites . . . . . . . . . . . . . . . . . . . . . . 13
4. Multihoming Issues . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Fault Tolerance . . . . . . . . . . . . . . . . . . . . . 14
4.1.1. Failure Detection . . . . . . . . . . . . . . . . . . 15
4.1.2. Path Exploration . . . . . . . . . . . . . . . . . . . 16
4.1.3. Path Selection . . . . . . . . . . . . . . . . . . . . 17
4.1.4. Re-Homing . . . . . . . . . . . . . . . . . . . . . . 19
4.2. Ingress Filtering . . . . . . . . . . . . . . . . . . . . 19
4.3. HA Synchronization . . . . . . . . . . . . . . . . . . . . 21
4.4. MR Synchronization . . . . . . . . . . . . . . . . . . . . 22
4.5. Prefix Delegation . . . . . . . . . . . . . . . . . . . . 23
4.6. Multiple Bindings/Registrations . . . . . . . . . . . . . 23
4.7. Source Address Selection . . . . . . . . . . . . . . . . . 23
4.8. Loop Prevention in Nested Mobile Networks . . . . . . . . 24
4.9. Prefix Ownership . . . . . . . . . . . . . . . . . . . . . 24
4.10. Preference Settings . . . . . . . . . . . . . . . . . . . 25
5. Recommendations to the Working Group . . . . . . . . . . . . . 26
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Normative References . . . . . . . . . . . . . . . . . . . 29
9.2. Informative References . . . . . . . . . . . . . . . . . . 29
Appendix A. Alternative Classifications Approach . . . . . . . . 32
A.1. Ownership-Oriented Approach . . . . . . . . . . . . . . . 32
A.1.1. ISP Model . . . . . . . . . . . . . . . . . . . . . . 32
A.1.2. Subscriber/Provider Model . . . . . . . . . . . . . . 33
A.2. Problem-Oriented Approach . . . . . . . . . . . . . . . . 34
Appendix B. Nested Tunneling for Fault Tolerance . . . . . . . . 35
B.1. Detecting Presence of Alternate Routes . . . . . . . . . . 35
B.2. Re-Establishment of Bi-Directional Tunnels . . . . . . . . 36
B.2.1. Using Alternate Egress Interface . . . . . . . . . . . 36
B.2.2. Using Alternate Mobile Router . . . . . . . . . . . . 36
B.3. To Avoid Tunneling Loop . . . . . . . . . . . . . . . . . 37
B.4. Points of Considerations . . . . . . . . . . . . . . . . . 37
3. Deployment Scenarios and Prerequisites . . . . . . . . . . . . 11
3.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . . 11
3.2. Prerequisites . . . . . . . . . . . . . . . . . . . . . . 13
4. Multihoming Issues . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Fault Tolerance . . . . . . . . . . . . . . . . . . . . . 14
4.1.1. Failure Detection . . . . . . . . . . . . . . . . . . 15
4.1.2. Path Exploration . . . . . . . . . . . . . . . . . . . 16
4.1.3. Path Selection . . . . . . . . . . . . . . . . . . . . 17
4.1.4. Re-Homing . . . . . . . . . . . . . . . . . . . . . . 19
4.2. Ingress Filtering . . . . . . . . . . . . . . . . . . . . 19
4.3. HA Synchronization . . . . . . . . . . . . . . . . . . . . 21
4.4. MR Synchronization . . . . . . . . . . . . . . . . . . . . 22
4.5. Prefix Delegation . . . . . . . . . . . . . . . . . . . . 23
4.6. Multiple Bindings/Registrations . . . . . . . . . . . . . 23
4.7. Source Address Selection . . . . . . . . . . . . . . . . . 23
4.8. Loop Prevention in Nested Mobile Networks . . . . . . . . 24
4.9. Prefix Ownership . . . . . . . . . . . . . . . . . . . . . 24
4.10. Preference Settings . . . . . . . . . . . . . . . . . . . 25
5. Recommendations to the Working Group . . . . . . . . . . . . . 26
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Normative References . . . . . . . . . . . . . . . . . . . 29
9.2. Informative References . . . . . . . . . . . . . . . . . . 29
Appendix A. Alternative Classifications Approach . . . . . . . . 32
A.1. Ownership-Oriented Approach . . . . . . . . . . . . . . . 32
A.1.1. ISP Model . . . . . . . . . . . . . . . . . . . . . . 32
A.1.2. Subscriber/Provider Model . . . . . . . . . . . . . . 33
A.2. Problem-Oriented Approach . . . . . . . . . . . . . . . . 34
Appendix B. Nested Tunneling for Fault Tolerance . . . . . . . . 35
B.1. Detecting Presence of Alternate Routes . . . . . . . . . . 35
B.2. Re-Establishment of Bi-Directional Tunnels . . . . . . . . 36
B.2.1. Using Alternate Egress Interface . . . . . . . . . . . 36
B.2.2. Using Alternate Mobile Router . . . . . . . . . . . . 36
B.3. To Avoid Tunneling Loop . . . . . . . . . . . . . . . . . 37
B.4. Points of Considerations . . . . . . . . . . . . . . . . . 37
The design goals and objectives of Network Mobility (NEMO) support in IPv6 are identified in [1], while the terminology is described in [2] and [3]. NEMO Basic Support (RFC 3963) [4] is the solution proposed by the NEMO Working Group to provide continuous Internet connectivity to nodes located in an IPv6 mobile network, e.g., like in an in-vehicle embedded IP network. The NEMO Basic Support solution does so by setting up bi-directional tunnels between the mobile routers (MRs) connecting the mobile network (NEMO) to the Internet and their respective home agents (HAs), much like how this is done in Mobile IPv6 [5], the solution for host mobility support. NEMO Basic Support is transparent to nodes located behind the MR (i.e., the mobile network nodes, or MNNs), and as such, does not require MNNs to take any action in the mobility management.
IPv6中网络移动（NEMO）支持的设计目标和目的在[1]中确定，而术语在[2]和[3]中描述。NEMO基本支持（RFC 3963）[4]是NEMO工作组提出的解决方案，旨在为位于IPv6移动网络中的节点提供连续的互联网连接，例如，与车载嵌入式IP网络类似。NEMO基本支持解决方案通过在将移动网络（NEMO）连接到互联网的移动路由器（MRs）与其各自的家庭代理（HAs）之间建立双向隧道来实现这一点，这与移动IPv6[5]中的做法非常相似，后者是主机移动性支持的解决方案。NEMO基本支持对位于MR后面的节点（即移动网络节点或MNN）是透明的，因此不要求MNN在移动性管理中采取任何行动。
However, mobile networks are typically connected by means of wireless and thus less reliable links; there could also be many nodes behind the MR. A loss of connectivity or a failure to connect to the Internet has thus a more significant impact than for a single mobile node. Scenarios illustrated in [6] demonstrate that providing a permanent access to mobile networks typically require the use of several interfaces and technologies. For example, this is particularly useful for Intelligent Transport Systems (ITS) applications since vehicles are moving across distant geographical locations. Access would be provided through different access technologies (e.g., Wimax, Wifi, 3G) and through different access operators.
然而，移动网络通常通过无线连接，因此可靠性较低；MR后面也可能有许多节点。因此，与单个移动节点相比，连接中断或无法连接到Internet的影响更大。[6]中说明的场景表明，提供对移动网络的永久访问通常需要使用多种接口和技术。例如，这对于智能交通系统（ITS）应用特别有用，因为车辆在遥远的地理位置上移动。接入将通过不同的接入技术（如Wimax、Wifi、3G）和不同的接入运营商提供。
As specified in Section 5 of the NEMO Basic Support Requirements [1] (R.12), the NEMO WG must ensure that NEMO Basic Support does not prevent mobile networks to be multihomed, i.e., when there is more than one point of attachment between the mobile network and the Internet (see definitions in [3]). This arises either:
如NEMO基本支持要求[1]（R.12）第5节所述，NEMO工作组必须确保NEMO基本支持不会阻止移动网络多址，即，当移动网络和互联网之间存在多个连接点时（见[3]中的定义）。这产生于：
o when an MR has multiple egress interfaces, or
o 当MR具有多个出口接口时，或
o the mobile network has multiple MRs, or
o 移动网络具有多个MRs，或
o the mobile network is associated with multiple HAs, or
o 移动网络与多个HA关联，或
o multiple global prefixes are available in the mobile network.
o 移动网络中有多个全局前缀。
Using NEMO Basic Support, this would translate into having multiple bi-directional tunnels between the MR(s) and the corresponding HA(s), and may result in multiple Mobile Network Prefixes (MNPs) available
使用NEMO基本支持，这将转化为在MR和相应HA之间具有多个双向隧道，并可能导致多个移动网络前缀（MNP）可用
to the MNNs. However, NEMO Basic Support does not specify any particular mechanism to manage multiple bi-directional tunnels. The objectives of this memo are thus multifold:
给MNN。然而，NEMO基本支持并未指定任何特定机制来管理多条双向隧道。因此，本备忘录的目标是多方面的：
o to determine all the potential multihomed configurations for a NEMO, and then to identify which of these may be useful in a real-life scenario;
o 确定NEMO的所有潜在多宿配置，然后确定其中哪些可能在实际场景中有用；
o to capture issues that may prevent some multihomed configurations to be supported under the operation of NEMO Basic Support. It does not necessarily mean that the ones not supported will not work with NEMO Basic Support, as it may be up to the implementors to make it work (hopefully this memo will be helpful to these implementors);
o 捕获可能阻止在NEMO基本支持下支持某些多址配置的问题。这并不一定意味着那些不受支持的将不能与NEMO基本支持一起工作，因为它可能由实施者来实现（希望本备忘录将对这些实施者有所帮助）；
o to decide which issues are worth solving and to determine which WG is the most appropriate to address these;
o 决定哪些问题值得解决，并确定哪个工作组最适合解决这些问题；
o to identify potential solutions to the previously identified issues.
o 确定先前确定问题的潜在解决方案。
In order to reach these objectives, a taxonomy for classifying the possible multihomed configurations is described in Section 2. Deployment scenarios, their benefits, and requirements to meet these benefits are illustrated in Section 3. Following this, the related issues are studied in Section 4. The issues are then summarized in a matrix for each of the deployment scenario, and recommendations are made on which of the issues should be worked on and where in Section 5. This memo concludes with an evaluation of NEMO Basic Support for multihomed configurations. Alternative classifications are outlined in the Appendix.
为了达到这些目标，第2节介绍了对可能的多址配置进行分类的分类法。第3节说明了部署场景、它们的好处以及满足这些好处的要求。随后，第4节研究了相关问题。然后，在每个部署场景的矩阵中总结这些问题，并在第5节中就应解决哪些问题以及在何处提出建议。本备忘录最后评估了NEMO对多宿配置的基本支持。附录中概述了替代分类。
The readers should note that this document considers multihoming only from the point of view of an IPv6 environment. In order to understand this memo, the reader is expected to be familiar with the above cited documents, i.e., with the NEMO terminology as defined in [2] (Section 3) and [3], Motivations and Scenarios for Multihoming [6], Goals and Requirements of Network Mobility Support [1], and the NEMO Basic Support specification [4]. Goals and benefits of multihoming as discussed in [6], are applicable to fixed nodes, mobile nodes, fixed networks, and mobile networks.
读者应注意，本文档仅从IPv6环境的角度考虑多宿主。为了理解本备忘录，读者应熟悉上述引用的文件，即[2]（第3节）和[3]中定义的NEMO术语、多宿动机和场景[6]、网络移动支持的目标和要求[1]以及NEMO基本支持规范[4]。[6]中讨论的多归属的目标和好处适用于固定节点、移动节点、固定网络和移动网络。
As there are several configurations in which mobile networks are multihomed, there is a need to classify them into a clearly defined taxonomy. This can be done in various ways. A Configuration-Oriented taxonomy is described in this section. Two other
由于有几种移动网络是多址的配置，因此需要将它们分类为明确定义的分类法。这可以通过多种方式实现。本节介绍了面向配置的分类法。另外两个
taxonomies, namely, the Ownership-Oriented Approach and the Problem-Oriented Approach, are outlined in Appendix A.1 and Appendix A.2.
附录A.1和附录A.2概述了分类法，即面向所有权的方法和面向问题的方法。
Multihomed configurations can be classified depending on how many MRs are present, how many egress interfaces, Care-of Address (CoA), and Home Addresses (HoA) the MRs have, how many prefixes (MNPs) are available to the mobile network nodes, etc. We use three key parameters to differentiate the multihomed configurations. Using these parameters, each configuration is referred by the 3-tuple (x,y,z), where 'x', 'y', 'z' are defined as follows:
多宿配置可以根据存在的MRs数量、出口接口数量、MRs的转交地址（CoA）和家庭地址（HoA）、移动网络节点可用的前缀（MNP）数量等进行分类。我们使用三个关键参数来区分多宿配置。使用这些参数，每个配置由3元组（x，y，z）引用，其中“x”、“y”、“z”的定义如下：
o 'x' indicates the number of MRs where:
o “x”表示MRs的数量，其中：
x=1 implies that a mobile network has only a single MR, presumably multihomed.
x=1意味着移动网络只有一个MR，可能是多址的。
x=n implies that a mobile network has more than one MR.
x=n意味着移动网络有多个MR。
o 'y' indicates the number of HAs associated with the entire mobile network, where:
o “y”表示与整个移动网络相关联的数量，其中：
y=1 implies that a single HA is assigned to the mobile network.
y=1表示将单个HA分配给移动网络。
y=n implies that multiple HAs are assigned to the mobile network.
y=n表示向移动网络分配了多个HAs。
o 'z' indicates the number of MNPs available within the NEMO, where:
o “z”表示NEMO内可用的MNP数量，其中：
z=1 implies that a single MNP is available in the NEMO.
z=1表示NEMO中有一个MNP可用。
z=N implies that multiple MNPs are available in the NEMO.
z=N表示NEMO中有多个MNP可用。
It can be seen that the above three parameters are fairly orthogonal with one another. Thus, different values of 'x', 'y', and 'z' result in different combinations of the 3-tuple (x,y,z).
可以看出，上述三个参数彼此相当正交。因此，“x”、“y”和“z”的不同值导致3元组（x、y、z）的不同组合。
As will be described in the sub-sections below, a total of 8 possible configurations can be identified. One thing the reader has to keep in mind is that in each of the following 8 cases, the MR may be multihomed if either (i) multiple prefixes are available (on the home link, or on the foreign link), or (ii) the MR is equipped with multiple interfaces. In such a case, the MR would have multiple (HoA,CoA) pairs. Issues pertaining to a multihomed 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 MNP(s) may either be explicitly announced by the MR via router advertisement, or made available through Dynamic Host Configuration Protocol (DHCP) [8].
如下文小节所述，总共可以确定8种可能的配置。读者必须记住的一件事是，在以下8种情况中的每种情况下，如果（i）多个前缀可用（在主链路或外部链路上），或者（ii）MR配备有多个接口，则MR可能是多址的。在这种情况下，MR将有多个（HoA，CoA）对。[7]中还讨论了与多宿主MR相关的问题。此外，读者还应记住，当“MNP在NEMO中可用”时，MNP可由MR通过路由器广告明确宣布，或通过动态主机配置协议（DHCP）提供[8]。
The (1,1,1) configuration has only one MR, it is associated with a single HA, and a single MNP is available in the NEMO. The MR and the AR are connected to the Internet via a single Access Router (AR). To fall into a multihomed configuration, at least one of the following conditions must hold:
（1,1,1）配置只有一个MR，它与一个HA关联，并且NEMO中有一个MNP可用。MR和AR通过单个接入路由器（AR）连接到互联网。要进入多址配置，必须至少满足以下条件之一：
o The MR has multiple interfaces and thus it has multiple CoAs;
o MR有多个接口，因此它有多个COA；
o Multiple global prefixes are available on the foreign link, and thus it has multiple CoAs; or
o 外部链路上有多个全局前缀，因此它有多个COA；或
o Multiple global prefixes are available on the home link, and thus the MR has more than one path to reach the HA.
o 主链路上有多个全局前缀，因此MR有多条路径到达HA。
Note that the case where multiple prefixes are available on the foreign link does not have any bearing on the MNPs. MNPs are independent of prefixes available on the link where the MR is attached to, thus prefixes available on the foreign link are not announced on the NEMO link. For the case where multiple prefixes are available on the home link, these are only announced on the NEMO link if the MR is configured to do so. In the present (1,1,1) configuration, only one MNP is announced.
请注意，外部链路上有多个前缀的情况对MNP没有任何影响。MNP独立于MR连接到的链路上可用的前缀，因此NEMO链路上不会公布外部链路上可用的前缀。对于主链路上有多个前缀的情况，只有在MR配置为这样做的情况下，才会在NEMO链路上宣布这些前缀。在当前（1,1,1）配置中，只宣布一个MNP。
A bi-directional tunnel would then be established between each (HoA,CoA) pair.
然后在每个（HoA，CoA）对之间建立一个双向隧道。
Regarding MNNs, they are (usually) not multihomed since they would configure a single global address from the single MNP available on the link they are attached to.
关于MNN，它们（通常）不是多址的，因为它们将从它们所连接的链路上可用的单个MNP配置单个全局地址。
_____
_ p _ | |
|_|-|<-_ |-|_|-| |-| _
_ |-|_|=| |_____| | _ |-|_|
|_|-| | |-|_|-|
|
MNNs MR AR Internet AR HA
_____
_ p _ | |
|_|-|<-_ |-|_|-| |-| _
_ |-|_|=| |_____| | _ |-|_|
|_|-| | |-|_|-|
|
MNNs MR AR Internet AR HA
Figure 1: (1,1,1): 1 MR, 1 HA, 1 MNP
图1：（1,1,1）：1个MR，1个HA，1个MNP
The (1,1,n) configuration has only one MR, it is associated with a single HA, and two or more MNPs are available in the NEMO.
（1,1，n）配置只有一个MR，它与单个HA关联，NEMO中有两个或多个MNP可用。
The MR may itself be multihomed, as detailed in Section 2.1. In such a case, a bi-directional tunnel would be established between each (HoA,CoA) pair.
MR本身可能是多址的，详见第2.1节。在这种情况下，将在每个（HoA，CoA）对之间建立一个双向隧道。
Regarding MNNs, they are multihomed because several MNPs are available on the link they are attached to. The MNNs would then configure a global address from each MNP available on the link.
关于MNN，它们是多址的，因为它们所连接的链路上有多个MNP可用。然后，MNN将从链路上可用的每个MNP配置一个全局地址。
_____
_ p1,p2 _ | |
|_|-|<-_ |-|_|-| |-| _
_ |-|_|=| |_____| | _ |-|_|
|_|-| | |-|_|-|
|
MNNs MR AR Internet AR HA
_____
_ p1,p2 _ | |
|_|-|<-_ |-|_|-| |-| _
_ |-|_|=| |_____| | _ |-|_|
|_|-| | |-|_|-|
|
MNNs MR AR Internet AR HA
Figure 2: (1,1,n): 1 MR, 1 HA, multiple MNPs
图2：（1,1，n）：1个MR，1个HA，多个MNP
The (1,n,1) configuration has only one MR and a single MNP is available in the NEMO. The MR, however, is associated with multiple HAs.
（1，n，1）配置只有一个MR，NEMO中有一个MNP可用。然而，MR与多个HA相关。
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-directional tunnel would then be established between each (HoA,CoA) pair.
NEMO是多址的，因为它有多个HA，但除此之外，第2.1节中详述的条件也适用于MR。然后在每个（HoA，CoA）对之间建立一个双向隧道。
Regarding MNNs, they are (usually) not multihomed since they would configure a single global address from the single MNP available on the link they are attached to.
关于MNN，它们（通常）不是多址的，因为它们将从它们所连接的链路上可用的单个MNP配置单个全局地址。
AR HA2
_ |
|-|_|-| _
_____ | |-|_|
_ p _ | |-|
|_|-|<-_ |-|_|-| |
_ |-|_|=| |_____|-| _
|_|-| | | _ |-|_|
|-|_|-|
|
MNNs MR AR Internet AR HA1
AR HA2
_ |
|-|_|-| _
_____ | |-|_|
_ p _ | |-|
|_|-|<-_ |-|_|-| |
_ |-|_|=| |_____|-| _
|_|-| | | _ |-|_|
|-|_|-|
|
MNNs MR AR Internet AR HA1
Figure 3: (1,n,1): 1 MR, multiple HAs, 1 MNP
图3：（1，n，1）：1个MR，多个HAs，1个MNP
The (1,n,n) configuration has only one MR. However, the MR is associated with multiple HAs and more than one MNP is available in the NEMO.
（1，n，n）配置只有一个MR。但是，MR与多个HA关联，NEMO中有多个MNP可用。
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 tunnel would then be established between each (HoA,CoA) pair.
MR是多址的，因为它有多个has，但此外，第2.1节中详述的条件也可能适用。然后在每个（HoA，CoA）对之间建立一个双向隧道。
Regarding MNNs, they are multihomed because several MNPs are available on the link they are attached to. The MNNs would then configure a global address with each MNP available on the link.
关于MNN，它们是多址的，因为它们所连接的链路上有多个MNP可用。然后，MNN将使用链路上可用的每个MNP配置一个全局地址。
AR HA2
_ | _
_____ |-|_|-|-|_|
_ p1,p2 _ | |-| |
|_|-|<-_ |-|_|-| | _
_ |-|_|=| |_____|-| _ |-|_|
|_|-| | |-|_|-|
| |
MNNs MR AR Internet AR HA1
AR HA2
_ | _
_____ |-|_|-|-|_|
_ p1,p2 _ | |-| |
|_|-|<-_ |-|_|-| | _
_ |-|_|=| |_____|-| _ |-|_|
|_|-| | |-|_|-|
| |
MNNs MR AR Internet AR HA1
Figure 4: (1,n,n): 1 MR, multiple HAs, multiple MNPs
图4：（1，n，n）：1个MR，多个HA，多个MNP
The (n,1,1) configuration has more than one MR advertising global routes. However, the MR(s) are associated with a single HA, and there is a single MNP available in the NEMO.
（n，1，1）配置有多条MR广告全球路线。但是，MR与单个HA关联，NEMO中有一个MNP可用。
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-directional tunnel would then be established between each (HoA,CoA) pair.
NEMO是多址的，因为它有多个MRs，但除此之外，第2.1节中详述的条件也适用于每个MR。然后将在每个（HoA，CoA）对之间建立一个双向隧道。
Regarding MNNs, they are (usually) not multihomed since they would configure a single global address from the single MNP available on the link they are attached to.
关于MNN，它们（通常）不是多址的，因为它们将从它们所连接的链路上可用的单个MNP配置单个全局地址。
MR2
p<-_ |
_ |-|_|-| _____
|_|-| |-| |
_ | | |-| _
|_|-| _ |-|_____| | _ |-|_|
|-|_|-| |-|_|-|
p<- | |
MNNs MR1 Internet AR HA
MR2
p<-_ |
_ |-|_|-| _____
|_|-| |-| |
_ | | |-| _
|_|-| _ |-|_____| | _ |-|_|
|-|_|-| |-|_|-|
p<- | |
MNNs MR1 Internet AR HA
Figure 5: (n,1,1): Multiple MRs, 1 HA, 1 MNP
图5：（n，1，1）：多个MRs，1 HA，1 MNP
The (n,1,n) configuration has more than one MR; multiple global routes are advertised by the MRs and multiple MNPs are available within the NEMO.
（n，1，n）配置具有多个MR；MRs公布了多条全球航线，NEMO内有多个MNP可用。
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-directional tunnel would then be established between each (HoA,CoA) pair.
NEMO是多址的，因为它有多个MRs，但除此之外，第2.1节中详述的条件也适用于每个MR。然后将在每个（HoA，CoA）对之间建立一个双向隧道。
Regarding MNNs, they are multihomed because several MNPs are available on the link they are attached to. The MNNs would then configure a global address with each MNP available on the link.
关于MNN，它们是多址的，因为它们所连接的链路上有多个MNP可用。然后，MNN将使用链路上可用的每个MNP配置一个全局地址。
MR2
p2<-_ |
_ |-|_|-| _____
|_|-| |-| |
_ | | |-| _
|_|-| _ |-|_____| | _ |-|_|
|-|_|-| |-|_|-|
p1<- | |
MNNs MR1 Internet AR HA
MR2
p2<-_ |
_ |-|_|-| _____
|_|-| |-| |
_ | | |-| _
|_|-| _ |-|_____| | _ |-|_|
|-|_|-| |-|_|-|
p1<- | |
MNNs MR1 Internet AR HA
Figure 6: (n,1,n): Multiple MRs, 1 HA, multiple MNPs
图6：（n，1，n）：多个MRs，1公顷，多个MNP
The (n,n,1) configuration has more than one MR advertising multiple global routes. The mobile network is simultaneously associated with multiple HAs and a single MNP is available in the NEMO.
（n，n，1）配置具有多个MR，用于广告多个全局路由。移动网络同时与多个HA关联，且NEMO中有一个MNP可用。
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 each MR. A bi-directional tunnel would then be established between each (HoA,CoA) pair.
NEMO是多址的，因为它有多个MRs和has，但除此之外，第2.1节中详述的条件也可能适用于每个MR。然后将在每个（HoA，CoA）对之间建立一个双向隧道。
Regarding MNNs, they are (usually) not multihomed since they would configure a single global address from the single MNP available on the link they are attached to.
关于MNN，它们（通常）不是多址的，因为它们将从它们所连接的链路上可用的单个MNP配置单个全局地址。
MR2 AR HA2
p _ |
<-_ | |-|_|-| _
_ |-|_|-| _____ | |-|_|
|_|-| |-| |-|
_ | | |
|_|-| _ |-|_____|-| _
|-|_|-| | _ |-|_|
<- | |-|_|-|
p |
MNNs MR1 Internet AR HA1
MR2 AR HA2
p _ |
<-_ | |-|_|-| _
_ |-|_|-| _____ | |-|_|
|_|-| |-| |-|
_ | | |
|_|-| _ |-|_____|-| _
|-|_|-| | _ |-|_|
<- | |-|_|-|
p |
MNNs MR1 Internet AR HA1
Figure 7: (n,n,1): Multiple MRs, Multiple HAs, 1 MNP
图7：（n，n，1）：多个MRs，多个HAs，1个MNP
The (n,n,n) configuration has multiple MRs advertising different global routes. The mobile network is simultaneously associated with more than one HA and multiple MNPs are available in the NEMO.
（n，n，n）配置具有多个宣传不同全局路由的MRs。移动网络同时与多个HA关联，NEMO中有多个MNP可用。
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 each MR. A bi-directional tunnel would then be established between each (HoA,CoA) pair.
NEMO是多址的，因为它有多个MRs和has，但除此之外，第2.1节中详述的条件也可能适用于每个MR。然后将在每个（HoA，CoA）对之间建立一个双向隧道。
Regarding MNNs, they are multihomed because several MNPs are available on the link they are attached to. The MNNs would then configure a global address with each MNP available on the link.
关于MNN，它们是多址的，因为它们所连接的链路上有多个MNP可用。然后，MNN将使用链路上可用的每个MNP配置一个全局地址。
MR2 AR HA2
p2 _ |
<-_ | |-|_|-| _
_ |-|_|-| _____ | |-|_|
|_|-| |-| |-|
_ | | |
|_|-| _ |-|_____|-| _
|-|_|-| | _ |-|_|
<- | |-|_|-|
p1 |
MNNs MR1 Internet AR HA1
MR2 AR HA2
p2 _ |
<-_ | |-|_|-| _
_ |-|_|-| _____ | |-|_|
|_|-| |-| |-|
_ | | |
|_|-| _ |-|_____|-| _
|-|_|-| | _ |-|_|
<- | |-|_|-|
p1 |
MNNs MR1 Internet AR HA1
Figure 8: (n,n,n): Multiple MRs, HAs, and MNPs
图8：（n，n，n）：多个MRs、HAs和MNP
The following generic goals and benefits of multihoming are discussed in [6]:
[6]中讨论了多主定位的以下一般目标和好处：
1. Permanent and Ubiquitous Access
1. 永久和无处不在的访问
2. Reliability
2. 可靠性
3. Load Sharing
3. 负荷分担
4. Load Balancing/Flow Distribution
4. 负载平衡/流量分配
5. Preference Settings
5. 首选项设置
6. Aggregate Bandwidth
6. 聚合带宽
These benefits are now illustrated from a NEMO perspective with a typical instance scenario for each case in the taxonomy. We then discuss the prerequisites to fulfill these.
现在，我们从NEMO的角度用分类法中每个案例的典型实例场景来说明这些好处。然后，我们讨论实现这些目标的先决条件。
x=1: Multihomed mobile networks with a single MR
x=1：具有单个MR的多址移动网络
o Example 1:
o 例1：
MR with dual/multiple access interfaces (e.g., 802.11 and GPRS capabilities). This is a (1,1,*) if a single HA is used for both. If two independent HAs are used, this is a (1,n,n) configuration.
MR具有双/多址接口（例如802.11和GPRS功能）。这是一个（1,1，*），如果一个HA同时用于两个HA。如果使用两个独立的HA，则这是一个（1，n，n）配置。
Benefits: Ubiquitous Access, Reliability, Load Sharing, Preference Settings, Aggregate Bandwidth.
好处：无处不在的访问、可靠性、负载共享、首选项设置、聚合带宽。
x=n: Multihomed mobile networks with multiple MRs
x=n：具有多个MRs的多址移动网络
o Example 1:
o 例1：
Train with one MR in each car, all served by the same HA, thus a (n,1,*) configuration. Alternatively, the train company might use different HAs, in different countries, thus a (n,n,n) configuration.
每节车厢中有一个MR的列车，由相同的HA提供服务，因此为（n，1，*）配置。或者，列车公司可能在不同的国家使用不同的HAs，因此使用（n，n，n）配置。
Benefits: Ubiquitous Access, Reliability, Load Sharing, Aggregate Bandwidth.
好处：无处不在的访问、可靠性、负载共享、聚合带宽。
o Example 2:
o 例2：
Wireless personal area network with a GPRS-enabled phone and a WiFi-enabled PDA. This is a (n,n,n) configuration if different HAs are also used.
无线个人区域网络，支持GPRS的手机和支持WiFi的PDA。如果还使用了不同的HA，则这是一个（n，n，n）配置。
Benefits: Ubiquitous Access, Reliability, Preference Settings, Aggregate Bandwidth.
好处：无处不在的访问、可靠性、首选项设置、聚合带宽。
y=1: Multihomed mobile networks with a single HA
y=1：具有单个HA的多址移动网络
o Example:
o 例子：
Most single HA cases in above examples.
以上示例中的大多数单一HA病例。
y=n: Multihomed mobile networks with multiple HAs
y=n：具有多个HA的多址移动网络
o Example 1:
o 例1：
Most multiple HAs cases in above examples.
在上述示例中，大多数情况下都有多个案例。
o Example 2:
o 例2：
Transatlantic flight with a HA in each continent. This is a (1,n,1) configuration if there is only one MR.
跨大西洋飞行，每个大陆都有HA。如果只有一个MR，则这是一个（1，n，1）配置。
Benefits: Ubiquitous Access, Reliability, Preference Settings (reduced delay, shortest path).
好处：无处不在的访问、可靠性、首选项设置（减少延迟、最短路径）。
z=1: Multihomed mobile networks with a single MNP
z=1：具有单个MNP的多址移动网络
o Example:
o 例子：
Most single HA cases in above examples.
以上示例中的大多数单一HA病例。
z=n: Multihomed mobile networks with multiple MNPs
z=n：具有多个MNP的多址移动网络
o Example 1:
o 例1：
Most multiple HAs cases in above examples.
在上述示例中，大多数情况下都有多个案例。
o Example 2:
o 例2：
Car with a prefix taken from home (personal traffic is transmitted using this prefix and is paid by the owner) and one that belongs to the car manufacturer (maintenance traffic is paid by the car manufacturer). This will typically be a (1,1,n) or a (1,n,n,) configuration.
前缀为从家中获取的汽车（使用此前缀传输个人交通，并由车主支付）和属于汽车制造商的汽车（维护交通由汽车制造商支付）。这通常是（1，1，n）或（1，n，n，）配置。
Benefits: Preference Settings
优点：首选项设置
In this section, requirements are stated in order to comply with the expected benefits of multihoming as detailed in [6].
在本节中，说明了各项要求，以符合[6]中详述的多主系统的预期效益。
At least one bi-directional tunnel must be available at any point in time between the mobile network and the fixed network to meet all expectations. But for most goals to be effective, multiple tunnels must be maintained simultaneously:
在移动网络和固定网络之间的任何时间点，必须至少有一条双向隧道可用，以满足所有期望。但为了实现大多数目标，必须同时维护多条隧道：
o Permanent and Ubiquitous Access:
o 永久和无处不在的访问：
At least one bi-directional tunnel must be available at any point in time.
在任何时间点，必须至少有一条双向隧道可用。
o Reliability:
o 可靠性：
Both the inbound and outbound traffic must be transmitted or diverted over another bi-directional tunnel once a bi-directional tunnel is broken or disrupted. It should be noted that the provision of fault tolerance capabilities does not necessarily require the existence of multiple bi-directional tunnels simultaneously.
一旦双向隧道破裂或中断，进出口交通必须通过另一条双向隧道传输或改道。应注意的是，提供容错能力并不一定需要同时存在多个双向隧道。
o Load Sharing and Load Balancing:
o 负载共享和负载平衡：
Multiple tunnels must be maintained simultaneously.
必须同时维护多个隧道。
o Preference Settings:
o 首选项设置：
Implicitly, multiple tunnels must be maintained simultaneously if preferences are set for deciding which of the available bi-directional tunnels should be used. To allow user/application to set the preference, a mechanism should be provided to the user/ application for the notification of the availability of multiple bi-directional tunnels, and perhaps also to set preferences. A similar mechanism should also be provided to network administrators to manage preferences.
如果设置了首选项以决定应使用哪个可用双向隧道，则隐式地必须同时维护多个隧道。为了允许用户/应用程序设置首选项，应向用户/应用程序提供一种机制，用于通知多个双向隧道的可用性，并且可能还用于设置首选项。还应向网络管理员提供类似的机制来管理首选项。
o Aggregate Bandwidth:
o 聚合带宽：
Multiple tunnels must be maintained simultaneously in order to increase the total aggregated bandwidth available to the mobile network.
为了增加移动网络可用的总聚合带宽，必须同时维护多个隧道。
As discussed in the previous section, multiple bi-directional tunnels need to be maintained either sequentially (e.g., for fault tolerance) or simultaneously (e.g., for load sharing).
如前一节所述，多个双向隧道需要按顺序（例如，为了容错）或同时（例如，为了负载共享）进行维护。
In some cases, it may be necessary to divert packets from a (perhaps failed) bi-directional tunnel to an alternative (perhaps newly established) bi-directional tunnel (i.e., for matters of fault recovery, preferences), or to split traffic between multiple tunnels (load sharing, load balancing).
在某些情况下，可能需要将数据包从（可能失败的）双向隧道转移到备用（可能新建立的）双向隧道（即，故障恢复、首选项），或者在多个隧道之间分割流量（负载共享、负载平衡）。
So, depending on the configuration under consideration, the issues discussed below may need to be addressed sometimes dynamically. For each issue, potential ways to solve the problem are investigated.
因此，根据所考虑的配置，下面讨论的问题有时可能需要动态解决。对于每个问题，都会研究解决问题的潜在方法。
One of the goals of multihoming is the provision of fault tolerance capabilities. In order to provide such features, a set of tasks need to be performed, including: failure detection, alternative available path exploration, path selection, and re-homing of established communications. These are also discussed in [9] by the Shim6 WG. In the following sub-sections, we look at these issues in the specific context of NEMO, rather than the general Shim6 perspective in [9]. In addition, in some scenarios, it may also be required to provide the mechanisms for coordination between different HAs (see Section 4.3) and also the coordination between different MRs (see Section 4.4).
多宿的目标之一是提供容错能力。为了提供这样的功能，需要执行一组任务，包括：故障检测、备用可用路径探索、路径选择和已建立通信的重新引导。Shim6工作组在[9]中也讨论了这些问题。在以下小节中，我们将在NEMO的特定背景下研究这些问题，而不是[9]中的一般Shim6观点。此外，在某些情况下，可能还需要提供不同HA之间的协调机制（见第4.3节）以及不同MR之间的协调机制（见第4.4节）。
It is expected for faults to occur more readily at the edge of the network (i.e., the mobile nodes) due to the use of wireless connections. Efficient fault detection mechanisms are necessary to recover in timely fashion.
由于使用无线连接，预计故障更容易发生在网络边缘（即移动节点）。高效的故障检测机制对于及时恢复是必要的。
Depending on the NEMO configuration considered, the failure protection domain greatly varies. In some configurations, the protection domain provided by NEMO multihoming is limited to the links between the MR(s) and the HA(s). In other configurations, the protection domain allows to recover from failures in other parts of the path, so an end-to-end failure detection mechanism is required.
根据所考虑的NEMO配置，故障保护域有很大的不同。在某些配置中，NEMO多宿提供的保护域仅限于MR和HA之间的链路。在其他配置中，保护域允许从路径的其他部分的故障中恢复，因此需要端到端故障检测机制。
The failure detection capabilities required for each configuration are detailed below:
每个配置所需的故障检测功能如下所示：
o For the (1,1,*) cases, multiple paths are available between a single MR and a single HA. All the traffic to and from the NEMO flows through the MR and HA. Failure detection mechanisms need only to be executed between these two devices. This is a NEMO-/ MIPv6-specific issue.
o 对于（1,1，*）情况，单个MR和单个HA之间有多条路径可用。进出尼莫的所有交通都经过MR和HA。故障检测机制只需要在这两个设备之间执行。这是NEMO-/MIPv6的特定问题。
o For the (n,1,*) cases, there is a single HA, so all the traffic to and from the NEMO will flow through it. The failure detection mechanisms need to be able to detect failure in the path between the used MR and the only HA. Hence, the failure detection mechanism needs only to involve the HA and the MRs. This is a NEMO/MIPv6 specific issue.
o 对于（n，1，*）情况，有一个HA，因此来往NEMO的所有流量都将通过它。故障检测机制需要能够检测所用MR和唯一HA之间路径中的故障。因此，故障检测机制只需涉及HA和MRs。这是NEMO/MIPv6的特定问题。
o For the (n,n,*) cases, there are multiple paths between the different HAs and the different MRs. Moreover, the HAs may be located in different networks, and have different Internet access links. This implies that changing the HA used may not only allow recovering from failures in the link between the HA and the MR, but also from other failure modes, affecting other parts of the path. In this case, an end-to-end failure detection mechanism would provide additional protection. However, a higher number of failures is likely to occur in the link between the HA and the MR, so it may be reasonable to provide optimized failure detection mechanisms for this failure mode. The (n,n,n) case is hybrid, since selecting a different prefix results in a change of path. For this case, the Shim6 protocols (such as those discussed in [9]) may be useful.
o 对于（n，n，*）情况，不同的HA和不同的MRs之间存在多条路径。此外，HA可能位于不同的网络中，并且具有不同的互联网接入链路。这意味着更改所使用的HA不仅允许从HA和MR之间链路的故障中恢复，还允许从影响路径其他部分的其他故障模式中恢复。在这种情况下，端到端故障检测机制将提供额外的保护。然而，在HA和MR之间的链路中可能发生更多的故障，因此为该故障模式提供优化的故障检测机制可能是合理的。（n，n，n）情况是混合的，因为选择不同的前缀会导致路径的改变。对于这种情况，Shim6协议（如[9]中讨论的协议）可能有用。
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
上述大多数案例涉及检测HA（s）和MR（s）之间的隧道故障。这与移动主机及其HA之间的故障检测没有什么不同。因此，一个
solution for MIPv6 should apply to NEMO as well. For case (n,*,*), an MR synchronization solution (see Section 4.4) should be able to complement a MIPv6 failure detection solution to achieve the desired functionality for NEMO.
MIPv6的解决方案也应适用于NEMO。对于情况（n，*，*），MR同步解决方案（见第4.4节）应能够补充MIPv6故障检测解决方案，以实现NEMO所需的功能。
In order for fault recovery to work, the MRs and HAs must first possess a means to detect failures:
为了使故障恢复工作，MRs和HAs必须首先具备检测故障的方法：
o On the MR's side, the MR can rely on router advertisements from access routers, or other layer-2 trigger mechanisms to detect faults, e.g., [10] and [11].
o 在MR方面，MR可以依赖于来自接入路由器的路由器广告或其他第2层触发机制来检测故障，例如，[10]和[11]。
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 methods (such as constant transmission of heartbeat signals) to detect failures and check tunnel liveness. In the subscriber model (see Appendix A.2: S/P model), a lack of standardized "tunnel liveness" protocol means that it is harder to detect failures.
o 在医管局方面，发现隧道故障较为困难。对于ISP部署模型，HAs和MRs可以使用专有方法（如持续传输心跳信号）来检测故障和检查隧道活动性。在订户模型（见附录A.2：S/P模型）中，缺乏标准化的“隧道活性”协议意味着更难检测故障。
A possible method is for the MRs to send binding updates more regularly with shorter Lifetime values. Similarly, HAs can return binding acknowledgment messages with smaller Lifetime values, thus forcing the MRs to send binding updates more frequently. These binding updates can be used to emulate "tunnel heartbeats". This, however, may lead to more traffic and processing overhead, since binding updates sent to HAs must be protected (and possibly encrypted) with security associations.
一种可能的方法是让MRs以更短的生存期值更定期地发送绑定更新。类似地，HAs可以返回具有较小生存期值的绑定确认消息，从而迫使MRs更频繁地发送绑定更新。这些绑定更新可用于模拟“隧道心跳”。但是，这可能会导致更多的通信量和处理开销，因为发送到HAs的绑定更新必须使用安全关联进行保护（并可能进行加密）。
Once a failure in the currently used path is detected, alternative paths have to be explored in order to identify an available one. This process is closely related to failure detection in the sense that paths being explored need to be alternative paths to the one that has failed. There are, however, subtle but significant differences between path exploration and failure detection. Failure detection occurs on the currently used path while path exploration occurs on the alternative paths (not on the one currently being used for exchanging packets). Although both path exploration and failure detection are likely to rely on a reachability or keepalive test exchange, failure detection also relies on other information, such as upper layer information (e.g., positive or negative feedback from TCP), lower layer information (e.g., an interface is down), and network layer information (e.g., as an address being deprecated or ICMP error message).
一旦在当前使用的路径中检测到故障，必须探索替代路径，以确定可用路径。这一过程与故障检测密切相关，因为正在探索的路径需要是故障路径的替代路径。然而，路径探索和故障检测之间存在细微但显著的差异。故障检测发生在当前使用的路径上，而路径探索发生在替代路径上（不是在当前用于交换数据包的路径上）。尽管路径探索和故障检测都可能依赖于可达性或keepalive测试交换，但故障检测也依赖于其他信息，如上层信息（例如，TCP的正面或负面反馈）、下层信息（例如，接口关闭）和网络层信息（例如，作为不推荐使用的地址或ICMP错误消息）。
Basically, the same cases as in the analysis of the failure detection (Section 4.1.1) issue are identified:
基本上，确定了与故障检测（第4.1.1节）问题分析相同的情况：
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 the MR have to be explored to identify an available one. The mechanism involves only the HA and the MR. This is a NEMO-/ MIPv6-specific issue.
o 对于（1,1，*）情况，单个MR和单个HA之间有多条路径可用。必须探索医管局与MR之间的现有路径，以确定可用的路径。该机制仅涉及医管局和MR。这是NEMO-/MIPv6的具体问题。
o For the (n,1,*) cases, there is a single HA, so all the traffic to and from the NEMO will flow through it. The available alternative paths are the different ones between the different MRs and the HA. The path-exploration mechanism only involves the HA and the MRs. This is a NEMO/MIPv6 specific issue.
o 对于（n，1，*）情况，有一个HA，因此来往NEMO的所有流量都将通过它。可供选择的途径是不同的MRs和医管局之间的不同途径。路径探索机制仅涉及医管局和MRs。这是NEMO/MIPv6的具体问题。
o For the (n,n,*) cases, there are multiple paths between the different HAs and the different MRs. In this case, alternative paths may be routed completely independent from one another. An end-to-end path-exploration mechanism would be able to discover if any of the end-to-end paths is available. The (n,n,1) case, however, seems to be pretty NEMO specific, because of the absence of multiple prefixes. The (n,n,n) case is hybrid, since selecting a different prefix results in a change of path. For this case, the Shim6 protocols (such as those discussed in [9]) may be useful.
o 对于（n，n，*）情况，不同的HA和不同的MRs之间存在多条路径。在这种情况下，备选路径可以彼此完全独立地路由。端到端路径探索机制将能够发现是否有任何端到端路径可用。然而，（n，n，1）的情况似乎是非常特定于NEMO的，因为没有多个前缀。（n，n，n）情况是混合的，因为选择不同的前缀会导致路径的改变。对于这种情况，Shim6协议（如[9]中讨论的协议）可能有用。
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 case (n,*,*), an MR synchronization solution (see Section 4.4) should be able to complement an MIPv6 path-exploration solution to achieve the desired functionality for NEMO.
上述大部分个案均涉及HA（s）与MR（s）之间隧道的路径勘探。这与移动主机及其HA之间的路径探索没有什么不同。因此，MIPv6的解决方案也应适用于NEMO。对于案例（n，*，*），MR同步解决方案（见第4.4节）应能够补充MIPv6路径探索解决方案，以实现NEMO所需的功能。
In order to perform path exploration, it is sometimes also necessary for the MR 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]. This is related to Section 4.1.1, since the ability to detect media availability would often imply the ability to detect media unavailability.
为了执行路径探索，MR有时还需要检测网络媒体的可用性。这可以通过使用第2层触发器[10]或检测网络连接（DNA）工作组开发/推荐的其他机制[11]来实现。这与第4.1.1节有关，因为检测媒体可用性的能力通常意味着检测媒体不可用性的能力。
A path-selection mechanism is required to select among the multiple available paths. Depending on the NEMO multihoming configuration involved, the differences between the paths may affect only the part between the HA and the MR, or they may affect the full end-to-end
需要一种路径选择机制来在多个可用路径中进行选择。根据涉及的NEMO多宿配置，路径之间的差异可能只影响HA和MR之间的部分，或者可能影响整个端到端
path. In addition, depending on the configuration, path selection may be performed by the HA(s), the MR(s), or the hosts themselves through address selection, as will be described in detail next.
路径此外，根据配置，路径选择可以由HA、MR或主机本身通过地址选择来执行，如下面将详细描述的。
The multiple available paths may differ on the tunnel between the MR and the HA used to carry traffic to/from the NEMO. In this case, path selection is performed by the MR and the intra-NEMO routing system for traffic flowing from the NEMO, and path selection is performed by the HA and intra-Home Network routing system for traffic flowing to the NEMO.
MR和HA之间的隧道上的多条可用路径可能不同，用于将交通运输到NEMO或从NEMO运出。在这种情况下，由MR和内部NEMO路由系统对来自NEMO的流量执行路径选择，并且由HA和内部家庭网络路由系统对流向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.
或者，可用的多条路径可能不仅仅在MR和HA之间的隧道中不同，因为使用不同的前缀可能导致使用不同的提供者；因此，在涉及的端点之间的完全不同的路径中。在这种情况下，除了前一种情况中介绍的机制外，可能还需要用于端到端路径选择的其他机制。该机制可能与主机内的源地址选择机制密切相关，因为选择给定地址意味着选择给定前缀，该前缀与服务于家庭网络之一的给定ISP相关联。
A dynamic path-selection mechanism is thus needed so that this path could be selected by:
因此，需要动态路径选择机制，以便通过以下方式选择该路径：
o The HA: it should be able to select the path based on some information recorded in the binding cache.
o HA：它应该能够根据绑定缓存中记录的一些信息选择路径。
o The MR: it should be able to select the path based on router advertisements received on both its egress interfaces or on its ingress interfaces for the (n,*,*) case.
o MR：对于（n，*，*）情况，它应该能够基于在其出口接口或入口接口上接收的路由器广告来选择路径。
o The MNN: it should be able to select the path based on "Default Router Selection" (see [Section 6.3.6 Default Router Selection] [12]) in the (n,*,*) case or based on "Source Address Selection" in the (*,*,n) cases (see Section 4.7 of the present memo).
o MNN：在（n，*，*）情况下，它应该能够基于“默认路由器选择”（参见[第6.3.6节默认路由器选择][12]）或在（*，*，n）情况下基于“源地址选择”（参见本备忘录第4.7节）选择路径。
o The user or the application: e.g., in case where a user wants to select a particular access technology among the available technologies for reasons, e.g., of cost or data rate.
o 用户或应用程序：例如，在用户出于成本或数据速率等原因想要在可用技术中选择特定接入技术的情况下。
o A combination of any of the above: a hybrid mechanism should be also available, e.g., one in which the HA, the MR, and/or the MNNs are coordinated to select the path.
o 上述任何一项的组合：还应提供混合机制，例如，协调HA、MR和/或MNN以选择路径的机制。
When multiple bi-directional tunnels are available and possibly used simultaneously, the mode of operation may be either primary-secondary (one tunnel is precedent over the others and used as the default
当多个双向隧道可用且可能同时使用时，运行模式可以是主-次模式（一个隧道优先于其他隧道，并用作默认模式）
tunnel, while the other serves as a backup) or peer-to-peer (no tunnel has precedence over one another, they are used with the same priority). This questions which of the bi-directional tunnels would be selected, and based on which of the parameters (e.g., type of flow that goes into/out of the mobile network).
隧道（另一个用作备份）或对等（没有隧道具有优先权，它们以相同的优先级使用）。这对选择哪个双向隧道以及基于哪个参数（例如，进出移动网络的流量类型）提出了疑问。
The mechanisms for the selection among the different tunnels between the MR(s) and the HA(s) seem to be quite NEMO/MIPv6 specific.
MR（s）和HA（s）之间的不同隧道之间的选择机制似乎相当特定于NEMO/MIPv6。
For (1,*,*) cases, they are no different from the case of path selection between a mobile host and its HA(s). As such, a solution for MIPv6 should apply to NEMO as well. For the (n,*,*) cases, an MR synchronization solution (see Section 4.4) should be able to complement an MIPv6 path-selection solution to achieve the desired functionality for NEMO.
对于（1，*，*）情况，它们与移动主机及其HA之间的路径选择情况没有区别。因此，MIPv6的解决方案也应适用于NEMO。对于（n，*，*）情况，MR同步解决方案（见第4.4节）应能够补充MIPv6路径选择解决方案，以实现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., [13]).
基于地址选择在不同端到端路径之间进行选择的机制类似于其他多主场景中使用的机制，如Shim6所考虑的机制（例如[13]）。
After an outage has been detected and an available alternative path has been identified, a re-homing event takes place, diverting the existing communications from one path to the other. Similar to the previous items involved in this process, the re-homing procedure heavily varies depending on the NEMO multihoming configuration.
在检测到中断并确定可用的替代路径后，发生重新引导事件，将现有通信从一条路径转移到另一条路径。与此过程中涉及的先前项目类似，根据NEMO多归宿配置的不同，重新归宿程序也有很大差异。
o For the (*,*,1) configurations, the re-homing procedure involves only the MR(s) and the HA(s). The re-homing procedure may involve the exchange of additional BU messages. These mechanisms are shared between NEMO Basic Support and MIPv6.
o 对于（*，*，1）配置，重新归位程序仅涉及MR和HA。重新归位程序可能涉及交换其他BU消息。这些机制在NEMO基本支持和MIPv6之间共享。
o For the (*,*,n) cases, in addition to the previous mechanisms, end-to-end mechanisms may be required. Such mechanisms may involve some form of end-to-end signaling or may simply rely on using different addresses for the communication. The involved mechanisms may be similar to those required for re-homing Shim6 communications (e.g., [13]).
o 对于（*，*，n）情况，除了先前的机制外，可能还需要端到端机制。这种机制可能涉及某种形式的端到端信令，或者可能仅仅依赖于使用不同的通信地址。所涉及的机制可能类似于重新引导Shim6通信所需的机制（例如[13]）。
Ingress filtering mechanisms [14][15] may drop the outgoing packets when multiple bi-directional tunnels end up at different HAs. This could particularly occur if different MNPs are handled by different HAs. If a packet with a source address configured from a specific
当多个双向隧道在不同的HA处结束时，入口过滤机制[14][15]可以丢弃出站分组。如果由不同的HA处理不同的MNP，则特别可能发生这种情况。如果数据包的源地址是从特定的
MNP is tunneled to a HA that does not handle that specific MNP, the packet may be discarded either by the HA or by a border router in the home network.
MNP通过隧道传输到不处理该特定MNP的HA，该数据包可由HA或家庭网络中的边界路由器丢弃。
The ingress filtering compatibility issue is heavily dependent on the particular NEMO multihoming configuration:
入口过滤兼容性问题在很大程度上取决于特定的NEMO多址配置：
o For the (*,*,1) cases, there is not such an issue, since there is a single MNP.
o 对于（*，*，1）案例，不存在这样的问题，因为只有一个MNP。
o For the (1,1,*) and (n,1,1) cases, there is not such a problem, since there is a single HA, accepting all the MNPs.
o 对于（1,1，*）和（n，1,1）案例，不存在这样的问题，因为只有一个医管局接受所有MNP。
o For the (n,1,n) case, though ingress filtering would not occur at the HA, it may occur at the MRs, when each MR is handling different MNPs.
o 对于（n，1，n）情况，虽然入口过滤不会发生在HA处，但当每个MR处理不同的mnp时，它可能发生在MRs处。
o (*,n,n) are the cases where the ingress filtering presents some difficulties. In the (1,n,n) case, the problem is simplified because all the traffic to and from the NEMO is routed through a single MR. Such configuration allows the MR to properly route packets respecting the constraints imposed by ingress filtering. In this case, the single MR may face ingress filtering problems that a multihomed mobile node may face, as documented in [7]. 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 no problems occur with the ingress filtering. However, this cannot be always assumed, resulting in the problem described below.
o （*，n，n）是入口过滤出现一些困难的情况。在（1，n，n）情况下，问题被简化，因为进出NEMO的所有流量都通过单个MR路由。这样的配置允许MR根据入口过滤施加的约束正确路由数据包。在这种情况下，如[7]中所述，单个MR可能面临多宿移动节点可能面临的入口过滤问题。更复杂的情况是（n，n，n）情况。当所有的HA都接受所有前缀时，就会出现一种简化的情况，这样入口过滤就不会出现问题。但是，不能总是假设这一点，从而导致下面描述的问题。
As an example of how this could happen, consider the deployment scenario illustrated in Figure 9: the mobile network has two mobile routers MR1 and MR2, with home agents HA1 and HA2, respectively. Two bi-directional tunnels are established between the two pairs. Each MR advertises a different MNP (P1 and P2 respectively). MNP P1 is registered to HA1, and MNP P2 is registered to HA2. Thus, MNNs should be free to auto-configure their addresses on any of P1 or P2. Ingress filtering could thus happen in two cases:
作为这可能发生的一个例子，考虑图9中所示的部署场景：移动网络具有两个移动路由器MR1和MR2，分别具有归属代理HA1和HA2。在两对隧道之间建立了两条双向隧道。每个MR宣传不同的MNP（分别为P1和P2）。MNP P1注册到HA1，MNP P2注册到HA2。因此，MNN可以自由地在P1或P2中的任何一个上自动配置其地址。因此，在两种情况下可能会发生入口过滤：
o If the two tunnels are available, MNN cannot forward packet with source address equals P1.MNN to MR2. This would cause ingress filtering at HA2 to occur (or even at MR2). This is contrary to normal Neighbor Discovery [12] practice that an IPv6 node is free to choose any router as its default router regardless of the prefix it chooses to use.
o 如果两个隧道可用，MNN无法将源地址等于P1.MNN的数据包转发到MR2。这将导致在HA2发生入口过滤（甚至在MR2）。这与正常的邻居发现[12]实践相反，IPv6节点可以自由选择任何路由器作为其默认路由器，而不管它选择使用的前缀是什么。
o If the tunnel to HA1 is broken, packets that would normally be sent through the tunnel to HA1 should be diverted through the tunnel to HA2. If HA2 (or some border router in HA2's domain) performs ingress filtering, packets with source address configured from MNP P1 may be discarded.
o 如果到HA1的隧道中断，通常通过隧道发送到HA1的数据包应该通过隧道转移到HA2。如果HA2（或HA2域中的某个边界路由器）执行入口过滤，则具有从MNP P1配置的源地址的包可能被丢弃。
Prefix: P1 +-----+ +----+ +----------+ +-----+
+--| MR1 |--| AR |--| |---| HA1 |
| +-----+ +----+ | | +-----+
IP: +-----+ | | | Prefix: P1
P1.MNN or | MNN |--+ | Internet |
P2.MNN +-----+ | | | Prefix: P2
| +-----+ +----+ | | +-----+
+--| MR2 |--| AR |--| |---| HA2 |
Prefix: P2 +-----+ +----+ +----------+ +-----+
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
图9：一个（n，n，n）移动网络
Possible solutions to the ingress filtering incompatibility problem may be based on the following approaches:
入口过滤不兼容问题的可能解决方案可能基于以下方法：
o Some form of source address-dependent routing, whether host-based and/or router-based where the prefix contained in the source address of the packet is considered when deciding which exit router to use when forwarding the packet.
o 某种形式的源地址相关路由，无论是基于主机和/或基于路由器，在决定转发数据包时使用哪个出口路由器时，考虑数据包源地址中包含的前缀。
o The usage of nested tunnels for (*,n,n) cases. Appendix B describes one such approach.
o （*，n，n）情况下嵌套隧道的使用。附录B描述了一种此类方法。
o Deprecating those prefixes associated to non-available exit routers.
o 拒绝使用与不可用的出口路由器关联的前缀。
The ingress filtering incompatibilities problems that appear in some NEMO multihoming configurations are similar to those considered in Shim6 (e.g., see [16]).
某些NEMO多址配置中出现的入口过滤不兼容问题与Shim6中考虑的问题类似（例如，见[16]）。
In the (*,n,*) configuration, a single MNP would be registered at different HAs. This gives rise to the following cases:
在（*，n，*）配置中，单个MNP将在不同的HA上注册。这导致以下情况：
o Only one HA may actively advertise a route to the MNP,
o 只有一个医管局可以主动宣传通往MNP的路线，
o Multiple HAs at different domains may advertise a route to the same MNP.
o 不同域上的多个HA可以向同一MNP播发路由。
This may pose a problem in the routing infrastructure as a whole if the HAs are located in different administrative domains. The implications of this aspect needs further exploration. A certain level of HA coordination may be required. A possible approach is to adopt an HA synchronization mechanism such as that described in [17] and [18]. Such synchronization might also be necessary in a (*,n,*) configuration, when an MR sends binding update messages to only one HA (instead of all HAs). In such cases, the binding update information might have to be synchronized between HAs. The mode of synchronization may be either primary-secondary or peer-to-peer. In addition, when a MNP is delegated to the MR (see Section 4.5), some level of coordination between the HAs may also be necessary.
如果HA位于不同的管理域中，这可能会在整个路由基础设施中造成问题。这方面的影响需要进一步探讨。可能需要一定程度的医管局协调。一种可能的方法是采用如[17]和[18]中所述的HA同步机制。在（*，n，*）配置中，当MR仅向一个HA（而不是所有HA）发送绑定更新消息时，也可能需要这种同步。在这种情况下，绑定更新信息可能必须在HA之间同步。同步模式可以是主从或对等。此外，当MNP委托给MR时（见第4.5节），HAs之间可能还需要一定程度的协调。
This issue is a general mobility issue that will also have to be dealt with by Mobile IPv6 (see Section 6.2.3 in [7]) as well as NEMO Basic Support.
这个问题是一个通用的移动性问题，移动IPv6（参见[7]中的第6.2.3节）以及NEMO基本支持也必须解决这个问题。
In the (n,*,*) configurations, there are common decisions that may require synchronization among different MRs [19], such as:
在（n，*，*）配置中，存在可能需要在不同MRs之间同步的公共决策[19]，例如：
o advertising the same MNP in the (n,*,1) configurations (see also "prefix delegation" in Section 4.5);
o 在（n，*，1）配置中宣传相同的MNP（另请参见第4.5节中的“前缀委托”）；
o one MR relaying the advertisement of the MNP from another failed MR in the (n,*,n) configuration; and
o 一个MR在（n，*，n）配置中从另一个失败的MR中继MNP的广告；和
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,*,*) configuration.
o 在（n，*，*）配置中，在MRs之间中继需要中继的所有内容，例如数据包、从入口接口创建隧道等。
However, there is no known standardized protocol for this kind of router-to-router synchronization. Without such synchronization, it may not be possible for a (n,*,*) configuration to achieve various multihoming goals, such as fault tolerance.
然而，对于这种路由器到路由器的同步，还没有已知的标准化协议。如果没有这种同步，则（n，*，*）配置可能无法实现各种多主目标，例如容错。
Such a synchronization mechanism can be primary-secondary (i.e., a master MR, with the other MRs as backup) or peer-to-peer (i.e., there is no clear administrative hierarchy between the MRs). The need for such mechanism is general in the sense that a multi-router site in the fixed network would require the same level of router synchronization.
这种同步机制可以是主-辅（即，主MR，另一MR作为备份）或对等（即，MR之间没有明确的管理层次结构）。在固定网络中的多路由器站点需要相同级别的路由器同步的意义上，对这种机制的需求是普遍的。
Thus, this issue is not specific to NEMO Basic Support, though there is a more pressing need to develop an MR-to-MR synchronization scheme for proving fault tolerances and failure recovery in NEMO configurations due to the higher possibility of links failure.
因此，这个问题并不特定于NEMO基本支持，尽管由于链路故障的可能性更高，因此更迫切需要开发一个MR到MR同步方案，以证明NEMO配置中的故障容限和故障恢复。
In conclusion, it is recommended to investigate a generic solution to this issue although the solution would first have to be developed for NEMO deployments.
总之，建议研究解决该问题的通用解决方案，尽管该解决方案必须首先针对NEMO部署进行开发。
In the (*,*,1) configurations, the same MNP must be advertised to the MNNs through different paths. There is, however, no synchronization mechanism available to achieve this. Without a synchronization mechanism, MR may end up announcing incompatible MNPs. Particularly,
在（*，*，1）配置中，必须通过不同路径向MNN播发相同的MNP。但是，没有可用的同步机制来实现这一点。如果没有同步机制，MR可能最终宣布不兼容的MNP。尤其
o for the (*,n,1) cases, how can multiple HAs delegate the same MNP to the mobile network? For doing so, the HAs may be somehow configured to advertise the same MNP (see also "HA Synchronization" in Section 4.3).
o 对于（*，n，1）情况，多个HAs如何将同一MNP委托给移动网络？为此，可以通过某种方式将HAs配置为公布相同的MNP（另请参见第4.3节中的“HA同步”）。
o for the (n,*,1) cases, how can multiple MRs be synchronized to advertise the same MNP down the NEMO-link? For doing so, the MRs may be somehow configured to advertise the same MNP (see also "MR Synchronization" in Section 4.4).
o 对于（n，*，1）种情况，如何同步多个MRs以在NEMO链路上发布同一MNP？为此，可以以某种方式将MRs配置为通告相同的MNP（另请参见第4.4节中的“MR同步”）。
Prefix delegation mechanisms [20][21][22] could be used to ensure all routers advertise the same MNP. Their applicability to a multihomed mobile network should be considered.
前缀委派机制[20][21][22]可用于确保所有路由器宣传相同的MNP。应考虑其对多址移动网络的适用性。
When an MR is configured with multiple CoAs, it is often necessary for it to bind these CoAs to the same MNP.
当MR配置有多个CoA时，通常需要将这些CoA绑定到同一MNP。
This is a generic mobility issue, since Mobile IPv6 nodes face a similar problem. This issue is discussed in [7]. It is sufficient to note that solutions like [23] can solve this for both Mobile IPv6 and NEMO Basic Support. This issue is being dealt with in the Monami6 WG.
这是一个通用的移动性问题，因为移动IPv6节点面临类似的问题。[7]中讨论了这个问题。值得注意的是，像[23]这样的解决方案可以为移动IPv6和NEMO基本支持解决这一问题。Monami6工作组正在处理这个问题。
In the (*,*,n) configurations, MNNs would be configured with multiple addresses. Source address selection mechanisms are needed to decide which address to choose from.
在（*，*，n）配置中，MNN将配置多个地址。需要源地址选择机制来决定选择哪个地址。
However, currently available source address selection mechanisms do not allow MNNs to acquire sufficient information to select their source addresses intelligently (such as based on the traffic condition associated with the home network of each MNP). It may be desirable for MNNs to be able to acquire "preference" information on each MNP from the MRs. This would allow default address selection
然而，当前可用的源地址选择机制不允许MNN获取足够的信息来智能地选择其源地址（例如，基于与每个MNP的家庭网络相关联的业务状况）。MNN可能希望能够从MRs获取每个MNP的“偏好”信息。这将允许默认地址选择
mechanisms, such as those specified in [24], 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. Note that source address selection may be closely related to path selection procedures (see Section 4.1.3) and re-homing techniques (see Section 4.1.4).
拟使用的机制，如[24]中规定的机制。基于双向隧道的性能，进一步探索在路由器广告中设置这种“偏好”信息可能是有用的。注意，源地址选择可能与路径选择程序（见第4.1.3节）和重设原点技术（见第4.1.4节）密切相关。
This is a general issue faced by any node when offered multiple prefixes.
当提供多个前缀时，这是任何节点都会面临的一般问题。
When a multihomed mobile network is nested within another mobile network, it can result in very complex topologies. For instance, a nested mobile network may be attached to two different root-MRs, thus the aggregated network no longer forms a simple tree structure. In such a situation, infinite loop within the mobile network may occur.
当一个多宿移动网络嵌套在另一个移动网络中时，可能会产生非常复杂的拓扑结构。例如，嵌套的移动网络可以连接到两个不同的根mr，因此聚合的网络不再形成简单的树结构。在这种情况下，移动网络内可能发生无限循环。
This problem is specific to NEMO Basic Support. However, at the time of writing, more research is recommended to assess the probability of loops occurring in a multihomed mobile network. For related work, see [25] for a mechanism to avoid loops in nested NEMO.
这个问题是特定于尼莫基本支持的。然而，在撰写本文时，建议进行更多的研究，以评估多址移动网络中发生环路的概率。有关相关工作，请参见[25]，了解避免嵌套NEMO中循环的机制。
When a (n,*,1) network splits, (i.e., the two MRs split themselves up), MRs on distinct links may try to register the only available MNP. This cannot be allowed, as the HA has no way to know which node with an address configured from that MNP is attached to which MR. Some mechanism must be present for the MNP to either be forcibly removed from one (or all) MRs, or the implementors must not allow a (n,*,1) network to split.
当（n，*，1）网络分裂时（即，两个MRs自身分裂），不同链路上的MRs可以尝试注册唯一可用的MNP。这是不允许的，因为HA无法知道从该MNP配置了地址的节点连接到哪个MR。必须存在某种机制才能从一个（或所有）MRs强制删除MNP，或者实现者不得允许（n，*，1）网络拆分。
A possible approach to solving this problem is described in [26].
[26]中描述了解决此问题的可能方法。
This problem is specific to NEMO Basic Support. However, it is unclear whether there is a sufficient deployment scenario for this problem to occur.
这个问题是特定于尼莫基本支持的。但是，目前尚不清楚是否有足够的部署场景来解决此问题。
It is recommended that the NEMO WG standardize a solution to solve this problem if there is sufficient vendor/operator interest, or specify that the split of a (n,*,1) network cannot be allowed without router renumbering.
如果供应商/运营商有足够的兴趣，建议NEMO工作组将解决此问题的解决方案标准化，或规定在未对路由器重新编号的情况下，不允许拆分（n，*，1）网络。
When a mobile network is multihomed, the MNNs may be able to benefit from this configuration, 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:
当移动网络是多址的时，mnn可以从该配置中受益，例如基于成本、传输延迟、带宽等在可用路径中进行选择。然而，在某些情况下，mnn不能进行这种选择。尤其：
o In the (*,*,n) configuration, the MNNs can influence the path by source address selection (see Section 4.1.3 and Section 4.7).
o 在（*，*，n）配置中，MNN可通过源地址选择影响路径（见第4.1.3节和第4.7节）。
o In the (n,*,*) configuration, the MNNs can influence the path by default router selection (see Section 4.1.3).
o 在（n，*，*）配置中，MNN可通过默认路由器选择影响路径（见第4.1.3节）。
o In the (1,n,1) configuration, the MNNs cannot influence the path selection.
o 在（1，n，1）配置中，MNN不能影响路径选择。
One aspect of preference setting is that the preference of the MNN (e.g., application or transport layer configuration) may not be the same as the preference used by MR. Thus, forwarding choices made by the MR may not be the best for a particular flow, and may even be detrimental to some transport control loops (i.e., the flow control algorithm for TCP may be messed up when MR unexpectedly performs load balancing on a TCP flow). A mechanism that allows the MNN to indicate its preference for a given traffic might be helpful here.
偏好设置的一个方面是，MNN的偏好（例如，应用或传输层配置）可能与MR使用的偏好不同。因此，MR做出的转发选择可能不是特定流的最佳选择，甚至可能对一些传输控制环路有害（即，当MR意外地对TCP流执行负载平衡时，TCP的流控制算法可能会出错）。允许MNN指示其对给定流量的偏好的机制在这里可能会有所帮助。
Another aspect of preference setting is that the MNN may not even be aware of the existence of multiple forwarding paths, e.g., the (1,n,1) configuration. A mechanism for the MR to advertise the availability of multiple tunneling paths would allow the MNN to take advantage of this, coupled with the previously mentioned mechanism that allows the MNN to indicate its preference for a given traffic.
偏好设置的另一方面是，MNN甚至可能不知道存在多个转发路径，例如（1，n，1）配置。用于MR宣传多个隧道路径的可用性的机制将允许MNN利用这一点，与前面提到的允许MNN指示其对给定业务的偏好的机制相结合。
This problem is general in the sense that IPv6 nodes may wish to influence the routing decision done by the upstream routers. Such a mechanism is currently being explored by various WGs, such as the NSIS and IPFIX WGs. It is also possible that the Shim6 layer in the MNNs may possess such a capability. It is recommended for vendors or operators to investigate into the solutions developed by these WGs when providing multihoming capabilities to mobile networks.
这个问题是一般意义上的IPv6节点可能希望影响上游路由器所做的路由决策。各种工作组，如NSIS和IPFIX工作组，目前正在探索这种机制。MNN中的Shim6层也可能具有这种能力。建议供应商或运营商在向移动网络提供多主功能时调查这些工作组开发的解决方案。
In addition, the Monami6 WG is currently developing a flow filtering solution for mobile nodes to indicate how flows should be forwarded by a filtering agent [27] (such as HA and mobile anchor points). It is recommended that the Monami6 WG consider the issues described here so that flow filtering can be performed by the MNN to indicate how flows should be forwarded by the MR.
此外，Monami6 WG目前正在为移动节点开发流过滤解决方案，以指示过滤代理如何转发流[27]（如HA和移动锚定点）。建议MONAMI6 WG考虑这里所描述的问题，以便MNN可以执行流过滤，以指示MMR如何转发流量。
Several issues that might impact the deployment of NEMO with multihoming capabilities were identified in Section 4. These are shown in the matrix below, for each of the eight multihoming configurations, together with indications from which WG(s) a solution to each issue is most likely to be found.
第4节确定了可能影响NEMO部署多归宿能力的几个问题。以下矩阵中显示了八种多归宿配置中的每一种配置，以及工作组最有可能找到每个问题解决方案的指示。
+=================================================================+
| # of MRs: | 1 | 1 | 1 | 1 | n | n | n | n |
| # of HAs: | 1 | 1 | n | n | 1 | 1 | n | n |
| # of Prefixes: | 1 | n | 1 | n | 1 | n | 1 | n |
+=================================================================+
| Fault Tolerance | * | * | * | * | * | * | * | * |
+---------------------------------+---+---+---+---+---+---+---+---+
| Failure Detection |N/M|N/M|N/M|N/M|N/M|N/M| N | S |
+---------------------------------+---+---+---+---+---+---+---+---+
| Path Exploration |N/M|N/M|N/M|N/M|N/M|N/M| N | S |
+---------------------------------+---+---+---+---+---+---+---+---+
| Path Selection | N |S/M| M |S/M| N |S/N| N |S/N|
+---------------------------------+---+---+---+---+---+---+---+---+
| Re-Homing |N/M| S |N/M| S |N/M| S |N/M| S |
+---------------------------------+---+---+---+---+---+---+---+---+
| Ingress Filtering | . | . | . | t | . | . | . | N |
+---------------------------------+---+---+---+---+---+---+---+---+
| HA Synchronization | . | . |N/M|N/M| . | . |N/M|N/M|
+---------------------------------+---+---+---+---+---+---+---+---+
| MR Synchronization | . | . | . | . | G | G | G | G |
+---------------------------------+---+---+---+---+---+---+---+---+
| Prefix Delegation | . | . | N | N | N | N | N | N |
+---------------------------------+---+---+---+---+---+---+---+---+
| Multiple Binding/Registrations | M | M | M | M | M | M | M | M |
+---------------------------------+---+---+---+---+---+---+---+---+
| Source Address Selection | . | G | . | G | . | G | . | G |
+---------------------------------+---+---+---+---+---+---+---+---+
| Loop Prevention in Nested NEMO | N | N | N | N | N | N | N | N |
+---------------------------------+---+---+---+---+---+---+---+---+
| Prefix Ownership | . | . | . | . | N | . | N | . |
+---------------------------------+---+---+---+---+---+---+---+---+
| Preference Settings | G | G | G | G | G | G | G | G |
+=================================================================+
N - NEMO Specific M - MIPv6 Specific G - Generic IPv6
S - SHIM6 WG D - DNA WG
. - Not an Issue t - trivial
* - Fault Tolerance is a combination of Failure Detection, Path
Exploration, Path Selection, and Re-Homing
+=================================================================+
| # of MRs: | 1 | 1 | 1 | 1 | n | n | n | n |
| # of HAs: | 1 | 1 | n | n | 1 | 1 | n | n |
| # of Prefixes: | 1 | n | 1 | n | 1 | n | 1 | n |
+=================================================================+
| Fault Tolerance | * | * | * | * | * | * | * | * |
+---------------------------------+---+---+---+---+---+---+---+---+
| Failure Detection |N/M|N/M|N/M|N/M|N/M|N/M| N | S |
+---------------------------------+---+---+---+---+---+---+---+---+
| Path Exploration |N/M|N/M|N/M|N/M|N/M|N/M| N | S |
+---------------------------------+---+---+---+---+---+---+---+---+
| Path Selection | N |S/M| M |S/M| N |S/N| N |S/N|
+---------------------------------+---+---+---+---+---+---+---+---+
| Re-Homing |N/M| S |N/M| S |N/M| S |N/M| S |
+---------------------------------+---+---+---+---+---+---+---+---+
| Ingress Filtering | . | . | . | t | . | . | . | N |
+---------------------------------+---+---+---+---+---+---+---+---+
| HA Synchronization | . | . |N/M|N/M| . | . |N/M|N/M|
+---------------------------------+---+---+---+---+---+---+---+---+
| MR Synchronization | . | . | . | . | G | G | G | G |
+---------------------------------+---+---+---+---+---+---+---+---+
| Prefix Delegation | . | . | N | N | N | N | N | N |
+---------------------------------+---+---+---+---+---+---+---+---+
| Multiple Binding/Registrations | M | M | M | M | M | M | M | M |
+---------------------------------+---+---+---+---+---+---+---+---+
| Source Address Selection | . | G | . | G | . | G | . | G |
+---------------------------------+---+---+---+---+---+---+---+---+
| Loop Prevention in Nested NEMO | N | N | N | N | N | N | N | N |
+---------------------------------+---+---+---+---+---+---+---+---+
| Prefix Ownership | . | . | . | . | N | . | N | . |
+---------------------------------+---+---+---+---+---+---+---+---+
| Preference Settings | G | G | G | G | G | G | G | G |
+=================================================================+
N - NEMO Specific M - MIPv6 Specific G - Generic IPv6
S - SHIM6 WG D - DNA WG
. - Not an Issue t - trivial
* - Fault Tolerance is a combination of Failure Detection, Path
Exploration, Path Selection, and Re-Homing
Figure 10: Matrix of NEMO Multihoming Issues
图10：NEMO多址问题矩阵
The above matrix serves to identify which issues are NEMO-specific, and which are not. The readers are reminded that this matrix is a simplification of Section 4 as subtle details are not represented in Figure 10.
上述矩阵用于确定哪些问题是针对NEMO的，哪些不是。提醒读者，该矩阵是对第4节的简化，因为图10中没有显示细微的细节。
As can be seen from Figure 10, the following are some concerns that 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:
从图10可以看出，以下是NEMO特有的一些问题：故障检测、路径探索、路径选择、重新归巢、入口过滤、HA同步、前缀委派、嵌套NEMO中的环路预防和前缀所有权。根据作者对NEMO可能部署的最佳了解，建议：
o A solution for Failure Detection, Path Exploration, Path Selection, and Re-Homing be solicited from other WGs.
o 可以向其他工作组寻求故障检测、路径探索、路径选择和重新定位的解决方案。
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 vendors to solicit a solution for these issues from other WGs in the IETF; for instance, the Monami6 or Shim6 WG.
尽管路径选择在图10中反映为特定于NEMO的，但该问题的技术考虑被认为与移动节点中多条路径的选择非常相似。因此，我们建议供应商向IETF中的其他工作组征求这些问题的解决方案；例如，Monami6或Shim6 WG。
o Ingress Filtering on the (n,n,n) configuration can be solved by the NEMO WG.
o NEMO WG可解决（n，n，n）配置上的入口过滤问题。
This problem is clearly defined, and can be solved by the WG. Deployment of the (n,n,n) configuration can be envisioned on vehicles for mass transportation (such as buses, trains) where different service providers may install their own MRs on the vehicle/vessel.
这个问题定义明确，工作组可以解决。（n，n，n）配置的部署可以设想在大众运输车辆（如公共汽车、火车）上，不同的服务提供商可以在车辆/船只上安装自己的MRs。
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 concentrate only on the (n,n,n) configuration should the WG decide to work on this issue.
应该注意的是，在更一般的意义上，Shim6 WG可能正在开发一种克服入口过滤的机制。因此，我们建议，如果NEMO工作组决定处理此问题，NEMO工作组应仅关注（n，n，n）配置。
o A solution for HA Synchronization can be looked at in a mobility-specific WG, taking into consideration both mobile hosts operating Mobile IPv6 and MRs operating NEMO Basic Support.
o HA同步解决方案可以在移动特定工作组中查看，同时考虑到运行移动IPv6的移动主机和运行NEMO基本支持的MRs。
o A solution for Multiple Bindings/Registrations is presently being developed by the Monami6 WG.
o Monami6工作组目前正在开发一种多绑定/注册解决方案。
o Prefix Delegation should be reviewed and checked by the NEMO WG.
o 前缀授权应由NEMO工作组审查和检查。
The proposed solutions [22] and [21] providing prefix delegation functionality to NEMO Basic Support should be reviewed in order to
应审查向NEMO基本支持提供前缀授权功能的拟议解决方案[22]和[21]，以便
make sure concerns, as discussed in Section 4.5, are properly handled.
确保第4.5节中讨论的问题得到妥善处理。
o Loop Prevention in Nested NEMO should be investigated.
o 应调查嵌套NEMO中的环路预防。
Further research is recommended to assess the risk of having a loop in the nesting of multihomed mobile networks.
建议进行进一步研究，以评估多宿移动网络嵌套中存在环路的风险。
o Prefix Ownership should be considered by the vendors and operators.
o 供应商和运营商应考虑前缀所有权。
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.
只有当具有多个MRs和单个MNP的移动网络可以任意加入和拆分时，才会出现前缀所有权问题。鼓励移动网络供应商和运营商就部署此类移动网络的适用性发表意见。
This memo presented an analysis of multihoming in the context of network mobility under the operation of NEMO Basic Support (RFC 3963). The purpose was to investigate issues related to such a bi-directional tunneling mechanism where mobile networks are multihomed and multiple bi-directional tunnels are established between Home Agent and Mobile Router pairs. For doing so, mobile networks were classified into a taxonomy comprising eight possible multihomed configurations. Issues were explained one by one and then summarized into a table showing the multihomed configurations where they apply, suggesting the most relevant IETF working group where they could be solved. This analysis will be helpful to extend the existing standards to support multihoming and to implementors of NEMO Basic Support and multihoming-related mechanisms.
本备忘录介绍了在NEMO基本保障（RFC 3963）运作下，网络移动性背景下的多址分析。目的是研究与这种双向隧道机制相关的问题，其中移动网络是多址的，并且在归属代理和移动路由器对之间建立了多个双向隧道。为此，移动网络被划分为一个分类法，包括八种可能的多址配置。一个接一个地解释了问题，然后总结成一个表格，显示了它们适用的多址配置，建议了最相关的IETF工作组在哪里可以解决这些问题。该分析将有助于扩展现有标准，以支持多宿，并有助于NEMO基本支持和多宿相关机制的实施者。
This is an informational document where the multihoming configurations under the operation of NEMO Basic Support are analyzed. Security considerations of these multihoming configurations, should they be different from those that concern NEMO Basic Support, must be considered by forthcoming solutions. For instance, an attacker could try to use the multihomed device as a means to access another network that would not be normally reachable through the Internet. Even when forwarding to another network is turned off by configuration, an attacker could compromise a system to enable it.
这是一份信息性文件，其中分析了NEMO基本保障下的多主配置。未来的解决方案必须考虑这些多主配置的安全考虑因素，如果它们与NEMO基本支持不同的话。例如，攻击者可以尝试使用多宿设备作为访问另一个通常无法通过Internet访问的网络的手段。即使配置关闭了向另一个网络的转发，攻击者也可能破坏系统以启用它。
The authors would like to thank people who have given valuable comments on various multihoming issues on the mailing list, and also those who have suggested directions in the 56th - 61st IETF Meetings. The initial evaluation of NEMO Basic Support on multihoming configurations is a contribution from Julien Charbon.
作者要感谢那些在邮件列表上对各种多主机问题提出宝贵意见的人，以及那些在第56-61届IETF会议上提出方向建议的人。NEMO对多主配置的基本支持的初步评估是Julien Charbon的贡献。
[1] Ernst, T., "Network Mobility Support Goals and Requirements", RFC 4886, July 2007.
[1] Ernst，T.，“网络移动性支持目标和要求”，RFC 48862007年7月。
[2] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[2] Way，J.和M.Kojo，“机动性相关术语”，RFC 3753，2004年6月。
[3] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007.
[3] Ernst，T.和H-Y.Lach，“网络移动支持术语”，RFC 48852007年7月。
[4] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[4] Devarapalli，V.，Wakikawa，R.，Petrescu，A.，和P.Thubert，“网络移动（NEMO）基本支持协议”，RFC 3963，2005年1月。
[5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[5] Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[6] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and K. Kuladinithi, "Motivations and Scenarios for Using Multiple Interfaces and Global Addresses", Work in Progress, October 2006.
[6] Ernst，T.，Montavont，N.，Wakikawa，R.，Ng，C.，和K.Kuladinhi，“使用多个接口和全局地址的动机和场景”，正在进行的工作，2006年10月。
[7] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", Work in Progress, February 2006.
[7] N.Montavont、R.Wakikawa、T.Ernst、T.Ng、C.和K.Kuladinhi，“移动IPv6中的多宿分析”，正在进行的工作，2006年2月。
[8] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[8] Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[9] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", Work in Progress, December 2006.
[9] Arkko，J.和I.Beijnum，“IPv6多宿的故障检测和定位对探测协议”，正在进行的工作，2006年12月。
[10] Krishnan, S., Montavont, N., Yegin, A., Veerepalli, S., and A. Yegin, "Link-layer Event Notifications for Detecting Network Attachments", Work in Progress, November 2006.
[10] Krishnan，S.，Montavont，N.，Yegin，A.，Veerepalli，S.，和A.Yegin，“用于检测网络附件的链路层事件通知”，正在进行的工作，2006年11月。
[11] Narayanan, S., "Detecting Network Attachment in IPv6 Networks (DNAv6)", Work in Progress, October 2006.
[11] Narayanan，S.，“在IPv6网络中检测网络连接（DNAv6）”，正在进行的工作，2006年10月。
[12] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[12] Narten，T.，Nordmark，E.，和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC24611998年12月。
[13] Nordmark, E. and M. Bagnulo, "Level 3 multihoming shim protocol", Work in Progress, November 2006.
[13] Nordmark，E.和M.Bagnulo，“第3级多归宿垫片协议”，正在进行的工作，2006年11月。
[14] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[14] Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[15] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[15] Baker，F.和P.Savola，“多址网络的入口过滤”，BCP 84，RFC 37042004年3月。
[16] Huitema, C. and M. Marcelo, "Ingress filtering compatibility for IPv6 multihomed sites", Work in Progress, October 2006.
[16] Huitema，C.和M.Marcelo，“IPv6多宿主站点的入口过滤兼容性”，正在进行的工作，2006年10月。
[17] Wakikawa, R., Devarapalli, V., and P. Thubert, "Inter Home Agents Protocol (HAHA)", Work in Progress, February 2004.
[17] Wakikawa，R.，Devarapalli，V.，和P.Thubert，“居家代理协议（HAHA）”，正在进行的工作，2004年2月。
[18] Koh, B., Ng, C., and J. Hirano, "Dynamic Inter Home Agent Protocol", Work in Progress, July 2004.
[18] Koh，B.，Ng，C.，和J.Hirano，“动态居家代理协议”，正在进行的工作，2004年7月。
[19] Tsukada, M., "Analysis of Multiple Mobile Routers Cooperation", Work in Progress, October 2005.
[19] Tsukada，M.，“多移动路由器合作分析”，正在进行的工作，2005年10月。
[20] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix Delegation", RFC 3769, June 2004.
[20] Miyakawa，S.和R.Droms，“IPv6前缀授权的要求”，RFC 3769，2004年6月。
[21] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO", Work in Progress, September 2006.
[21] Droms，R.和P.Thubert，“NEMO的DHCPv6前缀代表团”，正在进行的工作，2006年9月。
[22] Thubert, P. and TJ. Kniveton, "Mobile Network Prefix Delegation", Work in Progress, November 2006.
[22] Thubert，P.和TJ。Kniveton，“移动网络前缀代表团”，正在进行的工作，2006年11月。
[23] Wakikawa, R., "Multiple Care-of Addresses Registration", Work in Progress, June 2006.
[23] Wakikawa，R.，“多重照顾地址登记”，正在进行的工作，2006年6月。
[24] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[24] Draves，R.，“因特网协议版本6（IPv6）的默认地址选择”，RFC 3484，2003年2月。
[25] Thubert, P., Bontous, C., and N. Nicolas, "Nested Nemo Tree Discovery", Work in Progress, November 2006.
[25] Thubert，P.，Bontous，C.，和N.Nicolas，“嵌套尼莫树发现”，正在进行的工作，2006年11月。
[26] Kumazawa, M., "Token based Duplicate Network Detection for split mobile network (Token based DND)", Work in Progress, July 2005.
[26] Kumazawa，M.，“分裂移动网络中基于令牌的重复网络检测（基于令牌的DND）”，正在进行的工作，2005年7月。
[27] Soliman, H., "Flow Bindings in Mobile IPv6 and NEMO Basic Support", Work in Progress, March 2007.
[27] Soliman，H.，“移动IPv6和NEMO基本支持中的流绑定”，进展中的工作，2007年3月。
An alternative approach to classifying a multihomed mobile network was proposed by Erik Nordmark (Sun Microsystems) by breaking the classification of multihomed network based on ownership. This is more of a tree-like, top-down classification. Starting from the control and ownership of the HA(s) and MR(s), there are two different possibilities: either (i) the HA(s) and MR(s) are controlled by a single entity, or (ii) the HA(s) and MR(s) are controlled by separate entities. We called the first possibility the 'ISP Model', and the second the 'Subscriber/Provider Model'.
Erik Nordmark（Sun Microsystems）通过打破基于所有权的多宿网络分类，提出了另一种对多宿移动网络进行分类的方法。这更像是一种树状的自上而下的分类。从房委会和MR的控制权和所有权开始，有两种不同的可能性：（i）房委会和MR由单一实体控制，或（ii）房委会和MR由独立实体控制。我们称第一种可能性为“ISP模式”，第二种可能性为“订户/提供商模式”。
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 MRs on trains, ships, or planes. It is up to the ISP to deploy a certain configuration of mobile network; all 8 configurations, as described in the Configuration-Oriented Approach, are possible. In the remaining portion of this document, when specifically referring to a mobile network configuration that is controlled by a single entity, we will add an 'ISP' prefix; for example, ISP-(1,1,1) or ISP-(1,n,n).
HA（s）和MR（s）由同一实体控制的情况可以最好地说明为互联网服务提供商（ISP）在火车、轮船或飞机上安装MRs。由ISP部署特定的移动网络配置；如面向配置的方法中所述，所有8种配置都是可能的。在本文档的剩余部分，当特别提到由单个实体控制的移动网络配置时，我们将添加“ISP”前缀；例如，ISP-（1,1,1）或ISP-（1，n，n）。
When the HA(s) and MR(s) are controlled by a single entity (such as an ISP), the ISP can decide whether it wants to assign one or multiple MNPs to the mobile network just like it can make the same decision for any other link in its network (wired or otherwise). In any case, the ISP will make the routing between the mobile networks and its core routers (such as the HAs) work. This includes not introducing any aggregation between the HAs, which will filter out routing announcements for the MNP(s).
当HA和MR由单个实体（如ISP）控制时，ISP可以决定是否要将一个或多个MNP分配给移动网络，就像它可以对其网络中的任何其他链路（有线或其他）做出相同的决定一样。在任何情况下，ISP都会使移动网络与其核心路由器（如HAs）之间的路由正常工作。这包括不在HA之间引入任何聚合，这将过滤掉MNP的路由公告。
To such ends, the ISP has various means and mechanisms. For one, the ISP can run its Interior Gateway Protocol (IGP) over bi-directional tunnels between the MR(s) and HA(s). Alternatively, static routes may be used with the tunnels. When static routes are used, a mechanism to test "tunnel liveness" might be necessary to avoid maintaining stale routes. Such "tunnel liveness" may be tested by sending heartbeats signals from MR(s) to the HA(s). A possibility is to simulate heartbeats using Binding Updates messages by controlling the "Lifetime" field of the Binding Acknowledgment message to force the MR to send Binding Update messages at regular intervals. However, a more appropriate tool might be the Binding Refresh Request
为此，ISP有各种手段和机制。例如，ISP可以在MR和HA之间的双向隧道上运行其内部网关协议（IGP）。或者，静态路线可与隧道一起使用。当使用静态路由时，可能需要一种测试“隧道活跃度”的机制，以避免维护过时的路由。可以通过从MR向HA发送心跳信号来测试这种“隧道活性”。一种可能性是通过控制绑定确认消息的“生存期”字段来使用绑定更新消息模拟心跳，以强制MR定期发送绑定更新消息。但是，更合适的工具可能是绑定刷新请求
message, though conformance to the Binding Refresh Request message may be less strictly enforced in implementations since it serves a somewhat secondary role when compared to Binding Update messages.
消息，但在实现中对绑定刷新请求消息的一致性可能不那么严格，因为与绑定更新消息相比，它起着次要的作用。
The case of the HA(s) and MR(s) controlled by the separate entities can be best illustrated with a subscriber/provider model, where the MRs belongs to a single subscriber and subscribes to one or more ISPs for HA services. There is two sub-categories in this case: when the subscriber subscribes to a single ISP, and when the subscriber subscribes to multiple ISPs. In the remaining portion of this document, when specifically referring to a mobile network configuration that is in the subscriber/provider model where the subscriber subscribes to only one ISP, we will add an 'S/P' prefix; for example, S/P-(1,1,1) or S/P-(1,n,n). When specifically referring to a mobile network configuration that is in the subscriber/provider model where the subscriber subscribes to multiple ISPs, we will add an 'S/mP' prefix; for example, S/mP-(1,1,1) or S/mP-(1,n,n).
由独立实体控制的HA（s）和MR（s）的情况可以用订户/提供商模型来最好地说明，其中MRs属于单个订户并为HA服务向一个或多个ISP订户。在这种情况下，有两个子类别：当用户订阅单个ISP时，以及当用户订阅多个ISP时。在本文档的剩余部分中，当特别提到订户/提供商模型中的移动网络配置时，订户只订阅一个ISP，我们将添加一个“S/P”前缀；例如，S/P-（1,1,1）或S/P-（1,n，n）。当特别提到订户/提供商模型中的移动网络配置时，订户订阅多个ISP，我们将添加“S/mP”前缀；例如，S/mP-（1,1,1）或S/mP-（1，n，n）。
Not all 8 configurations are likely to be deployed for the S/P and S/mP models. For instance, it is unlikely to foresee a S/mP-(*,1,1) mobile network where there is only a single HA. For the S/P model, the following configurations are likely to be deployed:
并非所有8种配置都可能部署到S/P和S/mP型号。例如，不太可能预见只有一个HA的S/mP-（*，1,1）移动网络。对于S/P型号，可能会部署以下配置：
o S/P-(1,1,1): Single Provider, Single MR, Single HA, Single MNP
o S/P-（1,1,1）：单一供应商、单一MR、单一HA、单一MNP
o S/P-(1,1,n): Single Provider, Single MR, Single HA, Multiple MNPs
o S/P-（1,1，n）：单个提供商、单个MR、单个HA、多个MNP
o S/P-(1,n,1): Single Provider, Single MR, Multiple HAs, Single MNP
o S/P-（1，n，1）：单供应商，单MR，多HAs，单MNP
o S/P-(1,n,n): Single Provider, Single MR, Multiple HAs, Multiple MNPs
o S/P-（1，n，n）：单个提供者、单个MR、多个HAs、多个MNP
o S/P-(n,n,1): Single Provider, Multiple MRs, Single HA, Single MNP
o S/P-（n，n，1）：单个提供者、多个MRs、单个HA、单个MNP
o S/P-(n,1,n): Single Provider, Multiple MRs, Single HA, Multiple MNPs
o S/P-（n，1，n）：单个提供者、多个MRs、单个HA、多个MNP
o S/P-(n,n,1): Single Provider, Multiple MRs, Multiple HAs, Single MNP
o S/P-（n，n，1）：单个提供者、多个MRs、多个HAs、单个MNP
o S/P-(n,n,n): Single Provider, Multiple MRs, Multiple HAs, Multiple MNPs
o S/P-（n，n，n）：单个提供者、多个MRs、多个HAs、多个MNP
For the S/mP model, the following configurations are likely to be deployed:
对于S/mP型号，可能会部署以下配置：
o S/mP-(1,n,1): Multiple Providers, Single MR, Multiple HAs, Single MNP
o S/mP-（1，n，1）：多个提供者，单个MR，多个HAs，单个MNP
o S/mP-(1,n,n): Multiple Providers, Single MR, Multiple HAs, Multiple MNPs
o S/mP-（1，n，n）：多个提供者、单个MR、多个HAs、多个MNP
o S/mP-(n,n,n): Multiple Providers, Multiple MRs, Multiple HAs, Multiple MNPs
o S/mP-（n，n，n）：多个提供者、多个MRs、多个HAs、多个MNP
When the HA(s) and MR(s) are controlled by different entities, it is more likely that the MR is controlled by one entity (i.e., the subscriber), and the MR is establishing multiple bi-directional tunnels to one or more HA(s) provided by one or more ISP(s). In such cases, it is unlikely that the ISP will run IGP over the bi-directional tunnel, since the ISP will most certainly wish to retain full control of its routing domain.
当HA（s）和MR（s）由不同的实体控制时，MR更有可能由一个实体（即订户）控制，并且MR正在建立到一个或多个ISP提供的一个或多个HA（s）的多个双向隧道。在这种情况下，ISP不太可能在双向隧道上运行IGP，因为ISP肯定希望保留对其路由域的完全控制。
A third approach was proposed by Pascal Thubert (Cisco Systems). This focused on the problems of multihomed mobile networks rather than the configuration or ownership. With this approach, there is a set of 4 categories based on two orthogonal parameters: the number of HAs, and the number of MNPs advertised. Since the two parameters are orthogonal, the categories are not mutually exclusive. The four categories are:
Pascal Thubert（思科系统）提出了第三种方法。这集中于多址移动网络的问题，而不是配置或所有权问题。使用这种方法，有一组4个类别，基于两个正交参数：HA的数量和广告的MNP的数量。由于这两个参数是正交的，因此类别并不相互排斥。这四类是：
o Tarzan: Single HA for Different CoAs of Same MNP
o 泰山：同一MNP的不同CoA的单一HA
This is the case where one MR registers different CoAs to the same HA for the same subnet prefix. This is equivalent to the case of y=1, i.e., the (1,1,*) mobile network.
这是一个MR为同一子网前缀向同一HA注册不同CoA的情况。这相当于y＝1的情况，即（1,1，*）移动网络。
o JetSet: Multiple HAs for Different CoAs of Same MNP
o JetSet:同一MNP的不同CoA有多个HA
This is the case where the MR registers different CoAs to different HAs for the same subnet prefix. This is equivalent to the case of y=n, i.e., the (1,n,*) mobile network.
在这种情况下，MR为同一子网前缀向不同的HA注册不同的COA。这相当于y＝n的情况，即（1，n，*）移动网络。
o Shinkansen: Single MNP Advertised by MR(s)
o 新干线：由MR（s）宣传的单一MNP
This is the case where one MNP is announced by different MRs. This is equivalent to the case of x=n and z=1, i.e., the (n,*,1) mobile network.
这是由不同的mr宣布一个MNP的情况。这相当于x=n和z=1的情况，即（n，*，1）移动网络。
o DoubleBed: Multiple MNPs Advertised by MR(s)
o 双人床：由MR宣传的多个MNP
This is the case where more than one MNPs are announced by the different MRs. This is equivalent to the case of x=n and z=n, i.e., the (n,*,n) mobile network.
这是由不同的MRs宣布多个mnp的情况。这相当于x＝n和z＝n的情况，即（n，*，n）移动网络。
In order to utilize the additional robustness provided by multihoming, MRs that employ bi-directional tunneling with their HAs should dynamically change their tunnel exit points depending on the link status. For instance, if an MR detects that one of its egress interface is down, it should detect if alternate routes to the global Internet exists. This alternate route may be provided by any other MRs connected to one of its ingress interfaces that has an independent route to the global Internet, or by another active egress interface the MR itself possesses. If such an alternate route exists, the MR should re-establish the bi-directional tunnel using this alternate route.
为了利用多宿提供的额外鲁棒性，采用双向隧道和其HAs的MRs应根据链路状态动态改变其隧道出口点。例如，如果MR检测到其一个出口接口关闭，则应检测是否存在到全球互联网的备用路由。该备用路由可由连接到其具有到全球互联网的独立路由的入口接口之一的任何其他MR提供，或由MR自身拥有的另一个活动出口接口提供。如果存在此类备用路线，MR应使用该备用路线重新建立双向隧道。
In the remaining part of this Appendix, we will attempt to investigate methods of performing such re-establishment of bi-directional tunnels. This method of tunnel re-establishment is particularly useful for the (*,n,n) NEMO configuration. The method described is by no means complete and merely serves as a suggestion on how to approach the problem. It is also not the objective to specify a new protocol specifically tailored to provide this form of re-establishments. Instead, we will limit ourselves to currently available mechanisms specified in Mobile IPv6 [5] and Neighbor Discovery in IPv6 [12].
在本附录的剩余部分中，我们将尝试研究重建双向隧道的方法。这种隧道重建方法对于（*，n，n）NEMO配置特别有用。所描述的方法绝不是完整的，只是作为如何解决问题的建议。目的也不是具体规定专门为提供这种形式的重建而制定的新协议。相反，我们将仅限于移动IPv6[5]中指定的当前可用机制和IPv6[12]中指定的邻居发现机制。
To actively utilize the robustness provided by multihoming, an MR must first be capable of detecting alternate routes. This can be manually configured into the MR by the administrators if the configuration of the mobile network is relatively static. It is however highly desirable for MRs to be able to discover alternate routes automatically for greater flexibility.
为了积极利用多归宿提供的鲁棒性，MR必须首先能够检测备用路由。如果移动网络的配置相对静态，则管理员可以将其手动配置到MR中。然而，MRs非常希望能够自动发现备用路线，以获得更大的灵活性。
The case where an MR possesses multiple egress interface (bound to the same HA or otherwise) should be trivial, since the MR should be able to "realize" it has multiple routes to the global Internet.
MR拥有多个出口接口（绑定到同一HA或其他）的情况应该很简单，因为MR应该能够“意识到”它有多条通向全球互联网的路由。
In the case where multiple MRs are on the mobile network, each MR has to detect the presence of other MR. An MR can do so by listening for Router Advertisement message on its *ingress* interfaces. When an MR receives a Router Advertisement message with a non-zero Router
在移动网络上有多个MR的情况下，每个MR必须检测到其他MR的存在。MR可以通过在其*入口*接口上侦听路由器广告消息来检测其他MR的存在。当MR通过非零路由器接收路由器广告消息时
Lifetime field from one of its ingress interfaces, it knows that another MR that can provide an alternate route to the global Internet is present in the mobile network.
从它的一个入口接口，它知道移动网络中存在另一个可以提供到全球互联网的备用路由的MR。
When an MR detects that the link by which its current bi-directional tunnel with its HA is using is down, it needs to re-establish the bi-directional tunnel using an alternate route detected. We consider two separate cases here: firstly, the alternate route is provided by another egress interface that belongs to the MR; secondly, the alternate route is provided by another MR connected to the mobile network. We refer to the former case as an alternate route provided by an alternate egress interface, and the latter case as an alternate route provided by an alternate MR.
当MR检测到其当前双向隧道及其HA使用的链路断开时，它需要使用检测到的备用路由重新建立双向隧道。我们考虑了两个不同的情况：首先，另一个路由由属于MR的另一个出口接口提供；其次，备用路由由连接到移动网络的另一MR提供。我们将前一种情况称为备用出口接口提供的备用路线，将后一种情况称为备用MR提供的备用路线。
When an egress interface of an MR loses the connection to the global Internet, the MR can make use of its alternate egress interface should it possess multiple egress interfaces. The most direct way to do so is for the MR to send a binding update to the HA of the failed interface using the CoA assigned to the alternate interface in order to re-establish the bi-directional tunneling using the CoA on the alternate egress interface. After a successful binding update, the MR encapsulates outgoing packets through the bi-directional tunnel using the alternate egress interface.
当MR的出口接口失去与全球互联网的连接时，如果MR拥有多个出口接口，则可以使用其备用出口接口。最直接的方法是MR使用分配给备用接口的CoA向故障接口的HA发送绑定更新，以便在备用出口接口上使用CoA重新建立双向隧道。成功绑定更新后，MR使用备用出口接口通过双向隧道封装传出数据包。
The idea is to use the global address (most likely a CoA) assigned to an alternate egress interface as the new (back-up) CoA of the MR to re-establish the bi-directional tunneling with its HA.
其想法是使用分配给备用出口接口的全局地址（很可能是CoA）作为MR的新（备用）CoA，以重新建立其HA的双向隧道。
When the MR loses a connection to the global Internet, the MR can utilize a route provided by an alternate MR (if one exists) to re-establish the bi-directional tunnel with its HA. First, the MR has to obtain a CoA from the alternate MR (i.e., attach itself to the alternate MR). Next, it sends binding update to its HA using the CoA obtained from the alternate MR. From then on, the MR can encapsulate outgoing packets through the bi-directional tunnel via the alternate MR.
当MR失去与全球互联网的连接时，MR可以利用备用MR（如果存在）提供的路由与其HA重新建立双向隧道。首先，MR必须从候补MR处获得CoA（即，将其自身附加到候补MR上）。接下来，它使用从备用MR获得的CoA向其HA发送绑定更新。从那时起，MR可以通过备用MR通过双向隧道封装传出分组。
The idea is to obtain a CoA from the alternate MR and use this as the new (back-up) CoA of the MR to re-establish the bi-directional tunneling with its HA.
想法是从备用MR获得CoA，并将其用作MR的新（备用）CoA，以重新建立其HA的双向隧道。
Note that every packet sent between MNNs and their correspondent nodes will experience two levels of encapsulation. The first level of tunneling occurs between an MR that the MNN uses as its default router and the MR's HA. The second level of tunneling occurs between the alternate MR and its HA.
请注意，MNN与其对应节点之间发送的每个数据包都将经历两个级别的封装。第一级隧道发生在MNN用作其默认路由器的MR和MR的HA之间。第二级隧道发生在备用MR与其HA之间。
The method of re-establishing the bi-directional tunnel as described in Appendix B.2 may lead to infinite loops of tunneling. This happens when two MRs on a mobile network lose connection to the global Internet at the same time and each MR tries to re-establish bi-directional tunnel using the other MR. We refer to this phenomenon as tunneling loop.
附录B.2中所述的重建双向隧道的方法可能会导致隧道的无限循环。当移动网络上的两个MR同时失去与全球互联网的连接，并且每个MR试图使用另一个MR重新建立双向隧道时，就会发生这种情况。我们将这种现象称为隧道环路。
One approach to avoid tunneling loop is for an MR that has lost connection to the global Internet to insert an option into the Router Advertisement message it broadcasts periodically. This option serves to notify other MRs on the link that the sender no longer provides global connection. Note that setting a zero Router Lifetime field will not work well since it will cause MNNs that are attached to the MR to stop using the MR as their default router too (in which case, things are back to square one).
避免隧道循环的一种方法是，对于失去全球互联网连接的MR，在其定期广播的路由器广告消息中插入一个选项。此选项用于通知链接上的其他MRs发送方不再提供全局连接。请注意，设置零路由器生存期字段将无法正常工作，因为这将导致连接到MR的MNN也停止使用MR作为其默认路由器（在这种情况下，事情又回到了原点）。
This method of using tunnel re-establishments is by no means a complete solution. There are still points to consider in order 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 are 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 an MR whose link has failed knows that its prefix is not to be used, but it does not have 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 an MR to withdraw its own prefix when it discovers that its link is no longer working.
这种利用隧道重建的方法绝不是一个完整的解决方案。为了将其发展成一个全功能的解决方案，仍有一些需要考虑的问题。例如，在附录B.1中，建议MR使用路由器广告检测其他MRs的存在。然而，路由器广告是链接范围的，因此当存在多个链接时，一些信息可能会丢失。例如，假设有三个MR和三个不同的前缀，并且每个MR位于不同的链路中，其间有常规路由器。假设现在只有一个MR在工作；其他MRs如何识别配置新CoA时必须使用的前缀？在这种情况下，有三个前缀被宣布，链接失败的MR知道其前缀不被使用，但它没有足够的信息来决定使用另外两个前缀中的哪一个来配置新的CoA。在这种情况下，需要一种机制，允许MR在发现其链接不再工作时提取其自己的前缀。
Authors' Addresses
作者地址
Chan-Wah Ng Panasonic Singapore Laboratories Pte Ltd Blk 1022 Tai Seng Ave #06-3530 Tai Seng Industrial Estate Singapore 534415 SG
Chan Wah Ng松下新加坡实验室私人有限公司新加坡泰生大道1022号#06-3530新加坡泰生工业区534415 SG
Phone: +65 65505420
EMail: chanwah.ng@sg.panasonic.com
Phone: +65 65505420
EMail: chanwah.ng@sg.panasonic.com
Thierry Ernst INRIA INRIA Rocquencourt Domaine de Voluceau B.P. 105 Le Chesnay 78153 France
蒂埃里·恩斯特（Thierry Ernst INRIA INRIA Rocuncourt Domaine de Voluceau B.P.）
Phone: +33-1-39-63-59-30
Fax: +33-1-39-63-54-91
EMail: thierry.ernst@inria.fr
URI: http://www.nautilus6.org/~thierry
Phone: +33-1-39-63-59-30
Fax: +33-1-39-63-54-91
EMail: thierry.ernst@inria.fr
URI: http://www.nautilus6.org/~thierry
Eun Kyoung Paik KT KT Research Center 17 Woomyeon-dong, Seocho-gu Seoul 137-792 Korea
韩国首尔Seocho gu Woomyeon dong 17号Eun Kyong Paik KT研究中心137-792
Phone: +82-2-526-5233
Fax: +82-2-526-5200
EMail: euna@kt.co.kr
URI: http://mmlab.snu.ac.kr/~eun/
Phone: +82-2-526-5233
Fax: +82-2-526-5200
EMail: euna@kt.co.kr
URI: http://mmlab.snu.ac.kr/~eun/
Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain
马德里卡洛斯三世大学。西班牙马德里勒冈30号大学28911
Phone: +34 91624 8837
EMail: marcelo@it.uc3m.es
Phone: +34 91624 8837
EMail: marcelo@it.uc3m.es
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.