[要約] RFC 5979は、IPトンネル上でのNSIS（Next Steps in Signaling）操作に関する標準仕様です。このRFCの目的は、IPトンネルを介してNSIS操作を実現するための手順とプロトコルを提供することです。
Internet Engineering Task Force (IETF) C. Shen
Request for Comments: 5979 H. Schulzrinne
Category: Experimental Columbia U.
ISSN: 2070-1721 S. Lee
Samsung
J. Bang
Samsung AIT
March 2011
NSIS Operation over IP Tunnels
IPトンネル上のNSIS操作
Abstract
概要
NSIS Quality of Service (QoS) signaling enables applications to perform QoS reservation along a data flow path. When the data flow path contains IP tunnel segments, NSIS QoS signaling has no effect within those tunnel segments. Therefore, the resulting tunnel segments could become the weakest QoS link and invalidate the QoS efforts in the rest of the end-to-end path. The problem with NSIS signaling within the tunnel is caused by the tunnel encapsulation that masks packets' original IP header fields. Those original IP header fields are needed to intercept NSIS signaling messages and classify QoS data packets. This document defines a solution to this problem by mapping end-to-end QoS session requests to corresponding QoS sessions in the tunnel, thus extending the end-to-end QoS signaling into the IP tunnel segments.
NSIS Quality of Service（QOS）シグナリングにより、アプリケーションはデータフローパスに沿ってQoS予約を実行できます。データフローパスにIPトンネルセグメントが含まれている場合、NSIS QOSシグナル伝達はこれらのトンネルセグメント内で影響を与えません。したがって、結果のトンネルセグメントは最も弱いQoSリンクになり、エンドツーエンドパスの残りの部分でQoSの取り組みを無効にする可能性があります。トンネル内のNSISシグナル伝達の問題は、パケットの元のIPヘッダーフィールドをマスクするトンネルのカプセル化によって引き起こされます。これらの元のIPヘッダーフィールドは、NSIS信号メッセージを傍受し、QoSデータパケットを分類するために必要です。このドキュメントでは、トンネル内の対応するQoSセッションにエンドツーエンドのQoSセッションリクエストをマッピングすることにより、この問題の解決策を定義し、エンドツーエンドQoSシグナリングをIPトンネルセグメントに拡張します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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/rfc5979.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5979で取得できます。
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
3.1. IP Tunneling Protocols . . . . . . . . . . . . . . . . . . 6
3.2. NSIS QoS Signaling in the Presence of IP Tunnels . . . . . 7
4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Design Requirements . . . . . . . . . . . . . . . . . . . 10
4.2. Overall Design Approach . . . . . . . . . . . . . . . . . 11
4.3. Tunnel Flow ID for Different IP Tunneling Protocols . . . 13
5. NSIS Operation over Tunnels with Preconfigured QoS Sessions . 14
5.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 14
5.2. Receiver-Initiated Reservation . . . . . . . . . . . . . . 15
6. NSIS Operation over Tunnels with Dynamically Created QoS
Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Sender-Initiated Reservation . . . . . . . . . . . . . . . 17
6.2. Receiver-Initiated Reservation . . . . . . . . . . . . . . 19
7. NSIS-Tunnel Signaling Capability Discovery . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . . 25
IP tunneling [RFC1853] [RFC2003] is a technique that allows a packet to be encapsulated and carried as payload within an IP packet. The resulting encapsulated packet is called an IP tunnel packet, and the packet being tunneled is called the original packet. In typical scenarios, IP tunneling is used to exert explicit forwarding path control (e.g., in Mobile IP [RFC5944]), implement secure IP data delivery (e.g., in IPsec [RFC4301]), and help packet routing in IP networks of different characteristics (e.g., between IPv6 and IPv4 networks [RFC4213]). Section 3.1 summarizes a list of common IP tunneling protocols.
IP Tunneling [RFC1853] [RFC2003]は、パケットをカプセル化し、IPパケット内のペイロードとして伝達できるようにする手法です。結果のカプセル化されたパケットはIPトンネルパケットと呼ばれ、トンネルに登録されているパケットは元のパケットと呼ばれます。典型的なシナリオでは、IPトンネリングを使用して、明示的な転送パス制御（モバイルIP [RFC5944]など）を発揮し、安全なIPデータ配信を実装し（IPSEC [RFC4301]）、さまざまな特性のIPネットワークでのパケットルーティングを支援します。（例えば、IPv6とIPv4ネットワークの間[RFC4213]）。セクション3.1は、一般的なIPトンネルプロトコルのリストをまとめたものです。
This document considers the situation when the packet being tunneled contains a Next Step In Signaling (NSIS) [RFC4080] packet. NSIS is an IP signaling architecture consisting of a Generic Internet Signaling Transport (GIST) [RFC5971] sub-layer for signaling transport, and an NSIS Signaling Layer Protocol (NSLP) sub-layer customizable for different applications. We focus on the Quality of Service (QoS) NSLP [RFC5974] which provides functionalities that extend those of the earlier RSVP [RFC2205] signaling. In this document, the terms "NSIS" and "NSIS QoS" are used interchangeably.
このドキュメントでは、トンネルに登録されているパケットがシグナリング（NSIS）[RFC4080]パケットの次のステップが含まれている場合の状況を考慮します。NSISは、シグナリング輸送用の一般的なインターネットシグナリングトランスポート（GIST）[RFC5971]サブレイヤーと、さまざまなアプリケーションにカスタマイズ可能なNSISシグナリング層プロトコル（NSLP）サブレイヤーで構成されるIPシグナリングアーキテクチャです。以前のRSVP [RFC2205]シグナル伝達の機能を拡張する機能を提供するサービス品質（QOS）NSLP [RFC5974]に焦点を当てています。このドキュメントでは、「NSIS」と「NSIS QOS」という用語が同じ意味で使用されます。
Without additional efforts, NSIS signaling does not work within IP tunnel segments of a signaling path. The reason is that tunnel encapsulation masks the original packet including its header and payload. However, information from the original packet is required both for NSIS peer node discovery and for QoS data flow packet classification. Without access to information from the original packet, an IP tunnel acts as an NSIS-unaware virtual link in the end-to-end NSIS signaling path.
追加の努力がなければ、NSISシグナル伝達は、信号パスのIPトンネルセグメント内では機能しません。その理由は、トンネルのカプセル化がヘッダーとペイロードを含む元のパケットをマスクするからです。ただし、元のパケットからの情報は、NSISピアノードの発見とQoSデータフローパケット分類の両方に必要です。元のパケットからの情報へのアクセスがなければ、IPトンネルは、エンドツーエンドNSISシグナリングパスでNSISに不名誉な仮想リンクとして機能します。
This document defines a mechanism to extend end-to-end NSIS signaling for QoS reservation into IP tunnels. The NSIS-aware IP tunnel endpoints that support this mechanism are called NSIS-tunnel-aware endpoints. There are two main operation modes. On one hand, if the tunnel already has preconfigured QoS sessions, the NSIS-tunnel-aware endpoints map end-to-end QoS signaling requests directly to existing tunnel sessions as long as there are enough tunnel session resources; on the other hand, if no preconfigured tunnel QoS sessions are available, the NSIS-tunnel-aware endpoints dynamically initiate and maintain tunnel QoS sessions that are then associated with the corresponding end-to-end QoS sessions. Note that whether or not the tunnel preconfigures QoS sessions, and which preconfigured tunnel QoS sessions a particular end-to-end QoS signaling request should be mapped to are policy issues that are out of scope of this document.
このドキュメントでは、QoS予約のエンドツーエンドNSISシグナル伝達をIPトンネルに拡張するメカニズムを定義しています。このメカニズムをサポートするNSIS認識IPトンネルエンドポイントは、NSIS-Tunnel-Awareエンドポイントと呼ばれます。2つの主要な操作モードがあります。一方では、トンネルが既に事前に設定されたQoSセッションを持っている場合、NSIS-Tunnel-Awareのエンドポイントは、十分なトンネルセッションリソースがある限り、既存のトンネルセッションに直接エンドツーエンドのQoSシグナリング要求をマッピングします。一方、事前に設定されたトンネルQoSセッションが利用できない場合、NSIS-Tunnel-Awareのエンドポイントは、対応するエンドツーエンドQoSセッションに関連付けられたトンネルQoSセッションを動的に開始および維持します。トンネルがQoSセッションを事前に設定するかどうか、およびその事前に構成されたトンネルQoSセッションは、特定のエンドツーエンドのQoSシグナリング要求をマッピングする必要があることに注意してください。
The rest of this document is organized as follows. Section 2 defines terminology. Section 3 presents the problem statement including common IP tunneling protocols and existing behavior of NSIS QoS signaling over IP tunnels. Section 4 introduces the design requirements and overall approach of our mechanism. More details about how NSIS QoS signaling operates with tunnels that use preconfigured QoS and dynamic QoS signaling are provided in Sections 5 and 6. Section 7 describes a method to automatically discover whether a tunnel endpoint node supports the NSIS-tunnel interoperation mechanism defined in this document. Section 8 discusses IANA considerations, and Section 9 considers security.
このドキュメントの残りの部分は、次のように整理されています。セクション2では、用語を定義します。セクション3では、一般的なIPトンネルプロトコルと、IPトンネル上のNSIS QoSシグナル伝達の既存の動作を含む問題の声明を示します。セクション4では、メカニズムの設計要件と全体的なアプローチを紹介します。NSIS QOSシグナル伝達が事前に設定されたQoSを使用するトンネルで動作する方法の詳細については、セクション5および6で動的なQOSシグナル伝達を提供しています。。セクション8では、IANAの考慮事項について説明し、セクション9ではセキュリティを考慮します。
This document uses terminology defined in [RFC2473], [RFC5971], and [RFC5974]. In addition, the following terms are used:
この文書は、[RFC2473]、[RFC5971]、および[RFC5974]で定義された用語を使用します。さらに、次の用語が使用されます。
IP Tunnel: A tunnel that is configured as a virtual link between two IP nodes and on which the encapsulating protocol is IP.
IPトンネル：2つのIPノードとカプセル化プロトコルがIPである間の仮想リンクとして構成されたトンネル。
Tunnel IP Header: The IP header prepended to the original packet during encapsulation. It specifies the tunnel endpoints as source and destination.
トンネルIPヘッダー：カプセル化中に元のパケットに加えられたIPヘッダー。トンネルのエンドポイントをソースと宛先として指定します。
Tunnel-Specific Header: The header fields inserted by the encapsulation mechanism after the tunnel IP header and before the original packet. These headers may or may not exist depending on the specific tunnel mechanism used. An example of such header fields is the Encapsulation Security Payload (ESP) header for IPsec [RFC4301] tunneling mode.
トンネル固有のヘッダー：トンネルIPヘッダーの後および元のパケットの前に、カプセル化メカニズムによって挿入されたヘッダーフィールド。これらのヘッダーは、使用される特定のトンネルメカニズムに応じて存在する場合と存在しない場合があります。このようなヘッダーフィールドの例は、IPSEC [RFC4301]トンネルモードのカプセル化セキュリティペイロード（ESP）ヘッダーです。
Tunnel Intermediate Node (Tmid): A node that resides in the middle of the forwarding path between the tunnel entry-point node and the tunnel exit-point node.
トンネル中間ノード（TMID）：トンネルエントリポイントノードとトンネル出口ポイントノードの間の転送パスの中央にあるノード。
Flow Identifier (Flow ID): The set of header fields that is used to identify a data flow. For example, it may include flow sender and receiver addresses, and protocol and port numbers.
フロー識別子（フローID）：データフローの識別に使用されるヘッダーフィールドのセット。たとえば、フロー送信者とレシーバーアドレス、プロトコルとポート番号が含まれる場合があります。
End-to-End QoS Signaling: The signaling process that manipulates the QoS control information in the end-to-end path from the flow sender to the flow receiver. When the end-to-end flow path contains tunnel segments, this document uses end-to-end QoS signaling to refer to the QoS signaling outside the tunnel segments. This document uses "end-to-end QoS signaling" and "end-to-end signaling" interchangeably.
エンドツーエンドのQoSシグナリング：フロー送信者からフローレシーバーへのエンドツーエンドパスでQoS制御情報を操作するシグナリングプロセス。エンドツーエンドのフローパスにトンネルセグメントが含まれている場合、このドキュメントでは、エンドツーエンドQoSシグナル伝達を使用して、トンネルセグメントの外側のQoS信号を参照します。このドキュメントでは、「エンドツーエンドのQoSシグナル伝達」と「エンドツーエンドシグナリング」を互換性があります。
Tunnel QoS Signaling: The signaling process that manipulates the QoS control information in the path inside a tunnel, between the tunnel entry-point and the tunnel exit-point nodes. This document uses "tunnel QoS signaling" and "tunnel signaling" interchangeably.
トンネルQoSシグナル伝達：トンネル内部のパス内のQoS制御情報を操作するシグナリングプロセス、トンネルの入力ポイントとトンネル出口ポイントノードの間。このドキュメントでは、「トンネルQoSシグナル伝達」と「トンネルシグナリング」を交換可能に使用します。
NSIS-Aware Node: A node that supports NSIS signaling.
NSIS対応ノード：NSISシグナル伝達をサポートするノード。
NSIS-Aware Tunnel Endpoint Node: A tunnel endpoint node that is also an NSIS node.
NSISアウェアトンネルエンドポイントノード：NSISノードでもあるトンネルエンドポイントノード。
NSIS-Tunnel-Aware Endpoint Node: An NSIS-aware tunnel endpoint node that also supports the mechanism for NSIS operating over IP tunnels defined in this document.
NSIS-Tunnel-Awareエンドポイントノード：このドキュメントで定義されているIPトンネルで動作するNSISのメカニズムもサポートするNSISアウェアトンネルエンドポイントノード。
Tunnel from node B to node D
<---------------------->
Tunnel Tunnel Tunnel
Entry-Point Intermediate Exit-Point
Node Node Node
+-+ +-+ +-+ +-+ +-+
|A|-->--//-->--|B|=====>====|C|===//==>===|D|-->--//-->--|E|
+-+ +-+ +-+ +-+ +-+
Original Original
Packet Packet
Source Destination
Node Node
Figure 1: IP Tunnel
図1：IPトンネル
The following description about IP tunneling is derived from [RFC2473] and adapted for both IPv4 and IPv6.
IPトンネリングに関する以下の説明は[RFC2473]から派生し、IPv4とIPv6の両方に適合しています。
IP tunneling (Figure 1) is a technique for establishing a "virtual link" between two IP nodes for transmitting data packets as payloads of IP packets. From the point of view of the two nodes, this "virtual link", called an IP tunnel, appears as a point-to-point link on which IP acts like a link-layer protocol. The two IP nodes play specific roles. One node encapsulates original packets received from other nodes or from itself and forwards the resulting tunnel packets through the tunnel. The other node decapsulates the received tunnel packets and forwards the resulting original packets towards their destinations, possibly itself. The encapsulating node is called the tunnel entry-point node (Tentry), and it is the source of the tunnel packets. The decapsulating node is called the tunnel exit-point node (Texit), and it is the destination of the tunnel packets.
IPトンネリング（図1）は、データパケットをIPパケットのペイロードとして送信するための2つのIPノード間の「仮想リンク」を確立するための手法です。2つのノードの観点から、IPトンネルと呼ばれるこの「仮想リンク」は、IPがリンク層プロトコルのように機能するポイントツーポイントリンクとして表示されます。2つのIPノードが特定の役割を果たします。1つのノードは、他のノードまたはそれ自体から受信した元のパケットをカプセル化し、結果のトンネルパケットをトンネルから転送します。他のノードは、受信したトンネルパケットを脱カプセル化し、結果の元のパケットをその目的地、おそらくそれ自体に向けて転送します。カプセル化ノードは、トンネルエントリポイントノード（Tentry）と呼ばれ、トンネルパケットのソースです。脱カプセンティングノードは、トンネル出口ポイントノード（TEXIT）と呼ばれ、トンネルパケットの宛先です。
An IP tunnel is a unidirectional mechanism - the tunnel packet flow takes place in one direction between the IP tunnel entry-point and exit-point nodes. Bidirectional tunneling is achieved by combining two unidirectional mechanisms, that is, configuring two tunnels, each in opposite direction to the other -- the entry-point node of one tunnel is the exit-point node of the other tunnel.
IPトンネルは一方向のメカニズムです - トンネルパケットの流れは、IPトンネルのエントリポイントと出口点ノードの間で一方向に発生します。双方向トンネルは、2つの単方向メカニズム、つまり2つのトンネルを他方と反対方向に構成することによって達成されます。1つのトンネルのエントリポイントノードは、他のトンネルの出口ポイントノードです。
Figure 2 illustrates the original packet and the resulting tunnel packet. In a tunnel packet, the original packet is encapsulated within the tunnel header. The tunnel header contains two components, the tunnel IP header and other tunnel-specific headers. The tunnel IP header specifies the tunnel entry-point node as the IP source address and the tunnel exit-point node as the IP destination address, causing the tunnel packet to be forwarded in the tunnel. The tunnel-specific header between the tunnel IP header and the original packet is optional, depending on the tunneling protocol in use.
図2は、元のパケットと結果のトンネルパケットを示しています。トンネルパケットでは、元のパケットがトンネルヘッダー内にカプセル化されています。トンネルヘッダーには、トンネルIPヘッダーとその他のトンネル固有のヘッダーの2つのコンポーネントが含まれています。トンネルIPヘッダーは、トンネルエントリポイントノードをIPソースアドレスとして指定し、トンネル出口ポイントノードをIP宛先アドレスとして指定し、トンネルパケットをトンネルに転送します。トンネルIPヘッダーと元のパケット間のトンネル固有のヘッダーは、使用中のトンネルプロトコルに応じてオプションです。
+----------------------------------//-----+
| Original | |
| | Original Packet Payload |
| Header | |
+----------------------------------//-----+
< Original Packet >
|
v
< Tunnel Headers > < Original Packet >
+---------+-----------+-------------------------//--------------+
| Tunnel | Tunnel- | |
| IP | Specific | Original Packet |
| Header | Header | |
+---------+-----------+-------------------------//--------------+
< Tunnel IP Packet >
Figure 2: IP Tunnel Encapsulation
図2：IPトンネルのカプセル化
Commonly used IP tunneling protocols include Generic Routing Encapsulation (GRE) [RFC1701][RFC2784], Generic Routing Encapsulation over IPv4 Networks (GREIPv4) [RFC1702] and IP Encapsulation within IP (IPv4INIPv4) [RFC1853][RFC2003], Minimal Encapsulation within IP (MINENC) [RFC2004], IPv6 over IPv4 Tunneling (IPv6INIPv4) [RFC4213], Generic Packet Tunneling in IPv6 Specification (IPv6GEN) [RFC2473] and IPsec tunneling mode [RFC4301] [RFC4303]. Among these tunneling protocols, the tunnel headers in IPv4INIPv4, IPv6INIPv4, and IPv6GEN contain only a tunnel IP header, and no tunnel-specific header. All the other tunneling protocols have a tunnel header consisting of both a tunnel IP header and a tunnel-specific header. The tunnel-specific header is the GRE header for GRE and GREIPv4, the minimum encapsulation header for MINENC, and the ESP header for IPsec tunneling mode. As will be discussed in Section 4.3, some of the tunnel-specific headers may be used to identify a flow in the tunnel and facilitate NSIS operating over IP tunnels.
一般的に使用されるIPトンネルプロトコルには、汎用ルーティングカプセル化（GRE）[RFC1701] [RFC2784]、IPv4ネットワーク（GREIPV4）[RFC1702]上の一般的なルーティングカプセル化、およびIP（IPv4INIPV4）内のIPカプセル化（Minenc）[RFC2004]、IPv6 Over IPv4 Tunneling（IPv6Inipv4）[RFC4213]、IPv6仕様（IPv6Gen）[RFC2473]およびIPSECトンネルモード[RFC4301] [RFC4303]の汎用パケットトンネル。これらのトンネルプロトコルの中で、IPv4INIPv4、IPv6INIPv4、およびIPv6Genのトンネルヘッダーには、トンネルIPヘッダーのみが含まれており、トンネル固有のヘッダーはありません。他のすべてのトンネルプロトコルには、トンネルIPヘッダーとトンネル固有のヘッダーの両方で構成されるトンネルヘッダーがあります。トンネル固有のヘッダーは、GREおよびGREIPV4のGREヘッダー、Minencの最小カプセル化ヘッダー、IPSECトンネルモードのESPヘッダーです。セクション4.3で説明するように、トンネル固有のヘッダーの一部を使用して、トンネルの流れを識別し、IPトンネルを介して動作するNSIを促進できます。
Typically, applications use NSIS QoS signaling to reserve resources for a flow along the flow path. NSIS QoS signaling can be initiated by either the flow sender or flow receiver. Figure 3 shows an example scenario with five NSIS nodes, including flow sender node A, flow receiver node E, and intermediate NSIS nodes B, C, and D. Nodes that are not NSIS QoS capable are not shown.
通常、アプリケーションはNSIS QoSシグナリングを使用して、流れに沿った流れのリソースを予約します。NSIS QoSシグナル伝達は、フロー送信者またはフローレシーバーのいずれかによって開始できます。図3は、Flow SenderノードA、フローレシーバーノードE、およびNSIS QoSが対応していないNSIS QOSではないNSISノードB、C、およびD.ノードを含む5つのNSISノードを備えた5つのNSISノードを備えたシナリオの例を示しています。
NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS
Node Node Node Node Node
+-+ +-+ +-+ +-+ +-+
|A|-->--//-->--|B|----->----|C|---//-->---|D|-->--//-->--|E|
+-+ +-+ +-+ +-+ +-+
Flow Flow
Sender Receiver
Node Node
Figure 3: Example Scenario of NSIS QoS Signaling
図3：NSIS QoSシグナル伝達の例のシナリオ
Figure 4 illustrates a sender-initiated signaling sequence in the scenario of Figure 3. Sender node A sends a RESERVE message towards receiver node E. The RESERVE message gets forwarded by intermediate NSIS Nodes B, C, and D and finally reaches receiver node E. Receiver node E then sends back a RESPONSE message confirming the QoS reservation, again through the previous intermediate NSIS nodes in the flow path.
図4は、図3のシナリオで送信者が開始したシグナル伝達シーケンスを示しています。SenderNodeAは、レシーバーノードEに向かって予備メッセージを送信します。その後、レシーバーノードEは、フローパスの前の中間NSISノードを介して、QoS予約を確認する応答メッセージを送り返します。
There are two important aspects in the above signaling process that are worth mentioning. First, the flow sender does not initially know exactly which intermediate nodes are NSIS-aware and should be involved in the signaling process for a flow from node A to node E. Discovery of those nodes (namely, nodes B, C, and D) is accomplished by a separate NSIS peer discovery process (not shown above; see [RFC5971]). The NSIS peer discovery messages contain special IP header and payload formats or include a Router Alert Option (RAO) [RFC2113] [RFC2711]. The special formats of NSIS discovery messages allow nodes B, C, and D to intercept the messages and subsequently insert themselves into the signaling path for the flow in question. After formation of the signaling path, all signaling messages corresponding to this flow will be passed to these nodes for processing. Other nodes that are not NSIS-aware simply forward all signaling messages, as they would any other IP packets that do not require additional handling.
上記のシグナリングプロセスには、言及する価値がある2つの重要な側面があります。まず、フロー送信者は最初にどの中間ノードがNSISを認識し、ノードAからノードEへのフローのシグナル伝達プロセスに関与するかを正確に認識していません。別のNSISピアディスカバリープロセスによって達成されます（上記は示していません。[RFC5971]を参照）。NSISピアディスカバリーメッセージには、特別なIPヘッダーとペイロード形式が含まれているか、ルーターアラートオプション（RAO）[RFC2113] [RFC2711]が含まれています。NSISディスカバリーメッセージの特別な形式により、ノードB、C、およびDがメッセージを傍受し、その後、問題のフローの信号パスに自分自身を挿入することができます。シグナリングパスの形成後、このフローに対応するすべてのシグナリングメッセージは、処理のためにこれらのノードに渡されます。NSISが認識していない他のノードは、追加の処理を必要としない他のIPパケットと同様に、すべての信号メッセージを単純に転送するだけです。
Node A Node B Node C Node D Node E
| | | | |
| RESERVE | | | |
+------------->| | | |
| | RESERVE | | |
| +------------->| | |
| | | RESERVE | |
| | +------------->| |
| | | | RESERVE |
| | | +------------->|
| | | | RESPONSE |
| | | |<-------------+
| | | RESPONSE | |
| | |<-------------+ |
| | RESPONSE | | |
| |<-------------+ | |
| RESPONSE | | | |
|<-------------+ | | |
| | | | |
| | | | |
Figure 4: Sender-Initiated NSIS QoS Signaling
図4：送信者開始NSIS QoSシグナル伝達
Second, the goal of QoS signaling is to install control information to give QoS treatment for the flow being signaled. Basic QoS control information includes the data Flow ID for packet classification and the type of QoS treatment those packets are entitled to. The Flow ID contains a set of header fields such as flow sender and receiver addresses, and protocol and port numbers.
第二に、QoSシグナル伝達の目標は、制御情報をインストールして、信号されているフローのQoS処理を与えることです。基本的なQoS制御情報には、パケット分類のためのデータフローIDと、それらのパケットが権利を与えられるQOS処理のタイプが含まれます。フローIDには、フロー送信者やレシーバーアドレス、プロトコルとポート番号などのヘッダーフィールドのセットが含まれています。
Now consider Figure 5 where nodes B, C, and D are endpoints and intermediate nodes of an IP tunnel. During the signaling path discovery process, node B can still intercept and process NSIS peer discovery messages if it recognizes them before performing tunnel encapsulation; node D can identify NSIS peer discovery messages after performing tunnel decapsulation. A tunnel intermediate node such as node C, however, only sees the tunnel header of the packets and will not be able to identify the original NSIS peer discovery message or insert itself in the flow signaling path. Furthermore, the Flow ID of the original flow is based on IP header fields of the original packet. Those fields are also hidden in the payload of the tunnel packet. So, there is no way node C can classify packets belonging to that flow in the tunnel.
次に、図5を考えてみましょう。ここで、ノードb、c、およびdは、IPトンネルのエンドポイントと中間ノードです。シグナリングパス発見プロセス中、ノードBは、トンネルのカプセル化を実行する前にそれらを認識した場合、NSISピアディスカバリーメッセージを傍受および処理できます。ノードDは、トンネル脱カプセル化を実行した後、NSISピアディスカバリーメッセージを識別できます。ただし、ノードCなどのトンネル中間ノードは、パケットのトンネルヘッダーのみを表示し、元のNSISピアディスカバリーメッセージを識別したり、フローシグナル伝達経路に挿入したりすることはできません。さらに、元のフローのフローIDは、元のパケットのIPヘッダーフィールドに基づいています。これらのフィールドは、トンネルパケットのペイロードにも隠されています。したがって、ノードCがトンネル内のその流れに属するパケットを分類する方法はありません。
Tunnel from node B to node D
<---------------------->
Tunnel Tunnel Tunnel
Entry-Point Intermediate Exit-Point
NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS
Node Node Node Node Node
+-+ +-+ +-+ +-+ +-+
|A|-->--//-->--|B|=====>====|C|===//==>===|D|-->--//-->--|E|
+-+ +-+ +-+ +-+ +-+
Flow Flow
Sender Receiver
Node Node
Figure 5: Example Scenario of NSIS QoS Signaling with IP Tunnel
図5：IPトンネルによるNSIS QoSシグナリングの例のシナリオ
In summary, an IP tunnel segment normally appears like a QoS-unaware virtual link. Since the best QoS of an end-to-end path is judged based on its weakest segment, we need a mechanism to extend NSIS into the IP tunnel segments, which should allow the tunnel intermediate nodes to intercept original NSIS signaling messages and classify original data flow packets in the presence of tunnel encapsulation.
要約すると、IPトンネルセグメントは通常、QOSに不名誉な仮想リンクのように表示されます。エンドツーエンドパスの最良のQOはその最も弱いセグメントに基づいて判断されるため、NSIをIPトンネルセグメントに拡張するメカニズムが必要です。これにより、トンネル中間ノードが元のNSISシグナリングメッセージを傍受し、元のデータを分類できるようになります。トンネルカプセル化の存在下でのフローパケット。
We identify the following design requirements for NSIS operating over IP tunnels.
IPトンネルを介して動作するNSIの次の設計要件を特定します。
o The mechanism should work with all common IP tunneling protocols listed in Section 3.1.
o メカニズムは、セクション3.1にリストされているすべての一般的なIPトンネルプロトコルで動作する必要があります。
o Some IP tunnels maintain preconfigured QoS sessions inside the tunnel. The mechanism should work for IP tunnels both with and without preconfigured tunnel QoS sessions.
o 一部のIPトンネルは、トンネル内で事前に設定されたQoSセッションを維持しています。メカニズムは、事前に設定されたトンネルQoSセッションの有無にかかわらず、IPトンネルで機能する必要があります。
o The mechanism should minimize the required upgrade to existing infrastructure in order to facilitate its deployment. Specifically, we should limit the necessary upgrade to the tunnel endpoints.
o メカニズムは、展開を容易にするために、既存のインフラストラクチャへの必要なアップグレードを最小限に抑える必要があります。具体的には、必要なアップグレードをトンネルエンドポイントに制限する必要があります。
o The mechanism should provide a method for one NSIS-tunnel-aware endpoint to discover whether the other endpoint is also NSIS-tunnel-aware, when necessary.
o メカニズムは、1つのNSIS-Tunnel-Awareエンドポイントが必要に応じてNSIS-Tunnel-Awareであるかどうかを発見するための方法を提供する必要があります。
o The mechanism should learn from the design experience of previous related work on RSVP over IP tunnels (RSVP-TUNNEL) [RFC2746], while also addressing the following major differences of NSIS from RSVP. First, NSIS is designed as a generic framework to accommodate various signaling application needs, and therefore is split into a signaling transport layer and a signaling application layer; RSVP does not have a layer split and is designed only for QoS signaling. Second, NSIS QoS NSLP allows both sender-initiated and receiver-initiated reservations; RSVP only supports receiver-initiated reservations. Third, NSIS deals only with unicast; RSVP also supports multicast. Fourth, NSIS integrates a new SESSION-ID feature which is different from the session identification concept in RSVP.
o メカニズムは、IPトンネル（RSVPトンネル）[RFC2746]上のRSVPに関する以前の関連研究の設計体験から学習する必要があり、NSISのNSISの次の主要な違いにも対処します。第一に、NSISは、さまざまなシグナリングアプリケーションのニーズに対応するための一般的なフレームワークとして設計されているため、シグナリング輸送層とシグナリングアプリケーション層に分割されます。RSVPにはレイヤースプリットがなく、QoSシグナリング用にのみ設計されています。第二に、NSIS QOS NSLPでは、送信者が開始した予約と受信機が開始する両方の予約を許可します。RSVPは、受信機が開始する予約のみをサポートします。第三に、NSISはユニキャストのみを扱っています。RSVPはマルチキャストもサポートしています。第4に、NSISは、RSVPのセッション識別コンセプトとは異なる新しいセッションID機能を統合します。
The overall design of this NSIS signaling and IP tunnel interworking mechanism draws similar concepts from RSVP-TUNNEL [RFC2746], but is tailored and extended for NSIS operation.
このNSISシグナル伝達とIPトンネルインターワーキングメカニズムの全体的な設計は、RSVPトンネル[RFC2746]から同様の概念を引き出しますが、NSIS操作のために調整および拡張されています。
Since we only consider unidirectional flows, to accommodate flows in both directions of a tunnel, we require both tunnel entry-point and tunnel exit-point to be NSIS-tunnel-aware. An NSIS-tunnel-aware endpoint knows whether the other tunnel endpoint is NSIS-tunnel-aware either through preconfiguration or through an NSIS-tunnel capability discovery mechanism defined in Section 7.
トンネルの両方向への流れに対応するために一方向の流れのみを考慮するため、トンネルの入力ポイントとトンネル出口ポイントの両方がNSIS-Tunnel-Awareである必要があります。NSIS-Tunnel-Awareのエンドポイントは、他のトンネルエンドポイントが、前構成前またはセクション7で定義されているNSISトンネル能力発見メカニズムを介してNSISトンネルが認識しているかどうかを知っています。
Tunnel endpoints need to always intercept NSIS peer discovery messages and insert themselves into the NSIS signaling path so they can receive all NSIS signaling messages and coordinate their interaction with tunnel QoS.
トンネルのエンドポイントは、常にNSISピアディスカバリーメッセージを傍受し、NSISシグナリングパスに自分自身を挿入して、すべてのNSISシグナリングメッセージを受信し、トンネルQOとの相互作用を調整できるようにする必要があります。
To facilitate QoS handling in the tunnel, an end-to-end QoS session is mapped to a tunnel QoS session, either preconfigured or dynamically created. The tunnel session uses a tunnel Flow ID based on information available in the tunnel headers, thus allowing tunnel intermediate nodes to classify flow packets correctly.
トンネルでのQoS処理を容易にするために、エンドツーエンドのQoSセッションが、事前に設定された、または動的に作成されたトンネルQoSセッションにマッピングされます。トンネルセッションでは、トンネルヘッダーで利用可能な情報に基づいてトンネルフローIDを使用するため、トンネル中間ノードがフローパケットを正しく分類できるようにします。
For tunnels that maintain preconfigured QoS sessions, upon receiving a request to reserve resources for an end-to-end session, the tunnel endpoint maps the end-to-end QoS session to an existing tunnel session. To simplify the design, the mapping decision is always made by the tunnel entry-point, regardless of whether the end-to-end session uses sender-initiated or receiver-initiated NSIS signaling mode. The details about which end-to-end session can be mapped to which preconfigured tunnel session depend on policy mechanisms outside the scope of this document.
エンドツーエンドセッションのリソースを予約するリクエストを受け取った後、事前に設定されたQoSセッションを維持するトンネルの場合、トンネルエンドポイントはエンドツーエンドのQoSセッションを既存のトンネルセッションにマッピングします。設計を簡素化するために、エンドツーエンドセッションが送信者開始または受信機が開始したNSISシグナル伝達モードを使用するかどうかに関係なく、マッピング決定はトンネルの入力ポイントによって常に行われます。どのエンドツーエンドセッションをマッピングできるかの詳細は、事前に構成されたトンネルセッションが、このドキュメントの範囲外のポリシーメカニズムに依存するかをマッピングできます。
For tunnels that do not maintain preconfigured QoS sessions, the NSIS-tunnel-aware endpoints dynamically create and manage a corresponding tunnel QoS session for the end-to-end session. Since the initiation mode of both QoS sessions can be sender-initiated or receiver-initiated, to simplify the design, we require that the initiation mode of the tunnel QoS session follows that of the end-to-end QoS session. In other words, the end-to-end QoS session and its corresponding tunnel QoS session are either both sender-initiated or both receiver-initiated. To keep the handling mechanism consistent with the case for tunnels with preconfigured QoS sessions, the tunnel entry-point always initiates the mapping between the tunnel session and the end-to-end session.
事前に設定されたQoSセッションを維持していないトンネルの場合、NSIS-Tunnel-Awareエンドポイントは、エンドツーエンドセッションの対応するトンネルQoSセッションを動的に作成および管理します。両方のQoSセッションの開始モードは、送信者開始または受信機が開始する可能性があるため、設計を簡素化するため、トンネルQoSセッションの開始モードがエンドツーエンドQoSセッションの開始モードに従う必要があります。言い換えれば、エンドツーエンドのQoSセッションとその対応するトンネルQoSセッションは、送信者開始または両方の受信機が開始されます。処理メカニズムを事前に設定されたQoSセッションを備えたトンネルのケースと一致するようにするために、トンネルの入力ポイントは常にトンネルセッションとエンドツーエンドセッションの間のマッピングを開始します。
As the mapping initiator, the tunnel entry-point records the association between the end-to-end session and its corresponding tunnel session, both in tunnels with and without preconfigured QoS sessions. This association serves two purposes, one for the signaling plane and the other for the data plane. For the signaling plane, the association enables the tunnel entry-point to coordinate necessary interactions between the end-to-end and the tunnel QoS sessions, such as QoS adjustment in sender-initiated reservations. For the data plane, the association allows the tunnel entry-point to correctly encapsulate data flow packets according to the chosen tunnel Flow ID. Since the tunnel Flow ID uses header fields that are visible inside the tunnel, the tunnel intermediate nodes can classify the data flow packets and apply appropriate QoS treatment.
マッピングイニシエーターとして、トンネルエントリポイントは、エンドツーエンドのセッションと対応するトンネルセッションとの関連を記録します。この関連付けは、シグナリングプレーン用、もう1つはデータプレーン用の2つの目的に対応しています。シグナリングプレーンの場合、アソシエーションは、トンネルエントリポイントが、送信者開始予約のQoS調整など、エンドツーエンドとトンネルQoSセッションの間の必要な相互作用を調整することを可能にします。データプレーンの場合、アソシエーションは、選択したトンネルフローIDに従って、トンネルエントリポイントがデータフローパケットを正しくカプセル化することを許可します。トンネルフローIDはトンネル内に見えるヘッダーフィールドを使用するため、トンネル中間ノードはデータフローパケットを分類し、適切なQoS処理を適用できます。
In addition to the tunnel entry-point recording the association between the end-to-end session and its corresponding tunnel session, the tunnel exit-point also needs to maintain the same association for similar reasons. For the signaling plane, this association at the tunnel exit-point enables the interaction of the end-to-end and the tunnel QoS session such as QoS adjustment in receiver-initiated reservations. For the data plane, this association tells the tunnel exit-point that the relevant data flow packets need to be decapsulated according to the corresponding tunnel Flow ID.
エンドツーエンドセッションと対応するトンネルセッションとの関連性を記録するトンネルの入力ポイントに加えて、トンネル出口ポイントも同様の理由で同じ関連を維持する必要があります。シグナリングプレーンの場合、トンネル出口点でのこの関連性により、レシーバーが開始する予約におけるQoS調整など、エンドツーエンドとトンネルQoSセッションの相互作用が可能になります。データプレーンの場合、この関連付けは、トンネルの出口点に、関連するデータフローパケットを対応するトンネルフローIDに従って脱カプセル化する必要があることを伝えます。
In tunnels with preconfigured QoS sessions, the tunnel exit-point may also learn about the mapping information between the corresponding tunnel and end-to-end QoS sessions through preconfiguration as well. In tunnels without preconfigured QoS sessions, the tunnel exit-point knows the mapping between the corresponding tunnel and end-to-end QoS sessions through the NSIS signaling process that creates the tunnel QoS sessions inside the tunnel, with the help of appropriate QoS NSLP session-binding and message-binding mechanisms.
事前に設定されたQoSセッションを備えたトンネルでは、トンネルの出口ポイントは、対応するトンネルとエンドツーエンドのQoSセッションの間のマッピング情報についても、事前構成を通じて学習する場合があります。事前に設定されたQoSセッションのないトンネルでは、トンネルの出口ポイントは、適切なQoS NSLPセッションの助けを借りて、トンネル内のトンネルQoSセッションを作成するNSISシグナリングプロセスを通じて、対応するトンネルとエンドツーエンドのQoSセッションの間のマッピングを知っています。 - バインディングおよびメッセージ結合メカニズム。
One problem for NSIS operating over IP tunnels that dynamically create QoS sessions is that it involves two signaling sequences. The outcome of the tunnel signaling session directly affects the outcome of the end-to-end signaling session. Since the two signaling sessions overlap in time, there are circumstances when a tunnel endpoint has to decide whether it should proceed with the end-to-end signaling session while it is still waiting for results of the tunnel session. This problem can be addressed in two ways, namely sequential mode and parallel mode. In sequential mode, end-to-end signaling pauses while it is waiting for results of tunnel signaling, and resumes upon receipt of the tunnel signaling outcome. In parallel mode, end-to-end signaling continues outside the tunnel while tunnel signaling is still in process and its outcome is unknown. The parallel mode may lead to reduced signaling delays if the QoS resources in the tunnel path are sufficient compared to the rest of the end-to-end path. If the QoS resources in the tunnel path are more constraint than the rest of the end-to-end path, however, the parallel mode may lead to wasted end-to-end signaling or may necessitate renegotiation after the tunnel signaling outcome becomes available. In those cases, the signaling flow of the parallel mode also tends to be complicated. This document adopts a sequential mode approach for the two signaling sequences.
QoSセッションを動的に作成するIPトンネルを介して動作するNSIの1つの問題は、2つのシグナル伝達シーケンスが含まれることです。トンネルシグナリングセッションの結果は、エンドツーエンドシグナリングセッションの結果に直接影響します。2つのシグナリングセッションは時間内に重複しているため、トンネルエンドポイントがトンネルセッションの結果をまだ待っている間にエンドツーエンドのシグナリングセッションを進める必要があるかどうかを決定する必要がある場合があります。この問題は、シーケンシャルモードとパラレルモードの2つの方法で対処できます。シーケンシャルモードでは、トンネルシグナル伝達の結果を待っている間にエンドツーエンドのシグナル伝達が一時停止し、トンネルシグナリングの結果を受け取ったときに再開します。並列モードでは、エンドツーエンドのシグナル伝達はトンネルの外側に続きますが、トンネルシグナルはまだ進行中であり、その結果は不明です。パラレルモードは、トンネルパスのQoSリソースでエンドツーエンドパスの残りの部分と比較して十分である場合、シグナリングの遅延が減少する場合があります。ただし、トンネルパス内のQoSリソースがエンドツーエンドパスの残りの部分よりも制約である場合、並列モードは無駄なエンドツーエンドシグナル伝達につながる可能性があるか、トンネルシグナルの結果が利用可能になった後、再交渉を必要とする場合があります。そのような場合、並列モードのシグナル伝達フローも複雑になる傾向があります。このドキュメントは、2つのシグナル伝達シーケンスにシーケンシャルモードアプローチを採用しています。
A tunnel Flow ID identifies the end-to-end flow for packet classification within the tunnel. The tunnel Flow ID is based on a set of tunnel header fields. Different tunnel Flow IDs can be chosen for different tunneling mechanisms in order to minimize the classification overhead. This document specifies the following Flow ID formats for the respective tunneling protocols.
トンネルフローIDは、トンネル内のパケット分類のエンドツーエンドフローを識別します。トンネルフローIDは、トンネルヘッダーフィールドのセットに基づいています。分類オーバーヘッドを最小限に抑えるために、さまざまなトンネルメカニズムに異なるトンネルフローIDを選択できます。このドキュメントは、それぞれのトンネルプロトコルの次のフローID形式を指定します。
o For IPv6 tunneling protocols (IPv6GEN), the tunnel Flow ID consists of the tunnel entry-point IPv6 address and the tunnel exit-point IPv6 address plus a unique IPv6 flow label [RFC3697].
o IPv6トンネルプロトコル（IPv6Gen）の場合、トンネルフローIDは、トンネルエントリポイントIPv6アドレスとトンネルエグジポイントIPv6アドレスと、一意のIPv6フローラベル[RFC3697]で構成されています。
o For IPsec tunnel mode (IPsec), the tunnel Flow ID contains the tunnel entry-point IP address and the tunnel exit-point IP address plus the Security Parameter Index (SPI).
o IPSECトンネルモード（IPSEC）の場合、トンネルフローIDには、トンネルエントリポイントIPアドレスとトンネル出口ポイントIPアドレスとセキュリティパラメーターインデックス（SPI）が含まれています。
o For all other tunneling protocols (GRE, GREIPv4, IPv4INIPv4, MINENC, IPv6INIPv4), the tunnel entry-point inserts an additional UDP header between the tunnel header and the original packet. The Flow ID consists of the tunnel entry-point and tunnel exit-point IP addresses and the source port number in the additional UDP header. The source port number is dynamically chosen by the tunnel entry-point and conveyed to the tunnel exit-point. In these cases, it is especially important that the tunnel exit-point understands the additional UDP encapsulation, and therefore can correctly decapsulate both the normal tunnel header and the additional UDP header. In other words, both tunnel endpoints need to be NSIS-tunnel-aware.
o 他のすべてのトンネルプロトコル（GRE、GREIPV4、IPv4INIPv4、Minenc、IPv6Inipv4）について、トンネルエントリポイントは、トンネルヘッダーと元のパケットの間に追加のUDPヘッダーを挿入します。フローIDは、トンネルエントリポイントとトンネルの出口ポイントIPアドレスと、追加のUDPヘッダーのソースポート番号で構成されています。ソースポート番号は、トンネルエントリポイントによって動的に選択され、トンネルの出口ポイントに伝えられます。これらの場合、トンネル出口ポイントが追加のUDPカプセル化を理解することが特に重要であるため、通常のトンネルヘッダーと追加のUDPヘッダーの両方を正しく脱カプセル化できます。言い換えれば、両方のトンネルエンドポイントはNSIS-Tunnel-Awareである必要があります。
The above recommendations about choosing the tunnel Flow ID apply to dynamically created QoS tunnel sessions. For preconfigured QoS tunnel sessions, the corresponding Flow ID is determined by the configuration mechanism itself. For example, if the tunnel QoS is Diffserv based, the Diffserv Code Point (DSCP) field value may be used to identify the corresponding tunnel session.
トンネルフローIDの選択に関する上記の推奨事項は、動的に作成されたQoSトンネルセッションに適用されます。事前に設定されたQoSトンネルセッションの場合、対応するフローIDは構成メカニズム自体によって決定されます。たとえば、トンネルQoSがDiffServベースの場合、DiffServコードポイント（DSCP）フィールド値を使用して、対応するトンネルセッションを識別できます。
When tunnel QoS is managed by preconfigured QoS sessions, both the tunnel entry-point and tunnel exit-point need to be configured with information about the Flow ID of the tunnel QoS session. This allows the tunnel endpoints to correctly perform matching encapsulating and decapsulating operations. The procedures of NSIS operating over tunnels with preconfigured QoS sessions depend on whether the end-to-end NSIS signaling is sender-initiated or receiver-initiated. But in both cases, it is the tunnel entry-point that first creates the mapping between a tunnel session and an end-to-end session.
トンネルQoSが事前に設定されたQoSセッションによって管理される場合、トンネルの入力ポイントとトンネル出口点の両方を、トンネルQoSセッションのフローIDに関する情報とともに構成する必要があります。これにより、トンネルのエンドポイントは、一致するカプセル化および脱カプセル化操作を正しく実行できます。事前に設定されたQoSセッションでトンネルを介して動作するNSISの手順は、エンドツーエンドNSISシグナル伝達が送信者開始または受信機が開始するかどうかによって異なります。しかし、どちらの場合も、最初にトンネルセッションとエンドツーエンドセッションの間のマッピングを作成するのはトンネルの入力ポイントです。
Figure 6 illustrates the signaling sequence when end-to-end signaling outside the tunnel is sender-initiated. Upon receiving a RESERVE message from the sender, Tentry checks the tunnel QoS configuration, determines whether and how this end-to-end session can be mapped to a preconfigured tunnel session. The mapping criteria are part of the preconfiguration and outside the scope of this document. Tentry then tunnels the RESERVE message to Texit. Texit forwards the RESERVE message to the receiver. The receiver replies with a RESPONSE message that arrives at Texit, Tentry, and finally the sender. If the RESPONSE message that Tentry receives confirms that the overall signaling is successful, Tentry starts to encapsulate all incoming packets of the data flow using the tunnel Flow ID corresponding to the mapped tunnel session. Texit knows how to decapsulate the tunnel packets because it recognizes the mapped tunnel Flow ID based on information supplied during tunnel session preconfiguration.
図6は、トンネルの外側のエンドツーエンドのシグナルが送信者開始である場合のシグナル伝達シーケンスを示しています。送信者から予備のメッセージを受信すると、TentryはトンネルQoS構成をチェックし、このエンドツーエンドセッションを事前に設定されたトンネルセッションにマッピングするかどうか、および方法を決定します。マッピング基準は、事前構成の一部であり、このドキュメントの範囲外です。テントリーはその後、予備のメッセージをTexitにトンネルします。Texitは予備のメッセージを受信機に転送します。受信者は、Texit、Tentry、および最後に送信者に到着する応答メッセージで返信します。Tentryが受信した応答メッセージが全体的なシグナル伝達が成功していることを確認した場合、Tentryはマッピングされたトンネルセッションに対応するトンネルフローIDを使用して、データフローのすべての着信パケットをカプセル化し始めます。Texitは、トンネルセッションの事前設定中に提供された情報に基づいて、マッピングされたトンネルフローIDを認識するため、トンネルパケットを脱カプセル化する方法を知っています。
Sender Tentry Tmid Texit Receiver
| | | | |
| RESERVE | | | |
+------------->| | | |
| | RESERVE | |
| +---------------------------->| |
| | | | RESERVE |
| | | +------------->|
| | | | RESPONSE |
| | | |<-------------+
| | RESPONSE | |
| |<----------------------------+ |
| RESPONSE | | | |
|<-------------+ | | |
| | | | |
| | | | |
Figure 6: Sender-Initiated End-to-End Session with Preconfigured Tunnel QoS Sessions
図6：事前に設定されたトンネルQoSセッションを使用した送信者開始エンドツーエンドセッション
Figure 7 shows the signaling sequence when end-to-end signaling outside the tunnel is receiver-initiated. Upon receiving the first end-to-end Query message, Tentry examines the tunnel QoS configuration, then updates and tunnels the Query message to Texit. Texit decapsulates the QUERY message, processes it, and forwards it toward the receiver. The receiver sends back a RESERVE message passing through Texit and arriving at Tentry. Tentry decides on whether and how the QoS request for this end-to-end session can be mapped to a preconfigured tunnel session based on criteria outside the scope of this document. Then, Tentry forwards the RESERVE message towards the sender. The signaling continues until a RESPONSE message arrives at Tentry, Texit, and finally the receiver. If the RESPONSE message that Tentry receives confirms that the overall signaling is successful, Tentry starts to encapsulate all incoming packets of the data flow using the tunnel Flow ID corresponding to the mapped tunnel session. Similarly, Texit knows how to decapsulate the tunnel packets because it recognizes the mapped tunnel Flow ID based on information supplied during tunnel session preconfiguration.
図7は、トンネルの外側のエンドツーエンドのシグナルが受信機によって開始されたときのシグナル伝達シーケンスを示しています。最初のエンドツーエンドクエリメッセージを受信すると、TentryはトンネルQoS構成を調べ、次にクエリメッセージをTexitに更新およびトンネルします。Texitはクエリメッセージを脱カプセル化し、それを処理し、レシーバーに転送します。受信者は、Texitを通る予備のメッセージを送り返し、Texitに到着します。Tentryは、このドキュメントの範囲外の基準に基づいて、このエンドツーエンドセッションのQoS要求を事前に設定されたトンネルセッションにマッピングできるかどうか、および方法を決定します。次に、テントリーは予備のメッセージを送信者に向けて転送します。信号は、応答メッセージがTentry、Texit、そして最後に受信機に到着するまで続きます。Tentryが受信した応答メッセージが全体的なシグナル伝達が成功していることを確認した場合、Tentryはマッピングされたトンネルセッションに対応するトンネルフローIDを使用して、データフローのすべての着信パケットをカプセル化し始めます。同様に、Texitは、トンネルセッションの事前設定中に提供された情報に基づいて、マッピングされたトンネルフローIDを認識するため、トンネルパケットを脱カプセル化する方法を知っています。
Since separate tunnel QoS signaling is not involved in preconfigured QoS tunnels, Figures 6 and 7 make the tunnel look like a single virtual link. The signaling path simply skips all tunnel intermediate nodes. However, both Tentry and Texit need to deploy the NSIS-tunnel-related functionalities described above, including acting on the end-to-end NSIS signaling messages based on tunnel QoS status, mapping end-to-end and tunnel QoS sessions, and correctly encapsulating and decapsulating tunnel packets according to the tunnel protocol and the configured tunnel Flow ID.
個別のトンネルQoSシグナルは、事前に設定されたQoSトンネルには関与していないため、図6と7はトンネルを単一の仮想リンクのように見せます。シグナリングパスは、すべてのトンネル中間ノードをスキップするだけです。ただし、TentryとTexitの両方は、トンネルQoSステータスに基づいたエンドツーエンドNSISシグナリングメッセージ、エンドツーエンド、トンネルQoSセッションのマッピング、および正確に、上記のNSISトンネル関連の機能を展開する必要があります。トンネルプロトコルと構成されたトンネルフローIDに従って、トンネルパケットのカプセル化と脱カプセル化。
Sender Tentry Tmid Texit Receiver
| | | | |
| QUERY | | | |
+------------->| | | |
| | QUERY | |
| +---------------------------->| |
| | | | QUERY |
| | | +------------->|
| | | | RESERVE |
| | | |<-------------+
| | RESERVE | |
| |<----------------------------+ |
| RESERVE | | | |
|<-------------+ | | |
| RESPONSE | | | |
+------------->| | | |
| | RESPONSE | |
| +---------------------------->| |
| | | | RESPONSE |
| | | +------------->|
| | | | |
| | | | |
Figure 7: Receiver-Initiated End-to-End Session with Preconfigured Tunnel QoS Sessions
図7：事前に設定されたトンネルQoSセッションを使用したレシーバー開始エンドツーエンドセッション
When there are no preconfigured tunnel QoS sessions, a tunnel can apply the same NSIS QoS signaling mechanism used for the end-to-end path to manage the QoS inside the tunnel. The tunnel NSIS signaling involves only those NSIS nodes in the tunnel forwarding path. The Flow IDs for the tunnel signaling are based on tunnel header fields. NSIS peer discovery messages inside the tunnel distinguish themselves using the tunnel header fields, which solves the problem for tunnel intermediate NSIS nodes to intercept signaling messages.
事前に構成されたトンネルQoSセッションがない場合、トンネルは、エンドツーエンドパスに使用される同じNSIS QoSシグナル伝達メカニズムを適用して、トンネル内のQoSを管理できます。トンネルNSISシグナル伝達には、トンネル転送パス内のNSISノードのみが含まれます。トンネルシグナリングのフローIDは、トンネルヘッダーフィールドに基づいています。トンネル内のNSISピアディスカバリーメッセージは、トンネルヘッダーフィールドを使用して自分自身を区別します。これにより、トンネル中間NSISノードがシグナル伝達メッセージを傍受する問題が解決します。
When tunnel endpoints dynamically create tunnel QoS sessions, the initiation mode of the tunnel session always follows the initiation mode of the end-to-end session. Specifically, when the end-to-end session is sender-initiated, the tunnel session should also be sender-initiated; when the end-to-end session is receiver-initiated, the tunnel session should also be receiver-initiated.
トンネルのエンドポイントがトンネルQoSセッションを動的に作成する場合、トンネルセッションの開始モードは常にエンドツーエンドセッションの開始モードに従います。具体的には、エンドツーエンドのセッションが送信者開始の場合、トンネルセッションも送信者開始である必要があります。エンドツーエンドのセッションが受信機が開始する場合、トンネルセッションも受信機が開始する必要があります。
The tunnel entry-point conveys the corresponding tunnel Flow ID associated with an end-to-end session to the tunnel exit-point during the tunnel signaling process. The tunnel entry-point also informs the exit-point of the binding between the corresponding tunnel session and end-to-end session through the BOUND_SESSION_ID QoS NSLP message object. The reservation message dependencies between the tunnel session and end-to-end session are resolved using the MSG-ID and BOUND-MSG-ID objects of the QoS NSLP message binding mechanism.
トンネルエントリポイントは、トンネルシグナリングプロセス中にトンネル出口ポイントへのエンドツーエンドセッションに関連する対応するトンネルフローIDを伝えます。トンネルの入力ポイントは、Bound_Session_ID QOS NSLPメッセージオブジェクトを介して、対応するトンネルセッションとエンドツーエンドセッションの間のバインディングの出口点にも通知します。トンネルセッションとエンドツーエンドセッションの間の予約メッセージ依存関係は、QoS NSLPメッセージバインディングメカニズムのMSG-IDおよびBound-MSG-IDオブジェクトを使用して解決されます。
Figure 8 shows the typical messaging sequence of how NSIS operates over IP tunnels when both the end-to-end session and tunnel session are sender-initiated. Tunnel signaling messages are distinguished from end-to-end messages by a prime symbol after the message name. The sender first sends an end-to-end RESERVE message (1) that arrives at Tentry. Tentry chooses the tunnel Flow ID, creates the tunnel session, and associates the end-to-end session with the tunnel session. Tentry then sends a tunnel RESERVE' message (2) matching the request of the end-to-end session towards Texit to reserve tunnel resources. This RESERVE' message (2) includes a MSG-ID object that contains a randomly generated 128-bit MSG-ID. Meanwhile, Tentry inserts a BOUND-MSG-ID object containing the same MSG-ID as well as a BOUND-SESSION-ID object containing the SESSION-ID of the tunnel session into the original RESERVE message, and sends this RESERVE message (3) towards Texit using normal tunnel encapsulation. The Message_Binding_Type flags of both the MSG-ID and BOUND-MSG-ID objects in the RESERVE' and RESERVE messages (2, 3) are SET, indicating a bidirectional binding. The tunnel RESERVE' message (2) 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 (3) passes through the tunnel intermediate nodes (Tmid) just like other tunneled packets. These two messages could arrive at Texit in different orders, and the reaction of Texit in these different situations should combine the tunnel QoS message processing rules with the QoS NSLP processing principles for message binding [RFC5974], as illustrated below.
図8は、エンドツーエンドのセッションとトンネルセッションの両方が送信者開始である場合、NSIがIPトンネルで動作する方法の典型的なメッセージングシーケンスを示しています。トンネル信号メッセージは、メッセージ名の後にプライムシンボルによってエンドツーエンドのメッセージと区別されます。送信者は、最初にテントリーに到着するエンドツーエンドの予備メッセージ（1）を送信します。TentryはトンネルフローIDを選択し、トンネルセッションを作成し、エンドツーエンドセッションをトンネルセッションと関連付けます。その後、Tentryはトンネル保護区のメッセージ（2）を送信し、エンドツーエンドセッションの要求に合わせてTexitに向けてトンネルリソースを予約します。このリザーブメッセージ（2）には、ランダムに生成された128ビットMSG-IDを含むMSG-IDオブジェクトが含まれています。一方、Tentryは、同じMSG-IDを含むBound-MSG-IDオブジェクトと、トンネルセッションのセッションIDを元の予備メッセージに含むバウンドセッションIDオブジェクトを挿入し、この予備メッセージ（3）を送信します通常のトンネルカプセル化を使用してTexitに向かって。リザーブおよびリザーブメッセージ（2、3）内のMSG-IDとBound-MSG-IDオブジェクトの両方のメッセージ_Binding_Typeフラグが設定されており、双方向の結合を示しています。トンネルリザーブメッセージ（2）は、選択したトンネルフローIDによって識別されたフローのトンネル内でホップバイホップを処理し、エンドツーエンドの予備メッセージ（3）はトンネル中間ノード（TMID）を通過します他のトンネルパケットのように。これらの2つのメッセージは異なる順序でTexitに到達する可能性があり、これらのさまざまな状況でのTexitの反応は、以下に示すように、メッセージバインディングのためのQoS NSLP処理原則[RFC5974]とトンネルQoSメッセージ処理ルールを組み合わせる必要があります。
The first possibility is shown in the example messaging flow of Figure 8, where the tunnel RESERVE' message (2), also known as the triggering message in QoS NSLP message binding terms, arrives first. Since the message binding is bidirectional, Texit records the MSG-ID of the RESERVE' message (2), enqueues it and starts a MsgIDWait timer waiting for the end-to-end RESERVE message (3), also known as the bound signaling message in QoS NSLP message binding terms. The timer Sender Tentry Tmid Texit Receiver
最初の可能性は、QoS NSLPメッセージバインディング用語のトリガーメッセージとしても知られるトンネルリザーブのメッセージ（2）が最初に到着する図8のメッセージングフローの例に示されています。メッセージのバインディングは双方向であるため、Texitは予備のメッセージ（2）のMSG-IDを記録し、それをenqueし、バウンドシグナリングメッセージとしても知られるエンドツーエンドリザーブメッセージ（3）を待っているMSGIDWAITタイマーを起動しますQOS NSLPメッセージバインディング用語。タイマー送信者Tentry tmid texitレシーバー
| | | | |
| RESERVE(1) | | | |
+------------->| | | |
| | RESERVE'(2) | | |
| +=============>| | |
| | | RESERVE'(2) | |
| | +=============>| |
| | RESERVE(3) | |
| +---------------------------->| |
| | | RESPONSE'(4) | |
| | |<=============+ |
| | RESPONSE'(4) | | |
| |<=============+ | |
| | | | RESERVE(5) |
| | | +------------->|
| | | | RESPONSE(6) |
| | | |<-------------+
| | RESPONSE(6) | |
| |<----------------------------+ |
| RESPONSE(6) | | | |
|<-------------+ | | |
| | | | |
| | | | |
(1,5): RESERVE w/o BOUND-MSG-ID and BOUND-SESSION-ID
(2): RESERVE' w/ MSG-ID
(3): RESERVE w/ BOUND-MSG-ID and BOUND-SESSION-ID
Figure 8: Sender-Initiated Reservation for Both End-to-End and Tunnel Signaling
図8：エンドツーエンドとトンネルシグナリングの両方の送信者が開始する予約
value is set to the default retransmission timeout period QOSNSLP_REQUEST_RETRY. When the end-to-end RESERVE message (3) arrives, Texit notices that there is an existing stored MSG-ID which matches the MSG-ID in the BOUND-MSG-ID object of the incoming RESERVE message (3). Therefore, the message binding condition has been satisfied. Texit resumes processing of the tunnel RESERVE' message (2), creates the reservation state for the tunnel session, and sends a tunnel RESPONSE' message (4) to Tentry. At the same time, Texit checks the BOUND-SESSION-ID object of the end-to-end RESERVE message (3) and records the binding of the corresponding tunnel session with the end-to-end session. Texit also updates the end-to-end RESERVE message based on the result of the tunnel session reservation, removes its tunnel BOUND-SESSION-ID and BOUND-MSG-ID object and forwards the end-to-end RESERVE message (5) along the path towards the receiver. When the receiver receives the end-to-end RESERVE message (5), it sends an end-to-end RESPONSE message (6) back to the sender.
値は、デフォルトの再送信タイムアウト期間に設定されていますQOSNSLP_REQUEST_RETRY。エンドツーエンドリザーブメッセージ（3）が到着すると、Texitは、着信予備メッセージのバウンドMSG-IDオブジェクトのMSG-IDに一致する既存の保存されたMSG-IDがあることに気付きます（3）。したがって、メッセージ結合条件が満たされています。Texitは、トンネルリザーブのメッセージ（2）の処理を再開し、トンネルセッションの予約状態を作成し、トンネル応答「メッセージ（4）をテントリーに送信します。同時に、Texitはエンドツーエンドの予備メッセージ（3）のバウンドセッションIDオブジェクトをチェックし、対応するトンネルセッションのエンドツーエンドセッションの結合を記録します。Texitはまた、トンネルセッションの予約の結果に基づいてエンドツーエンドの予備メッセージを更新し、トンネルバウンドセッションIDとバウンドMSG-IDオブジェクトを削除し、エンドツーエンドの予備メッセージ（5）を転送します受信機への道。受信者がエンドツーエンドの予備メッセージ（5）を受信すると、エンドツーエンドの応答メッセージ（6）を送信者に送り返します。
The second possibility is that the end-to-end RESERVE message arrives before the tunnel RESERVE' message at Texit. In that case, Texit notices a BOUND-SESSION-ID object and a BOUND-MSG-ID object in the end-to-end RESERVE message, but realizes that the tunnel session does not exist yet. So, Texit enqueues the RESERVE message and starts a MsgIDWait timer. The timer value is set to the default retransmission timeout period QOSNSLP_REQUEST_RETRY. When the corresponding tunnel RESERVE' message arrives with a MSG-ID matching that of the outstanding BOUND-MSG-ID object, the message binding condition is satisfied. Texit sends a tunnel RESPONSE' message back to Tentry and updates the end-to-end RESERVE message by incorporating the result of the tunnel session reservation, as well as removing the tunnel BOUND-SESSION-ID and BOUND-MSG-ID objects. Texit then forwards the end-to-end RESERVE message along the path towards the receiver. When the receiver receives the end-to-end RESERVE message, it sends an end-to-end RESPONSE message back to the sender.
2番目の可能性は、エンドツーエンドの予備メッセージがTexitでのトンネルリザーブのメッセージの前に到着することです。その場合、Texitは、エンドツーエンドの予備メッセージにBoundsession-IDオブジェクトとBound-MSG-IDオブジェクトに気付きますが、トンネルセッションがまだ存在しないことを認識しています。したがって、Texitは予備のメッセージをエンキューし、MSGIDWAITタイマーを起動します。タイマー値は、デフォルトの再送信タイムアウト期間QOSNSLP_REQUEST_RETRYに設定されます。対応するトンネル保護区のメッセージが、未解決のBound-MSG-IDオブジェクトのそれと一致するMSG-IDで到着すると、メッセージバインディング条件が満たされます。Texitは、トンネルセッションの予約の結果を組み込んだり、トンネルバウンドセッションIDおよびバウンドMSG-IDオブジェクトを削除したりすることにより、トンネルの応答のメッセージをテントリーに送り返し、エンドツーエンドの予備メッセージを更新します。Texitは、レシーバーに向かってパスに沿ってエンドツーエンドの予備メッセージを転送します。受信者がエンドツーエンドの予備メッセージを受信すると、エンドツーエンドの応答メッセージを送信者に送り返します。
Yet another possibility is that the tunnel RESERVE' message arrives at Texit first, but the end-to-end RESERVE message never arrives. In that case, the MsgIDWait timer for the queued tunnel RESERVE' message will expire. Texit should then send a tunnel RESPONSE' message back to Tentry indicating a reservation error has occurred, and discard the tunnel RESERVE' message. The last possibility is that the end-to-end RESERVE message arrives at Texit first, but the tunnel RESERVE' message never arrives. In that case, the MsgIDWait timer for the queued end-to-end RESERVE message will expire. Texit should then treat this situation as a local reservation failure, and according to [RFC5974], Texit as a stateful QoS NSLP should generate an end-to-end RESPONSE message indicating RESERVE error to the sender.
さらに別の可能性は、トンネルリザーブのメッセージが最初にTexitに到着することですが、エンドツーエンドの予備のメッセージは決して到着しません。その場合、キューに登録されたトンネルリザーブのMSGIDWAITタイマーのメッセージが期限切れになります。Texitは、トンネル応答の「テントリーへのメッセージ」を送信して、予約エラーが発生したことを示し、トンネル保護区のメッセージを破棄します。最後の可能性は、エンドツーエンドのリザーブメッセージが最初にTexitに到着することですが、トンネル保護区のメッセージは決して到着しません。その場合、キューに囲まれたエンドツーエンドリザーブメッセージのMSGIDWAITタイマーが期限切れになります。Texitはこの状況を現地の予約の失敗として扱う必要があり、[RFC5974]によると、Texitは、ステートフルQoS NSLPとして、送信者への予備誤差を示すエンドツーエンドの応答メッセージを生成するはずです。
Once the end-to-end and the tunnel QoS session have both been successfully created and associated, the tunnel endpoints Tentry and Texit coordinate the signaling between the two sessions and make sure that adjustment or teardown of either session may trigger similar actions for the other session as necessary, by invoking appropriate signaling messages.
エンドツーエンドとトンネルQoSセッションの両方が正常に作成され、関連すると、トンネルエンドポイントテントリーとテキシットは、2つのセッション間のシグナリングを調整し、いずれかのセッションの調整または分解が他のセッションの同様のアクションをトリガーする可能性があることを確認してください。適切なシグナリングメッセージを呼び出すことにより、必要に応じてセッション。
Figure 9 shows the typical messaging sequence of how NSIS signaling
operates over IP tunnels when both end-to-end and tunnel sessions are
receiver-initiated. Upon receiving an end-to-end QUERY message (1)
from the sender, Tentry chooses the tunnel Flow ID and sends a tunnel
Sender Tentry Tmid Texit Receiver
| | | | |
| QUERY(1) | | | |
+------------->| | | |
| | QUERY'(2) | | |
| +=============>| | |
| | | QUERY'(2) | |
| | +=============>| |
| | | RESPONSE'(3) | |
| | |<=============+ |
| | RESPONSE'(3) | | |
| |<=============+ | |
| | QUERY(4) | |
| +---------------------------->| |
| | | | QUERY(5) |
| | | +------------->|
| | | | RESERVE(6) |
| | | |<-------------+
| | | RESERVE'(7) | |
| | |<=============+ |
| | RESERVE'(7) | | |
| |<=============+ | |
| | RESERVE(8) | |
| |<----------------------------+ |
| | RESPONSE'(9) | | |
| +=============>| | |
| | | RESPONSE'(9) | |
| | +=============>| |
| RESERVE(10) | | | |
|<-------------+ | | |
| RESPONSE(11) | | | |
+------------->| | | |
| | RESPONSE(11) | |
| +---------------------------->| |
| | | | RESPONSE(11) |
| | | +------------->|
| | | | |
| | | | |
(1), (5): QUERY w/ RESERVE-INIT
(2): QUERY' w/ RII
(4): QUERY w/ RESERVE-INIT and BOUND-SESSION-ID
(6), (10): RESERVE w/o BOUND-SESSION-ID
(7): RESERVE' w/ MSG-ID
(8): RESERVE w/ BOUND-MSG-ID and BOUND-SESSION-ID
Figure 9: Receiver-Initiated Reservation for Both End-to-end and Tunnel Signaling
図9：エンドツーエンドとトンネルシグナリングの両方のレシーバーが開始する予約
QUERY' message (2) matching the request of the end-to-end session towards Texit. This tunnel QUERY' message (2) is meant to discover QoS characteristics of the tunnel path, rather than initiate an actual reservation. Therefore, it includes a Request Identification Information (RII) object but does not set the RESERVE-INIT flag. The tunnel QUERY' message (2) is processed hop-by-hop inside the tunnel for the flow identified by the tunnel Flow ID. When Texit receives this tunnel QUERY' message (2), it replies with a corresponding tunnel RESPONSE' message (3) containing the tunnel path characteristics. After receiving the tunnel RESPONSE' message (3), Tentry creates the tunnel session, generates an outgoing end-to-end QUERY message (4) considering the tunnel path characteristics, appends a tunnel BOUND-SESSION-ID object containing the tunnel SESSION-ID, and sends it toward Texit using normal tunnel encapsulation. The end-to-end QUERY message (4) passes along tunnel intermediate nodes like other tunneled packets. Upon receiving this end-to-end QUERY message (4), Texit notices the tunnel session binding, creates the tunnel session state, removes the tunnel BOUND-SESSION-ID object, and forwards the end-to-end QUERY message (5) further along the path.
Query 'メッセージ（2）Texitへのエンドツーエンドセッションの要求と一致します。このトンネルクエリ「メッセージ（2）は、実際の予約を開始するのではなく、トンネルパスのQoS特性を発見することを目的としています。したがって、リクエスト識別情報（RII）オブジェクトが含まれていますが、リザーブINITフラグを設定しません。トンネルクエリ「メッセージ（2）は、トンネルフローIDによって識別されたフローのトンネル内のホップバイホップで処理されます。Texitがこのトンネルクエリのメッセージ（2）を受信すると、トンネルパスの特性を含む対応するトンネル応答 'メッセージ（3）で応答します。トンネルの応答 'メッセージ（3）を受信した後、Tentryはトンネルセッションを作成し、トンネルパスの特性を考慮して発信エンドツーエンドクエリメッセージ（4）を生成し、トンネルのバウンドセッションIDオブジェクトを追加します。ID、および通常のトンネルカプセル化を使用してTexitに向かって送信します。エンドツーエンドクエリメッセージ（4）は、他のトンネルパケットのようにトンネル中間ノードに沿って渡されます。このエンドツーエンドのクエリメッセージ（4）を受信すると、Texitはトンネルセッションのバインディングに気付き、トンネルセッション状態を作成し、トンネルバウンドセッションIDオブジェクトを削除し、エンドツーエンドクエリメッセージ（5）を転送しますさらにパスに沿って。
The end-to-end QUERY message (5) arrives at the receiver and triggers a RESERVE message (6). When Texit receives the RESERVE message (6), it notices that the session is bound to a receiver-initiated tunnel session. Therefore, Texit triggers a RESERVE' message (7) toward Tentry for the tunnel session reservation. This tunnel RESERVE' message (7) includes a randomly generated 128-bit MSG-ID. Meanwhile, Texit inserts a BOUND-MSG-ID object containing the same MSG-ID and a BOUND-SESSION-ID object containing the tunnel SESSION-ID into the end-to-end RESERVE message (8), and sends it towards Tentry using normal tunnel encapsulation. The Message_Binding_Type flags of the MSG-ID and BOUND-MSG-ID objects in the RESERVE' and RESERVE messages (7,8) are SET, indicating a bidirectional binding.
エンドツーエンドのクエリメッセージ（5）はレシーバーに到着し、予備のメッセージ（6）をトリガーします。Texitが予備のメッセージ（6）を受信すると、セッションが受信機が開始するトンネルセッションに拘束されていることに気付きます。したがって、Texitは、トンネルセッションの予約のために、予備の 'メッセージ（7）をテントリーにトリガーします。このトンネルリザーブメッセージ（7）には、ランダムに生成された128ビットMSG-IDが含まれています。一方、Texitは、同じMSG-IDを含むバウンドMSG-IDオブジェクトと、トンネルセッションIDをエンドツーエンドリザーブメッセージ（8）に含むバウンドセッションIDオブジェクトを挿入し、それを使用してテントリーに送信します通常のトンネルのカプセル化。予備のMSG-IDおよびバウンドMSG-IDオブジェクトのMessage_binding_typeフラグは、予備の 'および予備のメッセージ（7,8）に設定されており、双方向の結合を示しています。
At Tentry, the tunnel RESERVE' message (7) and the end-to-end RESERVE message (8) could arrive in either order. In a typical case shown in Figure 9, the tunnel RESERVE' message (7) arrives first. Tentry then records the MSG-ID of the tunnel RESERVE' message (7) and starts a MsgIDWait timer. When the end-to-end RESERVE message (8) with the BOUND-MSG-ID object containing the same MSG-ID arrives, the message binding condition is satisfied. Tentry resumes processing of the tunnel RESERVE' message (7), creates the reservation state for the tunnel session, and sends a tunnel RESPONSE' message (9) to Texit. At the same time, Tentry creates the outgoing end-to-end RESERVE message (10) by incorporating results of the tunnel session reservation and removing the BOUND-SESSION-ID and BOUND-MSG-ID objects, and forwards it along the path towards the sender. When the sender receives the end-to-end RESERVE message (10), it sends an end-to-end RESPONSE message (11) back to the receiver.
Tentryでは、トンネル保護区のメッセージ（7）とエンドツーエンドの予備メッセージ（8）がいずれかの順序で到着できます。図9に示す典型的なケースでは、トンネルリザーブのメッセージ（7）が最初に到着します。その後、TentryはTunnel Reserve 'Message（7）のMSG-IDを記録し、MSGIDWAITタイマーを開始します。同じMSG-IDを含むBound-MSG-IDオブジェクトを使用したエンドツーエンドの予備メッセージ（8）が到着すると、メッセージバインディング条件が満たされます。Tentryは、トンネルリザーブのメッセージ（7）の処理を再開し、トンネルセッションの予約状態を作成し、トンネル応答「メッセージ（9）をTexitに送信します。同時に、Tentryは、トンネルセッションの予約の結果を組み込み、Bound-Session-IDとBound-MSG-IDオブジェクトを削除することにより、発信エンドツーエンドの予備メッセージ（10）を作成し、パスに沿って転送します。送り主。送信者がエンドツーエンドのリザーブメッセージ（10）を受信すると、エンドツーエンドの応答メッセージ（11）を受信機に送り返します。
If the end-to-end RESERVE message arrives before the tunnel RESERVE' message at Tentry, or either of the two messages fails to arrive at Tentry, the processing rules at Tentry are similar to those of Texit in the situation discussed in Section 6.1.
トンネルリザーブのテントリーでのメッセージの前にエンドツーエンドの予備のメッセージが届く場合、または2つのメッセージのいずれかがテントリーに到達できない場合、テントリーの処理ルールは、セクション6.1で説明されている状況でTexitの処理と類似しています。
Once the end-to-end and the tunnel QoS session have both been successfully created and associated, the tunnel endpoints Tentry and Texit coordinate the signaling between the two sessions and make sure that adjustment or teardown of either session can trigger similar actions for the other session as necessary, by invoking appropriate signaling messages.
エンドツーエンドとトンネルQoSセッションの両方が正常に作成され、関連すると、トンネルエンドポイントテントリーとテキシットは、2つのセッション間のシグナリングを調整し、いずれかのセッションの調整または分解が他のセッションの同様のアクションをトリガーできることを確認します。適切なシグナリングメッセージを呼び出すことにより、必要に応じてセッション。
The mechanism of NSIS operating over IP tunnels requires the coordination of both tunnel endpoints in tasks such as special encapsulation and decapsulation of data flow packets according to the chosen tunnel Flow ID, as well as the possible creation and adjustment of the end-to-end and tunnel QoS sessions. Therefore, one NSIS-tunnel-aware endpoint needs to know that the other tunnel endpoint is also NSIS-tunnel-aware before initiating this mechanism of NSIS operating over IP tunnels. In some cases, especially for IP tunnels with preconfigured QoS sessions, an NSIS-tunnel-aware endpoint can learn about whether the other tunnel endpoint is also NSIS-tunnel-aware through preconfiguration. In other cases where such preconfiguration is not available, the initiating NSIS-tunnel-aware endpoint may dynamically discover the other tunnel endpoint's capability through a QoS NSLP NODE_CAPABILITY_TUNNEL object defined in this section.
IPトンネルを介して動作するNSIのメカニズムには、選択したトンネルフローIDに従ってデータフローパケットの特別なカプセル化や脱カプセル化などのタスクで、両方のトンネルエンドポイントの調整が必要です。トンネルQoSセッション。したがって、1つのNSIS-Tunnel-Awareエンドポイントは、IPトンネルを介して動作するNSISのこのメカニズムを開始する前に、他のトンネルエンドポイントもNSIS-Tunnel-Awareであることを知る必要があります。場合によっては、特に事前に設定されたQoSセッションを備えたIPトンネルの場合、NSIS-Tunnelに認識されたエンドポイントは、他のトンネルエンドポイントが事前設定を通じてNSIS-Tunnel-Awareでもあるかどうかを学ぶことができます。このような事前設定が利用できない他のケースでは、NSIS-Tunnel-Awareのエンドポイントを開始すると、このセクションで定義されているQoS NSLP node_capability_tunnelオブジェクトを介して、他のトンネルエンドポイントの機能を動的に発見できます。
The NODE_CAPABILITY_TUNNEL object is a zero-length object with a standard NSLP object header as shown in Figure 10.
node_capability_tunnelオブジェクトは、図10に示すように、標準のNSLPオブジェクトヘッダーを備えたゼロ長オブジェクトです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|B|r|r| Type |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: NODE_CAPABILITY_TUNNEL Object Format
図10：node_capability_tunnelオブジェクト形式
Type: NODE_CAPABILITY_TUNNEL (0x015) from the shared NSLP object type space Length: 0
タイプ：共有NSLPオブジェクトタイプのスペース長からnode_capability_tunnel（0x015）
The bits marked 'A' and 'B' define the desired behavior for objects whose Type field is not recognized. If a node does not recognize the NODE_CAPABILITY_TUNNEL object, the desired behavior is "Forward". That is, the object must be retained unchanged and forwarded as a result of message processing. This is satisfied by setting 'AB' to '10'.
「A」と「B」とマークされたビットは、タイプフィールドが認識されていないオブジェクトの目的の動作を定義します。ノードがnode_capability_tunnelオブジェクトを認識しない場合、目的の動作は「フォワード」です。つまり、メッセージ処理の結果としてオブジェクトを変更せずに保持し、転送する必要があります。これは、「ab」を「10」に設定することで満たされます。
The 'r' bit stands for 'reserved'.
「r」ビットは「予約済み」の略です。
The NODE_CAPABILITY_TUNNEL object is included in a tunnel QUERY' or RESERVE' message by a tunnel endpoint that needs to learn about the other endpoint's capability for NSIS tunnel handling. If the receiving tunnel endpoint is indeed NSIS-tunnel-aware, it recognizes this object and knows that the sending endpoint is NSIS-tunnel-aware. The receiving tunnel endpoint places the same object in a tunnel RESPONSE' message to inform the sending endpoint that it is also NSIS-tunnel-aware. The use of the NODE_CAPABILITY_TUNNEL object in the cases of sender-initiated reservation and receiver-initiated reservation are as follows.
node_capability_tunnelオブジェクトは、NSISトンネルハンドリングの他のエンドポイントの機能について学習する必要があるトンネルエンドポイントによるトンネルクエリまたは予備のメッセージに含まれています。受信トンネルエンドポイントが実際にNSIS-Tunnel-Awareである場合、このオブジェクトを認識し、送信エンドポイントがNSIS-Tunnel-Awareであることを知っています。受信トンネルエンドポイントは、同じオブジェクトをトンネル応答に配置し、送信エンドポイントにNSIS-Tunnel-Awareでもあることを通知します。送信者開始予約および受信機が開始する予約の場合におけるnode_capability_tunnelオブジェクトの使用は次のとおりです。
First, assume that the end-to-end session is sender-initiated as in Figure 8, and the NSIS-tunnel-aware Tentry wants to discover the NSIS tunnel capability of Texit. After receiving the first end-to-end RESERVE message (1), Tentry inserts an RII object and a NODE_CAPABILITY_TUNNEL object into the tunnel RESERVE' message (2) and sends it to Texit. If Texit is NSIS-tunnel-aware, it learns from the NODE_CAPABILITY_TUNNEL object that Tentry is also NSIS-tunnel-aware and includes the same object into the tunnel RESPONSE' message (4) sent back to Tentry.
まず、図8のようにエンドツーエンドのセッションが送信者によって開始され、NSIS-Tunnel-Aware TentryがTexitのNSISトンネル能力を発見したいと考えています。最初のエンドツーエンドリザーブメッセージ（1）を受信した後、TentryはRIIオブジェクトとnode_capability_tunnelオブジェクトをトンネルリザーブ 'メッセージ（2）に挿入し、texitに送信します。TexitがNSIS-Tunnel-Awareである場合、Node_capability_tunnelオブジェクトからTentryもNSIS-Tunnel-Awareであり、トンネル応答に同じオブジェクトを含めてテントリーに送信されるメッセージ（4）が含まれていることがわかります。
Second, assume that the end-to-end session is receiver-initiated as in Figure 9, and the NSIS-tunnel-aware Tentry wants to discover the NSIS tunnel capability of Texit. Upon receiving the first end-to-end QUERY message (1), Tentry inserts an RII object and a NODE_CAPABILITY_TUNNEL object in the tunnel QUERY' message (2) and sends it toward Texit. If Texit is NSIS-tunnel-aware, it learns from the NODE_CAPABILITY_TUNNEL object that Tentry is also NSIS-tunnel-aware and includes the same object tunnel RESPONSE' message (3) sent to Tentry.
第二に、図9のようにエンドツーエンドのセッションが受信機が開始され、NSIS-Tunnel-Aware TentryがTexitのNSISトンネル機能を発見したいと考えています。最初のエンドツーエンドクエリメッセージ（1）を受信すると、TentryはTunnel Query 'メッセージ（2）にRIIオブジェクトとnode_capability_tunnelオブジェクトを挿入し、texitに送信します。TexitがNSIS-Tunnel-Awareである場合、Node_Capability_TunnelオブジェクトからTentryもNSIS-Tunnel-Awareであり、同じオブジェクトトンネル応答 'メッセージ（3）がTentryに送信されることを学習します。
This document defines a new object type called NODE_CAPABILITY_TUNNEL for QoS NSLP. Its Type value (0x015) has been assigned by IANA. The object format and the setting of the extensibility bits are defined in Section 7.
このドキュメントでは、QOS NSLPのnode_capability_tunnelという新しいオブジェクトタイプを定義します。そのタイプ値（0x015）はIANAによって割り当てられています。オブジェクト形式と拡張性ビットの設定は、セクション7で定義されています。
This NSIS and IP tunnel interoperation mechanism has two IPsec-related security implications. First, NSIS messages may require per-hop processing within the IPsec tunnel, and that is potentially incompatible with IPsec. A similar problem exists for RSVP interacting with IPsec, when the Router Alert option is used (Appendix A.1 of RFC 4302 [RFC4302]). If this mechanism is indeed used for NSIS and IPsec tunnels, a so-called covert channel could exist where someone can create spurious NSIS signaling flows within the protected network in order to create signaling in the outside network, which then someone else is monitoring. For highly secure networks, this would be seen as a way to smuggle information out of the network, and therefore this channel will need to be rate-limited. A similar covert channel rate-limit problem exists for using Differentiated Services (DS) or Explicit Congestion Notification (ECN) fields with IPsec (Section 5.1.2 of RFC 4301 [RFC4301]).
このNSISおよびIPトンネル相互操作メカニズムには、2つのIPSEC関連のセキュリティへの影響があります。まず、NSISメッセージはIPSECトンネル内でホップごとの処理を必要とする場合があり、IPSECと互換性がない可能性があります。ルーターアラートオプションを使用する場合、IPSECと相互作用するRSVPにも同様の問題が存在します（RFC 4302 [RFC4302]の付録A.1）。このメカニズムが実際にNSISおよびIPSECトンネルに使用されている場合、誰かが外部ネットワークにシグナリングを作成し、他の誰かが監視しているために、誰かが保護されたネットワーク内でスプリアスなNSISシグナリングフローを作成できるいわゆる隠れたチャネルが存在する可能性があります。非常に安全なネットワークの場合、これはネットワークから情報を密輸する方法と見なされるため、このチャネルはレート制限する必要があります。同様の秘密のチャネルレートリミット問題は、差別化されたサービス（DS）またはIPSECを使用した明示的な混雑通知（ECN）フィールドを使用するために存在します（RFC 4301 [RFC4301]のセクション5.1.2）。
Second, since the NSIS-tunnel-aware endpoint is responsible for adapting changes between the NSIS signaling both inside and outside the tunnel, there could be additional risks for an IPsec endpoint that is also an NSIS-tunnel-aware endpoint. For example, security vulnerability (e.g., buffer overflow) on the NSIS stack of that IPsec tunnel endpoint may be exposed to the unprotected outside network. Nevertheless, it should also be noted that if any node along the signaling path is compromised, the whole end-to-end QoS signaling could be affected, whether or not the end-to-end path includes an IPsec tunnel.
第二に、NSIS-Tunnel-Awareのエンドポイントは、トンネルの内側と外側の両方でNSISシグナリング間の変化を適応させる責任があるため、NSIS-Tunnel-AwareエンドポイントであるIPSECエンドポイントに追加のリスクがある可能性があります。たとえば、IPSECトンネルエンドポイントのNSISスタックのセキュリティの脆弱性（バッファオーバーフローなど）は、保護されていない外部ネットワークにさらされる場合があります。それにもかかわらず、シグナリングパスに沿ったノードが侵害された場合、エンドツーエンドのパスにIPSECトンネルが含まれるかどうかにかかわらず、エンドツーエンドのQoSシグナリング全体が影響を受ける可能性があることにも注意する必要があります。
Several other documents discuss security issues for NSIS. General threats for NSIS can be found in [RFC4081]. Security considerations for NSIS NTLP and QoS NSLP are discussed in [RFC5971] and [RFC5974], respectively.
他のいくつかの文書は、NSIのセキュリティ問題について説明しています。NSIの一般的な脅威は[RFC4081]に記載されています。NSIS NTLPおよびQOS NSLPのセキュリティ上の考慮事項については、それぞれ[RFC5971]と[RFC5974]で説明しています。
The authors would like to thank Roland Bless, Francis Dupont, Lars Eggert, Adrian Farrel, Russ Housley, Georgios Karagiannis, Jukka Manner, Martin Rohricht, Peter Saint-Andre, Martin Stiemerling, Hannes Tschofenig, and other members of the NSIS working group for comments. Thanks to Yaron Sheffer for pointing out the IPsec-related security considerations.
著者は、ローランド・ブレッシング、フランシス・デュポン、ラース・エガート、エイドリアン・ファレル、ラス・ハウリー、ジョージオス・カラギアンニス、ジュッカ・マナー、マーティン・ローリヒト、ピーター・サンドレ、マーティン・スティメーリング、ハンヌ・ツェフニグ、および他のメンバーのメンバーに感謝します。コメント。IPSEC関連のセキュリティ上の考慮事項を指摘してくれたYaron Shefferに感謝します。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113] Katz、D。、「IPルーターアラートオプション」、RFC 2113、1997年2月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473] Conta、A。およびS. Deering、「IPv6仕様の一般的なパケットトンネル」、RFC 2473、1998年12月。
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[RFC2711] Partridge、C。およびA. Jackson、「IPv6ルーターアラートオプション」、RFC 2711、1999年10月。
[RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[RFC2746] Terzis、A.、Krawczyk、J.、Wroclawski、J.、およびL. Zhang、「RSVP Operation over IP Tunnels」、RFC 2746、2000年1月。
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004.
[RFC3697] Rajahalme、J.、Conta、A.、Carpenter、B。、およびS. Deering、「IPv6フローラベル仕様」、RFC 3697、2004年3月。
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005.
[RFC4080] Hancock、R.、Karagiannis、G.、Loughney、J。、およびS. van den Bosch、「シグナルの次のステップ（NSIS）：フレームワーク」、RFC 4080、2005年6月。
[RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
[RFC4081] Tschofenig、H。およびD. Kroeselberg、「シグナリングの次のステップ（NSIS）のセキュリティの脅威」、RFC 4081、2005年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月。
[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月。
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[RFC1701] Hanks、S.、Li、T.、Farinacci、D。、およびP. Traina、「ジェネリックルーティングカプセル化（GRE）」、RFC 1701、1994年10月。
[RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation over IPv4 networks", RFC 1702, October 1994.
[RFC1702] Hanks、S.、Li、T.、Farinacci、D。、およびP. Traina、「IPv4ネットワーク上の一般的なルーティングカプセル化」、RFC 1702、1994年10月。
[RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
[RFC1853] Simpson、W。、「IP In IP Tunneling」、RFC 1853、1995年10月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003] Perkins、C。、「IP内のIPカプセル化」、RFC 2003、1996年10月。
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[RFC2004] Perkins、C。、「IP内の最小カプセル化」、RFC 2004、1996年10月。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、B.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「一般的なルーティングカプセル化（GRE）」、RFC 2784、2000年3月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213] Nordmark、E。およびR. Gilligan、「IPv6ホストとルーターの基本的な遷移メカニズム」、RFC 4213、2005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロードのカプセル化（ESP）」、RFC 4303、2005年12月。
[RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010.
[RFC5944] Perkins、C.、ed。、「IPv4のIPモビリティサポート、改訂」、RFC 5944、2010年11月。
Authors' Addresses
著者のアドレス
Charles Shen Columbia University Department of Computer Science 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
チャールズシェンコロンビア大学コンピュータサイエンス学科1214アムステルダムアベニュー、MC 0401ニューヨーク、ニューヨーク10027 USA
Phone: +1 212 854 3109
EMail: charles@cs.columbia.edu
Henning Schulzrinne Columbia University Department of Computer Science 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
ヘニングシュルツリンヌコロンビア大学コンピュータサイエンス学科1214アムステルダムアベニュー、MC 0401ニューヨーク、ニューヨーク10027 USA
Phone: +1 212 939 7004
EMail: hgs@cs.columbia.edu
Sung-Hyuck Lee Convergence Technologies & Standardization Lab Samsung Information System America, INC. 95 West Plumeria Drive San Jose, CA 95134 USA
Sung-Hyuck Lee Convergence Technologies＆Standardization Lab Samsung Information System America、Inc。95West Plumeria Drive San Jose、CA 95134 USA
Phone: 1-408-544-5809 EMail: sung1.lee@samsung.com
電話：1-408-544-5809メール：sung1.lee@samsung.com
Jong Ho Bang SAMSUNG Advanced Institute of Technology San 14-1, Nongseo-ri, Giheung-eup Yongin-si, Gyeonggi-do 449-712 South Korea
ジョンホーバンサムスン高等技術研究所SAN 14-1、Nongseo-RI、Giheung-Eup Yongin-Si、Gyeonggi-Do 449-712 Korea
Phone: +82 31 280 9585
EMail: jh0278.bang@samsung.com