[要約] 要約：RFC 4923は、ネストされた仮想プライベートネットワーク（VPN）でのサービス品質（QoS）シグナリングに関するガイドラインです。 目的：このRFCの目的は、ネストされたVPN環境でのQoSシグナリングの実装と運用に関する問題を解決し、ネットワークのパフォーマンスと効率を向上させることです。
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）The IETF Trust（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）の内部部分と外部部分の間の通信、またはそのようなネットワークの連結を通じて通信が必要です。異なる優先順位を持つ通信。このメモは、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
ますます多くのネットワークは、パブリックランまたはワンを介した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は、セクション1.3でさらに明確にされています。これは、ネストされたVPNを、「顧客プロビジョニング」VPNのコンテキストでIPSECまたはIPSECのようなVPNの例として説明しています。その結果、「Plantext」と「ciphertext」インターフェイスをサポートするVPNルーターについて説明します。ただし、概念は、識別されたポイントでネットワークを出入りするIPトラフィックの[RFC3175]で提案されている概念や、ジェネリックルーティングカプセル化（GRE）、IPを含む他の種類のトンネルの使用を含む、あらゆる形態の集約に容易に拡張されます。/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トンネルは、ルーティングされたネットワークの他の機能と同様に、ホストには見えないことです。ホストは、「そこにあるもの」がPATH 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.
アプリケーションの1つのクラスは、特定の時間までに各パケットのデータを必要とし、それまでにデータが到着していない場合、データは本質的に価値がありません。これらの「リアルタイム」アプリケーションと呼びます。別のクラスのアプリケーションは、常にデータが到着するのを待ちます。これらの「弾性」アプリケーションと呼びます。
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ペイロードは、20ミリ秒間隔で160バイトサンプル（40バイトのIP/ UDP/ RTPヘッダー）で配信されます。これにより、沈黙の抑制なしで80 kbpsの帯域幅が得られ、レイヤー2のオーバーヘッドを占めません。リアルタイムで動作するには、G.711コーデックでは、IPレイヤーで80 kbpsで通信をサポートするためにデータが配信されるネットワークが必要です。これが不可能な場合（遅延に大きな損失または大きな変動がある場合）、音声の質が低下します。一方、容量の多くのメガビットが利用可能な場合、G.711コーデックも帯域幅の要件を増加させません。適応コーデックは存在しますが（例：G.722.2またはG.726）、適応メカニズムは、より大きな帯域幅を必要とすることができ、必要なデータフローの品質が満たされない帯域幅要件の特定の範囲内でのみ適応できます。ただし、弾性アプリケーションは一般に任意のネットワークに適応します。ボトルネックが毎秒9600ビットを提供する場合、Web転送または電子メール交換は毎秒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は最初に[RFC2205]で定義されており、[RFC2209]で定義されている一連のデータグラム処理ルールと統合サービスの詳細[RFC2210]。概念的には、このプロトコルは、ソースアプリケーションから宛先アプリケーションへのデータフローを識別し、それらの特定のリソースを要求する方法を指定します。ソースは、明示的または黙示的にリストされている単一のマシンまたはマシンのセットである場合がありますが、目的地は単一のマシンまたはマルチキャストグループ（したがって、その中のすべてのマシン）である場合があります。各アプリケーションは、IPプロトコルフィールドのトランスポートプロトコル番号で指定されているか、宛先およびおそらくソースポート番号を追加する場合があります。プロトコルは、IPv4 [RFC0791]とIPv6 [RFC2460]の両方に対して定義されます。さまざまな種類のトンネルに対して同じ機能を実行する手段を提供する必要があることもすぐに認識されました。これは、内部とトンネルの外側の関係との関係を意味します。したがって、定義は、IPSEC [RFC2207]および[RFC4860]、およびより一般的な形態のトンネル[RFC2746]のために開発されました。差別化されたサービスアーキテクチャ[RFC2475]のその後の開発により、[RFC2996]の標準RSVPデータフローによって使用される差別化されたサービスコードポイント（DSCP）[RFC2474]を指定し、IPアドレスのペアを使用するように定義が追加されました。データフローの識別情報としてのDSCP [RFC3175]。
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.
さらに、プロトコルの最初の定義には、ポリシー情報、および予約の先制のためのプレースホルダーが含まれていました。このプレースホルダーは、後に[RFC2750]で詳細に指定され、ポリシー[RFC2872]をアイデンティティ[RFC3182]に関連付け、それによりネットワークが認証された認定ユーザーに契約サービスを提供できるようになりました。これは、[RFC3312]のセッション開始プロトコル[RFC3261]と統合されました。予約の先制は[RFC3181]のように指定されます。これは、予約の優先度を使用してネットワークにインストールされ、別の防御優先度を使用して保持される予約は、予約全体を削除するRESVエラー信号を介してネットワークによって削除される場合があります。しかし、これには問題がそれほど白黒ではないことが多いという点で問題があります。問題が80 kbpsの既存の予約が維持できなくなったが、60 kbpsの予約が維持される可能性がある場合、VoIP送信者はG.711コーデックからG.729コーデックに変更してそれを達成できる可能性があります。または、トンネルまたは他の集合体に複数のセッションがある場合、コールの1つを排除することができます。[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.
o 識別されたパケットのIPアドレスではなく、ネットワーク内のイングレスデバイスと出口デバイスのIPアドレス、およびトラフィックが使用するDSCPのIPアドレスを識別するRFC 3175セッションオブジェクト。
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 イングレスルーターで動作し、「顧客」ネットワークからの個々の予約を受け入れる予約「アグリゲーター」の機能。予約をトンネルまたはMPLS LSPのISPコアに集約し、Deaggregatorに残すことが知られている交通ストリームとして集計します。
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 出力ルーターで動作し、集約的な予約とデータストリームを分割し、他のネットワークに渡される可能性のある個々のデータストリームに戻る予約「Deaggregator」の機能。
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で指定されたセッションオブジェクトは有用ですが、本質的に必要ではありません。ISPネットワークがMPLS LSP、IP/IP、またはGREトンネルなどのトンネルを使用している場合、またはIPSECセキュリティ協会を囲む場合、アグリゲーターとデーグレジャーターの概念は同じ方法で機能しますが、予約メカニズムは[RFC3473]および[RFC3473]と[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ルーターの概念構造は、他のルーターの概念構造と似ています。最も単純な形式では、物理的には2つ以上のポートデバイス（図4に示すものと同様）であり、保護されたエンクレーブに1つ以上のインターフェイスがあり、外の世界に1つ以上のインターフェイスがあります。後者では、ルーティングの観点からポイントツーポイントインターフェイスとして扱うことができるいくつかのトンネル（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.
暗号化/復号化ユニットは、プレーンテキストルーターの関数、そのインターフェイスカードの関数として、またはPlantextルーターの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:
さらに、Ciphertextドメインに対して集約されたシグナル伝達を生成する必要があります。これはいくつかの方法で達成される場合があります：
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 Plantextルーターで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または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で説明されています。プレーンテキストとciphertextドメインの間の情報の流れには
o IP datagrams via the encrypt/decrypt unit,
o 暗号化/復号化ユニットを介したIPデータグラム、
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.
したがって、ある飛び地のホストが別の飛び地のホストに予約を開くと、適切なタイプとサイズの予約が端から端まで作成されます。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ルーターが同様に、Ciphertextドメイン全体のピア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での音声セッションの集合」です。これにより、ネットワーク管理は、「総帯域幅がしきい値QNを超えない場合、「優先順位の新しいセッションPNの新しいセッションが受け入れられる可能性があります。新しいセッションを可能な限り受け入れるために、より低い優先事項が先制的に減少する可能性があります。」
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.
[RFC3175]の場合、DSCPは予約と対応するデータストリームの両方を識別するために使用する必要があるため、異なる優先順位レベルの総予約には異なる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:
どちらの場合でも、基本的な必要性は、1つのVPNルーターが[RFC3175]と呼ばれるものとして機能し、別のVPNルーターが「Deaggregator」として機能し、それらの間に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
o 予約とデータは、VPNルーター間のセキュリティ関連で行われます。
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]でさらに説明します。問題は、多くの場合、単に予約を削除するためではなく、ネットワークの変更により予約の帯域幅を減らすことです。エンドシステムに起因する予約の場合、最終システムはコーデックの変更を通じてニーズに対応できる可能性があります。ある種の総計の場合、1つ以上の予約を完全にドロップすることで送信されている帯域幅を減らすことができます。
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または他の種類の集約された予約では、これはDeaggregator（トンネルの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 集計された留保の1つ以上を特定し、仕事をするのに十分なものを特定し、
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に1回のセッションを提示し、そのセッションの優先順位レベルが高いことを想像できます。インテリアリンクが混雑している場合（たとえば、予約された帯域幅は、コールが認められた場合、ポリシーを超えます）、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:
図5のネットワークには、3つのセキュリティレイヤーが示されています。6つのプレーンテキストが周辺の周りのエンクレーブ、1つのレイヤー（図では「インターフェイスドメイン」と呼ばれる）、および最初の2つを接続する3番目の暗号テキストドメイン（参照）でそれらを接続する2つの暗号文ドメインを示しています。図の「内側のドメイン」として）。以下の情報の分布が存在します。
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 各エンクレーブは、通信することが許可されている他の飛び地に関する一般的なルーティング情報にアクセスできます。INSシステムは、リモートホストまたはドメインの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.
o VPNルーター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.
この例は、一方向の予約を前方方向に配置することに注意してください。音声およびビデオアプリケーションでは、通常、各方向に予約があります。明確にするためには、逆方向については議論されていませんが、同じように逆方向に動作し、同じセキュリティ協会を使用します。
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.
次に、H1からH4、H2からH5、およびH3からH6の予約のセットをインストールし、議論のために、これらが「ルーチン」の優先順位にあると仮定しましょう。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）に開いている適切なセキュリティアソシエーションまたはトンネルがあることを確認します。これは、指定された優先順位レベルで指定されたアプリケーションのセキュリティ協会またはトンネルになります。それを達成した後、それはパス信号をセキュリティ協会に配置し、それを転送します。[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に開かれた適切なセキュリティ協会またはトンネルがあることを保証します。これは、指定された優先順位レベルで指定されたアプリケーションのセキュリティ協会またはトンネルになります。それを達成した後、それはパス信号をセキュリティ協会に配置し、それを転送します。[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] Deaggregatorとして機能します。これは、内側のドメイン予約のパス信号を受信し、状態を保存し、VPN7からデータストリームを復号化し、RSVP信号をRSVP構成ルーターとして動作させ、受信したIPデータグラム（更新されたパス信号を含む）を転送し、そのインターフェイスドメイン。したがって、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] Deaggregatorとして機能します。これは、インターフェイスドメインの予約のパス信号を受信し、状態を保存し、ピアからデータストリームを復号化し、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信号で返信することを意味します。これらの信号は、帯域幅の予約を要求します。パス信号によって残されたトレイルに続いて、RESV信号はそれぞれのソースに戻ります。パス信号によって残された状態は、それらをそれぞれ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信号を次のsv信号に転送します。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信号を次のsv信号に転送します。VPN8は、内部ドメイン内の予約のRESVも生成し、予約の帯域幅を適切に設定または増加させようとします。これにより、内側のDeaggregator、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信号を次のsv信号に転送します。これにより、信号が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信号を受信し、Store Stateの状態を受け取り、VPN8からデータストリームを復号化し、RSVP信号をRSVP構成ルーターとして動作させ、受信したIPデータグラム（更新されたRESV信号を含む）を転送します。そのインターフェイスドメイン。したがって、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構成ルーターとして動作させ、受信したIPデータグラム（更新されたRESV信号を含む）を転送することを意味します（更新されたRESV信号を含む）その飛び地に。したがって、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で呼び出された詳細を調べることなく、それらをサポートするのに十分な帯域幅が存在する場合、他の優先レベルまたは他のアプリケーションの予約もこのネットワーク全体にインストールされる場合があります。たとえば、すでに説明されている「ルーチン」予約が音声用であり、関連するポリシーの下で十分な帯域幅が利用できる場合、「優先度」の優先順位レベルでの音声の予約がインストールされる場合があります。ただし、先制のメカニズムにより、これはインターフェースと内部ドメインの既存の「ルーチン」予約を拡張することはありません。「？？むしろ、この新しい予約は、そのアグリゲーターとDeaggregatorの優先順位で、アプリケーションクラスのトラフィックのための別のトンネルまたはセキュリティ協会を開きます。
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インターネットでは、ルーティングなどの基本的な機能のために帯域幅を保持する必要があり、一般に、ポリシーは、インターフェイス上の帯域幅の100％が1つの優先順位で1つのアプリケーションに割り当てられることを許可しません。その結果、定期的な音声とより高い優先順位レベルで音声で使用されるより多くの量（60％）で使用される特定の部分（たとえば50％）を許可することが許容される場合があります。このようなポリシーの下では、音声の優先順位の高い予約は、日常的な呼び出しの先制につながることはなく、弾力性のあるトラフィックに影響を与える可能性があり、より低い優先順位の新しい予約が拒否される可能性があると受け入れられる可能性があります。
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.
衛星やモバイルアドホックなどのマイクロ波ネットワークでは、適切なポリシーの下で帯域幅を増やすために無線信号の特性を変更できるネットワーク管理介入を想像することもできます。
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.
そのため、「ルーチン」の優先順位でいくつかの予約と「優先度」の優先順位を含む、図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で説明されているプロセスに続いて、新しい予約のためにネットワークを横切るパス状態になります。これは、VPN7-R9に新しい予約をインストールすることは不可能であるにもかかわらずインストールされます。これは、予約をインストールせず、ネットワークではH6が最終的に予約を必要とするかどうかを知らないためです。
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信号で応答するようになりました。パス信号が残ったトレイルに続いて、RESV信号はH3に向かって動きます。VPN6および（RSVPが構成された場合）R6は、リンクに十分な帯域幅があり、他の記載されているポリシーも満たされていることを確認します。それを達成した後、それぞれが予約状態を更新し、RESV信号を次のsv信号に転送します。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信号を次のsv信号に転送します。VPN8は、内部ドメイン内の予約のRESVも生成し、予約の帯域幅を適切に設定または増加させようとします。これにより、内側のDeaggregator、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オブジェクトに、いくつかのメモで指定された値を備えた先制の優先順位と防御の優先度が含まれていることを意味します。優先順位がある[RFC4495]のアルゴリズムは、ルーターの現存する予約の防御の優先度と比較して、新しい予約の先制優先度があります。>「優先度」の優先順位での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は、内部状態を更新するRESVエラーを送信して予約の減少を反映し、VPN8にRESVエラーを送信することにより、「ルーチン」予約を削減し、予約を関連するしきい値以下に減らすことを要求します。競合する予約。Deaggregatorとして機能するVPN8は、2つの変更を行います。「内側のドメイン」側では、予約を指定されたレート（現在は予約が許可されている）までの予約をマークし、RESVリフレッシュイベントが発生した場合、指定されたレートを要求します。「インターフェイスドメイン」側では、選択のアルゴリズムによって関連する予約の1つ以上を選択し、同様にレートを下げることを要求します。議論のために、選択した予約がVPN5の予約であると想像してみましょう。RESVエラーにより、R8からVPN5への進出が行われ、同様に帯域幅要求が規定額に削減され、「エンクレーブ」側のRESVエラー信号に合格し、予約を適切に削減することを要求します。
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は十分な帯域幅があり、他の記載されているポリシーも満たされ、RESVをVPN7に転送すると考えています。それぞれが予約状態を更新し、RESV信号を次のresv信号に転送します。VPN7は、内部ドメインの[RFC3175]アグリゲーターとして機能するようになりました。これは、内側のドメイン予約のRESV信号を受信し、Store Stateの状態を受け取り、VPN8からデータストリームを復号化し、RSVP信号をRSVP構成ルーターとして動作させ、受信したIPデータグラム（更新されたRESV信号を含む）を転送します。そのインターフェイスドメイン。したがって、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構成ルーターとして動作させ、受信したIPデータグラム（更新されたRESV信号を含む）を転送することを意味します（更新されたRESV信号を含む）その飛び地に。したがって、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データフロー[RFC2207]、総予約[RFC3175]、または他のタイプが含まれます。Deaggregatorの暗号文の識別子をciphertextユニットに渡します。
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.
パス：Plantext Pathメッセージは、暗号化されたデータとしてCiphertextユニットに送信されます。並行して、トリガーをciphertextユニットに送信する必要があります。このユニットでは、それがciphertext側の対応する集計パスメッセージを生成することになります。
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 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 Tear：Path Tear Tearメッセージは、暗号化されたデータとしてCiphertextユニットに送信されます。並行して、信号が暗号テキスト側に送信されます。これが最後の集計セッションである場合、その予約のパス裂け目を引き起こしたり、集約セッションの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：Plantext RESVメッセージは、暗号化されたデータとしてCiphertextユニットに送信されます。並行して、トリガーを暗号文ユニットに送信する必要があります。このユニットでは、それがciphertext側の対応する集約された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ティアメッセージは、暗号化されたデータとしてCiphertextユニットに送信されます。並行して、信号が暗号テキスト側に送信されます。これが最後の集計セッションである場合、その予約で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で説明されているように、集計予約をパラメーター化します。
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ルーターは、プレーンテキストルーター、暗号文ルーター、暗号化/復号化の実装（ラインカードやインターフェイスデバイスなど）、および暗号化/デクリプトの実装を管理し、潜在的に定義されたパスを管理するネットワーク管理プロセスで構成されています。情報は、プレーンテキストドメインとciphertextドメインの間に流れます。ネットワークガードがルーター間で構成命令を交換するソフトウェアプロセスとして実装されている場合、これは簡単に理解できます。データグラムを交換する別のシステムとして構築されている場合、それはやや複雑ですが、概念的に同等です。たとえば、ciphertextルーターは、ネットワークガード（コントロールプレーン）を介して受信された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 集約された予約のリソース管理を実行します（例：ciphertextカプセル化オーバーヘッドを含む、要求されたリソースへ）
o reads and writes configuration on the encrypt/decrypt units as necessary (e.g., reads plaintext to ciphertext IP address mapping)
o 必要に応じて、暗号化/復号化ユニットの構成を読み取り、書き込みます（たとえば、plantextをciphertext 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.
さらに、Plantextおよび暗号文ルーターは、ネットワークガードを介して集約された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 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.
上記の図は、ネットワークガードとの集約されたシグナル伝達のための単純なユースケースを示しています。このシナリオでは、ホストAがRSVPシグナリングを開始して、予約のためにBをホストBにします。ホスト間のRSVPシグナル伝達は、VPNルーターによって暗号化されたトンネルにカプセル化されます。集約されたRSVPシグナル伝達は、VPNルーターによってトリガーされ、パス上のRSVP対応ルーターでリソースを予約するために、CTルーターとインターフェイスドメインに流れ込みます。このユースケースでのRSVP予約の集約/掘削ポイントは、PTルーターです。PTルーターでのRSVPのA-RSVPへのシグナル伝達集約は、セクション3.1で説明されているデータフローと類似しています。ネットワークガードは、セクション3.2.1で説明されている追加の機能を実行して、Plantext A-RSVPメッセージを適切な暗号文A-RSVPメッセージに変換します。この場合に設定された典型的な予約は、これらの手順に従います。
o Host A sends RSVP PATH message to Host B.
o ホストAはRSVPパスメッセージをホストBに送信します
o PT-Router-A encapsulates RSVP PATH message in encrypted tunnel to VPN Router B.
o PT-Router-Aは、暗号化されたトンネルのRSVPパスメッセージをVPNルーターBにカプセル化します。
o CT Routers and Interface domain carry encrypted RSVP PATH message (like any other encrypted data message).
o CTルーターとインターフェイスドメインには、暗号化されたRSVPパスメッセージが含まれます（他の暗号化されたデータメッセージと同様）。
o PT-Router-B decrypts RSVP Path Message and sends an E2E PathErr message to PT-Router-A in the encrypted tunnel.
o PT-Router-BはRSVPパスメッセージを復号化し、暗号化されたトンネルのPT-Router-AにE2E PATHERRメッセージを送信します。
o PT-Router-B forwards decrypted plaintext RSVP PATH message to Host B.
o PT-Router-Bフォワードフォワップdecrypted Plantext RSVPパスメッセージB.
o PT-Router-A receives E2E PathErr and sends an aggregated RSVP PATH message towards PT-Router-B via the Network Guard.
o PT-Router-AはE2E PATHERRを受信し、ネットワークガードを介してPT-Router-Bに向かって集計されたRSVPパスメッセージを送信します。
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で説明されているように、Plantext Aggregate RSVPをCiphertext Aggregate RSVPメッセージに変換し、CT-Router-Aに送信します。
o The ciphertext aggregated RSVP message travels through ciphertext routers in the interface domain.
o ciphertextの集約RSVPメッセージは、インターフェイスドメイン内の暗号文ルーターを介して移動します。
o CT-Router-B receives the ciphertext aggregate RSVP message and sends it to the NetGrd-B.
o CT-Router-Bは、ciphertext集計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で説明されているように、ciphertext集計RSVPをプレーンテキスト集約RSVPメッセージに変換し、PT-Router-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.
その後のRSVPおよび凝集RSVPシグナル伝達は、[RFC3175]および[RFC4860]で詳細に説明されているように、同様の流れに続き、各プレーンテキストの予約を対応する微細伸筋の予約に集約します。これにより、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ルーターに運命づけられます。これは、警備員が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レイヤーを利用する2つの独立した機能です。これにより、2つの関数が共通のMacおよびIPアドレスを共有できるようになるため、1つの関数に導かれるトラフィックも他の関数が受信します。これらの2つの機能が2つのデバイスで物理的に分離されている場合、それらはまだ共通の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 ガードのciphertextインターフェイスは無差別モードに配置され、すべてのメッセージを受信し、関心のある少数を除くすべてを破棄することができます。この方法で。
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 ガードは、暗号文からすべてを受け取るように設計され、その大部分を別のインターフェイスを介してVPNルーターに渡すことができます。この場合、ガードと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ルーターを設計して、Ciphertextルーターからすべてのトラフィックを受信し、他のインターフェイスを介してガードに受け取る暗号化されていないトラフィックを渡すことができます。この場合、ガードと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.
o 図9に示すように、すべてのVPNルーター機能は、適切な内部トラフィック管理を備えた単一のシャーシに組み込まれ、プレーンテキストエンクレーブにトラフィックを送信し、一部はガードに送信できます。この場合、ガードと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ルートのネストに引用された理由の1つは、ネストされたVPNルーター全体のセキュリティのレベルが異なることです。セキュリティレベルが1つの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処理を受けることを強制する）、または同一にルーティングされる異なるDSCP（コントロールとデータプレーンのトラフィックQOを分離しますが、ルーティングではない）である可能性があります。。
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]で説明されているセキュリティ上の考慮事項もこの環境に適用されます。これらには、[RFC2747]および[RFC3097]に記載されているメカニズムを介してRSVPメッセージの整合性が含まれ、メッセージを処理するアグリゲーターとDeaggregatorペア間のノードで関連するキー管理（手動構成またはキー管理プロトコルを介して）を含みます。さらに、IPSECを使用することにより、ホップ間で機密性を提供できます。IETF MSECワーキンググループでのさらなる作業は、主要な管理と機密性のためにこれらの環境で適用される場合があります。
Doug Marquis, James Polk, Mike Tibodeau, Pete Babendreier, Roger Levesque, and Subha Dhesikan gave early review comments.
Doug Marquis、James Polk、Mike Tibodeau、Pete Babendreier、Roger Levesque、Subha Dhesikanは、早期のレビューコメントをしました。
Comments by Sean O'Keefe, Tony De Simone, Julie Tarr, Chris Christou, and their associates resulted in Section 3.2.
ショーン・オキーフ、トニー・デ・シモーネ、ジュリー・ター、クリス・クリストゥー、および彼らの仲間によるコメントは、セクション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.
Francois Le Faucheur、Bruce Davie、およびChris Christou（Pratik Boseを使用）は[RFC4860]を追加しました。これは、このアプローチのDSCPとの相互作用を明らかにしました。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、B.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
[RFC2207] Berger、L。およびT. O'Malley、「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. Zhang、「RSVP Operation over IP Tunnels」、RFC 2746、2000年1月。
[RFC2750] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[RFC2750] Herzog、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] Baker、F.、Iturralde、C.、Le Faucheur、F.、およびB. Davie、「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] Polk、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] Baker、F。およびJ. Polk、「インターネットプロトコルスイートでのリアルタイムサービスの緊急通信サービス（ETS）の実施」、RFC 4542、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] Le Faucheur、F.、Davie、B.、Bose、P.、Christou、C。、およびM. Davenport、「Generic Aggregate Resource Reservation Protocol（RSVP）Reservations」、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] Postel、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] Braden、B.、Clark、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] Braden、B。およびL. Zhang、「リソース予約プロトコル（RSVP） - バージョン1メッセージ処理ルール」、RFC 2209、1997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J。、「IETF統合サービスでのRSVPの使用」、RFC 2210、1997年9月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW. Weiss、「差別化されたサービスの建築」、RFC 2475、1998年12月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747] Baker、F.、Lindell、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] Braden、R。およびL. Zhang、「RSVP暗号化認証 - 更新されたメッセージタイプ値」、RFC 3097、2001年4月。
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001.
[RFC3181] Herzog、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.、Ford、P.、Moore、T.、Herzog、S。、およびR. Hess、「RSVPのアイデンティティ表現」、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。、チャーニー、A。、ベネット、J。、ベンソン、K。、ル・ブーデック、J。、コートニー、W。、ダバリ、S。、フィロウ、V。、およびD.スティリアディス、 "迅速な転送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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、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] Camarillo、G.、Marshall、W。、およびJ. Rosenberg、「リソース管理とセッション開始プロトコルの統合（SIP）」、RFC 3312、2002年10月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、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] Lin、Z。およびD. Pendarakis、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）リソース予約プロトコル - トラフィックエンジニアリング（RSVP -TE）の使用（ASON）（ASON）の拡張機能のためのIANA割り当てのドキュメント」、RFC3474、2003年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
Authors' Addresses
著者のアドレス
Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, California 93117 USA
フレッドベイカーシスコシステム1121
Phone: +1-408-526-4257
Fax: +1-413-473-2403
EMail: fred@cisco.com
Pratik Bose Lockheed Martin 700 North Frederick Ave Gaithersburg, Maryland 20871 USA
Pratik Bose Lockheed Martin 700 North Frederick Ave Gaithersburg、Maryland 20871 USA
Phone: +1-301-240-7041
Fax: +1-301-240-5748
EMail: pratik.bose@lmco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。