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
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.
本文档描述了IEEE 802.21媒体独立切换（MIH）协议的移动服务框架设计（MSFD），该协议解决了与MIH消息传输相关的问题。该文档还描述了用于移动服务（MoS）发现的机制和用于可靠传递MIH消息的传输层机制。本文档不提供用于保护移动节点（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.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括《信托法律条款》第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
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层传输问题分为两个主要部分：发现支持特定移动服务（MoS）的节点，以及在移动节点（MN）和发现的节点之间传输信息。MN需要发现过程来获得与对等节点进行MIH协议通信所需的信息。该信息包括对等节点的传输地址（例如，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.
媒体独立切换（MIH）：IEEE 802.21工作组定义的切换支持体系结构，包括MIH功能（MIHF）、MIH网络实体和MIH协议消息。
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].
媒体独立切换功能（MIHF）：一种切换功能，通过IEEE 802.21工作组[IEEE80221]定义的服务接入点（SAP）提供切换服务，包括事件服务（ES）、信息服务（IS）和命令服务（CS）。
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 SAP访问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.
媒体独立切换功能标识符（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].
移动服务（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.
移动服务传输协议（MSTP）：用于将MIH协议消息从MIHF传送到网络中其他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，起源于协议栈的下层或上层，并将信息发送到协议栈的本地或远程上层或下层。IS的目的是交换与各种相邻网络信息相关的信息元素。
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或本地协议栈较低层并将信息发送到本地MIHF或本地较高层的MoS。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）：Internet上主机的完整域名，显示（按相反顺序）从DNS根和顶级域到主机名（例如myexample.example.org）的完整委派路径。
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）：[RFC2131]和[RFC3315]中描述的协议，允许Internet设备分别从DHCP服务器获取IPv4和IPv6地址、子网掩码、默认网关地址和其他IP配置信息。
Domain Name System (DNS): a protocol described in [RFC1035] that translates domain names to IP addresses.
域名系统（DNS）：[RFC1035]中描述的将域名转换为IP地址的协议。
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.
家庭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确认（MIH ACK）：MIHF发送的MIH信令消息，以响应来自发送MIHF的MIH消息。
Point of Service (PoS): a network-side MIHF instance that exchanges MIH messages with an MN-based MIHF.
服务点（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在计时器过期时使用该确认，以确定段何时被视为丢失并应重新发送。
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.
路径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）：主要确保两个通信网络实体之间的隐私和数据完整性的应用层协议[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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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和移动服务器的各种可能部署场景。MN和移动服务器的相对位置影响MoS发现以及MIH信令服务的性能。本文档介绍了[RFC5164]中列出的方案，并指定了通过IP传输MIH协议的传输选项。
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和服务位于家庭网络中。我们将这组服务称为MoSh，如图1所示。MoSh可以位于MN用于连接到家庭网络的接入网络处，也可以位于其他位置。
+--------------+ +====+
| HOME NETWORK | |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位于到访网络中，并且移动服务由到访网络提供。我们将其称为MoSv，如图2所示。
+--------------+
| HOME NETWORK |
+--------------+
/\
||
\/
+====+ +-----------------+
|MoSv| | VISITED NETWORK |
+====+ +-----------------+
/\
||
\/
+--------+
| MN |
+--------+
+--------------+
| 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位于其家庭网络或访问网络中，并且服务由第三方网络提供。我们将这种情况称为MoS3，如图3所示。（请注意，MoS可以存在于家庭网络和到访网络中。）
+--------------+
| HOME NETWORK |
+====+ +--------------+ +--------------+
|MoS3| | THIRD PARTY | <===> /\
+====+ +--------------+ ||
\/
+-----------------+
| VISITED NETWORK |
+-----------------+
/\
||
\/
+--------+
| MN |
+--------+
+--------------+
| 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位于访问的网络中，所有MIH服务都由家庭网络提供，如图4所示。
+====+ +--------------+
|MoSh| | HOME NETWORK |
+====+ +--------------+
/\
||
\/
+-----------------+
| VISITED NETWORK |
+-----------------+
/\
||
\/
+--------+
| MN |
+--------+
+====+ +--------------+
|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.
可以独立于其他类型提供不同类型的MoS，ES、CS和is之间没有严格的关系，也不要求提供这些服务的实体应位于同一地点。然而，虽然IS倾向于涉及大量静态信息，但是ES和CS是动态服务，并且可以预期它们之间的一些关系，例如，在接收到链路事件（ES）时可以发出切换命令（CS）。本文档没有对MoS的位置做出任何假设（尽管可能存在一些首选配置），旨在灵活的MSFD在不同位置发现不同的服务，以优化切换性能。第5节将更详细地讨论MoS发现。
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节所述，解决方案空间分为两个功能域：发现和传输。已做出以下假设：
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级别的相关配置），以将两个MIHF对等方（例如，MN和移动服务器）与其各自的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地址（例如，在切换时），它必须刷新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用户。这组应用程序由一个或多个MIH客户端组成，这些客户端负责生成查询和响应、作为ES的一部分处理第2层触发器以及作为CS的一部分启动和执行切换操作。在MIHF用户下面是MIHF本身。此功能负责MoS发现，以及创建、维护、修改和销毁与位于MIH对等节点中的其他MIHF的MIH信令关联。MIHF下面是各种传输层协议以及地址发现功能。
+--------------------------+
| MIHF User |
+--------------------------+
||
+--------------------------+
| MIHF |
+--------------------------+
|| || ||
|| +------+ +-----+
|| | DHCP | | DNS |
|| +------+ +-----+
|| || ||
+--------------------------+
| TCP/UDP |
+--------------------------+
+--------------------------+
| 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依赖TCP和UDP提供的服务来传输MIH消息，并依赖DHCP和DNS进行对等发现。在对等MIHF IP地址未预先配置的情况下，源MIHF需要通过DHCP或DNS发现它，如第5节所述。一旦发现对等MIHF，MIHF必须通过UDP或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需要唯一标识提供移动服务（MoS）的MIHF端点。因此，MIHF标识符需要在提供移动服务的域内是唯一的，并且独立于配置的IP地址。MIMFID必须以FQDN[RFC2181]或NAI[RFC4282]的形式表示。可以通过第5节中描述的发现方法预配置或发现MIMFID。
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
MoS发现方法取决于MN是否尝试在家庭网络、到访网络或既不是家庭网络也不是到访网络的第三方远程网络中发现移动服务器。如果MN已经
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.
如果预先配置了移动服务器地址，则无需运行发现过程。如果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。
5.1. MoS Discovery When MN and MoSh Are in the Home Network (Scenario S1)
5.1. 当MN和MoSh在家庭网络中时的MoS发现（场景S1）
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可以使用DHCP选项进行MoS发现[RFC5678]，如图6b所示（在某些部署中，可能不存在DHCP中继）。
(a) +-------+
+----+ |Domain |
| MN |-------->|Name |
+----+ |Server |
MN@example.org +-------+
(a) +-------+
+----+ |Domain |
| MN |-------->|Name |
+----+ |Server |
MN@example.org +-------+
(b)
+-----+ +------+
+----+ | | |DHCP |
| MN |<----->| DHCP|<---->|Server|
+----+ |Relay| | |
+-----+ +------+
(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. 当MN和MoSv都在访问网络中时的MoS发现（场景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应尝试使用DHCP选项进行MoS发现[RFC5678]，如图7所示。
+-----+ +------+
+----+ | | |DHCP |
| MN |<----->| DHCP|<---->|Server|
+----+ |Relay| | |
+-----+ +------+
+-----+ +------+
+----+ | | |DHCP |
| MN |<----->| DHCP|<---->|Server|
+----+ |Relay| | |
+-----+ +------+
Figure 7: MoS Discovery Using DHCP Options
图7：使用DHCP选项的MoS发现
5.3. MoS Discovery When MIH Services Are in a Third-Party Remote Network (Scenario S3)
5.3. MIH服务位于第三方远程网络中时的MoS发现（场景S3）
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必须首先了解包含其正在搜索的MoS的网络的域名。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
或者，MN可以查询先前已知的移动服务器以了解所需网络的域名。最后，MN必须使用基于DNS的发现机制来在网络中查找移动服务器
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.
远程网络如图8b所示。应当注意，步骤b只能在获得远程网络的域名时执行。
(a)
+------------+
+----+ | |
| | |Information |
| MN |-------->| Server |
| | |(previously |
+----+ |discovered) |
+------------+
(a)
+------------+
+----+ | |
| | |Information |
| MN |-------->| Server |
| | |(previously |
+----+ |discovered) |
+------------+
(b)
+-------+
+----+ |Domain |
| MN |-------->|Name |
+----+ |Server |
MN@example.org +-------+
(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:MOS发现使用（a）对已知IS服务器的IS查询，（b）DNS查询
5.4. MoS Discovery When the MN Is in a Visited Network and Services Are at the Home Network (Scenario S4)
5.4. 当MN在访问网络中且服务在家庭网络中时的MoS发现（场景S4）
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
一旦发现MoS，MIH对等方将按照[IEEE80221]中的规定运行功能发现和订阅过程。MIH对等方可以通过TCP、UDP或服务器和客户端支持的任何其他传输来交换信息。客户机可以使用DNS发现机制来发现除了本文档中推荐的TCP和UDP之外，服务器还支持哪些传输协议。尽管这两种协议都可以提供所需的基本传输功能，但在不同网络丢失和拥塞情况下，需要在MIH服务的上下文中考虑与每种协议相关的性能权衡和独特特性。本节的目的是讨论不同MIH设置（如MIH消息大小和速率以及重传参数）的权衡。此外，还讨论了NAT穿越等因素
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.
讨论。鉴于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 response原语），ES或CS的典型MIH消息大小在50到100字节之间[IEEE80221]。因此，考虑到MIH消息大小对传输协议性能的影响，我们将讨论两个主要问题，即UDP上下文中长消息的分段和TCP上下文中短消息的串联。
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，则必须根据到目标的路径MTU（或未实现PMTU的最小MTU）对MIH消息的大小设置限制。最小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层碎片一起使用，并且不得在通过TCP传输MIH数据包时使用。
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
IP片段的丢失会导致整个MIH消息的重新传输，这反过来会导致端到端延迟性能差以及带宽浪费。[RFC5405]中的其他建议适用于在使用UDP和假设IP层碎片时限制MIH消息的大小。在处理短消息方面，TCP能够连接非常短的消息，以减少总体带宽开销。然而，这种减少的开销是以完成MIH事务的额外延迟为代价的，这对于CS和ES来说可能是不可接受的。还要注意，TCP是一种面向流的协议，它以字节（而不是消息）来度量数据流。因此，如果消息足够长，可以在多个TCP段之间拆分消息。即使是短消息也可以分为两部分。这还可能导致不可接受的延迟，尤其是当MN退出无线接入覆盖区域时可能发生的链路质量严重降级时。使用TCP_节点延迟选项可以
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.)
通过触发小于SMS的段的传输来缓解此问题。（应注意，[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消息以数百毫秒一次的速度到达，以便捕获环境中的快速变化和/或处理切换命令。另一方面，IS消息主要在每次访问新网络时进行交换，可能是几小时或几天。因此，短CS/ES消息或长IS消息交换的突发（在多个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（例如，基于两个MIH对等方之间的请求/响应MIH协议交换），则速率可以基于[IEEE80221]中规定的RTT。
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
如果使用UDP传输MIH消息，MIH必须使用MIH ACK。如果生成节点在MIHF设置的超时间隔内未接收到相应的MIH ACK，则重新传输MIH消息。可配置最大重传次数，并根据[RFC2988]中定义的算法计算重传计时器的值。默认的最大用户数
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.
当RTT未知时，重传设置为2，初始重传计时器（TMO）设置为3s。最大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]（假设TCP保持活动状态为2小时）对于MIH传输而言已足够。但是，关于使用UDP进行NAT遍历的问题，请参见[RFC5405]。在应用程序不交换任何UDP流量期间，如果中间盒破坏与应用程序会话相关联的每流状态，则会出现通信故障。因此，MN和移动服务器之间的通信应该能够优雅地处理此类故障，并实现重新建立其UDP会话的机制。此外，为了避免此类故障，可以定期发送MIH消息，类似于保持活动消息，以尝试刷新中间盒状态。由于[RFC4787]需要至少2分钟或更长的状态超时，使用UDP作为传输的MIH消息应每2分钟发送一次。[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消息在延迟约束方面更具弹性，并且一些长IS消息可能超过到目的地的路径的MTU。TCP应用作所有消息的默认传输。但是，如第6.1节所述，UDP与MIH确认相结合应用于传输短于或等于路径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和移动服务器都在MN的家庭网络中时，MIHF对等方之间的示例操作流程。DHCP用于移动服务（MoS）发现，TCP用于建立传输连接以承载is消息。当未预先配置移动服务器时，MIH用户需要发现移动服务器的IP地址以与远程MIHF通信。因此，MIH用户向本地MIHF发送发现请求消息，如[IEEE80221]中所定义。
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建立传输连接之前执行MoS发现，并且通过一些内部API调用DHCP客户端进程。DHCP客户端根据标准DHCP和[RFC5678]中定义的MoS选项发送DHCP通知消息。DHCP服务器通过DHCP ACK消息回复移动服务器的IP地址。然后，移动服务器地址通过一些内部API本地传递给MIHF。MIHF生成发现响应消息并将其传递给相应的MIH用户。MIH用户生成一个地址为远程移动服务器的查询。MIHF调用底层TCP客户端，该客户端与远程对等方建立传输连接。一旦建立了传输连接，MIHF通过MIH协议请求消息发送is查询。消息和查询分别到达目标MIHF和MIH用户。移动服务器MIH用户响应相应的IS查询，移动服务器MIHF通过MIH协议响应消息发送IS响应。消息到达源MIHF，它将IS响应传递给相应的MIH用户。
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 | | | | |
| | | | | |
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传输。对于MoS发现，特此根据IETF指南提供DHCP和DNS建议。对于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）和MN无法执行适当的切换。如果网络暴露于此类DoS，建议DNS服务提供商使用[RFC4033]中所述的域名系统安全扩展（DNSSEC）。读者也可以参考[RCF461]来考虑DNSSEC操作实践的方面。
The communication between an MN and a Mobility Server is exposed to a number of security threats:
MN和移动服务器之间的通信面临许多安全威胁：
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.
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和移动服务器之间的通信通道需要通过其他方式进行保护。
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:
本文档向IANA注册以下TCP和UDP端口：
Keyword Decimal Description
-------- --------------- ------------
ieee-mih 4551/tcp MIH Services
ieee-mih 4551/udp MIH Services
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 21811997年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消息的身份验证”，RFC31182001年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的动态主机配置协议（DHCPv6）”，RFC3315，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.Erenen，“网络访问标识符”，RFC 42822005年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移动服务（MoS）发现的动态主机配置协议（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/Published%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.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第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 46412006年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，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，2007年1月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，Ed.“流控制传输协议”，RFC 49602007年9月。
[RFC5164] Melia, T., Ed., "Mobility Services Transport: Problem Statement", RFC 5164, March 2008.
[RFC5164]Melia，T.，编辑，“移动服务运输：问题陈述”，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，“传输层安全（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 56812009年9月。
Authors' Addresses
作者地址
Telemaco Melia (editor) Alcatel-Lucent Route de Villejust Nozay 91620 France
Telemaco Melia（编辑）Alcatel-Lucent法国维勒赫斯特-诺扎伊路线91620
EMail: telemaco.melia@alcatel-lucent.com
EMail: telemaco.melia@alcatel-lucent.com
Gabor Bajko Nokia
诺基亚公司
EMail: Gabor.Bajko@nokia.com
EMail: Gabor.Bajko@nokia.com
Subir Das Telcordia Technologies Inc.
苏比尔·达斯·特尔科迪亚技术公司。
EMail: subir@research.telcordia.com
EMail: subir@research.telcordia.com
Nada Golmie NIST
纳达戈尔米NIST
EMail: nada.golmie@nist.gov
EMail: nada.golmie@nist.gov
Juan Carlos Zuniga InterDigital Communications, LLC
胡安·卡洛斯·祖尼加叉指通信有限责任公司
EMail: j.c.zuniga@ieee.org
EMail: j.c.zuniga@ieee.org