Network Working Group T. Melia, Ed.
Request for Comments: 5164 Cisco Systems
Category: Informational March 2008
Mobility Services Transport: Problem Statement
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
抽象
There are ongoing activities in the networking community to develop solutions that aid in IP handover mechanisms between heterogeneous wired and wireless access systems including, but not limited to, IEEE 802.21. Intelligent access selection, taking into account link-layer attributes, requires the delivery of a variety of different information types to the terminal from different sources within the network and vice-versa. The protocol requirements for this signalling have both transport and security issues that must be considered. The signalling must not be constrained to specific link types, so there is at least a common component to the signalling problem, which is within the scope of the IETF. This document presents a problem statement for this core problem.
異種の有線および無線アクセスシステム間のIPハンドオーバ機構における援助を含むが、IEEE 802.21、これらに限定されないというソリューションを開発するためのネットワーキングコミュニティの継続的な活動があります。インテリジェントアクセス選択は、アカウントリンク層の属性を考慮して、ネットワーク内の異なるソースから端末及びその逆に異なる情報タイプの種々の送達を必要とします。このシグナリングのためのプロトコル要件を考慮する必要があり、両方のトランスポートとセキュリティの問題を持っています。シグナリングは、特定のリンクタイプに制限されてはならないので、IETFの範囲内であるシグナリングの問題に対する一般的成分は、少なくともあります。この文書では、このコアの問題の問題文を提示します。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
2.1. Requirements Language ......................................3
3. Definition of Mobility Services .................................4
4. Deployment Scenarios for MoS ....................................4
4.1. End-to-End Signalling and Transport over IP ................5
4.2. End-to-End Signalling and Partial Transport over IP ........5
4.3. End-to-End Network-to-Network Signalling ...................6
5. MoS Transport Protocol Splitting ................................7
5.1. Payload Formats and Extensibility Considerations ...........8
5.2. Requirements on the Mobility Service Transport Layer .......8
6. Security Considerations ........................................11
7. Conclusions ....................................................12
8. Acknowledgements ...............................................13
9. References .....................................................13
9.1. Normative References ......................................13
9.2. Informative References ....................................13
Contributors ......................................................14
This document provides a problem statement for the exchange of information to support handover in heterogeneous link environments [1]. This mobility support service allows more sophisticated handover operations by making available information about network characteristics, neighboring networks and associated characteristics, indications that a handover should take place, and suggestions for suitable target networks to which to handover. The mobility support services are complementary to IP mobility mechanisms [4], [5], [6], [7], [8], [9] to enhance the overall performance and usability perception.
この文書では、異種のリンク環境でのハンドオーバーを支援するための情報交換のための問題文を提供します[1]。このモビリティサポートサービスは、ハンドオーバにどのに適したターゲット・ネットワークのためのネットワーク特性、隣接するネットワークおよび関連する特性、ハンドオーバが行われるべきであることを指摘し、提案についての入手可能な情報にすることによって、より洗練されたハンドオーバ動作を可能にします。モビリティ・サポート・サービスは、IPモビリティ機構[4]、[5]、[6]、[7]、[8]、[9]の全体的な性能と使いやすさの知覚を強化するために相補的です。
There are two key attributes to the handover support service problem for inter-technology handovers:
技術間ハンドオーバのためのハンドオーバ・サポート・サービスの問題には2つの重要な属性があります。
1. The Information: the information elements being exchanged. The messages could be of a different nature, such as information, commands to perform an action, or events informing of a change, potentially being defined following a common structure.
1.情報：情報要素が交換されています。メッセージは、情報として、異なる性質のものであってもよい、アクションを実行するコマンド、又は変化を知らせるイベントが、潜在的に共通の構造以下に定義されます。
2. The Underlying Transport: the transport mechanism to support exchange of the information elements mentioned above. This transport mechanism includes information transport, discovery of peers, and the securing of this information over the network.
2.基本的な輸送：上記の情報要素の交換をサポートするための搬送機構。この搬送機構は情報輸送、ピアの発見、及びネットワークを介してこの情報の固定を含みます。
The initial requirement for this protocol comes from the need to provide a transport for the Media Independent Handover (MIH) protocol being defined by IEEE 802.21 [1], which is not bound to any specific link layer and can operate over more that one network-layer hop. The solution should be flexible to accommodate evolution in the MIH standard, and should also be applicable for other new mobility signalling protocols that have similar message patterns and discovery and transport requirements.
このプロトコルの最初の要件は、IEEE 802.21によって定義されているメディア独立ハンドオーバ（MIH）プロトコルのトランスポートを提供する必要性から来ている[1]、任意の特定のリンクレイヤにバインドされていないとつ以上のネットワーク - で動作することができます層ホップ。ソリューションは、MIH規格の進化に対応するために柔軟であるべきであり、また、同様のメッセージパターンと発見および輸送要件を持つ他の新しいモビリティシグナリングプロトコルに適用可能であるべきです。
The structure of this document is as follows. Section 3 defines Mobility Services. Section 4 provides a simple model for the protocol entities involved in the signalling and their possible relationships. Section 5 describes a decomposition of the signalling problem into service-specific parts and a generic transport part. Section 5.2 describes more detailed requirements for the transport component. Section 6 provides security considerations. Section 7 summarizes the conclusions and open issues.
次のようにこのドキュメントの構造があります。第3節では、モビリティサービスを定義します。第4章では、プロトコルのシグナル伝達に関与するエンティティとその可能性の関係について簡単なモデルを提供します。第5節では、サービス固有の部分へのシグナル伝達の問題と一般的な搬送部の分解を説明します。 5.2節では、トランスポートコンポーネントのより詳細な要件について説明します。第6節は、セキュリティ上の考慮事項を提供します。第7節は結論と未解決の問題をまとめたもの。
The following abbreviations are used in the document:
次の略語は、文書で使用されています。
MIH: Media Independent Handover
MIH：メディア独立ハンドオーバ
MN: Mobile Node
MN：モバイルノード
NN: Network Node, intended to represent some device in the network (the location of the node, e.g., in the access network, the home network is not specified, and for the moment it is assumed that they can reside anywhere).
NN：ネットワーク内のいくつかのデバイスを表すことを意図ネットワークノード（ノードの位置は、例えば、アクセスネットワークにおいて、ホームネットワークが指定されていない、そしてしばらく彼らがどこにでも存在することができるものとします）。
EP: Endpoint, intended to represent the terminating endpoints of the transport protocol used to support the signalling exchanges between nodes.
EP：エンドポイント、ノード間のシグナリング交換をサポートするために使用されるトランスポートプロトコルの終端エンドポイントを表すことを意図したもの。
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 RFC 2119 [2].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[2]。
As mentioned in the Introduction, mobility (handover) support in heterogeneous wireless environments requires functional components located either in the mobile terminal or in the network to exchange information and eventually to make decisions upon this information exchange. For instance, traditional host-based handover solutions could be complemented with more sophisticated network-centric solutions. Also, neighborhood discovery, potentially a complex operation in heterogeneous wireless scenarios, can result in a simpler step if implemented with a unified interface towards the access network.
冒頭で述べたように、異種無線環境において移動性（ハンドオーバー）のサポート情報を交換するために、最終的に、この情報交換の際に決定を行うために、移動端末またはネットワークのいずれかに位置する機能的な構成要素を必要とします。例えば、従来のホストベースのハンドオーバーソリューションは、より洗練されたネットワーク中心のソリューションで補完することができます。アクセスネットワークに向けて統一されたインタフェースを用いて実装されている場合にも、近隣の発見、異種無線シナリオにおける潜在的複雑な操作は、簡単なステップをもたらすことができます。
In this document, the different supporting functions for Media Independent Handover (MIH) management are generally referred to as Mobility Services (MoS) that have different requirements for the transport protocol. These requirements and associated functionalities are the focus of this document. Speaking 802.21 terminology, MoS can be regarded as Information Services (IS), Event Services (ES), and Command Service (CS).
この文書では、メディア独立ハンドオーバー（MIH）管理のためのさまざまな支援機能は、一般的にトランスポートプロトコルのための要件が異なるモビリティサービス（MOS）と呼ばれています。これらの要件および関連する機能は、このドキュメントの焦点です。 802.21の用語をいえば、のMoSは、情報サービス（IS）、イベントサービス（ES）、およびコマンドサービス（CS）とみなすことができます。
The deployment scenarios are outlined in the following sections.
配備シナリオは、次のセクションで概説されています。
Note: while MN-to-MN signalling exchanges are theoretically possible, these are not currently being considered.
注意：MN-へ-MNのシグナリング交換は理論的には可能であるが、これらは、現在検討されていません。
The following scenarios are discussed for understanding the overall problem of transporting MIH protocol. Although these are all possible scenarios and MIH services can be delivered through link-layer specific solutions and/or through a "layer 3 or above" protocol, this problem statement focuses on the delivery of information for Mobility Services only for the latter case.
次のシナリオは、MIHプロトコルを輸送する全体的な問題を理解するために議論されています。これらはすべての可能なシナリオとMIHサービスは、リンク層固有のソリューションを通じて、および/または「レイヤ3以上」プロトコルを介して配信することができますされていますが、この問題文は後者のみの場合のためのモビリティサービスのための情報の提供に焦点を当てています。
In this case, the end-to-end signalling used to exchange the handover information elements (the Information Exchange) runs end-to-end between MN and NN. The underlying transport is also end-to-end.
この場合には、ハンドオーバー情報要素（情報交換）を交換するために使用されるエンドツーエンドシグナリングは、エンドツーエンドのMNとNNの間を走ります。基礎となるトランスポートは、エンドツーエンドです。
+------+ +------+
| MN | | NN |
| (EP) | | (EP) |
+------+ +------+
Information Exchange
<------------------------------------>
/------------------------------------\
< Transport over IP >
\------------------------------------/
Figure 1: End-to-End Signalling and Transport
図1：エンドツーエンドシグナリングとトランスポート
As before, the Information Exchange runs end-to-end between the MN and the second NN. However, in this scenario, some transport means other than IP are used from the MN to the first NN, and the transport over IP is used only between NNs. This is analogous to the use of EAP end-to-end between Supplicant and Authentication Server, with an upper-layer multihop protocol, such as Remote Authentication Dial-In User Service (RADIUS), used as a backhaul transport protocol between an Access Point and the Authentication Server.
前述のように、情報交換は、MNと第二NN間のエンドツーエンドを実行します。しかし、このシナリオでは、いくつかのトランスポートは、IP以外の手段MNから最初NNに使用され、IPオーバー輸送のみたNNの間で使用されています。これは、アクセスポイントとの間のバックホールトランスポートプロトコルとして使用するリモート認証ダイヤルインユーザーサービス（RADIUS）として、上層マルチホッププロトコルで、EAPを使用するエンドツーエンドのサプリカントと認証サーバとの間に類似しています認証サーバ。
+------+ +------+ +------+
| MN | | NN | | NN |
| | | (EP) | | (EP) |
+------+ +------+ +------+
Information Exchange
<------------------------------------>
(Transport over /------------------\
<--------------->< Transport over IP >
e.g. L2) \------------------/
Figure 2: Partial Transport
図2：パーシャルトランスポート
In this case, NN to NN signalling is envisioned. Such a model should allow different network components to gather information from each other. This is useful for instance in conditions where network components need to make decisions and instruct mobile terminals of operations to be executed.
この場合、NNシグナリングにNNが想定されます。このようなモデルは、異なるネットワーク構成要素が互いから情報を収集することを可能にするべきです。これは、ネットワークコンポーネントが決定を行い、実行される操作の移動端末に指示するために必要な条件でインスタンスのために有用です。
+------+ +------+
| NN | | NN |
| (EP) | | (EP) |
+------+ +------+
Information Exchange
------------------->
<-------------------
/----------------\
< Transport >
\----------------/
Figure 3: Information Exchange between Different NNs
図3：異なるNNの間の情報交換
Network nodes exchange information about the status of connected terminals.
ネットワークノードは、接続された端末のステータスについての情報を交換します。
Figure 4 shows a model where the Information Exchanges are implemented by a signalling protocol specific to a particular mobility service, and these are relayed over a generic transport layer (the Mobility Service Transport Layer).
図4は、情報交換は、特定のモビリティサービスに固有のシグナリングプロトコルによって実装されているモデルを示し、これらは、一般的なトランスポート層（モビリティサービストランスポート層）の上に中継されます。
+----------------+ ^
|Mobility Support| |
| Service 2 | |
+----------------+ | | | Mobility Service
|Mobility Support| +----------------+ | Signaling
| Service 1 | +----------------+ | Layer
| | |Mobility Support| |
+----------------+ | Service 3 | |
| | |
+----------------+ V
================================================
+---------------------------------------+ ^ Mobility Service
| Mobility Service Transport Protocol | | Transport
+---------------------------------------+ V Layer
================================================
+---------------------------------------+
| IP |
+---------------------------------------+
Figure 4: Handover Services over IP
図4：IP経由ハンドオーバサービス
The Mobility Service Transport Layer provides certain functionality (outlined in Section 5.2) to the higher-layer mobility support services in order to support the exchange of information between communicating Mobility Service functions. The transport layer effectively provides a container capability to mobility support services, as well as any required transport and security operations required to provide communication, without regard to the protocol semantics and data carried in the specific Mobility Services.
モビリティサービストランスポート層は、モビリティサービス機能を通信する間の情報交換をサポートするために上位層モビリティ・サポート・サービスに（セクション5.2に概説）特定の機能を提供します。トランスポート層は、効果的に、モビリティ・サポート・サービスへのコンテナ能力、ならびに特定のモビリティサービスで運ばれるプロトコルのセマンティクス及びデータに関係なく、通信を提供するために必要な任意の必要なトランスポートおよびセキュリティオペレーションを提供します。
The Mobility Support Services themselves may also define certain protocol exchanges to support the exchange of service-specific information elements. It is likely that the responsibility for defining the contents and significance of the information elements is the responsibility of standards bodies other than the IETF. Example Mobility Services include the Information Services, Event Services, and Command Services.
モビリティサポート自体は、サービス固有の情報要素の交換をサポートするために特定のプロトコル交換を定義することができるサービス。情報要素の内容と意義を定義するための責任がIETF以外の標準化団体の責任であると考えられます。例モビリティサービス情報サービス、イベントサービス、およびコマンドサービスが含まれます。
The format of the Mobility Service Transport Protocol (MSTP) is as follows:
次のようにモビリティサービス・トランスポート・プロトコル（MSTP）の形式は次のとおりです。
+----------------+----------------------------------------+
|Mobility Service| Opaque Payload |
|Transport Header| (Mobility Support Service) |
+----------------+----------------------------------------+
Figure 5: Protocol Structure
図5：プロトコル構造
This figure shows the case for an MIH message that is smaller than the MTU of the path to the destination. A larger payload may require the transport protocol to transparently fragment and reassemble the MIH message.
この図は、目的地までの経路のMTUよりも小さいMIHメッセージの場合を示しています。大きなペイロードは透過フラグメントとMIHメッセージを再構築するために、トランスポート・プロトコルを必要とするかもしれません。
The opaque payload encompasses the Mobility Support Service (MSTP) information that is to be transported. The definition of the Mobility Service Transport Header is something that is best addressed within the IETF. MSTP does not inspect the payload, and any required information will be provided by the MSTP users.
不透明なペイロードを搬送するモビリティサポートサービス（MSTP）情報を含みます。モビリティサービス・トランスポート・ヘッダーの定義は、最高のIETFの中にアドレス指定されているものです。 MSTPは、ペイロードを検査しない、任意の必要な情報は、MSTPのユーザによって提供されます。
The following section outlines some of the general transport requirements that should be supported by the Mobility Service Transport Protocol. Analysis has suggested that at least the following need to be taken into account:
次のセクションでは、モビリティサービストランスポートプロトコルによってサポートされる必要があり、一般的な輸送要件の一部を概説します。分析は、少なくとも以下の必要性を考慮しなければことを示唆しています：
Discovery: MNs need the ability to either discover nodes that support certain services or discover services provided by a certain node. The service discovery can be dealt with using messages as defined in [1]. This section refers to node-discovery in either scenario. There are no assumptions about the location of these Mobility Service nodes within the network. Therefore, the discovery mechanism needs to operate across administrative boundaries. Issues such as speed of discovery, protection against spoofing, when discovery needs to take place, and the length of time over which the discovery information may remain valid; all need to be considered. Approaches include:
ディスカバリー：MNが特定のサービスをサポートするノードを発見したり、特定のノードが提供するサービスを発見するためのいずれかの能力を必要としています。サービス発見[1]で定義されたメッセージを使用して対応することができます。このセクションでは、いずれのシナリオにおいて、ノード発見を指します。ネットワーク内のこれらのモビリティサービスノードの位置についての仮定はありません。したがって、検出メカニズムは、行政境界を越えて動作する必要があります。こうした発見は場所を取る必要がある発見の速さ、なりすましに対する保護、および発見情報が有効残る可能性がある時間の長さなどの問題。すべてを考慮する必要があります。アプローチは、次のとおりです。
* Hard coding information into the MN, indicating either the IP address of the NN, or information about the NN that can be resolved onto an IP address. The configuration information could be managed dynamically, but assumes that the NN is independent of the access network to which the MN is currently attached.
*ハードIPのNNのアドレス、またはIPアドレスに解決することができNNに関する情報のいずれかを示し、MNに情報を符号化します。構成情報は動的に管理が、NNは、MNが現在接続されているアクセスネットワークから独立していることを前提とすることができます。
* Pushing information to the MN, where the information is delivered to the MN as part of other configuration operations, for example, via DHCP or Router Discovery exchange. The benefit of this approach is that no additional exchanges with the network would be required, but the limitations associated with modifying these protocols may limit applicability of the solution.
*情報は、DHCPまたはルータ発見交換を介して、例えば、他の構成操作の一部として、MNに配信されるMNに情報を押します。このアプローチの利点は、ネットワークとの追加の交換は必要ないであろうということであるが、これらのプロトコルを変更することに関連する制限は、溶液の適用を制限することができます。
* MN dynamically requesting information about a node, which may require both MN and NN support for a particular service discovery mechanism. This may require additional support by the access network (e.g., multicast or anycast) even when it may not be supporting the service directly itself.
*は、動的MNと特定のサービス発見メカニズムのためのNNのサポートの両方を必要とするかもしれないノードに関する情報を要求するMN。これは、直接自身のサービスをサポートしなくてもよい場合でも、アクセスネットワーク（例えば、マルチキャストまたはエニーキャスト）することによって、追加のサポートを必要とするかもしれません。
Numerous directory and configuration services already exist, and reuse of these mechanisms may be appropriate. There is an open question about whether multiple methods of discovery would be needed, and whether NNs would also need to discover other NNs. The definition of a service also needs to be determined, including the granularity of the description. For example, IEEE 802.21 specifies three different types of Mobility Services (Information Services, Command Services, and Event Services) that can be located in different portions of the network. An MN could therefore run a discovery procedure of any service running in the (home or visited) network or could run a discovery procedure for a specific service.
多数のディレクトリおよび構成サービスが既に存在し、これらのメカニズムの再使用が適切であり得ます。そこ発見の複数の方法が必要とされるかどうかについての未解決の問題があり、NNはまた、他のNNを発見する必要があるでしょうか。サービスの定義は、説明の粒度を含め、決定する必要があります。例えば、IEEE 802.21は、ネットワークの異なる部分に配置することができモビリティサービスの3つのタイプ（情報サービス、コマンドサービス、およびイベントサービス）を指定します。 MNは、そのために実行されている任意のサービスの発見手順を実行（自宅を訪問したか）、ネットワークまたは特定のサービスの発見手順を実行することができますことができます。
Information from a trusted source: The MN uses the Mobility Service information to make decisions about what steps to take next. It is essential that there is some way to ensure that the information received is from a trustworthy source. This requirement should reuse trust relationships that have already been established in the network, for example, on the relationships established by the Authentication, Authorization, and Accounting (AAA) infrastructure after a mutual authentication, or on the certificate infrastructure required to support SEND [10]. Section 6 provides a more complete analysis.
MNは次回に実行する手順かについての意思決定を行うためにモビリティサービスの情報を使用しています：信頼できるソースからの情報。受信した情報が信頼できるソースからのものであることを確実にするいくつかの方法があることが不可欠です。この要求は、認証によって確立された関係で既に、例えば、ネットワーク内の確立された信頼関係を再利用する必要があり、相互認証後に、またはサポートするために必要な証明書インフラストラクチャ上の許可、アカウンティング（AAA）インフラストラクチャは、[10を送信します]。第6節では、より完全な分析を提供します。
Security association management: A common security association negotiation method, independent of any specific MSTP user, should be implemented between the endpoints of the MSTP. The solution must also work in the case of MN mobility.
セキュリティ関連の管理：一般的なセキュリティアソシエーションのネゴシエーション方法、任意の特定のMSTPユーザーの独立したが、MSTPのエンドポイント間で実施されるべきです。ソリューションはまた、MNの移動の場合には働かなければなりません。
Secure delivery: The Mobility Service information must be delivered securely (integrity and confidentiality) between trusted peers, where the transport may pass though untrusted intermediate nodes and networks. The Mobility Service information should also be protected against replay attacks and denial-of-service attacks.
配達を確保：モビリティサービス情報は、トランスポートは、信頼できない中間ノードとネットワークも渡すことができる、信頼できるピア間で確実に（完全性と機密性）送達されなければなりません。モビリティサービス情報も、リプレイ攻撃やサービス拒否攻撃から保護されなければなりません。
Low latency: Some of the Mobility Services generate time-sensitive information. Therefore, there is a need to deliver the information over quite short timescales, and the required lifetime of a connection might be quite short-lived. As an example, the frequency of messages defined in [1] varies according to the MIH service type. It is expected that Events and Commands messages arrive at an interval of hundreds of milliseconds in order to capture quick changes in the environment and/or process handover commands. On the other hand, Information Service messages are mainly exchanged each time a new network is visited that may be in the order of hours or days. For reliable delivery, short-lived connections could be set up as needed, although there is a connection setup latency associated with this approach. Alternatively, a long-lived connection could be used, but this requires advanced warning of being needed and some way to maintain the state associated with the connection. It also assumes that the relationships between devices supporting the mobility service are fairly stable. Another alternative is connectionless operation, but this has interactions with other requirements, such as reliable delivery.
低レイテンシー：モビリティサービスの中には、時間に敏感な情報を生成します。したがって、そこには非常に短い時間スケール上で情報を提供する必要がある、との接続に必要な寿命は非常に短命であるかもしれません。一例として、[1]で定義されたメッセージの頻度は、MIHサービスの種類に応じて変化します。イベントとコマンドメッセージが速い環境の変化および/またはプロセスのハンドオーバコマンドをキャプチャするために数百ミリ秒の間隔で到着することが予想されます。一方、情報サービス・メッセージは、主に数時間または数日間の順であってもよく、新たなネットワークが訪問するたびに交換されます。信頼性の高い配信のために、短時間の接続では、このアプローチに関連した接続設定待ち時間がありますが、必要に応じて設定することができます。また、長寿命の接続を使用することができるが、これは先進必要なことの警告および接続に関連した状態を維持するためにいくつかの方法が必要です。また、モビリティサービスをサポートするデバイス間の関係はかなり安定していることを前提としています。別の方法としては、コネクションレス操作ですが、これは、このような信頼性の高い配信など、他の要件との相互作用を持っています。
Reliability: Reliable delivery for some of the Mobility Services may be essential, but it is difficult to trade this off against the low latency requirement. It is also quite difficult to design a robust, high-performance mechanism that can operate in heterogeneous environments, especially one where the link characteristics can vary quite dramatically. There are two main approaches that could be adopted:
信頼性：モビリティサービスのいくつかのための信頼性の高い配信は不可欠かもしれないが、低遅延の要求に対して、これをトレードオフすることは困難です。異機種環境で動作することができ、堅牢で高性能なメカニズム、リンク特性はかなり劇的に変化することができ、特に1を設計することも極めて困難です。採用される可能性が二つの主要なアプローチがあります：
1. Assume the transport cannot be guaranteed to support reliable delivery. In this case, the Mobility Support Service itself will have to provide a reliability mechanism (at the MIH level) to allow communicating endpoints to acknowledge receipt of information.
1.トランスポートは、信頼性の高い配信をサポートすることを保証することはできないものとします。この場合には、モビリティサポートサービス自体は、情報の受信を確認するためにエンドポイントと通信できるようにする（MIHレベル）の信頼性メカニズムを提供しなければなりません。
2. Assume the underlying transport will provide reliable delivery. There is no need in this case to provide reliability at the MIH level.
2.基礎となるトランスポートが信頼性の高い配信を提供しますと仮定します。 MIHレベルでの信頼性を提供するために、この場合の必要はありません。
Guidelines provided in [3] are being considered while writing this document.
この文書を書いている間、[3]で提供ガイドラインが検討されています。
Congestion Control: A Mobility Service may wish to transfer small or large amounts of data, placing different requirements for congestion control in the transport. As an example, the MIH message [1] size varies widely from about 30 bytes (for a broadcast capability discovery request) to be normally less than 64 KB, but may be greater than 64KB (for an IS MIH_Get_Information response primitive). A typical MIH message size for the Events and Commands Services service ranges between 50 to 100 bytes. The solution should consider different congestion control mechanisms depending on the amount of data generated by the application (MIH) as suggested in [3].
輻輳制御：モビリティサービスは、輸送に輻輳制御のためのさまざまな要件を置く、データの小規模または大規模な量を転送したいことがあります。一例として、MIHメッセージは、[1]のサイズは64 KBより通常小さくなるように（ブロードキャスト能力発見要求に対して）約30バイトから大きく変化するが、（IS MIH_Get_Information応答プリミティブのために）64キロバイトよりも大きくてもよいです。イベントおよびコマンドサービスのサービスのための典型的なMIHメッセージのサイズが50〜100バイトの範囲です。溶液[3]で提案されているように、アプリケーション（MIH）によって生成されたデータの量に応じて異なる輻輳制御メカニズムを検討すべきです。
Fragmentation and reassembly: ES and CS messages are small in nature, are sent frequently, and may wish trade reliability in order to satisfy the tight latency requirements. On the other hand, IS messages are more resilient in terms of latency constraints, and some long IS messages could exceed the MTU of the path to the destination. Depending on the choice of the transport protocol, different fragmentation and reassembly strategies are required.
断片化と再構築：ESとCSのメッセージは、自然の中で小さいですが、頻繁に送信され、厳しい待ち時間要件を満たすために、貿易の信頼性を望むことができます。一方、メッセージは、レイテンシ制約の面で、より弾力性のある、そして長いいくつかのメッセージは、宛先へのパスのMTUを超える可能性です。トランスポートプロトコルの選択に応じて、異なる断片化と再構築戦略が必要とされています。
Multihoming: For some Information Services exchanged with the MN, there is a possibility that the request and response messages could be carried over two different links. For example, a handover command request is on the current link while the response could be delivered on the new link. It is expected that the transport protocol is capable of receiving information via multiple links. It is also expected that the MSTP user combines information belonging to the same session/transaction. When mobility is applied, the underlying IP mobility mechanism should provide session continuity when required.
マルチホーミング：いくつかの情報サービスは、MNと交換するために、要求および応答メッセージは、2つの異なるリンク上で実施される可能性があります。応答は、新しいリンク上で配信することができながら、例えば、ハンドオーバコマンド要求は、現在のリンクの上にあります。トランスポートプロトコルは、複数のリンクを介して情報を受信することができることが期待されます。また、MSTPのユーザーが同じセッション/トランザクションに属する情報を組み合わせることが期待されます。モビリティが適用されると、必要な場合、基礎となるIPモビリティメカニズムは、セッション継続性を提供する必要があります。
IPv4 and IPv6 support: The MSTP must support both IPv4 and IPv6 including NAT traversal for IPv4 networks and firewall pass-through for IPv4 and IPv6 networks.
IPv4とIPv6のサポート：MSTPは、IPv4ネットワークのためのNATトラバーサルなど、IPv4とIPv6の両方をサポートしなければならないとパススルーファイアウォールIPv4とIPv6ネットワークのために。
Network-supported Mobility Services aim at improving decision making and management of dynamically connected hosts.
ネットワークがサポートするモビリティサービスを動的に接続されたホストの意思決定と経営の向上を目指しています。
Information Services may not require authorization of the client, but both Event and Command Services may authenticate message sources, particularly if they are mobile. Network-side service entities will typically need to provide proof of authority to serve visiting devices. Where signalling or radio operations can result from received messages, significant disruption may result from processing bogus or modified messages. The effect of processing bogus messages depends largely upon the content of the message payload, which is handled by the handover services application. Regardless of the variation in effect, message delivery mechanisms need to provide protection against tampering, spoofing, and replay attacks.
情報サービスは、クライアントの承認を必要としないかもしれませんが、イベントとコマンド・サービスの両方は、彼らが携帯している場合は特に、メッセージソースを認証することができます。ネットワーク側のサービスエンティティは、通常、訪問のデバイスにサービスを提供する権限の証拠を提供する必要があります。シグナリングまたは無線操作が受信したメッセージから生じ得る場合、有意な破壊は、偽のまたは修飾されたメッセージを処理することから生じ得ます。偽のメッセージを処理の効果は、主に、ハンドオーバ・サービス・アプリケーションによって処理されるメッセージのペイロードの内容に依存します。かかわらず、効果の変動、メッセージ配信メカニズムが改ざん、なりすまし、リプレイ攻撃に対する保護を提供する必要があります。
Sensitive and identifying information about a mobile device may be exchanged during handover-service message exchange. Since handover decisions are to be made based upon message exchanges, it may be possible to trace a user's movement between cells, or predict future movements, by inspecting handover service messages. In order to prevent such tracking, message confidentiality and message integrity should be available. This is particularly important because many mobile devices are associated with only one user, since divulging of such information may violate the user's privacy. Additionally, identifying information may be exchanged during security association construction. As this information may be used to trace users across cell boundaries, identity protection should be available, if possible, when establishing source addresses (SAs).
モバイルデバイスに関する機密および識別情報をハンドオーバサービスメッセージ交換中に交換することができます。ハンドオーバ決定はメッセージ交換に基づいて行われるべきであるので、セル間のユーザの動きを追跡することが可能であってもよいし、ハンドオーバ・サービス・メッセージを検査することによって、将来の動きを予測します。こうした追跡を防ぐために、メッセージの機密性とメッセージの完全性は、利用可能であるべきです。多くのモバイルデバイスは、ユーザーのプライバシーを侵害することがあり、そのような情報の漏洩いるので、一つだけのユーザーに関連付けられているので、これは特に重要です。また、識別情報は、セキュリティアソシエーションの構築中に交換することができます。この情報は、セルの境界を越えてユーザーを追跡するために使用することができるよう、可能な場合、送信元アドレス（SA）を確立する際に、ID保護は、利用可能であるべきです。
In addition, the user should not have to disclose its identity to the network (anymore than it needed to during authentication) in order to access the Mobility Support Services. For example, if the local network is just aware that an anonymous user with a subscription to "example.com" is accessing the network, the user should not have to divulge their true identity in order to access the Mobility Support Services available locally.
また、ユーザーは、モビリティサポートサービスにアクセスするためには、ネットワーク（それは、認証時に必要なもうよりも）にその身元を開示する必要はありません。ローカルネットワークは、サブスクリプションへの「example.com」との匿名ユーザーがネットワークにアクセスしていることだけを認識している場合たとえば、ユーザーがローカルで利用可能なモビリティサポートサービスにアクセスするために自分の正体を明かす必要はありません。
Finally, the NNs themselves will potentially be subject to denial-of-service attacks from MNs, and these problems will be exacerbated if operation of the Mobility Service protocols imposes a heavy computational load on the NNs. The overall design has to consider at what stage (e.g., discovery, transport layer establishment, and service-specific protocol exchange) denial-of-service prevention or mitigation should be built in.
最後に、NNは自身が潜在的のMNからのサービス拒否攻撃の対象となり、およびモビリティサービスプロトコルの動作がNNの上に重い計算負荷を課した場合、これらの問題が悪化します。設計全体が組み込まれるべきステージ（例えば、発見、トランスポート層の確立、およびサービス固有のプロトコル交換）サービス拒否予防又は緩和に考慮しなければなりません。
This document outlined a broad problem statement for the signalling of information elements across a network to support Mobility Services. In order to enable this type of signalling service, a need for a generic transport solution with certain transport and security properties was outlined. Whilst the motivation for considering this problem has come from work within IEEE 802.21, a desirable goal is to ensure that solutions to this problem are applicable to a wider range of Mobility Services.
この文書では、モビリティサービスをサポートするために、ネットワークを介して情報要素のシグナリングのための幅広い問題文を概説しました。シグナリングサービスを、このタイプのを有効にするためには、特定のトランスポートとセキュリティプロパティを持つ汎用的な輸送ソリューションの必要性が概説されました。この問題を考えるための動機はIEEE 802.21内の作業から来ている一方で、望ましい目標は、この問題に対する解決策は、モビリティサービスのより広い範囲に適用可能であることを確認することです。
It would be valuable to establish realistic performance goals for the solution to this common problem (i.e., transport and security aspects) using experience from previous IETF work in this area and knowledge about feasible deployment scenarios. This information could then be used as an input to other standards bodies in assisting them to design Mobility Services with feasible performance requirements.
実現可能な展開シナリオについて、前のIETFこの分野での作業や知識の経験を使用して、この共通の問題（すなわち、輸送、セキュリティ面）に対する解決策のための現実的なパフォーマンス目標を確立するために有益であろう。その後、この情報は実現可能な性能要件とモビリティサービスを設計するためにそれらを支援するには、他の標準化団体への入力として使用することができます。
Much of the functionality required for this problem is available from existing IETF protocols or combination thereof. This document takes no position on whether an existing protocol can be adapted for the solution or whether new protocol development is required. In either case, we believe that the appropriate skills for development of protocols in this area lie in the IETF.
この問題のために必要な機能の多くは、既存のIETFプロトコルまたはそれらの組み合わせから入手可能です。この文書では、既存のプロトコルを解決するために、または新しいプロトコルの開発が必要とされているかどうかを適応させることができるかどうかにはポジションを取りません。いずれの場合も、当社はIETFにおけるこの分野の嘘におけるプロトコルの開発のための適切なスキルと考えています。
Thanks to Subir Das, Juan Carlos Zuniga, Robert Hancock, and Yoshihiro Ohba for their input. Thanks to the IEEE 802.21 chair, Vivek Gupta, for coordinating the work and supporting the IETF liaison. Thanks to all IEEE 802.21 WG folks who contributed to this document indirectly.
彼らの入力のためのSubirダス、フアン・カルロス・スニガ、ロバートハンコック、および義弘大場に感謝します。 IEEE 802.21椅子のおかげで、ヴィヴェック・グプタ、仕事を調整し、IETFのリエゾンを支援します。間接的に、この文書に貢献し、すべてのIEEE 802.21 WGの人々に感謝します。
[1] "Draft IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services", IEEE LAN/MAN Draft IEEE P802.21/D07.00, July 2007.
[1] "ローカルおよびメトロポリタンエリアネットワークのためのIEEE規格のドラフト：メディア独立ハンドオーバサービス"、IEEE LAN / MANドラフトIEEE P802.21 / D07.00、2007年7月を。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for Application Designers", Work in Progress.
[3]エッゲルト、L.とG. Fairhurst、 "アプリケーションデザイナーのためのUDP使用上のガイドライン" が進行中で働いています。
[4] 3GPP, "3GPP system architecture evolution (SAE): Report on technical options and conclusions", 3GPP TR 23.882 0.10.1, February 2006.
[4] 3GPP、 "3GPPシステムアーキテクチャ・エボリューション（SAE）：技術的なオプションとの結論に関する報告書"、3GPP TR 23.882 0.10.1、2006年2月。
[5] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[5]パーキンス、C.、エド。、 "IPv4のIPモビリティサポート"、RFC 3344、2002年8月。
[6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[6]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[7] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[7]モスコウィッツ、R.とP. Nikander、 "ホストアイデンティティプロトコル（HIP）アーキテクチャ"、RFC 4423、2006年5月。
[8] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
[8] Eronen、P.、 "IKEv2のモビリティとマルチホーミングプロトコル（MOBIKE）"、RFC 4555、2006年6月。
[9] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.
[9] Koodli、R.、エド。、 "モバイルIPv6のための高速ハンドオーバ"、RFC 4068、2005年7月。
[10] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[10] Arkko、J.、編、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索（SEND）"、RFC 3971、2005年3月。
Contributors' Addresses
貢献者のアドレス
Eleanor Hepworth Siemens Roke Manor Research Roke Manor Romsey, SO51 5RE UK
エレノア・ヘップワースシーメンスRokeマナー研究Rokeマナーロムジー、SO51 5RE英国
EMail: eleanor.hepworth@roke.co.uk
メールアドレス：eleanor.hepworth@roke.co.uk
Srivinas Sreemanthula Nokia Research Center 6000 Connection Dr. Irving, TX 75028 USA
スリニバスSrimanthulaノキア・リサーチセンター6000接続博士アーヴィング、TX 75028 USA
EMail: srinivas.sreemanthula@nokia.com
メールアドレス：srinivas.sreemanthula@nokia.com
Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscateway NJ 08854 USA
義弘大場東芝アメリカリサーチ社1 TelcordiaのドライブPiscateway NJ 08854 USA
EMail: yohba@tari.toshiba.com
メールアドレス：yohba@tari.toshiba.com
Vivek Gupta Intel Corporation 2111 NE 25th Avenue Hillsboro, OR 97124 USA
ヴィヴェック・グプタインテルコーポレーション2111 NE 25日アベニューヒルズボロ、OR 97124 USA
Phone: +1 503 712 1754 EMail: vivek.g.gupta@intel.com
電話：+1 503 712 1754 Eメール：vivek.g.gupta@intel.com
Jouni Korhonen TeliaSonera Corporation. P.O.Box 970 FIN-00051 Sonera FINLAND
Jouni Korhonenテリアソネラ社。 P.O.Box 970 FIN-00051 Soneraフィンランド
Phone: +358 40 534 4455 EMail: jouni.korhonen@teliasonera.com
電話番号：+358 40 534 4455 Eメール：jouni.korhonen@teliasonera.com
Rui L.A. Aguiar Instituto de Telecomunicacoes Universidade de Aveiro Aveiro 3810 Portugal
アヴェイロ3810ポルトガルの通信大学のL.A.ルイ・アギアル研究所
Phone: +351 234 377900 EMail: ruilaa@det.ua.pt
電話番号：+351 234 377900 Eメール：ruilaa@det.ua.pt
Sam(Zhongqi) Xia Huawei Technologies Co., Ltd HuaWei Bld., No.3 Xinxi Rd. Shang-Di Information Industry Base 100085 Hai-Dian District Beijing, P.R. China
サム（Z紅旗）ξああUA技術有限公司胡ああ魏BLの。、ラインRDで3番X。シャン-DI情報産業基地100085時間の愛-Dイアン地区北京、中華人民共和国など
Phone: +86-10-82836136 EMail: xiazhongqi@huawei.com
電話：+ 86-10-82836136 Eメール：xiazhongqi@huawei.com
Authors' Addresses
著者のアドレス
Telemaco Melia, Editor Cisco Systems International Sarl Avenue des Uttins 5 1180 Rolle Switzerland (FR)
Telemacoメリア、エディタシスコシステムズ・インターナショナルSarlはアベニューデUttins 5 1180ロルスイス（FR）
Phone: +41 21 822718 EMail: tmelia@cisco.com
電話：+41 21 822718 Eメール：tmelia@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。