Network Working Group F. Baker
Request for Comments: 4923 Cisco Systems
Category: Informational P. Bose
Lockheed Martin
August 2007
Quality of Service (QoS) Signaling in a Nested Virtual Private Network
ネストされた仮想プライベートネットワークにシグナリングサービスの品質（QoS）
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
Some networks require communication between an interior and exterior portion of a Virtual Private Network (VPN) or through a concatenation of such networks resulting in a nested VPN, but have sensitivities about what information is communicated across the boundary, especially while providing quality of service to communications with different precedence. This note seeks to outline the issues and the nature of the proposed solutions based on the framework for Integrated Services operation over Diffserv networks as described in RFC 2998.
にサービスの品質を提供し、特にながら、いくつかのネットワークは、またはネストされたVPNをもたらすようなネットワークの連結を介して仮想プライベートネットワーク（VPN）の内側と外側部分との間の通信を必要とするが、情報は、境界を越えて通信されるかについて感度を有します異なる優先との通信。このノートはRFC 2998に記載されたDiffservネットワーク上の統合サービス操作のためのフレームワークに基づいて提案されたソリューションの問題や自然を概説することを目指しています。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Problem Statement ..........................................3
1.2. Background Information and Terminology .....................4
1.3. Nested VPNs ................................................5
1.4. Signaled QoS Technology ....................................7
1.5. The Resource Reservation Protocol (RSVP) ...................9
1.6. Logical Structure of a VPN Router .........................10
2. Reservation and Preemption in a Nested VPN .....................13
2.1. Reservation in a Nested VPN ...............................14
2.2. Preemption in a Nested VPN ................................16
2.3. Working through an Example ................................17
2.3.1. Initial Routine Reservations - Generating
Network State ......................................18
2.3.2. Initial Routine Reservations - Request
Reservation ........................................19
2.3.3. Installation of a Reservation Using Precedence .....20
2.3.4. Installation of a Reservation Using Preemption .....21
3. Data Flows within a VPN Router .................................24
3.1. VPN Routers That Carry Data across the
Cryptographic Boundary ....................................24
3.1.1. Plaintext to Ciphertext Data Flows .................24
3.1.2. Ciphertext to Plaintext Data Flows .................27
3.2. VPN Routers That Use the Network Guard for
Signaling across the Cryptographic Boundary ...............28
3.2.1. Signaling Flow .....................................29
3.2.2. Use Case with Network Guard ........................30
4. Security Considerations ........................................33
5. Acknowledgements ...............................................34
6. References .....................................................34
6.1. Normative References ......................................34
6.2. Informative References ....................................35
More and more networks wish to guarantee secure transmission of IP traffic across public LANs or WANs and therefore use Virtual Private Networks. Some networks require communication between an interior and exterior portion of a VPN or through a concatenation of such networks resulting in a nested VPN, but have sensitivities about what information is communicated across the boundary, especially while providing quality of service to communications with different precedence. This note seeks to outline the issues and the nature of the proposed solutions. The outline of the QoS solution for real-time traffic has been described at a high level in [RFC4542]. The key characteristics of this proposal are that
より多くのネットワークは、公共のLANまたはWANの間でIPトラフィックの安全な伝送を保証するため、仮想プライベートネットワークを使用したいです。いくつかのネットワークは、VPNの内側と外側の部分との間またはネストされたVPNをもたらすようなネットワークの連結を介して通信を必要とするが、特に異なる優先順位との通信にサービスの品質を提供しながら、境界を越えて通信される情報についての感度を有します。このノートでは、問題と提案されたソリューションの性質を概観しよう。リアルタイムトラフィックのためのQoSソリューションの概要は、[RFC4542]でハイレベルで記述されています。この提案の重要な特徴は、ということです
o it uses standardized protocols,
Oそれは標準化されたプロトコルを使用して、
o it includes reservation setup and teardown for guaranteed and controlled load services using the standardized protocols,
Oそれは標準化されたプロトコルを使用して保証され、制御負荷サービスのために予約セットアップとティアダウンを含み、
o it is independent of link delay, and therefore consistent with high delay*bandwidth networks as well as the more common variety,
Oそれは、リンク遅延とは無関係に、かつ高遅延*帯域幅のネットワークだけでなく、より一般的な多様性を持つため、一致しています
o it has no single point of failure, such as a central reservation manager,
Oそれは、中央予約管理などの障害の単一点を有していません、
o it provides for the preemption of established data flows,
Oは、確立されたデータフローのプリエンプションを提供します
o in that preemption, it not only permits a policy-admitted data flow in, but selects a specific data flow to exclude based upon control input rather than simply accepting a loss of service dictated at the discretion of the network control function, and
Oそれプリエンプションでは、ポリシー認めデータが流入可能にするだけではなく、単にネットワーク制御機能の裁量で決定されるサービスの損失を受け入れるのではなく、制御入力に基づいて除外するために、特定のデータフローを選択し、そして
o it interoperates directly with SIP Proxies, H.323 Gatekeepers, or other call management subsystems to present the other services required in a preemptive or preferential telephone network.
Oそれはプリエンプティブまたは優先電話ネットワークに必要な他のサービスを提供するSIPプロキシ、H.323ゲートキーパー、または他のコール管理サブシステムと直接相互運用できます。
The thrust of the memo surrounds VPNs that use encryption in some form, such as IPsec and their subsequent nesting across multiple network domains. This specific type of VPNs is further clarified in Section 1.3, which describes the nested VPN as an example of an IPsec or IPsec like VPN under the context of a 'customer provisioned' VPN. As a result, we will discuss the VPN router supporting "plaintext" and "ciphertext" interfaces. However, the concept extends readily to any form of aggregation, including the concept proposed in [RFC3175] of the IP traffic entering and leaving a network at identified points, and the use of other kinds of tunnels including Generic Routing Encapsulation (GRE), IP/IP, MPLS, and so on.
メモの推力は、IPsecと複数のネットワークドメイン間でそれらのその後のネストとして何らかの形で暗号化を使用してVPNを取り囲みます。 VPNのこの特定のタイプは、さらに「顧客プロビジョニング」VPNのコンテキストでVPN等のIPsecやIPsecの例として、ネストされたVPNを記述する1.3項で明らかにされています。その結果、私たちは「平文」と「暗号文」のインターフェイスをサポートするVPNルータについて説明します。しかし、概念は、IP、IPトラフィックの特定されたポイントでネットワークに入ると出る、と総称ルーティングカプセル化（GRE）トンネルを含む他の種類の使用の[RFC3175]で提案された概念を含む凝集の任意の形態に容易に延びています/ IP、MPLS、というように。
A note on the use of the words "priority" and "precedence" in this document is in order. The term "priority" has been used in this context with a variety of meanings, resulting in a great deal of confusion. The term "priority" is used in this document to identify one of several possible datagram scheduling algorithms. A scheduler is used when deciding which datagram will be sent next on a computer interface; a priority scheduler always chooses a datagram from the highest priority class (queue) that is occupied, shielding one class of traffic from most of the jitter by passing jitter it would otherwise have experienced to another class. [RFC3181] applies the term to a reservation, in a sense that this document will refer to as "precedence". The term "precedence" is used in the sense implied in the phrase "Multi-Level Precedence and Preemption" [ITU.MLPP.1990]; some classes of sessions take precedence over others, which may result in bandwidth being admitted that might not otherwise have been or may result in the prejudicial termination of a lower-precedence session under a stated set of circumstances. For the purposes of the present discussion, "priority" is a set of algorithms applied to datagrams, where "precedence" is a policy attribute of sessions. The techniques of priority comparisons are used in a router or a policy decision point to implement precedence, but they are not the same thing.
この文書内の単語「優先度」と「優先度」の使用上の注意事項はオーダーです。用語「優先順位は」大きな混乱が生じ、様々な意味で、この文脈で使用されてきました。用語「優先度」はいくつかの可能なデータグラムスケジューリングアルゴリズムのいずれかを識別するために、このドキュメントで使用されています。コンピュータインタフェース上で次に送信されるデータグラムを決定する際にスケジューラが使用されます。優先度スケジューラは、常にそれはそう別のクラスに経験したであろうジッタを渡すことで、ジッタのほとんどからのトラフィックの1つのクラスをシールド、占有されている最も優先度の高いクラス（キュー）からのデータグラムを選択します。 [RFC3181]は、この文書は、「優先度」と呼ぶだろうという意味では、予約の用語が適用されます。用語「優先順位は」という句「マルチレベル優先順位および優先処理」[ITU.MLPP.1990]で暗黙の意味で使用されています。セッションのいくつかのクラスは、それはそうしていない可能性がありますまたは状況の規定のセットの下で優先順位の低いセッションの不利終了をもたらす可能性が入院されている帯域幅をもたらすことができるほか、より優先されます。この議論の目的のために、「優先順位」を「優先度」はセッションのポリシー属性であるデータグラムに適用されるアルゴリズムのセットです。優先順位の比較の技術が優先を実装するためにルータまたはポリシー決定ポイントで使用されているが、それらは同じものではありません。
Along the same lines, it is important for the reader to understand the difference between QoS policies and policies based on the "precedence" or "importance" of data to the person or function using it. Voice, regardless of the precedence level of the call, is impeded by high levels of variation in network-induced delay. As a result, voice is often serviced using a priority queue, transferring jitter from that application's traffic to other applications. This is as true of voice for routine calls as it is for flash traffic. There are classes of application traffic that require bounded delay. That is a different concept than "no jitter"; they can accept jitter within stated bounds. Routing protocols such as OSPF or BGP are critical to the correct functioning of network infrastructure. While they are designed to work well with moderate loss levels, they are not helped by them, and even a short period of high loss can result in dramatic network events. Variation in delay, however, is not at all an issue if it is within reasonable bounds. As a result, it is common for routers to treat routing protocol datagrams in a way that limits the probability of loss, accepting relatively high delay in some cases, even though the traffic is absolutely critical to the network. Telephone call setup exchanges have this characteristic as well: faced with a choice between loss and delay, protocols like SIP and H.323 far prefer the latter, as the call setup time is far less than it would be if datagrams had to be retransmitted, and this is true regardless of whether the call is routine or of high precedence. As such, QoS markings tell us how to provide good service to an application independent of how "important" it may be at the current time, while "importance" can be conveyed separately in many cases.
読者が「優先」またはそれを使用する人や関数へのデータの「重要性」に基づいて、QoSポリシーとポリシーの違いを理解するために同じラインに沿って、それが重要です。音声は関係なく、コールの優先レベルの、ネットワークによって誘発される遅延の変動の高いレベルによって妨げられます。その結果、音声は、多くの場合、他のアプリケーションにそのアプリケーションのトラフィックからのジッタを転送、プライオリティキューを使用して処理されます。それはフラッシュトラフィックのためであるとして、これはルーチン呼び出しのための声のように真です。有界遅延を必要とするアプリケーショントラフィックのクラスがあります。それは、「ジッタなし」とは異なる概念です。彼らは述べた範囲内でジッタを受け入れることができます。 OSPFやBGPなどのルーティングプロトコルは、ネットワークインフラストラクチャの正しい機能に重要です。それらは適度な損失レベルでうまく動作するように設計されていますが、彼らは彼らに助けされていない、とさえ高い損失の短い期間では劇的なネットワークイベントが発生することができます。それが妥当な範囲内であれば、遅延の変動は、しかし、すべての問題ではありません。ルータは、トラフィックがネットワークへの絶対的に重要であるにも関わらず、いくつかのケースでは、比較的高い遅延を受け入れ、損失の可能性を制限した方法でルーティングプロトコルのデータグラムを処理するため、結果として、それが一般的です。電話の呼設定交換は、同様にこの特性を持っている：呼設定時間はデータグラムを再送信する必要があった場合よりもはるかに少ないと損失と遅延の間の選択に直面して、SIPやH.323などのプロトコルは遠く、後者を好みます、これは関係なく、コールがルーチンまたは高い優先度であるかどうかの事実です。そのため、QoSマーキングは、「重要度」は多くの場合、個別に搬送することができる一方で、それは、現在の時間にあってもよい方法を「重要」のアプリケーションから独立に良いサービスを提供する方法を教えてください。
One could describe a nested VPN network in terms of three network diagrams. Figure 1 shows a simple network stretched across a VPN connection. The VPN router (where, following [RFC2460], a "router" is "a node that forwards packets not explicitly addressed to itself"), performs the following steps:
一つは、3つのネットワーク図の観点から、ネストされたVPNネットワークを記述することができます。図1は、VPN接続を介して延伸単純なネットワークを示しています。 VPNルータ（[RFC2460]以下、「ルータ」は「パケットを転送するノードが明示的に自分宛ではない」である）は、以下のステップを実行します。
o receives an IP datagram from a plaintext interface,
Oは、プレーンテキストインターフェイスからIPデータグラムを受信します
o determines what remote enclave and therefore other VPN router to forward it to,
oは、どのようなリモート飛び地とにそれを転送するので、他のVPNルータを決定します
o ensures that it has a tunnel mode security association (as generally defined in [RFC4301], Section 4) with that router,
oは、それはそのルータとのトンネルモードのセキュリティアソシエーション（として一般に[RFC4301]で定義され、セクション4）を有していることを確実にします
o encloses the encrypted datagram within another VPN (e.g., IPsec) and IP header, and
oは他のVPN（例えば、IPsec）のIPヘッダ内の暗号化されたデータグラムを包囲、及び
o forwards the encapsulated datagram toward the remote VPN router.
OリモートVPNルータに向けてカプセル化されたデータグラムを転送します。
The receiving VPN router reverses the steps:
受信VPNルータは、手順を逆に：
o determines what security association the datagram was received from,
oはセキュリティアソシエーションデータグラムがから受信されたかを決定し、
o decrypts the interior datagram,
oは、内部データグラムを解読します
o forwards the now-decapsulated datagram on a plaintext interface.
O平文インターフェイス上の今、デカプセル化データグラムを転送します。
The use of IPsec in this manner is described as the tunnel mode of [RFC4301] and [RFC4303].
この方法のIPsecの使用は[RFC4301]及び[RFC4303]のトンネルモードとして記載されています。
Host Host Host Host Host Host
/------------------/ /------------------/
Router -------Router
|
VPN-Router
||
|| IPsec Tunnel through routed network
||
VPN-Router
|
Router -------Router
/------------------/ /------------------/
Host Host Host Host Host Host
Figure 1: VPN-Connected Enclave
図1：VPN接続の飛び地
An important point to understand is that the VPN tunnel, like other features of the routed network, are invisible to the host. The host can infer that "something out there" is affecting the Path MTU, introducing delay, or otherwise affecting its data stream, but if properly implemented, it should be able to adapt to these. The words "if properly implemented" are the bane of every network manager, however; substandard implementations do demonstrably exist.
理解するための重要な点は、VPNトンネルは、ルーティングされたネットワークの他の機能と同様に、ホストには見えないということです。ホストは、「そこに何か」そのデータストリームに影響を与えそうでない場合は、パスMTUに影響を与える遅延を導入する、またはされていることを推測することができますが、適切に実装されている場合、これらに対応することができるはずです。 「適切に実装されている場合」の言葉は、しかし、すべてのネットワーク管理者の悩みの種です。規格外の実装が明らかに存在します。
Outside of the enclave, the hosts are essentially invisible. The communicating enclaves look like a simple data exchange between peer hosts across a routed network, as shown in Figure 2.
飛び地の外では、ホストは、本質的に見えません。図2に示すように、通信飛び地は、ルーティングされたネットワークを介してピア・ホストとの間の単純なデータ交換のように見えます。
Hosts Not Visible
/==================/
Router
|
VPN-Router
/---------------------/
Inner Domain
/---------------------/
VPN-Router
|
Router
/==================/
Hosts Not Visible
Figure 2: VPN-Connected Enclave from Exterior Perspective
図2：エクステリアの視点からのVPN接続の飛び地
Such networks can be nested and re-used in a complex manner. As shown in Figure 3, a pair of enclaves might communicate across a ciphertext network that, for various reasons, is itself re-encrypted and transmitted across a larger ciphertext network. The reasons for doing this vary, but they relate to information-hiding in the wider network, different levels of security required for different enclosed enclaves, and so on.
そのようなネットワークは、ネストされた、複雑な方法で再使用することができます。図3に示すように、飛び地のペアは、様々な理由のために、それ自体が再暗号化と、より大きな暗号文ネットワークを介して送信される暗号文ネットワークを介して通信するかもしれません。これを行う理由はさまざまですが、彼らはそうで広いネットワーク内の情報隠蔽、異なる囲まれた飛び地のために必要なセキュリティの異なるレベル、およびに関連しています。
Host Host Host Host Host Host
/------------------/ /------------------/
Router -------Router
|
VPN-Router VPN-Router VPN-Router
/---------------------/ /----------/
Router -------------Router
|
VPN-Router VPN-Router
/-----------/ /----------/
Router -------Router
|
|
Router -------Router
/-----------/ /----------/
VPN-Router VPN-Router
|
Router ------------Router
/---------------------/ /----------/
VPN-Router VPN-Router VPN-Router
|
Router -------Router
/------------------/ /------------------/
Host Host Host Host Host Host
Figure 3: Nested VPN
図3：ネストされたVPN
The key question this document explores is "how do reservations, and preemption of reservations, work in such an environment?"
この文書は探究重要な問題は、「どのような環境では、作業を予約を行うには、予約の先取り？」です
The Integrated Services model for networking was originally proposed in [RFC1633]. In short, it divides all applications into two broad classes: those that will adapt themselves to any available bandwidth, and those that will not or cannot. In the words of [RFC1633]:
ネットワーキングのための統合サービスモデルは元々[RFC1633]で提案されました。任意の利用可能な帯域幅に自分自身を適応するもの、それはないでしょうかできないものである：要するに、それは、2つの広範なクラスにすべてのアプリケーションを分割します。 [RFC1633]の言葉で：
One class of applications needs the data in each packet by a
certain time and, if the data has not arrived by then, the data
is essentially worthless; we call these "real-time"
applications. Another class of applications will always wait
for data to arrive; we call these "elastic" applications.
The Integrated Services model defines data flows supporting applications as either "real-time" or "elastic". It should be noted that "real-time" traffic is also referred to as "inelastic" traffic, and that elastic traffic is occasionally referred to as "non-real-time".
統合サービスモデルは、データを「リアルタイム」または「弾性」のいずれかのようなアプリケーションをサポートするフローを定義します。 「リアルタイム」トラフィックはまた、「非弾性」トラフィックと呼ばれ、その弾性トラフィックが時折「非リアルタイム」と呼ばれることに留意すべきです。
In this view, the key issue is the so-called "playback point": a real-time application is considered to have a certain point in time at which data describing the next sound, picture, or whatever to be delivered to a display device or forfeit its utility, while an elastic application has no such boundary. Another way to look at the difference is that real-time applications have an irreducible lower bound on their bandwidth requirements. For example, the typical G.711 payload is delivered in 160-byte samples (plus 40 bytes of IP/ UDP/RTP headers) at 20 millisecond intervals. This will yield 80 kbps of bandwidth, without silence suppression, and not accounting for the layer 2 overhead. To operate in real-time, a G.711 codec requires the network over which its data will be delivered to support communications at 80 kbps at the IP layer with roughly constant end-to-end delay and nominal or no loss. If this is not possible (if there is significant loss or wide variations in delay), voice quality will suffer. On the other hand, if many megabits of capacity are available, the G.711 codec will not increase its bandwidth requirements either. Although adaptive codecs exist (e.g., G.722.2 or G.726), the adaptive mechanism can either require greater or lesser bandwidth and can adapt only within a certain range of bandwidth requirements beyond which the quality of the data flow required is not met. Elastic applications, however, will generally adapt themselves to any network: if the bottleneck provides 9600 bits per second, a Web transfer or electronic mail exchange will happen at 9600 bits per second, and if hundreds of megabits are available, the TCP (or SCTP) transport will increase their transfer rate in an attempt to reduce the time required to accomplish the transfer.
このビューでは、重要な問題は、いわゆる「再生位置」である：リアルタイムアプリケーションは、画像、データが次の音を記述する時間内の特定のポイントを有すると考えられる、または表示装置に配信されるどんな弾性アプリケーションは、そのような境界を持っていない間、または、その有用性を失います。違いを見てもう一つの方法は、リアルタイムアプリケーションがその帯域幅要件の下限既約を持っているということです。例えば、典型的なG.711ペイロードは160バイトのサンプル（プラスIP / UDP / RTPヘッダの40バイト）は、20ミリ秒間隔でで送達されます。これは、無音抑圧することなく、帯域幅の80 kbpsのを生じ、そしてレイヤ2オーバーヘッドを占めないであろう。リアルタイムで動作するように、G.711コーデックが、そのデータは、ほぼ一定のエンドツーエンド遅延と公称又は全く損失がIPレイヤで80 kbpsの通信をサポートするために送達される上にネットワークを必要とします。これは（重大な損失や遅延の幅広い変動がある場合）が可能でない場合は、音声品質が低下します。容量の多くメガビットが利用可能な場合一方、G.711コーデックは、どちらかの帯域幅要件を増加しません。適応型コーデック（例えば、G.722.2またはG.726）が存在するが、適応機構は、より多い又はより少ない帯域幅を必要とするかのみ必要なデータフローの品質が満たされていないそれを超える帯域幅要件の特定の範囲内に適合させることができます。伸縮性のアプリケーションは、しかし、一般的に任意のネットワークに自分自身を適応します：ボトルネックは、毎秒9600ビットを提供する場合、ウェブ転送や電子メールの交換は毎秒9600ビットでどうなる、とメガビットの何百もが利用可能な場合、TCP（またはSCTP ）トランスポートは、転送を達成するために必要な時間を短縮しようとする試みに彼らの転送速度が向上します。
For real-time applications, those that require data to be delivered end to end with at least a certain rate and with delays varying between stated bounds, the Integrated Services architecture proposes the use of a signaling protocol that allows the communicating applications and the network to communicate about the application requirements and the network's capability to deliver them. Several such protocols have been developed or are under development, notably including the Resource Reservation Protocol (RSVP) and Next Steps in Signaling (NSIS). The present discussion is limited to RSVP, although any protocol that delivers a similar set of capabilities could be considered.
リアルタイムアプリケーション、少なくとも一定の速度で、記載された範囲の間で変化する遅延と端と端を配信すべきデータを必要とするもののために、サービス統合型アーキテクチャは、通信アプリケーションを可能にするシグナリングプロトコルおよびネットワークの使用を提案していますアプリケーションの要件とそれらを提供するためのネットワークの能力についての通信を行います。いくつかのこのようなプロトコルは、特にリソース予約プロトコル（RSVP）およびシグナル伝達における次のステップ（NSIS）を含め、開発または開発中であるされています。機能の類似のセットを提供し、任意のプロトコルが考えられるが、本議論は、RSVPに制限されます。
RSVP is initially defined in [RFC2205] with a set of datagram processing rules defined in [RFC2209] and datagram details for Integrated Services [RFC2210]. Conceptually, this protocol specifies a way to identify data flows from a source application to a destination application and request specific resources for them. The source may be a single machine or a set of machines listed explicitly or implied, whereas the destination may be a single machine or a multicast group (and therefore all of the machines in it). Each application is specified by a transport protocol number in the IP protocol field, or may additionally include destination and perhaps source port numbers. The protocol is defined for both IPv4 [RFC0791] and IPv6 [RFC2460]. It was recognized immediately that it was also necessary to provide a means to perform the same function for various kinds of tunnels, which implies a relationship between what is inside and what is outside the tunnel. Definitions were therefore developed for IPsec [RFC2207] and [RFC4860] and for more generic forms of tunnels [RFC2746]. With the later development of the Differentiated Services Architecture [RFC2475], definitions were added to specify the Differentiated Services Code Point (DSCP) [RFC2474] to be used by a standard RSVP data flow in [RFC2996] and to use a pair of IP addresses and a DSCP as the identifying information for a data flow [RFC3175].
RSVPは、最初は、[RFC2209]で定義されたデータグラム処理ルールのセットと統合サービスのためのデータグラム詳細[RFC2210]と[RFC2205]で定義されています。概念的に、このプロトコルは、宛先アプリケーションにソース・アプリケーションからのデータフローを識別するための方法を指定し、彼らのために特定のリソースを要求します。宛先は、単一のマシンまたは（その中のため、すべてのマシンの）マルチキャストグループであってもよく、一方ソースは、単一のマシンまたは、明示的に記載又は暗示マシンのセットであってもよいです。各アプリケーションは、IPプロトコルフィールドに、トランスポートプロトコル番号で指定された、またはそれに加えて、宛先、おそらく元ポート番号を含むことができます。プロトコルは、IPv4 [RFC0791]とIPv6 [RFC2460]の両方のために定義されています。これは内部であり、トンネルの外に何が何であるかとの間の関係を意味しており、トンネルの様々な種類の同じ機能を実行するための手段を提供することも必要であったことを即座に認識されました。定義は、したがって、IPsecの[RFC2207]及び[RFC4860]とトンネルのより一般的な形態のために[RFC2746]のために開発されました。差別化サービスアーキテクチャ[RFC2475]の後の発展に伴い、定義は[RFC2996]で標準RSVPデータフローで使用するとIPアドレスのペアを使用する差別化サービスコードポイント（DSCP）[RFC2474]を指定するために添加しましたデータフロー[RFC3175]のための識別情報としてDSCP。
In addition, the initial definition of the protocol included a placeholder for policy information, and for preemption of reservations. This placeholder was later specified in detail in [RFC2750] with a view to associating a policy [RFC2872] with an identity [RFC3182] and thereby enabling the network to provide a contracted service to an authenticated and authorized user. This was integrated with the Session Initiation Protocol [RFC3261] in [RFC3312]. Preemption of a reservation is specified as in [RFC3181] -- a reservation that is installed in the network using an Preemption Priority and retained using a separate Defending Priority may be removed by the network via an RESV Error signal that removes the entire reservation. This has issues, however, in that the matter is often not quite so black and white. If the issue is that an existing reservation for 80 kbps can no longer be sustained but a 60 kbps reservation could, it is possible that a VoIP sender could change from a G.711 codec to a G.729 codec and achieve that. Or, if there are multiple sessions in a tunnel or other aggregate, one of the calls could be eliminated leaving capacity for the others. [RFC4495] seeks to address this issue.
また、プロトコルの最初の定義は、ポリシー情報のため、および予約の先取りのためのプレースホルダが含まれていました。このプレースホルダは、後に[RFC3182]アイデンティティとポリシー[RFC2872]を関連付け、それにより認証され、許可されたユーザに契約したサービスを提供するために、ネットワークを有効にするビューと[RFC2750]に詳細に指定されました。これは、セッション開始プロトコル[RFC3312]の[RFC3261]に統合されました。予約のプリエンプションは、[RFC3181]のように指定されている - 別防衛優先度を使用して、先取り優先権を使用して、ネットワーク内に設置し、保持されている予約が全体予約を除去RESVエラー信号を介してネットワークによって除去することができます。問題は、多くの場合、それほど黒と白ではないという点でこれは、しかし、問題があります。問題は、80 kbpsのための既存の予約は、もはや持続できないことであるが、60 kbpsの予約ができれば、VoIP送信者がG.729コーデックにG.711コーデックから変更し、それを達成する可能性があります。トンネルまたは他の骨材に複数のセッションがある場合、または、コールの一方が他の能力を残して除去することができます。 [RFC4495]はこの問題に対処しようとします。
In a similar way, a capability was added to limit the possibility of control signals being spoofed or otherwise attacked [RFC2747] [RFC3097].
同様に、機能は、偽装された制御信号の可能性を制限するために追加されたか、そうでない場合は[RFC2747]、[RFC3097]を攻撃しました。
[RFC3175] describes several features that are unusual in RSVP, being specifically set up to handle aggregates in a service provider network. It describes three key components:
[RFC3175]は、具体的に、サービスプロバイダネットワーク内の凝集体を処理するように設定され、RSVPに異例であるいくつかの特徴を説明しています。これは、3つの主要コンポーネントについて説明します。
o The RFC 3175 session object, which identifies not the IP addresses of the packets that are identified, but the IP addresses of the ingress and egress devices in the network, and the DSCP that the traffic will use.
トラフィックが使用することが確認されたパケットのIPアドレスが、ネットワーク内の入力および出力デバイスのIPアドレス、およびDSCPないが識別RFC 3175セッションオブジェクト、O。
o The function of a reservation "aggregator", which operates in the ingress router and accepts individual reservations from the "customer" network. It aggregates the reservations into the ISP core in a tunnel or an MPLS LSP, or as a traffic stream that is known to leave at the deaggregator.
入口ルータで動作し、「顧客」ネットワークから個々の予約を受け付ける予約「アグリゲータ」の機能、O。これは、トンネル内のISPのコアまたはMPLS LSPに予約を集約し、またはデアグリゲーターに残すことが知られているトラフィックストリームとして。
o The function of a reservation "deaggregator", which operates in the egress router and breaks the aggregate reservation and data streams back out into individual data streams that may be passed to other networks.
O出口ルータで動作し、集計予約を破壊し、データを他のネットワークに渡すことができる個々のデータストリームにバックアウトストリーム予約「デアグリゲーター」の機能。
In retrospect, the Session Object specified by RFC 3175 is useful but not intrinsically necessary. If the ISP network uses tunnels, such as MPLS LSPs, IP/IP or GRE tunnels or enclosing IPsec Security Associations, the concepts of an aggregator and a deaggregator work in the same manner, although the reservation mechanism would be that of [RFC3473] and [RFC3474], [RFC2207], [RFC4860], or [RFC2746].
振り返ってみると、RFC 3175で指定されたセッションオブジェクトは便利なものの、本質的に必要ありません。予約機構は[RFC3473]のものであろうがISPネットワークは、同様にこのようなMPLS LSPを、IP / IPまたはGREトンネルまたはIPsecセキュリティアソシエーションを囲む、アグリゲーター及びデアグリゲーター作業の概念としてトンネルを使用する場合、および[RFC3474]、[RFC2207]、[RFC4860]、または[RFC2746]。
The conceptual structure of a VPN router is similar to that of any other router. In its simplest form, it is physically a two or more port device (similar to that shown in Figure 4), which has one or more interfaces to the protected enclave(s) and one or more interfaces to the outside world. On the latter, it structures some number of tunnels (in the case of an IPsec tunnel, having security associations) that it can treat as point-to-point interfaces from a routing perspective.
VPNルータの概念的な構造は、他のルータと同様です。その最も単純な形態では、それは物理的に保護された飛び地（S）への1つまたは複数のインタフェースと外部世界に1つまたは複数のインターフェイスを有している（図4に示すものと同様）は、2つの以上のポート装置です。それはルーティングの観点からポイント・ツー・ポイントインタフェースとして扱うことができることを、後者では、構造（セキュリティアソシエーションを有するIPsecトンネルの場合、）トンネルのいくつかの数。
+---------+ +-------+ +----+----+ +---------+
| RSVP | |Routing| |Net Guard| |IPsec Mgr|
+----+----+ +---+---+ +----+----+ +----+----+
| | | |
+----+-----------+------------+-----------------+----+
| IP |
+-----------+--------------------+------------+------+
| | |
| +-----+-----+ +----+------+
| | Encrypt/ | | Encrypt/ |
| |Decrypt for| |Decrypt for|
| | Security | | Security |
| |Association| |Association|
| +-----+-----+ +----+------+
| | |
+-----------+------------+ +-----+------------+------+
| Plaintext | | Ciphertext |
| Interface | | Interface |
+------------------------+ +-------------------------+
Figure 4: Logical Structure of a VPN Router
図4：VPNルーターの論理構造
The encrypt/decrypt unit may be implemented as a function of the plaintext router, as a function on its interface card, or as a function of an external device with a private interface to the IP routing functionality of the plaintext router. These are conceptually equivalent, although there are practical differences in implementation. The key issue is that when IP routing presents a message to the encrypt/decrypt unit for transmission, it must also be presented with the IP address of the plaintext routing peer, whether host or router, to which the security association must be established. This IP Address is used to select (and perhaps create) the security association, and in turn select the appropriate set of security parameters. This could also be implemented by presenting the local Security Parameter Index (SPI) for the data, if it has been created out of band by the Network Management Process.
暗号化/復号化ユニットは、そのインタフェースカード上の機能として、又は平文ルータのIPルーティング機能にプライベートインターフェイスと、外部装置の機能として、平文ルータの機能として実装されてもよいです。実装に実用的な違いがありますが、これらは、概念的に等価です。重要な問題は、IPルーティングが暗号化にメッセージを提示したときに/送信するためにユニットを解読、また、どのセキュリティアソシエーションが確立されなければならないために、ホストやルータ、かどうか、平文ルーティングピアのIPアドレスを提示しなければならないということです。このIPアドレスは、セキュリティアソシエーションを選択します（そしておそらく作成）するために使用され、今度はセキュリティパラメータの適切なセットを選択しています。それはネットワーク管理プロセスによって帯域外に作成された場合にも、データのローカルセキュリティパラメータインデックス（SPI）を提示することによって実現することができます。
In addition, it is necessary for aggregated signaling to be generated for the ciphertext domain. This may be accomplished in several ways:
集約されたシグナリングが暗号文ドメインのために生成されるのに加えて、それが必要です。これは、いくつかの方法で達成することができます。
o by having the RSVP process on the plaintext router generate the messages and having the encrypt/decrypt unit bypass them into the ciphertext network
O平文ルータにRSVPプロセスは、メッセージを生成有する暗号化を有することによって/ユニットを復号化暗号文ネットワークにそれらを迂回
o by having the plaintext RSVP process advise a process in the encrypt/decrypt implementation of what needs to be generated using some local exchange, and having it generate such messages, or
O平文RSVPプロセスは、いくつかのローカル交換機を使用して生成される必要があるものの実装を復号化/暗号化の処理を助言有し、それは、そのようなメッセージを生成有することによって、又は
o by having a separate parallel network management system intermediate between the plaintext and ciphertext routers, in which case, the encrypt/decrypt unit and the parallel network system must use the same address, and the ciphertext router must distinguish between traffic for them based on SPI or the presence of encryption.
Oにより、暗号化/ユニットを復号その場合、平文と暗号文ルータとの間の中間別個の並列ネットワーク管理システムを有する並列ネットワークシステムは、同一のアドレスを使用する必要があり、暗号文ルータはSPIに基づいて、それらのトラフィックを区別しなければなりませんまたは暗号化の存在。
Control plane signaling using this additional path is described in Section 3.2. The information flow between the plaintext and ciphertext domains includes
この追加のパスを使用して制御プレーンシグナリングは、セクション3.2に記載されています。平文と暗号文ドメインの間の情報の流れは、
o IP datagrams via the encrypt/decrypt unit,
暗号化を介して、IPデータグラムO /ユニットを復号化します、
o RSVP signaling via the bypass path,
バイパス経路を介してシグナルOのRSVP、
o Control information coordinating security associations, and
Oセキュリティアソシエーションを調整する情報を制御し、
o precious little else.
他のO貴重な少し。
/ \
( +--+ +--+ enclave ) ,---------.
.----------. \ |H2+---+R2| / ,-' `
+--+ +--+`--.\ +--+ ++-+ / / +--+ +--+
|H1+---+R1| \`. | ,' / |R3+---+H3|
+--+ +-++ ) '--. +----++ _.-' ( ++-+ +--+
| / _.`---|VPN2||''-. \ |
enclave +----+-i.--'' +----++ `----.\ +----+ enclave
--------|VPN1|' | ``|VPN3| ,
,+----+ | +----+------'
,' --+-------+----------+------------------+---`.
,' ++-+ `.
,' |R7+--------+ `.
/ interface +--+ | \
domain 1 +-+--+ \
_.--------|VPN7|--------.
,-----'' +--+-+ `------. .
`-. ,-' | `-. .-'
`-: inner domain +-++ `.'
( |R9| )
.'. ++-+ ;-.
.' `-. | ,-' `-.
' `------. +-+--+ _.-----' `
interface `---------|VPN8|-------''
domain 2 +-+--+ /
\ | +--+ /
`. +----------+R8| ,'
`. ++-+ ,'
`. --+------------------+-----------+------+-- ,'
,-----+----+ | +----+------.
,' |VPN6|. | _.|VPN4| `
+----+.`----. +----+ _.--'' ,+----+
| \ `--=.-|VPN5|---:' / |
+--+ ++-+ : ,-'' +----+ `--. ; ++-+ +--+
|H6+---+R6| | ,' | `.| |R4+---+H4|
+--+ +--+ ;/ +--+ ++-+ : +--+ +--+
// |H5+---+R5| \
enclave ,'( +--+ +--+ `. enclave
`. ,' \ enclave / '-. ,
`-------' \ / `-------'
Figure 5: Reservations in a Nested VPN
図5：ネストされたVPNで予約
Let us discuss how a resource reservation protocol, and specifically RSVP, might be used in a nested virtual private network.
私たちはどのようにリソース予約プロトコルを議論してみましょう、特にRSVP、ネストされた仮想プライベートネットワークで使用される可能性があります。
A reservation in a nested VPN is very much like a reservation in any other network, with one exception: it is composed of multiple reservations that must be coordinated. These include a reservation within the originating and receiving enclaves and a reservation at each layer of the VPN, as shown in Figure 5.
ネストされたVPNでのご予約は、1つの例外を除き、非常に多くの他のネットワークでの予約のようなものです：それは調整する必要があり、複数の予約で構成されています。図5に示すように、これらは、元の内予約と飛び地を受信し、VPNの各レイヤで予約を含みます。
Thus, when a host in one enclave opens a reservation to a host in another enclave, a reservation of the appropriate type and size is created end to end. As it traverses the VPN router leaving its enclave, the reservation information and the data are placed within the appropriate tunnel (e.g., the IPsec Security Association for its precedence level to the appropriate remote VPN router). At the remote VPN router, it is extracted from the tunnel and passed on its way to the target system. The data in the enclave will be marked with a DSCP appropriate to its application and (if there is a difference) precedence level, and the signaling datagrams (PATH and RESV) are marked with a DCLASS object indicating that value. RSVP signaling datagrams (PATH and RESV) are marked with a DCLASS object indicating the value used for the corresponding data. The DSCP on the signaling datagrams, however, is a DSCP for signaling, and has the one provision that if routing varies by DSCP, then it must be a DSCP that is routed the same way as the relevant data. The [RFC2872] policy object specifies the applicable policy (e.g., "routine service for voice traffic") and asserts a [RFC3182] credential indicating its user (which may be a person or a class of persons). As specified in [RFC3181], it also specifies its Preemption Priority and its Defending Priority; these enable the Preemption Priority of a new session to be compared with the Defending Priority of previously admitted sessions.
1つのエンクレーブ中のホストが、別のエンクレーブ内のホストに予約を開いたときしたがって、適切なタイプとサイズの予約がエンドツーエンドを作成します。それはその飛び地を残してVPNルータを横断するように、予約情報とデータが適切なトンネル内に配置されている（例えば、適切なリモートVPNルータへの優先レベルのIPsecセキュリティアソシエーション）。遠隔VPNルータで、それがトンネルから抽出され、ターゲット・システムへの途中で通過しました。エンクレーブ内のデータは、そのアプリケーションと（差がある場合）、優先レベルにDSCPの適切でマークされ、シグナリングデータグラム（PATHとRESV）はその値を示すDCLASSオブジェクトにマークされています。 RSVPシグナリングデータグラム（PATHとRESV）は、対応するデータのために使用される値を示すDCLASSオブジェクトにマークされています。 DSCPは、シグナリングデータグラム上で、しかし、シグナリングのためのDSCPであり、ルーティングは、DSCPによって変化する場合、それは、関連するデータと同じようにルーティングされるDSCPでなければならないことを1つの規定を有しています。 [RFC2872]ポリシー・オブジェクトは、適用可能なポリシー（例えば、「音声トラフィックのためのルーチンサービス」）を指定し、そのユーザ（人または人のクラスであってもよい）を示す[RFC3182]信任状をアサートします。 [RFC3181]で指定されているように、それはまた、その先取り優先権とその防衛優先順位を指定します。これらは、新しいセッションの先取り優先権が以前入院セッションのディフェンディング優先順位と比較することを可能にします。
On the ciphertext side of the VPN router, no guarantees result unless the VPN router likewise sets up a reservation to the peer VPN Router across the ciphertext domain. Thus, the VPN router sets up an [RFC2207], [RFC4860], or [RFC3175] reservation to its peer.
VPNルータは、同様に、暗号文ドメイン全体ピアVPNルータへの予約を設定しない限り、VPNルータの暗号文側では、保証はなりません。したがって、VPNルータは、[RFC2207]、[RFC4860]、または[RFC3175]ピアに予約を設定します。
The Session Object defined by [RFC2207] or [RFC4860] contains a field called a "virtual destination port", which allows the multiplexing of many reservations over a common security association and, in the latter case, a common DSCP value. Thus, the voice traffic at every precedence level might use the Expedited Forwarding (EF) DSCP and service as described in [RFC3246], but the reservations would be for "the aggregate of voice sessions at precedence Pn between these VPN routers". This would allow the network administration to describe policies with multiple thresholds, such as "a new session at precedence Pn may be accepted if the total reserved bandwidth does not exceed threshold Qn; if it is necessary and sufficient to accept the reservation, existing reservations at lower precedences may be preemptively reduced to make acceptance of the new session possible".
[RFC2207]または[RFC4860]で定義されたセッションオブジェクトが、後者の場合、一般的なDSCP値に、共通のセキュリティアソシエーションに比べて多くの予約の多重化を可能にし、「仮想宛先ポート」と呼ばれるフィールドが含ま。したがって、[RFC3246]に記載されているように、すべての優先順位レベルで音声トラフィックは、緊急転送（EF）DSCPとサービスを使用するかもしれないが、予約は、「これらのVPNルータ間の優先Pnので音声セッションの集合体」のことです。これは、ネットワーク管理は、「優先Pnので新しいセッションが合計予約された帯域幅が閾値Qnとを超えていない場合に受け入れられるような複数の閾値とのポリシーを記述することを可能にする;予約を受け入れるために必要かつ十分である場合、で予約を既存の下の優先順位は、先制「新しいセッションの受け入れを可能にするために減少させることができます。
In the [RFC3175] case, since the DSCP must be used to identify both the reservation and the corresponding data stream, the aggregate reservations for different precedence levels require different DSCP values.
DSCP予約と対応するデータストリームの両方を識別するために使用されなければならないので、[RFC3175]の場合に、異なる優先レベルの集計予約異なるDSCP値を必要とします。
In either case, the fundamental necessity is for one VPN router to act as what [RFC3175] calls the "aggregator" and another to act as the "deaggregator", and extend a VPN tunnel between them. If the VPN Tunnel is an IPsec Security Association between the VPN routers and the IP packet is entirely contained within (such as is used to cross a firewall), then the behavior of [RFC2746] is required of the tunnel. That bearer will have the following characteristics:
いずれの場合も、基本的な必要性は、一つのVPNルータは、[RFC3175]は「アグリゲータ」呼び出し、別の「デアグリゲーター」として作用し、そしてそれらの間にVPNトンネルを拡張するものとして作用するためです。 VPNトンネルがVPNルータとIPパケットとの間のIPsecセキュリティアソシエーションが完全（例えば、ファイアウォールを通過するために使用されるような）内に含まれている場合は、[RFC2746]の動作は、トンネルの必要とされます。それベアラは次の特徴があります。
o it will have a DSCP corollary to the DSCP for the data or the same DSCP as the data it carries,
Oそれが運ぶデータのようなデータのためのDSCPへのDSCP推論または同じDSCPを持つことになり、
o the reservations and data will be carried in security associations between the VPN routers, and
予約及びデータはVPNルータ間のセキュリティアソシエーションに実施される、O、及び
o the specification for the reservation for the tunnel itself will not be less than the sum of the requirements of the aggregated reservations.
Oトンネルの予約のための仕様自体が凝集予約の要求の和よりも小さくないであろう。
The following requirements relationships apply between the set of enclosed reservations and the tunnel reservation:
次の要件の関係は、同封の予約のセットとトンネルの予約の間で適用されます。
o The sum of the average rates of the contained reservations, having been adjusted for the additional IP headers, will be less than or equal to the average rate of the tunnel reservation.
含まれている予約の平均速度の合計O、トンネル予約の平均速度以下となり、追加のIPヘッダーのために調整されました。
o The sum of the peak rates of the contained reservations, having been adjusted for the additional IP headers, will be less than or equal to the peak rate of the tunnel reservation.
含まれている予約のピークレートの和O、トンネル予約のピークレート以下となり、追加のIPヘッダーのために調整されました。
o The sum of the burst sizes of the contained reservations, having been adjusted for the additional IP headers, will be less than or equal to the burst size of the tunnel reservation.
含まれている予約のバーストサイズの和O、トンネル予約のバーストサイズ以下となり、追加のIPヘッダーのために調整されました。
o The Preemption Priority of a tunnel reservation is identical to that of the individual reservations it aggregates.
Oトンネル予約の先取り優先権は、それが集約個々の予約のものと同一です。
o The Defending Priority of a tunnel reservation is identical to that of the individual reservations it aggregates.
oをトンネル予約の守る優先順位は、それが集約個々の予約のものと同一です。
This would differ only in the case that measurement-based admission is in use in the tunnel but not in the end system. In that case, the tunnel's average bandwidth specification would be greater than or equal to the actual average offered traffic. Such systems are beyond the scope of this specification.
これは、測定系の入場は、トンネル内ではなく、エンドシステムで使用されている場合にのみ異なるであろう。その場合には、トンネルの平均帯域幅仕様は実際の平均提供トラフィック以上であろう。このようなシステムは、この仕様の範囲を超えています。
As a policy matter, it may be useful to note a quirk in the way Internet QoS works. If the policies for various precedence levels specify different thresholds (e.g., "to accept a new routine call, the total reserved bandwidth after admission may not exceed X; to accept a call with a higher precedence level, the total reserved bandwidth after admission may not exceed X+Y, and this may be achieved by preempting a call with a lower precedence level"), the bandwidth Y effectively comes from the bandwidth in use by elastic traffic rather than forcing a preemption event.
ポリシーの問題として、インターネットのQoSの動作方法で癖を注意することは有用である可能性があります。さまざまな優先レベルのポリシーが異なるしきい値を指定した場合（例えば、「新しいルーチン呼び出しを受け入れるために、入学後の総確保された帯域幅はXを超えないようにして、優先順位の高いレベルでのコールを受け入れるために、入学後の総予約された帯域幅はないかもしれませんX + Yを超え、これはより低い優先レベル」）との通話を優先することによって達成することができる、帯域幅Yを効果的に弾性トラフィックなくプリエンプションのイベントを強制することによって、使用中の帯域幅から来ます。
As discussed in Section 1.5, preemption is specified in [RFC3181] and further addressed in [RFC4495]. The issue is that in many cases the need is to reduce the bandwidth of a reservation due to a change in the network, not simply to remove the reservation. In the case of an end-system-originated reservation, the end system might be able to accommodate the need through a change of codec; in the case of an aggregate of some kind, it could reduce the bandwidth it is sending by dropping one or more reservations entirely.
セクション1.5で議論するように、プリエンプションは、[RFC3181]で指定され、さらに、[RFC4495]でアドレス指定されます。問題は、多くの場合、必要性は、単に予約を削除するには、ネットワークの変化による予約の帯域幅を減らすことではないということです。エンドシステム由来の予約の場合には、エンドシステムは、コーデックの変更を介して必要に対応することができるかもしれません。いくつかの種類の集合体の場合には、それが完全に一つ以上の予約をドロップすることによって送信される帯域幅を減らすことができます。
In a nested VPN or other kind of aggregated reservation, this means that the deaggregator (the VPN router initiating the RESV signal for the tunnel) must
ネストされたVPNまたは凝集予約の他の種類では、これはデアグリゲーター（トンネルのRESV信号を開始するVPNルータ）がなければならないことを意味します
o receive the RESV Error signaling it to reduce its bandwidth,
O、それはその帯域幅を削減するために、シグナリングRESVエラーを受け取ります
o re-issue its RESV accordingly,
したがってO再発行のRESV、
o identify one or more of its aggregated reservations, enough to do the job, and
O仕事をするのに十分なその集約の予約、の一つ以上を特定し、
o signal them to reduce their bandwidth accordingly.
Oそれに応じて帯域幅を削減するためにそれらを知らせます。
It is possible, of course, that it is signaling them to reduce their bandwidth to zero, which is functionally equivalent to removing the reservation as described in [RFC3181].
[RFC3181]に記載されているように、予約を除去することと機能的に同等である、ゼロへの帯域幅を低減するためにそれらをシグナリングしていることを、もちろん、可能です。
In the routers in the core, an additional case arises. One could imagine that some enclave presents the VPN with a single session, and that session has a higher precedence level. If some interior link is congested (e.g., the reserved bandwidth will exceed policy if the call is admitted), a session between a different pair of VPN routers must be preempted. More generally, in selecting a reservation to preempt, the core router must always select a reservation at the lowest available Defending Priority. This is the reason that various precedence levels must be kept separate in the core.
コア内のルータでは、追加のケースが生じます。一つは、いくつかの飛び地は、単一のセッションでVPNを提示し、そのセッションは、優先順位の高いレベルを持っていることを想像できます。いくつかの内部リンクが輻輳している場合、VPNルータの異なる対の間のセッションは、プリエンプトされなければならない、（呼び出しが許可される場合、例えば、予約された帯域幅は、ポリシーを超えます）。より一般的には、先取りする予約を選択するには、コアルータは、常に利用可能な最低ディフェンディング優先順位で予約を選択する必要があります。これは、さまざまな優先レベルがコアに別々に保持されなければならない理由です。
The network in Figure 5 shows three security layers: six plaintext enclaves around the periphery, two ciphertext domains connecting them at one layer (referred to in the diagram as an "interface domain"), and a third ciphertext domain connecting the first two (referred to in the diagram as an "inner domain"). The following distribution of information exists:
周囲の6つの平文飛び地、（「界面領域」として図に呼ばれる）一つの層でそれらを接続する2つの暗号文ドメインと呼ばれる最初の二つを接続する第3の暗号文ドメイン（：図5のネットワークは、3つのセキュリティ層を示します「内部ドメイン」）として図中に。情報の以下の分布が存在します。
o Each enclave has access to general routing information concerning other enclaves it is authorized to communicate with: systems in it can translate a DNS name for a remote host or domain and obtain the corresponding address or prefix.
O各飛び地は、と通信することを許可されている他の飛び地に関する一般的なルーティング情報へのアクセスを有する：その中のシステムは、リモート・ホストまたはドメインのDNS名を変換し、対応するアドレスまたはプレフィックスを取得することができます。
o Each enclave router also has specific routing information regarding its own enclave.
O各飛び地のルータは、独自の飛び地に関する特定のルーティング情報を有しています。
o A default route is distributed within the enclave, pointing to its VPN router.
Oデフォルトルートは、そのVPNルータを指して、飛び地内に分配されます。
o VPN Routers 1-6 are able to translate remote enclave prefixes to the appropriate remote enclave's VPN router addresses.
O VPNルータ1-6適切なリモート飛び地のVPNルータアドレスにリモート飛び地プレフィックスを変換することができます。
o Each interface domain has access to general routing information concerning the other interface domains, but not the enclaves. Systems in an interface domain can translate a DNS name for a remote interface domain and obtain the corresponding address or prefix.
O各インタフェース領域は、他のインタフェースドメインではなく、飛び地に関する一般的なルーティング情報へのアクセスを有します。インタフェースドメイン内のシステムは、リモート・インタフェースのドメインのDNS名を変換し、対応するアドレスまたはプレフィックスを取得することができます。
o Each interface domain router also has specific routing information regarding its own interface domain.
O各インターフェイスのドメインルータは、独自のインタフェースドメインに関する特定のルーティング情報を有しています。
o A default route is distributed within the interface domain, pointing to the "inner" VPN router.
Oデフォルトルートは、「内部」VPNルータを指し、界面領域内に分布されています。
o VPN Routers 7 and 8 are able to translate remote interface domain prefixes to remote VPN router addresses.
VPNルータO 7および8は、リモートVPNルータアドレスに、リモート・インタフェースのドメインプレフィックスを変換することができます。
o Routers in the inner domain have routing information for that domain only.
O内部ドメイン内のルータは、そのドメインのルーティング情報を持っています。
While the example shows three levels, there is nothing magic about the number three. The model can be extended to any number of concentric layers.
一例は、以下の3つのレベルを示しているが、数3程度の魔法は何もありません。モデルは、同心円層の任意の数に拡張することができます。
Note that this example places unidirectional reservations in the forward direction. In voice and video applications, one generally has a reservation in each direction. The reverse direction is not discussed, for the sake of clarity, but operates in the same way in the reverse direction and uses the same security associations.
この例では、順方向に一方向の予約を置くことに注意してください。音声およびビデオアプリケーションでは、1は、一般的に各方向に予約されています。逆方向を明確にするために、議論が、逆方向に同じように動作し、同じセキュリティアソシエーションを使用していません。
Now let us install a set of reservations from H1 to H4, H2 to H5, and H3 to H6, and for the sake of argument, let us presume that these are at the "routine" precedence. H1, H2, and H3 each initiate a PATH signal describing their traffic. For the sake of argument, let us presume that H1's reservation is for an [RFC2205] session, H2's reservation is for a session encrypted using IPsec, and therefore depends on [RFC2207], and H3 (which is a Public Switched Telephone Network (PSTN) gateway) sends an [RFC3175] reservation comprising a number of distinct sessions. Since these are going to H4, H5, and H6, respectively, the default route leads them to VPN1, VPN2, and VPN3, respectively.
今、私たちはH6にH4、H5にH2、およびH3にH1からの予約のセットをインストールしてみましょう、と議論のために、私たちはこれらを「日常」の優先順位であることを前提としてみましょう。 H1、H2、およびH3は、それぞれ、それらのトラフィックを記述するパス信号を開始します。引数のために、私たちはH1の予約が[RFC2205]セッションのためのものであることを想定してみましょう、H2の予約がセッションのためにIPsecを使用して暗号化されるので、[RFC2207]に依存し、H3（公衆交換電話網（PSTN交換されています）ゲートウェイ）は、別個のセッションの数を含む[RFC3175]の予約を送信します。これらは、H4、H5、H6としようとしているので、それぞれ、デフォルトルートはそれぞれ、VPN1、VPN2、およびVPN3にそれらをリードしています。
The VPN routers each ensure that they have an appropriate security association or tunnel open to the indicated remote VPN router (VPN4, VPN5, or VPN6). This will be a security association or tunnel for the indicated application at the indicated precedence level. Having accomplished that, it will place the PATH signal into the security association and forward it. If such does not already exist, following [RFC3175]'s aggregation model, it will now open a reservation (send a PATH signal) for the tunnel/SA within the interface domain; if the reservation does exist, the VPN router will increase the bandwidth indicated in the ADSPEC appropriately. In this example, these tunnel/SA reservations will follow the default route to VPN7.
VPNルータ各々は、それらが示されたリモートVPNルータ（VPN4、VPN5、又はVPN6）のオープン適切なセキュリティアソシエーションまたはトンネルを有することを確認してください。これは、指示された優先レベルで指示されたアプリケーションのためのセキュリティアソシエーションまたはトンネルであろう。それを達成した、それはセキュリティアソシエーションへのPATH信号を配置し、それを転送します。そのようなすでに[RFC3175]の集合モデル以下、存在しない場合、それは今インタフェースドメイン内のトンネル/ SAため（パス信号を送る）予約を開きます。予約が存在しない場合は、VPNルータは適切にADSPECに示された帯域幅が増加します。この例では、これらのトンネル/ SA予約VPN7にデフォルトルートに従います。
VPN7 ensures that it has an appropriate security association or tunnel open to VPN8. This will be a security association or tunnel for the indicated application at the indicated precedence level. Having accomplished that, it will place the PATH signal into the security association and forward it. If such does not already exist, following [RFC3175]'s aggregation model, it will now open a reservation (send a PATH signal) for the tunnel/SA within the interface domain; if the reservation does exist, the VPN router will increase the bandwidth indicated in the ADSPEC appropriately. In this example, this tunnel/SA reservation is forwarded to VPN8.
VPN7は、VPN8に開い適切なセキュリティアソシエーションまたはトンネルを有することを保証します。これは、指示された優先レベルで指示されたアプリケーションのためのセキュリティアソシエーションまたはトンネルであろう。それを達成した、それはセキュリティアソシエーションへのPATH信号を配置し、それを転送します。そのようなすでに[RFC3175]の集合モデル以下、存在しない場合、それは今インタフェースドメイン内のトンネル/ SAため（パス信号を送る）予約を開きます。予約が存在しない場合は、VPNルータは適切にADSPECに示された帯域幅が増加します。この例では、このトンネル/ SA予約がVPN8に転送されます。
VPN8 acts as an [RFC3175] deaggregator for the inner domain. This means that it receives the PATH signal for the inner domain reservation and stores state, decrypts the data stream from VPN7, operates on the RSVP signals as an RSVP-configured router, and forwards the received IP datagrams (including the updated PATH signals) into its interface domain. The PATH signals originated by VPN1, VPN2, and VPN3 are therefore forwarded towards VPN4, VPN5, and VPN6 according to the routing of the interface domain.
VPN8は、内部ドメインの[RFC3175]デアグリゲーターとして作用します。これに（更新パス信号を含む）を受信したIPデータグラムを、内側のドメインの予約と格納状態に対するパス信号を受信VPN7からのデータストリームを復号し、RSVP-構成ルータとしてRSVP信号で動作し、転送することを意味しますそのインターフェースのドメイン。 VPN1、VPN2、およびVPN3によって発信パス信号は、従って、インタフェースドメインのルーティングに応じVPN4、VPN5、およびVPN6向かって転送されます。
VPN4, VPN5, and VPN6 each act as an [RFC3175] deaggregator for the interface domain. This means that it receives the PATH signal for the interface domain reservation and stores state, decrypts the data stream from its peer, operates on the RSVP signals as an RSVP-configured router, and forwards the received IP datagrams (including the updated PATH signals) into its enclave. The PATH signals originated by H1, H2, and H3 are therefore forwarded towards H4, H5, and H6 according to the routing of the enclave.
VPN4、VPN5、およびVPN6インタフェースドメインの[RFC3175]デアグリゲーターとしてそれぞれ作用します。これは、それがインタフェースドメインの予約と格納状態のパス信号を受信することを意味し、そのピアからデータストリームを復号し、RSVP-構成ルータとしてRSVP信号で動作し、（更新されたパス信号を含む）を受信したIPデータグラムを転送しますその飛び地に。 H1、H2、およびH3によって発信パス信号は、したがって、飛び地のルーティングに応じてH4、H5、H6及び向かって転送されます。
H4, H5, and H6 now receive the original PATH signals and deliver them to their application.
H4、H5、およびH6は現在、元のパス信号を受信し、そのアプリケーションに配信します。
The application in H4, H5, and H6 decides to install the indicated reservations, meaning that they now reply with RESV signals. These signals request the bandwidth reservation. Following the trail left by the PATH signals, the RESV signals traipse back to their respective sources. The state left by the PATH signals leads them to VPN4, VPN5, and VPN6, respectively. If the routers in the enclaves are configured for RSVP, this will be explicitly via R4, R5, or R6; if they are not, routing will lead them through those routers.
H4、H5、およびH6内のアプリケーションは、彼らが今、RESV信号で応答することを意味し、指示された予約をインストールすることを決定します。これらの信号は、帯域予約を要求します。 PATH信号で左に道に続き、RESV信号が戻って、それぞれのソースに足を棒にして歩き回ります。 PATH信号で左の状態は、それぞれ、VPN4、VPN5、およびVPN6にそれらをリードしています。エンクレーブ内のルータは、RSVPのために設定されている場合、これはR4、R5、またはR6を介して明示的であろう。そうでない場合は、ルーティングはそれらのルータを介してそれらをリードします。
The various RSVP-configured routers en route in the enclave (including the VPN router on the "enclave" side) will verify that there is sufficient bandwidth on their links and that any other stated policy is also met. Having accomplished that, each will update its reservation state and forward the RESV signal to the next. The VPN routers will also each generate an RESV for the reservation within the interface domain, attempting to set or increase the bandwidth of the reservation appropriately.
（「エンクレーブ」側のVPNルータを含む）エンクレーブ内の途中の様々なRSVP-構成ルータは、そのリンク上の十分な帯域幅があること、および任意の他の記載ポリシーも満たされていることを確認します。それを達成したが、それぞれは、その予約状態を更新し、次へRESV信号を転送します。 VPNルータは、各設定または適切予約の帯域幅を増加しようとすると、インタフェースドメイン内の予約のRESVを生成します。
The various RSVP-configured routers en route in the interface domain (including VPN8) will verify that there is sufficient bandwidth on their links and that any other stated policy is also met. Having accomplished that, each will update its reservation state and forward the RESV signal to the next. VPN8 will also generate an RESV for the reservation within the inner domain, attempting to set or increase the bandwidth of the reservation appropriately. This gets the reservation to the inner deaggregator, VPN8.
（VPN8含む）界面領域における途中の様々なRSVP-構成ルータは、そのリンク上の十分な帯域幅があること、および任意の他の記載ポリシーも満たされていることを確認します。それを達成したが、それぞれは、その予約状態を更新し、次へRESV信号を転送します。 VPN8も設定したり、適切に予約の帯域幅を増加しようとすると、内部ドメイン内での予約のためのRESVを生成します。これは内側のデアグリゲータ、VPN8に予約を取得します。
The various RSVP-configured routers en route in the inner domain (including VPN7) will verify that there is sufficient bandwidth on their links and that any other stated policy is also met. Having accomplished that, each will update its reservation state and forward the RESV signal to the next. This gets the signal to VPN7.
（VPN7含む）内ドメインにおける途中の様々なRSVP-構成ルータは、そのリンク上の十分な帯域幅があること、および任意の他の記載ポリシーも満たされていることを確認します。それを達成したが、それぞれは、その予約状態を更新し、次へRESV信号を転送します。これはVPN7に信号を取得します。
VPN7 acts as an [RFC3175] aggregator for the inner domain. This means that it receives the RESV signal for the inner domain reservation and stores state, decrypts the data stream from VPN8, operates on the RSVP signals as an RSVP-configured router, and forwards the received IP datagrams (including the updated RESV signals) into its interface domain. The RESV signals originated by VPN4, VPN5, and VPN6 are therefore forwarded towards VPN1, VPN2, and VPN3 through the interface domain.
VPN7は、内部ドメインの[RFC3175]アグリゲータとして機能します。これに（更新RESV信号を含む）を受信したIPデータグラムを、内側のドメインの予約格納状態のためのRESV信号を受信VPN8からのデータストリームを復号し、RSVP-構成ルータとしてRSVP信号で動作し、転送することを意味しますそのインターフェースのドメイン。 VPN4、VPN5、およびVPN6によって発信RESV信号は、従って、インタフェースドメインを介してVPN1、VPN2、およびVPN3に向かって転送されます。
VPN1, VPN2, and VPN3 each act as an [RFC3175] aggregator for the interface domain. This means that it receives the RESV signal for the interface domain reservation and stores state, decrypts the data stream from its peer, operates on the RSVP signals as an RSVP-configured router, and forwards the received IP datagrams (including the updated RESV signals) into its enclave. The RESV signals originated by H4, H5, and H6 are therefore forwarded towards H1, H2, and H3 according to the routing of the enclave.
VPN1、VPN2、およびVPN3インタフェースドメインの[RFC3175]アグリゲータとしてそれぞれ作用します。これは、それがインタフェースドメインの予約と格納状態のためのRESV信号を受信したことを意味し、そのピアからデータストリームを復号し、RSVP-構成ルータとしてRSVP信号で動作し、（更新されたRESV信号を含む）を受信したIPデータグラムを転送しますその飛び地に。 H4、H5、H6とによって発信RESV信号は、従って飛び地のルーティングに応じてH1、H2、およびH3に向かって転送されます。
H1, H2, and H3 now receive the original RESV signals and deliver them to their application.
H1、H2、およびH3は現在、オリジナルのRESV信号を受信し、そのアプリケーションに配信します。
Without going through the details called out in Sections 2.3.1 and 2.3.2, if sufficient bandwidth exists to support them, reservations of other precedence levels or other applications may also be installed across this network. If the "routine" reservations already described are for voice, for example, and sufficient bandwidth is available under the relevant policy, a reservation for voice at the "priority" precedence level might be installed. Due to the mechanics of preemption, however, this would not expand the existing "routine" reservations in the interface and inner domains, as doing this causes loss of information - how much of the reservation is now "routine" and how much is "priority"? Rather, this new reservation will open up a separate set of tunnels or security associations for traffic of its application class at its precedence between that aggregator and deaggregator.
十分な帯域幅がそれらをサポートするために存在する場合は、セクション2.3.1および2.3.2に呼び出さ詳細を経由せずに、他の優先レベルまたは他のアプリケーションの予約も、このネットワークを介してインストールすることができます。すでに説明した「日常」の予約は、例えば、音声用であり、十分な帯域幅は、関連する政策の下で提供された場合は、「優先」の優先レベルでの音声の予約が取り付けられている場合があります。プリエンプションの仕組みに、しかし、これはこれは情報の損失が発生することとして、インターフェースや内部ドメイン内の既存の「日常」の予約を拡張しません - どのくらいの予約は今、「日常的」であり、「優先順位どのくらいです「？むしろ、この新しい予約は、アグリゲータとデアグリゲータの間にその優先でそのアプリケーションクラスのトラフィックのためのトンネルやセキュリティアソシエーションの別個のセットを開きます。
As a side note, there is an opportunity here that does not exist in the PSTN. In the PSTN, all circuits are potentially usable by any PSTN application under a certain set of rules (H channels, such as those used by video streams, must be contiguous and ordered). As such, if a channel is not made available to routine traffic but is made available to priority traffic, the operator is potentially losing revenue on the reserved bandwidth and deserves remuneration. However, in the IP Internet, some bandwidth must be kept for basic functions such as routing, and, in general, policies will not permit 100% of the bandwidth on an interface to be allocated to one application at one precedence. As a result, it may be acceptable to permit a certain portion (e.g., 50%) to be used by routine voice and a larger amount (e.g., 60%) to be used by voice at a higher precedence level. Under such a policy, a higher precedence reservation for voice might not result in the preemption of a routine call, but rather impact elastic traffic, and might be accepted at a time that a new reservation of lower precedence might be denied.
注意点として、PSTNに存在していないここに機会があります。 PSTNでは、全ての回路は、ルールの特定のセット（例えば、ビデオストリームによって使用されるようなHチャネルが、連続およびオーダーでなければならない）の下で任意のPSTNアプリケーションによって潜在的に使用可能です。チャネルはルーチントラフィックに利用可能となるのではなく、優先順位のトラフィックに使用可能になった場合などのように、オペレータは、潜在的に確保された帯域幅に収入を失い、報酬に値するされます。しかし、IPインターネットでは、いくつかの帯域幅は、ルーティングなどの基本的な機能のために維持されなければならない、そして、一般的には、ポリシーが1つの優先に1つのアプリケーションに割り当てられるインターフェイスの帯域幅の100％を許可しません。結果として、（例えば、50％）ルーチン音声及び（例えば、60％）がより高い優先順位レベルで音声が使用するより多くが使用する特定の部分を可能にするために許容可能であり得ます。こうした方針の下、音声のための優先順位の高い予約はルーチン呼び出しのプリエンプションにつながるのではなく、弾性トラフィックに影響を与える、と低い優先順位の新しい予約が拒否される可能性がある時点で受理される可能性がありますいない可能性があります。
In microwave networks, such as satellite or mobile ad hoc, one could also imagine network management intervention that could change the characteristics of the radio signal to increase the bandwidth under some appropriate policy.
衛星やモバイルアドホックとしてマイクロ波ネットワークでは、1はまた、いくつかの適切なポリシーの下で帯域幅を増やすために、無線信号の特性を変えることができるネットワーク管理介入を想像できます。
So we now have a number of reservations across the network described in Figure 5 including several reservations at "routine" precedence and one at "priority" precedence. For sake of argument, let us presume that the link from VPN7 to R9 is now fully utilized - all of the bandwidth allocated by policy to voice at the routine or priority level has been reserved. Let us further imagine that a new "priority" reservation is now placed from H3 to H6.
だから我々は今、いくつかの「日常」の優先順位で予約して、「優先順位」の優先順位1つを含む、図5で説明したネットワーク全体の予約数を持っています。引数のために、私たちはVPN7からR9へのリンクは、現在十分に活用されていることを想定してみましょう - ルーチンまたは優先順位レベルでボイスポリシーによって割り当てられた帯域幅のすべてが予約されています。私たちは、さらに新しい「優先順位」予約は今H3からH6に配置されていることを想像してみましょう。
The process described in Section 2.3.1 is followed, resulting in PATH state across the network for the new reservation. This is installed even though it is not possible to install a new reservation on VPN7- R9, as it does not install any reservation and the network does not know whether H6 will ultimately require a reservation.
2.3.1項に記載された方法は、新たな予約のためにネットワークを介してパス状態で得られ、続いています。これは、任意の予約をインストールしていないと、ネットワークがH6が最終的に予約が必要になりますかどうかわからないよう、VPN7- R9に新しい予約をインストールすることはできませんにもかかわらず、インストールされています。
The process described in Section 2.3.2 is also followed. The application in H6 decides to install the indicated reservation, meaning that it now replies with an RESV signal. Following the trail left by the PATH signal, the RESV signal traipses back towards H3. VPN6 and (if RSVP was configured) R6 verify that there is sufficient bandwidth on their links and that any other stated policy is also met. Having accomplished that, each will update its reservation state and forward the RESV signal to the next. VPN6 also generates an RESV for the reservation within the interface domain, attempting to set or increase the bandwidth of the reservation appropriately.
セクション2.3.2に記載された方法も続きます。 H6内のアプリケーションは、それが今RESV信号を返信することを意味し、示された予約をインストールすることを決定します。 PATH信号で左に道に続き、RESV信号はバックH3に対するtraipses。 VPN6と（RSVPが設定されている場合）R6は、そのリンク上に十分な帯域幅があることを、他の明記方針も満たされていることを確認します。それを達成したが、それぞれは、その予約状態を更新し、次へRESV信号を転送します。 VPN6も適宜予約の帯域幅を設定するか、または増加させるためにしようと、インタフェースドメイン内予約RESVを生成します。
VPN6, R8, and VPN8's "interface domain" sides now verify that there is sufficient bandwidth on their links and that any other stated policy is also met. Having accomplished that, each will update its reservation state and forward the RESV signal to the next. VPN8 will also generate an RESV for the reservation within the inner domain, attempting to set or increase the bandwidth of the reservation appropriately. This gets the reservation to the inner deaggregator, VPN8.
VPN6、R8、及びVPN8の「インターフェースドメイン」側は、今ではリンク上およびその他の定められた方針も満たされていることを、十分な帯域幅があることを確認してください。それを達成したが、それぞれは、その予約状態を更新し、次へRESV信号を転送します。 VPN8も設定したり、適切に予約の帯域幅を増加しようとすると、内部ドメイン内での予約のためのRESVを生成します。これは内側のデアグリゲータ、VPN8に予約を取得します。
VPN8's "inner domain" side and R9 now verify that there is sufficient bandwidth on their links and that any other stated policy is also met. At R9, a problem is detected - there is not sufficient bandwidth under the relevant policy. In the absence of precedence, R9 would now return an RESV Error indicating that the reservation could not be increased or installed. In such a case, if a preexisting reservation of lower bandwidth already existed, the previous reservation would remain in place but the new bandwidth would not be granted, and the originator (H6) would be informed. Let us clarify what it means to be at a stated precedence: it means that the POLICY_DATA object in the RESV contains a Preemption Priority and a Defending Priority with values specified in some memo. With precedence, [RFC4495]'s algorithm would have the Preemption Priority of the new reservation compared to the Defending Priority of extant reservations in the router, of which there are two: one VPN7->VPN8 at "routine" precedence and one VPN7->VPN8 at "priority" precedence. Since the Defending Priority of routine reservation is less than the Preemption Priority of a "priority" reservation, the "routine" reservation is selected. R9 determines that it will accept the increase in its "priority" reservation VPN7->VPN8 and reduce the corresponding "routine" reservation. Two processes now occur in parallel:
VPN8の「内側領域」側とR9は、今では、リンク上に十分な帯域幅があることを、他の明記方針も満たされていることを確認します。 R9では、問題が検出された - 関連するポリシーの下で十分な帯域幅がありません。優先度がない場合には、R9は今、予約が増加したりインストールすることができなかったことを示すRESVエラーを返します。低帯域幅の既存の予約がすでに存在する場合、このような場合には、以前の予約は場所にとどまるだろうが、新しい帯域幅が付与されないだろう、と発信元（H6）が通知されます。私たちは、それが定められた優先度であることを意味するもの明確にしましょう：それはRESVでPOLICY_DATAオブジェクトは、いくつかのメモで指定した値で先取り優先権や防衛優先順位が含まれていることを意味します。 1 VPN7-> VPN8 『日常』の優先順位と1 VPN7-で：優先して、[RFC4495]のアルゴリズムは、2つが存在しているのルータでは現存の予約、のディフェンディング優先順位と比較して新しい予約の先取り優先権を持っているでしょう>「優先度」の優先順位でVPN8。ルーチン予約のディフェンディング優先順位が「優先」予約の先取り優先権よりも小さいので、「日常」の予約が選択されています。 R9は、その「優先順位」予約VPN7-> VPN8の増加を受け入れ、対応する「日常」の予約を削減することを決定します。 2つのプロセスが今並列に発生します。
o The routine reservation is reduced following the algorithms in [RFC4495] and
Oルーチン予約は[RFC4495]でアルゴリズム以下に低減され
o The priority reservation continues according to the usual rules.
O優先予約は通常の規則に従って継続します。
R9 reduces its "routine" reservation by sending an RESV Error updating its internal state to reflect the reduced reservation and sending an RESV Error to VPN8 requesting that it reduce its reservation to a number less than or equal to the relevant threshold less the sum of the competing reservations. VPN8, acting as a deaggregator, makes two changes. On the "inner domain" side, it marks its reservation down to the indicated rate (the most it is now permitted to reserve), so that if an RESV Refresh event happens, it will request the specified rate. On the "interface domain" side, it selects one or more of the relevant reservations by an algorithm of its choosing and requests that it likewise reduce its rate. For the sake of argument, let us imagine that the selected reservation is the one to VPN5. The RESV Error now makes its way through R8 to VPN5, which similarly reduces its bandwidth request to the stated amount and passes a RESV Error signal on the "enclave" side requesting that the reservation be appropriately reduced.
R9は、以下の関連するしきい値以下の和に等しい数にその予約を減らすことを要求して減少し、予約を反映するように、その内部状態を更新し、VPN8にRESVエラーを送信するRESVエラーを送信することによって、その「日常」で予約を減らしました予約を競合します。 VPN8は、デアグリゲータとして機能し、2つの変更を行います。 RESVリフレッシュイベントが発生した場合、それは指定されたレートを要求するように、「内側領域」側では、それは、ダウン指示された割合（ほとんどは、今予約するために許可されている）への予約をマークします。 「インターフェースドメイン」側では、その選択したアルゴリズムにより、関連する予約の一つ以上を選択し、それは同様にその速度を低減することを要求します。引数のために、私たちが選択した予約がVPN5に1であることを想像してみましょう。 RESVエラーは、現在と同様に述べ量に対するその帯域幅要求を低減し、予約が適切に低減することを要求する「エンクレーブ」側のRESVエラー信号を通過VPN5にR8を介して、その方法を、作ります。
H5 is now faced with a decision. If the request is to reduce its reservation to zero, that is equivalent to tearing down the reservation. In this simple case, it sends an RESV Tear to tear down the reservation entirely and advises its application to adjust its expectations of the session accordingly, which may mean shutting down the session. If the request is to reduce it below a certain value, however, it may be possible for the application to do so and remain viable. For example, if a VoIP application using a G.711 codec (80 kbps) is asked to reduce its bandwidth below 70 kbps, it may be possible to renegotiate the codec in use to G.729 or some other codec. In such a case, the originating application should re-reserve at the stated bandwidth (in this case, 70 kbps), initiate the application level change, and let the application change the reservation again (perhaps to 60 kbps) when it has completed that process.
H5は現在、意思決定に直面しています。要求はゼロにその予約を削減することであるならば、それは予約を切断することと同じです。この単純なケースでは、それは完全に予約を切断するRESV引裂きを送信し、セッションをシャットダウンを意味し得る。従って、セッションのその期待を調整するために、そのアプリケーションに通知します。要求が一定値以下に削減することである場合は、しかし、それはそうと、生存し続けるためのアプリケーションのために可能かもしれません。 G.711コーデック（80 kbps）を使用して、VoIPアプリケーション70 kbpsの下にその帯域幅を減少させるために要求された場合、例えば、G.729またはいくつかの他のコーデックに使用されているコーデックを再交渉することが可能です。このような場合には、発信アプリケーションは、（この場合、70 kbpsの）記載帯域幅でリザーブを再度アプリケーションレベルの変更を開始し、それはそれを完了したときに、アプリケーションが（おそらく60 kbpsに）再度予約を変更できなければなりません処理する。
At the time the reservation is being processed at R9, for the "priority" reservation, R9 believes that it has sufficient bandwidth and that any other stated policy is also met, and it forwards the RESV to VPN7. Each will update its reservation state and forward the RESV signal to the next. VPN7 now acts as an [RFC3175] aggregator for the inner domain. This means that it receives the RESV signal for the inner domain reservation and stores state, decrypts the data stream from VPN8, operates on the RSVP signals as an RSVP-configured router, and forwards the received IP datagrams (including the updated RESV signals) into its interface domain. The RESV signals originated by VPN4, VPN5, and VPN6 are therefore forwarded towards VPN1, VPN2, and VPN3 through the interface domain.
予約はR9で処理されている時には、「優先順位」の予約のために、R9は、それが十分な帯域幅を持ち、他に述べた方針も満たされていることと信じて、それがVPN7にRESVを転送します。それぞれは、その予約状態を更新し、次へRESV信号を転送します。 VPN7現在、インナードメインの[RFC3175]アグリゲータとして機能します。これに（更新RESV信号を含む）を受信したIPデータグラムを、内側のドメインの予約格納状態のためのRESV信号を受信VPN8からのデータストリームを復号し、RSVP-構成ルータとしてRSVP信号で動作し、転送することを意味しますそのインターフェースのドメイン。 VPN4、VPN5、およびVPN6によって発信RESV信号は、従って、インタフェースドメインを介してVPN1、VPN2、およびVPN3に向かって転送されます。
VPN3 now acts as an [RFC3175] aggregator for the interface domain. This means that it receives the RESV signal for the interface domain reservation and stores state, decrypts the data stream from its peer, operates on the RSVP signals as an RSVP-configured router, and forwards the received IP datagrams (including the updated RESV signals) into its enclave. The RESV signal originated by H6 is therefore forwarded towards H3 according to the routing of the enclave.
VPN3は現在インタフェースドメインの[RFC3175]アグリゲータとして機能します。これは、それがインタフェースドメインの予約と格納状態のためのRESV信号を受信したことを意味し、そのピアからデータストリームを復号し、RSVP-構成ルータとしてRSVP信号で動作し、（更新されたRESV信号を含む）を受信したIPデータグラムを転送しますその飛び地に。 H6によって発信RESV信号は、従って、飛び地のルーティングに応じH3に向かって転送されます。
H3 now receives the original RESV signals and delivers it to the relevant application.
H3は現在、オリジナルのRESV信号を受信し、関連するアプリケーションに配信します。
This section details the data flows within a VPN router, in the context of sessions as described in Section 2. It specifically identifies the signaling flow at a given VPN boundary and additionally elaborates the signaling mechanism with the aid of a Network Guard. A use case describing the proposal in the context of an operational scenario is presented herein.
第2節で説明したように、このセクションでは、データの詳細をそれが具体的に指定されたVPN境界でシグナリングフローを識別し、さらにネットワークガードを用いてシグナリングメカニズムを詳しく説明セッションのコンテキストで、VPNルータ内を流れます。動作シナリオの文脈で提案を説明するユースケースは、本明細書に提示されます。
+-----------------------+ +----------------------+
| +--------------------+| |+--------------------+|
| |RSVP || ||Aggregate RSVP ||
| | || || ||
| |Per session: || ID ||Agg. Session ||
| | Destination ||--->|| Agg. Destination ||
| | Source || || Agg. Source= self ||
| | potential SPI || || Agg. SPI generated||
| | DSCP ---------> DSCP ||
| | vPort or protocol---------> vPort ||
| | and port || || ||
| | Mean rate ---------> Sum of mean rates ||
| | Peak rate ---------> f(Peak rates) ||
| | Burst Size ---------> Sum of Burst sizes||
| | || || ||
| +--------------------+| |+--------------------+|
| +--------------------+| |+--------------------+|
| | IP || || IP ||
| +--------------------+| |+--------------------+|
| +--------------------+| |+--------------------+|
| | Plaintext Interface|| ||Ciphertext Interface||
| +--------------------+| |+--------------------+|
+-----------------------+ +----------------------+
Figure 6: Data Flows in a VPN Router Outbound
図6：データは、VPNルータのアウトバウンドに流れます
Parameters on a reservation include:
予約上のパラメータは、次のとおりです。
Destination Address: On the plaintext side, the VPN router participates in the end-to-end reservations being installed for plaintext sessions. These may include individual flows as described in [RFC2205], IPsec data flows [RFC2207], aggregate reservations [RFC3175], or other types. It passes an identifier for the ciphertext side of the deaggregator to its ciphertext unit.
宛先アドレス：平文側では、VPNルータは、プレーンテキストセッションのために設置されたエンド・ツー・エンドの予約に参加しています。 [RFC2205]に記載されているように、これらは、IPsecのデータは、集約の予約[RFC3175]、又は他のタイプ流れる[RFC2207]個々のフローを含むことができます。それは、その暗号文ユニットにデアグリゲーターの暗号文側の識別子を渡します。
DSCP: The DSCP of the plaintext data flow is provided to the cipher text side.
DSCP：平文データフローのDSCPを、暗号文側に設けられています。
Virtual Port: The virtual destination port is provided to the cipher text side. This may be derived from an [RFC2207] session object or from policy information.
仮想ポート：仮想宛先ポートは、暗号文側に提供されます。これは[RFC2207]セッションオブジェクトから、またはポリシー情報から導出することができます。
Mean Rate: The sum of the plaintext mean rates is provided to the ciphertext unit.
料金平均：平文平均レートの合計は、暗号文ユニットに提供されます。
Peak Rate: A function of the plaintext peak rates is provided to the ciphertext unit. This function is less than or equal to the sum of the peak rates.
ピークレート：平文ピークレートの関数は暗号文ユニットに提供されます。この関数は、以下のピークレートの和に等しいです。
Burst Size: The sum of the burst sizes is provided to the cipher text unit.
バーストサイズ：バーストサイズの合計は、暗号文ユニットに提供されます。
Messages include:
メッセージは次のとおりです。
Path: The plaintext PATH message is sent as encrypted data to the ciphertext unit. In parallel, a trigger needs to be sent to the ciphertext unit that results in it generating the corresponding aggregated PATH message for the ciphertext side.
パス：平文PATHメッセージは、暗号文単位に暗号化したデータとして送信されます。並行して、トリガーは、暗号文側に対応する集約されたPATHメッセージを生成することになる暗号文ユニットに送信する必要があります。
Path Error: This indicates that a PATH message sent to the remote enclave was in error. In the error case, the message itself is sent on as encrypted data, but a signal is sent to the ciphertext side in case the error affects the ciphertext reservation (such as removing or changing state).
パスエラー：これは、リモート飛び地に送信されたPATHメッセージがエラーであったことを示します。エラーの場合に、メッセージ自体が暗号化されたデータのように送信されるが、エラーが（このような状態を除去または変更されるように）暗号文の予約に影響を与える場合には信号が暗号文側に送られます。
Path Tear: The PATH Tear message is sent as encrypted data to the ciphertext unit. In parallel, a signal is sent to the cipher text side; it will trigger a Path Tear on its reservation in the event that this is the last aggregated session, or change the SENDER_TSPEC of the aggregated session.
パスの涙：PATH涙メッセージが暗号文単位に暗号化したデータとして送信されます。並行して、信号は、暗号文側に送られます。これが最後の集約のセッションである場合にその要予約パスの涙をトリガ、または集計セッションのSENDER_TSPECを変更します。
RESV: The plaintext RESV message is sent as encrypted data to the ciphertext unit. In parallel, a trigger needs to be sent to the ciphertext unit that results in it generating the corresponding aggregated RESV message for the ciphertext side.
RESV：平文RESVメッセージは、暗号文単位に暗号化されたデータとして送信されます。並行して、トリガーは、暗号文側に対応する集約RESVメッセージを生成することになる暗号文ユニットに送信する必要があります。
RESV Error: This indicates that a RESV message that was received as data and forwarded into the enclave was in error or needed to be preempted as described in [RFC3181] or [RFC4495]. In the error case, the message itself is sent on as encrypted data, but a signal is sent to the ciphertext side in case the error affects the ciphertext reservation (such as removing or changing state).
RESVエラー：これは、データとして受信し、飛び地に転送されたRESVメッセージがエラーであったか、[RFC3181]または[RFC4495]に記載されているようにプリエンプトするために必要なことを示しています。エラーの場合に、メッセージ自体が暗号化されたデータのように送信されるが、エラーが（このような状態を除去または変更されるように）暗号文の予約に影響を与える場合には信号が暗号文側に送られます。
RESV Tear: The RESV Tear message is sent as encrypted data to the ciphertext unit. In parallel, a signal is sent to the cipher text side; it will trigger a RESV Tear on its reservation in the event that this is the last aggregated session, or reduce the bandwidth of an existing reservation.
RESV引裂：RESV涙メッセージが暗号文単位に暗号化されたデータとして送信されます。並行して、信号は、暗号文側に送られます。これが最後の集約のセッションである場合にその予約のRESVの涙を誘発する、または既存の予約の帯域幅を削減します。
RESV Confirm: This indicates that a RESV message received as data and forwarded into the enclave, and is now being confirmed. This message is sent as encrypted data to the ciphertext side, and, in parallel, a signal is sent to potentially trigger an RESV Confirm on the aggregate reservation.
RESVの確認：これは、RESVメッセージがデータとして受信し、飛び地に転送されていることを示し、現在は確認されています。 RESV集約予約を確認トリガこのメッセージは、暗号文側へ暗号化データとして送信され、そして、並行して、信号は、潜在的に送信されます。
+-----------------------+ +----------------------+
| +--------------------+| |+--------------------+|
| |RSVP || ||Aggregate RSVP ||
| | || || terminated ||
| |Per session: |+ || ||
| | Destination || || ||
| | Source <---------Decrypted RSVP ||
| | potential SPI || || message sent to ||
| | DSCP || || Plaintext unit ||
| | vPort or protocol || || *as data* for ||
| | and port || || normal processing ||
| | Mean rate || || ||
| | Peak rate || || ||
| | Burst Size || || ||
| | || || ||
| +--------------------+| |+--------------------+|
| +--------------------+| |+--------------------+|
| | IP || || IP ||
| +--------------------+| |+--------------------+|
| +--------------------+| |+--------------------+|
| |Plaintext Interface || ||Ciphertext Interface||
| +--------------------+| |+--------------------+|
+-----------------------+ +----------------------+
Figure 7: Data Flows in a VPN Router Inbound
図7：データは、VPNルータインバウンドに流れます
The aggregate reservation is terminated by the ciphertext side of the VPN router. The RSVP messages related to the subsidiary sessions are carried in the encrypted tunnel as data, and therefore arrive at the plaintext side with other data. As the plaintext side participates in these reservations, some information is returned to the ciphertext size to parameterize the aggregate reservation as described in Section 3.1.1 in the processing of the outbound messages.
集計予約はVPNルータの暗号文側で終了します。補助セッションに関連するRSVPメッセージは、データとして暗号化されたトンネル内で運ば、したがって他のデータと平文側に到達しています。平文側がこれらの予約に参加したように、いくつかの情報は、アウトバウンド・メッセージの処理にセクション3.1.1で説明したように、集約の予約をパラメータ化するために暗号文のサイズに戻されます。
3.2. VPN Routers That Use the Network Guard for Signaling across the Cryptographic Boundary
3.2. 暗号境界を越えたシグナル伝達のためのネットワークガードを使用してVPNルータ
As described in Section 1.6 the Network Guard provides an additional path for the reservation signaling between the plaintext and cipher text domains.
1.6節で説明したようにネットワークガードは、平文と暗号文のドメイン間のシグナリング予約のための追加の経路を提供します。
_.------------.
,--'' Plaintext Domain--.
,-' +--------+ +--------+ `-.
,' | Host | | Host | `.
,' +--------+ +--------+ `.
; :
| +----------------------+ |
: | +--------+ | |
`. | | Router | | ,'
`. | +---+----+ | ,'
`- | +----------+ | ,'
---| +-+--+ +-+--+--+ |'
|----|E/D |--|Net Grd| | VPN Router
,-'| +-+--+ +-+--+--+ |\
, | +----------+ | \
,' | +---+----+ | `.
,' | | Router | | |
/ | +--------+ | \
; +----------------------+ :
| |
: Ciphertext Domain ;
Figure 8: RSVP Passage via Network Guard
図8：ネットワークを経由してガードRSVPパッセージ
In this context, the VPN router is composed of a plaintext router, a ciphertext router, an encrypt/decrypt implementation (such as a line card or interface device), and a network management process that manages the encrypt/decrypt implementation and potentially passes defined information flows between the plaintext and ciphertext domains. If the Network Guard is implemented as a software process that exchanges configuration instructions between the routers, this is simple to understand. If it is built as a separate systems exchanging datagrams, it is somewhat more complex, but conceptually equivalent. For example, the ciphertext router would consider an IP datagram received via the Network Guard (control plane) as having been received from and concerning the interface used in the data plane to the encrypt/decrypt unit.
この文脈において、VPNルータは平文ルータで構成され、暗号文ルータ、暗号化/（このようなラインカードまたはインタフェース・デバイスとして）実装を復号化し、暗号化を管理するネットワーク管理プロセス/実装を復号化し、潜在的に定義された通過情報は、平文と暗号文ドメイン間を流れます。ネットワークガードがルータ間の設定手順を交換するソフトウェアプロセスとして実装されている場合、これは理解することは簡単です。それはデータグラムを交換する別々のシステムとして構築されている場合、それは幾分より複雑であるが、概念的に等価。例えば、暗号文ルータから受信した暗号化/復号化ユニットへデータプレーンで使用されるインターフェースに関するれたようなネットワークガード（制御プレーン）を介して受信したIPデータグラムを検討します。
Encrypt/decrypt units may not be capable of terminating and originating flows as described in Section 3.1, and policy may prevent knowledge of the ciphertext network addresses in the plaintext router. In such a case, the plaintext and ciphertext routers may use the Network Guard as the path for the signaling flows. The Network Guard performs the following functions to enable the flow of reservation signaling across the cryptographic domain
セクション3.1で説明したように暗号化/復号化ユニットはフローを終了し、発信することができないことがあり、ポリシーは平文ルータの暗号文ネットワークアドレスに関する知識を防止することができます。このような場合には、平文と暗号文ルータは、シグナリングフローのパスなどのネットワークガードを使用してもよいです。ネットワークガードは、暗号化ドメイン全体予約シグナリングの流れを可能にするために、以下の機能を実行します
o transforms plaintext session identifiers into ciphertext session identifiers and vice-versa in IP datagrams and RSVP objects (e.g. IP addresses)
Oは、暗号文セッション識別子とIPデータグラムにその逆とRSVPオブジェクト（例えばIPアドレス）に平文セッション識別子を変換します
o performs resource management of aggregated reservations (e.g., including ciphertext encapsulation overhead to resources requested)
oは（要求されたリソースへの暗号文カプセル化オーバーヘッドを含む例えば、）集約の予約のリソース管理を行います
o reads and writes configuration on the encrypt/decrypt units as necessary (e.g., reads plaintext to ciphertext IP address mapping)
Oは、読み出しおよび暗号化の設定を書き込む/（例えば、IPアドレスのマッピングを暗号文する平文を読み取る）必要に応じて単位を復号化
In addition, the plaintext and ciphertext routers must support a routing function or local interface that ensures that aggregated RSVP messages flow via the Network Guard. However, the signaling flow across the entire VPN router at a cryptographic boundary remains identical to the description in Section 3.1.
加えて、平文と暗号文ルータは、ルーティング機能または集約RSVPメッセージがネットワークガードを介して流れることを保証するローカルインタフェースをサポートしなければなりません。しかし、暗号境界における全VPNルータを横切るシグナリングフローは、セクション3.1で説明と同じままです。
A reader may note that the VPN router described in Figure 8 can be collapsed into a single router with two halves, or the Network Guard and the encrypt/decrypt units can be part of the plaintext router. The details of alternate logical and physical architectures for the VPN router are beyond the scope of this document.
読者は、図8で説明したVPNルータは、2つの半体、またはネットワークガードおよび暗号化/復号化ユニットと単一のルータにすることが可能であることに注意することができる平文ルータの一部とすることができます。 VPNルータの代替論理および物理アーキテクチャの詳細は、このドキュメントの範囲を超えています。
........................................
: VPN Router A :
: :
:+-----------++----------++-----------+:
+------+ RSVP :| || NetGrd-A || |:
|Host A|<---->:|PT-Router-A|+----------+|CT-Router-A|::::::::
+------+ :| || E/D-A || |: ::
:+-----------++----------++-----------+: ::
: A-RSVP : ::
: <:::::::::::::> : ::
:......................................: ::
A-RSVP ::
,---.
,' `.
/ \
; Interface :
| Domain |
: ;
\ /
`. ,'
'---'
A-RSVP ::
........................................ ::
: VPN Router B : ::
: : ::
:+-----------++----------++-----------+: ::
+------+ RSVP :| || NetGrd-B || |: ::
|Host B|<---->:|PT-Router-B|+----------+|CT-Router-B|::::::::
+------+ :| || E/D-B || |:
:+-----------++----------++-----------+:
: A-RSVP :
: <:::::::::::::> :
:......................................:
Figure 9: Aggregated RSVP via Network Guard
図9：ネットワーク経由ガード集約RSVP
The above figure depicts a simple use case for aggregated signaling with the Network Guard. In this scenario, Host A initiates RSVP signaling to Host B for a reservation. The RSVP signaling between the hosts is encapsulated by the VPN routers into encrypted tunnels. Aggregated RSVP signaling is triggered by VPN routers, and flows into the CT-Routers, as well as the interface domains, to reserve resources at RSVP-capable routers on the path. The aggregation/ deaggregation point for RSVP reservations in this use case are the PT-Routers. The signaling aggregation of RSVP into A-RSVP at the PT-Router is similar to the data flow described in Section 3.1. The
上図は、ネットワークガードと凝集シグナリングのための単純なユースケースを示しています。このシナリオでは、ホストAは、予約のためのホストBにRSVPシグナリングを開始します。ホスト間のRSVPシグナリングは暗号化トンネルにVPNルータによってカプセル化されます。集約RSVPシグナリングは、VPNルータによってトリガされ、経路上のRSVP対応ルータでリソースを予約するために、CT-ルータ、ならびに界面領域に流入します。このユースケースにRSVP予約のための凝集/脱凝集点PT-ルータです。 PT-ルータにRSVP-にRSVPシグナリングの集合は、セクション3.1で説明したデータフローと同様です。ザ・
Network Guard performs the additional functions described in Section 3.2.1 to transform plaintext A-RSVP messages into suitable ciphertext A-RSVP messages. A typical reservation set up in this case would follow these steps.
ネットワークGuardは、適切な暗号文A-RSVPメッセージに平文A-RSVPメッセージを変換するために3.2.1節で説明する追加機能を実行します。この場合には設定の典型的な予約は次の手順に従います。
o Host A sends RSVP PATH message to Host B.
OホストAは、BをホストするためのRSVP PATHメッセージを送信します
o PT-Router-A encapsulates RSVP PATH message in encrypted tunnel to VPN Router B.
O PT-ルータ-Aは、VPNルータBに暗号化されたトンネル内のRSVP PATHメッセージをカプセル化します
o CT Routers and Interface domain carry encrypted RSVP PATH message (like any other encrypted data message).
O CTルータおよびインターフェイスのドメインは、（他の暗号化されたデータメッセージのような）暗号化されたRSVP PATHメッセージを運びます。
o PT-Router-B decrypts RSVP Path Message and sends an E2E PathErr message to PT-Router-A in the encrypted tunnel.
O PT-ルータ-BがRSVP PATHメッセージを復号化し、暗号化されたトンネル内PT-ルータ-AにE2EのPathErrメッセージを送信します。
o PT-Router-B forwards decrypted plaintext RSVP PATH message to Host B.
O PT-ルータ-Bの転送は、Bをホストする平文RSVP PATHメッセージを解読します
o PT-Router-A receives E2E PathErr and sends an aggregated RSVP PATH message towards PT-Router-B via the Network Guard.
O PT-ルータ-Aは、E2EのPathErrを受信し、ネットワークを介してガードPT-ルータ-Bに向かって集約RSVP PATHメッセージを送信します。
o The NetGrd-A transforms the plaintext aggregate RSVP into the ciphertext aggregate RSVP message as described in Section 3.2.1 and sends it to the CT-Router-A.
O NetGrd-Aは、セクション3.2.1に記載したように、暗号文の集合RSVPメッセージに平文集合RSVPを変換し、CT-ルータ-Aに送信します。
o The ciphertext aggregated RSVP message travels through ciphertext routers in the interface domain.
O暗号文集約RSVPメッセージは、インタフェース領域における暗号文ルータを通過します。
o CT-Router-B receives the ciphertext aggregate RSVP message and sends it to the NetGrd-B.
O CT-ルータ-Bは、暗号文の集合RSVPメッセージを受信しNetGrd-Bに送信します。
o The NetGrd-B transforms the ciphertext aggregate RSVP into the plaintext aggregate RSVP message as described in Section 3.2.1 and sends it to the PT-Router-B.
O NetGrd-Bは、セクション3.2.1に記載したように、平文集約RSVPメッセージに暗号文の集合RSVPを変換し、PT-ルータ-Bに送信します。
The subsequent RSVP and Aggregate RSVP signaling follows a similar flow, as described in detail in [RFC3175] and [RFC4860]to aggregate each plaintext reservation into a corresponding ciphertext reservation. This ensures that RSVP-capable ciphertext routers reserve the required resources for a plaintext end-to-end reservation. Subsequent mechanisms, such as preemption or the increase and decrease of resources reserved, may be applied to these reservations as described before in this document. The RSVP data flow as described in Section 3.1 within the VPN router (from the plaintext router to the ciphertext router via the Guard) provides necessary and sufficient information to routers in the ciphertext domain to implement the QoS solution presented in the document.
対応する暗号文予約にそれぞれ平文予約を集約する[RFC3175]及び[RFC4860]に詳細に記載されるように、その後のRSVPと集約RSVPシグナリングは、同様のフローに従います。これは、RSVP対応の暗号文ルータが平文エンドツーエンドの予約のために必要なリソースを確保することを保証します。本書で前に記載されているようなプリエンプションまたは予約されたリソースの増減などの後続のメカニズムは、これらの予約に適用されてもよいです。 （平文ルータからガードを介して暗号文ルータへの）VPNルータ内のセクション3.1に記載されているようなRSVPデータフローは、文書のQoSソリューションを実装するために暗号文ドメイン内のルータに必要かつ十分な情報を提供します。
In this description, we have described the Network Guard as being separate from the encrypt/decrypt unit. This separation exists because in certain implementations, it is mandated by those who specify the devices. The separation does not come for free, however; the separation of the devices for system-engineering purposes is expensive, and it imposes architectural problems. For example, when the Guard is used to aggregate RSVP messages or Protocol Independent Multicast (PIM) routing, the traffic is destined to the remote VPN router. This means that the Guard must somehow receive and respond to, on behalf of the VPN Router, messages that are not directed to it. Several possible solutions exist; they should be selected carefully based on the security and implementation needs of the environment. They are as follows:
この説明では、暗号化/復号化部から分離しているようなネットワークガードを記載しています。特定の実装では、それはデバイスを指定する人々によって義務付けられているので、この分離が存在します。分離は、しかし、無料で付属していません。システム・エンジニアリングの目的のためにデバイスの分離は高価であり、それは建築の問題を課します。例えば、ガードがRSVPメッセージまたはプロトコル独立マルチキャスト（PIM）ルーティングを集約するために使用される場合、トラフィックはリモートVPNルータ宛れます。これは、Guardが何らかの形で受け取り、VPNルータ、それに向けていないメッセージに代わって、に応答しなければならないことを意味します。いくつかの可能なソリューションが存在します。彼らは、環境のセキュリティと実装のニーズに基づいて慎重に選択する必要があります。それらは次の通りです：
o In the simplest case, the Network Guard and encrypt/decrypt unit can be two independent functions that utilize a common network and MAC layer. This can allow the two functions to share a common MAC and IP address, so that traffic destined for one function is also received by the other. In the case that these two functions are physically separated on two devices, they can still share a common MAC and IP address; however, additional modifications may be required on the Guard to filter and not process IP traffic not destined for itself.
O最も単純なケースでは、ネットワークガードおよび暗号化/復号化ユニットは、共通のネットワークとMACレイヤを利用する二つの独立した機能であることができます。これは、1つの機能に向かうトラフィックは他で受信されるように、2つの機能は、一般的なMACおよびIPアドレスを共有できるようにすることができます。これら二つの機能は、物理的に二つのデバイスに分離される場合には、彼らはまだ、共通のMACおよびIPアドレスを共有することができます。しかしながら、さらなる修飾は、それ自体に向けられていないIPトラフィックを処理フィルタリングしないようにガード上で必要とされ得ます。
o The ciphertext interface of the Guard could be placed into promiscuous mode, allowing it to receive all messages and discard all but the few it is interested in. The security considerations on putting a device in promiscuous mode at the VPN boundary needs to be taken into account in this method.
oをガードの暗号文インタフェースは、それがすべてのメッセージを受信し、すべてを破棄することができ、無差別モードに配置することができるが、いくつかは、それがに興味があります。VPN境界ニーズに無差別モードでデバイスを置くことで、セキュリティの考慮事項がに入れなければこの方法でアカウント。
o The Guard could be engineered to receive all from the ciphertext router and pass the bulk of it on to the VPN router through another interface. In this case, the Guard and the VPN router would use the same IP address. This mechanism puts the load of all data and management traffic destined for the VPN router upon the Guard.
O Guardは暗号文ルータから全てを受信し、別のインターフェイスを介してVPNルータへのバルクを渡すように操作することができます。この場合、GuardとVPNルータは、同じIPアドレスを使用します。このメカニズムは、ガード時にVPNルータ宛てのすべてのデータと管理トラフィックの負荷を置きます。
o The VPN router could be engineered to receive all traffic from the ciphertext router and pass any unencrypted traffic it receives to the Guard through another interface. In this case, the Guard and the VPN router would use the same IP address.
O VPNルータは、暗号文ルータからのすべてのトラフィックを受信し、それが別のインタフェースを介してガードを受ける任意の暗号化されていないトラフィックを通過するように操作することができます。この場合、GuardとVPNルータは、同じIPアドレスを使用します。
o All the VPN router functions, as shown in Figure 9, could be incorporated into a single chassis, with appropriate internal traffic management to send some traffic into the plaintext enclave and some to the Guard. In this case, the Guard and the VPN router would be -- at least, functionally -- the same system.
すべてのVPNルータ機能O、図9に示すように、平文エンクレーブとGuardにはいくつかの中にいくつかのトラフィックを送信するために適切な内部トラフィック管理と、単一の筐体に組み込むことができます。この場合には、ガード及びVPNルータがあろう - 少なくとも、機能 - 同じシステム。
Of these, clearly the last is the simplest architecturally and the one that most minimizes the attendant risk.
これらのうち、明確最後は建築最も簡単かつアテンダントリスクを最小化するものです。
The typical security concerns of datagram integrity, node and user authentication are implicitly met by the security association that exists between the VPN routers. The secure data stream that flows between the VPN routers is also used for the reservation signaling datagrams flowing between VPN routers. Information that is contained in these signaling datagrams receives the same level of encryption that is received by the data streams.
データグラムの完全性、ノードおよびユーザー認証の一般的なセキュリティ上の懸念は、暗黙的にVPNルータの間に存在するセキュリティアソシエーションによって満たされています。 VPNルータの間を流れる安全なデータストリームはまた、VPNルータとの間を流れるデータグラムをシグナリング予約するために使用されます。これらのシグナリングデータグラムに含まれる情報は、データストリームによって受信される暗号化の同じレベルを受信します。
One of the reasons cited for the nesting of VPN routes in Section 1.3 is the different levels of security across the nested VPN routers. If the security level decreases from one VPN router to the next VPN Router in the nested path, the reservation signaling datagrams will, by default, receive the lower security-level treatment. For most cases, the lower security treatment is acceptable. In certain networks, however, the reservation signaling across the entire nested path must receive the highest security-level treatment (e.g., encryption, authentication of signaling nodes). For example, the highest precedence level may only be signaled to VPN routers that can provide the highest security levels. If any VPN router in the nested path is incapable of providing the highest security level, it cannot participate in the reservation mechanism.
セクション1.3でVPNルートのネスティングのために引用した理由の一つは、ネストされたVPNルータを横断セキュリティのさまざまなレベルです。セキュリティレベルは、ネストされたパスの一方のVPNルータから次のVPNルータに減少した場合、予約シグナリングデータグラムは、デフォルトでは、低セキュリティレベルの処理を受けます。ほとんどの場合、セキュリティの低い治療が可能です。特定のネットワークでは、しかし、全体のネストされた経路を横切ってシグナル予約は、最高のセキュリティレベルの処理（例えば、暗号化、ノードシグナリングの認証）を受けなければなりません。例えば、最高の優先レベルは、最高のセキュリティレベルを提供することができるVPNルータにシグナリングすることができます。ネストされたパス内の任意のVPNルータは、最高のセキュリティレベルを提供することができない場合は、予約メカニズムに参加することはできません。
In the general case, the nested path may contain routers that are either incapable of participating in VPNs or providing required security levels. These routers can participate in the reservation only if the lower security level is acceptable (as configured by policy) for the signaling of reservation datagrams.
一般的な場合では、ネストされたパスのいずれかのVPNに参加し又は必要なセキュリティレベルを提供することができないルータを含むことができます。これらのルータは、予約データグラムのシグナリングのために（ポリシーで構成されるように）低いセキュリティレベルが許容可能である場合にのみ、予約に参加することができます。
VPN routers encapsulate encrypted IP packets and prepend an extra header on each packet. These packets, whether used for signaling or data, should be identifiable, at a minimum by the IP addresses and DSCP value. Therefore, the prepended header should contain, at a minimum, the DSCP value corresponding to the signaled reservation in each packet. This may literally be the same DSCP as is used for the data (forcing control plane traffic to receive the same QoS treatment as its data), or a different DSCP that is routed identically (separating control and data-plane traffic QoS but not routing).
VPNルータは暗号化されたIPパケットをカプセル化し、各パケットに余分なヘッダを付加しました。これらのパケットは、シグナリングまたはデータのために使用されるかどうか、IPアドレスとDSCP値で最小で、識別可能であるべきです。したがって、付加ヘッダは、最低でも、各パケットにおけるシグナリングの予約に対応するDSCP値を含むべきです。これは文字通り、または同じルーティングされる異なるDSCP（そのデータと同じQoS処理を受信するために制御プレーントラフィックを強制）（制御およびデータプレーントラフィックのQoSを分離するが、ルーティングではない）データに使用されるのと同じDSCPであってもよいです。
Additionally security considerations as described in [RFC4860] and [RFC3175] are also applicable in this environment; they include the integrity of RSVP messages can be ensured via mechanisms described in [RFC2747] and [RFC3097] and related key management (through manual configuration or a key management protocol) at nodes between any aggregator and deaggregator pair that processes the messages. In addition, confidentiality can be provided between hops by employing IPsec. Further work in the IETF MSEC Working Group may be applicable in these environments for key management and confidentiality.
[RFC4860]で説明し、[RFC3175]もこの環境で適用されるように加え、セキュリティの考慮事項。それらは、RSVPメッセージの完全性は、メッセージを処理し、任意のアグリゲータとデアグリゲーター対の間のノードに[RFC2747]及び[RFC3097]及び（手動設定またはキー管理プロトコルを介して）に関連する鍵管理に記載の機構を介して確保することができる含みます。また、機密性は、IPsecを使用することにより、ホップの間に設けることができます。 IETF MSECワーキンググループにおける更なる作業は、鍵管理と機密保持のために、これらの環境に適用することができます。
Doug Marquis, James Polk, Mike Tibodeau, Pete Babendreier, Roger Levesque, and Subha Dhesikan gave early review comments.
ダグ侯爵、ジェームズ・ポーク、マイク・Tibodeau、ピートBabendreier、ロジャー・レヴェック、およびサブハDhesikanは、初期のレビューコメントを与えました。
Comments by Sean O'Keefe, Tony De Simone, Julie Tarr, Chris Christou, and their associates resulted in Section 3.2.
ショーン・オキーフ、トニー・デ・シモーネ、ジュリーター、クリスChristouの、そして彼らの仲間のコメントは、セクション3.2になりました。
Francois Le Faucheur, Bruce Davie, and Chris Christou (with Pratik Bose) added [RFC4860], which clarified the interaction of this approach with the DSCP.
フランソワルFaucheur、ブルースデイビー、及び（Pratikボーズ有する）クリスChristouのはDSCPこのアプローチの相互作用を明らかに[RFC4860]を、追加しました。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]ブレーデン、B.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1機能仕様"、RFC 2205、1997年9月。
[RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
[RFC2207]バーガー、L.とT.オマリー、 "IPSECデータフローのためのRSVP拡張機能"、RFC 2207、1997年9月。
[RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[RFC2746] Terzis、A.、Krawczyk、J.、Wroclawski、J.、およびL.チャン、 "RSVPオペレーションオーバーIPトンネル"、RFC 2746、2000年1月。
[RFC2750] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[RFC2750]ヘルツォーク、S.、 "ポリシー制御のためのRSVP拡張機能"、RFC 2750、2000年1月。
[RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000.
[RFC2996] Bernet、Y.、 "RSVP DCLASSオブジェクトのフォーマット"、RFC 2996、2000年11月。
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[RFC3175]ベーカー、F.、Iturralde、C.、ルFaucheur、F.、およびB.デイビー、 "IPv4とIPv6の予約のためのRSVPの集約"、RFC 3175、2001年9月。
[RFC4495] Polk, J. and S. Dhesikan, "A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow", RFC 4495, May 2006.
[RFC4495]ポーク、J.とS. Dhesikan、「リソース予約プロトコル（RSVP）の予約フローの帯域幅の削減のための拡張」、RFC 4495、2006年5月。
[RFC4542] Baker, F. and J. Polk, "Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite", RFC 4542, May 2006.
[RFC4542]ベイカー、F.とJ.ポーク、RFC 4542「インターネットプロトコルスイートでサービスのリアルタイムのための緊急通信サービス（ETS）を実装」、2006年5月。
[RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. Davenport, "Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations", RFC 4860, May 2007.
[RFC4860]ルFaucheur、F.、デイビー、B.、ボーズ、P.、Christouの、C.、およびM.ダヴェンポート、 "汎用集計リソース予約プロトコル（RSVP）予約"、RFC 4860、2007年5月。
[ITU.MLPP.1990] International Telecommunications Union, "Multilevel Precedence and Preemption Service", ITU-T Recommendation I.255.3, 1990.
[ITU.MLPP.1990]国際電気通信連合、 "マルチレベル優先順位および優先処理サービス"、ITU-T勧告I.255.3、1990。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC1633]ブレーデン、B.、クラーク、D.、およびS. Shenker、 "インターネットアーキテクチャにおける統合サービス：概要"、RFC 1633、1994年6月。
[RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules", RFC 2209, September 1997.
[RFC2209]ブレーデン、B.およびL.チャン、 "資源予約プロトコル（RSVP） - バージョン1つのメッセージ処理ルール"、RFC 2209、1997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J.、RFC 2210、1997年9月 "IETF統合サービスとRSVPの使用"。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.、およびW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]ベーカー、F.、リンデル、B.、およびM. Talwar、 "RSVP暗号化認証"、RFC 2747、2000年1月。
[RFC2872] Bernet, Y. and R. Pabbati, "Application and Sub Application Identity Policy Element for Use with RSVP", RFC 2872, June 2000.
[RFC2872] Bernet、Y.およびR. Pabbati、 "RSVPで使用するアプリケーションおよびサブアプリケーションIDポリシー要素"、RFC 2872、2000年6月。
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001.
[RFC3097]ブレーデン、R.とL.チャン、 "RSVP暗号化認証 - 更新メッセージタイプ価値"、RFC 3097、2001年4月。
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001.
[RFC3181]ヘルツォーク、S.、RFC 3181 2001年10月、 "先取り優先権方針要素が通知さ"。
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182, October 2001.
[RFC3182] Yadavが、S.、Yavatkar、R.、Pabbati、R.、フォード、P.、ムーア、T.、ヘルツォーク、S.、およびR.ヘス、 "RSVPのID表現"、RFC 3182、2001年10月。
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[RFC3246]デイビー、B.、Charny、A.、ベネット、J.、ベンソン、K.、ルBoudec、J.、コートニー、W.、Davari、S.、Firoiu、V.、およびD. Stiliadis、 "緊急転送PHB（ホップ単位動作）」、RFC 3246、2002年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
[RFC3312]キャマリロ、G.、マーシャル、W.、およびJ.ローゼンバーグ、RFC 3312、2002年10月 "資源管理とセッション開始プロトコル（SIP）の統合"。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]バーガー、L.、 "一般化マルチプロトコルラベルスイッチング（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を拡張"、RFC 3473、2003年1月。
[RFC3474] Lin, Z. and D. Pendarakis, "Documentation of IANA assignments for Generalized MultiProtocol Label Switching (GMPLS) Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage and Extensions for Automatically Switched Optical Network (ASON)", RFC 3474, March 2003.
[RFC3474]林、Z.およびD. Pendarakis、 - 、RFC「一般化マルチプロトコル・ラベルのためのIANAの割り当てのドキュメント（GMPLS）リソース予約プロトコルスイッチングトラフィックエンジニアリング（RSVP-TE）使用と拡張機能を自動的に交換光ネットワーク（ASON）のために」 3474、2003年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
Authors' Addresses
著者のアドレス
Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, California 93117 USA
フレッドベイカーシスコシステムズ1121ヴィアデル・レイサンタバーバラ、カリフォルニア93117 USA
Phone: +1-408-526-4257 Fax: +1-413-473-2403 EMail: fred@cisco.com
電話：+ 1-408-526-4257ファックス：+ 1-413-473-2403 Eメール：fred@cisco.com
Pratik Bose Lockheed Martin 700 North Frederick Ave Gaithersburg, Maryland 20871 USA
Pratikボーズロッキード・マーティン700ノースフレデリック・アベニューゲイサーズバーグ、メリーランド州20871 USA
Phone: +1-301-240-7041 Fax: +1-301-240-5748 EMail: pratik.bose@lmco.com
電話：+ 1-301-240-7041ファックス：+ 1-301-240-5748 Eメール：pratik.bose@lmco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。