Network Working Group A. Terzis
Request for Comments: 2746 UCLA
Category: Standards Track J. Krawczyk
ArrowPoint Communications
J. Wroclawski
MIT LCS
L. Zhang
UCLA
January 2000
RSVP Operation Over IP Tunnels
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This document describes an approach for providing RSVP protocol services over IP tunnels. We briefly describe the problem, the characteristics of possible solutions, and the design goals of our approach. We then present the details of an implementation which meets our design goals.
この文書では、IPトンネル上のRSVPプロトコルサービスを提供するためのアプローチを説明しています。私たちは簡単に問題が、可能な解決策の特性、および我々のアプローチの設計目標を記述する。私たちは、その後、私たちの設計目標を満たしている実装の詳細を提示します。
IP-in-IP "tunnels" have become a widespread mechanism to transport datagrams in the Internet. Typically, a tunnel is used to route packets through portions of the network which do not directly implement the desired service (e.g. IPv6), or to augment and modify the behavior of the deployed routing architecture (e.g. multicast routing, mobile IP, Virtual Private Net).
IP・イン・IP「トンネルは」インターネットでデータグラムを輸送する広範な仕組みになっています。典型的に、トンネルは、例えば、マルチキャストルーティング、モバイルIP、仮想プライベートネット（直接所望のサービス（例えば、IPv6）を実装していない、または展開ルーティングアーキテクチャの挙動を増強し、修正するために、ネットワークの一部を介してパケットをルーティングするために使用され）。
Many IP-in-IP tunneling protocols exist today. [IP4INIP4] details a method of tunneling using an additional IPv4 header. [MINENC] describes a way to reduce the size of the "inner" IP header used in [IP4INIP4] when the original datagram is not fragmented. The generic tunneling method in [IPV6GEN] can be used to tunnel either IPv4 or IPv6 packets within IPv6. [RFC1933] describes how to tunnel IPv6
多くのIP-で-IPトンネリングプロトコルが今日存在します。 【IP4INIP4]追加のIPv4ヘッダを使用してトンネリングする方法を詳述します。 【MINENC】オリジナルデータグラムが断片化されていない場合[IP4INIP4]で使用される「内側」IPヘッダのサイズを小さくする方法が記載されています。 【IPV6GEN]におけるジェネリックトンネリング方法は、IPv6内のトンネルのIPv4またはIPv6パケットを使用することができます。 [RFC1933]はどのようにトンネルIPv6を説明します
datagrams through IPv4 networks. [RFC1701] describes a generic routing encapsulation, while [RFC1702] applies this encapsulation to IPv4. Finally, [ESP] describes a mechanism that can be used to tunnel an encrypted IP datagram.
IPv4ネットワークを通じてデータグラム。 [RFC1702]はIPv4のこのカプセル化を適用しながら、[RFC1701]は、総称ルーティングカプセル化を記載しています。最後に、[ESP]トンネルに暗号化されたIPデータグラムを使用することができる機構を記載しています。
From the perspective of traditional best-effort IP packet delivery, a tunnel behaves as any other link. Packets enter one end of the tunnel, and are delivered to the other end unless resource overload or error causes them to be lost.
従来のベストエフォート型のIPパケット配信の観点から、トンネルは他のリンクとして動作します。パケットは、トンネルの一端を入力し、リソースの過負荷やエラーはそれらが失われない限り、もう一方の端に配信されます。
The RSVP setup protocol [RFC2205] is one component of a framework designed to extend IP to support multiple, controlled classes of service over a wide variety of link-level technologies. To deploy this technology with maximum flexibility, it is desirable for tunnels to act as RSVP-controllable links within the network.
RSVPセットアッププロトコル[RFC2205]はリンクレベルの技術の広範囲にわたるサービスの複数の、制御されたクラスをサポートするためにIPを拡張するために設計された枠組みの一つの成分です。トンネルは、ネットワーク内のRSVP-制御可能なリンクとして機能するために最大限の柔軟性を持つこの技術を展開するには、それが望ましいです。
A tunnel, and in fact any sort of link, may participate in an RSVP-aware network in one of three ways, depending on the capabilities of the equipment from which the tunnel is constructed and the desires of the operator.
トンネル、およびリンクの実際に任意の並べ替えは、トンネルが構築された機器の機能と操作者の希望に応じて、3つの方法のいずれかでRSVPアウェアネットワークに参加することができます。
1. The (logical) link may not support resource reservation or QoS control at all. This is a best-effort link. We refer to this as a best-effort or type 1 tunnel in this note. 2. The (logical) link may be able to promise that some overall level of resources is available to carry traffic, but not to allocate resources specifically to individual data flows. A configured resource allocation over a tunnel is an example of this. We refer to this case as a type 2 tunnel in this note. 3. The (logical) link may be able to make reservations for individual end-to-end data flows. We refer to this case as a type 3 tunnel. Note that the key feature that distinguishes type 3 tunnels from type 2 tunnels is that in the type 3 tunnel new tunnel reservations are created and torn down dynamically as end-to-end reservations come and go.
1.（論理）リンクは、すべてのリソースの予約やQoS制御をサポートしていないかもしれません。これは、ベストエフォート型のリンクです。私たちは、このノートではベストエフォートまたはタイプ1のトンネルとしてこれを参照してください。 2.（論理）リンクは、リソースの一部全体のレベルがトラフィックを運ぶために利用可能であることを約束するが、個々のデータフローに特異的にリソースを割り当てないことができるかもしれません。トンネルを介して設定されたリソース割当は、この一例です。我々は、このノートのタイプ2トンネルこの場合を指します。 3.（論理）リンクは、個々のエンド・ツー・エンドのデータフローのための予約を行うことが可能であってもよいです。我々は、タイプ3トンネルこの場合を指します。タイプ2のトンネルから3トンネルを入力し区別する主要な特徴は、タイプ3トンネルに新しいトンネルの予約が作成され、エンド・ツー・エンドの予約が来て、行くように動的に切断されていることであることに注意してください。
Type 1 tunnels exist when at least one of the routers comprising the tunnel endpoints does not support the scheme we describe here. In this case, the tunnel acts as a best-effort link. Our goal is simply to make sure that RSVP messages traverse the link correctly, and the presence of the non-controlled link is detected, as required by the integrated services framework.
タイプ1のトンネルが存在する場合、我々はここで説明するスキームをサポートしていないトンネルのエンドポイントを構成するルータの少なくとも一つ。この場合には、ベストエフォート型のリンクとしてトンネルの役割を果たします。私たちの目標は、RSVPメッセージが正しくリンクを通過することを確認するだけであり、および統合サービスフレームワークで必要とされる非制御リンクの存在が、検出されました。
When the two end points of the tunnel are capable of supporting RSVP over tunnels, we would like to have proper resources reserved along the tunnel. Depending on the requirements of the situation, this might mean that one client's data flow is placed into a larger aggregate reservation (type 2 tunnels) or that possibly a new, separate reservation is made for the data flow (type 3 tunnels). Note that an RSVP reservation between the two tunnel end points does not necessarily mean that all the intermediate routers along the tunnel path support RSVP, this is equivalent to the case of an existing end-to-end RSVP session transparently passing through non-RSVP cloud.
トンネルの両端ポイントがトンネルでRSVPをサポートすることが可能であるとき、私たちはトンネルに沿って予約し、適切なリソースを持っていると思います。状況の要件によっては、これは1つのクライアントのデータの流れが大きく集計予約（2型のトンネル）内に配置されているかということは、おそらく新しい、別の予約がデータフロー（タイプ3トンネル）のために作られていること意味します。 2つのトンネルエンドポイント間のRSVP予約は、必ずしもトンネル経路支持RSVPに沿って全ての中間ルータが、これは既存のエンドツーエンドRSVPセッションが透過的に非RSVP雲を通過する場合に相当するという意味ではないことに留意されたいです。
Currently, however, RSVP signaling over tunnels is not possible. RSVP packets entering the tunnel are encapsulated with an outer IP header that has a protocol number other than 46 (e.g. it is 4 for IP-in-IP encapsulation) and do not carry the Router-Alert option, making them virtually "invisible" to RSVP routers between the two tunnel endpoints. Moreover, the current IP-in-IP encapsulation scheme adds only an IP header as the external wrapper. It is impossible to distinguish between packets that use reservations and those that don't, or to differentiate packets belonging to different RSVP Sessions while they are in the tunnel, because no distinguishing information such as a UDP port is available in the encapsulation.
しかし、現在はトンネル経由RSVPシグナリングはできません。トンネルに入るRSVPパケットが46以外のプロトコル番号を有する外部IPヘッダでカプセル化されている（例えば、それはIP-in-IPカプセル化のための4）とするためにそれらが実質「不可視」作り、ルータアラートオプションを運びません2つのトンネルエンドポイント間のRSVPルータ。また、現在のIP-in-IPカプセル化方式は、外部ラッパーとしてのみIPヘッダを付加します。そのようなUDPポートとして何の区別情報をカプセル化して利用できないので、予約とそうでないものを使用するパケットを区別するために、またはそれらがトンネルにいるときに別のRSVPセッションに属するパケットを区別することは不可能です。
This document describes an IP tunneling enhancement mechanism that allows RSVP to make reservations across all IP-in-IP tunnels. This mechanism is capable of supporting both type 2 and type 3 tunnels, as described above, and requires minimal changes to both RSVP and other parts of the integrated services framework.
このドキュメントは、RSVPは、すべてのIPインIPトンネルを越え予約を行うことができますIPトンネリング機能拡張メカニズムを説明しています。この機構は、上述したように、タイプ2およびタイプ3のトンネルの両方をサポートすることが可能であり、RSVPと統合サービス・フレームワークの他の部分の両方に最小限の変更を必要とします。
Our design choices are motivated by several goals.
私たちのデザインの選択は、いくつかの目標によって動機づけされています。
* Co-existing with most, if not all, current IP-in-IP tunneling schemes. * Limiting the changes to the RSVP spec to the minimum possible. * Limiting the necessary changes to only the two end points of a tunnel. This requirement leads to simpler deployment, lower overhead in the intermediate routers, and less chance of failure when the set of intermediate routers is modified due to routing changes. * Supporting correct inter-operation with RSVP routers that have not been upgraded to handle RSVP over tunnels and with non-RSVP tunnel endpoint routers. In these cases, the tunnel behaves as a non-RSVP link.
*、ほとんど、すべてではないが、現在のIP内IPトンネリングスキームと共存。 *可能な限り最小にRSVPの仕様への変更を制限します。 *トンネルの唯一の両端点に必要な変更を制限します。この要件は、単純な展開、中間ルータに低いオーバーヘッド、及び中間ルータのセットを伴うルーティングの変更に変更され、障害のより少ない機会をもたらします。 *トンネルで非RSVPトンネルエンドポイントルータでRSVPを処理するためにアップグレードされていないRSVPルータとの正しい相互運用をサポートします。これらの場合では、トンネルは、非RSVPリンクとして振る舞います。
The basic idea of the method described in this document is to recursively apply RSVP over the tunnel portion of the path. In this new session, the tunnel entry point Rentry sends PATH messages and the tunnel exit point Rexit sends RESV messages to reserve resources for the end-to-end sessions over the tunnel.
この文書に記載された方法の基本的な考え方は、再帰的にパスのトンネル部の上にRSVPを適用することです。この新しいセッションでは、トンネルエントリポイントRentryは、PATHメッセージを送信し、トンネル出口ポイントRexitがトンネル上で、エンドツーエンドのセッションのためのリソースを予約するRESVメッセージを送信します。
We discuss next two different aspects of the design: how to enhance an IP-in-IP tunnel with RSVP capability, and how to map end-to-end RSVP sessions to a tunnel session.
RSVP機能を備えたIPインIPトンネルを拡張する方法、およびどのようにトンネルセッションにエンドツーエンドRSVPセッションをマッピングするために：私たちは、デザインの次の二つの異なる側面を議論します。
To establish a RSVP reservation over a unicast IP-in-IP tunnel, we made the following design decisions:
ユニキャストIP-で-IPトンネル上のRSVP予約を確立するために、我々は次のような設計上の決定をしました。
One or more Fixed-Filter style unicast reservations between the two end points of the tunnel will be used to reserve resources for packets traversing the tunnel. In the type 2 case, these reservations will be configured statically by a management interface. In the type 3 case, these reservations will be created and torn down on demand, as end-to-end reservation requests come and go.
一つ以上のトンネルの二つのエンドポイント間の固定フィルタスタイルユニキャスト予約がトンネルを通過するパケットのためのリソースを予約するために使用されます。タイプ2の場合には、これらの予約管理インタフェースによって静的に設定されるであろう。エンド・ツー・エンドの予約要求が来て、行くようにタイプ3の場合には、これらの予約は、オンデマンドで作成され、解体されます。
Packets that do not require reservations are encapsulated in the normal way, e. g. being wrapped with an IP header only, specifying the tunnel entry point as source and the exit point as destination.
予約を必要としないパケットは、通常の方法で電子をカプセル化しています。グラム。送信元および宛先として出口ポイントとしてトンネルエントリポイントを指定して、唯一のIPヘッダでラップされます。
Data packets that require resource reservations within a tunnel must have some attribute other than the IP addresses visible to the intermediate routers, so that the routers may map the packet to an appropriate reservation. To allow intermediate routers to use standard RSVP filterspec handling, we choose to encapsulate such data packets by prepending an IP and a UDP header, and to use UDP port numbers to distinguish packets of different RSVP sessions. The protocol number in the outer IP header in this case will be UDP.
ルータが適切な予約にパケットをマッピングすることができるように、トンネル内のリソース予約を必要とするデータパケットは、IPが中間ルータに見えるアドレス以外のいくつかの属性を有していなければなりません。中間ルータは、標準のRSVP FilterSpecに処理を使用できるようにするために、我々は、IPおよびUDPヘッダを付加することで、このようなデータパケットをカプセル化することを選択し、かつ異なるRSVPセッションのパケットを区別するためにUDPのポート番号を使用します。この場合、外側のIPヘッダ内のプロトコル番号がUDPであろう。
Figure 1 shows RSVP operating over a tunnel. Rentry is the tunnel entry router which encapsulates data into the tunnel. Some number of intermediate routers forward the data across the network based upon the encapsulating IP header added by Rentry. Rexit is the endpoint of the tunnel. It decapsulates the data and forwards it based upon the original, "inner" IP header.
図1は、RSVPがトンネル上で動作を示しています。 Rentryトンネルにデータをカプセル化するトンネルエントリルータです。中間ルータのいくつかの数はRentryによって追加されたカプセル化IPヘッダに基づいて、ネットワークを介してデータを転送します。 Rexitは、トンネルのエンドポイントです。それは、元の、「内側」IPヘッダに基づいて、データ及び転送をデカプセル化します。
........... ............... .............
: _______ : : _____ :
: | | : : | | :
Intranet :--| Rentry|===================|Rexit|___:Intranet
: |_______| : : |_____| :
..........: : Internet : :...........
:..............
|___________________|
Figure 1. An example IP Tunnel
図1の例IPトンネル
Figure 2 shows a simple topology with a tunnel and a few hosts. The sending hosts H1 and H3 may be one or multiple IP hops away from Rentry; the receiving hosts H2 and H4 may also be either one or multiple IP hops away from Rexit.
図2は、トンネル、いくつかのホストとの単純なトポロジを示しています。送信ホストH1及びH3は、一つまたは複数のIP離れRentryからホップであってもよいです。受信ホストH2及びH4はまた、いずれか一方であってもよく、または複数のIPがRexitから離れるホップ。
H1 H2
: :
: :
+--------+ +---+ +---+ +---+ +-------+
| | | | | | | | | |
H3... | Rentry |===================================| Rexit |..... H4
| | | | | | | | | |
+--------+ +---+ +---+ +---+ +-------+
Figure 2: An example end-to-end path with
a tunnel in the middle.
An RSVP session may be in place between endpoints at hosts H1 and H2. We refer to this session as the "end-to-end" (E2E for short) or "original" session, and to its PATH and RESV messages as the end-to-end messages. One or more RSVP sessions may be in place between Rentry and Rexit to provide resource reservation over the tunnel. We refer to these as the tunnel RSVP sessions, and to their PATH and RESV messages as the tunnel or tunneling messages. A tunnel RSVP session may exist independently from any end-to-end sessions. For example through network management interface one may create a RSVP session over the tunnel to provide QoS support for data flow from H3 to H4, although there is no end-to-end RSVP session between H3 and H4.
RSVPセッションは、ホストH1とH2のエンドポイント間の場所にあってもよいです。私たちは、「エンドツーエンド」（略してE2E）または「オリジナル」のセッションとして、このセッションを参照し、エンド・ツー・エンドのメッセージとしてのPATHとRESVメッセージに。一つ以上のRSVPセッションがトンネルを介してリソース予約を提供するRentryとRexitの間で所定の位置にあってもよいです。私たちは、トンネルRSVPセッションとして、トンネルまたはトンネリングメッセージとしてのPATHとRESVメッセージにこれらを参照してください。トンネルRSVPセッションは、任意のエンドツーエンドのセッションとは独立して存在してもよいです。例えばネットワーク管理インターフェースを介して一方がH3とH4の間には、エンドツーエンドRSVPセッションはないが、H4とH3からデータフローのQoSサポートを提供するために、トンネル上のRSVPセッションを作成することができます。
When an end-to-end RSVP session crosses a RSVP-capable tunnel, there are two cases to consider in designing mechanisms to support an end-to-end reservation over the tunnel: mapping the E2E session to an existing tunnel RSVP session (type 2 tunnel), and dynamically creating a new tunnel RSVP session for each end-to-end session (type
（タイプ既存のトンネルRSVPセッションにE2Eセッションをマッピング：エンドツーエンドRSVPセッションは、RSVP対応トンネルを横切るときに、トンネルを介してエンド・ツー・エンドの予約をサポートするためのメカニズムを設計する際に考慮すべき2つのケースがあります2トンネル）、および動的各エンドツーエンドセッションのための新しいトンネルRSVPセッションを作成（タイプ
3 tunnel). In either case, the picture looks like a recursive application of RSVP. The tunnel RSVP session views the two tunnel endpoints as two end hosts with a unicast Fixed-Filter style reservation in between. The original, end-to-end RSVP session views the tunnel as a single (logical) link on the path between the source(s) and destination(s).
3トンネル）。いずれの場合も、絵はRSVPの再帰的なアプリケーションのように見えます。トンネルRSVPセッションの間でユニキャスト固定フィルタスタイルの予約を持つ2つのエンドホストとして2つのトンネルエンドポイントを見ます。オリジナル、エンドツーエンドRSVPセッションは、ソース（S）と宛先（複数可）との間の経路上に単一の（論理）リンクとしてトンネルを見ます。
Note that in practice a tunnel may combine type 2 and type 3 characteristics. Some end-to-end RSVP sessions may trigger the creation of new tunnel sessions, while others may be mapped into an existing tunnel RSVP session. The choice of how an end-to-end session is treated at the tunnel is a matter of local policy.
実際にはトンネル型2を組み合わせて、3特性を入力してもよいことに留意されたいです。他の既存のトンネルRSVPセッションにマッピングすることができるが、いくつかのエンドツーエンドRSVPセッションは、新しいトンネルセッションの作成をトリガすることができます。 、エンドツーエンドのセッションがトンネルで処理される方法の選択は、ローカルポリシーの問題です。
When an end-to-end RSVP session crosses a RSVP-capable tunnel, it is necessary to coordinate the actions of the two RSVP sessions, to determine whether or when the tunnel RSVP session should be created and torn down, and to correctly transfer error and ADSPEC information between the two RSVP sessions. We made the following design decision:
、エンドツーエンドRSVPセッションがRSVP対応のトンネルを横切るときに、二つのRSVPセッションのアクションを調整するためにトンネルRSVPセッションが作成され、解体されるべきであるかどうかかを決定するために、かつ正確にエラーを転送する必要がありますそして2つのRSVPセッション間ADSPEC情報。我々は、次の設計上の決定をしました。
* End-to-end RSVP control messages being forwarded through a tunnel are encapsulated in the same way as normal IP packets, e.g. being wrapped with the tunnel IP header only, specifying the tunnel entry point as source and the exit point as destination.
*トンネルを介して転送されるエンドツーエンドRSVP制御メッセージは、例えば、通常のIPパケットと同様にカプセル化されます送信元および宛先として出口ポイントとしてトンネルエントリポイントを指定するだけトンネルIPヘッダでラップされます。
As IP-in-IP tunnels are being used more widely for network traffic management purposes, it is clear we must support type 2 tunnels (tunnel reservation for aggregate end-to-end sessions). Furthermore, these type 2 tunnels should allow more than one (configurable, static) reservation to be used at once, to support different traffic classes within the tunnel. Whether it is necessary to support type 3 tunnels (dynamic per end-to-end session tunnel reservation) is a policy issue that should be left open. Our design supports both cases.
IPインIPトンネルは、ネットワークトラフィック管理目的のために広く使用されているように、我々がタイプ2トンネル（集約エンドツーエンドセッションのトンネル予約）をサポートする必要が明らかです。さらに、これらのタイプ2トンネルは、トンネル内の異なるトラフィッククラスをサポートするために、一度に使用される複数の（設定、静的）予約を可能にすべきです。 （エンドツーエンドセッションのトンネル予約ごとに動的）タイプ3のトンネルをサポートする必要があるかどうかは開いたままにしなければならないポリシーの問題です。私たちのデザインは、両方のケースをサポートしています。
If there is only one RSVP session configured over a tunnel, then all the end-to-end RSVP sessions (that are allowed to use this tunnel session) will be bound to this configured tunnel session. However when more than one RSVP session is in use over an IP tunnel, a second design issue is how the association, or binding, between an original RSVP reservation and a tunnel reservation is created and conveyed from one end of the tunnel to the other. The entry router Rentry and the exit router Rexit must agree on these associations so that changes in the original reservation state can be correctly mapped into changes in the tunnel reservation state, and that errors reported by intermediate routers to the tunnel end points can be correctly transformed into errors reported by the tunnel endpoints to the end-to-end RSVP session.
トンネルを介して構成された唯一のRSVPセッションがある場合、（このトンネルセッションを使用することが許可されている）すべてのエンドツーエンドRSVPセッションは、この設定されたトンネルセッションにバインドされます。複数のRSVPセッションがIPトンネルを介して使用されている場合しかし、第2の設計上の問題は、元のRSVP予約とトンネル予約との間の関連付け、または結合は、トンネルの一方の端部から他方に作成され、搬送される方法です。入口ルーターのRentryと出口ルータRexitは、元の予約状態の変化が正しくトンネル予約状態の変化にマッピングすることができるように、これらの団体に同意、およびトンネルエンドポイントに中間ルータによって報告されたエラーを正しく変換することができる必要がありますエンドツーエンドRSVPセッションにトンネルエンドポイントによって報告されたエラーに。
We require that this same association mechanism work for both the case of bundled reservation over a tunnel (type 2 tunnel), and the case of one-to-one mapping between original and tunnel reservations (type 3 tunnel). In our scheme the association is created when a tunnel entry point first sees an end-to-end session's RESV message and either sets up a new tunnel session, or adds to an existing tunnel session. This new association must be conveyed to Rexit, so that Rexit can reserve resources for the end-to-end sessions inside the tunnel. This information includes the identifier and certain parameters of the tunnel session, and the identifier of the end-to-end session to which the tunnel session is being bound. In our scheme, all RSVP sessions between the same two routers Rentry and Rexit will have identical values for source IP address, destination IP address, and destination UDP port number. An individual session is identified primarily by the source port value.
我々は、必要とするトンネルを介しバンドル予約の場合（タイプ2トンネル）、およびオリジナルトンネル予約（タイプ3トンネル）との間に1対1のマッピングの場合の両方について、この同じ関連機構ワーク。トンネルエントリポイントは、最初のエンド・ツー・エンドのセッションのRESVメッセージを見て、どちらか新しいトンネルセッションを設定、または既存のトンネルセッションに追加したときに私達の方式では関連付けが作成されます。 Rexitは、トンネル内のエンドツーエンドセッションのためのリソースを予約できるように、この新たな関連付けは、Rexitに搬送されなければなりません。この情報は、識別子とトンネルセッションの特定のパラメータ、トンネルセッションが結合されたエンドツーエンドのセッションの識別子を含みます。提案方式では、同じ2つのルータRentryとRexitの間のすべてのRSVPセッションは、送信元IPアドレス、宛先IPアドレス、宛先UDPのポート番号に対して同一の値を持つことになります。個々のセッションは、主に、ソースポートの値によって識別されます。
We identified three possible choices for a binding mechanism:
私たちは、結合メカニズムのための3つの可能な選択肢を特定しました。
1. Define a new RSVP message that is exchanged only between two tunnel end points to convey the binding information. 2. Define a new RSVP object to be attached to end-to-end PATH messages at Rentry, associating the end-to-end session with one of the tunnel sessions. This new object is interpreted by Rexit associating the end-to-end session with one of the tunnel sessions generated at Rentry. 3. Apply the same UDP encapsulation to the end-to-end PATH messages as to data packets of the session. When Rexit decapsulates the PATH message, it deduces the relation between the source UDP port used in the encapsulation and the RSVP session that is specified in the original PATH message.
1.バインディング情報を伝えるためにのみ2つのトンネルエンドポイント間で交換される新たなRSVPメッセージを定義します。 2.トンネルセッションのいずれかでエンドツーエンドのセッションを関連付ける、Rentryでエンドツーエンドパスメッセージに添付される新しいRSVPオブジェクトを定義します。この新しいオブジェクトはRentryで発生したトンネルセッションのいずれかでエンドツーエンドのセッションを関連付けるRexitによって解釈されます。 3.セッションのデータパケットに関して、エンド・ツー・エンドのPATHメッセージに同じUDPカプセル化を適用します。 RexitはPATHメッセージをデカプセル化するとき、それはカプセル化と、元のPATHメッセージで指定されたRSVPセッションで使用される送信元UDPポートとの間の関係を推定します。
The last approach above does not require any new design. However it requires additional resources to be reserved for PATH messages (since they are now subject to the tunnel reservation). It also requires a priori knowledge of whether Rexit supports RSVP over tunnels by UDP encapsulation. If Rentry encapsulates all the end-to-end PATH messages with the UDP encapsulation, but Rexit does not understand this encapsulation, then the encapsulated PATH messages will be lost at Rexit.
最後のアプローチは、上記のいずれかの新しいデザインを必要としません。 （彼らは今、トンネル予約の対象となっているので）しかし、それは、PATHメッセージのために確保されるように、追加のリソースが必要です。また、RexitはUDPカプセル化することにより、トンネル経由RSVPをサポートしているかどうかの事前知識が必要です。 RentryはUDPでカプセル化されたすべてのエンド・ツー・エンドのPATHメッセージをカプセル化しますが、Rexitは、このカプセル化を理解していない場合は、カプセル化されたPATHメッセージはRexitで失われます。
On the other hand, options (1) and (2) can handle this case transparently. They allow Rexit to pass on end-to-end PATHs received via the tunnel (because they are decapsulated normally), while throwing away the tunnel PATHs, all without any additional configuration. We chose Option (2) because it is simpler. We describe this object in the following section.
一方、選択肢（1）及び（2）透過このケースを扱うことができます。すべての追加の構成なしで、トンネル経路を捨てながら、それらは、（それらが正常にデカプセル化されているため）Rexitがトンネルを介して受信したエンドツーエンドのパスで通過することを可能にします。それは簡単ですので、私たちは、オプション（2）を選択しました。私たちは、次のセクションで、このオブジェクトを記述する。
Packet exchanges must follow the following constraints:
パケット交換は、次の制約に従う必要があります。
1. Rentry encapsulates and sends end-to-end PATH messages over the tunnel to Rexit where they get decapsulated and forwarded downstream. 2. When a corresponding end-to-end RESV message arrives at Rexit, Rexit encapsulates it and sends it to Rentry. 3. Based on some or all of the information in the end-to-end PATH messages, the flowspec in the end-to-end RESV message and local policies, Rentry decides if and how to map the end-to-end session to a tunnel session. 4. If the end-to-end session should be mapped to a tunnel session, Rentry either sends a PATH message for a new tunnel session or updates an existing one. 5. Rentry sends a E2E Path containing a SESSION_ASSOC object associating the end-to-end session with the tunnel session above. Rexit records the association and removes the object before forwarding the Path message further. 6. Rexit responds to the tunnel PATH message by sending a tunnel RESV message, reserving resources inside the tunnel. 7. Rentry UDP-encapsulates arriving packets only if a corresponding tunnel session reservation is actually in place for the packets.
1. Rentryはカプセル化して、彼らはデカプセル化し、下流の転送を受けるRexitにトンネル経由でエンド・ツー・エンドPATHメッセージを送信します。対応するエンドツーエンドのRESVメッセージはRexitに到着すると2、Rexitはそれをカプセル化しRentryに送ります。 3、どのようにエンドツーエンドのセッションをマッピングする場合、エンドツーエンドのPATHメッセージ内の情報の一部またはすべてに基づいて、エンド・ツー・エンドRESVメッセージ、地域政策のフロースペックは、Rentryが決定トンネルセッション。 4.エンドツーエンドのセッションがトンネルセッションにマッピングされる必要がある場合、いずれかRentry新しいトンネルセッションに対する経路メッセージを送信するか、既存のものを更新します。 5. Rentryは、上記トンネルセッションとのエンドツーエンドのセッションを関連付けるSESSION_ASSOCオブジェクトを含むE2Eパスを送ります。 Rexitは関連を記録し、さらにPathメッセージを転送する前にオブジェクトを削除します。 6. Rexitは、トンネル内のリソースを予約する、トンネルRESVメッセージを送信することによってトンネル経路メッセージに応答します。 7. Rentry UDPは、カプセル化、対応するトンネルセッションの予約がパケットのための場所に実際にある場合にのみ、パケット到着します。
The new object, called SESSION_ASSOC, is defined with the following format:
SESSION_ASSOCと呼ばれる新しいオブジェクトは、次の形式で定義されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | class | c-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SESSION object (for the end-to-end session) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Sender FILTER-SPEC (for the tunnel session) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SESSION_ASSOC Object
SESSION_ASSOCオブジェクト
Length
長さ
This field contains the size of the SESSION_ASSOC object in bytes.
このフィールドは、バイト単位でSESSION_ASSOCオブジェクトのサイズが含まれています。
Class
クラス
Should be 192.
192でなければなりません。
Ctype
CTYPE
Should be sent as zero and ignored on receipt.
ゼロとして送られて、領収書の上で無視されなければなりません。
SESSION object
SESSIONオブジェクト
The end-to-end SESSION contained in the object is to be mapped to the tunnel session described by the Sender FILTER-SPEC defined below.
オブジェクトに含まれているエンドツーエンドのセッションは、以下に定義された送信者FILTER-SPECによって記述トンネルセッションにマッピングされます。
Sender FILTER-SPEC
送信者FILTER-SPEC
This is the tunnel session that the above mentioned end-to-end session maps to over the tunnel. As we mentioned above, a tunnel session is identified primarily by source port. This is why we use a Sender Filter-Spec for the tunnel session, in the place of a SESSION object.
これは、トンネル上に、上述したエンドツーエンドのセッションマップそのトンネルセッションです。我々は、上述したように、トンネルセッションは、主に送信元ポートによって識別されます。私たちは、Sessionオブジェクトの代わりに、トンネルセッションのために送信者フィルタスペックを使用する理由です。
There has to be a way (other than through configuration) for Rexit to communicate to Rentry the fact that it is a tunnel endpoint supporting the scheme described in this document. We have defined for this reason a new object, called NODE_CHAR, carrying this information. If a node receives this object but does not understand it, it should drop it without producing any error report. Objects with Class-Num = 10bbbbbb (`b' represents a bit), as defined in the RSVP specification [RFC2205], have the characteristics we need. While for now this object only carries one bit of information, it can be used in the future to describe other characteristics of an RSVP capable node that are not part of the original RSVP specification.
Rexitは、それが本文書に記載の方式を支援するトンネルエンドポイントであるという事実をRentryと通信するための（コンフィギュレーションを介する以外の）方法がなければなりません。私たちは、この情報を運ぶ、この理由のためにNODE_CHARと呼ばれる新しいオブジェクトを定義しています。ノードは、このオブジェクトを受け取り、それを理解していない場合は、すべてのエラーレポートを生成することなく、それをドロップしなければなりません。クラス民= 10bbbbbb持つオブジェクトは、RSVP仕様[RFC2205]で定義された、我々は必要な特性を持っているように、（ `b」はビットを表します）。今のところ、このオブジェクトのみ1ビットの情報を搬送しながら、元のRSVP仕様の一部ではないRSVP可能なノードの他の特性を記述するために、将来的に使用することができます。
The object NODE_CHAR has the following format:
オブジェクトNODE_CHARの形式は次のとおりです。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | class | c-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |T|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length
長さ
This field contains the size of the NODE_CHAR object in bytes. It should be set to eight.
このフィールドは、バイト単位でNODE_CHARオブジェクトのサイズが含まれています。それは8に設定する必要があります。
Class
クラス
An appropriate value should be assigned by the IANA. We propose this value to be 128.
適切な値は、IANAによって割り当てられるべきです。私たちは、この値は128であることを提案しています。
Ctype
CTYPE
Should be sent as zero and ignored on receipt.
ゼロとして送られて、領収書の上で無視されなければなりません。
T bit
Tビット
This bit shows that the node is a RSVP-tunnel capable node.
このビットは、ノードがRSVP-トンネル可能なノードであることを示しています。
When Rexit receives an end-to-end reservation, it appends a NODE_CHAR object with the T bit set, to the RESV object, it encapsulates it and sends it to Rentry. When Rentry receives this RESV message it deduces that Rexit implements the mechanism described here and so it creates or adjusts a tunnel session and associates the tunnel session to the end-to-end session via a SESSION_ASSOC object. Rentry should remove the NODE_CHAR object, before forwarding the RESV message upstream. If on the other hand, Rentry does not support the RSVP Tunnels mechanism it would simply ignore the NODE_CHAR object and not forward it further upstream.
Rexitは、エンドツーエンド予約を受信すると、それはRESVオブジェクトに、Tビットが設定されたNODE_CHARオブジェクトを追加し、それをカプセル化しRentryに送ります。 RentryこのRESVメッセージを受信した場合には、Rexitは、ここで説明されたメカニズムを実装していることを推定するので、それが作成またはトンネルセッションを調整しSESSION_ASSOCオブジェクトを介してエンドツーエンドセッションにトンネルセッションを関連付けます。 Rentry上流RESVメッセージを転送する前に、NODE_CHARオブジェクトを削除すべきです。一方、RentryはRSVPトンネルメカニズムをサポートしていない場合、それは単にNODE_CHARオブジェクトを無視し、さらに上流にそれを転送しないでしょう。
In this section we discuss several cases separately, starting from the simplest scenario and moving to the more complex ones.
このセクションでは、最も簡単なシナリオから始めて、より複雑なものに移動し、別にいくつかの例を議論します。
Treating the two tunnel endpoints as a source and destination host, one easily sets up a FF-style reservation in between. Now the question is what kind of filterspec to use for the tunnel reservation, which directly relates to how packets get encapsulated over the tunnel. We discuss two cases below.
送信元および宛先ホストとして2つのトンネルエンドポイントを処理する、一方が容易との間にFF形式の予約を設定します。今の質問はFilterSpecにどのような種類の直接のパケットがトンネル経由でカプセル化された取得する方法に関し、トンネルの予約のために使用することです。当社は、下記の2例を議論します。
In the case where all the packets traversing a tunnel use the reserved resources, the current IP-in-IP encapsulation could be used. The RSVP session over the tunnel would simply specify a FF style reservation (with zero port number) with Rentry as the source address and Rexit as the destination address.
トンネルを通過するすべてのパケットが予約されたリソースを使用する場合には、現在のIPインIPカプセル化を用いることができます。トンネル上のRSVPセッションは、単に宛先アドレスとソースアドレスとRexitとしてRentryと（ゼロポート番号）FFスタイルの予約を指定することになります。
However if only some of the packets traversing the tunnel should benefit from the reservation, we must encapsulate the qualified packets in IP and UDP. This allows intermediate routers to use standard RSVP filterspec handling, without having to know about the existence of tunnels.
唯一のトンネルを通過するパケットの一部が予約の恩恵を受ける必要がありますただし場合、我々はIPやUDPにおける資格のパケットをカプセル化しなければなりません。これは、中間ルータがトンネルの存在を知らなくても、標準のRSVP FilterSpecに処理を使用することができます。
Rather than supporting both cases we choose to simplify implementations by requiring all data packets using reservations to be encapsulated with an outer IP and UDP header. This reduces special case checking and handling.
むしろ、我々は予約を使用して、すべてのデータパケットを要求することによって、実装を簡素化することを選択し、両方のケースを支持するよりも外側のIP及びUDPヘッダでカプセル化することができます。これは特殊なケースをチェックし、取り扱いを低減します。
According to the tunnel control policies, installed through some management interface, some or all end-to-end RSVP sessions may be allowed to map to the single RSVP session over the tunnel. In this case there is no need to provide dynamic binding information between end-to-end sessions and the tunnel session, given that the tunnel session is unique and pre-configured, and therefore well-known.
いくつかの管理インタフェースを介してインストールされたトンネル制御ポリシーによると、一部またはすべてのエンドツーエンドRSVPセッションは、トンネルを介して、単一のRSVPセッションにマッピングさせることができます。この場合、トンネルセッションが一意であると事前に設定し、したがって、周知のことを考えれば、エンドツーエンドのセッションとトンネルセッションとの間の動的バインディング情報を提供する必要はありません。
Binding multiple end-to-end sessions to one tunnel session, however, raises a new question of when and how the size of the tunnel reservation should be adjusted to accommodate the end-to-end sessions mapped onto it. Again the tunnel manager makes such policy decision. Several scenarios are possible. In the first, the tunnel reservation is never adjusted. This makes the tunnel the rough equivalent of a fixed-capacity hardware link. In the second, the tunnel reservation is adjusted whenever a new end-to-end reservation arrives or an old one is torn down. In the third, the tunnel reservation is adjusted upwards or downwards occasionally, whenever the end-to-end reservation level has changed enough to warrant the adjustment. This trades off extra resource usage in the tunnel for reduced control traffic and overhead.
1つのトンネルセッションに複数のエンドツーエンドのセッションを結合しかし、トンネル予約のサイズはそれにマッピングされたエンドツーエンドのセッションを収容するように調整されなければならない場合、どのように新たな問題を提起します。再びトンネルマネージャは、このような政策決定を行います。いくつかのシナリオが考えられます。最初に、トンネル予約が調整されることはありません。これは、トンネルの固定容量のハードウェアリンクの粗い等価になります。第二に、新しいエンドツーエンド予約が到着するたびに、トンネル予約が調整されるか、または古いものが取り壊されます。エンドツーエンドの予約レベル調整を保証するのに十分に変化したときはいつでも第三に、トンネル予約は、時折、上方または下方に調整されます。これは、減少した制御トラフィックとオーバーヘッドのためのトンネル内の余分なリソースの使用状況をトレードオフ。
We call a tunnel whose reservation cannot be adjusted a "hard pipe", as opposed to a "soft pipe" where the amount of resources allocated is adjustable. Section 5.2 explains how the adjustment can be carried out for soft pipes.
我々は、その予約割り当てられたリソースの量が調整可能である「ソフトパイプ」とは対照的に、「硬いパイプ」を調整することができないトンネルを呼び出します。 5.2節では、調整は、ソフトパイプのために行うことができる方法を説明します。
It is straightforward to build on the case of a single configured RSVP session over a tunnel by setting up multiple FF-style reservations between the two tunnel endpoints using a management interface. In this case Rentry must carefully encapsulate data packets with the proper UDP port numbers, so that packets belonging to different tunnel sessions will be distinguished by the intermediate RSVP routers. Note that this case and the one described before describe what we call type 2 tunnels.
管理インターフェイスを使用して、2つのトンネルエンドポイント間の複数のFF形式の予約を設定してトンネルを介して単一構成RSVPセッションの場合に構築することは簡単です。異なるトンネルセッションに属するパケットは、中間RSVPルータによって区別されるように、この場合Rentry注意深く、適切なUDPポート番号を有するデータパケットをカプセル化しなければなりません。この場合と前に説明したものは、我々は2型のトンネルと呼んでいるものを説明することに注意してください。
Nothing more needs to be said in this case. Rentry classifies the packets and encapsulates them accordingly. Packets with no reservations are encapsulated with an outer IP header only, while packets qualified for reservations are encapsulated with a UDP header as well as an IP header. The UDP source port value should be properly set to map to the corresponding tunnel reservation the packet is supposed to use.
より多くの何もこの場合には言わする必要はありません。 Rentryは、パケットを分類し、それに応じてそれらをカプセル化します。予約の資格パケットがUDPヘッダ、並びにIPヘッダでカプセル化されつつない予約を有するパケットは、唯一の外側のIPヘッダでカプセル化されます。 UDPソースポート値が正しくパケットを使用することになっている、対応するトンネル予約にマッピングするように設定されるべきです。
Since in this case, there is more than one RSVP session operating over the tunnel, one must explicitly bind each end-to-end RSVP session to its corresponding tunnel session. As discussed previously, this binding will be provided by the new SESSION_ASSOC object carried by the end-to-end PATH messages.
この場合には、トンネルを介して動作する複数のRSVPセッションがあるので、一方が明示的にそれに対応するトンネルセッションへの各エンドツーエンドRSVPセッションを結合しなければなりません。前述したように、この結合は、エンドツーエンドのPATHメッセージによって運ばれ、新たなSESSION_ASSOCオブジェクトによって提供されます。
This is the case of a type 3 tunnel. The only differences between this case and that of Section 4.2 are that:
これはタイプ3トンネルの場合です。この場合、セクション4.2のそれとの間の唯一の違いは、以下のとおりです。
- The tunnel session is created when a new end-to-end session shows up. - There is a one-to-one mapping between the end-to-end and tunnel RSVP sessions, as opposed to possibly many-to-one mapping that is allowed in the case described in Section 4.2.
- 新たなエンドツーエンドセッションが現れた場合に、トンネルセッションが作成されます。 - セクション4.2で説明した場合に許可されている可能性の多対1マッピングとは対照的に、エンド・ツー・エンドとトンネルRSVPセッションの間に1対1のマッピングが存在します。
Here one or more RSVP sessions are set up over a tunnel through a management interface. The session reservation parameters never change for a "hard pipe" tunnel. The reservation parameters may change for a "soft pipe" tunnel. Tunnel session PATH messages generated by Rentry are addressed to Rexit, where they are processed and deleted.
ここで一つ以上のRSVPセッションは、管理インタフェースを介してトンネルを介して設定されています。セッション予約パラメータは、「ハードパイプ」トンネルに変更することはありません。予約パラメータは、「ソフトパイプ」トンネルに変更してもよいです。 Rentryによって生成されたトンネルセッションPATHメッセージは、それらが処理され、削除されRexit、宛います。
When forwarding an end-to-end PATH message, a router acting as the tunnel entry point, Rentry, takes the following actions depending on the end-to-end session mentioned in the PATH message. There are two possible cases:
エンドツーエンドパスのメッセージを転送するとき、トンネルエントリポイントとして機能するルータは、Rentryは、PATHメッセージに記載のエンドツーエンドセッションに応じて次のアクションをとります。 2つのケースが考えられます
1. The end-to-end PATH message is a refresh of a previously known end-to-end session. 2. The end-to-end PATH message is from a new end-to-end session.
1.エンドツーエンドパスメッセージは、以前に知られているエンドツーエンドのセッションのリフレッシュです。 2.エンド・ツー・エンドのPATHメッセージは、新しいエンドツーエンドのセッションからです。
If the PATH message is a refresh of a previously known end-to-end session, then Rentry refreshes the Path state of the end-to-end session and checks to see if this session is mapped to a tunnel session. If this is the case, then when Rentry refreshes the end-to-end session, it includes in the end-to-end PATH message a SESSION_ASSOC object linking this session to its corresponding tunnel session It then encapsulates the end-to-end PATH message and sends it over the tunnel to Rexit. If the tunnel session was dynamically created, the end-to-end PATH message serves as a refresh for the local tunnel state at Rentry as well as for the end-to-end session.
PATHメッセージは、以前に知られているエンドツーエンドセッションのリフレッシュである場合、Rentryは、エンドツーエンドセッションのパス状態を更新し、このセッションがトンネルセッションにマッピングされているかどうかをチェック。この場合Rentryは、エンドツーエンドのセッションをリフレッシュするとき、次に、それはエンド・ツー・エンドのPATHメッセージ内の対応するトンネルセッションにこのセッションを連結SESSION_ASSOCオブジェクトを含み、これは、次いで、エンドツーエンドパスをカプセル化メッセージとRexitにトンネルを介して送信します。トンネルセッションが動的に作成された場合、エンドツーエンドのPATHメッセージはRentryでローカルトンネル状態のため、ならびにエンドツーエンドセッションのリフレッシュとして機能します。
Otherwise, if the PATH message is from a new end-to-end session that has not yet been mapped to a tunnel session, Rentry creates Path state for this new session setting the outgoing interface to be the tunnel interface. After that, Rentry encapsulates the PATH message and sends it to Rexit without adding a SESSION_ASSOC message.
PATHメッセージはまだトンネルセッションにマッピングされていない新たなエンドツーエンドのセッションからのものである場合はそうでなければ、Rentryトンネルインターフェイスであると発信インタフェースを設定するこの新しいセッションに対する経路状態を作成します。その後、Rentryは、PATHメッセージをカプセル化し、SESSION_ASSOCメッセージを追加することなく、Rexitに送信します。
When an end-to-end PATH TEAR is received by Rentry, this node encapsulates and forwards the message to Rexit. If this end-to-end session has a one-to-one mapping to a tunnel session or if this is the last one of the many end-to-end sessions mapping to a tunnel session, Rentry tears down the tunnel session by sending a PATH TEAR for that session to Rexit. If, on the other hand, there are remaining end-to-end sessions mapping to the tunnel session, then Rentry sends a tunnel PATH message adjusting the Tspec of the tunnel session.
エンドツーエンドパスのTEARをRentryによって受信されると、このノードは、カプセル化しRexitにメッセージを転送します。このエンドツーエンドのセッションは、トンネルセッションと1対1のマッピングを持っているか、これがトンネルセッションに多くのエンド・ツー・エンドのセッションマッピングの最後である場合、Rentryは、送信することにより、トンネルセッションを切断した場合RexitにそのセッションのPATH TEAR。一方、トンネルセッションにエンドツーエンドのセッションマッピング残りがある場合、RentryトンネルセッションのTspecは調整トンネルPATHメッセージを送信します。
Encapsulated end-to-end PATH messages are decapsulated and processed at Rexit. Depending on whether the end-to-end PATH message contains a SESSION_ASSOC object or not, Rexit takes the following steps:
カプセル化されたエンド・ツー・エンドのPATHメッセージはRexitでカプセル化が解除され、処理されます。エンド・ツー・エンドのPATHメッセージがSESSION_ASSOCオブジェクトが含まれているかどうかに応じて、Rexitは、以下の手順を実行します。
1. If the end-to-end PATH message does not contain a SESSION_ASSOC object, then Rentry sets the Non_RSVP flag at the Path state stored for this end-to-end sender, sets the global break bit in the ADSPEC and forwards the packets downstream. Alternatively, if tunnel sessions exist and none of them has the Non_RSVP flag set, Rexit can pick the worst-case Path ADSPEC params from the existing tunnel sessions and update the end-to-end ADSPEC using these values. This is a conservative estimation of the composed ADSPEC but it has the benefit of avoiding to set the break bit in the end-to-end ADSPEC before mapping information is available. In this case the Non_RSVP flag at the end-to-end Path state is not set.
1.エンドツーエンドPATHメッセージがSESSION_ASSOCオブジェクトが含まれていない場合、その後Rentryは、このエンドツーエンドの送信者のために記憶されるパス状態でNon_RSVPフラグをセットADSPECにグローバルブレークビットを設定し、パケットを転送します下流。トンネルセッションが存在し、それらのどれもNon_RSVPフラグが設定されていない場合、あるいは、Rexitは、最悪の場合のパスADSPEC paramsは既存のトンネルセッションからを選択し、これらの値を使用して、エンド・ツー・エンドのADSPECを更新することができます。これは、合成ADSPECの保守的な見積もりであるが、それは情報が利用可能であるマッピングする前に、エンドツーエンドのADSPECでブレークビットを設定するために回避する利点を有します。この場合、エンドツーエンドのパス状態でNon_RSVPフラグがセットされていません。
2. If the PATH message contains a SESSION_ASSOC object and no association for this end-to-end session already exists, then Rexit records the association between the end-to-end session and the tunnel session described by the object. If the end-to-end PATH arrives early before the tunnel PATH message arrives then it creates PATH state at Rexit for the tunnel session. When the actual PATH message for the tunnel session arrives it is treated as an update of the existing PATH state and it updates any information missing. We believe that this situation is another transient along with the others existing in RSVP and that it does not have any long-term effects on the correct operation of the mechanism described here.
2. PATHメッセージがSESSION_ASSOCオブジェクトを含み、このエンドツーエンドのセッションのための関連付けが既に存在しない場合は、Rexitは、エンドツーエンドのセッションオブジェクトによって記述されるトンネルセッションとの間の関連付けを記録します。トンネルPATHメッセージが到着する前に、エンドツーエンドのPATHが早く到着した場合、それはトンネルセッションのためにRexitでPATH状態を作成します。トンネルセッションの実際のPATHメッセージが到着したときには、既存のパスの状態の更新として扱われ、それが不足している情報を更新します。私たちは、この状況がRSVPに既存の他の人と、それはここで説明するメカニズムの正しい操作上の任意の長期的な影響を持っていないことに沿って、別の一時的であると信じています。
Before further forwarding the message to the next hop along the path to the destination, Rexit finds the corresponding tunnel session's recorded state and turns on Non_RSVP flag in the end-to-end Path state if the Non_RSVP bit was turned on for the tunnel session. If the end-to-end PATH message carries an ADSPEC object, Rexit performs composition of the characterization parameters contained in the ADSPEC. It does this by considering the tunnel session's overall (composed) characterization parameters as the local parameters for the logical link implemented by the tunnel, and composing these parameters with those in the end-to-end ADSPEC by executing each parameter's defined composition function. In the logical link's characterization parameters, the minimum path latency may take into account the encapsulation/decapsulation delay and the bandwidth estimate can represent the decrease in available bandwidth caused by the addition of the extra UDP header. ADSPECs and composition functions are discussed in great detail in [RFC2210].
前にさらに先への経路に沿った次のホップにメッセージを転送する、Rexitは、対応するトンネルセッションの記録状態を検出し、Non_RSVPビットがトンネルセッションのためにオンになった場合は、エンドツーエンドのパス状態でNon_RSVPフラグをオンにします。エンドツーエンドパスメッセージはADSPECオブジェクトを搬送する場合、RexitはADSPECに含まれる特性化パラメータの組成を行います。これは、論理リンクのローカルパラメータは、トンネルによって実装されるトンネルセッションの全体的な（合成）特徴付けパラメータを考慮して、各パラメータの定義された組成物の機能を実行することにより、エンドツーエンドのADSPECのもので、これらのパラメータを構成することによってこれを行います。論理リンクの特徴付けパラメータは、最小のパスの待ち時間を考慮にカプセル化/デカプセル化遅れを取ってもよいし、帯域幅推定値は、余分なUDPヘッダの添加による利用可能な帯域幅の減少を表すことができます。 ADSPECs及び組成関数は、[RFC2210]に非常に詳細に議論されます。
If the end-to-end session has reservation state, while no reservation state for the matching tunnel session exists, Rexit send a tunnel RESV message to Rentry matching the reservation in the end-to-end session.
マッチングトンネルセッションのための予約状態が存在しない間のエンドツーエンドのセッションは、予約状態を有する場合、Rexitは、エンドツーエンドのセッションで予約に一致RentryするトンネルRESVメッセージを送信します。
If Rentry does not support RSVP tunneling, then Rexit will have no PATH state for the tunnel. In this case Rexit simply turns on the global break bit in the decapsulated end-to-end PATH message and forwards it.
RentryはRSVPトンネリングをサポートしていない場合は、RexitがトンネルのためのPATH状態を持ちません。この場合、Rexitは、単にデカプセル化、エンドツーエンドのPATHメッセージにグローバルブレークビットをオンにし、それを転送します。
When forwarding a RESV message upstream, a router serving as the exit router, Rexit, may discover that one of the upstream interfaces is a tunnel. In this case the router performs a number of tests.
上流のRESVメッセージを転送するとき、出口ルータ、Rexitとしてのルータは、アップストリームインターフェイスの1つがトンネルであることを発見してもよいです。この場合、ルータは、テストの数を行います。
Step 1: Rexit must determine if there is a tunnel session bound to the end-to-end session given in the RESV message. If not, the tunnel is treated as a non-RSVP link, Rexit appends a NODE_CHAR object with the T bit set, to the RESV message and forwards it over the tunnel interface (where it is encapsulated as a normal IP datagram and forwarded towards Rentry).
ステップ1：RESVメッセージに与えられたエンドツーエンドセッションに結合したトンネルセッションがある場合Rexitが決定しなければなりません。そうでない場合、トンネルは非RSVPリンクとして扱われ、Rexitは、RESVメッセージに、Tビットが設定されたNODE_CHARオブジェクトを付加して転送し、それが通常のIPデータグラムとしてカプセル化されRentry向かって転送されるトンネルインターフェース（上）。
Step 2: If a bound tunnel session is found, Rexit checks to see if a reservation is already in place for the tunnel session bound to the end-to-end session given in the RESV message. If the arriving end-to-end RESV message is a refresh of existing RESV state, then Rexit sends the original RESV through tunnel interface (after adding the NODE_CHAR object). For dynamic tunnel sessions, the end-to-end RESV message acts as a refresh for the tunnel session reservation state, while for configured tunnel sessions, reservation state never expires.
ステップ2：結合したトンネルセッションが見つかった場合、Rexitは予約がRESVメッセージに与えられたエンドツーエンドセッションに結合したトンネルセッションのための場所に既に存在するかどうかをチェック。到着エンドツーエンドRESVメッセージは、既存のRESV状態のリフレッシュの場合、Rexitは（NODE_CHARオブジェクトを追加した後に）トンネルインターフェースを介して元のRESVを送信します。設定されたトンネルセッションのために、予約状態を無期限にしながら、動的トンネルセッションのために、エンド・ツー・エンドのRESVメッセージは、トンネルセッションの予約状態のリフレッシュとして作用します。
If the arriving end-to-end RESV message causes a change in the end-to-end RESV flowspec parameters, it may also trigger an attempt to change the tunnel session's flowspec parameters. In this case Rexit sends a tunnel session RESV, including a RESV_CONFIRM object.
到着エンドツーエンドRESVメッセージは、エンドツーエンドRESVフロースペックのパラメータが変化する場合、それはまた、トンネルセッションのフロースペックパラメータを変更しようとする試みをトリガすることができます。この場合、RexitはRESV_CONFIRMオブジェクトを含む、トンネルセッションRESVを送信します。
In the case of a "hard pipe" tunnel, a new end-to-end reservation or change in the level of resources requested by an existing reservation may cause the total resource level needed by the end-to-end reservations to exceed the level of resources reserved by the tunnel reservation. This event should be treated as an admission control failure, identically to the case where RSVP requests exceed the level of resources available over a hardware link. A RESV_ERR message with Error Code set to 01 (Admission Control failure), should be sent back to the originator of the end-to-end RESV message.
「硬質パイプ」トンネルの場合には、既存の予約によって要求されたリソースのレベルで新しいエンドツーエンド予約または変更は、レベルを超えて、エンドツーエンドの予約が必要とする総リソースレベルを引き起こすことトンネル予約によって予約されたリソースの。このイベントは、同じRSVP要求がハードウェアリンクを介して利用可能なリソースのレベルを超えた場合に、アドミッション制御不良として扱われるべきです。 01（アドミッション制御の失敗）に設定されたエラーコードでRESV_ERRメッセージは、バックエンド・ツー・エンドのRESVメッセージの発信者に送信されるべきです。
If a RESV CONFIRM response arrives, the original RESV is encapsulated and sent through the tunnel. If the updated tunnel reservation fails, Rexit must send a RESV ERR to the originator of the end-to-end RESV message, using the error code and value fields from the ERROR_SPEC object of the received tunnel session RESV ERR message. Note that the pre-existing reservations through the tunnel stay in place. Rexit continues refreshing the tunnel RESV using the old flowspec.
RESV確認応答が到着した場合、元のRESVは、カプセル化、トンネルを介して送信されます。更新されたトンネル予約が失敗した場合、Rexitは、受信したトンネルセッションのRESV ERRメッセージのERROR_SPECオブジェクトからエラーコードと値のフィールドを使用して、エンド・ツー・エンドのRESVメッセージの発信者にRESVのERRを送信しなければなりません。代わりにトンネル滞在を通じて、既存の予約があります。 Rexitは古いフロースペックを使用してトンネルRESVを更新し続けます。
Tunnel session state for a "soft pipe" may also be adjusted when an end-to-end reservation is deleted. The tunnel session gets reduced whenever one of the end-to-end sessions using the tunnel goes away (or gets reduced itself). However even when the last end-to-end session bound to that tunnel goes away, the configured tunnel session remains active, perhaps with a configured minimal flowspec.
エンドツーエンドの予約が削除されたときに「ソフトパイプ」のトンネルセッション状態も調整することができます。トンネルセッションは、トンネルを使用して、エンドツーエンドセッションの1つが消えるたびに減少します（またはそれ自体が減少されます）。そのトンネルにバインドされた最後のエンド・ツー・エンドのセッションが消えた場合でもしかし、設定されたトンネルセッションは、おそらく構成され、最小限のフロースペックで、アクティブのまま。
Note that it will often be appropriate to use some hysteresis in the adjustment of the tunnel reservation parameters, rather than adjusting the tunnel reservation up and down with each arriving or departing end-to-end reservation. Doing this will require the tunnel exit router to keep track of the resources allocated to the tunnel (the tunnel flowspec) and the resources actually in use by end-to-end reservations (the sum or statistical sum of the end-to-end reservation flowspecs) separately.
しばしば、むしろ各到着または出発エンド・ツー・エンドの予約を上下トンネル予約を調整するよりも、トンネル予約パラメータの調整にいくつかのヒステリシスを使用することが適切であろうことに留意されたいです。これを行うと、（エンド・ツー・エンドの予約によって実際に使用中のトンネル（トンネルフロースペック）に割り当てられたリソースとリソースを追跡するために、エンドツーエンド予約の和または統計和をトンネル出口ルーターを必要としますフロースペック）別途。
When an end-to-end RESV TEAR is received by Rexit, it encapsulates and forwards the message to Rentry. If the end-to-end session had created a dynamic tunnel session, then a RESV TEAR for the corresponding tunnel session is send by Rexit.
エンドツーエンドのRESV TEARをRexitによって受信されると、それはカプセル化Rentryにメッセージを転送します。エンドツーエンドのセッションは、動的トンネルセッションを作成した場合、対応するトンネルセッションのためのRESV TEARはRexitによって送信されます。
If the RESV message received is a refresh of an existing reservation then Rentry updates the reservation state and forwards the message upstream. On the other hand, if this is the first RESV message for this end-to-end session and a NODE_CHAR object with the T bit set is present, Rentry should initiate the mapping between this end-to-end session and some (possibly new) tunnel session. This mapping is based on some or all of the contents of the end-to-end PATH message, the contents of the end-to-end RESV message, and local policies. For example, there could be different tunnel sessions based on the bandwidth or delay requirements of end-to-end sessions)
受信したRESVメッセージは、既存の予約のリフレッシュである場合、Rentryは予約状態を更新し、上流のメッセージを転送します。これは、このエンドツーエンドのセッションの最初のRESVメッセージであるとTビットが設定されたNODE_CHARオブジェクトが存在する場合一方、Rentryは、このエンドツーエンドのセッションの間のマッピングを開始し、いくつかなければならない（おそらく新しいです）トンネルセッション。このマッピングは、エンドツーエンドのPATHメッセージの内容は、エンドツーエンドのRESVメッセージの内容、およびローカルポリシーの一部またはすべてに基づいています。例えば、エンドツーエンドのセッションの帯域幅や遅延要件に基づいて異なるトンネルセッションが存在し得ます）
If Rentry decides that this end-to-end session should be mapped to an existing configured tunnel session, it binds this end-to-end session to that tunnel session.
Rentryこのエンドツーエンドのセッションが既存の構成トンネルセッションにマッピングされるべきであると判断した場合、そのトンネルセッションにこのエンドツーエンドセッションに結合します。
If this end-to-end RSVP session is allowed to set up a new tunnel session, Rentry sets up tunnel session PATH state as if it were a source of data by starting to send tunnel-session PATH messages to Rexit, which is treated as the unicast destination of the data. The Tspec in this new PATH message is computed from the original PATH message by adjusting the Tspec parameters to include the tunnel overhead of the encapsulation of data packets. In this case Rentry should also send a PATH message from the end-to-end session this time containing the SESSION_ASSOC object linking the two sessions. The receipt of this PATH message by Rexit will trigger an update of the end-to-end Path state which in turn will have the effect of Rexit sending a tunnel RESV message, allocating resources inside the tunnel.
このエンドツーエンドRSVPセッションが新しいトンネルセッションを設定するために許可されている場合、それはとして扱われるRexitにトンネルセッションPATHメッセージを送信するために開始することによって、データのソースであったかのように、Rentryトンネルセッションパスの状態を設定しますデータのユニキャスト宛先。この新しいPATHメッセージ内のTspecは、データパケットのカプセル化のトンネルオーバーヘッドを含むことのTSPECパラメータを調整することによって、元のPATHメッセージから計算されます。この場合Rentryは、エンドツーエンドのセッションから2つのセッションを連結SESSION_ASSOCオブジェクトを含む今回PATHメッセージを送信する必要があります。 RexitによってこのPATHメッセージの受信は、順番にRexitがトンネル内のリソースを割り当てる、トンネルRESVメッセージを送信する効果を有することになるエンドツーエンドパスの状態の更新をトリガします。
The last case is when the end-to-end session is not allowed to use the tunnel resources. In this case no association is created between this end-to-end session and a tunnel session and no new tunnel session is created.
エンドツーエンドのセッションがトンネルリソースを使用することが許可されていない場合に最後のケースです。この場合には関連は、このエンドツーエンドのセッションとトンネルセッションと新しいトンネルセッションが作成されていない間に作成されません。
One limitation of our scheme is that the first RESV message of an end-to-end session determines the mapping between that end-to-end session and its corresponding session over the tunnel. Moreover as long as the reservation is active this mapping cannot change.
我々の方式の1つの制限は、エンドツーエンドのセッションの最初のRESVメッセージは、エンドツーエンドのセッションとトンネルを介してそれに対応するセッションとの間のマッピングを決定することです。また限り予約がアクティブであるように、このマッピングは変更できません。
When data packets arrive at the tunnel entry point Rentry, Rentry must decide whether to forward the packets using the normal IP-in-IP tunnel encapsulation or the IP+UDP encapsulation expected by the tunnel session. This decision is made by determining whether there is a resource reservation (not just PATH state) actually in place for the tunnel session bound to the arriving packet, that is, whether the packet matches any active filterspec.
データパケットがトンネルエントリポイントRentryに到着すると、Rentryは、通常のIPインIPトンネルカプセル化またはトンネルセッションが期待IP + UDPカプセル化を使用してパケットを転送するかどうかを決定しなければなりません。この決定は、リソース予約（だけでなく、PATH状態）は、パケットが任意のアクティブFilterSpecに一致するかどうかを、ある到着したパケットにバインドされたトンネルセッションのための場所に実際に存在するかどうかを判定することによって行われます。
If a reservation is in place, it means that both Rentry and Rexit are RSVP-tunneling aware routers, and the data will be correctly decapsulated at Rexit.
予約が所定の位置にある場合、それは入口と出口の両方がRSVP-トンネリングを認識ルータであることを意味し、データが正しくRexitでデカプセル化されます。
If no tunnel session reservation is in place, the data should be encapsulated in the tunnel's normal format, regardless of whether end-to-end PATH state covering the data is present.
何トンネルセッションの予約が適所にない場合、データに関係なくデータをカバーするエンドツーエンドパスの状態が存在するかどうかの、トンネルの通常の形式にカプセル化されるべきです。
There may be multiple end-to-end RSVP sessions between the two end points Rentry and Rexit. These sessions are distinguished by the source UDP port. Other components of the session ID, the source and destination IP addresses and the destination UDP port, are identical for all such sessions.
両端点RentryとRexit間の複数のエンドツーエンドRSVPセッションが存在してもよいです。これらのセッションは、送信元UDPポートによって区別されます。セッションID、送信元と送信先のIPアドレスと宛先UDPポートの他の成分には、そのようなすべてのセッションのために同じです。
The source UDP port is chosen by the tunnel entry point Rentry when it establishes the initial PATH state for a new tunnel session. The source UDP port associated with the new session is then conveyed to Rexit by the SESSION_ASSOC object.
それは新しいトンネルセッションの初期パス状態を確立するときに、ソースUDPポートがトンネルエントリポイントRentryによって選択されます。新しいセッションに関連付けられたソースUDPポートが次にSESSION_ASSOCオブジェクトによってRexitに搬送されます。
The destination UDP port used in tunnel sessions should the one assigned by IANA (363).
トンネルセッションで使用される宛先UDPポートは、IANA（363）ずつ割り当てられなければなりません。
When a tunnel session PATH message encounters an error, it is reported back to Rentry. Rentry must relay the error report back to the original source of the end-to-end session.
トンネルセッションPATHメッセージがエラーを検出した場合には、エントリに戻って報告されます。再入場は、エンドツーエンドのセッションの元のソースに戻ってエラーレポートを中継しなければなりません。
When a tunnel session RESV request fails, an error message is returned to Rexit. Rexit must treat this as an error in crossing the logical link (the tunnel) and forward the error message back to the end host.
トンネルセッションRESV要求が失敗した場合、エラーメッセージがRexitに戻されます。 Rexitは、論理リンク（トンネル）を交差にエラーとして扱い、バックエンドホストにエラーメッセージを転送しなければなりません。
Since the UDP encapsulated packets should not be fragmented, tunnel entry routers must support tunnel MTU discovery as discussed in section 5.1 of [IP4INIP4]. Alternatively, the Path MTU Discovery mechanism discussed in RFC 2210 [RFC2210] can be used.
UDPカプセル化されたパケットがフラグメントであってはならないので、[IP4INIP4]のセクション5.1で説明したように、トンネルエントリルータは、トンネルMTUディスカバリをサポートしなければなりません。あるいは、パスMTU発見メカニズムは、RFC 2210 [RFC2210]で説明し使用することができます。
As multiple End-to-End sessions can be mapped to a single tunnel session, there is the need to compute the aggregate Tspec of all the senders of those End-to-End sessions. This aggregate Tspec will the Tspec of the representative tunnel session. The same operation needs to be performed for flowspecs of End-to-End reservations arriving at Rexit.
複数のエンドツーエンドセッションは単一のトンネルセッションにマッピングすることができるように、これらのエンドツーエンドセッションのすべての送信者の集合Tspecはを計算する必要があります。この凝集Tspecは、代表的なトンネルセッションのTspecはあろう。同じ操作をRexitに到着するエンドツーエンドの予約のフロースペックのために実行する必要があります。
The semantics of these operations are not addressed here. The simplest way to do them is to compute a sum of the end-to-end Tspecs, as is defined in the specifications of the Controlled-Load and Guaranteed services (found at [RFC2211] and [RFC2212] respectively). However, it may also be appropriate to compute the aggregate reservation level for the tunnel using a more sophisticated statistical or measurement-based computation.
これらの操作の意味は、ここで扱われていません。それらを行うための最も簡単な方法は、制御負荷と（それぞれ[RFC2211]と[RFC2212]で発見）保証サービスの仕様で定義されているように、エンド・ツー・エンドのTSpecの合計を計算することです。しかし、また、より洗練された統計的または測定ベースの計算を使用してトンネルの集約の予約レベルを計算するために適切であり得ます。
In the case where the IP-in-IP tunnel supports IPSEC (especially ESP in Tunnel-Mode with or without AH) then the Tunnel Session uses the GPI SESSION and GPI SENDER_TEMPLATE/FILTER_SPEC as defined in [RSVPESP] for the PATH and RESV messages.
PATHとRESVメッセージのため[RSVPESP]で定義されるようにIPインIPトンネル（またはAHなしトンネルモードで特にESP）IPSECをサポートする場合には、その後トンネルセッションは、GPI SESSIONおよびGPI SENDER_TEMPLATE / FILTER_SPECを使用します。
Data packets are not encapsulated with a UDP header since the SPI can be used by the intermediate nodes for classification purposes. Notice that user oriented keying must be used between Rentry and Rexit, so that different SPIs are assigned to data packets that have reservation and "best effort" packets, as well as packets that belong to different Tunnel Sessions if those are supported.
SPIは、分類目的のために中間ノードによって使用することができるので、データパケットは、UDPヘッダでカプセル化されていません。そのユーザー指向のキーを注意してください別のSPIのは、データの予約と、「ベストエフォート」パケットを持つパケットだけでなく、それらがサポートされている場合、別のトンネルセッションに属するパケットに割り当てられるように、RentryとRexitの間で使用する必要があります。
The mechanisms described above are useful for unicast tunnels. Unicast tunnels provide logical point-to-point links in the IP infrastructure, though they may encapsulate and carry either unicast or multicast traffic between those points.
上述のメカニズムは、ユニキャストトンネルのために有用です。彼らはカプセル化して、それらの点の間のユニキャストまたはマルチキャストトラフィックを運ぶかもしれませんがユニキャストのトンネルは、IPインフラストラクチャ内の論理ポイントツーポイントリンクを提供します。
Two other types of tunnels may be imagined. The first of these is a "multicast" tunnel. In this type of tunnel, packets arriving at an entry point are encapsulated and transported (multicast) to -all- of the exit points. This sort of tunnel might prove useful for implementing a hierarchical multicast distribution network, or for emulating efficiently some portion of a native multicast distribution tree.
トンネルの他の二つの種類が想像することができます。これらの第一は、「マルチキャスト」トンネルです。トンネルのこのタイプでは、エントリポイントに到着するパケットは、カプセル化され、出口点の-all-する（マルチキャスト）に搬送されます。トンネルのこの種は、階層的なマルチキャスト配信ネットワークを実装する、あるいは効率的にネイティブマルチキャスト配信ツリーの一部をエミュレートするために有用であることが分かるかもしれません。
A second possible type of tunnel is the "multipoint" tunnel. In this type of tunnel, packets arriving at an entry point are normally encapsulated and transported to -one- of the exit points, according to some route selection algorithm.
トンネルの第二の可能なタイプは、「マルチ」トンネルです。トンネルのこのタイプでは、エントリポイントに到着するパケットは、通常、いくつかの経路選択アルゴリズムに従って、出口点の-one-にカプセル化されて搬送されます。
This type of tunnel differs from all previous types in that the ' shape' of the usual data distribution path does not match the 'shape' of the tunnel. The topology of the tunnel does not by itself define the data transmission function that the tunnel performs. Instead, the tunnel becomes a way to express some shared property of the set of connected tunnel endpoints. For example, the "tunnel" may be used to create and embed a logical shared broadcast network within some larger network. In this case the tunnel endpoints are the nodes connected to the logical shared broadcast network. Data traffic may be unicast between two such nodes, broadcast to all connected nodes, or multicast between some subset of the connected nodes. The tunnel itself is used to define a domain in which to manage routing and resource management - essentially a virtual private network.
トンネルのこのタイプは、通常のデータ配信経路の「形状」はトンネルの「形状」と一致しないという点で、以前のすべての種類は異なります。トンネルのトポロジーは、単独でトンネルが実行するデータ送信機能を定義していません。その代わりに、トンネルは、接続されているトンネルエンドポイントの集合のいくつかの共有性を表現するようになります。例えば、「トンネル」を作成し、いくつかの大規模ネットワーク内の論理共有ブロードキャストネットワークを埋め込むために使用されてもよいです。この場合、トンネルエンドポイントは、論理共有ブロードキャストネットワークに接続されたノードです。データトラフィックは、接続されたノードのサブセットとの間のすべての接続されたノード、またはマルチキャストにブロードキャスト、二つのそのようなノード間のユニキャストしてもよいです。本質的に、仮想プライベートネットワーク - トンネル自体は、ルーティングおよびリソース管理を管理するためのドメインを定義するために使用されます。
Note that while a VPN of this form can always be implemented using a multicast tunnel to emulate the broadcast medium, this approach will be very inefficient in the case of wide area VPNs, and a multipoint tunnel with appropriate control mechanisms will be preferable.
この形式のVPNは、常に放送媒体をエミュレートするためにマルチキャストトンネルを使用して実施することができるが、このアプローチは、広域VPNの場合には非常に非効率的になり、適切な制御機構を有するマルチポイントトンネルが好ましいであろうことに留意されたいです。
The following paragraphs provide some brief commentary on the use of RSVP in these situations. Future versions of this note will provide more concrete details and specifications.
次の段落は、このような状況でのRSVPの使用に関するいくつかの簡単な解説を提供しています。このノートの将来のバージョンでは、より具体的な詳細と仕様を提供します。
Using RSVP to provide resource management over a multicast tunnel is relatively straightforward. As in the unicast case, one or more RSVP sessions may be used, and end-to-end RSVP sessions may be mapped onto tunnel RSVP sessions on a many-to-one or one-to-one basis. Unlike the unicast, case, however, the mapping is complicated by RSVP's heterogeneity semantics. If different receivers have made different reservation requests, it may be that the RESV messages arriving at the tunnel would logically map the receiver's requests to different tunnel sessions. Since the data can actually be placed into only one session, the choice of session must be reconciled (merged) to select the one that will meet the needs of all applications. This requires a relatively simple extension to the session mapping mechanism.
マルチキャストトンネル上でリソース管理を提供するために、RSVPを使用することは比較的簡単です。ユニキャストの場合のように、一つ以上のRSVPセッションを使用してもよいし、エンドツーエンドRSVPセッションは、多対1または1対1のトンネルRSVPセッションにマッピングされてもよいです。ユニキャスト、ケースとは異なり、しかし、マッピングは、RSVPの異質セマンティクスによって複雑になります。異なる受信機が異なる予約要求を行った場合、それがトンネルに到着RESVメッセージは、論理的に異なるトンネルセッションに受信者の要求をマップすることかもしれません。データが実際に一つだけのセッションの中に配置することができますので、セッションの選択は、すべてのアプリケーションのニーズを満たすものを選択する（マージ）和解しなければなりません。これは、セッションマッピングメカニズムに比較的簡単な拡張が必要です。
Use of RSVP to support multipoint tunnels is somewhat more difficult. In this case, the goal is to give the tunnel as a whole a specific level of resources. For example, we may wish to emulate a "logical shared 10 megabit Ethernet" rather than a "logical shared Ethernet". However, the problem is complicated by the fact that in this type of tunnel the data does not always go to all tunnel endpoints. This implies that we cannot use the destination address of the encapsulated packets as part of the packet classification filter, because the destination address will vary for different packets within the tunnel.
マルチポイントトンネルをサポートするためのRSVPの使用がやや困難です。この場合、目標は、全体としてトンネルをリソースの特定のレベルを与えることです。たとえば、私たちは「論理共有10メガビット・イーサネット」ではなく「論理共有イーサネット」をエミュレートすることを望むかもしれません。しかし、問題は、トンネルのこのタイプでは、データは常にすべてのトンネルエンドポイントに行かないという事実によって複雑になります。これは、宛先アドレスがトンネル内の異なるパケットのために変化することになるので、我々は、パケット分類フィルタの一部としてカプセル化されたパケットの宛先アドレスを使用することができないことを意味します。
This implies the need for an extension to current RSVP session semantics in which the Session ID (destination IP address) is used -only- to identify the session state within network nodes, but is not used to classify packets. Other than this, the use of RSVP for multipoint tunnels follows that of multicast tunnels. A multicast group is created to represent the set of nodes that are tunnel endpoints, and one or more tunnel RSVP sessions are created to reserve resources for the encapsulated packets. In the case of a tunnel implementing a simple VPN, it is most likely that there will be one session to reserve resources for the whole VPN. Each tunnel endpoint will participate both as a source of PATH messages and a source of (FF or SE) RESV messages for this single session, effectively creating a single shared reservation for the entire logical shared medium. Tunnel endpoints MUST NOT make wildcard reservations over multipoint tunnels.
これは、セッションID（宛先IPアドレス）は、ネットワークノード内のセッションの状態を識別するために-only-使用される現在のRSVPセッションセマンティクスへの拡張の必要性を意味するが、パケットを分類するために使用されていません。これ以外にも、マルチポイントトンネルのためのRSVPの使用は、マルチキャストトンネルのことを次の。マルチキャストグループは、カプセル化されたパケットのためのリソースを確保するために作成されたトンネルエンドポイント、および1つまたは複数のトンネルRSVPセッションであるノードのセットを表すために作成されます。シンプルなVPNの実装トンネルの場合、全体のVPNのためのリソースを確保するために、1つのセッションが存在することになる可能性が最も高いです。各トンネルエンドポイントは、効果的に全体の論理共有媒体用の単一の共有の予約を作成し、PATHメッセージのソースと、この単一のセッションのために（FFまたはSE）RESVメッセージのソースの両方として参加します。トンネルエンドポイントはマルチポイントトンネルを介したワイルドカードの予約をしてはなりません。
The RSVP specification [RFC2205] states that through the RSVP/Routing Interface, the RSVP daemon must be able to learn the list of local interfaces along with their IP addresses. In the RSVP Tunnels case, the RSVP daemon needs also to learn which of the local interface(s) is (are) IP-in-IP tunnel(s) having the capabilities described here. The RSVP daemon can acquire this information, either by directly querying the underlying network and physical layers or by using any existing interface between RSVP and the routing protocol properly extended to provide this information.
RSVP仕様[RFC2205]はRSVP /ルーティングインタフェースを介して、RSVPデーモンは、それらのIPアドレスと共にローカルインタフェースのリストを学習することができなければならないことを述べています。 RSVPトンネル場合に、RSVPデーモンは、ここで説明する機能を有する（ある）IPインIPトンネル（S）であり、ローカルインターフェース（複数可）のどちら学ぶことも必要です。 RSVPデーモンは、直接基礎となるネットワークおよび物理層を照会することによって、またはRSVP、適切にこの情報を提供するように拡張ルーティングプロトコルとの間の既存のインターフェースを使用してのいずれかによって、この情報を取得することができます。
The introduction of RSVP Tunnels raises no new security issues other than those associated with the use of RSVP and tunnels. Regarding RSVP, the major issue is the need to control and authenticate access to enhanced qualities of service. This requirement is discussed further in [RFC2205]. [RSVPCRYPTO] describes the mechanism used to protect the integrity of RSVP messages carrying the information described here. The security issues associated with IP-in-IP tunnels are discussed in [IPINIP4] and [IPV6GEN].
RSVPトンネルの導入は、RSVPやトンネルの使用に関連したもの以外のどんな新しい安全保障問題も提起しません。 RSVPについては、大きな問題は、サービスの強化品質へのアクセスを制御し、認証する必要があります。この要件は、[RFC2205]で詳しく説明されています。 [RSVPCRYPTO]ここに記載された情報を運ぶRSVPメッセージの完全性を保護するために使用されるメカニズムを説明しています。 IPインIPトンネルに関連するセキュリティ問題は[IPV6GEN] [IPINIP4]で論じられています。
IANA should assign a Class number for the NODE_CHAR object defined in Section 3.3.2. This number should be in the 10bbbbbb range. The suggested value is 128.
IANAは、3.3.2項で定義されたNODE_CHARオブジェクトのクラス番号を割り当てる必要があります。この数は、10bbbbbbの範囲内であるべきです。推奨値は128です。
We thank Bob Braden for his insightful comments that helped us to produce this updated version of the document.
私たちは、ドキュメントのこの更新されたバージョンを生成するために私たちを助けた彼の洞察に満ちたコメントをボブブレーデンに感謝します。
[ESP] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827, August 1995.
[ESP]アトキンソン、R.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 1827、1995年8月。
[IP4INIP4] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[IP4INIP4]パーキンス、C.、 "IP内IPカプセル化"、RFC 2003、1996年10月。
[IPV6GEN] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
【IPV6GEN]コンタ、A.、およびS.デアリング、 "IPv6の仕様の汎用パケットトンネリング"、RFC 2473、1998年12月。
[MINENC] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[MINENC]パーキンス、C.、 "IP内の最小カプセル化"、RFC 2004、1996年10月。
[RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[RFC1701]ハンクス、S.、李、T.、ファリナッチ、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]ハンクス、S.、李、T.、ファリナッチ、D.とP. Trainaの、 "IPv4ネットワーク上総称ルーティングカプセル化"、RFC 1702、1994年10月。
[RFC1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996.
[RFC1933]ギリガン、R.およびE. Nordmarkと、 "IPv6ホストとルータの移行メカニズム"、RFC 1933、1996年4月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J.、RFC 2210、1997年9月 "IETF統合サービスとRSVPの使用"。
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[RFC2211] Wroclawski、J.、 "制御負荷ネットワーク要素サービスの仕様"、RFC 2211、1997年9月。
[RFC2212] Shenker, S., Partridge, C. and R. Guerin, "Specification of the Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC2212] Shenker、S.、ヤマウズラ、C.とR.ゲラン、 "保証されたサービスの質の仕様"、RFC 2212、1997年9月。
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.とS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"、RFC 2205、1997年9月。
[RSVPESP] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
[RSVPESP]バーガー、L.とT.オマリー、 "IPSECデータフローのためのRSVP拡張機能"、RFC 2207、1997年9月。
[RSVPCRYPTO] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
【RSVPCRYPTO]ベーカー、F.、リンデル、B.及びM. Talwar、 "RSVP暗号化認証"、RFC 2747、2000年1月。
John Krawczyk ArrowPoint Communications 50 Nagog Park Acton, MA 01720
ジョンKrawczykアローポイントコミュニケーションズ50 Nagogパークアクトン、MA 01720
Phone: 978-206-3027 EMail: jj@arrowpoint.com
電話：978-206-3027 Eメール：jj@arrowpoint.com
John Wroclawski MIT Laboratory for Computer Science 545 Technology Sq. Cambridge, MA 02139
コンピュータサイエンス545平方技術のためのジョンWroclawski MIT研究所。ケンブリッジ、MA 02139
Phone: 617-253-7885 Fax: 617-253-2673 EMail: jtw@lcs.mit.edu
電話：617-253-7885ファックス：617-253-2673 Eメール：jtw@lcs.mit.edu
Lixia Zhang UCLA 4531G Boelter Hall Los Angeles, CA 90095
L I老人張UCLA 4531ギガバイトOEホールロサンゼルス、CA 90095
Phone: 310-825-2695 EMail: lixia@cs.ucla.edu
電話：310-825-2695 Eメール：lixia@cs.ucla.edu
Andreas Terzis UCLA 4677 Boelter Hall Los Angeles, CA 90095
アンドレアスTerzis UCLA 4677 Boelterホールロサンゼルス、CA 90095
Phone: 310-267-2190 EMail: terzis@cs.ucla.edu
電話：310-267-2190 Eメール：terzis@cs.ucla.edu
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。