[要約] RFC 5164は、モビリティサービスのトランスポートに関する問題を述べたものであり、モビリティサービスのトランスポートに関連する課題を明確にすることを目的としています。
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.
ネットワーキングコミュニティでは、IEEE 802.21を含むがこれらに限定されない、不均一な有線システムとワイヤレスアクセスシステムの間のIPハンドオーバーメカニズムを支援するソリューションを開発するための継続的なアクティビティがあります。リンク層属性を考慮して、インテリジェントアクセスの選択には、ネットワーク内のさまざまなソースから端末へのさまざまな情報タイプの配信が必要です。このシグナリングのプロトコル要件には、考慮しなければならない輸送とセキュリティの両方の問題があります。シグナル伝達を特定のリンクタイプに制約してはならないため、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 [1]によって定義されているメディア独立ハンドオーバー（MIH）プロトコルのトランスポートを提供する必要性から生じています。レイヤーホップ。ソリューションは、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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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）管理のさまざまなサポート機能は、一般に、輸送プロトコルの要件が異なるモビリティサービス（MO）と呼ばれます。これらの要件と関連する機能は、このドキュメントの焦点です。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-To-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と2番目のNNの間でエンドツーエンドで実行されます。ただし、このシナリオでは、IP以外のいくつかの輸送手段がMNから最初のNNに使用され、IP上のトランスポートはNNの間でのみ使用されます。これは、サプリカントと認証サーバー間のEAPエンドツーエンドの使用に類似しています。リモート認証ダイヤルインユーザーサービス（RADIUS）などの上層層マルチホッププロトコルは、アクセスポイント間のバックホールトランスポートプロトコルとして使用されます。および認証サーバー。
+------+ +------+ +------+
| 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）情報が含まれます。Mobility Service Transport Headerの定義は、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:
発見：MNSには、特定のサービスをサポートするノードを発見するか、特定のノードが提供するサービスを発見する機能が必要です。サービスの発見は、[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.
* MNへのハードコーディング情報。NNのIPアドレス、またはIPアドレスに解決できるNNに関する情報のいずれかを示します。構成情報は動的に管理できますが、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.
* 情報がMNにプッシュされます。ここでは、他の構成操作の一部として、たとえばDHCPまたはルーター発見交換を介して情報が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は、特定のサービス発見メカニズムのMNとNNの両方のサポートが必要になる場合があるノードに関する情報を動的に要求します。これには、サービス自体を直接サポートしていない場合でも、アクセスネットワーク（マルチキャストなど）による追加のサポートが必要になる場合があります。
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.
多数のディレクトリおよび構成サービスがすでに存在しており、これらのメカニズムの再利用が適切かもしれません。複数の発見方法が必要かどうか、およびNNSが他のNNSを発見する必要があるかどうかについては、未解決の質問があります。説明の粒度を含め、サービスの定義も決定する必要があります。たとえば、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）インフラストラクチャ、または送信をサポートするために必要な証明書インフラストラクチャに関する認証、承認、および会計（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サービスタイプによって異なります。イベントとコマンドメッセージは、環境および/またはプロセスハンドオーバーコマンドの迅速な変更をキャプチャするために、数百ミリ秒の間隔に到達することが期待されています。一方、情報サービスメッセージは、数時間または数日の順に新しいネットワークが訪問されるたびに、主に交換されます。信頼できる配信のために、このアプローチに関連付けられた接続セットアップレイテンシがありますが、短命の接続を必要に応じてセットアップできます。あるいは、長寿命の接続を使用することもできますが、これには必要であるという高度な警告と、接続に関連する状態を維持するための何らかの方法が必要です。また、モビリティサービスをサポートするデバイス間の関係はかなり安定していると想定しています。もう1つの選択肢は、ConnectionLess操作ですが、これには信頼できる配信など、他の要件とのやり取りがあります。
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:
信頼性：一部のモビリティサービスの信頼できる配信は不可欠かもしれませんが、これを低レイテンシー要件と格闘することは困難です。また、異種の環境で動作できる堅牢で高性能のメカニズムを設計することも非常に困難です。特に、リンク特性が非常に劇的に変化する可能性があります。採用できる2つの主なアプローチがあります。
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未満であるが、64kbを超える（AN IS MIH_GET_INFORMATION RESPONSITITION PRIMITITITの場合）、約30バイト（ブロードキャスト能力ディスカバリーリクエストの場合）から大きく異なります。イベントおよびコマンドサービスサービスの典型的な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メッセージは本質的に小さく、頻繁に送信され、厳しい遅延要件を満たすために貿易の信頼性を希望する場合があります。一方、ISはレイテンシの制約の点でより回復力があり、いくつかの長いメッセージは、宛先へのパスの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.
Multihoming：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).
モバイルデバイスに関する機密情報と識別情報は、ハンドオーバーサービスのメッセージ交換中に交換される場合があります。メッセージ交換に基づいてハンドオーバーの決定は行われるため、ハンドオーバーサービスメッセージを検査することにより、ユーザーの動きを追跡したり、将来の動きを予測することができる場合があります。このような追跡を防ぐために、メッセージの機密性とメッセージの整合性を利用できるようにする必要があります。多くのモバイルデバイスは1人のユーザーのみに関連付けられているため、これは特に重要です。そのような情報を漏らすとユーザーのプライバシーに違反する可能性があるためです。さらに、識別情報は、セキュリティ協会の建設中に交換される場合があります。この情報は、セルの境界を越えてユーザーを追跡するために使用される場合があるため、ソースアドレス（SAS）を確立するときに、可能であればアイデンティティ保護が利用可能である必要があります。
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.
さらに、モビリティサポートサービスにアクセスするために、ユーザーはネットワークにIDをネットワークに開示する必要はありません（認証中に必要以上に）。たとえば、ローカルネットワークが「Example.com」のサブスクリプションを持つ匿名ユーザーがネットワークにアクセスしていることを認識している場合、ユーザーはローカルで利用可能なモビリティサポートサービスにアクセスするために真のIDを漏らす必要はありません。
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.
最後に、NNS自体はMNSからのサービス拒否攻撃の対象となる可能性があり、モビリティサービスプロトコルの動作がNNSに重い計算負荷を課す場合、これらの問題は悪化します。全体的な設計では、どの段階で（発見、輸送層の確立、サービス固有のプロトコル交換など）サービス拒否予防または緩和を構築する必要があります。
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 Das、Juan Carlos Zuniga、Robert Hancock、およびYoshihiro Ohbaに感謝します。IEEE 802.21議長のVivek Guptaに、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for Application Designers", Work in Progress.
[3] Eggert、L。and 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] Perkins、C.、ed。、「IPv4のIPモビリティサポート」、RFC 3344、2002年8月。
[6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[6] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[7] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[7] Moskowitz、R。およびP. Nikander、「Host Identity Protocol（HIP）Architecture」、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.、ed。、「モバイル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.、ed。、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（Send）」、RFC 3971、2005年3月。
Contributors' Addresses
貢献者の住所
Eleanor Hepworth Siemens Roke Manor Research Roke Manor Romsey, SO51 5RE UK
エレノア・ヘップワース・シーメンス・ローク・マナー研究ローク・マナー・ロンシー、SO51 5RE UK
EMail: eleanor.hepworth@roke.co.uk
Srivinas Sreemanthula Nokia Research Center 6000 Connection Dr. Irving, TX 75028 USA
Srinivas Srimanthula Nokia Research Center 6000 Connection Dr. Irving、TX 75028 USA
EMail: srinivas.sreemanthula@nokia.com
Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscateway NJ 08854 USA
Yoshihiro Ohba Toshiba America Research、Inc。1 Telcordia Drive Piscateway NJ 08854 USA
EMail: yohba@tari.toshiba.com
Vivek Gupta Intel Corporation 2111 NE 25th Avenue Hillsboro, OR 97124 USA
Vivek Gupta Intel Corporation 2111 NE 25th Avenue Hillsboro、または97124 USA
Phone: +1 503 712 1754 EMail: vivek.g.gupta@intel.com Jouni Korhonen TeliaSonera Corporation. P.O.Box 970 FIN-00051 Sonera FINLAND
電話：1 503 712 1754メール：Vivek.G.Gupta@intel.com Jouni Korhonen Teliasonera Corporation。P.O.Box 970 FIN-00051 SONERA FINLAND
Phone: +358 40 534 4455
EMail: jouni.korhonen@teliasonera.com
Rui L.A. Aguiar Instituto de Telecomunicacoes Universidade de Aveiro Aveiro 3810 Portugal
Rui L.A. Aguiar Instituto de Telecomunicacoes Universidade de aveiro aveiro 3810ポルトガル
Phone: +351 234 377900
EMail: 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
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
Phone: +86-10-82836136
EMail: xiazhongqi@huawei.com
Authors' Addresses
著者のアドレス
Telemaco Melia, Editor Cisco Systems International Sarl Avenue des Uttins 5 1180 Rolle Switzerland (FR)
Telemaco Melia、編集者Cisco Systems International Sarl Avenue Des Uttins 5 1180 Rolle Switzerland（FR）
Phone: +41 21 822718
EMail: tmelia@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。