RFC2746 日本語訳
2746 RSVP Operation Over IP Tunnels. A. Terzis, J. Krawczyk, J.Wroclawski, L. Zhang. January 2000. (Format: TXT=58094 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
Terzisがコメントのために要求するワーキンググループA.をネットワークでつないでください: 2746年のUCLAカテゴリ: 標準化過程J.Krawczyk ArrowPointコミュニケーションJ.Wroclawski MIT LCS L.チャンUCLA2000年1月
RSVP Operation Over IP Tunnels
IP Tunnelsの上のRSVP操作
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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に供給するためのアプローチについて説明します。 私たちは簡潔に問題、可能なソリューションの特性、および私たちのアプローチのデザイン目標について説明します。 そして、私たちは私たちのデザイン目標を達成する実装の詳細を提示します。
1. Introduction
1. 序論
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、Virtual兵士のNet)の振舞いを必要なサービスが(例えば、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ヘッダーのサイズを減少させる方法を述べます。 IPv6の中でIPv4かIPv6パケットのどちらかにトンネルを堀るのに[IPV6GEN]のジェネリックトンネリングメソッドを使用できます。 [RFC1933]はIPv6にトンネルを堀る方法を説明します。
Terzis, et al. Standards Track [Page 1] RFC 2746 RSVP Operation Over IP Tunnels January 2000
Terzis、他 IPの上の標準化過程[1ページ]RFC2746RSVP操作は2000年1月にトンネルを堀ります。
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ネットワークを通したデータグラム。 [RFC1701]は一般ルーティングのカプセル化について説明しますが、[RFC1702]はこのカプセル化をIPv4に適用します。 最終的に、[超能力]は暗号化された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つの方法の1つで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つが私たちがここで説明する体系をサポートしないとき、タイプ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,
トンネルの2つのエンドポイントがトンネルの上でRSVPをサポートすることができるとき、トンネルに沿って適切なリソースを予約して頂きたいと思います。 状況の要件によって、これは、あるクライアントのデータフローが、より大きい集合条件(2つのトンネルをタイプする)かそんなにことによるとaに新しい状態で置かれることを意味するかもしれません。
Terzis, et al. Standards Track [Page 2] RFC 2746 RSVP Operation Over IP Tunnels January 2000
Terzis、他 IPの上の標準化過程[2ページ]RFC2746RSVP操作は2000年1月にトンネルを堀ります。
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.
データフローのために別々の予約をします(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カプセル化のための4である)以外のプロトコル番号を持っている外側のIPヘッダーと共にカプセル化されて、Router-警戒オプションを運びません、2つのトンネル終点の間でそれらを実際にはRSVPルータに「目に見えません」して。 そのうえ、現在のIPにおけるIPカプセル化体系は外部のラッパーとしてIPヘッダーだけを加えます。 予約を使用するパケットとそうしないそれらを見分けるか、またはそれらがトンネルにある間異なったRSVPセッションズのものであるパケットを差別化するのが不可能です、UDPポートの情報を区別しないのがカプセル化で利用可能であるので。
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と統合サービスフレームワークの他の部品の両方への最小量の変化を必要とします。
2. The Design
2. デザイン
2.1. Design Goals
2.1. デザイン目標
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仕様に制限します。 * 必要な改革をトンネルの2つのエンドポイントだけに制限します。 中間的ルータのセットがルーティングのため変更されるとき、より簡単な展開への先導、中間的ルータにおける低いオーバーヘッド、および以下がやってみる失敗のこの要件は変化します。 * トンネルの上でRSVPを扱うためにアップグレードしていないRSVPルータと非RSVPトンネル終点ルータで正しい相互操作をサポートします。 これらの場合では、トンネルは非RSVPリンクとして振る舞います。
Terzis, et al. Standards Track [Page 3] RFC 2746 RSVP Operation Over IP Tunnels January 2000
Terzis、他 IPの上の標準化過程[3ページ]RFC2746RSVP操作は2000年1月にトンネルを堀ります。
2.2. Basic Approach
2.2. 基本的なアプローチ
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は終わりから終わりへのセッションのためにトンネルの上でRexitが送るPATHメッセージとトンネルエキジットポイントにリソースを予約する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におけるIPトンネルを高めるか、そして、どう終わりから終わりへのRSVPセッションからトンネルセッションを写像するか。
2.2.1. Design Decisions
2.2.1. デザイン決定
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つのエンドポイントの間の1つ以上のFixed-フィルタスタイルユニキャストの予約が、トンネルを横断するパケットのためのリソースを予約するのに使用されるでしょう。 タイプ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ヘッダーだけと共に包装されるe.g.、およびエキジットポイントでカプセルに入れられます。
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ヘッダーをprependingすることによってカプセル化して、異なった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ヘッダーに基礎づけたデータとフォワードをdecapsulatesします。
Terzis, et al. Standards Track [Page 4] RFC 2746 RSVP Operation Over IP Tunnels January 2000
Terzis、他 IPの上の標準化過程[4ページ]RFC2746RSVP操作は2000年1月にトンネルを堀ります。
........... ............... .............
: _______ : : _____ :
: | | : : | | :
Intranet :--| Rentry|===================|Rexit|___:Intranet
: |_______| : : |_____| :
..........: : Internet : :...........
:..............
|___________________|
........... ............... ............. : _______ : : _____ : : | | : : | | : イントラネット:--| Rentry|===================|Rexit|___:イントラネット: |_______| : : |_____| : ..........: : インターネット: :........... :.............. |___________________|
Figure 1. An example IP Tunnel
図1。 例のIP Tunnel
2.2.2. Mapping between End-to-End and Tunnel Sessions
2.2.2. 終わらせる終わりとトンネルの間でセッションを写像します。
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がRentryから遠くを跳びます。 受信はH2を接待します、そして、また、H4はどちらかであるかもしれませんか複数のIPがRexitから遠くを跳びます。
H1 H2
: :
: :
+--------+ +---+ +---+ +---+ +-------+
| | | | | | | | | |
H3... | Rentry |===================================| Rexit |..... H4
| | | | | | | | | |
+--------+ +---+ +---+ +---+ +-------+
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.
RSVPセッションがホストのH1とH2に終点の間に適所にあるかもしれません。 私たちは「終わりから終わり」(略して2EのE)か「オリジナル」のセッションと、そのPATHへのこのセッションと終わりから終わりへのメッセージとしてのRESVメッセージを示します。 トンネルの上に資源予約を供給するために、RentryとRexitの間には、1つ以上のRSVPセッションが適所にあるかもしれません。 私たちはトンネルかトンネリングメッセージとしてそれらのトンネルRSVPセッションと、PATHとRESVメッセージをこれらを参照します。 トンネルRSVPセッションは終わりから終わりへのどんなセッションからも独自に存在するかもしれません。 例えば、ネットワークマネージメントで、インタフェース1はH3からH4までデータフローのサポートをQoSに供給するためにトンネルの上のRSVPセッションを作成するかもしれません、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
終わりから終わりへのRSVPセッションがRSVPできるトンネルを越えるとき、トンネルの上にメカニズムを設計する際に終わりまでの終わりの予約をサポートすると考える2つのケースがあります: 2ユーロのEセッションから既存のトンネルRSVPセッション(2トンネルをタイプする)を写像して、終わりから終わりへのそれぞれのセッションのためにダイナミックに新しいトンネルRSVPセッションを作成する、(タイプ
Terzis, et al. Standards Track [Page 5] RFC 2746 RSVP Operation Over IP Tunnels January 2000
Terzis、他 IPの上の標準化過程[5ページ]RFC2746RSVP操作は2000年1月にトンネルを堀ります。
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セッションは中間でユニキャストFixed-フィルタスタイルの予約の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.
* 正常なIPパケット、例えば、存在と同様に、終わりから終わりへのRSVPコントロールトンネルを通して転送されるメッセージはトンネルIPヘッダーだけと共に包装されていた状態でカプセル化されます、目的地としてソースとエキジットポイントとしてのトンネルエントリー・ポイントを指定して。
2.3. Major Issues
2.3. 大変な問題
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トンネルは、1つ以上の(構成可能で、静的)の予約がすぐにトンネルの中で異なったトラフィックがクラスであるとサポートするのに使用されるのを許容するはずです。 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
トンネルの上で構成された1つのRSVPセッションしかないと、終わりから終わりへのRSVPすべてのセッション(それはこのトンネルセッションを使用できる)がこの構成されたトンネルセッションまで縛られるでしょう。 しかしながら、1つ以上のRSVPセッションがIPトンネルの上で使用中であるときに、2番目のデザイン問題は協会、または結合がトンネルの片端からもう片方までどう当初のRSVPの予約とトンネルの予約の間に創設されて、伝えられるかということです。 したがって、エントリールータRentryと出口ルータRexit必須がこれらの協会に同意する、それ
Terzis, et al. Standards Track [Page 6] RFC 2746 RSVP Operation Over IP Tunnels January 2000
Terzis、他 IPの上の標準化過程[6ページ]RFC2746RSVP操作は2000年1月にトンネルを堀ります。
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セッションに報告された誤りに変えることができます。
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トンネルをタイプする)の上の添付された予約に関するケースとオリジナルとトンネルの予約の間で1〜1に(タイプ3トンネル)を写像するケースの両方のために働くのを必要とします。 私たちの体系では、トンネルエントリー・ポイントが最初に終わりから終わりへのセッションのRESVメッセージを見て、新しいトンネルセッションをセットアップするか、または既存のトンネルセッションの一助となるとき、協会は創設されます。 この新連合をRexitまで運ばなければなりません、Rexitが終わりから終わりへのセッションのためにトンネルの中でリソースを予約できるように。 この情報はトンネルセッションの識別子とあるパラメタ、および終わりから終わりへのトンネルセッションが制限されている状態であるセッションに関する識別子を含んでいます。 私たちの体系では、同じ2つのルータの間では、すべてのRSVPセッションに、RentryとRexitはソース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. 新しいRSVPオブジェクトを定義して、Rentryの終わりから終わりへのPATHメッセージに付けられてください、トンネルセッションの1つとの終わりから終わりへのセッションを関連づけて。 この新しいオブジェクトはRentryで生成されるトンネルセッションの1つとの終わりから終わりへのセッションを関連づけるRexitによって解釈されます。 3. セッションのデータ・パケットに関して終わりから終わりへのPATHメッセージに同じUDPカプセル化を適用してください。 Rexit decapsulatesであるときに、PATHは通信して、それはポートがカプセル化に使用したソースUDPとオリジナルのPATHメッセージで指定されるRSVPセッションとの関係を推論します。
Terzis, et al. Standards Track [Page 7] RFC 2746 RSVP Operation Over IP Tunnels January 2000
Terzis、他 IPの上の標準化過程[7ページ]RFC2746RSVP操作は2000年1月にトンネルを堀ります。
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に終わらせる終わりのトンネルPATHsを捨てている間にトンネル(彼らが通常decapsulatedされるので)を通って受け取られたPATHsを渡させます、少しも追加構成なしですべて、。 (2) それが、より簡単であるので、私たちはOptionを選びました。 私たちは以下のセクションでこのオブジェクトについて説明します。
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は川下にdecapsulatedされて、それらが送られるRexitへのトンネルの上に終わりから終わりへのPATHメッセージをカプセル化して、送ります。 2. 終わりから終わりへのRESV対応するメッセージがRexitに到着するとき、Rexitはそれをカプセル化して、それをRentryに送ります。 3. 終わらせる終わりの情報PATHメッセージ、終わらせる終わりのflowspec RESVメッセージ、およびローカルの方針のいくつかかすべてに基づいてRentryが決める、そして、終わりから終わりへのセッションからトンネルセッションを写像する方法。 4. 終わりから終わりへのセッションがトンネルセッションまで写像されるべきであり、Rentryが新しいトンネルセッションへのPATHメッセージを送るか、または既存のものをアップデートするなら。 5. RentryはSESSION_ASSOCオブジェクトを含むE2E Pathに上であることのトンネルセッションとの終わりから終わりへのセッションを関連づけさせます。 Rexitは協会を記録して、さらにPathメッセージを転送する前に、オブジェクトを取り除きます。 6. Rexitは、トンネルの中でリソースを予約して、トンネルRESVメッセージを送ることによって、トンネルPATHメッセージに応じます。 7. 対応するトンネルセッションの予約がパケットのために実際に適所にある場合にだけ、パケットを到着にRentry UDPカプセルに入れります。
Terzis, et al. Standards Track [Page 8] RFC 2746 RSVP Operation Over IP Tunnels January 2000
Terzis、他 IPの上の標準化過程[8ページ]RFC2746RSVP操作は2000年1月にトンネルを堀ります。
2.3.1. SESSION_ASSOC Object
2.3.1. セッション_ASSOCオブジェクト
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) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| クラス| c-タイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | SESSIONオブジェクト(終わりから終わりへのセッションのための)| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 送付者FILTER-SPEC(トンネルセッションのための)| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SESSION_ASSOC Object
セッション_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.
終わりから終わりへのオブジェクトに含まれたSESSIONは以下で定義されたSender FILTER-SPECによって説明されたトンネルセッションまで写像されることになっています。
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.
これは終わりから終わりへの上記のセッションがトンネルの上に写像するトンネルセッションです。 私たちが上に言及したように、トンネルセッションは主としてソースポートによって特定されます。 これは私たちがトンネルセッションにSESSIONオブジェクトの場所でSender Filter-仕様を使用する理由です。
Terzis, et al. Standards Track [Page 9] RFC 2746 RSVP Operation Over IP Tunnels January 2000
Terzis、他 IPの上の標準化過程[9ページ]RFC2746RSVP操作は2000年1月にトンネルを堀ります。
2.3.2. NODE_CHAR Object
2.3.2. ノード_炭のオブジェクト
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と呼ばれる新しいオブジェクトを定義しました。 ノードがこのオブジェクトを受けますが、それを理解していないなら、どんなエラー・レポートも製作しないで、それはそれを下げるべきです。 Class-ヌム=10bbbbbb('b'はしばらくを表す)があるRSVP仕様[RFC2205]に基づき定義されるオブジェクトは私たちが必要とする特性を持っています。 このオブジェクトが当分1ビットの情報を運ぶだけである間、将来、当初のRSVP仕様の一部でないRSVPのできるノードの他の特性について説明するのにそれを使用できます。
The object NODE_CHAR has the following format:
オブジェクトNODE_CHARには、以下の形式があります:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | class | c-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |T|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| クラス| c-タイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。|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
Rexitが終わりから終わりへの予約を受けるとき、RESVオブジェクトに設定されたTビットでNODE_CHARオブジェクトを追加して、それは、それをカプセル化して、それをRentryに送ります。 _RentryがRexitがここで説明されたメカニズムを実装するので、トンネルセッションを作成するか、または調整するというそれが推論するこのRESVメッセージを受け取って、SESSIONを通してトンネルセッションから終わりから終わりへのセッションを関連づけるとき、ASSOCは反対します。 RESVメッセージ上流を進める前に、RentryはNODE_CHARオブジェクトを取り除くはずです。 if
Terzis, et al. Standards Track [Page 10] RFC 2746 RSVP Operation Over IP Tunnels January 2000
Terzis、他 IPの上の標準化過程[10ページ]RFC2746RSVP操作は2000年1月にトンネルを堀ります。
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.
他方では、Rentryはそれが単に無視するRSVP TunnelsメカニズムにNODE_CHARオブジェクトを支えて、上流へそれをより遠くに送りません。
3. Implementation
3. 実装
In this section we discuss several cases separately, starting from the simplest scenario and moving to the more complex ones.
このセクションで、最も簡単なシナリオと移行から複雑なものまで始まって、私たちは別々に数個のケースについて議論します。
3.1. Single Configured RSVP Session over an IP-in-IP Tunnel
3.1. IPにおけるIPの上の単一の構成されたRSVPセッショントンネル
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-スタイルの予約を中間でセットアップします。 現在、質問はトンネルの予約にどういうfilterspecを使用するかということです。(直接、予約はパケットがどうトンネルの上に要約されるかに関連します)。 私たちは以下の2つのケースについて議論します。
3.1.1. In the Absence of End-to-End RSVP Session
3.1.1. 終わりから終わりへのRSVPセッションがないとき
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セッションはRentryと共に送付先アドレスとしてのソースアドレスとRexitとして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ヘッダーと共に要約されるのに予約を使用することですべてのデータ・パケットを必要とすることによって実現を簡素化するのを選びます。 これは特別なケースの照合と取り扱いを抑えます。
3.1.2. In the Presence of End-to-End RSVP Session(s)
3.1.2. 終わりから終わりへのRSVPセッションがあるとき(s)
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
しかしながら、拘束力がある終わりから終わりへの複数のセッションから1つのトンネルセッションがいつ、トンネルの予約のサイズが終わりから終わりへのセッションを収容するようにどう調整されるべきであるかに関する新しい疑問を挙げます。
Terzis, et al. Standards Track [Page 11] RFC 2746 RSVP Operation Over IP Tunnels January 2000
Terzis、他 IPの上の標準化過程[11ページ]RFC2746RSVP操作は2000年1月にトンネルを堀ります。
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は軟質のパイプのためにどう調整を行うことができるかを説明します。
3.2. Multiple Configured RSVP Sessions over an IP-in-IP Tunnel
3.2. IPにおけるIPの上の複数の構成されたRSVPセッショントンネル
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.
トンネルの上のただ一つの構成されたRSVPセッションに関するケースの上に管理インタフェースを使用することで2つのトンネル終点の間の複数のFF-スタイルの予約をセットアップすることによって建てるのは簡単です。 この場合、Rentryは適切なUDPポートナンバーで慎重にデータ・パケットをカプセルに入れらなければなりません、異なったトンネルセッションに属するパケットが中間的RSVPルータによって区別されるように。 本件と以前説明されたのがいわゆるタイプ2トンネルについて説明することに注意してください。
3.2.1. In the Absence of End-to-End RSVP Session
3.2.1. 終わりから終わりへのRSVPセッションがないとき
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はパケットを分類して、それに従って、それらを要約します。 予約のないパケットは外側のIPヘッダーだけと共にカプセルに入れられます、予約に資格があったパケットがIPヘッダーと同様にUDPヘッダーと共にカプセルに入れられますが。 UDPソースポート価値は適切にパケットが使用するべきである対応するトンネルの予約への地図に設定されるべきです。
3.2.2. In the Presence of End-to-End RSVP Session(s)
3.2.2. 終わりから終わりへのRSVPセッションがあるとき(s)
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.
この場合、トンネルの上で作動する1つ以上のRSVPセッションがあるので、明らかに終わりから終わりへのRSVPそれぞれのセッションから対応するトンネルセッションを縛らなければなりません。 以前に議論するように、終わりから終わりへのPATHメッセージで運ばれた新しいSESSION_ASSOC物はこの結合を提供するでしょう。
Terzis, et al. Standards Track [Page 12] RFC 2746 RSVP Operation Over IP Tunnels January 2000
Terzis、他 IPの上の標準化過程[12ページ]RFC2746RSVP操作は2000年1月にトンネルを堀ります。
3.3. Dynamically Created Tunnel RSVP Sessions
3.3. ダイナミックに作成されたトンネルRSVPセッション
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.
- 終わりから終わりへの新しいセッションが現れるとき、トンネルセッションは作成されます。 - 終わりから終わりとトンネルRSVPセッションの間には、1〜1つのマッピングがあります、セクション4.2で説明された場合で許容されていることによると1つへの多くマッピングと対照的に。
4. RSVP Messages handling over an IP-in-IP Tunnel
4. IPにおけるIPの上のRSVP Messages取り扱いTunnel
4.1. RSVP Messages for Configured Session(s) Over A Tunnel
4.1. トンネルの上の構成されたセッションへのRSVPメッセージ
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セッションが管理インタフェースを通したトンネルの上にセットアップされます。 セッション予約パラメタは「固いパイプ」トンネルに決して変化しません。 予約パラメタは「軟質のパイプ」トンネルに変化するかもしれません。 Rentryによって発生したトンネルセッションPATHメッセージはRexitに記述されます。そこでは、それらは、処理されて、削除されます。
4.2. Handling of RSVP Messages at Tunnel Endpoints
4.2. トンネル終点のRSVPメッセージの取り扱い
4.2.1. Handling End-to-End PATH Messages at Rentry
4.2.1. Rentryの取り扱い終わりから終わりへの経路メッセージ
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:
終わりから終わりへのPATHメッセージを転送するとき、トンネルエントリー・ポイントとして機能するルータ(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. 終わりから終わりへのメッセージがaであるPATHは終わりから終わりへの以前に知られているセッションをリフレッシュします。 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メッセージがaであるなら以前に知られているセッション、当時のRentryがPathをリフレッシュする終わりから端への終わりから終わりへのセッションとチェックの状態をリフレッシュして、このセッションがトンネルセッションまで写像されるかどうか確認してください。 Rentryが終わりから終わりへのセッションをリフレッシュするとき、これがそうであるなら、それはその時このセッションのときに対応するトンネルセッションItにつなぐSESSION_ASSOC物が終わりから終わりへのPATHメッセージを要約して、トンネルの上にそれを送るという終わらせる終わりのPATHメッセージをRexitに含めます。 トンネルセッションがダイナミックに作成されたなら、aとしての終わりから終わりへのPATHメッセージサーブはRentryの地方のトンネル州と終わりから終わりへのセッションのためにリフレッシュします。
Terzis, et al. Standards Track [Page 13] RFC 2746 RSVP Operation Over IP Tunnels January 2000
Terzis、他 IPの上の標準化過程[13ページ]RFC2746RSVP操作は2000年1月にトンネルを堀ります。
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はこの新しいセッションのための外向的なインタフェースにトンネルのインタフェースであるように設定するPath州を創設します。 その後に、SESSION_ASSOCメッセージを加えないで、RentryはPATHメッセージを要約して、それを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.
終わりから終わりへのPATH TEARがRentryによって受け取られるとき、このノードは、メッセージをRexitに要約して、転送します。 終わりから終わりへのこのセッションでトンネルセッションまで1〜1つのマッピングがあるか、これがトンネルセッションまで写像される終わりから終わりへの多くのセッションの最後の1つであるなら、Rentryは、そのセッションのためにPATH TEARをRexitに送ることによって、トンネルセッションを取りこわします。 終わりから終わりへのセッショントンネルセッションまでの残っているマッピングが他方ではあれば、RentryはトンネルPATHメッセージにトンネルセッションのTspecを調整させます。
4.2.2. Handling End-to-End PATH Messages at Rexit
4.2.2. Rexitの取り扱い終わりから終わりへの経路メッセージ
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にdecapsulatedされて、処理されます。 終わりから終わりへの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はRSVPがPathで旗を揚げさせる_が終わらせるこの終わりの送付者を格納して、グローバルな中断ビットをADSPECにはめ込んで、パケットを川下に送ると述べるNonを設定します。 あるいはまた、トンネルセッションが存在していて、それらのいずれでもNon_RSVP旗を設定しないなら、Rexitは、これらの値を使用することで既存のトンネルセッションから最悪の場合Path ADSPEC paramsを選んで、終わりから終わりへのADSPECのときにアップデートできます。 これは落ち着いたADSPECの保守的な見積りですが、それには、マッピング情報が利用可能になる前に終わらせる終わりの中断ビットADSPECをセットとして避ける利益があります。 この場合、終わりから端へのPath状態の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が早く到着するなら、それはトンネルセッションのためにPATH状態をRexitに創設します。 トンネルセッションへの実際のPATHメッセージが到着すると、それはPATHが述べる存在のアップデートとして扱われます、そして、どんな情報の取り逃がすことをアップデートします。 私たちは、この状況がRSVPに存在する他のものと共に一時的な状態で別のものであり、それが、ここにどんな長期効果もメカニズムの正しい操作に説明されるのを持っていないと信じています。
Terzis, et al. Standards Track [Page 14] RFC 2746 RSVP Operation Over IP Tunnels January 2000
Terzis、他 IPの上の標準化過程[14ページ]RFC2746RSVP操作は2000年1月にトンネルを堀ります。
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旗のPath状態をつけます。 終わりから終わりへのPATHメッセージがADSPEC物を運ぶなら、RexitはADSPECに含まれた特殊化パラメタの構成を実行します。 トンネルセッションの総合的な(構成される)特殊化パラメタをトンネルによって実行された論理的なリンクのためのローカルのパラメタと考えることによって、それはこれをします、そして、それらが終わらせる終わりでこれらのパラメタを構成して、各パラメタを実行するのによるADSPECは構成機能を定義しました。 論理的なリンクの特殊化パラメタでは、最小の経路潜在はカプセル化/被膜剥離術遅れを考慮に入れるかもしれません、そして、帯域幅見積りは余分なUDPヘッダーの追加で引き起こされた利用可能な帯域幅の減少を表すことができます。 [RFC2210]で丹念にADSPECsと構成機能について議論します。
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 decapsulatedメッセージのグローバルな中断ビットの上と前方にそれをターンします。
4.2.3. Handling End-to-End RESV Messages at Rexit
4.2.3. Rexitの取り扱い終わりから終わりへのRESVメッセージ
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は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
ステップ2: 制限されたトンネルセッションが見つけられるなら、Rexitは、予約が終わりから終わりへのRESVメッセージで与えられているセッションまで縛られたトンネルセッションの間、既に適所にあるかを確認するためにチェックします。 終わりまでの到着している終わりのRESVメッセージがaであるなら、RESVが述べる存在をリフレッシュしてください、Rexitがトンネルのインタフェースを通したオリジナルのRESVを送るその時(NODE_CHAR物を加えた後に)。 ダイナミックなトンネルセッション、終わりから終わりへのRESVのときに
Terzis, et al. Standards Track [Page 15] RFC 2746 RSVP Operation Over IP Tunnels January 2000
Terzis、他 IPの上の標準化過程[15ページ]RFC2746RSVP操作は2000年1月にトンネルを堀ります。
message acts as a refresh for the tunnel session reservation state, while for configured tunnel sessions, reservation state never expires.
aとしてのメッセージ条例はトンネルセッション予約州にリフレッシュしますが、予約状態は構成されたトンネルセッションの間決して期限が切れません。
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、RESVを含んでいて、CONFIRMが反対するトンネルセッションを送ります。
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(入場Controlの故障)に用意ができているError Codeがある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 CONFIRM応答が到着するなら、トンネルを通してオリジナルのRESVを要約して、送ります。 アップデートされたトンネルの予約が失敗するなら、Rexitは終わりから終わりへのRESVメッセージの創始者にRESV ERRを送らなければなりません、受信されたトンネルセッションRESV ERRメッセージのERROR_SPEC物からエラーコードと値の分野を使用して。 トンネルを通る先在の予約が適所に残っていることに注意してください。 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.
到着か出発終わりから終わりへのそれぞれの予約のときに上下にトンネルの予約を調整するよりトンネル予約パラメタの調整にいくらかのヒステリシスをむしろ使用するのがしばしば適切であることに注意してください。 これをするのは、別々に、トンネル(トンネルflowspec)に割り当てられたリソースと実際に終わりから終わりへの予約で使用中のリソース(終わりから終わりへの予約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 TEARがRexitによって受け取られるとき、それは、メッセージをRentryに要約して、転送します。 終わりから終わりへのセッションがダイナミックなトンネルセッションを作成したなら、対応するトンネルセッションのためのRESV TEARはRexitで発信することです。
Terzis, et al. Standards Track [Page 16] RFC 2746 RSVP Operation Over IP Tunnels January 2000
Terzis、他 IPの上の標準化過程[16ページ]RFC2746RSVP操作は2000年1月にトンネルを堀ります。
4.2.4. Handling of End-to-End RESV Messages at Rentry.
4.2.4. Rentryの終わりから終わりへの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メッセージがaであるなら、次に、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このセッションが新しいトンネルセッションをセットアップできるなら、RentryはまるでそれがトンネルセッションPATHメッセージをRexitに送り始めるのによるデータの源であるかのようにトンネルセッションPATH州を設立します。Rexitはデータのユニキャストの目的地として扱われます。 この新しいPATHメッセージのTspecは、オリジナルのPATHメッセージからデータ・パケットのカプセル化のトンネルオーバーヘッドを含むようにTspecパラメタを調整することによって、計算されます。 また、この場合、Rentryは終わりから終わりへの今回のセッションからの2つのセッションをリンクするSESSION_ASSOC物を含むPATHメッセージを送るはずです。 RexitによるこのPATHメッセージの領収書は終わりから端への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メッセージが終わりから終わりへのそのセッションとトンネルの上のその対応するセッションの間でマッピングを決定するということです。 そのうえ、予約が活発である限り、このマッピングは変化できません。
Terzis, et al. Standards Track [Page 17] RFC 2746 RSVP Operation Over IP Tunnels January 2000
Terzis、他 IPの上の標準化過程[17ページ]RFC2746RSVP操作は2000年1月にトンネルを堀ります。
5. Forwarding Data
5. 推進データ
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.
予約が適所にあるなら、それは、RentryとRexitの両方がRSVP-トンネリングの意識しているルータであり、データがRexitで正しくdecapsulatedされることを意味します。
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.
トンネルセッションの予約が全く適所にないなら、データはトンネルの正常な形式で要約されるべきです、終わりから端へのPATHデータをカバーする州が存在しているかどうかにかかわらず。
6. Details
6. 詳細
6.1. Selecting UDP port numbers
6.1. UDPポートナンバーを選択します。
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つの間には、エンドポイントの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.
新しいトンネルセッションのために初期のPATH状態を設置するとき、ソースUDP港はトンネルエントリー・ポイントRentryによって選ばれています。 そして、新しいセッションに関連しているソースUDP港はSESSION_ASSOC物によってRexitまで運ばれます。
The destination UDP port used in tunnel sessions should the one assigned by IANA (363).
トンネルセッションのときに使用された目的地UDP港はIANA(363)によって割り当てられたものがそうするべきです。
6.2. Error Reporting
6.2. 誤り報告
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メッセージが誤りに遭遇するとき、それはRentryに報告を持ちかえられます。 Rentryは終わりから終わりへのセッションの一次資料にエラー・レポートをリレーして戻さなければなりません。
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は論理的なリンク(トンネル)を越える際に誤りとしてこれを扱って、終わりのホストにエラーメッセージを転送して戻さなければなりません。
Terzis, et al. Standards Track [Page 18] RFC 2746 RSVP Operation Over IP Tunnels January 2000
Terzis、他 IPの上の標準化過程[18ページ]RFC2746RSVP操作は2000年1月にトンネルを堀ります。
6.3. MTU Discovery
6.3. MTU発見
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発見を支持しなければなりません。 あるいはまた、RFC2210[RFC2210]で議論したPath MTUディスカバリーメカニズムは使用できます。
6.4. Tspec and Flowspec Calculations
6.4. TspecとFlowspec計算
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.
複数のEndから終わりにただ一つのトンネルセッションまでセッションを写像できるように、Endから終わりへのそれらのセッションのすべての送付者の集合Tspecを計算する必要があります。 この集合Tspecは代表しているトンネルセッションのTspecがそうするでしょう。 同じ操作は、Endから終わりへのRexitに到着する予約のflowspecsのために実行される必要があります。
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.
これらの操作の意味論はここに記述されません。 それらをする最も簡単な方法はControlled-負荷の、そして、Guaranteedサービス([RFC2211]と[RFC2212]では、それぞれ見つけられる)の仕様に基づき定義されていた状態で終わりから終わりへのTspecsのそのままな合計を計算することです。 しかしながら、また、より洗練された統計的であるか測定ベースの計算を使用するトンネルに集合予約レベルを計算するのも適切であるかもしれません。
7. IPSEC Tunnels
7. IPSEC Tunnels
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におけるIPトンネルがその時IPSEC(特にAHのあるなしにかかわらずトンネル・モードにおける超能力)を支持する場合では、Tunnel SessionはPATHとRESVメッセージのために[RSVPESP]で定義されるように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ヘッダーと共にカプセルに入れられません。 それらが支持されるなら異なったTunnelセッションズのものであるパケットと同様に異なったSPIsが予約を持っているデータ・パケットと「ベストエフォート型」のパケットに割り当てられるように、RentryとRexitの間でユーザ指向の合わせることを使用しなければならないのに注意してください。
8. RSVP Support for Multicast and Multipoint Tunnels
8. マルチキャストのRSVPサポートとMultipoint Tunnels
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インフラストラクチャに提供します、それらのポイントの間のユニキャストかマルチキャスト交通のどちらかを要約して、運ぶかもしれませんが。
Terzis, et al. Standards Track [Page 19] RFC 2746 RSVP Operation Over IP Tunnels January 2000
Terzis、他 IPの上の標準化過程[19ページ]RFC2746RSVP操作は2000年1月にトンネルを堀ります。
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つのタイプのトンネルは想像されるかもしれません。 これらの1番目は「マルチキャスト」トンネルです。 トンネル、エントリー・ポイントに到着するのが要約されて、輸送される(マルチキャスト)このタイプのパケット、-、オール、エキジットポイントについて。 この種類のトンネルは、階層的なマルチキャスト流通機構を実行するか、または効率的に原産のマルチキャスト分配木の何らかの一部を見習うために有用であることが分かるかもしれません。
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をいつも実行できる間、このアプローチが広い領域VPNsの場合で非常に効率が悪くなって、適切な制御機構がある多点トンネルが望ましくなることに注意してください。
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つへの多くのトンネルRSVPセッションか1〜1つの基礎に写像されるかもしれません。 しかしながら、ユニキャスト、ケースと異なって、マッピングはRSVPの異種性意味論によって複雑にされます。 異なった受信機が異なった予約の要請を作ったなら、多分、トンネルに到着するRESVメッセージは受信機の要求を論理的に異なったトンネルセッションまで写像するでしょう。 実際に1つのセッションだけまでデータを置くことができるので、すべてのアプリケーションの需要を満たすものを選択するためにセッションの選択を和解させなければなりません(合併されています)。 これはセッションマッピングメカニズムに比較的簡単な拡大を必要とします。
Terzis, et al. Standards Track [Page 20] RFC 2746 RSVP Operation Over IP Tunnels January 2000
Terzis、他 IPの上の標準化過程[20ページ]RFC2746RSVP操作は2000年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.
これはSession ID(送付先IPアドレス)が--使用されて、セッション状態を特定するのが中でノードをネットワークでつなぎますが、パケットを分類するのに使用されるだけではないということである現在のRSVPセッション意味論に拡大の必要性を含意します。 これを除いて、RSVPの多点トンネルの使用はマルチキャストトンネルのものに続きます。 マルチキャストグループはトンネル終点であるノードのセットを表すために創設されます、そして、1つ以上のトンネルRSVPセッションが、要約のパケットのためのリソースを予約するために作成されます。 簡単なVPNを実行するトンネルの場合では、全体のVPNのためのリソースを予約する1つのセッションがあるのは、たぶんです。 それぞれのトンネル終点はこのただ一つのセッションのためのPATHメッセージの源と(FFかSE)RESVメッセージの源として参加するでしょう、事実上、全体の論理的な共有された媒体のただ一つの共有された予約を作成して。 トンネル終点は多点トンネルの上のワイルドカードの予約をしてはいけません。
9. Extensions to the RSVP/Routing Interface
9. RSVP/ルート設定インタフェースへの拡大
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/ルート設定Interfaceで、RSVPデーモンがそれらのIPアドレスに伴う局所界面のリストを学ぶことができなければならないと述べます。 RSVP Tunnels事件では、RSVPデーモンは、また、ここで説明された能力を持ちながら局所界面のどれがIPにおける(あります)IPトンネルであるかを学ぶ必要があります。 RSVPデーモンは、直接基本的なネットワークと物理的な層について質問するか、またはRSVPとこの情報を提供するために適切に広げられたルーティング・プロトコルとのどんな既存のインタフェースも使用することによって、この情報を取得できます。
Terzis, et al. Standards Track [Page 21] RFC 2746 RSVP Operation Over IP Tunnels January 2000
Terzis、他 IPの上の標準化過程[21ページ]RFC2746RSVP操作は2000年1月にトンネルを堀ります。
10. Security Considerations
10. セキュリティ問題
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 Tunnelsの導入はRSVPとトンネルの使用に関連づけられたもの以外のどんな新しい安全保障問題も提起しません。 RSVPに関して、主要な問題は高められたサービスの品質へのアクセスを制御して、認証する必要性です。 [RFC2205]で、より詳しくこの要件について議論します。 [RSVPCRYPTO]はここで説明された情報を運ぶRSVPメッセージの保全を保護するのに使用されるメカニズムについて説明します。 [IPINIP4]と[IPV6GEN]でIPにおけるIPトンネルに関連している安全保障問題について議論します。
11. IANA Considerations
11. IANA問題
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物のClass番号を割り当てるはずです。 この数は10bbbbbb範囲にあるべきです。 提案された値は128です。
12. Acknowledgments
12. 承認
We thank Bob Braden for his insightful comments that helped us to produce this updated version of the document.
私たちは私たちがドキュメントのこのアップデートされたバージョンを生産するのを助けた彼の洞察に満ちたコメントについてボブ・ブレーデンに感謝します。
13. References
13. 参照
[ESP] Atkinson, R., "IP Encapsulating Security Payload (ESP)",
RFC 1827, August 1995.
[超能力] アトキンソン、R.、「セキュリティ有効搭載量(超能力)を要約するIP」、RFC1827、1995年8月。
[IP4INIP4] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[IP4INIP4] パーキンス、C.、「IPの中のIPカプセル化」、RFC2003、1996年10月。
[IPV6GEN] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[IPV6GEN] コンタとA.とS.デアリング、「IPv6仕様による一般的なパケットトンネリング」、RFC2473、1998年12月。
[MINENC] Perkins, C., "Minimal Encapsulation within IP", RFC
2004, October 1996.
[MINENC] パーキンス、C.、「IPの中の最小量のカプセル化」、RFC2004、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)」、RFC1701 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ネットワークの上の一般ルーティングのカプセル化」、RFC1702、1994年10月。
[RFC1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers", RFC 1933, April 1996.
[RFC1933] ギリガンとR.とE.Nordmark、「IPv6ホストとルータのための変遷メカニズム」、RFC1933、1996年4月。
Terzis, et al. Standards Track [Page 22] RFC 2746 RSVP Operation Over IP Tunnels January 2000
Terzis、他 IPの上の標準化過程[22ページ]RFC2746RSVP操作は2000年1月にトンネルを堀ります。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J.、「IETFの統合サービスとのRSVPの使用」、RFC2210、1997年9月。
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load
Network Element Service", RFC 2211, September 1997.
[RFC2211] Wroclawski、J.、「制御負荷ネットワーク要素サービスの仕様」、RFC2211、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.ゲラン、「保証されたサービスの質の仕様」、RFC2212、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の機能的な仕様」、RFC2205、1997年9月。
[RSVPESP] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC
Data Flows", RFC 2207, September 1997.
[RSVPESP] バーガーとL.とT.オマリー、「IPSECデータフローのためのRSVP拡張子」、RFC2207、1997年9月。
[RSVPCRYPTO] Baker, F., Lindell, B. and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747, January 2000.
[RSVPCRYPTO] ベイカーとF.とリンデルとB.とM.Talwar、「RSVPの暗号の認証」、RFC2747、2000年1月。
Terzis, et al. Standards Track [Page 23] RFC 2746 RSVP Operation Over IP Tunnels January 2000
Terzis、他 IPの上の標準化過程[23ページ]RFC2746RSVP操作は2000年1月にトンネルを堀ります。
14. Authors' Addresses
14. 作者のアドレス
John Krawczyk ArrowPoint Communications 50 Nagog Park Acton, MA 01720
ジョンKrawczyk ArrowPoint Communications50Nagog Parkアクトン、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
ジョンWroclawski MIT Laboratory for Computer Science545技術平方です。 ケンブリッジ、MA 02139
Phone: 617-253-7885 Fax: 617-253-2673 EMail: jtw@lcs.mit.edu
以下に電話をしてください。 617-253-7885 Fax: 617-253-2673 メールしてください: jtw@lcs.mit.edu
Lixia Zhang UCLA 4531G Boelter Hall Los Angeles, CA 90095
Lixiaチャン・UCLA 4531G Boelter Hallロサンゼルス、カリフォルニア 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
アンドレアスTerzis UCLA4677Boelter Hallロサンゼルス、カリフォルニア 90095
Phone: 310-267-2190 EMail: terzis@cs.ucla.edu
以下に電話をしてください。 310-267-2190 メールしてください: terzis@cs.ucla.edu
Terzis, et al. Standards Track [Page 24] RFC 2746 RSVP Operation Over IP Tunnels January 2000
Terzis、他 IPの上の標準化過程[24ページ]RFC2746RSVP操作は2000年1月にトンネルを堀ります。
15. Full Copyright Statement
15. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Terzis, et al. Standards Track [Page 25]
Terzis、他 標準化過程[25ページ]
一覧
スポンサーリンク
