Network Working Group H. Yokota
Request for Comments: 5271 KDDI Lab
Category: Informational G. Dommety
Cisco Systems, Inc.
June 2008
Mobile IPv6 Fast Handovers for 3G CDMA Networks
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
抽象
Mobile IPv6 is designed to maintain its connectivity while moving from one network to another. It is adopted in 3G CDMA networks as a way to maintain connectivity when the mobile node (MN) moves between access routers. However, this handover procedure requires not only movement detection by the MN, but also the acquisition of a new Care-of Address and Mobile IPv6 registration with the new care-of address before the traffic can be sent or received in the target network. During this period, packets destined for the mobile node may be lost, which may not be acceptable for a real-time application such as Voice over IP (VoIP) or video telephony. This document specifies fast handover methods in the 3G CDMA networks in order to reduce latency and packet loss during handover.
モバイルIPv6は、あるネットワークから別のネットワークに移動させながら、その接続性を維持するように設計されています。これは、モバイルノード（MN）は、アクセスルータ間を移動する際に接続を維持する方法として、3G CDMAネットワークにおいて採用されています。トラフィックがターゲットネットワークに送信または受信することができます前に、しかし、このハンドオーバ手順は、移動MNによって検出するだけでなく、新しい気付アドレスとモバイルIPv6登録新気付けアドレスでの獲得だけではないが必要です。この期間中、モバイルノード宛てのパケットは、ボイスオーバーIP（VoIP）のようなリアルタイムアプリケーションまたはビデオテレフォニーのために許容できない可能性がある、失われることがあります。この文書では、ハンドオーバー中の待ち時間とパケット損失を低減するために、3G CDMAネットワークにおける高速ハンドオーバ方式を指定します。
Table of Contents
目次
1. Introduction ....................................................2
2. Requirements Notation ...........................................3
3. Terminology .....................................................3
4. Network Reference Model for Mobile IPv6 over 3G CDMA Networks ...4
5. Fast Handover Procedures ........................................6
5.1. Predictive Fast Handover ...................................7
5.2. Reactive Fast Handover ....................................12
5.3. Considerations on the Link Indications ....................15
6. Message Format .................................................15
6.1. Handover Assist Information Option ........................15
6.2. Mobile Node Identifier Option .............................16
6.3. New Flag Extension to FBU Message .........................17
6.4. New Flag Extension to PrRtAdv Message .....................17
7. Security Considerations ........................................18
8. IANA Considerations ............................................18
9. Acknowledgements ...............................................19
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................19
Mobile IPv6 [2] allows mobile nodes (MNs) to maintain persistent IP connectivity while the MN moves around in the IPv6 network. It is adopted in 3G CDMA networks for handling host-based mobility management [12]. During handover, however, the mobile node (MN) needs to switch the radio link to obtain a new Care-of Address (CoA) and to re-register with the home agent (HA), which may cause a communication disruption. This is not desirable for real-time applications such as VoIP and video telephony. To reduce this disruption time or latency, a fast handover protocol for Mobile IPv6 [3] is proposed. RFC 4260 [7] further describes how this Mobile IPv6 Fast Handover could be implemented on link layers conforming to the IEEE 802.11 suite of specifications. However, 3G CDMA and IEEE 802.11 networks are substantially different in the radio access, the representations of the network nodes or parameters, and the network attachment procedures; for example, the beacon scanning or New Access Router (NAR) discovery based on [Access Point Identifier, Access Router-info (AP-ID, AR-info)] tuples specified in RFC 4260 can not be directly applied to 3G CDMA networks. This document therefore specifies how Mobile IPv6 fast handovers can be applied in the 3G CDMA networks.
モバイルIPv6 [2] MNがIPv6ネットワーク中を移動する間、移動ノード（MNの）は、永続IP接続性を維持することを可能にします。これは、[12]ホスト・ベースのモビリティ管理を処理するための3G CDMAネットワークにおいて採用されています。ハンドオーバー時には、しかし、モバイルノード（MN）は、通信の中断を引き起こす可能性がある、新しい気付アドレス（CoA）を取得するために、ホームエージェント（HA）に再登録するために無線リンクを切り替える必要があります。これは、VoIPやビデオ電話などのリアルタイムアプリケーションのために望ましいものではありません。この中断時間や待ち時間を低減するために、モバイルIPv6の高速ハンドオーバプロトコルは、[3]が提案されています。 RFC 4260 [7]さらに、このモバイルIPv6高速ハンドオーバが仕様のIEEE 802.11スイートに準拠したリンク層の上に実装する方法について説明します。しかし、3G CDMAおよびIEEE 802.11ネットワークは、ネットワークノードまたはパラメータ、およびネットワーク接続手順の表現無線アクセスにおいて実質的に異なります。例えば、RFC 4260に指定されたビーコンスキャンまたは[アクセスポイント識別子、アクセスルータ-INFO（AP-ID、AR-INFO）]に基づいて、新たなアクセスルータ（NAR）発見タプル直接3G CDMAネットワークに適用することができません。従って、この文書は、モバイルIPv6高速ハンドオーバは、3G CDMAネットワークで適用することができる方法を指定します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[1]に記載のように解釈されます。
This document refers to [3] for Mobile IPv6 fast handover terminology. Terms that first appear in this document are defined below:
この文書では、[3]のためのモバイルIPv6高速ハンドオーバの用語を意味します。まず、この文書に表示される用語を以下に定義されています。
Access Network Identifier (ANID): An identifier that is used by the Packet Data Serving Node (PDSN) to determine whether the MN is being handed off from the access network that was not previously using this PDSN. Anytime the MN crosses into a new region, which is defined by the ANID, it must re-register with that access network. The ANID is further composed of the System ID (SID), Network ID (NID), and Packet Zone ID (PZID) and these values are administered by the operator. The lengths of the SID, NID, and PZID are 2 octets, 2 octets, and 1 octet, respectively. Thus, that of the ANID occupies 5 octets [11].
アクセスネットワーク識別子（ANID）：MNが以前にこのPDSNを使用していなかったアクセスネットワークからハンドオフされているかどうかを決定するために、パケットデータサービングノード（PDSN）によって使用される識別子。いつでもMNはANIDによって定義され、新たな地域へ横切る、それがそのアクセスネットワークに再登録する必要があります。 ANIDは、さらに、システムID（SID）、ネットワークID（NID）、パケットゾーンID（PZID）から構成され、これらの値は、オペレータによって投与されます。 SID、NID、およびPZIDの長さは、それぞれ、2つのオクテット、2つのオクテット、及び1つのオクテットです。したがって、ANIDとは、5つのオクテット[11]占めます。
Forward Pilot Channel: A portion of the Forward Channel that carries the pilot. The Forward Channel is a portion of the physical layer channels transmitted from the 3G CDMA access network to the MN. Further, several sets of pilots (e.g., the active set or neighbor set) are defined to determine when and where to handover.
順方向パイロットチャンネル：パイロットを運ぶ順方向チャネルの部分。順方向チャネルは、MNへの3G CDMAアクセスネットワークから送信された物理層チャネルの一部です。さらに、パイロット（例えば、アクティブセット又は隣接セット）のいくつかのセットがいつ、どこで、ハンドオーバーするかを決定するために定義されています。
Home Link Prefix (HLP): The prefix address assigned to the home link where the MN should send the binding update message. This is also called Home Network Prefix (HNP) and one of the bootstrap parameters for the MN.
ホームリンクプレフィックス（HLP）：MNは、バインディング更新メッセージを送信しなければならないホームリンクに割り当てられたプレフィックスアドレス。これは、ホームネットワークプレフィックス（HNP）とMNのためのブートストラップパラメータの一つと呼ばれています。
International Mobile Subscriber Identity (IMSI): The IMSI is a string of decimal digits, up to a maximum of 15 digits, that identifies a unique mobile terminal or mobile subscriber internationally. The IMSI consists of three fields: the Mobile Country Code (MCC), the Mobile Network Code (MNC), and the Mobile Subscriber Identification Number (MSIN). An example of the IMSI is "440701234567890", where "440" is the MCC, "70" is the MNC, and "1234567890" is the MSIN. The IMSI conforms to the ITU-T E.212 numbering standard [6]. In this specification, IMSI is an ASCII string that consists of not more than 15 decimal digits (ASCII values between 30 and 39 hexadecimal), one character per IMSI digit. The above example would therefore be encoded as "34 34 30 37 30 31 32 33 34 35 36 37 38 39 30" in hexadecimal notation.
国際移動加入者識別（IMSI）：IMSIは国際ユニークなモバイル端末またはモバイル加入者を識別する15桁の最大値までの桁の文字列です。移動国コード（MCC）、モバイルネットワークコード（MNC）、およびモバイル加入者識別番号（MSIN）：IMSIは、三つのフィールドで構成されています。 IMSIの例は、「440701234567890」である「440」がMCC、「70」であるMNCであり、「1234567890」がMSINです。 IMSIは、ITU-T E.212番号規格に準拠[6]。本明細書では、IMSIは、以下15桁（30と39進数の間のASCII値）、IMSI桁ごとに一つの文字から成るASCII文字列です。上記の例は、したがって、16進数で "34 34 30 37 30 31 32 33 34 35 36 37 38 39 30" として符号化されるであろう。
Mobile Identity (MN ID): An identifier of the Mobile Node that is used by the access network. The value (e.g., IMSI) is unique within the operator's network.
モバイルID（MN ID）：アクセスネットワークによって使用されている移動ノードの識別子。値（例えば、IMSI）は、オペレータのネットワーク内で一意です。
Packet Data Serving Node (PDSN): An entity that routes MN originated or MN terminated packet data traffic. A PDSN establishes, maintains, and terminates link-layer sessions to MNs. A PDSN is the access router in the visited access provider network.
パケットデータサービングノード（PDSN）：ルートはMNを発信またはMNは、パケット・データ・トラフィックを終端するエンティティ。 PDSNは、確立し維持し、MN群へのリンク層セッションを終了します。 PDSNは、訪問先のアクセス・プロバイダ・ネットワーク内のアクセスルータです。
Sector Address Identifier (SectorID): A typical cell divides its coverage area into several sectors. In 3G CDMA systems, each sector uses a different PN (Pseudo Noise) code offset and is associated with SectorID. The SectorID is 128 bits long and can be represented in the IPv6 address format [8].
セクタアドレス識別子（セクタID）：典型的な細胞は、いくつかのセクタにそのサービスエリアを分割します。 3G CDMAシステムでは、各セクタは、異なるPN（擬似雑音）コードオフセットを使用し、セクタIDに関連付けられています。セクタIDは、128ビット長であり、IPv6アドレス形式[8]で表すことができます。
Figure 1 shows a simplified reference model of the Mobile IP enabled 3G CDMA networks. The home agent (HA) and Authentication, Authorization, and Accounting (AAA) server of the mobile node (MN) reside in the home IP network, and the MN roams within or between the access provider network(s). Usually, the home IP network is not populated by the MNs, which are instead connected only to the access provider networks. Prior to the Mobile IPv6 registration, the MN establishes a 3G CDMA access technology specific link-layer connection with the access router (AR). When the MN moves from one AR to another, the link-layer connection is re-established, and a Mobile IPv6 handover is performed. Those ARs reside in either the same or different access provider network(s). The figure shows the situation, where the MN moves from the Previous Access Router (PAR) to the New Access Router (NAR) via the radio access network (RAN).
図1は、モバイルIPの簡略化された参照モデルは、3G CDMAネットワークを有効に示します。ホームエージェント（HA）とモバイルノード（MN）の認証、許可、アカウンティング（AAA）サーバはホームIPネットワークに存在し、そしてMN内またはアクセス・プロバイダ・ネットワークとの間のローミング。通常、ホームIPネットワークは、代わりにのみアクセスプロバイダのネットワークに接続されているのMNによって移入されません。モバイルIPv6の登録に先立ち、MNは、アクセスルータ（AR）と3G CDMAアクセス技術の特定のリンク層接続を確立します。 MNが別のARに移動するとき、リンク層接続が再確立され、モバイルIPv6ハンドオーバが実行されます。それらのARは、同じまたは異なるアクセスプロバイダネットワーク（単数または複数）に存在します。図は、MNは、無線アクセスネットワーク（RAN）を介して新しいアクセスルータ（NAR）への前のアクセスルータ（PAR）から移動状況を示しています。
Home IP Network
+........................+
. +--------+ +--------+ .
. | HA |--| AAA | .
. +--------+ +--------+ .
+../......\..............+
/ \
Access Provider Network(s)
+.............+ +.............+
. +---------+ . . +---------+ .
. | PAR | . . | NAR | .
. +---------+ . . +---------+ .
. |: . . :| .
. |:L2link L2link:| .
. |: . . :| .
. +----+:---+ . . +---:+----+ .
. | RAN | . . | RAN | .
. +----+:---+ . . +---:+----+ .
. |: . . :| .
. +----+ . . +----+ .
. | MN | ---------> | MN | .
. +----+ . . +----+ .
+.............+ +.............+
Figure 1: Reference Model for Mobile IP
図1：モバイルIPのための参照モデル
In 3G CDMA networks, pilot channels transmitted by base stations allow the MN to obtain a rapid and accurate C/I (carrier to interference) estimate. This estimate is based on measuring the strength of the Forward Pilot Channel or the pilot, which is associated with a sector of a base station (BS). The MN searches for the pilots and maintains those with sufficient signal strength in the pilot sets. The MN sends measurement results, which include the offsets of the PN code in use and the C/Is in the pilot sets, to provide the radio access network (RAN) with the estimate of sectors in its neighborhood. There are several triggers for the MN to send those estimates, e.g., when the strength of a pilot in the pilot sets exceeds that of the current pilot, the MN sends the estimates to the access network. As long as the sector to which the MN is going to move belongs to the same access network, the mobility within that access network is handled by the access-specific interfaces [10] and the link-layer connection between the MN and AR can be maintained without a re-establishment. The MN can continually search for pilots without disrupting the data communication and a timely handover is assisted by the network. If, however, the serving access network finds that the sector associated with the highest pilot strength belongs to a different AR, it attempts to close the connection with the MN. The MN then attempts to get a new traffic channel assigned in the new access network, which is followed by establishing a new connection with the new AR. This could cause a noticeable communication disruption and lead to a serious degradation of the user experience. In order to minimize the service degradation, during the handover between ARs, an IP-level fast handover approach as defined in RFC 5268 needs to be involved. If the air interface information can be used as a trigger for the handover between access routers, fast and smooth handover of Mobile IPv6 can be realized in 3G CDMA networks. The MN can continually search for pilots without disrupting the data communication and a timely handover is assisted by the network.
3G CDMAネットワークでは、基地局によって送信されるパイロットチャネルは、MNは、迅速かつ正確なC / I（干渉搬送波）推定値を得ることを可能にします。この推定値は、基地局（BS）のセクタに関連付けられた順方向パイロットチャネル又はパイロットの強度を測定することに基づいています。 MNは、パイロットのために検索し、パイロットセットで十分な信号強度を有するものを維持しています。 MNは、使用中のPN符号のオフセットを含む測定結果を、送信およびC /は、その近傍のセクタの推定と無線アクセスネットワーク（RAN）を提供するために、パイロットセットにされています。パイロットセット内のパイロットの強さが現在のパイロットの、MNは、アクセスネットワークに見積りを送信することを超えた場合、MNは、例えば、これらの推定値を送信するために、いくつかのトリガーがあります。 MNが移動しようとしたセクタが同一のアクセスネットワークに属する限り、そのアクセスネットワーク内の移動度は、[10]アクセス固有のインタフェースによって処理され、MNとARとの間のリンク層接続であり得ます再確立することなく維持。 MNは、継続的にデータ通信とタイムリーなハンドオーバを中断することなく、パイロットを検索することができ、ネットワークによって支援されます。しかし、サービングアクセスネットワークが最も高いパイロット強度に関連付けられたセクタは異なるARに属することが判明した場合、それはMNとの接続を閉じよう。 MNは、新しいARとの新しい接続を確立することにより、続いて、新たなアクセスネットワークに割り当てられた新しいトラフィックチャネルを取得しようとします。これは顕著な通信の中断を引き起こし、ユーザーエクスペリエンスの深刻な悪化につながる可能性があります。アクセスルータ間のハンドオーバ中に、サービス低下を最小限にするために、RFC 5268で定義されているIPレベル高速ハンドオーバ手法が関与する必要があります。エア・インターフェース情報は、アクセスルータ間のハンドオーバのためのトリガとして使用することができる場合、モバイルIPv6の高速で円滑なハンドオーバは、3G CDMAネットワークで実現することができます。 MNは、継続的にデータ通信とタイムリーなハンドオーバを中断することなく、パイロットを検索することができ、ネットワークによって支援されます。
To assist the handover of the MN to the new AR, various types of information can be considered: the pilot sets, which include the candidates of the target sectors or BSs, the cell information where the MN resides, the serving nodes in the radio access network, and the location of the MN, if available. To identify the access network that the MN moves to or from, the Access Network Identifiers (ANID) or the subnet information can be used [9][10]. In this document, a collection of such information is called "handover assist information". In 3G CDMA networks, the Link-Layer Address of the New Access Point (AP) defined in [3] may not be available. If this is the case, the Handover Assist Information option defined in this document SHOULD be used instead.
新しいARにMNのハンドオーバーを支援するために、様々なタイプの情報を考慮することができる：ターゲットセクタまたは基地局、MNが存在するセル情報、無線アクセスにおけるサービングノードの候補を含むパイロット組ネットワーク、およびMNの場所、利用可能な場合。 MNは、またはから移動アクセスネットワークを識別するために、アクセス・ネットワーク識別子（ANID）又はサブネット情報を使用することができる[9] [10]。この文書では、そのような情報の収集には、「ハンドオーバ支援情報」と呼ばれています。 3G CDMAネットワークでは、で定義された新しいアクセスポイント（AP）のリンク層アドレスは、[3]利用できない場合があります。この場合、ハンドオーバは、この文書で定義されている情報オプションをアシスト代わりに使用してください。
There are two modes defined in [3] according to the time of sending the FBU (Fast Binding Update); one is called "predictive mode", where the MN sends the FBU and receives the FBAck (Fast Binding Acknowledgment) on the PAR's (Previous Access Router's) link and the other is called "reactive mode", where the MN sends the FBU from the NAR's (New Access Router's) link. In the predictive mode, the time and place the MN hands off must be indicated sufficiently before the time it actually happens. In cellular systems, since handovers are controlled by the network, the predictive mode is well applied. However, if the network is not configured to be able to identify the new AR, to which the MN is moving next, in a timely manner, the reactive mode is better applied.
で定義された2つのモードは、[3] FBU（高速バインディングアップデート）を送信する時間に応じて存在します。 1は、MNからFBUを送るMNがFBUを送信し、PARの（前のアクセスルータの）リンクするFBAck（高速バインディング確認応答）を受信し、他は「反応モード」と呼ばれる「予測モード」、と呼ばれていますNARの（新アクセスルータの）リンク。予測モードでは、時間とMNの手を離れて配置することは、それが実際に起こる時間前に十分に示されなければなりません。ハンドオーバがネットワークによって制御されているので、セルラシステムでは、予測モードが同様に適用されます。ネットワークはどのMNがタイムリーに、次の動いているし、新しいARを識別することができるように構成されていない場合は、反応性モードが優れて適用されます。
Section 2 of RFC 4907 [20] suggests architectural principles on the link indication and the effectiveness of the optimization. The link indication of this document relies on 3G CDMA networks and the effectiveness of the optimization is attributed to RFC 5268. The above principles are thus considered by the related specifications referenced in this document.
RFC 4907 [20]のセクション2は、リンク指示および最適化の有効性に関する建築原理を示唆しています。このドキュメントのリンク表示は、3G CDMAネットワークに依存し、最適化の有効性は、上記の原則は、このように、本書で参照関連の仕様によって検討されているRFC 5268.に起因します。
Figure 2 shows the predictive mode of MIPv6 fast handover operation. When the MN finds a sector or a BS whose pilot signal is sufficiently strong, it initiates handover according to the following sequence:
図2は、MIPv6の高速ハンドオーバ動作の予測モードを示しています。 MNは、セクタを発見またはそのパイロット信号BSが十分に強い場合、それは次の順序に従って、ハンドオーバを開始します。
(a) A router solicitation for proxy router advertisement is sent to the PAR. Handover assist information for the target 3G CDMA network is attached to this message.
（a）は、プロキシルータアドバタイズメントのためのルーター要請をPARに送信されます。ハンドオーバは、3G CDMAネットワークは、このメッセージに添付されたターゲットの情報を助けます。
(b) Based on the received handover assist information, the NAR is determined and a proxy router advertisement (PrRtAdv) containing the prefix of the NAR is sent back to the MN. The MN also checks that the R flag is not set in the PrRtAdv message, which indicates the network supports the predictive fast handover mode (defined later).
（b）は、受信したハンドオーバに基づく情報をアシスト、NARが決定され、NARのプレフィックスを含むプロキシルータ広告（代理ルータ広告）は、背面MNに送信されます。 MNはまた、Rフラグがネットワークを示す代理ルータ広告メッセージに設定され（後に定義）予測高速ハンドオーバモードをサポートされていないことをチェックします。
(c) The MN creates an NCoA (new CoA) and sends the Fast Binding Update (FBU) with the NCoA to the PAR, which in turn sends the Handover Initiate (HI) to the NAR.
（C）MNはNCOA（新しいCoA）を作成し、順番に開始します（HI）NARへのハンドオーバを送るPARにNCOA、と高速バインディングアップデート（FBU）を送信します。
(d) The NAR sends the Handover Acknowledge (HAck) back to the PAR, which in turn sends the FBU acknowledgment (FBAck) to the MN.
（d）のNARは、ハンドオーバが戻って今度はMNにFBU確認応答（するFBAck）を送信PARへ（ハック）アクノリッジ送信します。
(e) The PAR starts forwarding packets toward the NCoA and the NAR captures and buffers them.
（e）のPARはNCOAとNARキャプチャに向けてパケットの転送を開始し、それらをバッファリング。
(f) The link-layer connection associated with the PAR is closed and a new traffic channel is assigned in the new access network.
（f）をPARに関連付けられたリンク層接続が閉じられ、新しいトラフィックチャネルが新しいアクセスネットワークに割り当てられています。
(g) The MN attaches to the new access network. The attachment procedure is access technology specific and that for 3G CDMA network including the PPP transactions is described later.
（G）MNは、新しいアクセス・ネットワークに接続します。添付ファイルの手順は、後述するPPPの取引を含む3G CDMAネットワークのためのアクセス技術の特定と、そのです。
(h) The MN sends the Unsolicited Neighbor Advertisement (UNA).
（H）MNは迷惑近隣広告（UNA）を送信します。
(i) The NAR starts delivering packets to the MN.
（I）NARは、MNにパケットを配信を開始します。
(j) The MN sends the Binding Update (BU) to the HA to update the Binding Cache Entry (BCE) with the NCoA, and the HA sends back the Binding Acknowledgment (BA) to the MN.
（J）MNはNCOAとの結合キャッシュ・エントリ（BCE）を更新するHAにバインディング更新（BU）を送信し、HAは、MNに結合確認（BA）を返信します。
MN PAR NAR HA AAA
| RtSolPr | | | |
(a) |------------->| | | |
| PrRtAdv | | | |
(b) |<-------------| | | |
| FBU | Hl | | |
(c) |------------->|-------------->| | |
| FBack | HAck | | |
(d) |<-------------|<--------------| | |
| |forward packets| | |
(e) | |==============>|(buffering) | |
| | | | |
(f) handover | | | |
| | | | |
+--------------------------------------------------------------+
(g) | Attachment procedure |
+--------------------------------------------------------------+
| UNA | | |
(h) |----------------------------->| | |
| deliver packets | | |
(i) |<=============================| | |
| | BU/BA | | |
(j) |<------------------------------------------->| |
| | | | |
Figure 2: MIPv6 Fast Handover Operation (Predictive Mode)
図2：MIPv6の高速ハンドオーバー動作（予測モード）
It is assumed that the NAR can be identified by the PAR leveraging the handover assist information from the MN. To perform the predictive mode, the MN MUST send the FBU before the connection with the current access network is closed. If the MN fails to send the FBU before handover, it SHOULD fall back to the reactive mode. Even if the MN successfully sends the FBU, its reception by the PAR may be delayed for various reasons such as congestion. If the NAR receives the HI triggered by the delayed FBU after the reception of the UNA ((c) comes after (h)), then the NAR SHOULD send the HAck with handover not accepted and behave as the reactive mode.
MNからの情報を支援ハンドオーバを活用NARがPARで識別できるものとします。現在のアクセスネットワークとの接続が閉じられる前に予測モードを実行するには、MNは、FBUを送らなければなりません。 MNは、ハンドオーバ前にFBUを送信するために失敗した場合、それは反応モードにフォールバックすべきです。 MNが正常FBUを送信する場合であっても、PARによるその受信は、混雑のような種々の理由のために遅延させることができます。 NARは、UNAの受信後に遅延FBU（（C））は、H（後に来る）によってトリガさHIを受信した場合、NARは受け入れられないハンドオーバとハック送信し、反応モードとして動作すべきです。
In (a), Router Solicitation for Proxy Advertisement (RtSolPr) is supposed to include the New Access Point and the MN Link-Layer Address (LLA) options (Option Code=1 and 2, respectively) according to [3]. The New AP-LLA option MAY be replaced by the handover assist information option in 3G CDMA networks. As for the MN-LLA option, if the LLA for the MN is not available, 3G specific IDs such as IMSI[11] MAY be used. If this is the case, the MN ID option defined in Section 6.2, which can support other types of IDs and a length that is not necessarily multiples of 8 octets, SHOULD be used instead of the MN-LLA option.
（a）は、プロキシ広告（RtSolPrを）のためのルーター要請をに従って新しいアクセスポイントと（それぞれオプション・コード= 1、2、）MNのリンク層アドレス（LLA）のオプションが含まれるようになっている[3]。新しいAP-LLAオプションは、3G CDMAネットワークにおける情報オプションを支援するハンドオーバーに置き換えることができます。 MNのためのLLAが利用できない場合にMN-LLAオプションとして、そのようなIMSI [11]などの3G特定のIDを使用してもよいです。この場合、IDの他のタイプをサポートすることができ、セクション6.2で定義されたMN IDオプション、必ずしも8つのオクテットの倍数ではない長さであれば、MN-LLAオプションの代わりに使用されるべきです。
In (b), PrRtAdv MUST include options for the IP address of the NAR, which may be the link-local address, and the prefix for the MN. The PAR SHOULD be able to identify the NAR from the handover assist information provided by the MN.
（B）において、代理ルータ広告がリンクローカルアドレスであってもよいNARのIPアドレスのためのオプション、およびMNのプレフィックスを含まなければなりません。 PARは、MNによって提供される情報をアシストハンドオーバーからNARを識別することができるべきです。
Figure 3 shows the call flow for the initial attachment in the 3G CDMA network [12]. After the traffic channel is assigned, the MN first establishes a link-layer connection between itself and the access router. As a link-layer protocol, PPP is considered in this figure, and a PPP handshake is depicted as an example. After a link-layer connection is established, the MN registers with the HA by sending a Binding Update message. There are several parameters for using Mobile IPv6 such as the home address (HoA), the Care-of Address (CoA), the home agent address (HA), and the home link prefix (HLP). In [12], obtaining these values is called bootstrapping, and the bootstrapping information can be obtained during the link-layer establishment phase and/or the mobility binding phase [13].
図3は、[12] 3G CDMAネットワーク内の最初の取り付けのためのコールフローを示しています。トラフィックチャネルが割り当てられた後、MNは、まず自身とアクセスルータとの間のリンク層接続を確立します。リンク層プロトコルとして、PPPは、この図で考慮され、PPPハンドシェイクは、例として示されています。リンク層接続が確立された後、MNはバインディング更新メッセージを送信することによってHAに登録します。そのようないくつかのホームアドレス（HoAを）としてモバイルIPv6を使用するためのパラメータ、気付アドレス（CoA）、ホームエージェントアドレス（HA）、およびホームリンクプレフィックス（HLP）があります。 [12]において、これらの値を得ることはブートストラップと呼ばれ、ブートストラップ情報は、リンク層の確立フェーズ及び/又は移動性結合相[13]の間に取得することができます。
MN PAR NAR HA AAA
/ | (serving PDSN) (target PDSN) | |
| | LCP | | | |
| (1) |<----------------------->| | |
| | CHAP/PAP | Access-Request/Accept |
| (2) |<----------------------->|<-------------|------->|
| | | +------+ | | |
| (3) | | | HA |<---------+ |
| | | +------+ | |
|+........................................+ | |
|. | | . | |
|. | IPv6CP(IF-ID) | . | |
|.(4)* |<---------|------------->| . | |
(g)< . +---------+ | | | . | |
|.(5)*| LL-addr |<-+ | | . | |
|. +---------+ | | . | |
|. | | . | |
|. | RA(prefix) | . | |
|.(6)* |<---------|--------------| . | |
|. +-----+ | | | . | |
|.(7)*| CoA |<-----+ | | . | |
|. +-----+ | | . | |
|+........................................+ | |
| | DHCPv6(HA) | | |
| (8) |<---------------+------->| | |
| +-----+ | | | | |
| (9) | HA |<-----------+ | | |
| +-----+ | | | |
| | | | | |
\ | | | | |
Figure 3: Attachment Procedure in 3G CDMA Network
図3：3G CDMAネットワークにおけるアタッチメント手順
The procedure for the initial attachment is as follows:
次のように最初の取り付けのための手順は次のとおりです。
(g) The link-layer connection establishment and the bootstrapping phase.
（G）リンク層接続の確立とブートストラップ段階。
(g-1) The LCP (Link Control Protocol) configure-request/response messages are exchanged.
（G-1）LCP（リンク制御プロトコル）設定要求/応答メッセージが交換されます。
(g-2) User authentication (e.g., Challenge Handshake Authentication Protocol (CHAP) or Password Authentication Protocol (PAP)) is conducted.
（G-2）ユーザ認証（例えば、チャレンジハンドシェイク認証プロトコル（CHAP）またはパスワード認証プロトコル（PAP））が行われます。
(g-3) The static bootstrapping information is conveyed from the AAA and stored in the NAR (target PDSN). The HoA and HLP can be dynamically assigned by the HA in the mobility binding phase. This step can be skipped in the handover case.
（G-3）静的なブートストラップ情報は、AAAから搬送及びNAR（ターゲットPDSN）に格納されています。 HoAとHLPは、動的移動性結合相にHAによって割り当てられることができます。このステップは、ハンドオーバの場合にスキップすることができます。
(g-4) Unique interface IDs are negotiated in IPv6 Control Protocol (IPv6CP).
（G-4）固有インターフェイスIDは、IPv6制御プロトコル（IPV6CP）で交渉されます。
(g-5) The MN configures its link-local address based on the obtained interface ID.
（G-5）MNは、取得したインターフェースIDに基づいて、そのリンクローカルアドレスを設定します。
(g-6) A router advertisement containing the prefix is received by the MN.
（G-6）は、プレフィックスを含むルータ広告は、MNによって受信されます。
(g-7) The MN configures its CoA based on the obtained prefix.
（G-7）MNが得られたプレフィックスに基づいてCoAを構成します。
(g-8) DHCPv6 is used to obtain the static bootstrap information (e.g., the HA address). This step is performed in the initial attachment and can be skipped once the MN obtains those parameters.
（G-8）のDHCPv6は、静的なブートストラップ情報（例えば、HAアドレス）を取得するために使用されます。このステップは、最初の添付ファイルに実行され、MNはそれらのパラメータを取得するとスキップすることができます。
(g-9) The MN installs the bootstrap information for further procedures (e.g., the mobility binding).
（G-9）MNは、さらに手順（例えば、モビリティ結合）のためのブートストラップ情報をインストールします。
As is shown in Figure 3, it takes a considerable amount of time to establish a link-layer connection and almost all of the above sequences run every time the MN attaches to a new access network. It is therefore beneficial if packets in transit to the MN are saved not only during the time period when the MN switches to the new radio channel but also during the time period when the MN establishes the link-layer connection.
図3に示すように、リンク層接続を確立するためにかなりの時間がかかり、ほぼすべての上記配列のは、MNは、新しいアクセス・ネットワークに接続するたびに実行します。 MNへの輸送中のパケットは、MNは、新しい無線チャネルにもMNは、リンク層接続を確立期間中に切り替え期間中だけでなく、保存されている場合はそのために有益です。
There are several ways to configure a unique IP address for the MN. If a globally unique prefix is assigned per link as introduced in [12], the MN can use any interface ID except that of the other peer (the AR to which the MN is attached) to create a unique IP address. If this is the case, however, the PAR cannot provide the MN with a correct prefix for the new network in the PrRtAdv since such a prefix is selected by the NAR and provided in the router advertisement. The MN therefore configures a temporary NCoA with the prefix provided by the PAR and the correct NCoA MUST be assigned by the NAR. Therefore, in 3G CDMA network, the PAR MUST send the HI with the S flag set when it receives the FBU from the MN at step (c) in Figure 2.
MNのためのユニークなIPアドレスを設定するには、いくつかの方法があります。 [12]で導入され、グローバルに一意のプレフィックスをリンクごとに割り当てられている場合、MNは、一意のIPアドレスを作成するために、他のピア（MNが接続されているAR）のことを除いて、任意のインターフェースIDを使用することができます。この場合、そのような接頭辞はNARによって選択され、ルータ広告に設けられているので、しかし、PARは、代理ルータ広告の新しいネットワークの正しいプレフィックスをMNに提供することはできません。 MNは、したがって、PARと正しいNCOAが提供するプレフィックスがNARによって割り当てなければならないとの一時的なNCOAを設定します。それは、図2のステップ（c）にMNからFBUを受信したときしたがって、3G CDMAネットワークにおいて、PARは、Sフラグを設定してHIを送らなければなりません。
The UNA is supposed to include the MN-LLA [3], but the point-to-point link-layer connection may be able to uniquely identify the MN. The most required information by the UNA is the NCoA to check if there is a corresponding buffer. Therefore, in (h), the function of the UNA can be realized in several ways:
UNAは、MN-LLA [3]を含むことになっているが、ポイントツーポイントのリンク層接続を一意MNを識別することができるかもしれません。 UNAによって最も必要な情報は、対応するバッファがあるかどうかを確認することNCOAです。したがって、（h）に、UNAの機能は、いくつかの方法で実現することができます。
o Since the establishment of the link-layer connection in (g) indicates readiness of data communication on the MN side, the NAR immediately checks if there is a buffer that has packets destined for the NCoA, which was configured at steps (c) - (d), and starts delivering, if any (substitution of UNA).
（g）にリンク層接続の確立は、MN側のデータ通信の準備を示しているので、ステップ（C）で構成されたNCOA、宛てのパケットを有するバッファがある場合、O、NARはすぐチェック - （D）、および任意の（UNAの置換）場合、配信を開始。
o The MN sends the UNA as defined in [3]. Instead of the MN-LLA in the LLA option, the MN ID MAY be included in the MN ID option (standard implementation of UNA).
MN O [3]で定義されるようにUNAを送信します。代わりに、LLAオプションでMN-LLAの、MNのIDは、MN IDオプション（UNAの標準実装）に含まれるかもしれません。
The primary benefit of the predictive fast handover mode is that the packets destined for the MN can be buffered at the NAR, and packet loss due to handover will be much lower than that of the normal MIPv6 operation. Regarding the bootstrapping, the following benefit can be obtained, too:
予測高速ハンドオーバモードの主な利点は、MN宛のパケットは、NARでバッファリングすることができることであり、ハンドオーバに起因するパケット損失は、通常のMIPv6の動作よりもはるかに低くなります。ブートストラップについては、次のような利点も得られます。
o Since the NCoA can be configured via the fast handover procedures, a router advertisement is not required.
NCOAは、高速ハンドオーバ手順を介して構成することができるので、O、ルータ広告は必要とされません。
Therefore, the procedures (g-4) to (g-7) can be skipped from the standard MIPv6 operation in Figure 3.
したがって、（G-7）の手順（G-4）は、図3における標準のMIPv6操作から省略することができます。
When the network does not support the predictive fast handover mode, the reactive fast handover is applied. In this document, a new flag is defined in PrRtAdv to inform the MN about the capability of the network (see Section 6.4). To minimize packet loss in this situation, the PAR instead of the NAR can buffer packets for the MN until the MN regains connectivity with the NAR. The NAR obtains the information of the PAR from the MN on the NAR's link and receives packets buffered at the PAR. In this case, the PAR does not need to know the IP address of the NAR or the NCoA and just waits for the NAR to contact the PAR. However, since the PAR needs to know when to buffer packets for the MN, the PAR obtains the timing of buffering from the MN via the FBU or the lower-layer signaling, e.g., an indication of the release of the connection with the MN. Details of the procedure are as follows:
ネットワークは、予測高速ハンドオーバモードをサポートしていない場合には、反応性高速ハンドオーバが適用されます。この文書では、新しいフラグはネットワークの機能について、MNに通知する代理ルータ広告で定義されている（6.4節を参照してください）。 MNは、NARとの接続が回復するまで、このような状況でのパケット損失を最小限にするために、代わりにNARのPARは、MNのパケットをバッファリングすることができます。 NARはNARのリンク上のMNからPARの情報を取得し、PARでバッファリングされたパケットを受信します。この場合、PARはNARまたはNCOAのIPアドレスを知っている必要がありますし、NARがPARに連絡するためだけ待機しません。 PARは、MNのパケットをバッファリングするときに知っておく必要があるので、PARは、例えば、FBUまたは下位レイヤシグナリング、MNとの接続の解除の指示を介して、MNからバッファリングのタイミングを取得します。次のように手順の詳細は以下のとおりです。
(a) A router solicitation for proxy router advertisement MAY be sent to the PAR.
（a）は、プロキシルータアドバタイズメントのためのルーター要請は、PARに送ってもよいです。
(b) The proxy router advertisement MAY be sent to the MN. If the information on the NAR is not available by the PAR, "0::0" MUST be used for the options related to the NAR (e.g., IP address of the NAR).
（b）は、プロキシルータ通知は、MNに送ってもよいです。 NARの情報はPARで使用できない場合は「0 :: 0」NARに関連するオプション（例えば、NARのIPアドレス）を使用しなければなりません。
(c) The MN sends the FBU or the access network indicates the close of the connection with the MN by the lower-layer signaling. If the MN cannot formulate the NCoA, "0::0", MUST be used for the NCoA in the FBU. If the B flag is set in the FBU, the PAR SHOULD start buffering packets destined for the PCoA.
（C）MNは、FBUを送信又はアクセスネットワークは、下位レイヤシグナリングによりMNとの接続のクローズを示しています。 MNはNCOAを策定することができない場合は、「0 :: 0」、FBUでNCOAを使用しなければなりません。 BフラグがFBUに設定されている場合、PARはPCOA宛てバッファリングパケットを開始する必要があります。
(d) The link-layer connection associated with the PAR is closed and a new traffic channel is assigned in the new access network.
（d）のPARに関連付けられたリンク層接続が閉じられ、新しいトラフィックチャネルが新しいアクセスネットワークに割り当てられています。
(e) The MN attaches to the new access network. This part is the same as described in Section 5.1 and illustrated in Figure 3.
（E）MNは、新しいアクセス・ネットワークに接続します。セクション5.1で説明し、図3に示すように、この部分は同じです。
(f) The MN sends the UNA to the NAR.
（f）は、MNがNARにUNAを送信します。
(g) The MN sends the Fast Binding Update (FBU) to the PAR via the NAR.
（G）MNは、NARを経由してPARへ高速バインディング更新（FBU）を送信します。
(h) The NAR forwards the FBU from the MN to the PAR.
（H）NARがPARにMNからFBUを転送します。
(i) The PAR sends the Handover Initiate (HI) to the NAR with the Code set to 1.
（I）PARは、ハンドオーバを送信するコードを1に設定してNARに（HI）開始。
(j) The NAR sends the Handover Acknowledge (HAck) back to the PAR.
（J）NARは、ハンドオーバが戻っPARに（ハック）アクノリッジ送信します。
(k) The PAR sends the FBAck to the NAR.
（K）支払人NARへ戻る送ります。
(l) If the PAR is buffering packets destined for the PCoA, it starts forwarding them as well as newly arriving ones to the NAR.
（L）PARがPCOA宛のパケットをバッファリングされている場合は、新たにNARのものを到着だけでなく、それらの転送を開始します。
(m) The NAR delivers the packets to the MN.
（M）NARは、MNにパケットを配信します。
(n) The MN sends the BU to the HA to update the BCE with the NCoA and the HA sends back the BA to the MN.
（N）MNはNCOAとのBCEを更新するために、HAにBUを送信し、HAは、MNにBAを返信します。
MN PAR NAR HA AAA
| RtSolPr | | | |
(a) |------------->| | | |
| PrRtAdv | | | |
(b) |<-------------| | | |
| FBU | | | |
(c) |- - - - - - ->|(buffering) | | |
| | | | |
(d) handover | | | |
| | | | |
+--------------------------------------------------------------+
(e) | Attachment procedure |
+--------------------------------------------------------------+
| UNA | | |
(f) |----------------------------->| | |
| FBU | | |
(g) |----------------------------->| | |
| | FBU | | |
(h) | |<--------------| | |
| | HI | | |
(i) | |-------------->| | |
| | HAck | | |
(j) | |<--------------| | |
| | FBack | | |
(k) | |-------------->| | |
| |forward packets| | |
(l) | |==============>| | |
| deliver packets | | |
(m) |<=============================| | |
| | BU/BA | | |
(n) |<------------------------------------------->| |
| | | | |
Figure 4: MIPv6 Fast Handover Operation (Reactive Mode)
図4：MIPv6の高速ハンドオーバー動作（アクティブモード）
To indicate the PAR to buffer packets destined for the PCoA, in step (c), a new flag 'B' is defined in the FBU. When the PAR receives the FBU with this flag set, it SHOULD buffer packets for the MN. The PAR MAY also start buffering packets for the MN based on lower layer signal during handover. Since the packets are buffered at the PAR in this scenario, the UNA, which is received and processed by the NAR, can not be used to trigger to forward the buffered packets at the PAR. In Figure 4, the HAck from the NAR is used as the trigger for the forwarding of any buffered packets.
PCOA宛てのパケットをバッファリングするPARを示すために、工程（c）において、新しいフラグ「B」がFBUに定義されています。 PARは、このフラグを設定してFBUを受信すると、MNのためのパケットをバッファすべきです。 PARはまた、ハンドオーバ時下層信号に基づいてMNのバッファリングパケットを開始してもよいです。パケットがこのシナリオではPARで緩衝されているので、NARによって受信および処理されるUNAは、PARにバッファされたパケットを転送するためにトリガするために使用することができません。図4においては、NARからハック任意のバッファされたパケットを転送するためのトリガとして使用されます。
The handover indication from the lower layer of 3G CDMA system is reasonably reliable by the periodical reports from the MN; however, there are several situations where the target link is not available after the handover (step (d)) and the MN comes back to the PAR, or the MN is not able to move to the target link for some reason after the connection was closed. If this is the case, the attachment procedure is performed on the previous link. The packets buffered at the PAR SHOULD be delivered to the MN after the connection is re-established.
3G CDMAシステムの下位層からハンドオーバ指示は、MNからの定期的報告によって合理的に信頼性があります。しかし、（工程（d））、目標リンクがハンドオーバ後に使用できないいくつかの状況が存在するとMNがPARに戻ってくる、またはMNは、接続がした後に何らかの理由でターゲットリンクに移動することができません閉まっている。このような場合は、添付ファイルの手順は、前のリンク上で行われます。接続が再確立された後にPARでバッファリングされたパケットは、MNに送達されるべきです。
This section discusses if the link indications assumed in this document meet the principles defined in Section 2 of RFC 4907[20], which suggests 11 architectural principles on the link indication and the effectiveness of the optimization. This document relies on the 3G CDMA network regarding the link indication, which is precisely specified by 3GPP2. Therefore, principles (1) to (5), (7), (8), and (11), that is, "Model Validation", "Clear Definition", "Robustness", "Recovery from Invalid Indications", "Congestion Control", "Interoperability", "Race Condition", and "Transport of Link Indications" are considered by those specs. Principle (6) "Effectiveness" mentions the effectiveness of the optimization. This document bases its effectiveness on RFC 5268. Therefore, this principle is dealt by that RFC. Principle (9) "Metric Consistency" mentions inconsistencies between link and routing layer metrics. The spec of this document does not change the routing metrics and multi-homing is not considered. Finally, principle (10) "Layer Compression", mentions an overhead reduction scheme and interoperability. This document does not deal with overhead reduction and therefore this principle does not apply.
このセクションでは、この文書で想定リンク適応は、RFC 4907のセクション2で定義された原則を満たしている場合、[20]について説明リンク指示および最適化の有効性に関する11の建築原理を示唆しています。この文書では、正確に3GPP2によって指定されたリンクの表示、についての3G CDMAネットワークに依存しています。したがって、原理（1）〜（5）、（7）、（8）、（11）、すなわち、 "モデルの検証"、 "明確な定義"、 "ロバスト性"、 "無効な指標からの回復"、「輻輳制御」、 『相互運用性』、 『競合状態』、および 『リンク適応の輸送は、』これらの仕様によって検討されています。原則は、（6）「有効性」の最適化の有効性を言及しています。この文書では、この原則は、そのRFCによって配られ、したがってRFC 5268.にその有効性を基づか。原理（9）「メトリック整合性」リンクとルーティング層のメトリックとの間の矛盾を言及しています。このドキュメントの仕様では、ルーティングメトリックを変更しないとマルチホーミングが考慮されていません。最後に、原則として（10）、「レイヤー圧縮は」、オーバーヘッド削減スキームとの相互運用性に言及しています。この文書では、オーバーヘッド削減を扱っていないため、この原則は適用されません。
If the lower layer information of the new point of attachment is not represented as the link-layer address, the following option SHOULD be used. The primary purpose of this option is to convey the handover assist information described in Section 4.
新しい接続点の下位レイヤ情報はリンク層アドレスとして表現されていない場合は、次のオプションを使用する必要があります。このオプションの主な目的は、第4章で説明したハンドオーバ支援情報を伝えることです。
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 | Option-Code | HAI-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HAI-Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type 29
タイプ29
Length The size of this option in 8 octets including the Type, Length, Option-Code, and HAI-Length (Handover Assist Information-Length) fields.
タイプ、長さ、オプション・コード、およびHAI-長を含む8つのオクテットでこのオプションの長さサイズ（ハンドオーバが情報長をアシスト）フィールド。
Option-Code 1: Access Network Identifier (AN ID) 2: Sector ID
オプション-コード1：アクセスネットワーク識別子（ID）2：セクターID
HAI-Length The size of the HAI-Value field in octets.
HAI-長さオクテットでHAI-Valueフィールドのサイズ。
HAI-Value The value specified by the Option-Code.
HAI-価値オプション・コードで指定された値。
If those that received this message do not support this option, they SHOULD treat this option as opaque and MUST NOT drop it.
このメッセージを受信したものは、このオプションをサポートしていない場合、彼らは不透明として、このオプションを扱うべきで、それをドロップしてはなりません。
Option-Code indicates the particular type of handover assist information. Currently, two types of information are defined to assist the discovery of the NAR (see Section 3).
オプションコードは、ハンドオーバーの特定のタイプの情報をアシスト示します。現在、情報の2種類がNARの発見を支援するために定義されています（第3章を参照してください）。
Depending on the size of the HAI-Value field, appropriate padding MUST be used to ensure that the entire option size is a multiple of 8 octets. The HAI-Length is used to disambiguate the size of the HAI-Value.
HAI-Valueフィールドのサイズに応じて、適切なパディングはオプション全体のサイズは8つのオクテットの倍数であることを確認するために使用しなければなりません。 HAI-長は、HAI-価値の大きさを明確にするために使用されます。
The handover assist information MAY replace the New Access Point Link-Layer Address in 3G CDMA networks.
ハンドオーバ支援情報は、3G CDMAネットワークの新しいアクセスポイントのリンク層アドレスを交換することができます。
This option is used to transfer the Identifier of the MN, which is not its link-layer address.
このオプションは、そのリンク層アドレスではありませんMNの識別子を転送するために使用されます。
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 | Option-Code | MN ID-Length |
+---------------------------------------------------------------+
| MN ID ...
+-----------------------------
Type 30
タイプ30
Length The size of this option is in 8 octets including the Type, Length, and Option-Code.
長さはこのオプションのサイズは、タイプ、長さ、およびオプション・コードを含む8つのオクテットです。
Option-Code 1: NAI [4] 2: IMSI (See Section 3)
オプションコード1：NAI [4] 2：IMSI（セクション3を参照）。
MN ID-Length The length of the MN ID in octets.
MNオクテットでのMNのIDのID長の長さ。
MN ID MN ID value
MN ID MNのID値
The MN ID MAY replace the MN Link-Layer Address in 3G CDMA networks.
MNのIDは、3G CDMAネットワークにおけるMNのリンク層アドレスを交換することができます。
The MN MUST send the FBU to the PAR with the following new (B) flag set in the previous network to indicate the PAR to buffer packets destined for the PCoA. The rest of the Binding Update message format remains the same as defined in [2] and with the additional (M), (R), and (P) flags as specified in [14], [15], and [16], respectively.
MNはPCOA宛てのパケットをバッファリングするPARを示すために、前のネットワークに設定され、以下の新しい（B）フラグとPARにFBUを送らなければなりません。 [2]、（R）、（M）の追加と、及び（P）のフラグで指定されるように[14]、[15]及び[16]で定義されるようにBinding Updateメッセージフォーマットの残りの部分は同じままそれぞれ。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|B| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B flag: If the 'B' flag is set, the PAR SHOULD start buffering the packets destined for the MN as specified in Section 5.2.
Bフラグ：「B」フラグが設定されている場合、PARは5.2節で指定されたMN宛のパケットをバッファリングを開始する必要があります。
A new flag 'R' is defined in the PrRtAdv to inform the MN about the fast handover mode that the network supports.
新しいフラグ「R」はネットワークがサポートする高速ハンドオーバモードについてMNに通知する代理ルータ広告で定義されています。
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype |R| Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
R flag: If the 'R' flag is set, the network supports only the reactive handover mode. Otherwise, the network supports both the predictive and reactive fast handover mode.
Rフラグ：「R」フラグが設定されている場合、ネットワークにのみ反応ハンドオーバモードをサポートしています。そうでなければ、ネットワークは、予測と反応性高速ハンドオーバモードの両方をサポートしています。
The security considerations for Mobile IPv6 fast handover are described in [3]. When a 3G CDMA network is considered, it can be assumed that the PAR and the NAR have a trust relationship and the links between them and those between the ARs and the MN are secured. The MN is authenticated every time it attaches to the new link; therefore, the AR can securely identify the MN. Depending on the operator's policy, however, SEcure Neighbor Discovery (SEND) [18] and the shared handover key defined in [17] can also be applied.
モバイルIPv6高速ハンドオーバのためのセキュリティ問題は、[3]に記載されています。 3G CDMAネットワークを考慮すると、PARとNARは、信頼関係を持っていると仮定することができ、それらとのARとMNの間にそれらの間のリンクが確保されています。 MNは、それが新しいリンクに接続するたびに認証されます。そのため、ARはしっかりMNを識別することができます。オペレータのポリシーに応じて、しかし、セキュア近隣探索（SEND）[18]及び[17]にも適用することが可能で定義された共有ハンドオーバキー。
This document defines two new IPv6 Neighbor Discovery options that have been assigned from the same space as the IPv6 Neighbor Discovery Options defined in [19].
この文書では、[19]で定義されたIPv6近隣探索オプションと同じ空間から割り当てられた2つの新しいIPv6近隣探索オプションを定義します。
29: Handover Assist Information Option (Section 6.1)
29：ハンドオーバが情報オプションをアシスト（6.1節）
30: Mobile Node Identifier Option (Section 6.2)
30：モバイルノード識別子オプション（6.2節）
This document creates two new registries for the Option-Code field in the Handover Assist Information Option and that in the Mobile Node Identifier Option. The values for the Option-Code must be within the range 0-255. New values for both registries can be allocated by Standards Action or IESG approval [5].
この文書では、ハンドオーバにおけるオプションコード・フィールド用の2つの新しいレジストリモバイルノード識別子オプションでの情報オプションとそのアシストを作成します。オプション・コードの値は0〜255の範囲内でなければなりません。両方のレジストリのための新しい値は、標準アクションまたはIESG承認で割り当てることができます[5]。
The Option-Code values that have been assigned by IANA are as follows:
次のようにIANAによって割り当てられているオプション・コード値は次のとおりです。
Option-Code for Handover Assist Information Option
Value Description Reference
----- ---------------------------- ----------
0 Reserved
1 ANID Section 6.1
2 Sector ID Section 6.1
Option-Code for Mobile Node Identifier Option
Value Description Reference
----- ---------------------------- ----------
0 Reserved
1 NAI Section 6.2
2 IMSI Section 6.2
The authors would like to thank Kuntal Chowdhury, Ashutosh Dutta, Ved Kafle, and Vijay Devarapalli for providing feedback and support for this work. The authors would also thank Sebastian Thalanany for 3GPP2 expert review.
作者はこの仕事のためのフィードバックとサポートを提供するためのKuntalチョードリー、アッシュートッシュDuttaさん、VED Kafle、およびビジェイDevarapalliに感謝したいと思います。著者らはまた、3GPP2の専門家のレビューのためにセバスチャンThalananyに感謝します。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[2]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[3] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5268, June 2008.
[3] Koodli、R.、エド。、 "モバイルIPv6高速ハンドオーバ"、RFC 5268、2008年6月。
[4] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[4] Aboba、B.、Beadles、M.、Arkko、J.、およびP. Eronen、 "ネットワークアクセス識別子"、RFC 4282、2005年12月。
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[5] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[6] ITU-T Recommendation, "The international identification plan for mobile terminals and mobile users", ITU-T E.212, May 2004.
[6] ITU-T勧告、 "モバイル端末とモバイルユーザのための国際識別計画"、ITU-T E. 212、2004年5月。
[7] McCann, P., "Mobile IPv6 Fast Handovers for 802.11 Networks", RFC 4260, November 2005.
[7]マッキャン、P.、 "802.11ネットワークのためのモバイルIPv6高速ハンドオーバ"、RFC 4260、2005年11月。
[8] 3GPP2 TSG-C, "cdma2000 High Rate Packet Data Air Interface Specification", C.S0024-A v.2.0, July 2005.
[8] 3GPP2 TSG-C、 "cdma2000高速パケットデータエアインタフェース仕様"、C.S0024-V.2.0、2005年7月。
[9] 3GPP2 TSG-A, "3GPP2 Access Network Interfaces Interoperability Specification", A.S0001-A v.2.0, June 2001.
[9] 3GPP2 TSG-A、 "3GPP2アクセス・ネットワーク・インタフェースの相互運用仕様"、A.S0001-V.2.0、2001年6月。
[10] 3GPP2 TSG-A, "Interoperability Specification for High Rate Packet 1 2 Data (HRPD) Access Network Interfaces - Rev A.", A.S0007-A v.2.0, May 2003.
[10] 3GPP2 TSG-A、 "相互運用性仕様高速パケット1 2データ（HRPD）アクセスネットワークインタフェースのための - 改訂A"、A.S0007-V.2.0、2003年5月。
[11] 3GPP2 TSG-A, "Interoperability Specification (IOS) for High Rate Packet Data (HRPD) Access Network Interfaces", 3GPP2 A.S0008-0 v3.0, May 2003.
[11] 3GPP2 TSG-A、 "相互運用性仕様高速パケットデータ（HRPD）アクセスネットワークインタフェース用（IOS）"、3GPP2 A.S0008-0 v3.0の、2003年5月。
[12] 3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard: Simple IP and Mobile IP services", X.S0011-002-D v.1.0, February 2006.
[12] 3GPP2 TSG-X、 "CDMA2000無線IPネットワーク標準：シンプルIPおよびモバイルIPサービス"、X.S0011-002-D v.1.0を、2006年2月。
[13] Devarapalli, V., Patel, A., Keung, K., and K. Chowdhury, "Mobile IPv6 Bootstrapping for the Authentication Option Protocol", Work in Progress, September 2007.
[13] Devarapalli、V.、パテル、A.、キョン、K.、およびK.チョードリ、 "認証オプションプロトコルのモバイルIPv6ブートストラップ"、進歩、2007年9月ワーク。
[14] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005.
[14]ソリマン、H.、カステルッシア、C.、エルMalki、K.、およびL. Bellier、 "階層型Mobile IPv6のモビリティ管理（HMIPv6の）"、RFC 4140、2005年8月。
[15] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[15] Devarapalli、V.、Wakikawa、R.、ペトレスク、A.、およびP. Thubert、 "ネットワークモビリティ（NEMO）基本サポートプロトコル"、RFC 3963、2005年1月。
[16] Gundavell, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", Work in Progress, February 2008.
[16] Gundavell、S.編、レオン、K.、Devarapalli、V.、チョードリ、K.、およびB.パティル、 "プロキシ・モバイルIPv6"、進歩、2008年2月に働いています。
[17] Kempf, J., Ed. and R. Koodli, "Distributing a Symmetric FMIPv6 Handover Key using SEND", RFC 5269, June 2008.
[17]ケンプ、J.、エド。そして、R. Koodli、RFC 5269、2008年6月 "SENDを使用して対称FMIPv6とハンドオーバキーの配布"。
[18] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[18] Arkko、J.、編、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索（SEND）"、RFC 3971、2005年3月。
[19] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[19] Narten氏、T.、Nordmarkと、E.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 4861、2007年9月。
[20] Aboba, B., Ed., "Architectural Implications of Link Indications", RFC 4907, June 2007.
[20] Aboba、B.、エド。、 "リンク適応の建築的意味"、RFC 4907、2007年6月。
Authors' Addresses
著者のアドレス
Hidetoshi Yokota KDDI Lab 2-1-15 Ohara, Fujimino Saitama, 356-8502 JP
ひでとし よこた Ｋっぢ ぁｂ ２ー１ー１５ おはら、 ふじみの さいたま、 ３５６ー８５０２ ＪＰ
Phone: +81 49 278 7894 Fax: +81 49 278 7510 EMail: yokota@kddilabs.jp
電話：+81 49 278 7894ファックス：+81 49 278 7510 Eメール：yokota@kddilabs.jp
Gopal Dommety Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 US
ゴパルDommetyシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134米国
Phone: +1 408 525 1404 EMail: gdommety@cisco.com
電話：+1 408 525 1404 Eメール：gdommety@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。