RFC4980 日本語訳
4980 Analysis of Multihoming in Network Mobility Support. C. Ng, T.Ernst, E. Paik, M. Bagnulo. October 2007. (Format: TXT=88572 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループC.ウン要求をネットワークでつないでください: 4980年のパナソニックシンガポール研究室カテゴリ: 情報のT.のE.パクKT M.Bagnulo UC3MエルンストINRIA2007年10月
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でのマルチホーミングの分析です。 モバイルネットワークが「マルチ-家へ帰」るかもしれない多くの状況があって、分類学は、可能な構成を分類するために提案されます。 ネットワークの移動性がRFC3963(ネモBasic Support)によって支持されるとき、「マルチ-家へ帰」っているモバイルネットワークの可能な展開シナリオは関連問題と共に説明されます。 どうこれらの問題を記述するかに関して推薦を提供します。
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. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 分類. . . . . . . . . . . . . . . . . . . . . . . . 4 2.1。 (1,1,1): 単一の状態でMRを選抜してください。ハ、単一のMNP. . . . . . . . 6 2.2。 (1、1、n): MRを選抜してください、そして、ハ、複数のMNP.62.3人を選抜してください。 (1、n、1): 独身のMR、倍数はそうして、シングルはMNP. . . . . . . 7 2.4です。 (1、n、n): 独身のMR、倍数はそうして、倍数はMNP. . . . . 8 2.5です。 (n、1、1): 複数のMRs、ハ、シングルを選抜してください。MNP. . . . . . . 8 2.6。 (n、1、n): 複数のMRs、ハ、複数のMNP.92.7人を選抜してください。 (n、n、1): 複数のMRs、倍数はそうして、シングルはMNP. . . . . 9 2.8です。 (n、n、n): 複数のMRs、倍数はそうして、倍数はMNP. . . . 10です。
Ng, et al. Informational [Page 1] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[1ページ]のRFC4980分析
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. 展開シナリオと前提条件. . . . . . . . . . . . 11 3.1。 展開シナリオ. . . . . . . . . . . . . . . . . . . 11 3.2。 前提条件. . . . . . . . . . . . . . . . . . . . . . 13 4。 マルチホーミング問題. . . . . . . . . . . . . . . . . . . . . . 14 4.1。 耐障害性. . . . . . . . . . . . . . . . . . . . . 14 4.1.1。 失敗検出. . . . . . . . . . . . . . . . . . 15 4.1.2。 経路探検. . . . . . . . . . . . . . . . . . . 16 4.1.3。 経路選択. . . . . . . . . . . . . . . . . . . . 17 4.1.4。 再の家へ帰り.194.2。 イングレスフィルタリング. . . . . . . . . . . . . . . . . . . . 19 4.3。 ハ、同期. . . . . . . . . . . . . . . . . . . . 21 4.4 MR同期. . . . . . . . . . . . . . . . . . . . 22 4.5。 代表団. . . . . . . . . . . . . . . . . . . . 23 4.6を前に置いてください。 複数の結合/登録証明書.234.7。 ソースアドレス選択. . . . . . . . . . . . . . . . . 23 4.8。 入れ子にされたモバイルネットワーク. . . . . . . . 24 4.9で防止を輪にしてください。 所有権. . . . . . . . . . . . . . . . . . . . . 24 4.10を前に置いてください。 好みの設定. . . . . . . . . . . . . . . . . . . 25 5。 作業部会. . . . . . . . . . . . . 26 6への推薦。 結論. . . . . . . . . . . . . . . . . . . . . . . . . . 28 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 28 8。 承認. . . . . . . . . . . . . . . . . . . . . . . 29 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.1。 引用規格. . . . . . . . . . . . . . . . . . . 29 9.2。 有益な参照. . . . . . . . . . . . . . . . . . 29付録A.代替手段分類は.32A.1にアプローチします。 所有権指向のアプローチ. . . . . . . . . . . . . . . 32A.1.1。 ISPモデル.32A.1.2。 加入者/プロバイダーモデル.33A.2。 問題指向のアプローチ. . . . . . . . . . . . . . . . 34付録B.は耐障害性. . . . . . . . 35B.1のためにトンネリングを入れ子にしました。 代替経路. . . . . . . . . . 35B.2の存在を検出します。 双方向のTunnels.36B.2.1の再建。 交互の出口のインタフェース. . . . . . . . . . . 36B.2.2を使用します。 交互のモバイルルータ. . . . . . . . . . . . 36B.3を使用します。 輪. . . . . . . . . . . . . . . . . 37のB.4にトンネルを堀るのを避けるために。 ポイントの問題. . . . . . . . . . . . . . . . . 37
Ng, et al. Informational [Page 2] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[2ページ]のRFC4980分析
1. Introduction
1. 序論
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でのNetwork Mobility(ネモ)サポートのデザイン目標と目的は[1]で特定されます、用語が[2]と[3]で説明されますが。 ネモBasic Support(RFC3963)[4]は連続したインターネットの接続性を提供するネモ作業部会によって提案されたコネの乗り物の埋め込まれたIPネットワークにおいてIPv6モバイルネットワークで位置していて、例えば、同様のノードの解答です。 ネモBasic Support解決策はインターネットと彼らのそれぞれの家のエージェント(HAs)にモバイルネットワーク(ネモ)を接続しながら可動のルータ(MRs)の間の双方向のトンネルを設立することによって、そうします、モバイルIPv6[5]でどうこれをするように、ホスト移動性サポートの解決策。 ネモBasic SupportはMR(すなわち、モバイルネットワークノード、またはMNNs)の後ろ、そして、そういうものとして見つけられたノードに透明です、と移動性管理におけるどんな行動も取るMNNsは必要としません。
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の後ろに多くのノードがあるかもしれません。インターネットに接続しない場合、その結果、ただ一つの可動のノードより重要な影響を与えます。 [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 WGは、ネモBasic Support Requirements[1](R.12)のセクション5で指定されるようにネモBasic Supportが「マルチ-家へ帰」るためにモバイルネットワークを防がないのを確実にしなければなりません、すなわち、モバイルネットワークとインターネットの間に1接着点以上があるとき。([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 またはモバイルネットワークが複数のHAsに関連している。
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
これはMR(s)と対応するHA(s)の間の複数の双方向のトンネルを持っているのに翻訳して、利用可能な複数のモバイルNetwork Prefixes(MNP)をもたらして、ネモBasic Supportを使用するかもしれません。
Ng, et al. Informational [Page 3] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[3ページ]のRFC4980分析
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:
MNNsに。 しかしながら、ネモBasic Supportは、複数の双方向のトンネルを管理するためにどんな特定のメカニズムも指定しません。 その結果、このメモの目的は多重です:
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 すべての潜在的「マルチ-家へ帰」っている構成が、ネモ、そして、これらのどれが本当の人生シナリオで役に立つかもしれないかを特定することを決定するために。
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 いくつかを防ぐかもしれない問題を得るのは、ネモBasic Supportの操作で支持されるために構成を「マルチ-家へ帰」らせました。 それは、必ず支持されなかったのがネモBasic Supportと共に働かないことを意味するというわけではありません、働かせるのが、作成者次第(願わくは、このメモはこれらの作成者にとって有用になる)であるときに。
o to decide which issues are worth solving and to determine which WG
is the most appropriate to address these;
o どの問題は解決する価値があるかを決めて、WGがどれであるかを決定するために、大部分はこれらをアドレスに当てます。
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でするところで推薦状をします。 このメモは「マルチ-家へ帰」っている構成のためにネモBasic Supportの評価で締めくくります。 代替の分類はAppendixに概説されています。
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環境の観点からマルチホーミングを考えることに注意するべきです。 このメモを理解するために、読者が上記の引用されたドキュメントによく知られさせると予想されます、すなわち、Network Mobility Support[1]のMultihoming[6]、Goals、およびRequirementsのために[2](セクション3)、[3]、Motivations、およびScenariosで定義されるネモ用語、およびネモBasic Support仕様[4]で。 [6]の議論するとしてのマルチホーミングの目標と利益は固定ノード、ネットワークに固定された可動のノード、およびモバイルネットワークに適用されます。
2. Classification
2. 分類
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
モバイルネットワークが「マルチ-家へ帰」るいくつかの構成があるとき、それらを明確に定義された分類学に分類する必要があります。 いろいろこれができます。 Configurationの指向の分類学はこのセクションで説明されます。 2もう一方
Ng, et al. Informational [Page 4] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[4ページ]のRFC4980分析
taxonomies, namely, the Ownership-Oriented Approach and the Problem- Oriented Approach, are outlined in Appendix A.1 and Appendix A.2.
分類学(すなわち、Ownershipが指向のApproachとProblemの指向のApproach)は、Appendix A.1とAppendix 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がプレゼント、いくつの出口のインタフェースであるかによって、Multihomed構成を分類できる、Care、-、Address(CoA)、およびMRsが持っているホームAddresses(HoA)、いくつの接頭語(MNP)がモバイルネットワークノードに利用可能であるかなど。 私たちは、「マルチ-家へ帰」っている構成を微分するのに3つの主要なパラメタを使用します。 これらのパラメタを使用して、各構成は3-tuple(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は、モバイルネットワークには1MRがあるのを含意します。
o 'y' indicates the number of HAs associated with the entire mobile
network, where:
o 'y'は全体のモバイルネットワーク、どこに関連しているHAsの数を示すか:
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'はネモの中で利用可能なMNP、どこに関する数を示すか:
z=1 implies that a single MNP is available in the NEMO.
z=1は、単一のMNPがネモで利用可能であることを含意します。
z=N implies that multiple MNPs are available in the NEMO.
z=Nは、複数の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).
上記の3つのパラメタがお互いと共にかなり直交しているのを見ることができます。 したがって、'x'、'y'、および'z'の異価は3-tuple(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つの可能な構成を特定できます。 読者が覚えておかなければならない1つのことは(i) 複数の接頭語が利用可能であるか(家のリンクの上、または、外国リンクの上の)、または(ii)MRは複数のインタフェースを備えているならそれぞれの以下の8つの場合では、MRが「マルチ-家へ帰」るかもしれないということです。 このような場合には、MRには、複数の(HoA、CoA)組があるでしょう。 また、multihomed MRに関係する問題が[7]に記述されます。 また、さらに、読者は、「MNPによる/がネモで利用可能であるということです」のときに、MNPをMRがルータ通知で明らかに発表するか、またはDynamic Host Configuration Protocol(DHCP)[8]を通して利用可能にするかもしれないのを覚えておくべきです。
Ng, et al. Informational [Page 5] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[5ページ]のRFC4980分析
2.1. (1,1,1): Single MR, Single HA, Single MNP
2.1. (1,1,1): MRを選抜してくださいといって、ハ、シングルを選抜してください、MNP
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)構成には1MRしかありません、そして、それは独身のHAに関連しています、そして、単一のMNPはネモで利用可能です。 MRとARは独身のAccess Router(AR)を通してインターネットに接続されます。 「マルチ-家へ帰」っている構成になるように、少なくとも以下の条件の1つは持ちこたえなければなりません:
o The MR has multiple interfaces and thus it has multiple CoAs;
o MRには、複数のインタフェースがあります、そして、その結果、複数のCoAsを持っています。
o Multiple global prefixes are available on the foreign link, and
thus it has multiple CoAs; or
o 複数のグローバルな接頭語が外国リンクで利用可能です、そして、その結果、複数のCoAsを持っています。 または
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に達するように、1つ以上の経路があります。
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が取り付けられるリンクで利用可能な接頭語から独立している、その結果、外国リンクで利用可能な接頭語はネモリンクの上に発表されません。 複数の接頭語が家のリンクで利用可能であるケースにおいて、MRがそうするために構成される場合にだけ、これらはネモリンクの上に発表されます。 現在(1、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.
彼らが付けられているリンクで利用可能な単一のMNPからただ一つのグローバルアドレスを構成するでしょう、したがって、MNNsに関して、(通常、)彼らは「マルチ-家へ帰」りません。
_____
_ p _ | |
|_|-|<-_ |-|_|-| |-| _
_ |-|_|=| |_____| | _ |-|_|
|_|-| | |-|_|-|
|
MNNs MR AR Internet AR HA
_____ _ p_| | |_|、-、| <、-_ |-|_|-| |-| _ _ |-|_|=| |_____| | _ |-|_| |_|-| | |-|_|-| | MNNs MR ARインターネットAR、ハ。
Figure 1: (1,1,1): 1 MR, 1 HA, 1 MNP
図1: (1,1,1): 1人のさん、1、ハ、1つのMNP
2.2. (1,1,n): Single MR, Single HA, Multiple MNPs
2.2. (1、1、n): MRを選抜してくださいといって、ハ、倍数を選抜してください、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)構成には1MRしかありません、そして、それは独身のHAに関連しています、そして、2つ以上のMNPがネモで利用可能です。
Ng, et al. Informational [Page 6] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[6ページ]のRFC4980分析
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.
MNNsに関して、いくつかのMNPがそれらが付けられているリンクで利用可能であるので、彼らは「マルチ-家へ帰」ります。 そして、MNNsはリンクで利用可能なそれぞれのMNPからグローバルアドレスを構成するでしょう。
_____
_ p1,p2 _ | |
|_|-|<-_ |-|_|-| |-| _
_ |-|_|=| |_____| | _ |-|_|
|_|-| | |-|_|-|
|
MNNs MR AR Internet AR HA
_____ _ p1、p2_| | |_|、-、| <、-_ |-|_|-| |-| _ _ |-|_|=| |_____| | _ |-|_| |_|-| | |-|_|-| | MNNs MR ARインターネットAR、ハ。
Figure 2: (1,1,n): 1 MR, 1 HA, multiple MNPs
図2: (1、1、n): 1 MR、1HA、複数のMNP
2.3. (1,n,1): Single MR, Multiple HAs, Single MNP
2.3. (1、n、1): 独身のMR、倍数はそうして、シングルは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)構成には1MRしかありません、そして、単一のMNPはネモで利用可能です。 しかしながら、MRは複数のHAsに関連しています。
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.
複数の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.
彼らが付けられているリンクで利用可能な単一のMNPからただ一つのグローバルアドレスを構成するでしょう、したがって、MNNsに関して、(通常、)彼らは「マルチ-家へ帰」りません。
AR HA2
_ |
|-|_|-| _
_____ | |-|_|
_ p _ | |-|
|_|-|<-_ |-|_|-| |
_ |-|_|=| |_____|-| _
|_|-| | | _ |-|_|
|-|_|-|
|
MNNs MR AR Internet AR HA1
アルゴンHA2_| |-|_|-| _ _____ | |-|_| _ p_| |-| |_|、-、| <、-_ |-|_|-| | _ |-|_|=| |_____|-| _ |_|-| | | _ |-|_| |-|_|-| | MNNs MR ARインターネットAR HA1
Figure 3: (1,n,1): 1 MR, multiple HAs, 1 MNP
図3: (1、n、1): 1 MR、複数のHAs、1つのMNP
Ng, et al. Informational [Page 7] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[7ページ]のRFC4980分析
2.4. (1,n,n): Single MR, Multiple HAs, Multiple MNPs
2.4. (1、n、n): 独身のMR、倍数はそうして、倍数は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)構成には1MRしかありません。しかしながら、MRは複数のHAsに関連しています、そして、1つ以上の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.
複数のHAsを持っているので、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 with each MNP available on the link.
MNNsに関して、いくつかのMNPがそれらが付けられているリンクで利用可能であるので、彼らは「マルチ-家へ帰」ります。 そして、それぞれのMNPが利用可能な状態でMNNsはリンクの上にグローバルアドレスを構成するでしょう。
AR HA2
_ | _
_____ |-|_|-|-|_|
_ p1,p2 _ | |-| |
|_|-|<-_ |-|_|-| | _
_ |-|_|=| |_____|-| _ |-|_|
|_|-| | |-|_|-|
| |
MNNs MR AR Internet AR HA1
アルゴンHA2_| _ _____ |-|_|-|-|_| _ p1、p2_| |-| | |_|、-、| <、-_ |-|_|-| | _ _ |-|_|=| |_____|-| _ |-|_| |_|-| | |-|_|-| | | MNNs MR ARインターネットAR HA1
Figure 4: (1,n,n): 1 MR, multiple HAs, multiple MNPs
図4: (1、n、n): 1 MR、複数のHAs、複数のMNP
2.5. (n,1,1): Multiple MRs, Single HA, Single MNP
2.5. (n、1、1): 複数のMRs、ハ、シングルを選抜してください、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)構成で、1MRがグローバルなルートの広告を出します。 しかしながら、MR(s)は独身のHAに関連しています、そして、ネモで利用可能な単一の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.
複数の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.
彼らが付けられているリンクで利用可能な単一のMNPからただ一つのグローバルアドレスを構成するでしょう、したがって、MNNsに関して、(通常、)彼らは「マルチ-家へ帰」りません。
Ng, et al. Informational [Page 8] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[8ページ]のRFC4980分析
MR2
p<-_ |
_ |-|_|-| _____
|_|-| |-| |
_ | | |-| _
|_|-| _ |-|_____| | _ |-|_|
|-|_|-| |-|_|-|
p<- | |
MNNs MR1 Internet AR HA
MR2 p<-_| _ |-|_|-| _____ |_|-| |-| | _ | | |-| _ |_|-| _ |-|_____| | _ |-|_| |-|_|-| |-|_|-| p<、-| | MNNs MR1インターネットAR、ハ。
Figure 5: (n,1,1): Multiple MRs, 1 HA, 1 MNP
図5: (n、1、1): 複数のMRs、1、ハ、1つのMNP
2.6. (n,1,n): Multiple MRs, Single HA, Multiple MNPs
2.6. (n、1、n): 複数のMRs、ハ、倍数を選抜してください、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)構成には、1MRがあります。 複数のグローバルなルートがMRsによって広告を出されます、そして、複数の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.
複数の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.
MNNsに関して、いくつかのMNPがそれらが付けられているリンクで利用可能であるので、彼らは「マルチ-家へ帰」ります。 そして、それぞれのMNPが利用可能な状態でMNNsはリンクの上にグローバルアドレスを構成するでしょう。
MR2
p2<-_ |
_ |-|_|-| _____
|_|-| |-| |
_ | | |-| _
|_|-| _ |-|_____| | _ |-|_|
|-|_|-| |-|_|-|
p1<- | |
MNNs MR1 Internet AR HA
MR2 p2<-_| _ |-|_|-| _____ |_|-| |-| | _ | | |-| _ |_|-| _ |-|_____| | _ |-|_| |-|_|-| |-|_|-| p1<、-| | MNNs MR1インターネットAR、ハ。
Figure 6: (n,1,n): Multiple MRs, 1 HA, multiple MNPs
図6: (n、1、n): 複数のMRs、1HA、複数のMNP
2.7. (n,n,1): Multiple MRs, Multiple HAs, Single MNP
2.7. (n、n、1): 複数のMRs、倍数はそうして、シングルは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)構成で、1MRが複数のグローバルなルートの広告を出します。 モバイルネットワークは同時に複数のHAsに関連しています、そして、単一のMNPはネモで利用可能です。
Ng, et al. Informational [Page 9] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[9ページ]のRFC4980分析
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.
複数の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.
彼らが付けられているリンクで利用可能な単一のMNPからただ一つのグローバルアドレスを構成するでしょう、したがって、MNNsに関して、(通常、)彼らは「マルチ-家へ帰」りません。
MR2 AR HA2
p _ |
<-_ | |-|_|-| _
_ |-|_|-| _____ | |-|_|
|_|-| |-| |-|
_ | | |
|_|-| _ |-|_____|-| _
|-|_|-| | _ |-|_|
<- | |-|_|-|
p |
MNNs MR1 Internet AR HA1
MR2 AR HA2p_| <。_ | |-|_|-| _ _ |-|_|-| _____ | |-|_| |_|-| |-| |-| _ | | | |_|-| _ |-|_____|-| _ |-|_|-| | _ |-|_| <| |-|_|-| p| MNNs MR1インターネットAR HA1
Figure 7: (n,n,1): Multiple MRs, Multiple HAs, 1 MNP
図7: (n、n、1): 複数のMRs、倍数がそうした、1つのMNP
2.8. (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs
2.8. (n、n、n): 複数のMRs、倍数はそうして、倍数は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が異なったグローバルなルートの広告を出します。 モバイルネットワークは同時に1HAに関連しています、そして、複数の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.
複数の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.
MNNsに関して、いくつかのMNPがそれらが付けられているリンクで利用可能であるので、彼らは「マルチ-家へ帰」ります。 そして、それぞれのMNPが利用可能な状態でMNNsはリンクの上にグローバルアドレスを構成するでしょう。
Ng, et al. Informational [Page 10] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[10ページ]のRFC4980分析
MR2 AR HA2
p2 _ |
<-_ | |-|_|-| _
_ |-|_|-| _____ | |-|_|
|_|-| |-| |-|
_ | | |
|_|-| _ |-|_____|-| _
|-|_|-| | _ |-|_|
<- | |-|_|-|
p1 |
MNNs MR1 Internet AR HA1
MR2 AR HA2 p2_| <。_ | |-|_|-| _ _ |-|_|-| _____ | |-|_| |_|-| |-| |-| _ | | | |_|-| _ |-|_____|-| _ |-|_|-| | _ |-|_| <| |-|_|-| p1| MNNs MR1インターネットAR HA1
Figure 8: (n,n,n): Multiple MRs, HAs, and MNPs
エイト環: (n、n、n): 複数のMRs、MNP
3. Deployment Scenarios and Prerequisites
3. 展開シナリオと前提条件
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.
これらの利益は現在、分類学における各ケースのために典型的な例のシナリオでネモ見解から例証されます。 そして、私たちは、これらを実現させるために前提条件について議論します。
3.1. Deployment Scenarios
3.1. 展開シナリオ
x=1: Multihomed mobile networks with a single MR
x=1: 独身のMRと共にモバイルネットワークをMultihomedしました。
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能力)を連結します。 独身のHAが両方に使用されるなら、これはa(1、1、*)です。 2独立しているHAsが使用されているなら、これは(1、n、n)構成です。
Benefits: Ubiquitous Access, Reliability, Load Sharing,
Preference Settings, Aggregate Bandwidth.
利益: 遍在しているアクセス、信頼性、負荷分割法、好みの設定は帯域幅に集められます。
Ng, et al. Informational [Page 11] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[11ページ]のRFC4980分析
x=n: Multihomed mobile networks with multiple MRs
x=n: 複数のMRsと共にモバイルネットワークをMultihomedしました。
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.
1MRと共にその結果、各車、同じHAによって役立たれたすべて、(n、1、*)構成で訓練してください。 あるいはまた、列車会社はその結果、異なった国、(n、n、n)構成に異なったHAsを使用するかもしれません。
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がある無線の個人的な領域ネットワーク。 また、異なったHAsが使用されるなら、これは(n、n、n)構成です。
Benefits: Ubiquitous Access, Reliability, Preference Settings,
Aggregate Bandwidth.
利益: 遍在しているアクセス、信頼性、好みの設定は帯域幅に集められます。
y=1: Multihomed mobile networks with a single HA
y=1: 独身のHAと共にモバイルネットワークをMultihomedしました。
o Example:
o 例:
Most single HA cases in above examples.
上記の例におけるほとんどのただ一つのHAケース。
y=n: Multihomed mobile networks with multiple HAs
y=n: 複数のHAsと共にモバイルネットワークをMultihomedしました。
o Example 1:
o 例1:
Most multiple HAs cases in above examples.
上記の例におけるほとんどの複数のHAsケース。
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がある大西洋横断の飛行。 1MRしかなければ、これは(1、n、1)構成です。
Benefits: Ubiquitous Access, Reliability, Preference Settings
(reduced delay, shortest path).
利益: 遍在しているAccess、Reliability、Preference設定(遅れ、最短パスを減少させます)。
z=1: Multihomed mobile networks with a single MNP
z=1: 単一のMNPでモバイルネットワークをMultihomedしました。
o Example:
o 例:
Most single HA cases in above examples.
上記の例におけるほとんどのただ一つのHAケース。
Ng, et al. Informational [Page 12] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[12ページ]のRFC4980分析
z=n: Multihomed mobile networks with multiple MNPs
z=n: 複数のMNPでモバイルネットワークをMultihomedしました。
o Example 1:
o 例1:
Most multiple HAs cases in above examples.
上記の例におけるほとんどの複数のHAsケース。
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.
家から接頭語を取っている車(個人的な交通は、この接頭語を使用することで伝えられて、所有者によって支払われる)と自動車製造業者のものであるもの(維持交通は自動車製造業者によって支払われます)。 これは、通常a(1、1、n)か(1、n、n)構成になるでしょう。
Benefits: Preference Settings
利益: 好みの設定
3.2. Prerequisites
3.2. 前提条件
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:
少なくとも1つの双方向のトンネルが、時間内に、すべての期待に合うようにモバイルネットワークと固定ネットワークの間で任意な点で利用可能でなければなりません。 しかし、ほとんどの目標が有効であるように、同時に、複数のトンネルを維持しなければなりません:
o Permanent and Ubiquitous Access:
o 永久的で遍在しているアクセス:
At least one bi-directional tunnel must be available at any point
in time.
少なくとも1つの双方向のトンネルが時間内に、任意な点で利用可能であるに違いありません。
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.
同時に、複数のトンネルを維持しなければなりません。
Ng, et al. Informational [Page 13] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[13ページ]のRFC4980分析
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.
同時に、モバイルネットワークに利用可能な総集められた帯域幅を増加させるように複数のトンネルを維持しなければなりません。
4. Multihoming Issues
4. マルチホーミング問題
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.
それで、構成に考慮でよって、以下で議論した問題は、時々ダイナミックに記述される必要があるかもしれません。 各問題において、問題を解決する潜在的方法は調査されます。
4.1. Fault Tolerance
4.1. 耐障害性
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).
マルチホーミングの目標の1つは耐障害性能力の支給です。 そのような特徴を提供するために、以下を含んで、1セットのタスクは、実行される必要があります。 確立したコミュニケーションの失敗検出、代替の利用可能な経路探検、経路選択、および再の家へ帰り。 また、これらは[9]でShim6 WGによって議論されています。 以下の小区分では、私たちは[9]の一般的なShim6見解よりむしろネモの特定の文脈のこれらの問題を見ます。 また、さらに、いくつかのシナリオでは、それが、異なったMRsの間で異なったHAs(セクション4.3を見る)とコーディネートの間でもメカニズムをコーディネートに提供するのに必要であるかもしれません(セクション4.4を見てください)。
Ng, et al. Informational [Page 14] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[14ページ]のRFC4980分析
4.1.1. Failure Detection
4.1.1. 失敗検出
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.
考えられたネモ構成によって、失敗保護ドメインは大いに異なります。 いくつかの構成では、ネモマルチホーミングで提供された保護ドメインはMR(s)とHA(s)とのリンクに制限されます。 したがって、他の構成では、保護ドメインで、終わりから終わりへの失敗検出メカニズムが経路の他の地域で障害を修復するのが必要です。
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を通して流れます。 失敗検出メカニズムは、これらの2台の装置の間で単に実行される必要があります。 これは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があるので、ネモとネモからのすべての交通がそれを通して流れるでしょう。 失敗検出メカニズムは、中古のMRと唯一のHAの間の経路に失敗を検出できる必要があります。 したがって、失敗検出メカニズムは、単にHAとMRsにかかわる必要があります。 これはネモ/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、*)ケースのために、異なったHAsと異なったMRsの間には、複数の経路があります。 そのうえ、HAsは異なったネットワークで位置していて、異なったインターネット・アクセスリンクを持っているかもしれません。 これは、HAとMRの間にリンクで障害を修復するのを許容するだけではなく、HAが使用した変化が他の故障モードから許容もするかもしれないのを含意します、経路の他の地域に影響して。 この場合、終わりから終わりへの失敗検出メカニズムは追加保護を提供するでしょう。 しかしながら、より大きい数の失敗が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(s)の間の失敗検出に関するケースと異なっていません。 そういうものとしてa
Ng, et al. Informational [Page 15] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[15ページ]のRFC4980分析
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の解決策はまた、ネモに適用されるべきです。 ケース(n、*、*)において、MR同期対策(セクション4.4を見る)は、ネモのために必要な機能性を達成するためにMIPv6失敗検出対策の補足となることができるべきです。
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がアクセスルータからのルータ通知か、欠点、例えば、[10]を検出する他の層-2台のトリガー機構と[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 HAの側では、トンネルの故障を検出するのが、より難しいです。 ISP展開モデルのために、HAsとMRsは失敗を検出して、トンネル活性をチェックする独占方法(ハートビート信号の一定の伝達などの)を使用できます。 加入者モデル(Appendix 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が、より短いLifetime値と共に拘束力があるアップデートより定期的に発信することです。 同様に、HAsは、より小さいLifetime値がある拘束力がある承認メッセージを返すことができます、その結果、MRsを拘束力があるアップデートより頻繁に発信させます。 「トンネル鼓動」を見習うのにこれらの拘束力があるアップデートを使用できます。 しかしながら、これは、より多くの交通と処理オーバヘッドに通じるかもしれません、セキュリティ関係と共にHAsに送られた拘束力があるアップデートを保護しなければならないので(そして、ことによるとコード化されます)。
4.1.2. Path Exploration
4.1.2. 経路探検
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エラーメッセージとしての)などのように。
Ng, et al. Informational [Page 16] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[16ページ]のRFC4980分析
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の間で利用可能です。 HAとMRの間の既存の経路は、利用可能なものを特定するために探検されなければなりません。 メカニズムはHAとMRだけにかかわります。これは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があるので、ネモとネモからのすべての交通がそれを通して流れるでしょう。 利用可能な迂回経路は異なったMRsとHAの間の異なったものです。 経路探検メカニズムはHAとMRsにかかわるだけです。 これはネモ/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、*)ケースのために、異なったHAsと異なったMRsの間には、複数の経路があります。 この場合、迂回経路はお互いから完全に独立していた状態で発送されるかもしれません。 終わりから終わりへの経路探検メカニズムは、終わりから端への経路のどれかが利用可能であるかどうか発見できるでしょう。 しかしながら、(n、n、1)ケースは複数の接頭語の欠如のために特定のきれいなネモであるように思えます。 (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(s)の間の経路探検に関するケースと異なっていません。 そういうものとして、MIPv6の解決策はまた、ネモに適用されるべきです。 ケース(n、*、*)において、MR同期対策(セクション4.4を見る)は、ネモのために必要な機能性を達成するためにMIPv6経路探検対策の補足となることができるべきです。
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]、またはDetecting Network Attachment(DNA)作業部会[11]によって開発されたか、または推薦された他のメカニズムを使用することで達成されるかもしれません。 これはセクション4.1.1に関係づけられます、メディアの有用性を検出する能力がしばしばメディア使用不能を検出する能力を含意するでしょう、したがって。
4.1.3. Path Selection
4.1.3. 経路選択
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
経路選択メカニズムが、利用可能な倍数の中で経路を選択するのに必要です。 かかわったネモマルチホーミング構成によって、経路の違いはHAとMRの間の部分だけに影響するかもしれませんか、またはそれらは完全な終わりから終わりに影響するかもしれません。
Ng, et al. Informational [Page 17] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[17ページ]のRFC4980分析
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(s)、MR(s)、またはホストによってアドレス選択で自分たちで実行されるかもしれません、次に詳細に説明されるように。
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の間のトンネルについて異なる意見をもつかもしれません。 この場合、経路選択はMRとネモから流れる交通のイントラネモルーティングシステムによって実行されます、そして、経路選択はネモに注ぐ交通のHAとイントラホームNetworkルーティングシステムによって実行されます。
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の間のトンネル以上において異なるかもしれません、異なった接頭語の用法が異なったプロバイダーを使用するのに結果として生じるかもしれないので。 したがって、かかわった終点の間の完全に異なった経路で。 この場合、先の事件で提示されたメカニズム以外に、終わりから終わりへの経路選択のための追加メカニズムが必要であるかもしれません。 このメカニズムはホストの中で密接にソースアドレス選択メカニズムに関連するかもしれません、と以来与えられたアドレスを選択するのが与えられた接頭語(ホームネットワークの1つに役立つ与えられた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 ハ: それは拘束力があるキャッシュに記録された何らかの情報に基づく経路を選択できるべきです。
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、*、*)ケースか(*、*、n)場合における「ソースアドレス選択」に基づいて[12])を見てください[セクション6.3.6Default Router Selection](現在のメモのセクション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、そして/または、MNNsが経路を選択するために調整されるもの。
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
複数の双方向のトンネルが同時に利用可能であって、ことによると使用されているとき、運転モードが第一に二次であるかもしれない、(1つのトンネルがデフォルトとして他のもので中古な上の先例です。
Ng, et al. Informational [Page 18] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[18ページ]のRFC4980分析
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)の間の異なったトンネルの中の選択のためのメカニズムはネモ/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(s)の間の経路選択に関するケースと異なっていません。 そういうものとして、MIPv6の解決策はまた、ネモに適用されるべきです。 (n、*、*)ケースにおいて、MR同期対策(セクション4.4を見る)は、ネモのために必要な機能性を達成するためにMIPv6経路選択対策の補足となることができるべきです。
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])。
4.1.4. Re-Homing
4.1.4. 再の家へ帰り
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.
供給停止が検出されて、利用可能な迂回経路が特定された後に、再の家へ帰り出来事は起こります、1つの経路からもう片方に既存のコミュニケーションを紛らして。 この過程にかかわる前の項目と同様であることで、ネモマルチホーミング構成によって、再の家へ帰り手順はずっしりと異なります。
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(s)とHA(s)だけを伴います。 再の家へ帰り手順は追加BUメッセージの交換を伴うかもしれません。 これらのメカニズムはネモBasic Supportと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])。
4.2. Ingress Filtering
4.2. イングレスフィルタリング
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
複数の双方向のトンネルが異なったHAsで終わると、メカニズム[14][15]をフィルターにかけるイングレスは出発しているパケットを落とすかもしれません。 異なったMNPが異なったHAsによって扱われるなら、これは特に起こるかもしれません。 aがあるパケットであるなら、詳細から構成されたアドレスの出典を明示してください。
Ng, et al. Informational [Page 19] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[19ページ]のRFC4980分析
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:
イングレスフィルタリング互換性問題はずっしりと特定のネモマルチホーミング構成に依存しています:
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を受け入れるa独身のHAはそうです。
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に起こらないでしょうが、MRsに起こるかもしれません、各MRが異なったMNPを扱っているとき。
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)場合では、ネモとネモからのすべての交通が独身のMRを通して発送されるので、問題は簡易型です。そのような構成は、イングレスフィルタリングによって課された規制を尊敬しながら適切にパケットを発送するためにMRを許容します。 この場合、独身のMRは「マルチ-家へ帰」っている可動のノードが直面するかもしれない問題をフィルターにかけるイングレスに直面するかもしれません、[7]に記録されるように。 より複雑なケースは(n、n、n)ケースです。 すべての接頭語がすべてのHAsによって受け入れられるとき、簡易型のケースは現れます、問題が全くイングレスフィルタリングで起こらないように。 しかしながら、以下で説明された問題をもたらして、いつもこれを想定できるというわけではありません。
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で例証された展開シナリオを考えてください: モバイルネットワークには、それぞれ家のエージェントのHA1とHA2と2の可動のルータMR1とMR2があります。 2つの双方向のトンネルが2組の間で確立されます。 各MRが異なったMNPの広告を出す、(P1とP2、それぞれ) MNP P1はHA1に登録されます、そして、MNP P2はHA2に登録されます。 したがって、MNNsは自由にP1かP2のどれかに関する彼らのアドレスを自動構成するはずであることができます。 その結果、イングレスフィルタリングは2つの場合で起こることができました:
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 2つのトンネルが利用可能であるなら、MNNはソースアドレス同輩P1.MNNがあるパケットをMR2に送ることができません。 これで、HA2のイングレスフィルタリングは起こるでしょう(またはMR2でさえ)。 これはそれが使用するのを選ぶ接頭語にかかわらずIPv6ノードがデフォルトルータとして無料でどんなルータも選ぶことができる正常なNeighborディスカバリー[12]習慣に合いません。
Ng, et al. Informational [Page 20] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[20ページ]のRFC4980分析
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 +-----+ +----+ +----------+ +-----+
以下を前に置いてください。 P1+-----+ +----+ +----------+ +-----+ +--| MR1|--| アルゴン|--| |---| HA1| | +-----+ +----+ | | +-----+ IP: +-----+ | | | 以下を前に置いてください。 またはP1 P1.MNN。| MNN|--+ | インターネット| P2.MNN+-----+ | | | 以下を前に置いてください。 P2| +-----+ +----+ | | +-----+ +--| MR2|--| アルゴン|--| |---| HA2| 以下を前に置いてください。 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はそのようなアプローチの1つについて説明します。
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]).
いくつかのネモマルチホーミング構成に現れる両立し難いこと問題をフィルターにかけるイングレスはShim6で考えられたものと同様です。(例えば、[16])を見てください。
4.3. HA Synchronization
4.3. ハ、同期
In the (*,n,*) configuration, a single MNP would be registered at different HAs. This gives rise to the following cases:
(*、n、*)構成では、単一のMNPは異なったHAsに登録されるでしょう。 これは以下のケースをもたらします:
o Only one HA may actively advertise a route to the MNP,
o 1HAだけが活発にMNPにルートの広告を出すかもしれません。
o Multiple HAs at different domains may advertise a route to the
same MNP.
o 異なったドメインの複数のHAsが同じMNPにルートの広告を出すかもしれません。
Ng, et al. Informational [Page 21] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[21ページ]のRFC4980分析
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.
HAsが異なった管理ドメインに位置しているなら、これは全体でルーティングインフラストラクチャで問題を設定するかもしれません。 この局面の含意はさらなる探検を必要とします。 あるレベルのHAコーディネートが必要であるかもしれません。 可能なアプローチは[17]と[18]で説明されたそれなどのHA同期メカニズムを採用することです。 また、そのような同期も(*、n、*)構成で必要であるかもしれません、MRが1HA(すべてのHAsの代わりに)だけに拘束力があるアップデートメッセージを送るとき。 そのような場合、拘束力があるアップデート情報はHAsの間で同期しなければならないかもしれません。 同期の方法は、第一の2番目かピアツーピアのどちらかであるかもしれません。 また、さらに、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が対処されなければならない一般的な移動性問題です。(ネモBasic Supportと同様に[7])でセクション6.2.3を見てください。
4.4. MR Synchronization
4.4. MR同期
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)構成(また、セクション4.5で「接頭語代表団」を見る)で同じMNPの広告を出します。
o one MR relaying the advertisement of the MNP from another failed
MR in the (n,*,n) configuration; and
o 別のものからMNPの広告をリレーする1MRが(n、*、n)構成でMRに失敗しました。 そして
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 MRsの間ですべてをリレーして、それは、リレーされる必要があります、データ・パケットなどのように、イングレスインタフェースなどからトンネルを作成して、(n、*、*)構成で。
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.
そのような同期メカニズムは、第一の2番目(すなわち、バックアップとしての他のMRsのマスターMR)かピアツーピアであるかもしれません(すなわち、MRsの間には、どんな明確な管理階層構造もありません)。 そのようなメカニズムの必要性は固定ネットワークにおけるマルチルータサイトが同じレベルのルータ同期を必要とするだろうという意味で一般的です。
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.
したがって、この問題はネモBasic Supportに特定ではありません、リンクの、より高い可能性によるネモ構成における耐障害性と失敗回復が失敗であると立証することのMRからMRへの同期計画を開発するより緊急の必要がありますが。
Ng, et al. Informational [Page 22] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[22ページ]のRFC4980分析
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.
結論として、解決策は最初に、ネモ展開のために見いだされなければならないでしょうが、この問題の一般的な解決を調査するのはお勧めです。
4.5. Prefix Delegation
4.5. 接頭語代表団
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)構成では、異なった経路を通して同じMNPのMNNsに広告を出さなければなりません。 しかしながら、これを達成するために利用可能などんな同期メカニズムもありません。 同期メカニズムがなければ、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)
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)ケースに関しては、同じMNPの広告を出すために連動して、MRsがどれくらい缶の複数かがネモ-リンクより倒しますか? そうするのにおいて、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.
すべてのルータが同じMNPの広告を出すのを保証するのに接頭語代表団メカニズム[20][21][22]を使用できました。 「マルチ-家へ帰」っているモバイルネットワークへの彼らの適用性は考えられるべきです。
4.6. Multiple Bindings/Registrations
4.6. 複数の結合/登録証明書
When an MR is configured with multiple CoAs, it is often necessary for it to bind these CoAs to the same MNP.
MRが複数のCoAsによって構成されるとき、同じMNPにこれらのCoAsを縛るのがしばしば必要です。
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とネモBasic Supportの両方のためにこれを解決できることに注意するのは十分です。 この問題はMonami6 WGで対処されています。
4.7. Source Address Selection
4.7. ソースアドレス選択
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)構成では、MNNsは複数のアドレスによって構成されるでしょう。 ソースアドレス選択メカニズムが、どのアドレスから選ぶかを決めるのが必要です。
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
しかしながら、現在の利用可能なソースアドレス選択メカニズムで、MNNsは、知的に彼らのソースアドレスを選択するために十分な情報を取得できません(それぞれのMNPのホームネットワークに関連している交通状態に基づいているように)。 MNNsがMRsからそれぞれのMNPの「好み」情報を取得できるのは、望ましいかもしれません。 これはデフォルトアドレス選択を許容するでしょう。
Ng, et al. Informational [Page 23] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[23ページ]のRFC4980分析
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]で指定しました。 双方向のトンネルの性能に基づくRouter Advertisementにそのような「好み」情報をはめ込むときのさらなる探検は役に立つと判明するかもしれません。 ソースアドレス選択が密接に経路選択手順(セクション4.1.3を見る)と再の家へ帰りのテクニックに関連するかもしれないことに注意してください(セクション4.1.4を見てください)。
This is a general issue faced by any node when offered multiple prefixes.
これは複数の接頭語を提供するときどんなノードでも直面している一般答弁です。
4.8. Loop Prevention in Nested Mobile Networks
4.8. 入れ子にされたモバイルネットワークにおける輪の防止
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.
「マルチ-家へ帰」っているモバイルネットワークが別のモバイルネットワークの中で入れ子にされるとき、それは非常に複雑なtopologiesをもたらすことができます。 例えば、入れ子にされたモバイルネットワークは2異なった根-MRsに付けられるかもしれません、その結果、集められたネットワークがもう簡単な木構造を形成しません。 そのような状況で、モバイルネットワークの中の無限ループは起こるかもしれません。
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.
この問題はネモBasic Supportに特定です。 しかしながら、これを書いている時点でより多くの研究が輪が「マルチ-家へ帰」っているモバイルネットワークで現れるという確率を算定することが勧められます。 関連する仕事に関しては、メカニズムが避ける[25]が入れ子にされたネモで輪にされるのを確実にしてください。
4.9. Prefix Ownership
4.9. 接頭語所有権
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が自分たちを分けた2)であり、異なったリンクの上のMRsは唯一の利用可能なMNPを登録しようとするかもしれません。 これを許容できません、HAにアドレスがそのMNPから構成されていることのどのノードがどのMRに添付されるかを知る方法が全くないとき。何らかのメカニズムが1(すべて)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.
この問題はネモBasic Supportに特定です。 しかしながら、この問題が起こることができるくらいの展開シナリオがあるかどうかが、不明瞭です。
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 WGが十分な業者/オペレータ関心があればこの問題を解決するか、またはルータの番号を付け替えるのなしで(n、*、1)ネットワークの分裂を許容できないと指定するために解決策を標準化するのは、お勧めです。
Ng, et al. Informational [Page 24] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[24ページ]のRFC4980分析
4.10. Preference Settings
4.10. 好みの設定
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:
モバイルネットワークが「マルチ-家へ帰」るとき、MNNsはこの構成の利益を得ることができるかもしれません、費用、トランスミッション遅れ、帯域幅などに基づく利用可能な経路の中で選ぶようなもの しかしながら、いくつかの場合、MNNsはそのような選択を入手しません。 特に:
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)構成では、ソースアドレス選択でMNNsは経路に影響を及ぼすことができます(セクション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、*、*)構成では、MNNsはデフォルトで経路に影響を及ぼすことができます。ルータ選択(セクション4.1.3を見ます)。
o In the (1,n,1) configuration, the MNNs cannot influence the path
selection.
o (1、n、1)構成では、MNNsは経路選択に影響を及ぼすことができません。
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.
好みの設定の1つの局面は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 WGsなどの様々なWGsによって探られています。 また、MNNsのShim6層にはそのような能力があるのも、可能です。 業者かオペレータがマルチホーミング能力をモバイルネットワークに提供するときこれらのWGsによって見いだされた解決策に調査するのは、お勧めです。
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.
さらに、可動のノードが流れがろ過剤[27](HAや可動のアンカー・ポイントなどの)によってどう進められるべきであるかを示すように、Monami6 WGは現在、解決策をフィルターにかける流れを発生しています。 Monami6 WGが、MNNがその流れフィルタリングを実行できるようにここで説明された問題が流れがMRによってどう進められるはずであるかを示すと考えるのは、お勧めです。
Ng, et al. Informational [Page 25] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[25ページ]のRFC4980分析
5. Recommendations to the Working Group
5. 作業部会への推薦
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で特定されました。 これらは以下のマトリクスで示されます、それぞれの8つのマルチホーミング構成のために、それぞれの問題の解決がどのWG(s)が最も見つけられそうであるかからの指摘と共に。
+=================================================================+
| # 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
+=================================================================+ | # MRsについて: | 1 | 1 | 1 | 1 | n| n| n| n| | # 持っています: | 1 | 1 | n| n| 1 | 1 | n| n| | # 接頭語について: | 1 | n| 1 | n| 1 | n| 1 | n| +=================================================================+ | 耐障害性| * | * | * | * | * | * | * | * | +---------------------------------+---+---+---+---+---+---+---+---+ | 失敗検出|ニュートン毎メートル|ニュートン毎メートル|ニュートン毎メートル|ニュートン毎メートル|ニュートン毎メートル|ニュートン毎メートル| N| S| +---------------------------------+---+---+---+---+---+---+---+---+ | 経路探検|ニュートン毎メートル|ニュートン毎メートル|ニュートン毎メートル|ニュートン毎メートル|ニュートン毎メートル|ニュートン毎メートル| N| S| +---------------------------------+---+---+---+---+---+---+---+---+ | 経路選択| N|S/M| M|S/M| N|S/N| N|S/N| +---------------------------------+---+---+---+---+---+---+---+---+ | 再の家へ帰り|ニュートン毎メートル| S|ニュートン毎メートル| S|ニュートン毎メートル| S|ニュートン毎メートル| S| +---------------------------------+---+---+---+---+---+---+---+---+ | イングレスフィルタリング| . | . | . | t| . | . | . | N| +---------------------------------+---+---+---+---+---+---+---+---+ | ハ、同期| . | . |ニュートン毎メートル|ニュートン毎メートル| . | . |ニュートン毎メートル|ニュートン毎メートル| +---------------------------------+---+---+---+---+---+---+---+---+ | MR同期| . | . | . | . | G| G| G| G| +---------------------------------+---+---+---+---+---+---+---+---+ | 接頭語代表団| . | . | N| N| N| N| N| N| +---------------------------------+---+---+---+---+---+---+---+---+ | 複数の結合/登録証明書| M| M| M| M| M| M| M| M| +---------------------------------+---+---+---+---+---+---+---+---+ | ソースアドレス選択| . | G| . | G| . | G| . | G| +---------------------------------+---+---+---+---+---+---+---+---+ | 入れ子にされたネモでの輪の防止| N| N| N| N| N| N| N| N| +---------------------------------+---+---+---+---+---+---+---+---+ | 接頭語所有権| . | . | . | . | N| . | N| . | +---------------------------------+---+---+---+---+---+---+---+---+ | 好みの設定| G| G| G| G| G| G| G| G| +=================================================================+ N--ネモSpecific M--MIPv6 Specific G--一般的なIPv6 S--SHIM6 WG D--DNA WG--Issue tでない--些細な*--欠点ToleranceはFailure Detection、Path Exploration、Path Selection、およびRe-家へ帰りの組み合わせです。
Figure 10: Matrix of NEMO Multihoming Issues
図10: ネモマルチホーミング問題のマトリクス
Ng, et al. Informational [Page 26] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[26ページ]のRFC4980分析
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.
上のマトリクスは、どの問題がネモ特有であるか、そして、どれが特有でないかを特定するのに役立ちます。 読者は微妙な細部が図10に表されないようにこのマトリクスがセクション4の簡素化であることを思い出させられています。
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から見ることができるように、↓これはいくつかのネモにとって、特定の関心です: 失敗検出、経路探検、経路選択、再自動誘導しています、イングレスフィルタリング、ハ、同期、接頭語代表団、中で入れ子にされた輪の防止ネモ、そして、所有権を前に置いてください。 ネモの可能な展開に関する作者の最も良い知識に基づいて、以下のことが推薦されます。
o A solution for Failure Detection, Path Exploration, Path
Selection, and Re-Homing be solicited from other WGs.
o 解決策、Failure Detection、Path Exploration、Path Selection、およびRe-家へ帰りには、他のWGsから、請求されてください。
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.
Path Selectionはネモ特有であるとして図10に反映されますが、問題の技術的問題点が可動のノードにおける、複数の経路の品揃えと全く同様であると信じられています。 そういうものとして、私たちは、業者がIETFの他のWGsからのこれらの問題の解決に請求することを勧めるでしょう。 例えば、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)構成のイングレスFilteringを解決できます。
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.
この問題を明確に定義して、WGは解決できます。 大量輸送(バス、列車などの)のための異なったサービスプロバイダーが乗り物/船の上にそれら自身のMRsをインストールするかもしれない手段で(n、n、n)構成の展開を思い描くことができます。
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が、より一般的な意味におけるイングレスフィルタリングに打ち勝つためにメカニズムを開発しているかもしれないことに注意されるべきです。 その結果、私たちは、WGが、この問題に働くと決めるならNEMO WGが(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 Synchronizationがあることができるので、解決策は、両方を考慮に入れる移動性の特定のWGでモバイルホストがネモBasic Supportを操作しながらモバイルIPv6とMRsを操作するのを見ました。
o A solution for Multiple Bindings/Registrations is presently being
developed by the Monami6 WG.
o Multiple Bindings/登録証明書の解決策は現在、Monami6 WGによって見いだされています。
o Prefix Delegation should be reviewed and checked by the NEMO WG.
o 接頭語DelegationはNEMO WGによって見直されて、チェックされるはずです。
The proposed solutions [22] and [21] providing prefix delegation
functionality to NEMO Basic Support should be reviewed in order to
接頭語代表団の機能性をネモBasic Supportに供給する提案された解決策[22]と[21]は見直されるべきです。
Ng, et al. Informational [Page 27] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[27ページ]のRFC4980分析
make sure concerns, as discussed in Section 4.5, are properly
handled.
セクション4.5で議論する関心が適切に扱われるのを確実にしてください。
o Loop Prevention in Nested NEMO should be investigated.
o Nestedネモの輪のPreventionは調査されるべきです。
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 接頭語Ownershipは業者とオペレータによって考えられるべきです。
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があるモバイルネットワークが任意に接合して、分かれることができるなら、Prefix Ownershipの問題は起こるだけです。 モバイルネットワークの業者とオペレータがそのような種類のモバイルネットワークを配備する適用性に関する彼らの意見を入力するよう奨励されます。
6. Conclusion
6. 結論
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.
このメモはネモBasic Support(RFC3963)の操作でネットワークの移動性の文脈における、マルチホーミングの分析を提示しました。 目的はモバイルネットワークが「マルチ-家へ帰」って、複数の双方向のトンネルがホームのエージェントとモバイルRouter組の間で確立されるそのような両性愛者の方向のトンネリングメカニズムに関連する問題を調査することでした。 そうするのにおいて、モバイルネットワークは8つの可能な「マルチ-家へ帰」っている構成を包括する分類学に分類されました。 問題は、それらがどこに適用するかを「マルチ-家へ帰」っている構成に示すテーブルへ、ひとつずつ説明されて、次に、まとめられました、それらを解決できた最も関連しているIETFワーキンググループを示して。 この分析はサポートマルチホーミングと、そして、ネモBasic Supportの作成者に既存の規格を与えるために役立っていてマルチホーミング関連のメカニズムになるでしょう。
7. Security Considerations
7. セキュリティ問題
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.
これはネモBasic Supportの操作でのマルチホーミング構成が分析される情報のドキュメントです。 それらがネモBasic Supportに関するものと異なるなら、今度の解決策でこれらのマルチホーミング構成のセキュリティ問題を考えなければなりません。 例えば、攻撃者は別の通常、インターネットを通して届いていないネットワークにアクセスする手段として「マルチ-家へ帰」っている装置を使用しようとすることができました。 別のネットワークへの推進が構成によってオフにされるときさえ、攻撃者は、それを可能にするためにシステムで妥協できました。
Ng, et al. Informational [Page 28] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[28ページ]のRFC4980分析
8. Acknowledgments
8. 承認
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番目で指示を示した人に感謝したいです--第61IETF Meetings。 マルチホーミング構成におけるネモBasic Supportの事前評価はジュリアンCharbonからの貢献です。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[1] Ernst, T., "Network Mobility Support Goals and Requirements",
RFC 4886, July 2007.
[1] エルンスト、T.、「ネットワークの移動性は目標と要件を支持する」RFC4886、2007年7月。
[2] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[2] 方法とJ.とM.Kojo、「移動性関連用語」、RFC3753、2004年6月。
[3] Ernst, T. and H-Y. Lach, "Network Mobility Support
Terminology", RFC 4885, July 2007.
[3] エルンスト、T.、およびH-Y。 ラック、「ネットワーク移動性サポート用語」、RFC4885、2007年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.、ペトレスク、A.、およびP.Thubert、「ネットワークの移動性(ネモ)の基本的なサポートプロトコル」、RFC3963、2005年1月。
[5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[5] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
9.2. Informative References
9.2. 有益な参照
[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] エルンスト、T.、Montavont、N.、Wakikawa、R.、ウン、C.、およびK.Kuladinithi、「複数のインタフェースとグローバルなアドレスを使用するための動機とシナリオ」は進行中(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]MontavontとN.とWakikawaとR.とエルンストとT.とウン、C.とK.Kuladinithi、「モバイル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.)はバウンドしています、J.、フォルツ、B.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、2003年7月。
[9] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair
Exploration Protocol for IPv6 Multihoming", Work in Progress,
December 2006.
[9] 「IPv6マルチホーミングのための失敗検出とロケータ組探検プロトコル」というArkko、J.、およびI.Beijnumは進行中(2006年12月)で働いています。
Ng, et al. Informational [Page 29] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[29ページ]のRFC4980分析
[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] クリシュナン、S.、N.、Yegin、A.、Veerepalli、S.、およびA.Yegin、「ネットワーク付属を見つけるためのリンクレイヤイベント通知」というMontavontは進行中(2006年11月)で働いています。
[11] Narayanan, S., "Detecting Network Attachment in IPv6 Networks
(DNAv6)", Work in Progress, October 2006.
[11] 「IPv6ネットワーク(DNAv6)でネットワーク付属を見つけ」て、ナラヤナン、S.は進歩、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.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、1998年12月。
[13] Nordmark, E. and M. Bagnulo, "Level 3 multihoming shim
protocol", Work in Progress, November 2006.
[13] Progress、2006年11月のNordmarkとE.とM.Bagnulo、「レベル3 マルチホーミング詰め物のプロトコル」、Work。
[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] ファーガソン、P.、およびD.Senieは「以下をフィルターにかけるイングレスをネットワークでつなぎます」。 「IP Source Address Spoofingを使うサービス妨害Attacksを破ります」、BCP38、RFC2827、2000年5月。
[15] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[15] ベイカー、F.とP.Savola、「Multihomedのためにネットワークをフィルターにかけるイングレス」BCP84、2004年3月のRFC3704。
[16] Huitema, C. and M. Marcelo, "Ingress filtering compatibility
for IPv6 multihomed sites", Work in Progress, October 2006.
[16] Progress、2006年10月のHuitemaとC.とM.マルセロ、「IPv6 multihomedサイトに互換性をフィルターにかけるイングレス」、Work。
[17] Wakikawa, R., Devarapalli, V., and P. Thubert, "Inter Home
Agents Protocol (HAHA)", Work in Progress, February 2004.
[17] R.、Devarapalli、V.、およびP.Thubert、「間のホームエージェントプロトコル(ハハハ)」というWakikawaは進歩、2004年2月に働いています。
[18] Koh, B., Ng, C., and J. Hirano, "Dynamic Inter Home Agent
Protocol", Work in Progress, July 2004.
[18] B.とウン、C.とJ.平野、「ダイナミックな間のホームエージェントプロトコル」というKohは進歩、2004年7月に働いています。
[19] Tsukada, M., "Analysis of Multiple Mobile Routers Cooperation",
Work in Progress, October 2005.
[19] 塚田、M.、「複数のモバイルルータ協力の分析」、処理中の作業、2005年10月。
[20] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix
Delegation", RFC 3769, June 2004.
[20]MiyakawaとS.とR.Droms、「IPv6接頭語代表団のための要件」、RFC3769、2004年6月。
[21] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO",
Work in Progress, September 2006.
[21] 「ネモのためのDHCPv6接頭語代表団」というDroms、R.、およびP.Thubertは進歩、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.、「複数、注意、-、登録を記述する、」、6月2006、進行中で、働いてください。
[24] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003.
[24]Draves、R.、「インターネットプロトコルバージョン6(IPv6)のためのデフォルトAddress Selection」、RFC3484、2003年2月。
Ng, et al. Informational [Page 30] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[30ページ]のRFC4980分析
[25] Thubert, P., Bontous, C., and N. Nicolas, "Nested Nemo Tree
Discovery", Work in Progress, November 2006.
[25] P.とBontous、C.とN.ニコラ、「入れ子にされたネモ木の発見」というThubertは進歩、2006年11月に働いています。
[26] Kumazawa, M., "Token based Duplicate Network Detection for
split mobile network (Token based DND)", Work in Progress,
July 2005.
[26] 熊沢、M.、「分裂モバイルネットワーク(象徴のベースのDND)のための象徴のベースのDuplicate Network Detection」、Progress、2005年7月のWork。
[27] Soliman, H., "Flow Bindings in Mobile IPv6 and NEMO Basic
Support", Work in Progress, March 2007.
[27] ソリマン、H.、「モバイルIPv6とネモで基本的な結合が支持する流れ」が進歩、2007年3月に働いています。
Ng, et al. Informational [Page 31] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[31ページ]のRFC4980分析
Appendix A. Alternative Classifications Approach
付録A.代替手段分類アプローチ
A.1. Ownership-Oriented Approach
A.1。 所有権指向のアプローチ
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'.
「マルチ-家へ帰」っているモバイルネットワークを分類することへの代替的アプローチは、所有権に基づく「マルチ-家へ帰」っているネットワークの分類を壊すことによって、エリックNordmark(サン・マイクロシステムズ)によって提案されました。 これは木のようなトップダウン分類の以上です。 HA(s)とMR(s)のコントロールと所有権から始めて、2つの異なった可能性があります: (i) HA(s)とMR(s)が単一体によって制御されるか、または(ii)のHA(s)とMR(s)は別々の実体によって制御されます。 私たちは、'ISP Model'に最初の可能性を呼んで、2番目を'加入者/プロバイダーModel'と呼びました。
A.1.1. ISP Model
A.1.1。 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).
列車、船、または飛行機の上にMRsをインストールしながらインターネットサービスプロバイダ(ISP)として同じ実体で制御されたHA(s)とMR(s)に関するケースを例証できるのは最も良いです。 モバイルネットワークのある構成を配備するのはISPまで達しています。 Configurationが指向のApproachで説明されるすべての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).
単一体(ISPなどの)によってHA(s)とMR(s)が制御されるとき、ISPは、それがまさしくネットワークにおけるリンクのためのいかなる他のも同じ決定を(ワイヤードであるかそうではありません)であるのにすることができるように1か複数のMNPをモバイルネットワークに配属したがっているかどうか決めることができます。 どのような場合でも、ISPで、モバイルネットワークとそのコアルータ(HAsなどの)の間のルーティングは働くでしょう。 これは、HAsの間に少しの集合も紹介するのを含んでいません。HAsは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(s)とHA(s)の間の双方向のトンネルの上でInteriorゲートウェイプロトコル(IGP)を走らせることができます。 あるいはまた、スタティックルートはトンネルと共に使用されるかもしれません。 スタティックルートが使用されているとき、「トンネル活性」をテストするメカニズムが、聞き古したルートを維持するのを避けるのに必要であるかもしれません。 そのような「トンネル活性」は、鼓動信号をMR(s)からHA(s)に送ることによって、テストされるかもしれません。 可能性はMRにメッセージをBinding Updateに一定の間隔を置いて送らせるBinding Acknowledgmentメッセージの「生涯」分野を制御することによってBinding Updatesメッセージを使用することで鼓動をシミュレートすることです。 しかしながら、より適切なツールはBinding Refresh Requestであるかもしれません。
Ng, et al. Informational [Page 32] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[32ページ]のRFC4980分析
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.
Binding Updateメッセージと比べるとそれがいくらか二次の役割を受けるので、Binding Refresh Requestメッセージへの順応は実現で、より厳密でなく励行されるかもしれませんが、メッセージ。
A.1.2. Subscriber/Provider Model
A.1.2。 加入者/プロバイダーモデル
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サービスのために1つ以上のISPに加入します)。 この場合、2つのサブカテゴリがあります: 加入者がただ一つのISPに加入して、加入者が複数のISPに加入するとき。 '明確に加入者が1つのISPだけに加入する加入者/プロバイダーモデルにあるモバイルネットワーク構成について言及するとき、このドキュメントの残存部分では、私たちが加えるつもりである、/P'接頭語です。 例えば、S/P(1、1、1)かS/P(1、n、n)。 '明確に加入者が複数のISPに加入する加入者/プロバイダーモデルにあるモバイルネットワーク構成について言及するとき、私たちが加えるつもりである、/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モデルのために配備されそうであるというわけではありません。 例えば、それはS/mPについて見通しそうにはありません。(*、1、独身のHAしかない1)モバイルネットワーク。 S/Pモデルにおいて、以下の構成は配備されそうです:
o S/P-(1,1,1): Single Provider, Single MR, Single HA, Single MNP
o S/P(1、1、1): ただ一つのプロバイダー、独身のMRがハ、シングルを選抜する、MNP
o S/P-(1,1,n): Single Provider, Single MR, Single HA, Multiple MNPs
o S/P(1、1、n): ただ一つのプロバイダー、独身のMRがハ、倍数を選抜する、MNP
o S/P-(1,n,1): Single Provider, Single MR, Multiple HAs, Single MNP
o S/P(1、n、1): ただ一つのプロバイダー、独身のMR、倍数はそうして、シングルはMNPです。
o S/P-(1,n,n): Single Provider, Single MR, Multiple HAs, Multiple
MNPs
o S/P(1、n、n): ただ一つのプロバイダー、独身のMR、倍数はそうして、倍数はMNPです。
o S/P-(n,n,1): Single Provider, Multiple MRs, Single HA, Single MNP
o S/P(n、n、1): ただ一つのプロバイダー、複数のMRsがハ、シングルを選抜する、MNP
o S/P-(n,1,n): Single Provider, Multiple MRs, Single HA, Multiple
MNPs
o S/P(n、1、n): ただ一つのプロバイダー、複数のMRsがハ、倍数を選抜する、MNP
o S/P-(n,n,1): Single Provider, Multiple MRs, Multiple HAs, Single
MNP
o S/P(n、n、1): プロバイダー、複数のMRsを選抜してください、そして、倍数はそうして、シングルはMNPです。
o S/P-(n,n,n): Single Provider, Multiple MRs, Multiple HAs, Multiple
MNPs
o S/P(n、n、n): プロバイダー、複数のMRsを選抜してください、そして、倍数はそうして、倍数はMNPです。
Ng, et al. Informational [Page 33] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[33ページ]のRFC4980分析
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、倍数はそうして、シングルはMNPです。
o S/mP-(1,n,n): Multiple Providers, Single MR, Multiple HAs,
Multiple MNPs
o S/mp(1、n、n): 複数のプロバイダー、独身のMR、倍数はそうして、倍数はMNPです。
o S/mP-(n,n,n): Multiple Providers, Multiple MRs, Multiple HAs,
Multiple MNPs
o S/mp(n、n、n): 複数のプロバイダー、複数のMRs、倍数はそうして、倍数は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)が異なった実体によって制御されるとき、1つの実体(すなわち、加入者)によってMRが制御されるのが、おそらくであり、MRは1つ以上のISPによって提供された1HA(s)に複数の双方向のトンネルを確立しています。 そのような場合、ISPが両性愛者の方向のトンネルの上でIGPを走らせるのは、ありそうもないです、ISPが最も確かに経路ドメインの完全なコントロールを保有したくなるので。
A.2. Problem-Oriented Approach
A.2。 問題指向のアプローチ
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:
3番目のアプローチはパスカルThubert(シスコシステムズ)によって提案されました。 これは構成か所有権よりむしろ「マルチ-家へ帰」っているモバイルネットワークの問題に焦点を合わせました。 このアプローチと共に、2つの直交したパラメタに基づく4つのカテゴリのセットがあります: HAsの数、および広告に掲載されたMNPの数。 2つのパラメタが直交しているので、カテゴリは互いに排他的ではありません。 4つのカテゴリは以下の通りです。
o Tarzan: Single HA for Different CoAs of Same MNP
o ターザン: 単一である、同じMNPの異なったCoAsのためにハ。
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.
これは1MRが同じサブネット接頭語のために同じHAに異なったCoAsを登録するそうです。 これはすなわち、y=1に関するケース、(1、1、*)モバイルネットワークに同等です。
o JetSet: Multiple HAs for Different CoAs of Same MNP
o 飛び回ります: 倍数は同じMNPの異なったCoAsのためにそうしました。
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が同じサブネット接頭語のために異なったHAsに異なったCoAsを登録するそうです。 これはすなわち、y=nに関するケース、(1、n、*)モバイルネットワークに同等です。
o Shinkansen: Single MNP Advertised by MR(s)
o 新幹線: MRによって広告に掲載された単一のMNP(s)
This is the case where one MNP is announced by different MRs.
This is equivalent to the case of x=n and z=1, i.e., the (n,*,1)
mobile network.
これは1つのMNPが異なったMRsによって発表されるそうです。 これはすなわち、x=nとz=1に関するケース、(n、*、1)モバイルネットワークに同等です。
Ng, et al. Informational [Page 34] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[34ページ]のRFC4980分析
o DoubleBed: Multiple MNPs Advertised by MR(s)
o DoubleBed: MRによって広告に掲載された複数のMNP(s)
This is the case where more than one MNPs are announced by the
different MRs. This is equivalent to the case of x=n and z=n,
i.e., the (n,*,n) mobile network.
これは1つ以上のMNPが異なったMRsによって発表されるそうです。 これはすなわち、x=nとz=nに関するケース、(n、*、n)モバイルネットワークに同等です。
Appendix B. Nested Tunneling for Fault Tolerance
耐障害性のための付録のB.の入れ子にされたトンネリング
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がそれを検出するなら出口のインタフェースの1つが下がっている、それは世界的なインターネットへの代替経路が存在するかどうか検出するべきです。 独立しているルートを世界的なインターネットに持っているイングレスインタフェースの1つに接続されたいかなる他のMRs、または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].
このAppendixの残存部分では、私たちは、両性愛者の方向のトンネルのそのような再建を実行する方法を調査するのを試みるつもりです。 トンネル再建のこの方法が特に役に立つ、(*、n、n)ネモ構成。 説明された方法は、決して完全でなく、また単にどう問題にアプローチするかに関する提案として機能しません。 また、それはこのフォームの再建を提供するために明確に合わせた新しいプロトコルを指定する目的ではありません。 代わりに、私たちは自分達をIPv6[12]でモバイルIPv6[5]とNeighborディスカバリーで指定された現在利用可能なメカニズムに制限するつもりです。
B.1. Detecting Presence of Alternate Routes
B.1。 代替経路の存在を検出します。
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
複数のMRsがモバイルネットワークにある場合では、各MRは他のMRの存在を検出しなければなりません。MRは、*イングレス*インタフェースでRouter Advertisementメッセージの聞こうとすることによって、そうすることができます。 MRが非ゼロRouterと共にRouter Advertisementメッセージを受け取るとき
Ng, et al. Informational [Page 35] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[35ページ]のRFC4980分析
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.
イングレスインタフェースの1つからの生涯分野、それは代替経路を世界的なインターネットに提供できる別のMRがモバイルネットワークで存在しているのを知っています。
B.2. Re-Establishment of Bi-Directional Tunnels
B.2。 双方向のTunnelsの再建
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がある現在の双方向のトンネルが使用されているリンクが下がっている、それは代替経路が検出した両性愛者の方向のトンネル使用を復職させる必要があります。 私たちはここで2回の別件を考えます: まず第一に、MRに属す別の出口のインタフェースは代替経路を提供します。 第二に、代替経路はモバイルネットワークに接続された別のMRによって提供されます。 私たちは、交互の出口のインタフェースによって提供された代替経路と前のケースを呼んで、交互のMRによって提供された代替経路として後者のケースを呼びます。
B.2.1. Using Alternate Egress Interface
B.2.1。 交互の出口のインタフェースを使用します。
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を使用することで双方向のトンネリングを復職させるために交互のインタフェースに割り当てられたCoAを使用することで失敗したインタフェースのHAに拘束力があるアップデートを送ることです。 うまくいっている拘束力があるアップデートの後に、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.
考えはHAと共に双方向のトンネリングを復職させるためにMRの新しい(バックアップ)CoAとして交互の出口のインタフェースに割り当てられたグローバルアドレス(たぶんCoA)を使用することです。
B.2.2. Using Alternate Mobile Router
B.2.2。 交互のモバイルルータを使用します。
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はHAと共に双方向のトンネルを再証明するために交互のMR(1つが存在しているなら)によって提供されたルートを利用できます。 まず最初に、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.
考えは、HAと共に双方向のトンネリングを復職させるのに交互のMRからCoAを入手して、MRの新しい(バックアップ)CoAとしてこれを使用することです。
Ng, et al. Informational [Page 36] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[36ページ]のRFC4980分析
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.
MNNsの間に送られたあらゆるパケットと彼らの通信員ノードが2つのレベルのカプセル化になることに注意してください。 最初のレベルのトンネリングはMNNがデフォルトルータとして使用するMRとMRのHAの間に起こります。 第2レベルのトンネリングは交互のMRとそのHAの間に起こります。
B.3. To Avoid Tunneling Loop
B.3。 輪にトンネルを堀るのを避けるために
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.
Appendix B.2で説明されるように双方向のトンネルを復職させる方法はトンネリングの無限ループにつながるかもしれません。 モバイルネットワークの2MRsが同時に世界的なインターネットに接続を失うと、これは起こります、そして、各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).
輪にトンネルを堀るのを避ける1つのアプローチがそれが定期的に放送するRouter Advertisementメッセージにオプションを挿入するために世界的なインターネットに接続を失ったMRのためのものです。 このオプションは、リンクの上に送付者がもうグローバルな接続を提供しないように他のMRsに通知するのに役立ちます。 MRに取り付けられるMNNsが、それで彼らのデフォルトルータとしてもMRを使用するのを止めるので(その場合、いろいろなことは1つを二乗するために戻っています)Router Lifetimeがさばくゼロを設定するのがうまくいかないことに注意してください。
B.4. Points of Considerations
B.4。 ポイントの問題
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.
トンネル再建を使用するこの方法は決して完全解ではありません。 まだ、完全に機能的な解決策にそれを開発するために考えるポイントがあります。 例えば、Appendix B.1では、MRがRouter Advertisementsを使用することで他のMRsの存在を検出することが提案されました。 しかしながら、Router Advertisementsが見られたリンクであるので、1個以上のリンクがあるとき、何らかの情報が失われるかもしれません。 例えば、3MRsと3つの異なった接頭語があるケースと各MRが中間で通常のルータとの異なったリンクにあると仮定してください。 独身のMRだけが働いているので、思ってください。 他のMRsは、彼らが新しいCoAを構成するのにどの接頭語を使用しなければならないかをどのように特定しますか? この場合、発表される3つの接頭語があります、そして、リンクが失敗したMRは接頭語が使用されていないことですが、新しいCoAを構成するのに他の2つの接頭語のどれを使用したらよいかを決めることができるくらいの情報を持っていないのを知っています。 そのような場合、メカニズムが、リンクがもう働いていないと発見するとき、MRがそれ自身の接頭語を引き下がらせるのを許容するのに必要です。
Ng, et al. Informational [Page 37] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[37ページ]のRFC4980分析
Authors' Addresses
作者のアドレス
Chan-Wah Ng Panasonic Singapore Laboratories Pte Ltd Blk 1022 Tai Seng Ave #06-3530 Tai Seng Industrial Estate Singapore 534415 SG
チェン-バーウンパナソニックシンガポール研究所Pte Ltd Blk1022のタイSeng Ave#06-3530タイSeng工業団地シンガポール534415SG
Phone: +65 65505420 EMail: chanwah.ng@sg.panasonic.com
以下に電話をしてください。 +65 65505420はメールされます: chanwah.ng@sg.panasonic.com
Thierry Ernst INRIA INRIA Rocquencourt Domaine de Voluceau B.P. 105 Le Chesnay 78153 France
ティエリーエルンストINRIA INRIA Rocquencourtドメーヌde Voluceau B.P.105Le Chesnay78153フランス
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
以下に電話をしてください。 +33-1-39-63 59-30 Fax: +33-1-39-63 54-91のメール: thierry.ernst@inria.fr ユリ: http://www.nautilus6.org/~thierry
Eun Kyoung Paik KT KT Research Center 17 Woomyeon-dong, Seocho-gu Seoul 137-792 Korea
Eun KyoungパクKT KT Research Center17Woomyeon-ドング、Seocho-guソウル137-792韓国
Phone: +82-2-526-5233 Fax: +82-2-526-5200 EMail: euna@kt.co.kr URI: http://mmlab.snu.ac.kr/~eun/
以下に電話をしてください。 +82-2-526-5233 Fax: +82-2-526-5200 メールしてください: euna@kt.co.kr ユリ: http://mmlab.snu.ac.kr/~eun/
Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain
マルセロBagnulo UniversidadカルロスIII deマドリードAv。 Universidad、30マドリード28911レガネス(スペイン)
Phone: +34 91624 8837 EMail: marcelo@it.uc3m.es
以下に電話をしてください。 +34 91624 8837はメールされます: marcelo@it.uc3m.es
Ng, et al. Informational [Page 38] RFC 4980 Analysis of Multihoming in NEMO October 2007
ウン、他 ネモ2007年10月のマルチホーミングの情報[38ページ]のRFC4980分析
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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-ipr@ietf.org のIETFに情報を記述してください。
Ng, et al. Informational [Page 39]
ウン、他 情報[39ページ]
一覧
スポンサーリンク
