[要約] RFC 5271は、3G CDMAネットワークにおけるMobile IPv6の高速ハンドオーバーに関する規格です。このRFCの目的は、モバイルデバイスが異なるアクセスポイント間でスムーズに切り替えるための手順とプロトコルを提供することです。
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
3G CDMAネットワーク用のモバイルIPv6ファストハンドオーバー
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登録の取得も、ターゲットネットワークでトラフィックを送信または受信する前に、新しいケアオブアドレスを登録します。この期間中、モバイルノードに向けたパケットが失われる可能性があります。これは、Voice Over 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ネットワークで移動しながら、モバイルノード（MNS）が永続的なIP接続を維持できます。ホストベースのモビリティ管理を処理するために、3G CDMAネットワークで採用されています[12]。ただし、ハンドオーバー中、モバイルノード（MN）は無線リンクを切り替えて新しいアドレス（COA）を取得し、ホームエージェント（HA）と再登録する必要があります。これは、VoIPやビデオテレフォニーなどのリアルタイムアプリケーションでは望ましくありません。この破壊時間または遅延を短縮するために、モバイルIPv6 [3]の高速ハンドオーバープロトコルが提案されています。RFC 4260 [7]は、IEEE 802.11の仕様スイートに準拠したリンクレイヤーにこのモバイルIPv6高速ハンドオーバーをどのように実装できるかについてさらに説明しています。ただし、3G CDMAおよびIEEE 802.11ネットワークは、無線アクセス、ネットワークノードまたはパラメーターの表現、およびネットワーク添付ファイル手順で大きく異なります。たとえば、RFC 4260で指定された[アクセスポイント識別子、Access Router-ID、AR-INFO）]に基づくビーコンスキャンまたは新しいアクセスルーター（NAR）発見は、3G CDMAネットワークに直接適用することはできません。したがって、このドキュメントは、3G CDMAネットワークにモバイルIPv6高速ハンドオーバーを適用する方法を指定します。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[1]に記載されているとおりに解釈される。
This document refers to [3] for Mobile IPv6 fast handover terminology. Terms that first appear in this document are defined below:
このドキュメントは、モバイルIPv6高速ハンドオーバー用語の[3]を参照しています。このドキュメントに最初に表示される用語は、以下に定義されています。
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）：ノードにサービスを提供するパケットデータ（PDSN）で使用される識別子で、MNが以前にこの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.
フォワードパイロットチャネル：パイロットを運ぶフォワードチャネルの一部。フォワードチャネルは、3G CDMAアクセスネットワークからMNに送信される物理層チャネルの一部です。さらに、パイロットのいくつかのセット（アクティブセットまたはネイバーセットなど）が定義され、いつ、どこで引き渡すかを決定します。
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のブートストラップパラメーターの1つとも呼ばれます。
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桁までの10進数桁で、独自のモバイルターミナルまたはモバイルサブスクライバーを国際的に識別します。IMSIは、モバイルカントリーコード（MCC）、モバイルネットワークコード（MNC）、およびモバイルサブスクライバー識別番号（MSIN）の3つのフィールドで構成されています。IMSIの例は「440701234567890」です。ここで、「440」はMCC、「70」はMNC、「1234567890」がMSINです。IMSIは、ITU-T E.212番号標準に準拠しています[6]。この仕様では、IMSIは15桁以下（30〜39ヘキサデシマルのASCII値）で構成されるASCII文字列であり、IMSI桁ごとに1文字です。したがって、上記の例は、16進表記の「34 34 37 30 31 32 33 34 35 36 33 36 33 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をルーティングするエンティティは、パケットデータトラフィックを終了しました。PDSNは、リンク層セッションをMNSに確立、維持、および終了します。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].
セクターアドレス識別子（SectorID）：典型的なセルは、そのカバレッジエリアをいくつかのセクターに分割します。3G CDMAシステムでは、各セクターは異なるPN（擬似ノイズ）コードオフセットを使用し、SectorIDに関連付けられています。SectorIDの長さは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ネットワークの単純化された参照モデルを示しています。モバイルノード（MN）のホームエージェント（HA）と認証、認証、および会計（AAA）サーバーは、ホームIPネットワークに存在し、MNはアクセスプロバイダーネットワーク内または間にローミングします。通常、ホームIPネットワークにはMNSが入力されておらず、代わりにアクセスプロバイダーネットワークにのみ接続されています。モバイルIPv6登録の前に、MNはAccessルーター（AR）との3G CDMAアクセステクノロジー固有のリンク層接続を確立します。MNがARから別のARに移動すると、リンク層接続が再確立され、モバイルIPv6ハンドオーバーが実行されます。これらのARは、同じまたは異なるアクセスプロバイダーネットワークのいずれかにあります。この図は、MNが以前のアクセスルーター（PAR）からラジオアクセスネットワーク（RAN）を介して新しいアクセスルーター（NAR）に移動する状況を示しています。
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コードのオフセットとパイロットセットにあります。これは、近隣のセクターの見積もりを無線アクセスネットワーク（RAN）に提供します。MNがこれらの推定を送信するためのいくつかのトリガーがあります。たとえば、パイロットセットのパイロットの強度が現在のパイロットの強度を超えると、MNはアクセスネットワークに推定値を送信します。MNが移動するセクターが同じアクセスネットワークに属している限り、そのアクセスネットワーク内のモビリティはアクセス固有のインターフェイス[10]によって処理され、MNとAR間のリンク層接続は再確立なしで維持されます。MNは、データ通信を混乱させることなくパイロットを継続的に検索でき、タイムリーなハンドオーバーはネットワークによって支援されます。ただし、サービングアクセスネットワークが、最高のパイロット強度に関連するセクターが異なるARに属していることを発見した場合、MNとの接続を閉じようとします。その後、MNは新しいアクセスネットワークに新しいトラフィックチャネルを割り当てられ、その後、新しいARとの新しい接続を確立することを試みます。これにより、顕著なコミュニケーションの混乱を引き起こし、ユーザーエクスペリエンスの深刻な劣化につながる可能性があります。サービスの劣化を最小限に抑えるには、ARS間の引き渡し中に、RFC 5268で定義されているIPレベルの高速ハンドオーバーアプローチを関与させる必要があります。アクセスルーター間のハンドオーバーのトリガーとしてエアインターフェイス情報を使用できる場合、3G CDMAネットワークでモバイルIPv6の高速でスムーズなハンドオーバーを実現できます。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.
MNの新しいARへの引き渡しを支援するために、さまざまなタイプの情報を考慮することができます。ターゲットセクターまたはBSSの候補を含むパイロットセット、MNが存在するセル情報、無線アクセス内のサービングノード利用可能な場合は、ネットワーク、およびMNの場所。MNが移動するアクセスネットワークを識別するために、アクセスネットワーク識別子（ANID）またはサブネット情報を使用できます[9] [10]。このドキュメントでは、そのような情報のコレクションは「ハンドオーバーアシスト情報」と呼ばれます。3G CDMAネットワークでは、[3]で定義されている新しいアクセスポイント（AP）のリンク層アドレスは利用できない場合があります。この場合、このドキュメントで定義されているハンドオーバーアシスト情報オプションを代わりに使用する必要があります。
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.
FBUの送信時（高速バインディングアップデート）に従って[3]で定義されている2つのモードがあります。1つは「予測モード」と呼ばれ、MNはFBUを送信し、PAR（以前のアクセスルーター）リンクでFBAC（高速結合確認）を受信し、もう1つは「反応モード」と呼ばれ、MNはFBUを送信します。NAR（新しいアクセスルーター）リンク。予測モードでは、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) プロキシルーター広告のルーター勧誘が額面に送信されます。ターゲット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のプレフィックスを含むプロキシルーター広告（PRRTADV）がMNに送り返されます。MNはまた、RフラグがPRRTADVメッセージに設定されていないことを確認します。これは、ネットワークが予測高速ハンドオーバーモードをサポートしていることを示します（後で定義）。
(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）を作成し、NCOAを備えた高速バインディングアップデート（FBU）をPARに送信します。
(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は、ハンドオーバー謝辞（ハック）をPARに送り返し、これによりFBUの確認（FBACK）をMNに送信します。
(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は、バインディングアップデート（BU）をHAに送信して、NCOAでバインディングキャッシュエントリ（BCE）を更新し、HAはバインディング承認（BA）をMNに送り返します。
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.
NARは、MNからのハンドオーバーアシスト情報を参照することによって識別できると想定されています。予測モードを実行するには、MNは現在のアクセスネットワークとの接続が閉じられる前にFBUを送信する必要があります。MNがハンドオーバー前にFBUを送信できない場合、反応モードに戻る必要があります。MNがFBUを正常に送信したとしても、補充などのさまざまな理由でPARによる受信が遅れる可能性があります。NARがUNA（（c））の受信後に遅延FBUによってトリガーされた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）では、[3]に従って、プロキシ広告（RTSOLPR）のルーター勧誘（RTSOLPR）には、それぞれ新しいアクセスポイントとMNリンクレイヤーアドレス（LLA）オプション（オプションコード= 1および2）が含まれることになっています。新しいAP-LLAオプションは、3G CDMAネットワークのハンドオーバーアシスト情報オプションに置き換えられる場合があります。MN-LLAオプションについては、MNのLLAが利用できない場合、IMSI [11]などの3G固有のIDを使用できます。この場合、セクション6.2で定義されているMN IDオプションは、MN-LLAオプションの代わりに、必ずしも8オクテットの倍数ではない他のタイプのIDと長さをサポートできます。
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）では、PRRTADVには、NARのIPアドレスのオプションを含める必要があります。これは、Link-Localアドレスであり、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は、3G CDMAネットワークの初期アタッチメントのコールフローを示しています[12]。トラフィックチャネルが割り当てられた後、MNは最初にそれ自体とアクセスルーターとの間にリンク層接続を確立します。リンク層プロトコルとして、PPPはこの図で考慮され、PPPの握手が例として描かれています。リンク層接続が確立された後、MNはバインディングアップデートメッセージを送信することによりHAに登録します。ホームアドレス（HOA）、ケアオブアドレス（COA）、ホームエージェントアドレス（HA）、ホームリンクプレフィックス（HLP）など、モバイルIPv6を使用するためのいくつかのパラメーターがあります。[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（リンク制御プロトコル）Configure-Request/Responseメッセージが交換されます。
(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がリンク層接続を確立する期間中にも保存された場合、それは有益です。
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は他のピア（MNが接続されているAR）を除くインターフェイスIDを使用して一意のIPアドレスを作成できます。ただし、この場合、PARはPRRTADVの新しいネットワークの正しいプレフィックスをMNに提供することはできません。そのようなプレフィックスはNARによって選択され、ルーター広告で提供されているためです。したがって、MNはPARによって提供されるプレフィックスを使用して一時的なNCOAを構成し、正しいNCOAをNARによって割り当てる必要があります。したがって、3G CDMAネットワークでは、図2のステップ（c）でMNからFBUを受信すると、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).
o （g）でのリンク層接続の確立は、MN側でのデータ通信の準備ができることを示しているため、NARは、NCOA用のパケットがあるバッファがあるかどうかをすぐにチェックします。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).
o MNは、[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.
o NCOAは高速ハンドオーバー手順を介して構成できるため、ルーター広告は必要ありません。
Therefore, the procedures (g-4) to (g-7) can be skipped from the standard MIPv6 operation in Figure 3.
したがって、図3の標準MIPV6操作から手順（G-4）から（G-7）をスキップできます。
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:
ネットワークが予測高速ハンドオーバーモードをサポートしていない場合、リアクティブな高速ハンドオーバーが適用されます。このドキュメントでは、PRRTADVで新しいフラグが定義され、ネットワークの機能についてMNに通知します（セクション6.4を参照）。この状況でのパケット損失を最小限に抑えるために、MNがNARとの接続性を取り戻すまで、NARの代わりにPARがMNのパケットをバッファすることができます。NARは、NARのリンクでMNからPARの情報を取得し、PARでバッファリングされたパケットを受信します。この場合、PARはNARまたはNCOAのIPアドレスを知る必要はなく、NARがPARに接触するのを待つだけです。ただし、PARはMNのパケットをいつバッファするかを知る必要があるため、PARはFBUまたは下層シグナル伝達を介して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はUNAをNARに送ります。
(g) The MN sends the Fast Binding Update (FBU) to the PAR via the NAR.
(g) MNは、NARを介して高速バインディングアップデート（FBU）をPARに送信します。
(h) The NAR forwards the FBU from the MN to the PAR.
(h) NARはFBUをMNからPARに転送します。
(i) The PAR sends the Handover Initiate (HI) to the NAR with the Code set to 1.
(i) PARは、コードを1に設定して、ハンドオーバー開始（HI）をNARに送信します。
(j) The NAR sends the Handover Acknowledge (HAck) back to the PAR.
(j) NARは、ハンドオーバー確認（ハック）をパーに送り返します。
(k) The PAR sends the FBAck to the NAR.
(k) PARはFBACKを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はBUをHAに送信してNCOAでBCEを更新し、HAはBAをMNに送り返します。
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）では、FBUで新しいフラグ「B」が定義されています。このフラグセットで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 [20]のセクション2で定義されている原則を満たしているかどうかについて説明します。このドキュメントは、3GPP2で正確に指定されているリンク表示に関する3G CDMAネットワークに依存しています。したがって、原則（1）から（5）、（7）、（8）、および（11）、つまり「モデル検証」、「クリア定義」、「堅牢性」、「無効な適応からの回復」、「うっ血」制御「相互運用性」、「人種条件」、および「リンクの輸送」は、これらの仕様によって考慮されます。原則（6）「有効性」は、最適化の有効性に言及しています。このドキュメントは、RFC 5268に基づいてその有効性の基礎となっています。したがって、この原則はそのRFCによって扱われます。原則（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
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.
オクテットのhaivalueフィールドのサイズのhaiの長さ。
HAI-Value The value specified by the Option-Code.
hai-balueオプションコードで指定された値。
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).
オプションコードは、特定のタイプのハンドオーバーアシスト情報を示します。現在、NARの発見を支援するために2種類の情報が定義されています（セクション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.
haivalueフィールドのサイズに応じて、オプションサイズ全体が8オクテットの倍数であることを確認するために、適切なパディングを使用する必要があります。hai-lengthは、ha-valueのサイズを明確にするために使用されます。
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 Id-LengthオクテットのMN 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は、以前のネットワークに設定された次の新しい（b）フラグを使用してFBUをPARに送信する必要があります。バインディングアップデートメッセージ形式の残りの部分は、[2]で定義されているものと同じままです。また、[14]、[15]、および[16]で指定されている追加（m）、（r）、および（p）フラグがあります。それぞれ。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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」がPRRTADVで定義され、ネットワークがサポートする高速ハンドオーバーモードについて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.
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には信頼関係があり、それらとARSとMNの間のリンクが確保されていると想定できます。MNは、新しいリンクに取り付けるたびに認証されます。したがって、ARはMnを安全に識別できます。ただし、オペレーターのポリシーに応じて、[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 Chowdhury、Ashutosh Dutta、Ved Kafle、Vijay Devarapalliに感謝したいと思います。著者はまた、3GPP2のエキスパートレビューについてSebastian Thalananyに感謝します。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[2] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[3] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5268, June 2008.
[3] Koodli、R.、ed。、「Mobile IPv6 Fast Handovers」、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] McCann、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-A 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-A 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）アクセスネットワークインターフェイス-Rev A.」、A.S0007-A 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.、Patel、A.、Keung、K。、およびK. Chowdhury、「認証オプションプロトコル用のモバイル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] Soliman、H.、Castelluccia、C.、El Malki、K。、およびL. Bellier、「階層モバイル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.、Petrescu、A。、およびP. Thubert、「Network Mobility（NEMO）Basic Support Protocol」、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.、ed。、Leung、K.、Devarapalli、V.、Chowdhury、K。、およびB. Patil、「Proxy Mobile IPv6」、Work in Progress、2008年2月。
[17] Kempf, J., Ed. and R. Koodli, "Distributing a Symmetric FMIPv6 Handover Key using SEND", RFC 5269, June 2008.
[17] Kempf、J.、ed。およびR. Koodli、「Sendを使用した対称FMIPV6ハンドオーバーキーの配布」、RFC 5269、2008年6月。
[18] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[18] Arkko、J.、ed。、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（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.、Simpson、W。、およびH. Soliman、「IPバージョン6（IPv6）の近隣発見」、RFC 4861、2007年9月。
[20] Aboba, B., Ed., "Architectural Implications of Link Indications", RFC 4907, June 2007.
[20] Aboba、B.、ed。、「リンク表示の建築的意味」、RFC 4907、2007年6月。
Authors' Addresses
著者のアドレス
Hidetoshi Yokota KDDI Lab 2-1-15 Ohara, Fujimino Saitama, 356-8502 JP
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
Gopal Dommety Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 US
Gopal Dommety Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134 US
Phone: +1 408 525 1404
EMail: gdommety@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。