Internet Engineering Task Force (IETF) T. Sanda, Ed.
Request for Comments: 5980 Panasonic
Category: Informational X. Fu
ISSN: 2070-1721 University of Goettingen
S. Jeong
HUFS
J. Manner
Aalto University
H. Tschofenig
Nokia Siemens Networks
March 2011
Internet Engineering Task Force (IETF) T. Sanda, Ed.
Request for Comments: 5980 Panasonic
Category: Informational X. Fu
ISSN: 2070-1721 University of Goettingen
S. Jeong
HUFS
J. Manner
Aalto University
H. Tschofenig
Nokia Siemens Networks
March 2011
NSIS Protocol Operation in Mobile Environments
NSIS协议在移动环境中的运行
Abstract
摘要
Mobility of an IP-based node affects routing paths, and as a result, can have a significant effect on the protocol operation and state management. This document discusses the effects mobility can cause to the Next Steps in Signaling (NSIS) protocol suite, and shows how the NSIS protocols operate in different scenarios with mobility management protocols.
基于IP的节点的移动性会影响路由路径，因此会对协议操作和状态管理产生重大影响。本文档讨论了移动性可能对信令（NSIS）协议套件中的下一步造成的影响，并展示了NSIS协议如何在使用移动性管理协议的不同场景中运行。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5980.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5980.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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 Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation and Terminology . . . . . . . . . . . . 4
3. Challenges with Mobility . . . . . . . . . . . . . . . . . . . 5
4. Basic Operations for Mobility Support . . . . . . . . . . . . 8
4.1. General Functionality . . . . . . . . . . . . . . . . . . 8
4.2. QoS NSLP . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. NATFW NSLP . . . . . . . . . . . . . . . . . . . . . . . . 12
4.4. Localized Signaling in Mobile Scenarios . . . . . . . . . 13
4.4.1. CRN Discovery . . . . . . . . . . . . . . . . . . . . 15
4.4.2. Localized State Update . . . . . . . . . . . . . . . . 15
5. Interaction with Mobile IPv4/v6 . . . . . . . . . . . . . . . 16
5.1. Interaction with Mobile IPv4 . . . . . . . . . . . . . . . 17
5.2. Interaction with Mobile IPv6 . . . . . . . . . . . . . . . 19
5.3. Interaction with Mobile IP Tunneling . . . . . . . . . . . 20
5.3.1. Sender-Initiated Reservation with Mobile IP Tunnel . . 20
5.3.2. Receiver-Initiated Reservation with Mobile IP
Tunnel . . . . . . . . . . . . . . . . . . . . . . . . 23
5.3.3. CRN Discovery and State Update with Mobile IP
Tunneling . . . . . . . . . . . . . . . . . . . . . . 24
6. Further Studies . . . . . . . . . . . . . . . . . . . . . . . 25
6.1. NSIS Operation in the Multihomed Mobile Environment . . . 25
6.1.1. Selecting the Best Interface(s) or CoA(s) . . . . . . 26
6.1.2. Differentiation of Two Types of CRNs . . . . . . . . . 27
6.2. Interworking with Other Mobility Protocols . . . . . . . . 28
6.3. Intermediate Node Becomes a Dead Peer . . . . . . . . . . 29
7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.1. Normative References . . . . . . . . . . . . . . . . . . . 30
10.2. Informative References . . . . . . . . . . . . . . . . . . 30
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation and Terminology . . . . . . . . . . . . 4
3. Challenges with Mobility . . . . . . . . . . . . . . . . . . . 5
4. Basic Operations for Mobility Support . . . . . . . . . . . . 8
4.1. General Functionality . . . . . . . . . . . . . . . . . . 8
4.2. QoS NSLP . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. NATFW NSLP . . . . . . . . . . . . . . . . . . . . . . . . 12
4.4. Localized Signaling in Mobile Scenarios . . . . . . . . . 13
4.4.1. CRN Discovery . . . . . . . . . . . . . . . . . . . . 15
4.4.2. Localized State Update . . . . . . . . . . . . . . . . 15
5. Interaction with Mobile IPv4/v6 . . . . . . . . . . . . . . . 16
5.1. Interaction with Mobile IPv4 . . . . . . . . . . . . . . . 17
5.2. Interaction with Mobile IPv6 . . . . . . . . . . . . . . . 19
5.3. Interaction with Mobile IP Tunneling . . . . . . . . . . . 20
5.3.1. Sender-Initiated Reservation with Mobile IP Tunnel . . 20
5.3.2. Receiver-Initiated Reservation with Mobile IP
Tunnel . . . . . . . . . . . . . . . . . . . . . . . . 23
5.3.3. CRN Discovery and State Update with Mobile IP
Tunneling . . . . . . . . . . . . . . . . . . . . . . 24
6. Further Studies . . . . . . . . . . . . . . . . . . . . . . . 25
6.1. NSIS Operation in the Multihomed Mobile Environment . . . 25
6.1.1. Selecting the Best Interface(s) or CoA(s) . . . . . . 26
6.1.2. Differentiation of Two Types of CRNs . . . . . . . . . 27
6.2. Interworking with Other Mobility Protocols . . . . . . . . 28
6.3. Intermediate Node Becomes a Dead Peer . . . . . . . . . . 29
7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.1. Normative References . . . . . . . . . . . . . . . . . . . 30
10.2. Informative References . . . . . . . . . . . . . . . . . . 30
Mobility of IP-based nodes incurs route changes, usually at the edge of the network. Since IP addresses are usually part of flow identifiers, the change of IP addresses implies the change of flow identifiers (i.e., the General Internet Signaling Transport (GIST) message routing information or Message Routing Information (MRI) [RFC5971]). Local mobility usually does not cause the change of the global IP addresses, but affects the routing paths within the local access network.
基于IP的节点的移动性会引起路由变化，通常发生在网络边缘。由于IP地址通常是流标识符的一部分，IP地址的更改意味着流标识符的更改（即，通用互联网信令传输（GIST）消息路由信息或消息路由信息（MRI）[RFC5971]）。本地移动性通常不会引起全局IP地址的变化，但会影响本地接入网内的路由路径。
The NSIS protocol suite consists of two layers: the NSIS Transport Layer Protocol (NTLP) and the NSIS Signaling Layer Protocol (NSLP). The General Internet Signaling Transport (GIST) [RFC5971] implements
NSIS协议套件由两层组成：NSIS传输层协议（NTLP）和NSIS信令层协议（NSLP）。通用因特网信令传输（GIST）[RFC5971]实现
the NTLP, which is a protocol that is independent of the signaling application and that transports service-related information between neighboring GIST nodes. Each specific service has its own NSLP protocol; currently there are two specified NSLP protocols, the QoS NSLP [RFC5974] and the Network Address Translator / Firewall (NAT/FW) NSLP [RFC5973].
NTLP是一种独立于信令应用程序的协议，在相邻GIST节点之间传输服务相关信息。每个特定服务都有自己的NSLP协议；目前有两种指定的NSLP协议，QoS NSLP[RFC5974]和网络地址转换器/防火墙（NAT/FW）NSLP[RFC5973]。
The goals of this document are to present the effects of mobility on the NTLP/NSLPs and to provide guides on how such NSIS protocols work in basic mobility scenarios, including support for Mobile IPv4 and Mobile IPv6 scenarios. We also show how these protocols fulfill the requirements regarding mobility set forth in [RFC3726]. In general, the NSIS protocols work well in mobile environments. The Session ID (SID) used in NSIS signaling enables the separation of the signaling state and the IP addresses of the communicating hosts. This makes it possible to directly update a signaling state in the network due to mobility without being forced to first remove the old state and then re-establish a new one. This is the fundamental reason why NSIS signaling works well in mobile environments. Additional information and mobility-specific enhanced operations, e.g., operations with crossover node (CRN), are also introduced.
本文档的目标是展示移动性对NTLP/NSLP的影响，并提供关于此类NSIS协议如何在基本移动性场景中工作的指南，包括对移动IPv4和移动IPv6场景的支持。我们还展示了这些协议如何满足[RFC3726]中提出的关于移动性的要求。一般来说，NSIS协议在移动环境中工作良好。NSIS信令中使用的会话ID（SID）能够分离信令状态和通信主机的IP地址。这使得可以由于移动性而直接更新网络中的信令状态，而不必首先移除旧状态，然后重新建立新状态。这是NSIS信令在移动环境中工作良好的根本原因。还介绍了附加信息和特定于移动性的增强操作，例如交叉节点（CRN）操作。
This document focuses on basic mobility scenarios. Key management related to handovers, multihoming, and interactions between NSIS and other mobility management protocols than Mobile IP are out of scope of this document. Also, practical implementations typically need various APIs across components within a node. API issues, e.g., APIs from GIST to the various mobility and routing schemes, are also out of scope of this work. The generic GIST API towards NSLP is flexible enough to fulfill most mobility-related needs of the NSLP layer.
本文档重点介绍基本的移动场景。与NSIS和移动IP以外的其他移动管理协议之间的切换、多归属和交互相关的密钥管理不在本文档的范围内。此外，实际实现通常需要跨节点内的组件使用各种API。API问题，例如从GIST到各种移动性和路由方案的API，也不在本工作范围内。面向NSLP的通用GIST API足够灵活，可以满足NSLP层的大多数移动性相关需求。
The terminology in this document is based on [RFC5971] and [RFC3753]. In addition, the following terms are used. Note that in this document, a generic route change caused by regular IP routing is referred to as a 'route change', and the route change caused by mobility is referred to as 'mobility'.
本文件中的术语基于[RFC5971]和[RFC3753]。此外，还使用了以下术语。请注意，在本文档中，由常规IP路由引起的一般路由更改称为“路由更改”，由移动性引起的路由更改称为“移动性”。
(1) Downstream
(1) 下游的
The direction from a data sender towards the data receiver.
从数据发送方到数据接收方的方向。
(2) Upstream
(2) 上游
The direction from a data receiver towards the data sender.
从数据接收器到数据发送器的方向。
(3) Crossover Node (CRN)
(3) 交叉节点（CRN）
A Crossover Node is a node that for a given function is a merging point of two or more paths belonging to flows of the same session along which states are installed.
交叉节点是一个节点，对于给定功能，它是属于安装状态的同一会话流的两条或多条路径的合并点。
In the mobility scenarios, there are two different types of merging points in the network according to the direction of signaling flows followed by data flows, where we assume that the Mobile Node (MN) is the data sender.
在移动场景中，根据信令流和数据流的方向，网络中存在两种不同类型的合并点，其中我们假设移动节点（MN）是数据发送方。
Upstream CRN (UCRN): the node closest to the data sender from which the state information in the direction from data receiver to data sender begins to diverge after a handover.
上游CRN（UCRN）：距离数据发送方最近的节点，在切换后，从数据接收方到数据发送方的方向上的状态信息开始从该节点发散。
Downstream CRN (DCRN): the node closest to the data sender from which the state information in the direction from the data sender to the data receiver begins to converge after a handover.
下游CRN（DCRN）：距离数据发送方最近的节点，在该节点上，从数据发送方到数据接收方的状态信息在切换后开始收敛。
In general, the DCRN and the UCRN may be different due to the asymmetric characteristics of routing, although the data receiver is the same.
通常，尽管数据接收器相同，但由于路由的不对称特性，DCRN和UCRN可能不同。
(4) State Update
(4) 状态更新
State Update is the procedure for the re-establishment of NSIS state on the new path, the teardown of NSIS state on the old path, and the update of NSIS state on the common path due to the mobility. The State Update procedure is used to address mobility for the affected flows.
状态更新是在新路径上重新建立NSIS状态、在旧路径上拆除NSIS状态以及由于移动性而在公共路径上更新NSIS状态的过程。状态更新过程用于解决受影响流的移动性问题。
Upstream State Update: State Update for the upstream signaling flow.
上游状态更新：上游信令流的状态更新。
Downstream State Update: State Update for the downstream signaling flow.
下游状态更新：下游信令流的状态更新。
This section identifies problems that are caused by mobility and affect the operations of NSIS protocol suite.
本节确定由移动性引起并影响NSIS协议套件操作的问题。
1. Change of route and possible change of the MN's IP address
1. 更改路由和MN IP地址的可能更改
Topology changes or network reconfiguration might lead to path changes for data packets sent to or from the MN and can cause an IP address change of the MN. Traditional route changes usually do not cause address changes of the flow endpoints. When an IP address
拓扑更改或网络重新配置可能导致发送到MN或从MN发送的数据包的路径更改，并可能导致MN的IP地址更改。传统的路由更改通常不会导致流端点的地址更改。当一个IP地址
changes due to mobility, information within the path-coupled MRI is affected (the source or destination address). Consequently, this concerns GIST as well as NSLPs, e.g., the packet classifier in QoS NSLP or some rules carried in NAT/FW NSLP. So, firewall rules, NAT bindings, and QoS reservations that are already installed may become invalid because the installed states refer to a non-existent flow. If the affected nodes are also on the new path, this information must be updated accordingly.
由于移动性的变化，路径耦合MRI内的信息受到影响（源地址或目标地址）。因此，这涉及GIST以及NSLP，例如，QoS NSLP中的分组分类器或NAT/FW NSLP中携带的一些规则。因此，已安装的防火墙规则、NAT绑定和QoS保留可能会变得无效，因为已安装的状态引用的是不存在的流。如果受影响的节点也位于新路径上，则必须相应地更新此信息。
2. Double state problem
2. 双重状态问题
After a handover, packets may end up getting delivered through a new path. Since the state on the old path still remains as it was after re-establishing the state along the new path, we have two separate states for the same signaling session. Although the state on the old path will be deleted automatically based on the soft state timeout, the state timer value may be quite long (e.g., 90 s as a default value). With the QoS NSLP, this problem might result in the waste of resources and lead to failure of admitting new reservations (due to lack of resources). With the NAT/FW NSLP, it is still possible to re-use this installed state although an MN roams to a new location; this means that another host can send data through a firewall without any prior NAT/FW NSLP signaling because the previous state did not yet expire.
在切换之后，数据包可能最终通过一条新路径传递。由于旧路径上的状态在沿着新路径重新建立状态后仍然保持原样，因此对于同一信令会话，我们有两个单独的状态。尽管旧路径上的状态将根据软状态超时自动删除，但状态计时器值可能相当长（例如，默认值为90秒）。对于QoS NSLP，此问题可能会导致资源浪费，并导致无法接受新的预订（由于缺乏资源）。使用NAT/FW NSLP，尽管MN漫游到新位置，但仍然可以重新使用该已安装状态；这意味着另一个主机可以通过防火墙发送数据，而无需任何先前的NAT/FW NSLP信令，因为先前的状态尚未过期。
3. End-to-end signaling and frequency of route changes
3. 端到端信号和路线变更频率
The change of route and IP addresses in mobile environments is typically much faster and more frequent than traditional route changes caused by node or link failure. This may result in a need to speed up the update procedure of NSLP states.
移动环境中路由和IP地址的更改通常比由节点或链路故障引起的传统路由更改更快、更频繁。这可能导致需要加快NSLP状态的更新过程。
4. Identification of the crossover node
4. 交叉节点的识别
When a handover at the edge of a network has happened, in the typical case, only some parts of the end-to-end path used by the data packets change. In this situation, the crossover node (CRN) plays a central role in managing the establishment of the new signaling application state, and removing any useless state, while localizing the signaling to only the affected part of the network.
当在网络边缘发生切换时，在典型情况下，只有数据包使用的端到端路径的某些部分发生变化。在这种情况下，交叉节点（CRN）在管理新信令应用状态的建立和移除任何无用状态方面起着中心作用，同时仅将信令定位到网络的受影响部分。
5. Upstream State Update vs. Downstream State Update
5. 上游状态更新与下游状态更新
Due to the asymmetric nature of Internet routing, the upstream and downstream paths are likely not to be exactly the same. Therefore, state update needs to be handled independently for upstream and downstream paths.
由于互联网路由的不对称性，上游和下游路径可能不完全相同。因此，需要为上游和下游路径独立处理状态更新。
6. Upstream signaling
6. 上行信号
If the MN is the receiver and moves to a new point of attachment, it is difficult to signal upstream towards the Correspondent Node (CN). New signaling states have to be established along the new path, but for a path-coupled Message Routing Method (MRM), this has to be initiated in downstream direction. So, NTLP signaling state in the upstream direction cannot be initiated by the MN, i.e., GIST cannot easily send a Query in the upstream direction (there is an upstream Q-mode, but this is only applicable in a limited scope). The use of additional protocols such as application-level signaling (e.g, Session Initiation Protocol (SIP)) or mobility management signaling (e.g., Mobile IP) may help to trigger NSLP and NTLP signaling from the CN side in the downstream direction though.
如果MN是接收器并且移动到新的连接点，则很难向对应节点（CN）的上游发送信号。必须沿新路径建立新的信令状态，但对于路径耦合消息路由方法（MRM），这必须在下游方向启动。因此，MN不能发起上游方向的NTLP信令状态，即GIST不能轻易地在上游方向发送查询（存在上游Q模式，但这仅适用于有限的范围）。然而，诸如应用级信令（例如，会话发起协议（SIP））或移动性管理信令（例如，移动IP）之类的附加协议的使用可有助于在下游方向上从CN侧触发NSLP和NTLP信令。
7. Authorization issues
7. 授权问题
The procedure of State Update may be initiated by the MN, the CN, or even nodes within the network (e.g., crossover node, Mobility Anchor Point (MAP) in Hierarchical Mobile IP (HMIP)). This State Update on behalf of the MN raises authorization issues about the entity that is allowed to make these state modifications.
状态更新过程可由MN、CN或甚至网络内的节点（例如，分层移动IP（HMIP）中的交叉节点、移动性锚点（MAP））发起。此代表MN的状态更新引发了有关允许进行这些状态修改的实体的授权问题。
8. Dead peer and invalid NSIS Receiver (NR) problem
8. 死点和无效NSIS接收器（NR）问题
When the MN is on the path of a signaling exchange, after handover the old Access Router (AR) cannot forward NSLP messages towards the MN. In this case, the old AR's mobility or routing protocol (or even the NSLP) may trigger an error message to indicate that the last node fails or is truncated. This error message is forwarded and may mistakenly cause the removal of the state on the existing common path, if the state is not updated before the error message is propagated through the signaling peers. This is called the 'invalid NSIS Receiver (NR) problem'.
当MN位于信令交换的路径上时，在切换之后，旧的接入路由器（AR）不能向MN转发NSLP消息。在这种情况下，旧AR的移动性或路由协议（甚至NSLP）可能触发错误消息以指示最后一个节点失败或被截断。此错误消息被转发，如果在错误消息通过信令对等方传播之前未更新状态，则可能会错误地导致删除现有公共路径上的状态。这称为“无效NSIS接收器（NR）问题”。
9. IP-in-IP encapsulation
9. IP封装中的IP
Mobility protocols may use IP-in-IP encapsulation on the segment of the end-to-end path for routing traffic from the CN to the MN, and vice versa. Encapsulation harms any attempt to identify and filter data traffic belonging to, for example, a QoS reservation. Moreover, encapsulation of data traffic may lead to changes in the routing paths since the source and the destination IP addresses of the inner header differ from those of the outer header. Mobile IP uses tunneling mechanisms to forward data packets among end hosts. Traversing through the tunnel, NSIS signaling messages are transparent on the tunneling path due to the change of flow's addresses. In case of interworking with Mobile IP tunneling, CRNs
移动协议可以在端到端路径的段上使用IP-in-IP封装来将业务从CN路由到MN，反之亦然。封装会损害识别和过滤属于（例如）QoS保留的数据流量的任何尝试。此外，由于内部报头的源和目的地IP地址不同于外部报头的源和目的地IP地址，因此数据业务的封装可能导致路由路径的改变。移动IP使用隧道机制在终端主机之间转发数据包。NSIS信令消息穿过隧道时，由于流地址的变化，在隧道路径上是透明的。如果与移动IP隧道互通，CRN
can be discovered on the tunneling path. It enables NSIS protocols to perform the State Update procedure over the IP tunnel. In this case, GIST needs to cope with the change of Message Routing Information (MRI) for the CRN discovery on the tunnel. Also, NSLP signaling needs to determine when to remove the tunneling segment on the signaling path and/or how to tear down the old state via interworking with the IP tunneling operation. Furthermore, tunneling adds additional IP header as overhead that must be taken into account by QoS NSLP, for example, when resources must be reserved accordingly. So an NSLP must usually be aware whether tunneling or route optimization is actually used for a flow [RFC5979].
可以在隧道路径上发现。它使NSIS协议能够通过IP隧道执行状态更新过程。在这种情况下，GIST需要处理隧道上CRN发现的消息路由信息（MRI）的变化。此外，NSLP信令需要确定何时移除信令路径上的隧道段和/或如何通过与IP隧道操作的互通来解除旧状态。此外，隧道增加了额外的IP头作为开销，QoS NSLP必须考虑到这一点，例如，当必须相应地保留资源时。因此，NSLP通常必须知道是否实际将隧道或路由优化用于流[RFC5979]。
This section presents the basic operations of the NSIS protocol suite after mobility-related route changes. Details of the operation of Mobile IP with respect to NSIS protocols are discussed in the subsequent section.
本节介绍移动相关路由更改后NSIS协议套件的基本操作。有关NSIS协议的移动IP操作细节将在后续章节中讨论。
The NSIS protocol suite decouples state and flow identification. A state is stored and referred by the Session ID (SID). Flows associated with a given NSLP state are defined by the Message Routing Information (MRI). GIST notices when a routing path associated with a SID changes, and provides a notification to the NSLP. It is then up to the NSLP to update the state information in the network. Thus, the effect is an update to the states, not a full new request. This decoupling also effectively solves a typical problem with certain signaling protocols, where protocol state is identified by flow endpoints, and when flow endpoint addresses change, the whole session state becomes invalid.
NSIS协议套件将状态和流标识解耦。状态由会话ID（SID）存储和引用。与给定NSLP状态关联的流由消息路由信息（MRI）定义。GIST会在与SID关联的路由路径发生更改时发出通知，并向NSLP提供通知。然后由NSLP更新网络中的状态信息。因此，其效果是对状态的更新，而不是一个全新的请求。这种解耦还有效地解决了某些信令协议的典型问题，其中协议状态由流端点标识，并且当流端点地址更改时，整个会话状态变为无效。
A further benefit of the decoupling is that if the MRI, i.e., the IP addresses associated with the data flow, remain the same after movement, the NSIS signaling will repair only the affected path of the end-to-end session. Thus, updating the session information in the network will be localized, and no end-to-end signaling will be needed. If the MRI changes, end-to-end signaling usually cannot be avoided since new information for proper data flow identification must be provided all the way between the data sender and receiver, e.g., in order to update filters, QoS profiles, or other flow-related session data.
解耦的另一个好处是，如果MRI（即与数据流相关联的IP地址）在移动后保持不变，NSIS信令将仅修复端到端会话的受影响路径。因此，更新网络中的会话信息将被本地化，并且不需要端到端信令。如果MRI发生变化，通常无法避免端到端信令，因为必须在数据发送方和接收方之间始终提供用于正确数据流识别的新信息，例如，为了更新过滤器、QoS配置文件或其他与流相关的会话数据。
GIST provides NSLPs with an identifier of the next signaling peer, the Source Identification Information (SII) handle. When this SII-Handle changes, the NSLP knows a routing change has happened. Yet,
GIST为NSLP提供下一个信令对等方的标识符，即源标识信息（SII）句柄。当此SII句柄发生更改时，NSLP知道发生了路由更改。然而
the NSLP can also figure out whether it is also the crossover node for the session. Thus, CRN discovery is always done at the NSLP layer because only NSLPs have a notion of end-to-end signaling.
NSLP还可以确定它是否也是会话的交叉节点。因此，CRN发现始终在NSLP层完成，因为只有NSLP具有端到端信令的概念。
When a path changes, the session information on the old path needs to be removed. Normally, the information is released when the session timer is expired after a routing change. But the NSLP running on the end-host or the CRN, depending on the direction of the session, may use the SII-Handle (provided by GIST) to explicitly remove states on the old path; new session information is simultaneously set up on the new path. Both current NSLPs use sequence numbers to identify the order of messages, and this information can be used by the protocols to recover from a routing change.
当路径更改时，需要删除旧路径上的会话信息。通常，当路由更改后会话计时器过期时，会释放该信息。但是，根据会话的方向，在终端主机或CRN上运行的NSLP可以使用SII句柄（由GIST提供）显式删除旧路径上的状态；在新路径上同时设置新会话信息。当前的两个NSLP都使用序列号来标识消息的顺序，协议可以使用这些信息从路由更改中恢复。
Since NSIS operates on a hop-by-hop basis, any peer can perform state updates. This is possible because a chain of trust is expected between NSIS nodes. If this weren't the case (e.g., true resource reservations are not possible), one misbehaving or compromised node would effectively break everything. Thus, currently the NSIS protocols do not limit the roles of each NSIS signaling peer on a path, and any node can make updates. Yet, some updates are reflected back to the signaling endpoints, and they can decide whether or not the signaling actually succeeded.
由于NSIS在逐跳的基础上运行，因此任何对等方都可以执行状态更新。这是可能的，因为NSIS节点之间需要信任链。如果情况并非如此（例如，不可能实现真正的资源保留），一个行为不端或受损的节点将有效地破坏一切。因此，目前NSIS协议不限制路径上每个NSIS信令对等方的角色，任何节点都可以进行更新。然而，一些更新会反映回信令端点，它们可以决定信令是否实际成功。
If the signaling packets are encapsulated in a tunnel, it is necessary to perform a separate signaling exchange for the tunneled region. Furthermore, a binding is needed to tie the end-to-end and tunneled session together.
如果信令分组封装在隧道中，则有必要对隧道区域执行单独的信令交换。此外，需要绑定来将端到端和隧道会话绑定在一起。
In some cases, the NSLP must be aware whether tunneling is used, since additional tunneling overhead must be taken into account, e.g., for resource reservations, etc.
在某些情况下，NSLP必须知道是否使用了隧道，因为必须考虑额外的隧道开销，例如资源预留等。
Figure 1 illustrates an example of QoS NSLP signaling in a Mobile IPv6 route optimization case, for a data flow from the MN to the CN, where sender-initiated reservation is used. Once a handover event is detected in the MN, the MN needs to acquire the new Care-of Address (CoA) and update the path coupled MRI accordingly. Then, the MN issues towards the CN a QoS NSLP RESERVE message that carries the unique session ID and other identification information for the session, as well as the reservation requirements (steps (1)-(4) in Figure 1). Upon receipt of the RESERVE message, the QoS NSLP nodes (which will be discovered by the underlying NTLP) establish the corresponding QoS NSLP state, and forward the message towards the CN. When there is already an existing NSLP state with the same session ID, the state will be updated. If all the QoS NSLP nodes along the
图1说明了移动IPv6路由优化情况下的QoS NSLP信令示例，用于从MN到CN的数据流，其中使用了发送方发起的保留。一旦在MN中检测到切换事件，MN需要获取新的转交地址（CoA）并相应地更新路径。然后，MN向CN发出QoS NSLP保留消息，该消息携带会话的唯一会话ID和其他标识信息以及保留要求（图1中的步骤（1）-（4））。在接收到保留消息后，QoS NSLP节点（将由底层NTLP发现）建立相应的QoS NSLP状态，并将消息转发给CN。当已有具有相同会话ID的现有NSLP状态时，将更新该状态。如果所有QoS NSLP节点沿着
path support the required QoS, the CN in turn responds with a RESPONSE message to confirm the reservation (steps (5)-(6) in Figure 1).
路径支持所需的QoS，CN反过来用响应消息响应以确认保留（图1中的步骤（5）-（6））。
In a bidirectional tunneling case, the only difference is that the RESERVE message should be sent to the home agent (HA) instead of the CN, and the node that responds with a RESPONSE should be the HA instead of the CN, too. More details are given in Section 5.
在双向隧道情况下，唯一的区别是保留消息应该发送到归属代理（HA）而不是CN，并且用响应响应的节点也应该是HA而不是CN。更多细节见第5节。
Therefore, for the basic operation there is no fundamental difference among different operation modes of Mobile IP, and the main issue of mobility support in NSIS is to trigger NSLP signaling appropriately when a handover event is detected. Also, the destination of the NSLP signaling shall follow the Mobile IP data path using path-coupled signaling.
因此，对于基本操作，移动IP的不同操作模式之间没有根本的区别，NSIS中的移动性支持的主要问题是在检测到切换事件时适当地触发NSLP信令。此外，NSLP信令的目的地应遵循使用路径耦合信令的移动IP数据路径。
In this process, the obsoleted state in the old path is not explicitly released because the state can be released by timer expiration. To speed up the process, it may be possible to localize the signaling. When the RESERVE message reaches a node, depicted as CRN in this document (step (2) in Figure 1), where a state is determined for the first time to reflect the same session, the node may issue a NOTIFY message towards the MN's old CoA (step (9) in Figure 1). The QoS NSIS Entity (QNE) adjacent to the MN's old position stops the NOTIFY message (step (10) in Figure 1) and sends a RESERVE message (with Teardown bit set) towards the CN to release the obsoleted state (step (11) in Figure 1). This RESERVE with tear message is stopped by the CRN (step (12) in Figure 1). The Reservation Sequence Number (RSN) is used in the messages to distinguish the order of the signaling. More details are given in Section 4.4
在此过程中，旧路径中的废弃状态不会显式释放，因为该状态可以通过计时器过期来释放。为了加速该过程，可以对信令进行本地化。当保留消息到达本文档中描述为CRN的节点时（图1中的步骤（2）），其中第一次确定状态以反映同一会话，节点可向MN的旧CoA发出通知消息（图1中的步骤（9））。与MN的旧位置相邻的QoS NSIS实体（QNE）停止NOTIFY消息（图1中的步骤（10））并向CN发送保留消息（设置了拆卸位），以释放废弃状态（图1中的步骤（11））。CRN停止此保留带撕裂消息（图1中的步骤（12））。在消息中使用保留序列号（RSN）来区分信令的顺序。更多详情见第4.4节
MN QNE1 MN QNE2 QNE3 QNE4 CN
(CoA1) | (CoA2) | (CRN) | |
| | | | | | |
| | |RESERVE | | | |
| | |------->| | | |
| | | (1) |RESERVE | | |
| | | |--------->| | |
| | | | (2) |RESERVE | |
| | | | |------->| |
| | | | | (3) |RESERVE |
| | | | | |------->|
| | | | NOTIFY| | (4) |
| | | |<---------| | |
| | | NOTIFY| (9) | | |
| |<------------| | | |
| | | (10) | | | |
| |RESERVE(T) | | | |
| |------------>| | | |
| | | (11) |RESERVE(T)| | |
| | | |--------->| | |
| | | | (12) | |RESPONSE|
| | | | | |<-------|
| | | | |RESPONSE| (5) |
| | | | RESPONSE|<-------| |
| | |RESPONSE|<---------| (6) | |
| | |<------ | (7) | | |
| | | (8) | | | |
| | | | | | |
MN QNE1 MN QNE2 QNE3 QNE4 CN
(CoA1) | (CoA2) | (CRN) | |
| | | | | | |
| | |RESERVE | | | |
| | |------->| | | |
| | | (1) |RESERVE | | |
| | | |--------->| | |
| | | | (2) |RESERVE | |
| | | | |------->| |
| | | | | (3) |RESERVE |
| | | | | |------->|
| | | | NOTIFY| | (4) |
| | | |<---------| | |
| | | NOTIFY| (9) | | |
| |<------------| | | |
| | | (10) | | | |
| |RESERVE(T) | | | |
| |------------>| | | |
| | | (11) |RESERVE(T)| | |
| | | |--------->| | |
| | | | (12) | |RESPONSE|
| | | | | |<-------|
| | | | |RESPONSE| (5) |
| | | | RESPONSE|<-------| |
| | |RESPONSE|<---------| (6) | |
| | |<------ | (7) | | |
| | | (8) | | | |
| | | | | | |
Figure 1: Example Basic Handover Signaling in the QoS NSLP
图1:QoS NSLP中的基本切换信令示例
Further cases to consider are:
进一步考虑的情况是：
* receiver-initiated reservation if MN is sender
* 如果MN是发送方，则接收方发起保留
* sender-initiated reservation if MN is receiver
* 如果MN是接收方，则发送方发起保留
* receiver-initiated reservation if MN is receiver
* 如果MN是接收器，则接收器启动保留
In the first case, the MN can easily initiate a new QUERY along the new path after movement, thereby installing signaling state and eventually eliciting a new RESERVE from the CN in upstream direction. Similarly, the second and third cases require the CN to initiate a RESERVE or QUERY message respectively. The difficulty in both cases is, however, to let the CN know that the MN has moved. Because the MN is the receiver, it cannot simply use an NSLP message to do so, because upstream signaling is not possible in this case (cf. Section 3, Upstream Signaling).
在第一种情况下，MN可以在移动后沿着新路径容易地发起新的查询，从而安装信令状态并最终在上游方向从CN获得新的保留。类似地，第二和第三种情况要求CN分别启动保留或查询消息。然而，在这两种情况下，困难在于让CN知道MN已经移动。因为MN是接收机，所以它不能简单地使用NSLP消息来实现这一点，因为在这种情况下上行信令是不可能的（参见第3节，上行信令）。
Figure 2 illustrates an example of NATFW NSLP signaling in a Mobile IPv6 route optimization case, for a data flow from the MN to the CN. The difference to the QoS NSLP is that for the NATFW NSLP only the NSIS initiator (NI) can update the signaling session, in any case. Once a handover event is detected in the MN, the MN must get to know the new Care-of Address and update the path coupled MRI accordingly. Then the MN issues a NATFW NSLP CREATE message towards the CN, that carries the unique session ID and other identification information for the session (steps (1)-(4) in Figure 2). Upon receipt of the CREATE message, the NATFW NSLP nodes (which will be discovered by the underlying NTLP) establish the corresponding NATFW NSLP state, and forward the message towards the CN. When there is already an existing NSLP state with the same session ID, the state will be updated. If all the NATFW NSLP nodes along the path accept the required NAT/firewall configuration, the CN in turn responds with a RESPONSE message, to confirm the configuration (steps (5)-(8) in Figure 2).
图2说明了移动IPv6路由优化情况下，从MN到CN的数据流的NATFW NSLP信令示例。与QoS NSLP的区别在于，对于NATFW NSLP，在任何情况下，只有NSIS启动器（NI）可以更新信令会话。一旦在MN中检测到切换事件，MN必须知道新的转交地址并相应地更新路径。然后，MN向CN发出NATFW NSLP CREATE消息，该消息携带会话的唯一会话ID和其他标识信息（图2中的步骤（1）-（4））。收到CREATE消息后，NATFW NSLP节点（将由底层NTLP发现）建立相应的NATFW NSLP状态，并将消息转发给CN。当已有具有相同会话ID的现有NSLP状态时，将更新该状态。如果路径上的所有NATFW NSLP节点都接受所需的NAT/防火墙配置，则CN依次响应一条响应消息，以确认配置（图2中的步骤（5）-（8））。
In a bidirectional tunneling case, the only difference is that the CREATE message should be sent to the HA instead of the CN, and the node that responds with a RESPONSE should be the HA instead of the CN too.
在双向隧道情况下，唯一的区别是创建消息应该发送到HA而不是CN，并且用响应响应的节点也应该是HA而不是CN。
Therefore, for the basic operation there is no fundamental difference among different operation modes of Mobile IP, and the main issue of mobility support in NSIS is to trigger NSLP signaling appropriately when a handover event is detected, and the destination of the NSLP signaling shall follow the Mobile IP data path as being path-coupled signaling.
因此，对于基本操作，移动IP的不同操作模式之间没有根本的区别，NSIS中移动支持的主要问题是在检测到切换事件时适当触发NSLP信令，NSLP信令的目的地应遵循作为路径耦合信令的移动IP数据路径。
In this process, the obsoleted state in the old path is not explicitly released because the state can be released by timer expiration. To speed up the process, when the CREATE message reaches a node, depicted as CRN in this document (step (2) in Figure 2), where a state is determined for the first time to reflect the same session, the node may issue a NOTIFY message towards the MN's old CoA (steps (9)-(10) in Figure 2). When the NI notices this, it sends a CREATE message towards the CN to release the obsoleted state (steps (11)-(12)) in Figure 2).
在此过程中，旧路径中的废弃状态不会显式释放，因为该状态可以通过计时器过期来释放。为了加快该过程，当CREATE消息到达本文档中描述为CRN的节点时（图2中的步骤（2）），其中第一次确定状态以反映同一会话，该节点可以向MN的旧CoA发出NOTIFY消息（图2中的步骤（9）-（10））。当NI注意到这一点时，它向CN发送一条CREATE消息以释放废弃状态（图2中的步骤（11）-（12））。
MN NI MN NF1 NF2 NF3 CN
(CoA1) | (CoA2) | (CRN) | |
| | | | | | |
| | | | | | |
| | |CREATE | | | |
| | |------->| | | |
| | | (1) |CREATE | | |
| | | |--------->| | |
| | | | (2) |CREATE | |
| | | | |------->| |
| | | | | (3) |CREATE |
| | | | | |------->|
| | | | NOTIFY| | (4) |
| | | |<---------| | |
| | | NOTIFY| (9) | | |
| |<------------| | | |
| | | (10) | | | |
| |CREATE(CoA2) | | | |
| |------------>| | | |
| | | (11) |CREATE(CoA2) | |
| | | |--------->| | |
| | | | (12) | |RESPONSE|
| | | | | |<-------|
| | | | |RESPONSE| (5) |
| | | | RESPONSE|<-------| |
| | |RESPONSE|<---------| (6) | |
| | |<------ | (7) | | |
| | | (8) | | | |
| | | | | | |
| | | | | | |
MN NI MN NF1 NF2 NF3 CN
(CoA1) | (CoA2) | (CRN) | |
| | | | | | |
| | | | | | |
| | |CREATE | | | |
| | |------->| | | |
| | | (1) |CREATE | | |
| | | |--------->| | |
| | | | (2) |CREATE | |
| | | | |------->| |
| | | | | (3) |CREATE |
| | | | | |------->|
| | | | NOTIFY| | (4) |
| | | |<---------| | |
| | | NOTIFY| (9) | | |
| |<------------| | | |
| | | (10) | | | |
| |CREATE(CoA2) | | | |
| |------------>| | | |
| | | (11) |CREATE(CoA2) | |
| | | |--------->| | |
| | | | (12) | |RESPONSE|
| | | | | |<-------|
| | | | |RESPONSE| (5) |
| | | | RESPONSE|<-------| |
| | |RESPONSE|<---------| (6) | |
| | |<------ | (7) | | |
| | | (8) | | | |
| | | | | | |
| | | | | | |
Figure 2: Example of NATFW NSLP Operation
图2:NATFW NSLP操作示例
This section describes detailed CRN operations. As described in previous sections, CRN operations are informational.
本节描述了详细的CRN操作。如前几节所述，CRN操作是信息性的。
As shown in Figure 3, mobility generally causes the signaling path to either converge or diverge depending on the direction of each signaling flow.
如图3所示，移动性通常会导致信令路径根据每个信令流的方向会聚或发散。
Old path
+--+ +-----+
original |MN|<------ |OAR | ---------^
address | | |NSLP1| ^
+--+ +-----+ ^ common path
| C +-----+ +-----+ +--+
| | |<--|NSLP1|----|CN|
| |NSLP2| |NSLP2| | |
v New path +-----+ +-----+ +--+
+--+ +-----+ V B A
New CoA |MN|<------ |NAR |----------V >>>>>>>>>>>>
| | |NSLP1| ^
+--+ +-----+ ^
D ^
<=====(upstream signaling followed by data flows) =====
Old path
+--+ +-----+
original |MN|<------ |OAR | ---------^
address | | |NSLP1| ^
+--+ +-----+ ^ common path
| C +-----+ +-----+ +--+
| | |<--|NSLP1|----|CN|
| |NSLP2| |NSLP2| | |
v New path +-----+ +-----+ +--+
+--+ +-----+ V B A
New CoA |MN|<------ |NAR |----------V >>>>>>>>>>>>
| | |NSLP1| ^
+--+ +-----+ ^
D ^
<=====(upstream signaling followed by data flows) =====
(a) The topology for upstream NSIS signaling flow due to mobility (in the case that the MN is a data sender)
(a) 由于移动性的上游NSIS信令流的拓扑（在MN是数据发送方的情况下）
Old path
+--+ +-----+
original |MN|------> |OAR | ----------V
| | |NSLP1|
address +--+ +-----+ V common path
| K +-----+ +-----+ +--+
| | |---|NSLP1|--->|CN|
| |NSLP2| |NSLP2| | |
v New path +-----+ +-----+ +--+
+--+ +-----+ ^ M N
New CoA |MN|------> |NAR |-----------^ >>>>>>>>>>>>
| | |NSLP1| ^
+--+ +-----+ ^
L ^
====(downstream signaling followed by data flows) ======>
Old path
+--+ +-----+
original |MN|------> |OAR | ----------V
| | |NSLP1|
address +--+ +-----+ V common path
| K +-----+ +-----+ +--+
| | |---|NSLP1|--->|CN|
| |NSLP2| |NSLP2| | |
v New path +-----+ +-----+ +--+
+--+ +-----+ ^ M N
New CoA |MN|------> |NAR |-----------^ >>>>>>>>>>>>
| | |NSLP1| ^
+--+ +-----+ ^
L ^
====(downstream signaling followed by data flows) ======>
(b) The topology for downstream NSIS signaling flow due to mobility (in the case that the MN is a data sender)
(b) 由于移动性而导致的下游NSIS信令流的拓扑（在MN是数据发送方的情况下）
Note: OAR - old access router NAR - new access router
注：OAR-旧接入路由器NAR-新接入路由器
Figure 3: The Topology for NSIS Signaling Caused by Mobility
图3：移动性引起的NSIS信令拓扑
These topological changes due to mobility cause the NSIS state established in the old path to be useless. Such state may be removed as soon as possible. In addition, NSIS state needs to be established along the new path and be updated along the common path. The re-
这些由移动性引起的拓扑变化导致在旧路径中建立的NSIS状态无效。这种状态可能会尽快消除。此外，NSIS状态需要沿新路径建立，并沿公共路径更新。再-
establishment of NSIS signaling may be localized when route changes (including mobility) occur; this is to minimize the impact on the service and to avoid unnecessary signaling overhead. This localized signaling procedure is referred to as State Update (refer to the terminology section). In mobile environments, for example, the NSLP/ NTLP needs to limit the scope of signaling information to only the affected portion of the signaling path because the signaling path in the wireless access network usually changes only partially.
当发生路由变化（包括移动性）时，NSIS信令的建立可以本地化；这是为了最小化对服务的影响，并避免不必要的信令开销。这种本地化的信令过程称为状态更新（请参阅术语部分）。例如，在移动环境中，NSLP/NTLP需要将信令信息的范围仅限于信令路径的受影响部分，因为无线接入网络中的信令路径通常仅部分改变。
The CRN is discovered at the NSLP layer. In case of QoS NSLP, when a RESERVE message with an existing SESSION_ID is received and its SII and MRI are changed, the QNE knows its upstream or downstream peer has changed by the handover, for sender-oriented and receiver-oriented reservations, respectively. Also, the QNE realizes it is implicitly the CRN.
在NSLP层发现CRN。在QoS NSLP的情况下，当接收到具有现有会话ID的保留消息并且其SII和MRI被改变时，QNE知道其上游或下游对等方已通过切换分别针对面向发送方和面向接收方的保留而改变。此外，QNE意识到它隐式地是CRN。
In the downstream State Update, the MN initiates the RESERVE with a new RSN for state setup toward a CN, and also the implicit DCRN discovery is performed by the procedure of signaling as described in Section 4.4.1. The MRI from the DCRN to the CN (i.e., common path) is updated by the RESERVE message. The DCRN may also send a NOTIFY with "Route Change" (0x02) to the previous upstream peer. The NOTIFY is forwarded hop-by-hop and reaches the edge QNE (i.e., QNE1 in Figure 1). After the QNE is aware that the MN as QNI has disappeared (how this can be noticed is out of scope for NSIS, yet, e.g., GIST will eventually know this through undelivered messages), the QNE sends a tearing RESERVE towards downstream. When the tearing RESERVE reaches the DCRN, it stops forwarding and drops it. Note that, however, it is not necessary for GIST state to be explicitly removed because of the inexpensiveness of the state maintenance at the GIST layer [RFC5971]. Note that the sender-initiated approach leads to faster setup than the receiver-initiated approach as in RSVP [RFC2205].
在下游状态更新中，MN使用新的RSN向CN发起保留，用于状态设置，并且隐式DCRN发现也通过第4.4.1节中描述的信令过程执行。从DCRN到CN（即公共路径）的MRI由保留消息更新。DCRN还可以向前一个上游对等方发送带有“路由更改”（0x02）的通知。通知逐跳转发并到达边缘QNE（即图1中的QNE1）。在QNE意识到MN as QNI已经消失后（如何注意到这一点超出了NSIS的范围，但是，例如GIST最终将通过未传递的消息知道这一点），QNE向下游发送撕裂保留。当撕裂保留到达DCRN时，它停止转发并丢弃它。然而，请注意，由于GIST层的状态维护成本较低，因此没有必要显式删除GIST状态[RFC5971]。注意，发送方启动的方法比RSVP[RFC2205]中的接收方启动的方法更快。
In the scenario of an upstream State Update, there are two possible methods for state update. One is the CN (or the HA, Gateway Foreign Agent (GFA), or MAP) sends the refreshing RESERVE message toward the MN to perform State Update upon receiving the trigger (e.g., Mobile IP (MIP) binding update). The UCRN is discovered implicitly by the CN-initiated signaling along the common path as described in Section 4.4.1. When the refreshing RESERVE reaches to the adjacent QNE of UCRN, the QNE sends back a RESPONSE saying "Reduced refreshes not supported; full QSPEC required" (0x03). Then, the UCRN sends the RESERVE with full QSPEC towards the MN to set up a new reservation.
在上游状态更新的场景中，有两种可能的状态更新方法。一个是CN（或HA、网关外部代理（GFA）或MAP）向MN发送刷新保留消息以在接收到触发时执行状态更新（例如，移动IP（MIP）绑定更新）。如第4.4.1节所述，UCRN由CN发起的信令沿公共路径隐式发现。当刷新保留到达UCRN的相邻QNE时，QNE发回一个响应，表示“不支持减少的刷新；需要完整的QSPEC”（0x03）。然后，UCRN向MN发送带有完整QSPEC的保留，以建立新的保留。
The UCRN may also send a tearing RESERVE to the previous downstream peer. The tearing RESERVE is forwarded hop-by-hop and reaches the edge QNE. After the QNE is aware that the MN as QNI has disappeared, the QNE drops the tearing peer. Another method is: if a GIST hop is already established on the new path (e.g., by QUERY from the CN, or the HA, GFA, or MAP) when MN gets a hint from GIST that routing has changed, the MN sends a NOTIFY upstream saying "Route Change" (0x02). When the NOTIFY hits the UCRN, the UCRN is aware that the NOTIFY is for a known session and comes from a new SII-Handle. Then, the UCRN sends towards the MN a RESERVE with a new RSN and an RII. By receiving the RESERVE, the MN replies with a RESPONSE. The UCRN may also send tearing RESERVE to previous downstream peer. The tearing RESERVE is forwarded hop-by-hop and reaches to the edge QNE. After the QNE is aware that the MN as QNI has disappeared, the QNE drops the tearing peer.
UCRN还可以向前一个下游对等方发送撕裂保留。撕裂保留逐跳转发并到达边缘QNE。当QNE意识到MN as QNI已经消失后，QNE会丢弃撕裂对等体。另一种方法是：当MN从GIST获得路由已更改的提示时，如果GIST跃点已在新路径上建立（例如，通过来自CN或HA、GFA或MAP的查询），则MN向上游发送通知，称为“路由更改”（0x02）。当NOTIFY到达UCRN时，UCRN知道NOTIFY是用于已知会话的，并且来自新的SII句柄。然后，UCRN向MN发送带有新RSN和RII的保留。通过接收保留，MN以响应进行响应。UCRN还可以向前一个下游对等方发送撕裂保留。撕裂保留逐跳转发并到达边缘QNE。当QNE意识到MN as QNI已经消失后，QNE会丢弃撕裂对等体。
The State Update on the common path to reflect the changed MRI brings issues on the end-to-end signaling addressed in Section 3. Although the State Update over the common path does not give rise to re-processing of AAA and admission control, it may lead to increased signaling overhead and latency.
公共路径上的状态更新反映了更改后的MRI，这给第3节中讨论的端到端信令带来了问题。尽管公共路径上的状态更新不会引起AAA和准入控制的重新处理，但它可能会导致信令开销和延迟增加。
One of the goals of the State Update is to avoid the double reservation on the common path as described in Section 3. The double reservation problem on the common path can be solved by establishing a signaling association using a unique SID and by updating the packet classifier / MRI. In this case, even though the flows on the common path have different MRIs, they refer to the same NSLP state.
状态更新的目标之一是避免公共路径上的双重保留，如第3节所述。公共路径上的双重保留问题可以通过使用唯一SID建立信令关联和更新分组分类器/MRI来解决。在这种情况下，即使公共路径上的流具有不同的MRI，它们也引用相同的NSLP状态。
Mobility management solutions like Mobile IP try to hide mobility effects from applications by providing stable addresses and avoiding address changes. On the other hand, the MRI [RFC5971] contains flow addresses and will change if the CoA changes. This makes an impact on some NSLPs such as QoS NSLP and NAT/FW NSLP.
移动IP等移动性管理解决方案通过提供稳定的地址和避免地址更改，试图对应用程序隐藏移动性影响。另一方面，MRI[RFC5971]包含流地址，如果CoA发生变化，则会发生变化。这会对一些NSLP造成影响，例如QoS NSLP和NAT/FW NSLP。
QoS NSLP must be mobility-aware because it needs to care about the resources on the actual current path, and sending a new RESERVE or QUERY for the new path. Applications on top of Mobile IP communicate along logical flows that use home addresses, whereas QoS NSLP has to be aware of the actual flow path, e.g., whether the flow is currently tunneled or route-optimized, etc. QoS NSLP may have to obtain current link properties; especially there may be additional overhead due to mobility header extensions that must be taken into account in QSPEC (e.g., the m parameter in the traffic model (TMOD); see [RFC5975]). Therefore, NSLPs must interact with mobility management implementations in order to request information about the current
QoS NSLP必须具有移动性意识，因为它需要关心实际当前路径上的资源，并为新路径发送新的保留或查询。移动IP上的应用程序沿着使用家庭地址的逻辑流进行通信，而QoS NSLP必须知道实际的流路径，例如，流当前是隧道还是路由优化等。QoS NSLP可能必须获得当前的链路属性；特别是，由于移动性报头扩展，可能会有额外的开销，必须在QSPEC中加以考虑（例如，流量模型（TMOD）中的m参数；请参见[RFC5975]）。因此，NSLP必须与移动性管理实现交互，以请求有关当前移动的信息
flow address (CoAs), source addresses, tunneling, or overhead. Furthermore, an implementation must select proper interface addresses in the natural language interface (NLI) in order to ensure that a corresponding Messaging Association is established along the same path as the flow in the MRI. Moreover, the home agent needs to perform additional actions (e.g., reservations) for the tunnel. If the home agent lacks support of a mobility-aware QoS NSLP, a missing tunnel reservation is usually the result. Practical problems may occur in situations where a home agent needs to send a GIST query (with S-flag=1) towards the MN's home address and the query is not tunneled due to route optimization between HA and MN: the query will be wrongly intercepted by QNEs within the tunnel.
流地址（COA）、源地址、隧道或开销。此外，实现必须在自然语言接口（NLI）中选择适当的接口地址，以确保沿着与MRI中的流相同的路径建立相应的消息关联。此外，归属代理需要为隧道执行附加操作（例如，预订）。如果归属代理缺少对移动感知QoS NSLP的支持，则通常会导致丢失隧道预留。在归属代理需要向MN的归属地址发送GIST查询（S-flag=1）并且由于HA和MN之间的路由优化，该查询未被隧道化的情况下，可能会出现实际问题：该查询将被隧道内的QNE错误拦截。
NAT/FW box needs to be configured before MIP signaling, hence NAT/FW signaling will have to be performed to allow Return Routability Test (RRT) and Binding Update (BU) / Binding Acknowledgement (BA) messages to traverse the NAT/FWs in the path. After RRT and BU/BA messages are completed, more NAT/FW signaling needs to be performed for passing the data. Optimized version can include a combined NAT/FW message to cover both RRT and BU/BA messages pattern. However, this may require NAT/FW NSLP to do a slight update to support carrying multiple NAT/FW rules in one signaling round trip.
需要在MIP信令之前配置NAT/FW盒，因此必须执行NAT/FW信令，以允许返回路由性测试（RRT）和绑定更新（BU）/绑定确认（BA）消息在路径中穿过NAT/FWs。RRT和BU/BA消息完成后，需要执行更多NAT/FW信令来传递数据。优化版本可以包括一个组合NAT/FW消息，以涵盖RRT和BU/BA消息模式。然而，这可能需要NAT/FW NSLP进行轻微更新，以支持在一个信令往返中承载多个NAT/FW规则。
This section analyzes NSIS operation with the tunneled route case especially for QoS NSLP.
本节分析了NSIS在隧道路由情况下的操作，特别是QoS NSLP。
In Mobile IPv4 [RFC5944], the data flows are forwarded based on triangular routing, and an MN retains a new CoA from the Foreign Agent (FA) (or an external method such as DHCP) in the visited access network. When the MN acts as a data sender, the data and signaling flows sent from the MN are directly transferred to the CN, not necessarily through the HA or indirectly through the HA using the reverse tunneling. On the other hand, when the MN acts as a data receiver, the data and signaling flows sent from the CN are routed through the IP tunneling between the HA and the FA (or the HA and the MN in the case of the co-located CoA). With this approach, routing is dependent on the HA, and therefore the NSIS protocols interact with the IP tunneling procedure of Mobile IP for signaling.
在移动IPv4[RFC5944]中，数据流基于三角路由转发，并且MN在访问的接入网络中保留来自外部代理（FA）（或诸如DHCP的外部方法）的新CoA。当MN充当数据发送者时，从MN发送的数据和信令流直接传输到CN，不一定通过HA或使用反向隧道间接通过HA。另一方面，当MN充当数据接收器时，从CN发送的数据和信令流通过HA和FA之间的IP隧道路由（或者在共址CoA的情况下通过HA和MN路由）。通过这种方法，路由依赖于HA，因此NSIS协议与移动IP的IP隧道过程交互以进行信令。
Figure 4 (a) to (e) show how the NSIS signaling flows depend on the direction of the data flows and the routing methods.
图4（a）至（e）显示了NSIS信令流如何依赖于数据流的方向和路由方法。
MN FA (or FL) CN
| | |
| IPv4-based Standard IP routing |
|------------ |--------------------------------->|
| | |
MN FA (or FL) CN
| | |
| IPv4-based Standard IP routing |
|------------ |--------------------------------->|
| | |
(a) MIPv4: MN-->CN, no reverse tunnel
(a) MIPv4:MN-->CN，无反向通道
MN FA HA CN
| IPv4 (normal) | | |
|--------------->| IPv4(tunnel) | |
| |--------------->| IPv4 (normal)|
| | |------------->|
MN FA HA CN
| IPv4 (normal) | | |
|--------------->| IPv4(tunnel) | |
| |--------------->| IPv4 (normal)|
| | |------------->|
(b) MIPv4: MN-->CN, the reverse tunnel with FA CoA
(b) MIPv4:MN-->CN，具有FA-CoA的反向隧道
MN (FL) HA CN
| | | |
| IPv4(tunnel) | |
|------------------------------->|IPv4 (normal) |
| | |-------------->|
MN (FL) HA CN
| | | |
| IPv4(tunnel) | |
|------------------------------->|IPv4 (normal) |
| | |-------------->|
(c) MIPv4: MN-->CN, the reverse tunnel with co-located CoA
(c) MIPv4:MN-->CN，具有同一位置CoA的反向隧道
CN HA FA MN
|IPv4 (normal) | | |
|-------------->| | |
| | MIPv4 (tunnel) | |
| |---------------->| IPv4 (normal)|
| | |------------->|
CN HA FA MN
|IPv4 (normal) | | |
|-------------->| | |
| | MIPv4 (tunnel) | |
| |---------------->| IPv4 (normal)|
| | |------------->|
(d) MIPv4: CN-->MN, Foreign agent CoA
(d) MIPv4:CN-->MN，外国代理CoA
CN HA (FL) MN
|IPv4(normal ) | | |
|-------------->| | |
| | MIPv4 (tunnel) | |
| |------------------------------->|
| | | |
CN HA (FL) MN
|IPv4(normal ) | | |
|-------------->| | |
| | MIPv4 (tunnel) | |
| |------------------------------->|
| | | |
(e) MIPv4: CN-->MN with co-located CoA
(e) MIPv4:CN-->MN与共位CoA
Figure 4: NSIS Signaling Flows under Different Mobile IPv4 Scenarios
图4：不同移动IPv4场景下的NSIS信令流
When an MN (as a signaling sender) arrives at a new FA and the corresponding binding process is completed (Figure 4 (a), (b), and (c)), the MN performs the CRN discovery (DCRN) and the State Update toward the CN (as described in Section 4) to establish the NSIS state
当MN（作为信令发送方）到达新FA并且相应的绑定过程完成时（图4（a）、（b）和（c）），MN执行CRN发现（DCRN）和朝向CN的状态更新（如第4节所述），以建立NSIS状态
along the new path between the MN and the CN. In case the reverse tunnel is not used (Figure 4 (a)), a new NSIS state is established on the direct path from the MN to the CN. If the reverse tunnel and FA CoA are used (Figure 4 (b)), a new NSIS state is established along a tunneling path from the FA to the HA separately from the end-to-end path. CRN discovery and State Update in tunneling path is also separately performed if necessary. If the reverse tunnel and co-located CoA are used (Figure 4 (c)), the NSIS signaling for the DCRN discovery and for the State Update is the same as the case of using the FA CoA above, except for the use of the reverse tunneling path from the MN to the HA. That is, in this case, one of the tunnel endpoints is the MN, not the FA.
沿着MN和CN之间的新路径。如果未使用反向隧道（图4（a）），则在从MN到CN的直接路径上建立新的NSIS状态。如果使用反向隧道和FA CoA（图4（b）），则沿着从FA到HA的隧道路径（与端到端路径分开）建立新的NSIS状态。如有必要，隧道路径中的CRN发现和状态更新也将单独执行。如果使用反向隧道和共位CoA（图4（c）），则用于DCRN发现和状态更新的NSIS信令与使用上述FA CoA的情况相同，但使用从MN到HA的反向隧道路径除外。也就是说，在这种情况下，隧道端点之一是MN，而不是FA。
When an MN (as a signaling receiver) arrives at a new FA and the corresponding binding process is completed (Figure 4 (d) and (e)), the MN sends a NOTIFY message to the signaling sender, i.e., the CN. In case the FA CoA is used (Figure 4 (d)), the CN initiates an NSIS signaling to update an existing state between the CN and the HA, and afterwards the NSIS signaling messages are forwarded to the FA and reach the MN. A new NSIS state is established along the tunneling path from the HA to the FA separately from end-to-end path. During this operation, a UCRN is discovered on the tunneling path, and a new MRI for the State Update on the tunnel may need to be created. CRN discovery and State Update in the tunneling path is also separately performed if necessary. In case co-located CoA is used (Figure 4 (d)), the NSIS signaling for the UCRN discovery and for the State Update is also the same as the case of using the FA CoA, above except for the endpoint of the tunneling path from the HA to the MN.
当MN（作为信令接收器）到达新FA并且相应的绑定过程完成时（图4（d）和（e）），MN向信令发送方即CN发送通知消息。在使用FA-CoA的情况下（图4（d）），CN发起NSIS信令以更新CN和HA之间的现有状态，然后NSIS信令消息被转发到FA并到达MN。沿着从HA到FA的隧道路径分别从端到端路径建立新的NSIS状态。在此操作期间，在隧道路径上发现UCRN，并且可能需要为隧道上的状态更新创建新的MRI。如有必要，隧道路径中的CRN发现和状态更新也将单独执行。在使用共位CoA的情况下（图4（d）），用于UCRN发现和状态更新的NSIS信令也与使用FA CoA的情况相同，但从HA到MN的隧道路径的端点除外。
Note that Mobile IPv4 optionally supports route optimization. In the case route optimization is supported, the signaling operation will be the same as Mobile IPv6 route optimization.
请注意，移动IPv4可选地支持路由优化。在支持路由优化的情况下，信令操作将与移动IPv6路由优化相同。
Unlike Mobile IPv4, with Mobile IPv6 [RFC3775], the FA is not required on the data path. If an MN moves to a visited network, a CoA at the network is allocated like co-located CoA in Mobile IPv4. In addition, the route optimization process between the MN and CN can be used to avoid the triangular routing in the Mobile IPv4 scenarios.
与移动IPv4不同，使用移动IPv6[RFC3775]，数据路径上不需要FA。如果MN移动到访问过的网络，则网络上的CoA将像移动IPv4中的同处CoA一样分配。此外，MN和CN之间的路由优化过程可用于避免移动IPv4场景中的三角路由。
If the route optimization is not used, data flow routing and NSIS signaling procedures (including the CRN discovery and the State Update) will be similar to the case of using Mobile IPv4 with the co-located CoA. However, if route optimization is used, signaling messages are sent directly from the MN to the CN, or from the CN to the MN. Therefore, route change procedures described in Section 4 are applicable to this case.
如果未使用路由优化，数据流路由和NSIS信令过程（包括CRN发现和状态更新）将类似于使用移动IPv4和共址CoA的情况。然而，如果使用路由优化，则信令消息直接从MN发送到CN，或从CN发送到MN。因此，第4节中描述的路线变更程序适用于这种情况。
In this section, we assume that the MN acts as an NI and the CN acts as an NR in interworking between Mobile IP and NSIS signaling.
在本节中，我们假设在移动IP和NSIS信令之间的互通中，MN充当NI，CN充当NR。
Scenarios for interaction with Mobile IP tunneling vary depending on:
与移动IP隧道交互的场景因以下情况而异：
- Whether a tunneling entry point (Tentry) is an MN or other node. For a Mobile IPv4 co-located CoA or Mobile IPv6 CoA, Tentry is an MN. For a Mobile IPv4 FA CoA, Tentry is an FA. In both cases, an HA is the tunneling exit point (Texit).
- 隧道入口点（Tentry）是MN还是其他节点。对于移动IPv4共址CoA或移动IPv6 CoA，Tentry是MN。对于移动IPv4 FA-CoA，Tentry是FA。在这两种情况下，HA都是隧道出口点（Texit）。
- Whether the mode of QoS NSLP signaling is sender-initiated or receiver-initiated.
- QoS NSLP信令的模式是发送方发起还是接收方发起。
- Whether the operation mode over the tunnel is with preconfigured QoS sessions or with dynamically created QoS sessions as described in [RFC5979].
- 隧道上的操作模式是使用预配置的QoS会话还是使用[RFC5979]中所述的动态创建的QoS会话。
The following subsections describe sender-initiated and receiver-initiated reservations with Mobile IP tunneling, as well as CRN discovery and State Updates with Mobile IP tunneling.
以下小节介绍了使用移动IP隧道的发送方发起和接收方发起的预订，以及使用移动IP隧道的CRN发现和状态更新。
The following scenario assumes that an FA is a Tentry. However, the procedure is the same when an MN is a Tentry if the MN and the FA are considered the same node.
下面的场景假设一个FA是一个Tentry。然而，如果MN和FA被视为同一节点，则当MN为十分之一时，过程是相同的。
- When an MN moves into a new network attachment point, QoS NSLP in the MN initiates the RESERVE (end-to-end) message to start the State Update procedure. The GIST below the QoS NSLP adds the GIST header and then sends the encapsulated RESERVE message to peer GIST node with the corresponding QoS NSLP. In this case, the peer GIST node is an FA if the FA is an NSIS-aware node. The FA is one of the endpoints of Mobile IP tunneling: Tentry. For proper NSIS tunneling operation, a Mobile IP endpoint is required to be NSIS tunneling aware. In case of interaction with tunnel signaling originated from the FA, there can be two scenarios depending on whether or not the tunnel already has preconfigured QoS sessions. In the former case, the FA map end-to-end QoS signaling requests directly to existing tunnel sessions. In the latter case, the FA dynamically initiates and maintains tunnel QoS sessions that are then associated with the corresponding end-to-end QoS sessions. [RFC5979].
- 当MN移动到新的网络连接点时，MN中的QoS NSLP启动保留（端到端）消息以启动状态更新过程。QoS NSLP下面的GIST添加GIST头，然后将封装的保留消息与相应的QoS NSLP一起发送给对等GIST节点。在这种情况下，如果FA是NSIS感知节点，则对等GIST节点是FA。FA是移动IP隧道的端点之一：Tentry。对于正确的NSIS隧道操作，移动IP端点需要具有NSIS隧道感知能力。在与源自FA的隧道信令交互的情况下，根据隧道是否已经预配置了QoS会话，可以有两种情况。在前一种情况下，FA将端到端QoS信令请求直接映射到现有的隧道会话。在后一种情况下，FA动态地发起和维护隧道QoS会话，然后这些会话与相应的端到端QoS会话相关联。[RFC5979]。
- Figure 5 shows the typical NSIS operation over tunnels with preconfigured QoS sessions. Both the FA and the HA are configured with information about the Flow ID of the tunnel QoS session. Upon receiving a RESERVE message from the MN, the FA checks tunnel QoS configuration, and determines whether and how this end-to-end session can be mapped to a preconfigured tunnel session. The FA then tunnels the RESERVE message to the HA. The CN replies with a RESPONSE message which arrives at the HA, the FA, and the MN.
- 图5显示了具有预配置QoS会话的隧道上的典型NSIS操作。FA和HA都配置有关于隧道QoS会话的流ID的信息。在接收到来自MN的保留消息后，FA检查隧道QoS配置，并确定此端到端会话是否以及如何映射到预配置的隧道会话。FA然后将保留消息隧道传输给HA。CN用到达HA、FA和MN的响应消息进行回复。
- Figure 6 shows the typical NSIS operation over tunnels with dynamically created QoS sessions. When the FA receives an end-to-end RESERVE message from the MN, the FA chooses the tunnel Flow ID, creates the tunnel session, and associates the end-to-end session with the tunnel session. The FA then sends a tunnel RESERVE' message (matching the request of the end-to-end session) towards the HA to reserve tunnel resources. The tunnel RESERVE' message is processed hop-by-hop inside the tunnel for the flow identified by the chosen tunnel Flow ID, while the end-to-end RESERVE message passes through the tunnel intermediate nodes (Tmid). When these two messages arrive at the HA, the HA creates the reservation state for the tunnel session, and sends a tunnel RESPONSE' message to the FA. At the same time, the HA updates the end-to-end RESERVE message based on the result of the tunnel session reservation and forwards the end-to-end RESERVE message along the path towards the CN. When the CN receives the end-to-end RESERVE message, it sends an end-to-end RESPONSE message back to the MN.
- 图6显示了具有动态创建的QoS会话的隧道上的典型NSIS操作。当FA从MN接收到端到端保留消息时，FA选择隧道流ID，创建隧道会话，并将端到端会话与隧道会话相关联。FA然后向HA发送“隧道保留”消息（匹配端到端会话的请求），以保留隧道资源。隧道保留”消息在隧道内逐跳处理，用于所选隧道流ID标识的流，而端到端保留消息通过隧道中间节点（Tmid）。当这两条消息到达HA时，HA为隧道会话创建保留状态，并向FA发送隧道响应消息。同时，HA基于隧道会话预留的结果更新端到端预留消息，并沿着通向CN的路径转发端到端预留消息。当CN接收到端到端保留消息时，它将端到端响应消息发送回MN。
More detailed operations are specified in [RFC5979].
[RFC5979]中规定了更详细的操作。
MN (Sender) FA (Tentry) Tmid HA (Texit) CN (Receiver)
MN（发送方）FA（第十方）Tmid HA（Texit）CN（接收方）
| | | | |
| RESERVE | | | |
+------------->| | | |
| | RESERVE | |
| +--------------------------->| |
| | | | RESERVE |
| | | +------------->|
| | | | RESPONSE |
| | | |<-------------+
| | RESPONSE | |
| |<---------------------------+ |
| RESPONSE | | | |
|<-------------+ | | |
| | | | |
| | | | |
| RESERVE | | | |
+------------->| | | |
| | RESERVE | |
| +--------------------------->| |
| | | | RESERVE |
| | | +------------->|
| | | | RESPONSE |
| | | |<-------------+
| | RESPONSE | |
| |<---------------------------+ |
| RESPONSE | | | |
|<-------------+ | | |
| | | | |
Figure 5: Sender-Initiated QoS NSLP over Tunnel with Preconfigured QoS Sessions
图5：发送方通过预先配置的QoS会话通过隧道发起QoS NSLP
MN (Sender) FA (Tentry) Tmid HA (Texit) CN (Receiver)
MN（发送方）FA（第十方）Tmid HA（Texit）CN（接收方）
| | | | |
| RESERVE | | | |
+------------->| | | |
| | RESERVE' | | |
| +=============>| | |
| | | RESERVE' | |
| | +=============>| |
| | RESERVE | |
| +---------------------------->| |
| | | RESPONSE' | |
| | |<=============+ |
| | RESPONSE' | | |
| |<=============+ | |
| | | | RESERVE |
| | | +------------->|
| | | | RESPONSE |
| | | |<-------------+
| | RESPONSE | |
| |<----------------------------+ |
| RESPONSE | | | |
|<-------------+ | | |
| | | | |
| | | | |
| RESERVE | | | |
+------------->| | | |
| | RESERVE' | | |
| +=============>| | |
| | | RESERVE' | |
| | +=============>| |
| | RESERVE | |
| +---------------------------->| |
| | | RESPONSE' | |
| | |<=============+ |
| | RESPONSE' | | |
| |<=============+ | |
| | | | RESERVE |
| | | +------------->|
| | | | RESPONSE |
| | | |<-------------+
| | RESPONSE | |
| |<----------------------------+ |
| RESPONSE | | | |
|<-------------+ | | |
| | | | |
Figure 6: Sender-Initiated QoS NSLP over Tunnel with Dynamically Created QoS Sessions
图6：发送方通过动态创建的QoS会话通过隧道发起QoS NSLP
Figures 7 and 8 show examples of receiver-initiated operation over Mobile IP tunnel with preconfigured and dynamically created QoS sessions, respectively. The Basic Operation is the same as the sender-initiated case.
图7和图8分别显示了预配置和动态创建的QoS会话在移动IP隧道上由接收器发起的操作的示例。基本操作与发送方发起的案例相同。
MN (Sender) FA (Tentry) Tmid HA (Texit) CN (Receiver)
MN（发送方）FA（第十方）Tmid HA（Texit）CN（接收方）
| | | | |
| QUERY | | | |
+------------->| | | |
| | QUERY | |
| +--------------------------->| |
| | | | QUERY |
| | | +------------->|
| | | | RESERVE |
| | | |<-------------+
| | RESERVE | |
| |<---------------------------+ |
| RESERVE | | | |
|<-------------+ | | |
| RESPONSE | | | |
+------------->| | | |
| | RESPONSE | |
| +--------------------------->| |
| | | | RESPONSE |
| | | +------------->|
| | | | |
| | | | |
| QUERY | | | |
+------------->| | | |
| | QUERY | |
| +--------------------------->| |
| | | | QUERY |
| | | +------------->|
| | | | RESERVE |
| | | |<-------------+
| | RESERVE | |
| |<---------------------------+ |
| RESERVE | | | |
|<-------------+ | | |
| RESPONSE | | | |
+------------->| | | |
| | RESPONSE | |
| +--------------------------->| |
| | | | RESPONSE |
| | | +------------->|
| | | | |
Figure 7: Receiver-Initiated QoS NSLP over Tunnel with Preconfigured QoS Sessions
图7：具有预配置QoS会话的通过隧道的接收方发起的QoS NSLP
MN (Sender) FA (Tentry) Tmid HA (Texit) CN (Receiver)
MN（发送方）FA（第十方）Tmid HA（Texit）CN（接收方）
| QUERY | | | |
+------------->| | | |
| | QUERY' | | |
| +=============>| | |
| | | QUERY' | |
| | +=============>| |
| | | RESPONSE' | |
| | |<=============+ |
| | RESPONSE' | | |
| |<=============+ | |
| | QUERY | |
| +---------------------------->| |
| | | | QUERY |
| | | +------------->|
| | | | RESERVE |
| | | |<-------------+
| | | RESERVE' | |
| | |<=============+ |
| | RESERVE' | | |
| |<=============+ | |
| | RESERVE | |
| |<----------------------------+ |
| | RESPONSE' | | |
| +=============>| | |
| | | RESPONSE' | |
| | +=============>| |
| RESERVE | | | |
|<-------------+ | | |
| RESPONSE | | | |
+------------->| | | |
| | RESPONSE | |
| +---------------------------->| |
| | | | RESPONSE |
| | | +------------->|
| | | | |
| QUERY | | | |
+------------->| | | |
| | QUERY' | | |
| +=============>| | |
| | | QUERY' | |
| | +=============>| |
| | | RESPONSE' | |
| | |<=============+ |
| | RESPONSE' | | |
| |<=============+ | |
| | QUERY | |
| +---------------------------->| |
| | | | QUERY |
| | | +------------->|
| | | | RESERVE |
| | | |<-------------+
| | | RESERVE' | |
| | |<=============+ |
| | RESERVE' | | |
| |<=============+ | |
| | RESERVE | |
| |<----------------------------+ |
| | RESPONSE' | | |
| +=============>| | |
| | | RESPONSE' | |
| | +=============>| |
| RESERVE | | | |
|<-------------+ | | |
| RESPONSE | | | |
+------------->| | | |
| | RESPONSE | |
| +---------------------------->| |
| | | | RESPONSE |
| | | +------------->|
| | | | |
Figure 8: Receiver-Initiated QoS NSLP over Tunnel with Dynamically Created QoS Session
图8：具有动态创建的QoS会话的通过隧道的接收方发起的QoS NSLP
If a tunnel is in the mode of using dynamically created QoS sessions, the Mobile IP tunneling scenario can include two types of CRNs, i.e., a CRN on an end-to-end path and a CRN on a tunneling path. If a
如果隧道处于使用动态创建的QoS会话的模式，则移动IP隧道场景可以包括两种类型的CRN，即端到端路径上的CRN和隧道路径上的CRN。如果
tunnel is in the mode of using preconfigured QoS sessions, it can only have CRNs on end-to-end paths. CRN discovery and State Update for these two paths are operated independently.
隧道处于使用预配置QoS会话的模式，它只能在端到端路径上具有CRN。这两条路径的CRN发现和状态更新是独立操作的。
CRN discovery for an end-to-end path is initiated by the MN by sending a RESERVE (sender-initiated case) or QUERY (receiver-initiated case) message. As the MN uses HoA as the source address even after handover, a CRN is found by normal route change process (i.e., the same SID and Flow ID, but a different SII-Handle). If an HA is QoS NSLP aware, the HA is found as the CRN. The CRN initiates the tearing-down process on the old path as described in [RFC5974].
MN通过发送保留（发送方发起的情况）或查询（接收方发起的情况）消息来启动端到端路径的CRN发现。由于MN即使在切换后也使用HoA作为源地址，因此通过正常的路由更改过程（即，相同的SID和流ID，但不同的SII句柄）可以找到CRN。如果HA是QoS NSLP感知的，则该HA被发现为CRN。CRN在[RFC5974]中所述的旧路径上启动拆卸过程。
CRN discovery for the tunneling path is initiated by Tentry by sending a RESERVE' (sender-initiated case) or QUERY' (receiver-initiated case) message. The route change procedures described in Section 4 are applicable to this case.
Tentry通过发送保留（发送方发起的情况）或查询（接收方发起的情况）消息来启动隧道路径的CRN发现。第4节中描述的路线变更程序适用于这种情况。
The end-to-end state inside the tunnel should not be torn down until all states inside the tunnel have been torn from the implementation perspective. However, detailed discussions are out of scope for this document.
从实现的角度来看，在隧道内的所有状态都被拆除之前，不应拆除隧道内的端到端状态。但是，详细讨论超出了本文件的范围。
All sections above dealt with basic issues on NSIS mobility support. This section introduces potential issues and possible approaches for complicated scenarios in the mobile environment, i.e., peer failure scenarios, multihomed scenarios, and interworking with other mobility protocols, which may need to be resolved in the future. Topics in this section are out of scope for this document. Detailed operations in this section are just for future reference.
以上所有章节都讨论了NSIS机动性支持的基本问题。本节介绍了移动环境中复杂场景的潜在问题和可能的方法，即对等故障场景、多址场景以及与其他移动协议的互通，这些可能需要在将来解决。本节中的主题超出了本文档的范围。本节中的详细操作仅供将来参考。
In multihomed mobile environments, multiple interfaces and addresses (i.e., CoAs and HoAs) are available, so two major issues can be considered. One is how to select or acquire the most appropriate interface(s) and/or address(es) from the end-to-end QoS point of view. The other is, when multiple paths are simultaneously used for load-balancing purposes, how to differentiate and manage two types of CRNs, i.e., the CRN between two ongoing paths (LB-CRN: Load Balancing CRN) and the CRN between the old and new paths caused by the MN's handover (HO-CRN: Handover CRN). This section introduces possible approaches for these issues.
在多址移动环境中，多个接口和地址（即COA和HOA）可用，因此可以考虑两个主要问题。一个是如何从端到端QoS的角度选择或获取最合适的接口和/或地址。另一个问题是，当多条路径同时用于负载平衡目的时，如何区分和管理两种类型的CRN，即两条正在进行的路径之间的CRN（LB-CRN：负载平衡CRN）和MN切换导致的新旧路径之间的CRN（HO-CRN：切换CRN）。本节介绍解决这些问题的可能方法。
In the MIPv6 route optimization case, if registrations of multiple CoAs are provided [RFC5648], the contents of QUERYs sent by candidate CoAs can be used to select the best interface(s) or CoA(s).
在MIPv6路由优化案例中，如果提供了多个CoA的注册[RFC5648]，候选CoA发送的查询内容可用于选择最佳接口或CoA。
Assume that an MN is a data sender and has multiple interfaces. Now the MN moves to a new location and acquires CoA(s) for multiple interfaces. After the MN performs the BU/BA procedure, it sends QUERY messages toward the CN through the interface(s) associated with the CoA(s). On receiving the QUERY messages, the CN or gateway, determines the best (primary) CoA(s) by checking the 'QoS Available' object in the QUERY messages. Then, a RESERVE message is sent toward the MN to reserve resources along the path that the primary CoA takes. If the reservation is not successful, the CN transmits another RESERVE message using the CoA with the next highest priority. The CRN may initiate a teardown (RESERVE with the TEAR flag set) message toward old access router (OAR) to release the reserved resources on the old path.
假设MN是一个数据发送方，并且有多个接口。现在MN移动到一个新位置，并为多个接口获取CoA。MN执行BU/BA过程后，通过与CoA相关联的接口向CN发送查询消息。在接收到查询消息时，CN或网关通过检查查询消息中的“QoS Available”对象来确定最佳（主要）CoA。然后，向MN发送RESERVE消息以沿主CoA采取的路径保留资源。如果保留未成功，则CN使用具有下一个最高优先级的CoA发送另一个保留消息。CRN可向旧接入路由器（OAR）发起拆卸（设置撕裂标志的保留）消息，以释放旧路径上的保留资源。
For a sender-initiated reservation, a similar approach is possible. That is, the QUERY and RESERVE messages are initiated by an MN, and the MN selects the primary CoA based on the information delivered by the QUERY message.
对于发送方发起的预订，也可以采用类似的方法。也就是说，查询和保留消息由MN发起，MN基于查询消息传递的信息选择主CoA。
|--Handover-->|
MN OAR AR1 AR2 AR3 CRN CRN CRN CN
(OAR/AR1)(OAR/AR2)(OAR/AR3)
| | | | | | | | |
|---QUERY(1)->|-------------------->|---------------------->|
| | | | | | | | |
|---QUERY(2)-------->|--------------------->|-------------->|
| | | | | | | | |
|---QUERY(3)--------------->|---------------------->|------>|
| | | | | | | | |
| | | | | | | | Primary CoA
| | | | | | | | Selection(4)
| | | | | | | | |
| | | | | | |<--RESERVE(5)--|
| | | |<------RESERVE(6)-----| (MRI |
| | | | (Actual reservation) | Update) |
|<----RESERVE(7)-----| | | | | |
| | | | | | | | |
| |<-----------teardown(8)-------------| | |
| | | | | | | | |
| | | | Multimedia Traffic | | |
|<=================->|<===================->|<=============>|
| | | | | | | | |
|--Handover-->|
MN OAR AR1 AR2 AR3 CRN CRN CRN CN
(OAR/AR1)(OAR/AR2)(OAR/AR3)
| | | | | | | | |
|---QUERY(1)->|-------------------->|---------------------->|
| | | | | | | | |
|---QUERY(2)-------->|--------------------->|-------------->|
| | | | | | | | |
|---QUERY(3)--------------->|---------------------->|------>|
| | | | | | | | |
| | | | | | | | Primary CoA
| | | | | | | | Selection(4)
| | | | | | | | |
| | | | | | |<--RESERVE(5)--|
| | | |<------RESERVE(6)-----| (MRI |
| | | | (Actual reservation) | Update) |
|<----RESERVE(7)-----| | | | | |
| | | | | | | | |
| |<-----------teardown(8)-------------| | |
| | | | | | | | |
| | | | Multimedia Traffic | | |
|<=================->|<===================->|<=============>|
| | | | | | | | |
Figure 9: Receiver-Initiated Reservation in the Multihomed Environment
图9：多宿环境中由接收方发起的预订
When multiple interfaces of the MN are simultaneously used for load-balancing purposes, a possible approach for distinguishing the LB-CRN and HO-CRN will introduce an identifier to determine the relationship between interfaces and paths.
当MN的多个接口同时用于负载平衡目的时，用于区分LB-CRN和HO-CRN的可能方法将引入标识符以确定接口和路径之间的关系。
An MN uses interface 1 and interface 2 for the same session, where the paths (say path 1 and path 2) have the same SID but different Flow IDs as shown in (a) of Figure 10. Then, one of the interfaces of the MN performs a handover and obtains a new CoA, and the MN will try to establish a new path (say Path 3) with the new Flow ID, as shown in (b) of Figure 10. In this case, the CRN between path 2 and path 3 cannot determine if it is LB-CRN or HO-CRN since for both cases, the SID is the same but the Flow IDs are different. Hence, the CRN will not know if State Update is required. One possible solution to solve this issue is to introduce a path classification identifier, which shows the relationship between interfaces and paths. For example, signaling messages and QNEs that belong to paths from interface 1 and interface 2 carry the identifiers '00' and '02', respectively. By having this identifier, the CRN between path 2 and
MN为同一会话使用接口1和接口2，其中路径（比如路径1和路径2）具有相同的SID，但不同的流ID，如图10的（a）所示。然后，MN的一个接口执行切换并获得一个新的CoA，MN将尝试用新的流ID建立一个新的路径（比如路径3），如图10的（b）所示。在这种情况下，路径2和路径3之间的CRN无法确定它是LB-CRN还是HO-CRN，因为对于这两种情况，SID相同，但流ID不同。因此，CRN将不知道是否需要状态更新。解决这个问题的一个可能的解决方案是引入一个路径分类标识符，它显示接口和路径之间的关系。例如，属于来自接口1和接口2的路径的信令消息和QNE分别携带标识符“00”和“02”。通过使用此标识符，路径2和
path 3 will be able to determine whether it is an LB-CRN or HO-CRN. For example, if path 3 carries '00', the CRN is an LB-CRN, and if '01', the CRN is an HO-CRN.
路径3将能够确定它是LB-CRN还是HO-CRN。例如，如果路径3携带'00'，则CRN为LB-CRN，如果'01'，则CRN为HO-CRN。
+--+ Path 1 +---+ +--+
| |IF1 <-----------------|LB-| common path | |
|MN| |CRN|-------------|CN|
| | Path 2 | | | |
| |IF2 <-----------------| | | |
| | +---+ +--+
| |
+--+
+--+ Path 1 +---+ +--+
| |IF1 <-----------------|LB-| common path | |
|MN| |CRN|-------------|CN|
| | Path 2 | | | |
| |IF2 <-----------------| | | |
| | +---+ +--+
| |
+--+
(a) NSIS Path classification in multihomed environments
(a) 多宿环境中的NSIS路径分类
+--+ Path 1 +---+ +--+
| |IF1 <-----------------|??-| common path | |
|MN| |CRN|-------------|CN|
| | Path 2 -| | | |
| |IF2 <--- +------+ | | | | |
| | \_|??-CRN|--v +---+ +--+
| | / +------+
+--+IF? <---
Path 3
+--+ Path 1 +---+ +--+
| |IF1 <-----------------|??-| common path | |
|MN| |CRN|-------------|CN|
| | Path 2 -| | | |
| |IF2 <--- +------+ | | | | |
| | \_|??-CRN|--v +---+ +--+
| | / +------+
+--+IF? <---
Path 3
(b) NSIS Path classification after handover
(b) NSIS切换后的路径分类
Figure 10: The Topology for NSIS Signaling in Multihomed Mobile Environments
图10：多宿移动环境中NSIS信令的拓扑
In mobility scenarios, the end-to-end signaling problem by the State Update (unlike the problem of generic route changes) gives rise to the degradation of network performance, e.g., increased signaling overhead, service blackout, and so on. To reduce signaling latency in the Mobile-IP-based scenarios, the NSIS protocol suite may need to interwork with localized mobility management (LMM). If the GIST/NSLP (QoS NSLP or NAT/FW NSLP) protocols interact with Hierarchical Mobile IPv6 and the CRN is discovered between an MN and an MAP, the State Update can be localized by address mapping. However, how the State Update is performed with scoped signaling messages within the access network under the MAP is for future study.
在移动场景中，状态更新（与一般路由变化问题不同）导致网络性能的降低，例如信令开销增加、业务中断等。为了减少基于移动IP的场景中的信令延迟，NSIS协议套件可能需要与本地化移动性管理（LMM）互通。如果GIST/NSLP（QoS-NSLP或NAT/FW-NSLP）协议与分层移动IPv6交互，并且在MN和MAP之间发现CRN，则可以通过地址映射对状态更新进行本地化。然而，如何使用MAP下的接入网络内的作用域信令消息执行状态更新有待于将来的研究。
In the interdomain handover, a possible way to mitigate the latency penalty is to use the multihomed MN. It is also possible to allow the NSIS protocols to interact with mobility protocols such as Seamoby protocols (e.g., Candidate Access Router Discovery (CARD) [RFC4066] and the Context Transfer Protocol (CXTP) [RFC4067]) and Fast Mobile IP (FMIP). Another scenario is to use a peering agreement that allows aggregation authorization to be performed for aggregate reservation on an interdomain link without authorizing each individual session. How these approaches can be used in NSIS signaling is for further study.
在域间切换中，减轻延迟损失的一种可能方法是使用多址MN。还可以允许NSIS协议与移动协议交互，例如Seamoby协议（例如，候选接入路由器发现（CARD）[RFC4066]和上下文传输协议（CXTP）[RFC4067]）和快速移动IP（FMIP）。另一个场景是使用对等协议，该协议允许对域间链路上的聚合保留执行聚合授权，而无需授权每个会话。如何将这些方法用于NSIS信令还有待进一步研究。
The failure of a (potential) NSIS CRN may result in incomplete state re-establishment on the new path and incomplete teardown on the old path after handover. In this case, a new CRN should be rediscovered immediately by the CRN discovery procedure.
（潜在）NSIS CRN的故障可能导致新路径上的状态重建不完整，以及在切换后旧路径上的拆卸不完整。在这种情况下，应通过CRN发现程序立即重新发现新的CRN。
The failure of an AR may make the interactions with Seamoby protocols (such as CARD and CXTP) impossible. In this case, the neighboring peer closest to the dead AR may need to interact with such protocols. A more detailed analysis of interactions with Seamoby protocols is left for future work.
AR的故障可能使与Seamoby协议（如CARD和CXTP）的交互变得不可能。在这种情况下，离死AR最近的相邻对等方可能需要与此类协议交互。对与Seamoby协议的交互进行更详细的分析将留待以后的工作。
In Mobile-IP-based scenarios, the failures of NSIS functions at an FA and an HA may result in incomplete interaction with IP tunneling. In this case, recovery for NSIS functions needs to be performed immediately. In addition, a more detailed analysis of interactions with IP tunneling is left for future work.
在基于移动IP的场景中，FA和HA处NSIS功能的故障可能导致与IP隧道的不完全交互。在这种情况下，需要立即执行NSIS功能的恢复。此外，对与IP隧道的交互作用的更详细分析留待将来的工作。
This document does not introduce new security concerns. The security considerations pertaining to the NSIS protocol specifications, especially [RFC5971], [RFC5973], and [RFC5974], remain relevant. When deployed in service provider networks, it is mandatory to ensure that only authorized entities are permitted to initiate re-establishment and removal of NSIS states in mobile environments, including the use of NSIS proxies and CRNs.
本文件没有引入新的安全问题。与NSIS协议规范相关的安全注意事项，尤其是[RFC5971]、[RFC5973]和[RFC5974]仍然相关。在服务提供商网络中部署时，必须确保仅允许授权实体在移动环境中启动重新建立和删除NSIS状态，包括使用NSIS代理和CRN。
Sung-Hyuck Lee was the editor of early drafts of this document. Since draft version 06, Takako Sanda has taken the editorship.
Sung Hyuck Lee是这份文件早期草稿的编辑。从第06版初稿开始，山田高子担任编辑。
Many individuals have contributed to this document. Since it was not possible to list them all in the authors section, this section was created to have a sincere respect for those who contributed: Paulo
许多人对本文件作出了贡献。由于不可能在“作者”一节中列出所有作者，因此创建本节是为了向那些做出贡献的人表示诚挚的敬意：保罗
Mendes, Robert Hancock, Roland Bless, Shivanajay Marwaha, and Martin Stiemerling. Separating authors into two groups was done without treating any one of them better (or worse) than others.
门德斯、罗伯特·汉考克、罗兰·布莱斯、希瓦纳杰·马瓦哈和马丁·斯蒂梅林。将作者分为两组，没有对其中任何一个进行比其他人更好（或更差）的治疗。
The authors would like to thank Byoung-Joon Lee, Charles Q. Shen, Cornelia Kappler, Henning Schulzrinne, and Jongho Bang for significant contributions in early drafts of this document. The authors would also like to thank Robert Hancock, Andrew Mcdonald, John Loughney, Rudiger Geib, Cheng Hong, Elena Scialpi, Pratic Bose, Martin Stiemerling, and Luis Cordeiro for their useful comments and suggestions.
作者要感谢Byoung Joon Lee、Charles Q.Shen、Cornelia Kappler、Henning Schulzrinne和Jongho Bang在本文件早期草稿中的重要贡献。作者还想感谢罗伯特·汉考克、安德鲁·麦克唐纳、约翰·洛尼、鲁迪格·盖布、程红、埃琳娜·斯亚尔皮、普拉蒂克·博斯、马丁·斯蒂梅林和路易斯·科尔代罗，感谢他们提出的有用的意见和建议。
[RFC3775] Johnson, D., "Mobility Support in IPv6", RFC3775 , June 2004.
[RFC3775]Johnson，D.，“IPv6中的移动支持”，RFC3775，2004年6月。
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010.
[RFC5971]Schulzrinne，H.和R.Hancock，“要点：通用互联网信号传输”，RFC 59712010年10月。
[RFC5973] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", RFC 5973, October 2010.
[RFC5973]Stieemerling，M.，Tschofenig，H.，Aoun，C.，和E.Davies，“NAT/防火墙NSIS信令层协议（NSLP）”，RFC 59732010年10月。
[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, October 2010.
[RFC5974]Way，J.，Karagiannis，G.，和A.McDonald，“用于服务质量信令的NSIS信令层协议（NSLP）”，RFC 5974，2010年10月。
[RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010.
[RFC5944]Perkins，C.，Ed.，“IPv4的IP移动支持，修订版”，RFC 59442010年11月。
[RFC2205] Braden, B., "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC2205 , September 1997.
[RFC2205]Braden，B.，“资源预留协议（RSVP）——第1版功能规范”，RFC2205，1997年9月。
[RFC3726] Brunner, (Ed), M., "Requirements for Signaling Protocols", RFC3726 , June 2004.
[RFC3726]Brunner，（编辑），M，“信令协议的要求”，RFC37262004年6月。
[RFC3753] Manner, J., "Mobility Related Terminology", RFC3753 , June 2004.
[RFC3753]Way，J.，“机动性相关术语”，RFC3753，2004年6月。
[RFC4066] Liebsch, M., "Candidate Access Router Discovery (CARD)", RFC4066 , July 2005.
[RFC4066]Liebsch，M.，“候选接入路由器发现（卡）”，RFC4066，2005年7月。
[RFC4067] Loughney, J., "Context Transfer Protocol (CXTP)", RFC4067 , July 2005.
[RFC4067]Loughney，J.，“上下文传输协议（CXTP）”，RFC4067，2005年7月。
[RFC5648] Wakikawa, R., "Multiple Care-of-Address Registration", RFC5648 , October 2009.
[RFC5648]Wakikawa，R.，“多重转交地址登记”，RFC5648，2009年10月。
[RFC5975] Ash, G., Bader, A., Kappler, C., and D. Oran, "QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)", RFC 5975, October 2010.
[RFC5975]Ash，G.，Bader，A.，Kappler，C.，和D.Oran，“服务质量NSIS信令层协议（NSLP）的QSPEC模板”，RFC 59752010年10月。
[RFC5979] Shen, C., Schulzrinne, H., Lee, S., and J. Bang, "NSIS Operation over IP Tunnels", RFC 5979, March 2011.
[RFC5979]Shen，C.，Schulzrinne，H.，Lee，S.，和J.Bang，“NSIS在IP隧道上的运行”，RFC 59792011年3月。
Authors' Addresses
作者地址
Takako Sanda (editor) Panasonic Corporation 600 Saedo-cho, Tsuzuki-ku, Yokohama Kanagawa 224-8539 Japan
高子散打（编辑）松下公司，日本横滨神奈川筑基区Saedo cho 600号，邮编224-8539
Phone: +81 45 938 3056
EMail: sanda.takako@jp.panasonic.com
Phone: +81 45 938 3056
EMail: sanda.takako@jp.panasonic.com
Xiaoming Fu University of Goettingen Computer Networks Group Goldschmidtstr. 7 Goettingen 37077 Germany
小明福大学GetetEN计算机网络集团GooStMultTr.7戈廷根37077德国
Phone: +49 551 39 172023
EMail: fu@cs.uni-goettingen.de
Phone: +49 551 39 172023
EMail: fu@cs.uni-goettingen.de
Seong-Ho Jeong Hankuk University of FS Dept. of Information and Communications Engineering 89 Wangsan, Mohyun, Cheoin-gu Yongin-si, Gyeonggi-do 449-791 Korea
京畿道信息技术与通信工程学院信息技术与通信工程学院王山89，Mohyun，邱永谷，韩国
Phone: +82 31 330 4642
EMail: shjeong@hufs.ac.kr
Phone: +82 31 330 4642
EMail: shjeong@hufs.ac.kr
Jukka Manner Aalto University Department of Communications and Networking (Comnet) P.O. Box 13000 FIN-00076 Aalto Finland
阿尔托大学通信与网络系（Comnet）邮政信箱13000 FIN-00076阿尔托芬兰
Phone: +358 9 470 22481
EMail: jukka.manner@tkk.fi
URI: http://www.netlab.tkk.fi/~jmanner/
Phone: +358 9 470 22481
EMail: jukka.manner@tkk.fi
URI: http://www.netlab.tkk.fi/~jmanner/
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig诺基亚西门子网络公司芬兰Linnoitustie 6 Espoo 02600
Phone: +358 50 4871445
EMail: Hannes.Tschofenig@nsn.com
Phone: +358 50 4871445
EMail: Hannes.Tschofenig@nsn.com