Network Working Group J. Kempf, Ed.
Request for Comments: 4830 DoCoMo USA Labs
Category: Informational April 2007
Problem Statement for Network-Based Localized
Mobility Management (NETLMM)
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
Localized mobility management is a well-understood concept in the IETF, with a number of solutions already available. This document looks at the principal shortcomings of the existing solutions, all of which involve the host in mobility management, and makes a case for network-based local mobility management.
ローカライズされたモビリティ管理は、すでに利用可能なソリューションの数で、IETFではよく理解概念です。この文書では、モビリティ管理でホストを伴うすべてが既存のソリューションの主な欠点を見て、ネットワークベースのローカルモビリティ管理のためのケースを作ります。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. The Local Mobility Problem ......................................4
3. Scenarios for Localized Mobility Management .....................7
3.1. Large Campus ...............................................7
3.2. Advanced Cellular Network ..................................7
3.3. Picocellular Network with Small But Node-Dense Last
Hop Links ..................................................8
4. Problems with Existing Solutions ................................8
5. Advantages of Network-based Localized Mobility Management .......9
6. Security Considerations ........................................10
7. Informative References .........................................10
8. Acknowledgements ...............................................11
9. Contributors ...................................................12
Localized mobility management has been the topic of much work in the IETF. The experimental protocols developed from previous works, namely Fast-Handovers for Mobile IPv6 (FMIPv6) [13] and Hierarchical Mobile IPv6 (HMIPv6) [18], involve host-based solutions that require host involvement at the IP layer similar to, or in addition to, that required by Mobile IPv6 [10] for global mobility management. However, recent developments in the IETF and the Wireless LAN (WLAN) infrastructure market suggest that it may be time to take a fresh look at localized mobility management.
ローカライズされたモビリティ管理はIETFで多くの仕事の話題となっています。実験前の作品、モバイルIPv6（FMIPv6と）[13]及び階層モバイルIPv6（HMIPv6の）のために、すなわち高速ハンドオーバ[18]から開発されたプロトコルと同様IP層でのホストの関与を必要とするホストベースのソリューションを含む、またはInグローバルな移動性管理のためのモバイルIPv6 [10]で必要とされることに加えて。しかし、IETFおよび無線LAN（WLAN）インフラ市場における最近の発展は、局所モビリティ管理で新鮮な表情を取る時間であることを示唆しています。
First, new IETF work on global mobility management protocols that are not Mobile IPv6, such as Host Identity Protocol (HIP) [16] and IKEv2 Mobility and Multihoming (MOBIKE) [4], suggests that future wireless IP nodes may support a more diverse set of global mobility protocols. While it is possible that existing localized mobility management protocols could be used with HIP and MOBIKE, some would require additional effort to implement, deploy, or in some cases, even specify in a non-Mobile IPv6 mobile environment.
まず、ホスト識別プロトコル（HIP）[16]とIKEv2のモビリティとマルチホーミング（MOBIKE）としてモバイルIPv6ではありませんグローバルモビリティ管理プロトコル、上の新しいIETF仕事は、[4]、将来の無線IPノードがより多様をサポートすることを示唆していますグローバルモビリティプロトコルのセット。それは、既存の局所モビリティ管理プロトコルは、HIPとMOBIKEで使用される可能性がありますが、いくつかは、実装、展開、またはいくつかのケースであっても非モバイルIPv6モバイル環境で指定するための追加的な努力が必要となります。
Second, the success in the WLAN infrastructure market of WLAN switches, which perform localized management without any host stack involvement, suggests a possible paradigm that could be used to accommodate other global mobility options on the mobile node while reducing host stack software complexity, expanding the range of mobile nodes that could be accommodated.
第二に、任意のホストスタックの関与なしにローカライズされた管理を行うWLANスイッチのWLANインフラストラクチャ市場での成功は、拡大し、ホストスタックソフトウェアの複雑さを軽減しながら、モバイルノード上の他のグローバルモビリティオプションに対応するために使用できる可能性のパラダイムを提案します収容することができるモバイルノードの範囲。
This document briefly describes the general local mobility problem and scenarios where localized mobility management would be desirable. Then problems with existing or proposed IETF localized mobility management protocols are briefly discussed. The network-based mobility management architecture and a short description of how it solves these problems are presented. A more detailed discussion of goals for a network-based, localized mobility management protocol and gap analysis for existing protocols can be found in [11]. Note that IPv6 and wireless links are considered to be the initial scope for a network-based localized mobility management, so the language in this document reflects that scope. However, the conclusions of this document apply equally to IPv4 and wired links, where nodes are disconnecting and reconnecting.
この文書では、簡単にローカライズされたモビリティ管理が望ましいであろう一般的なローカルモビリティの問題とシナリオについて説明します。そして、既存または提案されているIETF局所モビリティ管理プロトコルで問題が簡単に説明されています。ネットワークベースのモビリティ管理アーキテクチャと、それはこれらの問題を解決する方法の簡単な説明が提示されています。既存のプロトコル用のネットワークベースの局在モビリティ管理プロトコルとギャップ分析の目標のより詳細な説明は、[11]に見出すことができます。 IPv6および無線リンクはネットワークベースのローカライズされたモビリティ管理のための最初の範囲であると考えられ、したがって、この文書に記載されている言語は、その範囲を反映していることに注意してください。しかしながら、この文献の結論は、ノードが切断および再接続されたIPv4および有線リンク、に等しく適用されます。
Mobility terminology in this document follows that in RFC 3753 [14], with the addition of some new and revised terminology given here:
このドキュメントのモビリティの用語は、RFC 3753 [14]には、いくつかの新規および改訂版の用語を追加して、ここで与えられたことになります。
WLAN Switch
WLANスイッチ
A WLAN switch is a multiport bridge Ethernet [8] switch that connects network segments but also allows a physical and logical star topology, which runs a protocol to control a collection of 802.11 [6] access points. The access point control protocol allows the switch to perform radio resource management functions such as power control and terminal load balancing between the access points. Most WLAN switches also support a proprietary protocol for inter-subnet IP mobility, usually involving some kind of inter-switch IP tunnel, which provides session continuity when a terminal moves between subnets.
WLANスイッチは、ネットワークセグメントを接続するだけでなく、802.11 [6]アクセスポイントの収集を制御するためのプロトコルを実行し、物理的および論理的なスター型トポロジーを可能にするマルチポートブリッジイーサネット[8]のスイッチです。アクセスポイント制御プロトコルは、スイッチは、電力制御とアクセスポイント間バランス端末負荷として無線リソース管理機能を実行することを可能にします。ほとんどのWLANスイッチはまた、通常、サブネット間ときに端末が移動セッション継続性を提供し、スイッチ間のIPトンネルのいくつかの種類を含む、サブネット間のIPモビリティのための独自のプロトコルをサポートします。
Access Network
アクセスネットワーク
An access network is a collection of fixed and mobile network components allowing access to the Internet all belonging to a single operational domain. It may consist of multiple air interface technologies (for example, 802.16e [7], Universal Mobile Telecommunications System (UMTS) [1], etc.) interconnected with multiple types of backhaul interconnections (such as Synchronous Optical Network (SONET) [9], metro Ethernet [15] [8], etc.).
アクセスネットワークは、すべて単一の操作のドメインに属するインターネットへのアクセスを許可する固定およびモバイルネットワークコンポーネントの集まりです。これは、複数のエアインタフェース技術からなるものであってもよい（例えば、802.16eの[7]、ユニバーサルモバイルテレコミュニケーションシステム（UMTS）[1]など）、同期光ネットワーク（SONET）9とバックホール相互接続の複数種類（と相互接続]、メトロイーサネット（登録商標）[15] [8]など）。
Local Mobility (revised)
ローカル・モビリティ（改訂版）
Local Mobility is mobility over an access network. Note that although the area of network topology over which the mobile node moves may be restricted, the actual geographic area could be quite large, depending on the mapping between the network topology and the wireless coverage area.
ローカル・モビリティは、アクセスネットワーク経由で移動度です。ネットワークトポロジの領域がその上、モバイルノードの移動を制限してもよいが、実際の地理的エリアは、ネットワークトポロジと無線カバレッジエリアの間のマッピングに応じて、非常に大きくなり得ることに留意されたいです。
Localized Mobility Management
ローカライズされたモビリティ・マネジメント
Localized Mobility Management is a generic term for any protocol that maintains the IP connectivity and reachability of a mobile node for purposes of maintaining session continuity when the mobile node moves, and whose signaling is confined to an access network.
ローカライズされたモビリティ管理をするとき、移動ノードが移動セッションの連続性を維持し、そのシグナリングアクセスネットワークに限定されるの目的のために、モバイルノードのIP接続と到達可能性を維持する任意のプロトコルの総称です。
Localized Mobility Management Protocol
局所モビリティ管理プロトコル
A protocol that supports localized mobility management.
ローカライズされたモビリティ管理をサポートするプロトコル。
Global Mobility Management Protocol
グローバル・モビリティ管理プロトコル
A Global Mobility Management Protocol is a mobility protocol used by the mobile node to change the global, end-to-end routing of packets for purposes of maintaining session continuity when movement causes a topology change, thus invalidating a global unicast address of the mobile node. This protocol could be Mobile IP [10] [17], but it could also be HIP [16] or MOBIKE [4].
グローバル・モビリティ管理プロトコルは、移動は、このように移動ノードのグローバルユニキャストアドレスを無効化する、トポロジー変化を引き起こす場合、セッションの連続性を維持する目的のためにパケットのグローバルな、エンドツーエンドルーティングを変更するためにモバイルノードによって使用されるモビリティプロトコルであります。このプロトコルは、モバイルIP [10] [17]かもしれないが、それはまた、HIP [16]又はMOBIKE [4]とすることができます。
Global Mobility Anchor Point
グローバルモビリティアンカーポイント
A node in the network where the mobile node maintains a permanent address and a mapping between the permanent address and the local temporary address where the mobile node happens to be currently located. The Global Mobility Anchor Point may be used for purposes of rendezvous and possibly traffic forwarding.
モバイルノードは永久的なアドレスと永久アドレスとモバイルノードが現在位置するたまたまローカル一時アドレスとの間のマッピングを維持し、ネットワーク内のノード。グローバルモビリティアンカーポイントはランデブーと、おそらくトラフィック転送の目的で使用することができます。
Intra-Link Mobility
イントラリンクモビリティ
Intra-Link Mobility is mobility between wireless access points within a link. Typically, this kind of mobility only involves Layer 2 mechanisms, so Intra-Link Mobility is often called Layer 2 mobility. No IP subnet configuration is required upon movement since the link does not change, but some IP signaling may be required for the mobile node to confirm whether or not the change of wireless access point also resulted in the previous access routers becoming unreachable. If the link is served by a single access point/router combination, then this type of mobility is typically absent. See Figure 1.
イントラリンクモビリティは、リンク内の無線アクセスポイント間の移動度です。一般的に、モビリティのこの種は、レイヤ2のメカニズムが関与するので、イントラリンクモビリティは、多くの場合、レイヤ2モビリティと呼ばれています。何のIPサブネットの設定は、リンクが変更されないので、移動の際に必要とされないが、いくつかのIPシグナリングは、無線アクセスポイントの変化はまた、到達不能になって以前のアクセスルータをもたらしたか否かを確認するために、モバイルノードのために必要とされてもよいです。リンクは、単一のアクセスポイント/ルーターの組み合わせによって提供されている場合は、モビリティのこのタイプは、一般的に存在しません。図1を参照してください。
The local mobility problem is restricted to providing IP mobility management for mobile nodes within an access network. The access network gateways function as aggregation routers. In this case, there is no specialized routing protocol (e.g., Generic Tunneling Protocol (GTP), Cellular IP, Hawaii, etc.) and the routers form a standard IP routed network (e.g., OSPF, Intermediate System to Intermediate System (IS-IS), RIP, etc.). This is illustrated in Figure 1, where the access network gateway routers are designated as "ANG". Transitions between service providers in separate autonomous systems, or across broader, topological "boundaries" within the same service provider, are excluded.
地元の移動性の問題は、アクセスネットワーク内の移動ノードのIPモビリティ管理を提供することに制限されています。アクセス・ネットワーク・ゲートウェイは、集約ルータとして機能します。この場合、特殊なルーティングプロトコルは、（例えば、一般的なトンネリングプロトコル（GTP）、セルラIP、ハワイ、等）とルータが標準のIPネットワークを（ルーティング構成が存在しない、例えば、OSPF、中間システムへの中間システム（IS- ）、RIPなど）です。これは、アクセス・ネットワーク・ゲートウェイ・ルータは「ANG」として指定され、図1に示されています。別の自律システムにおけるサービスプロバイダ間の遷移は、または同じサービスプロバイダ内の広い、トポロジカル「境界線」を越え、除外されています。
Figure 1 depicts the scope of local mobility in comparison to global mobility. The Access Network Gateways (ANGs), GA1 and GB1, are gateways to their access networks. The Access Routers (ARs), RA1 and RA2, are in access network A; RB1 is in access network B. Note that it is possible to have additional aggregation routers between ANG GA1 and ANG GB1, and the access routers if the access network is large. Access Points (APs) PA1 through PA3 are in access network A; PB1 and PB2 are in access network B. Other ANGs, ARs, and APs are also possible, and other routers can separate the ARs from the ANGs. The figure implies a star topology for the access network deployment, and the star topology is the primary interest since it is quite common, but the problems discussed here are equally relevant to ring or mesh topologies in which ARs are directly connected through some part of the network.
図1は、グローバルモビリティと比較して、ローカル・モビリティの範囲を示しています。アクセスネットワークゲートウェイ（ANGs）、GA1とGB1は、そのアクセスネットワークへのゲートウェイです。アクセスルータ（ARS）、RA1とRA2は、アクセスネットワークAにあります。 RB1は、アクセスネットワークが大きい場合には、追加のANG GA1とANG GB1の間の集約ルータ、およびアクセスルータを有することが可能であることをアクセスネットワークB注です。 PA3を通じてアクセスポイント（AP）PA1は、アクセスネットワークAです。 PB1及びPB2は、アクセスネットワークB.他ANGs、アクセスルータにあり、APはまた可能であり、他のルータがANGsからのARを分離することができます。図は、アクセスネットワークの展開のためのスタートポロジを意味し、それは非常に一般的ですので、スタートポロジは、主要な関心であるが、ここで議論の問題が鳴らすかのARは、直接の一部を介して接続されているトポロジをメッシュにも同様に関連しています通信網。
Access Network A Access Network B
アクセスネットワークAアクセスネットワークB
+-------+ +-------+
|ANG GA1| (other ANGs) |ANG GB1| (other ANGs)
+-------+ +-------+
@ @ @
@ @ @
@ @ @ (other routers)
@ @ @
@ @ @
@ @ @
+------+ +------+ +------+
|AR RA1| |AR RA2|(other ARs) |AR RB1| (other ARs)
+------+ +------+ +------+
* * *
* * * * *
* * * * *
* * * * *
* * * * *
* * * (other APs) * * (other APs)
/\ /\ /\ /\ /\
/AP\ /AP\ /AP\ /AP\ /AP\
/PA1 \ /PA2 \ /PA3 \ /PB1 \ /PB2 \
------ ------ ------ ------ ------
+--+ +--+ +--+ +--+
|MN|----->|MN|----->|MN|-------->|MN|
+--+ +--+ +--+ +--+
Intra-link Local Global
(Layer 2) Mobility Mobility
Mobility
Figure 1. Scope of Local and Global Mobility Management
ローカルおよびグローバルモビリティ・マネジメントの図1.適用範囲
As shown in the figure, a global mobility protocol may be necessary when a mobile node (MN) moves between two access networks. Exactly what the scope of the access networks is depends on deployment considerations. Mobility between two APs under the same AR constitutes intra-link (or Layer 2) mobility, and is typically handled by Layer 2 mobility protocols (if there is only one AP/cell per AR, then intra-link mobility may be lacking). Between these two lies local mobility. Local mobility occurs when a mobile node moves between two APs connected to two different ARs.
同図に示すように、モバイルノード（MN）が2つのアクセスネットワーク間を移動する際に、グローバルモビリティプロトコルが必要であってもよいです。まさにアクセスネットワークの範囲があることは、展開の考慮事項に依存します。同じAr下で2つのAP間の移動度は、イントラリンク（またはレイヤ2）モビリティを構成し、（イントラリンク移動度が不足することができる次いでARごとに1つのAP /セルがある場合）は、典型的には、レイヤ2モビリティプロトコルによって処理されます。これら二つの間のローカルモビリティがあります。モバイルノードは、2つの異なるアクセスルータに接続された2つのAP間を移動するときに、ローカル移動度が生じます。
Global mobility protocols allow a mobile node to maintain reachability when the MN's globally routable IP address changes. It does this by updating the address mapping between the permanent address and temporary local address at the global mobility anchor point, or even end to end by changing the temporary local address directly at the node with which the mobile node is corresponding. A global mobility management protocol can therefore be used between ARs for handling local mobility. However, there are three well-known problems involved in using a global mobility protocol for every movement between ARs. Briefly, they are:
グローバルモビリティプロトコルは、ときMNのグローバルにルーティング可能なIPアドレスの変更、移動ノードが到達可能性を維持することができます。これは、グローバルモビリティアンカーポイントで永久アドレスと一時的なローカルアドレス間のアドレスマッピングを更新する、あるいは移動ノードが対応しているノードに直接、一時的なローカルアドレスを変更することにより、エンドツーエンドでこれを行います。グローバルモビリティ管理プロトコルは、したがって、ローカルモビリティを処理するためのARの間で使用することができます。しかし、アクセスルータ間のすべての運動のためのグローバルモビリティプロトコルを使用してに関与し3のよく知られた問題があります。簡単に言えば、彼らは以下のとおりです。
1) Update latency. If the global mobility anchor point and/or correspondent node (for route-optimized traffic) is at some distance from the mobile node's access network, the global mobility update may require a considerable amount of time. During this time, packets continue to be routed to the old temporary local address and are essentially dropped.
1）の待ち時間を更新します。 （経路最適化トラフィック用）グローバルモビリティ・アンカー・ポイントおよび/またはコレスポンデントノードは、モバイルノードのアクセスネットワークからいくつかの距離であれば、グローバルモビリティの更新はかなりの時間が必要な場合があります。この間、パケットが古い一時ローカルアドレスにルーティングされ続け、実質的に削除されます。
2) Signaling overhead. The amount of signaling required when a mobile node moves from one last-hop link to another can be quite extensive, including all the signaling required to configure an IP address on the new link and global mobility protocol signaling back into the network for changing the permanent to temporary local address mapping. The signaling volume may negatively impact wireless bandwidth usage and real-time service performance.
2）シグナリングオーバーヘッド。量は、別の最後のホップリンクからモバイルノードの移動は、永久を変更するため、ネットワークに再びシグナリング新しいリンクおよびグローバルモビリティプロトコルにIPアドレスを設定するために必要なすべてのシグナルを含む、非常に広範囲であり得る場合に必要なシグナリング一時ローカルアドレスへのマッピング。シグナリング・ボリュームは、負無線帯域使用率とリアルタイムサービスのパフォーマンスに影響を与えることができます。
3) Location privacy. The change in temporary local address as the mobile node moves exposes the mobile node's topological location to correspondents and potentially to eavesdroppers. An attacker that can assemble a mapping between subnet prefixes in the mobile node's access network and geographical locations can determine exactly where the mobile node is located. This can expose the mobile node's user to threats on their location privacy. A more detailed discussion of location privacy for Mobile IPv6 can be found in [12].
3）場所のプライバシー。モバイルノードが移動するときに一時的なローカルアドレスの変更は、特派へと潜在的に盗聴者へのモバイルノードの位相的な位置を公開します。モバイルノードが位置する場所を正確サブネットモバイルノードのアクセスネットワーク内のプレフィクスと地理的位置との間のマッピングを組み立てることができる攻撃者が決定することができます。これは、その場所のプライバシー上の脅威に移動ノードのユーザに公開することができます。モバイルIPv6のロケーションプライバシーのより詳細な説明は、[12]に見出すことができます。
These problems suggest that a protocol to localize the management of topologically small movements is preferable to using a global mobility management protocol on each movement to a new link. In addition to these problems, localized mobility management can provide a measure of local control, so mobility management can be tuned for specialized local conditions. Note also that if localized mobility management is provided, it is not strictly required for a mobile node to support a global mobility management protocol since movement within a restricted IP access network can still be accommodated. Without such support, however, a mobile node experiences a disruption in its traffic when it moves beyond the border of the localized mobility management domain.
これらの問題はトポロジカルに小さな動きの管理をローカライズするためのプロトコルは、新しいリンクへ移動する毎にグローバルモビリティ管理プロトコルを使用するよりであることを示唆しています。これらの問題に加えて、局所モビリティ管理は、局所制御の手段を提供することができますので、移動性管理は、特殊な地域の状況に合わせて調整することができます。局所モビリティ管理が提供されている場合、厳密にまだ収容することができる制限付きIPアクセスネットワーク内での移動以来、グローバルモビリティ管理プロトコルをサポートするために、モバイルノードのために必要とされていないことにも注意してください。それは局所モビリティ管理ドメインの境界を超えて移動したとき、このような支援がなければ、しかし、モバイルノードは、そのトラフィックの中断を経験します。
There are a variety of scenarios in which localized mobility management is useful.
局所モビリティ管理が有用である、さまざまなシナリオがあります。
One scenario where localized mobility management would be attractive is a campus WLAN deployment, in which the geographical span of the campus, distribution of buildings, availability of wiring in buildings, etc. preclude deploying all WLAN access points as part of the same IP subnet. WLAN Layer 2 mobility could not be used across the entire campus.
ローカライズされたモビリティ管理が魅力的である1つのシナリオは、同じIPサブネットの一部として、すべてのWLANアクセスポイントを展開排除などキャンパスWLANの展開、キャンパスの中に地理的なスパン、建物の分布、建物内の配線の利用可能性、です。 WLANのレイヤ2モビリティは、キャンパス全体にわたって使用することができませんでした。
In this case, the campus is divided into separate last-hop links, each served by one or more access routers. This kind of deployment is served today by WLAN switches that coordinate IP mobility between them, effectively providing localized mobility management at the link layer. Since the protocols are proprietary and not interoperable, any deployments that require IP mobility necessarily require switches from the same vendor.
この場合、キャンパスは、それぞれが1つまたは複数のアクセスルータによって提供される、別々の最終ホップリンクに分かれています。展開のこの種を効果的にリンク層に局在モビリティ管理を提供し、それらの間でIPモビリティを座標WLANスイッチにより、今日提供しています。プロトコルは独自性と相互運用性はありませんので、IPモビリティを必要とするすべての展開は必ずしも同じベンダーからの切り替えが必要です。
Next-generation cellular protocols, such as 802.16e [7] and Super 3G/3.9G [2], have the potential to run IP deeper into the access network than the current 3G cellular protocols, similar to today's WLAN networks. This means that the access network can become a routed IP network. Interoperable localized mobility management can unify local mobility across a diverse set of wireless protocols all served by IP, including advanced cellular, WLAN, and personal area wireless technologies such as UltraWide Band (UWB) [5] and Bluetooth [3]. Localized mobility management at the IP layer does not replace Layer 2 mobility (where available) but rather complements it. A standardized, interoperable localized mobility management protocol for IP can remove the dependence on IP-layer localized mobility protocols that are specialized to specific link technologies or proprietary, which is the situation with today's 3G protocols. The expected benefit is a reduction in maintenance cost and deployment complexity. See [11] for a more detailed discussion of the goals for a network-based localized mobility management protocol.
などの802.16eなどの次世代携帯プロトコルは、[7]とスーパー3G / 3.9G [2]、今日のWLANネットワークに類似し、現在の3G携帯電話のプロトコル、よりアクセスネットワークに深くIPを実行する可能性があります。これは、アクセスネットワークがルーティングされたIPネットワークになることができることを意味します。相互運用可能なローカライズされたモビリティ管理は、高度なセルラ、WLAN、およびそのようなウルトラワイドバンド（UWB）などのパーソナルエリアの無線技術を含む全てのIPによってサービスされる無線プロトコルの多様なセットを横切ってローカルモビリティを統一することができる[5]やBluetooth [3]。 IP層でのローカライズされたモビリティ管理は、レイヤ2モビリティ（利用可能）を置き換えるのではなく、それを補完するものではありません。 IPのための標準化、相互運用可能なローカライズされたモビリティ管理プロトコルは、今日の3Gプロトコルの状況で特定のリンク技術や独自に特化しているIP-層ローカライズされたモビリティプロトコルへの依存を削除することができます。予想される利点は、メンテナンスコストと展開の複雑さの減少です。ネットワークベースのローカライズされたモビリティ管理プロトコルのための目標のより詳細な議論については[11]を参照してください。
Future radio link protocols at very high frequencies may be constrained to very short, line-of-sight operation. Even some existing protocols, such as UWB [5] and Bluetooth [3], are designed for low transmit power, short-range operation. For such protocols, extremely small picocells become more practical. Although picocells do not necessarily imply "pico subnets", wireless sensors and other advanced applications may end up making such picocellular type networks node-dense, requiring subnets that cover small geographical areas, such as a single room. The ability to aggregate many subnets under a localized mobility management scheme can help reduce the amount of IP signaling required on link movement.
非常に高い周波数での将来の無線リンクプロトコルは、非常に短い、視線動作に制約されてもよいです。このようなUWB [5]やBluetooth [3]としても、いくつかの既存のプロトコルは、低送信電力、短距離動作するように設計されています。そのようなプロトコルのために、非常に小さいピコセルは、より実用的になります。ピコセルは、必ずしも「ピコサブネット」を意味するものではないが、無線センサーおよびその他の高度なアプリケーションは、シングルルームのような小さな地理的エリアをカバーするサブネットを必要とする、ノード密度の高いこのようなピコセルラータイプのネットワークを作ってしまうことができます。ローカライズされたモビリティ管理スキームの下で、多くのサブネットを集約する機能は、リンクの動きに必要なIPシグナリングの量を減らすことができます。
Existing solutions for localized mobility management fall into two classes:
ローカライズされた移動性管理のための既存のソリューションは、2つのクラスに分けられます。
1) Interoperable IP-level protocols that require changes to the mobile node's IP stack and handle localized mobility management as a service provided to the mobile node by the access network.
1）移動ノードのIPスタックへの変更を必要とし、アクセスネットワークによってモバイル・ノードに提供されるサービスとして局在モビリティ管理を処理する相互運用可能なIPレベルのプロトコル。
2) Link specific or proprietary protocols that handle localized mobility for any mobile node but only for a specific type of link layer, for example, 802.11 [6].
2）のみ、リンク層の特定のタイプのために、例えば、802.11 [6]のいずれかの移動ノードのためのローカライズされたモビリティを扱う特定のまたは独自のプロトコルをリンク。
The dedicated localized mobility management IETF protocols for Solution 1 are not yet widely deployed, but work continues on standardization. Some Mobile IPv4 deployments use localized mobility management. For Solution 1, the following are specific problems:
解決方法1のための専用の局所モビリティ管理IETFプロトコルはまだ広く普及しているが、仕事が標準化に引き続きされていません。一部のモバイルIPv4の展開は、ローカライズされたモビリティ管理を使用します。ソリューション1の場合は、以下の具体的な問題は、次のとおりです。
1) The host stack software requirement limits broad usage even if the modifications are small. The success of WLAN switches indicates that network operators and users prefer no host stack software modifications. This preference is independent of the lack of widespread Mobile IPv4 deployment, since it is much easier to deploy and use the network.
1）ホスト・スタック・ソフトウェア要件は修正が小さい場合であっても広い使用を制限します。 WLANスイッチの成功は、ネットワーク事業者とユーザーが何もホストスタックソフトウェアの修正を好むていないことを示しています。ネットワークを展開して使用する方がはるかに簡単ですので、この設定は、広範なモバイルIPv4の展開の欠如とは無関係です。
2) Future mobile nodes may choose other global mobility management protocols, such as HIP or MOBIKE. The existing localized mobility management solutions all depend on Mobile IP or derivatives.
2）今後のモバイルノードは、HIP又はMOBIKE等の他のグローバルモビリティ管理プロトコルを選択することができます。既存の局所モビリティ管理ソリューションのすべては、モバイルIPまたはその誘導体に依存しています。
3) Existing localized mobility management solutions do not support both IPv4 and IPv6.
3）既存のローカライズされた移動性管理ソリューションは、IPv4とIPv6の両方をサポートしていません。
4) Existing host-based localized mobility management solutions require setting up additional security associations with network elements in the access domain.
4）既存のホスト・ベースのローカライズされたモビリティ管理ソリューションは、アクセスドメイン内のネットワーク要素と追加のセキュリティアソシエーションを設定が必要です。
Market acceptance of WLAN switches has been very large, so Solution 2 is widely deployed and continuing to grow. Solution 2 has the following problems:
解決策2を広く展開し、成長を続けているので、WLANスイッチの市場での受け入れは、非常に大きくなっています。解決策2は、以下のような問題点があります。
1) Existing solutions only support WLAN networks with Ethernet backhaul and therefore are not available for advanced cellular networks or picocellular protocols, or other types of wired backhaul.
1）既存の解決策は、イーサネット・バックホールとWLANネットワークをサポートし、従って高度なセルラネットワーク又はピコセルラープロトコル、または有線バックホールの他のタイプのために使用できません。
2) Each WLAN switch vendor has its own proprietary protocol that does not interoperate with other vendors' equipment.
2）各WLANスイッチ・ベンダーは、他のベンダの機器との相互運用性はありません独自のプロトコルを持っています。
3) Because the solutions are based on Layer 2 routing, they may not scale up to a metropolitan area or local province, particularly when multiple kinds of link technologies are used in the backbone.
溶液は、レイヤ2ルーティングに基づいているため3）、それらは、リンク・テクノロジーの複数種類の骨格において使用される場合は特に、メトロポリタンエリア又はローカル地域にスケールアップしないことができます。
Having an interoperable, standardized localized mobility management protocol that is scalable to topologically large networks, but requires no host stack involvement for localized mobility management is a highly desirable solution. The advantages that this solution has over Solutions 1 and 2 above are as follows:
位相幾何学的に大規模なネットワークにスケーラブルですが、ローカライズされた移動性管理のためのホストスタックの関与が非常に望ましい解決策ではありません必要との相互運用可能な、標準化され局所モビリティ管理プロトコルを持ちます。次のように、この溶液は、溶液1および2上に有することの利点は、上記のとおりです。
1) Compared with Solution 1, a network-based solution requires no localized mobility management support on the mobile node and is independent of global mobility management protocol, so it can be used with any or none of the existing global mobility management protocols. The result is a more modular mobility management architecture that better accommodates changing technology and market requirements.
1）溶液1と比較すると、ネットワークベースのソリューションは、モバイルノードにはローカライズされたモビリティ管理のサポートを必要とせず、グローバルモビリティ管理プロトコルとは無関係であるので、それは、任意のまたは既存のグローバルモビリティ管理プロトコルのいずれと共に使用することができます。結果は、より良い適応は、技術と市場要件の変化よりモジュラーモビリティ管理アーキテクチャです。
2) Compared with Solution 2, an IP-level network-based localized mobility management solution works for link protocols other than Ethernet, and for wide area networks.
2）ソリューション2と比較すると、IPレベルのネットワーク・ベースのローカライズされたモビリティ管理ソリューションは、イーサネット以外のリンク・プロトコルについて、およびワイドエリアネットワークのために動作します。
RFC 4831 [11] discusses a reference architecture for a network-based, localized mobility protocol and the goals of the protocol design.
RFC 4831 [11]は、ネットワークベースの、ローカライズされたモビリティプロトコルおよびプロトコル設計の目的のための参照アーキテクチャを説明します。
Localized mobility management has certain security considerations, one of which -- the need for security from access network to mobile node -- was discussed in this document. Host-based localized mobility management protocols have all the security problems involved with providing a service to a host. Network-based localized mobility management requires security among network elements that is equivalent to what is needed for routing information security, and security between the host and network that is equivalent to what is needed for network access, but no more. A more complete discussion of the security goals for network-based localized mobility management can be found in [11].
モバイルノードへのアクセスネットワークからのセキュリティの必要性 - - ローカライズされた移動性管理は、特定のセキュリティ上の考慮事項、のいずれかを持って、この文書で説明しました。ホストベースのローカライズされたモビリティ管理プロトコルは、ホストにサービスを提供に関わるすべてのセキュリティ上の問題を持っています。ネットワークベース局所モビリティ管理は、情報セキュリティをルーティングするために必要とされるものに相当し、ネットワーク要素間のセキュリティ、およびネットワークアクセスのために必要とされるものに相当し、ホストとネットワーク間のセキュリティを必要としませんが、ないより。ネットワークベースのローカライズされたモビリティ管理のためのセキュリティ目標のより完全な議論は[11]に記載されています。
[1] 3GPP, "UTRAN Iu interface: General aspects and principles", 3GPP TS 25.410, 2002, http://www.3gpp.org/ftp/Specs/html-info/25410.htm.
[1] 3GPP、 "UTRAN Iuインターフェース：一般的側面と原則"、3GPP TS 25.410、2002、http://www.3gpp.org/ftp/Specs/html-info/25410.htm。
[2] 3GPP, "3GPP System Architecture Evolution: Report on Technical Options and Conclusions", TR 23.882, 2005, http://www.3gpp.org/ftp/Specs/html-info/23882.htm.
[2] 3GPP、 "3GPPシステムアーキテクチャエボリューション：技術的なオプションと結論に関する報告書"、TR 23.882、2005、http://www.3gpp.org/ftp/Specs/html-info/23882.htm。
[3] Bluetooth SIG, "Specification of the Bluetooth System", November, 2004, available at http://www.bluetooth.com.
[3]のBluetooth SIG、2004年11月、 "ブルートゥースシステムの仕様"、http://www.bluetooth.comでご利用いただけます。
[4] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
[4] Eronen、P.、 "IKEv2のモビリティとマルチホーミングプロトコル（MOBIKE）"、RFC 4555、2006年6月。
[5] IEEE 802.15 WPAN High Rate Alternative PHY Task Group 3a (TG3a), http://www.ieee802.org/15/pub/TG3a.html.
[5] IEEE 802.15 WPAN高レートの代替PHYタスクグループ3aを（TG3a）、http://www.ieee802.org/15/pub/TG3a.html。
[6] IEEE, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications", IEEE Std. 802.11, 1999.
[6] IEEE、 "無線LAN媒体アクセス制御（MAC）および物理層（PHY）仕様"、IEEE STD。 802.11、1999。
[7] IEEE, "Amendment to IEEE Standard for Local and Metropolitan Area Networks - Part 16: Air Interface for Fixed Broadband Wireless Access Systems - Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands", IEEE Std. 802.16e-2005, 2005.
[7] IEEE、「地方とメトロポリタンエリアネットワークのIEEE規格に改正 - パート16：固定ブロードバンド無線アクセスシステムのためのエア・インタフェース - 固定およびライセンスバンドでモバイル運用組み合わせるための物理的および媒体アクセス制御層」、IEEE規格。 802.16eの-2005、2005。
[8] IEEE, "Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications", IEEE Std. 802.3-2005, 2005.
[8] IEEE、 "衝突検出（CSMA / CD）アクセス方法及び物理層仕様のキャリアセンス多重アクセス"、IEEE STD。 802.3から2005、2005。
[9] ITU-T, "Architecture of Transport Networks Based on the Synchronous Digital Hierarchy (SDH)", ITU-T G.803, March, 2000.
[9] ITU-T、ITU-T G. 803、2000年3月 "同期デジタル階層（SDH）に基づいてトランスポート・ネットワークのアーキテクチャ"。
[10] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[10]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[11] Kempf, J., Ed., "Goals for Network-Based Localized Mobility Management (NETLMM)", RFC 4831, April 2007.
[11]ケンプ、J.、エド。、 "ネットワークベース局所モビリティ管理（NETLMM）の目標"、RFC 4831、2007年4月。
[12] Koodli, R., "IP Address Location Privacy and Mobile IPv6: Problem Statement", Work in Progress, February 2007.
[12] Koodli、R.、 "IPアドレス所在地プライバシーとモバイルIPv6：問題文"、進歩、2007年2月での作業。
[13] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.
[13] Koodli、R.、 "モバイルIPv6の高速ハンドオーバ"、RFC 4068、2005年7月。
[14] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[14]ようにして、J.とM.古城、 "モビリティ関連用語"、RFC 3753、2004年6月。
[15] Metro Ethernet Forum, " Metro Ethernet Network Architecture Framework - Part 1: Generic Framework", MEF 4, May, 2004.
[15]メトロ・イーサネット・フォーラム、 "メトロ・イーサネット・ネットワークアーキテクチャフレームワーク - パート1：一般的なフレームワーク"、MEF 4月、2004。
[16] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[16]モスコウィッツ、R.とP. Nikander、 "ホストアイデンティティプロトコル（HIP）アーキテクチャ"、RFC 4423、2006年5月。
[17] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[17]パーキンス、C.、 "IPv4のIPモビリティサポート"、RFC 3344、2002年8月。
[18] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005.
[18]ソリマン、H.、カステルッシア、C.、エルMalki、K.、およびL. Bellier、 "階層型Mobile IPv6のモビリティ管理（HMIPv6の）"、RFC 4140、2005年8月。
The authors would like to acknowledge the following for particularly diligent reviewing: Vijay Devarapalli, Peter McCann, Gabriel Montenegro, Vidya Narayanan, Pekka Savola, and Fred Templin.
ビジェイDevarapalli、ピーター・マッキャン、ガブリエルモンテネグロ、Vidyaナラヤナン、ペッカSavola、およびフレッド・テンプリン：著者は、特に勤勉な見直しのために以下のことを承認したいと思います。
Kent Leung Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: kleung@cisco.com
ケントレオンシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134 USA Eメール：kleung@cisco.com
Phil Roberts Motorola Labs Schaumberg, IL USA EMail: phil.roberts@motorola.com
フィル・ロバーツモトローラ研究所Schaumberg、IL USA Eメール：phil.roberts@motorola.com
Katsutoshi Nishida NTT DoCoMo Inc. 3-5 Hikarino-oka, Yokosuka-shi Kanagawa, Japan Phone: +81 46 840 3545 EMail: nishidak@nttdocomo.co.jp
かつとし にしだ んっｔ どこも いんｃ。 ３ー５ ひかりのーおか、 よこすかーし かながわ、 じゃぱん Ｐほね： ＋８１ ４６ ８４０ ３５４５ えまいｌ： にしだｋ＠んっｔどこも。こ。ｊｐ
Gerardo Giaretta Telecom Italia Lab via G. Reiss Romoli, 274 10148 Torino Italy Phone: +39 011 2286904 EMail: gerardo.giaretta@tilab.com
G.ライスRomoli経由ヘラルドGiarettaテレコムイタリア・ラボ、274 10148トリノイタリア電話：+39 011 2286904 Eメール：gerardo.giaretta@tilab.com
Marco Liebsch NEC Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221-90511-46 EMail: marco.liebsch@ccrle.nec.de
マルコLiebsch NECネットワーク研究所Kurfuersten所36ハイデルベルクドイツ電話：+49 6221-90511-46 Eメール：marco.liebsch@ccrle.nec.de
Editor's Address
編集者の住所
James Kempf DoCoMo USA Labs 181 Metro Drive, Suite 300 San Jose, CA 95110 USA Phone: +1 408 451 4711 EMail: kempf@docomolabs-usa.com
ジェームズ・ケンプドコモUSA Labsの181メトロドライブ、スイート300サンノゼ、CA 95110 USA電話：+1 408 451 4711 Eメール：kempf@docomolabs-usa.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。