Network Working Group T. Melia, Ed.
Request for Comments: 5164 Cisco Systems
Category: Informational March 2008
Network Working Group T. Melia, Ed.
Request for Comments: 5164 Cisco Systems
Category: Informational March 2008
Mobility Services Transport: Problem Statement
移动服务运输：问题陈述
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Abstract
摘要
There are ongoing activities in the networking community to develop solutions that aid in IP handover mechanisms between heterogeneous wired and wireless access systems including, but not limited to, IEEE 802.21. Intelligent access selection, taking into account link-layer attributes, requires the delivery of a variety of different information types to the terminal from different sources within the network and vice-versa. The protocol requirements for this signalling have both transport and security issues that must be considered. The signalling must not be constrained to specific link types, so there is at least a common component to the signalling problem, which is within the scope of the IETF. This document presents a problem statement for this core problem.
网络社区正在开展活动，以开发有助于异构有线和无线接入系统（包括但不限于IEEE 802.21）之间IP切换机制的解决方案。考虑到链路层属性，智能接入选择需要从网络内的不同来源向终端提供各种不同的信息类型，反之亦然。该信令的协议要求必须考虑传输和安全问题。信令不得局限于特定的链路类型，因此信令问题至少有一个共同的部分，这在IETF的范围内。本文档介绍了此核心问题的问题陈述。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................3
2.1. Requirements Language ......................................3
3. Definition of Mobility Services .................................4
4. Deployment Scenarios for MoS ....................................4
4.1. End-to-End Signalling and Transport over IP ................5
4.2. End-to-End Signalling and Partial Transport over IP ........5
4.3. End-to-End Network-to-Network Signalling ...................6
5. MoS Transport Protocol Splitting ................................7
5.1. Payload Formats and Extensibility Considerations ...........8
5.2. Requirements on the Mobility Service Transport Layer .......8
6. Security Considerations ........................................11
7. Conclusions ....................................................12
8. Acknowledgements ...............................................13
9. References .....................................................13
9.1. Normative References ......................................13
9.2. Informative References ....................................13
Contributors ......................................................14
1. Introduction ....................................................2
2. Terminology .....................................................3
2.1. Requirements Language ......................................3
3. Definition of Mobility Services .................................4
4. Deployment Scenarios for MoS ....................................4
4.1. End-to-End Signalling and Transport over IP ................5
4.2. End-to-End Signalling and Partial Transport over IP ........5
4.3. End-to-End Network-to-Network Signalling ...................6
5. MoS Transport Protocol Splitting ................................7
5.1. Payload Formats and Extensibility Considerations ...........8
5.2. Requirements on the Mobility Service Transport Layer .......8
6. Security Considerations ........................................11
7. Conclusions ....................................................12
8. Acknowledgements ...............................................13
9. References .....................................................13
9.1. Normative References ......................................13
9.2. Informative References ....................................13
Contributors ......................................................14
This document provides a problem statement for the exchange of information to support handover in heterogeneous link environments [1]. This mobility support service allows more sophisticated handover operations by making available information about network characteristics, neighboring networks and associated characteristics, indications that a handover should take place, and suggestions for suitable target networks to which to handover. The mobility support services are complementary to IP mobility mechanisms [4], [5], [6], [7], [8], [9] to enhance the overall performance and usability perception.
本文档提供了在异构链路环境中支持切换的信息交换问题陈述[1]。该移动性支持服务通过提供有关网络特征、相邻网络和相关特征的信息、应进行切换的指示以及对要切换到的合适目标网络的建议，允许更复杂的切换操作。移动性支持服务是对IP移动性机制[4]、[5]、[6]、[7]、[8]、[9]的补充，以增强整体性能和可用性感知。
There are two key attributes to the handover support service problem for inter-technology handovers:
技术间切换的切换支持服务问题有两个关键属性：
1. The Information: the information elements being exchanged. The messages could be of a different nature, such as information, commands to perform an action, or events informing of a change, potentially being defined following a common structure.
1. 信息：交换的信息元素。消息可能具有不同的性质，例如信息、执行操作的命令或通知更改的事件，可能是按照公共结构定义的。
2. The Underlying Transport: the transport mechanism to support exchange of the information elements mentioned above. This transport mechanism includes information transport, discovery of peers, and the securing of this information over the network.
2. 底层传输：支持上述信息元素交换的传输机制。这种传输机制包括信息传输、对等点的发现以及通过网络保护这些信息。
The initial requirement for this protocol comes from the need to provide a transport for the Media Independent Handover (MIH) protocol being defined by IEEE 802.21 [1], which is not bound to any specific link layer and can operate over more that one network-layer hop. The solution should be flexible to accommodate evolution in the MIH standard, and should also be applicable for other new mobility signalling protocols that have similar message patterns and discovery and transport requirements.
该协议的初始要求来自于需要为IEEE 802.21[1]定义的媒体独立切换（MIH）协议提供传输，该协议不绑定到任何特定链路层，并且可以在多个网络层跃点上运行。该解决方案应具有灵活性，以适应MIH标准的发展，并且还应适用于具有类似消息模式以及发现和传输需求的其他新移动信令协议。
The structure of this document is as follows. Section 3 defines Mobility Services. Section 4 provides a simple model for the protocol entities involved in the signalling and their possible relationships. Section 5 describes a decomposition of the signalling problem into service-specific parts and a generic transport part. Section 5.2 describes more detailed requirements for the transport component. Section 6 provides security considerations. Section 7 summarizes the conclusions and open issues.
本文件的结构如下。第3节定义了移动服务。第4节为信令中涉及的协议实体及其可能的关系提供了一个简单的模型。第5节描述了将信令问题分解为服务特定部分和通用传输部分。第5.2节描述了运输组件的更详细要求。第6节提供了安全注意事项。第7节总结了结论和未决问题。
The following abbreviations are used in the document:
本文件中使用了以下缩写：
MIH: Media Independent Handover
MIH：媒体独立切换
MN: Mobile Node
移动节点
NN: Network Node, intended to represent some device in the network (the location of the node, e.g., in the access network, the home network is not specified, and for the moment it is assumed that they can reside anywhere).
NN：网络节点，用于表示网络中的某些设备（节点的位置，例如，在接入网络中，未指定家庭网络，目前假定它们可以驻留在任何地方）。
EP: Endpoint, intended to represent the terminating endpoints of the transport protocol used to support the signalling exchanges between nodes.
EP：端点，用于表示传输协议的终止端点，用于支持节点之间的信令交换。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[2]中所述进行解释。
As mentioned in the Introduction, mobility (handover) support in heterogeneous wireless environments requires functional components located either in the mobile terminal or in the network to exchange information and eventually to make decisions upon this information exchange. For instance, traditional host-based handover solutions could be complemented with more sophisticated network-centric solutions. Also, neighborhood discovery, potentially a complex operation in heterogeneous wireless scenarios, can result in a simpler step if implemented with a unified interface towards the access network.
如引言中所述，异构无线环境中的移动性（切换）支持需要位于移动终端或网络中的功能组件来交换信息，并最终根据该信息交换做出决策。例如，传统的基于主机的切换解决方案可以与更复杂的以网络为中心的解决方案相补充。此外，邻域发现，在异构无线场景中可能是一项复杂的操作，如果使用面向接入网络的统一接口实现，则可以实现更简单的步骤。
In this document, the different supporting functions for Media Independent Handover (MIH) management are generally referred to as Mobility Services (MoS) that have different requirements for the transport protocol. These requirements and associated functionalities are the focus of this document. Speaking 802.21 terminology, MoS can be regarded as Information Services (IS), Event Services (ES), and Command Service (CS).
在本文档中，媒体独立切换（MIH）管理的不同支持功能通常称为对传输协议有不同要求的移动服务（MoS）。这些要求和相关功能是本文件的重点。说到802.21术语，MoS可以被视为信息服务（IS）、事件服务（ES）和命令服务（CS）。
The deployment scenarios are outlined in the following sections.
以下各节概述了部署场景。
Note: while MN-to-MN signalling exchanges are theoretically possible, these are not currently being considered.
注：虽然MN-to-MN信令交换在理论上是可能的，但目前并未考虑这些交换。
The following scenarios are discussed for understanding the overall problem of transporting MIH protocol. Although these are all possible scenarios and MIH services can be delivered through link-layer specific solutions and/or through a "layer 3 or above" protocol, this problem statement focuses on the delivery of information for Mobility Services only for the latter case.
为了理解传输MIH协议的总体问题，将讨论以下场景。尽管这些都是可能的场景，并且MIH服务可以通过链路层特定的解决方案和/或通过“第3层或以上”协议交付，但本问题陈述仅关注后一种情况下的移动服务信息交付。
In this case, the end-to-end signalling used to exchange the handover information elements (the Information Exchange) runs end-to-end between MN and NN. The underlying transport is also end-to-end.
在这种情况下，用于交换切换信息元素（信息交换）的端到端信令在MN和NN之间端到端地运行。底层传输也是端到端的。
+------+ +------+
| MN | | NN |
| (EP) | | (EP) |
+------+ +------+
Information Exchange
<------------------------------------>
+------+ +------+
| MN | | NN |
| (EP) | | (EP) |
+------+ +------+
Information Exchange
<------------------------------------>
/------------------------------------\
< Transport over IP >
\------------------------------------/
/------------------------------------\
< Transport over IP >
\------------------------------------/
Figure 1: End-to-End Signalling and Transport
图1：端到端信令和传输
As before, the Information Exchange runs end-to-end between the MN and the second NN. However, in this scenario, some transport means other than IP are used from the MN to the first NN, and the transport over IP is used only between NNs. This is analogous to the use of EAP end-to-end between Supplicant and Authentication Server, with an upper-layer multihop protocol, such as Remote Authentication Dial-In User Service (RADIUS), used as a backhaul transport protocol between an Access Point and the Authentication Server.
与之前一样，在MN和第二个NN之间进行端到端的信息交换。然而，在此场景中，从MN到第一个NN使用IP以外的一些传输手段，并且IP传输仅在NN之间使用。这类似于在请求者和身份验证服务器之间使用EAP端到端，上层多跳协议（如远程身份验证拨入用户服务（RADIUS））用作接入点和身份验证服务器之间的回程传输协议。
+------+ +------+ +------+
| MN | | NN | | NN |
| | | (EP) | | (EP) |
+------+ +------+ +------+
Information Exchange
<------------------------------------>
+------+ +------+ +------+
| MN | | NN | | NN |
| | | (EP) | | (EP) |
+------+ +------+ +------+
Information Exchange
<------------------------------------>
(Transport over /------------------\
<--------------->< Transport over IP >
e.g. L2) \------------------/
(Transport over /------------------\
<--------------->< Transport over IP >
e.g. L2) \------------------/
Figure 2: Partial Transport
图2：部分运输
In this case, NN to NN signalling is envisioned. Such a model should allow different network components to gather information from each other. This is useful for instance in conditions where network components need to make decisions and instruct mobile terminals of operations to be executed.
在这种情况下，设想NN到NN信令。这种模型应该允许不同的网络组件相互收集信息。例如，在网络组件需要做出决策并指示移动终端执行操作的情况下，这是有用的。
+------+ +------+
| NN | | NN |
| (EP) | | (EP) |
+------+ +------+
Information Exchange
------------------->
<-------------------
+------+ +------+
| NN | | NN |
| (EP) | | (EP) |
+------+ +------+
Information Exchange
------------------->
<-------------------
/----------------\
< Transport >
\----------------/
/----------------\
< Transport >
\----------------/
Figure 3: Information Exchange between Different NNs
图3：不同NN之间的信息交换
Network nodes exchange information about the status of connected terminals.
网络节点交换有关连接终端状态的信息。
Figure 4 shows a model where the Information Exchanges are implemented by a signalling protocol specific to a particular mobility service, and these are relayed over a generic transport layer (the Mobility Service Transport Layer).
图4显示了一个模型，其中信息交换由特定于特定移动服务的信令协议实现，并且这些协议通过通用传输层（移动服务传输层）中继。
+----------------+ ^
|Mobility Support| |
| Service 2 | |
+----------------+ | | | Mobility Service
|Mobility Support| +----------------+ | Signaling
| Service 1 | +----------------+ | Layer
| | |Mobility Support| |
+----------------+ | Service 3 | |
| | |
+----------------+ V
================================================
+---------------------------------------+ ^ Mobility Service
| Mobility Service Transport Protocol | | Transport
+---------------------------------------+ V Layer
================================================
+---------------------------------------+
| IP |
+---------------------------------------+
+----------------+ ^
|Mobility Support| |
| Service 2 | |
+----------------+ | | | Mobility Service
|Mobility Support| +----------------+ | Signaling
| Service 1 | +----------------+ | Layer
| | |Mobility Support| |
+----------------+ | Service 3 | |
| | |
+----------------+ V
================================================
+---------------------------------------+ ^ Mobility Service
| Mobility Service Transport Protocol | | Transport
+---------------------------------------+ V Layer
================================================
+---------------------------------------+
| IP |
+---------------------------------------+
Figure 4: Handover Services over IP
图4：IP上的切换服务
The Mobility Service Transport Layer provides certain functionality (outlined in Section 5.2) to the higher-layer mobility support services in order to support the exchange of information between communicating Mobility Service functions. The transport layer effectively provides a container capability to mobility support services, as well as any required transport and security operations required to provide communication, without regard to the protocol semantics and data carried in the specific Mobility Services.
移动性服务传输层向更高层的移动性支持服务提供某些功能（在第5.2节中概述），以支持通信移动性服务功能之间的信息交换。传输层有效地为移动支持服务以及提供通信所需的任何传输和安全操作提供容器能力，而不考虑特定移动服务中承载的协议语义和数据。
The Mobility Support Services themselves may also define certain protocol exchanges to support the exchange of service-specific information elements. It is likely that the responsibility for defining the contents and significance of the information elements is the responsibility of standards bodies other than the IETF. Example Mobility Services include the Information Services, Event Services, and Command Services.
移动支持服务本身还可以定义某些协议交换，以支持特定于服务的信息元素的交换。定义信息元素的内容和重要性的责任很可能是IETF以外的标准机构的责任。示例移动服务包括信息服务、事件服务和指挥服务。
The format of the Mobility Service Transport Protocol (MSTP) is as follows:
移动服务传输协议（MSTP）的格式如下：
+----------------+----------------------------------------+
|Mobility Service| Opaque Payload |
|Transport Header| (Mobility Support Service) |
+----------------+----------------------------------------+
+----------------+----------------------------------------+
|Mobility Service| Opaque Payload |
|Transport Header| (Mobility Support Service) |
+----------------+----------------------------------------+
Figure 5: Protocol Structure
图5：协议结构
This figure shows the case for an MIH message that is smaller than the MTU of the path to the destination. A larger payload may require the transport protocol to transparently fragment and reassemble the MIH message.
此图显示了小于目标路径MTU的MIH消息的情况。更大的有效载荷可能需要传输协议透明地分割和重新组装MIH消息。
The opaque payload encompasses the Mobility Support Service (MSTP) information that is to be transported. The definition of the Mobility Service Transport Header is something that is best addressed within the IETF. MSTP does not inspect the payload, and any required information will be provided by the MSTP users.
不透明有效载荷包含要传输的移动支持服务（MSTP）信息。移动服务传输报头的定义最好在IETF中解决。MSTP不检查有效载荷，任何所需信息将由MSTP用户提供。
The following section outlines some of the general transport requirements that should be supported by the Mobility Service Transport Protocol. Analysis has suggested that at least the following need to be taken into account:
以下部分概述了移动服务传输协议应支持的一些一般传输要求。分析表明，至少需要考虑以下因素：
Discovery: MNs need the ability to either discover nodes that support certain services or discover services provided by a certain node. The service discovery can be dealt with using messages as defined in [1]. This section refers to node-discovery in either scenario. There are no assumptions about the location of these Mobility Service nodes within the network. Therefore, the discovery mechanism needs to operate across administrative boundaries. Issues such as speed of discovery, protection against spoofing, when discovery needs to take place, and the length of time over which the discovery information may remain valid; all need to be considered. Approaches include:
发现：MNs需要能够发现支持特定服务的节点或发现特定节点提供的服务。可以使用[1]中定义的消息处理服务发现。本节介绍两种场景中的节点发现。没有关于这些移动服务节点在网络中的位置的假设。因此，发现机制需要跨管理边界运行。发现速度、防欺骗保护、何时需要进行发现以及发现信息可能保持有效的时间长度等问题；所有这些都需要考虑。方法包括：
* Hard coding information into the MN, indicating either the IP address of the NN, or information about the NN that can be resolved onto an IP address. The configuration information could be managed dynamically, but assumes that the NN is independent of the access network to which the MN is currently attached.
* 将信息硬编码到MN中，指示NN的IP地址，或可解析为IP地址的关于NN的信息。配置信息可以动态管理，但假设NN独立于MN当前连接的接入网络。
* Pushing information to the MN, where the information is delivered to the MN as part of other configuration operations, for example, via DHCP or Router Discovery exchange. The benefit of this approach is that no additional exchanges with the network would be required, but the limitations associated with modifying these protocols may limit applicability of the solution.
* 将信息推送到MN，其中信息作为其他配置操作的一部分传递到MN，例如，通过DHCP或路由器发现交换。这种方法的好处是不需要与网络进行额外的交换，但与修改这些协议相关的限制可能会限制解决方案的适用性。
* MN dynamically requesting information about a node, which may require both MN and NN support for a particular service discovery mechanism. This may require additional support by the access network (e.g., multicast or anycast) even when it may not be supporting the service directly itself.
* MN动态请求关于节点的信息，这可能需要对特定服务发现机制的MN和NN支持。这可能需要接入网络的额外支持（例如，多播或选播），即使它可能不直接支持服务本身。
Numerous directory and configuration services already exist, and reuse of these mechanisms may be appropriate. There is an open question about whether multiple methods of discovery would be needed, and whether NNs would also need to discover other NNs. The definition of a service also needs to be determined, including the granularity of the description. For example, IEEE 802.21 specifies three different types of Mobility Services (Information Services, Command Services, and Event Services) that can be located in different portions of the network. An MN could therefore run a discovery procedure of any service running in the (home or visited) network or could run a discovery procedure for a specific service.
许多目录和配置服务已经存在，重用这些机制可能是合适的。关于是否需要多种发现方法，以及NNs是否也需要发现其他NN，还有一个悬而未决的问题。还需要确定服务的定义，包括描述的粒度。例如，IEEE 802.21规定了可位于网络不同部分的三种不同类型的移动服务（信息服务、命令服务和事件服务）。因此，MN可以运行（家庭或访问）网络中运行的任何服务的发现过程，或者可以运行特定服务的发现过程。
Information from a trusted source: The MN uses the Mobility Service information to make decisions about what steps to take next. It is essential that there is some way to ensure that the information received is from a trustworthy source. This requirement should reuse trust relationships that have already been established in the network, for example, on the relationships established by the Authentication, Authorization, and Accounting (AAA) infrastructure after a mutual authentication, or on the certificate infrastructure required to support SEND [10]. Section 6 provides a more complete analysis.
来自可信来源的信息：MN使用移动服务信息来决定下一步要采取什么步骤。必须有某种方法确保收到的信息来源可靠。此要求应重用网络中已经建立的信任关系，例如，在相互身份验证后由身份验证、授权和记帐（AAA）基础设施建立的关系上，或在支持发送所需的证书基础设施上[10]。第6节提供了更完整的分析。
Security association management: A common security association negotiation method, independent of any specific MSTP user, should be implemented between the endpoints of the MSTP. The solution must also work in the case of MN mobility.
安全关联管理：应该在MSTP的端点之间实现一种通用的安全关联协商方法，该方法独立于任何特定的MSTP用户。该解决方案也必须适用于MN迁移率的情况。
Secure delivery: The Mobility Service information must be delivered securely (integrity and confidentiality) between trusted peers, where the transport may pass though untrusted intermediate nodes and networks. The Mobility Service information should also be protected against replay attacks and denial-of-service attacks.
安全交付：移动服务信息必须在受信任的对等方之间安全交付（完整性和机密性），其中传输可能通过不受信任的中间节点和网络。还应保护移动服务信息免受重播攻击和拒绝服务攻击。
Low latency: Some of the Mobility Services generate time-sensitive information. Therefore, there is a need to deliver the information over quite short timescales, and the required lifetime of a connection might be quite short-lived. As an example, the frequency of messages defined in [1] varies according to the MIH service type. It is expected that Events and Commands messages arrive at an interval of hundreds of milliseconds in order to capture quick changes in the environment and/or process handover commands. On the other hand, Information Service messages are mainly exchanged each time a new network is visited that may be in the order of hours or days. For reliable delivery, short-lived connections could be set up as needed, although there is a connection setup latency associated with this approach. Alternatively, a long-lived connection could be used, but this requires advanced warning of being needed and some way to maintain the state associated with the connection. It also assumes that the relationships between devices supporting the mobility service are fairly stable. Another alternative is connectionless operation, but this has interactions with other requirements, such as reliable delivery.
低延迟：一些移动服务生成对时间敏感的信息。因此，需要在很短的时间内交付信息，并且所需的连接生命周期可能很短。例如，[1]中定义的消息频率根据MIH服务类型而变化。预计事件和命令消息以数百毫秒的间隔到达，以便捕获环境中的快速变化和/或处理移交命令。另一方面，信息服务消息主要在每次访问新网络时交换，访问时间可能为小时或天。为了实现可靠的传输，可以根据需要设置短期连接，尽管这种方法存在连接设置延迟。或者，也可以使用长寿命的连接，但这需要提前发出警告，并以某种方式维护与连接关联的状态。它还假设支持移动服务的设备之间的关系相当稳定。另一种选择是无连接操作，但这与其他需求（如可靠交付）有交互作用。
Reliability: Reliable delivery for some of the Mobility Services may be essential, but it is difficult to trade this off against the low latency requirement. It is also quite difficult to design a robust, high-performance mechanism that can operate in heterogeneous environments, especially one where the link characteristics can vary quite dramatically. There are two main approaches that could be adopted:
可靠性：某些移动服务的可靠交付可能至关重要，但很难与低延迟要求进行权衡。设计一种能够在异构环境中运行的健壮、高性能的机制也是相当困难的，尤其是在链路特性变化非常大的环境中。可以采用两种主要方法：
1. Assume the transport cannot be guaranteed to support reliable delivery. In this case, the Mobility Support Service itself will have to provide a reliability mechanism (at the MIH level) to allow communicating endpoints to acknowledge receipt of information.
1. 假设无法保证传输支持可靠的交付。在这种情况下，移动支持服务本身必须提供一种可靠性机制（在MIH级别），以允许通信端点确认信息的接收。
2. Assume the underlying transport will provide reliable delivery. There is no need in this case to provide reliability at the MIH level.
2. 假设基础传输将提供可靠的交付。在这种情况下，没有必要在MIH级别提供可靠性。
Guidelines provided in [3] are being considered while writing this document.
在编写本文件时，正在考虑[3]中提供的指南。
Congestion Control: A Mobility Service may wish to transfer small or large amounts of data, placing different requirements for congestion control in the transport. As an example, the MIH message [1] size varies widely from about 30 bytes (for a broadcast capability discovery request) to be normally less than 64 KB, but may be greater than 64KB (for an IS MIH_Get_Information
拥塞控制：移动服务可能希望传输少量或大量数据，从而对传输中的拥塞控制提出不同的要求。例如，MIH消息[1]大小变化很大，从大约30字节（对于广播能力发现请求）到通常小于64KB，但可能大于64KB（对于IS MIH_Get_信息）
response primitive). A typical MIH message size for the Events and Commands Services service ranges between 50 to 100 bytes. The solution should consider different congestion control mechanisms depending on the amount of data generated by the application (MIH) as suggested in [3].
响应原语）。事件和命令服务的典型MIH消息大小在50到100字节之间。该解决方案应该考虑不同的拥塞控制机制，这取决于应用程序（MIH）生成的数据量（如3）中所建议的。
Fragmentation and reassembly: ES and CS messages are small in nature, are sent frequently, and may wish trade reliability in order to satisfy the tight latency requirements. On the other hand, IS messages are more resilient in terms of latency constraints, and some long IS messages could exceed the MTU of the path to the destination. Depending on the choice of the transport protocol, different fragmentation and reassembly strategies are required.
碎片化和重组：ES和CS消息本质上很小，发送频繁，可能希望交易可靠性以满足紧凑的延迟要求。另一方面，IS消息在延迟约束方面更具弹性，并且一些长IS消息可能超过到目的地的路径的MTU。根据传输协议的选择，需要不同的分段和重组策略。
Multihoming: For some Information Services exchanged with the MN, there is a possibility that the request and response messages could be carried over two different links. For example, a handover command request is on the current link while the response could be delivered on the new link. It is expected that the transport protocol is capable of receiving information via multiple links. It is also expected that the MSTP user combines information belonging to the same session/transaction. When mobility is applied, the underlying IP mobility mechanism should provide session continuity when required.
多宿主：对于与MN交换的某些信息服务，请求和响应消息可能通过两个不同的链路传输。例如，切换命令请求在当前链路上，而响应可以在新链路上传递。预计传输协议能够通过多个链路接收信息。还期望MSTP用户组合属于同一会话/事务的信息。当应用移动性时，底层IP移动性机制应在需要时提供会话连续性。
IPv4 and IPv6 support: The MSTP must support both IPv4 and IPv6 including NAT traversal for IPv4 networks and firewall pass-through for IPv4 and IPv6 networks.
IPv4和IPv6支持：MSTP必须同时支持IPv4和IPv6，包括IPv4网络的NAT穿越和IPv4和IPv6网络的防火墙穿越。
Network-supported Mobility Services aim at improving decision making and management of dynamically connected hosts.
网络支持的移动服务旨在改进动态连接主机的决策和管理。
Information Services may not require authorization of the client, but both Event and Command Services may authenticate message sources, particularly if they are mobile. Network-side service entities will typically need to provide proof of authority to serve visiting devices. Where signalling or radio operations can result from received messages, significant disruption may result from processing bogus or modified messages. The effect of processing bogus messages depends largely upon the content of the message payload, which is handled by the handover services application. Regardless of the variation in effect, message delivery mechanisms need to provide protection against tampering, spoofing, and replay attacks.
信息服务可能不需要客户机的授权，但事件和命令服务都可以对消息源进行身份验证，特别是在消息源是移动的情况下。网络端服务实体通常需要提供为访问设备提供服务的授权证明。如果接收到的消息可能导致信令或无线电操作，则处理伪造或修改的消息可能会导致重大中断。处理虚假消息的效果在很大程度上取决于由切换服务应用程序处理的消息有效负载的内容。无论效果如何，消息传递机制都需要提供保护，以防篡改、欺骗和重播攻击。
Sensitive and identifying information about a mobile device may be exchanged during handover-service message exchange. Since handover decisions are to be made based upon message exchanges, it may be possible to trace a user's movement between cells, or predict future movements, by inspecting handover service messages. In order to prevent such tracking, message confidentiality and message integrity should be available. This is particularly important because many mobile devices are associated with only one user, since divulging of such information may violate the user's privacy. Additionally, identifying information may be exchanged during security association construction. As this information may be used to trace users across cell boundaries, identity protection should be available, if possible, when establishing source addresses (SAs).
在切换服务消息交换期间，可以交换关于移动设备的敏感和识别信息。由于切换决策将基于消息交换作出，因此可以通过检查切换服务消息来跟踪用户在小区之间的移动或预测未来的移动。为了防止此类跟踪，应提供消息机密性和消息完整性。这一点尤其重要，因为许多移动设备仅与一个用户关联，因为泄露此类信息可能会侵犯用户的隐私。此外，在安全关联构建期间，可以交换标识信息。由于此信息可用于跨单元边界跟踪用户，因此在建立源地址（SA）时，如果可能，应提供身份保护。
In addition, the user should not have to disclose its identity to the network (anymore than it needed to during authentication) in order to access the Mobility Support Services. For example, if the local network is just aware that an anonymous user with a subscription to "example.com" is accessing the network, the user should not have to divulge their true identity in order to access the Mobility Support Services available locally.
此外，为了访问移动支持服务，用户不必向网络透露其身份（在认证期间不必透露）。例如，如果本地网络刚刚意识到订阅了“example.com”的匿名用户正在访问网络，则该用户不必为了访问本地可用的移动支持服务而泄露其真实身份。
Finally, the NNs themselves will potentially be subject to denial-of-service attacks from MNs, and these problems will be exacerbated if operation of the Mobility Service protocols imposes a heavy computational load on the NNs. The overall design has to consider at what stage (e.g., discovery, transport layer establishment, and service-specific protocol exchange) denial-of-service prevention or mitigation should be built in.
最后，NNs本身将可能受到来自MNs的拒绝服务攻击，并且如果移动服务协议的操作对NNs施加沉重的计算负载，则这些问题将加剧。总体设计必须考虑在什么阶段（例如发现、传输层建立和服务特定协议交换）拒绝服务的预防或缓解。
This document outlined a broad problem statement for the signalling of information elements across a network to support Mobility Services. In order to enable this type of signalling service, a need for a generic transport solution with certain transport and security properties was outlined. Whilst the motivation for considering this problem has come from work within IEEE 802.21, a desirable goal is to ensure that solutions to this problem are applicable to a wider range of Mobility Services.
本文件概述了支持移动服务的网络信息元素信令的广泛问题陈述。为了实现这种类型的信令服务，需要一种具有某些传输和安全特性的通用传输解决方案。虽然考虑此问题的动机来自IEEE 802.21中的工作，但理想的目标是确保此问题的解决方案适用于更广泛的移动服务。
It would be valuable to establish realistic performance goals for the solution to this common problem (i.e., transport and security aspects) using experience from previous IETF work in this area and knowledge about feasible deployment scenarios. This information could then be used as an input to other standards bodies in assisting them to design Mobility Services with feasible performance requirements.
利用以往IETF在这一领域的工作经验和关于可行部署场景的知识，为解决这一常见问题（即运输和安全方面）建立现实的性能目标是很有价值的。这些信息可以作为其他标准机构的输入，帮助他们设计具有可行性能要求的移动服务。
Much of the functionality required for this problem is available from existing IETF protocols or combination thereof. This document takes no position on whether an existing protocol can be adapted for the solution or whether new protocol development is required. In either case, we believe that the appropriate skills for development of protocols in this area lie in the IETF.
该问题所需的大部分功能可从现有IETF协议或其组合中获得。本文件对现有协议是否适用于解决方案或是否需要开发新协议不作任何说明。在这两种情况下，我们都认为在这一领域开发协议的适当技能在于IETF。
Thanks to Subir Das, Juan Carlos Zuniga, Robert Hancock, and Yoshihiro Ohba for their input. Thanks to the IEEE 802.21 chair, Vivek Gupta, for coordinating the work and supporting the IETF liaison. Thanks to all IEEE 802.21 WG folks who contributed to this document indirectly.
感谢苏比尔·达斯、胡安·卡洛斯·祖尼加、罗伯特·汉考克和大叶吉弘的投入。感谢IEEE 802.21主席Vivek Gupta协调工作并支持IETF联络。感谢所有间接参与本文档的IEEE 802.21 WG人员。
[1] "Draft IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services", IEEE LAN/MAN Draft IEEE P802.21/D07.00, July 2007.
[1] “局域网和城域网IEEE标准草案：媒体独立切换服务”，IEEE LAN/MAN草案IEEE P802.21/D07.00，2007年7月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for Application Designers", Work in Progress.
[3] Eggert，L.和G.Fairhurst，“应用程序设计者的UDP使用指南”，正在进行中。
[4] 3GPP, "3GPP system architecture evolution (SAE): Report on technical options and conclusions", 3GPP TR 23.882 0.10.1, February 2006.
[4] 3GPP，“3GPP系统架构演进（SAE）：技术选择和结论报告”，3GPP TR 23.882 0.10.11906年2月。
[5] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[5] Perkins，C.，编辑，“IPv4的IP移动支持”，RFC 3344，2002年8月。
[6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[6] Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[7] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[7] Moskowitz，R.和P.Nikander，“主机身份协议（HIP）体系结构”，RFC4423，2006年5月。
[8] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
[8] Eronen，P.，“IKEv2移动性和多址协议（MOBIKE）”，RFC4552006年6月。
[9] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.
[9] Koodli，R.，Ed.，“移动IPv6的快速切换”，RFC 4068，2005年7月。
[10] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[10] Arkko，J.，Ed.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
Contributors' Addresses
投稿人地址
Eleanor Hepworth Siemens Roke Manor Research Roke Manor Romsey, SO51 5RE UK
Eleanor Hepworth西门子Roke Manor Research Roke Manor Romsey，英国SO51 5RE
EMail: eleanor.hepworth@roke.co.uk
EMail: eleanor.hepworth@roke.co.uk
Srivinas Sreemanthula Nokia Research Center 6000 Connection Dr. Irving, TX 75028 USA
Srivinas Sreemanthula诺基亚研究中心6000连接美国德克萨斯州欧文博士75028
EMail: srinivas.sreemanthula@nokia.com
EMail: srinivas.sreemanthula@nokia.com
Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscateway NJ 08854 USA
美国新泽西州皮斯卡特韦特尔科迪亚大道1号东芝美国研究公司大叶吉弘08854
EMail: yohba@tari.toshiba.com
EMail: yohba@tari.toshiba.com
Vivek Gupta Intel Corporation 2111 NE 25th Avenue Hillsboro, OR 97124 USA
维韦克·古普塔英特尔公司美国希尔斯伯勒东北25大道2111号，邮编：97124
Phone: +1 503 712 1754
EMail: vivek.g.gupta@intel.com
Phone: +1 503 712 1754
EMail: vivek.g.gupta@intel.com
Jouni Korhonen TeliaSonera Corporation. P.O.Box 970 FIN-00051 Sonera FINLAND
Jouni Korhonen TeliaSonera公司。芬兰索内拉邮政信箱970 FIN-00051
Phone: +358 40 534 4455
EMail: jouni.korhonen@teliasonera.com
Phone: +358 40 534 4455
EMail: jouni.korhonen@teliasonera.com
Rui L.A. Aguiar Instituto de Telecomunicacoes Universidade de Aveiro Aveiro 3810 Portugal
鲁伊L.A.阿圭亚电信研究所葡萄牙阿维罗大学3810
Phone: +351 234 377900
EMail: ruilaa@det.ua.pt
Phone: +351 234 377900
EMail: ruilaa@det.ua.pt
Sam(Zhongqi) Xia Huawei Technologies Co., Ltd HuaWei Bld., No.3 Xinxi Rd. Shang-Di Information Industry Base 100085 Hai-Dian District Beijing, P.R. China
Sam（中旗）夏华为技术有限公司中国北京市海淀区上地信息产业基地新西路3号华为大厦100085
Phone: +86-10-82836136
EMail: xiazhongqi@huawei.com
Phone: +86-10-82836136
EMail: xiazhongqi@huawei.com
Authors' Addresses
作者地址
Telemaco Melia, Editor Cisco Systems International Sarl Avenue des Uttins 5 1180 Rolle Switzerland (FR)
Telemaco Melia，编辑Cisco Systems International Sarl Avenue des Uttins 5 1180 Rolle Switzerland（FR）
Phone: +41 21 822718
EMail: tmelia@cisco.com
Phone: +41 21 822718
EMail: tmelia@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.