[要約] RFC 6252は、異なるドメイン間のハンドオーバー最適化のためのメディア非依存型プリ認証（MPA）のフレームワークに関するものです。このRFCの目的は、異なるネットワークドメイン間でのハンドオーバーの効率を向上させるためのプリ認証の仕組みを提供することです。
Internet Research Task Force (IRTF) A. Dutta, Ed.
Request for Comments: 6252 V. Fajardo
Category: Informational NIKSUN
ISSN: 2070-1721 Y. Ohba
K. Taniuchi
Toshiba
H. Schulzrinne
Columbia Univ.
June 2011
A Framework of Media-Independent Pre-Authentication (MPA) for Inter-Domain Handover Optimization
ドメイン間のハンドオーバー最適化のためのメディアに依存しない事前認証（MPA）のフレームワーク
Abstract
概要
This document describes Media-independent Pre-Authentication (MPA), a new handover optimization mechanism that addresses the issues on existing mobility management protocols and mobility optimization mechanisms to support inter-domain handover. MPA is a mobile-assisted, secure handover optimization scheme that works over any link layer and with any mobility management protocol, and is most applicable to supporting optimization during inter-domain handover. MPA's pre-authentication, pre-configuration, and proactive handover techniques allow many of the handoff-related operations to take place before the mobile node has moved to the new network. We describe the details of all the associated techniques and their applicability for different scenarios involving various mobility protocols during inter-domain handover. We have implemented the MPA mechanism for various network-layer and application-layer mobility protocols, and we report a summary of experimental performance results in this document.
このドキュメントでは、既存のモビリティ管理プロトコルの問題に対処する新しいハンドオーバー最適化メカニズムと、ドメイン間のハンドオーバーをサポートするモビリティ最適化メカニズムである、メディアに依存しない事前認証（MPA）について説明します。MPAは、任意のリンクレイヤーおよびあらゆるモビリティ管理プロトコルで機能するモバイルアシストの安全なハンドオーバー最適化スキームであり、ドメイン間のハンドオーバー中の最適化をサポートすることに最も適しています。MPAの著作権、事前構成、およびプロアクティブなハンドオーバー技術により、モバイルノードが新しいネットワークに移動する前に、ハンドオフ関連操作の多くが行われることがあります。すべての関連する手法の詳細と、ドメイン間のハンドオーバー中にさまざまなモビリティプロトコルを含むさまざまなシナリオに対するそれらの適用性について説明します。さまざまなネットワーク層およびアプリケーションレイヤーモビリティプロトコルのMPAメカニズムを実装しており、このドキュメントで実験的パフォーマンス結果の概要を報告しています。
This document is a product of the IP Mobility Optimizations (MOBOPTS) Research Group.
このドキュメントは、IP Mobility Optimizations（MOBOPTS）研究グループの製品です。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the MOBOPTS Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネット研究タスクフォース（IRTF）の製品です。IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適していない場合があります。このRFCは、インターネット研究タスクフォース（IRTF）のMobopts Research Groupのコンセンサスを表しています。IRSGによって公開されたことが承認された文書は、インターネット標準のレベルの候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6252.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6252で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Specification of Requirements ..............................5
1.2. Performance Requirements ...................................5
2. Terminology .....................................................7
3. Handover Taxonomy ...............................................7
4. Related Work ...................................................11
5. Applicability of MPA ...........................................12
6. MPA Framework ..................................................13
6.1. Overview ..................................................13
6.2. Functional Elements .......................................14
6.3. Basic Communication Flow ..................................16
7. MPA Operations .................................................20
7.1. Discovery .................................................21
7.2. Pre-Authentication in Multiple-CTN Environment ............22
7.3. Proactive IP Address Acquisition ..........................23
7.3.1. PANA-Assisted Proactive IP Address Acquisition .....24
7.3.2. IKEv2-Assisted Proactive IP Address Acquisition ....24
7.3.3. Proactive IP Address Acquisition Using
DHCPv4 Only ........................................24
7.3.4. Proactive IP Address Acquisition Using Stateless
Autoconfiguration ..................................26
7.4. Tunnel Management .........................................26
7.5. Binding Update ............................................28
7.6. Preventing Packet Loss ....................................29
7.6.1. Packet Loss Prevention in Single-Interface MPA .....29
7.6.2. Preventing Packet Losses for Multiple Interfaces ...29
7.6.3. Reachability Test ..................................30
7.7. Security and Mobility .....................................31
7.7.1. Link-Layer Security and Mobility ...................31
7.7.2. IP-Layer Security and Mobility .....................32
7.8. Authentication in Initial Network Attachment ..............33
8. Security Considerations ........................................33
9. Acknowledgments ................................................34
10. References ....................................................34
10.1. Normative References .....................................34
10.2. Informative References ...................................36
Appendix A. Proactive Duplicate Address Detection .................40
Appendix B. Address Resolution ....................................41
Appendix C. MPA Deployment Issues .................................42
C.1. Considerations for Failed Switching and Switch-Back ........42
C.2. Authentication State Management ............................43
C.3. Pre-Allocation of QoS Resources ............................44
C.4. Resource Allocation Issue during Pre-Authentication ........45
C.5. Systems Evaluation and Performance Results .................47
C.5.1. Intra-Technology, Intra-Domain .........................47
C.5.2. Inter-Technology, Inter-Domain .........................49
C.5.3. MPA-Assisted Layer 2 Pre-Authentication ................49
C.6. Guidelines for Handover Preparation ........................54
As wireless technologies, including cellular and wireless LANs, are becoming popular, supporting terminal handovers across different types of access networks, such as from a wireless LAN to CDMA or to General Packet Radio Service (GPRS), is considered a clear challenge. On the other hand, supporting seamless terminal handovers between access networks of the same type is still more challenging, especially when the handovers are across IP subnets or administrative domains. To address those challenges, it is important to provide terminal mobility that is agnostic to link-layer technologies in an optimized and secure fashion without incurring unreasonable complexity. In this document, we discuss a framework to support terminal mobility that provides seamless handovers with low latency and low loss. Seamless handovers are characterized in terms of performance requirements as described in Section 1.2. [MPA-WIRELESS] is an accompanying document that describes implementation of a few MPA-based systems, including performance results to show how existing protocols could be leveraged to realize the functionalities of MPA.
セルラーおよびワイヤレスLANを含むワイヤレステクノロジーが人気を博しているため、ワイヤレスLANからCDMAまたは一般的なパケットラジオサービス（GPRS）など、さまざまな種類のアクセスネットワークにわたるターミナルハンドオーバーをサポートすることは明確な課題と考えられています。一方、同じタイプのアクセスネットワーク間のシームレスなターミナルハンドオーバーをサポートすることは、特にハンドオーバーがIPサブネットまたは管理ドメイン全体にある場合、さらに困難です。これらの課題に対処するには、不合理な複雑さを伴うことなく、最適化された安全なファッションでリンク層技術をリンクレイヤーテクノロジーに依存している端末のモビリティを提供することが重要です。このドキュメントでは、遅延が低く、損失が低いシームレスなハンドオーバーを提供するターミナルモビリティをサポートするフレームワークについて説明します。セクション1.2で説明されているように、シームレスなハンドオーバーは、パフォーマンス要件の観点から特徴付けられます。[MPA-Wireless]は、MPAの機能性を実現するために既存のプロトコルを活用する方法を示すパフォーマンス結果を含む、いくつかのMPAベースのシステムの実装を説明する付随するドキュメントです。
Terminal mobility is accomplished by a mobility management protocol that maintains a binding between a locator and an identifier of a mobile node, where the binding is referred to as the mobility binding. The locator of the mobile node may dynamically change when there is a movement of the mobile node. The movement that causes a change of the locator may occur when there is a change in attachment point due to physical movement or network change. A mobility management protocol may be defined at any layer. In the rest of this document, the term "mobility management protocol" refers to a mobility management protocol that operates at the network layer or higher.
端子モビリティは、ロケーターとモバイルノードの識別子との間のバインディングを維持するモビリティ管理プロトコルによって達成されます。ここで、バインディングはモビリティ結合と呼ばれます。モバイルノードの動きがあると、モバイルノードのロケーターが動的に変更される場合があります。ロケーターの変更を引き起こす動きは、物理的な動きまたはネットワークの変化のためにアタッチメントポイントに変更があるときに発生する可能性があります。モビリティ管理プロトコルは、任意のレイヤーで定義できます。このドキュメントの残りの部分では、「モビリティ管理プロトコル」という用語は、ネットワークレイヤー以上で動作するモビリティ管理プロトコルを指します。
There are several mobility management protocols at different layers. Mobile IP [RFC5944] and Mobile IPv6 [RFC3775] are mobility management protocols that operate at the network layer. Similarly, MOBIKE (IKEv2 Mobility and Multihoming) [RFC4555] is an extension to the Internet Key Exchange Protocol (IKEv2) that provides the ability to deal with a change of an IP address of an IKEv2 end-point. There are several ongoing activities in the IETF to define mobility management protocols at layers higher than the network layer. HIP (Host Identity Protocol) [RFC5201] defines a new protocol layer between the network layer and transport layer to provide terminal mobility in a way that is transparent to both the network layer and transport layer. Also, SIP-based mobility is an extension to SIP to maintain the mobility binding of a SIP user agent [SIPMM].
異なるレイヤーには、いくつかのモビリティ管理プロトコルがあります。モバイルIP [RFC5944]およびモバイルIPv6 [RFC3775]は、ネットワークレイヤーで動作するモビリティ管理プロトコルです。同様に、Mobike（IKEV2 Mobility and Multihoming）[RFC4555）は、IKEV2エンドポイントのIPアドレスの変更に対処する機能を提供するインターネットキーエクスチェンジプロトコル（IKEV2）の拡張です。IETFには、ネットワークレイヤーよりも高いレイヤーでモビリティ管理プロトコルを定義するためのいくつかの継続的なアクティビティがあります。HIP（ホストIDプロトコル）[RFC5201]は、ネットワーク層と輸送層の間の新しいプロトコル層を定義し、ネットワーク層と輸送層の両方に透明な方法で端子モビリティを提供します。また、SIPベースのモビリティは、SIPユーザーエージェント[SIPMM]のモビリティ結合を維持するためのSIPの拡張機能です。
While mobility management protocols maintain mobility bindings, these cannot provide seamless handover if used in their current form. An additional optimization mechanism is needed to prevent the loss of in-flight packets transmitted during the mobile node's binding update procedure and to achieve seamless handovers. Such a mechanism is referred to as a mobility optimization mechanism. For example, mobility optimization mechanisms for Mobile IPv4 [RFC4881] and Mobile IPv6 [RFC5568] are defined to allow neighboring access routers to communicate and carry information about mobile terminals. There are protocols that are considered as "helpers" of mobility optimization mechanisms. The CARD (Candidate Access Router Discovery) protocol [RFC4066] is designed to discover neighboring access routers. CXTP (Context Transfer Protocol) [RFC4067] is designed to carry state that is associated with the services provided for the mobile node, or context, among access routers. In Section 4, we describe some of the fast-handover schemes that attempt to reduce the handover delay.
モビリティ管理プロトコルはモビリティバインディングを維持していますが、現在の形式で使用してもシームレスなハンドオーバーを提供することはできません。モバイルノードのバインディングアップデート手順中に送信された飛行中のパケットの損失を防ぎ、シームレスなハンドオーバーを達成するには、追加の最適化メカニズムが必要です。このようなメカニズムは、モビリティ最適化メカニズムと呼ばれます。たとえば、モバイルIPv4 [RFC4881]およびモバイルIPv6 [RFC5568]のモビリティ最適化メカニズムは、近隣のアクセスルーターがモバイル端子に関する情報を通信および携帯できるように定義されています。モビリティ最適化メカニズムの「ヘルパー」と見なされるプロトコルがあります。カード（候補アクセスルーター発見）プロトコル[RFC4066]は、隣接するアクセスルーターを発見するように設計されています。CXTP（コンテキスト転送プロトコル）[RFC4067]は、アクセスルーター間でモバイルノードまたはコンテキストに提供されるサービスに関連付けられている状態を運ぶように設計されています。セクション4では、ハンドオーバー遅延を減らしようとする速い手渡しスキームのいくつかについて説明します。
There are several issues in existing mobility optimization mechanisms. First, existing mobility optimization mechanisms are tightly coupled with specific mobility management protocols. For example, it is not possible to use mobility optimization mechanisms designed for Mobile IPv4 or Mobile IPv6 with MOBIKE. What is strongly desired is a single, unified mobility optimization mechanism that works with any mobility management protocol. Second, there is no existing mobility optimization mechanism that easily supports handovers across administrative domains without assuming a pre-established security association between administrative domains.
既存のモビリティ最適化メカニズムにはいくつかの問題があります。まず、既存のモビリティ最適化メカニズムは、特定のモビリティ管理プロトコルと密接に結びついています。たとえば、モバイクを備えたモバイルIPv4またはモバイルIPv6向けに設計されたモビリティ最適化メカニズムを使用することはできません。強く望まれているのは、あらゆるモビリティ管理プロトコルで機能する単一の統一されたモビリティ最適化メカニズムです。第二に、管理ドメイン間に事前に確立されたセキュリティ関連を想定せずに、管理ドメイン全体の携帯船を簡単にサポートする既存のモビリティ最適化メカニズムはありません。
A mobility optimization mechanism should work across administrative domains in a secure manner only based on a trust relationship between a mobile node and each administrative domain. Third, a mobility optimization mechanism needs to support not only terminals with multiple interfaces where simultaneous connectivity through multiple interfaces or connectivity through a single interface can be expected, but also terminals with a single interface.
モビリティ最適化メカニズムは、モバイルノードと各管理ドメインの間の信頼関係に基づいてのみ、安全な方法で管理ドメイン全体で機能する必要があります。第三に、モビリティ最適化メカニズムは、複数のインターフェイスを介した同時接続または単一のインターフェイスを介した接続性を介した複数のインターフェイスを持つ端子だけでなく、単一のインターフェイスを持つ端子もサポートする必要があります。
This document describes a framework of Media-independent Pre-Authentication (MPA), a new handover optimization mechanism that addresses all those issues. MPA is a mobile-assisted, secure handover optimization scheme that works over any link layer and with any mobility management protocol, including Mobile IPv4, Mobile IPv6, MOBIKE, HIP, and SIP mobility. In cases of multiple operators without a roaming relationship or without an agreement to participate in a key management scheme, MPA provides a framework that can perform pre-authentication to establish the security mechanisms without assuming a common source of trust. In MPA, the notion of IEEE 802.11i pre-authentication is extended to work at a higher layer, with additional mechanisms to perform early acquisition of an IP address from a network where the mobile node may move, as well as proactive handover to the network while the mobile node is still attached to the current network. Since this document focuses on the MPA framework, it is left to future work to choose the protocols for MPA and define detailed operations. The accompanying document [MPA-WIRELESS] provides one method that describes usage and interactions between existing protocols to accomplish MPA functionality.
このドキュメントでは、これらすべての問題に対処する新しいハンドオーバー最適化メカニズムである、メディアに依存しない事前認証（MPA）のフレームワークについて説明します。MPAは、任意のリンクレイヤーで動作し、モバイルIPv4、モバイルIPv6、Mobike、HIP、SIPモビリティなどのモビリティ管理プロトコルで動作するモバイル支援の安全なハンドオーバー最適化スキームです。MPAは、共通の管理源を想定せずにセキュリティメカニズムを確立するために事前認証を実行できるフレームワークを提供します。MPAでは、IEEE 802.11iの概念は、モバイルノードが移動するネットワークからIPアドレスを早期に取得するための追加のメカニズムと、ネットワークへのプロアクティブなハンドオーバーを実行するための追加のメカニズムにより、より高いレイヤーで動作するように拡張されます。モバイルノードはまだ現在のネットワークに接続されています。このドキュメントはMPAフレームワークに焦点を当てているため、MPAのプロトコルを選択し、詳細な操作を定義することは将来の作業に任されています。付随するドキュメント[MPA-Wireless]は、MPA機能を達成するための既存のプロトコル間の使用と相互作用を説明する1つの方法を提供します。
This document represents the consensus of the IP Mobility Optimizations (MOBOPTS) Research Group. It has been reviewed by Research Group members active in the specific area of work.
このドキュメントは、IPモビリティ最適化（MOBOPTS）研究グループのコンセンサスを表しています。特定の作業分野で活動している研究グループメンバーによってレビューされています。
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. 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 [RFC2119].
このドキュメントでは、仕様の要件を示すためにいくつかの単語を使用しています。これらの言葉はしばしば大文字になります。「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
In order to provide desirable quality of service for interactive Voice over IP (VoIP) and streaming traffic, one needs to limit the value of end-to-end delay, jitter, and packet loss to a certain threshold level. ITU-T and ITU-E standards define the acceptable values for these parameters. For example, for one-way delay, ITU-T G.114 [RG98] recommends 150 ms as the upper limit for most of the applications, and 400 ms as generally unacceptable delay. One-way delay tolerance for video conferencing is in the range of 200 to 300 ms [ITU98]. Also, if an out-of-order packet is received after a certain threshold, it is considered lost. According to ETSI TR 101 [ETSI], a normal voice conversation can tolerate up to 2% packet loss. But this is the mean packet loss probability and may be applicable to a scenario when the mobile node is subjected to repeated handoff during a normal conversation. Measurement techniques for delay and jitter are described in [RFC2679], [RFC2680], and [RFC2681].
IP（VOIP）およびストリーミングトラフィックのインタラクティブボイス（VOIP）に望ましいサービス品質を提供するには、エンドツーエンドの遅延、ジッター、およびパケット損失の価値を特定のしきい値レベルに制限する必要があります。ITU-TおよびITU-E標準は、これらのパラメーターの許容値を定義します。たとえば、一元配置遅延の場合、ITU-T G.114 [RG98]は、ほとんどのアプリケーションの上限として150ミリ秒、一般的に容認できない遅延として400ミリ秒を推奨します。ビデオ会議の一元配置遅延許容範囲は、200〜300ミリ秒の範囲です[ITU98]。また、特定のしきい値の後にオーダーアウトパケットが受信された場合、それは失われたと見なされます。ETSI TR 101 [ETSI]によると、通常の音声会話は最大2％のパケット損失を許容できます。ただし、これは平均パケット損失確率であり、モバイルノードが通常の会話中に繰り返しハンドオフにさらされる場合のシナリオに適用できる場合があります。遅延とジッターの測定技術は、[RFC2679]、[RFC2680]、および[RFC2681]で説明されています。
In the case of interactive VoIP traffic, end-to-end delay affects the jitter value, and thus is an important issue to consider. An end-to-end delay consists of several components, such as network delay, operating system (OS) delay, codec delay, and application delay. A complete analysis of these delays can be found in [WENYU]. During a mobile node's handover, in-flight transient traffic cannot reach the mobile node because of the associated handover delay. These in-flight packets could either be lost or buffered. If the in-flight packets are lost, this packet loss will contribute to jitter between the last packet before handoff and the first packet after handoff. If these packets are buffered, packet loss is minimized, but there is additional jitter for the in-flight packets when these are flushed after the handoff. Buffering during handoff avoids the packet loss, but at the cost of additional one-way delay. A tradeoff between one-way delay and packet loss is desired based on the type of application. For example, for a streaming application, packet loss can be reduced by increasing the playout buffer, resulting in longer one-way packet delay.
インタラクティブなVoIPトラフィックの場合、エンドツーエンドの遅延はジッター値に影響を与えるため、考慮すべき重要な問題です。エンドツーエンドの遅延は、ネットワーク遅延、オペレーティングシステム（OS）遅延、コーデック遅延、アプリケーションの遅延など、いくつかのコンポーネントで構成されています。これらの遅延の完全な分析は、[wenyu]で見つけることができます。モバイルノードのハンドオーバー中に、交差しているトランスジェットトラフィックは、関連するハンドオーバー遅延のため、モバイルノードに到達できません。これらの飛行中のパケットは、紛失またはバッファリングされる可能性があります。飛行中のパケットが失われた場合、このパケットの損失は、ハンドオフ前の最後のパケットとハンドオフ後の最初のパケットの間のジッターに寄与します。これらのパケットがバッファリングされている場合、パケットの損失は最小限に抑えられますが、ハンドオフ後にこれらがフラッシュされると、飛行中のパケットに追加のジッターがあります。ハンドオフ中のバッファリングは、パケットの損失を回避しますが、追加の一方向遅延がかかります。一元配置遅延とパケット損失の間のトレードオフは、アプリケーションのタイプに基づいて望まれます。たとえば、ストリーミングアプリケーションの場合、プレイアウトバッファーを増やすことでパケットの損失を減らすことができ、一方向のパケット遅延が長くなります。
The handover delay is attributed to several factors, such as discovery, configuration, authentication, binding update, and media delivery. Many of the security-related procedures, such as handover keying and re-authentication procedures, deal with cases where there is a single source of trust at the top, and the underlying Authentication, Authorization, and Accounting (AAA) domain elements trust the top source of trust and the keys it generates and distributes. In this scenario, there is an appreciable delay in re-establishing link-security-related parameters, such as authentication, link key management, and access authorization during inter-domain handover. The focus of this document is the design of a framework that can reduce the delay due to authentication and other handoff-related operations such as configuration and binding update.
ハンドオーバー遅延は、発見、構成、認証、拘束力のある更新、メディア配信など、いくつかの要因に起因します。ハンドオーバーキーイングや再認証手順などのセキュリティ関連の手順の多くは、最上部に単一の信頼源がある場合、および基礎となる認証、承認、および会計（AAA）ドメイン要素が最上位に信頼できるケースを扱います。信頼のソースとそれが生成および配布する鍵。このシナリオでは、認証、リンクキー管理、ドメイン間のハンドオーバー中のアクセス許可など、リンクセキュリティ関連のパラメーターを再確立するにはかなりの遅延があります。このドキュメントの焦点は、認証や構成やバインディングアップデートなどの他のハンドオフ関連操作による遅延を減らすことができるフレームワークの設計です。
Mobility Binding: A binding between a locator and an identifier of a mobile terminal.
モビリティバインディング：ロケーターとモバイル端末の識別子の間のバインディング。
Mobility Management Protocol (MMP): A protocol that operates at the network layer or above to maintain a binding between a locator and an identifier of a mobile node.
Mobility Management Protocol（MMP）：ネットワークレイヤー以上で動作するプロトコルは、ロケーターとモバイルノードの識別子間のバインディングを維持します。
Binding Update (BU): A procedure to update a mobility binding.
バインディングアップデート（BU）：モビリティバインディングを更新する手順。
Media-independent Pre-Authentication Mobile Node (MN): A mobile node using Media-independent Pre-Authentication (MPA). MPA is a mobile-assisted, secure handover optimization scheme that works over any link layer and with any mobility management protocol. An MPA mobile node is an IP node. In this document, the term "mobile node" or "MN" without a modifier refers to "MPA mobile node". An MPA mobile node usually has a functionality of a mobile node of a mobility management protocol as well.
メディアに依存しない事前認証モバイルノード（MN）：メディア非依存の事前認証（MPA）を使用したモバイルノード。MPAは、任意のリンクレイヤーおよびモビリティ管理プロトコルで機能するモバイル支援の安全なハンドオーバー最適化スキームです。MPAモバイルノードはIPノードです。このドキュメントでは、修飾子のない「モバイルノード」または「MN」という用語は、「MPAモバイルノード」を指します。MPAモバイルノードには、通常、モビリティ管理プロトコルのモバイルノードの機能があります。
Candidate Target Network (CTN): A network to which the mobile node may move in the near future.
候補ターゲットネットワーク（CTN）：近い将来にモバイルノードが移動するネットワーク。
Target Network (TN): The network to which the mobile node has decided to move. The target network is selected from one or more candidate target networks.
ターゲットネットワーク（TN）：モバイルノードが移動することを決定したネットワーク。ターゲットネットワークは、1つ以上の候補ターゲットネットワークから選択されます。
Proactive Handover Tunnel (PHT): A bidirectional IP tunnel [RFC2003] [RFC2473] that is established between the MPA mobile node and an access router of a candidate target network. In this document, the term "tunnel" without a modifier refers to "proactive handover tunnel".
プロアクティブハンドオーバートンネル（PHT）：MPAモバイルノードと候補ターゲットネットワークのアクセスルーターの間に確立される双方向IPトンネル[RFC2003] [RFC2473]。このドキュメントでは、修飾子のない「トンネル」という用語は、「プロアクティブなハンドオーバートンネル」を指します。
Point of Attachment (PoA): A link-layer device (e.g., a switch, an access point, or a base station) that functions as a link-layer attachment point for the MPA mobile node to a network.
ポイントオブアタッチメント（POA）：ネットワークへのMPAモバイルノードのリンク層アタッチメントポイントとして機能するリンク層デバイス（スイッチ、アクセスポイント、またはベースステーションなど）。
Care-of Address (CoA): An IP address used by a mobility management protocol as a locator of the MPA mobile node.
Care-of Address（COA）：MPAモバイルノードのロケーターとしてモビリティ管理プロトコルによって使用されるIPアドレス。
Based on the type of movement, type of access network, and underlying mobility support, one can primarily define the handover as inter-technology, intra-technology, inter-domain, and intra-domain. We describe briefly each of these handover processes. However, our focus of the discussion is on inter-domain handover.
動きの種類、アクセスネットワークの種類、および基礎となるモビリティサポートに基づいて、主にハンドオーバーをテクノロジー間、テクノロジー内、ドメイン間、およびドメイン内として定義できます。これらのハンドオーバープロセスのそれぞれを簡単に説明します。ただし、議論の焦点は、ドメイン間のハンドオーバーにあります。
Inter-technology: A mobile node may be equipped with multiple interfaces, where each interface can support a different access technology (e.g., 802.11, CDMA). A mobile node may communicate with one interface at any time in order to conserve power. During the handover, the mobile node may move out of the footprint of one access technology (e.g., 802.11) and move into the footprint of a different access technology (e.g., CDMA). This will warrant switching of the communicating interface on the mobile node as well. This type of inter-technology handover is often called "vertical handover", since the mobile node moves between two different cell sizes.
テクノロジー間：モバイルノードには、各インターフェイスが異なるアクセステクノロジー（802.11、CDMAなど）をサポートできる複数のインターフェイスが装備されている場合があります。モバイルノードは、電力を節約するために、いつでも1つのインターフェイスと通信できます。ハンドオーバー中、モバイルノードは、1つのアクセステクノロジーのフットプリント（802.11など）のフットプリントから移動し、異なるアクセステクノロジー（CDMAなど）のフットプリントに移動する場合があります。これにより、モバイルノード上の通信インターフェイスの切り替えも保証されます。モバイルノードは2つの異なるセルサイズ間で移動するため、このタイプの技術間ハンドオーバーは「垂直ハンドオーバー」と呼ばれることがよくあります。
Intra-technology: An intra-technology handover is defined as when a mobile node moves within the same type of access technology, such as between 802.11[a,b,n] and 802.11 [a,b,n] or between CDMA1XRTT and CDMA1EVDO. In this scenario, a mobile node may be equipped with a single interface (with multiple PHY types of the same technology) or with multiple interfaces. An intra-technology handover may involve intra-subnet or inter-subnet movement and thus may need to change its L3 locator, depending upon the type of movement.
テクノロジー内：テクノロジー内のハンドオーバーは、802.11 [a、b、n]と802.11 [a、b、n]、またはcdma1xrttとcdma1evdoの間など、モバイルノードが同じタイプのアクセステクノロジー内で移動する場合として定義されます。。このシナリオでは、モバイルノードには、単一のインターフェイス（同じテクノロジーの複数のPHYタイプを含む）または複数のインターフェイスを備えている場合があります。テクノロジー内のハンドオーバーには、サブネット内またはサブネット間の動きが含まれる場合があるため、動きの種類に応じて、L3ロケーターを変更する必要があります。
Inter-domain: A domain can be defined in several ways. But for the purposes of roaming, we define "domain" as an administrative domain that consists of networks managed by a single administrative entity that authenticates and authorizes a mobile node for accessing the networks. An administrative entity may be a service provider, an enterprise, or any organization. Thus, an inter-domain handover will by default be subjected to inter-subnet handover, and in addition it may be subjected to either inter-technology or intra-technology handover. A mobile node is subjected to inter-subnet handover when it moves from one subnet (broadcast domain) to another subnet (broadcast domain). Inter-domain handover will be subjected to all the transition steps a subnet handover goes through, and it will be subjected to authentication and authorization processes as well. It is also likely that the type of mobility support in each administrative domain will be different. For example, administrative domain A may have Mobile IP version 6 (MIPv6) support, while administrative domain B may use Proxy MIPv6 [RFC5213].
ドメイン間：ドメインはいくつかの方法で定義できます。しかし、ローミングの目的のために、「ドメイン」を、ネットワークにアクセスするためのモバイルノードを認証および承認する単一の管理エンティティによって管理されるネットワークで構成される管理ドメインとして定義します。管理エンティティは、サービスプロバイダー、企業、または任意の組織である場合があります。したがって、ドメイン間のハンドオーバーは、デフォルトではサブネット間ハンドオーバーの対象となり、さらに、技術間またはテクノロジー内のハンドオーバーのいずれかにさらされる場合があります。モバイルノードは、1つのサブネット（ブロードキャストドメイン）から別のサブネット（ブロードキャストドメイン）に移動すると、サブネット間ハンドオーバーにかけられます。ドメイン間のハンドオーバーは、サブネットのハンドオーバーが通過するすべての移行ステップにかけられ、認証と承認プロセスにも適用されます。また、各管理ドメインのモビリティサポートの種類が異なる可能性があります。たとえば、管理ドメインAにはモバイルIPバージョン6（MIPV6）サポートがあり、管理ドメインBはプロキシMIPv6 [RFC5213]を使用する場合があります。
Intra-domain: When a mobile node's movement is confined to movement within an administrative domain, it is called "intra-domain movement". An intra-domain movement may involve intra-subnet, inter-subnet, intra-technology, and inter-technology as well.
ドメイン内：モバイルノードの動きが管理ドメイン内の動きに限定される場合、「ドメイン内の動き」と呼ばれます。ドメイン内運動には、サブネット内、サブネット間、テクノロジー内、およびテクノロジー間も含まれる場合があります。
Both inter-domain and intra-domain handovers can be subjected to either inter-technology or intra-technology handover based on the network access characteristics. Inter-domain handover requires authorization for acquisition or modification of resources assigned to a mobile node, and the authorization needs interaction with a central authority in a domain. In many cases, an authorization procedure during inter-domain handover follows an authentication procedure that also requires interaction with a central authority in a domain. Thus, security associations between the network entities, such as routers in the neighboring administrative domains, need to be established before any interaction takes place between these entities. Similarly, an inter-domain mobility may involve different mobility protocols, such as MIPv6 and Proxy MIPv6, in each of its domains. In that case, one needs a generalized framework to achieve the optimization during inter-domain handover. Figure 1 shows a typical example of inter-domain mobility involving two domains, domain A and domain B. It illustrates several important components, such as a AAA Home server (AAAH); AAA visited servers (e.g., AAAV1 and AAAV2); an Authentication Agent (AA); a layer 3 point of attachment, such as an Access Router (AR); and a layer 2 point of attachment, such as an Access Point (AP). Any mobile node may be using a specific mobility protocol and associated mobility optimization technique during intra-domain movement in either domain. But the same optimization technique may not be suitable to support inter-domain handover, independent of whether it uses the same or a different mobility protocol in either domain.
ドメイン間およびドメイン内の両方の携帯電話は、ネットワークアクセスの特性に基づいて、テクノロジー間またはテクノロジー内のハンドオーバーのいずれかを受けることができます。ドメイン間のハンドオーバーには、モバイルノードに割り当てられたリソースの取得または変更の認可が必要であり、承認にはドメイン内の中央当局との対話が必要です。多くの場合、ドメイン間のハンドオーバー中の承認手順は、ドメイン内の中央当局との相互作用も必要とする認証手順に従います。したがって、隣接する管理ドメインのルーターなどのネットワークエンティティ間のセキュリティ関連は、これらのエンティティ間で相互作用する前に確立する必要があります。同様に、ドメイン間モビリティには、各ドメインにMIPV6やProxy MIPV6などのさまざまなモビリティプロトコルが含まれる場合があります。その場合、ドメイン間のハンドオーバー中に最適化を実現するために、一般化されたフレームワークが必要です。図1は、ドメインAとドメインBの2つのドメインを含むドメイン間モビリティの典型的な例を示しています。これは、AAAホームサーバー（AAAH）などのいくつかの重要なコンポーネントを示しています。AAAはサーバーにアクセスしました（AAAV1やAAAV2など）。認証エージェント（AA）;アクセスルーター（AR）などのレイヤー3ポイント。アクセスポイント（AP）などのレイヤー2ポイント。どちらのモバイルノードも、どちらのドメインでもドメイン内運動中に特定のモビリティプロトコルと関連するモビリティ最適化手法を使用している場合があります。しかし、同じ最適化手法は、どちらのドメインでも同じモビリティプロトコルを使用するか、異なるモビリティプロトコルを使用するかどうかに関係なく、ドメイン間のハンドオーバーをサポートするのに適していない場合があります。
+-----------------------------+
| +--------+ |
| | | |
| | AAAH ------------------|
| | | | |
| +|-------+ | |
| | | |
| | Home Domain | |
| | | |
+-------|---------------------+ |
| |
| |
| |
+----------------------------|---------+ +-------------|------------+
| Domain A | | | Domain B | |
| | | | +|-------+ |
| +-------|+ | | +-----+ | | |
| | | | | | ------ AAAV2 | |
| | AAAV1 | | | | AA | | | |
| +-------------- | | | +|----+ +--------+ |
| | | +--------+ | | | |
| |AA | | | |--- ---- |
| +--|--+ | | / \ / \ |
| | /----\ | || AR |-----| AR | |
| -|-- / \ | | \ / \ / |
| / \ | AR | | | -|-- --|- |
| | AR ----------- / | |+--|---+ +------|------+ |
| \ / \--|-/ | || AP4 | | L2 Switch | |
| -/-- +-----|------+ | || | +-|---------|-+ |
| / | L2 Switch | | |+------+ | | |
| / +-|-------|--+ | | +---|--+ +----|-+ |
| +----/-+ +----|-+ +-|----+ | | | | | | |
| | | | | | | | | | AP5 | |AP6 | |
| | AP1 | | AP2 | | AP3 | | | +----|-+ +------+ |
| +------+ +------+ +--|---+ | | | |
+--------------------------------|-----+ +------------ |------------+
--|--------- |
//// \\\\ -----|-----
// +------+ //// +------+ \\\\
| | MN ------------->|MN | \\\
| | | | | | | |
| +------+ | | +------+ |
\\ | // |
\\\\ \\\/ ///
------------ \\\\------------- ////
Figure 1: Inter-Domain Mobility
図1：ドメイン間モビリティ
While basic mobility management protocols such as Mobile IP [RFC5944], Mobile IPv6 [RFC3775], and SIP-Mobility [SIPMM] provide continuity to TCP and RTP traffic, these are not optimized to reduce the handover latency during a mobile node's movement between subnets and domains. In general, these mobility management protocols introduce handover delays incurred at several layers, such as layer 3 and the application layer, for updating the mobile node's mobility binding. These protocols are affected by underlying layer 2 delay as well. As a result, applications using these mobility protocols suffer from performance degradation.
モバイルIP [RFC5944]、モバイルIPv6 [RFC3775]、SIP-Mobility [SIPMM]などの基本的なモビリティ管理プロトコルは、TCPおよびRTPトラフィックの連続性を提供しますが、モバイルノードのサブセット間の移動中のハンドオーバーレイテンシを減らすために最適化されていません。およびドメイン。一般に、これらのモビリティ管理プロトコルは、モバイルノードのモビリティ結合を更新するために、レイヤー3やアプリケーションレイヤーなどの複数のレイヤーで発生したハンドオーバー遅延を導入します。これらのプロトコルは、基礎となるレイヤー2の遅延の影響を受けます。その結果、これらのモビリティプロトコルを使用したアプリケーションは、パフォーマンスの劣化に悩まされています。
There have been several optimization techniques that apply to current mobility management schemes that try to reduce handover delay and packet loss during a mobile node's movement between cells, subnets, and domains. Micro-mobility management schemes such as [CELLIP] and [HAWAII], and intra-domain mobility management schemes such as [IDMP], [MOBIP-REG], and [RFC5380], provide fast handover by limiting the signaling updates within a domain. Fast Mobile IP protocols for IPv4 and IPv6 networks [RFC4881] [RFC5568] utilize mobility information made available by link-layer triggers. Yokota et al. [YOKOTA] propose the joint use of an access point and a dedicated Media Access Control (MAC) bridge to provide fast handover without altering the MIPv4 specification. Shin et al. [MACD] propose a scheme that reduces the delay due to MAC-layer handoff by providing a cache-based algorithm. In this scheme, the mobile node caches the neighboring channels that it has already visited and thus uses a selective scanning method. This helps to reduce the associated scanning time.
モバイルノードのセル、サブネット、およびドメイン間の移動中にハンドオーバー遅延とパケット損失を減らしようとする現在のモビリティ管理スキームに適用されるいくつかの最適化手法がありました。[Cellip]や[Hawaii]などのマイクロモビリティ管理スキーム、および[IDMP]、[Mobip-Reg]、[RFC5380]などのドメイン内モビリティ管理スキームは、ドメイン内のシグナリング更新を制限することにより高速ハンドオーバーを提供します。。IPv4およびIPv6ネットワークの高速モバイルIPプロトコル[RFC4881] [RFC5568]は、Link-Layerトリガーによって利用可能なモビリティ情報を利用しています。横浜ら。[Yokota]は、MIPV4仕様を変更せずに高速ハンドオーバーを提供するために、アクセスポイントと専用メディアアクセス制御（MAC）ブリッジの共同使用を提案します。Shin et al。[MACD]キャッシュベースのアルゴリズムを提供することにより、MAC層のハンドオフによる遅延を減らすスキームを提案します。このスキームでは、モバイルノードは既にアクセスしている隣接チャネルをキャッシュし、したがって選択的なスキャン方法を使用します。これにより、関連するスキャン時間を短縮するのに役立ちます。
Some mobility management schemes use dual interfaces, thus providing make-before-break [SUM]. In a make-before-break situation, communication usually continues with one interface when the secondary interface is in the process of getting connected. The IEEE 802.21 working group is discussing these scenarios in detail [802.21]. Providing fast handover using a single interface needs more careful design than for a client with multiple interfaces. Dutta et al. [SIPFAST] provide an optimized handover scheme for SIP-based mobility management, where the transient traffic is forwarded from the old subnet to the new one by using an application-layer forwarding scheme. [MITH] provides a fast-handover scheme for the single-interface case that uses mobile-initiated tunneling between the old Foreign Agent and a new Foreign Agent. [MITH] defines two types of handover schemes: Pre-MIT (Mobile Initiated Tunneling) and Post-MIT (Media Initiated Tunneling). The proposed MPA scheme is very similar to Mobile Initiated Tunneling Handoff's (MITH's) predictive scheme, where the mobile node communicates with the Foreign Agent before actually moving to the new network. However, the MPA scheme is not limited to MIP; this scheme takes care of movement between domains and performs pre-authentication in addition to proactive handover. Thus, MPA reduces the overall delay to a period close to that of link-layer handover delay. Most of the mobility optimization techniques developed so far are restricted to a specific type of mobility protocol only. While supporting optimization for inter-domain mobility, these protocols assume that there is a pre-established security arrangement between two administrative domains. But this assumption may not always be viable. Thus, there is a need to develop an optimization mechanism that can support inter-domain mobility without any underlying constraints or security-related assumptions.
一部のモビリティ管理スキームでは、デュアルインターフェイスを使用しているため、ブレイク前[合計]を提供します。ブレイク前の状況では、セカンダリインターフェイスが接続の過程にある場合、通常、通信は1つのインターフェイスで続きます。IEEE 802.21ワーキンググループは、これらのシナリオを詳細に議論しています[802.21]。単一のインターフェイスを使用して高速ハンドオーバーを提供するには、複数のインターフェイスを持つクライアントよりも慎重な設計が必要です。Dutta et al。[SIPFAST] SIPベースのモビリティ管理のための最適化されたハンドオーバースキームを提供します。ここでは、アプリケーション層転送スキームを使用して、過渡トラフィックが古いサブネットから新しいサブネットに転送されます。[MITH]は、古い外国人エージェントと新しい外国人エージェントの間でモバイル開始トンネリングを使用するシングルインターフェイスケースの高速手渡しスキームを提供します。[MITH]は、2種類のハンドオーバースキームを定義します。MITPRE-MIT（モバイル開始トンネル）とMIT後（メディア開始トンネリング）。提案されたMPAスキームは、モバイルノードが実際に新しいネットワークに移動する前に、モバイルノードが外国人エージェントと通信するモバイル開始ハンドオフ（MITHの）予測スキームに非常に似ています。ただし、MPAスキームはMIPに限定されません。このスキームは、ドメイン間の動きを処理し、プロアクティブなハンドオーバーに加えて事前認証を実行します。したがって、MPAは、全体的な遅延をリンク層のハンドオーバー遅延の期間に近い期間に減らします。これまでに開発されたモビリティ最適化手法のほとんどは、特定のタイプのモビリティプロトコルのみに制限されています。ドメイン間モビリティの最適化をサポートしている間、これらのプロトコルは、2つの管理ドメイン間に事前に確立されたセキュリティの取り決めがあると想定しています。しかし、この仮定は常に実行可能ではないかもしれません。したがって、根本的な制約やセキュリティ関連の仮定なしでドメイン間モビリティをサポートできる最適化メカニズムを開発する必要があります。
Recently, the HOKEY working group within the IETF has been defining ways to expedite the authentication process. In particular, it has defined pre-authentication [RFC5836] and fast re-authentication [RFC5169] mechanisms to expedite the authentication and security association process.
最近、IETF内のHokeyワーキンググループは、認証プロセスを促進する方法を定義しています。特に、認証とセキュリティの関連プロセスを促進するために、事前認証[RFC5836]および高速再認証[RFC5169]メカニズムを定義しました。
MPA is more applicable where an accurate prediction of movement can be easily made. For other environments, special care must be taken to deal with issues such as pre-authentication to multiple CTNs (Candidate Target Networks), and failed switching and switching back as described in [MPA-WIRELESS]. However, addressing those issues in actual deployments may not be easier. Some of the deployment issues are described in Appendix C.
MPAは、動きの正確な予測を簡単に作成できる場合、より適用可能です。他の環境では、複数のCTN（候補ターゲットネットワーク）への事前認証などの問題に対処するために特別な注意を払う必要があり、[MPA-Wireless]に記載されているように、切り替えと切り替えに失敗しました。ただし、実際の展開でこれらの問題に対処するのは簡単ではないかもしれません。展開の問題のいくつかは、付録Cで説明されています。
The authors of the accompanying document [MPA-WIRELESS] have cited several use cases of how MPA can be used to optimize several network-layer and application-layer mobility protocols. The effectiveness of MPA may be relatively reduced if the network employs network-controlled localized mobility management in which the MN does not need to change its IP address while moving within the network. The effectiveness of MPA may also be relatively reduced if signaling for network access authentication is already optimized for movements within the network, e.g., when simultaneous use of multiple interfaces during handover is allowed. In other words, MPA is more viable as a solution for inter-administrative domain predictive handover without the simultaneous use of multiple interfaces. Since MPA is not tied to a specific mobility protocol, it is also applicable to support optimization for inter-domain handover where each domain may be equipped with a different mobility protocol.
付随するドキュメント[MPA-Wireless]の著者は、MPAを使用していくつかのネットワーク層およびアプリケーションレイヤーモビリティプロトコルを最適化する方法のいくつかのユースケースを引用しました。ネットワークがネットワーク内を移動している間にMNがIPアドレスを変更する必要がないネットワーク制御のローカライズされたモビリティ管理を採用している場合、MPAの有効性は比較的低下する可能性があります。ネットワークアクセス認証のシグナリングがネットワーク内の動きに対してすでに最適化されている場合、たとえば、ハンドオーバー中に複数のインターフェイスを同時に使用する場合、MPAの有効性は比較的低下する場合があります。言い換えれば、MPAは、複数のインターフェイスを同時に使用することなく、誘発性ドメインの予測的ハンドオーバーのソリューションとしてより実行可能です。MPAは特定のモビリティプロトコルに結び付けられていないため、各ドメインに異なるモビリティプロトコルを装備できるドメイン間ハンドオーバーの最適化をサポートすることにも適用できます。
Figure 1 shows an example of inter-domain mobility where MPA could be applied. For example, domain A may support just Proxy MIPv6, whereas domain B may support Client Mobile IPv6. MPA's different functional components can provide the desired optimization techniques proactively.
図1は、MPAを適用できるドメイン間モビリティの例を示しています。たとえば、ドメインAはProxy Mipv6のみをサポートする場合がありますが、ドメインBはクライアントモバイルIPv6をサポートする場合があります。MPAのさまざまな機能コンポーネントは、目的の最適化手法を積極的に提供できます。
Media-independent Pre-Authentication (MPA) is a mobile-assisted, secure handover optimization scheme that works over any link layer and with any mobility management protocol. With MPA, a mobile node is not only able to securely obtain an IP address and other configuration parameters for a CTN, but also able to send and receive IP packets using the IP address obtained before it actually attaches to the CTN. This makes it possible for the mobile node to complete the binding update of any mobility management protocol and use the new CoA before performing a handover at the link layer.
メディアに依存しない事前認証（MPA）は、モバイル支援の安全なハンドオーバー最適化スキームであり、任意のリンクレイヤーおよびモビリティ管理プロトコルで機能します。MPAを使用すると、モバイルノードは、CTNのIPアドレスとその他の構成パラメーターを安全に取得できるだけでなく、実際にCTNに接続する前に取得したIPアドレスを使用してIPパケットを送信および受信することもできます。これにより、モバイルノードがモビリティ管理プロトコルのバインディングアップデートを完了し、リンクレイヤーでハンドオーバーを実行する前に新しいCOAを使用できるようになります。
MPA adopts the following basic procedures to provide this functionality. The first procedure is referred to as "pre-authentication", the second procedure is referred to as "pre-configuration", and the combination of the third and fourth procedures is referred to as "secure proactive handover". The security association established through pre-authentication is referred to as an "MPA-SA".
MPAは、次の基本手順を採用して、この機能を提供します。最初の手順は「事前認証」と呼ばれ、2番目の手順は「事前構成」と呼ばれ、3番目と4番目の手順の組み合わせは「安全なプロアクティブハンドオーバー」と呼ばれます。承認前を通じて確立されたセキュリティ協会は、「MPA-SA」と呼ばれます。
This functionality is provided by allowing a mobile node that has connectivity to the current network, but is not yet attached to a CTN, to
この機能は、現在のネットワークに接続されているが、まだCTNに接続されていないモバイルノードを許可することにより提供されます。
(i) establish a security association with the CTN to secure the subsequent protocol signaling, then
(i) CTNとのセキュリティ協会を確立して、後続のプロトコルシグナル伝達を保護し、次に
(ii) securely execute a configuration protocol to obtain an IP address and other parameters from the CTN as well as execute a tunnel management protocol to establish a Proactive Handover Tunnel (PHT) [RFC2003] between the mobile node and an access router of the CTN, then
（ii）構成プロトコルを安全に実行してCTNからIPアドレスとその他のパラメーターを取得し、トンネル管理プロトコルを実行して、モバイルノードとCTNのアクセスルーターの間のプロアクティブハンドオーバートンネル（PHT）[RFC2003]を確立します、 それから
(iii) send and receive IP packets, including signaling messages for the binding update of an MMP and data packets transmitted after completion of the binding update, over the PHT, using the obtained IP address as the tunnel inner address, and finally (iv) delete or disable the PHT immediately before attaching to the CTN when it becomes the target network, and then re-assign the inner address of the deleted or disabled tunnel to its physical interface immediately after the mobile node is attached to the target network through the interface. Instead of deleting or disabling the tunnel before attaching to the target network, the tunnel may be deleted or disabled immediately after being attached to the target network.
（iii）MMPのバインディングアップデートのシグナリングメッセージとバインディングアップデートの完了後に送信されたデータパケットの信号メッセージを含むIPパケットを送信および受信します。CTNがターゲットネットワークになるときにPHTを削除または無効にし、モバイルノードがインターフェイスを介してターゲットネットワークに接続された直後に、削除または無効なトンネルの内側アドレスを物理インターフェイスに再割り当てし、その後削除または無効にします。ターゲットネットワークに取り付ける前にトンネルを削除または無効にする代わりに、ターゲットネットワークに取り付けられた直後にトンネルを削除または無効にすることができます。
Step (iii) above (i.e., the binding update procedure), in particular, makes it possible for the mobile node to complete the higher-layer handover before starting a link-layer handover. This means that the mobile node is able to send and receive data packets transmitted after completing the binding update over the tunnel, while data packets transmitted before completion of the binding update do not use the tunnel.
特に、上記のステップ（iii）上（つまり、バインディングアップデート手順）により、リンク層のハンドオーバーを開始する前に、モバイルノードが高層のハンドオーバーを完了することができます。これは、モバイルノードがトンネル上のバインディングアップデートを完了した後に送信されたデータパケットを送信および受信できることを意味し、バインディングアップデートの完了前に送信されたデータパケットではトンネルを使用しません。
In the MPA framework, the following functional elements are expected to reside in each CTN to communicate with a mobile node: an Authentication Agent (AA), a Configuration Agent (CA), and an Access Router (AR). These elements can reside in one or more network devices.
MPAフレームワークでは、次の機能要素が各CTNに存在してモバイルノード（認証エージェント（AA）、構成エージェント（CA）、およびアクセスルーター（AR）と通信することが期待されます。これらの要素は、1つ以上のネットワークデバイスに存在する可能性があります。
An authentication agent is responsible for pre-authentication. An authentication protocol is executed between the mobile node and the authentication agent to establish an MPA-SA. The authentication protocol MUST be able to establish a shared key between the mobile node and the authentication agent and SHOULD be able to provide mutual authentication. The authentication protocol SHOULD be able to interact with a AAA protocol, such as RADIUS or Diameter, to carry authentication credentials to an appropriate authentication server in the AAA infrastructure. This interaction happens through the authentication agent, such as the PANA Authentication Agent (PAA). In turn, the derived key is used to derive additional keys that will be applied to protecting message exchanges used for pre-configuration and secure proactive handover. Other keys that are used for bootstrapping link-layer and/or network-layer ciphers MAY also be derived from the MPA-SA. A protocol that can carry the Extensible Authentication Protocol (EAP) [RFC3748] would be suitable as an authentication protocol for MPA.
認証エージェントは、事前認証を担当します。モバイルノードと認証エージェントの間で認証プロトコルが実行され、MPA-SAが確立されます。認証プロトコルは、モバイルノードと認証エージェントの間に共有キーを確立できる必要があり、相互認証を提供できる必要があります。認証プロトコルは、RADIUSや直径などのAAAプロトコルと対話して、AAAインフラストラクチャの適切な認証サーバーに認証資格情報を運ぶことができるはずです。この相互作用は、PANA認証エージェント（PAA）などの認証エージェントを介して行われます。次に、派生キーを使用して、事前構成と保護されたプロアクティブハンドオーバーに使用されるメッセージ交換を保護するために適用される追加のキーを導き出すために使用されます。ブートストラップリンク層やネットワークレイヤー暗号に使用される他のキーも、MPA-SAから導出される場合があります。拡張可能な認証プロトコル（EAP）[RFC3748]を運ぶことができるプロトコルは、MPAの認証プロトコルとして適しています。
A configuration agent is responsible for one part of pre-configuration, namely securely executing a configuration protocol to deliver an IP address and other configuration parameters to the mobile node. The signaling messages of the configuration protocol (e.g., DHCP) MUST be protected using a key derived from the key corresponding to the MPA-SA.
構成エージェントは、事前構成の一部、つまり、設定プロトコルを安全に実行して、IPアドレスとその他の構成パラメーターをモバイルノードに配信します。構成プロトコルの信号メッセージ（例：DHCP）は、MPA-SAに対応するキーから派生したキーを使用して保護する必要があります。
An access router in the MPA framework is a router that is responsible for the other part of pre-configuration, i.e., securely executing a tunnel management protocol to establish a proactive handover tunnel to the mobile node. IP packets transmitted over the proactive handover tunnel SHOULD be protected using a key derived from the key corresponding to the MPA-SA. Details of this procedure are described in Section 6.3.
MPAフレームワークのアクセスルーターは、事前構成の他の部分に責任を負うルーターです。つまり、トンネル管理プロトコルを安全に実行して、モバイルノードへのプロアクティブなハンドオーバートンネルを確立します。プロアクティブなハンドオーバートンネルを介して送信されたIPパケットは、MPA-SAに対応するキーから派生したキーを使用して保護する必要があります。この手順の詳細については、セクション6.3で説明します。
Figure 2 shows the basic functional components of MPA.
図2は、MPAの基本的な機能成分を示しています。
+----+
| CN |
+----+
/
(Core Network)
/ \
/ \
+----------------/--------+ +----\-----------------+
| +-----+ | |+-----+ |
| | | +-----+ | || | +-----+ |
| | AA | |CA | | ||AA | | CA | |
| +--+--+ +--+--+ | |+--+--+ +--+--+ |
| | +------+ | | | | +-----+ | |
| | | pAR | | | | | |nAR | | |
| ---+---+ +---+-----+----+---+-+ +-----+ |
| +---+--+ | | +-----+ |
| | | | |
| | | | |
| | | | |
+------------+------------+ +--------|-------------+
Current | Candidate| Target Network
Network | |
+------+ +------+
| oPoA | | nPoA |
+--.---+ +--.---+
. .
. .
+------+
| MN | ---------->
+------+
Figure 2: MPA Functional Components
図2：MPA機能コンポーネント
Assume that the mobile node is already connected to a point of attachment, say oPoA (old point of attachment), and assigned a care-of address, say oCoA (old care-of address). The communication flow of MPA is described as follows. Throughout the communication flow, data packet loss should not occur except for the period during the switching procedure in Step 5 below, and it is the responsibility of link-layer handover to minimize packet loss during this period.
モバイルノードはすでに添付ファイルのポイントに接続されていると仮定します。これは、OPOA（添付ファイルの古いポイント）など、OCOA（古いケアオブアドレス）などのアドレスのケアを割り当てました。MPAの通信フローは次のように説明されています。通信フロー全体を通して、以下のステップ5の切り替え手順中の期間を除いてデータパケットの損失は発生しないはずであり、この期間中のパケット損失を最小限に抑えることはリンク層のハンドオーバーの責任です。
Step 1 (pre-authentication phase): The mobile node finds a CTN through some discovery process, such as IEEE 802.21, and obtains the IP addresses of an authentication agent, a configuration agent, and an access router in the CTN (Candidate Target Network) by some means. Details about discovery mechanisms are discussed in Section 7.1. The mobile node performs pre-authentication with the authentication agent. As discussed in Section 7.2, the mobile node may need to pre-authenticate with multiple candidate target networks. The decision regarding with which candidate network the mobile node needs to pre-authenticate will depend upon several factors, such as signaling overhead, bandwidth requirement (Quality of Service (QoS)), the mobile node's location, communication cost, handover robustness, etc. Determining the policy that decides the target network with which the mobile node should pre-authenticate is out of scope for this document.
ステップ1（事前認証フェーズ）：モバイルノードは、IEEE 802.21などの発見プロセスを通じてCTNを見つけ、認証エージェント、構成エージェント、およびCTN（候補ターゲットネットワークのアクセスルーターのIPアドレスを取得します。）何らかの方法で。発見メカニズムの詳細については、セクション7.1で説明します。モバイルノードは、認証エージェントとの事前認証を実行します。セクション7.2で説明したように、モバイルノードは複数の候補ターゲットネットワークと事前に認識する必要がある場合があります。候補ネットワークに関する決定は、モバイルノードが事前に必要なネットワークを使用する必要があります。シグナリングオーバーヘッド、帯域幅要件（サービス品質（QOS））、モバイルノードの位置、通信コスト、ハンドオーバーの堅牢性など、いくつかの要因に依存します。このドキュメントのモバイルノードが事前に認識されるべきターゲットネットワークを決定するポリシーを決定することは、範囲外です。
If the pre-authentication is successful, an MPA-SA is created between the mobile node and the authentication agent. Two keys are derived from the MPA-SA, namely an MN-CA key and an MN-AR key, which are used to protect subsequent signaling messages of a configuration protocol and a tunnel management protocol, respectively. The MN-CA key and the MN-AR key are then securely delivered to the configuration agent and the access router, respectively.
事前認証が成功した場合、MPA-SAがモバイルノードと認証エージェントの間に作成されます。2つのキーは、MPA-SA、すなわちMN-CAキーとMN-ARキーから派生しており、それぞれ構成プロトコルとトンネル管理プロトコルの後続のシグナリングメッセージを保護するために使用されます。MN-CAキーとMN-ARキーは、それぞれ構成エージェントとアクセスルーターに安全に配信されます。
Step 2 (pre-configuration phase): The mobile node realizes that its point of attachment is likely to change from the oPoA to a new one, say nPoA (new point of attachment). It then performs pre-configuration with the configuration agent, using the configuration protocol to obtain several configuration parameters such as an IP address, say nCoA (new care-of address), and a default router from the CTN. The mobile node then communicates with the access router using the tunnel management protocol to establish a proactive handover tunnel. In the tunnel management protocol, the mobile node registers the oCoA and the nCoA as the tunnel outer address and the tunnel inner address, respectively. The signaling messages of the pre-configuration protocol are protected using the MN-CA key and the MN-AR key. When the configuration agent and the access router are co-located in the same device, the two protocols may be integrated into a single protocol, such as IKEv2. After completion of the tunnel establishment, the mobile node is able to communicate using both the oCoA and the nCoA by the end of Step 4. A configuration protocol and a tunnel management protocol may be combined in a single protocol or executed in different orders depending on the actual protocol(s) used for configuration and tunnel management.
ステップ2（事前構成フェーズ）：モバイルノードは、その添付ファイルのポイントがOPOから新しいものに変更される可能性が高いことを認識しています。次に、構成プロトコルを使用して、IPアドレスなどのいくつかの構成パラメーター、NCOA（新しいケアオブアドレス）、およびCTNのデフォルトルーターなどのいくつかの構成パラメーターを取得する構成エージェントとの事前構成を実行します。モバイルノードは、トンネル管理プロトコルを使用してアクセスルーターと通信し、プロアクティブなハンドオーバートンネルを確立します。トンネル管理プロトコルでは、モバイルノードがOCOAとNCOAをそれぞれトンネルの外側のアドレスとトンネル内側のアドレスとして登録します。事前構成プロトコルのシグナルメッセージは、MN-CAキーとMN-ARキーを使用して保護されます。構成エージェントとAccessルーターが同じデバイスで共同配置されると、2つのプロトコルがIKEV2などの単一のプロトコルに統合される場合があります。トンネル設立の完了後、モバイルノードは、ステップ4の終了までにOCOAとNCOAの両方を使用して通信できます。構成プロトコルとトンネル管理プロトコルは、単一のプロトコルで組み合わせるか、異なる注文で実行される場合があります。構成とトンネル管理に使用される実際のプロトコル。
Step 3 (secure proactive handover main phase): The mobile node decides to switch to the new point of attachment by some means. Before the mobile node switches to the new point of attachment, it starts secure proactive handover by executing the binding update operation of a mobility management protocol and transmitting subsequent data traffic over the tunnel (main phase). This proactive binding update could be triggered based on certain local policy at the mobile node end, after the pre-configuration phase is over. This local policy could be Signal-to-Noise Ratio, location of the mobile node, etc. In some cases, it may cache multiple nCoA addresses and perform simultaneous binding with the Correspondent Node (CN) or Home Agent (HA).
ステップ3（確実なプロアクティブハンドオーバーメインフェーズ）：モバイルノードは、何らかの方法で新しい添付ポイントに切り替えることを決定します。モバイルノードが新しい添付ポイントに切り替わる前に、モビリティ管理プロトコルのバインディングアップデート操作を実行し、トンネル上の後続のデータトラフィックを送信することにより、安全なプロアクティブハンドオーバーを開始します（メインフェーズ）。このプロアクティブなバインディングアップデートは、事前構成フェーズが終了した後、モバイルノードエンドの特定のローカルポリシーに基づいてトリガーできます。このローカルポリシーは、信号対雑音の比率、モバイルノードの位置などです。場合によっては、複数のNCOAアドレスをキャッシュし、特派員ノード（CN）またはホームエージェント（HA）と同時バインディングを実行する場合があります。
Step 4 (secure proactive handover pre-switching phase): The mobile node completes the binding update and becomes ready to switch to the new point of attachment. The mobile node may execute the tunnel management protocol to delete or disable the proactive handover tunnel and cache the nCoA after deletion or disabling of the tunnel. This transient tunnel can be deleted prior to or after the handover. The buffering module at the next access router buffers the packets once the tunnel interface is deleted. The decision as to when the mobile node is ready to switch to the new point of attachment depends on the handover policy.
ステップ4（確実にプロアクティブなハンドオーバー前スイッチングフェーズ）：モバイルノードはバインディングアップデートを完了し、新しい添付ポイントに切り替える準備ができています。モバイルノードは、トンネル管理プロトコルを実行して、プロアクティブなハンドオーバートンネルを削除または無効にし、トンネルの削除または無効化後にNCOAをキャッシュすることができます。この一時的なトンネルは、ハンドオーバーの前後に削除できます。次のアクセスルーターのバッファリングモジュールは、トンネルインターフェイスが削除されると、パケットをバッファリングします。モバイルノードがいつ新しいポイントに切り替える準備ができているかについての決定は、ハンドオーバーポリシーに依存します。
Step 5 (switching): It is expected that a link-layer handover occurs in this step.
ステップ5（切り替え）：このステップでリンク層のハンドオーバーが発生すると予想されます。
Step 6 (secure proactive handover post-switching phase): The mobile node executes the switching procedure. Upon successful completion of the switching procedure, the mobile node immediately restores the cached nCoA and assigns it to the physical interface attached to the new point of attachment. If the proactive handover tunnel was not deleted or disabled in Step 4, the tunnel is deleted or disabled as well. After this, direct transmission of data packets using the nCoA is possible without using a proactive handover tunnel.
ステップ6（スイッチング後の積極的なハンドオーバーの保護）：モバイルノードは、切り替え手順を実行します。切り替え手順が正常に完了すると、モバイルノードはキャッシュされたNCOAをすぐに復元し、新しい添付ポイントに接続された物理インターフェイスに割り当てます。ステップ4でプロアクティブなハンドオーバートンネルが削除または無効になっていない場合、トンネルも削除または無効になります。この後、積極的なハンドオーバートンネルを使用せずにNCOAを使用したデータパケットの直接送信は可能です。
Call flow for MPA is shown in Figures 3 and 4.
MPAのコールフローを図3および4に示します。
IP address(es)
Available for
Use by MN
|
+-----------------------------------+ |
| Candidate Target Network | |
| (Future Target Network) | |
MN oPoA | nPoA AA CA AR | |
| | | | | | | | |
| | +-----------------------------------+ |
| | | | | | .
+---------------+ | | | | | .
|(1) Found a CTN| | | | | | .
+---------------+ | | | | | |
| Pre-authentication | | | |
| [authentication protocol] | | |
|<--------+------------->|MN-CA key| | |
| | | |-------->|MN-AR key| |
+-----------------+ | | |------------------>| |
|(2) Increased | | | | | | [oCoA]
|chance to switch | | | | | | |
| to CTN | | | | | | |
+-----------------+ | | | | | |
| | | | | | |
| Pre-configuration | | | |
| [configuration protocol to get nCoA] | |
|<--------+----------------------->| | |
| Pre-configuration | | | |
| [tunnel management protocol to establish PHT] V
|<--------+--------------------------------->|
| | | | | | ^
+-----------------+ | | | | | |
|(3) Determined | | | | | | |
|to switch to CTN | | | | | | |
+-----------------+ | | | | | |
| | | | | | |
| Secure proactive handover main phase | |
| [execution of binding update of MMP and | |
| transmission of data packets through AR | [oCoA, nCoA]
| based on nCoA over the PHT] | | |
|<<=======+================================>+--->... |
. . . . . . .
. . . . . . .
. . . . . . .
Figure 3: Example Communication Flow (1/2)
図3：通信フローの例（1/2）
| | | | | | |
+----------------+ | | | | | |
|(4) Completion | | | | | | |
|of MMP BU and | | | | | | |
|ready to switch | | | | | | |
+----------------+ | | | | | |
| Secure proactive handover pre-switching phase |
| [tunnel management protocol to delete PHT] V
|<--------+--------------------------------->|
+---------------+ | | | |
|(5)Switching | | | | |
+---------------+ | | | |
| | | | |
+---------------+ | | | |
|(6) Completion | | | | |
|of switching | | | | |
+---------------+ | | | |
o<- Secure proactive handover post-switching phase ^
| [Re-assignment of Tunnel Inner Address | |
| to the physical I/F] | |
| | | | | |
| Transmission of data packets through AR | [nCoA]
| based on nCoA| | | | |
|<---------------+---------------------------+-->... |
| | | | | .
Figure 4: Example Communication Flow (2/2)
図4：通信フローの例（2/2）
In order to provide an optimized handover for a mobile node experiencing rapid movement between subnets and/or domains, one needs to look into several operations. These issues include:
サブネットおよび/またはドメイン間の急速な動きを経験するモバイルノードの最適化されたハンドオーバーを提供するには、いくつかの操作を調査する必要があります。これらの問題は次のとおりです。
i) discovery of neighboring networking elements,
i) 隣接するネットワーキング要素の発見、
ii) connecting to the right network based on certain policy,
ii）特定のポリシーに基づいて適切なネットワークに接続する、
iii) changing the layer 2 point of attachment,
iii）レイヤー2ポイントの添付ファイルの変更、
iv) obtaining an IP address from a DHCP or PPP server,
iv）DHCPまたはPPPサーバーからIPアドレスを取得する、
v) confirming the uniqueness of the IP address,
v) IPアドレスの独自性を確認し、
vi) pre-authenticating with the authentication agent,
vi）認証エージェントとの事前認定、
vii) sending the binding update to the Correspondent Host (CH), viii) obtaining the redirected streaming traffic to the new point of attachment,
vii）拘束力のあるアップデートを特派員ホスト（CH）、viiiに送信する）リダイレクトストリーミングトラフィックを新しい添付ポイントに取得する、
ix) ping-pong effect, and
ix）ping-pong効果、および
x) probability of moving to more than one network and associating with multiple target networks.
x) 複数のネットワークに移動し、複数のターゲットネットワークに関連する確率。
We describe these issues in detail in the following paragraphs and describe how we have optimized these issues in the case of MPA-based secure proactive handover.
これらの問題を次の段落で詳しく説明し、MPAベースのセキュアプロアクティブハンドオーバーの場合にこれらの問題を最適化した方法について説明します。
Discovery of neighboring networking elements such as access points, access routers, and authentication servers helps expedite the handover process during a mobile node's movement between networks. After discovering the network neighborhood with a desired set of coordinates, capabilities, and parameters, the mobile node can perform many of the operations, such as pre-authentication, proactive IP address acquisition, proactive address resolution, and binding update, while in the previous network.
アクセスポイント、アクセスルーター、認証サーバーなどの隣接するネットワーキング要素の発見は、ネットワーク間のモバイルノードの移動中にハンドオーバープロセスを促進するのに役立ちます。目的の座標、機能、およびパラメーターのセットを備えたネットワーク近隣を発見した後、モバイルノードは、前の認識、プロアクティブなIPアドレスの取得、プロアクティブなアドレス解決、バインディングアップデートなど、多くの操作を実行できます。通信網。
There are several ways a mobile node can discover neighboring networks. The Candidate Access Router Discovery protocol [RFC4066] helps discover the candidate access routers in the neighboring networks. Given a certain network domain, SLP (Service Location Protocol) [RFC2608] and DNS help provide addresses of the networking components for a given set of services in the specific domain. In some cases, many of the network-layer and upper-layer parameters may be sent over link-layer management frames, such as beacons, when the mobile node approaches the vicinity of the neighboring networks. IEEE 802.11u is considering issues such as discovering the neighborhood using information contained in the link layer. However, if the link-layer management frames are encrypted by some link-layer security mechanism, then the mobile node may not be able to obtain the requisite information before establishing link-layer connectivity to the access point. In addition, this may add burden to the bandwidth-constrained wireless medium. In such cases, a higher-layer protocol is preferred to obtain the information regarding the neighboring elements. Some proposals, such as [802.21], help obtain information about the neighboring networks from a mobility server. When the movement is imminent, the mobile node starts the discovery process by querying a specific server and obtains the required parameters, such as the IP address of the access point, its characteristics, routers, SIP servers, or authentication servers of the neighboring networks. In the event of multiple networks, it may obtain the required parameters from more than one neighboring network and keep these in a cache. At some point, the mobile node finds several CTNs out of many probable networks and starts the pre-authentication process by communicating with the required entities in the CTNs. Further details of this scenario are in Section 7.2.
モバイルノードが隣接するネットワークを発見する方法はいくつかあります。候補アクセスルーター発見プロトコル[RFC4066]は、隣接するネットワーク内の候補アクセスルーターを発見するのに役立ちます。特定のネットワークドメインが与えられた場合、SLP（サービスロケーションプロトコル）[RFC2608]およびDNSは、特定のドメイン内の特定のサービスセットのネットワークコンポーネントのアドレスを提供するのに役立ちます。場合によっては、モバイルノードが隣接するネットワークの近くに近づくと、ネットワーク層と上層層のパラメーターの多くは、ビーコンなどのリンク層管理フレームを介して送信される場合があります。IEEE 802.11Uは、リンクレイヤーに含まれる情報を使用して近隣を発見するなどの問題を検討しています。ただし、リンク層管理フレームがリンク層セキュリティメカニズムによって暗号化されている場合、モバイルノードは、アクセスポイントへのリンクレイヤー接続を確立する前に、必要な情報を取得できない場合があります。さらに、これにより、帯域幅が制約したワイヤレス媒体に負担が加わる可能性があります。そのような場合、隣接する要素に関する情報を取得するには、高層プロトコルが推奨されます。[802.21]などのいくつかの提案は、モビリティサーバーから隣接するネットワークに関する情報を取得するのに役立ちます。動きが差し迫っている場合、モバイルノードは特定のサーバーを照会することにより発見プロセスを開始し、アクセスポイントのIPアドレス、その特性、ルーター、SIPサーバー、または隣接ネットワークの認証サーバーなどの必要なパラメーターを取得します。複数のネットワークが発生した場合、複数のネットワークから必要なパラメーターを取得し、これらをキャッシュに保持する場合があります。ある時点で、モバイルノードは多くの可能性のあるネットワークからいくつかのCTNを見つけ、CTNSの必要なエンティティと通信することにより、事前認証プロセスを開始します。このシナリオの詳細は、セクション7.2にあります。
In some cases, although a mobile node selects a specific network to be the target network, it may actually end up moving into a neighboring network other than the target network, due to factors that are beyond the mobile node's control. Thus, it may be useful to perform the pre-authentication with a few probable candidate target networks and establish time-bound transient tunnels with the respective access routers in those networks. Thus, in the event of a mobile node moving to a candidate target network other than that chosen as the target network, it will not be subjected to packet loss due to authentication and IP address acquisition delay that could occur if the mobile node did not pre-authenticate with that candidate target network. It may appear that by pre-authenticating with a number of candidate target networks and reserving the IP addresses, the mobile node is reserving resources that could be used otherwise. But since this happens for a time-limited period, it should not be a big problem; it depends upon the mobility pattern and duration. The mobile node uses a pre-authentication procedure to obtain an IP address proactively and to set up the time-bound tunnels with the access routers of the candidate target networks. Also, the MN may retain some or all of the nCoAs for future movement.
場合によっては、モバイルノードは特定のネットワークをターゲットネットワークに選択しますが、モバイルノードの制御を超えた要因により、実際にターゲットネットワーク以外の隣接ネットワークに移動する可能性があります。したがって、いくつかの可能性のある候補ターゲットネットワークを使用して事前認証を実行し、それらのネットワーク内のそれぞれのアクセスルーターを使用して時間帯域の一時的なトンネルを確立することが有用かもしれません。したがって、ターゲットネットワークとして選択されたもの以外の候補ターゲットネットワークに移動するモバイルノードが候補ターゲットネットワークに移動した場合、モバイルノードが事前に行わなかった場合に発生する可能性のある認証とIPアドレスの取得遅延により、パケット損失は発生しません。 - その候補ターゲットネットワークとの認識。多数の候補ターゲットネットワークで事前に認識し、IPアドレスを予約することにより、モバイルノードはそうでなければ使用できるリソースを予約しているように見えるかもしれません。しかし、これは時間制限期間にわたって起こるので、それは大きな問題ではないはずです。モビリティパターンと期間に依存します。モバイルノードは、事前認証手順を使用してIPアドレスを積極的に取得し、候補ターゲットネットワークのアクセスルーターを使用して時間帯域トンネルをセットアップします。また、MNは、将来の動きのためにNCOAの一部またはすべてを保持する場合があります。
The mobile node may choose one of these addresses as the binding update address and send it to the CN (Correspondent Node) or HA (Home Agent), and will thus receive the tunneled traffic via the target network while in the previous network. But in some instances, the mobile node may eventually end up moving to a network that is other than the target network. Thus, there will be a disruption in traffic as the mobile node moves to the new network, since the mobile node has to go through the process of assigning the new IP address and sending the binding update again. There are two solutions to this problem. As one solution to the problem, the mobile node can take advantage of the simultaneous mobility binding and send multiple binding updates to the Correspondent Host or HA. Thus, the Correspondent Host or HA forwards the traffic to multiple IP addresses assigned to the virtual interfaces for a specific period of time. This binding update gets refreshed at the CH after the mobile node moves to the new network, thus stopping the flow to the other candidate networks. RFC 5648 [RFC5648] discusses different scenarios of mobility binding with multiple care-of-addresses. As the second solution, in case simultaneous binding is not supported in a specific mobility scheme, forwarding of traffic from the previous target network will help take care of the transient traffic until the new binding update is sent from the new network.
モバイルノードは、これらのアドレスのいずれかをバインディングアップデートアドレスとして選択し、CN（特派員ノード）またはHA（ホームエージェント）に送信するため、前のネットワーク内でターゲットネットワークを介してトンネルトラフィックを受信します。しかし、場合によっては、モバイルノードは最終的にターゲットネットワーク以外のネットワークに移動することになります。したがって、モバイルノードは新しいIPアドレスを割り当ててバインディングアップデートを再度送信するプロセスを実行する必要があるため、モバイルノードが新しいネットワークに移動するにつれてトラフィックが中断されます。この問題には2つの解決策があります。問題の1つの解決策として、モバイルノードは同時モビリティバインディングを利用して、特派員ホストまたはHAに複数のバインディングアップデートを送信できます。したがって、特派員のホストまたはHAは、特定の期間、仮想インターフェイスに割り当てられた複数のIPアドレスにトラフィックを転送します。このバインディングアップデートは、モバイルノードが新しいネットワークに移動した後、CHで更新され、他の候補ネットワークへのフローが停止します。RFC 5648 [RFC5648]は、複数のアドレスレスによるモビリティ結合のさまざまなシナリオについて説明しています。2番目のソリューションとして、特定のモビリティスキームで同時バインディングがサポートされていない場合、以前のターゲットネットワークからのトラフィックの転送は、新しいネットワークから新しいバインディングアップデートが送信されるまで一時的なトラフィックの処理に役立ちます。
In general, a mobility management protocol works in conjunction with the Foreign Agent or in the co-located address mode. The MPA approach can use both the co-located address mode and the Foreign Agent address mode. We discuss here the address assignment component that is used in the co-located address mode. There are several ways a mobile node can obtain an IP address and configure itself. In some cases, a mobile node can configure itself statically in the absence of any configuration element such as a server or router in the network. In a LAN environment, the mobile node can obtain an IP address from DHCP servers. In the case of IPv6 networks, a mobile node has the option of obtaining the IP address using stateless autoconfiguration or DHCPv6. In some wide-area networking environments, the mobile node uses PPP (Point-to-Point Protocol) to obtain the IP address by communicating with a NAS (Network Access Server).
一般に、モビリティ管理プロトコルは、外国人エージェントまたは共同配置されたアドレスモードと組み合わせて機能します。MPAアプローチは、共同配置アドレスモードと外国エージェントアドレスモードの両方を使用できます。ここでは、共同配置アドレスモードで使用されるアドレス割り当てコンポーネントについて説明します。モバイルノードがIPアドレスを取得して自分自身を構成する方法はいくつかあります。場合によっては、ネットワーク内のサーバーやルーターなどの構成要素がない場合、モバイルノードは静的に自らを構成できます。LAN環境では、モバイルノードはDHCPサーバーからIPアドレスを取得できます。IPv6ネットワークの場合、モバイルノードには、Stateless AutoconfigurationまたはDHCPV6を使用してIPアドレスを取得するオプションがあります。いくつかの広い地域のネットワーキング環境では、モバイルノードはPPP（ポイントツーポイントプロトコル）を使用して、NAS（ネットワークアクセスサーバー）と通信してIPアドレスを取得します。
Each of these processes takes on the order of few hundred milliseconds to a few seconds, depending upon the type of IP address acquisition process and operating system of the clients and servers. Since IP address acquisition is part of the handover process, it adds to the handover delay, and thus it is desirable to reduce this delay as much as possible. There are a few optimized techniques available, such as DHCP Rapid Commit [RFC4039] and GPS-coordinate-based IP address [GPSIP], that attempt to reduce the handover delay due to IP address acquisition time. However, in all these cases, the mobile node also obtains the IP address after it moves to the new subnet and incurs some delay because of the signaling handshake between the mobile node and the DHCP server.
これらの各プロセスは、クライアントとサーバーのIPアドレス取得プロセスの種類とオペレーティングシステムに応じて、数百ミリ秒から数秒程度の注文を取ります。IPアドレスの取得はハンドオーバープロセスの一部であるため、ハンドオーバー遅延に追加されるため、この遅延を可能な限り減らすことが望ましいです。DHCP Rapid Commit [RFC4039]やGPS座標ベースのIPアドレス[GPSIP]など、最適化された手法がいくつかあります。ただし、これらすべての場合、モバイルノードは新しいサブネットに移動した後にIPアドレスも取得し、モバイルノードとDHCPサーバーの間のシグナリングハンドシェイクのためにある程度の遅延が発生します。
In Fast MIPv6 [RFC5568], through the RtSolPr and PrRtAdv messages, the MN also formulates a prospective new CoA (nCoA) when it is still present on the Previous Access Router's (pAR's) link. Hence, the latency due to new prefix discovery subsequent to handover is eliminated. However, in this case, both the pAR and the Next Access Router (nAR) need to cooperate with each other to be able to retrieve the prefix from the target network.
高速MIPV6 [RFC5568]では、RTSOLPRおよびPRRTADVメッセージを介して、MNは以前のAccess Router（PARの）リンクにまだ存在する場合に、前向きな新しいCOA（NCOA）も定式化します。したがって、ハンドオーバー後の新しいプレフィックスの発見によるレイテンシは排除されます。ただし、この場合、PARと次のアクセスルーター（NAR）の両方が、ターゲットネットワークからプレフィックスを取得できるように互いに協力する必要があります。
In the following paragraph, we describe a few ways that a mobile node can obtain the IP address proactively from the CTN, and the associated tunnel setup procedure. These can broadly be divided into four categories: PANA-assisted proactive IP address acquisition, IKE-assisted proactive IP address acquisition, proactive IP address acquisition using DHCP only, and stateless autoconfiguration. When DHCP is used for address configuration, a DHCP server is assumed to be serving one subnet.
次の段落では、モバイルノードがCTNからIPアドレスを積極的に取得できる方法と、関連するトンネルセットアップ手順について説明します。これらは、4つのカテゴリに広く分割できます。PANA-ASSISTED PROACTIVE IPアドレス取得、IKE支援のプロアクティブIPアドレス取得、DHCPのみを使用したプロアクティブなIPアドレス取得、およびステートレスオートコンフィギュレーション。DHCPがアドレス構成に使用される場合、DHCPサーバーは1つのサブネットを提供していると想定されます。
In the case of PANA-assisted proactive IP address acquisition, the mobile node obtains an IP address proactively from a CTN. The mobile node makes use of PANA [RFC5191] messages to trigger the IP address acquisition process via a DHCP client that is co-located with the PANA authentication agent in the access router in the CTN acting on behalf of the mobile node. Upon receiving a PANA message from the mobile node, the DHCP client on the authentication agent performs normal DHCP message exchanges to obtain the IP address from the DHCP server in the CTN. This address is piggy-backed in a PANA message and is delivered to the mobile node. In the case of IPv6, a Router Advertisement (RA) is carried as part of the PANA message. In the case of stateless autoconfiguration, the mobile node uses the prefix(es) obtained as part of the RA and its MAC address to construct the unique IPv6 address(es) as it would have done in the new network. In the case of stateful address autoconfiguration, a procedure similar to DHCPv4 can be applied.
PANA支援プロアクティブIPアドレス取得の場合、モバイルノードはCTNからIPアドレスを積極的に取得します。モバイルノードは、PANA [RFC5191]メッセージを使用して、モバイルノードに代わって作用するCTNのアクセスルーターのPANA認証エージェントと共同住宅されるDHCPクライアントを介してIPアドレス取得プロセスをトリガーします。モバイルノードからパナメッセージを受信すると、認証エージェントのDHCPクライアントは通常のDHCPメッセージ交換を実行して、CTNのDHCPサーバーからIPアドレスを取得します。このアドレスは、パナメッセージでピギーバックされ、モバイルノードに配信されます。IPv6の場合、パナメッセージの一部としてルーター広告（RA）が運ばれます。Stateless Autoconfigurationの場合、モバイルノードはRAとそのMACアドレスの一部として取得されたプレフィックス（ES）を使用して、新しいネットワークで行われたように一意のIPv6アドレス（ES）を構築します。Stateful Address Autoconfigurationの場合、DHCPV4と同様の手順を適用できます。
IKEv2-assisted proactive IP address acquisition works when an IPsec gateway and a DHCP relay agent [RFC3046] are resident within each access router in the CTN. In this case, the IPsec gateway and DHCP relay agent in a CTN help the mobile node acquire the IP address from the DHCP server in the CTN. The MN-AR key established during the pre-authentication phase is used as the IKEv2 pre-shared secret needed to run IKEv2 between the mobile node and the access router. The IP address from the CTN is obtained as part of the standard IKEv2 procedure, using the co-located DHCP relay agent for obtaining the IP address from the DHCP server in the target network using standard DHCP. The obtained IP address is sent back to the client in the IKEv2 Configuration Payload exchange. In this case, IKEv2 is also used as the tunnel management protocol for a proactive handover tunnel (see Section 7.4). Alternatively, a VPN gateway can dispense the IP address from its IP address pool.
IKEV2補助プロアクティブIPアドレス取得は、IPSECゲートウェイとDHCPリレーエージェント[RFC3046]がCTNの各アクセスルーター内に居住している場合に機能します。この場合、CTNのIPSECゲートウェイとDHCPリレーエージェントは、モバイルノードがCTNのDHCPサーバーからIPアドレスを取得するのを支援します。認証前フェーズ中に確立されたMN-ARキーは、モバイルノードとアクセスルーターの間でIKEV2を実行するために必要なIKEV2の事前共有秘密として使用されます。CTNからのIPアドレスは、標準のDHCPを使用してターゲットネットワークのDHCPサーバーからIPアドレスを取得するために、共同配置DHCPリレーエージェントを使用して、標準のIKEV2プロシージャの一部として取得されます。取得したIPアドレスは、IKEV2構成ペイロードエクスチェンジでクライアントに送信されます。この場合、IKEV2は、プロアクティブなハンドオーバートンネルのトンネル管理プロトコルとしても使用されます（セクション7.4を参照）。または、VPNゲートウェイは、IPアドレスプールからIPアドレスを分配することができます。
As another alternative, DHCP may be used for proactively obtaining an IP address from a CTN without relying on PANA or IKEv2-based approaches by allowing direct DHCP communication between the mobile node and the DHCP relay agent or DHCP server in the CTN. The mechanism described in this section is applicable to DHCPv4 only. The mobile node sends a unicast DHCP message to the DHCP relay agent or DHCP server in the CTN requesting an address, while using the address associated with the current physical interface as the source address of the request.
別の代替案として、DHCPは、CTNのモバイルノードとDHCPリレーエージェントまたはDHCPサーバー間の直接DHCP通信を許可することにより、PANAまたはIKEV2ベースのアプローチに依存せずにCTNからIPアドレスを積極的に取得するために使用できます。このセクションで説明するメカニズムは、DHCPV4のみに適用できます。モバイルノードは、現在の物理インターフェイスに関連付けられたアドレスを要求のソースアドレスとして使用しながら、住所を要求するCTNのDHCPリレーエージェントまたはDHCPサーバーにユニキャストDHCPメッセージを送信します。
When the message is sent to the DHCP relay agent, the DHCP relay agent relays the DHCP messages back and forth between the mobile node and the DHCP server. In the absence of a DHCP relay agent, the mobile node can also directly communicate with the DHCP server in the target network. The broadcast option in the client's unicast DISCOVER message should be set to 0 so that the relay agent or the DHCP server can send the reply directly back to the mobile node using the mobile node's source address.
メッセージがDHCPリレーエージェントに送信されると、DHCPリレーエージェントはモバイルノードとDHCPサーバーの間でDHCPメッセージを前後にリリーします。DHCPリレーエージェントがない場合、モバイルノードはターゲットネットワーク内のDHCPサーバーと直接通信することもできます。クライアントのユニキャスト発見メッセージのブロードキャストオプションは、リレーエージェントまたはDHCPサーバーがモバイルノードのソースアドレスを使用してモバイルノードに直接返信を送信できるように、0に設定する必要があります。
In order to prevent malicious nodes from obtaining an IP address from the DHCP server, DHCP authentication should be used, or the access router should be configured with a filter to block unicast DHCP messages sent to the remote DHCP server from mobile nodes that are not pre-authenticated. When DHCP authentication is used, the DHCP authentication key may be derived from the MPA-SA established between the mobile node and the authentication agent in the candidate target network.
悪意のあるノードがDHCPサーバーからIPアドレスの取得を防ぐために、DHCP認証を使用するか、アクセスルーターをフィルターで構成する必要があります。 - 認識。DHCP認証を使用すると、DHCP認証キーは、候補ターゲットネットワークのモバイルノードと認証エージェントの間に確立されたMPA-SAから導き出される場合があります。
The proactively obtained IP address is not assigned to the mobile node's physical interface until the mobile node has moved to the new network. The IP address thus obtained proactively from the target network should not be assigned to the physical interface but rather to a virtual interface of the client. Thus, such a proactively acquired IP address via direct DHCP communication between the mobile node and the DHCP relay agent or the DHCP server in the CTN may be carried with additional information that is used to distinguish it from other addresses as assigned to the physical interface.
プロアクティブに取得されたIPアドレスは、モバイルノードが新しいネットワークに移動するまで、モバイルノードの物理インターフェイスに割り当てられません。したがって、ターゲットネットワークから積極的に取得されたIPアドレスは、物理インターフェイスではなく、クライアントの仮想インターフェイスに割り当てられるべきです。したがって、モバイルノードとDHCPリレーエージェントまたはCTNのDHCPサーバー間の直接DHCP通信を介して、このような積極的に取得したIPアドレスは、物理インターフェイスに割り当てられた他のアドレスと区別するために使用される追加情報を持つことができます。
Upon the mobile node's entry to the new network, the mobile node can perform DHCP over the physical interface to the new network to get other configuration parameters, such as the SIP server or DNS server, by using DHCP INFORM. This should not affect the ongoing communication between the mobile node and Correspondent Host. Also, the mobile node can perform DHCP over the physical interface to the new network to extend the lease of the address that was proactively obtained before entering the new network.
モバイルノードの新しいネットワークへのエントリにより、モバイルノードは、新しいネットワークへの物理インターフェイスを介してDHCPを実行して、DHCP情報を使用してSIPサーバーやDNSサーバーなどの他の構成パラメーターを取得できます。これは、モバイルノードと特派員ホスト間の継続的な通信に影響しないはずです。また、モバイルノードは、新しいネットワークへの物理インターフェイスを介してDHCPを実行して、新しいネットワークに入る前に積極的に取得されたアドレスのリースを拡張できます。
In order to maintain the DHCP binding for the mobile node and keep track of the dispensed IP address before and after the secure proactive handover, the same DHCP client identifier needs to be used for the mobile node for both DHCP for proactive IP address acquisition and for DHCP performed after the mobile node enters the target network. The DHCP client identifier may be the MAC address of the mobile node or some other identifier.
モバイルノードのDHCPバインディングを維持し、安全なプロアクティブハンドオーバーの前後に調剤されたIPアドレスを追跡するには、プロアクティブなIPアドレス取得のためのDHCPの両方のモバイルノードに同じDHCPクライアント識別子を使用する必要があります。DHCPは、モバイルノードがターゲットネットワークに入った後に実行されます。DHCPクライアント識別子は、モバイルノードのMACアドレスまたは他の識別子である場合があります。
For IPv6, a network address is configured either using DHCPv6 or stateless autoconfiguration. In order to obtain the new IP address proactively, the router advertisement of the next-hop router can be sent over the established tunnel, and a new IPv6 address is generated based on the prefix and MAC address of the mobile node. Generating a CoA from the new network will avoid the time needed to obtain an IP address and perform Duplicate Address Detection.
IPv6の場合、ネットワークアドレスは、DHCPV6またはStateless Autoconfigurationを使用して構成されます。新しいIPアドレスを積極的に取得するために、ネクストホップルーターのルーター広告を確立されたトンネルに送信でき、モバイルノードのプレフィックスとMACアドレスに基づいて新しいIPv6アドレスが生成されます。新しいネットワークからCOAを生成すると、IPアドレスを取得し、重複するアドレス検出を実行するのに必要な時間が回避されます。
Duplicate Address Detection and address resolution are part of the IP address acquisition process. As part of the proactive configuration, these two processes can be done ahead of time. Details of how these two processes can be done proactively are described in Appendix A and Appendix B, respectively.
複製アドレスの検出とアドレス解決は、IPアドレス取得プロセスの一部です。プロアクティブな構成の一部として、これらの2つのプロセスは事前に実行できます。これらの2つのプロセスを積極的に実行する方法の詳細については、それぞれ付録Aと付録Bで説明します。
In the case of stateless autoconfiguration, the mobile node checks to see the prefix of the router advertisement in the new network and matches it with the prefix of the newly assigned IP address. If these turn out to be the same, then the mobile node does not go through the IP address acquisition phase again.
Stateless Autoconfigurationの場合、モバイルノードは新しいネットワークのルーター広告のプレフィックスを確認するためにチェックし、新しく割り当てられたIPアドレスのプレフィックスと一致します。これらが同じであることが判明した場合、モバイルノードはIPアドレス取得フェーズを再度通過しません。
After an IP address is proactively acquired from the DHCP server in a CTN, or via stateless autoconfiguration in the case of IPv6, a proactive handover tunnel is established between the mobile node and the access router in the CTN. The mobile node uses the acquired IP address as the tunnel's inner address.
IPアドレスがCTNのDHCPサーバーから積極的に取得された後、またはIPv6の場合のステートレスオートコンチュレーションを介して、モバイルノードとCTNのアクセスルーターの間にプロアクティブなハンドオーバートンネルが確立されます。モバイルノードは、取得したIPアドレスをトンネルの内側アドレスとして使用します。
There are several reasons why this transient tunnel is established between the nAR and the mobile node in the old PoA, unlike the transient tunnel in FMIPv6 (Fast MIPv6) [RFC5568], where it is set up between the mobile node's new point of attachment and the old access router.
この一時的なトンネルが、FMIPV6（高速MIPV6）[RFC5568]の一時的なトンネルとは異なり、古いPOAのNARとモバイルノードの間に確立される理由はいくつかあります。古いアクセスルーター。
In the case of inter-domain handoff, it is important that any signaling message between the nPoA and the mobile node needs to be secured. This transient secured tunnel provides the desired functionality, including securing the proactive binding update and transient data between the end-points before the handover has taken place. Unlike the proactive mode of FMIPv6, transient handover packets are not sent to the pAR, and thus a tunnel between the mobile node's new point of attachment and the old access router is not needed.
ドメイン間のハンドオフの場合、NPOAとモバイルノードの間のシグナリングメッセージを保護する必要があることが重要です。この一時的なセキュリティトンネルは、ハンドオーバーが行われる前のエンドポイント間のプロアクティブなバインディングアップデートと一時的なデータの保護など、目的の機能を提供します。FMIPV6のプロアクティブモードとは異なり、一時的なハンドオーバーパケットはPARに送信されないため、モバイルノードの新しいアタッチメントポイントと古いアクセスルーターの間のトンネルは必要ありません。
In the case of inter-domain handoff, the pAR and nAR could logically be far from each other. Thus, the signaling and data during the pre-authentication period will take a longer route, and thus may be subjected to longer one-way delay. Hence, MPA provides a tradeoff between larger packet loss or larger one-way packet delay for a transient period, when the mobile node is preparing for handoff.
ドメイン間のハンドオフの場合、PARとNARは論理的に互いに遠く離れる可能性があります。したがって、認証前の期間中のシグナルとデータはより長いルートがかかるため、一元配置遅延が長くなる可能性があります。したがって、MPAは、モバイルノードがハンドオフの準備をしているときに、より大きなパケット損失または一時的な一方向のパケット遅延とのトレードオフを提供します。
The proactive handover tunnel is established using a tunnel management protocol. When IKEv2 is used for proactive IP address acquisition, IKEv2 is also used as the tunnel management protocol. Alternatively, when PANA is used for proactive IP address acquisition, PANA may be used as the secure tunnel management protocol.
プロアクティブなハンドオーバートンネルは、トンネル管理プロトコルを使用して確立されています。IKEV2がプロアクティブなIPアドレス取得に使用される場合、IKEV2はトンネル管理プロトコルとしても使用されます。あるいは、PANAがプロアクティブなIPアドレス取得に使用される場合、PANAは安全なトンネル管理プロトコルとして使用される場合があります。
Once the proactive handover tunnel is established between the mobile node and the access router in the candidate target network, the access router also needs to perform proxy address resolution (Proxy ARP) on behalf of the mobile node so that it can capture any packets destined to the mobile node's new address.
モバイルノードと候補ターゲットネットワークのアクセスルーターの間にプロアクティブなハンドオーバートンネルが確立されると、アクセスルーターはモバイルノードに代わってプロキシアドレス解像度（プロキシARP）を実行する必要があります。モバイルノードの新しいアドレス。
Since the mobile node needs to be able to communicate with the Correspondent Node while in the previous network, some or all parts of the binding update and data from the Correspondent Node to the mobile node need to be sent back to the mobile node over a proactive handover tunnel. Details of these binding update procedures are described in Section 7.5.
モバイルノードは、以前のネットワークでは、バインディングアップデートの一部またはすべての部分と、特派員ノードからモバイルノードへのデータの一部またはすべての部分をプロアクティブ上でモバイルノードに戻す必要があるため、モバイルノードは通信型ノードと通信できる必要があるためハンドオーバートンネル。これらの結合更新手順の詳細については、セクション7.5で説明します。
In order for the traffic to be directed to the mobile node after the mobile node attaches to the target network, the proactive handover tunnel needs to be deleted or disabled. The tunnel management protocol used for establishing the tunnel is used for this purpose. Alternatively, when PANA is used as the authentication protocol, the tunnel deletion or disabling at the access router can be triggered by means of the PANA update mechanism as soon as the mobile node moves to the target network. A link-layer trigger ensures that the mobile node is indeed connected to the target network and can also be used as the trigger to delete or disable the tunnel. A tunnel management protocol also triggers the router advertisement (RA) from the next access router to be sent over the tunnel, as soon as the tunnel creation is complete.
モバイルノードがターゲットネットワークに接続された後、トラフィックをモバイルノードに向けるには、プロアクティブなハンドオーバートンネルを削除または無効にする必要があります。トンネルの確立に使用されるトンネル管理プロトコルは、この目的に使用されます。または、パナが認証プロトコルとして使用される場合、アクセスルーターでのトンネルの削除または無効化は、モバイルノードがターゲットネットワークに移動するとすぐに、PANA更新メカニズムによってトリガーできます。リンク層トリガーは、モバイルノードが実際にターゲットネットワークに接続されていることを保証し、トンネルを削除または無効にするトリガーとしても使用できます。トンネル管理プロトコルは、トンネルの作成が完了するとすぐに、トンネル上に送信される次のアクセスルーターからルーター広告（RA）をトリガーします。
There are several kinds of binding update mechanisms for different mobility management schemes.
さまざまなモビリティ管理スキームには、いくつかの種類のバインディング更新メカニズムがあります。
In the case of Mobile IPv4 and Mobile IPv6, the mobile node performs a binding update with the Home Agent only, if route optimization is not used. Otherwise, the mobile node performs the binding update with both the Home Agent (HA) and Correspondent Node (CN).
モバイルIPv4とモバイルIPv6の場合、モバイルノードは、ルート最適化が使用されない場合にのみ、ホームエージェントとのバインディングアップデートを実行します。それ以外の場合、モバイルノードは、ホームエージェント（HA）と特派員ノード（CN）の両方でバインディングアップデートを実行します。
In the case of SIP-based terminal mobility, the mobile node sends a binding update using an INVITE to the Correspondent Node and a REGISTER message to the Registrar. Based on the distance between the mobile node and the Correspondent Node, the binding update may contribute to the handover delay. SIP-fast handover [SIPFAST] provides several ways of reducing the handover delay due to binding update. In the case of secure proactive handover using SIP-based mobility management, we do not encounter the delay due to the binding update at all, as it takes place in the previous network.
SIPベースのターミナルモビリティの場合、モバイルノードは、特派員ノードへの招待状を使用してバインディングアップデートを送信し、レジスタラへのレジスタメッセージを送信します。モバイルノードと特派員ノード間の距離に基づいて、バインディングアップデートはハンドオーバー遅延に寄与する可能性があります。SIP-Fast Handover [SIPFAST]は、バインディングアップデートによりハンドオーバー遅延を減らすいくつかの方法を提供します。SIPベースのモビリティ管理を使用した安全なプロアクティブハンドオーバーの場合、以前のネットワークで行われているため、バインディングアップデートのために遅延はまったく遭遇しません。
Thus, this proactive binding update scheme looks more attractive when the Correspondent Node is too far from the communicating mobile node. Similarly, in the case of Mobile IPv6, the mobile node sends the newly acquired CoA from the target network as the binding update to the HA and CN. Also, all signaling messages between the MN and HA and between the MN and CN are passed through this proactive tunnel that is set up. These messages include Binding Update (BU); Binding Acknowledgement (BA); and the associated return routability messages, such as Home Test Init (HoTI), Home Test (HoT), Care-of Test Init (CoTI), and Care-of Test (CoT). In Mobile IPv6, since the receipt of an on-link router advertisement is mandatory for the mobile node to detect the movement and trigger the binding update, a router advertisement from the next access router needs to be advertised over the tunnel. By proper configuration on the nAR, the router advertisement can be sent over the tunnel interface to trigger the proactive binding update. The mobile node also needs to make the tunnel interface the active interface, so that it can send the binding update using this interface as soon as it receives the router advertisement.
したがって、このプロアクティブなバインディングアップデートスキームは、通信者ノードが通信モバイルノードから遠すぎると、より魅力的に見えます。同様に、モバイルIPv6の場合、モバイルノードは、HAおよびCNへのバインディングアップデートとして、ターゲットネットワークから新しく取得したCOAを送信します。また、MNとHAの間、およびMNとCNの間のすべてのシグナリングメッセージは、設定されているこのプロアクティブなトンネルを通過します。これらのメッセージには、バインディングアップデート（BU）が含まれます。バインディング承認（BA）;ホームテストINIT（HOTI）、ホームテスト（HOT）、ケアオブテストININT（COTI）、およびケアオブテスト（COT）などの関連する返品ルー上のメッセージ。モバイルIPv6では、モバイルノードが動きを検出し、バインディングアップデートをトリガーするためにオンリンクルーター広告の受信が必須であるため、次のアクセスルーターからのルーター広告をトンネル上で宣伝する必要があります。NARの適切な構成により、ルーター広告をトンネルインターフェイス上に送信して、プロアクティブなバインディングアップデートをトリガーできます。また、モバイルノードは、トンネルインターフェイスをアクティブインターフェイスにする必要があります。これにより、ルーター広告を受信するとすぐにこのインターフェイスを使用してバインディングアップデートを送信できます。
If the proactive handover tunnel is realized as an IPsec tunnel, it will also protect these signaling messages between the tunnel end-points and will make the return routability test secured as well. Any subsequent data will also be tunneled through, as long as the mobile node is in the previous network. The accompanying document [MPA-WIRELESS] talks about the details of how binding updates and signaling for return routability are sent over the secured tunnel.
プロアクティブなハンドオーバートンネルがIPSECトンネルとして実現された場合、トンネルのエンドポイント間のこれらのシグナリングメッセージも保護し、リターンルー上のテストも確保されます。モバイルノードが以前のネットワークにある限り、後続のデータもトンネル化されます。付随するドキュメント[MPA-Wireless]は、拘束力のある更新と返品ルー上の信号が担保付きトンネルを介して送信される方法の詳細について説明しています。
In the MPA case, packet loss due to IP address acquisition, secured authentication, and binding update does not occur. However, transient packets during link-layer handover can be lost. Possible scenarios of packet loss and its prevention are described below.
MPAの場合、IPアドレスの取得、保護された認証、および拘束力のある更新によるパケット損失は発生しません。ただし、リンク層のハンドオーバー中の一時的なパケットは失われる可能性があります。パケット損失とその予防の考えられるシナリオを以下に説明します。
For single-interface MPA, there may be some transient packets during link-layer handover that are directed to the mobile node at the old point of attachment before the mobile node is able to attach to the target network. Those transient packets can be lost. Buffering these packets at the access router of the old point of attachment can eliminate packet loss. Dynamic buffering signals from the MN can temporarily hold transient traffic during handover, and then these packets can be forwarded to the MN once it attaches to the target network. A detailed analysis of the buffering technique can be found in [PIMRC06].
シングルインターフェイスMPAの場合、モバイルノードがターゲットネットワークに接続できる前に、古いアタッチメントポイントでモバイルノードに向けられたリンク層ハンドオーバー中に一時的なパケットがある場合があります。これらの一時的なパケットは失われる可能性があります。古いアタッチメントポイントのアクセスルーターでこれらのパケットをバッファリングすると、パケットの損失を排除できます。MNからの動的バッファリング信号は、ハンドオーバー中に一時的に過渡トラフィックを保持でき、これらのパケットはターゲットネットワークに接続するとMNに転送できます。緩衝技術の詳細な分析は、[PIMRC06]に記載されています。
An alternative method is to use bicasting. Bicasting helps to forward the traffic to two destinations at the same time. However, it does not eliminate packet loss if link-layer handover is not seamlessly performed. On the other hand, buffering does not reduce packet delay. While packet delay can be compensated by a playout buffer at the receiver side for a streaming application, a playout buffer does not help much for interactive VoIP applications that cannot tolerate large delay jitters. Thus, it is still important to optimize the link-layer handover anyway.
別の方法は、バイカストを使用することです。バイカストは、トラフィックを2つの宛先に同時に転送するのに役立ちます。ただし、リンク層のハンドオーバーがシームレスに実行されない場合、パケットの損失を排除しません。一方、バッファリングはパケットの遅延を軽減しません。パケット遅延は、ストリーミングアプリケーションのレシーバー側のプレイアウトバッファーによって補償される可能性がありますが、プレイアウトバッファーは、大きな遅延ジッターに耐えられないインタラクティブなVoIPアプリケーションにはあまり役に立ちません。したがって、とにかくリンク層のハンドオーバーを最適化することが依然として重要です。
MPA usage in multi-interface handover scenarios involves preparing the second interface for use via the current active interface. This preparation involves pre-authentication and provisioning at a target network where the second interface would be the eventual active interface. For example, during inter-technology handover from a WiFi to a CDMA network, pre-authentication at the CDMA network can be performed via the WiFi interface. The actual handover occurs when the CDMA interface becomes the active interface for the MN.
マルチインターフェイスハンドオーバーシナリオでのMPA使用には、現在のアクティブインターフェイスを介して使用する2番目のインターフェイスを準備します。この準備には、2番目のインターフェイスが最終的なアクティブインターフェイスになるターゲットネットワークでの事前認証とプロビジョニングが含まれます。たとえば、WiFiからCDMAネットワークへのテクノロジー間ハンドオーバー中に、CDMAネットワークでの事前認証はWiFiインターフェイスを介して実行できます。実際のハンドオーバーは、CDMAインターフェイスがMNのアクティブインターフェイスになったときに発生します。
In such scenarios, if handover occurs while both interfaces are active, there is generally no packet loss, since transient packets directed towards the old interface will still reach the MN. However, if sudden disconnection of the current active interface is used to initiate handover to the prepared interface, then transient packets for the disconnected interface will be lost while the MN attempts to be reachable at the prepared interface. In such cases, a specialized form of buffering can be used to eliminate packet loss where packets are merely copied at an access router in the current active network prior to disconnection. If sudden disconnection does occur, copied packets can be forwarded to the MN once the prepared interface becomes the active reachable interface. The copy-and-forward mechanism is not limited to multi-interface handover.
このようなシナリオでは、両方のインターフェイスがアクティブになっている間にハンドオーバーが発生した場合、古いインターフェイスに向けられた一時的なパケットがMNに到達するため、一般的にパケット損失はありません。ただし、現在のアクティブインターフェイスの突然の切断を使用して、調製されたインターフェイスへのハンドオーバーを開始すると、MNが準備されたインターフェイスで到達可能になろうとする間、切断されたインターフェイスの過渡パケットが失われます。そのような場合、バッファリングの特殊な形式を使用して、切断前に現在のアクティブネットワークのアクセスルーターにパケットがコピーされるだけで、パケットの損失を排除できます。突然の切断が発生した場合、準備されたインターフェイスがアクティブな到達可能なインターフェイスになると、コピーされたパケットをMNに転送できます。コピーアンドフォワードメカニズムは、マルチインターフェイスのハンドオーバーに限定されません。
A notable side-effect of this process is the possible duplication of packets during forwarding to the new active interface. Several approaches can be employed to minimize this effect. Relying on upper-layer protocols such as TCP to detect and eliminate duplicates is the most common approach. Customized duplicate detection and handling techniques can also be used. In general, packet duplication is a well-known issue that can also be handled locally by the MN.
このプロセスの顕著な副作用は、新しいアクティブインターフェイスへの転送中のパケットの重複の可能性です。この効果を最小限に抑えるために、いくつかのアプローチを採用できます。重複を検出および排除するためにTCPなどの上層層プロトコルに依存することが最も一般的なアプローチです。カスタマイズされた重複した検出および取り扱い手法も使用できます。一般に、パケットの複製はよく知られている問題であり、MNがローカルで処理することもできます。
If the mobile node takes a longer amount of time to detect the disconnection event of the current active interface, this can also have an adverse effect on the length of the handover process. Thus, it becomes necessary to use an optimized scheme of detecting interface disconnection in such scenarios. Use of the current interface to perform pre-authentication instead of the new interface is desirable in certain circumstances, such as to save battery power, or in cases where the adjacent cells (e.g., WiFi or CDMA) are non-overlapping, or in cases when the carrier does not allow the simultaneous use of both interfaces. However, in certain circumstances, depending upon the type of target network, only parts of MPA operations can be performed (e.g., pre-authentication, pre-configuration, or proactive binding update). In a specific scenario involving handoff between WiFi and CDMA networks, some of the PPP context can be set up during the pre-authentication period, thus reducing the time for PPP activation.
モバイルノードが現在のアクティブインターフェイスの切断イベントを検出するのに時間がかかる場合、これはハンドオーバープロセスの長さに悪影響を与える可能性もあります。したがって、このようなシナリオでインターフェイスの切断を検出する最適化されたスキームを使用する必要があります。新しいインターフェイスの代わりに事前認証を実行するための現在のインターフェイスを使用することは、バッテリーの電源を節約したり、隣接するセル（wifiやCDMAなど）が重複しない場合、または場合によっては、特定の状況では望ましいものです。キャリアが両方のインターフェイスの同時使用を許可しない場合。ただし、特定の状況では、ターゲットネットワークのタイプに応じて、MPA操作の一部のみを実行できます（たとえば、事前認証、事前構成、またはプロアクティブなバインディングアップデート）。WiFiとCDMAネットワークの間のハンドオフを含む特定のシナリオでは、PPPコンテキストの一部を認証前に設定することができ、PPP活性化の時間を短縮できます。
In addition to previous techniques, the MN may also want to ensure reachability of the new point of attachment before switching from the old one. This can be done by exchanging link-layer management frames with the new point of attachment. This reachability check should be performed as quickly as possible. In order to prevent packet loss during this reachability check, transmission of packets over the link between the MN and the old point of attachment should be suspended by buffering the packets at both ends of the link during the reachability check. How to perform this buffering is out of scope of this document. Some of the results of using this buffering scheme are explained in the accompanying document [MPA-WIRELESS].
以前の手法に加えて、MNは、古いものから切り替える前に、新しいアタッチメントポイントの到達可能性を確保したい場合もあります。これは、リンク層管理フレームを新しい添付ポイントと交換することで実行できます。この到達可能性チェックは、できるだけ早く実行する必要があります。この到達可能性チェック中にパケットの損失を防ぐために、到達可能性チェック中にリンクの両端でパケットをバッファリングすることにより、MNと古いアタッチメントポイント間のリンク上のパケットの送信を停止する必要があります。このバッファリングの実行方法は、このドキュメントの範囲外です。このバッファリングスキームを使用した結果のいくつかは、付随するドキュメント[MPA-Wireless]で説明されています。
This section describes how MPA can help establish layer 2 and layer 3 security association in the target networks while the mobile node is in the previous network.
このセクションでは、MPAがモバイルノードが前のネットワークにある間に、ターゲットネットワークでレイヤー2とレイヤー3セキュリティアソシエーションを確立するのに役立つ方法について説明します。
Using the MPA-SA established between the mobile node and the authentication agent for a CTN, during the pre-authentication phase, it is possible to bootstrap link-layer security in the CTN while the mobile node is in the current network, as described in the following steps. Figure 5 shows the sequence of operation.
モバイルノードとCTN用の認証エージェントの間に確立されたMPA-SAを使用して、事前認証フェーズ中に、モバイルノードが現在のネットワークにある間にCTNでリンク層セキュリティをブートストラップすることができます。次の手順。図5は、操作のシーケンスを示しています。
(1) The authentication agent and the mobile node derive a PMK (Pair-wise Master Key) [RFC5247] using the MPA-SA that is established as a result of successful pre-authentication. Successful operation of EAP and a AAA protocol may be involved during pre-authentication to establish the MPA-SA. From the PMK, distinct TSKs (Transient Session Keys) [RFC5247] for the mobile node are directly or indirectly derived for each point of attachment of the CTN.
(1) 認証エージェントとモバイルノードは、PMK（ペアワイズマスターキー）[RFC5247）を導き出し、認証前の成功の結果として確立されたMPA-SAを使用します。EAPおよびAAAプロトコルの操作が成功すると、MPA-SAを確立するための事前認定中に関与する可能性があります。PMKから、モバイルノードの個別のTSK（一時的なセッションキー）[RFC5247]は、CTNの付着ポイントごとに直接的または間接的に導出されます。
(2) The authentication agent may install the keys derived from the PMK and used for secure association to points of attachment. The derived keys may be TSKs or intermediary keys from which TSKs are derived.
(2) 認証エージェントは、PMKから派生したキーをインストールし、安全な関連付けに使用され、アタッチメントポイントに使用できます。派生キーは、TSKまたはTSKが導出される中間キーである場合があります。
(3) After the mobile node chooses a CTN as the target network and switches to a point of attachment in the target network (which now becomes the new network for the mobile node), it executes a secure association protocol such as the IEEE 802.11i 4-way handshake [802.11], using the PMK in order to establish PTKs (Pair-wise Transient Keys) and group keys [RFC5247] used for protecting link-layer packets between the mobile node and the point of attachment. No additional execution of EAP authentication is needed here.
(3) モバイルノードがターゲットネットワークとしてCTNを選択し、ターゲットネットワークの添付ファイル（モバイルノードの新しいネットワークになるように）に切り替えた後、IEEE 802.11i 4-wayなどの安全な関連プロトコルを実行します。PMKを使用して、モバイルノードとアタッチメントポイント間のリンク層パケットを保護するために使用されるPTK（ペアワイズトランジェントキー）とグループキー[RFC5247]を確立するためにPMKを使用します。ここでは、EAP認証の追加の実行は必要ありません。
(4) While the mobile node is roaming in the new network, the mobile node only needs to perform a secure association protocol with its point of attachment, and no additional execution of EAP authentication is needed either. Integration of MPA with link-layer handover optimization mechanisms such as 802.11r can be archived this way.
(4) モバイルノードは新しいネットワークでローミングしていますが、モバイルノードは添付ポイントを備えた安全な関連プロトコルを実行する必要があり、EAP認証の追加の実行も必要ありません。802.11Rなどのリンク層ハンドオーバー最適化メカニズムとMPAの統合は、この方法でアーカイブできます。
The mobile node may need to know the link-layer identities of the points of attachment in the CTN to derive TSKs.
モバイルノードは、TSKを導出するためにCTNのアタッチメントポイントのリンク層のアイデンティティを知る必要がある場合があります。
_________________ ____________________________
| Current Network | | CTN |
| ____ | | ____ |
| | | (1) pre-authentication | | |
| | MN |<------------------------------->| AA | |
| |____| | | |____| |
| . | | | |
| . | | | |
|____.____________| | | |
.movement | |(2) Keys |
____.___________________| | |
| _v__ _____ | |
| | |(3) secure assoc. | | | |
| | MN |<------------------>| AP1 |<-------+ |
| |____| |_____| | |
| . | |
| .movement | |
| . | |
| . | |
| _v__ _____ | |
| | |(4) secure assoc. | | | |
| | MN |<------------------>| AP2 |<-------+ |
| |____| |_____| |
|_____________________________________________________|
Figure 5: Bootstrapping Link-Layer Security
図5：ブートストラップリンク層セキュリティ
IP-layer security is typically maintained between the mobile node and the first-hop router, or any other network element such as SIP proxy by means of IPsec. This IPsec SA can be set up either in tunnel mode or in ESP mode. However, as the mobile node moves, the IP address of the router and outbound proxy will change in the new network. The mobile node's IP address may or may not change, depending upon the mobility protocol being used. This will warrant re-establishing a new security association between the mobile node and the desired network entity. In some cases, such as in a 3GPP/3GPP2 IMS/MMD environment, data traffic is not allowed to pass through unless there is an IPsec SA established between the mobile node and outbound proxy. This will of course add unreasonable delay to the existing real-time communication during a mobile node's movement. In this scenario, key exchange is done as part of a SIP registration that follows a key exchange procedure called AKA (Authentication and Key Agreement).
通常、IP層セキュリティは、モバイルノードと最初のホップルーター、またはIPSECを使用してSIPプロキシなどのその他のネットワーク要素の間で維持されます。このIPSEC SAは、トンネルモードまたはESPモードのいずれかでセットアップできます。ただし、モバイルノードが移動すると、ルーターとアウトバウンドプロキシのIPアドレスが新しいネットワークで変更されます。モバイルノードのIPアドレスは、使用されているモビリティプロトコルに応じて、変更されない場合があります。これにより、モバイルノードと目的のネットワークエンティティとの間の新しいセキュリティ協会が再確立されることが保証されます。場合によっては、3GPP/3GPP2 IMS/MMD環境など、モバイルノードとアウトバウンドプロキシの間にIPSEC SAが確立されていない限り、データトラフィックは通過できません。これはもちろん、モバイルノードの動き中に既存のリアルタイム通信に不当な遅延を追加します。このシナリオでは、Key Exchangeは、AKA（認証と重要な契約）と呼ばれる主要な交換手順に従うSIP登録の一部として行われます。
MPA can be used to bootstrap this security association as part of pre-authentication via the new outbound proxy. Prior to the movement, if the mobile node can pre-register via the new outbound proxy in the target network and completes the pre-authentication procedure, then the new SA state between the mobile node and new outbound proxy can be established prior to the movement to the new network. A similar approach can also be applied if a key exchange mechanism other than AKA is used or the network element with which the security association has to be established is different than an outbound proxy.
MPAは、新しいアウトバウンドプロキシを介して事前認証の一部としてこのセキュリティ協会をブートストラップするために使用できます。動きの前に、モバイルノードがターゲットネットワークの新しいアウトバウンドプロキシを介して事前登録でき、事前認証手順を完了することができれば、モバイルノードと新しいアウトバウンドプロキシの間の新しいSA状態を運動前に確立できます。新しいネットワークへ。AKA以外のキー交換メカニズムが使用されている場合、またはセキュリティ協会を確立する必要があるネットワーク要素がアウトバウンドプロキシとは異なる場合、同様のアプローチも適用できます。
By having the security association established ahead of time, the mobile node does not need to be involved in any exchange to set up the new security association after the movement. Any further key exchange will be limited to renew the expiry time. This will reduce the delay for real-time communication as well.
セキュリティ協会を事前に確立することにより、モバイルノードは、移動後に新しいセキュリティ協会を設定するために、どの交換にも関与する必要はありません。さらに重要な交換は、有効期限を更新するために制限されます。これにより、リアルタイム通信の遅延も減ります。
When the mobile node initially attaches to a network, network access authentication would occur regardless of the use of MPA. The protocol used for network access authentication when MPA is used for handover optimization can be a link-layer network access authentication protocol such as IEEE 802.1X, or a higher-layer network access authentication protocol such as PANA.
モバイルノードが最初にネットワークに接続すると、MPAの使用に関係なくネットワークアクセス認証が発生します。ネットワークアクセス認証に使用されるプロトコルMPAがハンドオーバーの最適化に使用される場合、IEEE 802.1xなどのリンク層ネットワークアクセス認証プロトコル、またはPANAなどの高層ネットワークアクセス認証プロトコルになります。
This document describes a framework for a secure handover optimization mechanism based on performing handover-related signaling between a mobile node and one or more candidate target networks to which the mobile node may move in the future. This framework involves acquisition of the resources from the CTN as well as data packet redirection from the CTN to the mobile node in the current network before the mobile node physically connects to one of those CTNs.
このドキュメントでは、モバイルノードとモバイルノードが将来移動する可能性のある1つ以上の候補ターゲットネットワークとの間でハンドオーバー関連のシグナリングを実行することに基づいた安全なハンドオーバー最適化メカニズムのフレームワークについて説明します。このフレームワークには、CTNからのリソースの取得と、モバイルノードがこれらのCTNの1つに物理的に接続する前に、CTNから現在のネットワークのモバイルノードへのデータパケットリダイレクトが含まれます。
Acquisition of the resources from the candidate target networks must be done with appropriate authentication and authorization procedures in order to prevent an unauthorized mobile node from obtaining the resources. For this reason, it is important for the MPA framework to perform pre-authentication between the mobile node and the candidate target networks. The MN-CA key and the MN-AR key generated as a result of successful pre-authentication can protect subsequent handover signaling packets and data packets exchanged between the mobile node and the MPA functional elements in the CTNs.
候補ターゲットネットワークからのリソースの取得は、許可されていないモバイルノードがリソースの取得を防ぐために、適切な認証と承認手順を使用して行う必要があります。このため、MPAフレームワークがモバイルノードと候補ターゲットネットワーク間で事前認証を実行することが重要です。MN-CAキーと、成功した事前認証の結果として生成されたMN-ARキーは、モバイルノードとCTNSのMPA機能要素の間で交換されるその後のハンドオーバーシグナリングパケットとデータパケットを保護できます。
The MPA framework also addresses security issues when the handover is performed across multiple administrative domains. With MPA, it is possible for handover signaling to be performed based on direct communication between the mobile node and routers or mobility agents in the candidate target networks. This eliminates the need for a context transfer protocol [RFC5247] for which known limitations exist in terms of security and authorization. For this reason, the MPA framework does not require trust relationships among administrative domains or access routers, which makes the framework more deployable in the Internet without compromising the security in mobile environments.
MPAフレームワークは、複数の管理ドメインでハンドオーバーが実行される場合、セキュリティの問題にも対処します。MPAを使用すると、候補ターゲットネットワークのモバイルノードとルーターまたはモビリティエージェント間の直接通信に基づいて、ハンドオーバーシグナルを実行することができます。これにより、セキュリティと承認の観点から既知の制限が存在するコンテキスト転送プロトコル[RFC5247]の必要性が排除されます。このため、MPAフレームワークでは、管理ドメインやアクセスルーター間の信頼関係を必要としないため、モバイル環境のセキュリティを損なうことなく、インターネットでフレームワークをより展開可能にします。
We would like to thank Farooq Anjum and Raziq Yaqub for their review of this document, and Subir Das for standardization support in the IEEE 802.21 working group.
この文書のレビューについては、Farooq AnjumとRaziq Yaqub、IEEE 802.21ワーキンググループの標準化サポートについては、Subir Dasに感謝します。
The authors would like to acknowledge Christian Vogt, Rajeev Koodli, Marco Liebsch, Juergen Schoenwaelder, and Charles Perkins for their thorough review of the document and useful feedback.
著者は、ドキュメントと有用なフィードバックの徹底的なレビューについて、クリスチャン・フォグト、ラジーエフ・クッドリ、マルコ・リーブシュ、ジュエルゲン・シェーンワエルダー、チャールズ・パーキンスを認めたいと考えています。
Author and Editor Ashutosh Dutta would like to thank Telcordia Technologies, and author Victor Fajardo would like to thank Toshiba America Research and Telcordia Technologies, for supporting the development of their document while they were employed in their respective organizations.
著者で編集者のアシュトッシュ・ドゥッタは、テルコルディア・テクノロジーズに感謝したいと思います。著者のビクター・ファハルドは、それぞれの組織で雇用されている間に文書の開発をサポートしてくれた東芝研究とテルコルディア技術に感謝したいと思います。
[RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010.
[RFC5944] Perkins、C.、ed。、「IPv4のIPモビリティサポート、改訂」、RFC 5944、2010年11月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J.、およびH. Levkowetz、ed。、「Extensible認証プロトコル（EAP）」、RFC 3748、2004年6月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、9月1997年。
[RFC5380] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, October 2008.
[RFC5380] Soliman、H.、Castelluccia、C.、El Malki、K。、およびL. Bellier、「階層モバイルIPv6（HMIPV6）モビリティ管理」、RFC 5380、2008年10月。
[RFC5568] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5568, July 2009.
[RFC5568] Koodli、R.、ed。、「Mobile IPv6 Fast Handovers」、RFC 5568、2009年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
[RFC4555] Eronen、P。、「IKEV2モビリティおよびマルチホームプロトコル（MOBIKE）」、RFC 4555、2006年6月。
[RFC4881] El Malki, K., Ed., "Low-Latency Handoffs in Mobile IPv4", RFC 4881, June 2007.
[RFC4881] El Malki、K.、ed。、「モバイルIPv4の低遅延ハンドオフ」、RFC 4881、2007年6月。
[RFC4066] Liebsch, M., Ed., Singh, A., Ed., Chaskar, H., Funato, D., and E. Shim, "Candidate Access Router Discovery (CARD)", RFC 4066, July 2005.
[RFC4066] Liebsch、M.、Ed。、Singh、A.、Ed。、Chaskar、H.、Funato、D。、およびE. Shim、「候補アクセスルーター発見（カード）」、RFC 4066、2005年7月。
[RFC4067] Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, "Context Transfer Protocol (CXTP)", RFC 4067, July 2005.
[RFC4067] Loughney、J.、Nakhjiri、M.、Perkins、C。、およびR. Koodli、「Context Transfer Protocol（CXTP）」、RFC 4067、2005年7月。
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008.
[RFC5247] Aboba、B.、Simon、D。、およびP. Eronen、「拡張可能な認証プロトコル（EAP）キー管理フレームワーク」、RFC 5247、2008年8月。
[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, May 2008.
[RFC5191] Forsberg、D.、Ohba、Y.、Ed。、Patil、B.、Tschofenig、H。、およびA. Yegin、「ネットワークアクセスのための認証を運ぶためのプロトコル（PANA）」、RFC 5191、2008年5月。
[RG98] ITU-T, "General Characteristics of International Telephone Connections and International Telephone Circuits: One-Way Transmission Time", ITU-T Recommendation G.114, 1998.
[RG98] ITU-T、「国際電話接続と国際電話回路の一般的な特性：一元配置伝送時間」、ITU-T推奨G.114、1998。
[ITU98] ITU-T, "The E-Model, a computational model for use in transmission planning", ITU-T Recommendation G.107, 1998.
[ITU98] ITU-T、「伝送計画で使用するための計算モデルであるE-Model」、ITU-T推奨G.107、1998。
[ETSI] ETSI, "Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON) Release 3; End-to-end Quality of Service in TIPHON systems; Part 1: General aspects of Quality of Service (QoS)", ETSI TR 101 329-1 V3.1.2, 2002.
[ETSI] ETSI、「ネットワーク上のテレコミュニケーションとインターネットプロトコルの調和（TIPHON）リリース3; Tiphon Systemsのエンドツーエンドサービス品質;パート1：サービス品質の一般的な側面（QoS）、ETSI TR 101 329-1 v3.1.2、2002。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201] Moskowitz、R.、Nikander、P.、Jokela、P.、Ed。、およびT. Henderson、「Host Identity Protocol」、RFC 5201、2008年4月。
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2679] Almes、G.、Kalidindi、S。、およびM. Zekauskas、「IPPMの一方向遅延メトリック」、RFC 2679、1999年9月。
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC2680] Almes、G.、Kalidindi、S。、およびM. Zekauskas、「IPPMの一元配置パケット損失メトリック」、RFC 2680、1999年9月。
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999.
[RFC2681] Almes、G.、Kalidindi、S。、およびM. Zekauskas、「IPPMの往復遅延メトリック」、RFC 2681、1999年9月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003] Perkins、C。、「IP内のIPカプセル化」、RFC 2003、1996年10月。
[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[RFC2608] Guttman、E.、Perkins、C.、Veizades、J。、およびM. Day、「サービスロケーションプロトコル、バージョン2」、RFC 2608、1999年6月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473] Conta、A。およびS. Deering、「IPv6仕様の一般的なパケットトンネル」、RFC 2473、1998年12月。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[RFC3046] Patrick、M。、「DHCPリレーエージェント情報オプション」、RFC 3046、2001年1月。
[RFC4039] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4)", RFC 4039, March 2005.
[RFC4039] Park、S.、Kim、P。、およびB. Volz、「動的ホスト構成プロトコルバージョン4（DHCPV4）の迅速なコミットオプション」、RFC 4039、2005年3月。
[RFC5172] Varada, S., Ed., "Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol", RFC 5172, March 2008.
[RFC5172] Varada、S.、ed。、「IPv6コントロールプロトコルを使用したIPv6データグラム圧縮の交渉」、RFC 5172、2008年3月。
[RFC5648] Wakikawa, R., Ed., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", RFC 5648, October 2009.
[RFC5648] Wakikawa、R.、ed。、Devarapalli、V.、Tsirtsis、G.、Ernst、T。、およびK. Nagami、「複数のアドレスの登録」、RFC 5648、2009年10月。
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, April 2006.
[RFC4429]ムーア、N。、「IPv6の楽観的な重複アドレス検出（DAD）」、RFC 4429、2006年4月。
[RFC5836] Ohba, Y., Ed., Wu, Q., Ed., and G. Zorn, Ed., "Extensible Authentication Protocol (EAP) Early Authentication Problem Statement", RFC 5836, April 2010.
[RFC5836] Ohba、Y.、ed。、Wu、Q.、ed。、およびG. Zorn、ed。、「Extensible認証プロトコル（EAP）初期認証問題声明」、RFC 5836、2010年4月。
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5213] Gundavelli、S.、Ed。、Leung、K.、Devarapalli、V.、Chowdhury、K。、およびB. Patil、「Proxy Mobile IPv6」、RFC 5213、2008年8月。
[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, October 2010.
[RFC5974] MANER、J.、Karagiannis、G。、およびA. McDonald、「サービス品質シグナル伝達のためのNSISシグナリング層プロトコル（NSLP）」、RFC 5974、2010年10月。
[RFC5169] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti, "Handover Key Management and Re-Authentication Problem Statement", RFC 5169, March 2008.
[RFC5169] Clancy、T.、Nakhjiri、M.、Narayanan、V。、およびL. Dondeti、「ハンドオーバーキー管理と再認可問題声明」、RFC 5169、2008年3月。
[SIPMM] Schulzrinne, H. and E. Wedlund, "Application-Layer Mobility Using SIP", ACM MC2R, July 2000.
[SIPMM] Schulzrinne、H。およびE. Wedlund、「SIPを使用したアプリケーションレイヤーモビリティ」、ACM MC2R、2000年7月。
[CELLIP] Campbell, A., Gomez, J., Kim, S., Valko, A., Wan, C., and Z. Turanyi, "Design, Implementation, and Evaluation of Cellular IP", IEEE Personal Communications, August 2000.
[Cellip] Campbell、A.、Gomez、J.、J.、Kim、S.、Valko、A.、Wan、C。、およびZ. Turanyi、「Cellular IPの設計、実装、評価」、IEEEパーソナルコミュニケーション、8月2000。
[MOBIQUIT07] Lopez, R., Dutta, A., Ohba, Y., Schulzrinne, H., and A. Skarmeta, "Network-layer assisted mechanism to optimize authentication delay during handoff in 802.11 networks", IEEE Mobiquitous, June 2007.
[Mobiquit07] Lopez、R.、Dutta、A.、Ohba、Y.、Schulzrinne、H.、およびA. Skarmeta、「ネットワーク層支援メカニズム802.11ネットワークでのハンドオフ中の認証遅延を最適化する」、IEEE Mobivitous、2007年6月。
[MISHRA04] Mishra, A., Shin, M., Petroni, N., Clancy, T., and W. Arbaugh, "Proactive key distribution using neighbor graphs", IEEE Wireless Communications Magazine, February 2004.
[Mishra04] Mishra、A.、Shin、M.、Petroni、N.、Clancy、T。、およびW. Arbaugh、「近隣グラフを使用したプロアクティブキーディストリビューション」、IEEE Wireless Communications Magazine、2004年2月。
[SPRINGER07] Dutta, A., Das, S., Famolari, D., Ohba, Y., Taniuchi, K., Fajardo, V., Lopez, R., Kodama, T., Schulzrinne, H., and A. Skarmeta, "Seamless proactive handover across heterogeneous access networks", Wireless Personal Communications, November 2007.
[Springer07] Dutta、A.、Das、S.、Famolari、D.、Ohba、Y.、Taniuchi、K.、Fajardo、V.、Lopez、R.、Kodama、T.、Schulzrinne、H。、およびA。スカルメタ、「不均一アクセスネットワーク全体のシームレスなプロアクティブハンドオーバー」、ワイヤレスパーソナルコミュニケーション、2007年11月。
[HAWAII] Ramjee, R., La Porta, T., Thuel, S., Varadhan, K., and S. Wang, "HAWAII: A Domain-based Approach for Supporting Mobility in Wide-area Wireless networks", International Conference on Network Protocols ICNP'99.
[ハワイ] Ramjee、R.、La Porta、T.、Thuel、S.、Varadhan、K。、およびS. Wang、「Hawaii：広い地域のワイヤレスネットワークのモビリティをサポートするためのドメインベースのアプローチ」、国際会議ネットワークプロトコルICNP'99。
[IDMP] Das, S., McAuley, A., Dutta, A., Misra, A., Chakraborty, K., and S. Das, "IDMP: An Intra-Domain Mobility Management Protocol for Next Generation Wireless Networks", IEEE Wireless Communications Magazine, October 2000.
[IDMP] Das、S.、McAuley、A.、Dutta、A.、Misra、A.、Chakraborty、K。、およびS. Das、「IDMP：次世代ワイヤレスネットワークのドメイン内モビリティ管理プロトコル」、IEEE Wireless Communications Magazine、2000年10月。
[MOBIP-REG] Gustafsson, E., Jonsson, A., and C. Perkins, "Mobile IPv4 Regional Registration", Work in Progress, June 2004.
[Mobip-Reg] Gustafsson、E.、Jonsson、A。、およびC. Perkins、「モバイルIPv4地域登録」、2004年6月、進行中の作業。
[YOKOTA] Yokota, H., Idoue, A., Hasegawa, T., and T. Kato, "Link Layer Assisted Mobile IP Fast Handoff Method over Wireless LAN Networks", Proceedings of ACM MobiCom02, 2002.
[Yokota] Yokota、H.、Idoue、A.、Hasegawa、T.、およびT. Kato、「リンクレイヤーアシストモバイルIP高速ハンドオフメソッドをワイヤレスLANネットワーク上のハンドオフメソッド」、ACM Mobicom02、2002の議事録。
[MACD] Shin, S., Forte, A., Rawat, A., and H. Schulzrinne, "Reducing MAC Layer Handoff Latency in IEEE 802.11 Wireless LANs", MobiWac Workshop, 2004.
[MACD] Shin、S.、Forte、A.、Rawat、A.、およびH. Schulzrinne、「IEEE 802.11ワイヤレスLANSのMACレイヤーハンドオフレイテンシの削減」、Mobiwac Workshop、2004。
[SUM] Dutta, A., Zhang, T., Madhani, S., Taniuchi, K., Fujimoto, K., Katsube, Y., Ohba, Y., and H. Schulzrinne, "Secured Universal Mobility for Wireless Internet", WMASH'04, October 2004.
[sum] Dutta、A.、Zhang、T.、Madhani、S.、Taniuchi、K.、Fujimoto、K.、Katube、Y.、Ohba、Y.、およびH. Schulzrinne、「ワイヤレスインターネットのためのユニバーサルモビリティを確保する」"、Wmash'04、2004年10月。
[SIPFAST] Dutta, A., Madhani, S., Chen, W., Altintas, O., and H. Schulzrinne, "Fast-handoff Schemes for Application Layer Mobility Management", PIMRC 2004.
[Sipfast] Dutta、A.、Madhani、S.、Chen、W.、Altintas、O.、およびH. Schulzrinne、「アプリケーション層モビリティ管理のためのファーストハンドオフスキーム」、PIMRC 2004。
[PIMRC06] Dutta, A., Berg, E., Famolari, D., Fajardo, V., Ohba, Y., Taniuchi, K., Kodama, T., and H. Schulzrinne, "Dynamic Buffering Control Scheme for Mobile Handoff", Proceedings of PIMRC 2006, 1-11.
[PIMRC06] Dutta、A.、Berg、E.、Famolari、D.、Fajardo、V.、Ohba、Y.、Taniuchi、K.、Kodama、T。、およびH. Schulzrinne、モバイルの動的バッファリング制御スキームハンドオフ」、PIMRC 2006、1-11の議事録。
[MITH] Gwon, Y., Fu, G., and R. Jain, "Fast Handoffs in Wireless LAN Networks using Mobile initiated Tunneling Handoff Protocol for IPv4 (MITHv4)", Wireless Communications and Networking 2003, January 2005.
[Mith] Gwon、Y.、Fu、G。、およびR. Jain、「IPv4（MITHV4）のモバイル開始ハンドオフプロトコルを使用したワイヤレスLANネットワークでの高速ハンドオフ」、Wireless Communications and Networking 2003、2005年1月。
[WENYU] Jiang, W. and H. Schulzrinne, "Modeling of Packet Loss and Delay and their Effect on Real-Time Multimedia Service Quality", NOSSDAV 2000, June 2000.
[Wenyu] Jiang、W。and H. Schulzrinne、「パケットの損失と遅延のモデリングとリアルタイムマルチメディアサービス品質への影響」、Nossdav 2000、2000年6月。
[802.21] "IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services, IEEE 802.21-2008", a contribution to IEEE 802.21 WG, January 2009.
[802.21]「ローカルおよびメトロポリタンエリアネットワークのIEEE標準：Media Independent Handover Services、IEEE 802.21-2008」、IEEE 802.21 WGへの貢献、2009年1月。
[802.11] "IEEE Wireless LAN Edition A compilation based on IEEE Std 802.11-1999(R2003)", Institute of Electrical and Electronics Engineers, September 2003.
[802.11]「IEEEワイヤレスLANエディションIEEE STD 802.11-1999（R2003）に基づくコンピレーション」、2003年9月、電子およびエレクトロニクスエンジニア研究所。
[GPSIP] Dutta, A., Madhani, S., Chen, W., Altintas, O., and H. Schulzrinne, "GPS-IP based fast-handoff approaches for Mobiles", IEEE Sarnoff Symposium 2006.
[GPSIP] Dutta、A.、Madhani、S.、Chen、W.、Altintas、O.、およびH. Schulzrinne、「携帯用のGPS-IPベースのファストハンドオフアプローチ」、IEEE Sarnoff Symposium 2006。
[MAGUIRE] Vatn, J. and G. Maguire, "The effect of using co-located care-of addresses on macro handover latency", 14th Nordic Teletraffic Seminar 1998.
[Maguire] Vatn、J。and G. Maguire、「マクロハンドオーバーレイテンシで共同配置されたケアのケアを使用する効果」、第14回ノルディックテレトラフィックセミナー1998。
[MPA-MOBIKE] El Mghazli, Y., Bournelle, J., and J. Laganier, "MPA using IKEv2 and MOBIKE", Work in Progress, June 2006.
[MPA-Mobike] El Mghazli、Y.、Bournelle、J。、およびJ. Laganier、「IKEV2とMobikeを使用したMPA」、2006年6月、進行中の作業。
[MPA-WIRELESS] Dutta, A., Famolari, D., Das, S., Ohba, Y., Fajardo, V., Taniuchi, K., Lopez, R., and H. Schulzrinne, "Media- Independent Pre-authentication Supporting Secure Interdomain Handover Optimization", IEEE Wireless Communications Magazine, April 2008.
[MPA-Wireless] Dutta、A.、Famolari、D.、Das、S.、Ohba、Y.、Fajardo、V.、Taniuchi、K.、Lopez、R.、およびH. Schulzrinne、Media-Independent Pre-2008年4月、IEEE Wireless Communications Magazine、IEEE Wireless Communications Magazineをサポートすること」。
When the DHCP server dispenses an IP address, it updates its lease table, so that this same address is not given to another client for that specific period of time. At the same time, the client also keeps a lease table locally so that it can renew when needed. In some cases where a network consists of both DHCP and non-DHCP-enabled clients, there is a probability that another client in the LAN may have been configured with an IP address from the DHCP address pool. In such a scenario, the server detects a duplicate address based on ARP (Address Resolution Protocol) or IPv6 Neighbor Discovery before assigning the IP address. This detection procedure may take from 4 sec to 15 sec [MAGUIRE] and will thus contribute to a larger handover delay. In the case of a proactive IP address acquisition process, this detection is performed ahead of time and thus does not affect the handover delay at all. By performing the Duplicate Address Detection (DAD) ahead of time, we reduce the IP address acquisition time.
DHCPサーバーがIPアドレスを分配すると、リーステーブルを更新するため、この同じアドレスがその特定の期間にわたって別のクライアントに与えられません。同時に、クライアントは、必要に応じて更新できるように、クライアントがローカルにリーステーブルを保持します。ネットワークがDHCPと非DHCP対応クライアントの両方で構成されている場合には、LANの別のクライアントがDHCPアドレスプールのIPアドレスで構成されている可能性があります。このようなシナリオでは、サーバーは、IPアドレスを割り当てる前に、ARP（アドレス解像度プロトコル）またはIPv6ネイバーディスカバリーに基づいて重複するアドレスを検出します。この検出手順は4秒から15秒[マグワイア]にかかる可能性があるため、より大きなハンドオーバー遅延に貢献します。プロアクティブなIPアドレス取得プロセスの場合、この検出は事前に実行されるため、ハンドオーバー遅延にはまったく影響しません。重複アドレス検出（DAD）を事前に実行することにより、IPアドレスの取得時間を短縮します。
The proactive DAD over the candidate target network should be performed by the nAR on behalf of the mobile node at the time of proactive handover tunnel establishment, since DAD over a tunnel is not always performed. For example, in the case of IPv6, DAD over an IP-IP tunnel interface is turned off in an existing implementation. In the case of IPv6 over PPP [RFC5172], the IP Control Protocol (IPCPv6) negotiates the link-local addresses, and hence DAD over the tunnel is not needed. After the mobile node has moved to the target network, a DAD procedure may be started because of reassignment of the nCoA to the physical interface to the target network. In that case, the mobile node should use optimistic DAD [RFC4429] over the physical interface so that the nCoA that was used inside the proactive handover tunnel before handover can be immediately used over that physical interface after handover. The schemes used for the proactive DAD and optimistic DAD are applicable to both stateless and stateful address autoconfiguration schemes used for obtaining a nCoA.
候補者ターゲットネットワーク上のプロアクティブなDADは、積極的なハンドオーバートンネル設立時にモバイルノードに代わってNARによって実行される必要があります。たとえば、IPv6の場合、IP-IPトンネルインターフェイスを介したDADは、既存の実装でオフになります。PPPを介したIPv6の場合、IPコントロールプロトコル（IPCPV6）はリンクローカルアドレスを交渉するため、トンネル上のパパは必要ありません。モバイルノードがターゲットネットワークに移動した後、NCOAをターゲットネットワークへの物理インターフェイスに再割り当てするため、DADの手順が開始される場合があります。その場合、モバイルノードは物理インターフェイス上で楽観的なパパ[RFC4429]を使用して、ハンドオーバーの前にプロアクティブなハンドオーバートンネル内で使用されたNCOAを、ハンドオーバー後にその物理インターフェイスですぐに使用できるようにする必要があります。積極的なパパと楽観的なパパに使用されるスキームは、NCOAの取得に使用されるステートレスとステートフルのアドレスの自動構成スキームの両方に適用できます。
Address resolution involves updating the next access router's neighbor cache. We briefly describe these two operations below.
アドレス解決には、次のアクセスルーターのネイバーキャッシュを更新することが含まれます。以下のこれら2つの操作について簡単に説明します。
During the process of pre-configuration, the MAC address resolution mappings needed by the mobile node to communicate with nodes in the target network after attaching to the target network can also be known, where the communicating nodes may be the access router, authentication agent, configuration agent, or Correspondent Node. There are several possible ways of performing such proactive MAC address resolution.
事前構成の過程で、ターゲットネットワークに接続した後にターゲットネットワーク内のノードと通信するためにモバイルノードが必要とするMACアドレス解像度マッピングも既知であり、通信ノードはアクセスルーター、認証エージェントです。構成エージェント、または特派員ノード。このような積極的なMACアドレス解像度を実行する方法はいくつかあります。
o One can use an information service mechanism [802.21] to resolve the MAC addresses of the nodes. This might require each node in the target network to be involved in the information service so that the server of the information service can construct the database for proactive MAC address resolution.
o 情報サービスメカニズム[802.21]を使用して、ノードのMACアドレスを解決できます。これには、ターゲットネットワーク内の各ノードが情報サービスに関与する必要があるため、情報サービスのサーバーがプロアクティブなMACアドレス解像度のためにデータベースを構築できるようにします。
o One can extend the authentication protocol used for pre-authentication or the configuration protocol used for pre-configuration to support proactive MAC address resolution. For example, if PANA is used as the authentication protocol for pre-authentication, PANA messages may carry attribute-value pairs (AVPs) used for proactive address resolution. In this case, the PANA authentication agent in the target network may perform address resolution on behalf of the mobile node.
o 事前認証に使用される認証プロトコル、または事前構成に使用される構成プロトコルを拡張して、プロアクティブなMACアドレス解像度をサポートすることができます。たとえば、PANAが承認前の認証プロトコルとして使用される場合、PANAメッセージは、プロアクティブアドレス解像度に使用される属性値ペア（AVP）を運ぶ場合があります。この場合、ターゲットネットワークのPANA認証エージェントは、モバイルノードに代わってアドレス解像度を実行できます。
o One can also make use of DNS to map the MAC address of the specific interface associated with a specific IP address of the network element in the target network. One may define a new DNS resource record (RR) to proactively resolve the MAC addresses of the nodes in the target network. But this approach may have its own limitations, since a MAC address is a resource that is bound to an IP address, and not directly to a domain name.
o DNSを使用して、ターゲットネットワークのネットワーク要素の特定のIPアドレスに関連付けられた特定のインターフェイスのMACアドレスをマッピングすることもできます。ターゲットネットワーク内のノードのMACアドレスを積極的に解決するために、新しいDNSリソースレコード（RR）を定義できます。ただし、MACアドレスはIPアドレスにバインドされており、ドメイン名に直接接続されているリソースであるため、このアプローチには独自の制限がある場合があります。
When the mobile node attaches to the target network, it installs the proactively obtained address resolution mappings without necessarily performing address resolution queries for the nodes in the target network.
モバイルノードがターゲットネットワークに接続すると、ターゲットネットワークのノードのアドレス解像度クエリを必ずしも実行せずに、プロアクティブに取得したアドレス解像度マッピングをインストールします。
On the other hand, the nodes that reside in the target network and that are communicating with the mobile node should also update their address resolution mappings for the mobile node as soon as the mobile node attaches to the target network. The above proactive address resolution methods could also be used for those nodes to proactively resolve the MAC address of the mobile node before the mobile node attaches to the target network. However, this is not useful, since those nodes need to detect the attachment of the mobile node to the target network before adopting the proactively resolved address resolution mapping. A better approach would be integration of attachment detection and address resolution mapping update. This is based on gratuitously performing address resolution [RFC5944], [RFC3775] in which the mobile node sends an ARP Request or an ARP Reply in the case of IPv4, or a Neighbor Advertisement in the case of IPv6, immediately after the mobile node attaches to the new network, so that the nodes in the target network can quickly update the address resolution mapping for the mobile node.
一方、ターゲットネットワークに存在し、モバイルノードと通信しているノードは、モバイルノードがターゲットネットワークに接続するとすぐに、モバイルノードのアドレス解像度マッピングを更新する必要があります。上記のプロアクティブアドレス解決方法は、これらのノードにも使用されて、モバイルノードがターゲットネットワークに接続する前にモバイルノードのMACアドレスをプロアクティブに解決することもできます。ただし、これらのノードは、積極的に解決されたアドレス解像度マッピングを採用する前に、ターゲットネットワークへのモバイルノードのアタッチメントを検出する必要があるため、これは役に立ちません。より良いアプローチは、添付ファイルの検出とアドレス解像度マッピングの更新の統合です。これは、モバイルノードの場合、モバイルノードの場合にIPv4の場合のARPリクエストまたはARPの返信を送信するモバイルノードがARP要求またはARP返信を送信するアドレス解像度[RFC5944]、[RFC3775]、[RFC5944]、[RFC3775]に基づいています。ターゲットネットワーク内のノードがモバイルノードのアドレス解像度マッピングをすばやく更新できるように、新しいネットワークに向けて。
In this section, we describe some of the deployment issues related to MPA.
このセクションでは、MPAに関連する展開の問題のいくつかについて説明します。
The ping-pong effect is one of the common problems found during handover. The ping-pong effect arises when a mobile node is located at the borderline of the cell or decision point and a handover procedure is frequently executed. This results in higher call drop probability, lower connection quality, increased signaling traffic, and waste of resources. All of these affect mobility optimization. Handoff algorithms are the deciding factors for performing the handoff between the networks. Traditionally, these algorithms employ a threshold to compare the values of different metrics to decide on the handoff. These metrics include signal strength, path loss, Carrier-to-Interference Ratio (CIR), Signal-to-Interference Ratio (SIR), Bit Error Rate (BER), and power budget. In order to avoid the ping-pong effect, some additional parameters are employed by the decision algorithm, such as hysteresis margin, dwell timers, and averaging window. For a vehicle moving at a high speed, other parameters, such as the distance between the mobile node and the point of attachment, velocity of the mobile node, location of the mobile node, traffic, and bandwidth characteristics are also taken into account to reduce the ping-pong effect. More recently, there are other handoff algorithms available that help reduce the ping-pong effect in a heterogeneous network environment and that are based on techniques such as hypothesis testing, dynamic programming, and pattern recognition techniques. While it is important to devise smart handoff algorithms to reduce the ping-pong effect, it is also important to devise methods to recover from this effect.
Ping-Pong効果は、ハンドオーバー中に見られる一般的な問題の1つです。Ping-Pong効果は、モバイルノードがセルまたは決定ポイントの境界線にある場合に発生し、ハンドオーバー手順が頻繁に実行されます。これにより、コールドロップ確率が高く、接続品質の低下、シグナルトラフィックの増加、リソースの無駄になります。これらはすべて、モビリティの最適化に影響します。ハンドオフアルゴリズムは、ネットワーク間でハンドオフを実行するための決定要因です。従来、これらのアルゴリズムはしきい値を使用して、異なるメトリックの値を比較してハンドオフを決定します。これらのメトリックには、信号強度、パス損失、キャリアとインターフェンス比（CIR）、信号対干渉比（SIR）、ビットエラー率（BER）、および電力予算が含まれます。Ping-Pong効果を回避するために、ヒステリシスマージン、ドウェルタイマー、平均ウィンドウなどの決定アルゴリズムによっていくつかの追加パラメーターが採用されています。高速で移動する車両の場合、モバイルノードとアタッチメントの距離、モバイルノードの速度、モバイルノードの位置、トラフィック、帯域幅の特性などの他のパラメーターも考慮に入れて、ピンポン効果。最近では、不均一なネットワーク環境でのPing-Pong効果を減らすのに役立つ他のハンドオフアルゴリズムがあり、仮説テスト、動的プログラミング、パターン認識技術などの手法に基づいています。Ping-Pong効果を減らすには、スマートハンドオフアルゴリズムを考案することが重要ですが、この効果から回復する方法を考案することも重要です。
In the case of the MPA framework, the ping-pong effect will result in the back-and-forth movement of the mobile node between the current network and target network, and between the candidate target networks. MPA in its current form will be affected because of the number of tunnels set up between the mobile node and neighboring access routers, the number of binding updates, and associated handoff latency resulting from the ping-pong situation. The mobile node's handoff rate may also contribute to delay and packet loss. We propose a few techniques that will help reduce the probability of the ping-pong effect and propose several methods for the MPA framework so that it can recover from the packet loss resulting from the ping-pong effect.
MPAフレームワークの場合、Ping-Pong効果は、現在のネットワークとターゲットネットワーク間、および候補ターゲットネットワーク間のモバイルノードの前後の動きをもたらします。現在の形式のMPAは、モバイルノードと隣接するアクセスルーターの間に設定されたトンネルの数、バインディングアップデートの数、およびピンポンの状況に起因する関連するハンドオフレイテンシのために影響を受けます。モバイルノードのハンドオフレートは、遅延とパケットの損失にも寄与する可能性があります。Ping-Pong効果の確率を減らし、MPAフレームワークのいくつかの方法を提案するいくつかの手法を提案し、Ping-Pong効果から生じるパケット損失から回復できるようにします。
The MPA framework can take advantage of the mobile node's geo-location with respect to APs in the neighboring networks using GPS. In order to avoid the oscillation between the networks, a location-aware algorithm can be derived by using a co-relation between the user's location and cached data from the previous handover attempts. In some cases, location may not be the only indicator for a handoff decision. For example, in Manhattan-type grid networks, although a mobile node is close to an AP, it may not have enough SNR (Signal-to-Noise Ratio) to make a good connection. Thus, knowledge of the mobility pattern, dwell time in a call, and path identification will help avoid the ping-pong problem to a great extent.
MPAフレームワークは、GPSを使用して隣接ネットワークのAPに関して、モバイルノードのジオロケーションを活用できます。ネットワーク間の振動を回避するために、ユーザーの位置と以前のハンドオーバー試行からのキャッシュデータの間の共関係を使用して、位置認識アルゴリズムを導き出すことができます。場合によっては、ハンドオフ決定の唯一の指標ではない場合があります。たとえば、マンハッタン型グリッドネットワークでは、モバイルノードはAPに近いものの、適切な接続を行うのに十分なSNR（信号対雑音比）がない場合があります。したがって、モビリティパターン、コールの滞留時間、およびパス識別の知識は、ピンポンの問題を大幅に回避するのに役立ちます。
In the absence of a good handoff algorithm that can avoid the ping-pong effect, it may be required to put in place a good recovery mechanism so as to mitigate the effect of ping-pong. It may be necessary to keep the established context in the current network for a period of time, so that it can be quickly recovered when the mobile node comes back to the network where the context was last used. This context may include security association, IP address used, and tunnels established. Bicasting the data to both the previous network and the new network for a predefined period will also help the mobile node to take care of the lost packets in case the mobile node moves back and forth between the networks. The mobile node can also take certain action, after it determines that it is in a stable state with respect to a ping-pong situation.
Ping-Pong効果を回避できる優れたハンドオフアルゴリズムがない場合、Ping-Pongの効果を緩和するために、適切な回復メカニズムを導入する必要がある場合があります。現在のネットワークの確立されたコンテキストを一定期間保持する必要がある場合があり、モバイルノードがコンテキストが最後に使用されたネットワークに戻ったときに迅速に回復できるようにする必要がある場合があります。このコンテキストには、セキュリティ協会、使用されているIPアドレス、および確立されたトンネルが含まれる場合があります。事前に定義された期間の以前のネットワークと新しいネットワークの両方にデータをバイカストすると、モバイルノードがネットワーク間を行き来する場合に備えて、モバイルノードが失われたパケットの処理にも役立ちます。モバイルノードは、ピンポンの状況に関して安定した状態にあると判断した後、特定のアクションを実行することもできます。
When the MPA framework takes advantage of a combination of IKEv2 and MOBIKE, the ping-pong effect can be reduced further [MPA-MOBIKE].
MPAフレームワークがIKEV2とMobikeの組み合わせを利用すると、Ping-Pong効果をさらに減らすことができます[MPA-Mobike]。
In the case of pre-authentication with multiple target networks, it is useful to maintain the state in the authentication agent of each of the neighboring networks for a certain time period. Thus, if the mobile node does move back and forth between neighboring networks, already-maintained authentication state can be helpful. We provide some highlights on multiple security association state management below.
複数のターゲットネットワークを使用した事前認証の場合、特定の期間、各隣接ネットワークの認証エージェントに状態を維持することが有用です。したがって、モバイルノードが隣接するネットワーク間を前後に移動する場合、すでに維持されている認証状態が役立ちます。以下の複数のセキュリティ協会の状態管理に関するいくつかのハイライトを提供します。
A mobile node that has pre-authenticated with an authentication agent in a candidate target network and has an MPA-SA may need to continue to keep the MPA-SA while it continues to stay in the current network or even after it makes a handover to a network that is different from the candidate target network.
候補ターゲットネットワーク内の認証エージェントと事前に認証され、MPA-SAがあるモバイルノードは、現在のネットワークにとどまっている間、または引き渡しを続けている間、MPA-SAを維持し続ける必要がある場合があります。候補ターゲットネットワークとは異なるネットワーク。
When an MN that has been authenticated and authorized by an authentication agent in the current network makes a handover to a target network, it may want to hold the SA that has been established between the MN and the authentication agent for a certain time period so that it does not have to go through the entire authentication signaling to create an SA from scratch, in case it returns to the previous network. Such an SA being held at the authentication agent after the MN's handover to another network is considered as an MPA-SA. In this case, the authentication agent should change the fully authorized state for the MN to an unauthorized state. The unauthorized state can be changed to the fully authorized state only when the MN comes back to the network and provides proof of possession of a key associated with the MPA-SA.
現在のネットワークの認証エージェントによって認証および承認されたMNがターゲットネットワークへの引き渡しを行う場合、特定の期間にわたってMNと認証エージェントの間に確立されたSAを保持して、以前のネットワークに戻った場合に備えて、SAをゼロから作成するために認証信号全体を通過する必要はありません。このようなSAは、MNの別のネットワークへの引き渡しの後に認証エージェントに保持されています。MPA-SAと見なされます。この場合、認証エージェントは、MNの完全に認可された状態を許可されていない状態に変更する必要があります。許可されていない状態は、MNがネットワークに戻ってMPA-SAに関連するキーの所持の証明を提供する場合にのみ、完全に認可された状態に変更できます。
While an MPA-SA is being held at an authentication agent, the MN will need to keep updating the authentication agent when an IP address of the MN changes due to a handover, to re-establish the new SA.
MPA-SAは認証エージェントに保持されていますが、MNは、新しいSAを再確立するために、MNのIPアドレスが引き渡しにより変更されたときに認証エージェントを更新し続ける必要があります。
In the pre-configuration phase, it is also possible to pre-allocate QoS resources that may be used by the mobile node not only after handover but also before handover. When pre-allocated QoS resources are used before handover, they are used for application traffic carried over a proactive handover tunnel.
事前構成段階では、ハンドオーバーだけでなくハンドオーバー前にもモバイルノードで使用できるQoSリソースを事前に割り当てることもできます。事前に割り当てられたQoSリソースが引き渡される前に使用される場合、それらはプロアクティブなハンドオーバートンネルに運ばれるアプリケーショントラフィックに使用されます。
It is possible that QoS resources are pre-allocated in an end-to-end fashion. One method to achieve this proactive end-to-end QoS reservation is to execute the NSIS Signaling Layer Protocol (NSLP) [RFC5974] or the Resource Reservation Protocol (RSVP) [RFC2205] over a proactive handover tunnel where pre-authentication can be used for bootstrapping a security association for the proactive handover tunnel to protect the QoS signaling. In this case, QoS resources are pre-allocated on the path between the Correspondent Node and a target access router and can be used continuously before and after handover. On the other hand, duplicate pre-allocation of QoS resources between the target access router and the mobile node is necessary when using pre-allocated QoS resources before handover, due to differences in paths between the target access router and the mobile node before and after handover. QoS resources to be used for the path between the target access router and the mobile node after handover may be pre-allocated by extending NSLP to work for off-path signaling (Note: this path can be viewed as off-path before handover) or by media-specific QoS signaling at layer 2.
QoSリソースがエンドツーエンドの方法で事前にアロークされる可能性があります。この積極的なエンドツーエンドのQoS予約を達成する1つの方法は、NSISシグナリングレイヤープロトコル（NSLP）[RFC5974]またはリソース予約プロトコル（RSVP）[RFC2205]を実行することです。QOSシグナルを保護するためのプロアクティブハンドオーバートンネルのセキュリティ協会をブートストラップするため。この場合、QoSリソースは、特派員ノードとターゲットアクセスルーターの間のパスで事前に割り当てられ、ハンドオーバーの前後に連続的に使用できます。一方、ターゲットアクセスルーターとターゲットアクセスルーターとモバイルノードの前後のモバイルノードの違いが違いにより、ハンドオーバー前に事前に割り当てられたQoSリソースを使用する場合、ターゲットアクセスルーターとモバイルノードの間のQoSリソースの重複した事前配分が必要です。引き渡す。ターゲットアクセスルーターとハンドオーバー後のモバイルノードの間のパスに使用するQoSリソースは、NSLPを拡張してオフパスシグナリングで動作することにより事前にアロークできます（注：このパスは、ハンドオーバー前にオフパスと見なすことができます）またはレイヤー2でのメディア固有のQoSシグナル伝達による。
In the case of multiple CTNs, establishing multiple tunnels with the neighboring target networks provides some additional benefits. But it contributes to some resource utilization issues as well. A pre-authentication process with multiple candidate target networks can happen in several ways.
複数のCTNSの場合、隣接するターゲットネットワークで複数のトンネルを確立するには、いくつかの追加の利点が提供されます。しかし、それはいくつかのリソース利用の問題にも貢献しています。複数の候補ターゲットネットワークを使用した事前認証プロセスは、いくつかの方法で発生する可能性があります。
The very basic scheme involves authenticating the mobile node with the multiple authentication agents in the neighboring networks, but actual pre-configuration and binding update take place only after layer 2 movement to a specific network is complete.
非常に基本的なスキームでは、隣接するネットワーク内の複数の認証エージェントを使用してモバイルノードを認証することが含まれますが、実際の事前構成とバインディングの更新は、特定のネットワークへのレイヤー2の動きが完了した後にのみ行われます。
Similarly, in addition to pre-authentication, the mobile node can also complete the pre-configuration while in the previous network, but can postpone the binding update until after the mobile node has moved. Like the previous case, in this case the mobile node also does not need to set up the pre-configured tunnels. While the pre-authentication process and part of the pre-configuration process are taken care of before the mobile node has moved to the new network, the binding update is actually done after the mobile node has moved.
同様に、事前認証に加えて、モバイルノードは前のネットワークで事前構成を完了することもできますが、モバイルノードが移動するまでバインディングアップデートを延期できます。前のケースと同様に、この場合、モバイルノードも事前に構成されたトンネルをセットアップする必要はありません。モバイルノードが新しいネットワークに移動する前に、承認前のプロセスと事前構成プロセスの一部が処理されますが、モバイルノードが移動した後、バインディングアップデートは実際に行われます。
The third type of multiple pre-authentication involves all the three steps while the mobile node is in the previous networks, such as authentication, configuration, and binding update. But, this specific process utilizes the highest amount of resources. Some of the resources that get used during this process are as follows:
3番目のタイプの複数の事前認証には、モバイルノードが認証、構成、バインディングの更新などの以前のネットワークにある間、3つのステップすべてが含まれます。しかし、この特定のプロセスは、最高のリソースを利用しています。このプロセス中に使用されるリソースの一部は次のとおりです。
(1) Additional signaling for pre-authentication in the neighboring networks
(1) 隣接するネットワークでの事前認証のための追加のシグナル
(2) Holding the IP address of the neighboring networks in the mobile node's cache for a certain amount of time. Additional processing in the mobile node is needed for storing these IP addresses. In addition, this caching of addresses also uses up the temporary IP addresses from the neighboring routers.
(2) 隣接するネットワークのIPアドレスをモバイルノードのキャッシュに保持します。これらのIPアドレスを保存するには、モバイルノードの追加処理が必要です。さらに、このアドレスのキャッシングは、隣接するルーターからの一時的なIPアドレスも使用します。
(3) There is an additional cost associated with setting up additional transient tunnels with the target routers in the neighboring networks and the mobile node.
(3) 隣接するネットワークとモバイルノードにターゲットルーターを備えた追加の過渡トンネルのセットアップに関連する追加コストがあります。
(4) In the case of a binding update with multiple IP addresses obtained from the neighboring networks, multiple transient streams flow between the CN and mobile node using these transient tunnels.
(4) 隣接するネットワークから取得された複数のIPアドレスを使用したバインディングアップデートの場合、これらの過渡トンネルを使用して、CNとモバイルノードの間に複数の一時的なストリームが流れます。
However, there are pros and cons related to sending the binding update after the handover. If the binding update is sent after the mobile node has moved to the new network, this will contribute to the delay if the CH or HA is far from the MN. Multiple binding updates can be taken care of in many different ways. We describe a few of these update mechanisms below.
ただし、ハンドオーバー後のバインディングアップデートの送信に関連する長所と短所があります。モバイルノードが新しいネットワークに移動した後にバインディングアップデートが送信された場合、CHまたはHAがMNから遠く離れている場合、これは遅延に寄与します。複数のバインディングアップデートは、さまざまな方法で処理できます。以下のこれらの更新メカニズムのいくつかについて説明します。
When only pre-authentication and pre-configuration are done ahead of time with multiple networks, the mobile node sends one binding update to the CN. In this case, it is important to find out when to send the binding update after the layer 2 handoff.
複数のネットワークを使用して事前に事前構成と事前構成のみが事前に行われる場合、モバイルノードはCNに1つのバインディングアップデートを送信します。この場合、レイヤー2ハンドオフの後にバインディングアップデートをいつ送信するかを調べることが重要です。
In case a binding update with multiple contact addresses is sent, multiple media streams stem out of the CN, using the transient tunnels. But in that case, one needs to send another binding update after the handover, with the contact address set to the new address (only one address) where the mobile node has moved. This way, the mobile node stops sending media to other neighboring networks where the mobile node did not move.
複数の連絡先アドレスを使用したバインディングアップデートが送信された場合、過渡トンネルを使用して、複数のメディアストリームがCNから登場します。ただし、その場合、ハンドオーバー後に別のバインディングアップデートを送信する必要があり、モバイルノードが移動した新しいアドレス（1つのアドレスのみ）に連絡先アドレスを設定する必要があります。これにより、モバイルノードは、モバイルノードが移動しなかった他の隣接ネットワークにメディアの送信を停止します。
The following is an illustration of this specific case that takes care of multiple binding streams, when the mobile node moves only to a specific network, but sends multiple binding updates in the previous network. The MN sends a binding update to the CH with multiple contact addresses, such as c1, c2, and c3, that were obtained from three neighboring networks. This allows the CN to send transient multiple streams to the mobile node over the pre-established tunnels. After the mobile node moves to the actual network, it sends another binding update to the CN with the care-of address of the mobile node in the network where the mobile node has moved. One issue with multiple streams is consumption of extra bandwidth for a small period of time.
以下は、モバイルノードが特定のネットワークにのみ移動するが、以前のネットワークで複数のバインディングアップデートを送信する場合、複数のバインディングストリームを処理するこの特定のケースの図です。MNは、3つの隣接ネットワークから取得したC1、C2、C3などの複数の連絡先アドレスを持つCHにバインディングアップデートを送信します。これにより、CNは、事前に確立されたトンネルを介してモバイルノードに一時的な複数のストリームを送信できます。モバイルノードが実際のネットワークに移動すると、モバイルノードが移動したネットワーク内のモバイルノードのケアを使用して、CNに別のバインディングアップデートを送信します。複数のストリームの問題の1つは、少数の期間の余分な帯域幅を消費することです。
Alternatively, one can apply the buffering technique at the target access router or at the Home Agent. Transient data can be forwarded to the mobile node after it has moved. Forwarding of data can be triggered by the mobile node either as part of Mobile IP registration or as a separate buffering protocol.
または、ターゲットアクセスルーターまたはホームエージェントにバッファリング技術を適用できます。一時的なデータは、移動した後にモバイルノードに転送できます。データの転送は、モバイルIP登録の一部として、または別のバッファリングプロトコルとしてモバイルノードによってトリガーできます。
In this section, we present some of the results from MPA implementation when applied to different handover scenarios. We present the summary of results from our experiments using MPA techniques for two types of handovers: i) intra-technology and intra-domain, and ii) inter-technology and inter-domain. We also present the results of how the MPA can bootstrap layer 2 security for both roaming and non-roaming cases. Detailed procedures and results are explained in [MOBIQUIT07] and [SPRINGER07].
このセクションでは、さまざまなハンドオーバーシナリオに適用された場合、MPA実装の結果の一部を提示します。2種類の拳オーバーにMPA技術を使用した実験の結果の要約を示します：i）テクノロジー内および領域内、およびii）技術間およびドメイン間。また、MPAがローミングケースと非ローミングケースの両方のセキュリティをブートストラップ2レイヤーにできる方法の結果を示します。詳細な手順と結果は、[mobiquit07]および[springer07]で説明されています。
The results for MIPv6 and SIP mobility involving intra-domain mobility are shown in Figures 6 and 7, respectively.
ドメイン内移動度を含むMIPV6およびSIPモビリティの結果を、それぞれ図6と7に示します。
Buffering Buffering Buffering Buffering
(disabled) (enabled) (disabled) (enabled)
& RO & RO & RO & RO
(disabled) (disabled) (enabled) (enabled)
-------------------------------------------------------------------
L2 handoff (ms) 4.00 4.33 4.00 4.00
L3 handoff (ms) 1.00 1.00 1.00 1.00
L3ハンドオフ（MS）1.00 1.00 1.00 1.00
Avg. packet loss 1.33 0 0.66 0
Avg. inter-packet 16.00 16.00 16.00 16.00 arrival interval (ms)
平均。インターパケット16.00 16.00 16.00 16.00到着間隔（MS）
Avg. inter-packet n/a 45.33 n/a 66.60 arrival time during handover (ms)
平均。インターパケットN/A 45.33 N/A 66.60ハンドオーバー中の到着時間（MS）
Avg. packet jitter n/a 29.33 n/a 50.60 (ms)
平均。パケットジッターN/A 29.33 N/A 50.60（MS）
Buffering Period n/a 50.00 n/a 50.00 (ms)
バッファリング期間n/a 50.00 n/a 50.00（ms）
Buffered Packets n/a 2.00 n/a 3.00
バッファーパケットn/a 2.00 n/a 3.00
RO = Router Optimization
Figure 6: Mobile IPv6 with MPA Results
図6：MPAの結果を伴うモバイルIPv6
Buffering Buffering
disabled enabled
-----------------------------------------------
L2 handoff (ms) 4.00 5.00
L3 handoff (ms) 1.00 1.00
L3ハンドオフ（MS）1.00 1.00
Avg. packet loss 1.50 0
Avg. inter-packet 16.00 16.00 arrival interval (ms)
平均。インターパケット16.00 16.00到着間隔（MS）
Avg. inter-packet n/a 29.00 arrival time during handover (ms)
平均。インターパケットN/A 29.00ハンドオーバー中の到着時間（MS）
Avg. packet jitter n/a 13.00 (ms)
平均。パケットジッターn/a 13.00（ms）
Buffering Period n/a 20.00
(ms)
Buffered Packets n/a 3.00
Figure 7: SIP Mobility with MPA Results
図7：MPAの結果を伴うSIPモビリティ
For all measurements, we did not experience any performance degradation during handover in terms of the audio quality of the voice traffic.
すべての測定について、音声トラフィックのオーディオ品質に関して、ハンドオーバー中にパフォーマンスの劣化は発生しませんでした。
With the use of buffering during handover, packet loss during the actual L2 and L3 handover is eliminated with appropriate and reasonable settings of the buffering period for both MIP6 and SIP mobility. In the case of MIP6, there is not a significant difference in results with and without route optimization. It should be noted that results with more samples would be necessary for a more detailed analysis.
ハンドオーバー中のバッファリングの使用により、実際のL2およびL3のハンドオーバー中のパケット損失は、MIP6とSIPモビリティの両方でバッファリング期間の適切かつ合理的な設定で排除されます。MIP6の場合、ルートの最適化の有無にかかわらず、結果に有意な違いはありません。より詳細な分析には、より多くのサンプルを使用した結果が必要であることに注意する必要があります。
In the case of non-MPA-assisted handover, handover delay and associated packet loss occur from the moment the link-layer handover procedure begins, up to successful processing of the binding update. During this process, IP address acquisitions via DHCP incur the longest delay. This is due to the detection of duplicate IP addresses in the network before the DHCP request completes. The binding update exchange also experiences a long delay if the CN is too far from the MN. As a result, the non-MPA-assisted handover took an average of 4 seconds to complete, with an approximate packet loss of about 200 packets. The measurement is based on the same traffic rate and traffic source as the MPA-assisted handover.
非MPAアシストハンドオーバーの場合、リンク層のハンドオーバー手順が始まる瞬間から、ハンドオーバー遅延と関連するパケット損失が発生し、バインディングアップデートの処理が成功します。このプロセス中に、DHCPを介したIPアドレスの取得は最長の遅延が発生します。これは、DHCP要求が完了する前にネットワーク内の重複IPアドレスの検出によるものです。また、CNがMNから遠すぎると、バインディングアップデート交換は長い遅延が発生します。その結果、MPA以外のハンドオーバーは、約200パケットのおおよそのパケット損失で、平均4秒かかりました。測定は、MPAアシストハンドオーバーと同じトラフィックレートとトラフィックソースに基づいています。
Handoff involving heterogeneous access can take place in many different ways. We limit the experiment to two interfaces, and therefore results in several possible setup scenarios, depending upon the activity of the second interface. In one scenario, the second interface comes up when the link to the first interface goes down. This is a reactive scenario and usually gives rise to undesirable packet loss and handoff delay. In a second scenario, the second interface is being prepared while the mobile node still communicates using the old interface. Preparation of the second interface should include setup of all the required state and security associations (e.g., PPP state, the Link Control Protocol (LCP), the Challenge Handshake Authentication Protocol (CHAP)). If such a lengthy process is established ahead of time, it reduces the time taken for the secondary interface to be attached to the network. After preparation, the mobile node decides to use the second interface as the active interface. This results in less packet loss, as it uses make-before-break techniques. This is a proactive scenario and can have two "flavors". The first is where both interfaces are up; the second is when only the old interface is up and the prepared interface is brought up only when handoff is about to occur. This scenario may be beneficial from a battery management standpoint. Devices that operate two interfaces simultaneously can rapidly deplete their batteries. However, by activating the second interface only after an appropriate network has been selected, the client may utilize battery power effectively.
不均一なアクセスを含むハンドオフは、さまざまな方法で行われます。実験を2つのインターフェイスに制限するため、2番目のインターフェイスのアクティビティに応じて、いくつかの可能なセットアップシナリオが得られます。1つのシナリオでは、最初のインターフェイスへのリンクがダウンすると、2番目のインターフェイスが表示されます。これはリアクティブなシナリオであり、通常、望ましくないパケットの損失とハンドオフ遅延を生じさせます。2番目のシナリオでは、2番目のインターフェイスが準備され、モバイルノードは古いインターフェイスを使用して通信します。2番目のインターフェイスの準備には、必要なすべての状態およびセキュリティ協会のセットアップ（PPP状態、リンク制御プロトコル（LCP）、チャレンジハンドシェイク認証プロトコル（CHAP））のセットアップを含める必要があります。このような長いプロセスが事前に確立されている場合、セカンダリインターフェイスがネットワークに添付されるまでの時間が短縮されます。準備後、モバイルノードは2番目のインターフェイスをアクティブインターフェイスとして使用することを決定します。これにより、ブレイク前のテクニックを使用するため、パケットの損失が少なくなります。これは積極的なシナリオであり、2つの「フレーバー」を持つことができます。1つ目は、両方のインターフェイスが上昇する場所です。2つ目は、古いインターフェイスのみがアップし、準備インターフェイスがハンドオフが発生しようとしているときにのみ育てられる場合です。このシナリオは、バッテリー管理の観点から有益な場合があります。2つのインターフェイスを同時に操作するデバイスは、バッテリーを急速に枯渇させる可能性があります。ただし、適切なネットワークが選択された後にのみ2番目のインターフェイスをアクティブにすることにより、クライアントはバッテリー電源を効果的に利用することができます。
As compared to non-optimized handover that may result in a delay of up to 18 sec and loss of 1000 or more packets during the handover from the wireless LAN (WLAN) to CDMA, we observed 0 packet loss and a 50-ms handoff delay between the last pre-handoff packet and the first in-handoff packet. This handoff delay includes the time due to link down detection and time needed to delete the tunnel after the mobile node has moved. However, we observed about 10 duplicate packets because of the copy-and-forward mechanism at the access routers. But these duplicate packets are usually handled easily by the upper-layer protocols.
ワイヤレスLAN（WLAN）からCDMAへのハンドオーバー中に最大18秒の遅延と1000以上のパケットの損失をもたらす可能性のある最適化されていないハンドオーバーと比較して、パケット損失0と50 msのハンドオフ遅延が観察されました最後のプリハンドオフパケットと最初のハンドオフパケットの間。このハンドオフの遅延には、モバイルノードが移動した後にトンネルを削除するために必要なリンクダウン検出と時間が必要な時間が含まれます。ただし、アクセスルーターでのコピーアンドフォワードメカニズムのため、約10個の重複パケットを観察しました。ただし、これらの重複パケットは通常、上層層プロトコルによって簡単に処理されます。
In this section, we discuss the results obtained from MPA-assisted layer 2 pre-authentication and compare these with EAP authentication and IEEE 802.11i's pre-authentication techniques. Figure 8 shows the experimental testbed where we have conducted the MPA-assisted pre-authentication experiment for bootstrapping layer 2 security as explained in Section 7. By pre-authenticating and pre-configuring the link, the security association procedure during handoff reduces to a 4-way handshake only. Then the MN moves to the AP and, after association, runs a 4-way handshake by using the PSKap (Pre-shared Key at AP) generated during PANA pre-authentication. At this point, the handoff is complete. Details of this experimental testbed can be found in [MOBIQUIT07].
このセクションでは、MPAアシストレイヤー2の事前認証から得られた結果について説明し、これらをEAP認証とIEEE 802.11iの認証前手法と比較します。図8は、セクション7で説明されているように、ブートストラップレイヤー2セキュリティのMPA支援前の認証実験を実施した実験テストベッドを示しています。 - ウェイハンドシェイクのみ。次に、MNはAPに移動し、関連性の後、パナ前の免除中に生成されたPSKAP（APで事前共有キー）を使用して4方向の握手を実行します。この時点で、ハンドオフが完了しました。この実験テストベッドの詳細は、[mobiquit07]にあります。
+----------------------------+-----------+ +-------------+----------+
| | | |
| Home Domain +-------++ | | |
| | | | | |
| |AAAHome | | | |
| + | | | |
| +-----+--+ | | |
| | | | Network B |
| Network A | | | |
| /----\ | | /---\ |
| /nAR \ | | / \ |
| | PAA |--------+-+----------+ pAR | |
| \ / | | \ / |
| \----/ | | \-+-/ |
| | | | | |
| +-------------------| | | | |
| | IEEE 802.11i| | | | |
| +------+ +------+ | | +---+--+ |
| | | | | | | | | |
| |AP2 | |AP1 | | | |AP0 | |
| +------+ +------+ | | +------+ |
| +------+ +-----+ | | +-----+ |
| | | | | | | | | |
| |MN +----------->|MN |<+------------- |MN | |
| +------+ +-----+ | | ++----+ |
|----------------------------------------+ +------------+-----------+
Figure 8: Experimental Testbed for MPA-Assisted L2 Pre-Authentication (Non-Roaming)
図8：MPAアシストL2の事前認証（非ローミング）の実験テストベッド
+-----------------------------+
| +--------+ |
| | | |
| | AAAH + |
| | | |
| ++-------+ |
| | |
| | Home AAA Domain |
| | |
+-------+---------------------+
|
|
|
RADIUS/ |
Diameter |
|
|
+----------------------------+-----------+ +-------------+----------+
| | | | |
| Roaming +-------++ | | |
| AAA Domain A | | | | |
| | AAAV | | | |
| + | | | |
| Network A +-----+--+ | | Network B |
| | | | |
| | | | |
| /----\ | | /---\ |
| /nAR \ | | / \ |
| | PAA |--------+-+----------+ pAR | |
| \ / | | \ / |
| \----/ | | \-+-/ |
| | | | | |
| +-------------------| | | | |
| | IEEE 802.11i| | | | |
| +------+ +------+ | | +---+--+ |
| | | | | | | | | |
| |AP2 | |AP1 | | | |AP0 | |
| +------+ +------+ | | +------+ |
| +------+ +-----+ | | +-----+ |
| | | | | | | | | |
| |MN +----------->|MN |<---------------| MN | |
| +------+ +-----+ | | ++----+ |
-----------------------------------------+ +------------+-----------+
Figure 9: Experimental Testbed for MPA-Assisted L2 Pre-Authentication (Roaming)
図9：MPAアシストL2の実験テストベッド（ローミング）（ローミング）
We have experimented with three types of movement scenarios involving both non-roaming and roaming cases, using the testbeds shown in Figures 8 and 9, respectively. In the roaming case, the MN is visiting in a domain different than its home domain. Consequently, the MN needs to contact the AAA server in the home domain (AAAH) from its new domain. For the non-roaming case, we assume the MN is moving within its home domain, and only the local AAA server (AAAHome), which is the home AAA server for the mobile node, is contacted.
それぞれ図8と9に示すテストベッドを使用して、非ローミングとローミングの両方のケースを含む3種類の動きシナリオを実験しました。ローミングの場合、MNはホームドメインとは異なるドメインで訪問しています。その結果、MNは新しいドメインからホームドメイン（AAAH）のAAAサーバーに連絡する必要があります。非ローミングケースの場合、MNがホームドメイン内に移動していると仮定し、モバイルノードのホームAAAサーバーであるローカルAAAサーバー（AAAHOME）のみが連絡されます。
The first scenario does not involve any pre-authentication. The MN is initially connected to AP0 and moves to AP1. Because neither network-layer authentication nor IEEE 802.11i pre-authentication is used, the MN needs to engage in a full EAP authentication with AP1 to gain access to the network after the move (post-authentication). This experiment shows the effect of the absence of any kind of pre-authentication.
最初のシナリオには、事前認証は含まれません。MNは最初にAP0に接続され、AP1に移動します。ネットワーク層認証もIEEE 802.11iの事前認証も使用されていないため、MNはAP1で完全なEAP認証に従事して、移動後にネットワークにアクセスする必要があります（承認後）。この実験は、あらゆる種類の免除がないことの効果を示しています。
The second scenario involves 802.11i pre-authentication and involves movement between AP1 and AP2. In this scenario, the MN is initially connected to AP2, and starts IEEE 802.11i pre-authentication with AP1. This is an ideal scenario to compare the values obtained from 802.11i pre-authentication with that of network-layer assisted pre-authentication. Both scenarios use RADIUS as the AAA protocol (APs implement a RADIUS client). The third scenario takes advantage of network-layer assisted link-layer pre-authentication. It involves movement between two APs (e.g., between AP0 and AP1) that belong to two different subnets where 802.11i pre-authentication is not possible. Here, Diameter is used as the AAA protocol (PAA implements a Diameter client).
2番目のシナリオには、802.11iの事前認証が含まれ、AP1とAP2の間の動きが含まれます。このシナリオでは、MNは最初にAP2に接続され、IEEE 802.11iがAP1を使用して開始します。これは、802.11iから得られた値とネットワークレイヤーの支援前受託の値と取得した値を比較するための理想的なシナリオです。どちらのシナリオもAAAプロトコルとして半径を使用します（APSはRADIUSクライアントを実装します）。3番目のシナリオでは、ネットワーク層支援リンク層の免除を利用します。802.11iの事前認証が不可能な2つの異なるサブネットに属する2つのAP（例：AP0とAP1の間）間の移動が含まれます。ここでは、直径がAAAプロトコルとして使用されます（PAAは直径クライアントを実装します）。
In the third movement scenario, the MN is initially connected to AP0. The MN starts PANA pre-authentication with the PAA, which is co-located on the AR in the new candidate target network (nAR in network A) from the current associated network (network B). After authentication, the PAA proactively installs two keys, PSKap1 and PSKap2, in AP1 and AP2, respectively. By doing the key installations proactively, the PAA preempts the process of communicating with the AAA server for the keys after the mobile node moves to the new network. Finally, because PSKap1 is already installed, AP1 immediately starts the 4-way handshake. We have used measurement tools such as ethereal and kismet to analyze the measurements for the 4-way handshake and PANA authentication. These measurements reflect different operations involved during network-layer pre-authentication.
3番目の動きのシナリオでは、MNは最初にAP0に接続されています。MNは、現在の関連ネットワーク（ネットワークB）から新しい候補ターゲットネットワーク（ネットワークAのNAR）のARで共同住宅されているPAAとのパナの事前認証を開始します。認証後、PAAはそれぞれAP1とAP2に2つのキー、PSKAP1とPSKAP2の2つのキーを積極的にインストールします。キーインストールを積極的に実行することにより、PAAは、モバイルノードが新しいネットワークに移動した後、キーのAAAサーバーと通信するプロセスを先取りします。最後に、PSKAP1はすでにインストールされているため、AP1はすぐに4ウェイハンドシェイクを開始します。EtherealやKismetなどの測定ツールを使用して、4ウェイハンドシェイクとパナ認証の測定値を分析しました。これらの測定値は、ネットワーク層の事前認証中に関与するさまざまな操作を反映しています。
In our experiment, as part of the discovery phase, we assume that the MN is able to retrieve the PAA's IP address and all required information about AP1 and AP2 (e.g., channel, security-related parameters, etc.) at some point before the handover. This avoids the scanning during link-layer handoff. We have applied this assumption to all three scenarios. Because our focus is on reducing the time spent on the authentication phase during handoff, we do not discuss the details of how we avoid the scanning.
私たちの実験では、発見フェーズの一部として、MNはPAAのIPアドレスと、AP1およびAP2に関するすべての必要な情報（たとえば、チャネル、セキュリティ関連のパラメーターなど）を取得できると想定しています。引き渡す。これにより、リンク層のハンドオフ中のスキャンが回避されます。この仮定を3つのシナリオすべてに適用しました。私たちの焦点は、ハンドオフ中に認証フェーズに費やされた時間を短縮することにあるので、スキャンを避ける方法の詳細については説明しません。
=====================================================================
Types |802.11i | 802.11i | MPA-assisted
|Post- | Pre- | Layer 2
|authentication | authentication | Pre-authentication
=====================================================================
Operation| Non- | Roaming | Non- | Roaming |Non- | Roaming|
| Roaming | | Roaming | |Roaming| |
===================================================================
Tauth | 61 ms | 599 ms | 99 ms | 638 ms | 177 ms| 831 ms |
-------------------------------------------------------------------
Tconf | -- | -- | -- | -- | 16 ms | 17ms |
-------------------------------------------------------------------
Tassoc+ | | | | | | |
4way | 18 ms | 17 ms | 16 ms | 17 ms | 16 ms | 17 ms |
------------------------------------------------------------------|
Total | 79 ms | 616 ms | 115 ms | 655 ms | 208 ms| 865 ms |
------------------------------------------------------------------|
Time | | | | | | |
affecting| 79 ms | 616 ms | 16 ms | 17 ms | 15 ms | 17 ms |
handover | | | | | | |
------------------------------------------------------------------|
Figure 10: Results of MPA-Assisted Layer 2 Pre- and Post-Authentication
図10：MPAアシストレイヤー2の結果の結果および告発後
Figure 10 shows the timing (rounded off to the most significant number) associated with some of the handoff operations we have measured in the testbed. We describe each of the timing parameters below.
図10は、テストベッドで測定したハンドオフ操作の一部に関連付けられたタイミング（最も重要な数に丸められている）を示しています。以下の各タイミングパラメーターについて説明します。
"Tauth" refers to the execution of EAP-Transport Layer Security (TLS) authentication. This time does not distinguish whether this authentication was performed during pre-authentication or a typical post-authentication.
「Tauth」とは、EAP-Transport Layer Security（TLS）認証の実行を指します。今回は、この認証が承認前に実行されたのか、それとも典型的な認証後の告発後に実行されたのかを区別しません。
"Tconf" refers to the time spent during PSK generation and installation after EAP authentication is complete. When network-layer pre-authentication is not used, this time is not considered.
「TCONF」とは、EAP認証が完了した後のPSKの生成中に費やされた時間とインストールを指します。ネットワーク層の事前認証が使用されない場合、今回は考慮されません。
"Tassoc+4way" refers to the time dedicated to the completion of the association and the 4-way handshake with the target AP after the handoff.
「Tassoc 4way」とは、協会の完成と、ハンドオフ後のターゲットAPとの4ウェイハンドシェイクに専念する時間を指します。
The first two columns in the figure show the results for non-roaming and roaming cases, respectively, when no pre-authentication is used at all. The second two columns depict the same cases when IEEE 802.11i pre-authentication is used. The last two columns show when we used network-layer-assisted layer 2 pre-authentication. When pre-authentication is used, only the factor Tassoc+4way affects the handoff time. When no pre-authentication is used, the time affecting the handoff includes Tauth (the complete EAP-TLS authentication) plus Tassoc+4way.
図の最初の2つの列は、事前認証がまったく使用されない場合、それぞれ非ローミングおよびローミングケースの結果を示しています。2番目の列は、IEEE 802.11iの事前認証が使用されている場合と同じケースを示しています。最後の2つの列は、ネットワークレイヤー支援レイヤー2の前認証を使用したときに示しています。事前認証を使用すると、Tassoc 4way因子のみがハンドオフ時間に影響します。事前認証が使用されない場合、ハンドオフに影響を与える時間には、Tauth（完全なEAP-TLS認証）とTassoc 4wayが含まれます。
That is precisely the time affecting the handoff in the case where the MN moves from AP0 to AP1 in the absence of pre-authentication. As it is seen, these delays are not suitable for real-time applications. Indeed, for the non-roaming case, we obtained a ~80-ms delay for re-establishing the connection with target AP1. It takes about 600 ms to complete the handoff when the MN moves to a visited domain and the home AAA server is located far away. However, network-layer pre-authentication is only affected by Tassoc+4way (~17 ms) involving any kind of handoff authentication. As is evident, IEEE 802.11i pre-authentication provides a comparable benefit (~16 ms) in terms of handoff but is limited to cases when APs are in the same Distribution System (DS). Additionally, network-layer pre-authentication leverages a single EAP authentication to bootstrap security in several target APs by allowing the MN to move among APs under the same PAA without running EAP and consequently without contacting the AAA server. In this sense, it extends IEEE 802.11r advantages over IEEE 802.11i by allowing inter-subnet and inter-domain and even inter-technology handoffs.
これは、事前認証がない場合にMNがAP0からAP1に移動する場合のハンドオフに影響を与える時間です。ご覧のとおり、これらの遅延はリアルタイムアプリケーションには適していません。実際、非ローミングの場合、ターゲットAP1との接続を再確立するために、約80 msの遅延を取得しました。MNが訪問ドメインに移動し、Home AAAサーバーが遠くにある場合、ハンドオフを完了するには約600ミリ秒かかります。ただし、ネットワーク層の事前認証は、あらゆる種類のハンドオフ認証を含むTassoc 4way（〜17 ms）のみの影響を受けます。明らかなように、IEEE 802.11i事前認証は、ハンドオフの観点から同等の利点（〜16ミリ秒）を提供しますが、APが同じ配電システム（DS）にある場合に限定されます。さらに、ネットワーク層の事前認証は、MNがEAPを実行せずにAAAサーバーに連絡せずに同じPAAの下でAPを移動できるようにすることにより、いくつかのターゲットAPのブートストラップセキュリティに単一のEAP認証を活用します。この意味で、IEEE 802.11Rの利点は、IEEE 802.11iよりも、領域間およびドメイン間、さらにはテクノロジー間のハンドオフを許可することで拡張します。
In this section, we provide some guidelines for the roaming clients that use pre-authentication mechanisms to reduce the handoff delay. These guidelines can help determine the extent of the pre-authentication operation that is needed based on a specific type of movement of the client. IEEE 802.11i and 802.11r take advantage of the pre-authentication mechanism at layer 2. Thus, many of the guidelines observed for 802.11i-based pre-authentication and 802.11r-based fast roaming could also be applicable to the clients that use MPA-based pre-authentication techniques. However, since MPA operations are not limited to a specific subnet and involve inter-subnet and inter-domain handover, the guidelines need to take into account other factors, such as movement pattern of the mobile node, cell size, etc.
このセクションでは、ハンドオフ遅延を減らすために事前認証メカニズムを使用するローミングクライアントのガイドラインを提供します。これらのガイドラインは、クライアントの特定のタイプの動きに基づいて必要な事前認証操作の程度を判断するのに役立ちます。IEEE 802.11iおよび802.11rは、レイヤー2での承認前メカニズムを活用しています。したがって、802.11iベースの前発作と802.11Rベースの高速ローミングで観察されたガイドラインの多くは、MPAを使用するクライアントにも適用できます。 - ベースの前発育技術。ただし、MPAの操作は特定のサブネットに限定されず、サブネット間およびドメイン間のハンドオーバーを含むため、ガイドラインでは、モバイルノード、セルサイズなどの移動パターンなど、他の要因を考慮する必要があります。
The time needed to complete the pre-authentication mechanism is an important parameter, since the mobile node needs to determine how much ahead of time the mobile node needs to start the pre-authentication process so that it can finish the desired operations before the handover to the target network starts. The pre-authentication time will vary, depending upon the speed of the mobile node (e.g., pedestrian vs. vehicular) and cell sizes (e.g., WiFi, Cellular). Cell residence time is defined as the average time the mobile node stays in the cell before the next handoff takes place. Cell residence time is dependent upon the coverage area and velocity of the mobile node. Thus, cell residence time is an important factor in determining the desirable pre-authentication time that a mobile node should consider.
モバイルノードは、ハンドオーバーの前に目的の操作を終了できるようにモバイルノードが事前に事前に必要なものを決定する必要があるため、承認前メカニズムを完了するために必要な時間は重要なパラメーターです。ターゲットネットワークが開始されます。免除前の時間は、モバイルノード（たとえば、歩行者対車両）とセルサイズ（wifi、細胞）の速度によって異なります。セルの滞留時間は、次のハンドオフが行われる前に、モバイルノードがセルにとどまる平均時間として定義されます。セルの滞留時間は、カバレッジエリアとモバイルノードの速度に依存します。したがって、セルの滞留時間は、モバイルノードが考慮すべき望ましい事前認証時間を決定する重要な要因です。
Since the pre-authentication operation involves six steps as described in Section 6.3 and each step takes some discrete amount of time, only part of these sub-operations may be completed before handoff, depending upon the available delay budget.
セクション6.3で説明されているように6つのステップが必要であり、各ステップには個別の時間がかかるため、利用可能な遅延予算に応じて、これらのサブ操作の一部のみがハンドオフ前に完了することができます。
For example, a mobile node could complete only network discovery and the network-layer authentication process before the handoff and postpone the rest of the operations until after the handover is complete. On the other hand, if it is a slow-moving vehicle and the adjacent cells are sparsely spaced, a mobile node could complete all the desired MPA-related operations. Finishing all the MPA-related operations ahead of time reduces the handoff delay but adds other constraints, such as cell residence time.
たとえば、モバイルノードは、ハンドオフの前にネットワークの発見とネットワーク層認証プロセスのみを完了し、ハンドオーバーが完了するまで残りの操作を延期することができます。一方、動きが遅い車両であり、隣接するセルがまばらに間隔を空けている場合、モバイルノードはすべての望ましいMPA関連操作を完了することができます。すべてのMPA関連操作を早めに完了すると、ハンドオフ遅延が減少しますが、セルの滞留時間などの他の制約が追加されます。
We give a numerical example here, similar to [MISHRA04].
ここでは、[mishra04]と同様に数値の例を示します。
D = Coverage diameter
v = Mobile node's velocity
v =モバイルノードの速度
RTT = round trip time from AP to AAA server, including processing time for authentication (Tauth)
RTT = APからAAAサーバーへの往復時間、認証のための処理時間（Tauth）を含む
Tpsk = Time spent to install keys proactively on the target APs
TPSK =ターゲットAPに積極的にキーをインストールするのに費やされる時間
If for a given value of D = 100 ft, Tpsk = 10 ms, and RTT = 100 ms, a mobile node needs to execute only the pre-authentication procedure associated with MPA, then the following can be calculated for a successful MPA procedure before the handoff is complete.
d = 100 ft、TPSK = 10 ms、およびRTT = 100 msの特定の値に対して、モバイルノードはMPAに関連付けられた事前認証手順のみを実行する必要がある場合、以前の成功したMPA手順のために以下を計算できます。ハンドオフが完了しました。
2RTT + Tpsk < D/v
2RTT TPSK <d/v
v = 100 ft/(200 ms + 10 ms) = ~500 ft/sec
Similarly, for a similar cell size, if the mobile node is involved in both pre-authentication and pre-configuration operations as part of the MPA procedure, and it takes an amount of time Tconf = 190 ms to complete the layer 3 configuration including IP address configuration, then for a successful MPA operation,
同様に、同様のセルサイズの場合、MPA手順の一部としてモバイルノードが事前承認操作と再構成前操作の両方に関与している場合、IPを含むレイヤー3構成を完了するにはtconf = 190 msの時間がかかります。MPA操作を成功させるために、構成をアドレスして、
2RTT + Tpsk + Tconf < D/v
v = 100 ft/(200 ms + 10 ms + 190 ms) = ~250 ft/sec
Thus, compared to only the pre-authentication part of the MPA operation, in order to be able to complete both pre-authentication and pre-configuration operations successfully, either the mobile node needs to move at a slower pace or it needs to expedite these operations for this given cell size. Thus, types of MPA operations will be constrained by the velocity of the mobile node.
したがって、MPA操作の承認前の部分のみと比較して、事前認証とコンフィギュレーション前の操作の両方を正常に完了できるようにするために、モバイルノードはより遅いペースで移動する必要があるか、これらを促進する必要があります。この指定されたセルサイズの動作。したがって、MPA操作のタイプは、モバイルノードの速度によって制約されます。
As an alternative, if a mobile node does complete all of the pre-authentication procedure well ahead of time, it uses up the resources accordingly by way of an extra IP address, tunnel, and extra bandwidth. Thus, there is always a tradeoff between the performance benefit obtained from the pre-authentication mechanism and network characteristics, such as movement speed, cell size, and resources utilized.
別の方法として、モバイルノードが事前承認前手順をすべて事前に完了する場合、追加のIPアドレス、トンネル、および余分な帯域幅によってそれに応じてリソースを使用します。したがって、容認前メカニズムから得られたパフォーマンスの利点と、動き速度、セルサイズ、使用されるリソースなどのネットワーク特性との間には、常にトレードオフがあります。
Authors' Addresses
著者のアドレス
Ashutosh Dutta (editor) NIKSUN 100 Nassau Park Blvd. Princeton, NJ 08540 USA
Ashutosh Dutta（編集者）Niksun 100 Nassau Park Blvd.ニュージャージー州プリンストン08540 USA
EMail: ashutosh.dutta@ieee.org
Victor Fajardo NIKSUN 100 Nassau Park Blvd. Princeton, NJ 08540 USA
Victor Fajardo niksun 100 Nassau Park Blvd.ニュージャージー州プリンストン08540 USA
EMail: vf0213@gmail.com
Yoshihiro Ohba Corporate R&D Center, Toshiba Corporation 1 Komukai-Toshiba-cho, Saiwai-ku Kawasaki, Kanagawa 212-0001 Japan
ヨシヒロオバコーポレートR＆Dセンター、東芝コーポーメント1コムカイトーバヒバチョ、聖川川崎、カナガワ212-0001日本
EMail: yoshihiro.ohba@toshiba.co.jp
Kenichi Taniuchi Toshiba Corporation 2-9 Suehiro-cho Ome, Tokyo 198-8710 Japan
田中ki toshiba Corporation 2-9 Suehiro-Cho Ome、Tokyo 198-8710 Japan
EMail: kenichi.taniuchi@toshiba.co.jp
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 USA
ヘニングシュルツリンコロンビア大学コンピュータサイエンス学科450コンピューターサイエンスビル、ニューヨーク、ニューヨーク10027 USA
Phone: +1 212 939 7004
EMail: hgs@cs.columbia.edu