[要約] RFC 4830は、ネットワークベースのローカライズドモビリティ管理（NETLMM）の問題を述べたものであり、モビリティ管理の課題と目的を明確にすることを目的としています。
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)
ネットワークベースのローカライズされたモビリティ管理（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）The IETF Trust（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レイヤーでホストの関与を必要とするホストベースのソリューションが含まれます。さらに、グローバルモビリティ管理にモバイル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）[4]など、モバイルIPv6ではないグローバルモビリティ管理プロトコルでの新しいIETF作業は、将来のワイヤレスIPノードがより多様なものをサポートする可能性があることを示唆しています。グローバルモビリティプロトコルのセット。既存のローカライズされたモビリティ管理プロトコルを股関節と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インフラストラクチャ市場での成功は、ホストスタックソフトウェアの複雑さを減らし、モバイルノードの他のグローバルモビリティオプションに対応するために使用できる可能性のあるパラダイムを示唆しています。収容できるモバイルノードの範囲。
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スイッチは、ネットワークセグメントを接続するマルチポートブリッジイーサネット[8]スイッチであり、物理的および論理的なスタートポロジを可能にします。これにより、プロトコルを実行して802.11 [6]アクセスポイントのコレクションを制御します。アクセスポイント制御プロトコルを使用すると、スイッチは、アクセスポイント間の電源制御や端子負荷分散などの無線リソース管理機能を実行できます。ほとんどの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]など）で構成されている場合があります。]、メトロイーサネット[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- is- is-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は、グローバルなモビリティと比較して、ローカルモビリティの範囲を示しています。Access Network Gateways（ANGS）、GA1およびGB1は、アクセスネットワークへのゲートウェイです。アクセスルーター（ARS）、RA1、RA2はアクセスネットワークAにあります。RB1はアクセスネットワークBにあります。ANGGA1とANG GB1の間に追加の集約ルーターがあり、アクセスネットワークが大きい場合はアクセスルーターを使用することが可能であることに注意してください。アクセスポイント（APS）PA1からPA3からアクセスネットワークAにあります。PB1とPB2はアクセスネットワークBにあります。他のANG、ARS、およびAPも可能であり、他のルーターはARをANGから分離できます。この図は、アクセスネットワークの展開の星トポロジーを意味し、スタートポロジは非常に一般的であるため主に関心を持っていますが、ここで説明する問題は、ARが直接接続されているリングまたはメッシュトポロジに等しく関連しています。通信網。
Access Network A Access Network B
アクセスネットワークアクセスネットワーク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）モビリティを構成し、通常、レイヤー2モビリティプロトコルで処理されます（ARごとに1つのAP/セルのみがある場合、リンク内モビリティが欠けている可能性があります）。これらの2つの間には、地元のモビリティがあります。ローカルモビリティは、モバイルノードが2つの異なるARに接続された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の間でグローバルモビリティ管理プロトコルを使用できます。ただし、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) オーバーヘッドの信号。モバイルノードが1つのラストホップリンクから別のリンクに移動するときに必要なシグナリングの量は、新しいリンクで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つは、キャンパスWLANの展開であり、キャンパスの地理的スパン、建物の分布、建物での配線の利用可能性などが、同じIPサブネットの一部としてすべての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]やSuper 3G/3.9G [2]などの次世代のセルラープロトコルは、今日のWLANネットワークと同様に、現在の3GセルラープロトコルよりもアクセスネットワークにIPをより深く走らせる可能性があります。これは、アクセスネットワークがルーティングされたIPネットワークになる可能性があることを意味します。相互運用可能なローカライズされたモビリティ管理は、高度なセルラー、WLAN、およびウルトラアウィドバンド（UWB）[5]やBluetooth [3]などの個人エリアワイヤレステクノロジーを含む、すべてIPが提供するワイヤレスプロトコルの多様なセットにわたってローカルモビリティを統合できます。IPレイヤーでのローカライズされたモビリティ管理は、レイヤー2モビリティ（利用可能な場合）に代わるものではなく、むしろそれを補完します。IP向けの標準化された相互運用可能なローカライズされたモビリティ管理プロトコルは、特定のリンクテクノロジーまたは専有に特化したIP層のローカライズされたモビリティプロトコルへの依存を削除できます。これは、今日の3Gプロトコルの状況です。予想される利点は、メンテナンスコストと展開の複雑さの削減です。ネットワークベースのローカライズされたモビリティ管理プロトコルの目標の詳細については、[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:
WLANスイッチの市場の受け入れは非常に大きいため、ソリューション2は広く展開され、成長を続けています。ソリューション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.
3) ソリューションはレイヤー2ルーティングに基づいているため、特にバックボーンで複数の種類のリンクテクノロジーが使用されている場合、大都市圏や地方の州に拡大しない場合があります。
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].
ローカライズされたモビリティ管理には、特定のセキュリティ上の考慮事項があります。その1つは、アクセスネットワークからモバイルノードまでのセキュリティの必要性 - このドキュメントで議論されています。ホストベースのローカライズされたモビリティ管理プロトコルには、ホストにサービスを提供することに関連するすべてのセキュリティ問題があります。ネットワークベースのローカライズされたモビリティ管理には、情報セキュリティをルーティングするために必要なものと同等のネットワーク要素間のセキュリティ、およびネットワークアクセスに必要なものと同等のホストとネットワーク間のセキュリティが必要ですが、これ以上ありません。ネットワークベースのローカライズされたモビリティ管理のセキュリティ目標についてのより完全な議論は、[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、「Bluetoothシステムの仕様」、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 STD。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、「同期デジタル階層（SDH）に基づく輸送ネットワークのアーキテクチャ」、ITU-T G.803、2000年3月。
[10] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[10] Johnson、D.、Perkins、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] Kempf、J.、ed。、「ネットワークベースのローカライズされたモビリティ管理（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] Mather、J。およびM. Kojo、「Mobility関連用語」、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年5月。
[16] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[16] Moskowitz、R。およびP. Nikander、「Host Identity Protocol（HIP）Architecture」、RFC 4423、2006年5月。
[17] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[17] Perkins、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] Soliman、H.、Castelluccia、C.、El Malki、K。、およびL. Bellier、「階層モバイル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.
著者は、Vijay Devarapalli、Peter McCann、Gabriel Montenelo、Vidya Narayanan、Pekka Savola、Fred Templinの特に勤勉なレビューのために、以下を認めたいと思います。
Kent Leung Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: kleung@cisco.com
Kent Leung Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134 USAメール：kleung@cisco.com
Phil Roberts Motorola Labs Schaumberg, IL USA EMail: phil.roberts@motorola.com
Phil Roberts Motorola Labs Schaumberg、IL USAメール：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
nishida ntt docomo Inc. 3-5 hikarino-oka、yokosuka-shi kanagawa、日本電話：81 46 840 3545電子メール：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. Reiss Romoli経由のGerardo Giaretta Telecom Italia Lab、274 10148 Torino Italy電話：39 011 2286904メール：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
Marco Liebsch Nec Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Dermany電話：49 6221-90511-46メール：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
James Kempf Docomo USA Labs 181 Metro Drive、Suite 300 San Jose、CA 95110 USA電話：1 408 451 4711メール：kempf@docomolabs-usa.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。