[要約] RFC 5980は、モバイル環境でのNSISプロトコルの操作に関する仕様です。このRFCの目的は、モバイルネットワークでのリソース予約と制御を改善するためのガイドラインを提供することです。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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 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].
NSISプロトコルスイートは、NSIS輸送層プロトコル（NTLP）とNSISシグナル層プロトコル（NSLP）の2つのレイヤーで構成されています。一般的なインターネットシグナリングトランスポート（GIST）[RFC5971]は、シグナリングアプリケーションとは無関係であり、隣接する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/NSLPに対するモビリティの効果を提示し、モバイルIPv4やモバイルIPv6シナリオのサポートなど、基本的なモビリティシナリオでそのようなNSISプロトコルがどのように機能するかについてのガイドを提供することです。また、これらのプロトコルが[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.
モビリティシナリオでは、シグナリングフローの方向に従ってデータフローが続く2つの異なるタイプのマージポイントがあり、モバイルノード（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 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と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.
ハンドオーバー後、パケットは新しいパスを通じて配信される可能性があります。古い経路の状態は、新しいパスに沿って状態を再確立した後のようにまだ残っているため、同じシグナリングセッションのために2つの別々の状態があります。古いパス上の状態はソフト状態のタイムアウトに基づいて自動的に削除されますが、状態タイマー値は非常に長い場合があります（たとえば、デフォルト値として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）の場合、これは下流方向に開始する必要があります。したがって、上流方向のNTLPシグナリング状態はMNでは開始できません。つまり、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、またはノードによって開始される場合があります（例：クロスオーバーノード、モビリティアンカーポイント（MAP）階層モバイルIP（HMIP））。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-in-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 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トンネルとの相互作用の場合、Tunneling PathでCRNを発見できます。NSISプロトコルは、IPトンネルを介して状態更新手順を実行できます。この場合、GISTは、トンネル上のCRN発見のメッセージルーティング情報（MRI）の変更に対処する必要があります。また、NSLPシグナル伝達は、信号経路のトンネルセグメントをいつ除去するか、および/またはIPトンネリング操作との統合を介して古い状態を取り壊す方法を決定する必要があります。さらに、Tunnelingは、リソースをそれに応じて予約する必要がある場合など、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は、NSLPSに次のシグナリングピア、ソース識別情報（SII）ハンドルの識別子を提供します。このSIIハンドルが変更されると、NSLPはルーティングの変更が発生したことを知っています。しかし、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ノード間で信頼のチェーンが予想されるため可能です。これが当てはまらなかった場合（たとえば、真のリソースの予約は不可能です）、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は、MNからCNへのデータフローのモバイルIPv6ルート最適化ケースでのQoS NSLPシグナル伝達の例を示しています。MNでハンドオーバーイベントが検出されると、MNは新しいケアオブアドレス（COA）を取得し、それに応じてパス結合MRIを更新する必要があります。次に、MNは、CN A QOS NSLP予約メッセージに向けて発行します。これは、セッションの一意のセッションIDおよびその他の識別情報、および予約要件（図1の手順（1） - （4））を掲載します。予備のメッセージを受け取ると、QoS NSLPノード（基礎となるNTLPによって発見されます）は、対応するQoS NSLP状態を確立し、メッセージをCNに転送します。同じセッションIDを持つ既存のNSLP状態がすでにある場合、状態は更新されます。パスに沿ったすべてのQOS NSLPノードが必要な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.
双方向のトンネルの場合、唯一の違いは、予備のメッセージをCNの代わりにホームエージェント（HA）に送信する必要があり、応答で応答するノードもCNの代わりにHAである必要があります。詳細については、セクション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として描かれているノードに到達すると、同じセッションを反映するために状態が初めて決定された場合、ノードはMNの古いものに向けて通知メッセージを発行する場合がありますCOA（図1のステップ（9））。MNの古い位置に隣接するQOS NSISエンティティ（QNE）は、図1の通知メッセージ（ステップ（10））を停止し、CNに向かって予備のメッセージ（分解ビットセット）を送信して、廃止状態を解放します（ステップ（11）図1）。涙メッセージ付きのこの予備は、図1のCRN（ステップ（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) | | | |
| | | | | | |
Figure 1: Example Basic Handover Signaling in the QoS NSLP
図1：QoSNSLPの基本的なハンドオーバーシグナル伝達の例
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から新しいリザーブを引き出すことができます。同様に、2番目と3番目のケースでは、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は、MNからCNへのデータフローのモバイルIPv6ルート最適化ケースでのNATFW NSLPシグナル伝達の例を示しています。QOS NSLPの違いは、NATFW NSLPの場合、NSISイニシエーター（NI）のみがシグナリングセッションを更新できることです。MNでハンドオーバーイベントが検出されると、MNは新しいアドレスを知り、それに応じてパス結合MRIを更新する必要があります。次に、MNはNATFW NSLPを発行し、CNに向けてメッセージを作成します。これは、セッションの一意のセッション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.
双方向のトンネルの場合、唯一の違いは、CNの代わりに作成メッセージをHAに送信する必要があり、応答で応答するノードはCNの代わりにHAである必要があることです。
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).
このプロセスでは、状態がタイマーの満了によって解放される可能性があるため、古い経路の廃止された状態は明示的に放出されません。プロセスをスピードアップするために、作成メッセージがこのドキュメントでCRNとして描かれたノードに到達すると、同じセッションを反映するために状態が初めて決定された場合、ノードはAを発行する場合があります。MNの古いCOA（図2の手順（9） - （10））へのメッセージに通知します。NIがこれに気付くと、CNに向かって作成メッセージを送信して、図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) | | | |
| | | | | | |
| | | | | | |
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) モビリティによる上流の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) ======>
(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
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の場合、既存のセッション_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はCNに向けた状態セットアップのための新しいRSNで予備を開始し、セクション4.4.1で説明されているシグナル伝達手順によって暗黙的なDCRN発見が実行されます。DCRNからCN（つまり、共通パス）へのMRIは、予備のメッセージによって更新されます。DCRNは、「ルート変更」（0x02）の通知を前の上流のピアに送信する場合があります。Notifyはホップバイホップに転送され、エッジQNEに到達します（つまり、図1のQNE1）。QNEがQNIとしてMNが消えたことを認識した後（これがNSIの範囲外であることに気づく方法は、たとえば、GISTは最終的には居住していないメッセージを通してこれを知ることができます）、QNEは下流に涙リザーブを送ります。引き裂き保護区がDCRNに到達すると、転送が停止し、ドロップします。ただし、GIST層[RFC5971]での状態メンテナンスの安価なため、GIST状態を明示的に除去する必要はないことに注意してください。送信者が開始するアプローチは、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つの可能な方法があります。1つはCN（またはHA、ゲートウェイ外部エージェント（GFA）、またはMAP）で、トリガー（モバイルIP（MIP）バインディングアップデートなど）を受信すると、MNに向けてさわやかな予備メッセージを送信します。UCRNは、セクション4.4.1で説明されているように、共通経路に沿ったCN開始シグナル伝達によって暗黙的に発見されます。さわやかなリザーブがUCRNの隣接するQNEに到達すると、QNEは「サポートされていないリフレッシュが低下し、完全なQSPECが必要」（0x03）という応答を送り返します。次に、UCRNは完全なQSPECで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がQNIが消えたことを認識した後、QNEは引き裂きピアを落とします。別の方法は、MNがルーティングが変更されたGISTからヒントを取得したときに、新しいパス（たとえば、CNまたはHA、GFA、またはMAPからのクエリによって（例：CNまたはHA、GFA、またはMAP）にすでに確立されている場合、MNは通知を送信します「ルート変更」（0x02）という上流。NotifyがUCRNにヒットすると、UCRNはNotifyが既知のセッションであり、新しいSIIハンドルから来ていることを認識しています。次に、UCRNはMNに新しいRSNとRIIを備えた予備を送ります。保護区を受け取ることにより、MNは応答で応答します。UCRNは、以前の下流のピアに引き裂き予備を送ることもあります。引き裂き保護区はホップバイホップに転送され、エッジQNEに到達します。QNEがMNが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.
州の更新の目標の1つは、セクション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などのいくつかの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 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.
QoS NSLPは、実際の現在のパスのリソースを気にかけ、新しいパスの新しいリザーブまたはクエリを送信する必要があるため、モビリティを認識する必要があります。モバイルIPの上のアプリケーションは、ホームアドレスを使用する論理フローに沿って通信しますが、QoS NSLPは実際のフローパス、たとえばフローが現在トンネル化されているかルート最適化されているかなどを認識する必要があります。リンクプロパティ。特に、QSPEC（たとえば、トラフィックモデルのMパラメーター（TMOD））で考慮する必要があるモビリティヘッダー拡張機能のために、追加のオーバーヘッドがある場合があります。[RFC5975]を参照）。したがって、NSLPは、現在のフローアドレス（COAS）、ソースアドレス、トンネリング、またはオーバーヘッドに関する情報を要求するために、モビリティ管理の実装と対話する必要があります。さらに、実装では、MRIのフローと同じパスに沿って対応するメッセージングアソシエーションが確立されるように、自然言語インターフェイス（NLI）で適切なインターフェイスアドレスを選択する必要があります。さらに、ホームエージェントは、トンネルに対して追加のアクション（予約など）を実行する必要があります。ホームエージェントがモビリティを認識しているQOS NSLPのサポートがない場合、通常、トンネルの予約がありません。ホームエージェントがMNのホームアドレスに向かってGISTクエリ（S-Flag = 1を使用）を送信する必要があり、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ボックスは、MIPシグナリングの前に構成する必要があります。したがって、NAT/FWシグナリングは、RETURNルーティング可能性テスト（RRT）とバインディングアップデート（BU）/バインディング確認（BA）メッセージを許可するために実行する必要があります。パス。RRTおよびBU/BAメッセージが完了した後、データを渡すためにより多くのNAT/FWシグナリングを実行する必要があります。最適化されたバージョンには、RRTとBU/BAメッセージの両方のパターンをカバーするために、組み合わせたNAT/FWメッセージを含めることができます。ただし、これには、NAT/FW NSLPが1つのシグナリングラウンドトリップで複数のNAT/FWルールを運ぶことをサポートするためにわずかな更新を行う必要がある場合があります。
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から送信されたデータとシグナリングフローはCNに直接転送されます。必ずしもHAを介して、または逆トンネリングを使用してHAを介して間接的にはありません。一方、MNがデータ受信機として機能する場合、CNから送信されたデータとシグナリングフローは、HAとFA（またはCo-Locatedの場合のIPトンネリング（またはHAとMN）を介してルーティングされます。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.
図4（a）から（e）は、NSISシグナル伝達フローがデータフローの方向とルーティング方法にどのように依存するかを示しています。
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)|
| | |------------->|
(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、共同位置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-> 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 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（シグナル送信者として）が新しいFAに到着し、対応する結合プロセスが完了すると（図4（a）、（b）、および（c））、MnはCRN発見（DCRN）と状態を実行しますCN（セクション4で説明されているように）に向けて更新して、MNとCNの間の新しいパスに沿ってNSIS状態を確立します。逆トンネルが使用されない場合（図4（a））、MNからCNへの直接経路に新しいNSIS状態が確立されます。逆トンネルとFA COAを使用する場合（図4（b））、新しいNSIS状態が、FAからHAへのトンネリングパスに沿ってエンドツーエンドパスからは別に確立されます。トンネルパスでのCRNディスカバリーと状態の更新も、必要に応じて個別に実行されます。逆トンネルと共同配置COAを使用している場合（図4（c））、DCRN発見と状態の更新のNSISシグナリングは、上記のFA COAを使用した場合と同じです。MNからHAへの逆トンネリングパス。つまり、この場合、トンネルのエンドポイントの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に通知メッセージを送信します。FA COAが使用される場合（図4（d））、CNはNSISシグナルを開始してCNとHAの間の既存の状態を更新し、その後NSISシグナリングメッセージがFAに転送され、MNに到達します。新しいNSIS状態は、HAからFAへのトンネルパスに沿って、エンドツーエンドパスとは別に確立されています。この操作中に、UCRNがトンネリングパスで発見され、トンネルの状態更新用の新しいMRIを作成する必要がある場合があります。トンネルパスでのCRNディスカバリーと状態の更新も、必要に応じて個別に実行されます。Co-Located 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.
モバイル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.
ルートの最適化を使用していない場合、データフロールーティングとNSISシグナル伝達手順（CRN発見と状態の更新を含む）は、共同配置COAでモバイルIPv4を使用する場合と同様です。ただし、ルート最適化を使用すると、シグナリングメッセージは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.
このセクションでは、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またはモバイル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がテントリーであることを前提としています。ただし、MNとFAが同じノードと見なされる場合、MNが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が予備（エンドツーエンド）メッセージを開始して、状態更新手順を開始します。QOS NSLPの下のGISTはGISTヘッダーを追加し、対応するQOS NSLPを使用してカプセル化された予備のメッセージをピアギストノードに送信します。この場合、FAがNSIS認識ノードである場合、ピアギストノードはFAです。FAは、モバイルIPトンネリングのエンドポイントの1つであるTentryです。適切な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から予備のメッセージを受信すると、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）を通過します。これらの2つのメッセージがHAに到着すると、HAはトンネルセッションの予約状態を作成し、Tunnel Response 'メッセージをFAに送信します。同時に、HAはトンネルセッションの予約の結果に基づいてエンドツーエンドの予備メッセージを更新し、CNに向かうパスに沿ってエンドツーエンドの予備メッセージを転送します。CNがエンドツーエンドの予備メッセージを受信すると、MNにエンドツーエンドの応答メッセージを送り返します。
More detailed operations are specified in [RFC5979].
より詳細な操作は[RFC5979]で指定されています。
MN (Sender) FA (Tentry) Tmid HA (Texit) CN (Receiver)
MN（送信者）FA（Tentry）tmid ha（texit）cn（受信者）
| | | | |
| RESERVE | | | |
+------------->| | | |
| | RESERVE | |
| +--------------------------->| |
| | | | RESERVE |
| | | +------------->|
| | | | RESPONSE |
| | | |<-------------+
| | RESPONSE | |
| |<---------------------------+ |
| RESPONSE | | | |
|<-------------+ | | |
| | | | |
Figure 5: Sender-Initiated QoS NSLP over Tunnel with Preconfigured QoS Sessions
図5：事前に設定されたQoSセッションを備えたトンネル上の送信者が開始したQoSNSLP
MN (Sender) FA (Tentry) Tmid HA (Texit) CN (Receiver)
MN（送信者）FA（Tentry）tmid ha（texit）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セッションを備えたトンネル上の送信者が開始したQoSNSLP
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（Tentry）tmid ha（texit）cn（受信者）
| | | | |
| QUERY | | | |
+------------->| | | |
| | QUERY | |
| +--------------------------->| |
| | | | QUERY |
| | | +------------->|
| | | | RESERVE |
| | | |<-------------+
| | RESERVE | |
| |<---------------------------+ |
| RESERVE | | | |
|<-------------+ | | |
| RESPONSE | | | |
+------------->| | | |
| | RESPONSE | |
| +--------------------------->| |
| | | | RESPONSE |
| | | +------------->|
| | | | |
Figure 7: Receiver-Initiated QoS NSLP over Tunnel with Preconfigured QoS Sessions
図7：事前に設定されたQoSセッションを備えたトンネル上のレシーバーが開始したQoSNSLP
MN (Sender) FA (Tentry) Tmid HA (Texit) CN (Receiver)
MN（送信者）FA（Tentry）tmid ha（texit）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セッションを備えたトンネル上のレシーバーが開始したQoSNSLP
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トンネルのシナリオには、2種類のCRN、つまりエンドツーエンドパス上のCRNとトンネリングパスにCRNを含めることができます。トンネルが事前に設定されたQoSセッションを使用するモードにある場合、エンドツーエンドパスにCRNのみを持つことができます。これら2つのパスの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ディスカバリーは、予備（送信者が開始したケース）またはクエリ（レシーバー開始ケース）メッセージを送信することにより、MNによって開始されます。MNはHOAをハンドオーバー後でもソースアドレスとして使用するため、CRNは通常のルート変更プロセス（つまり、同じSIDとフローIDですが、別のSIIハンドル）によって見つかります。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.
トンネリングパスの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.
マルチホームのモバイル環境では、複数のインターフェイスとアドレス（つまり、COASとHOA）が利用可能であるため、2つの主要な問題を考慮することができます。1つは、エンドツーエンドのQoS視点から最も適切なインターフェイスおよび/またはアドレス（ES）を選択または取得する方法です。もう1つは、複数のパスが負荷分散の目的で同時に使用される場合、2種類のCRNを区別および管理する方法、つまり2つの進行中のパス（LB-CRN：Load Balancing CRN）と古いものとCRNの間のCRNの間のCRNをどのように管理するかです。MNのハンドオーバー（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またはGatewayは、クエリメッセージで「利用可能な」オブジェクトをチェックすることにより、最適な（プライマリ）COAを決定します。次に、主要なCOAがとるパスに沿ってリソースを予約するために、MNに向かって予備のメッセージが送信されます。予約が成功しない場合、CNは次の優先度を持つCOAを使用して別の予備メッセージを送信します。CRNは、古いパスで予約済みのリソースをリリースするために、古いアクセスルーター（OAR）に向けて、断down（涙フラグセット付き）メッセージを開始する場合があります。
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 | | |
|<=================->|<===================->|<=============>|
| | | | | | | | |
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.
MNは、同じセッションでインターフェイス1とインターフェイス2を使用します。パス（パス1とパス2）は同じSIDですが、図10の（a）に示すように異なるフローIDがあります。MNはハンドオーバーを実行して新しいCOAを取得し、MNは図10の（b）に示すように、新しいフローIDを使用して新しいパス（たとえばパス3）を確立しようとします。この場合、パス2の間のCRNまた、Path 3はLB-CRNまたはHO-CRNかどうかを判断できません。どちらの場合も、SIDは同じですが、フローIDは異なります。したがって、CRNは状態の更新が必要かどうかはわかりません。この問題を解決するための可能な解決策の1つは、インターフェイスとパスの関係を示すパス分類識別子を導入することです。たとえば、インターフェイス1とインターフェイス2からのパスに属するシグナリングメッセージとQNESは、それぞれ識別子 '00'と「02」を運びます。この識別子を持つことにより、Path 2とPath 3の間のCRNは、LB-CRNまたはHO-CRNであるかどうかを判断できます。たとえば、Path 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）と対話する必要がある場合があります。GIST/NSLP（QOS NSLPまたはNAT/FW NSLP）プロトコルが階層モバイルIPv6と相互作用し、MNとANマップの間でCRNが発見された場合、状態更新はアドレスマッピングによってローカライズできます。ただし、マップの下のアクセスネットワーク内のスコープされたシグナリングメッセージを使用して状態更新を実行する方法は、将来の調査のためです。
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 Protocols（例えば、候補アクセスルーター発見（カード）[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プロトコル（カードや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プロキシやCRNの使用を含むモバイル環境でNSIS状態の再確立と除去を開始することが許可されたエンティティのみが許可されることを保証することが必須です。
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.
多くの個人がこの文書に貢献しています。著者セクションにそれらすべてをリストすることは不可能だったので、このセクションは、パウロ・メンデス、ロバート・ハンコック、ローランド・ブレッシング、シヴァナジェイ・マルワハ、マーティン・スティメーリングの貢献者に誠実な敬意を払うために作成されました。著者を2つのグループに分離することは、それらのいずれかを他のグループよりも優れた（または悪い）扱うことなく行われました。
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]ジョンソン、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、「Gist：General Internet Signaling Transport」、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.、Aoun、C。、およびE. Davies、「Nat/Firewall NSIS Signaling Layer Protocol（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] MANER、J.、Karagiannis、G。、およびA. McDonald、「サービス品質シグナル伝達のためのNSISシグナリング層プロトコル（NSLP）」、2010年10月。
[RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010.
[RFC5944] Perkins、C.、ed。、「IPv4のIPモビリティサポート、改訂」、RFC 5944、2010年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、（Ed）、M。、「シグナリングプロトコルの要件」、RFC3726、2004年6月。
[RFC3753] Manner, J., "Mobility Related Terminology", RFC3753 , June 2004.
[RFC3753] MANER、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。、「Context Transfer Protocol（CXTP）」、RFC4067、2005年7月。
[RFC5648] Wakikawa, R., "Multiple Care-of-Address Registration", RFC5648 , October 2009.
[RFC5648] Wakikawa、R。、「Multiple Care-of-Address登録」、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 5975、2010年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 Operation over IP Tunnels」、RFC 5979、2011年3月。
Authors' Addresses
著者のアドレス
Takako Sanda (editor) Panasonic Corporation 600 Saedo-cho, Tsuzuki-ku, Yokohama Kanagawa 224-8539 Japan
タカコ・サンダ（編集者）パナソニックコーポレーション600 Saedo-Cho、Tsuzuki-ku、横浜Kanagawa 224-8539 Japan
Phone: +81 45 938 3056
EMail: sanda.takako@jp.panasonic.com
Xiaoming Fu University of Goettingen Computer Networks Group Goldschmidtstr. 7 Goettingen 37077 Germany
Xiaoming Fu Goettingen University Computer Networks Group Goldschmidtstr。7 Goettingen 37077ドイツ
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
Seong-ho Jeong Hankuk FS Information Communications Engineering 89 Wangsan、Mohyun、Cheoin-Gu Yongin-Si、Gyeonggi-Do 449-791 Korea
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
電話：82 31 330 4642メール：shjeong@hufs.ac.kr jukka monather aalto University of Communications and Networking（COMNET）P.O。Box 13000 Fin-00076 Aalto Finland
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 Nokia Siemens Networks Linnoitustie 6 Espoo 02600フィンランド
Phone: +358 50 4871445
EMail: Hannes.Tschofenig@nsn.com