[要約] RFC 2746は、IPトンネル上でのRSVP（Resource Reservation Protocol）の動作に関する仕様です。このRFCの目的は、RSVPを使用してトンネル上でのリソース予約を可能にするための手順と要件を定義することです。
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
IPトンネル上のRSVP操作
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.
Copyright（c）The Internet Society（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-in-IP「トンネル」は、インターネットでデータグラムを輸送するための広範なメカニズムになっています。通常、トンネルは、目的のサービス（IPv6など）を直接実装していないネットワークの一部を介してパケットをルーティングしたり、展開されたルーティングアーキテクチャの動作を増強したり変更したりするために使用されます（例：マルチキャストルーティング、モバイルIP、仮想プライベートネット）。
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 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.
今日、多くのIP-in-IPトンネルプロトコルが存在しています。[IP4INIP4]は、追加のIPv4ヘッダーを使用してトンネリングの方法を詳述します。[Minenc]は、元のデータグラムが断片化されていない場合に[IP4INIP4]で使用される「内部」IPヘッダーのサイズを縮小する方法を説明しています。[IPv6Gen]の一般的なトンネルメソッドを使用して、IPv6内のIPv4またはIPv6パケットのいずれかをトンネル化できます。[RFC1933]は、IPv4ネットワークを介してIPv6データグラムをトンネルする方法について説明しています。[RFC1701]は、一般的なルーティングカプセル化について説明し、[RFC1702]はこのカプセル化をIPv4に適用します。最後に、[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を拡張するように設計されたフレームワークの1つのコンポーネントです。このテクノロジーを最大限の柔軟性で展開するには、トンネルがネットワーク内の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トンネルと呼びます。タイプ3トンネルとタイプ2トンネルを区別する重要な機能は、タイプ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のトンネルは、トンネルのエンドポイントを含むルーターの少なくとも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.
トンネルの2つのエンドポイントがトンネル上で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-in-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-in-IPトンネルスキームと共存しています。* RSVP仕様の変更を最小限に制限する。*トンネルの2つのエンドポイントのみに必要な変更を制限します。この要件により、展開が簡単になり、中間ルーターのオーバーヘッドが低くなり、ルーティングの変更により中間ルーターのセットが変更された場合の故障の可能性が低くなります。*トンネル上および非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を再帰的に適用することです。この新しいセッションでは、トンネルのエントリポイントレントリーがパスメッセージを送信し、トンネル出口ポイント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.
デザインの次の2つの異なる側面について説明します。RSVP機能を備えたIP-in-IPトンネルを強化する方法と、エンドツーエンドのRSVPセッションをトンネルセッションにマッピングする方法について説明します。
To establish a RSVP reservation over a unicast IP-in-IP tunnel, we made the following design decisions:
ユニキャストIP-in-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つのエンドポイント間の1つまたは複数の固定フィルタースタイルのユニキャスト予約は、トンネルを横断するパケットのリソースを予約するために使用されます。タイプ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.
予約を必要としないパケットは、通常の方法でカプセル化されます。g。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ヘッダーを準備してこのようなデータパケットをカプセル化し、UDPポート番号を使用して異なるRSVPセッションのパケットを区別することを選択します。この場合の外側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を示しています。レンタリーは、トンネルへのデータをカプセル化するトンネルエントリルーターです。レンタリーによって追加されたカプセル化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は、レンタリーから1つまたは複数のIPホップを離れている場合があります。受信ホストH2およびH4は、Rexitから1つまたは複数のIPホップを離れている場合もあります。
H1 H2
: :
: :
+--------+ +---+ +---+ +---+ +-------+
| | | | | | | | | |
H3... | Rentry |===================================| Rexit |..... H4
| | | | | | | | | |
+--------+ +---+ +---+ +---+ +-------+
Figure 2: An example end-to-end path with a tunnel in the middle.
図2：中央にトンネルがあるエンドツーエンドのパスの例。
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.
ホストH1とH2のエンドポイントの間にRSVPセッションが導入される場合があります。このセッションを「エンドツーエンド」（略してE2E）または「オリジナル」セッションと呼び、そのパスとRESVメッセージをエンドツーエンドのメッセージと呼びます。トンネル上のリソース予約を提供するために、レンタリーとRexitの間に1つ以上のRSVPセッションが整っている場合があります。これらをトンネルRSVPセッションと呼び、トンネルまたはトンネリングメッセージとしてパスとRESVメッセージを参照します。トンネルRSVPセッションは、エンドツーエンドのセッションとは独立して存在する場合があります。たとえば、ネットワーク管理インターフェイスを介してトンネル上でRSVPセッションを作成して、H3からH4へのデータフローのQOSサポートを提供する場合がありますが、H3とH4の間にエンドツーエンドの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 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).
エンドツーエンドのRSVPセッションがRSVP対応トンネルを越えた場合、トンネル上のエンドツーエンドの予約をサポートするメカニズムを設計する際に、E2Eセッションを既存のトンネルRSVPセッションにマッピングすることを検討する2つのケースがあります（タイプタイプ2トンネル）、および各エンドツーエンドセッション（タイプ3トンネル）の新しいトンネルRSVPセッションを動的に作成します。どちらの場合でも、写真はRSVPの再帰的アプリケーションのように見えます。トンネルRSVPセッションでは、2つのトンネルエンドポイントを2つのエンドホストとして表示します。オリジナルのエンドツーエンドのRSVPセッションでは、トンネルをソースと宛先の間のパス上の単一の（論理）リンクとして表示します。
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対応トンネルを越えた場合、2つの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-in-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セッションが1つしかない場合、すべてのエンドツーエンドのRSVPセッション（このトンネルセッションを使用することが許可されている）は、この構成されたトンネルセッションにバインドされます。ただし、IPトンネルで複数のRSVPセッションが使用されている場合、2番目の設計上の問題は、元のRSVP予約とトンネル予約の間の関連性または拘束力が、トンネルの一方の端から他方の端から伝達される方法です。エントリルーターレンタリーと出口ルーターのレキシットは、これらの関連付けに同意する必要があります。これにより、元の予約状態の変更をトンネル予約状態の変更に正しくマッピングでき、トンネルエンドポイントに中間ルーターによって報告されたエラーを正しく変換できます。エンドツーエンドの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つのルーターレンタリーと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.エンドツーエンドセッションをトンネルセッションの1つと関連付け、レンタリーでエンドツーエンドパスメッセージに添付する新しいRSVPオブジェクトを定義します。この新しいオブジェクトは、レクシットセッションをレンタリーで生成したトンネルセッションの1つに関連付けることによって解釈されます。3.セッションのデータパケットと同じUDPカプセル化をエンドツーエンドのパスメッセージに適用します。RexitがPATHメッセージを脱カプセル化すると、カプセル化で使用されるソースUDPポートと、元のパスメッセージで指定されたRSVPセッションとの関係を推測します。
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.
上記の最後のアプローチでは、新しいデザインは必要ありません。ただし、パスメッセージのために追加のリソースを予約する必要があります（現在、トンネル予約の対象となるため）。また、RexitがUDPカプセル化によりトンネルよりもRSVPをサポートするかどうかの先験的な知識が必要です。RentryがUDPカプセル化を使用してすべてのエンドツーエンドパスメッセージをカプセル化するが、Rexitがこのカプセル化を理解していない場合、カプセル化されたパスメッセージは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）はこのケースを透過的に処理できます。それらは、トンネルパスをすべて追加の構成なしで捨てながら、レキシットがトンネルを介して受信したエンドツーエンドパスを通過することを可能にします（通常は脱カプセル化されているため）。より単純なため、オプション（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. レンタリーはカプセル化してエンドツーエンドのパスメッセージをトンネル上に送信して、脱カプセル化して下流に転送されます。2.対応するエンドツーエンドのRESVメッセージがRexitに到着すると、Rexitはそれをカプセル化し、レンタリーに送信します。3.エンドツーエンドのパスメッセージの一部またはすべての情報、エンドツーエンドのRESVメッセージおよびローカルポリシーのFlowsPecに基づいて、Rentryはエンドツーエンドセッションをにマッピングするかどうか、および方法を決定します。トンネルセッション。4.エンドツーエンドセッションをトンネルセッションにマッピングする必要がある場合、レンタリーは新しいトンネルセッションのパスメッセージを送信するか、既存のトンネルセッションを更新します。5.レンタリーは、上記のトンネルセッションにエンドツーエンドセッションを関連付けるセッション_ASSOCオブジェクトを含むE2Eパスを送信します。Rexitは、パスメッセージをさらに転送する前に、アソシエーションを記録し、オブジェクトを削除します。6. Rexitは、トンネルRESVメッセージを送信し、トンネル内のリソースを予約することにより、トンネルパスメッセージに応答します。7. Rentry UDP-Enculsは、パケットの対応するトンネルセッションの予約が実際に整っている場合にのみ、到着パケットをカプセル化します。
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
セッションオブジェクト
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.
オブジェクトに含まれるエンドツーエンドセッションは、以下に定義されている送信者フィルタースペックによって説明されているトンネルセッションにマッピングされます。
Sender 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.
これは、上記のエンドツーエンドのセッションがトンネルを越えてマップするトンネルセッションです。上で述べたように、トンネルセッションは主にソースポートによって識別されます。これが、セッションオブジェクトの代わりに、トンネルセッションに送信者フィルタースペックを使用する理由です。
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がこのドキュメントで説明されているスキームをサポートするトンネルエンドポイントであるという事実をレンタルするために通信するための方法（構成以外）が必要です。このため、Node_Charと呼ばれる新しいオブジェクトを定義し、この情報を伝えました。ノードがこのオブジェクトを受信したが理解していない場合、エラーレポートを作成せずにドロップする必要があります。class-num = 10bbbbbbb（ `b 'は少し表します）を持つオブジェクトは、RSVP仕様[RFC2205]で定義されているように、必要な特性を持っています。今のところ、このオブジェクトは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がエンドツーエンドの予約を受信すると、tビットセットを使用してnode_charオブジェクトをRESVオブジェクトに追加すると、それをカプセル化してレンタリーに送信します。RentryがこのRESVメッセージを受信すると、Rexitがここで説明されているメカニズムを実装し、トンネルセッションを作成または調整し、Session_Assocオブジェクトを介してトンネルセッションをエンドツーエンドセッションに関連付けます。RESVメッセージを上流に転送する前に、Rentryはnode_charオブジェクトを削除する必要があります。一方、レンタリーが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つのトンネルエンドポイントをソースおよび宛先ホストとして扱うと、1つはその間にFFスタイルの予約を簡単に設定できます。ここで、問題は、トンネルの予約にどのような種類のフィルターペックを使用するかということです。これは、パケットがトンネル上にカプセル化される方法に直接関係しています。以下の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-in-IPカプセル化を使用できます。トンネル上のRSVPセッションでは、FFスタイルの予約（ゼロポート番号付き）をソースアドレスとして、宛先アドレスとしてRexitを指定します。
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フィルタースペック処理を使用できます。
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つのトンネルセッションに結合すると、マッピングされたエンドツーエンドセッションに対応するために、トンネル予約のサイズをいつ、どのように調整する必要があるかについての新しい問題が発生します。繰り返しますが、トンネルマネージャーはそのような政策決定を下します。いくつかのシナリオが可能です。最初に、トンネルの予約が調整されることはありません。これにより、トンネルは固定容量のハードウェアリンクに相当する大まかなになります。2番目では、新しいエンドツーエンドの予約が到着したり、古いものが取り壊されたりするたびに、トンネル予約が調整されます。3番目では、エンドツーエンドの予約レベルが調整を保証するのに十分な変更があれば、トンネル予約が時々上または下向きに調整されます。これにより、コントロールトラフィックとオーバーヘッドの削減のために、トンネルでの追加のリソース使用量がオフになります。
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セッションのケースに基づいて構築することは簡単です。この場合、Rentryは適切なUDPポート番号を使用してデータパケットを慎重にカプセル化する必要があります。そのため、さまざまなトンネルセッションに属するパケットは、中間RSVPルーターによって区別されます。このケースと前に説明したケースは、タイプ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.
この場合、これ以上言う必要はありません。レンタリーはパケットを分類し、それに応じてそれらをカプセル化します。予約なしのパケットは、外側のIPヘッダーのみでカプセル化されますが、予約の資格のあるパケットは、UDPヘッダーと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セッションを対応するトンネルセッションに明示的にバインドする必要があります。前述のように、このバインディングは、エンドツーエンドのパスメッセージによって運ばれる新しい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で説明されている場合に許可されている可能性のあるマッピングとは対照的に、エンドツーエンドとトンネルの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.
ここでは、1つ以上のRSVPセッションが管理インターフェイスを介してトンネル上に設定されます。「ハードパイプ」トンネルのセッション予約パラメーターは決して変更されません。「ソフトパイプ」トンネルの予約パラメーターが変更される場合があります。レンタリーによって生成されたトンネルセッションパスメッセージは、処理および削除された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:
エンドツーエンドのパスメッセージを転送するとき、トンネルのエントリポイントであるレンタリーとして機能するルーターは、パスメッセージに記載されているエンドツーエンドセッションに応じて、次のアクションを実行します。可能な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.エンドツーエンドのパスメッセージは、新しいエンドツーエンドセッションからのものです。
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.
パスメッセージが以前に既知のエンドツーエンドセッションの更新である場合、レンタリーはエンドツーエンドセッションのパス状態を再リッシュし、このセッションがトンネルセッションにマッピングされているかどうかを確認します。この場合、Rentryがエンドツーエンドセッションをリフレッシュする場合、このセッションを対応するトンネルセッションにリンクするセッション_Assocオブジェクトにエンドツーエンドパスメッセージに含まれます。メッセージを送信して、トンネルを介してRexitに送信します。トンネルセッションが動的に作成された場合、エンドツーエンドのパスメッセージは、レンタリーのローカルトンネル状態とエンドツーエンドセッションのリフレッシュとして機能します。
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.
それ以外の場合、パスメッセージがまだトンネルセッションにマッピングされていない新しいエンドツーエンドセッションからのものである場合、レンタリーは、この新しいセッションのパス状態を作成し、発信インターフェイスをトンネルインターフェイスに設定します。その後、Rentryはパスメッセージをカプセル化し、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.
エンドツーエンドのパスの裂け目がレンタリーによって受信されると、このノードはメッセージをカプセル化して転送します。このエンドツーエンドのセッションにトンネルセッションに1対1のマッピングがある場合、またはこれがトンネルセッションへの多くのエンドツーエンドセッションマッピングの最後の1つである場合、レンタリーは送信してトンネルセッションを引き裂きますそのセッションが再拡張するためのパス裂け目。一方、トンネルセッションにマッピングするエンドツーエンドのセッションが残っている場合、レントリーはトンネルセッションのTSPECを調整するトンネルパスメッセージを送信します。
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:
カプセル化されたエンドツーエンドのパスメッセージは脱カプセル化され、Rexitで処理されます。エンドツーエンドのパスメッセージに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. エンドツーエンドのパスメッセージにsession_assocオブジェクトが含まれていない場合、レンタリーはこのエンドツーエンドの送信者のために保存されているパス状態にnon_rsvpフラグを設定し、ADSPECにグローバルブレークビットを設定し、パケットを下流に転送します。あるいは、トンネルセッションが存在し、いずれもnon_rsvpフラグセットがない場合、rexitは既存のトンネルセッションから最悪のパスADSPECパラメーションを選択し、これらの値を使用してエンドツーエンドの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. パスメッセージにセッション_Assocオブジェクトが含まれており、このエンドツーエンドセッションの関連性が既に存在しない場合、Rexitはエンドツーエンドセッションとオブジェクトによって記述されたトンネルセッションとの間の関連を記録します。エンドツーエンドのパスがトンネルパスメッセージが届く前に早く到着した場合、トンネルセッションのRexitでパス状態を作成します。トンネルセッションの実際のパスメッセージが到着すると、既存のパス状態の更新として扱われ、欠落している情報が更新されます。この状況は、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は、対応するトンネルセッションの記録された状態を見つけ、トンネルセッションの非_RSVPビットがオンになった場合、エンドツーエンドパス状態で非_RSVPフラグをオンにします。エンドツーエンドのパスメッセージにADSPECオブジェクトが搭載されている場合、RexitはADSPECに含まれる特性評価パラメーターの構成を実行します。これは、トンネルセッションの全体的な（構成）特性評価パラメーターを、トンネルによって実装された論理リンクのローカルパラメーターとして検討し、各パラメーターの定義された構成関数を実行することにより、これらのパラメーターをエンドツーエンドADSPECのパラメーターと構成することにより、これを行います。論理リンクの特性評価パラメーターでは、最小パスレイテンシはカプセル化/脱カプセル化遅延を考慮し、帯域幅の推定値は、追加のUDPヘッダーの追加によって引き起こされる利用可能な帯域幅の減少を表すことができます。ADSPECと構成関数については、[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はエンドツーエンドセッションの予約に一致するレンタリーにトンネル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にはトンネルのパス状態がありません。この場合、Rexitは、脱カプセル化されたエンドツーエンドパスメッセージのグローバルなブレークビットをオンにするだけで、それを転送します。
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：REXITは、RESVメッセージに記載されているエンドツーエンドセッションにバインドされたトンネルセッションがあるかどうかを判断する必要があります。そうでない場合、トンネルは非RSVPリンクとして扱われ、Rexitはtビットセットでnode_charオブジェクトをRESVメッセージに追加し、トンネルインターフェイス（通常のIPデータグラムとしてカプセル化され、レンタリーに転送されます。）。
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はトンネルインターフェイスを介して元のRESVを送信します（node_charオブジェクトを追加した後）。動的なトンネルセッションの場合、エンドツーエンドの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 FlowsPecパラメーターの変更を引き起こす場合、トンネルセッションのFlowsPecパラメーターを変更する試みをトリガーする可能性もあります。この場合、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メッセージの発信元にREXIT ERRを送信する必要があります。トンネルを介した既存の予約は、所定の位置にとどまることに注意してください。Rexitは、古いFlowsPecを使用してトンネル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つがなくなると、トンネルセッションが削減されます（または自体が減少します）。ただし、そのトンネルに縛られた最後のエンドツーエンドセッションがなくなった場合でも、構成されたトンネルセッションは、おそらく構成された最小限のFlowsPecでアクティブのままです。
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.
トンネルの予約を上下に調整するのではなく、トンネル予約パラメーターの調整にヒステリシスを使用することがしばしば適切であることに注意してください。これを行うには、トンネル出口ルーターがトンネルに割り当てられたリソース（トンネルフローペック）とエンドツーエンドの予約（エンドツーエンド予約の合計または統計的合計）を追跡するために必要です。FlowsPecs）別々に。
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の裂傷がRexitによって受信されると、メッセージをレンタリーにカプセル化して転送します。エンドツーエンドのセッションで動的なトンネルセッションが作成された場合、対応するトンネルセッションのRESV涙がRexitによって送信されます。
4.2.4. Handling of End-to-End RESV Messages at Rentry.
4.2.4. レンタリーでのエンドツーエンドのRESVメッセージの処理。
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メッセージが既存の予約の更新である場合、レンタリーは予約状態を更新し、メッセージを上流に転送します。一方、これがこのエンドツーエンドセッションの最初のRESVメッセージであり、tビットセットを備えたnode_charオブジェクトが存在する場合、レンタリーはこのエンドツーエンドセッションと一部（おそらく新しい）の間のマッピングを開始する必要があります）トンネルセッション。このマッピングは、エンドツーエンドのパスメッセージの内容、エンドツーエンドの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に送信し始めることにより、データのソースであるかのように設定します。データのユニキャスト宛先。この新しいパスメッセージのTSPECは、TSPECパラメーターを調整してデータパケットのカプセル化のトンネルオーバーヘッドを含めることにより、元のパスメッセージから計算されます。この場合、Rentryはまた、2つのセッションをリンクするSession_Assocオブジェクトを含むエンドツーエンドセッションからパスメッセージを送信する必要があります。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.
データパケットがトンネルエントリポイントレンタリーに到着すると、レンタリーは、通常のIP-in-IPトンネルのカプセル化を使用してパケットを転送するか、トンネルセッションで予想されるIP UDPカプセル化を使用してパケットを転送するかどうかを決定する必要があります。この決定は、到着パケットに縛られたトンネルセッションのリソース予約（パス状態だけでなく）が実際に設置されているかどうか、つまりパケットがアクティブなフィルターピックと一致するかどうかを判断することによって行われます。
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.
予約が施行されている場合、レンタリーと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.
2つのエンドポイントレントリーと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ポートは、新しいトンネルセッションの初期パス状態を確立するときに、トンネルエントリポイントレンタリーによって選択されます。新しいセッションに関連付けられたソース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.
トンネルセッションパスメッセージがエラーに遭遇すると、レンタリーに報告されます。レンタリーは、エラーレポートをエンドツーエンドセッションの元のソースに戻す必要があります。
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発見をサポートする必要があります。あるいは、RFC 2210 [RFC2210]で説明されているPATH MTU発見メカニズムを使用できます。
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に到着するエンドツーエンドの予約のFlowspecについて、同じ操作を実行する必要があります。
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.
IP-in-IPトンネルがIPSEC（特にAHの有無にかかわらずトンネルモードのESP）をサポートする場合、トンネルセッションは、パスとRESVメッセージの[rsvpesp]で定義されているGPIセッションと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ヘッダーでカプセル化されていません。レンタリーとRexitの間にユーザー指向のキーイングを使用する必要があることに注意してください。そうすれば、異なるSPIが予約と「最良の努力」パケット、およびサポートされている場合は異なるトンネルセッションに属するパケットに割り当てられます。
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.
他の2つのタイプのトンネルが想像される場合があります。これらの最初は「マルチキャスト」トンネルです。このタイプのトンネルでは、エントリポイントに到達するパケットがカプセル化され、出口ポイントのすべてに輸送（マルチキャスト）が輸送されます。この種のトンネルは、階層的なマルチキャスト配信ネットワークを実装したり、ネイティブマルチキャスト分布ツリーの一部の一部を効率的にエミュレートするのに役立つ可能性があります。
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.
2番目のタイプのトンネルは、「マルチポイント」トンネルです。このタイプのトンネルでは、エントリポイントに到着するパケットは通常、カプセル化され、いくつかのルート選択アルゴリズムに従って、出口ポイントの-1枚に輸送されます。
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.
このタイプのトンネルは、通常のデータ分布パスの「形状」がトンネルの「形状」と一致しないという点で、以前のすべてのタイプとは異なります。トンネルのトポロジは、トンネルが実行するデータ送信機能をそれ自体で定義していません。代わりに、トンネルは、接続されたトンネルエンドポイントのセットの共有プロパティを表現する方法になります。たとえば、「トンネル」を使用して、いくつかのより大きなネットワーク内に論理共有放送ネットワークを作成および埋め込むことができます。この場合、トンネルのエンドポイントは、論理共有放送ネットワークに接続されたノードです。データトラフィックは、このような2つのノード間でユニキャストされ、接続されたすべてのノードにブロードキャストするか、接続されたノードの一部のサブセット間でマルチキャストにすることができます。トンネル自体は、ルーティングとリソース管理を管理するドメインを定義するために使用されます。これは、本質的に仮想プライベートネットワークです。
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を使用して、マルチキャストトンネルでリソース管理を提供することは比較的簡単です。ユニキャストの場合と同様に、1つ以上のRSVPセッションを使用する場合があり、エンドツーエンドのRSVPセッションは、多面または1対1のベースでトンネルRSVPセッションにマッピングされる場合があります。ただし、ユニキャストの場合とは異なり、マッピングはRSVPの不均一性セマンティクスによって複雑になります。異なるレシーバーが異なる予約リクエストを行った場合、トンネルに到着するRESVメッセージがレシーバーの要求を異なるトンネルセッションに論理的にマッピングする可能性があります。データは実際に1つのセッションのみに配置できるため、すべてのアプリケーションのニーズを満たすものを選択するために、セッションの選択を調整（マージ）する必要があります。これには、セッションマッピングメカニズムに対する比較的単純な拡張が必要です。
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アドレス）がネットワークノード内のセッション状態を識別するために使用されるが、パケットの分類には使用されない現在のRSVPセッションセマンティクスの拡張機能の必要性を意味します。これ以外に、マルチポイントトンネルにRSVPを使用すると、マルチキャストトンネルの使用が続きます。マルチキャストグループは、トンネルエンドポイントであるノードのセットを表すために作成され、カプセル化されたパケットのリソースを予約するために1つ以上のトンネルRSVPセッションが作成されます。単純なVPNを実装するトンネルの場合、VPN全体のリソースを予約するセッションが1つある可能性が最も高いです。各トンネルエンドポイントは、この単一セッションのパスメッセージのソースと（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デーモンは、ここで説明されている機能を持つローカルインターフェイスのどれが（s）IP-in-IPトンネルであるかを学習する必要があります。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-in-IPトンネルに関連するセキュリティの問題は、[IPINIP4]および[IPv6Gen]で説明されています。
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.
この更新されたバージョンのドキュメントを作成するのに役立った彼の洞察に富んだコメントをしてくれたBob Bradenに感謝します。
[ESP] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827, August 1995.
[ESP] Atkinson、R。、「セキュリティペイロードをカプセル化するIP（ESP）」、RFC 1827、1995年8月。
[IP4INIP4] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[IP4INIP4] Perkins、C。、「IP内のIPカプセル化」、RFC 2003、1996年10月。
[IPV6GEN] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[IPv6Gen] Conta、A。およびS. Deering、「IPv6仕様の一般的なパケットトンネル」、RFC 2473、1998年12月。
[MINENC] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[Minenc] Perkins、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] Hanks、S.、Li、T.、Farinacci、D。、およびP. Traina、「Generic Routing Cancapstulation（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月。
[RFC1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996.
[RFC1933] Gilligan、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。、「IETF統合サービスでのRSVPの使用」、RFC 2210、1997年9月。
[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.、Partridge、C。およびR. Guerin、「保証されたサービス品質の仕様」、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] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[RSVPESP] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
[RSVPESP] Berger、L。およびT. O'Malley、「IPSECデータフローのRSVP拡張」、RFC 2207、1997年9月。
[RSVPCRYPTO] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RSVPCRYPTO] Baker、F.、Lindell、B。、およびM. Talwar、「RSVP暗号認証」、RFC 2747、2000年1月。
John Krawczyk ArrowPoint Communications 50 Nagog Park Acton, MA 01720
John Krawczyk Arrowpoint Communications 50 Nagog Park Acton、MA 01720
Phone: 978-206-3027 EMail: jj@arrowpoint.com
電話：978-206-3027メール：jj@arrowpoint.com
John Wroclawski MIT Laboratory for Computer Science 545 Technology Sq. Cambridge, MA 02139
コンピューターサイエンスのためのJohn Wroclawski MIT Laboratory 545 Technology Sq。ケンブリッジ、マサチューセッツ州02139
Phone: 617-253-7885 Fax: 617-253-2673 EMail: jtw@lcs.mit.edu
電話：617-253-7885ファックス：617-253-2673メール：jtw@lcs.mit.edu
Lixia Zhang UCLA 4531G Boelter Hall Los Angeles, CA 90095
Lixia Zhang UCLA 4531G Boelter Hall Los Angeles、CA 90095
Phone: 310-825-2695 EMail: lixia@cs.ucla.edu
電話：310-825-2695メール：lixia@cs.ucla.edu
Andreas Terzis UCLA 4677 Boelter Hall Los Angeles, CA 90095
Andreas Terzis UCLA 4677 Boelter Hall Los Angeles、CA 90095
Phone: 310-267-2190 EMail: terzis@cs.ucla.edu
電話：310-267-2190メール：terzis@cs.ucla.edu
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。