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
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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さ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
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トランスポート層プロトコル（NTLP）とNSISシグナリング層プロトコル（NSLP）：NSISプロトコル群は、二つの層からなります。一般的なインターネットシグナリングトランスポート（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].
シグナリングのアプリケーションから独立しており、それが隣接GISTノード間のサービス関連情報を搬送するプロトコルであるNTLP、。それぞれの特定のサービスには独自のNSLPプロトコルを持っています。現在、指定された2つの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 / NSLPs上のモビリティの影響を提示すると、このような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.
このドキュメントでは、基本的なモビリティのシナリオに焦点を当てています。ハンドオーバ、マルチホーミング、およびモバイルIP以外NSISおよびその他のモビリティ管理プロトコル間の相互作用に関連する鍵管理がこの文書の範囲外です。また、実用的な実装では、典型的には、ノード内の構成要素の様々な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.
クロスオーバーノードは、指定された機能のための状態がインストールされてそれに沿って同一のセッションのフローに属する2つの以上の経路の合流点であるノードです。
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状態の再確立するための手順です。州Update手順が影響を受けたフローのための移動性に対処するために使用されます。
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プロトコル群の動作に影響を与えている問題を識別します。
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 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.
トポロジの変更やネットワークの再構成は、パスにつながるかもしれないMNへまたはから送信されたデータパケットのために変更し、MNのIPアドレスの変更を引き起こす可能性があります。伝統的なルート変更は、通常のフローのエンドポイントのアドレスの変更が発生することはありません。モビリティによるIPアドレス変更は、パス結合MRI内の情報は、（送信元または宛先アドレス）に影響される場合。したがって、これはGISTと同様にNSLPsと、QoS NSLPまたはNAT / FW NSLPで運ばれ、いくつかのルールでは、例えば、パケット分類器に関するものです。インストールの状態が存在しないフローを参照しているためので、すでにインストールされているファイアウォールルール、NATバインディング、およびQoS予約は無効になる場合があります。影響を受けたノードは、新たなパス上にもある場合は、この情報に応じて更新する必要があります。
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.
ハンドオーバ後、パケットは、新しいパスを介して配信なってしまうことがあります。古いパス上の状態はまだ新しいパスに沿って状態を再確立した後にそれがあったとして残っているので、我々は同じシグナリングセッションのための2つの別々の状態を持っています。旧経路上の状態が自動的に柔らかい状態のタイムアウトに基づいて削除されますが、状態タイマ値（例えば、デフォルト値として90秒）非常に長いかもしれません。 QoSのNSLPでは、この問題は、資源の浪費につながる可能性があり、（リソースが不足しているため）、新たな予約を認めるの故障につながります。 NAT / FW NSLPと、MNが新しい場所にローミングするが、このインストール状態を再利用することも可能です。これは、以前の状態がまだ有効期限が切れていなかったので、別のホストが、事前のNAT / FW NSLPシグナリングせずにファイアウォールを介してデータを送信できることを意味します。
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状態の更新手順をスピードアップすることが必要になることがあります。
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）は、新しいシグナリングアプリケーション状態の確立を管理し、ネットワークの唯一の患部へのシグナリングを局在化しつつ、無駄な状態を除去するのに中心的な役割を果たしています。
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.
インターネットルーティングの非対称性に、上流と下流のパスがまったく同じではないと思われます。したがって、状態更新は、上流及び下流経路のために独立して処理する必要があります。
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）のために、これは、下流方向で開始されなければなりません。だから、上流方向に状態をシグナリングNTLP、すなわちMNによって開始することができない、GISTは容易（上流Qモードがあるが、これは限られた範囲でのみ適用される）、上流方向にクエリを送信することはできません。そのようなアプリケーション・レベルのシグナリング（例えば、セッション開始プロトコル（SIP））またはモビリティ管理シグナリング（例えば、モバイルIP）のような追加のプロトコルの使用はNSLPとNTLPはしかし、下流方向にCN側からシグナリングをトリガするのを助けることができます。
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.
状態更新の手順（例えば、クロスオーバーノード、階層型モバイルIPにおけるモビリティ・アンカー・ポイント（MAP）（HMIP））ネットワーク内でMN、CN、あるいはノードによって開始することができます。 MNに代わって、この状態更新は、これらの状態の変更を行うことを許可されたエンティティについての認可の問題を提起します。
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）問題」と呼ばれます。
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 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].
モビリティプロトコルは、CNからMNへのトラフィックをルーティングするためのエンドツーエンドパス、およびその逆のセグメントにIP-in-IPカプセル化を使用してもよいです。カプセル化は、例えば、QoS予約をに属するデータトラフィックを識別し、フィルタしようとする試みを損ないます。ソース及び内部ヘッダの宛先IPアドレスが外部ヘッダのものとは異なるので、データトラフィックのカプセル化は、ルーティング経路に変化をもたらすことができます。モバイルIPは、エンドホスト間でデータパケットを転送するトンネリングメカニズムを使用します。トンネルを通って横断する、シグナリングメッセージをNSISは、フローのアドレスの変化によるトンネリング・パス上に透明です。モバイルIPトンネルと相互作用する場合には、CRNsはトンネルパス上に発見することができます。これは、IPトンネルの上に状態更新手順を実行するにはNSISプロトコルを可能にします。この場合、GISTは、トンネル上のCRNの発見のためのメッセージルーティング情報（MRI）の変化に対応する必要があります。また、NSLPシグナリングはシグナリングパス上にトンネルセグメントを削除するかを決定する必要がある及び/又はIPトンネリング動作と連動介し古い状態を切断する方法。また、トンネリングは、リソースがそれに応じて予約しなければならない場合、例えば、のQoS NSLPによって考慮されなければならないオーバーヘッドなどの追加のIPヘッダを付加します。だから、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, 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.
GISTは、次のシグナリングピア、ソース識別情報（SII）は、ハンドルの識別子とNSLPsを提供します。この変更をSIIは、ハンドルすると、NSLPは、ルーティングの変更が起こっている知っています。しかし、NSLPも、それはまた、セッションのためのクロスオーバーノードであるかどうかを把握することができます。唯一NSLPsは、エンドツーエンドのシグナリングの概念を持っているので、このように、CRNの発見は常に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は、セッションの方向に応じて、明示的に古いパス上の状態を除去する（GISTによって提供される）SII-ハンドルを使用してもよいです。新しいセッション情報は、同時に新しいパスに設定されています。現在NSLPs両方がメッセージの順序を識別するためにシーケンス番号を使用し、そしてこの情報は、ルーティング変化から回復するためのプロトコルで使用することができます。
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ノード間で期待されているので、これは可能です。これがそうでないならば、1つの誤動作や危険にさらさノードが効果的にすべてのものを壊す（例えば、真のリソース予約はできません）。したがって、現在、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 path support the required QoS, the CN in turn responds with a RESPONSE message to confirm the reservation (steps (5)-(6) in Figure 1).
図1は、QoS NSLPが送信者によって開始予約が使用されているCN、MNへのデータ・フローのために、モバイルIPv6ルート最適化の場合のシグナリングの一例を示す図です。ハンドオーバーイベントがMNに検出されると、MNは新しい気付アドレス（CoA）を取得し、それに応じてMRIに結合経路を更新する必要があります。 CNに向け、次に、MNの問題セッションの一意のセッションIDやその他の識別情報を運ぶのQoS NSLP RESERVEメッセージ、ならびに予約要求（ステップ（1） - 図1の（4））。 RESERVEメッセージを受信すると、（下地NTLPによって発見されるであろう）のQoS NSLPノードは対応するQoS NSLP状態を確立し、CNに向けてメッセージを転送します。同じセッションIDを持つ既存のNSLP状態がすでにある場合は、状態が更新されます。経路に沿ったすべてのQoS NSLPノードが必要なQoSをサポートしている場合、次にCNは、予約を確認するRESPONSEメッセージで応答する（ステップ（5） - （6）図1の）。
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.
双方向トンネリングの場合には、唯一の違いは、RESERVEメッセージは、ホームエージェント（HA）の代わりにCN、あまりにも、代わりにCNのHAであるべきであるRESPONSEで応答ノードに送信されるべきであるということです。詳細は第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
状態はタイマ満了によって解除することができますので、このプロセスでは、古いパスで廃止された状態が明示的に解放されません。プロセスをスピードアップするために、シグナリングをローカライズすることも可能です。 RESERVEメッセージは、この文書に記載されているCRN（図1のステップ（2））として示され、ノードに到達したときの状態が同じセッションを反映するために最初に判定された場合、ノードは、MNの古い向かってNOTIFYメッセージを発行することができますCoAを（図1のステップ（9））。 MNの古い位置に隣接したQoS NSISエンティティ（QNE）は、NOTIFYメッセージ（図1のステップ（10））を停止し、廃止状態を解除するようにCNに向かって（ティアダウンは、ビットセットを有する）RESERVEメッセージを送信する（ステップ（11）図1において）。涙メッセージでこのRESERVEは、（図1のステップ（12））CRNによって停止されます。予約シーケンス番号（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) | | | |
| | | | | | |
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から新しいRESERVEを誘発する、移動後の新たな経路に沿って新しいクエリを容易に開始することができます。同様に、第二及び第三のケースは、それぞれRESERVEまたはQUERYメッセージを開始するためにCNを必要とします。どちらの場合も難易度がCNはMNが移動したことを知らせるために、しかし、です。 MNが受信機であるため、上流のシグナル伝達は、この場合（参照部3と、上流のシグナル）には不可能であるので、それは単に、そうするNSLPメッセージを使用することができません。
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は、NATFW NSLPがCNに対してMNのデータ・フローのために、モバイルIPv6ルート最適化の場合のシグナリングの一例を示す図です。 QoS NSLPの差のみNSISイニシエータNATFW NSLP（NI）のためにいずれの場合も、シグナリングセッションを更新することができるということです。ハンドオーバーイベントがMNに検出されると、MNは、新たな気付アドレスを知って取得し、それに応じてMRIを結合されたパスを更新する必要があります。その後、MNはNATFW NSLPセッションに一意のセッションIDやその他の識別情報を運ぶCNに向かってメッセージを作成発行する（ステップ（1） - （4）図2に）。 CREATEメッセージを受信すると、（下地NTLPによって発見されるであろう）NATFW NSLPノードは、対応するNATFW NSLP状態を確立し、CNに向けてメッセージを転送します。同じセッションIDを持つ既存のNSLP状態がすでにある場合は、状態が更新されます。経路に沿った全てNATFW NSLPノードが必要NAT /ファイアウォール設定を受け入れる場合は、今度はCN、構成（ - （8）図2のステップ（5））を確認するために、RESPONSEメッセージで応答します。
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.
双方向トンネリングの場合には、唯一の違いは、CREATEメッセージをHAの代わりにCN、あまりにも代わりにCNのHAであるべきであるRESPONSEで応答ノードに送信されるべきであるということです。
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メッセージは、状態が同じセッションを反映するように最初に決定される（図2のステップ（2））は、この文書にCRNとして示さノードを、到達プロセスをスピードアップするために、ノードは、発行することができますMNの古いのCoAに向けてメッセージをNOTIFY（ステップ（9） - （10）、図2中）。図2） - NIこれに気づいたとき、それは廃止状態（（12）ステップ（11））を放出するようにCNに向けてメッセージを作成し送信します。
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) =====
(a) The topology for upstream NSIS signaling flow due to mobility (in the case that the MN is a data sender)
（A）（MNは、データ送信側である場合に）によるモビリティ上流NSISシグナリングフローのトポロジ
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- 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状態は無用であることを古いパスに設立起こします。このような状態は、できるだけ早く除去することができます。また、NSIS状態は、新たな経路に沿って確立されるように、共通の経路に沿って更新される必要があります。 （モビリティを含む）ルート変更が発生したとき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.
CRNはNSLP層で発見されました。 QoS NSLPの場合には、既存のSESSION_IDとRESERVEメッセージが受信され、その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はCNに向けた状態のセットアップのための新しいRSNで予約を開始し、また、セクション4.4.1に記載したように暗黙DCRN発見は、シグナリングの手順により行われます。 CN（すなわち、共通経路）へDCRNからMRIはRESERVEメッセージによって更新されます。 DCRNも前上流ピアに「ルート変更」（0×02）とNOTIFYを送信することができます。 NOTIFY（すなわち、QNE1図1の）ホップバイホップに転送され、エッジQNEに到達します。 QNE（これは気付くことができる方法、例えば、GISTは、最終的に未配信のメッセージを介してこれを知っているだろう、NSISの範囲外で、まだ）QNIとしてMNが消えていることを認識したら、QNEは、下流への引き裂きRESERVEを送信します。引き裂きRESERVEは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.
上流の状態更新のシナリオでは、状態更新のための2つの可能な方法があります。一つは、CN（またはHA、ゲートウェイ外部エージェント（GFA）、またはMAP）でトリガー（例えば、モバイルIP（MIP）バインディングアップデート）を受信すると、状態更新を実行するためにMNに向けて爽やかRESERVEメッセージを送信します。セクション4.4.1に記載したようUCRNは、共通経路に沿ってCNによって開始シグナリングによって暗黙的に発見されます。さわやかRESERVEはUCRNの隣接するQNEに達すると、QNEは言って応答を返信する「還元リフレッシュがサポートされていないが、完全なQSPEC必要」（0×03）。その後、UCRNは、新しい予約を設定するMNへのフルQSPECでRESERVEを送信します。
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も前下流ピアに引き裂きRESERVEを送信することができます。引き裂きRESERVEは、ホップバイホップ転送とエッジQNEに到達します。 QNEがQNIとしてMNが消えていることを認識したら、QNEは引き裂きピアを削除します。もう一つの方法は次のとおりです。GISTホップがすでに新しいパス（例えば、CN、またはHA、GFA、またはMAPからQUERYによって）MNは、ルーティングが変更されたことGISTからヒントを得て、MNは、NOTIFY送信に確立された場合上流の「ルート変更」（0×02）と述べました。インクルードはUCRNに当たるNOTIFYとき、UCRNが知られているセッションのためのものであり、新しいSII-ハンドルから来て通知することを認識しています。その後、UCRNはMNに向けて新しいRSNとRIIとRESERVEを送信します。 RESERVEを受信することにより、MNは、応答で応答します。 UCRNは、以前の下流ピアに引き裂くRESERVEを送信することができます。引き裂きRESERVEは、ホップバイホップに転送され、エッジQNEに到達します。 QNEがQNIとしてMNが消えていることを認識したら、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を反映するために、共通のパスを超える状態更新がAAAと入場コントロールの再処理に上昇を与えるものではありませんが、エンドツーエンドのシグナリングの問題は、3章でそれに対処します増加したシグナリングオーバーヘッドと待ち時間につながる可能性があります。
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が変更された場合変更されます。これは、そのようなQoS NSLPやNAT / FW NSLPなど、いくつかのNSLPsに影響します。
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 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.
それは実際の電流パス上のリソースを気にする必要があり、新しいパスのための新たなRESERVEまたはクエリを送信するので、QoS NSLPは、モビリティを意識しなければなりません。モバイルIPの上でアプリケーションのQoS NSLPは流れが現在トンネルさや経路最適化されているかどうか、例えば、実際の流路を知っていなければならないのに対して、ホームアドレスを使用して論理的な流れに沿って通信する、などのQoS NSLPは、電流を入手する必要がありリンクプロパティ。特に起因QSPECに考慮しなければならないモビリティヘッダ拡張に追加のオーバーヘッドが存在してもよい（例えば、トラフィックモデル（TMOD）におけるmパラメータは、参照[RFC5975]）。したがって、NSLPsは、電流の流れのアドレス（のCoA）、送信元アドレス、トンネリング、またはオーバーヘッド情報を要求するために、モビリティ管理の実装と相互作用しなければなりません。さらに、実装は、対応するメッセージング協会はMRIのフローと同じ経路に沿って確立されることを確実にするために、自然言語インターフェース（NLI）における適切なインタフェースアドレスを選択しなければなりません。また、ホーム・エージェントは、トンネルのための追加のアクション（例えば、予約）を行う必要があります。ホームエージェントは移動性を意識したQoS NSLPのサポートが欠けている場合は、不足しているトンネルの予約は通常の結果です。実用上の問題は、MNのホームアドレスに向けて（1 = S-フラグ付き）、ホームエージェントは、GISTのクエリを送信する必要がある状況で発生する可能性がありますし、クエリが原因HAとMN間の経路最適化にトンネリングされていません：クエリが誤って傍受されますトンネル内QNEsによる。
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.
NAT / FWボックスはしたがってNAT / FWシグナリングはでNAT /のFWを横断するリターンルータビリティテスト（RRT）及びバインディング更新（BU）/バインディング確認（BA）メッセージを許可するために実行されなければならない、MIPシグナリングの前に設定する必要がありますパス。 RRTおよびBU / BAメッセージが完了した後、より多くのNAT / FWシグナリングは、データを渡すために実行する必要があります。最適化されたバージョンは、RRT及びBU / BAメッセージパターンの両方をカバーするために結合NAT / FWのメッセージを含むことができます。しかし、これは1シグナリングのラウンドトリップで複数のNAT / FWのルールを運ぶサポートするために、わずかな更新を行うにはNAT / FW NSLPが必要な場合があります。
This section analyzes NSIS operation with the tunneled route case especially for QoS NSLP.
このセクションでは、特にQoSのNSLPのためのトンネリングされたルートの場合とNSIS操作を分析します。
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から送信されたシグナリングフローを直接リバーストンネリングを使用していない必ずしもHAを介して、または間接的にHAを介してCNに転送されます。 MNは、CNから送信されたデータ受信装置、データおよびシグナリングフローとして作用する場合一方、同じ場所に配置する場合にはHAとFA（又はHAとMNの間のIPトンネルを介してルーティングされますCOA）。このアプローチでは、ルーティングは、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.
（e）は図4（A）は、NSISシグナリングフローは、データフローのルーティング方法の方向に依存する方法を示します。
MN FA (or FL) CN
| | |
| IPv4-based Standard IP routing |
|------------ |--------------------------------->|
| | |
(a) MIPv4: MN-->CN, no reverse tunnel
（A）のMIPv4：MN - > CN、NOリバーストンネルを
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) |
| | |-------------->|
(c) MIPv4: MN-->CN, the reverse tunnel with co-located CoA
（C）のMIPv4：MN - > CN、CO-CoAの位置とリバーストンネル
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) | |
| |------------------------------->|
| | | |
(e) MIPv4: CN-->MN with co-located CoA
（E）のMIPv4：CN - 同じ場所に配置CoAを持つ> MN
Figure 4: NSIS Signaling Flows under Different Mobile IPv4 Scenarios
図4：NSISシグナリングは、異なるモバイルIPv4シナリオの下でフロー
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（シグナリング送信者など）が（図4（A）、（B）、及び（c））新しいFAに到着し、対応する結合処理が完了すると、MNはCRN発見（DCRN）と国家を行いますNSIS状態を確立する（セクション4で説明したように）CNに向けて更新
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））が使用されていない場合には、新しいNSIS状態はCNへMNからの直接経路上に確立されています。リバーストンネルおよびFA CoAが使用される場合（図4（b）参照）、新しいNSIS状態は、エンドツーエンドのパスとは別にHAへFAからトンネリング経路に沿って確立されます。必要に応じて、トンネルパスのCRNの発見と状態更新も別々に行われます。リバーストンネルと同じ場所に配置CoAが使用される場合（図4（c）参照）、DCRN発見のため及び状態更新のためのシグナリングNSISでの使用を除いて、上記FA CoAを使用した場合と同じですHAへのMNからのトンネルパスを逆転。すなわち、この場合には、トンネルエンドポイントの1つは、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にNOTIFYメッセージを送信します。場合FA CoAが使用されている（図4（D））は、CNはNSISがFAに転送されCNとHA、およびその後シグナリングメッセージをNSISの間の既存の状態を更新し、MNに到達するためにシグナリングを開始します。新しいNSIS状態は、エンドツーエンドパス別にFAにHAからトンネリング経路に沿って確立されます。この操作中、UCRNはトンネルパス上で発見され、トンネルの状態更新のための新たなMRIを作成する必要があります。必要に応じて、トンネルパスのCRNの発見と状態更新も別々に行われます。ケース内の同一位置のCoAが使用される（図4（D））、NSIS UCRN発見のため及び状態更新のためのシグナリングはまた、トンネリング経路の終点を除いて上記で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.
モバイルIPv6 [RFC3775]とモバイルIPv4とは異なり、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.
ルート最適化が使用されていない場合、データ・フロー・ルーティングおよび（CRN発見及び状態更新を含む）NSISシグナリング手順は、共同配置のCoAとモバイルIPv4を用いた場合と同様であろう。ルート最適化が使用されている場合は、シグナリングメッセージをCNへ、またはCNからMNに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.
このセクションでは、MNは、NIとして作用し、CNはモバイルIPとNSISシグナリングとの間のインターワーキングで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またはCoAをモバイルIPv6のために、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].
- [RFC5979]に記載されているようにトンネルを介して動作モードかどうかは、あらかじめ設定されたQoSセッションまたは動的に作成された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は、MNとFAが同じノードであると考えられる場合Tentryである場合しかし、手順は同じです。
- 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が状態更新手順を開始するRESERVE（エンドツーエンド）メッセージを開始します。 QoS NSLP以下GISTはGISTのヘッダを付加して対応するQoS NSLPを持つGISTノードをピアにカプセル化されたRESERVEメッセージを送信します。 FAは、NSIS対応ノードである場合は、この場合には、ピア・GISTノードは、FAです。 Tentry：FAはモバイルIPトンネルのエンドポイントの1つです。適切なNSISトンネリング動作のために、モバイルIPエンドポイントは、NSISトンネリング注意する必要があります。トンネルシグナリングとの相互作用の場合にFA由来、トンネルが既にQoSのセッションを事前設定したか否かに応じて、2つのシナリオが存在し得ます。前者の場合、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からRESERVEメッセージを受信すると、FAは、トンネルQoS設定をチェックし、そしてどのようにこのエンドツーエンドのセッションが事前設定されたトンネルセッションにマッピングすることができるか否かを判断します。 FAは、HAにRESERVEメッセージをトンネルします。 CNは、HA、FA、およびMNに到着RESPONSEメッセージで応答します。
- 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から、エンドツーエンドのRESERVEメッセージを受信すると、FAトンネルフローIDを選択し、トンネルセッションを作成し、トンネルセッションとのエンドツーエンドのセッションを関連付けます。 FAは、次に、トンネルリソースを予約するためにHAに向かって（エンドツーエンドセッションの要求に合致する）トンネルRESERVE」メッセージを送信します。エンドツーエンドのRESERVEメッセージはトンネル中間ノード（TMID）を通過しながらトンネルRESERVE」メッセージは、ホップバイホップ選択トンネルフローIDによって識別されたフローのためのトンネル内に処理されます。これら2件のメッセージがHAに到着すると、HAはトンネルセッションのための予約状態を作成し、FAにトンネルRESPONSE」メッセージを送信します。同時に、HAはトンネルセッションの予約の結果に基づいて、エンド・ツー・エンドのRESERVEメッセージを更新し、CNに向かって経路に沿ってエンドツーエンドのRESERVEメッセージを転送します。 CNは、エンドツーエンドのRESERVEメッセージを受信すると、それが戻ってMNへのエンドツーエンドの応答メッセージを送信します。
More detailed operations are specified in [RFC5979].
より詳細な操作は、[RFC5979]で指定されています。
MN (Sender) FA (Tentry) Tmid HA (Texit) CN (Receiver)
TX（送信）SC（Tentry）TMID MA（カバー）CN（レシーバー）
| | | | |
| 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)
TX（送信）SC（Tentry）TMID MA（カバー）CN（レシーバー）
| | | | |
| 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は、それぞれ事前に構成し、動的に作成されたQoSセッション、を有するモバイルIPトンネルを介して受信器で開始操作の8例を示します。基本操作は、送信者が開始した場合と同様です。
MN (Sender) FA (Tentry) Tmid HA (Texit) CN (Receiver)
TX（送信）SC（Tentry）TMID MA（カバー）CN（レシーバー）
| | | | |
| 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)
TX（送信）SC（Tentry）TMID MA（カバー）CN（レシーバー）
| 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 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セッションを使用するモードになっている場合、モバイルIPトンネルシナリオはトンネリング経路上CRNsの二つのタイプ、すなわち、エンドツーエンドパス上のCRNとCRNを含むことができます。トンネルは、あらかじめ設定されたQoSセッションを使用するモードである場合、それだけで、エンドツーエンドのパスにCRNsを有することができます。これらの二つのパスの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].
エンドツーエンドパスのCRNの発見はRESERVE（送信者が開始した場合）またはQUERY（受信機が開始した場合）メッセージを送信することによって、MNによって開始されます。 MNもハンドオーバ後に送信元アドレスとしてのHoAを使用するように、CRNは、通常の経路変更処理（すなわち、同一のSIDおよびフローIDが、異なるSII-ハンドル）によって求められます。 HAは、QoS NSLP認識している場合は、HAはCRNとして発見されました。 [RFC5974]に記載されているようにCRNは、旧経路上の引き裂きダウンプロセスを開始します。
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.
トンネリングパスのCRNの発見は、RESERVE「（送信者が開始した場合）またはQUERY」（受信機が開始した場合）メッセージを送信することによりTentryによって開始されます。セクション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）で入手可能であるので、2つの主要な問題が考えられます。一つは、選択またはビューのエンド・ツー・エンドのQoSの観点から最も適切なインターフェース（複数可）及び/又はアドレスを取得する方法です。他には、複数のパスが、同時に2つの継続的なパス（LB-CRN：CRN負荷分散）の間、すなわち、CRNをCRNsの2種類を区別して管理する方法、負荷分散の目的のために使用されている場合には、古いの間CRNとMNのハンドオーバ（：ハンドオーバCRN HO-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).
複数のCoAの登録は、[RFC5648]を提供する場合のMIPv6ルート最適化の場合には、候補のCoAにより送信QUERYsの内容は、最良のインタフェース（S）または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（S）を取得します。 MNは、BU / BA手順を実行した後、それはCoAを（S）に関連付けられたインターフェース（複数可）を介してCNに向かってクエリーメッセージを送信します。 QUERYメッセージを受信すると、CN又はゲートウェイは、QUERYメッセージに「利用可能なQoS」はオブジェクトをチェックすることによって最良の（プライマリ）のCoA（単数または複数）を決定します。次いで、RESERVEメッセージは、プライマリCoAが取るパスに沿ってリソースを予約するためにMNに向けて送信されます。予約が成功しない場合、CNは、次に高い優先度でCoAを使用して別のRESERVEメッセージを送信します。 CRNは、旧経路上に確保されたリソースを解放する（TEARフラグが設定されたRESERVE）旧アクセスルータ（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.
送信者が開始した予約の場合は、同様のアプローチが可能です。つまり、QUERYとRESERVEメッセージは、MNによって開始され、MNは、QUERYメッセージによって配信される情報に基づいて主要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 | | |
|<=================->|<===================->|<=============>|
| | | | | | | | |
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 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.
そして、（a）は、図10からのインターフェースのいずれかをMNは、同一のセッションのためのインタフェース1とインタフェース2を使用するに示すように、パス（例えば、パス1及びパス2）は、同じSIDが、異なるフローIDを有する場合MNは、パス2との間のハンドオーバを実行し、新たなCoAを取得し、MNは、に示すように、この場合には図10の（b）に示すように、新たなフローIDと（パス3を言う）新たな経路を確立しようとし、CRN両方の場合のために、SIDが同じであるが、フローIDが異なるため、それはLB-CRNまたはHO-CRNである場合、パス3は判断できません。状態更新が必要な場合は、したがって、CRNは知ることができません。この問題を解決する1つの可能な解決策は、インターフェイスとパスとの関係を示す経路種別識別子を導入することです。たとえば、インターフェイス1およびインターフェイス2からのパスに属するシグナリングメッセージ及びQNEsは、それぞれ、識別子「00」と「02」を運びます。この識別子を有することにより、パス2およびパス3との間のCRNは、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 <-----------------| | | |
| | +---+ +--+
| |
+--+
(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
(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）と連動する必要があるかもしれません。 / NSLP（QoSのNSLPまたはNAT / FW NSLP）プロトコルは、階層化モバイルIPv6およびCRNと相互GISTは、MNとMAP間で発見された場合、状態更新はアドレスマッピングにより局所化することができます。しかし、どのように状態更新が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の障害が不可能（例えばCARDとCXTPなど）Seamobyプロトコルとの相互作用を行うことができます。この場合、死者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プロキシとCRNsの使用を含む、モバイル環境での再確立およびNSIS状態の除去を開始することが許可されていることを確認することが必須です。
Sung-Hyuck Lee was the editor of early drafts of this document. Since draft version 06, Takako Sanda has taken the editorship.
宋・ヒョクリーは、このドキュメントの初期の草稿の編集者でした。ドラフト版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.
メンデス、ロバート・ハンコック、ローランド祝福、Shivanajay Marwaha、とマーティンStiemerling。二つのグループに分ける著者は、他よりも、それらのいずれかのより良い（またはより悪い）を治療せずに行われました。
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-ジュン・リー、チャールズQ.シェン、コーネリアKappler、ヘニングSchulzrinneと、そしてJonghoバンに感謝したいと思います。著者はまた、彼らの役に立つコメントと提案のためにロバート・ハンコック、アンドリュー・マクドナルド、ジョンLoughney、リュディガーGeib、チェン香港、エレナシャルピ、PRATICボーズ、マーティンStiemerling、およびルイスCordeiroに感謝したいと思います。
[RFC3775] Johnson, D., "Mobility Support in IPv6", RFC3775 , June 2004.
[RFC3775]ジョンソン、D.、 "IPv6におけるモビリティサポート"、RFC3775、2004年6月。
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010.
[RFC5971] Schulzrinneと、H.とR.ハンコック、 "GIST：一般的なインターネットシグナリング交通"、RFC 5971、2010年10月。
[RFC5973] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", RFC 5973, October 2010.
[RFC5973] Stiemerling、M.、Tschofenig、H.、アウン、C.、およびE.デイヴィス、 "NAT /ファイアウォールNSISシグナリング層プロトコル（NSLP）"、RFC 5973、2010年10月。
[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, October 2010.
[RFC5974]マナー、J.、Karagiannis、G.、およびA.マクドナルド、 "NSISシグナリング層プロトコルクオリティ・オブ・サービスシグナリングのための（NSLP）"、RFC 5974、2010年10月。
[RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010.
[RFC5944]パーキンス、C.、エド。、 "IPv4のIPモビリティのサポート、改訂"、RFC 5944、2010年11月。
[RFC2205] Braden, B., "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC2205 , September 1997.
[RFC2205]ブレーデン、B.、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"、RFC2205、1997年9月。
[RFC3726] Brunner, (Ed), M., "Requirements for Signaling Protocols", RFC3726 , June 2004.
[RFC3726]ブルナー、（エド）、M.、 "シグナリングプロトコルのための要件"、RFC3726、2004年6月。
[RFC3753] Manner, J., "Mobility Related Terminology", RFC3753 , June 2004.
[RFC3753]マナー、J.、 "モビリティ関連用語"、RFC3753、2004年6月。
[RFC4066] Liebsch, M., "Candidate Access Router Discovery (CARD)", RFC4066 , July 2005.
[RFC4066] Liebsch、M.、 "候補アクセスルータ発見（CARD）"、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]アッシュ、G.、ベイダー、A.、Kappler、C.、およびD.オラン、 "サービス品質NSISシグナリング層プロトコルのためのQSPECテンプレート（NSLP）"、RFC 5975、2010年10月。
[RFC5979] Shen, C., Schulzrinne, H., Lee, S., and J. Bang, "NSIS Operation over IP Tunnels", RFC 5979, March 2011.
"IPトンネルでNSIS操作" [RFC5979]シェン、C.、Schulzrinneと、H.、リー、S.、およびJ.バン、RFC 5979、2011年3月。
Authors' Addresses
著者のアドレス
Takako Sanda (editor) Panasonic Corporation 600 Saedo-cho, Tsuzuki-ku, Yokohama Kanagawa 224-8539 Japan
たかこ さんだ （えぢとｒ） ぱなそにｃ こｒぽらちおん ６００ さえどーちょ、 つずきーく、 よこはま かながわ ２２４ー８５３９ じゃぱん
Phone: +81 45 938 3056 EMail: sanda.takako@jp.panasonic.com
電話：+81 45 938 3056 Eメール：sanda.takako@jp.panasonic.com
Xiaoming Fu University of Goettingen Computer Networks Group Goldschmidtstr. 7 Goettingen 37077 Germany
ゲッティンゲンコンピュータネットワークグループGoldschmidtstrの暁明フー大学。 7ゲッティンゲン37077ドイツ
Phone: +49 551 39 172023 EMail: fu@cs.uni-goettingen.de
電話：+49 551 39 172023 Eメール：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
情報のFS部門とコミュニケーションエンジニアリング89ワンサン、Mohyun、処仁区龍仁京畿道449から791韓国のソン・ホーチョン韓国外国語大学
Phone: +82 31 330 4642 EMail: shjeong@hufs.ac.kr
電話：+82 31 330 4642 Eメール：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/
電話：+358 9 470 22481 Eメール：jukka.manner@tkk.fi URI：http://www.netlab.tkk.fi/~jmanner/
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
ハンネスTschofenigノキアシーメンスネットワークスLinnoitustie 6 02600エスポー、フィンランド
Phone: +358 50 4871445 EMail: Hannes.Tschofenig@nsn.com
電話番号：+358 50 4871445 Eメール：Hannes.Tschofenig@nsn.com