[要約] RFC 5677は、IEEE 802.21 Mobility Services Framework Design（MSFD）の要約と目的を提供します。このフレームワークは、異なるネットワーク間でのモビリティサービスの提供を容易にするために設計されています。
Network Working Group T. Melia, Ed.
Request for Comments: 5677 Alcatel-Lucent
Category: Standards Track G. Bajko
Nokia
S. Das
Telcordia Technologies Inc.
N. Golmie
NIST
JC. Zuniga
InterDigital Communications, LLC
December 2009
IEEE 802.21 Mobility Services Framework Design (MSFD)
IEEE 802.21モビリティサービスフレームワーク設計（MSFD）
Abstract
概要
This document describes a mobility services framework design (MSFD) for the IEEE 802.21 Media Independent Handover (MIH) protocol that addresses identified issues associated with the transport of MIH messages. The document also describes mechanisms for Mobility Services (MoS) discovery and transport-layer mechanisms for the reliable delivery of MIH messages. This document does not provide mechanisms for securing the communication between a mobile node (MN) and the Mobility Server. Instead, it is assumed that either lower-layer (e.g., link-layer) security mechanisms or overall system-specific proprietary security solutions are used.
このドキュメントでは、MIHメッセージの輸送に関連する特定された問題に対処するIEEE 802.21 Media Independent Handover（MIH）プロトコルのモビリティサービスフレームワーク設計（MSFD）について説明します。このドキュメントでは、MIHメッセージの信頼できる配信のためのモビリティサービス（MOS）の発見および輸送層メカニズムのメカニズムについても説明しています。このドキュメントは、モバイルノード（MN）とモビリティサーバー間の通信を保護するためのメカニズムを提供しません。代わりに、低層（リンク層）セキュリティメカニズムまたはシステム固有の独自のセキュリティソリューション全体が使用されると想定されています。
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
IESG Note
IESGノート
As described later in this specification, this protocol does not provide security mechanisms. In some deployment situations lower-layer security services may be sufficient. Other situations require proprietary mechanisms or as yet incomplete standard mechanisms, such as the ones currently considered by IEEE. For these reasons, the specification recommends careful analysis before considering any deployment.
この仕様で後で説明したように、このプロトコルはセキュリティメカニズムを提供しません。一部の展開状況では、低層セキュリティサービスで十分かもしれません。他の状況には、現在IEEEが考慮しているような独自のメカニズムまたはまだ不完全な標準メカニズムが必要です。これらの理由により、仕様は展開を検討する前に慎重な分析を推奨します。
The IESG emphasizes the importance of these recommendations. The IESG also notes that this specification deviates from the traditional IETF requirement that support for security in the open Internet environment is a mandatory part of any Standards Track protocol specification. An exception has been made for this specification, but this should not be taken to mean that other future specifications are free from this requirement.
IESGは、これらの推奨事項の重要性を強調しています。IESGはまた、この仕様は、オープンなインターネット環境でのセキュリティのサポートが、標準の追跡プロトコル仕様の必須部分であるという従来のIETF要件から逸脱していることに注目しています。この仕様には例外が作成されていますが、これは、他の将来の仕様がこの要件がないことを意味することを意味するものではありません。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、BSDライセンスに記載されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................4
2. Terminology .....................................................4
2.1. Requirements Language ......................................7
3. Deployment Scenarios ............................................7
3.1. Scenario S1: Home Network MoS ..............................8
3.2. Scenario S2: Visited Network MoS ...........................8
3.3. Scenario S3: Third-Party MoS ...............................9
3.4. Scenario S4: Roaming MoS ...................................9
4. Solution Overview ..............................................10
4.1. Architecture ..............................................11
4.2. MIHF Identifiers (FQDN, NAI) ..............................12
5. MoS Discovery ..................................................12
5.1. MoS Discovery When MN and MoSh Are in the Home
Network (Scenario S1) .....................................13
5.2. MoS Discovery When MN and MoSv Both Are in Visited
Network (Scenario S2) .....................................14
5.3. MoS Discovery When MIH Services Are in a
Third-Party Remote Network (Scenario S3) ..................14
5.4. MoS Discovery When the MN Is in a Visited Network
and Services Are at the Home Network (Scenario S4) ........15
6. MIH Transport Options ..........................................15
6.1. MIH Message Size ..........................................16
6.2. MIH Message Rate ..........................................17
6.3. Retransmission ............................................17
6.4. NAT Traversal .............................................18
6.5. General Guidelines ........................................18
7. Operation Flows ................................................19
8. Security Considerations ........................................21
8.1. Security Considerations for MoS Discovery .................21
8.2. Security Considerations for MIH Transport .................21
9. IANA Considerations ............................................22
10. Acknowledgements ..............................................23
11. References ....................................................23
11.1. Normative References .....................................23
11.2. Informative References ...................................23
This document proposes a solution to the issues identified in the problem statement document [RFC5164] for the layer 3 transport of IEEE 802.21 MIH protocols.
このドキュメントは、IEEE 802.21 MIHプロトコルのレイヤー3輸送について、問題ステートメントドキュメント[RFC5164]で特定された問題の解決策を提案しています。
The MIH Layer 3 transport problem is divided into two main parts: the discovery of a node that supports specific Mobility Services (MoS) and the transport of the information between a mobile node (MN) and the discovered node. The discovery process is required for the MN to obtain the information needed for MIH protocol communication with a peer node. The information includes the transport address (e.g., the IP address) of the peer node and the types of MoS provided by the peer node.
MIHレイヤー3トランスポートの問題は、特定のモビリティサービス（MO）をサポートするノードの発見と、モバイルノード（MN）と発見されたノード間の情報の輸送の2つの主要部分に分けられます。MNがピアノードとのMIHプロトコル通信に必要な情報を取得するには、MNが発見プロセスが必要です。情報には、ピアノードのトランスポートアドレス（例：IPアドレス）と、ピアノードが提供するMOSのタイプが含まれます。
This document lists the major MoS deployment scenarios. It describes the solution architecture, including the MSFD reference model and MIHF identifiers. MoS discovery procedures explain how the MN discovers Mobility Servers in its home network, in a visited network or in a third-party network. The remainder of this document describes the MIH transport architecture, example message flows for several signaling scenarios, and security issues.
このドキュメントには、主要なMOS展開シナリオがリストされています。MSFD参照モデルとMIHF識別子を含むソリューションアーキテクチャについて説明します。MOSディスカバリー手順では、MNがホームネットワーク、訪問されたネットワーク、またはサードパーティネットワークでモビリティサーバーをどのように発見するかを説明しています。このドキュメントの残りの部分では、MIH輸送アーキテクチャ、いくつかのシグナル伝達シナリオのメッセージフローの例、およびセキュリティの問題について説明しています。
This document does not provide mechanisms for securing the communication between a mobile node and the Mobility Server. Instead, it is assumed that either lower layer (e.g., link layer) security mechanisms, or overall system-specific proprietary security solutions, are used. The details of such lower layer and/or proprietary mechanisms are beyond the scope of this document. It is RECOMMENDED against using this protocol without careful analysis that these mechanisms meet the desired requirements, and encourages future standardization work in this area. The IEEE 802.21a Task Group has recently started work on MIH security issues that may provide some solution in this area. For further information, please refer to Section 8.
このドキュメントは、モバイルノードとモビリティサーバー間の通信を保護するためのメカニズムを提供しません。代わりに、下層（リンク層など）セキュリティメカニズム、またはシステム固有の独自のセキュリティソリューション全体が使用されると想定されています。このような下層および/または独自のメカニズムの詳細は、このドキュメントの範囲を超えています。これらのメカニズムが望ましい要件を満たしていることを慎重に分析することなく、このプロトコルを使用することをお勧めし、この分野での将来の標準化作業を促進します。IEEE 802.21Aタスクグループは最近、この分野で何らかの解決策を提供するMIHセキュリティの問題に関する作業を開始しました。詳細については、セクション8を参照してください。
The following acronyms and terminology are used in this document:
このドキュメントでは、次の頭字語と用語が使用されています。
Media Independent Handover (MIH): the handover support architecture defined by the IEEE 802.21 working group that consists of the MIH Function (MIHF), MIH Network Entities, and MIH protocol messages.
Media Independent Handover（MIH）：MIH関数（MIHF）、MIHネットワークエンティティ、およびMIHプロトコルメッセージで構成されるIEEE 802.21ワーキンググループによって定義されたハンドオーバーサポートアーキテクチャ。
Media Independent Handover Function (MIHF): a switching function that provides handover services including the Event Service (ES), Information Service (IS), and Command Service (CS), through service access points (SAPs) defined by the IEEE 802.21 working group [IEEE80221].
Media Independent Handover Function（MIHF）：IEEE 802.21ワーキンググループによって定義されたサービスアクセスポイント（SAP）を介して、イベントサービス（ES）、情報サービス（IS）、コマンドサービス（CS）を含むハンドオーバーサービスを提供するスイッチング関数[IEEE80221]。
MIHF User: An entity that uses the MIH SAPs to access MIHF services, and which is responsible for initiating and terminating MIH signaling.
MIHFユーザー：MIH SAPSを使用してMIHFサービスにアクセスし、MIHシグナリングの開始と終了を担当するエンティティ。
Media Independent Handover Function Identifier (MIHFID): an identifier required to uniquely identify the MIHF endpoints for delivering mobility services (MoS); it is implemented as either a FQDN or NAI.
Media Independent Handover関数識別子（MIHFID）：モビリティサービス（MOS）を提供するためのMIHFエンドポイントを一意に識別するために必要な識別子。FQDNまたはNAIのいずれかとして実装されています。
Mobility Services (MoS): composed of Information Service, Command Service, and Event Service provided by the network to mobile nodes to facilitate handover preparation and handover decision, as described in [IEEE80221] and [RFC5164].
Mobility Services（MOS）：[IEEE80221]および[RFC5164]で説明されているように、ハンドオーバーの準備とハンドオーバー決定を容易にするために、ネットワークがモバイルノードに提供する情報サービス、コマンドサービス、およびイベントサービスで構成されています。
MoSh: Mobility Services provided by the mobile node's Home Network.
MOSH：モバイルノードのホームネットワークが提供するモビリティサービス。
MoSv: Mobility Services provided by the Visited Network.
MOSV：訪問されたネットワークが提供するモビリティサービス。
MoS3: Mobility Services provided by a third-party network, which is a network that is neither the Home Network nor the current Visited Network.
MOS3：ホームネットワークでも現在の訪問ネットワークでもないネットワークであるサードパーティネットワークが提供するモビリティサービス。
Mobile Node (MN): an Internet device whose location changes, along with its point of connection to the network.
モバイルノード（MN）：ネットワークへの接続ポイントとともに、場所が変化するインターネットデバイス。
Mobility Services Transport Protocol (MSTP): a protocol that is used to deliver MIH protocol messages from an MIHF to other MIH-aware nodes in a network.
Mobility Services Transport Protocol（MSTP）：MIHFからネットワーク内の他のMIH対応ノードにMIHプロトコルメッセージを提供するために使用されるプロトコル。
Information Service (IS): a MoS that originates at the lower or upper layers of the protocol stack and sends information to the local or remote upper or lower layers of the protocol stack. The purpose of IS is to exchange information elements (IEs) relating to various neighboring network information.
情報サービス（IS）：プロトコルスタックの下層または上層層で発生するMOSを送信し、プロトコルスタックのローカルまたはリモートの上層または下層に情報を送信します。の目的は、さまざまな隣接するネットワーク情報に関連する情報要素（IE）を交換することです。
Event Service (ES): a MoS that originates at a remote MIHF or the lower layers of the local protocol stack and sends information to the local MIHF or local higher layers. The purpose of the ES is to report changes in link status (e.g., Link Going Down messages) and various lower layer events.
イベントサービス（ES）：リモートMIHFまたはローカルプロトコルスタックの下層層で発生するMOSは、ローカルMIHFまたはローカル高層に情報を送信します。ESの目的は、リンクステータス（例：リンクダウンメッセージ）およびさまざまな下層イベントの変更を報告することです。
Command Service (CS): a MoS that sends commands from the remote MIHF or local upper layers to the remote or local lower layers of the protocol stack to switch links or to get link status.
コマンドサービス（CS）：リモートMIHFまたはローカル上層層からコマンドを送信するMOSは、リンクを切り替えるかリンクステータスを取得するために、プロトコルスタックのリモートまたはローカル下層にローカル下層に送信します。
Fully Qualified Domain Name (FQDN): a complete domain name for a host on the Internet, showing (in reverse order) the full delegation path from the DNS root and top-level domain down to the host name (e.g., myexample.example.org).
完全資格のドメイン名（FQDN）：インターネット上のホストの完全なドメイン名。（逆順序で）DNSルートおよびトップレベルのドメインからホスト名（例：myexample.example」までの完全な委任パスを表示します。組織）。
Network Access Identifier (NAI): the user ID that a user submits during network access authentication [RFC4282]. For mobile users, the NAI identifies the user and helps to route the authentication request message.
ネットワークアクセス識別子（NAI）：ユーザーがネットワークアクセス認証中に提出するユーザーID [RFC4282]。モバイルユーザーの場合、NAIはユーザーを識別し、認証要求メッセージのルーティングを支援します。
Network Address Translator (NAT): a device that implements the Network Address Translation function described in [RFC3022], in which local or private network layer addresses are mapped to routable (outside the NAT domain) network addresses and port numbers.
ネットワークアドレス翻訳者（NAT）：[RFC3022]に記載されているネットワークアドレス変換関数を実装するデバイス。ローカルまたはプライベートネットワークレイヤーアドレスは、ルーティング可能な（NATドメイン外）ネットワークアドレスとポート番号にマッピングされます。
Dynamic Host Configuration Protocol (DHCP): protocols described in [RFC2131] and [RFC3315] that allow Internet devices to obtain respectively IPv4 and IPv6 addresses, subnet masks, default gateway addresses, and other IP configuration information from DHCP servers.
動的ホスト構成プロトコル（DHCP）：インターネットデバイスがそれぞれIPv4およびIPv6アドレス、サブネットマスク、デフォルトゲートウェイアドレス、およびDHCPサーバーからその他のIP構成情報を取得できるようにする[RFC2131]および[RFC3315]で説明されているプロトコル。
Domain Name System (DNS): a protocol described in [RFC1035] that translates domain names to IP addresses.
ドメイン名システム（DNS）：ドメイン名をIPアドレスに変換する[RFC1035]で説明されているプロトコル。
Authentication, Authorization, and Accounting (AAA): a set of network management services that respectively determine the validity of a user's ID, determine whether a user is allowed to use network resources, and track users' use of network resources.
認証、承認、および会計（AAA）：ユーザーのIDの有効性をそれぞれ決定し、ユーザーがネットワークリソースの使用を許可されているかどうかを判断し、ユーザーのネットワークリソースの使用を追跡するネットワーク管理サービスのセット。
Home AAA (AAAh): an AAA server located on the MN's home network.
Home AAA（AAAH）：MNのホームネットワークにあるAAAサーバー。
Visited AAA (AAAv): an AAA server located in a visited network that is not the MN's home network.
訪問AAA（AAAV）：MNのホームネットワークではない訪問されたネットワークにあるAAAサーバー。
MIH Acknowledgement (MIH ACK): an MIH signaling message that an MIHF sends in response to an MIH message from a sending MIHF.
MIH Ancountigment（MIH ACK）：MIHFが送信MIHFからのMIHメッセージに応答して送信するMIHシグナル伝達メッセージ。
Point of Service (PoS): a network-side MIHF instance that exchanges MIH messages with an MN-based MIHF.
Point of Service（POS）：MNベースのMIHFとMIHメッセージを交換するネットワーク側MIHFインスタンス。
Network Access Server (NAS): a server to which an MN initially connects when it is trying to gain a connection to a network and that determines whether the MN is allowed to connect to the NAS's network.
ネットワークアクセスサーバー（NAS）：ネットワークへの接続を取得しようとしているときにMNが最初に接続し、MNがNASのネットワークに接続できるかどうかを決定するサーバー。
User Datagram Protocol (UDP): a connectionless transport-layer protocol used to send datagrams between a source and a destination at a given port, defined in RFC 768.
ユーザーデータグラムプロトコル（UDP）：RFC 768で定義された特定のポートのソースと宛先の間にデータグラムを送信するために使用されるコネクションレストランスポート層プロトコル。
Transmission Control Protocol (TCP): a stream-oriented transport-layer protocol that provides a reliable delivery service with congestion control, defined in RFC 793.
トランスミッションコントロールプロトコル（TCP）：RFC 793で定義された輻輳制御を備えた信頼できる配信サービスを提供するストリーム指向の輸送層プロトコル。
Round-Trip Time (RTT): an estimation of the time required for a segment to travel from a source to a destination and an acknowledgement to return to the source that is used by TCP in connection with timer expirations to determine when a segment is considered lost and should be resent.
往復時間（RTT）：セグメントがソースから宛先に移動するのに必要な時間の推定と、タイマーの満足度に関連して使用されるソースに戻るために、セグメントが考慮される時期を判断するためにTCPによって使用されるソースに戻ることの承認失われ、resする必要があります。
Maximum Transmission Unit (MTU): the largest size of an IP packet that can be sent on a network segment without requiring fragmentation [RFC1191].
最大送信ユニット（MTU）：フラグメンテーションを必要とせずにネットワークセグメントで送信できるIPパケットの最大サイズ[RFC1191]。
Path MTU (PMTU): the largest size of an IP packet that can be sent on an end-to-end network path without requiring IP fragmentation.
PATH MTU（PMTU）：IP断片化を必要とせずにエンドツーエンドネットワークパスで送信できるIPパケットの最大サイズ。
Transport Layer Security Protocol (TLS): an application layer protocol that primarily assures privacy and data integrity between two communicating network entities [RFC5246].
トランスポートレイヤーセキュリティプロトコル（TLS）：主に2つの通信ネットワークエンティティ[RFC5246]間のプライバシーとデータの整合性を保証するアプリケーションレイヤープロトコル。
Sender Maximum Segment Size (SMSS): size of the largest segment that the sender can transmit as per [RFC5681].
送信者の最大セグメントサイズ（SMSS）：送信者が[RFC5681]に従って送信できる最大セグメントのサイズ。
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 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
This section describes the various possible deployment scenarios for the MN and the Mobility Server. The relative positioning of the MN and Mobility Server affects MoS discovery as well as the performance of the MIH signaling service. This document addresses the scenarios listed in [RFC5164] and specifies transport options to carry the MIH protocol over IP.
このセクションでは、MNおよびMobility Serverのさまざまな展開シナリオについて説明します。MNとモビリティサーバーの相対的な位置付けは、MOS発見とMIHシグナル伝達サービスのパフォーマンスに影響します。このドキュメントは、[RFC5164]にリストされているシナリオに対応し、MIHプロトコルをIPよりも運ぶためのトランスポートオプションを指定します。
In this scenario, the MN and the services are located in the home network. We refer to this set of services as MoSh as shown in Figure 1. The MoSh can be located at the access network the MN uses to connect to the home network, or it can be located elsewhere.
このシナリオでは、MNとサービスはホームネットワークにあります。図1に示すように、このサービスセットをMOSHと呼びます。MOSHは、MNがホームネットワークに接続するために使用するアクセスネットワークに配置するか、他の場所に配置できます。
+--------------+ +====+
| HOME NETWORK | |MoSh|
+--------------+ +====+
/\
||
\/
+--------+
| MN |
+--------+
Figure 1: MoS in the Home Network
図1：ホームネットワーク内のMOS
In this scenario, the MN is in the visited network and mobility services are provided by the visited network. We refer to this as MoSv as shown in Figure 2.
このシナリオでは、MNは訪問されたネットワークにあり、モビリティサービスは訪問されたネットワークによって提供されます。図2に示すように、これをMOSVと呼びます。
+--------------+
| HOME NETWORK |
+--------------+
/\
||
\/
+====+ +-----------------+
|MoSv| | VISITED NETWORK |
+====+ +-----------------+
/\
||
\/
+--------+
| MN |
+--------+
Figure 2: MoSv in the Visited Network
図2：訪問されたネットワーク内のMOSV
In this scenario, the MN is in its home network or in a visited network and services are provided by a third-party network. We refer to this situation as MoS3 as shown in Figure 3. (Note that MoS can exist both in home and in visited networks.)
このシナリオでは、MNはホームネットワークまたは訪問されたネットワークにあり、サービスはサードパーティネットワークによって提供されます。図3に示すように、この状況をMOS3と呼びます（MOSは自宅と訪問ネットワークの両方に存在できることに注意してください。）
+--------------+
| HOME NETWORK |
+====+ +--------------+ +--------------+
|MoS3| | THIRD PARTY | <===> /\
+====+ +--------------+ ||
\/
+-----------------+
| VISITED NETWORK |
+-----------------+
/\
||
\/
+--------+
| MN |
+--------+
Figure 3: MoS from a Third Party
図3：サードパーティのMOS
In this scenario, the MN is located in the visited network and all MIH services are provided by the home network, as shown in Figure 4.
このシナリオでは、MNは訪問されたネットワークにあり、図4に示すように、すべてのMIHサービスはホームネットワークによって提供されます。
+====+ +--------------+
|MoSh| | HOME NETWORK |
+====+ +--------------+
/\
||
\/
+-----------------+
| VISITED NETWORK |
+-----------------+
/\
||
\/
+--------+
| MN |
+--------+
Figure 4: MoS Provided by the Home While in Visited
図4：訪問中に家から提供されたMOS
Different types of MoS can be provided independently of other types and there is no strict relationship between ES, CS, and IS, nor is there a requirement that the entities that provide these services should be co-located. However, while IS tends to involve a large amount of static information, ES and CS are dynamic services and some relationships between them can be expected, e.g., a handover command (CS) could be issued upon reception of a link event (ES). This document does not make any assumption on the location of the MoS (although there might be some preferred configurations), and aims at flexible MSFD to discover different services in different locations to optimize handover performance. MoS discovery is discussed in more detail in Section 5.
さまざまなタイプのMOは、他のタイプとは独立して提供でき、ES、CSの間に厳格な関係はありません。また、これらのサービスを提供するエンティティを共同配置する必要があるという要件もありません。ただし、大量の静的情報を含む傾向がありますが、ESとCSは動的サービスであり、それらの間のいくつかの関係が予想される可能性があります。このドキュメントでは、MOの場所について仮定しません（いくつかの優先構成があるかもしれませんが）。柔軟なMSFDを目指して、さまざまな場所で異なるサービスを発見して、ハンドオーバーパフォーマンスを最適化します。MOS発見については、セクション5で詳しく説明します。
As mentioned in Section 1, the solution space is being divided into two functional domains: discovery and transport. The following assumptions have been made:
セクション1で述べたように、ソリューション空間は、発見と輸送という2つの機能的なドメインに分割されています。次の仮定がなされています。
o The solution is primarily aimed at supporting IEEE 802.21 MIH services -- namely, Information Service (IS), Event Service (ES), and Command Service (CS).
o このソリューションは、主にIEEE 802.21 MIHサービス、つまり情報サービス（IS）、イベントサービス（ES）、およびコマンドサービス（CS）をサポートすることを目的としています。
o If the MIHFID is available, FQDN or NAI's realm is used for mobility service discovery.
o MIHFIDが利用可能な場合、FQDNまたはNAIの領域はモビリティサービスの発見に使用されます。
o The solutions are chosen to cover all possible deployment scenarios as described in Section 3.
o セクション3で説明されているように、すべての可能な展開シナリオをカバーするためにソリューションが選択されます。
o MoS discovery can be performed during initial network attachment or at any time thereafter.
o MOSディスカバリーは、最初のネットワーク添付時またはその後いつでも実行できます。
The MN may know the realm of the Mobility Server to be discovered. The MN may also be pre-configured with the address of the Mobility Server to be used. In case the MN does not know what realm / Mobility Server to query, dynamic assignment methods are described in Section 5.
MNは、発見されるモビリティサーバーの領域を知っている可能性があります。MNは、使用するモビリティサーバーのアドレスと事前に構成されている場合があります。MNがどのレルム /モビリティサーバーをクエリするかを知らない場合、動的割り当て方法はセクション5で説明されています。
The discovery of the Mobility Server (and the related configuration at MIHF level) is required to bind two MIHF peers (e.g., MN and Mobility Server) with their respective IP addresses. Discovery MUST be executed in the following conditions:
モビリティサーバーの発見（およびMIHFレベルでの関連する構成）は、2つのMIHFピア（MNやMobility Serverなど）をそれぞれのIPアドレスでバインドするために必要です。発見は、次の条件で実行する必要があります。
o Bootstrapping: upon successful Layer 2 network attachment, the MN MAY be required to use DHCP for address configuration. These procedures can carry the required information for MoS configuration in specific DHCP options.
o ブートストラップ：レイヤー2ネットワークアタッチメントが成功すると、MNはアドレス構成にDHCPを使用する必要がある場合があります。これらの手順は、特定のDHCPオプションでMOS構成に必要な情報を伝達できます。
o If the MN does not receive MoS information during network attachment and the MN does not have a pre-configured Mobility Server, it MUST run a discovery procedure upon initial IP address configuration.
o MNがネットワーク添付時にMOS情報を受け取らず、MNに事前に構成されたモビリティサーバーがない場合、初期IPアドレス構成時に発見手順を実行する必要があります。
o If the MN changes its IP address (e.g., upon handover), it MUST refresh MIHF peer bindings (i.e., MIHF registration process). In case the Mobility Server used is not suitable anymore (e.g., too large RTT experienced), the MN MAY need to perform a new discovery procedure.
o MNがIPアドレスを変更する場合（例：Handover）、MIHFピアバインディング（つまり、MIHF登録プロセス）を更新する必要があります。使用されているモビリティサーバーがもはや適切でない場合（たとえば、経験豊富なRTTが大きすぎる）、MNは新しい発見手順を実行する必要がある場合があります。
o If the MN is a multi-homed device and it communicates with the same Mobility Server via different IP addresses, it MAY run discovery procedures if one of the IP addresses changes.
o MNがマルチホームデバイスであり、異なるIPアドレスを介して同じモビリティサーバーと通信する場合、IPアドレスのいずれかが変更された場合に発見手順を実行する可能性があります。
Once the MIHF peer has been discovered, MIH information can be exchanged between MIH peers over a transport protocol such as UDP or TCP. The usage of transport protocols is described in Section 6 and packing of the MIH messages does not require extra framing since the MIH protocol defined in [IEEE80221] already contains a length field.
MIHFピアが発見されると、MIH情報は、UDPやTCPなどの輸送プロトコルを介してMIHピア間で交換できます。輸送プロトコルの使用についてはセクション6で説明されており、MIHメッセージの梱包は、[IEEE80221]で定義されているMIHプロトコルにはすでに長さフィールドが含まれているため、追加のフレーミングを必要としません。
Figure 5 depicts the MSFD reference model and its components within a node. The topmost layer is the MIHF user. This set of applications consists of one or more MIH clients that are responsible for operations such as generating query and response, processing Layer 2 triggers as part of the ES, and initiating and carrying out handover operations as part of the CS. Beneath the MIHF user is the MIHF itself. This function is responsible for MoS discovery, as well as creating, maintaining, modifying, and destroying MIH signaling associations with other MIHFs located in MIH peer nodes. Below the MIHF are various transport-layer protocols as well as address discovery functions.
図5は、MSFD参照モデルとノード内のそのコンポーネントを示しています。最上層はMIHFユーザーです。この一連のアプリケーションは、クエリと応答の生成、ESの一部としてレイヤー2の処理をトリガーし、CSの一部としてハンドオーバー操作を開始および実行するなどの操作を担当する1つ以上のMIHクライアントで構成されています。MIHFユーザーの下には、MIHF自体があります。この関数は、MOS発見の原因となり、MIHピアノードにある他のMIHFとのMIHシグナル伝達関連の作成、維持、修正、および破壊の原因となっています。MIHFの下には、さまざまな輸送層プロトコルとアドレス発見機能があります。
+--------------------------+
| MIHF User |
+--------------------------+
||
+--------------------------+
| MIHF |
+--------------------------+
|| || ||
|| +------+ +-----+
|| | DHCP | | DNS |
|| +------+ +-----+
|| || ||
+--------------------------+
| TCP/UDP |
+--------------------------+
Figure 5: MN Stack
図5：MNスタック
The MIHF relies on the services provided by TCP and UDP for transporting MIH messages, and relies on DHCP and DNS for peer discovery. In cases where the peer MIHF IP address is not pre-configured, the source MIHF needs to discover it either via DHCP or DNS as described in Section 5. Once the peer MIHF is discovered, the MIHF must exchange messages with its peer over either UDP or TCP. Specific recommendations regarding the choice of transport protocols are provided in Section 6.
MIHFは、MIHメッセージの輸送にTCPとUDPが提供するサービスに依存しており、ピアディスカバリーのためにDHCPとDNSに依存しています。ピアMIHF IPアドレスが事前に構成されていない場合、セクション5で説明されているように、Source MIHFはDHCPまたはDNSを介してそれを発見する必要があります。またはTCP。輸送プロトコルの選択に関する具体的な推奨事項は、セクション6に記載されています。
There are no security features currently defined as part of the MIH protocol level. However, security can be provided either at the transport or IP layer where it is necessary. Section 8 provides guidelines and recommendations for security.
MIHプロトコルレベルの一部として現在定義されているセキュリティ機能はありません。ただし、セキュリティは、必要な場合の輸送層またはIPレイヤーで提供できます。セクション8では、セキュリティに関するガイドラインと推奨事項を示しています。
MIHFID is required to uniquely identify the MIHF end points for delivering the mobility services (MoS). Thus an MIHF identifier needs to be unique within a domain where mobility services are provided and independent of the configured IP address(es). An MIHFID MUST be represented either in the form of an FQDN [RFC2181] or NAI [RFC4282]. An MIHFID can be pre-configured or discovered through the discovery methods described in Section 5.
MIHFIDは、モビリティサービス（MO）を提供するためのMIHFエンドポイントを一意に識別する必要があります。したがって、MIHF識別子は、モビリティサービスが提供され、構成されたIPアドレス（ES）とは独立しているドメイン内で一意である必要があります。MIHFIDは、FQDN [RFC2181]またはNAI [RFC4282]の形で表す必要があります。MIHFIDは、セクション5で説明されている発見方法を通じて事前に構成または検出できます。
The MoS discovery method depends on whether the MN attempts to discover a Mobility Server in the home network, in the visited network, or in a third-party remote network that is neither the home network nor the visited network. In the case where the MN already has a Mobility Server address pre-configured, it is not necessary to run the discovery procedure. If the MN does not have pre-configured Mobility Server, the following procedure applies.
MOSディスカバリーメソッドは、MNがホームネットワーク、訪問されたネットワーク、またはホームネットワークでも訪問ネットワークでもないサードパーティのリモートネットワークでモビリティサーバーを発見しようとするかどうかに依存します。MNが既にモビリティサーバーアドレスを事前に構成している場合、発見手順を実行する必要はありません。MNに事前に構成されたモビリティサーバーがない場合、次の手順が適用されます。
In the case where a Mobility Server is provided locally (scenarios S1 and S2), the discovery techniques described in [RFC5678] and [RFC5679] are both applicable as described in Sections 5.1 and 5.2.
モビリティサーバーがローカルに提供されている場合（シナリオS1およびS2）、[RFC5678]および[RFC5679]で説明されている発見技術は、セクション5.1および5.2で説明されているように適用されます。
In the case where a Mobility Server is located in the home network while the MN is in the visited network (scenario S4), the DNS-based discovery described in [RFC5679] is applicable.
MNが訪問されたネットワーク（シナリオS4）にある間にモビリティサーバーがホームネットワークにある場合、[RFC5679]で説明されているDNSベースの発見が適用されます。
In the case where a Mobility Server is located in a third-party network that is different from the current visited network (scenario S3), only the DNS-based discovery method described in [RFC5679] is applicable.
モビリティサーバーが現在の訪問ネットワーク（シナリオS3）とは異なるサードパーティネットワークに配置されている場合、[RFC5679]で説明されているDNSベースの発見方法のみが適用されます。
It should be noted that authorization of an MN to use a specific Mobility Server is neither in scope of this document nor is currently specified in [IEEE80221]. We further assume all devices can access discovered MoS. In case future deployments will implement authorization policies, the mobile nodes should fall back to other learned MoS if authorization is denied.
特定のモビリティサーバーを使用するMNの許可は、このドキュメントの範囲ではなく、現在[IEEE80221]で指定されていることに注意する必要があります。さらに、すべてのデバイスが発見されたMOSにアクセスできると仮定します。将来の展開が承認ポリシーを実装する場合、承認が拒否された場合、モバイルノードは他の学習MOSに戻る必要があります。
To discover a Mobility Server in the home network, the MN SHOULD use the DNS-based MoS discovery method described in [RFC5679]. In order to use that mechanism, the MN MUST have its home domain pre-configured (i.e., subscription is tied to a network). The DNS query option is shown in Figure 6a. Alternatively, the MN MAY use the DHCP options for MoS discovery [RFC5678] as shown in Figure 6b (in some deployments, a DHCP relay may not be present).
ホームネットワークでモビリティサーバーを発見するには、MNは[RFC5679]で説明されているDNSベースのMOS発見方法を使用する必要があります。そのメカニズムを使用するには、MNにはホームドメインが事前に構成されている必要があります（つまり、サブスクリプションはネットワークに関連付けられています）。DNSクエリオプションを図6aに示します。あるいは、MNは、図6Bに示すように、MOS発見[RFC5678]にDHCPオプションを使用する場合があります（一部の展開では、DHCPリレーが存在しない場合があります）。
(a) +-------+
+----+ |Domain |
| MN |-------->|Name |
+----+ |Server |
MN@example.org +-------+
(b)
+-----+ +------+
+----+ | | |DHCP |
| MN |<----->| DHCP|<---->|Server|
+----+ |Relay| | |
+-----+ +------+
Figure 6: MOS Discovery (a) Using DNS Query, (b) Using DHCP Option
図6：MOSディスカバリー（a）DNSクエリの使用、（b）DHCPオプションを使用する
5.2. MoS Discovery When MN and MoSv Both Are in Visited Network (Scenario S2)
5.2. MOS Discovery MNとMOSVが両方とも訪問ネットワークにあるとき（シナリオS2）
To discover a Mobility Server in the visited network, the MN SHOULD attempt to use the DHCP options for MoS discovery [RFC5678] as shown in Figure 7.
訪問されたネットワークでモビリティサーバーを発見するには、MNは図7に示すように、MOSディスカバリー[RFC5678]のDHCPオプションを使用しようとする必要があります。
+-----+ +------+
+----+ | | |DHCP |
| MN |<----->| DHCP|<---->|Server|
+----+ |Relay| | |
+-----+ +------+
Figure 7: MoS Discovery Using DHCP Options
図7：DHCPオプションを使用したMOS発見
To discover a Mobility Server in a remote network other than home network, the MN MUST use the DNS-based MoS discovery method described in [RFC5679]. The MN MUST first learn the domain name of the network containing the MoS it is searching for. The MN can query its current Mobility Server to find out the domain name of a specific network or the domain name of a network at a specific location (as in Figure 8a). IEEE 802.21 defines information elements such as OPERATOR ID and SERVICE PROVIDER ID that can be a domain name. An IS query can provide this information, see [IEEE80221].
ホームネットワーク以外のリモートネットワークでモビリティサーバーを発見するには、MNは[RFC5679]で説明されているDNSベースのMOS発見方法を使用する必要があります。MNは、最初に検索しているMOを含むネットワークのドメイン名を学習する必要があります。MNは、現在のモビリティサーバーを照会して、特定の場所の特定のネットワークのドメイン名またはネットワークのドメイン名（図8Aのように）を見つけることができます。IEEE 802.21は、ドメイン名になる可能性のあるオペレーターIDやサービスプロバイダーIDなどの情報要素を定義します。ISクエリはこの情報を提供できます。[IEEE80221]を参照してください。
Alternatively, the MN MAY query a Mobility Server previously known to learn the domain name of the desired network. Finally, the MN MUST use DNS-based discovery mechanisms to find a Mobility Server in the remote network as in Figure 8b. It should be noted that step b can only be performed upon obtaining the domain name of the remote network.
あるいは、MNは、目的のネットワークのドメイン名を学習することが以前に知られているモビリティサーバーを照会することができます。最後に、MNは、図8Bのように、DNSベースのディスカバリーメカニズムを使用してリモートネットワークでモビリティサーバーを見つける必要があります。ステップBは、リモートネットワークのドメイン名を取得したときにのみ実行できることに注意してください。
(a)
+------------+
+----+ | |
| | |Information |
| MN |-------->| Server |
| | |(previously |
+----+ |discovered) |
+------------+
(b)
+-------+
+----+ |Domain |
| MN |-------->|Name |
+----+ |Server |
MN@example.org +-------+
Figure 8: MOS Discovery Using (a) IS Query to a Known IS Server, (b) DNS Query
図8：（a）を使用したMOSディスカバリーは既知のサーバーにクエリです（b）DNSクエリ
To discover a Mobility Server in the visited network when MIH services are provided by the home network, the DNS-based discovery method described in [RFC5679] is applicable. To discover the Mobility Server at home while in a visited network using DNS, the MN SHOULD use the procedures described in Section 5.1.
MIHサービスがホームネットワークによって提供されている場合、訪問されたネットワークでモビリティサーバーを発見するために、[RFC5679]で説明されているDNSベースの発見方法が適用されます。DNSを使用して訪問されたネットワークで自宅でモビリティサーバーを発見するには、MNはセクション5.1で説明されている手順を使用する必要があります。
Once the MoS have been discovered, MIH peers run a capability discovery and subscription procedure as specified in [IEEE80221]. MIH peers MAY exchange information over TCP, UDP, or any other transport supported by both the server and the client. The client MAY use the DNS discovery mechanism to discover which transport protocols are supported by the server in addition to TCP and UDP that are recommended in this document. While either protocol can provide the basic transport functionality required, there are performance trade-offs and unique characteristics associated with each that need to be considered in the context of the MIH services for different network loss and congestion conditions. The objectives of this section are to discuss these trade-offs for different MIH settings such as the MIH message size and rate, and the retransmission parameters. In addition, factors such as NAT traversal are also discussed. Given the reliability requirements for the MIH transport, it is assumed in this discussion that the MIH ACK mechanism is to be used in conjunction with UDP, while it MUST NOT be used with TCP since TCP includes acknowledgement and retransmission functionality.
MOSが発見されると、MIHピアは[IEEE80221]で指定されているように、機能発見とサブスクリプション手順を実行します。MIHピアは、TCP、UDP、またはサーバーとクライアントの両方がサポートするその他のトランスポートを介して情報を交換できます。クライアントは、DNS発見メカニズムを使用して、このドキュメントで推奨されるTCPとUDPに加えて、サーバーによってサポートされているトランスポートプロトコルを発見できます。どちらのプロトコルも必要な基本的な輸送機能を提供できますが、さまざまなネットワーク損失と輻輳条件のためにMIHサービスのコンテキストで考慮する必要がある各パフォーマンスのトレードオフとそれぞれに関連するユニークな特性があります。このセクションの目的は、MIHメッセージのサイズとレート、再送信パラメーターなどのさまざまなMIH設定のこれらのトレードオフを議論することです。さらに、NATトラバーサルなどの要因についても説明します。MIH輸送の信頼性要件を考えると、この議論では、MIH ACKメカニズムはUDPと併用することが想定されていますが、TCPには謝辞と再送信機能が含まれているため、TCPで使用してはなりません。
Although the MIH message size varies widely from about 30 bytes (for a capability discovery request) to around 65000 bytes (for an IS MIH_Get_Information response primitive), a typical MIH message size for the ES or CS ranges between 50 to 100 bytes [IEEE80221]. Thus, considering the effects of the MIH message size on the performance of the transport protocol brings us to discussing two main issues, related to fragmentation of long messages in the context of UDP and the concatenation of short messages in the context of TCP.
MIHメッセージサイズは、約30バイト（機能発見要求の場合）から約65000バイト（IS MIH_GET_INFORMATION応答の原始）まで大きく異なりますが、ESまたはCSの典型的なMIHメッセージサイズは50〜100バイトの範囲です[IEEE80221]。したがって、輸送プロトコルのパフォーマンスに対するMIHメッセージサイズの効果を考慮すると、UDPのコンテキストでの長いメッセージの断片化とTCPのコンテキストでの短いメッセージの連結に関連する2つの主要な問題を議論することができます。
Since transporting long MIH messages may require fragmentation that is not available in UDP, if MIH is using UDP a limit MUST be set on the size of the MIH message based on the path MTU to destination (or the Minimum MTU where PMTU is not implemented). The Minimum MTU depends on the IP version used for transmission, and is the lesser of the first hop MTU, and 576 or 1280 bytes for IPv4 [RFC1122] or for IPv6 [RFC2460], respectively, although applications may reduce these values to guard against the presence of tunnels.
長いMIHメッセージを輸送する必要があるため、UDPで使用できない断片化が必要になる場合があります。MIHがUDPを使用している場合、PATH MTUに基づいてMIHメッセージのサイズに制限を設定する必要があります（またはPMTUが実装されていない最小MTU）。最小MTUは、送信に使用されるIPバージョンに依存し、最初のホップMTUの低下、IPv4 [RFC1122]またはIPv6 [RFC2460]の場合はそれぞれ576または1280バイトですが、アプリケーションはこれらの値を減らすためにこれらの値を減らす可能性があります。トンネルの存在。
According to [IEEE80221], when an MIH message is sent using an L3 or higher-layer transport, L3 takes care of any fragmentation issue and the MIH protocol does not handle fragmentation in such cases. Thus, MIH layer fragmentation MUST NOT be used together with IP layer fragmentation and MUST not be used when MIH packets are carried over TCP.
[IEEE80221]によると、L3または高層輸送を使用してMIHメッセージが送信されると、L3は断片化の問題を処理し、MIHプロトコルはそのような場合に断片化を処理しません。したがって、MIH層の断片化はIPレイヤーの断片化と一緒に使用してはならず、MIHパケットがTCPに運ばれた場合は使用しないでください。
The loss of an IP fragment leads to the retransmission of an entire MIH message, which in turn leads to poor end-to-end delay performance in addition to wasted bandwidth. Additional recommendations in [RFC5405] apply for limiting the size of the MIH message when using UDP and assuming IP layer fragmentation. In terms of dealing with short messages, TCP has the capability to concatenate very short messages in order to reduce the overall bandwidth overhead. However, this reduced overhead comes at the cost of additional delay to complete an MIH transaction, which may not be acceptable for CS and ES. Note also that TCP is a stream-oriented protocol and measures data flow in terms of bytes, not messages. Thus, it is possible to split messages across multiple TCP segments if they are long enough. Even short messages can be split across two segments. This can also cause unacceptable delays, especially if the link quality is severely degraded as is likely to happen when the MN is exiting a wireless access coverage area. The use of the TCP_NODELAY option can alleviate this problem by triggering transmission of a segment less than the SMSS. (It should be noted that [RFC4960] addresses both of these problems, but discussion of SCTP is omitted here, as it is generally not used for the mobility services discussed in this document.)
IPフラグメントの損失は、MIHメッセージ全体の再送信につながり、これにより、無駄な帯域幅に加えて、エンドツーエンドの遅延性能が低下します。[RFC5405]の追加の推奨事項は、UDPを使用したときにMIHメッセージのサイズを制限し、IPレイヤーの断片化を想定することに適用されます。短いメッセージを処理するという点では、TCPには、帯域幅全体のオーバーヘッドを減らすために、非常に短いメッセージを連結する機能があります。ただし、このオーバーヘッドの減少は、MIHトランザクションを完了するために追加の遅延がかかる費用がかかりますが、これはCSおよびESには受け入れられない場合があります。また、TCPはストリーム指向のプロトコルであり、メッセージではなくバイトの観点からデータフローを測定することに注意してください。したがって、複数のTCPセグメントに十分な長さである場合、メッセージを分割することができます。短いメッセージでさえ、2つのセグメントに分割できます。これは、特にMNがワイヤレスアクセスカバレッジ領域を終了しているときに発生する可能性が高いように、リンクの品質が大幅に低下している場合、容認できない遅延を引き起こす可能性があります。TCP_NODELAYオプションの使用は、SMSSよりも小さいセグメントの送信をトリガーすることにより、この問題を軽減できます。（[RFC4960]はこれらの問題の両方に対処することに注意する必要がありますが、SCTPの議論は一般にこのドキュメントで説明されているモビリティサービスには使用されていないため、ここでは省略されています。）
The frequency of MIH messages varies according to the MIH service type. It is expected that CS/ES messages arrive at a rate of one in hundreds of milliseconds in order to capture quick changes in the environment and/or process handover commands. On the other hand, IS messages are exchanged mainly every time a new network is visited, which may be in order of hours or days. Therefore, a burst of either short CS/ES messages or long IS message exchanges (in the case where multiple MIH nodes request information) may lead to network congestion. While the built-in rate-limiting controls available in TCP may be well suited for dealing with these congestion conditions, this may result in large transmission delays that may be unacceptable for the timely delivery of ES or CS messages. On the other hand, if UDP is used, a rate-limiting effect similar to the one obtained with TCP SHOULD be obtained by adequately adjusting the parameters of a token bucket regulator as defined in the MIH specifications [IEEE80221]. Recommendations for token bucket parameter settings are as follows:
MIHメッセージの頻度は、MIHサービスタイプによって異なります。CS/ESメッセージは、環境および/またはプロセスハンドオーバーコマンドの迅速な変更をキャプチャするために、数百ミリ秒単位で1つのレートに到達することが期待されています。一方、主に新しいネットワークが訪問されるたびにメッセージが交換されます。したがって、短いCS/ESメッセージまたはLONGのいずれかのバーストは、メッセージ交換（複数のMIHノードが情報を要求する場合）であり、ネットワークの輻輳につながる可能性があります。TCPで利用可能な組み込みのレート制限コントロールは、これらの渋滞条件に対処するのに適している可能性がありますが、これにより、ESまたはCSメッセージのタイムリーな配信に受け入れられない大きな伝送遅延が発生する可能性があります。一方、UDPを使用する場合、MIH仕様[IEEE80221]で定義されているトークンバケットレギュレーターのパラメーターを適切に調整することにより、TCPで得られたものと同様のレート制限効果を取得する必要があります。トークンバケットパラメーター設定の推奨事項は次のとおりです。
o If the MIHF knows the RTT (e.g., based on the request/response MIH protocol exchange between two MIH peers), the rate can be based upon this as specified in [IEEE80221].
o MIHFがRTTを知っている場合（例えば、2つのMIHピア間のリクエスト/応答MIHプロトコル交換に基づいて）、レートは[IEEE80221]で指定されているようにこれに基づいています。
o If not, then on average it SHOULD NOT send more than one UDP message every 3 seconds.
o そうでない場合は、平均して3秒ごとに複数のUDPメッセージを送信してはなりません。
For TCP, the retransmission timeout is adjusted according to the measured RTT. However due to the exponential backoff mechanism, the delay associated with retransmission timeouts may increase significantly with increased packet loss.
TCPの場合、再送信タイムアウトは測定されたRTTに従って調整されます。ただし、指数関数的なバックオフメカニズムにより、再送信タイムアウトに関連する遅延は、パケット損失の増加とともに大幅に増加する可能性があります。
If UDP is being used to carry MIH messages, MIH MUST use MIH ACKs. An MIH message is retransmitted if its corresponding MIH ACK is not received by the generating node within a timeout interval set by the MIHF. The maximum number of retransmissions is configurable and the value of the retransmission timer is computed according to the algorithm defined in [RFC2988]. The default maximum number of retransmissions is set to 2 and the initial retransmission timer (TMO) is set to 3s when RTT is not known. The maximum TMO is set to 30s.
UDPがMIHメッセージを運ぶために使用されている場合、MIHはMIH Acksを使用する必要があります。MIHFが対応するMIH ACKがMIHFによって設定されたタイムアウト間隔内の生成ノードによって受信されない場合、MIHメッセージが再送信されます。再送信の最大数は構成可能であり、再送信タイマーの値は[RFC2988]で定義されているアルゴリズムに従って計算されます。再送信のデフォルトの最大数は2に設定され、RTTが不明な場合は初期再送信タイマー（TMO）が3秒に設定されます。最大TMOは30秒に設定されています。
There are no known issues for NAT traversal when using TCP. The default connection timeout of 2 hours 4 minutes [RFC5382] (assuming a 2-hour TCP keep-alive) is considered adequate for MIH transport purposes. However, issues with NAT traversal using UDP are documented in [RFC5405]. Communication failures are experienced when middleboxes destroy the per-flow state associated with an application session during periods when the application does not exchange any UDP traffic. Hence, communication between the MN and the Mobility Server SHOULD be able to gracefully handle such failures and implement mechanisms to re-establish their UDP sessions. In addition and in order to avoid such failures, MIH messages MAY be sent periodically, similarly to keep-alive messages, in an attempt to refresh middlebox state. As [RFC4787] requires a minimum state timeout of 2 minutes or more, MIH messages using UDP as transport SHOULD be sent once every 2 minutes. Re-registration or event indication messages as defined in [IEEE80221] MAY be used for this purpose.
TCPを使用する場合、NATトラバーサルの既知の問題はありません。2時間4分[RFC5382]のデフォルト接続タイムアウト（2時間のTCPキープアリブを想定）は、MIH輸送目的で適切と見なされます。ただし、UDPを使用したNATトラバーサルの問題は[RFC5405]に記録されています。ミドルボックスが、アプリケーションがUDPトラフィックを交換しない期間中に、アプリケーションセッションに関連する流量あたりの状態を中間ボックスが破壊すると、通信障害が発生します。したがって、MNとMobilityサーバー間の通信は、そのような障害を優雅に処理し、UDPセッションを再確立するメカニズムを実装できるはずです。さらに、そのような障害を回避するために、MIHメッセージは、ミドルボックスの状態を更新しようとして、同様にアライブメッセージを保持することと同様に定期的に送信することができます。[RFC4787]には2分以上の最小ステートタイムアウトが必要なため、輸送としてUDPを使用したMIHメッセージは2分ごとに1回送信する必要があります。[IEEE80221]で定義されている再登録またはイベント表示メッセージは、この目的に使用できます。
The ES and CS messages are small in nature and have 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. TCP SHOULD be used as the default transport for all messages. However, UDP in combination with MIH acknowledgement SHOULD be used for transporting ES and CS messages that are shorter than or equal to the path MTU as described in Section 6.1.
ESおよびCSメッセージは本質的に小さく、潜在的な要件が厳しいです。一方、ISはレイテンシの制約の点でより回復力があり、いくつかの長いメッセージは、宛先へのパスのMTUを超える可能性があります。TCPは、すべてのメッセージのデフォルトトランスポートとして使用する必要があります。ただし、MIHの確認と組み合わせたUDPは、セクション6.1で説明されているように、PATH MTU以下のESおよびCSメッセージの輸送に使用する必要があります。
For both UDP and TCP cases, if a port number is not explicitly assigned (e.g., by the DNS SRV), MIH messages sent over UDP, TCP, or other supported transport MUST use the default port number defined in Section 9 for that particular transport.
UDPケースとTCPケースの両方で、ポート番号が明示的に割り当てられていない場合（例：DNS SRVによって）、UDP、TCP、またはその他のサポートされているトランスポートを介して送信されたMIHメッセージは、その特定のトランスポートでセクション9で定義されているデフォルトのポート番号を使用する必要があります。。
A Mobility Server MUST support both UDP and TCP for MIH transport and the MN MUST support TCP. Additionally, the server and MN MAY support additional transport mechanisms. The MN MAY use the procedures defined in [RFC5679] to discover additional transport protocols supported by the server (e.g., SCTP).
モビリティサーバーは、MIH輸送のためにUDPとTCPの両方をサポートする必要があり、MNはTCPをサポートする必要があります。さらに、サーバーとMNは追加の輸送メカニズムをサポートする場合があります。MNは、[RFC5679]で定義されている手順を使用して、サーバー（SCTPなど）でサポートされている追加の輸送プロトコルを発見できます。
Figure 9 gives an example operation flow between MIHF peers when an MIH user requests an IS and both the MN and the Mobility Server are in the MN's home network. DHCP is used for Mobility Services (MoS) discovery, and TCP is used for establishing a transport connection to carry the IS messages. When the Mobility Server is not pre-configured, the MIH user needs to discover the IP address of the Mobility Server to communicate with the remote MIHF. Therefore, the MIH user sends a discovery request message to the local MIHF as defined in [IEEE80221].
図9は、MIHユーザーがISを要求し、MNとMobilityサーバーの両方がMNのホームネットワークにある場合、MIHFピア間の操作フローの例を示しています。DHCPはモビリティサービス（MOS）発見に使用され、TCPはISメッセージを伝えるための輸送接続を確立するために使用されます。モビリティサーバーが事前に構成されていない場合、MIHユーザーはモビリティサーバーのIPアドレスを発見してリモートMIHFと通信する必要があります。したがって、MIHユーザーは[IEEE80221]で定義されているように、ローカルMIHFにディスカバリーリクエストメッセージを送信します。
In this example (one could draw similar mechanisms with DHCPv6), we assume that MoS discovery is performed before a transport connection is established with the remote MIHF, and the DHCP client process is invoked via some internal APIs. The DHCP client sends a DHCP INFORM message according to standard DHCP and with the MoS option as defined in [RFC5678]. The DHCP server replies via a DHCP ACK message with the IP address of the Mobility Server. The Mobility Server address is then passed to the MIHF locally via some internal APIs. The MIHF generates the discovery response message and passes it on to the corresponding MIH user. The MIH user generates an IS query addressed to the remote Mobility Server. The MIHF invokes the underlying TCP client, which establishes a transport connection with the remote peer. Once the transport connection is established, the MIHF sends the IS query via an MIH protocol REQUEST message. The message and query arrive at the destination MIHF and MIH user, respectively. The Mobility Server MIH user responds to the corresponding IS query and the Mobility Server MIHF sends the IS response via an MIH protocol RESPONSE message. The message arrives at the source MIHF, which passes the IS response on to the corresponding MIH user.
この例（DHCPV6で同様のメカニズムを描くことができます）では、リモートMIHFとの輸送接続が確立され、DHCPクライアントプロセスが内部APIを介して呼び出される前にMOS発見が実行されると仮定します。DHCPクライアントは、[RFC5678]で定義されているように、標準のDHCPに従ってDHCP情報メッセージを送信します。DHCPサーバーは、モビリティサーバーのIPアドレスを使用してDHCP ACKメッセージを介して返信します。モビリティサーバーアドレスは、いくつかの内部APIを介してローカルにMIHFに渡されます。MIHFは、Discovery Responseメッセージを生成し、対応するMIHユーザーに渡します。MIHユーザーは、リモートモビリティサーバーにアドレス指定されたISクエリを生成します。MIHFは、リモートピアとの輸送接続を確立する基礎となるTCPクライアントを呼び出します。トランスポート接続が確立されると、MIHFはMIHプロトコル要求メッセージを介してISクエリを送信します。メッセージとクエリは、それぞれ宛先MIHFとMIHユーザーに到着します。Mobility Server MIHユーザーは、対応するISクエリに応答し、MiHプロトコル応答メッセージを介してIS応答を送信します。メッセージはソースMIHFに到着し、対応するMIHユーザーへのIS応答を渡します。
MN MoS
|===================================| |======| |===================|
+ ---------+ +---------+
| MIH USER | +------+ +------+ +------+ +------+ | MIH USER|
| +------+ | | TCP | |DHCP | |DHCP | | TCP | | +------+|
| | MIHF | | |Client| |Client| |Server| |Server| | | MIHF ||
+----------+ +------+ +------+ +------+ +------++----------+
| | | | | |
MIH Discovery | | | | |
Request | | | | |
| | | | | |
|Invoke DHCP Client | | | |
|(Internal process with MoS)|DHCP INFORM| | |
|==========================>|==========>| | |
| | | | | |
| Inform Mobility Server | DHCP ACK | | |
| Address |<==========| | |
|<==========================| | | |
| (internal process) | | | |
| | | | | |
MIH Discovery | | | | |
Response | | | | |
| | | | | |
IS Query | | | | |
MIH User-> MIHF | | | | |
| | | | | |
|Invoke TCP Client| | | | |
|================>| TCP connection established | |
Internal process |<=============================>| |
| | | | | |
| IS QUERY REQUEST (via MIH protocol) |
|===========================================================>|
| | | | | IS QUERY|
| | | | | REQUEST|
| | | | MIHF-> MIH User |
| | | | | QUERY|
| | | | | RESPONSE|
| | | | MIHF <-MIH User |
| | | | | |
| | IS QUERY RESPONSE (via MIH protocol) |
|<===========================================================|
| | | | | |
IS RESPONSE | | | | |
MIH User <-MIHF | | | | |
| | | | | |
Figure 9: Example Flow of Operation Involving MIH User
図9：MIHユーザーが関与する操作の例の例
There are two components to the security considerations: MoS discovery and MIH transport. For MoS discovery, DHCP and DNS recommendations are hereby provided per IETF guidelines. For MIH transport, we describe the security threats and expect that the system deployment will have means to mitigate such threats when sensitive information is being exchanged between the mobile node and Mobility Server. Since IEEE 802.21 base specification does not provide MIH protocol level security, it is assumed that either lower layer security (e.g., link layer) or overall system-specific (e.g., proprietary) security solutions are available. The present document does not provide any guidelines in this regard. It is stressed that the IEEE 802.21a Task Group has recently started work on MIH security issues that may provide some solution in this area. Finally, authorization of an MN to use a specific Mobility Server, as stated in Section 5, is neither in scope of this document nor is currently specified in [IEEE80221].
セキュリティ上の考慮事項には、MOS発見とMIH輸送の2つのコンポーネントがあります。MOS発見の場合、DHCPおよびDNSの推奨事項は、IETFガイドラインごとに提供されます。MIH輸送の場合、セキュリティの脅威について説明し、システムの展開には、モバイルノードとモビリティサーバーの間で機密情報が交換されている場合、そのような脅威を軽減する手段があると予想しています。IEEE 802.21ベース仕様はMIHプロトコルレベルのセキュリティを提供していないため、低層セキュリティ（リンク層など）またはシステム全体の（たとえば、独自）セキュリティソリューションのいずれかが利用可能であると想定されています。現在の文書は、この点でガイドラインを提供していません。IEEE 802.21Aタスクグループが最近、この分野で何らかの解決策を提供するMIHセキュリティの問題に関する作業を開始したことを強調しています。最後に、セクション5に記載されているように、特定のモビリティサーバーを使用するMNの許可は、このドキュメントの範囲ではなく、現在[IEEE80221]で指定されています。
There are a number of security issues that need to be taken into account during node discovery. In the case where DHCP is used for node discovery and authentication of the source and content of DHCP messages is required, network administrators SHOULD use the DHCP authentication option described in [RFC3118], where available, or rely upon link layer security. [RFC3118] provides mechanisms for both entity authentication and message authentication. In the case where the DHCP authentication mechanism is not available, administrators may need to rely upon the underlying link layer security. In such cases, the link between the DHCP client and Layer 2 termination point may be protected, but the DHCP message source and its messages cannot be authenticated or the integrity of the latter checked unless there exits a security binding between link layer and DHCP layer.
ノードの発見中に考慮する必要があるセキュリティの問題がいくつかあります。DHCPがノード発見とDHCPメッセージのソースとコンテンツの認証に使用される場合、ネットワーク管理者は[RFC3118]で説明されているDHCP認証オプションを使用する必要があります。[RFC3118]は、エンティティ認証とメッセージ認証の両方にメカニズムを提供します。DHCP認証メカニズムが利用できない場合、管理者は基礎となるリンクレイヤーセキュリティに依存する必要がある場合があります。そのような場合、DHCPクライアントとレイヤー2終端ポイントの間のリンクを保護できますが、DHCPメッセージソースとそのメッセージは、リンクレイヤーとDHCPレイヤー間のセキュリティバインディングが終了しない限り、認証されたり、後者の整合性を確認したりすることはできません。
In the case where DNS is used for discovering MoS, fake DNS requests and responses may cause denial of service (DoS) and the inability of the MN to perform a proper handover, respectively. Where networks are exposed to such DoS, it is RECOMMENDED that DNS service providers use the Domain Name System Security Extensions (DNSSEC) as described in [RFC4033]. Readers may also refer to [RFC4641] to consider the aspects of DNSSEC operational practices.
DNSがMOSを発見するために使用される場合、偽のDNSリクエストと応答は、それぞれサービスの拒否（DOS）とそれぞれ適切なハンドオーバーを実行できない可能性があります。ネットワークがそのようなDOSにさらされる場合、[RFC4033]で説明されているように、DNSサービスプロバイダーがドメイン名システムセキュリティ拡張機能（DNSSEC）を使用することをお勧めします。また、読者は[RFC4641]を参照して、DNSSECの運用慣行の側面を検討することもできます。
The communication between an MN and a Mobility Server is exposed to a number of security threats: o Mobility Server identity spoofing. A fake Mobility Server could provide the MNs with bogus data and force them to select the wrong network or to make a wrong handover decision.
MNとモビリティサーバーの間の通信は、多くのセキュリティの脅威にさらされています：oモビリティサーバーのアイデンティティスプーフィング。偽のモビリティサーバーは、MNSに偽のデータを提供し、間違ったネットワークを選択したり、間違ったハンドオーバー決定を行うように強制します。
o Tampering. Tampering with the information provided by a Mobility Server may result in the MN making wrong network selection or handover decisions.
o 改ざん。モビリティサーバーが提供する情報を改ざんすると、MNが間違ったネットワーク選択またはハンドオーバー決定を行う可能性があります。
o Replay attack. Since Mobility Services as defined in [IEEE80221] support a 'PUSH model', they can send large amounts of data to the MNs whenever the Mobility Server thinks that the data is relevant for the MN. An attacker may intercept the data sent by the Mobility Server to the MNs and replay it at a later time, causing the MNs to make network selection or handover decisions that are not valid at that point in time.
o リプレイ攻撃。[IEEE80221]で定義されているモビリティサービスは「プッシュモデル」をサポートするため、モビリティサーバーがデータがMNに関連していると考えるたびに、MNSに大量のデータを送信できます。攻撃者は、モビリティサーバーから送信されたデータをMNSにインターセプトし、後でリプレイすることができ、MNSはその時点で有効でないネットワーク選択またはハンドオーバー決定を行います。
o Eavesdropping. By snooping the communication between an MN and a Mobility Server, an attacker may be able to trace a user's movement between networks or cells, or predict future movements, by inspecting handover service messages.
o 盗聴。MNとモビリティサーバーの間の通信をスヌーピングすることにより、攻撃者は、ハンドオーバーサービスメッセージを検査することにより、ネットワークまたはセル間のユーザーの動きを追跡したり、将来の動きを予測できる場合があります。
There are many deployment-specific system security solutions available, which can be used to countermeasure the above mentioned threats. For example, for the MoSh and MoSv scenarios (including roaming scenarios), link layer security may be sufficient to protect the communication between the MN and Mobility Server. This is a typical mobile operator environment where link layer security provides authentication, data confidentiality, and integrity. In other scenarios, such as the third-party MoS, link layer security solutions may not be sufficient to protect the communication path between the MN and the Mobility Server. The communication channel between MN and Mobility Server needs to be secured by other means.
利用可能な多くの展開固有のシステムセキュリティソリューションがあります。これは、上記の脅威に対抗するために使用できます。たとえば、MOSHおよびMOSVシナリオ（ローミングシナリオを含む）の場合、MNとモビリティサーバー間の通信を保護するのに十分なリンクレイヤーセキュリティで十分かもしれません。これは、リンクレイヤーセキュリティが認証、データの機密性、および整合性を提供する典型的なモバイルオペレーター環境です。サードパーティMOSなどの他のシナリオでは、MNとモビリティサーバーの間の通信パスを保護するには、リンクレイヤーセキュリティソリューションでは不十分な場合があります。MNとMobility Serverの間の通信チャネルは、他の手段で保護する必要があります。
The present document does not provide any specific guidelines about the way these security solutions should be deployed. However, if in the future the IEEE 802.21 Working Group amends the specification with MIH protocol level security or recommends the deployment scenarios, IETF may revisit the security considerations and recommend specific transport-layer security as appropriate.
現在のドキュメントでは、これらのセキュリティソリューションを展開する方法に関する特定のガイドラインは提供していません。ただし、将来、IEEE 802.21ワーキンググループがMIHプロトコルレベルのセキュリティで仕様を修正するか、展開シナリオを推奨する場合、IETFはセキュリティ上の考慮事項を再検討し、適切に特定の輸送層セキュリティを推奨する場合があります。
This document registers the following TCP and UDP ports with IANA:
このドキュメントは、次のTCPおよびUDPポートをIANAで登録します。
Keyword Decimal Description
-------- --------------- ------------
ieee-mih 4551/tcp MIH Services
ieee-mih 4551/udp MIH Services
The authors would like to thank Yoshihiro Ohba, David Griffith, Kevin Noll, Vijay Devarapalli, Patrick Stupar, and Sam Xia for their valuable comments, reviews, and fruitful discussions.
著者は、貴重なコメント、レビュー、実り多い議論をしてくれたヨシヒロ・オバ、デビッド・グリフィス、ケビン・ノール、ヴィジェイ・デヴァラパリ、パトリック・スパル、サム・シアに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181] Elz、R。およびR. Bush、「DNS仕様の説明」、RFC 2181、1997年7月。
[RFC3118] Droms, R., Ed., and W. Arbaugh, Ed., "Authentication for DHCP Messages", RFC 3118, June 2001.
[RFC3118] Droms、R.、ed。、およびW. Arbaugh、ed。、「DHCPメッセージの認証」、RFC 3118、2001年6月。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] DROMS、R.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6のダイナミックホスト構成プロトコル」、RFC 3315、2003年7月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティの導入と要件」、RFC 4033、2005年3月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282] Aboba、B.、Beadles、M.、Arkko、J。、およびP. Eronen、「ネットワークアクセス識別子」、RFC 4282、2005年12月。
[RFC5678] Bajko, G. and S. Das, "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery", RFC 5678, December 2009.
[RFC5678] Bajko、G。およびS. Das、「IEEE 802.21 Mobility Services（MOS）Discoveryのダイナミックホスト構成プロトコル（DHCPV4およびDHCPV6）オプション」、RFC 5678、2009年12月。
[RFC5679] Bajko, G., "Locating IEEE 802.21 Mobility Services Using DNS", RFC 5679, December 2009.
[RFC5679] Bajko、G。、「DNSを使用したIEEE 802.21モビリティサービスの位置」、RFC 5679、2009年12月。
[IEEE80221] "IEEE Standard for Local and Metropolitan Area Networks - Part 21: Media Independent Handover Services", IEEE LAN/MAN Std 802.21-2008, January 2009, http://www.ieee802.org/21/private/Published%20Spec/ 802.21-2008.pdf (access to the document requires membership).
[IEEE80221]「ローカルおよびメトロポリタンエリアネットワークのIEEE標準 - パート21：メディア独立ハンドオーバーサービス」、IEEE LAN/MAN STD 802.21-2008、2009年1月、http：//www.ieee802.org/21/private/publided%20SPEC/ 802.21-2008.pdf（ドキュメントへのアクセスにはメンバーシップが必要です）。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] DROMS、R。、「動的ホスト構成プロトコル」、RFC 2131、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「Internet Protocol、Version 6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988] Paxson、V。およびM. Allman、「TCPの再送信タイマーのコンピューティング」、RFC 2988、2000年11月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022] Srisuresh、P。およびK. Egevang、「従来のIPネットワークアドレス翻訳者（従来のNAT）」、RFC 3022、2001年1月。
[RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", RFC 4641, September 2006.
[RFC4641] Kolkman、O。およびR. Gieben、「DNSSEC運用慣行」、RFC 4641、2006年9月。
[RFC4787] Audet, F., Ed., and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787] Audet、F.、ed。、およびC. Jennings、「Unicast UDPのネットワークアドレス変換（NAT）行動要件」、BCP 127、RFC 4787、2007年1月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R.、ed。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC5164] Melia, T., Ed., "Mobility Services Transport: Problem Statement", RFC 5164, March 2008.
[RFC5164] Melia、T.、ed。、「Mobility Services Transport：Problem Statement」、RFC 5164、2008年3月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.2」、RFC 5246、2008年8月。
[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
[RFC5382] Guha、S.、Ed。、Biswas、K.、Ford、B.、Sivakumar、S.、およびP. Srisuresh、「TCPのNat行動要件」、BCP 142、RFC 5382、2008年10月。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[RFC5405] Eggert、L。およびG. Fairhurst、「アプリケーションデザイナーのユニキャストUDP使用ガイドライン」、BCP 145、RFC 5405、2008年11月。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
[RFC5681] Allman、M.、Paxson、V。、およびE. Blanton、「TCP混雑制御」、RFC 5681、2009年9月。
Authors' Addresses
著者のアドレス
Telemaco Melia (editor) Alcatel-Lucent Route de Villejust Nozay 91620 France
Telemaco Melia（編集者）Alcatel-Lucent Route de Villejust Nozay 91620フランス
EMail: telemaco.melia@alcatel-lucent.com
Gabor Bajko Nokia
Gabor Bajko Nokia
EMail: Gabor.Bajko@nokia.com
Subir Das Telcordia Technologies Inc.
Subir Das Telcordia Technologies Inc.
EMail: subir@research.telcordia.com
Nada Golmie NIST
Nada Golmie Nist
EMail: nada.golmie@nist.gov
Juan Carlos Zuniga InterDigital Communications, LLC
Juan Carlos Zuniga Interdigital Communications、LLC
EMail: j.c.zuniga@ieee.org