RFC4881 日本語訳
4881 Low-Latency Handoffs in Mobile IPv4. K. El Malki, Ed.. June 2007. (Format: TXT=151124 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. El Malki, Ed. Request for Comments: 4881 Athonet Category: Experimental June 2007
ワーキンググループK.高架鉄道Malki、エドをネットワークでつないでください。コメントのために以下を要求してください。 4881年のAthonetカテゴリ: 実験的な2007年6月
Low-Latency Handoffs in Mobile IPv4
モバイルIPv4の低遅延Handoffs
Status of This Memo
このメモの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
Mobile IPv4 describes how a Mobile Node can perform IPv4-layer handoffs between subnets served by different Foreign Agents. In certain cases, the latency involved in these handoffs can be above the threshold required for the support of delay-sensitive or real- time services. The aim of this document is to present two methods to achieve low-latency Mobile IPv4 handoffs. In addition, a combination of these two methods is described. The described techniques allow greater support for real-time services on a Mobile IPv4 network by minimizing the period of time when a Mobile Node is unable to send or receive IPv4 packets due to the delay in the Mobile IPv4 Registration process.
モバイルIPv4はモバイルNodeが異なったForeignエージェントによって勤められたサブネットの間でどうIPv4-層のhandoffsを実行できるかを説明します。 ある場合には、これらのhandoffsにかかわる潜在は遅れ敏感であるか本当の時間指定サービスのサポートに必要である敷居を超えていることができます。 このドキュメントの目的は低遅延のモバイルIPv4 handoffsを達成する2つのメソッドを提示することです。 さらに、これらの2つのメソッドの組み合わせは説明されます。 説明されたテクニックはモバイルIPv4 Registrationの遅れによるモバイルIPv4ネットワークのモバイルNodeがIPv4パケットを送るか、または受けることができない期間を最小にするのによるリアルタイムのプロセスの、より大きいサポートを許します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. The Techniques .............................................5
1.3. L2 Triggers ................................................7
1.4. Requirements Language ......................................9
2. Requirements ....................................................9
3. The PRE-REGISTRATION Handoff Method ............................10
3.1. Operation .................................................11
3.2. Network-Initiated Handoff .................................13
3.3. Mobile-Initiated Handoff ..................................15
3.4. Obtaining and Proxying nFA Advertisements .................17
3.4.1. Inter-FA Solicitation ..............................17
3.4.2. Tunneled nFA Advertisements ........................18
3.5. Caching Router Advertisements .............................19
1. 序論…3 1.1. 用語…4 1.2. テクニック…5 1.3. L2引き金…7 1.4. 要件言語…9 2. 要件…9 3. プレ登録移管メソッド…10 3.1. 操作…11 3.2. 移管をネットワークで開始します…13 3.3. モバイルに開始している移管…15 3.4. 入手とProxying nFA広告…17 3.4.1. 相互ファ懇願…17 3.4.2. nFA広告にトンネルを堀ります…18 3.5. ルータ通知をキャッシュします…19
El Malki, Ed. Experimental [Page 1] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[1ページ]RFC4881低遅延
3.6. Movement Detection, MN, and FA Considerations .............19
3.7. L2 Address Considerations .................................21
3.8. Applicability of PRE-REGISTRATION Handoff .................21
4. The POST-REGISTRATION Handoff Method ...........................23
4.1. Two-Party Handoff .........................................24
4.2. Three-Party Handoff .......................................28
4.3. Renewal or Termination of Tunneling Service ...............34
4.4. When Will the MN Perform a Mobile IPv4 Registration? ......34
4.5. Handoff Request (HRqst) Message Format ....................36
4.6. Handoff Reply (HRply) Message Format ......................38
4.7. Handoff to Third (HTT) Message Format .....................40
4.8. Applicability of POST-REGISTRATION Handoff Method .........40
5. Combined Handoff Method ........................................41
6. Layer 2 and Layer 3 Handoff Timing Considerations ..............42
7. Reverse Tunneling Support ......................................42
8. Handoff Signaling Failure Recovery .............................43
8.1. PRE-REGISTRATION Signaling Failure Recovery ...............43
8.1.1. Failure of PrRtSol and PrRtAdv .....................43
8.1.2. Failure of Inter-FA Solicitation and
Advertisement ......................................44
8.2. POST-REGISTRATION Signaling Failure Recovery ..............44
8.2.1. HRqst Message Dropped ..............................44
8.2.2. HRply Message Dropped ..............................45
9. Generalized Link Layer and IPv4 Address (LLA) Extension ........46
9.1. 3GPP2 IMSI Link Layer Address and Connection ID
Extension .................................................47
9.2. 3GPP IMSI Link Layer Address Extension ....................48
9.3. Ethernet Link Layer Address Extension .....................49
9.4. IEEE 64-Bit Global Identifier (EUI-64) Address Extension ..50
9.5. Solicited IPv4 Address Extension ..........................51
9.6. Access Point Identifier Extension .........................52
9.7. FA IPv4 Address Extension .................................53
10. IANA Considerations ...........................................53
10.1. New Extension Values .....................................53
10.2. Generalized Link Layer and IP Address Identifier (LLA) ...54
10.3. New Message Type and Code ................................54
11. Security Considerations .......................................55
12. Acknowledgements ..............................................57
13. References ....................................................57
13.1. Normative References .....................................57
13.2. Informative References ...................................58
Appendix A - Gateway Foreign Agents................................59
Appendix B - Low Latency Handoffs for Multiple-Interface MNs.......60
Appendix C - PRE_REGISTRATION Message Summary......................61
3.6. 動き検出、Mn、およびファ問題…19 3.7. L2は問題を扱います…21 3.8. プレ登録移管の適用性…21 4. ポスト登録移管メソッド…23 4.1. 2パーティの移管…24 4.2. 3パーティの移管…28 4.3. トンネリングサービスの更新か終了…34 4.4. ミネソタはいつモバイルIPv4登録を実行するでしょうか? ......34 4.5. 移管要求(HRqst)メッセージ・フォーマット…36 4.6. 移管回答(HRply)メッセージ・フォーマット…38 4.7. 第3(HTT)メッセージ・フォーマットへの移管…40 4.8. ポスト登録移管メソッドの適用性…40 5. 移管メソッドを結合します…41 6. 2と層3の移管タイミング問題を層にしてください…42 7. トンネリングサポートを逆にしてください…42 8. 移管シグナリング失敗回復…43 8.1. プレ登録シグナリング失敗回復…43 8.1.1. PrRtSolとPrRtAdvの失敗…43 8.1.2. 相互ファ懇願と広告の失敗…44 8.2. ポスト登録シグナリング失敗回復…44 8.2.1. HRqstメッセージは低下しました…44 8.2.2. HRplyメッセージは低下しました…45 9. 一般化されたリンクレイヤとIPv4は、(LLA)が拡大であると扱います…46 9.1. 3GPP2 IMSIは層のアドレスと接続ID拡大をリンクします…47 9.2. 3GPP IMSIは層のアドレス拡大をリンクします…48 9.3. イーサネットは層のアドレス拡大をリンクします…49 9.4. IEEEの64ビットのグローバルな識別子(EUI-64)は拡大を扱います。50 9.5. 請求されたIPv4は拡大を扱います…51 9.6. アクセスポイント識別子拡張子…52 9.7. ファIPv4は拡大を扱います…53 10. IANA問題…53 10.1. 新しい拡大値…53 10.2. 一般化されたリンクレイヤとIPは識別子(LLA)を扱います…54 10.3. 新しいメッセージタイプとコード…54 11. セキュリティ問題…55 12. 承認…57 13. 参照…57 13.1. 標準の参照…57 13.2. 有益な参照…58 付録A--ゲートウェイの外国人のエージェント…59 付録B--複数のインタフェースMNsのための低遅延Handoffs…60 付録C--前_の登録メッセージ概要…61
El Malki, Ed. Experimental [Page 2] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[2ページ]RFC4881低遅延
1. Introduction
1. 序論
Mobile IPv4 [1] describes how a Mobile Node (MN) can perform IPv4- layer handoff between subnets served by different Foreign Agents (FAs). In certain cases, the latency involved in handoff can be above the threshold required for the support of delay-sensitive or real-time services. The aim of this document is to present two techniques to achieve low-latency Mobile IPv4 handoff during movement between FAs. A further combination of these two techniques is also described. The presented techniques allow greater support for real- time services on a Mobile IPv4 network by minimizing the period of time during which an MN is unable to send or receive IPv4 packets due to the delay in the Mobile IPv4 Registration process. One or more of these techniques may be required to achieve fast Mobile IPv4 handoffs over different wireless technologies (e.g., WLAN, Cellular, WiMAX, Flash-OFDM, etc.). Each wireless technology has different layer 2 handoff procedures, and the best low-latency technique for each scenario should be used to optimize the handoff performance. Further deployment and experimentation are required to determine which technique is best suited to the wireless technologies in terms of implementation and performance. Therefore, the authors encourage further performance measurements and work on low-latency-over-foo specifications in collaboration with the appropriate wireless technology fora to describe the applicability to different wireless layer 2s.
モバイルIPv4[1]はモバイルNode(ミネソタ)がどう異なったForeignエージェント(FAs)によって勤められたサブネットの間のIPv4層の移管を実行できるかを説明します。 ある場合には、移管にかかわる潜在は遅れ敏感であるかリアルタイムでサービスのサポートに必要である敷居を超えていることができます。 このドキュメントの目的はFAsの間の動きの間、低遅延のモバイルIPv4移管を達成するために2つのテクニックを提示することです。 また、これらの2つのテクニックのさらなる組み合わせは説明されます。 提示されたテクニックは、モバイルIPv4ネットワークでミネソタがIPv4パケットを送るか、またはモバイルIPv4 Registrationプロセスの遅れのため受けることができない期間を最小にすることによって、本当の時間指定サービスの、より大きいサポートを許します。 これらのテクニックの1つ以上が、異なった無線技術(例えば、WLAN、Cellular、WiMAX、Flash-OFDMなど)の上で速いモバイルIPv4 handoffsを達成するのに必要であるかもしれません。 各無線技術には、異なった層の2移管手順があります、そして、各シナリオのための最も良い低遅延のテクニックは、移管性能を最適化するのに使用されるべきです。 さらなる展開と実験が、どのテクニックを実装と性能で無線技術に合わせるかを最も良い決定するのに必要です。 したがって、作者は、適切な無線技術フォーラムとの共同における低い潜在過剰foo仕様に対する性能測定と仕事が異なったワイヤレスの層2sに適用性を説明するようさらに奨励します。
In the rest of this section, terminology used throughout the document is presented, the handoff techniques are briefly described, and the use of link-layer information is outlined. In Section 2, a brief description of requirements is presented. Section 3 describes the details of the PRE-REGISTRATION handoff technique, and Section 4 describes the details of the POST-REGISTRATION handoff technique. In Section 5, a combined method using the two handoff techniques together is presented. Section 6 discusses layer 2 and layer 3 handoff timing considerations. Section 7 discusses reverse tunneling support, Section 8 describes mechanisms to recover from message failures, and Section 9 describes protocol extensions required by the handoff techniques. Sections 10 and 11 discuss IANA and security considerations. Finally, the three appendices discuss additional material related to the handoff techniques. Appendix A gives a short introduction to Regional Registrations [11], which can be used together with low-latency handoffs. Appendix B discusses low-latency handoff when an MN has multiple wireless L2 interfaces, in which case the techniques in this document may not be necessary. Appendix C provides a summary of the messages used in PRE-REGISTRATION.
このセクションの残りでは、ドキュメント中で使用される用語は提示されます、そして、移管のテクニックは簡潔に説明されます、そして、リンクレイヤ情報の使用は概説されています。 セクション2では、要件の簡単な説明は提示されます。 セクション3はPRE-REGISTRATION移管のテクニックの詳細について説明します、そして、セクション4はポスト-REGISTRATION移管のテクニックの詳細について説明します。 セクション5では、2つの移管のテクニックを一緒に使用する結合したメソッドは提示されます。 セクション6は層2と層3の移管タイミング問題について論じます。 セクション7は逆のトンネリングサポートについて論じます、そして、セクション8はメッセージ失敗から回復するためにメカニズムについて説明します、そして、セクション9は移管のテクニックによって必要とされたプロトコル拡大について説明します。 セクション10と11はIANAとセキュリティ問題について論じます。 最終的に、3個の付録が移管のテクニックに関連する追加材料について議論します。 付録Aは短い序論をRegional Registrations[11]に与えます。(低遅延handoffsと共にRegional Registrationsを使用できます)。 ミネソタに複数のワイヤレスのL2インタフェースがあるとき、付録Bは低遅延移管について議論します、その場合、テクニックが本書では必要でないかもしれません。 付録CはPRE-REGISTRATIONで使用されるメッセージの概要を提供します。
El Malki, Ed. Experimental [Page 3] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[3ページ]RFC4881低遅延
1.1. Terminology
1.1. 用語
This section presents a few terms used throughout the document.
このセクションはドキュメント中で使用されるいくつかの用語を提示します。
oFA - old Foreign Agent (FA), the FA involved in handling the
care-of address (CoA) of a Mobile Node (MN) prior to a layer 3
(L3) handoff.
oFA、--、年取ったForeignエージェント(FA)、FAが中で扱うことを伴った注意、-、層の前のモバイルNode(ミネソタ)の(CoA)に3(L3)移管を扱ってください。
nFA - new Foreign Agent, the FA anticipated to be handling an MN's
care-of address after completion of an L3 handoff.
nFA、--、新しいForeignエージェント、FAがミネソタのものを扱っていると予期した注意、-、L3移管の完成の後のアドレス。
aFA - anchor Foreign Agent, the FA that is currently handling the
network end of the tunnel in POST-REGISTRATION.
aFA--Foreignエージェント、現在ポスト-REGISTRATIONのトンネルのネットワーク端を扱っているFAを据えつけてください。
L2 handoff - Movement of an MN's point of layer 2 (L2) connection
from one wireless access point to another.
L2移管--ミネソタの層2(L2)の接続のポイントの1ワイヤレス・アクセスポイントからもう1ポイントまでの動き。
L3 handoff - Movement of an MN between FAs that involves changing
the care-of address at Layer 3 (L3).
L3移管--、変化することを伴うFAsの間のミネソタの動き、注意、-、Layer3(L3)のアドレス。
L2 trigger - Information from L2 that informs L3 of particular
events before and after L2 handoff. The descriptions of L2
triggers in this document are not specific to any particular
L2, but rather represent generalizations of L2 information
available from a wide variety of L2 protocols.
L2引き金--L2移管の前後に特定のイベントについてL3に知らせるL2からの情報。 L2引き金の記述は本書ではどんな特定のL2にも明確ではありませんが、むしろさまざまなL2プロトコルから利用可能なL2情報の一般化を表してください。
L2-MT - An L2 trigger that occurs at the MN, informing of movement
to a certain nFA (Mobile Trigger).
L2-MT--あるnFA(モバイルTrigger)への動きについて知らせて、ミネソタに現れるL2引き金。
L2-ST or source trigger - An L2 trigger that occurs at oFA,
informing the oFA that L2 handoff is about to occur.
L2-STかソース引き金--oFAに現れるL2引き金、oFAに知らせて、そのL2移管は起ころうとしています。
L2-TT or target trigger - An L2 trigger that occurs at nFA,
informing the nFA that an MN is about to be handed off to nFA.
L2-TTか目標引き金--ミネソタがnFAに渡されようとしていることをnFAに知らせて、nFAに現れるL2引き金。
L2-LU - An L2 trigger that occurs at the MN or nFA, informing that
the L2 link between MN and nFA is established.
L2-LU--ミネソタかnFAに現れるL2引き金、L2がミネソタとnFAの間でリンクする案内は設立されます。
L2-LD - An L2 trigger that occurs at the oFA, informing the oFA
that the L2 link between MN and oFA is lost.
L2-LD--oFAに現れるL2引き金、L2がミネソタとoFAの間でリンクすることをoFAに知らせるのは無くなっています。
low-latency handoff - L3 handoff in which the period of time
during which the MN is unable to receive packets is minimized.
低遅延移管--ミネソタがパケットを受けることができない期間が最小にされるL3移管。
low-loss handoff - L3 handoff in which the number of packets
dropped or delayed is minimized. Low-loss handoff is often
called smooth handoff.
低い損失移管--パケットの数が低下したか、または延着したL3移管は最小にされます。 低い損失移管はしばしば滑らかな移管と呼ばれます。
El Malki, Ed. Experimental [Page 4] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[4ページ]RFC4881低遅延
seamless handoff - L3 handoff that is both low latency and low
loss.
シームレスの移管--低遅延と低い損失の両方であるL3移管。
bidirectional edge tunnel (BET) - A bidirectional tunnel
established between two FAs for purposes of temporarily routing
an MN's traffic to/from it on a new subnet without requiring
the MN to change CoA.
双方向の縁のトンネル(BET)--ミネソタがCoAを変える必要でない新しいサブネットで一時ミネソタのトラフィックをそれからの/に発送する目的のために2FAsの間で確立された双方向のトンネル。
ping-pong - Rapid back-and-forth movement between two wireless
access points often due to failure of L2 handoff. Ping-pong
can occur if radio conditions for both the old and new access
points are about equivalent and less than optimal for
establishing a good, low-error L2 connection.
ピンポン--しばしばL2移管の失敗による2ワイヤレス・アクセスポイントの間の急速な前後方向の運動。 良くて、低い誤りのL2接続を確立するには、両方の古くて新しいアクセスポイントのためのラジオ状態がほとんど同等であって、あまり最適でないなら、ピンポンは起こることができます。
network-initiated handoff - L3 handoff in which oFA or nFA
initiates the handoff.
ネットワークによって開始された移管--L3移管はどのoFAかnFAで移管を開始するか。
mobile-initiated handoff - L3 handoff in which the MN initiates
the handoff.
モバイルで開始している移管--ミネソタが移管を開始するL3移管。
MN or FA identifier - An IPv4 address of an MN or FA, or an L2
identifier that can be resolved to the IPv4 address of an MN or
FA. If the identifier is an L2 identifier, it may be specific
to the L2 technology.
ミネソタかFA識別子--ミネソタのIPv4アドレス、FA、またはミネソタかFAのIPv4アドレスに決議できるL2識別子。 識別子がL2識別子であるなら、L2技術に特定であるかもしれません。
1.2. The Techniques
1.2. テクニック
Mobile IPv4 was originally designed without any assumptions about the underlying link layers over which it would operate so that it could have the widest possible applicability. This approach has the advantage of facilitating a clean separation between L2 and L3 of the protocol stack, but it has negative consequences for handoff latency. The strict separation between L2 and L3 results in the following built-in sources of delay:
モバイルIPv4は元々、それが可能な限り広い適用性を持つことができるように作動する基本的なリンクレイヤに関する少しも仮定なしで設計されました。 このアプローチはプロトコル・スタックのL2とL3の間に清潔な分離を容易にする利点を持っていますが、それには、移管潜在のための否定的結果があります。 L2とL3の間の厳しい分離は遅れの以下の内蔵の源をもたらします:
- The MN may only communicate with a directly connected FA. This
implies that an MN may only begin the registration process after
an L2 handoff to nFA (new FA) has completed.
- ミネソタは直接接続されたFAとコミュニケートするだけであるかもしれません。 これは、ミネソタがnFA(新しいFA)へのL2移管の後のプロセスが終了した登録を始めるだけであるかもしれないのを含意します。
- The registration process takes some non-zero time to complete as
the Registration Requests propagate through the network. During
this period of time, the MN is not able to send or receive IPv4
packets.
- Registration Requestsがネットワークを通して伝播するのに従って、登録手続は完成するいくらかの非ゼロ時かかります。 この期間の間、ミネソタは、IPv4パケットを送ることができませんし、受けることができません。
This document presents techniques for reducing these built-in delay components of Mobile IPv4. The techniques can be divided into two general categories, depending on which of the above problems they are attempting to address:
このドキュメントはモバイルIPv4のこれらの内蔵の遅れの部品を減少させるためのテクニックを提示します。 テクニックを2つの一般的なカテゴリに分割できます、それらが、上の問題のどれを扱うのを試みているかによって:
El Malki, Ed. Experimental [Page 5] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[5ページ]RFC4881低遅延
- Allow the MN to communicate with the nFA while still connected
to the oFA.
- まだoFAに接続されている間、ミネソタとnFAとコミュニケートさせてください。
- Provide for data delivery to the MN at the nFA even before the
formal registration process has completed.
- 正式な登録手続の前のnFAさえのミネソタへの配送が完成したデータに備えてください。
The first category of techniques allows the MN to "pre-build" its registration state on the nFA prior to an underlying L2 handoff. The second category of techniques allows for service to continue uninterrupted while the handoff is being processed by the network without requiring the MN's involvement.
テクニックの最初のカテゴリは、ミネソタが基本的なL2移管の前にnFAに登録状態を「プレ建てること」を許容します。 テクニックの2番目のカテゴリが、サービスが続くのを許容する、とぎれなさ、移管がミネソタのかかわり合いを必要としないでネットワークによって処理されている間。
Three methods are presented in this document to achieve low-latency L3 handoff, one for each category described above and one as a combination of the two:
3つのメソッドが低遅延L3移管、上で説明された各カテゴリあたり1つ、および2つのものの組み合わせとしての1つを達成するために本書では提示されます:
- PRE-REGISTRATION handoff method,
- PRE-REGISTRATION移管メソッド
- POST-REGISTRATION handoff method, and
- そしてポスト-REGISTRATION移管メソッド。
- combined handoff method.
- 結合した移管メソッド。
The PRE-REGISTRATION handoff method allows the MN to be involved in an anticipated IPv4-layer handoff. The MN is assisted by the network in performing an L3 handoff before it completes the L2 handoff. The L3 handoff can be either network-initiated or mobile-initiated. Accordingly, L2 triggers are used both in the MN and in the FA to trigger particular L3 handoff events. The PRE-REGISTRATION method coupled with L2 mobility helps to achieve seamless handoffs between FAs. The basic Mobile IPv4 concept involving advertisement followed by registration is supported, and the PRE-REGISTRATION handoff method relies on Mobile IPv4 security. No new messages are proposed, except for an extension to the Agent Solicitation message in the mobile- initiated case.
PRE-REGISTRATION移管メソッドで、ミネソタは予期されたIPv4-層の移管にかかわります。 ミネソタはL2移管を終了する前にL3移管を実行するのがネットワークによって補助されます。 L3移管は、ネットワークによって開始するかモバイルで開始できます。 それに従って、L2引き金は、特定のL3移管イベントの引き金となるのにミネソタとFAで使用されます。 L2の移動性に結びつけられたPRE-REGISTRATIONメソッドは、FAsの間でシームレスのhandoffsを達成するのを助けます。 登録があとに続いた広告にかかわる基本のモバイルIPv4概念はサポートされます、そして、PRE-REGISTRATION移管メソッドはモバイルIPv4セキュリティを当てにします。 モバイルの開始しているケースの中のエージェントSolicitationメッセージへの拡大以外に、どんな新しいメッセージも提案されません。
The POST-REGISTRATION handoff method proposes extensions to the Mobile IPv4 protocol to allow the oFA (old FA) and nFA (new FA) to utilize L2 triggers to set up a bidirectional tunnel between oFA and nFA that allows the MN to continue using its oFA while on nFA's subnet. This enables a rapid establishment of service at the new point of attachment, which minimizes the impact on real-time applications. The MN must eventually perform a formal Mobile IPv4 Registration after L2 communication with the new FA is established, but this can be delayed as required by the MN or FA. Until the MN performs registration, the FAs will set up and move bidirectional tunnels as required to give the MN continued connectivity.
nFAのサブネットにある間、ポスト-REGISTRATION移管メソッドは、oFA(古いFA)とnFA(新しいFA)がoFAとnFAの間のミネソタがoFAを使用し続けることができる双方向のトンネルを設立するのにL2引き金を利用するのを許容するためにモバイルIPv4プロトコルに拡大を提案します。 これは急速なリアルタイムのアプリケーションのときに影響を最小にする新しい接着点でのサービスの設立を可能にします。 新しいFAとのL2コミュニケーションが確立されますが、これがミネソタかFAで必要に応じて遅れることができた後にミネソタは結局、正式なモバイルIPv4 Registrationを実行しなければなりません。 ミネソタが登録を実行するまで、FAsは、継続的な接続性をミネソタに与えるために必要に応じて双方向のトンネルを設立して、動かすでしょう。
El Malki, Ed. Experimental [Page 6] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[6ページ]RFC4881低遅延
The combined method involves running a PRE-REGISTRATION and a POST- REGISTRATION handoff in parallel. If the PRE-REGISTRATION handoff can be performed before the L2 handoff completes, the combined method resolves to a PRE-REGISTRATION handoff. However, if the PRE- REGISTRATION handoff does not complete within an access technology dependent time period, the oFA starts forwarding traffic for the MN to the nFA as specified in the POST-REGISTRATION handoff method. This provides for a useful backup mechanism when completion of a PRE-REGISTRATION handoff cannot always be guaranteed before the L2 handoff completion.
結合したメソッドは、PRE-REGISTRATIONと平行なポストのREGISTRATION移管を実行することを伴います。 PRE-REGISTRATION移管であるなら、実行できます。前、L2移管が完成する、PRE-REGISTRATION移管への結合したメソッド決心。 しかしながら、PRE- REGISTRATION移管がアクセス技術に依存する期間以内に完全でなくするなら、oFAは指定されるとしてのポスト-REGISTRATION移管メソッドによるnFAへのミネソタにトラフィックを送り始めます。 L2移管完成の前にいつもPRE-REGISTRATION移管の完成を保証できるというわけではないとき、これは役に立つバックアップメカニズムに備えます。
It should be noted that the methods described in this document may be applied to MNs having a single interface (e.g., Wireless LAN interface) or multiple interfaces (e.g., one WLAN and one cellular interface). However, the case of multiply-interfaced MNs needs special consideration, since the handoff methods described in this document may not be required in all cases (see Appendix B).
本書では説明されたメソッドが単一のインタフェース(例えば、Wireless LANインタフェース)か複数のインタフェース(例えば、1WLANと1つのセルインタフェース)を持っているMNsに適用されるかもしれないことに注意されるべきです。 しかしながら、ケース、掛け算、-、連結、MNsは特別の配慮を必要とします、本書では説明された移管メソッドがすべての場合で必要でないかもしれないので(Appendix Bを見てください)。
1.3. L2 Triggers
1.3. L2引き金
An L2 trigger is a signal of an L2 event. In this document, the L2 events relate to the L2 handoff process. One possible event is early notice of an upcoming change in the L2 point of attachment of the mobile node to the access network. Another possible event is the completion of relocation of the mobile node's L2 point of attachment to a new L2 access point. This information may come explicitly from L2 in a solicited or unsolicited manner, or it may be derived from L2 messages. Although the protocols outlined in this document make use of specific L2 information, Mobile IPv4 should be kept independent of any specific L2. L2 triggers are an abstraction mechanism for a technology-specific trigger. Therefore, an L2 trigger that is made available to the Mobile IPv4 stack is assumed to be generic and technology independent. The precise format of these triggers is not covered in this document, but the information required to be contained in the L2 triggers for low-latency handoffs is specified.
L2引き金はL2イベントに関する信号です。 本書では、L2イベントはL2移管プロセスに関連します。 1つの可能なイベントはアクセスネットワークへのモバイルノードのL2接着点の今度の変化の早めの通知です。 別の可能なイベントは新しいL2アクセスポイントへのモバイルノードのL2接着点の再配置の完成です。 この情報がL2から請求されたか求められていない方法で明らかに来るかもしれませんか、またはL2メッセージからそれを得るかもしれません。 本書では概説されたプロトコルは特定のL2情報を利用しますが、モバイルIPv4はどんな特定のL2からも独立しているように保たれるべきです。 L2引き金は技術特有の引き金のための抽象化メカニズムです。 したがって、モバイルIPv4スタックが入手するL2引き金はジェネリックと技術独立者であると思われます。 これらの引き金の正確な形式は本書ではカバーされていませんが、低遅延handoffsのためのL2引き金に含まれるのに必要である情報は指定されます。
In order to properly abstract from the L2, it is assumed that one of the three entities -- the MN, oFA, or nFA -- is made aware of the need for an L2 handoff and that the nFA or MN can optionally also be made aware that an L2 handoff has completed. A specific L2 will often dictate when a trigger is received and which entity will receive it. Certain L2s provide advance triggers on the network side, while others provide advance triggers on the MN. Also, the particular timing of the trigger with respect to the actual L2 handoff may differ from technology to technology. For example, some wireless links may provide such a trigger well in advance of the actual handoff. In contrast, other L2s may provide little or no information in anticipation of the L2 handoff.
適切に、L2から抽象的です、完成されて、3つの実体の1つ(ミネソタ、oFA、またはnFA)をL2移管の必要性を意識するようにして、また、任意にnFAかミネソタをL2移管がそうしたのを意識するようにすることができると思われます。 特定のL2は、しばしば引き金がいつ受け取られているか、そして、どの実体がそれを受けるかを決めるでしょう。 あるL2sはネットワーク側で前売りの引き金を提供しますが、他のものはミネソタで前売りの引き金を提供します。 また、実際のL2移管に関する引き金の特定のタイミングは技術から技術まで異なるかもしれません。 例えば、いくつかのワイヤレスのリンクが実際の移管のよく前にそのような引き金を提供するかもしれません。 対照的に、他のL2sはL2移管を予測してまず情報を提供しないかもしれません。
El Malki, Ed. Experimental [Page 7] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[7ページ]RFC4881低遅延
An L2 trigger may be categorized according to whether it is received by the MN, oFA, or nFA. Table 1 gives such a categorization along with information contained in the trigger. The methods presented in this document operate based on different types of L2 triggers as shown in Table 1. Once the L2 trigger is received, the handoff processes described hereafter are initiated. The three triggers, L2-ST, L2-TT, and L2-MT, are independent of each other and are not expected to occur together since each will trigger a different type of handoff behaviour.
それがミネソタ、oFA、またはnFAによって受け取られるかどうかに従って、L2引き金は分類されるかもしれません。 テーブル1は引き金に含まれた情報に伴うそのような分類を与えます。 本書では提示されたメソッドは異なったタイプのL2引き金に基づいてTable1に示されるように作動します。 L2引き金がいったん受け取られているようになると、今後説明された移管プロセスは開始されます。 それぞれが異なったタイプの移管のふるまいの引き金となって、3個の引き金(L2-ST、L2-TT、およびL2-MT)が、互いから独立していて、一緒に起こらないと予想されます。
+-------------+----------------------+------------------------------+ | L2 Trigger | Mobile | Source | | | Trigger | Trigger | | | (L2-MT) | (L2-ST) | +-------------+----------------------+------------------------------+ | Recipient | MN | oFA | +-------------+----------------------+--------------+---------------+ | Method | PRE | PRE | POST | | | mobile-initiated | network- | source | | | | initiated | trigger | +-------------+----------------------+--------------+---------------+ | When? | sufficiently before | sufficiently | sufficiently | | | the L2 handoff | before L2 | before L2 | | | so that MN can | handoff for | handoff for | | | solicit PrRtAdv | FA to send | oFA & nFA to | | | from oFA | PrRtAdv | exchange | | | | to MN | HRqst/HRply | +-------------+----------------------+--------------+---------------+ | Parameters | nFA identifier | nFA identifier, MN identifier| +-------------+----------------------+------------------------------+
+-------------+----------------------+------------------------------+ | L2引き金| モバイル| ソース| | | 引き金| 引き金| | | (L2-MT) | (L2、-、第) | +-------------+----------------------+------------------------------+ | 受取人| ミネソタ| oファ| +-------------+----------------------+--------------+---------------+ | メソッド| 前| 前| ポスト| | | モバイルで、開始されています。| ネットワーク| ソース| | | | 開始されます。| 引き金| +-------------+----------------------+--------------+---------------+ | いつですか? | 十分以前| 十分| 十分| | | L2移管| L2の前で| L2の前で| | | ミネソタがそうすることができるように| 移管| 移管| | | PrRtAdvに請求してください。| 発信するFA| oファとnFA| | | oFAから| PrRtAdv| 交換| | | | ミネソタに| HRqst/HRply| +-------------+----------------------+--------------+---------------+ | パラメタ| nFA識別子| nFA識別子、ミネソタ識別子| +-------------+----------------------+------------------------------+
Table 1 - L2 Trigger
(continued on next page)
テーブル1--L2引き金(次のページでは、続けられています)
El Malki, Ed. Experimental [Page 8] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[8ページ]RFC4881低遅延
+------------+----------------------+---------------+---------------+ | L2 Trigger | Target | Link-Up | Link-Down | | | Trigger | (L2-LU) | (L2-LD) | | | (L2-TT) | | | |------------+----------------------+---------------+---------------+ | Recipient | nFA | MN or nFA | oFA | |------------+-----------+----------+---------------+---------------+ | Method | PRE | POST | PRE & POST | POST | | | network- | target | | | | | initiated | trigger | | | |------------+----------------------+---------------+---------------+ | When? | | when radio | when radio | | | same as | link between | link between | | | source trigger | MN & nFA is | MN and oFA | | | | established | is lost | |------------+----------------------+---------------+---------------+ | Parameters | oFA identifier | @MN: nFA IPv4 | MN identifier | | | MN identifier | or L2 addr. | | | | | @nFA: MN IPv4 | | | | | or L2 addr. | | +------------+----------------------+---------------+---------------+
+------------+----------------------+---------------+---------------+ | L2引き金| 目標| 結び付いてください。| 下にリンクします。| | | 引き金| (L2-Lu) | (L2-LD) | | | (L2-TT) | | | |------------+----------------------+---------------+---------------+ | 受取人| nFA| ミネソタかnFA| oファ| |------------+-----------+----------+---------------+---------------+ | メソッド| 前| ポスト| 前、ポスト| ポスト| | | ネットワーク| 目標| | | | | 開始されます。| 引き金| | | |------------+----------------------+---------------+---------------+ | いつですか? | | 無線連絡してくださいというとき| 無線連絡してくださいというとき| | | 同じ| 間にリンクしてください。| 間にリンクしてください。| | | ソース引き金| ミネソタとnFAはそうです。| ミネソタとoFA| | | | 設立されます。| 無くなる| |------------+----------------------+---------------+---------------+ | パラメタ| oFA識別子| @MN: nFA IPv4| ミネソタ識別子| | | ミネソタ識別子| または、L2 addr。 | | | | | @nFA: ミネソタIPv4| | | | | または、L2 addr。 | | +------------+----------------------+---------------+---------------+
Table 1 - L2 Trigger
テーブル1--L2引き金
1.4. Requirements Language
1.4. 要件言語
In this document, the key words "MAY", "MUST", "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT" are to be interpreted as described in [2].
そして、キーワード「5月」、“MUST"、「必須NOT」、本書では「任意」の、そして、「お勧め」の“SHOULD"、「」 [2]で説明されるように解釈されることになっているべきになってください。
2. Requirements
2. 要件
The following requirements are applicable to low-latency handoff techniques and are supported by the methods in this document:
以下の要件は、低遅延移管のテクニックに適切であり、メソッドで本書ではサポートされます:
- to provide low-latency and low-loss handoff for real-time
services,
- 本当の時間指定サービスのための低遅延と低い損失移管を提供するために
- to have no dependence on a wireless L2 technology,
- ワイヤレスのL2技術に依存を全く持たないように
- to support inter- and intra-access technology handoffs, and
- そしてそして、サポート、相互、イントラアクセス技術handoffs。
- to limit wireless bandwidth usage.
- ワイヤレスの帯域幅用法を制限するために。
El Malki, Ed. Experimental [Page 9] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[9ページ]RFC4881低遅延
3. The PRE-REGISTRATION Handoff Method
3. プレ登録移管メソッド
The PRE-REGISTRATION handoff method is based on the normal Mobile IPv4 handoff procedure specified in [1], according to which:
PRE-REGISTRATION移管メソッドが[1]で指定された正常なモバイルIPv4移管手順に基づいている、どれ、:
- an advertisement for an FA is received by an MN,
- FAのための広告はミネソタによって受け取られます。
- the advertisement allows the MN to perform movement detection,
and
- そしてミネソタが広告で動き検出を実行できる。
- the MN registers with the FA.
- ミネソタはFAとともに記名します。
The basic messages specified in [1] are extended to carry information required to achieve fast handoffs. The PRE-REGISTRATION method allows both the MN and FA to initiate the layer 3 handoff and it can make use of L2 triggers on either the FA or MN side, depending on whether network-initiated or mobile-initiated handoff occurs.
[1]で指定された基本のメッセージは、速いhandoffsを達成するのに必要である情報を運ぶために広げられます。 PRE-REGISTRATIONメソッドはミネソタと層を開始するFAの両方に3移管を許容します、そして、どちらかにおけるL2引き金の使用をFAかミネソタの側にすることができます、ネットワークによって開始されたかモバイルで開始している移管が起こるかどうかによって。
PRE-REGISTRATION supports the normal Mobile IPv4 model [1] and optionally also the Regional Registration model [11]. There can be advantages in implementing [11] together with low-latency handoff mechanisms, in particular in cases where the Home Agent (HA) is at a distance (in terms of delay) from the nFA. The time required for the handoff procedure to complete can be reduced by using a closer local HA, called Gateway Foreign Agent (GFA) in [11]. However, implementation of [11] is not required by PRE-REGISTRATION. PRE- REGISTRATION also supports movement where a new Authentication, Authorization, and Accounting (AAA) transaction must occur to authenticate the MN with a new domain.
PRE-REGISTRATIONは任意に普通のモバイルIPv4モデル[1]をサポートします、また、Regional Registrationが[11]をモデル化します。 低遅延移管メカニズムと共に[11]を実行するのにおいて利点があることができます、特にホームのエージェント(HA)が離れたままnFAから来ている(遅れに関して)場合で。 ゲートウェイのForeignエージェント(GFA)は、[11]により近い地方のHAを使用することによって完了する移管手順に必要である時間は短縮できると呼びました。 しかしながら、[11]の実現はPRE-REGISTRATIONによって必要とされません。 また、新しいAuthentication、Authorization、およびAccounting(AAA)取引が新しいドメインがあるミネソタを認証するために起こらなければならないところでPRE- REGISTRATIONは動きを支持します。
El Malki, Ed. Experimental [Page 10] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[10ページ]RFC4881低遅延
3.1. Operation
3.1. 操作
The PRE-REGISTRATION handoff mechanism is summarized in Figure 1.
PRE-REGISTRATION移管メカニズムは図1にまとめられます。
+---------+
| HA (GFA)|<---------+
+---------+ | 4. (Reg)RegReq
| 5. (Reg)RegReply
v
+-----+ 1a. PrRtSol +-----+
| | -----------------> | nFA |
| oFA | 1b. PrRtAdv | |
+-----+ <----------------- +-----+
^ | ^
(2a. PrRtSol)| | 2b |
| | PrRtAdv | 3. (Reg)RegReq
| | |
| v --------------------+
+-----+ /
| MN |
+-----+ - - - - - ->
Movement
+---------+ | ハ、(GFA)| <、-、-、-、-、-、-、-、--+ +---------+ | 4. (レッジ)RegReq| 5. (レッジ)RegReply対+-----+ 1a。 PrRtSol+-----+ | | ----------------->| nFA| | oファ| 1b。 PrRtAdv| | +-----+ <。----------------- +-----+ ^ | ^ (2a。 PrRtSol)| | 2b| | | PrRtAdv| 3. (レッジ)RegReq| | | | v--------------------+ +-----+ / | ミネソタ| +-----+--、--、--、--、--、->運動
Figure 1 - PRE-REGISTRATION Handoff Protocol
図1--プレ登録移管プロトコル
The following steps provide more detail on the protocol:
以下のステップはプロトコルに関するその他の詳細を提供します:
1. Message 1a is a Proxy Router (Agent) Solicitation (PrRtSol)
from oFA to nFA. It is a Mobile IP agent solicitation
containing an identifier for the nFA (i.e., IP address or L2
address) in a Generalized Link Layer and IP Address Extension
(see Section 9). When message 1a is received by the nFA
containing nFA's correct identifier in the LLA extension, the
nFA MUST return the Proxy Router Advertisement (Agent
Advertisement) in message 1b. Message 1b is simply nFA's Agent
Advertisement containing the nFA layer 2 address in a
Generalized Link Layer and IP Address (LLA) Extension (see
Section 9.3). Messages 1a and 1b SHOULD occur in advance of
the PRE-REGISTRATION handoff in order not to delay the handoff.
For this to occur, oFA SHOULD solicit and cache advertisements
from neighboring nFAs using messages 1a and 1b, thus decoupling
the timing of this exchange from the rest of the PRE-
REGISTRATION handoff. When the L3 handoff is initiated by a
target L2 trigger at nFA (L2-TT), message 1b equals message 2b
and is sent unsolicited directly to MN (tunneled by nFA to MN
through oFA) instead of being relayed by oFA.
1. oFAからnFAまでメッセージ1aはProxy Router(エージェント)懇願(PrRtSol)です。 それはGeneralized Link LayerとIP Address ExtensionにnFA(すなわち、IPアドレスかL2アドレス)のための識別子を含むモバイルIPエージェント懇願(セクション9を見る)です。 メッセージ1aがLLA拡張子にnFAの正しい識別子を含むnFAによって受け取られるとき、nFAはメッセージ1bでProxy Router Advertisement(エージェントAdvertisement)を返さなければなりません。 メッセージ1bはGeneralized Link LayerとIP Address(LLA)拡張子でnFA層2のアドレスを含む単にnFAのエージェントAdvertisement(セクション9.3を見る)です。 メッセージの1aと1b SHOULDは移管を遅らせない命令におけるPRE-REGISTRATION移管の前に起こります。 oFA SHOULDはこれが起こるように、メッセージの1aと1bを使用することで隣接しているnFAsからの広告に請求して、キャッシュします、その結果、PRE- REGISTRATION移管の残りからのこの交換のタイミングの衝撃を吸収します。 nFA(L2-TT)で目標L2引き金でL3移管を開始するとき、oFAによってリレーされることの代わりに直接ミネソタに求められていない状態で(oFAを通してnFAによってミネソタにトンネルを堀られます)メッセージ1bはメッセージ2bと等しく、送ります。
El Malki, Ed. Experimental [Page 11] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[11ページ]RFC4881低遅延
2. Message 2a is a Proxy Router Solicitation (PrRtSol) from MN to
oFA. It is different from a normal Router (Agent) Solicitation
since it is soliciting an advertisement from a router different
from the one receiving this message. It is a Mobile IP Agent
Solicitation containing an identifier for the nFA (i.e., IP
address or L2 address) in a Generalized Link Layer and IP
Address Extension (see Section 9). The presence of message 2a
indicates that the handoff is mobile-initiated and its absence
means that the handoff is network-initiated. In mobile-
initiated handoff, message 2a occurs if there is an L2 trigger
in the MN to solicit for a Proxy Router Advertisement
(PrRtAdv). When message 2a is received by the oFA, it MUST
return the Proxy Router Advertisement (Agent Advertisement) in
message 2b. This is simply nFA's Agent Advertisement
containing the nFA layer 2 address in a Generalized Link Layer
and IP Address (LLA) Extension (see Section 9.3). In network-
initiated source-triggered handoff, the L2 trigger occurs at
oFA, and oFA MUST relay the Agent Advertisement in message 2b
without the need for the MN to solicit. Note that it is also
possible for nFA to advertise directly to the MN in the
network-initiated target-triggered case (see Section 3.2).
2. ミネソタからoFAまでメッセージ2aはProxy Router Solicitation(PrRtSol)です。 それは、このメッセージを受け取るものと異なったルータからの広告に請求しているので、通常のRouter(エージェント)懇願と異なっています。 それはGeneralized Link LayerとIP Address ExtensionにnFA(すなわち、IPアドレスかL2アドレス)のための識別子を含むモバイルIPエージェントSolicitation(セクション9を見る)です。 メッセージ2aの存在は、移管が可動に開始されていて、不在が、移管がネットワークによって開始されていることを意味するのを示します。 可動の開始している移管では、Proxy Router Advertisement(PrRtAdv)を請うためにL2引き金がミネソタにあれば、メッセージ2aは現れます。 メッセージ2aがoFAによって受け取られるとき、それはメッセージ2bでProxy Router Advertisement(エージェントAdvertisement)を返さなければなりません。 これはGeneralized Link LayerとIP Address(LLA)拡張子でnFA層2のアドレスを含む単にnFAのエージェントAdvertisement(セクション9.3を見る)です。 ネットワークの開始しているソースによって引き起こされた移管では、L2引き金はoFAに現れます、そして、oFAはメッセージ2bでミネソタが請求する必要性なしでエージェントAdvertisementをリレーしなければなりません。 また、nFAが直接ネットワークによって開始された目標で引き起こされた場合におけるミネソタに広告を出すのも、可能であることに注意してください(セクション3.2を見てください)。
3. The MN performs movement detection upon receipt of a solicited
or unsolicited Agent Advertisement and, if required, it sends a
Registration Request (RegReq) message [1] in message 3 to nFA.
When a local Gateway Foreign Agent (GFA) is present, this
message can optionally be a Regional Registration Request
(RegRegReq) [11]. Message 3 is routed through oFA since the MN
is not directly connected to nFA prior to the L2 handoff.
3. ミネソタは請求されたか求められていないエージェントAdvertisementを受け取り次第動き検出を実行します、そして、必要なら、それはメッセージ3のRegistration Request(RegReq)メッセージ[1]をnFAに送ります。 地元のゲートウェイのForeignエージェント(GFA)が出席しているとき、このメッセージは任意にRegional Registration Request(RegRegReq)[11]であることができます。 ミネソタがL2移管の前に直接nFAにつなげられないので、メッセージ3はoFAを通して発送されます。
4. Messages 4 and 5 complete the standard Mobile IPv4 Registration
[1] or optionally Regional Registration [11] initiated with
message 3. The Registration Request MUST contain the MN's
layer 2 address in a Generalized Link Layer and IP Address
Extension (see Sections 3.7 and 9). This identifier may be a
plain Ethernet address or an identifier specific to the
wireless technology. If the MN is not already connected to
nFA, the Registration Reply in message 5 MUST be buffered by
the nFA and unicast to the MN on-link as soon as the MN
connects to nFA (i.e., L2-LU trigger at nFA, which can be
implemented by the MN sending an Agent Solicitation or
optionally using special layer 2 techniques, which are outside
the scope of this document). This is necessary since the MN
may have to detach from oFA, due to the wireless L2 connection,
before it receives the reply. The MN's L2 address is obtained
using the extensions in Section 9, as described in Section 3.7.
Figures 2 and 3 illustrate this procedure.
4. メッセージ4と5が標準のモバイルIPv4 Registration[1]を完成するか、または任意に、Regional Registration[11]はメッセージで3を開始しました。 Registration RequestはGeneralized Link LayerとIP Address Extensionにミネソタの層2のアドレスを含まなければなりません(セクション3.7と9を見てください)。 この識別子は、明瞭なイーサネット・アドレスか無線技術に特定の識別子であるかもしれません。 ミネソタが既にnFAにつなげられないなら、nFAはメッセージ5のRegistration Replyをバッファリングしなければなりません、そして、ミネソタの次第リンクのミネソタへのユニキャストはnFA(すなわち、nFAのL2-LU引き金)に接続します。エージェントSolicitationを送るミネソタが実行できるか、または任意に特別番組を使用して、nFAは2つのテクニックを層にします。(このドキュメントの範囲の外にテクニックがあります)。 これが以来oFAから取り外すのにミネソタがそうしたかもしれないのが必要です、無線のL2接続のため、回答を受け取る前に。 セクション3.7で説明されるようにセクション9で拡張子を使用することでミネソタのL2アドレスを得ます。 数字2と3はこの手順を例証します。
El Malki, Ed. Experimental [Page 12] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[12ページ]RFC4881低遅延
5. If the registration is successful, packets for the MN are
tunneled from the HA (or GFA) to the nFA and then to the MN.
5. 登録がうまくいくなら、ミネソタへのパケットはHA(または、GFA)からnFAまでそして、ミネソタにトンネルを堀られます。
PRE-REGISTRATION is not dependent on [11]. However, if the HA is at a distance (in terms of delay) from the nFA, the use of a local GFA may reduce the time required for the handoff procedure to complete.
PRE-REGISTRATIONは[11]に依存していません。 しかしながら、HAが離れたままnFAから来ているなら(遅れに関して)、地方のGFAの使用は完了する移管手順に必要である時間を短縮するかもしれません。
The time at which the L2 trigger is received by the oFA or MN, thereby triggering the PRE-REGISTRATION handoff, compared to the time at which the actual L2 handoff occurs is important for the optimal performance of the low-latency handoff. That is, in the optimal case, the L2 trigger will be received and the four messaging steps of PRE-REGISTRATION described above will be completed (i.e., up to when the Registration Request is processed by HA or GFA) before the MN moves. Optimally, the Registration Reply and the first packet redirected by the HA (or GFA) to nFA will reach the MN at the moment in which the MN's L2 link to nFA is fully established. The MN would therefore not suffer any disruption due to the L3 handoff. This cannot always be guaranteed unless particular implementation techniques are used. To alleviate a part of this timing problem, the MN MAY set the S bit [1] in low-latency Registration Requests sent by the MN. This allows the MN to receive packets at both oFA and nFA during the short layer 2 handoff time. Other techniques may be required, such as L2 techniques or buffering, but these are outside the scope of this document. In addition, further handoff smoothing considerations may be required to prevent the loss of packets in- flight between HA (or GFA) and oFA while the MN performs a PRE- REGISTRATION handoff. These are also outside the scope of this document.
L2引き金がoFAかミネソタによって受け取られる時、その結果、低遅延移管の最適の性能に、PRE-REGISTRATION移管であって、実際のL2移管が起こる時と比較された引き金となるのは重要です。 すなわち、最適の場合では、L2引き金を受け取るでしょう、そして、ミネソタが動く前に上で説明されたPRE-REGISTRATIONの4メッセージングステップを終了するでしょう(すなわち、Registration RequestがHAかGFAによって処理される時まで)。 最適に、HA(または、GFA)によってnFAに向け直されたRegistration Replyと最初のパケットは現在、nFAへのミネソタのL2リンクが完全に設立されるミネソタに達するでしょう。 したがって、ミネソタはL3移管による少しの分裂も受けないでしょう。 特定の実現のテクニックが使用されていない場合、いつもこれを保証できるというわけではありません。 このタイミング問題の一部を軽減するために、ミネソタはミネソタによって送られた低遅延Registration RequestsにSビット[1]をはめ込むかもしれません。 これで、ミネソタは短い層の2移管時間、oFAとnFAの両方でパケットを受けることができます。 他のテクニックがL2のテクニックやバッファリングのように必要であるかもしれませんが、このドキュメントの範囲の外にこれらはあります。 さらに、問題を整えるさらなる移管は中でパケットの損失を防ぐのが必要であることで、HA(または、GFA)とoFAの間の飛行がミネソタである間、PRE- REGISTRATION移管を実行するということであるかもしれません。 このドキュメントの範囲の外にもこれらはあります。
Figures 2, 3, and 4 contain message timing diagrams for the network- initiated and mobile-initiated PRE-REGISTRATION handoff procedures.
数字2、3、および4ネットワークのためのダイヤグラムが開始したメッセージタイミングと可動に開始しているPRE-REGISTRATION移管手順を含んでください。
3.2. Network-Initiated Handoff
3.2. ネットワークによって開始された移管
As described in Table 1, a PRE-REGISTRATION handoff can be initiated at oFA by a source trigger or at nFA by a target trigger. Figures 2 and 3 contain message timing diagrams for PRE-REGISTRATION network- initiated handoff for source and target triggers.
Table1で説明されるように、ソース引き金によるoFAにおいて、または、目標引き金によるnFAでPRE-REGISTRATION移管を開始できます。 数字2と3はPRE-REGISTRATIONネットワークソースと目標引き金のための開始している移管のためのメッセージタイムチャートを含んでいます。
A source-triggered, network-initiated handoff occurs when an L2 trigger is received at the oFA informing it of a certain MN's upcoming movement from oFA to nFA. The L2 trigger contains information including the MN's identifier (i.e., the IPv4 address itself or an identifier that can be resolved to the IPv4 address) and the nFA's identifier. An identifier may be an IPv4 address or something specific to the wireless technology (e.g., Base Station or Access Point Identifier). A target-triggered, network-initiated
あるミネソタの今度のoFAからnFAまでの運動についてそれを知らせるoFAにL2引き金を受け取るとき、ソースによって引き起こされて、ネットワークによって開始された移管は起こります。 L2引き金はミネソタの識別子(すなわち、IPv4アドレス自体かIPv4アドレスに決議できる識別子)とnFAの識別子を含む情報を含んでいます。 識別子は、IPv4アドレスか無線技術に何か特定のものであるかもしれません(例えば、基地の駅かAccess Point Identifier)。 目標で引き起こされて、ネットワークによって開始にされる
El Malki, Ed. Experimental [Page 13] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[13ページ]RFC4881低遅延
handoff occurs when an L2 trigger is received at the nFA informing it of a certain MN's upcoming movement from oFA. This type of trigger is also shown in Table 1 and contains information including the MN's and the oFA's identifier.
あるミネソタの今度の運動についてoFAからそれを知らせるnFAにL2引き金を受け取るとき、移管は起こります。 このタイプの引き金は、また、Table1に示されて、ミネソタのものを含む情報とoFAの識別子を含んでいます。
MN oFA nFA HA/GFA
| |<~~~~~~ L2-Source | |
| | Trigger | |
|<--------------------| | |
| PrRtAdv | | |
| | | |
|---------------------------------------->| |
| RegReq or | | |
| RegRegReq (routed via oFA) |------------------->|
| | RegReq or RegRegReq|
| | |
| Buffered ~~~~~>|<-------------------|
|---------------------------------------->| (Reg)RegReply |
| Agent Solicitation | |
| (sent when MN connects to nFA) | |
| | |
|<----------------------------------------| |
| (Reg)RegReply | |
| (sent when nFA receives Solicitation or L2-LU) |
ミネソタoFA nFA、ハ、/GFA| |<~~~~~~ L2-ソース| | | | 引き金| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| PrRtAdv| | | | | | | |---------------------------------------->| | | またはRegReq。| | | | RegRegReq(oFAを通して、掘ります)|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| RegReqかRegRegReq| | | | | バッファリングされます。~~~~~>| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| |---------------------------------------->| (レッジ)RegReply| | エージェント懇願| | | (ミネソタがnFAに接続するとき、発信します) | | | | | |<----------------------------------------| | | (レッジ)RegReply| | | (nFAがSolicitationかL2-LUを受けるとき、発信します) |
Figure 2 - PRE-REGISTRATION Handoff Message Timing Diagram
(Network-Initiated, Source Trigger)
図2--プレ登録移管メッセージタイムチャート(ネットワークによって開始されたソース引き金)
In a source-triggered handoff, when oFA receives the trigger (L2-ST), it MUST send message 2b, the Proxy Router Advertisement (PrRtAdv), to the MN. The PrRtAdv is nFA's Agent Advertisement [1] with one of the link-layer extensions described in Section 9. The use of the contents of this extension is described in Section 3.7. Messages 1a and 1b SHOULD be exchanged by oFA and nFA before the L2 trigger is received (see Section 3.4.1). Message 2a is not used.
oFAが引き金(L2-ST)を受けるときのソースによって引き起こされた移管では、メッセージ2bを送らなければなりません、Proxy Router Advertisement(PrRtAdv)、ミネソタに。 PrRtAdvはリンクレイヤ拡大の1つがセクション9で説明されているnFAのエージェントAdvertisement[1]です。 この拡大のコンテンツの使用はセクション3.7で説明されます。 メッセージの1aと1b SHOULD、L2引き金が受け取られている(セクション3.4.1を見てください)前にoFAとnFAによって交換されてください。 メッセージ2aは使用されていません。
El Malki, Ed. Experimental [Page 14] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[14ページ]RFC4881低遅延
MN oFA nFA HA/GFA
| | L2-Target~~~~~~~~>| |
| | Trigger | |
| |...................| |
|<--------------------------------------- | |
| (PrRtAdv) |...................| |
| | Tunneled Agent Advertisement |
| | | |
|---------------------------------------->| |
| RegReq. or | | |
| RegRegReq (routed via oFA) |------------------->|
| | RegReq or RegRegReq|
| | |
| Buffered ~~~~~>|<-------------------|
|---------------------------------------->| (Reg)RegReply |
| Agent Solicitation | |
| (sent when MN connects to nFA) | |
| | |
|<----------------------------------------| |
| (Reg)RegReply | |
| (sent when nFA receives Solicitation or L2-LU) |
ミネソタoFA nFA、ハ、/GFA| | L2-目標~~~~~~~~>|、|、|、| 引き金| | | |...................| | |<--------------------------------------- | | | (PrRtAdv) |...................| | | | トンネルを堀られたエージェント広告| | | | | |---------------------------------------->| | | RegReq。| | | | RegRegReq(oFAを通して、掘ります)|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| RegReqかRegRegReq| | | | | バッファリングされます。~~~~~>| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| |---------------------------------------->| (レッジ)RegReply| | エージェント懇願| | | (ミネソタがnFAに接続するとき、発信します) | | | | | |<----------------------------------------| | | (レッジ)RegReply| | | (nFAがSolicitationかL2-LUを受けるとき、発信します) |
Figure 3 - PRE-REGISTRATION Handoff Message Timing Diagram
(Network-Initiated, Target Trigger)
図3--プレ登録移管メッセージタイムチャート(ネットワークによって開始された目標引き金)
In a target-triggered handoff, when nFA receives the trigger (L2-TT), it MUST tunnel an Agent Advertisement to the MN through oFA to initiate the L3 handoff. The inner advertisement is unicast by nFA to MN, thus nFA treats the target trigger as a Router (Agent) Solicitation. This advertisement is tunneled to oFA, which functions as a normal router, decapsulating the advertisement and forwarding it to the MN. This message MUST be authenticated to prevent attacks (see Section 3.4.2).
nFAが引き金(L2-TT)を受けるときの目標で引き起こされた移管では、それは、L3移管を開始するためにoFAを通してミネソタのエージェントAdvertisementにトンネルを堀らなければなりません。 内側の広告がミネソタへのnFAによるユニキャストである、その結果、nFAはRouter(エージェント)懇願として目標引き金を扱います。 この広告はoFAにトンネルを堀られます、広告をdecapsulatingして、それをミネソタに送って。(oFAは正常なルータとして機能します)。 攻撃を防ぐためにこのメッセージを認証しなければなりません(セクション3.4.2を見てください)。
3.3. Mobile-Initiated Handoff
3.3. モバイルに開始している移管
As shown in Table 1, a mobile-initiated handoff occurs when an L2 trigger is received at the MN informing that it will shortly move to nFA. The L2 trigger contains information such as the nFA's identifier (i.e., nFA's IPv4 address or an identifier that can be resolved to the nFA's IPv4 address). As an example, a Wireless LAN MN may perform a scan to obtain the Base Station Identifier (BSSID) of the access point that is a potential handoff target (i.e., its signal is becoming stronger). The message timing diagram is shown in Figure 4.
それがまもなくnFAに動かすミネソタの案内のときにL2引き金を受け取るとき、Table1に示されるように、可動に開始している移管は起こります。 L2引き金はnFAの識別子(nFAのIPv4アドレスに決議できるすなわち、nFAのIPv4アドレスか識別子)などの情報を含んでいます。 例として、Wireless LANミネソタは、潜在的移管目標であるアクセスポイントの基地の駅のIdentifier(BSSID)を入手するためにスキャンを実行するかもしれません(すなわち、信号は、より強くなっています)。 メッセージタイムチャートは図4に示されます。
El Malki, Ed. Experimental [Page 15] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[15ページ]RFC4881低遅延
MN oFA nFA HA/GFA
|<~~~~~ L2-Trigger | | |
| | | |
|-------------------->| | |
| PrRtSol | | |
| | | |
|<--------------------| | |
| PrRtAdv | | |
| | | |
|---------------------------------------->| |
| RegReq or | | |
| RegRegReq (routed via oFA) |------------------->|
| | RegReq or RegRegReq|
| | |
| Buffered ~~~~~>|<-------------------|
|---------------------------------------->| (Reg)RegReply |
| Agent Solicitation | |
| (sent when MN connects to nFA) | |
| | |
|<----------------------------------------| |
| (Reg)RegReply | |
| (sent when nFA receives Solicitation or L2-LU) |
ミネソタoFA nFA、ハ、/GFA|<~~~~~ L2-引き金| | | | | | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| PrRtSol| | | | | | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| PrRtAdv| | | | | | | |---------------------------------------->| | | またはRegReq。| | | | RegRegReq(oFAを通して、掘ります)|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| RegReqかRegRegReq| | | | | バッファリングされます。~~~~~>| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| |---------------------------------------->| (レッジ)RegReply| | エージェント懇願| | | (ミネソタがnFAに接続するとき、発信します) | | | | | |<----------------------------------------| | | (レッジ)RegReply| | | (nFAがSolicitationかL2-LUを受けるとき、発信します) |
Figure 4 - PRE-REGISTRATION Handoff Message Timing Diagram
(Mobile-Initiated)
図4--プレ登録移管メッセージタイムチャート(モバイルに開始している)
As a consequence of the L2 trigger (L2-MT), the MN MUST send message 1a, the Proxy Router Solicitation (PrRtSol). This message is a unicast Agent Solicitation to oFA for a Proxy Router Advertisement (PrRtAdv). This solicitation MUST have a TTL=1 as in [1]. The Proxy Router Advertisement Solicitation unicast to oFA is an Agent Solicitation with a special extension. The solicitation MUST have an extension containing an FA identifier (i.e., IPv4 address or L2 address contained in an LLA extension, see Section 9) because the MN is soliciting another specific FA's advertisement from the oFA. This specific FA will be the MN's nFA. The identifier is the IPv4 address of the nFA or another identifier that can be used by the oFA to resolve to nFA's IPv4 address. If the identifier is not an IPv4 address, it MAY be specific to the underlying wireless technology, for example, an access point or Base Station Identifier (e.g., WLAN BSSID) that can be mapped by oFA to the nFA IPv4 address as described in Section 3.4.1. The extension containing the identifier is a sub- type of the Generalized Link Layer Address Extension described in Section 9.
L2引き金(L2-MT)の結果として、ミネソタは1a、Proxy Router Solicitation(PrRtSol)をメッセージに送らなければなりません。 このメッセージはProxy Router Advertisement(PrRtAdv)のためのoFAのユニキャストエージェントSolicitationです。 この懇願には、TTL=1が[1]のようになければなりません。 oFAへのProxy Router Advertisement Solicitationユニキャストは特別な拡大を伴うエージェントSolicitationです。 懇願には、ミネソタがoFAからの別の特定のFAの広告に請求しているので、FA識別子(すなわち、IPv4アドレスかL2アドレスがLLA拡張子で含まれて、セクション9を見る)を含む拡張子がなければなりません。 この特定のFAはミネソタのnFAになるでしょう。 識別子はnFAのIPv4アドレスへのoFAが決心に使用できるnFAか別の識別子のIPv4アドレスです。 識別子がIPv4アドレスでないなら、例えばoFAがセクション3.4.1で説明されるようにnFA IPv4アドレスに写像できる基本的な無線技術、アクセスポイントまたは基地の駅のIdentifier(例えば、WLAN BSSID)に特定であるかもしれません。 識別子を含む拡大はセクション9で説明されたGeneralized Link Layer Address Extensionのサブタイプです。
Two extension sub-types have been defined to contain the nFA's IPv4 address and an access point identifier. They are called the Solicited Agent IPv4 Address Extension and the Access Point
2つの拡大サブタイプが、nFAのIPv4アドレスとアクセスポイント識別子を含むように定義されました。 それらはSolicitedエージェントIPv4 Address ExtensionとAccess Pointと呼ばれます。
El Malki, Ed. Experimental [Page 16] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[16ページ]RFC4881低遅延
Identifier Extension, and are described in Sections 9.5 and 9.6. These two extensions SHOULD NOT be present in the same PrRtSol message.
識別子Extension、セクション9.5に9.6に説明されます。 これらの2拡大SHOULD NOT、同じPrRtSolメッセージに存在してください。
When oFA receives the PrRtSol message, it MUST reply to the MN with the Proxy Router Advertisement (PrRtAdv, message 2b). The PrRtAdv is simply the Agent Advertisement for the requested nFA, proxied by oFA. In order to expedite the handoff, the actual nFA advertisement SHOULD be cached by the oFA following a previous exchange with nFA, shown in messages 1a and 1b, as specified in Section 3.5. The PrRtAdv message MUST contain the nFA's L2 address (using the LLA extension in Section 9.3). This is further described in Section 3.7.
oFAがPrRtSolメッセージを受け取るとき、それはProxy Router Advertisement(PrRtAdv、メッセージ2b)と共にミネソタに答えなければなりません。 PrRtAdvはoFAによってproxiedされた要求されたnFAの単にエージェントAdvertisementです。 移管を速めるために、nFAとの前の交換に続いて、実際のnFA広告SHOULDがoFAによってキャッシュされて、示されたコネは1aと1bを通信させます、セクション3.5で指定されるように。 PrRtAdvメッセージはnFAのL2アドレスを含まなければなりません(セクション9.3でLLA拡張子を使用して)。 これはセクション3.7でさらに説明されます。
3.4. Obtaining and Proxying nFA Advertisements
3.4. 入手とProxying nFA広告
Since L2 triggers are involved in initiating PRE-REGISTRATION handoff, the trigger timing SHOULD be arranged such that a full L3 PRE-REGISTRATION handoff can complete before the L2 handoff process completes. That is, the L2 handoff should be completed after the MN's registration with the nFA is performed (message 3 in Figure 1). The registration MAY be transmitted in more than one copy (default recommendation: 2) to reduce the probability that it is lost due to errors on the wireless link. This would not apply to reliable wireless links where retransmissions are performed at layer 2 in case of error to guarantee packet delivery.
以来、L2引き金はPRE-REGISTRATION移管(完全なL3 PRE-REGISTRATION移管が以前完成できる整っているそのようなものが過程が終了するL2移管であったならSHOULDを調節する引き金)を開始するのにかかわります。 nFAとのミネソタの登録が実行された(図1のメッセージ3)後にすなわち、L2移管は終了するべきです。 登録は、無線のリンクでそれが誤りのため失われているという確率を減少させるためにコピー1部以上(デフォルト推薦: 2)で伝えられるかもしれません。 これは「再-トランスミッション」が誤りの場合にパケット配信を保証するために層2で実行される信頼できる無線のリンクに適用されないでしょう。
A PRE-REGISTRATION handoff in this case requires the MN to receive an Agent Advertisement from the nFA through the old wireless access point. How to achieve this is discussed in the following subsections. Messages exchanged between FAs MUST be authenticated to prevent impersonation attacks. The minimal requirement is that all FAs involved in low-latency handoffs MUST support manual pre- configuration of security associations with other neighboring FAs, involving shared keys and the default algorithms of [1] (see the Security Considerations of this document).
PRE-REGISTRATION移管は、この場合ミネソタがnFAから古いワイヤレス・アクセスポイントまでエージェントAdvertisementを受け取るのを必要とします。 以下の小区分でどうこれを達成するかについて議論します。 ものまね攻撃を防ぐためにFAsの間で交換されたメッセージを認証しなければなりません。 最小量の要件は低遅延handoffsにかかわるすべてのFAsが他の隣接しているFAsとのセキュリティ協会の手動のプレ構成を支持しなければならないということです、[1]の共有されたキーとデフォルトアルゴリズムにかかわって(このドキュメントのSecurity Considerationsを見てください)。
3.4.1. Inter-FA Solicitation
3.4.1. 相互ファ懇願
This applies to the network-initiated source-triggered (L2-ST) and mobile-initiated (L2-MT) cases only. Inter-FA solicitation assumes that oFA has access to the IPv4 address of the nFA. The IPv4 address of nFA is obtained by means of an L2 trigger at oFA in the network- initiated case (see Section 3.2) or by means of the extension to the Proxy Router Solicitation (PrRtSol) from the MN in the mobile- initiated case (see Section 3.3). This extension to the PrRtSol may contain an IPv4 address or another identifier, for example, an identifier of a Wireless Base Station such as the WLAN BSSID. In the latter case, the oFA must implement a mechanism to resolve the Base
これはネットワークによって開始された情報筋によって引き起こされるのであっ(L2-ST)て可動に開始している(L2-MT)ケースだけに適用されます。 相互FA懇願は、oFAがnFAのIPv4アドレスに近づく手段を持っていると仮定します。 oFAのL2引き金によってネットワークの開始しているケース(セクション3.2を見る)か可動の開始している場合におけるミネソタからのProxy Router Solicitationへの拡大(PrRtSol)によってnFAのIPv4アドレスを得ます(セクション3.3を見てください)。 PrRtSolへのこの拡大はWLAN BSSIDなどのWireless基地の駅に関するIPv4アドレスか別の識別子、例えば識別子を含むかもしれません。 後者の場合では、oFAは、基地を分解するようにメカニズムを実行しなければなりません。
El Malki, Ed. Experimental [Page 17] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[17ページ]RFC4881低遅延
Station Identifier to an IPv4 address. The default mechanism is to use a configured table of neighboring Base Station Identifiers (e.g., BSSID) to FA IPv4 address mappings in each FA. Other automated discovery mechanisms may also be used.
IPv4アドレスへの駅のIdentifier。 デフォルトメカニズムは隣接している基地の駅のIdentifiers(例えば、BSSID)の構成されたテーブルを各FAのFA IPv4アドレス・マッピングに使用することです。 また、他の自動化された発見メカニズムは使用されるかもしれません。
If oFA does not cache advertisements (see Section 3.5) once it receives an L2 trigger and obtains the address of the nFA for a specific MN, it MUST send a unicast Agent Solicitation (PrRtSol) to nFA. The nFA replies to the oFA by unicasting an Agent Advertisement with appropriate extensions (PrRtAdv). This method removes the TTL limitation of [1] for Mobile IPv4 messages (i.e., TTL=1 is not applicable here). The TTL limitation cannot be applied since oFA and nFA may be more than one hop away and since it is unnecessary for a secured unicast message. The ICMP solicitations and advertisements MUST be authenticated and integrity protected. These messages MUST be protected using Encapsulating Security Payload (ESP) [10] to prevent attacks (see the Security Considerations section of this document). An FA MUST NOT accept ICMP solicitations or advertisements from sources that are not authenticated.
いったん特定のミネソタとしてL2引き金を受けて、nFAのアドレスを得るとoFAが広告(セクション3.5を見る)をキャッシュしないなら、それはユニキャストエージェントSolicitation(PrRtSol)をnFAに送らなければなりません。 nFAは、適切な拡大(PrRtAdv)と共にエージェントAdvertisementをunicastingすることによって、oFAに答えます。 この方法はモバイルIPv4メッセージのための[1]のTTL制限を取り除きます(すなわち、TTL=1はここで適切ではありません)。 oFAとnFAが遠くで十二分にワンバウンドであるかもしれなく、安全にされたユニキャストメッセージに、それが不要であるので、TTL制限を適用できません。 ICMP懇願と広告を認証しなければなりませんでした、そして、保全は保護されました。 攻撃を防ぐのにEncapsulating Security有効搭載量(超能力)[10]を使用して、これらのメッセージを保護しなければなりません(このドキュメントのSecurity Considerations部を見てください)。 FA MUST NOTは認証されないソースからICMP懇願か広告を受け入れます。
As a practical matter, oFA SHOULD pre-solicit and cache advertisements from known neighboring FAs (see section 3.5) to avoid performing the solicitation during an actual handoff procedure.
実際問題として、oFA SHOULDは、実際の移管手順の間、懇願を実行するのを避けるために知られている隣接しているFAs(セクション3.5を見る)からの広告にあらかじめ請求して、キャッシュします。
3.4.2. Tunneled nFA Advertisements
3.4.2. トンネルを堀られたnFA広告
This applies to the network-initiated target-triggered (L2-TT) case only. Following a target trigger (L2-TT) the nFA MUST send a tunneled Agent Advertisement to the MN through oFA. Tunneling nFA advertisements assumes that the nFA is aware of the IPv4 address for oFA and the MN. These IPv4 addresses are obtained by means of the FA and MN identifiers contained in an L2 trigger received at nFA in the network-initiated case (see Section 3.2). However, in [1] the TTL must be 1 on Agent Advertisements from the nFA. Therefore, tunneling advertisements is applicable if the TTL limitation of [1] is relaxed. For this purpose, a pre-established security association between oFA and nFA MUST be in place to authenticate this message and relax the TTL limitation. If the implementation requires this, a tunnel SHOULD be configured when the inter-FA security association is established. The tunneled ICMP advertisement MUST be secured using tunnel mode ESP [10] between nFA and oFA. An FA MUST NOT accept tunneled ICMP packets destined to it from sources that are not authenticated.
これはネットワークによって開始された目標で引き起こされた(L2-TT)ケースだけに適用されます。 目標引き金(L2-TT)に続いて、nFAはoFAを通してトンネルを堀られたエージェントAdvertisementをミネソタに送らなければなりません。 nFA広告にトンネルを堀るのは、nFAがoFAとミネソタへのIPv4アドレスを意識していると仮定します。 識別子がnFAにネットワークによって開始された場合で受け取られたL2引き金に含んだFAとミネソタによるこれらのIPv4アドレスを得ます(セクション3.2を見てください)。 しかしながら、TTLはnFAからのエージェントAdvertisementsの上の[1]の1歳であるに違いありません。 したがって、[1]のTTL制限が緩和されるなら、広告にトンネルを堀るのは適切です。 このために、このメッセージを認証して、TTL制限を緩和するために、oFAとnFAとのプレ設立されたセキュリティ協会は適所にあるに違いありません。 実現がこれを必要とするなら、相互FAセキュリティ協会が設立されると構成されていて、aはSHOULDにトンネルを堀ります。 トンネルモードのnFAの間の超能力[10]とoFAを使用して、トンネルを堀られたICMP広告を保証しなければなりません。 FA MUST NOTは認証されないソースからそれに運命づけられたトンネルを堀られたICMPパケットを受け入れます。
El Malki, Ed. Experimental [Page 18] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[18ページ]RFC4881低遅延
3.5. Caching Router Advertisements
3.5. ルータ通知をキャッシュします。
In the mobile-initiated (L2-MT) case and the network-initiated source-triggered (L2-ST) case, the message exchange 1 in Figure 1 could impose an additional latency on the L3 handoff process if done as part of the handoff procedure. In order to remove this source of latency, the inter-FA Router (Agent) Solicitation and Advertisement exchange SHOULD be performed in advance of handoff. A process SHOULD be in place at the oFA to solicit its neighboring nFAs at a predefined time interval (MIN_SOLICITATION_INTERVAL). This interval SHOULD NOT be set too small to avoid unnecessary consumption of network bandwidth and nFA processing resources. The minimum value of MIN_SOLICITATION_INTERVAL is 1 second. If the FA Challenge/Response mechanism in [7] is used, then the MIN_SOLICITATION_INTERVAL MUST be set to a value smaller then the window of time in which a challenge remains valid so that the nFA challenge does not expire before the MN issues the Registration Request. Therefore, the recommended default value for the MIN_SOLICITATION_INTERVAL in oFA is (0.5 * nFA's CHALLENGE_WINDOW * nFA's Agent Advertisement interval). The CHALLENGE_WINDOW and Agent Advertisement interval are defined in [7] and [1] respectively. The minimum requirement is that the MIN_SOLICITATION_INTERVAL MUST be manually configurable, while possible autoconfiguration mechanisms are outside the scope of this document. To allow advertisement caching in certain implementations and in cases where the nFA advertisement interval is very small, it MAY be necessary for the implementation in nFA to allow different CHALLENGE_WINDOW and Agent Advertisement interval settings for its nFA-oFA interface.
可動に開始している(L2-MT)場合とネットワークによって開始されたソースによって引き起こされた(L2-ST)場合では、移管手順の一部としてするなら、図1の交換処理1はL3移管の過程に追加潜在を課すかもしれません。 潜在、相互FA Router(エージェント)懇願、およびAdvertisement交換SHOULDのこの源を取り外すには、移管の前に実行されてください。 AはSHOULDを処理します。oFAに適所にあって、事前に定義された時間間隔(MIN_SOLICITATION_INTERVAL)で、隣接しているnFAsに請求してください。 この間隔SHOULD NOT、ネットワーク回線容量の不要な消費とnFA処理リソースを避けることができないくらい小さいセットになってください。 MIN_SOLICITATION_INTERVALの最小値は1秒です。 そして次に、使用される[7]のFA Challenge/反応機構、MIN_SOLICITATION_INTERVAL MUSTが、より小さく値へのセットであるなら、ミネソタがRegistration Requestを発行する前に挑戦が有効なままで残っているのでnFAが挑戦する時間の窓は期限が切れません。 したがって、oFAのMIN_SOLICITATION_INTERVALにおけるお勧めのデフォルト値は(0.5*nFAのCHALLENGE_WINDOW*nFAのエージェントAdvertisement間隔)です。 CHALLENGE_WINDOWとエージェントAdvertisement間隔は[7]と[1]でそれぞれ定義されます。 必要最小限はMIN_SOLICITATION_INTERVAL MUSTが手動で構成可能であるということです、このドキュメントの範囲の外に可能な自動構成メカニズムがありますが。 ある実現とnFA広告間隔が非常に小さい場合における広告キャッシュを許すために、nFAでの実現が異なったCHALLENGE_WINDOWとエージェントAdvertisementにnFA-oFAインタフェースへの間隔設定を許すのが必要であるかもしれません。
The oFA SHOULD cache the most recent advertisement from its neighboring nFAs. This advertisement MUST be sent to the MN in message 2b with a TTL=1. The oFA SHOULD also have a mechanism in place to create a list of neighboring nFAs. The minimum requirement for each FA is that it SHOULD allow manual configuration of a list of nFA addresses that an MN could possibly perform an L3 handoff to. The FA addresses in this list will depend on deployment and radio coverage. It is also possible to specify another protocol to achieve nFA discovery, but this is outside the scope of this document.
oFA SHOULDは隣接しているnFAsからの最新の広告をキャッシュします。 TTL=1とメッセージ2bのミネソタにこの広告を送らなければなりません。 また、oFA SHOULDは、隣接しているnFAsのリストを作成するために適所にメカニズムを持っています。 それはそれです。各FAのための必要最小限、SHOULDはミネソタがL3移管を実行できたnFAアドレスのリストのマニュアル構成を許します。 このリストのFAアドレスは展開とラジオ適用範囲によるでしょう。 また、nFA発見を達成するために別のプロトコルを指定するのも可能ですが、このドキュメントの範囲の外にこれはあります。
3.6. Movement Detection, MN, and FA Considerations
3.6. 動き検出、Mn、およびファ問題
When the MN receives an Agent Advertisement with a Mobility Agent extension, it performs actions according to the following movement detection mechanism: the MN SHOULD be "Eager" to perform new bindings. This means that the MN SHOULD perform registrations with any new FA from which it receives an advertisement (i.e., MN is Eager), as long as there are no locally-defined policies in the MN that discourage the use of the discovered FA. For example, the MN
ミネソタがMobilityエージェント拡張子があるエージェントAdvertisementを受けるとき、以下の動き検出メカニズムによると、動作を実行します: MN SHOULD、「切望する」新しく実行する結合になってください。 これは、MN SHOULDがそれが広告を受け取るどんな新しいFAとの登録証明書も実行することを意味します(すなわち、ミネソタはEagerです)、ミネソタの発見されたFAの使用に水をさしている局所的に定義された方針が全くない限り。 例えば、ミネソタ
El Malki, Ed. Experimental [Page 19] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[19ページ]RFC4881低遅延
could have a policy based on the cost of service. The method by which the MN determines whether the FA is a new FA is described in [1] and MAY use an FA-NAI extension [11]. By being "Eager" to perform registrations, the MN reduces latency times.
方針をサービス生産費に基づかせることができました。 ミネソタがFAが新しいFAであるかどうか決定する方法は、[1]で説明されて、FA-NAI拡張子[11]を使用するかもしれません。 登録証明書を実行することにおいて「切望する」であることによって、ミネソタは待ち時間を減少させます。
The MN also needs to change its default router from oFA to nFA. The MN MUST change its default router to nFA as soon as the PRE- REGISTRATION procedure has completed (i.e., Registration Reply is received by MN) as described in [1].
また、ミネソタは、デフォルトルータをoFAからnFAに変える必要があります。 ミネソタはPRE- REGISTRATION手順がそうしたのと同じくらいすぐ、[1]で説明されるようにデフォルトルータをnFAに完成していた状態で(すなわち、Registration Replyはミネソタによって受け取られます)変えなければなりません。
Overall, the MN behaves as described in [1] with the following changes: the specified movement detection mechanism mentioned above and the ability to use the L2-MT to initiate an Agent Solicitation with a special extension (PrRtSol). Also, when the MN receives an L2-LU trigger (i.e., new interface or link is up), it MUST immediately send an Agent Solicitation [1] on that interface. An nFA that receives an Agent Solicitation [1] will use it as an L2-LU trigger event, and according to [1] it will record the MN's IPv4/layer 2 addresses (i.e., the Address Resolution Protocol (ARP) entry). At that point, the nFA starts delivering data to the MN including the previously buffered Registration Reply. The nFA MAY also use other L2 mechanisms to detect earlier that the MN has attached to the new link and to start forwarding data to it. The MN SHOULD NOT attempt to retransmit a low-latency Registration Request (i.e., Registration Request containing an LLA extension described in Section 9.) when it does not receive the Registration Reply.
全体的に見て、ミネソタは[1]で以下の変化で説明されるように振る舞います: 前記のように指定された動き検出メカニズムと特別な拡大(PrRtSol)を伴うエージェントSolicitationを開始するのにL2-MTを使用する能力。 また、ミネソタがすぐにL2-LU引き金を受けるとき(すなわち、新しいインタフェースかリンクが上がっています)、それはエージェントSolicitation[1]をそのインタフェースに送らなければなりません。 エージェントSolicitation[1]を受けるnFAはL2-LU引き金の出来事としてそれを使用するでしょう、そして、[1]によると、それはミネソタのIPv4/層2のアドレス(すなわち、Address Resolutionプロトコル(ARP)エントリー)を記録するでしょう。 その時、nFAは以前にバッファリングされたRegistration Replyを含むミネソタにデータを届け始めます。 また、データをそれに転送して、nFAは、より早く検出するミネソタが新しいリンクと、そして、始めに取り付けた他のL2メカニズムを使用するかもしれません。 MN SHOULD NOTは、Registration Replyを受けないとき、低遅延Registration Request(すなわち、セクション9で説明されたLLA拡張子を含むRegistration Request)を再送するのを試みます。
When moving from a PRE-REGISTRATION network to a normal Mobile IPv4 [1] network, the MN will no longer receive PrRtAdv messages (i.e., Agent Advertisements with the LLA extension). If the MN still receives L2-MTs, it will attempt to send PrRtSol messages. The normal FA will reply with a normal Agent Advertisement [1]. If the MN does not receive a PrRtAdv in reply to its PrRtSol, it MAY retransmit the PrRtSol message once after PRE_SOL_INTERVAL seconds and then for another PRE_SOL_ATTEMPTS times with exponential backoff of the transmission interval. If a PrRtAdv is not received within PRE_SOL_INTERVAL seconds after the last PrRtSol attempt, the MN MUST stop sending PrRtSol messages until after a registration with a new FA is performed. The default value for PRE_SOL_ATTEMPTS is 2, and for PRE_SOL_INTERVAL, it is 1 second. It should be noted that the performance of the movement detection mechanism mandated in PRE- REGISTRATION (i.e., eager to register) may have sub-optimal behaviour in a standard Mobile IPv4 [1] network. Therefore, standard movement detection mechanisms [1] should be used in plain Mobile IPv4 networks. Instead, when the MN moves from a normal Mobile IPv4 [1] network to a PRE-REGISTRATION network, the MN starts receiving L2-MT triggers or PrRtAdv messages. When the MN receives L2-MT triggers or PrRtAdv messages, it SHOULD follow the PRE-REGISTRATION procedure.
PRE-REGISTRATIONネットワークから正常なモバイルIPv4[1]ネットワークまで動くとき、ミネソタはもう、PrRtAdvメッセージ(すなわち、LLA拡張子があるエージェントAdvertisements)を受け取らないでしょう。 ミネソタがまだL2-MTsを受けていると、それは、メッセージをPrRtSolに送るのを試みるでしょう。 正常なFAは正常なエージェントAdvertisement[1]で返答するでしょう。 ミネソタがPrRtSolに対してPrRtAdvを受けないなら、それはPRE_SOL_INTERVAL秒の後とそして、別のPRE_SOL_ATTEMPTS回数ように一度トランスミッション間隔の指数のbackoffでPrRtSolメッセージを再送するかもしれません。 PrRtAdvが最後のPrRtSol試みのSOL_INTERVAL秒後にPRE_の中に受け取られないなら、ミネソタは、新しいFAとの登録が実行された後までメッセージをPrRtSolに送るのを止めなければなりません。 PRE_SOL_ATTEMPTSのためのデフォルト値は2です、そして、PRE_SOL_INTERVALに関して、それは1秒です。 PRE- REGISTRATION(すなわち、切望している登録するのを)で強制された動き検出メカニズムの性能が標準のモバイルIPv4[1]ネットワークでサブ最適のふるまいを持っているかもしれないことに注意されるべきです。 したがって、標準の動き検出メカニズム[1]は明瞭なモバイルIPv4ネットワークに使用されるべきです。 ミネソタが正常なモバイルIPv4[1]ネットワークからPRE-REGISTRATIONネットワークまで動くとき、代わりに、ミネソタはL2-MT引き金かPrRtAdvメッセージを受け取り始めます。 WhenミネソタはL2-MT引き金かPrRtAdvメッセージを受け取って、それはSHOULDです。PRE-REGISTRATION手順に従ってください。
El Malki, Ed. Experimental [Page 20] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[20ページ]RFC4881低遅延
If there is uncertainty as to which mode to choose (e.g., MN receives messages from both PRE-REGISTRATION and normal FAs), the MN decides based on its registration status with the current FA. If the MN already has a valid normal Mobile IPv4 Registration [1] with the advertising FA, it SHOULD give priority to the PRE-REGISTRATION procedure. Otherwise it SHOULD give priority to normal Mobile IPv4 [1] Registration procedure. The MN SHOULD NOT attempt to perform PRE-REGISTRATION and standard Mobile IPv4 [1] Registrations in parallel.
どのモードを選んだらよいかに関して不確実性があれば(例えば、ミネソタはPRE-REGISTRATIONと正常なFAsの両方からメッセージを受け取ります)、ミネソタは現在のFAがある登録状態に基づいて決めます。 ミネソタには、有効な正常なモバイルIPv4 Registration[1]が広告FAと共に既にあります、それ。SHOULDはPRE-REGISTRATION手順に優先的に取り扱います。 そうでなければ、それ、SHOULDは正常なモバイルIPv4[1]登録手順を最優先させます。 MN SHOULD NOTは、PRE-REGISTRATIONと平行な標準のモバイルIPv4[1]登録証明書を実行するのを試みます。
3.7. L2 Address Considerations
3.7. L2アドレス問題
Some special considerations should be taken with respect to the wireless system on which this handoff method is being implemented. Consider an Ethernet-like system such as IEEE 802.11, for example. In PRE-REGISTRATION, the MN is registering with an FA (nFA) that is not its current first-hop router; therefore, the L2 address of the Ethernet frame containing the MN's Registration Request reaching the nFA is not the MN's address. Therefore, the FA MUST NOT use the Ethernet address of the incoming Registration Request as the MN's L2 address as specified in [1]. This applies to the cases where the wireless access points are bridges or routers and independently of whether the FA is implemented in the wireless access points themselves. In this case, the MN's Registration Request (or Regional Registration Request) MUST use an L2 address extension to the registration message. Such an L2 address is either the same L2 address that remains constant as the MN moves, or it is the MN's L2 address at nFA. To communicate its L2 address, the MN includes a Generalized Link Layer and IP Address Extension (see Section 9) with its Registration Request (or Regional Registration Request) message. If this extension is present, the FA MUST use the L2 address contained in the extension to communicate with the MN. If a particular wireless L2 technology has defined a special interface to the wireless network that allows the FA to resolve the mapping between an MN's IPv4 address and its L2 address without the need to use the extension, the L2 address extension contents may be discarded. For the same reasons above, the MN MUST NOT use the source L2 address of the Agent Advertisement message (PrRtAdv) as its default router's L2 address. Therefore, the nFA MUST include a Generalized Link Layer and IP Address Extension (see Section 9.3) with its Agent Advertisement (PrRtAdv) messages.
この移管方法が実行することにされるのであるワイヤレスシステムに関していくつかの特別な問題を取るべきです。 例えば、IEEE802.11などのイーサネットのようなシステムを考えてください。 PRE-REGISTRATIONでは、ミネソタは現在の最初に、ホップルータでないFA(nFA)とともに記名しています。 したがって、nFAに達するミネソタのRegistration Requestを含むイーサネットフレームのL2アドレスはミネソタのアドレスではありません。 したがって、FA MUST NOTは[1]の指定されるとしてのミネソタのL2アドレスとして入って来るRegistration Requestのイーサネット・アドレスを使用します。 ワイヤレス・アクセスポイントが橋かルータであるところとFAがワイヤレス・アクセスポイント自体で実行されるかどうかの如何にかかわらずこれはケースに適用されます。 この場合、ミネソタのRegistration Request(または、Regional Registration Request)はL2アドレス拡張子を登録メッセージに使用しなければなりません。 ミネソタが動くとき、そのようなL2アドレスは同じL2が記述する一定のままで残っているどちらかかそれがnFAのミネソタのL2アドレスです。 L2アドレスを伝えるために、ミネソタはRegistration Request(または、Regional Registration Request)メッセージでGeneralized Link LayerとIP Address Extensionを含めます(セクション9を見ます)。 この拡大が存在しているなら、FA MUSTはミネソタとコミュニケートするために拡大に含まれたL2アドレスを使用します。 特定の無線のL2技術がFAが拡張子を使用する必要性なしでミネソタのIPv4アドレスとそのL2アドレスの間のマッピングを決議できるワイヤレス・ネットワークと特別なインタフェースを定義したなら、L2アドレス拡大コンテンツは捨てられるかもしれません。 同じ理由のために、上では、ミネソタがデフォルトルータのL2アドレスとしてエージェントAdvertisementメッセージ(PrRtAdv)のソースL2アドレスを使用してはいけません。 したがって、nFAはエージェントAdvertisement(PrRtAdv)メッセージでGeneralized Link LayerとIP Address Extensionを含まなければなりません(セクション9.3を見ます)。
3.8. Applicability of PRE-REGISTRATION Handoff
3.8. プレ登録移管の適用性
The PRE-REGISTRATION handoff method is applicable to scenarios where a period of service disruption due to layer 3 is not acceptable, for example, when performing real-time communications, and therefore where an anticipation of the layer 3 handoff is required. Security
PRE-REGISTRATION移管方法は、瞬時通信を実行するとき例えば層3による勤続期間分裂が許容できないシナリオに適切であり、したがって、層の3移管の予期が必要であるところで適切です。 セキュリティ
El Malki, Ed. Experimental [Page 21] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[21ページ]RFC4881低遅延
for the PRE-REGISTRATION handoff method is based on the same security model as [1] including the use of AAA. A prerequisite for PRE- REGISTRATION is that the FA or MN is able to obtain an L2 trigger informing it of a pending L2 handoff procedure. The target of the L2 handoff is another access point or radio network that is in the coverage area of a new FA. The L2 trigger information may be in the form of identifiers that need to be resolved to IPv4 addresses using methods that may be specific to the wireless network and are not considered here. If, for example, the oFA or MN determines that the IPv4 address of the new FA matches oFA's address, then the PRE- REGISTRATION handoff SHOULD NOT be initiated.
PRE-REGISTRATION移管において、AAAの使用を含んでいて、方法は[1]と同じ機密保護モデルに基づいています。 PRE- REGISTRATIONのための前提条件によるFAかミネソタが未定のL2移管手順についてそれを知らせるL2引き金を入手できるということです。 L2移管の目標は、新しいFAの適用範囲の地域にある別のアクセスポイントかラジオ放送網です。 L2引き金の情報がワイヤレス・ネットワークに特定であるかもしれなく、ここで考えられない方法を使用することでIPv4アドレスに決議される必要がある識別子の形にあるかもしれません。 例えば、oFAかミネソタが、新しいFAマッチoFAのアドレスのIPv4アドレス、次に、PRE- REGISTRATION移管SHOULD NOTが開始されることを決定するなら。
The L2 trigger must allow enough time for the PRE-REGISTRATION handoff procedure to be performed. In many wireless L2 technologies, the L2 handoff procedure involves a number of message exchanges before the effective L2 handoff is performed. For such technologies, PRE-REGISTRATION handoff can be initiated at the beginning of the L2 handoff procedure and completed before the L2 handoff is completed. It is efficient to engineer the network such that this succession of events is ensured.
L2引き金は、十分な時間、PRE-REGISTRATION移管手順が実行されるのを許容しなければなりません。 多くの無線のL2技術に、有効なL2移管が実行される前にL2移管手順は多くの交換処理にかかわります。 そのような技術において、L2移管が終了する前に、PRE-REGISTRATION移管は、L2移管手順の始めに開始されて、終了できます。 ネットワークを設計するのが効率的であるので、出来事のこの継承は確実にされます。
The PRE-REGISTRATION handoff method is applicable in the following cases:
PRE-REGISTRATION移管方法は以下の場合で適切です:
- when the MN has locally defined policies that determine a
preference for one access over another, for example, due to
service cost within the same or different technology, and
therefore where it is necessary to allow the MN to select the
appropriate FA with which to connect.
- ミネソタが局所的に優先を決定する方針を定義したときには、例えばサービスのため個人的には同じであるか異なった技術の中で別のものの上で費用にアクセスして、ミネソタが接続するのが適切であるFAを選択するのを許容するのが必要であるところでしたがって、アクセスしてください。
- when L2 security between the MN and the FA is either not present
or cannot be relied upon to provide adequate security.
- ミネソタとFAの間のL2セキュリティを存在していないか、または十分な安全性を提供するために当てにすることができないとき。
- when the trigger to initiate the handoff is received at the MN.
- ミネソタに移管を開始する引き金を受け取るとき。
In the first case, it is necessary to involve eventual local MN policies in the movement detection procedure as described in Section 3.6.
前者の場合、セクション3.6で説明される動き検出手順に最後のローカルのミネソタ方針にかかわるのが必要です。
El Malki, Ed. Experimental [Page 22] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[22ページ]RFC4881低遅延
4. The POST-REGISTRATION Handoff Method
4. ポスト登録移管方法
The POST-REGISTRATION handoff method uses bidirectional edge tunnels (BETs) or unidirectional tunnels to perform low-latency change in the L2 point of attachment for the MN without requiring any involvement by the MN. Figure 5 illustrates the basic POST-REGISTRATION handoff.
ポスト-REGISTRATION移管方法は、ミネソタのそばでかかわり合いを必要としないでL2接着点の低遅延変化をミネソタに実行するのに双方向の縁のトンネル(BETs)か単方向のトンネルを使用します。 図5は基本的なポスト-REGISTRATION移管を例証します。
+------+
| CN |
+------+
|
...
|
+------+ BET +------+
| aFA |==========| nFA |
+------+ +------+
| wireless link
|
movement +------+
---------> | MN |
+------+
+------+ | CN| +------+ | ... | +------+が賭けられた+------+ | aFA|==========| nFA| +------+ +------+ | 無線のリンク| 動き+------+ --------->| ミネソタ| +------+
Figure 5 - POST-REGISTRATION Concept
図5--ポスト登録概念
Following a successful Mobile IPv4 Registration between MN and oFA, the oFA becomes the mobility anchor point for the MN, called the anchor FA (aFA). When the MN moves from oFA to nFA, rather than performing signaling over the wireless link to register with the nFA, the MN can defer the L3 handoff and continue to use its aFA (i.e., oFA in this case). If the MN moves to a third FA before registering with the nFA, in certain cases described later, the third FA signals aFA to move the wireless link end of the BET from nFA to it. The network end of the BET remains anchored at aFA until the MN performs the Mobile IPv4 Registration.
アンカーFA(aFA)は、ミネソタとoFAの間のうまくいっているモバイルIPv4 Registrationに続いて、oFAがミネソタへの移動性アンカー・ポイントになると呼びました。 ミネソタが無線のリンクの上にnFAとともに記名すると合図しながら働くよりoFAからnFAまでむしろ動くとき、ミネソタは、L3移管を延期して、aFA(すなわち、この場合、oFA)を使用し続けることができます。 nFAとともに記名する前にミネソタが第3のFAに動くなら、後で説明されたある場合では、第3FAは、nFAからそれまでBETの無線のリンク端を動かすようにaFAに合図します。 BETのネットワーク端はミネソタがモバイルIPv4 Registrationを実行するまでaFAに据えつけられたままで残っています。
Messages between oFA/aFA and nFA MUST be authenticated. The minimal requirement is that all FAs involved in low-latency handoffs MUST support manual pre-configuration of security associations with other neighboring FAs, involving shared keys and the default algorithms of [1]. POST-REGISTRATION FAs MUST implement the inter-FA authentication extension (FA-FA authentication extension) specified in [11] and MAY additionally use other security mechanisms.
oFA/aFAとnFAの間のメッセージを認証しなければなりません。 最小量の要件は低遅延handoffsにかかわるすべてのFAsが他の隣接しているFAsとのセキュリティ協会の手動のプレ構成を支持しなければならないということです、[1]の共有されたキーとデフォルトアルゴリズムにかかわって。 ポスト-REGISTRATION FAsは[11]で指定された相互FA認証拡張子(FA-FA認証拡張子)を実行しなければならなくて、さらに、他のセキュリティー対策を使用するかもしれません。
El Malki, Ed. Experimental [Page 23] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[23ページ]RFC4881低遅延
4.1. Two-Party Handoff
4.1. 2パーティの移管
Two-party handoff occurs when the MN moves from oFA to nFA. Normally, this movement would result in a new Mobile IPv4 Registration at nFA. However, in POST-REGISTRATION, the MN and nFA MAY delay this but maintain connectivity using the BET (or alternatively unidirectional tunnel) between oFA and nFA. The protocol is shown in Figure 6.
ミネソタがoFAからnFAまで動くと、2パーティーの移管は起こります。 通常、この動きはnFAで新しいモバイルIPv4 Registrationをもたらすでしょう。 しかしながら、ポスト-REGISTRATIONでは、ミネソタとnFAは、これを遅らせますが、接続性使用がoFAとnFAの間のBET(または、あるいはまた、単方向のトンネル)であることを支持するかもしれません。 プロトコルは図6に示されます。
1a) L2-ST ~~~~> +------+ 2) HRqst +------+ <~~~ 1b) L2-TT
| oFA |<-------->| nFA |
4a) L2-LD~> +------+ 3) HRply +------+ <~~~ 4b) L2-LU
^ ^
old L2 | | new L2
+-------+ +-----+
| |
| |
V V
+------+ movement
4c) L2-LU ---> | MN | --------->
+------+
1a) L2、第-~~~~>+------+ 2) HRqst+------+ <。~~~ 1b) L2-TT| oファ| <、-、-、-、-、-、-、--、>| nFA| 4a) L2-LD~>+------+ 3) HRply+------+ <。~~~ 4b) ^ ^の古いL2-LU L2| | 新しいL2+-------+ +-----+ | | | | +に対するV------+運動4c) L2-Lu--->| ミネソタ| --------->+------+
Figure 6 - Two-Party Handoff (POST-REGISTRATION)
図6--2パーティの移管(ポスト登録)
The following describes the progress of a two-party handoff. The numbered items refer to steps in Figure 6. The source-triggered HRqst/HRply message for tunnel creation, the target-triggered HRqst/HRply message for tunnel creation, and the HRqst/HRply to extend or terminate a BET (or unidirectional tunnel) are identified using the suffixes (s), (t), and (r), respectively.
以下は2パーティーの移管の進歩について説明します。 番号付の項目は図6におけるステップを示します。 トンネル創造へのソースによって引き起こされたHRqst/HRplyメッセージ、トンネル創造への目標で引き起こされたHRqst/HRplyメッセージ、およびBET(または、単方向のトンネル)を広げているか、または終えるHRqst/HRplyは、それぞれ接尾語、(t)、および(r)を使用することで特定されます。
1) Either the oFA or nFA receives an L2 trigger informing it that
a certain MN is about to move from oFA to nFA. The two cases
are:
1) oFAかnFAのどちらかが、あるミネソタがoFAからnFAまで動こうとしていることをそれに知らせるL2引き金を受けます。 2つのケースは以下の通りです。
a) The L2 trigger is a source trigger (L2-ST) at oFA. The
trigger contains the MN's L2 address and an identifier for
the nFA (the IPv4 address itself or an L2 address that can
be resolved to the IPv4 address of the nFA).
a) L2引き金はoFAのソース引き金の(L2-ST)です。 引き金はnFA(nFAのIPv4アドレスに決議できるIPv4アドレス自体かL2アドレス)のためのミネソタのL2アドレスと識別子を含んでいます。
b) The L2 trigger is a target trigger (L2-TT) at nFA. The
trigger contains the MN's L2 address and an identifier for
the oFA (the IPv4 address itself or an L2 address that can
be resolved to the IPv4 address of the oFA).
b) L2引き金はnFAの目標引き金(L2-TT)です。 引き金はoFA(oFAのIPv4アドレスに決議できるIPv4アドレス自体かL2アドレス)のためのミネソタのL2アドレスと識別子を含んでいます。
2) The FA receiving the trigger sends a Handoff Request (HRqst) to
the other FA. There are two cases:
2) 引き金を受けるFAはHandoff Request(HRqst)をもう片方のFAに送ります。 2つのケースがあります:
El Malki, Ed. Experimental [Page 24] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[24ページ]RFC4881低遅延
a) If oFA is sending the HRqst, the H bit is set and the N bit
is unset, indicating it is an HRqst(s). The HRqst(s)
contains the lifetime of the tunnel the oFA is willing to
support, the MN's IPv4 home address, the MN's HA address,
and an LLA option with the MN's L2 address. If the lifetime
is zero and the T bit is not set, the oFA is not willing to
tunnel any packets for MN. A positive lifetime and a set T
bit indicate that the oFA is willing to tunnel for the
indicated time. Section 4.5 describes the HRqst(s) and
Section 9 describes the LLA option.
a) oFAがHRqstを送るなら、Hビットは設定されます、そして、Nビットはunsetです、それがHRqst(s)であることを示して。 HRqst(s)はミネソタのL2アドレスによるoFAが支えても構わないと思っているトンネルの生涯、ミネソタのIPv4ホームアドレス、ミネソタのHAアドレス、およびLLAオプションを含んでいます。 寿命がゼロであり、Tビットが設定されないなら、oFAはどんなパケットにもミネソタにトンネルを堀ることを望んでいません。 積極的な生涯、セットTビットは、oFAが、示された時にトンネルを堀っても構わないと思っているのを示します。 セクション4.5はHRqst(s)について説明します、そして、セクション9はLLAオプションについて説明します。
b) If nFA is sending the HRqst, the N bit is set and the H bit
is unset, indicating that it is an HRqst(t). If the T bit
is set, nFA has requested a reverse tunnel and the HRqst(t)
contains the lifetime of the tunnel the nFA is requesting.
The HRqst(t) also contains an LLA option with the MN's L2
address. The MN's IPv4 home address and HA address are not
sent, unless they are discovered by some means outside the
scope of this document (for example, as part of the L2-TT).
Section 4.5 describes the HRqst(t).
b) nFAがHRqstを送るなら、Nビットは設定されます、そして、Hビットはunsetです、それがHRqst(t)であることを示して。 Tビットが設定されるなら、nFAは、逆のトンネルとHRqst(t)がnFAが要求しているトンネルの生涯を含むよう要求しました。 また、HRqst(t)はミネソタのL2アドレスによるLLAオプションを含んでいます。 ミネソタのIPv4ホームアドレスとHAアドレスは送られません、それらがどうでもこのドキュメント(例えばL2-TTの一部として)の範囲の外で発見されない場合。 セクション4.5はHRqst(t)について説明します。
3) The FA receiving the HRqst sends a Handoff Reply (HRply) to the
other FA. There are two cases:
3) HRqstを受けるFAはHandoff Reply(HRply)をもう片方のFAに送ります。 2つのケースがあります:
a) If oFA is sending the HRply, the N bit is set and the H and
R bits are unset, indicating that the reply is in response
to a HRqst(t), i.e., it is an HRply(t). If the T bit is
set, the HRply(t) contains the tunnel lifetime the oFA is
willing to provide; otherwise, the tunnel lifetime is set to
zero indicating that the oFA is not willing to provide
tunnel service. If both HRply(t) and HRqst(t) have the T
bit set and non-zero lifetime, a BET is established. The
HRply(t) also contains the MN's home subnet IPv4 address,
the MN's HA address, and an LLA option containing the MN's
L2 address. Section 4.6 describes the HRply(t).
a) oFAがHRplyを送るなら、Nビットは設定されます、そして、HとRビットはunsetです、回答がHRqst(t)に対応していて、すなわち、それがHRply(t)であることを示して。 Tビットが設定されるなら、HRply(t)はトンネルを含んでいます。oFAが望んでいる寿命は提供されます。 そうでなければ、生涯にトンネルを堀ってください、oFAがトンネルサービスを提供することを望んでいないのを示さないのに設定されます。 HRply(t)とHRqst(t)の両方にT噛み付いているセットと非ゼロ寿命があるなら、BETは設立されます。 また、HRply(t)はミネソタの家のサブネットIPv4アドレス、ミネソタのHAアドレス、およびミネソタのL2アドレスを含むLLAオプションを含んでいます。 セクション4.6はHRply(t)について説明します。
b) If nFA sends the HRply, the H bit is set and the N and R
bits are unset, indicating that this is a response to
HRqst(s), i.e., it is an HRply(s). If the T bit is set, the
nFA indicates that it requests a reverse tunnel, and the
lifetime field is set with the requested tunnel lifetime.
The T bit can be set in HRply only if the oFA had set the T
bit in the corresponding HRqst or if the nFA is required to
reverse tunnel incoming packets to oFA because ingress
filtering is enabled on its network. This establishes a
BET. The tunnel lifetime requested by the nFA must be less
than or equal to the tunnel lifetime offered by oFA in the
HRqst(s). Section 4.6 describes the HRply(s).
b) nFAがHRplyを送って、Hビットが設定されて、これがHRqst(s)への応答であることを示して、NとRビットがunsetであるなら、すなわち、それはHRply(s)です。 Tビットが設定されるなら、nFAは、逆のトンネルを要求するのを示します、そして、生涯分野は要求されたトンネルで生涯を決めることです。 イングレスフィルタリングがネットワークで可能にされるのでoFAが対応するHRqstかそれともnFAが逆にならなければならないかどうかでTが噛み付いたセットを入って来るパケットにoFAにトンネルを堀らせた場合にだけ、HRplyにTビットを設定できます。 これはBETを設立します。 トンネルはnFAによる寿命が、要求した寿命がHRqst(s)のoFAで提供したよりトンネル以下であるに違いありません。 セクション4.6はHRply(s)について説明します。
El Malki, Ed. Experimental [Page 25] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[25ページ]RFC4881低遅延
4) The point during the L2 handoff in which the MN is no longer
connected on a given link is signaled by an L2-LD trigger at
oFA and MN. Completion of L2 handoff is signaled by an L2-LU
trigger at nFA and MN. The trigger is handled as follows:
4) ミネソタがもう与えられたリンクにつなげられないL2移管の間の時点はoFAとミネソタでL2-LD引き金によって合図されます。 L2移管の完成はnFAとミネソタでL2-LU引き金によって合図されます。 引き金は以下の通り扱われます:
a) When oFA receives the L2-LD trigger, it begins forwarding
MN-bound packets through the forward tunnel to nFA.
a) oFAがL2-LD引き金を受けるとき、それは前進のトンネルを通してミネソタ行きのパケットをnFAに送り始めます。
b) When the nFA receives the L2-LU trigger, it begins
delivering packets tunneled from oFA to MN and forwards
outbound packets from MN using normal routing mechanisms or
through a reverse tunnel to oFA or HA. The nFA at this
point may not yet be the default router of the MN (see
Section 4.4); therefore, to receive all outbound packets
from the MN the nFA must send a unicast proxy ARP message
(used in [1]) to the MN upon receiving an L2-LU trigger.
This proxy ARP message is an ARP Reply [5] sent by the nFA
on behalf of oFA, therefore supplying the nFA link-layer
address in the Sender Hardware Address field and the oFA
IPv4 address in the Target Protocol Address field.
b) nFAがL2-LU引き金を受けるとき、それは、oFAかHAにoFAからミネソタまでトンネルを堀られたパケットを届け始めて、正常なルーティングメカニズムを使用するミネソタ、または、逆のトンネルを通して外国行きのパケットを送ります。 ここのnFAはまだミネソタのデフォルトルータでないかもしれません(セクション4.4を見てください)。 したがって、ミネソタからすべての外国行きのパケットを受けるために、nFAはユニキャストプロキシARPメッセージを送らなければなりません。([1])では、L2-LU引き金を受けるとき、ミネソタに使用されています。 このプロキシARPメッセージはoFAを代表してnFAによって送られたARP Reply[5]です、したがって、Sender Hardware Address分野のnFAリンクレイヤアドレスとTargetプロトコルAddress分野のoFA IPv4アドレスを供給します。
c) When the MN receives the L2-LU, it MAY initiate the Mobile
IPv4 Registration process by soliciting an Agent
Advertisement as described in [1]. If the registration is
successful, the nFA takes over the role of anchor FA (aFA)
from the oFA. Alternatively, the MN MAY defer the Mobile
IPv4 Registration (see Section 4.4).
c) ミネソタがL2-LUを受けるとき、[1]で説明されるようにエージェントAdvertisementに請求することによって、それはモバイルIPv4 Registrationの過程に着手するかもしれません。 登録がうまくいくなら、nFAはoFAからアンカーFA(aFA)の役割を引き継ぎます。 あるいはまた、ミネソタはモバイルIPv4 Registrationを延期するかもしれません(セクション4.4を見てください)。
5) The oFA becomes an aFA if the MN moves to a third FA before
having performed a Mobile IPv4 Registration with nFA.
5) nFAと共にモバイルIPv4 Registrationを実行する前にミネソタが第3のFAに動くなら、oFAはaFAになります。
6) Should L2 handoff fail in Step 4 (due to L2 reasons) and a
ping-pong situation arise, the oFA may be able to determine
this case through the trigger mechanism (i.e., FA sees
successive L2-ST/L2-TT followed by L2-LD and then L2-LU). The
FA that originated the HRqst can in this case cancel the tunnel
by sending an HRqst(r) to the other FA with lifetime zero. It
will then simply continue delivering packets to MN exactly as
if no handoff had been pending. Section 4.5 describes the
HRqst(r).
6) L2移管がStep4(L2理由による)とピンポン状況に失敗するなら、起こってください、そして、oFAはトリガー機構を通した本件を決定してもよいです(すなわち、FAは、連続したL2-ST/L2-TTがL2-LDと次に、L2-LUによって続かれているのを見ます)。 HRqstを溯源したFAは、この場合生涯ゼロでもう片方のFAにHRqst(r)を送ることによって、トンネルを取り消すことができます。 そして、それは、まるでちょうどどんな移管も未定でなかったかのように単にパケットをミネソタに届け続けるでしょう。 セクション4.5はHRqst(r)について説明します。
If the oFA sets the B bit in HRqst/HRply and the nFA has not requested a reverse tunnel by setting the T bit, the nFA SHOULD tunnel outgoing packets from the MN to the HA because the MN has requested this service from the oFA. The nFA SHOULD offer this service only if no security between the nFA and the MN's HA is required, or if there is an existing nFA-HA security association.
oFAがBビットをHRqst/HRplyにはめ込んで、nFAがTビットを設定することによって逆のトンネルを要求していないなら、ミネソタがoFAからこのサービスを要求したので、nFA SHOULDはミネソタからHAまで出発しているパケットにトンネルを堀ります。 nFAとミネソタのHAの間のセキュリティは全く単に必要でない、または既存のnFA-HAセキュリティ協会があれば、nFA SHOULDがこのサービスを提供します。
El Malki, Ed. Experimental [Page 26] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[26ページ]RFC4881低遅延
The actual timing of BET or unidirectional tunnel placement depends on the available L2 triggers. The forward tunnel from oFA to nFA is constructed using one of the tunneling procedures described in [1] for the HA to FA tunnel with the difference that the ends of the tunnel are at the oFA and nFA, respectively. The reverse tunnel from nFA to oFA is constructed as described in [3] with the difference that the network end of the tunnel is at the oFA instead of the HA. If both forward and reverse tunnels are established, then a BET has been established. With optimal L2 trigger information, as described above, the FAs can set up the BET immediately when the L2 handoff is initiated, start tunneling MN-bound data when the link to the MN goes down, and the nFA can use the link-up trigger to start delivering packets. In the absence of optimal L2 trigger information, the HRply can act as the trigger to start tunneling MN-bound data, but in this case, the period of packet delivery disruption to the MN could still be present and additional measures may be required to provide uninterrupted service. Particular implementation and deployment scenarios could require techniques to smooth the handoff by providing a means to convey packets arriving during the L2 handoff. The exact techniques are outside the scope of this document.
BETか単方向のトンネルプレースメントの実際のタイミングは利用可能なL2引き金に依存します。 前進のoFAからnFAまでのトンネルは、HAにそれぞれトンネルの端がoFAとnFAにある違いがあるFAトンネルに[1]で説明されたトンネリング手順の1つを使用することで建築されます。 逆のnFAからoFAまでのトンネルは[3]でトンネルのネットワーク端がHAの代わりにoFAにある違いで説明されるように建築されます。 前進のものと同様に逆のトンネルが確立されるなら、BETは設立されました。 L2移管がすぐ開始されるときFAsが上で説明されるとしてBETに設定できる最適のL2引き金の情報と共に、ミネソタへのリンクが落ちるときにはミネソタ行きのデータにトンネルを堀り始めてください。そうすれば、nFAは、パケットを届け始めるためにリンク上がっている引き金を使用できます。 この場合ミネソタのパケット配信分裂の一区切りはまだ存在しているかもしれません、そして、最適のL2引き金の情報がないとき、HRplyはミネソタ行きのデータにトンネルを堀り始めるために引き金として機能できますが、追加措置が、とぎれないサービスを提供するのに必要であるかもしれません。 特定の実現と展開シナリオは、L2移管の間に到着するパケットを運ぶ手段を提供することによって移管を整えるためにテクニックを必要とするかもしれません。 このドキュメントの範囲の外に正確なテクニックがあります。
Figures 7 and 8 show timing diagrams for source trigger (L2-ST) and target trigger (L2-TT) two-party handoffs, respectively.
数字7と8はソースの引き金(L2-ST)と目標引き金(L2-TT)の2パーティーのhandoffsのためにそれぞれタイムチャートを示しています。
MN nFA oFA
| | |
| | HRqst(s) |<~~~ L2-ST
| |<------------------|
| | HRply(s) |
| |------------------>|
| | |
--------------------------------------------<~~~ L2-LD
L2 Handoff
--------------------------------------------<~~~ L2-LU
| | |
|<------------------->| |
| MN's traffic | |
ミネソタnFA oFA| | | | | HRqst(s)|<~~~ L2、第-| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| HRply(s)| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| --------------------------------------------<~~~ L2-LD L2移管--------------------------------------------<~~~ L2-Lu| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| ミネソタの交通| |
Figure 7 - Two-Party Source Trigger Handoff Timing
図7--2パーティのソース引き金の移管タイミング
El Malki, Ed. Experimental [Page 27] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[27ページ]RFC4881低遅延
MN nFA oFA
| | |
| L2-TT ~~~>| HRqst(t) |
| |------------------>|
| | HRply(t) |
| |<------------------|
| | |
--------------------------------------------<~~~ L2-LD
L2 Handoff
--------------------------------------------<~~~ L2-LU
| | |
|<------------------->| |
| MN's traffic | |
ミネソタnFA oFA| | | | L2-TT~~~>| HRqst(t)| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| HRply(t)| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| --------------------------------------------<~~~ L2-LD L2移管--------------------------------------------<~~~ L2-Lu| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| ミネソタの交通| |
Figure 8 - Two-Party Target Trigger Handoff Timing
エイト環--2パーティの目標引き金の移管タイミング
Once the tunnel between aFA and the current FA is in place, it is torn down by one of the following events:
aFAと現在のFAの間のトンネルが適所にいったんあると、以下の出来事の1つでそれを取りこわします:
1) The aFA decides to stop tunneling because the lifetime it sent
expires and was not renewed, or the aFA or current FA decide to
terminate tunnel service prematurely for some other reason
(refer to Section 4.3).
1) aFAは、早まってある他の理由でサービスにトンネルを堀る(セクション4.3を参照する)ようにそれが送った寿命が期限が切れて、更新されなかったか、またはaFAか現在のFAが、終わると決めるのでトンネルを堀る停止に決めます。
2) The MN completes the process by performing a Mobile IPv4
Registration with the current FA. This may be initiated by the
FA that sends an Agent Advertisement or by the MN that solicits
for an Agent Advertisement as in [1].
2) ミネソタは、現在のFAと共にモバイルIPv4 Registrationを実行することによって、過程を完了します。 これはエージェントAdvertisementを送るFAか[1]のようにエージェントAdvertisementを請うミネソタによって開始されるかもしれません。
3) The MN moves to a third FA (see Section 4.2)
3) ミネソタは第3のFAに動きます。(セクション4.2を見ます)
4.2. Three-Party Handoff
4.2. 3パーティの移管
Three-party handoff is applicable when an MN, which has already established an aFA and is receiving tunneled packets through its current FA, moves to a new FA without performing a Mobile IPv4 Registration.
ミネソタ(既にaFAを設立して、現在のFAを通してトンネルを堀られたパケットを受けている)がモバイルIPv4 Registrationを実行しないで新しいFAに動くとき、3パーティーの移管は適切です。
The need for the three-party handoff function depends on the wireless system in which POST-REGISTRATION is being implemented. For radio L2 protocols in which it is possible for the MN to move so rapidly from one FA to another such that a probability exists that the Mobile IPv4 Registration with nFA will not complete before the MN moves on, HTT (Handoff to Third) SHOULD be implemented. Certain wireless systems and implementations do not allow such fast movement between FAs and may force the Mobile IPv4 Registration to occur soon after L2 handoff, in which case three-party handoff is not applicable. If this three-party handoff feature is not implemented, the FA SHOULD
3パーティーの移管機能の必要性はポスト-REGISTRATIONが実行されているワイヤレスシステムによります。 ミネソタが運動するのが、可能であるラジオL2プロトコルには、あまりに確率が存在しているようなnFAとモバイルIPv4 Registrationがミネソタの前に完成しないものがオンHTT(Thirdへの移管)SHOULDを動かすほど急速に1FAから別のFAまで実行されてください。 ワイヤレスシステムと実現でFAsの間のそのような速い運動を許さないで、モバイルIPv4 RegistrationがL2移管のすぐ後にやむを得ず起こるかもしれないのを確信しています、その場合、3パーティーの移管は適切ではありません。 この3パーティーの移管機能が実行されないならFA SHOULD
El Malki, Ed. Experimental [Page 28] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[28ページ]RFC4881低遅延
send an Agent Advertisement to the MN after L2 handoff has completed (L2-LU at nFA) and/or the MN SHOULD solicit an Agent Advertisement after L2 handoff (L2-LU at MN).
L2移管が(nFAのL2-LU)を完成した後にエージェントAdvertisementをミネソタに送ってください、そして、MN SHOULDはL2移管(ミネソタのL2-LU)の後にエージェントAdvertisementに請求します。
+------+
+--->| aFA |<---+
| +------+ |
4b) HRqst(r) | | 3) HRqst(t)
HRply(r) | | HRply(t)
| |
v 2a) HRqst v
1a) L2-ST ~~~> +------+ HTT +------+ <~~~ 1b) L2-TT
| oFA |<-------->| nFA |
4a) L2-LD ~~~> +------+ 2b) HTT +------+ <~~~ 5a) L2-LU
^ HRply ^
old L2 | | new L2
+-------+ +-----+
| |
| |
V V
+------+ movement
5b) L2-LU ~~~> | MN | --------->
+------+
+------+ +--->| aFA| <、-、--+ | +------+ | 4b) HRqst(r) | | 3) HRqst(t) HRply(r) | | HRply(t) | | 2a)に対して HRqst対1a) L2、第-~~~>+------+ HTT+------+ <。~~~ 1b) L2-TT| oファ| <、-、-、-、-、-、-、--、>| nFA| 4a) L2-LD~~~>+------+2b) HTT+------+ <。~~~ 5a) ^の古いL2-LU^HRply L2| | 新しいL2+-------+ +-----+ | | | | +に対するV------+運動5b) L2-Lu~~~>| ミネソタ| --------->+------+
Figure 9 - Three-Party Handoff
図9--3パーティの移管
The L3 handoff can be deferred either because of a decision by the MN/FA (i.e., MN does not send Agent Solicitations and FA does not send Agent Advertisements), or it may result from rapid movement between oFA and nFA that does not allow enough time for the registration to complete. This scenario is shown in Figure 9. In this case, oFA must inform nFA (i.e., the third FA) to contact aFA about moving the radio end of the tunnel. This is performed with the HTT message. The general idea behind the three-party handoff procedure is that the oFA supplies nFA with the same information it would have obtained via an L2-TT if handoff had occurred from aFA to nFA; then, the nFA performs an HRqst(t)/HRply(t) sequence with aFA in order to move the BET to nFA. When the L2 handoff is complete, oFA sends an HRqst(r) to aFA to terminate the previous BET.
ミネソタ/FAによる決定のためにL3移管を延期できますか(すなわち、ミネソタはエージェントSolicitationsを送りません、そして、FAはエージェントAdvertisementsを送りません)、またはそれはoFAとnFAの間の十分な時間終了する登録を考慮しない急速な運動から生じるかもしれません。 このシナリオは図9に示されます。 この場合、oFAは、トンネルのラジオ端を動かすことに関してaFAに連絡するためにnFA(すなわち、第3FA)に知らせなければなりません。 これはHTTメッセージで実行されます。 3パーティーの移管手順の後ろの概念は移管がaFAからnFAまで起こったならoFAがそれがL2-TTを通して得た同じ情報をnFAに供給するということです。 そして、nFAは、BETをnFAに動かすためにaFAと共にHRqst(t)/HRply(t)系列を実行します。 L2移管が完全であるときに、oFAは、前のBETを終えるためにHRqst(r)をaFAに送ります。
The following describes the progress of a three-party handoff. The numbered items refer to steps in Figure 9.
以下は3パーティーの移管の進歩について説明します。 番号付の項目は図9におけるステップを示します。
1) Either the oFA or nFA receives an L2 trigger informing it that
a certain MN is about to be moved. The two cases are:
1) oFAかnFAのどちらかが、あるミネソタが動かされようとしていることをそれに知らせるL2引き金を受けます。 2つのケースは以下の通りです。
El Malki, Ed. Experimental [Page 29] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[29ページ]RFC4881低遅延
a) The L2 trigger is a source trigger (L2-ST) at oFA. The
trigger contains the MN's L2 address and an identifier for
the nFA (the IPv4 address itself or an L2 address that can
be mapped to the IPv4 address of the nFA).
a) L2引き金はoFAのソース引き金の(L2-ST)です。 引き金はnFA(nFAのIPv4アドレスに写像できるIPv4アドレス自体かL2アドレス)のためのミネソタのL2アドレスと識別子を含んでいます。
b) The L2 trigger is a target trigger (L2-TT) at nFA. The
trigger contains the MN's L2 address and an identifier for
the oFA (the IPv4 address itself or an L2 address that can
be resolved to the IPv4 address of the oFA).
b) L2引き金はnFAの目標引き金(L2-TT)です。 引き金はoFA(oFAのIPv4アドレスに決議できるIPv4アドレス自体かL2アドレス)のためのミネソタのL2アドレスと識別子を含んでいます。
2) The oFA and nFA exchange an HTT/HRply or HRqst/HTT pair. HTT
is indicated by setting both the H and N bits in the HRqst or
HRply. The HTT message MUST NOT have any tunnel flag bits set,
because the tunnel is negotiated between the aFA and nFA, not
oFA and nFA. There are two cases:
2) oFAとnFAはHTT/HRplyかHRqst/HTT組を交換します。 HTTは、HとNビットの両方をHRqstかHRplyにはめ込むことによって、示されます。 HTTメッセージでどんなトンネルフラグビットも設定してはいけません、トンネルがoFAとnFAではなく、aFAとnFAの間で交渉されるので。 2つのケースがあります:
a) The L2 trigger is an L2-ST. The oFA sends HTT to nFA
containing the MN's home IPv4 address, the MN's HA address,
an LLA containing the aFA's IPv4 address, and an LLA
containing the L2 address of the MN. This is enough
information for nFA to perform a target-triggered handoff
with aFA. The nFA responds with an HRply(s). Section 4.7
describes the HTT.
a) L2引き金はL2-STです。oFAはミネソタの家のIPv4アドレス、ミネソタのHAアドレス、aFAのIPv4アドレスを含むLLA、およびミネソタのL2アドレスを含むLLAを含むnFAにHTTを送ります。 これはnFAがaFAとの目標で引き起こされた移管を実行できるくらいの情報です。 nFAはHRply(s)と共に応じます。 セクション4.7はHTTについて説明します。
b) The L2 trigger is an L2-TT. The nFA sends HRqst(t) to oFA,
exactly as if a two-party handoff were occurring. The oFA
responds with HTT containing the same information as in a)
above. This is enough information for nFA to perform a
target-triggered handoff with aFA.
b) L2引き金はL2-TTです。 まるでちょうど2パーティーの移管が起こっているかのようにnFAはHRqst(t)をoFAに送ります。 HTTがa)のように同じ情報を含んでいて、oFAは上で応じます。 これはnFAがaFAとの目標で引き起こされた移管を実行できるくらいの情報です。
3) Upon receipt of the HTT, the nFA first checks its Visitor Cache
to see whether it is already tunneling for MN. If so, Step 6
is performed. If not, nFA performs a target-triggered handoff
with aFA, exactly as in Section 4.1, exchanging an
HRqst(t)/HRply(t) pair. Because aFA receives no L2 trigger
indicating when L2 handoff starts, it may start tunneling to
nFA upon transmission of the HRply(t).
3) HTTを受け取り次第、nFAは、最初に、それが既にミネソタにトンネルを堀っているかどうかを見るためにVisitor Cacheをチェックします。 そうだとすれば、Step6は実行されます。 そうでなければ、HRqst(t)/HRply(t)組を交換して、nFAはちょうどセクション4.1のようにaFAとの目標で引き起こされた移管を実行します。 aFAがL2移管がいつ始まるかを示すL2引き金を全く受けないので、それは、HRply(t)のトランスミッションのときにnFAにトンネルを堀り始めるかもしれません。
4) Once the L2 handoff is under way and the MN gets disconnected
at L2, aFA and oFA exchange messages canceling tunnel service
between aFA and oFA and allowing aFA to start the tunnel with
nFA.
4) かつて、L2移管は進行中です、そして、ミネソタはL2、aFA、およびaFAとoFAの間のトンネルサービスを中止して、aFAがnFAからトンネルを始動するのを許容するoFA交換メッセージで外されます。
a) The point in the L2 handoff process where the MN gets
disconnected from oFA is signaled at oFA by L2-LD.
a) ミネソタがoFAから外されるL2移管の過程によるポイントはoFAでL2-LDによって合図されます。
El Malki, Ed. Experimental [Page 30] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[30ページ]RFC4881低遅延
b) The oFA exchanges an HRqst(r)/HRply(r) pair having lifetime
zero with aFA. This cancels tunnel service between oFA and
aFA. If aFA has not already established a tunnel to nFA, it
must do so immediately upon receipt of the HRqst(r). The
aFA provides tunneling service exactly as described in
Section 4.1, Step 4a.
b) oFAは生涯ゼロを持っているHRqst(r)/HRply(r)組をaFAと交換します。 これはoFAとaFAの間のトンネルサービスを中止します。 aFAが既にトンネルをnFAに確立していないなら、それはそれほどすぐに、HRqst(r)を受け取り次第しなければなりません。 Step 4a、aFAはちょうどセクション4.1で説明されるようにトンネリングサービスを提供します。
5) Completion of L2 handoff is signaled by an L2-LU trigger at nFA
and/or MN. The nFA and MN handle the trigger as follows:
5) L2移管の完成はnFA、そして/または、ミネソタでL2-LU引き金によって合図されます。 nFAとミネソタは以下の引き金を扱います:
a) The nFA provides packet delivery service to the MN exactly
as described in Section 4.1, Step 4b.
a) Step 4b、nFAはちょうどセクション4.1で説明されるようにミネソタへのパケットデリバリ・サービスを提供します。
b) The MN either defers or initiates Mobile IPv4 Registration
when it receives the L2-LU, as in Section 4.1.
b) L2-LUを受けるとき、ミネソタは、セクション4.1のようにモバイルIPv4 Registrationを延期するか、または開始します。
6) In the special case where nFA and aFA are the same (i.e., the
MN is moving back to the original anchor FA), aFA recognizes
that it is tunneling to oFA when it checks its Visitor Cache in
Step 3. In this case, there is no need for aFA to send the
HRqst(t)/HRply(t) in Step 3. Upon receipt of the L2-LU trigger
on handoff completion, the aFA begins routing packets to MN and
the tunnel to nFA is torn down. The oFA still exchanges the
HRqst(r)/HRply(r) with aFA in Step 4b because oFA cannot know a
priori that aFA and nFA are the same, but they are redundant.
6) nFAとaFAが同じである(すなわち、ミネソタはオリジナルのアンカーFAに戻る予定です)特別な場合では、aFAは、Step3でVisitor Cacheをチェックするとき、それがoFAにトンネルを堀っていると認めます。 この場合、aFAがStep3でHRqst(t)/HRply(t)を送る必要は全くありません。 移管完成でのL2-LU引き金を受け取り次第、aFAはパケットをミネソタに発送し始めます、そして、nFAへのトンネルを取りこわします。 oFAが、aFAとnFAが同じであることを先験的に知ることができないので、oFAはまだStep 4bのaFAとHRqst(r)/HRply(r)を交換していますが、それらは余分です。
El Malki, Ed. Experimental [Page 31] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[31ページ]RFC4881低遅延
Figures 10 and 11 show timing diagrams for source trigger (L2-ST) and target trigger (L2-TT) three-party handoff, respectively.
数字10と11はソース引き金の(L2-ST)と目標引き金(L2-TT)の3パーティーの移管のためにそれぞれタイムチャートを示しています。
MN nFA oFA aFA
| | L2-ST ~~~> | |
| | | |
| |<-------------| |
| | HTT | |
| |------------->| |
| | HRply(s) | |
| |------------------------------>|
| | HRqst(t) | |
| |<------------------------------|
| | HRply(t) | |
| | | |
----------------------------------<~~~ L2-LD |
|--------------->|
L2 Handoff | HRqst(r) |
| |
|<---------------|
| HRply(r) |
| |
----------------------------------<~~~ L2-LU |
| MN's traffic | | |
|<-------------->| | |
ミネソタnFA oFA aFA| | L2、第-~~~>|| | | | | | | <、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| HTT| | | |、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| HRply(s)| | | |------------------------------>| | | HRqst(t)| | | |<------------------------------| | | HRply(t)| | | | | | ----------------------------------<~~~ L2-LD| |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| L2移管| HRqst(r)| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| HRply(r)| | | ----------------------------------<~~~ L2-Lu| | ミネソタの交通| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|
Figure 10 - Three-Party Source Trigger Handoff Timing
図10--3パーティのソース引き金の移管タイミング
El Malki, Ed. Experimental [Page 32] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[32ページ]RFC4881低遅延
MN nFA oFA aFA
| | | |
| |<~~~ L2-TT | |
| |------------->| |
| | HRqst(t) | |
| |<-------------| |
| | HTT | |
| |------------------------------>|
| | HRqst(t) | |
| |<------------------------------|
| | HRply(t) | |
| | | |
----------------------------------<~~~ L2-LD |
|--------------->|
L2 Handoff | HRqst(r) |
| |
|<---------------|
| HRply(r) |
| |
----------------------------------<~~~ L2-LU |
| MN's traffic | | |
|<-------------->| | |
ミネソタnFA oFA aFA| | | | | |<~~~ L2-TT| | | |、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| HRqst(t)| | | | <、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| HTT| | | |------------------------------>| | | HRqst(t)| | | |<------------------------------| | | HRply(t)| | | | | | ----------------------------------<~~~ L2-LD| |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| L2移管| HRqst(r)| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| HRply(r)| | | ----------------------------------<~~~ L2-Lu| | ミネソタの交通| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|
Figure 11 - Three-Party Target Trigger Handoff Timing
図11--3パーティの目標引き金の移管タイミング
Unlike two-party handoff, the timing of BET establishment between aFA and nFA cannot fully depend on the availability of L2 trigger information because aFA does not receive an L2 trigger signaling L2 handoff. The two timing extremes at which aFA can place the BET with nFA are:
2パーティーの移管と異なって、aFAがL2引き金のシグナリングL2移管を受けないので、aFAとnFAの間のBET設立のタイミングは完全にL2引き金の情報の有用性に依存できるというわけではありません。 aFAがBETをnFAに置くことができる2つのタイミング極端は以下の通りです。
1) At the earliest, aFA MAY start tunneling packets using the BET
to nFA after sending the HRply(t) to nFA in response to the
request for target-triggered handoff.
1) 最も早いところでは、aFAは、目標で引き起こされた移管を求める要求に対応してHRply(t)をnFAに送った後にnFAにBETを使用することでパケットにトンネルを堀り始めるかもしれません。
2) At the latest, aFA MAY start tunneling packets using the BET to
nFA and tear down the BET with oFA when receiving the HRqst(r)
from oFA indicating that the MN has disconnected.
2) 遅くとも、ミネソタが連絡を断ったのを示すoFAからHRqst(r)を受けるとき、aFAはBETを使用することでnFAにパケットにトンネルを堀り始めて、oFAと共にBETを取りこわすかもしれません。
In addition, aFA MAY continue tunneling to oFA if 1) is selected, until the HRqst(r) is received. In this case, the result may be duplicated packets at the MN because the MN will receive packets through oFA on the old L2 until it disconnects (L2-LD). If 2) is selected, the additional latency will add to the MN's L3 service disruption period. Of course, aFA can choose to place the BET sometime between 1) and 2) if reliable bounds are available on the duration of time between L2-ST/L2-TT and the MN's disconnection (L2- LD). The exact selection of when to establish the BET is likely to
aFAは、1が)選択されるならHRqst(r)が受け取られているまでさらに、oFAにトンネルを堀り続けるかもしれません。 (L2-LD)を外すまでミネソタが古いL2の上のoFAを通してパケットを受けるので、この場合、結果はミネソタのコピーされたパケットであるかもしれません。 2が)選択されると、追加潜在はミネソタのL3サービスの崩壊の期間に加えるでしょう。 もちろん、信頼できる領域がL2-ST/L2-TTとミネソタの断線(L2LD)の間の時間の持続時間で利用可能であるなら、aFAは1と)2の)間のいつかBETを置くのを選ぶことができます。 いつにBETを設立しそうであるかに関する正確な選択
El Malki, Ed. Experimental [Page 33] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[33ページ]RFC4881低遅延
be influenced by network engineering and implementation considerations, including whether a handoff smoothing solution is used, and is beyond the scope of this specification.
ネットワーク工学と実現問題によって影響を及ぼされてください、解決策を整える移管が使用されていて、この仕様の範囲を超えているかを含んでいて。
4.3. Renewal or Termination of Tunneling Service
4.3. トンネリングサービスの更新か終了
To prevent a BET from expiring when its lifetime runs out, the MN's current FA signals the aFA to either renew or terminate the BET. This may be the case when the MN defers Mobile IPv4 Registration. If no such signal is received, the aFA will terminate the BET when the lifetime expires. In addition, the current FA or aFA may need to terminate the BET prior to the lifetime expiring. In order to avoid error conditions in which tunnels do not expire even though the MN to which they apply is no longer reachable, FAs SHOULD set the tunnel lifetime field to some value other that 0xffff, which indicates "good until canceled".
寿命がなくなるとき、BETが期限が切れるのを防ぐために、ミネソタの現在のFAは、BETを取り替えるか、または終えるようにaFAに合図します。 ミネソタがモバイルIPv4 Registrationを延期するとき、これはそうであるかもしれません。 寿命が期限が切れて、そのような何か信号が受信されていないと、aFAはBETを終えるでしょう。 さらに、現在のFAかaFAが、生涯の期限が切れることの前にBETを終える必要があるかもしれません。 それらが適用するミネソタによるもう届きません、FAs SHOULDがトンネル生涯分野をいくつかに設定するということですが、トンネルが期限が切れないエラー条件を避けるためにその0xffffを別に評価してください、どれ、表示、「良さ、取り消されるか、」
Figure 12 illustrates the message exchange that occurs between the FA needing to terminate or extend the tunnel (designated FA(1) in the figure) and the other FA (designated FA(2) in the figure). The HRqst(r)/HRply(r) is indicated by setting the R bit in the HRqst/HRply messages. If the HRqst(r) is renewing a BET, then it contains a non-zero lifetime; otherwise, if the lifetime is set to zero, it indicates tunnel termination. The aFA has complete control over whether a tunnel is extended or terminated, and it MAY reply to a request for extension with a shorter lifetime than was requested.
図12はトンネルを終えるか、または広げる必要があるFA(図でFA(1)に指定される)と他のFA(図でFA(2)に指定される)の間に起こる交換処理を例証します。 HRqst(r)/HRply(r)は、HRqst/HRplyメッセージにRビットをはめ込むことによって、示されます。 HRqst(r)がBETを取り替えているなら、非ゼロ生涯を含んでいます。 さもなければ、寿命がゼロに決められるなら、それはトンネル終了を示します。 トンネルが広げられるか、または終えられることにかかわらずaFAは完全なコントロールを家に迎えます、そして、それは要求されたより短い生涯で拡大を求める要求に答えるかもしれません。
HRqst(r)
+------+ <-------- +------+
| FA(2)| ---------> | FA(1)|
+------+ HRply(r) +------+
HRqst(r)+------+ <。-------- +------+ | ファ(2)| --------->| ファ(1)| +------+ HRply(r)+------+
Figure 12 - BET Renewal or Termination
図12--賭け更新か終了
4.4. When Will the MN Perform a Mobile IPv4 Registration?
4.4. ミネソタはいつモバイルIPv4登録を実行するでしょうか?
The MN/FA have control over when to perform the Mobile IPv4 Registration. Although the MN/FA may decide to defer Mobile IPv4 Registration for a certain period, three possible events can lead to the need to terminate tunneling service. If this occurs, the MN MUST perform the Mobile IPv4 Registration. These events are:
ミネソタ/FAには、いつモバイルIPv4 Registrationを実行するかのコントロールがあります。 ミネソタ/FAは、ある期間、モバイルIPv4 Registrationを延期すると決めるかもしれませんが、3回の可能な出来事が、サービスにトンネルを堀りながら、終わる必要性に通じることができます。 これが起こるなら、ミネソタはモバイルIPv4 Registrationを実行しなければなりません。 これらの出来事は以下の通りです。
1) The end of life for the BET is pending and a request by the
current FA to aFA for renewal has been denied, or alternatively
the current FA or aFA needs to terminate the BET prematurely.
The FA in this case MUST initiate the Mobile IPv4 Registration
by sending an Agent Advertisement to the MN as in [1].
1) BETのための寿命末期は未定です、そして、更新のためのaFAへの現在のFAによる要求が否定されたか、またはあるいはまた、現在のFAかaFAが早まってBETを終える必要があります。 この場合、FAは、[1]のようにエージェントAdvertisementをミネソタに送ることによって、モバイルIPv4 Registrationを開始しなければなりません。
El Malki, Ed. Experimental [Page 34] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[34ページ]RFC4881低遅延
2) The MN itself decides to perform a Mobile IPv4 Registration and
initiates it by sending an Agent Solicitation as in [1].
2) ミネソタ自体は、モバイルIPv4 Registrationを実行すると決めて、[1]のようにエージェントSolicitationを送ることによって、それを開始します。
3) During a source-triggered handoff, the oFA attempts to perform
BET handoff but nFA is not capable of performing it. The FA in
this case MUST initiate the Mobile IPv4 Registration by sending
the MN an Agent Advertisement as in [1]. Note that this
situation will never arise during target-triggered handoff
because an HRqst(t) will not be sent to oFA by an nFA that
doesn't support POST-REGISTRATION.
3) ソースによって引き起こされた移管の間、oFAは、BET移管を実行するのを試みますが、nFAはそれを実行できません。 この場合、FAは、[1]のようにエージェントAdvertisementをミネソタに送ることによって、モバイルIPv4 Registrationを開始しなければなりません。 HRqst(t)がポスト-REGISTRATIONを支持しないnFAによってoFAに送られないのでこの状況が目標で引き起こされた移管の間決して起こらないことに注意してください。
Some detailed scenarios relating to case 2) will be described hereafter. According to [1], when using an FA care-of address, the MN MAY use the FA as its default router. Otherwise, it MUST choose its default router from those advertised in the ICMP Router Advertisement portion of the Agent Advertisement. Here we assume that the FA router is also the MN's default router. In POST- REGISTRATION, when a tunnel is established between oFA and nFA and the MN has moved to nFA, the oFA MUST NOT send Agent Advertisements to the MN. In this case, it is possible that the MN will not receive Agent Advertisements for extended periods of time. According to [8], hosts will remove default router entries if the lifetime of the Router Advertisement expires and no further advertisements are received. Note that the ICMP Router Advertisement lifetime is not related to the Registration Lifetime in the Mobility Agent Advertisement extension [1]. To avoid this disruption, the MN MUST solicit the default router (i.e., FA) before the lifetime of its active default router entry runs out, or alternatively, the FA MUST advertise as soon as the MN-nFA link is up (L2-LU). This effectively means that the MN will at most be able to defer Mobile IPv4 Registration for as long as the remaining lifetime of the active default router, as configured in the ICMP Router Advertisements. The MN MUST perform a Mobile IPv4 Registration [1] when it receives an Agent Advertisement following a POST-REGISTRATION handoff.
ケース2)に関連するいくつかの詳細なシナリオが今後説明されるでしょう。 使用する、[1]、いつに従ってFA、注意、-、アドレス、ミネソタはデフォルトルータとしてFAを使用するかもしれません。 さもなければ、それはエージェントAdvertisementのICMP Router Advertisement部分の広告に掲載されたものからデフォルトルータを選ばなければなりません。 ここで、私たちは、FAルータがミネソタのもデフォルトルータであると思います。 トンネルがoFAとnFAの間で確立されて、ミネソタがnFAに動いたとき、ポストREGISTRATIONでは、oFAはエージェントAdvertisementsをミネソタに送ってはいけません。 この場合、ミネソタが延ばされた期間にエージェントAdvertisementsを受けないのは、可能です。 [8]によると、Router Advertisementの寿命が期限が切れて、さらなるどんな広告も受け取られていないと、ホストはデフォルトルータエントリーを取り除くでしょう。 ICMP Router Advertisement寿命がMobilityエージェントAdvertisement拡張子[1]でRegistration Lifetimeに関連しないことに注意してください。 活発なデフォルトルータエントリーの寿命がなくなる前にこの分裂を避けるために、ミネソタがデフォルトルータ(すなわち、FA)に請求しなければならない、あるいはまた、さもなければ、ミネソタ-nFAリンクが上がっていると(L2-LU)すぐに、FA MUSTは広告を出します。 事実上、これは、ミネソタがアクティブなデフォルトルータの残っている生涯と同じくらい長い間モバイルIPv4 Registrationを高々延期できることを意味します、ICMP Router Advertisementsで構成されるように。 [1] ポスト-REGISTRATION移管に続いて、エージェントAdvertisementを受けるとき、ミネソタはモバイルIPv4 Registrationを実行しなければなりません。
El Malki, Ed. Experimental [Page 35] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[35ページ]RFC4881低遅延
4.5. Handoff Request (HRqst) Message Format
4.5. 移管要求(HRqst)メッセージ・フォーマット
This is a new Mobile IPv4 message carried on UDP (destination port 434) [1]. The UDP header is followed by the fields below.
これはUDP(仕向港434)[1]で伝えられる新しいモバイルIPv4メッセージです。 分野はUDPヘッダーの以下にあとに続いています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |H|N|R|M|G|T|B| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ|H|N|R|M|G|T|B| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 生涯| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mnホームアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ハ、アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 識別+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 拡大… +-+-+-+-+-+-+-+-
Type 16 (Handoff Request)
16をタイプしてください。(移管要求)
H Source-triggered handoff request. When set and
the N bit is unset, indicates that the request
was the result of an L2-ST at oFA.
Hソースによって引き起こされた移管要求。 セットしてください、Nビットが、unsetであり、要求がoFAのL2-STの結果であったのを示すとき。
N Target triggered handoff request. When set and
the H bit is unset, indicates that the request
was the result of an L2-TT at nFA.
N目標は移管要求の引き金となりました。 セットしてください、Hビットが、unsetであり、要求がnFAのL2-TTの結果であったのを示すとき。
R Set if the request is an HRqst(r) (i.e., a
request to renew the tunnel, H and N bits must
be unset).
Rは要求がHRqst(r)(すなわち、トンネル、H、およびNビットを取り替えるという要求はunsetであるに違いない)であるならセットしました。
M The FA issuing the HRqst will use Minimal
Encapsulation as defined in [1,5] for the
tunnel.
HRqstを発行するM FAはトンネルへの[1、5]で定義されるようにMinimal Encapsulationを使用するでしょう。
G The FA issuing the HRqst will use Generic
Routing Encapsulation (GRE) [4] as defined in
[1,5] for the tunnel. Extensions of HRqst
containing GRE type and key Fields are outside
the scope of this document.
HRqstを発行するG FAは[4] トンネルへの[1、5]で定義されるようにGenericルート設定Encapsulation(GRE)を使用するでしょう。 このドキュメントの範囲の外にGREタイプと主要なフィールズを含むHRqstの拡大があります。
El Malki, Ed. Experimental [Page 36] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[36ページ]RFC4881低遅延
T For an HRqst(s), indicates that the oFA is
willing to support both forward and reverse
tunnel service. For an HRqst(t), indicates that
the nFA is requesting reverse tunnel service.
HRqst(s)のためのT、oFAが、前方に両方を支持し、トンネルサービスを逆にしても構わないと思っているのを示します。 HRqst(t)のために示す、nFAが逆のトンネルサービスを要求しているのを示します。
B When sent in an HRqst(s), indicates that the MN
has requested a reverse tunnel to the HA and
that the nFA SHOULD use a reverse tunnel to the
HA if it will not be reverse tunneling to the
oFA.
B、いつが、HRqst(s)を送って、ミネソタが逆のトンネルをHAに要求して、oFAへの逆のトンネリングでなくなるならnFA SHOULDが逆のトンネルをHAに使用するのを示しますか?
Lifetime The lifetime of the tunnel in seconds. If this
is an HRqst(t), then the lifetime represents a
request by nFA for a reverse tunnel. If this is
an HRqst(s), then the lifetime represents the
maximum amount of time that oFA is willing to
maintain both forward and reverse tunnels. If
this is an HRqst(r), then the lifetime
represents a request for the amount of time to
renew the tunnel's lifetime. A value of 0 on an
HRqst(s) indicates that the oFA is unwilling to
grant tunnel service. A value of 0 on an
HRqst(t) indicates that the nFA does not require
reverse tunnel service. A value of 0 on an
HRqst(r) indicates that the tunnel should be
terminated. A value of 0xffff indicates
infinity.
トンネルの寿命が中で後援する生涯。 これがHRqst(t)であるなら、寿命は逆のトンネルを求めるnFAによる要求を表します。 これがHRqst(s)であるなら、寿命はoFAが、前方に両方を維持し、トンネルを逆にしても構わないと思う最大の時間を表します。 これがHRqst(r)であるなら、寿命はトンネルの生涯を更新する時間を求める要求を表します。 HRqst(s)の上の0の値は、oFAがトンネルサービスを承諾したがっていないのを示します。 HRqst(t)の上の0の値は、nFAが逆のトンネルサービスを必要としないのを示します。 HRqst(r)の上の0の値は、トンネルが終えられるべきであるのを示します。 0xffffの値は無限を示します。
MN Home Address For HRqst(s), the home address of the MN.
ミネソタホームAddress For HRqst(s)、ミネソタに関するホームアドレス。
HA Addr For HRqst(s), the HA address of the mobile node.
HA Addr For HRqst(s)、可動のノードのHAアドレス。
Identification As defined in [1].
[1]で定義された識別As。
Extensions The message MUST include an LLA (see Section 9)
containing the MN's L2 address and an L2 address
that can be mapped to an IPv4 address for the
FA. This message MUST contain the FA-FA
Authentication Extension [11] that is used to
secure the HRqst message.
拡大、メッセージはFAのためのIPv4アドレスに写像できるミネソタのL2アドレスとL2アドレスを含むLLA(セクション9を見る)を含まなければなりません。 このメッセージはHRqstメッセージを保証するのに使用されるFA-FA Authentication Extension[11]を含まなければなりません。
El Malki, Ed. Experimental [Page 37] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[37ページ]RFC4881低遅延
4.6. Handoff Reply (HRply) Message Format
4.6. 移管回答(HRply)メッセージ・フォーマット
This is a new Mobile IPv4 message carried on UDP (destination port 434) [1]. The UDP header is followed by the fields below.
これはUDP(仕向港434)[1]で伝えられる新しいモバイルIPv4メッセージです。 分野はUDPヘッダーの以下にあとに続いています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |H|N|R|M|G|T|B| Reserved | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ|H|N|R|M|G|T|B| 予約されます。| コード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 生涯| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mnホームアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ハ、アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 識別+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 拡大… +-+-+-+-+-+-+-+-
Type 17 (Handoff Reply)
17をタイプしてください。(移管回答)
Code A value indicating the result of the Handoff
Request. Only two codes are currently
supported, 0, indicating success, and 1,
indicating that the handoff cannot be performed.
The remaining values are for future use.
Handoff Requestの結果を示すA値をコード化してください。 成功、および1を示して、0が、移管を実行できないのを示して、2つのコードだけが現在、サポートされます。 残余価値は今後の使用のためのものです。
Lifetime The lifetime, in seconds, for which the
bidirectional tunnel for the MN will be
maintained. If this is an HRply(s), then the
lifetime represents a request by nFA, and it can
be any value up to the maximum value sent in the
HRqst(s). Larger values are assumed to default
to oFA's maximum. If this is an HRply(t), then
the lifetime represents the maximum amount of
time that the oFA will grant to the nFA. If
this is an HRply(r), then the lifetime
represents the amount of time by which the
tunnel life will be extended. If the Code field
indicates that handoff failed, the Lifetime
field will be ignored and SHOULD be set to zero.
A value of 0 on an HRply(t) indicates that the
oFA is unwilling to grant service. A value of 0
on an HRply(s) indicates that the nFA does not
生涯、秒の生涯。(ミネソタへの双方向のトンネルは秒の間、維持されるでしょう)。 これがHRply(s)であるなら、寿命はnFAによる要求を表します、そして、HRqst(s)で送られた最大値までそれはどんな値であるかもしれません。 より大きい値がoFAの最大にデフォルトとすると思われます。 これがHRply(t)であるなら、寿命はoFAがnFAに与える最大の時間を表します。 これがHRply(r)であるなら、寿命は時間をトンネル生活が伸ばされる表します。 Code分野が、移管が失敗して、Lifetime分野が無視されるのを示すか、そして、SHOULD、ゼロに設定されてください。 HRply(t)の上の0の値は、oFAがサービスを承諾したがっていないのを示します。 HRply(s)の上の0の値は、nFAがそうしないのを示します。
El Malki, Ed. Experimental [Page 38] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[38ページ]RFC4881低遅延
require service. A value of 0 on an HRply(r)
indicates that the tunnel lifetime will be
terminated. A value of 0xffff indicates an
infinite lifetime.
サービスを必要としてください。 HRply(r)の上の0の値は、寿命がそうするトンネルが終えられるのを示します。 0xffffの値は無限の生涯を示します。
H Source-triggered handoff reply. When set and
the N bit is unset, indicates that the reply is
in response to an HRqst(s).
Hソースによって引き起こされた移管回答。 セットしてください、Nビットが、unsetであり、回答がHRqst(s)に対応しているのを示すとき。
N Target-triggered handoff reply. When set and
the H bit is unset, indicates that the reply is
in response to an HRqst(t).
N目標で引き起こされた移管回答。 セットしてください、Hビットが、unsetであり、回答がHRqst(t)に対応しているのを示すとき。
R Set if the reply is an HRply(r). Neither the H
nor the N bit are set.
Rは回答がHRply(r)であるならセットしました。 HもNビットも設定されません。
M The FA issuing the HRqst will use Minimal
Encapsulation as defined in [1,5] for the
tunnel.
HRqstを発行するM FAはトンネルへの[1、5]で定義されるようにMinimal Encapsulationを使用するでしょう。
G The FA issuing the HRqst will use GRE [4]
Encapsulation as defined in [1,5] for the
tunnel. When this flag bit is set, the HRply
may require extensions containing the GRE type
and key fields, but they are outside the scope
of this document.
HRqstを発行するG FAはトンネルへの[1、5]で定義されるようにGRE[4]カプセル化を使用するでしょう。 このフラグビットが設定されるとき、HRplyはGREタイプとキーフィールドを含む拡大を必要とするかもしれませんが、このドキュメントの範囲の外にそれらはあります。
T For an HRply(s), indicates that the nFA is
requesting to reverse tunnel service. For an
HRply(t), indicates that the oFA is willing to
provide both forward and reverse tunnel service.
HRply(s)のためのT、nFAが、逆になるように、サービスにトンネルを堀るよう要求しているのを示します。 HRply(t)のために示す、oFAが、両方を前方に提供し、トンネルサービスを逆にしても構わないと思っているのを示します。
B When sent in an HRply(t), indicates that the MN
has requested a reverse tunnel to the HA and
that the nFA SHOULD use a reverse tunnel to the
HA if it will not be reverse tunneling to the
oFA. It can be set in HRply(t) only if the T
bit was unset in the corresponding HRqst(t).
B、いつが、HRply(t)を送って、ミネソタが逆のトンネルをHAに要求して、oFAへの逆のトンネリングでなくなるならnFA SHOULDが逆のトンネルをHAに使用するのを示しますか? Tビットが対応するHRqst(t)のunsetであった場合にだけHRply(t)にそれを設定できます。
MN Home Address For HRply(t), the home IPv4 address of the MN.
ミネソタホームAddress For HRply(t)、ミネソタの家のIPv4アドレス。
HA Addr For HRply(t), the HA IPv4 address of the MN.
HA Addr For HRply(t)、ミネソタのHA IPv4アドレス。
Identification As defined in [1].
[1]で定義された識別As。
Extensions This Message MUST contain the FA-FA
Authentication Extension [11] that is used to
secure the HRply message.
拡大This MessageはHRplyメッセージを保証するのに使用されるFA-FA Authentication Extension[11]を含まなければなりません。
El Malki, Ed. Experimental [Page 39] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[39ページ]RFC4881低遅延
4.7. Handoff to Third (HTT) Message Format
4.7. 第3(HTT)メッセージ・フォーマットへの移管
The Handoff to Third message has the same format as the Handoff Request and Handoff Reply messages, except both the H and N bits are set. If the HTT message is in response to an L2-ST and is sent to initiate a handoff, then, with the exception of the H and N bits, the message has the same fields set and includes the same extensions as an HRqst(s). If the HTT message is sent in response to an HRqst(t), then, with the exception of the H and N bits, the message has the same fields set and includes the same extensions as an HRply(t). The tunnel bits MUST NOT be set in the HTT message because BET construction is not negotiated between oFA and nFA; it is negotiated between nFA and aFA in the ensuing HRqst(t)/HRply(t).
ThirdメッセージへのHandoffには、Handoff RequestとHandoff Replyメッセージと同じ形式があって、両方を除いて、HとNビットは設定されます。 HTTメッセージはL2-STに対応していて、次に、HとNビットを除いて、移管を開始するために送るなら、メッセージは、HRqst(s)として同じ分野を設定させて、同じ拡張子を含んでいます。 次に、HとNビットを除いて、HRqst(t)に対応してHTTメッセージを送るなら、メッセージは、HRply(t)として同じ分野を設定させて、同じ拡張子を含んでいます。 BET工事がoFAとnFAの間で交渉されないので、HTTメッセージにトンネルビットを設定してはいけません。 それは続いているHRqst(t)/HRply(t)のnFAとaFAの間で交渉されます。
In addition, the HTT MUST contain the following extensions in the specified order:
さらに、HTT MUSTは指定された順序で以下の拡大を含んでいます:
Solicited IPv4 Address Option: containing aFA's Address
請求されたIPv4はオプションを記述します: aFAのAddressを含んでいます。
LLA Option: containing the L2 address of the MN.
LLAオプション: ミネソタのL2アドレスを含んでいます。
4.8. Applicability of POST-REGISTRATION Handoff Method
4.8. ポスト登録移管方法の適用性
The POST-REGISTRATION handoff approach allows FAs to communicate directly about a pending handoff, and does not require any IPv4-layer messages to be sent to or from an MN prior to the L2 handoff event. Therefore, it eliminates a possible source of handoff latency. This may be required when the link layer imposes hard deadlines on the time at which a handoff must occur, such as when an MN is rapidly moving out of a radio coverage area. Consequently, POST-REGISTRATION is primarily of interest in handoff between FAs that support the same radio access technology. Handoff between heterogeneous radio technologies will, of necessity, require interaction between the MN and the network, and so is not a domain of applicability for POST- REGISTRATION.
ポスト-REGISTRATION移管アプローチは、FAsが直接未定の移管について話し合うのを許容して、L2移管出来事の前にどんなミネソタかミネソタから送られるべきIPv4-層のメッセージも必要としません。 したがって、それは移管潜在の可能な源を排除します。 リンクレイヤが移管が起こらなければならない時に困難な締め切りを課すと、これが必要であるかもしれません、ミネソタが急速にラジオ適用範囲部から引っ越している時のように。 その結果、ポスト-REGISTRATIONは同じラジオアクセス技術を支持するFAsの間で主として移管におもしろいです。 技術がそうする異種のラジオの間の移管、必要です、ミネソタとネットワークとの相互作用を必要としてください、そして、ポストREGISTRATIONのための適用領域もそうです。
Because a POST-REGISTRATION handoff is triggered by an unspecified mechanism that informs the oFA or nFA that an L2 handoff is pending, the POST-REGISTRATION approach is only applicable to networks where such a mechanism is available. For example, an L2 may provide indications of radio signal quality that cause the oFA or nFA to send the POST-REGISTRATION handoff messages. Any such indications must also provide each FA involved in the handoff with the identity of the other, so that messages can be sent to the right place. This may involve mapping L2 information onto FA IPv4 addresses. Also, the FAs involved in a handoff must have pre-provisioned security arrangements so that the POST-REGISTRATION messages can be authenticated. If a handoff is to be completed as a result of the POST-REGISTRATION
ポスト-REGISTRATION移管がL2移管が未定であることをoFAかnFAに知らせる不特定のメカニズムによって引き起こされるので、ポスト-REGISTRATIONアプローチは単にそのようなメカニズムが利用可能であるネットワークに適切です。 例えば、L2はoFAかnFAがポスト-REGISTRATION移管メッセージを送る無線信号品質のしるしを供給するかもしれません。 また、どんなそのような指摘も移管にかかわる各FAにもう片方のアイデンティティを提供しなければなりません、適当な場所にメッセージを送ることができるように。 これは、L2情報をFA IPv4アドレスに写像することを伴うかもしれません。 また、移管にかかわるFAsは、ポスト-REGISTRATIONメッセージを認証できるようにセキュリティアレンジメントにあらかじめ食糧を供給したに違いありません。 移管がポスト-REGISTRATIONの結果、完成されることであるなら
El Malki, Ed. Experimental [Page 40] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[40ページ]RFC4881低遅延
messaging, any L2 handoff indications must also be securely authenticated so that traffic to the old point of attachment is not improperly halted.
メッセージング、また、しっかりとどんなL2移管指摘も認証しなければならないので、古い接着点への交通は不適切に止められません。
POST-REGISTRATION handoff is appropriate in the following cases:
ポスト-REGISTRATION移管は以下の場合で適切です:
- L2 triggers are available on the network to indicate that L2
handoff is pending.
- L2引き金はL2移管まである示すネットワークで利用可能です。
- Pre-provisioned security mechanisms are in place to allow fast
and secure messaging between the FAs and between the MN and an
FA.
- FAsの間と、そして、ミネソタとFAの間にメッセージングを速く許容して、保証するために、あらかじめ食糧を供給されたセキュリティー対策は適所にあります。
- Access point choice by the MN is not a concern or the choice
requires user intervention and therefore is not on the critical
path for handoff.
- ミネソタによるアクセスポイント選択が関心でない選択は、ユーザ介入を必要として、したがって、移管のためのクリティカルパスにありません。
5. Combined Handoff Method
5. 結合した移管方法
The combined method uses both PRE-REGISTRATION and POST-REGISTRATION handoff. If PRE-REGISTRATION does not complete prior to the expiration of a timer on the nFA, the POST-REGISTRATION mechanism is used to create the tunnel between oFA and nFA. This protects the MN from delays caused by errors such as loss of the Mobile IPv4 Registration Reply message involved in PRE-REGISTRATION for the mobile-initiated and network-initiated source-triggered cases. It also protects the MN from delays caused by errors or the loss of any of the Mobile IPv4 messages involved in PRE-REGISTRATION for the network-initiated target-triggered case.
結合した方法はPRE-REGISTRATIONとポスト-REGISTRATION移管の両方を使用します。 PRE-REGISTRATIONがnFAにおけるタイマの満了の前に完全でなくするなら、ポスト-REGISTRATIONメカニズムは、oFAとnFAの間のトンネルを作成するのに使用されます。 これは可動に開始していてネットワークによって開始されたソースによって引き起こされたケースのためにPRE-REGISTRATIONにかかわるモバイルIPv4 Registration Replyメッセージの損失などの誤りで引き起こされた遅れからミネソタを保護します。 また、それはネットワークによって開始された目標で引き起こされたケースのためにPRE-REGISTRATIONにかかわるモバイルIPv4メッセージのどれかの誤りか損失で引き起こされた遅れからミネソタを保護します。
When the nFA receives a target trigger, it will follow the PRE- REGISTRATION procedure. When the combined method is used, the nFA MUST also start a timer when it receives a target trigger. The timer should be set to a small value (default for target trigger case: 1 second).
nFAが目標引き金を受けるとき、それはPRE- REGISTRATION手順に従うでしょう。 また、結合した方法が使用されているとき、目標引き金を受けるとき、nFAはタイマを始動しなければなりません。 タイマは小さい値(目標引き金のケースのためのデフォルト: 1秒)に設定されるべきです。
According to PRE-REGISTRATION, the nFA will receive the Registration Request from the MN. When the combined method is used, this Registration Request sent by the MN MUST contain the IPv4 address of the oFA in an FA IPv4 address LLA extension (see Section 9.7). This same Registration Request message will contain multiple LLA extensions, since it will also contain the MN's layer 2 address in an LLA extension as described for PRE-REGISTRATION (see Sections 3.7 and 9). When the nFA has not started the handoff procedure using a target trigger (i.e., mobile-initiated or network-initiated target- triggered cases), the nFA MUST start a timer as soon as it receives the low-latency Registration Request from the MN. This timer should be set to a small value (default: 1 second).
PRE-REGISTRATIONによると、nFAはミネソタからRegistration Requestを受けるでしょう。 結合した方法が使用されているとき、ミネソタによって送られたこのRegistration RequestはFA IPv4アドレスLLA拡張子でoFAのIPv4アドレスを含まなければなりません(セクション9.7を見てください)。 この同じRegistration Requestメッセージは複数のLLA拡張子を含むでしょう、また、PRE-REGISTRATIONのために説明されるようにLLA拡張子でミネソタの層2のアドレスを含むので(セクション3.7と9を見てください)。 nFAが目標引き金(すなわち、可動の開始しているかネットワークによって開始された目標引き起こされたケース)を使用することで移管手順を始めていないとき、ミネソタから低遅延Registration Requestを受けるとすぐに、nFAはタイマを始動しなければなりません。 このタイマは小さい値(デフォルト: 1秒)に設定されるべきです。
El Malki, Ed. Experimental [Page 41] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[41ページ]RFC4881低遅延
In all cases, the timer MUST be reset when the Registration Reply message is received by nFA. If the timer expires before the Registration Reply is received, the nFA MUST initiate the POST- REGISTRATION procedure. The nFA utilizes the oFA IPv4 address (previously received in the extension to the Registration Request message) as the destination of the POST-REGISTRATION HRqst message to create the tunnel between nFA and oFA. The nFA MAY tear down this tunnel when it receives and forwards a successful Registration Reply for that MN.
すべての場合では、Registration ReplyメッセージがnFAによって受け取られるとき、タイマをリセットしなければなりません。 Registration Replyが受け取られている前にタイマが期限が切れるなら、nFAはポストREGISTRATION手順に着手しなければなりません。 nFAはnFAとoFAの間のトンネルを作成するポスト-REGISTRATION HRqstメッセージの目的地としてoFA IPv4アドレス(以前に、拡大でRegistration Requestメッセージに受信する)を利用します。 うまくいっているRegistration Replyをそのミネソタに受けて、送るとき、nFAはこのトンネルを取りこわすかもしれません。
6. Layer 2 and Layer 3 Handoff Timing Considerations
6. 層2と層3の移管タイミング問題
In the optimal cases considered in the PRE-REGISTRATION and POST- REGISTRATION handoffs, it was assumed that a timely L2 trigger would be received in such a way that packets could be delivered to the MN via its nFA immediately upon connection. In this way, the MN does not suffer disruption due to the L3 handoff. However, such precise timing of the L2 trigger and handoff mechanism with respect to the actual L2 handoff event will not be possible in all wireless systems and may depend on particular implementation techniques. Therefore, some uncertainty may exist at L3 as to exactly when the L2 connection between the MN and the nFA becomes fully established and can be used for L3 traffic. It is possible that in certain implementations traffic will be re-routed too early or too late with respect to the moment when the connection between the MN and the nFA becomes fully established. The techniques that may solve this problem and allow the MN to receive traffic independently of the timing of the L2 handoff event include buffering and simultaneous bindings (i.e., bicasting: setting the S bit [1] in Registration Requests). However, these are optional and are not mandated.
PRE-REGISTRATIONで考えられた最適のケースとポストREGISTRATION handoffsでは、タイムリーなL2引き金がすぐ接続でのnFAを通してパケットをミネソタに届けることができたような方法で受け取られると思われました。 このように、ミネソタはL3移管による分裂を受けません。 しかしながら、実際のL2移管出来事に関するL2引き金と移管メカニズムのそのような正確なタイミングは、すべてのワイヤレスシステムで可能でなく、特定の実現のテクニックに依存するかもしれません。 したがって、何らかの不確実性がL3にちょうどミネソタとnFAとのL2接続は完全に確立するようになって、L3交通に使用できる時に関して存在するかもしれません。 ある一定の実現交通におけるそれがミネソタとnFAとの接続が完全に確立するようになる瞬間に関して早過ぎるか、または遅過ぎる状態で別ルートで送られるのは、可能です。 この問題を解決して、ミネソタがL2移管出来事のタイミングの如何にかかわらず交通を受けるのを許容するかもしれないテクニックはバッファリングしていて同時の結合(すなわち、bicasting: Sビット[1]をRegistration Requestsにはめ込む)を含んでいます。 しかしながら、これらは、任意であり、強制されません。
7. Reverse Tunneling Support
7. トンネリングサポートを逆にしてください。
The handoff methods all support reverse tunneling. The MN may request reverse tunneling [3] by setting the T bit in its Registration Request. In the case of POST-REGISTRATION, if the MN had requested reverse tunneling previously at oFA, the handoff message from oFA (see Section 4) includes the T bit enabled to inform nFA to establish a BET for the visitor entry. Typically, the T bit will always be set to ensure that any delays in the MN receiving its new care-of address do not result in any delay in uplink packet transmission from the MN, but local policies and particular L2 technologies may allow the reverse tunnel to be turned off.
すべてが支持する移管方法はトンネリングを逆にします。 ミネソタは、TビットをRegistration Requestにはめ込むことによって、逆のトンネリング[3]を要求するかもしれません。 ポスト-REGISTRATIONの場合では、ミネソタが以前にoFAで逆のトンネリングを要求したなら、oFA(セクション4を見る)からの移管メッセージは訪問者エントリーにBETを証明するためにnFAに知らせるのが可能にされたTビットを含んでいます。 Tビットがいつも通常、ことになる、いずれもミネソタの受信で延着するのを保証するように設定されて、それが新しいという注意、-、アドレスは、下にターンされるためにミネソタからのアップリンクパケット伝送のどんな遅れでも結果ではなく、技術が許容するかもしれないローカルの方針と特定のL2に逆のトンネルをします。
El Malki, Ed. Experimental [Page 42] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[42ページ]RFC4881低遅延
8. Handoff Signaling Failure Recovery
8. 移管シグナリング失敗回復
In general and to a greater extent in wireless networks, packets carrying handoff signaling may be dropped or lost due to errors on the link. In this section, we consider mechanisms for recovery from handoff signaling failures.
一般に、そして、ワイヤレス・ネットワークにおける、より大きい範囲に、移管シグナリングを運ぶパケットは、リンクにおける誤りのため落とされるか、または失われるかもしれません。 このセクションでは、私たちは移管シグナリング失敗からの回復のためにメカニズムを考えます。
8.1. PRE-REGISTRATION Signaling Failure Recovery
8.1. プレ登録シグナリング失敗回復
Failure of PRE-REGISTRATION signaling breaks down into three cases:
PRE-REGISTRATIONシグナリングの失敗は3つのケースに分解します:
1) Loss of messages PrRtSol and PrRtAdv on the air link.
1) メッセージPrRtSolとPrRtAdvの放送されたリンクの損失。
2) Loss of the solicitation by an FA to obtain another neighboring
FA's Advertisement or loss of the neighboring FA's
advertisement.
2) 別の隣接しているFAのAdvertisementを入手するFAによる懇願の損失か隣接しているFAの広告の損失。
3) Failure of the standard Mobile IPv4 Registration.
3) 標準のモバイルIPv4 Registrationの失敗。
Of these, case 3) is handled by standard Mobile IPv4 mechanisms described in [1]. Case 2) is expected to be a rare event because spontaneous packet drop rates on the fixed network are caused by congestion or router failure. Since bit error rates on wireless links are higher than on fixed links, case 1) is more likely to occur. In the following subsections, cases 1) and 2) are considered.
これらでは、ケース3)は[1]で説明された標準のモバイルIPv4メカニズムによって扱われます。 ケース2)は固定ネットワークの自然発生的なパケット低下率が混雑かルータ失敗によって引き起こされるのでめったにない事件であると予想されます。 無線のリンクのビット誤り率が固定連結路より高いので、ケース1)は、より起こりそうです。 以下の小区分では、ケース1と)2)は考えられます。
8.1.1. Failure of PrRtSol and PrRtAdv
8.1.1. PrRtSolとPrRtAdvの失敗
PRE-REGISTRATION handoff can fail in network-initiated handoff when the PrRtAdv sent by oFA in response to the source trigger (L2-ST) or the advertisement sent by nFA in response to the target trigger (L2- TT) fails to reach the MN. PRE-REGISTRATION handoff can also fail in mobile-initiated handoff when either the PrRtSol sent from the MN or return PrRtAdv sent from the oFA is dropped. To reduce the probability that PrRtAdv and PrRtSol are lost, the MN and FA MAY transmit multiple copies of these messages. Should these messages fail anyway, in both cases the MN connects to the nFA without having received any prior signaling. In this case, the MN solicits an FA Advertisement when it connects to nFA at L2 (L2-LU), as described in Section 3.6, and performs a standard Mobile IPv4 Registration with the nFA as specified in [1].
ソース引き金に対応してoFAによって送られたPrRtAdv(L2-ST)か目標引き金に対応してnFAによって送られた広告(L2TT)がミネソタに達しないと、PRE-REGISTRATION移管はネットワークによって開始された移管に失敗できます。 また、ミネソタから送られたPrRtSolかoFAから送られたリターンPrRtAdvのどちらかが落とされるとき、PRE-REGISTRATION移管は可動に開始している移管に失敗できます。 減少するために、PrRtAdvとPrRtSolが無くなるという確率、ミネソタ、およびFA MAYはこれらのメッセージの複本を伝えます。 とにかく失敗してください、どちらの場合も、ミネソタがどんな先のシグナリングも受けていなくてnFAに接続するというこれらのメッセージはそうするべきです。 この場合、ミネソタは、L2(L2-LU)でnFAに接続するとき、セクション3.6で説明されるようにFA Advertisementに請求して、[1]の指定されるとしてのnFAと共に標準のモバイルIPv4 Registrationを実行します。
El Malki, Ed. Experimental [Page 43] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[43ページ]RFC4881低遅延
8.1.2. Failure of Inter-FA Solicitation and Advertisement
8.1.2. 相互ファ懇願と広告の失敗
The solicitation from an FA to another neighboring FA may fail or the corresponding advertisement from the neighboring FA may be lost. To reduce the probability that these messages are lost, the FAs MAY transmit multiple copies of these messages. If a failure occurs anyway, the FA soliciting the Agent Advertisement is unable to send a PrRtAdv in response to a source trigger or to a mobile-initiated PrRtSol. In these cases, when the MN does not receive a notification or confirmation of a PRE-REGISTRATION handoff, the MN MUST perform a standard Mobile IPv4 Registration as soon as it connects to the nFA (L2-LU) as described in Section 8.1.1.
FAから隣接している別のFAまでの懇願は失敗するかもしれませんか、または隣接しているFAからの対応する広告が失われるかもしれません。 これらのメッセージが無くなるという確率を減少させるために、FAsはこれらのメッセージの複本を伝えるかもしれません。 失敗がとにかく起こるなら、エージェントAdvertisementに請求するFAはソース引き金に対応した可動に開始しているPrRtSolにPrRtAdvを送ることができません。 ミネソタがPRE-REGISTRATION移管の通知か確認を受け取らないときのこれらの場合では、セクション8.1.1で説明されるようにnFA(L2-LU)に接続するとすぐに、ミネソタは標準のモバイルIPv4 Registrationを実行しなければなりません。
8.2. POST-REGISTRATION Signaling Failure Recovery
8.2. ポスト登録シグナリング失敗回復
Failure occurs in POST-REGISTRATION when either the HRqst or HRply message is dropped. The effects of the failure and the recovery procedure depend on which message is dropped, and whether the handoff is source or target triggered. Since all of the POST-REGISTRATION signaling is going over the fixed network, it can be expected that spontaneous dropping of packets in the absence of congestion and router failure should be a relatively rare event. Nevertheless, failure recovery mechanisms SHOULD be implemented.
HRqstかHRplyメッセージが落とされるとき、失敗はポスト-REGISTRATIONに起こります。 失敗の影響とリカバリ手順は移管がどのメッセージが落とされるか、そして、ソースかそれとも引き起こされた目標であるかに頼っています。 ポスト-REGISTRATIONシグナリングのすべてが固定ネットワークを調べているので、混雑とルータ失敗がないときパケットの自然発生的な低下が比較的まれな出来事であると予想できます。 それにもかかわらず、失敗回収機構SHOULD、実行されてください。
8.2.1. HRqst Message Dropped
8.2.1. HRqstメッセージは低下しました。
If the HRqst message is dropped, the effect is the same for both source- and target-triggered handoffs. In either case, the FA to which the HRqst was destined will never respond with an HRply message. If the handoff is source triggered, then the nFA never learns of the handoff, and the oFA never receives confirmation. If the handoff is target-triggered, then the oFA never learns of the handoff, and the nFA never receives confirmation.
HRqstメッセージが落とされるなら、ソースと目標で引き起こされたhandoffsの両方に、効果は同じです。 どちらの場合ではも、HRqstが運命づけられたFAはHRplyメッセージで決して応じないでしょう。 移管が引き起こされたソースであるなら、nFAは移管を決して知りません、そして、oFAは確認を決して受け取りません。 移管が目標によって引き起こされるなら、oFAは移管を決して知りません、そして、nFAは確認を決して受け取りません。
The recovery procedure in this case is as follows: the oFA MUST NOT construct a forward tunnel when the MN moves off-link (L2-LD) if the handoff is source-triggered, and the nFA MUST NOT construct a reverse tunnel if the handoff is target triggered. If the nFA was not informed of the handoff by an HRqst message (corresponding to failure of source-triggered handoff) or if the handoff was not confirmed by an HRply message (corresponding to failure of target-triggered handoff), the nFA MUST unicast an Agent Advertisement to the MN as soon as its L2 connection is established (L2-LU at nFA).
この場合、リカバリ手順は以下の通りです: 移管がソースによって引き起こされるならミネソタがオフリンク(L2-LD)を動かすとき、oFAは前進のトンネルを建築してはいけません、そして、nFAは移管が引き起こされた目標であるなら逆のトンネルを建築してはいけません。 nFAがHRqstメッセージによって移管について知らされなかったか(ソースによって引き起こされた移管の失敗に対応する)、または移管がHRplyメッセージによって確認されなかったなら(目標で引き起こされた移管の失敗に対応する)、nFAが確認されなければならなかった、ユニキャスト、L2接続の次第ミネソタのエージェントAdvertisementは設立されます(nFAのL2-LU)。
El Malki, Ed. Experimental [Page 44] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[44ページ]RFC4881低遅延
8.2.2. HRply Message Dropped
8.2.2. HRplyメッセージは低下しました。
If the HRply message is dropped, the FA sending the HRply will assume that the handoff has been confirmed, but the FA that is expecting to receive the HRply does not receive confirmation. In this case, the failure recovery procedure is different for source-triggered and target-triggered handoffs.
HRplyメッセージが落とされると、HRplyを送るFAは、移管が確認されたと仮定するでしょうが、HRplyを受け取ると予想しているFAは確認を受け取りません。 この場合、ソースによって引き起こされて目標で引き起こされたhandoffsにおいて、失敗リカバリ手順は異なっています。
In a target-triggered handoff, the oFA assumes that the handoff is confirmed because it has sent the HRply, but the nFA has not received it so it does not have confirmation. The oFA starts tunneling packets to the nFA when the MN moves from its link (L2-LD). The nFA MUST send an FA Advertisement to the MN as soon as its L2 link is up (L2-LU at nFA) and MAY drop the tunneled packets. The nFA SHOULD send an ICMP Destination Unreachable [9] message to the oFA. When the oFA receives this message, it will terminate the tunnel and stop forwarding packets. If reverse tunneling was requested, the nFA MUST NOT reverse tunnel because it has not received handoff confirmation.
目標で引き起こされた移管には、HRplyを送りましたが、nFAがそれを受けていないのでoFAが、移管が確認されると仮定するので、それでは、確認がありません。 ミネソタがリンク(L2-LD)から動くと、oFAはnFAにパケットにトンネルを堀り始めます。 nFAはL2リンクが上がっていると(nFAのL2-LU)すぐに、FA Advertisementをミネソタに送らなければならなくて、トンネルを堀られたパケットを落とすかもしれません。 nFA SHOULDはICMP Destination Unreachable[9]メッセージをoFAに送ります。 oFAがこのメッセージを受け取るとき、それは、トンネルを終えて、パケットを進めるのを止めるでしょう。 逆のトンネリングが要求されたなら、移管確認を受け取っていないので、nFAはトンネルを逆にしてはいけません。
In source-triggered handoff, the nFA assumes that the handoff is confirmed because it has sent the HRply, but the oFA has not received it so it does not have confirmation. Without failure recovery, the MN could move to the nFA without the oFA being able to start the forward tunnel for the MN's packets, and the MN would not be able to initiate a Mobile IPv4 Registration because it does not know that the handoff has failed. In this situation, the oFA MUST send out an HRqst message to the nFA with lifetime zero as soon as the MN leaves its link (L2-LD). The oFA SHOULD continue to retransmit the HRqst message, with exponential backoff for CONFIG-HFAIL seconds or until it receives an HRply acknowledging the request to cancel the tunnel. The default value for CONFIG-HFAIL is 10 seconds. When the nFA receives the HRqst, it MUST immediately send an Agent Advertisement to the MN, as is the case whenever a tunnel is canceled. In addition, the oFA MUST also drop any packets received through the reverse tunnel from the nFA. The oFA SHOULD NOT send the ICMP Destination Unreachable message to the nFA because the nFA has been informed by the HRqst message to cancel the tunnel. However, if the nFA receives an ICMP Destination Unreachable message for the tunnel prior to receiving the HRqst canceling the tunnel, it MUST send an FA Advertisement to the MN and cancel the tunnel.
ソースによって引き起こされた移管には、HRplyを送りましたが、oFAがそれを受けていないのでnFAが、移管が確認されると仮定するので、それでは、確認がありません。 失敗回復、ミネソタはミネソタのパケットのために前進のトンネルを始動できるoFAなしでnFAに動くことができました、そして、移管が失敗したのを知らないので、ミネソタはモバイルIPv4 Registrationを開始できないでしょう。 この状況で、ミネソタが(L2-LD)にリンクを残すとすぐに、oFAは生涯ゼロがあるnFAにHRqstメッセージを出さなければなりません。 CONFIG-HFAIL秒かトンネルを取り消すという要求を承諾しながらHRplyを受けるまで、oFA SHOULDは、指数のbackoffでHRqstメッセージを再送し続けています。 CONFIG-HFAILのためのデフォルト値は10秒です。 nFAがすぐにHRqstを受けるとき、エージェントAdvertisementをミネソタに送らなければなりません、そして、トンネルは取り消されます。 また、さらに、oFAは逆のトンネルを通ってnFAから受け取られたどんなパケットも落とさなければなりません。 nFAがトンネルを取り消すHRqstメッセージによって知らされたので、oFA SHOULDはICMP Destination UnreachableメッセージをnFAに送りません。 しかしながら、トンネルを取り消すHRqstを受ける前にnFAがトンネルへのICMP Destination Unreachableメッセージを受け取るなら、それは、FA Advertisementをミネソタに送って、トンネルを取り消さなければなりません。
El Malki, Ed. Experimental [Page 45] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[45ページ]RFC4881低遅延
9. Generalized Link Layer and IPv4 Address (LLA) Extension
9. 一般化されたリンクレイヤとIPv4アドレス(LLA)拡大
This section defines the Generalized Link Layer and IPv4 Address (LLA) Extension, used by any node that needs to communicate link layer and IPv4 addresses. The format of the extension relies on sub-types, where each sub-type defines its own sub-structure. This document defines six sub-types. Future RFCs should allocate their own sub-type and define their own address formats.
このセクションはリンクレイヤとIPv4アドレスを伝える必要があるどんなノードによっても使用されるGeneralized Link LayerとIPv4 Address(LLA)拡張子を定義します。 拡大の形式はサブタイプを当てにします。そこでは、それぞれのサブタイプがそれ自身の基礎を定義します。 このドキュメントは6つのサブタイプを定義します。 将来のRFCsはそれら自身のサブタイプを割り当てて、それら自身のアドレス形式を定義するはずです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | LLA ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| サブタイプ| LLA… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
138 (skippable) [1] - when used in Registration Requests
140 (skippable) [1] - when used in Agent Advertisements
138(skippable)[1]エージェントAdvertisementsで使用されるとRegistration Requests140(skippable)[1]で使用されると
Length
長さ
The length of the Link Layer Address + the one-octet Sub-Type
field
+ 1八重奏のSub-タイプがさばくLink Layer Addressの長さ
Sub-Type
サブタイプ
This field contains the Link Layer sub-type identifier
この分野はLink Layerサブタイプ識別子を含んでいます。
LLA
LLA
Contains the Link Layer Address
リンクレイヤアドレスを含んでいます。
In this document, seven sub-types are defined:
本書では、7つのサブタイプが定義されます:
1 3GPP2 International Mobile Station Identity and
Connection ID [13]
2 3GPP International Mobile Subscriber Identity [15]
3 Ethernet 48-bit MAC address [5]
4 64-bit Global ID, EUI-64 [6]
5 Solicited IPv4 Address
6 Access Point Identifier
7 FA IPv4 Address
1 3GPP2の国際モバイル駅のIdentityとConnection ID[13]2 3GPP移動加入者識別番号[15]3のイーサネットの48ビットのMACアドレス[5]4の64ビットのGlobal ID、EUI-64[6]5Solicited IPv4 Address6のAccess Point Identifier7FA IPv4 Address
The following subsections describe the extensions.
以下の小区分は拡大について説明します。
El Malki, Ed. Experimental [Page 46] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[46ページ]RFC4881低遅延
9.1. 3GPP2 IMSI Link Layer Address and Connection ID Extension
9.1. 3GPP2 IMSIリンクレイヤアドレスと接続ID拡大
The IMSI Link Layer Address Extension contains the International Mobile Station Identity (IMSI).
IMSI Link Layer Address Extensionは国際モバイル駅のIdentity(IMSI)を含んでいます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | IMSI ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| サブタイプ| IMSI… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
1 (skippable) [1]
1 (skippable)[1]
Length
長さ
The length of the IMSI field + the one-octet Sub-Type field
+ 1八重奏のSub-タイプがさばくIMSI分野の長さ
Sub-Type
サブタイプ
1
1
IMSI
IMSI
Contains the IMSI, in the form:
<IMSI>:<Connection Id>
Where the <IMSI> is an ASCII-based representation of the
International Mobile Station Identity, most significant
digit first, ":" is ASCII 0x3a, and the Connection ID is the
ASCII representation of a small, decimal number used for
distinguishing different link-layer connections from the
same mobile device.
フォームにIMSIを含んでいます: 「<IMSI>: <Connection Id>Where、最初に<IMSI>が国際モバイル駅のIdentityのASCIIベースの表現、最上位けたである、」、:、」 ASCIIは0x3aです、そして、Connection IDは同じモバイル機器と異なったリンクレイヤ接続を区別するのに使用されるわずかな10進数のASCII表現です。
El Malki, Ed. Experimental [Page 47] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[47ページ]RFC4881低遅延
9.2. 3GPP IMSI Link Layer Address Extension
9.2. 3GPP IMSIリンクレイヤアドレス拡張子
The IMSI Link Layer Address Extension contains the International Mobile Station Identity.
IMSI Link Layer Address Extensionは国際モバイル駅のIdentityを含んでいます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | IMSI ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| サブタイプ| IMSI… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
2 (skippable) [1]
2 (skippable)[1]
Length
長さ
The length of the IMSI field + the one-octet Sub-Type field
+ 1八重奏のSub-タイプがさばくIMSI分野の長さ
Sub-Type
サブタイプ
2
2
IMSI
IMSI
Contains the IMSI, a number composed of 15 digits or less,
coded as described in [15].
IMSI、[15]で説明されるようにコード化された15ケタ以下で構成された数を含んでいます。
El Malki, Ed. Experimental [Page 48] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[48ページ]RFC4881低遅延
9.3. Ethernet Link Layer Address Extension
9.3. イーサネットリンクレイヤアドレス拡大
The Ethernet Link Layer Address Extension contains the 48-bit Ethernet MAC Address, as defined in [5].
イーサネットLink Layer Address Extensionは[5]で定義されるように48ビットのイーサネットマックーアドレスを含んでいます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | MAC ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| サブタイプ| Mac… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
3 (skippable) [1]
3 (skippable)[1]
Length
長さ
7 (includes the Sub-Type field)
7 (Sub-タイプ分野を含んでいます)
Sub-Type
サブタイプ
3
3
MAC
Mac
Contains the 48-bit Ethernet MAC Address.
48ビットのイーサネットマックーアドレスを含んでいます。
El Malki, Ed. Experimental [Page 49] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[49ページ]RFC4881低遅延
9.4. IEEE 64-Bit Global Identifier (EUI-64) Address Extension
9.4. IEEEの64ビットのグローバルな識別子(EUI-64)アドレス拡張子
The 64-bit Global Identifier (EUI-64) Address Extension contains the 64-bit address, as defined in [6].
64ビットのGlobal Identifier(EUI-64)アドレスExtensionは[6]で定義されるように64ビットのアドレスを含んでいます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | MAC ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| サブタイプ| Mac… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
4 (skippable) [1]
4 (skippable)[1]
Length
長さ
9 (includes the Sub-Type field)
9 (Sub-タイプ分野を含んでいます)
Sub-Type
サブタイプ
4
4
MAC
Mac
Contains the 64-bit Global Identifier Address.
64ビットのグローバルな識別子アドレスを含んでいます。
El Malki, Ed. Experimental [Page 50] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[50ページ]RFC4881低遅延
9.5. Solicited IPv4 Address Extension
9.5. 請求されたIPv4アドレス拡張子
The 32-bit Solicited IPv4 Address Extension contains the IPv4 address of the agent (FA) being solicited. This extension MAY be present in an ICMP Agent Solicitation as explained in Section 3.3.
32ビットのSolicited IPv4 Address Extensionは請求されるエージェント(FA)のIPv4アドレスを含んでいます。 この拡大はセクション3.3で説明されるようにICMPエージェントSolicitationに存在しているかもしれません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | IPv4 addr ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| サブタイプ| IPv4 addr… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
5 (skippable) [1]
5 (skippable)[1]
Length
長さ
5 (includes the Sub-Type field)
5 (Sub-タイプ分野を含んでいます)
Sub-Type
サブタイプ
5
5
IPv4 Address
IPv4アドレス
Contains the 32-bit IPv4 Address of the solicited node.
請求されたノードの32ビットのIPv4 Addressを含んでいます。
El Malki, Ed. Experimental [Page 51] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[51ページ]RFC4881低遅延
9.6. Access Point Identifier Extension
9.6. アクセスポイント識別子拡張子
The 32-bit Access Point Identifier Extension contains an identifier of the access point to which the MN will move. This may be a wireless L2 identifier. The MN is able to solicit an advertisement from the FA servicing a certain access point by using this extension with Agent Solicitations as explained in Section 3.3.
32ビットのAccess Point Identifier Extensionはミネソタが移行するアクセスポイントに関する識別子を含んでいます。 これはワイヤレスのL2識別子であるかもしれません。 ミネソタはセクション3.3で説明されるようにエージェントSolicitationsとのこの拡張子を使用することによって、あるアクセスポイントを修理するFAからの広告に請求できます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | AP ID...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| サブタイプ| APアイダホ州。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
6 (skippable) [1]
6 (skippable)[1]
Length
長さ
5 (includes the Sub-Type field)
5 (Sub-タイプ分野を含んでいます)
Sub-Type
サブタイプ
6
6
AP ID
AP ID
Contains the 32-bit Access Point Identifier.
32ビットのアクセスポイント識別子を含んでいます。
El Malki, Ed. Experimental [Page 52] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[52ページ]RFC4881低遅延
9.7. FA IPv4 Address Extension
9.7. ファIPv4アドレス拡張子
The 32-bit FA IPv4 Address Extension contains the IPv4 address of the agent (FA). This extension MAY be present in a Registration Request message to identify the oFA as explained in Section 5.
32ビットのFA IPv4 Address Extensionはエージェント(FA)のIPv4アドレスを含んでいます。 この拡大はセクション5で説明されるようにoFAを特定するRegistration Requestメッセージに存在しているかもしれません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | IPv4 addr ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| サブタイプ| IPv4 addr… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
7 (skippable) [1]
7 (skippable)[1]
Length
長さ
5 (includes the Sub-Type field)
5 (Sub-タイプ分野を含んでいます)
Sub-Type
サブタイプ
7
7
IPv4 Address
IPv4アドレス
Contains the 32-bit IPv4 Address of the FA node.
FAノードの32ビットのIPv4 Addressを含んでいます。
10. IANA Considerations
10. IANA問題
This document defines one new extension to Mobile IPv4 Control messages and one new extension to Mobile IPv4 Router Discovery messages already maintained by IANA. This document also defines a new Mobile IPv4 Control message type to be used between FAs. To ensure correct interoperation based on this specification, IANA must reserve values in the Mobile IPv4 number space for two new extensions and one new message type. IANA must also manage the numbering spaces created by the two new extensions, the message type, and its associated Code field.
このドキュメントはモバイルIPv4 Controlメッセージへの1つの新しい拡大とIANAによって既に維持されたモバイルIPv4 Routerディスカバリーメッセージへの1つの新しい拡大を定義します。 また、このドキュメントは、FAsの間で使用されるために新しいモバイルIPv4 Controlメッセージタイプを定義します。 この仕様に基づく正しいinteroperationを確実にするために、IANAは2つの新しい拡大と1つの新しいメッセージタイプのためにモバイルIPv4数のスペースで値を予約しなければなりません。 また、IANAは2つの新しい拡大、メッセージタイプ、およびその関連Code分野によって作成された付番空間を管理しなければなりません。
10.1. New Extension Values
10.1. 新しい拡大値
Section 9 introduces two extensions.
セクション9は2つの拡大を導入します。
Generalized Link Layer and IPv4 Address (LLA) Extension for Router Discovery messages: A new Mobile IPv4 extension that follows after Mobile IPv4 ICMP Router Discovery messages (e.g., Mobile IP Agent Advertisements). The type value of this extension belongs to the
Routerディスカバリーメッセージのための一般化されたLink LayerとIPv4 Address(LLA)拡張子: モバイルIPv4 ICMP Routerディスカバリーメッセージ(例えば、モバイルIPエージェントAdvertisements)のあとについて行く新しいモバイルIPv4拡張子。 この拡大のタイプ値は属します。
El Malki, Ed. Experimental [Page 53] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[53ページ]RFC4881低遅延
Mobile IPv4 number space for Router Discovery messages maintained by IANA. The value assigned by IANA is 140. This new extension uses the Link Layer and IPv4 Address Identifier (LLA) sub-type numbering space that requires IANA management (see Section 10.2).
IANAによって維持されたRouterディスカバリーメッセージのためのモバイルIPv4数のスペース。 IANAによって割り当てられた値は140です。 この新しい拡大は、IANA管理を必要とするスペースに付番しながら、Link LayerとIPv4 Address Identifier(LLA)サブタイプを使用します(セクション10.2を見てください)。
Generalized Link Layer and IPv4 Address (LLA) Extension for Mobile IP Control messages: A new Mobile IPv4 extension appended to Mobile IP Control messages (e.g., Registration Request). The type value of this extension belongs to the Mobile IPv4 number space for extensions to Mobile IPv4 Control messages maintained by IANA. It MUST be in the skippable (128-255) range as defined in [1]. The value assigned is 138 by IANA. This new extension uses the Link Layer and IP Address Identifier (LLA) sub-type numbering space that requires IANA management (see Section 10.2).
モバイルIP Controlメッセージのための一般化されたLink LayerとIPv4 Address(LLA)拡張子: 新しいモバイルIPv4拡張子はControlメッセージ(例えば、Registration Request)をモバイルIPに追加しました。 この拡大のタイプ値はIANAによって維持されたモバイルIPv4 Controlメッセージへの拡大のためのモバイルIPv4数のスペースに属します。 それは[1]で定義されるようにskippable(128-255)範囲にあるに違いありません。 割り当てられた値はIANAによる138です。 この新しい拡大は、IANA管理を必要とするスペースに付番しながら、Link LayerとIP Address Identifier(LLA)サブタイプを使用します(セクション10.2を見てください)。
10.2. Generalized Link Layer and IP Address Identifier (LLA)
Sub-type Values
10.2. 一般化されたリンクレイヤとIPアドレス識別子(LLA)サブタイプ値
This section describes the sub-type values that are applicable to both the Generalized LLA Extensions for Mobile IP Control and Router Discovery messages. This specification makes use of the sub-type values 1-7, and all other values other than zero (reserved) are available for assignment via IETF consensus [14]. The seven sub-type values defined in this specification are:
このセクションはモバイルIP ControlとRouterディスカバリーメッセージに、両方のGeneralized LLA Extensionsに適切なサブタイプ値について説明します。 この仕様はサブタイプ値1-7を利用します、そして、ゼロ(予約される)以外の他のすべての値がIETFコンセンサス[14]で課題に利用可能です。 この仕様に基づき定義された7つのサブタイプ値は以下の通りです。
1 3GPP2 International Mobile Station Identity and
Connection ID [13]
2 3GPP International Mobile Subscriber Identity [15]
3 Ethernet 48-bit MAC address [5]
4 64-bit Global ID, EUI-64 [6]
5 Solicited IPv4 Address
6 Access Point Identifier
7 FA IPv4 Address
1 3GPP2の国際モバイル駅のIdentityとConnection ID[13]2 3GPP移動加入者識別番号[15]3のイーサネットの48ビットのMACアドレス[5]4の64ビットのGlobal ID、EUI-64[6]5Solicited IPv4 Address6のAccess Point Identifier7FA IPv4 Address
10.3. New Message Type and Code
10.3. 新しいメッセージタイプとコード
Sections 4.5 and 4.6 define two new Mobile IPv4 message types: Handoff Request and Handoff Reply. These require two type numbers to be assigned by IANA from the Mobile IPv4 Control message type address space. The Handoff Reply message also introduces its own Code field that requires IANA to manage a new Code address space. This specification makes use of the Code values 0-1, where 0 identifies a successful handoff and 1 defines a generic handoff failure. All other values are available for assignment via IETF consensus [14].
セクション4.5と4.6は2つの新しいモバイルIPv4メッセージタイプを定義します: 移管要求と移管は返答します。 これらは、2つの形式数がIANAによってモバイルIPv4 Controlメッセージタイプアドレス空間から割り当てられるのを必要とします。 また、Handoff ReplyメッセージはIANAが新しいCodeアドレス空間を管理するのを必要とするそれ自身のCode野原を挿入します。 この仕様はCode値0-1を利用します。そこでは、0がうまくいっている移管を特定して、1はジェネリック移管失敗を定義します。 他のすべての値がIETFコンセンサス[14]で課題に利用可能です。
El Malki, Ed. Experimental [Page 54] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[54ページ]RFC4881低遅延
Code Values for Mobile IP Handoff Reply Messages
モバイルIP移管応答メッセージのためのコード値
0 Successful Handoff 1 Generic Handoff Failure 2-255 Unallocated
0 うまくいっている移管1ジェネリック移管失敗2-255Unallocated
11. Security Considerations
11. セキュリティ問題
For the PRE-REGISTRATION method, as discussed in Section 3.8, the oFA and nFA MUST share a security association to authenticate and integrity protect messages transported between them. In addition, oFA must be authorized to solicit nFA based on the security association. The minimal requirement to establish a security association between FAs is that both FAs support manual pre- configuration of security associations involving shared keys. Other mechanisms to establish security associations using IKE [16] based on shared secrets or public keys may also be used. The inter-FA ICMP messages (solicitations and advertisements) MUST be authenticated and integrity protected using ESP [10]. The default ESP authentication algorithm for use in this specification is HMAC-SHA1-96 [12]. The absence of this security would allow denial-of-service attacks from malicious nodes at any distance from the FA. To secure Registration Request and Reply messages, PRE-REGISTRATION uses the security mechanisms already described in [1] and optionally [11].
セクション3.8で議論するようなoFAとnFAが共有しなければならないPRE-REGISTRATIONメソッドのために、認証するセキュリティ協会と保全はそれらの間で輸送されたメッセージを保護します。 さらに、セキュリティ協会に基づくnFAに請求するのをoFAを認可しなければなりません。 FAsの間のセキュリティ協会を設立するという最小量の要件は両方のFAsが共有されたキーにかかわるセキュリティ協会の手動のプレ構成をサポートするということです。 また、共有秘密キーか公開鍵に基づくIKE[16]を使用することでセキュリティ協会を確立する他のメカニズムは使用されるかもしれません。 相互FA ICMPメッセージ(懇願と広告)を認証しなければなりませんでした、そして、保全は、超能力[10]を使用することで保護されました。 この仕様に基づく使用のためのデフォルト超能力認証アルゴリズムはHMAC-SHA1-96[12]です。 このセキュリティの欠如はFAからのどんな遠方の悪意があるノードからもサービス不能攻撃を許容するでしょう。 Registration RequestとReplyメッセージ、PRE-REGISTRATION用途がセキュリティー対策であると既に機密保護するのが[1]に任意に[11]について説明しました。
POST-REGISTRATION introduces a new change to Mobile IPv4, which is the possibility that an MN may receive packets from an FA with which it has not yet performed a Mobile IPv4 Registration. It is not recommended that the MN drop packets from unknown FAs since it would effectively eliminate the advantages of POST-REGISTRATION. From a security viewpoint, dropping packets from unknown FAs would not provide significant protection for an MN from any attack. This is because any malicious host may use the MN's home address to send packets to the MN through its current known FA; therefore, processing packets received from unknown FAs would not provide worse security than with normal Mobile IPv4.
ポスト-REGISTRATIONはモバイルIPv4に新しい変化を紹介します。(IPv4はミネソタがまだそれとモバイルIPv4 Registrationを実行していないFAからパケットを受けるかもしれない可能性です)。 事実上、ポスト-REGISTRATIONの利点を排除するでしょう、したがって、ミネソタが未知のFAsからパケットを下げることが勧められません。 セキュリティ観点から、未知のFAsからパケットを下げるのは重要な保護をどんな攻撃からもミネソタに提供しないでしょう。 これはどんな悪意があるホストも現在の知られているFAを通してパケットをミネソタに送るのにミネソタのホームアドレスを使用するかもしれないからです。 したがって、未知のFAsから受け取られた処理パケットは正常なモバイルIPv4より悪いセキュリティを提供しないでしょう。
In a similar way to PRE-REGISTRATION, in POST-REGISTRATION, oFA and nFA MUST share a security association required to protect the Handoff Request and Reply messages. The minimal requirement to establish a security association between FAs is that the FAs support manual pre- configuration of security associations involving shared keys. Other mechanisms to establish security associations using IKE [16] based on shared secrets or public keys may also be used. The Handoff Request and Reply messages MUST be authenticated using the FA-FA authentication extension [11] that uses the default algorithm specified in [7]. The absence of this security would allow impersonation attacks and denial-of-service attacks.
PRE-REGISTRATIONへの同様の道、ポスト-REGISTRATIONでは、oFAとnFAはHandoff Requestを保護するのに必要であるセキュリティ協会とReplyメッセージを共有しなければなりません。 FAsの間のセキュリティ協会を設立するという最小量の要件はFAsが共有されたキーにかかわるセキュリティ協会の手動のプレ構成をサポートするということです。 また、共有秘密キーか公開鍵に基づくIKE[16]を使用することでセキュリティ協会を確立する他のメカニズムは使用されるかもしれません。 [7]で指定されたデフォルトアルゴリズムを使用するFA-FA認証拡張子[11]を使用して、Handoff RequestとReplyメッセージを認証しなければなりません。 このセキュリティの欠如はものまね攻撃とサービス不能攻撃を許容するでしょう。
El Malki, Ed. Experimental [Page 55] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[55ページ]RFC4881低遅延
The minimal requirement is that all FAs involved in low latency handoffs MUST support manual pre-configuration of peer-to-peer security associations with neighboring FAs, involving shared secrets and are already required to support the default algorithms of [1]. Other mechanisms to establish security associations using IKE [16] based on shared or public keys may also be used.
最小量の要件は低遅延handoffsにかかわるすべてのFAsが共有秘密キーにかかわって、隣接しているFAsとのピアツーピアセキュリティ協会の手動のプレ構成をサポートしなければならなくて、デフォルトが[1]のアルゴリズムであるとサポートするのに既に必要であるということです。 また、共有にされるに基づいてIKE[16]を使用することでセキュリティ協会を確立する他のメカニズムか公開鍵が使用されるかもしれません。
Since the techniques outlined in this document depend on particular L2 information (triggers) to optimize performance, some level of L2 security is assumed. Both PRE- and POST-REGISTRATION techniques depend on L2 triggers, but the L2 security implications are different for the two techniques.
本書では概説されたテクニックが性能を最適化するために特定のL2情報(引き金)によるので、何らかのレベルのL2セキュリティは想定されます。 PREとポスト-REGISTRATIONのテクニックの両方がL2引き金によりますが、2つのテクニックにおいて、L2セキュリティ含意は異なっています。
In particular, in POST-REGISTRATION, the L2 triggers initiate the establishment of tunnels that route IPv4 packets for the MN to its new location. Therefore, the L2 triggers MUST be secured against any tampering by malicious nodes, either mobile or within the wired network. The L2 addresses or IPv4 addresses for the MN and the FAs that appear in the L2 triggers MUST correspond to the actual nodes that are participating in the handoff. If there is any possibility that tampering may occur, the recipient of an L2 trigger MUST have some way of authenticating the L2 information. Wireless networks that do not provide such features will be subject to impersonation attacks, where malicious nodes could cause FAs to believe that an MN has moved to other service areas or to allow a bogus MN to obtain unauthorized service from an FA prior to performing a Mobile IPv4 Registration. In POST-REGISTRATION, the L2 triggers would typically be sent between a wireless base station and the FA. No standard protocol exists at this time to communicate the L2 trigger information, but it is important that any future protocol used for this purpose provides adequate security. If the wireless base station and FA were integrated, then this security threat would not apply. Also the layer 2 control messages on the wireless link must be secured appropriately to prevent a malicious node from running impersonation attacks and causing unwanted L2 triggers to be generated. Integrity and replay protection would be required to avoid impersonation threats and resource consumption threats where a malicious node replays old messages to cause resource consumption. This depends on the type of L2 security of the wireless link. For example, in cellular technologies, the control messages are secured, although the type of security varies depending on the cellular standard, but this is not typically the case in WLAN IEEE 802.11 networks.
ポスト-REGISTRATIONでは、特に、L2引き金はIPv4パケットをミネソタに発送するトンネルの設立を新しい位置に開始します。 したがって、いずれもに対して悪意があるノードでいじるどちらのまたモバイルでもあると機密保護されるか、有線ネットワークの中にL2引き金があるに違いありません。 L2引き金に現れるミネソタとFAsのためのL2アドレスかIPv4アドレスが移管に参加している実際のノードに一致しなければなりません。 何か改ざんが起こるかもしれない可能性があれば、L2引き金の受取人には、L2情報を認証する何らかの方法がなければなりません。 そのような特徴を提供しないワイヤレス・ネットワークはものまね攻撃を受けることがあるでしょう、悪意があるノードが、FAsが、ミネソタが他のサービスエリアに移行したと信じているか、またはモバイルIPv4 Registrationを実行する前ににせのミネソタがFAから権限のないサービスを得るのを許容することを引き起こす場合があったところで。 ポスト-REGISTRATIONでは、ワイヤレスの基地局とFAの間にL2引き金を通常送るでしょう。 標準プロトコルは全くこのとき、L2引き金の情報を伝えるために存在しませんが、このために使用されるどんな将来のプロトコルも十分な安全性を提供するのは、重要です。 ワイヤレスの基地局とFAが統合しているなら、この軍事的脅威は適用されないでしょうに。 また、悪意があるノードでものまね攻撃を述べて、求められていないL2引き金を生成するのを防ぐために適切にワイヤレスのリンクに関する層2のコントロールメッセージを保証しなければなりません。 保全と反復操作による保護が、悪意があるノードがリソース消費を引き起こす古いメッセージを再演するところでものまねの脅威とリソース消費の脅威を避けるのに必要でしょう。 これはワイヤレスのリンクのL2セキュリティのタイプに頼っています。 例えば、携帯電話技術で、コントロールメッセージを保証して、しかし、セル規格、これによって、セキュリティのタイプは異なりますが、通常WLAN IEEEのケースは802.11のネットワークではありませんか?
In PRE-REGISTRATION, the security of L2 triggers has different implications. The PRE-REGISTRATION technique depends on Mobile IPv4 security between MN and FA, so the same security considerations in [1] apply. Should malicious nodes be able to generate or modify L2
PRE-REGISTRATIONでは、L2引き金のセキュリティは異なった意味を持っています。 PRE-REGISTRATIONのテクニックがミネソタとFAの間のモバイルIPv4セキュリティによるので、[1]の同じセキュリティ問題は適用されます。 悪意があるノードは、L2を生成するはずですか、変更するはずであることができますか?
El Malki, Ed. Experimental [Page 56] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[56ページ]RFC4881低遅延
trigger information (i.e., L2-ST or L2-TT), this would cause advertisements to be sent to the MN. They would consume wireless resources and processing in the MN, but would not allow an impersonation attack. In order to prevent such denial-of-service attacks, there should be a limit on the number of advertisements that an FA (oFA) will relay to the MN as a result of the reception of L2 triggers. This number will depend on the L2 technology, and the default limit is 10 per second.
情報(すなわち、L2-STかL2-TT)の引き金となってください、そして、これは広告をミネソタに送るでしょう。 彼らは、ミネソタでワイヤレスのリソースと処理を消費するでしょうが、ものまね攻撃を許さないでしょう。 そのようなサービス不能攻撃を防ぐために、限界がFA(oFA)がL2引き金のレセプションの結果、ミネソタにリレーする広告の数にあるべきです。 この数をL2技術に依存するでしょう、そして、デフォルト限界は1秒あたり10です。
12. Acknowledgements
12. 承認
The authors want to thank Lennart Bang, Bryan Hartwell, Joel Hortelius, Gianluca Verin, and Jonathan Wood for valuable comments and suggestions on the whole document. The authors also thank the Mobile IPv4 WG chairs, Phil Roberts and Basavaraj Patil, for their input.
作者は全体のドキュメントの上に貴重なコメントと提案についてレナートBang、ブライアン・ハートウェル、ジョエルHortelius、ジャンルカ・ベリン、およびジョナサンWoodに感謝したがっています。 また、作者は彼らの入力についてモバイルIPv4 WGいす(フィル・ロバーツとBasavarajパティル)に感謝します。
13. References
13. 参照
13.1. Normative References
13.1. 引用規格
[1] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[1] パーキンス、C.、エド、「IPv4"、RFC3344、2002年8月のIP移動性サポート。」
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Montenegro, G., Ed., "Reverse Tunneling for Mobile IP, revised",
RFC 3024, January 2001.
[3] モンテネグロ、G.、エドRFC3024、「モバイルIPのためにTunnelingを逆にして、改訂され」て、2001年1月。
[4] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina,
"Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
2000年3月の[4] ファリナッチとD.と李とT.とハンクスとS.とマイヤー、D.とP.Traina、「一般ルーティングのカプセル化(GRE)」RFC2784。
[5] Plummer, D., "Ethernet Address Resolution Protocol: Or
Converting Network Protocol Addresses to 48.bit Ethernet Address
for Transmission on Ethernet Hardware", STD 37, RFC 826,
November 1982.
[5] プラマー、D.、「イーサネットアドレス決議は以下について議定書の中で述べます」。 「または、ネットワーク・プロトコルを変換するのは、イーサネットハードウェアの上でイーサネットがトランスミッションのためのアドレスであると48.bitに扱う」STD37、RFC826、1982年11月。
[6] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
Registration Authority",
http://standards.ieee.org/regauth/oui/tutorials/EUI64.html,
March 1997.
[6]IEEE、「64ビットのグローバルな識別子(EUI-64)登録局のためのガイドライン」、 http://standards.ieee.org/regauth/oui/tutorials/EUI64.html 、1997年3月。
[7] Perkins, C., Calhoun, P., and J. Bharatia, "Mobile IPv4
Challenge/Response Extensions (Revised)", RFC 4721, January
2007.
[7] パーキンス、C.、カルフーン、P.、およびJ.Bharatia、「モバイルIPv4挑戦/応答拡大(改訂される)」、RFC4721、2007年1月。
El Malki, Ed. Experimental [Page 57] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[57ページ]RFC4881低遅延
[8] Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256,
September 1991.
[8] デアリング、S.、エド、「ICMPルータ発見メッセージ」、RFC1256、9月1991日
[9] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
September 1981.
[9] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル」、STD5、RFC792、1981年9月。
[10] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
December 2005.
[10] ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4303、2005年12月。
[11] Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4
Regional Registration", RFC 4857, June 2007.
[11]FogelstroemとE.とイェンソン、A.とC.パーキンス、「モバイルIPv4地方の登録」、RFC4857、2007年6月。
[12] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP
and AH", RFC 2404, November 1998.
そして、[12] マドソン、C.、およびR.グレン、「超能力の中のHMAC-SHA-1-96の使用、ああ、」、RFC2404、11月1998日
13.2. Informative References
13.2. 有益な参照
[13] TIA/EIA/IS-2000.
[13] ティア/EIA/、-2000です。
[14] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[14]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[15] 3GPP TS 23.003 (www.3gpp.org).
[15] 3GPP t23.003(www.3gpp.org)。
[16] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[16] コーフマン、C.、エド、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、12月2005日
El Malki, Ed. Experimental [Page 58] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[58ページ]RFC4881低遅延
Appendix A - Gateway Foreign Agents
付録A--ゲートウェイの外国人のエージェント
The Mobile IPv4 Regional Registration specification [11] introduces the Gateway Foreign Agent (GFA), as a mobility agent that two FAs providing service to an MN have in common. Figure A.1 provides an example of an MN's initial registration through the GFA. If this is the first registration message, the message MUST be forwarded to the HA. All packets sent to the MN will be delivered to the GFA, which in turn will forward the packets to the FA servicing the MN.
モバイルIPv4 Regional Registration仕様[11]は移動性エージェントとしてのゲートウェイのForeignエージェント(GFA)のためにミネソタに対するサービスを提供すると共通であるその2FAsを導入します。 図A.1はGFAを通してミネソタの新規登録に関する例を提供します。 これが最初の登録メッセージであるなら、メッセージをHAに転送しなければなりません。 ミネソタに送られたすべてのパケットがGFAに提供されるでしょう。(順番に、GFAはミネソタにサービスを提供するFAにパケットを送るでしょう)。
RegReq +-----+ RegReq
+----------->| oFA |--------------+
| +-----+ |
| v
+----+ +-----+ RegReq +----+
| MN | | GFA |<------->| HA |
+----+ +-----+ +----+
RegReq+-----+ RegReq+----------->| oファ|--------------+ | +-----+ | | +に対して----+ +-----+ RegReq+----+ | ミネソタ| | GFA| <、-、-、-、-、-、--、>| ハ| +----+ +-----+ +----+
+-----+
| nFA |
+-----+
+-----+ | nFA| +-----+
Figure A.1 - Initial Registrations through GFA
図A.1--GFAを通した初期の登録証明書
If the MN moves to an nFA that is serviced by a GFA common with oFA, the MN MAY issue a Regional Registration Request (see Figure A.2). The Regional Registration message does not need to be forwarded to the HA, since the MN's traffic can still be delivered to the same GFA. This optimized approach effectively reduces the latency involved in the registration process.
ミネソタがoFAについて一般的なGFAによって調整されるnFAに移行するなら、ミネソタはRegional Registration Requestを発行するかもしれません(図A.2を見てください)。 Regional RegistrationメッセージによってHAに送られる必要はありません、まだミネソタのトラフィックを同じGFAに提供できるので。 事実上、この最適化されたアプローチは登録手続にかかわるレイテンシを減少させます。
+-----+
| oFA |
+-----+
+----+ +-----+ +----+
| MN | | GFA | | HA |
+----+ +-----+ +----+
| ^
| +-----+ |
+------------>| nFA |-------------+
RegRegReq +-----+ RegRegReq
+-----+ | oファ| +-----+ +----+ +-----+ +----+ | ミネソタ| | GFA| | ハ| +----+ +-----+ +----+ | ^ | +-----+ | +------------>| nFA|-------------+ RegRegReq+-----+ RegRegReq
Figure A.2 - Regional Registration through GFA
図A.2--GFAを通した地方の登録
Note that the GFA may also be the MN's first-hop router.
また、GFAがミネソタの最初に、ホップルータであるかもしれないことに注意してください。
El Malki, Ed. Experimental [Page 59] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[59ページ]RFC4881低遅延
Appendix B - Low-Latency Handoffs for Multiple-Interface MNs
付録B--複数のインタフェースMNsのための低遅延Handoffs
For MNs that have two wireless network interfaces, either on the same wireless network or on wireless networks having different wireless L2 technologies, the techniques discussed in this document may be unnecessary if the Mobile IPv4 stack on the MN allows switching an IPv4 address binding between interfaces. This Appendix discusses how multiple wireless interfaces can aid low-latency handoff.
同じワイヤレス・ネットワークの上、または、異なったワイヤレスのL2技術を持っているワイヤレス・ネットワークの上に2つのワイヤレス・ネットワークインタフェースを持っているMNsに関しては、ミネソタでのモバイルIPv4スタックでIPv4アドレス結合をインタフェースの間に切り換えるなら、本書では議論したテクニックは不要であるかもしれません。 このAppendixは複数のワイヤレスインターフェースがどう低遅延移管を支援できるかについて議論します。
+------+ +---------+
| HA |--------| (GFA) |
+------+ +---------+
/ \
... ...
/ \
/ \
+------+ +------+
| oFA | | nFA |
+------+ +------+
| |
+------+ +------+
| RN1 | | RN2 |
+------+ +------+
+------+
| MN | --------->
+------+
Movement
+------+ +---------+ | ハ|--------| (GFA) | +------+ +---------+ / \ ... ... / \ / \ +------+ +------+ | oファ| | nFA| +------+ +------+ | | +------+ +------+ | RN1| | RN2| +------+ +------+ +------+ | ミネソタ| --------->+------+ 動き
Figure B.1 - Network Model for Mobile IPv4 with Multi-Access
図B.1--マルチアクセスがあるモバイルIPv4のネットワークモデル
Figure B.1 illustrates the normal and hierarchical MIPv4 models. As shown in the figure, assume that the MN is connected to Radio Network 1 (RN1) and is registered with oFA through which it is receiving traffic. Suppose MN enters the coverage area of RN2 and nFA and that it prefers connectivity to this network for reasons beyond the scope of this document (e.g., user preferences, cost, QoS available, etc.). The MN activates the interface to RN2 but continues communicating through RN1. The MN may solicit advertisements from nFA through the interface connected to RN1 to speed up the handoff process, provided there is no TTL restriction, or it can solicit advertisements through the interface connected to RN2 if it has been configured for IPv4 traffic.
図B.1は正常で階層的なMIPv4モデルを例証します。 図に示されるように、ミネソタがRadio Network1(RN1)につなげられて、それがトラフィックを受けているoFAに登録されると仮定してください。 ミネソタがRN2と、nFAとその適用範囲の地域に入るなら、それはこのドキュメント(例えば、ユーザー選択、費用、利用可能なQoSなど)の範囲を超えた理由でこのネットワークより接続性を好みます。 ミネソタは、RN2にインタフェースを動かしますが、RN1を通して交信し続けています。 ミネソタはnFAから移管プロセスを加速するためにRN1に接続されたインタフェースまで広告を勧誘するかもしれません、TTL制限が全くないか、またはそれがIPv4トラフィックのために構成されたならRN2に接続されたインタフェースを通して広告を勧誘できるなら。
Once the MN is registered with nFA and is successfully receiving and transmitting through the new network, it tears down the interface to RN1. If the MN has enough time to complete this procedure without incurring degraded service or disconnection, the MN would experience a seamless multi-access handoff, but it may not be possible in all
ミネソタは、一度、nFAとともに記名して、首尾よく受信されています、そして、新しいネットワークを通して伝わって、それはRN1までインタフェースを取りこわします。 ミネソタには降格しているサービスか断線を被らないでこの手順を完了できるくらいの時間がありますが、ミネソタがシームレスのマルチアクセス移管を経験するでしょうが、それが全部で可能でないかもしれないなら
El Malki, Ed. Experimental [Page 60] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[60ページ]RFC4881低遅延
cases, due to network coverage or for other reasons. Should multiple interface handoff be possible, then the low-latency methods described in this document are not necessary.
ネットワーク適用範囲のためか他の理由によるケース。 複数のインタフェース移管が可能であるべきであり、次に、本書では説明された低遅延メソッドは必要ではありません。
In order to support the possible failure of the connectivity with the new network (RN2/nFA) in the short period following handoff, the MN may use the S bit in its Mobile IPv4 Registration Request to maintain simultaneous bindings with both its existing (HA or GFA) binding with oFA and a new binding with nFA.
新しいネットワーク(RN2/nFA)と共に短期の次の移管で接続性の可能な失敗をサポートして、ミネソタは、両方を存在にさせている中の同時の結合(HAかGFA)をoFAとnFAとの新しい結合で拘束力があるように維持するのにモバイルIPv4 Registration RequestでSビットを使用するかもしれません。
Appendix C - PRE-REGISTRATION Message Summary
付録C--プレ登録メッセージ概要
This appendix contains a quick reference for IPv4 and layer 2 addresses to be used in PRE-REGISTRATION messages.
この付録はIPv4と層2のアドレスがPRE-REGISTRATIONメッセージで使用されるクイックリファレンスを含んでいます。
Proxy Router Advertisement (PrRtAdv) This is a standard Router/Agent Advertisement [1] with the following characteristics:
プロキシRouter Advertisement、(PrRtAdv) これは以下の特性がある標準のRouter/エージェントAdvertisement[1]です:
Source IPv4 Address: nFA IPv4 Address
Source Layer 2 Address: oFA L2 Address
Destination IPv4 Address: MN IPv4 Address (from PrRtSol)
Destination Layer 2 Address: MN L2 Address (from PrRtSol)
LLA Extension (defined in this spec): containing nFA Layer 2
Address.
ソースIPv4アドレス: nFA IPv4は、ソース層2がアドレスであると扱います: oファL2は、目的地IPv4がアドレスであると扱います: ミネソタIPv4は、目的地層2がアドレスであると扱います(PrRtSolから): ミネソタL2 Address(PrRtSolからの)LLA Extension(この仕様では、定義されます): nFA Layer2Addressを含んでいます。
Proxy Router Solicitation (PrRtSol) This is a standard Router/Agent Solicitation [1] with the following characteristics:
プロキシRouter Solicitation、(PrRtSol) これは以下の特性がある標準のRouter/エージェントSolicitation[1]です:
Source IPv4 Address: MN Address
Source Layer 2 Address: MN Address
Destination IPv4 Address: oFA Address (from source address of
previous Router Advertisement or PrRtAdv)
Destination Layer 2 Address: oFA Address (from source address of
previous Router Advertisement or PrRtAdv LLA)
LLA Extension (defined in this spec): depends on the layer 2
technology (e.g., typically for WLAN, this would be the BSSID of
the new WLAN Access Point)
ソースIPv4アドレス: Mnアドレスソース層2のアドレス: Mnアドレス送付先IPv4アドレス: oFA Address(前のRouter AdvertisementかPrRtAdvのソースアドレスからの)目的地Layer2Address: oFA Address(前のRouter AdvertisementかPrRtAdv LLAのソースアドレスからの)LLA Extension(この仕様では、定義されます): 層2の技術によります。(例えば、通常、WLANに関して、これは新しいWLAN Access PointのBSSIDでしょう)
Registration Request (as seen on MN-oFA link) This is a Mobile IPv4 Registration Request message [1] with the following characteristics:
登録Request、(ミネソタ-oFAリンクの上に見られるように) これは以下の特性があるモバイルIPv4 Registration Requestメッセージ[1]です:
Source IPv4 Address: MN Address
Source Layer 2 Address: MN Address
Destination IPv4 Address: nFA Address (from source addr of
PrRtAdv)
ソースIPv4アドレス: Mnアドレスソース層2のアドレス: Mnアドレス送付先IPv4アドレス: nFAアドレス(PrRtAdvのソースaddrからの)
El Malki, Ed. Experimental [Page 61] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[61ページ]RFC4881低遅延
Destination Layer 2 Address: Default Router (i.e., oFA Address)
LLA Extension (defined in this spec): containing the MN's L2
address that must be used by nFA. This will typically be an
Ethernet MAC address but other types can be used as specified in
Section 9 of this document.
目的地層2のアドレス: デフォルトRouter(すなわち、oFA Address)LLA Extension(この仕様では、定義されます): nFAが使用しなければならないミネソタのL2アドレスを含んでいます。 これは通常イーサネットMACアドレスになるでしょうが、このドキュメントのセクション9で指定されるように他のタイプを使用できます。
Although this is not mandated, an MN implementation may set the S bit (see Section 6) in Registration Request messages to improve the handoff and avoid problems due to failed layer 2 handoffs and layer 2 ping-pong effects between two base stations.
これは強制されませんが、ミネソタの実現はRegistration RequestメッセージのSビット(セクション6を見る)に2つの基地局の間の失敗した層2のhandoffsと層2のピンポン効果のため移管を改良して、問題を避けるように設定するかもしれません。
Registration Reply (as seen on oFA-MN link) This is a Mobile IPv4 Registration Reply message [1] with the following characteristics:
登録Reply、(oFA-ミネソタのリンクの上に見られるように) これは以下の特性があるモバイルIPv4 Registration Replyメッセージ[1]です:
Source IPv4 Address: nFA Address
Source Layer 2 Address: oFA Address
Destination IPv4 Address: MN Address (from source of Registration
Request)
Destination Layer 2 Address: MN Address (from source of
Registration Request)
ソースIPv4アドレス: nFAはソース層2のアドレスを記述します: oファアドレス送付先IPv4アドレス: ミネソタAddress(Registration Requestの源からの)目的地Layer2Address: Mnアドレス(Registration Requestの源からの)
El Malki, Ed. Experimental [Page 62] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[62ページ]RFC4881低遅延
Contributing Authors
作者を寄付します。
Pat Calhoun Cisco Systems EMail: pcalhoun@cisco.com
カルフーンシスコシステムズメールを軽くたたいてください: pcalhoun@cisco.com
Tom Hiller Lucent Technologies EMail: tom.hiller@lucent.com
トムHillerルーセントテクノロジーズはメールされます: tom.hiller@lucent.com
James Kempf NTT DoCoMo USA Labs EMail: kempf@docomolabs-usa.com
ジェームスケンフNTTドコモ米国研究室はメールされます: kempf@docomolabs-usa.com
Peter J. McCann Motorola Labs EMail: pete.mccann@motorola.com
ピーターJ.マッキャンモトローラ研究室はメールされます: pete.mccann@motorola.com
Ajoy Singh Motorola EMail: asingh1@email.mot.com
AjoyシンモトローラEMail: asingh1@email.mot.com
Hesham Soliman Elevate Technologies EMail: Hesham@elevatemobile.com
Heshamソリマンは技術メールを上げます: Hesham@elevatemobile.com
Sebastian Thalanany US Cellular EMail: Sebastian.thalanany@uscellular.com
セバスチャンThalanany米国セルのメール: Sebastian.thalanany@uscellular.com
Editor's Address
エディタのアドレス
Karim El Malki Athonet EMail: karim@athonet.com
カリム高架鉄道Malki Athonetはメールします: karim@athonet.com
El Malki, Ed. Experimental [Page 63] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007
エド高架鉄道Malki、IPv4 Handoffs2007年6月のモバイルの実験的な[63ページ]RFC4881低遅延
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に情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
El Malki, Ed. Experimental [Page 64]
高架鉄道Malki、エド、実験的[64ページ]
一覧
スポンサーリンク
