RFC4923 日本語訳
4923 Quality of Service (QoS) Signaling in a Nested Virtual PrivateNetwork. F. Baker, P. Bose. August 2007. (Format: TXT=92632 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group F. Baker
Request for Comments: 4923 Cisco Systems
Category: Informational P. Bose
Lockheed Martin
August 2007
コメントを求めるワーキンググループF.ベイカー要求をネットワークでつないでください: 4923年のシスコシステムズカテゴリ: 情報のP.ボーズロッキード・マーチン2007年8月
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).
IETFが信じる著作権(C)(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.
ネットワークの中にはどんな情報が特に異なった先行をコミュニケーションへのサービスの質に提供している間境界の向こう側に伝えられるかに関して敏感さを持っているのを除いて、Virtual兵士のNetwork(VPN)の内部の、そして、外の部分の間、または、入れ子にされたVPNをもたらすそのようなネットワークの連結を通してコミュニケーションを必要とするものもあります。 この注意はDiffservネットワークの上のIntegrated Services操作のためにRFC2998で説明されるようにフレームワークに基づく提案されたソリューションの問題と本質について概説しようとします。
Baker & Bose Informational [Page 1] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[1ページ]のRFC4923QoS
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
1. 序論…3 1.1. 問題声明…3 1.2. 基礎的な情報と用語…4 1.3. VPNsを入れ子にします…5 1.4. QoS技術に合図します…7 1.5. 資源予約プロトコル(RSVP)…9 1.6. VPNルータの論理構造…10 2. 入れ子にされたVPNでの予約と先取り…13 2.1. 入れ子にされたVPNの予約…14 2.2. 入れ子にされたVPNでの先取り…16 2.3. 例を終えます…17 2.3.1. ネットワーク状態を生成して、通常の予約に頭文字をつけてください…18 2.3.2. 初期の通常の予約--予約を要求してください…19 2.3.3. 先行を使用する予約のインストール…20 2.3.4. 先取りを使用する予約のインストール…21 3. データはVPNルータの中を流れます…24 3.1. 暗号の境界の向こう側にデータを運ぶVPNルータ…24 3.1.1. 暗号文データへの平文は流れます…24 3.1.2. 平文データへの暗号文は流れます…27 3.2. ネットワークを使用するVPNルータは暗号の境界の向こう側に合図するために警備されます…28 3.2.1. シグナリングは流れます…29 3.2.2. ネットワーク警備があるケースを使用してください…30 4. セキュリティ問題…33 5. 承認…34 6. 参照…34 6.1. 標準の参照…34 6.2. 有益な参照…35
Baker & Bose Informational [Page 2] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[2ページ]のRFC4923QoS
1. Introduction
1. 序論
1.1. Problem Statement
1.1. 問題声明
More and more networks wish to guarantee secure transmission of IP traffic across public LANs or WANs and therefore use Virtual Private Networks. Some networks require communication between an interior and exterior portion of a VPN or through a concatenation of such networks resulting in a nested VPN, but have sensitivities about what information is communicated across the boundary, especially while providing quality of service to communications with different precedence. This note seeks to outline the issues and the nature of the proposed solutions. The outline of the QoS solution for real- time traffic has been described at a high level in [RFC4542]. The key characteristics of this proposal are that
ますます多くのネットワークが、公共のLANかWANの向こう側にIPトラフィックの安全な送信を保証して、したがって、Virtual兵士のNetworksを使用したがっています。 ネットワークの中にはどんな情報が特に異なった先行をコミュニケーションへのサービスの質に提供している間境界の向こう側に伝えられるかに関して敏感さを持っているのを除いて、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 Proxies、H.323 Gatekeepers、または他の呼び出し管理サブシステムと相互運用性を持っています。
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
メモの突きは何らかのフォームで暗号化を使用するVPNsを囲んでいます、IPsecや複数のネットワークドメイン中の彼らのその後の巣篭もりのように。 VPNsのこの特定のタイプはセクション1.3でさらにはっきりさせられます。('顧客の文脈の下におけるVPNが'VPNに食糧を供給したようにそれは、IPsecかIPsecに関する例として入れ子にされたVPNを記述します)。 その結果、私たちは「平文」と「暗号文」インタフェースをサポートするVPNルータについて議論するつもりです。 しかしながら、概念は容易にどんなフォームの集合にも達します、特定されるところでネットワークに入って、出るIPトラフィックの[RFC3175]で提案された概念を含んでいて
Baker & Bose Informational [Page 3] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[3ページ]のRFC4923QoS
points, and the use of other kinds of tunnels including Generic Routing Encapsulation (GRE), IP/IP, MPLS, and so on.
ポイント、およびGenericルート設定Encapsulation(GRE)、IP/IP、MPLSなどを含む他の種類のトンネルの使用。
1.2. Background Information and Terminology
1.2. 基礎的な情報と用語
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つを特定するのに本書では使用されます。どのデータグラムが次にコンピュータ・インタフェースで送られるかを決めるとき、スケジューラは使用されています。 優先度スケジューラは占領された最優先のクラス(待ち行列)からデータグラムをいつも選びます、ジターの大部分からそうでなければそれがもう1人のクラスに経験したジターを通過することによって1つのクラスのトラフィックを保護して。 [RFC3181]はある意味で、このドキュメントが「先行」を呼ぶという条件に用語を適用します。 「先行」という用語は「マルチレベル先行と先取り」[ITU.MLPP.1990]という句で暗示している意味で使用されます。 数人のクラスのセッションは他のものの上で優先します。その他のものは、述べられたセットの状況で認められて、そうでなければ、それがいなかったかもしれないか、または下側の先行セッションの偏見をいだかせている終了をもたらすかもしれないということである帯域幅をもたらすかもしれません。 現在の議論の目的のために、「優先権」は「先行」がセッションの方針属性であるデータグラムに適用された1セットのアルゴリズムです。 優先権比較のテクニックは先行を実装するのにルータか政策決定ポイントで使用されますが、それらは同じものではありません。
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
同じやり方で、読者が「先行」かデータの「重要性」に基づくQoS方針と方針の違いを人か機能に理解しているのは、それを使用することで重要です。 呼び出しの先行レベルにかかわらず、声はネットワークによって誘発された遅れの、高いレベルの変化によって妨害されています。 その結果、そのアプリケーションのトラフィックから他のアプリケーションまでのジターを移して、声は、優先待ち行列を使用することでしばしば修理されます。 通常の呼び出しに、これは声に関してそれがフラッシュトラフィックのためのものであるのと同じくらい本当です。 境界がある遅れを必要とするアプリケーショントラフィックのクラスがあります。 それは「ジターがありません」より異なった概念です。 彼らは述べられた領域の中でジターを受け入れることができます。 OSPFかBGPなどのルーティング・プロトコルはネットワークインフラの正しい機能に重要です。 適度の損失レベルでうまくいくように設計されていますが、それらは彼らによって助けられません、そして、短期の高い損失さえ劇的なネットワークイベントをもたらすことができます。 しかしながら、妥当な領域の中にそれがあるなら、問題には遅れの変化がありません。 その結果、ルータに、それが損失の確率を制限する方法でルーティング・プロトコルデータグラムを扱うのは一般的です、いくつかの場合、比較的高い遅れを受け入れて、トラフィックがネットワークに絶対に重要ですが。 交換にはこの特性がある通話セットアップ
Baker & Bose Informational [Page 4] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[4ページ]のRFC4923QoS
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.
さて: プロトコルの損失と、遅れと、同様のSIPとH.323の選択が遠くに直面されていて、後者を好んでください、データグラムが再送されなければならなくて、呼び出しが日常的であるかどうかにかかわらずこれが本当であるならそれであるだろうよりはるかに少ないか、または高い先行について呼び出し準備時間。 そういうものとして、QoS印はそれが現在の時間にどのように「重要であるかもしれないか」の如何にかかわらずアプリケーションに対する良いサービスを提供する方法を私たちに教えます、別々に多くの場合「重要性」を運ぶことができますが。
1.3. Nested VPNs
1.3. 入れ子にされたVPNs
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:
1つは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 平文インタフェースの現在decapsulatedされたデータグラムを進めます。
The use of IPsec in this manner is described as the tunnel mode of [RFC4301] and [RFC4303].
IPsecの使用はこの様に[RFC4301]と[RFC4303]のトンネルモードとして記述されています。
Baker & Bose Informational [Page 5] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[5ページ]のRFC4923QoS
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
ホストホストホストホストホストホスト/------------------/ /------------------/ルータ-------ルータ| VPN-ルータ|| || 発送されたネットワークを通したIPsec Tunnel|| VPN-ルータ| ルータ-------ルータ/------------------/ /------------------/ホストホストホストホストホストホスト
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
どんな目に見える/も接待しません。==================/ルータ| VPN-ルータ/---------------------/内側のドメイン/---------------------/VPN-ルータ| ルータ/==================目に見えない/ホスト
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
そのようなネットワークを入れ子にして、複雑な方法で再使用できます。 図3に示されるように、1組の飛び地は様々な理由で再暗号化されて、より大きい暗号文ネットワークの向こう側に伝えられる暗号文ネットワークの向こう側に交信するかもしれません。 推論します。
Baker & Bose Informational [Page 6] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[6ページ]のRFC4923QoS
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.
これをするのは異なりますが、より広いネットワークで情報隠蔽に関連します、と異なったレベルのセキュリティは異なった同封の飛び地などのために必要としました。
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
ホストホストホストホストホストホスト/------------------/ /------------------/ルータ-------ルータ| VPN-ルータVPN-ルータVPN-ルータ/---------------------/ /----------/ルータ-------------ルータ| VPN-ルータVPN-ルータ/-----------/ /----------/ルータ-------ルータ| | ルータ-------ルータ/-----------/ /----------/VPN-ルータVPN-ルータ| ルータ------------ルータ/---------------------/ /----------/VPN-ルータVPN-ルータVPN-ルータ| ルータ-------ルータ/------------------/ /------------------/ホストホストホストホストホストホスト
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?"
このドキュメントが探検されるという主要な質問は「予約、および予約の先取りはそのような環境でどのようにうまくいきますか?」ということです。
1.4. Signaled QoS Technology
1.4. 合図されたQoS技術
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]:
ネットワークのためのIntegrated Servicesモデルは元々、[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つのクラスのアプリケーションはある時間までに各パケットでデータを必要とします、そして、データがその時までに到着していないなら、データは本質的には価値がありません。 私たちはこれらの「リアルタイムで」のアプリケーションを呼びます。 もう1人のクラスのアプリケーションは、いつもデータが到着するのを待つでしょう。 私たちはこれらの「弾性」のアプリケーションを呼びます。
Baker & Bose Informational [Page 7] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[7ページ]のRFC4923QoS
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".
Integrated Servicesモデルは「リアルタイムで」か「弾性」としてアプリケーションをサポートするデータフローを定義します。 また、「リアルタイムで」のトラフィックがトラフィックが時折呼ばれる「弾力性のない」トラフィック、およびそのゴムひもと呼ばれることに注意されるべきである、「非、-全く調節してください、」
In this view, the key issue is the so-called "playback point": a real-time application is considered to have a certain point in time at which data describing the next sound, picture, or whatever to be delivered to a display device or forfeit its utility, while an elastic application has no such boundary. Another way to look at the difference is that real-time applications have an irreducible lower bound on their bandwidth requirements. For example, the typical G.711 payload is delivered in 160-byte samples (plus 40 bytes of IP/ UDP/RTP headers) at 20 millisecond intervals. This will yield 80 kbps of bandwidth, without silence suppression, and not accounting for the layer 2 overhead. To operate in real-time, a G.711 codec requires the network over which its data will be delivered to support communications at 80 kbps at the IP layer with roughly constant end- to-end delay and nominal or no loss. If this is not possible (if there is significant loss or wide variations in delay), voice quality will suffer. On the other hand, if many megabits of capacity are available, the G.711 codec will not increase its bandwidth requirements either. Although adaptive codecs exist (e.g., G.722.2 or G.726), the adaptive mechanism can either require greater or lesser bandwidth and can adapt only within a certain range of bandwidth requirements beyond which the quality of the data flow required is not met. Elastic applications, however, will generally adapt themselves to any network: if the bottleneck provides 9600 bits per second, a Web transfer or electronic mail exchange will happen at 9600 bits per second, and if hundreds of megabits are available, the TCP (or SCTP) transport will increase their transfer rate in an attempt to reduce the time required to accomplish the transfer.
この視点では、主要な問題はいわゆる「再生ポイント」です: リアルタイムのアプリケーションは、どのデータに時間内にのある一定のポイントに次の音、画像、またはディスプレイ装置に提供されるものなら何でも説明させるか、そして、またはユーティリティを没収させると考えられます、弾性のアプリケーションには、どんなそのような境界もありませんが。 違いを見る別の方法はリアルタイムのアプリケーションがそれらの帯域幅要件に削減できない下界を持っているということです。 例えば、典型的なG.711ペイロードは160バイトのサンプルで20回のミリ秒間隔に提供されます(IP/UDP/RTPヘッダーの40バイト)。 これは層2のオーバーヘッドで会計ではなく、沈黙抑圧なしで帯域幅の80キロビット毎秒をもたらすでしょう。 リアルタイムでで作動するために、データが終わりまでのおよそ一定の終わりの遅れでIP層の80キロビット毎秒でサポートコミュニケーションに提供されていて名目上になるネットワークを必要としますが、G.711コーデックはどんな損失も必要としません。 これが可能でないなら(遅れの重大な損失か広い変化があれば)、音声の品質に苦しむでしょう。 他方では、容量の多くのメガビットが利用可能であるなら、G.711コーデックは帯域幅要件を増強しないでしょう。 適応型のコーデックは存在していますが(例えば、G.722.2かG.726)、適応型のメカニズムは、よりすばらしいか、より少ない帯域幅を必要とすることができて、流れが必要としたデータの品質が満たされないある一定の範囲に関する帯域幅要件だけ以内で適合できます。 しかしながら、一般に、弾性のアプリケーションはどんなネットワークにも慣れるでしょう: ボトルネックが9600のbpsを提供すると、ウェブ転送か電子メール交換が9600のbpsで起こるでしょう、そして、何百ものメガビットが利用可能であるなら、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.
リアルタイムのアプリケーションのために、データが提供されるのを必要とするものは少なくともあるレートで終わるために終わって、遅れが述べられた領域の間で異なって、Integrated Servicesアーキテクチャは交信アプリケーションとネットワークがアプリケーション要件とそれらを提供するネットワークの能力について話し合うことができるシグナリングプロトコルの使用を提案します。 そのようないくつかのプロトコルが、開発されるか、または開発中であるのに開発されました、Signaling(NSIS)にResource予約プロトコル(RSVP)とNext Stepsを著しく含んでいて。 同様の能力を提供するどんなプロトコルも考えることができましたが、現在の議論はRSVPに制限されます。
Baker & Bose Informational [Page 8] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[8ページ]のRFC4923QoS
1.5. The Resource Reservation Protocol (RSVP)
1.5. 資源予約プロトコル(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].
1セットのデータグラム処理規則がIntegrated Services[RFC2210]のための[RFC2209]とデータグラムの詳細で定義されている状態で、RSVPは初めは、[RFC2205]で定義されます。 概念的に、このプロトコルはソースアプリケーションから目的地アプリケーションまでデータフローを特定して、それらのために特定のリソースを要求する方法を指定します。 ソースが単一マシンであるかもしれないかまたは1セットのマシンは、明らかに記載したか、ところが、目的地が単一マシンかマルチキャストグループであるかもしれないこと(そして、したがって、それのマシンのすべて)を含意しました。 各アプリケーションは、IPプロトコル分野の輸送プロトコル番号によって指定されるか、またはさらに、目的地と恐らくソースポート番号を含むかもしれません。 プロトコルはIPv4[RFC0791]とIPv6[RFC2460]の両方のために定義されます。 すぐに、また、様々な種類のトンネルに同じ機能を実行する中にあるものとトンネルの外にあるものとの関係を含意する手段を提供するのも必要であると認められました。 したがって、定義はIPsec[RFC2207]と[RFC4860]と、より多くのジェネリック形式のトンネル[RFC2746]に開発されました。 Differentiated Services Architecture[RFC2475]の後の開発で、定義は、1組のIPアドレスとDSCPを[RFC2996]の標準のRSVPデータフローによって使用されて、データフロー[RFC3175]に身元が分かる情報として使用するために、Differentiated Services Code Point(DSCP)[RFC2474]を指定するために加えられました。
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.
さらに、プロトコルの初期の定義は方針情報、および予約の先取りのためのプレースホルダを含んでいました。 このプレースホルダは、後で方針[RFC2872]をアイデンティティ[RFC3182]に関連づけて、その結果、ネットワークが認証されて認可されたユーザに対する収縮したサービスを提供するのを可能にするために[RFC2750]で詳細に指定されました。 Session Initiationプロトコル[RFC3261]が[RFC3312]にある状態で、これは統合していました。 予約の先取りは[RFC3181]のように指定されます--別々のDefending Priorityを使用することでPreemption Priorityを使用することでネットワークにインストールされて、保有される予約は全体の予約を取り除くRESV Error信号でネットワークによって取り除かれるかもしれません。 これには、その件がしばしばそんなに白黒であるというわけではないので、しかしながら、問題があります。 問題がもう80キロビット毎秒の既存の予約を支えることができませんでしたが、60キロビット毎秒の予約が支えることができたということであるなら、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]の可能性を制限するために加えられました。
Baker & Bose Informational [Page 9] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[9ページ]のRFC4923QoS
[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 3175年のRFCセッションオブジェクトとトラフィックが使用するDSCP。(それは、ネットワークで特定されるパケットのIPアドレスではなく、イングレスと出口デバイスのIPアドレスを特定します)。
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コアの中、または、「反-アグリゲータ」でいなくなるのが知られているトラフィックストリームとして予約に集められます。
o The function of a reservation "deaggregator", which operates in
the egress router and breaks the aggregate reservation and data
streams back out into individual data streams that may be passed
to other networks.
o 予約"「反-アグリゲータ」"の機能。(それは、他のネットワークに通過されるかもしれない個々のデータ・ストリームに、出口ルータで作動して、集合予約とデータ・ストリームを破って戻します)。
In retrospect, the Session Object specified by RFC 3175 is useful but not intrinsically necessary. If the ISP network uses tunnels, such as MPLS LSPs, IP/IP or GRE tunnels or enclosing IPsec Security Associations, the concepts of an aggregator and a deaggregator work in the same manner, although the reservation mechanism would be that of [RFC3473] and [RFC3474], [RFC2207], [RFC4860], or [RFC2746].
追憶では、RFC3175によって指定されたSession Objectは役に立ちますが、本質的に必要ではありません。 ISPネットワークがMPLS LSPsなどのトンネルを使用するなら、IP/IPかGREトンネルか予約メカニズムは[RFC3473]と[RFC3474]か、[RFC2207]か、[RFC4860]か、[RFC2746]のものでしょうが、同じ方法でIPsec Security Associations、アグリゲータの概念、および「反-アグリゲータ」仕事を同封します。
1.6. Logical Structure of a VPN Router
1.6. VPNルータの論理構造
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トンネルの場合ではセキュリティ協会を持っている)を構造化します。
Baker & Bose Informational [Page 10] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[10ページ]のRFC4923QoS
+---------+ +-------+ +----+----+ +---------+
| RSVP | |Routing| |Net Guard| |IPsec Mgr|
+----+----+ +---+---+ +----+----+ +----+----+
| | | |
+----+-----------+------------+-----------------+----+
| IP |
+-----------+--------------------+------------+------+
| | |
| +-----+-----+ +----+------+
| | Encrypt/ | | Encrypt/ |
| |Decrypt for| |Decrypt for|
| | Security | | Security |
| |Association| |Association|
| +-----+-----+ +----+------+
| | |
+-----------+------------+ +-----+------------+------+
| Plaintext | | Ciphertext |
| Interface | | Interface |
+------------------------+ +-------------------------+
+---------+ +-------+ +----+----+ +---------+ | RSVP| |ルート設定| |ネットの警備| |IPsec Mgr| +----+----+ +---+---+ +----+----+ +----+----+ | | | | +----+-----------+------------+-----------------+----+ | IP| +-----------+--------------------+------------+------+ | | | | +-----+-----+ +----+------+ | | /を暗号化してください。| | /を暗号化してください。| | |解読する| |解読する| | | セキュリティ| | セキュリティ| | |協会| |協会| | +-----+-----+ +----+------+ | | | +-----------+------------+ +-----+------------+------+ | 平文| | 暗号文| | インタフェース| | インタフェース| +------------------------+ +-------------------------+
Figure 4: Logical Structure of a VPN Router
図4: VPNルータの論理構造
The encrypt/decrypt unit may be implemented as a function of the plaintext router, as a function on its interface card, or as a function of an external device with a private interface to the IP routing functionality of the plaintext router. These are conceptually equivalent, although there are practical differences in implementation. The key issue is that when IP routing presents a message to the encrypt/decrypt unit for transmission, it must also be presented with the IP address of the plaintext routing peer, whether host or router, to which the security association must be established. This IP Address is used to select (and perhaps create) the security association, and in turn select the appropriate set of security parameters. This could also be implemented by presenting the local Security Parameter Index (SPI) for the data, if it has been created out of band by the Network Management Process.
ユニットを暗号化するか、または解読してください。平文ルータの機能として実装されるかもしれません、インタフェースカードか、平文ルータのIPルーティングの機能性への個人的なインタフェースがある外部のデバイスの機能とした機能として。 これらは、実装の実用的な違いがありますが、概念的に同等です。 IPであるときに、主要な問題がaが通信するプレゼントを発送することでのそれである、トランスミッションのためにユニットを暗号化するか、または解読してください、そして、また、平文ルーティング同輩のIPアドレスをそれに与えなければなりません、ホストかルータであることにかかわらず。セキュリティ協会をルータに設立しなければなりません。 そして、このIP Addressが選択するのにおいて使用されている、(恐らく作成する、)、セキュリティ協会、順番に適切なセットのセキュリティパラメタを選択してください。 また、データのために、地方のSecurity Parameter Index(SPI)を寄贈することによって、これを実装することができるでしょう、それがバンドからNetwork Management Processによって作成されたなら。
In addition, it is necessary for aggregated signaling to be generated for the ciphertext domain. This may be accomplished in several ways:
さらに、集められたシグナリングが暗号文ドメインに生成されるのが必要です。 これはいくつかの方法で達成されるかもしれません:
o by having the RSVP process on the plaintext router generate the
messages and having the encrypt/decrypt unit bypass them into the
ciphertext network
o 平文ルータのRSVPプロセスにメッセージを生成させて、有、暗号文ネットワークへのそれらをユニット迂回に暗号化するか、または解読してください。
o by having the plaintext RSVP process advise a process in the
encrypt/decrypt implementation of what needs to be generated using
some local exchange, and having it generate such messages, or
o または平文RSVPプロセスに中でプロセスをアドバイスさせる、何が、何らかの市内交換を使用して、そのようなメッセージを生成させながら生成される必要があるかに関する実装を暗号化するか、または解読してください。
Baker & Bose Informational [Page 11] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[11ページ]のRFC4923QoS
o by having a separate parallel network management system
intermediate between the plaintext and ciphertext routers, in
which case, the encrypt/decrypt unit and the parallel network
system must use the same address, and the ciphertext router must
distinguish between traffic for them based on SPI or the presence
of encryption.
o その場合別々の平行なネットワーク管理システムを平文と暗号文ルータの間で中間的にする、暗号化のSPIか存在に基づいてそれらのためにユニットと平行なネットワーク・システム必須使用に同じアドレスを解読して、暗号化するか、または必須が見分ける暗号文ルータにトラフィックを解読してください。
Control plane signaling using this additional path is described in Section 3.2. The information flow between the plaintext and ciphertext domains includes
この追加経路を使用するコントロール飛行機シグナリングがセクション3.2で説明されます。 平文と暗号文ドメインの間の流れが含む情報
o IP datagrams via the encrypt/decrypt unit,
o を通してIPデータグラム、ユニットを暗号化するか、または解読してください。
o RSVP signaling via the bypass path,
o 迂回経路を通して合図するRSVP
o Control information coordinating security associations, and
o そしてセキュリティ協会を調整する情報を制御してください。
o precious little else.
o ほかの貴重な少し。
Baker & Bose Informational [Page 12] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[12ページ]のRFC4923QoS
2. Reservation and Preemption in a Nested VPN
2. 入れ子にされたVPNでの予約と先取り
/ \
( +--+ +--+ 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 / '-. ,
`-------' \ / `-------'
/、\(+--+ +--+ 飛び地)---------. .----------. \ |H2+---+ R2| / ,-' ` +--+ +--+`--.\ +--+ ++-+ / / +--+ +--+ |H1+---+ R1| \`. | ,' / |R3+---+ H3| +--+ +-++ ) '--. +----++ _.-' ( ++-+ +--+ | / _.`---|VPN2||''-. \ | 飛び地+----「+i.--」 +----++ `----.\ +----+ 飛び地--------|VPN1|' | ``|VPN3| , ,+----+ | +----+------' ,' --+-------+----------+------------------+---`. ,' ++-+ `. ,' |R7+--------'+'/インタフェース+--+| \ domain 1 +-+--+ \ _.--------|VPN7|--------. ,-----'' +--+-+ `------. . `-. ,-' | `-. .-' `-: '内側のドメイン+++''(| R9|)'。 ++-+ ;-. .' `-. | ,-' `-. ' `------. +-+--+ _.-----''‘を連結してください'---------|VPN8|-------「ドメイン、2++--+、/、\、」| +--+ / `. +----------+ R8| ,' `. ++-+ ,' `. --+------------------+-----------+------+-- ,' ,-----+----+ | +----+------. ,' |VPN6|. | _. | VPN4| ` +----+.`----. +----+ _.--'' ,+----+ | \ `--=.-|VPN5|---:' / | +--+ ++-+ : ,-'' +----+ `--. ; ++-+ +--+ |H6+---+ R6| | ,' | `.| |R4+---+ H4| +--+ +--+ ;/ +--+ ++-+ : +--+ +--+ // |H5+---+ R5| '\飛び地'、(+--+ +--+ '. 飛び地'、'\飛び地/'、-、'、-、-、-、-、-、--、'\/'、-、-、-、-、-、--、'、'
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が入れ子にされた仮想私設網にどう使用されるかもしれないかについて議論しましょう。
Baker & Bose Informational [Page 13] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[13ページ]のRFC4923QoS
2.1. Reservation in a Nested VPN
2.1. 入れ子にされたVPNの予約
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つの例外と共にいかなる他のネットワークにおける予約にも似ています: それは調整しなければならない複数の予約で構成されます。 これらはVPNの各層に起因すること、飛び地を受領して、および予約の中に予約を含んでいます、図5に示されるように。
Thus, when a host in one enclave opens a reservation to a host in another enclave, a reservation of the appropriate type and size is created end to end. As it traverses the VPN router leaving its enclave, the reservation information and the data are placed within the appropriate tunnel (e.g., the IPsec Security Association for its precedence level to the appropriate remote VPN router). At the remote VPN router, it is extracted from the tunnel and passed on its way to the target system. The data in the enclave will be marked with a DSCP appropriate to its application and (if there is a difference) precedence level, and the signaling datagrams (PATH and RESV) are marked with a DCLASS object indicating that value. RSVP signaling datagrams (PATH and RESV) are marked with a DCLASS object indicating the value used for the corresponding data. The DSCP on the signaling datagrams, however, is a DSCP for signaling, and has the one provision that if routing varies by DSCP, then it must be a DSCP that is routed the same way as the relevant data. The [RFC2872] policy object specifies the applicable policy (e.g., "routine service for voice traffic") and asserts a [RFC3182] credential indicating its user (which may be a person or a class of persons). As specified in [RFC3181], it also specifies its Preemption Priority and its Defending Priority; these enable the Preemption Priority of a new session to be compared with the Defending Priority of previously admitted sessions.
1つの飛び地のホストが別の飛び地のホストに予約を公開するとき、したがって、適切なタイプとサイズの予約は終わらせる作成された終わりです。 飛び地を出て、VPNルータを横断するのに従って、予約情報とデータは適切なトンネル(例えば、適切なリモートVPNルータへの先行レベルのためのIPsec Security Association)の中に置かれます。 リモートVPNルータでは、それは、トンネルから抽出されて、目標システムへの途中に移られます。 飛び地のデータはアプリケーションに適切なDSCPと(違いがあれば)先行レベルでマークされるでしょう、そして、DCLASSオブジェクトがその値を示していて、シグナリングデータグラム(PATHとRESV)はマークされます。 DCLASSオブジェクトが対応するデータに使用される値を示していて、RSVPシグナリングデータグラム(PATHとRESV)はマークされます。 シグナリングデータグラムの上のDSCPはしかしながら、シグナリングのためのDSCPであり、掘るならDSCPで異なる1つの支給を持っています、そして、関連データとして同じ道に発送されるのは、DSCPであるに違いありません。 [RFC2872]政策目的は、適切な方針(例えば、「音声トラヒックのための通常のサービス」)を指定して、ユーザ(人か人々のクラスであるかもしれない)を示す[RFC3182]資格証明書について断言します。 また、[RFC3181]で指定されるように、Preemption PriorityとそのDefending Priorityを指定します。 これらは、新しいセッションのPreemption Priorityが以前に認められたセッションのDefending Priorityと比較されるのを可能にします。
On the ciphertext side of the VPN router, no guarantees result unless the VPN router likewise sets up a reservation to the peer VPN Router across the ciphertext domain. Thus, the VPN router sets up an [RFC2207], [RFC4860], or [RFC3175] reservation to its peer.
VPNルータの暗号文側では、VPNルータが同様に暗号文ドメイン中の同輩VPN Routerに予約をセットアップしない場合、保証が全く結果として生じません。 したがって、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
[RFC2207]か[RFC4860]によって定義されたSession Objectは共通の安全保障協会の上の多くの予約と後者の場合における一般的なDSCP価値のマルチプレクシングを許容する「仮想の仕向港」と呼ばれる分野を含んでいます。 したがって、あらゆる先行レベルにおける音声トラヒックは[RFC3246]で説明されるようにExpedited Forwarding(EF)DSCPとサービスを利用するかもしれませんが、予約は「これらのVPNルータの間の先行Pnの声のセッションの集合」のためのものでしょう。 これで、ネットワーク管理は複数の敷居で方針を説明できるでしょう、「総予約された帯域幅が敷居Qnを超えていないなら、先行Pnの新しいセッションを受け入れるかもしれません」などのように。 受け入れるのが必要であって、十分であるなら
Baker & Bose Informational [Page 14] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[14ページ]のRFC4923QoS
the reservation, existing reservations at lower precedences may be preemptively reduced to make acceptance of the new session possible".
「予約であり、下側の先行における既存の予約は新しいセッションの承認を可能にするように先制的に抑えられるかもしれません。」
In the [RFC3175] case, since the DSCP must be used to identify both the reservation and the corresponding data stream, the aggregate reservations for different precedence levels require different DSCP values.
予約と対応するデータ・ストリームの両方を特定するのにDSCPを使用しなければならなくて以来の[RFC3175]場合では、異なった先行レベルの集合予約は異なったDSCP値を必要とします。
In either case, the fundamental necessity is for one VPN router to act as what [RFC3175] calls the "aggregator" and another to act as the "deaggregator", and extend a VPN tunnel between them. If the VPN Tunnel is an IPsec Security Association between the VPN routers and the IP packet is entirely contained within (such as is used to cross a firewall), then the behavior of [RFC2746] is required of the tunnel. That bearer will have the following characteristics:
どちらの場合ではも、基本的な必要性は、1つのVPNルータが"「反-アグリゲータ」"として機能するように[RFC3175]が「アグリゲータ」と呼ぶことと別のものとして機能して、それらの間のVPNトンネルを広げることです。 VPN TunnelがVPNルータの間のIPsec Security Associationであり、IPパケットが中に完全に含まれているなら(ファイアウォールを越えるのに使用されます)、トンネルは[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 トンネルの予約のPreemption Priorityはそれが集める個々の予約のものと同じです。
o The Defending Priority of a tunnel reservation is identical to
that of the individual reservations it aggregates.
o トンネルの予約のDefending Priorityはそれが集める個々の予約のものと同じです。
Baker & Bose Informational [Page 15] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[15ページ]のRFC4923QoS
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は先取りイベントを強制するより弾性のトラフィックで使用中の帯域幅からむしろ来ます。
2.2. Preemption in a Nested VPN
2.2. 入れ子にされたVPNでの先取り
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か他の種類の集められた予約では、これは、「反-アグリゲータ」(トンネルのためのRESV信号を開始するVPNルータ)がそうしなければならないことを意味します。
o receive the RESV Error signaling it to reduce its bandwidth,
o 帯域幅を減少させるようにそれに合図するRESV Errorを受けてください。
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
コアのルータでは、追加ケースは起こります。 人は、いくつかの飛び地がただ一つのセッションをVPNに与えると想像できました、そして、そのセッションには、より高い先行レベルがあります。 ある内部のリンクが混雑している、(例えば、予約された帯域幅は方針を超えるでしょう。
Baker & Bose Informational [Page 16] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[16ページ]のRFC4923QoS
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.
呼び出しが認められる、)、間のaセッションのときに、VPNルータの異なった組を先取りしなければなりません。 先取りする予約を選択するのにおいて、より一般に、コアルータは最も低い利用可能なDefending Priorityでいつも予約を選択しなければなりません。 これはコアで様々な先行レベルを別々に保たなければならない理由です。
2.3. Working through an Example
2.3. 例を終えます。
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つの暗号文ドメイン(ダイヤグラムで、「インタフェースドメイン」に言及される)、および最初の2を接続する3番目の暗号文ドメイン(ダイヤグラムで、「内側のドメイン」に言及されます)。 以下の情報の流通は存在しています:
o Each enclave has access to general routing information concerning
other enclaves it is authorized to communicate with: systems in it
can translate a DNS name for a remote host or domain and obtain
the corresponding address or prefix.
o 各飛び地はコミュニケートするのが認可されている他の飛び地に関して一般的なルーティング情報に近づく手段を持っています: それのシステムは、リモートホストかドメインにDNS名を翻訳して、対応するアドレスか接頭語を得ることができます。
o Each enclave router also has specific routing information
regarding its own enclave.
o また、それぞれの飛び地のルータには、それ自身の飛び地の特定のルーティング情報があります。
o A default route is distributed within the enclave, pointing to its
VPN router.
o VPNルータを示して、デフォルトルートは飛び地の中で分配されます。
o VPN Routers 1-6 are able to translate remote enclave prefixes to
the appropriate remote enclave's VPN router addresses.
o VPN Routers1-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 Routers7と8はリモートインタフェースドメイン接頭語をリモートVPNルータアドレスに翻訳できます。
o Routers in the inner domain have routing information for that
domain only.
o 内側のドメインのルータには、そのドメインだけのためのルーティング情報があります。
Baker & Bose Informational [Page 17] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[17ページ]のRFC4923QoS
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つのレベルを示していますが、No.threeに関して魔法であるものは何もありません。 いろいろな同心の層にモデルを広げることができます。
Note that this example places unidirectional reservations in the forward direction. In voice and video applications, one generally has a reservation in each direction. The reverse direction is not discussed, for the sake of clarity, but operates in the same way in the reverse direction and uses the same security associations.
この例が単方向の予約を順方向に置くことに注意してください。 一般に、声とビデオ・アプリケーションでは、1つは各方向に予約を持っています。 反対の方向は、明快のために議論しませんが、同様に、反対の方向に作動して、同じセキュリティ協会を使用します。
2.3.1. Initial Routine Reservations - Generating Network State
2.3.1. 初期の通常の予約--ネットワーク状態を生成すること。
Now let us install a set of reservations from H1 to H4, H2 to H5, and H3 to H6, and for the sake of argument, let us presume that these are at the "routine" precedence. H1, H2, and H3 each initiate a PATH signal describing their traffic. For the sake of argument, let us presume that H1's reservation is for an [RFC2205] session, H2's reservation is for a session encrypted using IPsec, and therefore depends on [RFC2207], and H3 (which is a Public Switched Telephone Network (PSTN) gateway) sends an [RFC3175] reservation comprising a number of distinct sessions. Since these are going to H4, H5, and H6, respectively, the default route leads them to VPN1, VPN2, and VPN3, respectively.
今度は、H1からH4までの予約、H5へのH2、およびH6へのH3の1セットをインストールさせてください、そして、議論するために、「通常」の先行にはこれらがあると推定しましょう。 H1、H2、およびH3はそれぞれそれらのトラフィックについて説明するPATH信号を開始します。 議論するために、H1の予約が[RFC2205]セッションの間、あって、H2の予約がIPsecを使用することで暗号化されたセッションの間、あって、したがって、[RFC2207]によって、H3(Public Switched Telephone Network(PSTN)ゲートウェイである)が[RFC3175]の予約に多くの異なったセッションを包括させると推定しましょう。 以来、これらはH4、H5に行きます、そして、H6、それぞれ、デフォルトルートはそれぞれそれらをVPN1、VPN2、およびVPN3に導きます。
The VPN routers each ensure that they have an appropriate security association or tunnel open to the indicated remote VPN router (VPN4, VPN5, or VPN6). This will be a security association or tunnel for the indicated application at the indicated precedence level. Having accomplished that, it will place the PATH signal into the security association and forward it. If such does not already exist, following [RFC3175]'s aggregation model, it will now open a reservation (send a PATH signal) for the tunnel/SA within the interface domain; if the reservation does exist, the VPN router will increase the bandwidth indicated in the ADSPEC appropriately. In this example, these tunnel/SA reservations will follow the default route to VPN7.
VPNルータは、それらには示されたリモートVPNルータ(VPN4、VPN5、またはVPN6)に開かれている適切なセキュリティ協会かトンネルがあるのをそれぞれ確実にします。 これは、示された先行レベルにおける示されたアプリケーションのためにセキュリティ協会かトンネルになるでしょう。 それを達成したので、それは、PATH信号をセキュリティ協会に置いて、それを送るでしょう。 [RFC3175]の集合モデルに従って、そのようなものが既に存在していないと、現在、インタフェースドメインの中のトンネル/SAに関する条件(PATH信号を送る)を開くでしょう。 予約が存在していると、VPNルータはADSPECで適切に示された帯域幅を増強するでしょう。 この例では、これらのトンネル/SAの予約はデフォルトルートにVPN7に従うでしょう。
VPN7 ensures that it has an appropriate security association or tunnel open to VPN8. This will be a security association or tunnel for the indicated application at the indicated precedence level. Having accomplished that, it will place the PATH signal into the security association and forward it. If such does not already exist, following [RFC3175]'s aggregation model, it will now open a reservation (send a PATH signal) for the tunnel/SA within the interface domain; if the reservation does exist, the VPN router will increase the bandwidth indicated in the ADSPEC appropriately. In this example, this tunnel/SA reservation is forwarded to VPN8.
VPN7は、VPN8に開かれている適切なセキュリティ協会かトンネルを持っているのを確実にします。 これは、示された先行レベルにおける示されたアプリケーションのためにセキュリティ協会かトンネルになるでしょう。 それを達成したので、それは、PATH信号をセキュリティ協会に置いて、それを送るでしょう。 [RFC3175]の集合モデルに従って、そのようなものが既に存在していないと、現在、インタフェースドメインの中のトンネル/SAに関する条件(PATH信号を送る)を開くでしょう。 予約が存在していると、VPNルータはADSPECで適切に示された帯域幅を増強するでしょう。 この例では、このトンネル/SAの予約をVPN8に送ります。
Baker & Bose Informational [Page 18] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[18ページ]のRFC4923QoS
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]「反-アグリゲータ」として機能します。 これはインタフェースドメインに内側のドメインの予約のためのPATH信号を受信して、状態を保存して、VPN7からのデータ・ストリームを解読して、RSVPによって構成されたルータとしてRSVP信号を作動させて、容認されたIPデータグラムを送ることを(アップデートされたPATH信号を含んでいます)意味します。 したがって、インタフェースドメインのルーティングに応じて、VPN1、VPN2、およびVPN3によって溯源されたPATH信号を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]「反-アグリゲータ」としてそれぞれ機能します。 これは飛び地にインタフェースドメインの予約のためのPATH信号を受信して、状態を保存して、同輩からデータ・ストリームを解読して、RSVPの構成されたルータとしてRSVP信号を作動させて、容認されたIPデータグラムを送ることを(アップデートされたPATH信号を含んでいます)意味します。 したがって、飛び地のルーティングに応じて、H1、H2、およびH3によって溯源されたPATH信号をH4、H5、およびH6に向かって転送します。
H4, H5, and H6 now receive the original PATH signals and deliver them to their application.
H4、H5、およびH6は現在、オリジナルのPATH信号を受信して、彼らのアプリケーションにそれらを提供します。
2.3.2. Initial Routine Reservations - Request Reservation
2.3.2. 初期の通常の予約--予約を要求してください。
The application in H4, H5, and H6 decides to install the indicated reservations, meaning that they now reply with RESV signals. These signals request the bandwidth reservation. Following the trail left by the PATH signals, the RESV signals traipse back to their respective sources. The state left by the PATH signals leads them to VPN4, VPN5, and VPN6, respectively. If the routers in the enclaves are configured for RSVP, this will be explicitly via R4, R5, or R6; if they are not, routing will lead them through those routers.
H4、H5、およびH6のアプリケーションは、示された条件(彼らが現在RESV信号で返答する意味)をインストールすると決めます。 これらの信号は帯域幅の予約を要求します。 PATH信号で残っている道に続いて、RESV信号は彼らのそれぞれのソースにぶらついて戻ります。 PATH信号で残っている州はそれぞれそれらをVPN4、VPN5、およびVPN6に導きます。 飛び地のルータがRSVPのために構成されるなら、これはあるためにR4、R5、またはR6を通して明らかに望んでいます。 それらがそうでないなら、ルーティングはそれらのルータを通してそれらを導くでしょう。
The various RSVP-configured routers en route in the enclave (including the VPN router on the "enclave" side) will verify that there is sufficient bandwidth on their links and that any other stated policy is also met. Having accomplished that, each will update its reservation state and forward the RESV signal to the next. The VPN routers will also each generate an RESV for the reservation within the interface domain, attempting to set or increase the bandwidth of the reservation appropriately.
飛び地(「飛び地」側の上のVPNルータを含んでいる)の途中様々なRSVPによって構成されたルータは、それらのリンクの上に十分な帯域幅があって、また、いかなる他の述べられた方針も満たされることを確かめるでしょう。 それを達成したので、それぞれが、予約状態をアップデートして、RESV信号を次に転送するでしょう。 また、VPNルータはインタフェースドメインの中の予約のためにそれぞれRESVを生成するでしょう、適切に予約の帯域幅を設定するか、または増強するのを試みて。
The various RSVP-configured routers en route in the interface domain (including VPN8) will verify that there is sufficient bandwidth on their links and that any other stated policy is also met. Having accomplished that, each will update its reservation state and forward the RESV signal to the next. VPN8 will also generate an RESV for the
インタフェースドメイン(VPN8を含んでいる)の途中様々なRSVPによって構成されたルータは、それらのリンクの上に十分な帯域幅があって、また、いかなる他の述べられた方針も満たされることを確かめるでしょう。 それを達成したので、それぞれが、予約状態をアップデートして、RESV信号を次に転送するでしょう。 また、VPN8はRESVを生成するでしょう。
Baker & Bose Informational [Page 19] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[19ページ]のRFC4923QoS
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に予約を得ます。
The various RSVP-configured routers en route in the inner domain (including VPN7) will verify that there is sufficient bandwidth on their links and that any other stated policy is also met. Having accomplished that, each will update its reservation state and forward the RESV signal to the next. This gets the signal to VPN7.
内側のドメイン(VPN7を含んでいる)の途中様々なRSVPによって構成されたルータは、それらのリンクの上に十分な帯域幅があって、また、いかなる他の述べられた方針も満たされることを確かめるでしょう。 それを達成したので、それぞれが、予約状態をアップデートして、RESV信号を次に転送するでしょう。 これは信号をVPN7に手に入れます。
VPN7 acts as an [RFC3175] aggregator for the inner domain. This means that it receives the RESV signal for the inner domain reservation and stores state, decrypts the data stream from VPN8, operates on the RSVP signals as an RSVP-configured router, and forwards the received IP datagrams (including the updated RESV signals) into its interface domain. The RESV signals originated by VPN4, VPN5, and VPN6 are therefore forwarded towards VPN1, VPN2, and VPN3 through the interface domain.
VPN7は内側のドメインへの[RFC3175]アグリゲータとして機能します。 これはインタフェースドメインに内側のドメインの予約のためのRESV信号を受信して、状態を保存して、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信号を含んでいます)意味します。 したがって、飛び地のルーティングに応じて、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信号を受信して、彼らのアプリケーションにそれらを提供します。
2.3.3. Installation of a Reservation Using Precedence
2.3.3. 先行を使用する予約のインストール
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を呼び出しました、また、十分な帯域幅がそれらを支持するために存在しているなら、他の先行レベルか他のアプリケーションの予約はこのネットワークの向こう側にインストールされるかもしれません。 例えば、既に説明された「通常」の予約が声のためのものであり、十分な帯域幅が関連方針の下で利用可能であるなら、「優先権」先行レベルにおける声の予約はインストールされるかもしれません。 しかしながら、先取りの整備士のため、これはインタフェースと内側のドメインで既存の「通常」の予約を広げないでしょう、これをするのが情報の損失をもたらすとき--予約のいくらが現在「通常であるか」、そして、「優先権」はいくらですか? むしろ、この新しい予約はそのアグリゲータと「反-アグリゲータ」の間の先行のときに別々のセットのトンネルかセキュリティ協会をアプリケーションのクラスの交通に開けるでしょう。
Baker & Bose Informational [Page 20] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[20ページ]のRFC4923QoS
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では、すべてのサーキットがどんなPSTNアプリケーションでもあるセットの規則の下で潜在的に使用可能です(ビデオストリームで使用されるものなどのHチャンネルは、隣接で規則正しくなければなりません)。 そういうものとして、チャンネルを通常の交通に利用可能に作られていませんが、優先権交通が入手するなら、オペレータは、潜在的に予約された帯域幅の収入を失っていて、報酬に値します。 しかしながら、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.
また、マイクロ波通信網では、衛星か可動であるように、臨時に、人は、何らかの適切な方針の下でネットワークマネージメントが帯域幅を増加させるように無線信号の特性を変えることができた介入であると想像できました。
2.3.4. Installation of a Reservation Using Preemption
2.3.4. 先取りを使用する予約のインストール
So we now have a number of reservations across the network described in Figure 5 including several reservations at "routine" precedence and one at "priority" precedence. For sake of argument, let us presume that the link from VPN7 to R9 is now fully utilized - all of the bandwidth allocated by policy to voice at the routine or priority level has been reserved. Let us further imagine that a new "priority" reservation is now placed from H3 to H6.
それで、私たちは現在、「通常」の先行と1時に「優先権」先行でいくつかの予約を含む図5でネットワークの向こう側の多くの予約について説明させます。 議論の目的のために、VPN7からR9へのリンクが現在完全に利用されると推定しましょう--方針でルーチンか優先順位における声に割り当てられた帯域幅のすべてが予約されました。 さらに、新しい「優先権」の予約が現在H3からH6まで置かれると想像しましょう。
The process described in Section 2.3.1 is followed, resulting in PATH state across the network for the new reservation. This is installed even though it is not possible to install a new reservation on VPN7- R9, as it does not install any reservation and the network does not know whether H6 will ultimately require a reservation.
新しい予約のためのネットワークの向こう側のPATH状態をもたらして、セクション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
また、セクション2.3.2で説明された過程は従われています。 それが現在RESV信号で返答することを意味して、H6のアプリケーションは、示された予約をインストールすると決めます。 PATH信号で残っている道に続いて、RESV信号はH3に向かってぶらついて戻ります。 VPN6と(RSVPが構成されたなら)R6は、それらのリンクの上に十分な帯域幅があって、また、いかなる他の述べられた方針も満たされることを確かめます。 それを達成したので、それぞれが予約をアップデートするでしょう。
Baker & Bose Informational [Page 21] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[21ページ]のRFC4923QoS
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.
RESV信号を次に述べて、転送してください。 また、VPN6は予約のためにインタフェースドメインの中でRESVを発生させます、予約の帯域幅を適切に設定するか、または増加させるのを試みて。
VPN6, R8, and VPN8's "interface domain" sides now verify that there is sufficient bandwidth on their links and that any other stated policy is also met. Having accomplished that, each will update its reservation state and forward the RESV signal to the next. VPN8 will also generate an RESV for the reservation within the inner domain, attempting to set or increase the bandwidth of the reservation appropriately. This gets the reservation to the inner deaggregator, VPN8.
VPN6、R8、およびVPN8の「インタフェースドメイン」側は、現在、それらのリンクの上に十分な帯域幅があって、また、いかなる他の述べられた方針も満たされることを確かめます。 それを達成したので、それぞれが、予約状態をアップデートして、RESV信号を次に転送するでしょう。 また、VPN8は予約のために内側のドメインの中でRESVを発生させるでしょう、予約の帯域幅を適切に設定するか、または増加させるのを試みて。 これは内側の「反-アグリゲータ」、VPN8に予約を得ます。
VPN8's "inner domain" side and R9 now verify that there is sufficient bandwidth on their links and that any other stated policy is also met. At R9, a problem is detected - there is not sufficient bandwidth under the relevant policy. In the absence of precedence, R9 would now return an RESV Error indicating that the reservation could not be increased or installed. In such a case, if a preexisting reservation of lower bandwidth already existed, the previous reservation would remain in place but the new bandwidth would not be granted, and the originator (H6) would be informed. Let us clarify what it means to be at a stated precedence: it means that the POLICY_DATA object in the RESV contains a Preemption Priority and a Defending Priority with values specified in some memo. With precedence, [RFC4495]'s algorithm would have the Preemption Priority of the new reservation compared to the Defending Priority of extant reservations in the router, of which there are two: one VPN7->VPN8 at "routine" precedence and one VPN7->VPN8 at "priority" precedence. Since the Defending Priority of routine reservation is less than the Preemption Priority of a "priority" reservation, the "routine" reservation is selected. R9 determines that it will accept the increase in its "priority" reservation VPN7->VPN8 and reduce the corresponding "routine" reservation. Two processes now occur in parallel:
VPN8の「内側のドメイン」側とR9は、現在、それらのリンクの上に十分な帯域幅があって、また、いかなる他の述べられた方針も満たされることを確かめます。 R9では、問題は検出されます--十分な帯域幅が関連方針の下にありません。 先行がないとき、R9は現在、予約を増加できなかったか、インストールできなかったのを示すRESV Errorを返すでしょう。 新しい帯域幅は与えられないでしょう、そして、このような場合には、下側の帯域幅の先在の予約が既に存在しているなら、前の予約は適所に残っているでしょうにが、創始者(H6)は知識があるでしょう。 述べられた先行にはあるそれが意味することをはっきりさせましょう: それは、RESVのPOLICY_DATA物がPreemption Priorityと値が何らかのメモで指定されているDefending Priorityを含むことを意味します。 先行によって、[RFC4495]のアルゴリズムで、2があるルータにおける実在の予約のDefending Priorityと新しい予約のPreemption Priorityを比較するでしょう: 「通常」の先行における1VPN7->のVPN8と「優先権」先行における1VPN7->のVPN8。 通常の予約のDefending Priorityが「優先権」の予約のPreemption Priority以下であるので、「通常」の予約は選択されます。 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
RESV Errorに減少している予約を反映するために内部の状態をアップデートさせることによって、R9は「通常」の予約を抑えます、そして、aに予約を抑えるよう要求するVPN8にRESV Errorを送って、それほど関連より敷居に付番しないでください。競争の予約の合計。 「反-アグリゲータ」として機能して、VPN8は2つの変更を行います。 「内側のドメイン」側では、予約に示されたレートまでマークする、(最も多く、現在です。
Baker & Bose Informational [Page 22] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[22ページ]のRFC4923QoS
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.
予約することが許可されている、)、RESV Refresh出来事が起こると、指定されたレートを要求するように。 「インタフェースドメイン」側では、レートを同様に低下させるのがその選ぶのと要求のアルゴリズムで関連予約の1つ以上を選択します。 議論するために、選択された予約がものであるとVPN5に想像させてください。 RESV Errorは今、R8をVPN5に擦りぬけて、予約が適切に抑えられるよう要求する「飛び地」側でRESV Error信号を渡します。(同様に、VPN5は述べられた量に帯域幅要求を減らします)。
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 Tearを送って、アプリケーションを教えます。 しかしながら、要求がそれをある値より下であるまで減少させることであるなら、アプリケーションがそうして、実行可能なままで残っているのは、可能であるかもしれません。 例えば、G.711コーデック(80キロビット毎秒)を使用するVoIPアプリケーションが70キロビット毎秒の下で帯域幅を減少させるように頼まれるなら、G.729かある他のコーデックに使用中のコーデックを再交渉するのは可能であるかもしれません。その過程を完了したとき、アプリケーションは、由来しているアプリケーションで、このような場合には、述べられた帯域幅で(この場合70キロビット毎秒)を再予約して、アプリケーションレベル変化を起こして、再び予約を変えるべきです(恐らく60キロビット毎秒に)。
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信号を次に転送するでしょう。 VPN7は現在、内側のドメインへの[RFC3175]アグリゲータとして機能します。 これはインタフェースドメインに内側のドメインの予約のためのRESV信号を受信して、状態を格納して、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信号を含んでいます)意味します。 したがって、飛び地のルーティングに応じて、H6によって溯源されたRESV信号をH3に向かって転送します。
Baker & Bose Informational [Page 23] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[23ページ]のRFC4923QoS
H3 now receives the original RESV signals and delivers it to the relevant application.
H3は現在、オリジナルのRESV信号を受信して、関連アプリケーションにそれを届けます。
3. Data Flows within a VPN Router
3. データはVPNルータの中を流れます。
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境界で明確にシグナリング流動を特定して、Network Guardの援助でさらに、シグナル伝達機構について詳しく説明します。 使用は操作上のシナリオの文脈における提案がここに提示される説明をケースに入れます。
3.1. VPN Routers That Carry Data across the Cryptographic Boundary
3.1. 暗号の境界の向こう側にデータを運ぶVPNルータ
3.1.1. Plaintext to Ciphertext Data Flows
3.1.1. 暗号文データフローへの平文
+-----------------------+ +----------------------+
| +--------------------+| |+--------------------+|
| |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||
| +--------------------+| |+--------------------+|
+-----------------------+ +----------------------+
+-----------------------+ +----------------------+ | +--------------------+| |+--------------------+| | |RSVP|| ||集合RSVP|| | | || || || | |セッション単位で: || ID||Agg。 セッション|| | | 目的地|、|、-、--、>|、| Agg。 目的地|| | | ソース|| || Agg。 ソース=自己|| | | 潜在的SPI|| || Agg。 発生するSPI|| | | DSCP--------->DSCP|| | | vPortかプロトコル--------->vPort|| | | そして、ポート|| || || | | ミーン・レート---------ミーン・レートの>合計|| | | ピークレート--------->f(ピークレート)|| | | 放出量---------Burstサイズの>合計|| | | || || || | +--------------------+| |+--------------------+| | +--------------------+| |+--------------------+| | | IP|| || IP|| | +--------------------+| |+--------------------+| | +--------------------+| |+--------------------+| | | 平文インタフェース|| ||暗号文インタフェース|| | +--------------------+| |+--------------------+| +-----------------------+ +----------------------+
Figure 6: Data Flows in a VPN Router Outbound
図6: VPNルータにおける外国行きのデータフロー
Baker & Bose Informational [Page 24] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[24ページ]のRFC4923QoS
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]、または他のタイプで説明されるように個々の流れを含むかもしれません。 それは「反-アグリゲータ」の暗号文側面のための識別子を暗号文ユニットに通過します。
DSCP: The DSCP of the plaintext data flow is provided to the cipher
text side.
DSCP: 平文データフローのDSCPを暗号テキスト側に提供します。
Virtual Port: The virtual destination port is provided to the cipher
text side. This may be derived from an [RFC2207] session object
or from policy information.
仮想のポート: 暗号テキスト側に仮想の仕向港を提供します。 これは[RFC2207]セッション物か方針情報から引き出されるかもしれません。
Mean Rate: The sum of the plaintext mean rates is provided to the
ciphertext unit.
ミーン・レート: 平文ミーン・レートの合計を暗号文ユニットに提供します。
Peak Rate: A function of the plaintext peak rates is provided to the
ciphertext unit. This function is less than or equal to the sum
of the peak rates.
レートに最大限にしてください: 平文ピークレートの関数を暗号文ユニットに提供します。 この機能はピークレートの、より合計以下です。
Burst Size: The sum of the burst sizes is provided to the cipher
text unit.
サイズを押し破いてください: 暗号テキストユニットに放出量の合計を提供します。
Messages include:
メッセージは:
Path: The plaintext PATH message is sent as encrypted data to the
ciphertext unit. In parallel, a trigger needs to be sent to the
ciphertext unit that results in it generating the corresponding
aggregated PATH message for the ciphertext side.
経路: コード化されたデータとして平文PATHメッセージを暗号文ユニットに送ります。 平行では、引き金は、暗号文側への対応する集められたPATHメッセージを発生させながらそれをもたらす暗号文ユニットに送られる必要があります。
Path Error: This indicates that a PATH message sent to the remote
enclave was in error. In the error case, the message itself is
sent on as encrypted data, but a signal is sent to the ciphertext
side in case the error affects the ciphertext reservation (such as
removing or changing state).
経路誤り: これは、遠く離れた飛び地に送られたPATHメッセージが間違っていたのを示します。 誤り事件では、コード化されたデータとしてメッセージ自体を転送しますが、誤りが暗号文条件(状態を取り除くか、または変えなどなどの)に影響するといけないので、暗号文側に信号を送ります。
Path Tear: The PATH Tear message is sent as encrypted data to the
ciphertext unit. In parallel, a signal is sent to the cipher text
side; it will trigger a Path Tear on its reservation in the event
that this is the last aggregated session, or change the
SENDER_TSPEC of the aggregated session.
経路裂け目: コード化されたデータとしてPATH Tearメッセージを暗号文ユニットに送ります。 平行では、暗号テキスト側に信号を送ります。 それは、これが最後に集められたセッションであるなら予約でPath Tearの引き金となるか、または集められたセッションのSENDER_TSPECを変えるでしょう。
Baker & Bose Informational [Page 25] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[25ページ]のRFC4923QoS
RESV: The plaintext RESV message is sent as encrypted data to the
ciphertext unit. In parallel, a trigger needs to be sent to the
ciphertext unit that results in it generating the corresponding
aggregated RESV message for the ciphertext side.
RESV: コード化されたデータとして平文RESVメッセージを暗号文ユニットに送ります。 平行では、引き金は、暗号文側への対応する集められたRESVメッセージを発生させながらそれをもたらす暗号文ユニットに送られる必要があります。
RESV Error: This indicates that a RESV message that was received as
data and forwarded into the enclave was in error or needed to be
preempted as described in [RFC3181] or [RFC4495]. In the error
case, the message itself is sent on as encrypted data, but a
signal is sent to the ciphertext side in case the error affects
the ciphertext reservation (such as removing or changing state).
RESV誤り: これは、データとして受け取られて、飛び地に転送されたRESVメッセージが、[RFC3181]か[RFC4495]で説明されるように間違っていたか、または先取りされる必要だったのを示します。 誤り事件では、コード化されたデータとしてメッセージ自体を転送しますが、誤りが暗号文条件(状態を取り除くか、または変えなどなどの)に影響するといけないので、暗号文側に信号を送ります。
RESV Tear: The RESV Tear message is sent as encrypted data to the
ciphertext unit. In parallel, a signal is sent to the cipher text
side; it will trigger a RESV Tear on its reservation in the event
that this is the last aggregated session, or reduce the bandwidth
of an existing reservation.
RESVは引き裂きます: コード化されたデータとしてRESV Tearメッセージを暗号文ユニットに送ります。 平行では、暗号テキスト側に信号を送ります。 それは、これが最後に集められたセッションであるなら予約でRESV Tearの引き金となるか、または既存の予約の帯域幅を減少させるでしょう。
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 Confirmの引き金となるように信号を送ります。
Baker & Bose Informational [Page 26] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[26ページ]のRFC4923QoS
3.1.2. Ciphertext to Plaintext Data Flows
3.1.2. 平文データフローへの暗号文
+-----------------------+ +----------------------+
| +--------------------+| |+--------------------+|
| |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||
| +--------------------+| |+--------------------+|
+-----------------------+ +----------------------+
+-----------------------+ +----------------------+ | +--------------------+| |+--------------------+| | |RSVP|| ||集合RSVP|| | | || || 終わります。|| | |セッション単位で: |+ || || | | 目的地|| || || | | ソース<。---------RSVPであると解読されます。|| | | 潜在的SPI|| || 発信するメッセージ|| | | DSCP|| || 平文ユニット|| | | vPortかプロトコル|| || *データ*|| | | そして、ポート|| || 正常処理|| | | ミーン・レート|| || || | | ピークレート|| || || | | 放出量|| || || | | || || || | +--------------------+| |+--------------------+| | +--------------------+| |+--------------------+| | | IP|| || IP|| | +--------------------+| |+--------------------+| | +--------------------+| |+--------------------+| | |平文インタフェース|| ||暗号文インタフェース|| | +--------------------+| |+--------------------+| +-----------------------+ +----------------------+
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で外国行きのメッセージの処理で説明されるように集合予約をparameterizeするように何らかの情報を暗号文サイズに返します。
Baker & Bose Informational [Page 27] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[27ページ]のRFC4923QoS
3.2. VPN Routers That Use the Network Guard for Signaling across the
Cryptographic Boundary
3.2. 暗号の境界の向こう側に合図するのにネットワーク護衛を使用するVPNルータ
As described in Section 1.6 the Network Guard provides an additional path for the reservation signaling between the plaintext and cipher text domains.
セクション1.6で説明されるように、Network Guardは平文と暗号テキストドメインの間で合図する予約に追加経路を提供します。
_.------------.
,--'' Plaintext Domain--.
,-' +--------+ +--------+ `-.
,' | Host | | Host | `.
,' +--------+ +--------+ `.
; :
| +----------------------+ |
: | +--------+ | |
`. | | Router | | ,'
`. | +---+----+ | ,'
`- | +----------+ | ,'
---| +-+--+ +-+--+--+ |'
|----|E/D |--|Net Grd| | VPN Router
,-'| +-+--+ +-+--+--+ |\
, | +----------+ | \
,' | +---+----+ | `.
,' | | Router | | |
/ | +--------+ | \
; +----------------------+ :
| |
: Ciphertext Domain ;
_.------------. '「--」平文ドメイン--、-、'+--------+ +--------+ `-. ,' | ホスト| | ホスト| `. ,' +--------+ +--------+ `. ; : | +----------------------+ | : | +--------+ | | `. | | ルータ| | ,' `. | +---+----+ | ,' `- | +----------+ | ,' ---| +-+--+ +-+--+--+ |' |----|E/D|--|ネットGrd| | VPN'ルータ、-、'| +-+--+ +-+--+--+ |\ , | +----------+ | \ ,' | +---+----+ | `. ,' | | ルータ| | | / | +--------+ | \ ; +----------------------+ : | | : 暗号文ドメイン。
Figure 8: RSVP Passage via Network Guard
エイト環: Network Guardを通したRSVP Passage
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ルータは平文ルータで構成されます、暗号文ルータ、実現(線カードかインタフェース機器などの)、およびネットワークマネージメントが管理される過程であるとコード化するか、または解読してください、実現をコード化するか、または解読してください。そうすれば、潜在的に、パスは平文と暗号文ドメインの間の情報流れを定義しました。 Network Guardがルータの間で構成指示を交換するソフトウェア処理として実行されるなら、これは理解しているのが簡単です。 それがデータグラムを交換する別々のシステムとして建てられるなら、いくらか複雑ですが、概念的に同等です。 例えば、暗号文ルータがインタフェースと中で使用されたインタフェースに関して受け取ったとしてのデータが平らにするNetwork Guard(制御飛行機)を通して受け取られたIPデータグラムを考えるだろう、ユニットをコード化するか、または解読してください。
Baker & Bose Informational [Page 28] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[28ページ]のRFC4923QoS
3.2.1. Signaling Flow
3.2.1. シグナリング流動
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であったかもしれないならユニットをコード化するか、または解読してください。そうすれば、方針は平文ルータにおける暗号文ネットワーク・アドレスに関する知識を防いでもよいです。 このような場合には、シグナリングのための経路が流れるとき、平文と暗号文ルータはNetwork Guardを使用するかもしれません。 Network Guardは、暗号のドメインの向こう側に予約シグナリングの流れを可能にするために以下の機能を実行します。
o transforms plaintext session identifiers into ciphertext session
identifiers and vice-versa in IP datagrams and RSVP objects (e.g.
IP addresses)
o IPデータグラムとRSVP物で逆もまた同様に平文セッション識別子を暗号文セッション識別子に変えます。(例えば、IPアドレス)
o performs resource management of aggregated reservations (e.g.,
including ciphertext encapsulation overhead to resources
requested)
o 集められた予約の資源管理を実行します。(例えば、リソースへのオーバーヘッドが要求した暗号文カプセル化を含んでいます)
o reads and writes configuration on the encrypt/decrypt units as
necessary (e.g., reads plaintext to ciphertext IP address mapping)
o 構成を読み書きする、必要に応じてユニットをコード化するか、または解読してください。(例えば、暗号文IPアドレス・マッピングに平文を読み込みます)
In addition, the plaintext and ciphertext routers must support a routing function or local interface that ensures that aggregated RSVP messages flow via the Network Guard. However, the signaling flow across the entire VPN router at a cryptographic boundary remains identical to the description in Section 3.1.
さらに、平文と暗号文ルータはそれがNetwork Guardを通して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.
ユニットをコード化するか、または解読してください。そして、読者が、2つの半分、またはNetwork Guardと共に図8で説明されたVPNルータはただ一つのルータまで潰すことができることに注意するかもしれない、平文ルータの一部であることができます。 VPNルータのための交互の論理的で物理的な構造の詳細はこのドキュメントの範囲を超えています。
Baker & Bose Informational [Page 29] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[29ページ]のRFC4923QoS
3.2.2. Use Case with Network Guard
3.2.2. ネットワーク警備があるケースを使用してください。
........................................
: 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 :
: <:::::::::::::> :
:......................................:
........................................ : VPNルータA: : : :+-----------++----------++-----------+: +------+ RSVP:||| NetGrd-A|| |: |ホストA| <、-、-、-->:、| PTルータA|+----------+|コネチカットルータA|:::::::: +------+ :| || E/D-A|| |: :: :+-----------++----------++-----------+: :: : 1RSVP: :: : <:、:、:、:、:、:、:、:、:、:、:、:、:>: :: :......................................: :: 1RSVP:、: ,---. ,' `. / \ ; 以下を連結してください。 | ドメイン| : ; \ / `. ,' '---'1RSVP:、:、' ........................................ :: : VPNルータB: :: : : :: :+-----------++----------++-----------+: :: +------+ RSVP:||| NetGrd-B|| |: :: |ホストB| <、-、-、-->:、| PTルータB|+----------+|コネチカットルータB|:::::::: +------+ :| || E/D-B|| |: :+-----------++----------++-----------+: : 1RSVP: : <:、:、:、:、:、:、:、:、:、:、:、:、:>: :......................................:
Figure 9: Aggregated RSVP via Network Guard
図9: Network Guardを通して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と共にケースに入れます。 このシナリオでは、Host Aは予約のためにHost Bに合図するRSVPを開始します。 ホストの間で合図するRSVPはVPNルータによって暗号化されたトンネルにカプセル化されます。 集められたRSVPシグナリングは、VPNルータによって引き起こされて、経路でRSVPできるルータでリソースを予約するためにコネチカット-ルータ、およびインタフェースドメインに流れます。 これでのRSVPの予約がケースを使用するので、集合/「反-集合」ポイントは太平洋標準時のルータです。 太平洋標準時のルータにおけるA-RSVPへのRSVPのシグナリング集合はセクション3.1で説明されたデータフローと同様です。 The
Baker & Bose Informational [Page 30] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[30ページ]のRFC4923QoS
Network Guard performs the additional functions described in Section 3.2.1 to transform plaintext A-RSVP messages into suitable ciphertext A-RSVP messages. A typical reservation set up in this case would follow these steps.
ネットワークGuardは平文A-RSVPメッセージを適当な暗号文A-RSVPメッセージに変えるためにセクション3.2.1で説明された追加機能を実行します。 この場合セットアップされている典型的な予約はこれらの方法に従うでしょう。
o Host A sends RSVP PATH message to Host B.
o ホストAはRSVP PATHメッセージをHost Bに送ります。
o PT-Router-A encapsulates RSVP PATH message in encrypted tunnel to
VPN Router B.
o PTルータAは、暗号化されたトンネルでRSVP PATHがメッセージであるとVPN Router Bにカプセル化します。
o CT Routers and Interface domain carry encrypted RSVP PATH message
(like any other encrypted data message).
o コネチカットRoutersとInterfaceドメインは暗号化されたRSVP PATHメッセージ(いかなる他の暗号化されたデータメッセージのようなも)を伝えます。
o PT-Router-B decrypts RSVP Path Message and sends an E2E PathErr
message to PT-Router-A in the encrypted tunnel.
o PTルータBは、RSVP Path Messageを解読して、E2E PathErrメッセージを暗号化されたトンネルのPTルータAに送ります。
o PT-Router-B forwards decrypted plaintext RSVP PATH message to Host
B.
o PTルータBフォワードは平文RSVP PATHメッセージをHost 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ルータAは、Network Guardを通してPTルータBに向かって2EのE PathErrを受けて、集められたRSVP PATHメッセージを送ります。
o The NetGrd-A transforms the plaintext aggregate RSVP into the
ciphertext aggregate RSVP message as described in Section 3.2.1
and sends it to the CT-Router-A.
o NetGrd-Aはセクション3.2.1で説明されるように平文の集合RSVPを暗号文の集合RSVPメッセージに変えて、コネチカットルータAにそれを送ります。
o The ciphertext aggregated RSVP message travels through ciphertext
routers in the interface domain.
o 暗号文はインタフェースドメインの暗号文ルータを通したRSVPメッセージ旅行に集められました。
o CT-Router-B receives the ciphertext aggregate RSVP message and
sends it to the NetGrd-B.
o コネチカットルータBは、暗号文の集合RSVPメッセージを受け取って、それをNetGrd-Bに送ります。
o The NetGrd-B transforms the ciphertext aggregate RSVP into the
plaintext aggregate RSVP message as described in Section 3.2.1 and
sends it to the PT-Router-B.
o NetGrd-Bはセクション3.2.1で説明されるように暗号文の集合RSVPを平文の集合RSVPメッセージに変えて、PTルータBにそれを送ります。
The subsequent RSVP and Aggregate RSVP signaling follows a similar flow, as described in detail in [RFC3175] and [RFC4860]to aggregate each plaintext reservation into a corresponding ciphertext reservation. This ensures that RSVP-capable ciphertext routers reserve the required resources for a plaintext end-to-end reservation. Subsequent mechanisms, such as preemption or the increase and decrease of resources reserved, may be applied to these reservations as described before in this document. The RSVP data flow as described in Section 3.1 within the VPN router (from the plaintext router to the ciphertext router via the Guard) provides necessary and sufficient information to routers in the ciphertext domain to implement the QoS solution presented in the document.
その後のRSVPとAggregate RSVPシグナリングは同様の流れに続きます、対応する暗号文の予約へのそれぞれの平文の予約に集めるために[RFC3175]と[RFC4860]で詳細に説明されるように。 これは、RSVPできる暗号文ルータが平文終わりから終わりへの予約のための必要なリソースを予約するのを確実にします。 予約されたリソースの先取りか増加や減少などのその後のメカニズムは以前本書では説明されるようにこれらの予約に適用されるかもしれません。 VPNルータ(平文ルータからGuardを通した暗号文ルータまでの)の中でセクション3.1で説明されるRSVPデータフローは暗号文ドメインのルータへの必要でドキュメントに示されたQoSソリューションは実現できるくらいの情報を提供します。
Baker & Bose Informational [Page 31] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[31ページ]のRFC4923QoS
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:
この記述では、私たちが存在として別々の状態でNetwork Guardを記述した、ユニットを暗号化するか、または解読してください。 ある実装では、それがデバイスを指定する人によって強制されるので、この分離は存在しています。 しかしながら、分離はただで来ません。 システムエンジニアリング目的のためのデバイスの分離は高価です、そして、それは建築問題を課します。GuardがRSVPメッセージかプロトコル無党派Multicast(PIM)ルーティングに集めるのに使用されるとき、例えば、トラフィックはリモートVPNルータに運命づけられています。 これは、GuardがVPN Routerを代表したそれに向けられないメッセージにどうにか受信して、応じなければならないことを意味します。 いくつかの可能なソリューションが存在しています。 それらは環境のセキュリティと実装の必要性に基づいて慎重に選択されるべきです。 それらは以下の通りです:
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 そして、最も簡単なケース、Network Guard、2が一般的なネットワークとMAC層を利用する独立している機能であったかもしれないならユニットを暗号化するか、または解読してください。 これで、2つの機能が一般的なMACとIPアドレスを共有できます、また、もう片方で1つの機能のために運命づけられたトラフィックを受け取るように。 これらの2つの機能が2台のデバイスで物理的に切り離されて、まだ一般的なMACとIPアドレスを共有できます。 しかしながら、追加変更がそれ自体のために運命づけられなかったプロセスIPトラフィックではなく、フィルタへのGuardで必要であるかもしれません。
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 Guardの暗号文インタフェースを無差別なモードに置くことができました、すべてのメッセージを受け取って、それが興味を持っているわずか以外のすべてを捨てるのを許容して。 連れていかれるべきVPN境界の必要性における無差別なモードにデバイスを入れるときのセキュリティ問題はこのメソッドで説明されます。
o The Guard could be engineered to receive all from the ciphertext
router and pass the bulk of it on to the VPN router through
another interface. In this case, the Guard and the VPN router
would use the same IP address. This mechanism puts the load of
all data and management traffic destined for the VPN router upon
the Guard.
o 別のインタフェースで暗号文ルータをすべて受け取って、それの嵩をVPNルータに通過するためにGuardを設計できました。 この場合、GuardとVPNルータは同じIPアドレスを使用するでしょう。 このメカニズムはGuardの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 暗号文ルータからすべてのトラフィックを受けて、それがGuardに受けるどんな非暗号化されたトラフィックも別のインタフェースを通して移るためにVPNルータを設計できました。 この場合、GuardとVPNルータは同じIPアドレスを使用するでしょう。
o All the VPN router functions, as shown in Figure 9, could be
incorporated into a single chassis, with appropriate internal
traffic management to send some traffic into the plaintext enclave
and some to the Guard. In this case, the Guard and the VPN router
would be -- at least, functionally -- the same system.
o 図9に示されるすべてのVPNルータ機能が、Guardへの平文飛び地といくつかに何らかのトラフィックを送るために適切な国内取引管理でただ一つの筐体に組み入れられるかもしれません。 この場合、GuardとVPNルータが少なくとも、そして、機能上あるでしょう。同じシステム。
Baker & Bose Informational [Page 32] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[32ページ]のRFC4923QoS
Of these, clearly the last is the simplest architecturally and the one that most minimizes the attendant risk.
明確に、建築上、最終はこれらでは、最も簡単なものであり、1つはそれです。大部分は付添人危険を最小にします。
4. Security Considerations
4. セキュリティ問題
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 Routerと減少すると、予約シグナリングデータグラムはデフォルトで下側のセキュリティー・レベル処理を受けるでしょう。 ほとんどのケースにおいて、下側のセキュリティ処理は許容できます。 しかしながら、あるネットワークで、全体の入れ子にされた経路の向こう側に合図する予約は最も高いセキュリティー・レベル処理(例えば、暗号化、シグナリングノードの認証)を受けなければなりません。 例えば、最も高い先行レベルは最も高いセキュリティー・レベルを提供できる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.
一般的な場合では、入れ子にされた経路がVPNsに参加できないルータを含むかもしれませんか、または提供はセキュリティー・レベルを必要としました。 下側のセキュリティー・レベルが許容できる場合にだけ(方針で構成されるように)、これらのルータは予約データグラムのシグナリングのために予約に参加できます。
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のパケットとprependが付加的なヘッダーであるとカプセル化します。 シグナリングかデータに使用されるか否かに関係なく、これらのパケットはIPアドレスとDSCP値で最小限で身元保証可能であるべきです。 したがって、prependedヘッダーは各パケットに最小限で合図された予約に対応するDSCP値を含むべきです。 これは、文字通りデータ(コントロール飛行機通行にデータと同じQoS処理を受けさせる)に使用される同じDSCP、または同様に発送される異なったDSCPであるかもしれません(ルーティングではなく、コントロールとデータ空輸QoSを切り離して)。
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
また、さらに、[RFC4860]と[RFC3175]で説明されるセキュリティ問題もこの環境で適切です。 彼らはいずれも間のノードで[RFC2747]と[RFC3097]で説明されたメカニズムと関連するかぎ管理(手動の構成か主要な管理プロトコルを通した)を通してメッセージを確実にすることができるRSVPの保全を含んでいます。
Baker & Bose Informational [Page 33] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[33ページ]のRFC4923QoS
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.
メッセージを処理するアグリゲータと「反-アグリゲータ」組。 さらに、IPsecを使うことによって、ホップの間に秘密性を提供できます。 かぎ管理と秘密性に、IETF MSEC作業部会におけるさらなる仕事はこれらの環境で適切であるかもしれません。
5. Acknowledgements
5. 承認
Doug Marquis, James Polk, Mike Tibodeau, Pete Babendreier, Roger Levesque, and Subha Dhesikan gave early review comments.
ダグMarquis、ジェイムズ・ポーク、マイクTibodeau、ピートBabendreier、ロジャー・レベスク、およびSubha Dhesikanは早めのレビューコメントを与えました。
Comments by Sean O'Keefe, Tony De Simone, Julie Tarr, Chris Christou, and their associates resulted in Section 3.2.
ショーン・オキーフ、トニー・Deシモン、ジュリー・ター、クリス・クリストウ、および彼らの仲間によるコメントはセクション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.
フランソアLe Faucheur、ブルース・デイビー、およびクリス・クリストウ(Pratikボーズがいる)は[RFC4860]を加えました。(それは、DSCPに関するこのアプローチの相互作用をはっきりさせました)。
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC2205] ブレーデン、B.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for
IPSEC Data Flows", RFC 2207, September 1997.
[RFC2207] バーガーとL.とT.オマリー、「IPSECデータフローのためのRSVP拡張子」、RFC2207、1997年9月。
[RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L.
Zhang, "RSVP Operation Over IP Tunnels", RFC 2746,
January 2000.
2000年1月の[RFC2746]TerzisとA.とKrawczykとJ.とWroclawski、J.とL.チャン、「IP Tunnelsの上のRSVP操作」RFC2746。
[RFC2750] Herzog, S., "RSVP Extensions for Policy Control", RFC
2750, January 2000.
[RFC2750] ハーツォグ、S.、「方針コントロールのためのRSVP拡張子」、RFC2750、2000年1月。
[RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC
2996, November 2000.
[RFC2996] Bernet、Y.、「RSVP DCLASSオブジェクトの形式」、RFC2996、2000年11月。
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B.
Davie, "Aggregation of RSVP for IPv4 and IPv6
Reservations", RFC 3175, September 2001.
[RFC3175] ベイカー、F.、イトゥラルデ、C.、Le Faucheur、F.、およびB.デイビー、「IPv4とIPv6予約のためのRSVPの集合」、RFC3175(2001年9月)。
[RFC4495] Polk, J. and S. Dhesikan, "A Resource Reservation
Protocol (RSVP) Extension for the Reduction of
Bandwidth of a Reservation Flow", RFC 4495, May 2006.
[RFC4495] ポーク、J.、およびS.Dhesikan(「予約流動の帯域幅の減少のための資源予約プロトコル(RSVP)拡大」、RFC4495)は2006がそうするかもしれません。
Baker & Bose Informational [Page 34] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[34ページ]のRFC4923QoS
[RFC4542] Baker, F. and J. Polk, "Implementing an Emergency
Telecommunications Service (ETS) for Real-Time
Services in the Internet Protocol Suite", RFC 4542,
May 2006.
[RFC4542] ベイカー、F.、およびJ.ポーク(「非常時がテレコムサービス(ETS)であるとインターネットのリアルタイムのプロトコル群に実装します」、RFC4542)は2006がそうするかもしれません。
[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.、デイビー、B.、ボーズ、P.、クリストウ、C.、およびM.ダヴェンポート、「ジェネリックの集合資源予約プロトコル(RSVP)予約」、RFC4860)は2007がそうするかもしれません。
6.2. Informative References
6.2. 有益な参照
[ITU.MLPP.1990] International Telecommunications Union, "Multilevel
Precedence and Preemption Service", ITU-T
Recommendation I.255.3, 1990.
[ITU.MLPP.1990] 国際電気通信組合、「先行と先取りが修理する多レベル」、ITU-T推薦I.255.3、1990。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview",
RFC 1633, June 1994.
[RFC1633] ブレーデン、B.、クラーク、D.、およびS.Shenker、「インターネットアーキテクチャにおける統合サービス:」 「概要」、RFC1633、1994年6月。
[RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation
Protocol (RSVP) -- Version 1 Message Processing
Rules", RFC 2209, September 1997.
[RFC2209] ブレーデンとB.とL.チャン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1メッセージ処理は統治する」RFC2209、1997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J.、「IETFの統合サービスとのRSVPの使用」、RFC2210、1997年9月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol,
Version 6 (IPv6) Specification", RFC 2460, December
1998.
[RFC2460]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2474] ニコルズ、K.、ブレーク、S.、ベイカー、F.、およびD.黒、「IPv4とIPv6ヘッダーとの差別化されたサービス分野(DS分野)の定義」、RFC2474(1998年12月)。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
Z., and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2475] ブレーク、S.は黒くされます、D.、カールソン、M.、デイヴィース、E.、ワング、Z.とW.ウィス、「差別化されたサービスのためのアーキテクチャ」RFC2475、1998年12月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747, January
2000.
[RFC2747] ベイカーとF.とリンデル、B.とM.Talwar、「RSVPの暗号の認証」、RFC2747、2000年1月。
Baker & Bose Informational [Page 35] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[35ページ]のRFC4923QoS
[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との使用のためのアプリケーションと潜水艦アプリケーションアイデンティティ方針要素」、RFC2872(2000年6月)
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC
3097, April 2001.
[RFC3097] ブレーデンとR.とL.チャン、「RSVPの暗号の認証--メッセージタイプ価値をアップデートする」RFC3097、2001年4月。
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy
Element", RFC 3181, October 2001.
[RFC3181] ハーツォグ、S.、「合図された先取り優先権方針要素」、RFC3181、2001年10月。
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P.,
Moore, T., Herzog, S., and R. Hess, "Identity
Representation for RSVP", RFC 3182, October 2001.
[RFC3182]YadavとS.とYavatkarとR.とPabbatiとR.とフォードとP.とムーアとT.とハーツォグ、S.とR.ヘス、「RSVPのアイデンティティ表現」RFC3182(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.、Le Boudec、J.、コートニー、W.、Davari、S.、Firoiu、V.、および2002年のD.Stiliadis、「完全優先転送PHB(1ホップあたりの振舞い)」、RFC3246行進。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Johnston, A., Peterson, J., Sparks, R., Handley, M.,
and E. Schooler, "SIP: Session Initiation Protocol",
RFC 3261, June 2002.
[RFC3261] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
"Integration of Resource Management and Session
Initiation Protocol (SIP)", RFC 3312, October 2002.
[RFC3312] キャマリロ、G.、マーシャル、W.、およびJ.ローゼンバーグ、「資源管理とセッション開始プロトコル(一口)の統合」、RFC3312(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] バーガー、L.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)シグナリング資源予約プロトコル交通工学(RSVP-Te)拡大」、RFC3473、2003年1月。
[RFC3474] Lin, Z. and D. Pendarakis, "Documentation of IANA
assignments for Generalized MultiProtocol Label
Switching (GMPLS) Resource Reservation Protocol -
Traffic Engineering (RSVP-TE) Usage and Extensions
for Automatically Switched Optical Network (ASON)",
RFC 3474, March 2003.
[RFC3474] リン、Z.、およびD.Pendarakis、「Generalized MultiProtocol Label Switching(GMPLS)リソース予約プロトコルのためのIANA課題のドキュメンテーション--Automatically Switched Optical Network(ASON)のためにEngineering(RSVP-TE)用法とExtensionsを取引してください」、RFC3474、2003年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4303]ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4303、2005年12月。
Baker & Bose Informational [Page 36] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[36ページ]のRFC4923QoS
Authors' Addresses
作者のアドレス
Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, California 93117 USA
デル・レイカリフォルニア93117サンタバーバラ(米国)経由でフレッドベイカーシスコシステムズ1121
Phone: +1-408-526-4257 Fax: +1-413-473-2403 EMail: fred@cisco.com
以下に電話をしてください。 +1-408-526-4257 Fax: +1-413-473-2403 メールしてください: fred@cisco.com
Pratik Bose Lockheed Martin 700 North Frederick Ave Gaithersburg, Maryland 20871 USA
北のフレディリック・Ave Pratikボーズロッキード・マーチン700メリーランド20871ゲイザースバーグ(米国)
Phone: +1-301-240-7041 Fax: +1-301-240-5748 EMail: pratik.bose@lmco.com
以下に電話をしてください。 +1-301-240-7041 Fax: +1-301-240-5748 メールしてください: pratik.bose@lmco.com
Baker & Bose Informational [Page 37] RFC 4923 QoS in a Nested VPN August 2007
入れ子にされたVPN2007年8月のベイカーとボーズ情報[37ページ]のRFC4923QoS
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Baker & Bose Informational [Page 38]
ベイカーとボーズInformationalです。[38ページ]
一覧
スポンサーリンク
