RFC3175 日本語訳
3175 Aggregation of RSVP for IPv4 and IPv6 Reservations. F. Baker, C.Iturralde, F. Le Faucheur, B. Davie. September 2001. (Format: TXT=88681 bytes) (Updated by RFC5350) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group F. Baker
Request for Comments: 3175 C. Iturralde
Category: Standards Track F. Le Faucheur
B. Davie
Cisco Systems
September 2001
コメントを求めるワーキンググループF.ベイカー要求をネットワークでつないでください: 3175年のC.イトゥラルデカテゴリ: 標準化過程F.Le Faucheur B.デイビーシスコシステムズ2001年9月
Aggregation of RSVP for IPv4 and IPv6 Reservations
IPv4とIPv6予約のためのRSVPの集合
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
Abstract
要約
This document describes the use of a single RSVP (Resource ReSerVation Protocol) reservation to aggregate other RSVP reservations across a transit routing region, in a manner conceptually similar to the use of Virtual Paths in an ATM (Asynchronous Transfer Mode) network. It proposes a way to dynamically create the aggregate reservation, classify the traffic for which the aggregate reservation applies, determine how much bandwidth is needed to achieve the requirement, and recover the bandwidth when the sub-reservations are no longer required. It also contains recommendations concerning algorithms and policies for predictive reservations.
このドキュメントはトランジットルーティング領域の向こう側に他のRSVPの予約に集めるために独身のRSVP(リソースReSerVationプロトコル)の予約の使用について説明します、概念的にATM(非同期なTransfer Mode)ネットワークにおけるVirtual Pathsの使用と同様の方法で。 サブの予約はもう必要でないときに、それがダイナミックに集合予約を作成して、集合予約が適用される交通を分類して、どのくらいの帯域幅が要件を達成するのに必要であるかを決定して、帯域幅を回復する方法を提案します。 また、それは予言の予約のためのアルゴリズムと方針に関して推薦を含んでいます。
1. Introduction
1. 序論
A key problem in the design of RSVP version 1 [RSVP] is, as noted in its applicability statement, that it lacks facilities for aggregation of individual reserved sessions into a common class. The use of such aggregation is recommended in [CSZ], and required for scalability.
RSVPバージョン1[RSVP]のデザインにおける主要な問題はそうです、個々の予約されたセッションの集合のための施設を共通集合に欠いているという適用性証明に述べられるように。 そのような集合の使用が、[CSZ]で推薦されて、スケーラビリティに必要です。
The problem of aggregation may be addressed in a variety of ways. For example, it may sometimes be sufficient simply to mark reserved traffic with a suitable DSCP (e.g., EF), thus enabling aggregation of scheduling and classification state. It may also be desirable to install one or more aggregate reservations from ingress to egress of
集合の問題はさまざまな方法で記述されるかもしれません。 例えば、単に適当なDSCP(例えば、EF)を予約された交通に付けるのは時々十分であるかもしれません、その結果、スケジューリングと分類状態の集合を可能にします。 また、それも1つ以上の集合イングレスから出口までの予約をインストールするのにおいて望ましいかもしれません。
Baker, et al. Standards Track [Page 1] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[1ページ]。
an "aggregation region" (defined below) where each aggregate reservation carries similarly marked packets from a large number of flows. This is to provide high levels of assurance that the end-to- end requirements of reserved flows will be met, while at the same time enabling reservation state to be aggregated.
それぞれの集合予約が多くから同様にマークされたパケットを運ぶ「集合領域」(以下では、定義される)が流れます。 同時に予約状態が集められるのを可能にしている間終わりから終わりへの予約された流れに関する必要条件が満たされるという高いレベルを保証を提供することこれがものである。
Throughout, we will talk about "Aggregator" and "Deaggregator", referring to the routers at the ingress and egress edges of an aggregation region. Exactly how a router determines whether it should perform the role of aggregator or deaggregator is described below.
あらゆる点で、私たちは「アグリゲータ」と"Deaggregator"に関して話すつもりです、集合領域のイングレスと出口縁でルータについて言及して。 ルータが、それがアグリゲータか「反-アグリゲータ」の役割を実行するべきであるかどうかちょうどどう決定するかが以下で説明されます。
We will refer to the individual reserved sessions (the sessions we
are attempting to aggregate) as "end-to-end" reservations ("E2E" for
short), and to their respective Path/Resv messages as E2E Path/Resv
messages. We refer to the the larger reservation (that which
represents many E2E reservations) as an "aggregate" reservation, and
its respective Path/Resv messages as "aggregate Path/Resv messages".
私たちは「終わりから終わり」条件(略して「2EのE」)としての個々の予約されたセッション(私たちが集めるのを試みるセッション)、および2EのE経路/Resvメッセージとしてのそれらのそれぞれの経路/Resvメッセージを参照するつもりです。 私たちは、より大きい条件(多くの2ユーロのEの予約を表すそれ)を「集合」の予約と呼んで、「集合Path/Resvメッセージ」としてそれぞれのPath/Resvメッセージを呼びます。
1.1. Problem Statement: Aggregation Of E2E Reservations
1.1. 問題声明: 2ユーロのE予約の集合
The problem of many small reservations has been extensively discussed, and may be summarized in the observation that each reservation requires a non-trivial amount of message exchange, computation, and memory resources in each router along the way. It would be nice to reduce this to a more manageable level where the load is heaviest and aggregation is possible.
多くの小さい予約の問題は、手広く議論して、各予約が道に沿って各ルータにおける重要な量の交換処理、計算、およびメモリリソースを必要とするという観測でまとめられるかもしれません。 負荷が最も重く、集合が可能であるところで、より処理しやすいレベルにこれを引き下げてうれしいでしょう。
Aggregation, however, brings its own challenges. In particular, it reduces the level of isolation between individual flows, implying that one flow may suffer delay from the bursts of another. Synchronization of bursts from different flows may occur. However, there is evidence [CSZ] to suggest that aggregation of flows has no negative effect on the mean delay of the flows, and actually leads to a reduction of delay in the "tail" of the delay distribution (e.g., 99% percentile delay) for the flows. These benefits of aggregation to some extent offset the loss of strict isolation.
しかしながら、集合はそれ自身の挑戦をもたらします。 特に、個々の流れの間の孤立のレベルを減少させます、1回の流れが別のものの炸裂から遅れを受けるかもしれないのを含意して。 異なった流れからの炸裂の同期は起こるかもしれません。 しかしながら、流れの集合が流れの意地悪な遅れにマイナスの効果を全く持たないで、実際に流れのための遅れ分配(例えば、99%の百分順位遅れ)の「テール」での遅れの減少に通じるのを示すために、証拠[CSZ]があります。 集合のこれらの利益は厳しい孤立の損失をある程度相殺します。
1.2. Proposed Solution
1.2. 提案されたソリューション
The solution we propose involves the aggregation of several E2E reservations that cross an "aggregation region" and share common ingress and egress routers into one larger reservation from ingress to egress. We define an "aggregation region" as a contiguous set of systems capable of performing RSVP aggregation (as defined following) along any possible route through this contiguous set.
私たちが提案する解決策は1つのより大きいイングレスから出口までの予約と「集合領域」に交差していて、一般的なイングレスと出口ルータを共有する数個の2ユーロのEの予約の集合にかかわります。 私たちはこの隣接のセットを通してどんな可能なルートに沿ってもRSVP集合(続いて、定義されるように)を実行できるシステムの隣接のセットと「集合領域」を定義します。
Baker, et al. Standards Track [Page 2] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[2ページ]。
Communication interfaces fall into two categories with respect to an aggregation region; they are "exterior" to an aggregation region, or they are "interior" to it. Routers that have at least one interface in the region fall into one of three categories with respect to a given RSVP session; they aggregate, they deaggregate, or they are between an aggregator and a deaggregator.
通信インターフェースは集合領域に関して2つのカテゴリになります。 それらが集合領域に「外です」、またはそれらはそれに「内部です」。 その領域に少なくとも1つのインタフェースを持っているルータが与えられたRSVPセッションに関して3つのカテゴリの1つになります。 彼らが集めるか、「反-集合」です、またはアグリゲータと「反-アグリゲータ」の間には、彼らはいます。
Aggregation depends on being able to hide E2E RSVP messages from RSVP-capable routers inside the aggregation region. To achieve this end, the IP Protocol Number in the E2E reservation's Path, PathTear, and ResvConf messages is changed from RSVP (46) to RSVP-E2E-IGNORE (134) upon entering the aggregation region, and restored to RSVP at the deaggregator point. These messages are ignored (no state is stored and the message is forwarded as a normal IP datagram) by each router within the aggregation region whenever they are forwarded to an interior interface. Since the deaggregating router perceives the previous RSVP hop on such messages to be the aggregating router, Resv and other messages do not require this modification; they are unicast from RSVP hop to RSVP hop anyway.
集合は集合領域の中に2EのE RSVPメッセージをRSVPできるルータから隠すことができるのに依存します。 この終わり、2ユーロのEの予約のPathのIPプロトコルNumber、PathTear、およびResvConfメッセージを達成するのは、集合領域に入るときRSVP(46)から2RSVP EのE IGNORE(134)に変えられて、「反-アグリゲータ」ポイントでRSVPに回復します。 内部のインタフェースにそれらを送るときはいつも、これらのメッセージは集合領域の中の各ルータによって無視されます(状態を全く格納しません、そして、正常なIPデータグラムとしてメッセージを転送します)。 「反-集合」ルータが、前のRSVPが集合ルータであるそのようなメッセージに跳び乗ると知覚するので、Resvと他のメッセージはこの変更を必要としません。 RSVPホップからRSVPホップまでそれらはとにかくユニキャストです。
The token buckets (SENDER_TSPECs and FLOWSPECS) of E2E reservations are summed into the corresponding information elements in aggregate Path and Resv messages. Aggregate Path messages are sent from the aggregator to the deaggregator(s) using RSVP's normal IP Protocol Number. Aggregate Resv messages are sent back from the deaggregator to the aggregator, thus establishing an aggregate reservation on behalf of the set of E2E flows that use this aggregator and deaggregator.
2ユーロのEの予約の象徴バケツ(SENDER_TSPECsとFLOWSPECS)は集合PathとResvメッセージに対応する情報要素へまとめられます。 RSVPの正常なIPプロトコルNumberを使用することで集合Pathメッセージをアグリゲータからdeaggregator(s)に送ります。 集合Resvメッセージは「反-アグリゲータ」からアグリゲータまで返送されます、その結果、このアグリゲータと「反-アグリゲータ」を使用する2EのE流れのセットを代表して集合予約を確立します。
Such establishment of a smaller number of aggregate reservations on behalf of a larger number of E2E reservations yields the corresponding reduction in the amount of state to be stored and amount of signalling messages exchanged in the aggregation region.
より多くの2EのEの予約を代表したより少ない数の集合予約のそのような設立は格納されるべき状態の量とメッセージが集合領域で交換した合図の量の対応する減少をもたらします。
By using Differentiated Services mechanisms for classification and scheduling of traffic supported by aggregate reservations (rather than performing per aggregate reservation classification and scheduling), the amount of classification and scheduling state in the aggregation region is even further reduced. It is not only independent of the number of E2E reservations, it is also independent of the number of aggregate reservations in the aggregation region. One or more Diff-Serv DSCPs are used to identify traffic covered by aggregate reservations and one or more Diff-Serv PHBs are used to offer the required forwarding treatment to this traffic. There may be more than one aggregate reservation between the same pair of routers, each representing different classes of traffic and each using a different DSCP and a different PHB.
集合条件(集合予約分類単位で働いて、スケジューリングよりむしろ)で支持された交通の分類とスケジューリングのためのDifferentiated Servicesメカニズムを使用することによって、集合領域の分類とスケジューリング状態の量はさらに減少さえします。 2ユーロのEの予約の数から独立しているだけではない、また、それも集合領域の集合予約の数から独立しています。 1Diff-Serv DSCPsが集合予約でカバーされた交通を特定するのに使用されます、そして、1Diff-Serv PHBsが、必要な推進処理をこの交通に提供するのに使用されます。 ルータの同じ組と、それぞれ異なったクラスの交通を表して、それぞれ異なったDSCPを使用して、異なったPHBの間には、1つ以上の集合予約があるかもしれません。
Baker, et al. Standards Track [Page 3] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[3ページ]。
1.3. Definitions
1.3. 定義
We define an "aggregation region" as a set of RSVP-capable routers for which E2E RSVP messages arriving on an exterior interface of one router in the set would traverse one or more interior interfaces (of this and possibly of other routers in the set) before finally traversing an exterior interface.
私たちは最終的に外のインタフェースを横断する前にセットにおける1つのルータの外のインタフェースで到着する2EのE RSVPメッセージが1つ以上の内部のインタフェース(これとことによるとセットにおける他のルータの)を横断する1セットのRSVPできるルータと「集合領域」を定義します。
Such an E2E RSVP message is said to have crossed the aggregation region.
そのようなE2E RSVPメッセージは集合領域に交差したと言われています。
We define the "aggregating" router for this E2E flow as the first router that processes the E2E Path message as it enters the aggregation region (i.e., the one which forwards the message from an exterior interface to an interior interface).
私たちはこの2EのE流動のために集合領域(すなわち、外のインタフェースから内部のインタフェースまでメッセージを転送するもの)に入るとき2EのE Pathメッセージを処理する最初のルータと「集合」ルータを定義します。
We define the "deaggregating" router for this E2E flow as the last router to process the E2E Path as it leaves the aggregation region (i.e., the one which forwards the message from an interior interface to an exterior interface).
私たちはこの2EのE流動のために(すなわち、内部のインタフェースから外のインタフェースまでメッセージを転送するもの)に集合領域を出るとき2EのE Pathを処理する最後のルータと「「反-集合」」ルータを定義します。
We define an "interior" router for this E2E flow as any router in the aggregation region which receives this message on an interior interface and forwards it to another interior interface. Interior routers perform neither aggregation nor deaggregation for this flow.
私たちはこの2EのE流動のために内部のインタフェースにこのメッセージを受け取って、別の内部のインタフェースにそれを送る集合領域のどんなルータとも「内部」のルータを定義します。 内部のルータはこの流れのために集合も「反-集合」も実行しません。
Note that by these definitions a single router with a mix of interior and exterior interfaces may have the capability to act as an aggregator on some E2E flows, a deaggregator on other E2E flows, and an interior router on yet other flows.
内部の、そして、外のインタフェースのミックスがあるただ一つのルータにはこれらの定義で、およそ2EのEのアグリゲータが流れるとき行動する能力、他の2EのE流れの「反-アグリゲータ」、およびまだ他の流れに関する内部のルータがあるかもしれないことに注意してください。
1.4. Detailed Aspects of Proposed Solution
1.4. 提案されたソリューションの詳細な局面
A number of issues jump to mind in considering this model.
多くの問題が、このモデルを考える際に気にするためにジャンプします。
1.4.1. Traffic Classification Within The Aggregation Region
1.4.1. 集合領域の中の交通分類
One of the reasons that RSVP Version 1 did not identify a way to aggregate sessions was that there was not a clear way to classify the aggregate. With the development of the Differentiated Services architecture, this is at least partially resolved; traffic of a particular class can be marked with a given DSCP and so classified. We presume this model.
RSVPバージョン1が集合セッションへの道を特定しなかった理由の1つは集合を分類する明確な方法がなかったということでした。 Differentiated Services構造の開発で、これは少なくとも部分的に決議されています。 特定のクラスの交通を与えられたDSCPと共にマークして、そう分類できます。 私たちはこのモデルを推定します。
We presume that on each link en route, a queue, WDM color, or similar management component is set aside for all aggregated traffic of the same class, and that sufficient bandwidth is made available to carry
私たちは途中各リンクの上では、同じクラスのすべての集められた交通のために待ち行列、WDM色、または同様の管理コンポーネントをかたわらに置いて、十分な帯域幅を運ぶために利用可能にすると推定します。
Baker, et al. Standards Track [Page 4] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[4ページ]。
the traffic that has been assigned to it. This bandwidth may be adjusted based on the total amount of aggregated reservation traffic assigned to the same class.
それに割り当てられた交通。 この帯域幅は同じクラスに配属された集められた予約交通の総量に基づいて調整されるかもしれません。
There are numerous options for exactly which Diff-serv PHBs might be used for different classes of traffic as it crosses the aggregation region. This is the "service mapping" problem described in [RFC2998], and is applicable to situations broader than those described in this document. Arguments can be made for using either EF or one or more AF PHBs for aggregated traffic. For example, since controlled load requires non-TSpec-conformant (policed) traffic to be forwarded as best effort traffic rather than dropped, it may be appropriate to use an AF class for controlled load, using the higher drop preference for non-conformant packets.
集合領域に交差しているのでまさに、異なったクラスの交通にどのDiff-serv PHBsを使用できるように頻繁なオプションがあるか。 これは、[RFC2998]で説明された「サービス対応表」問題であり、本書では説明されたものより広い状況に適切です。 集められた交通にEFか1AF PHBsのどちらかを使用するために議論をすることができます。 例えば、制御負荷が、非TSpec-conformant(取り締まられる)交通が落とされるよりベストエフォート型交通としてむしろ進められるのを必要とするので、制御負荷にAFのクラスを使用するのは適切であるかもしれません、非conformantパケットにより高い低下好みを使用して。
In conventional (unaggregated) RSVP operation, a session is identified by a destination address and optionally a protocol port. Since data belonging to an aggregated reservation is identified by a DSCP, the session is defined by the destination address and DSCP. For those cases where two DSCPs are used (for conformant and non- conformant packets, as noted above), the session is identified by the DSCP of conformant packets. In general we will talk about mapping aggregated traffic onto a DSCP (even if a second DSCP may be used for non-conformant traffic).
従来(「非-集合」である)のRSVP操作では、セッションは送付先アドレスによって特定されます、そして、任意に、aはポートについて議定書の中で述べます。 集められた予約に属すデータがDSCPによって特定されるので、セッションは目的地のアドレスとDSCPによって定義されます。 2DSCPsが使用されている(conformantと非conformantのパケットのために上で述べたように)それらのケースにおいて、セッションはconformantパケットのDSCPによって特定されます。 一般に、私たちは集められた交通をDSCPに写像することに関して話すつもりです(第2のDSCPが非conformant交通に使用されても)。
Whichever PHB or PHBs are used to carry aggregated reservations, care needs to be take in an environment where provisioned Diff-Serv and aggregated RSVP are used in the same network, to ensure that the total admitted load for a single PHB does not exceed the link capacity allocated to that PHB. One solution to this is to reserve one PHB (or more) strictly for the aggregated reservation traffic (e.g., AF1 Class) while using other PHBs for provisioned Diff-Serv (e.g., AF2, AF3 and AF4 Classes).
運ぶのに使用されるPHBかPHBsが条件(食糧を供給されたDiff-Servと集められたRSVPが独身のPHBのための総認められた負荷がそのPHBに割り当てられたリンク容量を超えていないのを保証するのに同じネットワークに使用される環境における撮影である注意の必要性)を集めました。 この1つの解決策は集められた予約交通(例えば、AF1 Class)への1PHB(さらに)が食糧を供給されたDiff-Serv(例えば、AF2、AF3、およびAF4 Classes)に他のPHBsを使用している間、厳密に、控え目であることです。
Inside the aggregation region, some RSVP reservation state is maintained per aggregate reservation, while classification and scheduling state (e.g., DSCPs used for classifying traffic) is maintained on a per aggregate reservation class basis (rather than per aggregate reservation). For example, if Guaranteed Service reservations are mapped to the EF DSCP throughout the aggregation region, there may be a reservation for each aggregator/deaggregator pair in each router, but only the EF DSCP needs to be inspected at each interior interface, and only a single queue is used for all EF traffic.
集合領域の中では、何らかのRSVP予約状態が集合予約単位で維持されます、分類とスケジューリング状態(例えば交通を分類するのに使用されるDSCPs)が集合予約クラス基礎あたりのaで維持されますが(むしろ、集合予約、) EF DSCPだけが、それぞれの内部のインタフェースで点検される必要があります、そして、例えば、Guaranteed Serviceの予約が集合領域中のEF DSCPに写像されるなら、各ルータにはそれぞれのアグリゲータ/「反-アグリゲータ」組の予約があるかもしれませんが、ただ一つの待ち行列だけがすべてのEF交通に使用されます。
Baker, et al. Standards Track [Page 5] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[5ページ]。
1.4.2. Deaggregator Determination
1.4.2. Deaggregator決断
The first question is "How do we determine the Aggregator/Deaggregator pair that are responsible for aggregating a particular E2E flow through the aggregation region?"
最初の質問は「私たちはどのように集合領域を通る特定のE2E流動に集めるのに責任があるAggregator/Deaggregator組を決心していますか?」です。
Determination of the aggregator is trivial: we know that an E2E flow has arrived at an aggregator when its Path message arrives at a router on an exterior interface and must be forwarded on an interior interface.
アグリゲータの決断は些細です: 私たちは、Pathメッセージは外のインタフェースでルータに到着して、内部のインタフェースで転送しなければならないとき、E2E流動がアグリゲータに到着したのを知っています。
Determination of the deaggregator is more involved. If an SPF routing protocol, such as OSPF or IS-IS, is in use, and if it has been extended to advertise information on Deaggregation roles, it can tell us the set of routers from which the deaggregator will be chosen. In principle, if the aggregator and deaggregator are in the same area, then the identity of the deaggregator could be determined from the link state database. However, this approach would not work in multi-area environments or for distance vector protocols.
「反-アグリゲータ」の決断はさらにかかわります。 または、OSPFなどのSPFルーティング・プロトコルである、-、コネは使用であり、Deaggregationの役割の情報の広告を出すために広げられたなら、それは「反-アグリゲータ」が選ばれるルータのセットを私たちに言うことができます。 原則として、アグリゲータと「反-アグリゲータ」が同じ領域にいるなら、「反-アグリゲータ」のアイデンティティはリンク州のデータベースから決定するかもしれません。 しかしながら、このアプローチはマルチ領域環境か距離ベクトルプロトコルに効き目がないでしょう。
One method for Deaggregator determination is manual configuration. With this method the network operator would configure the Aggregator and the Deaggregator with the necessary information.
Deaggregator決断のための1つの方法は手動の構成です。 この方法で、ネットワーク・オペレータは必要事項でAggregatorとDeaggregatorを構成するでしょう。
Another method allows automatic Deaggregator determination and corresponding Aggregator notification. When the E2E RSVP Path message transits from an interior interface to an exterior interface, the deaggregating router must advise the aggregating router of the correlation between itself and the flow. This has the nice attribute of not being specific to the routing protocol. It also has the property of automatically adjusting to route changes. For instance, if because of a topology change, another Deaggregator is now on the shortest path, this method will automatically identify the new Deaggregator and swap to it.
別の方法は自動Deaggregator決断と対応するAggregator通知を許容します。 2EのE RSVP Pathメッセージが内部のインタフェースから外のインタフェースまで通過するとき、「反-集合」ルータはそれ自体と流れの間の相関関係を集合ルータに知らせなければなりません。 これには、ルーティング・プロトコルに特定でないことの良い属性があります。 また、それには、変化を発送するために自動的に適応する特性があります。 例えば、別のDeaggregatorがトポロジー変化のために現在、最短パスにあると、この方法は、自動的に新しいDeaggregatorを特定して、それにスワップされるでしょう。
1.4.3. Mapping E2E Reservations Onto Aggregate Reservations
1.4.3. 2ユーロのE予約を集合予約に写像します。
As discussed above, there may be multiple Aggregate Reservations between the same Aggregator/Deaggregator pair. The rules for mapping E2E reservations onto aggregate reservations are policy decisions which depend on the network environment and network administrator's objectives. Such a policy is outside the scope of this specification and we simply assume that such a policy is defined by the network administrator. We also assume that such a policy is somehow accessible to the Aggregators/Deaggregators but the details of how this policy is made accessible to Aggregators/Deaggregators (Local Configuration, COPS, LDAP, etc.) is outside the scope of this specification.
上で議論するように、同じAggregator/Deaggregator組の間には、複数のAggregate予約があるかもしれません。 2ユーロのEの予約を集合予約に写像するための規則はネットワーク環境とネットワークアドミニストレータの目的による政策決定です。 この仕様の範囲の外にそのような方針はあります、そして、私たちはそのような方針がネットワーク管理者によって定義されると単に思います。 また、私たちは、そのような方針がどうにかAggregators/Deaggregatorsにアクセスしやすいと思いますが、この仕様の範囲の外にどうこの方針をAggregators/Deaggregators(地方のConfiguration、COPS、LDAPなど)にアクセスしやすくするかに関する詳細があります。
Baker, et al. Standards Track [Page 6] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[6ページ]。
An example of very simple policy would be that all the E2E reservations are mapped onto a single Aggregate Reservation (i.e., single DSCP) between a given pair of Aggregator/Deaggregator.
非常に簡単な方針に関する例はすべての2ユーロのEの予約がAggregator/Deaggregatorの与えられた組の間のただ一つのAggregate予約(すなわち、独身のDSCP)に写像されるということでしょう。
Another example of policy, which takes into account the Int-Serv service type requested by the receiver (and signalled in the E2E Resv), would be where Guaranteed Service E2E reservations are mapped onto one DSCP in the aggregation region and where Controlled Load E2E reservations are mapped onto another DSCP.
方針に関する別の例は2EのGuaranteed Service Eの予約がどこで集合領域の1DSCPに写像されるか、そして、2EのControlled Load Eの予約がどこで別のDSCPに写像されるかということでしょう。(方針は受信機(そして、2EのE Resvでは、合図される)によって要求されたInt-Servサービスタイプを考慮に入れます)。
A third example of policy would be one where the mapping of E2E reservations onto Aggregate Reservations take into account Policy Objects (such as information authenticating the end user) which may be included by the sender in the E2E path and/or by the receiver in the E2E Resv.
方針に関する3番目の例はAggregate予約への2ユーロのEの予約に関するマッピングが2EのE経路の送付者2EのE Resvの受信機によって含まれるかもしれないPolicy Objects(エンドユーザを認証する情報などの)を考慮に入れるものでしょう。
Regardless of the actual policy, a range of options are conceivable for where the decision to map an E2E reservation onto an aggregate reservation is taken and how this decision is communicated between Aggregator and Deaggregator. Both Aggregator and Deaggregator could be assumed to make such a decision independently. However, this would either require definition of additional procedures to solve inconsistent mapping decisions (i.e., Aggregator and Deaggregator decide to map a given E2E reservation onto different Aggregate Reservations) or would result in possible undetected misbehavior in the case of inconsistent decisions.
実際の方針にかかわらず、さまざまなオプションがどこでE2Eの予約を集合予約に写像するという決定を取るか、そして、AggregatorとDeaggregatorの間でどのようにこの決定を伝えるかに想像できます。 AggregatorとDeaggregatorの両方が独自にそのような決定をすると思うことができました。 しかしながら、これは、無節操なマッピング決定(すなわち、AggregatorとDeaggregatorは、与えられたE2Eの予約を異なったAggregate予約に写像すると決める)を解決するために追加手順の定義を必要とするだろうか、または無節操な決定の場合で可能な非検出された不正行為をもたらすでしょう。
For simplicity and reliability, we assign the responsibility of the mapping decision entirely to the Deaggregator. The Aggregator is notified of the selected mapping by the Deaggregator and follows this decision. The Deaggregator was chosen rather than the Aggregator because the Deaggregator is the first to have access to all the information required to make such a decision (in particular receipt of the E2E Resv which indicates the requested Int-Serv service type and includes information signalled by the receiver). This allows faster operations such as set-up or size adjustment of an Aggregate Reservation in a number of situations resulting in faster E2E reservation establishment.
簡単さと信頼性のために、私たちはマッピング決定の責任を完全にDeaggregatorに割り当てます。 Aggregatorは選択されたマッピングについてDeaggregatorによって通知されて、この決定に続きます。 Deaggregatorがそのような決定(特に要求されたInt-Servサービスタイプを示して、受信機によって合図された情報を含んでいる2EのE Resvの領収書)をするのに必要であるすべての情報に近づく手段を持つ1番目であるので、DeaggregatorはAggregatorよりむしろ選ばれました。 これは、より速く2ユーロのE予約設立をもたらす多くの状況における、Aggregate予約のセットアップかサイズの調節などの、より速い操作を許します。
1.4.4. Size of Aggregate Reservations
1.4.4. 集合予約のサイズ
A range of options exist for determining the size of the aggregate reservation, presenting a tradeoff between simplicity and scalability. Simplistically, the size of the aggregate reservation needs to be greater than or equal to the sum of the bandwidth of the E2E reservations it aggregates, and its burst capacity must be greater than or equal to the sum of their burst capacities. However, if followed religiously, this leads us to change the bandwidth of the
さまざまなオプションが、簡単さとスケーラビリティの間の見返りを提示して、集合予約のサイズを決定するために存在しています。 Simplisticallyに、集合予約のサイズは、それが集める2ユーロのEの予約の帯域幅のより多くの合計である必要があります、そして、炸裂容量は彼らの炸裂能力の合計以上であるに違いありません。 しかしながら、私たちは帯域幅を変えますこれが、宗教的に続かれているなら導く。
Baker, et al. Standards Track [Page 7] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[7ページ]。
aggregate reservation each time an underlying E2E reservation changes, which loses one of the key benefits of aggregation, the reduction of message processing cost in the aggregation region.
基本的なE2Eの予約(集合の主要な利益の1つを失う)が変化するたびに予約を集めてください、集合領域でのメッセージ加工費の減少。
We assume, therefore, that there is some policy, not defined in this specification (although sample policies are suggested which have the necessary characteristics). This policy maintains the amount of bandwidth required on a given aggregate reservation by taking account of the sum of the bandwidths of its underlying E2E reservations, while endeavoring to change it infrequently. This may require some level of trend analysis. If there is a significant probability that in the next interval of time the current aggregate reservation will be exhausted, the router must predict the necessary bandwidth and request it. If the router has a significant amount of bandwidth reserved but has very little probability of using it, the policy may be to predict the amount of bandwidth required and release the excess.
したがって、私たちは、何らかの方針がこの仕様に基づき定義されるのではなく、あると思います(サンプル方針は示されますが(必要な特性があります))。 この方針は、帯域幅の量が努力している間、基本的な2ユーロのEの予約の帯域幅の合計を考慮に入れるのによる与えられた集合予約でそれをまれに変えるのが必要であると主張します。 これは何らかのレベルの傾向変動分析を必要とするかもしれません。 時間の次の間隔では、現在の集合予約が消耗するという重要な確率があれば、ルータは、必要な帯域幅を予測して、それを要求しなければなりません。 ルータでは、かなりの量の帯域幅を控えさせますが、それを使用するという確率はほとんどないなら、方針が、帯域幅の量が必要であると予測して、過剰をリリースすることであるかもしれません。
This policy is likely to benefit from introduction of some hysteresis (i.e., ensure that the trigger condition for aggregate reservation size increase is sufficiently different from the trigger condition for aggregate reservation size decrease) to avoid oscillation in stable conditions.
この方針は、安定した状態における振動を避けるためにいくらかのヒステリシス(すなわち、引き金の状態が集合予約サイズ増加のために集合予約サイズ減少のための引き金の状態と十分異なっているのを確実にする)の導入の利益を得そうです。
Clearly, the definition and operation of such policies are as much business issues as they are technical, and are out of the scope of this document.
明確に、そのような方針の定義と操作は、それらが技術的であり同じくらい多くのビジネス問題であり、このドキュメントの範囲の外にあります。
1.4.5. E2E Path ADSPEC update
1.4.5. 2ユーロのE経路ADSPECアップデート
As described above, E2E RSVP messages are hidden from the Interior routers inside the aggregation region. Consequently, the ADSPECs of E2E Path messages are not updated as they travel through the aggregation region. Therefore, the Deaggregator for a flow is responsible for updating the ADSPEC in the corresponding E2E Path to reflect the impact of the aggregation region on the QoS that may be achieved end-to-end. The Deaggregator should update the ADSPEC of the E2E Path as accurately as possible.
上で説明されるように、集合領域の中のInteriorルータ2EのE RSVPメッセージを隠されます。 その結果、集合領域を通って旅行するとき、2EのE PathメッセージのADSPECsをアップデートしません。 したがって、流れのためのDeaggregatorは達成された終わりから終わりであるかもしれないQoSの上の集合領域の影響を反映するために2対応するEのE PathでADSPECをアップデートするのに責任があります。 Deaggregatorはできるだけ正確に2EのE PathのADSPECをアップデートするはずです。
Since Aggregate Path messages are processed inside the aggregation region, their ADSPEC is updated by Interior routers to reflect the impact of the aggregation region on the QoS that may be achieved within the interior region. Consequently, the Deaggregator should make use of the information included in the ADSPEC from an Aggregate Path where available. The Deaggregator may elect to wait until such information is available before forwarding the E2E Path in order to accurately update its ADSPEC.
Aggregate Pathメッセージが集合領域の中で処理されるので、InteriorルータでそれらのADSPECをアップデートして、内陸の領域の中で達成されるかもしれないQoSの上の集合領域の影響を反映します。 その結果、Deaggregatorは入手できるところにADSPECにAggregate Pathから含まれていた情報を利用するはずです。 Deaggregatorは、正確にADSPECをアップデートするために2EのE Pathを進める前にそのような情報が利用可能になるまで待つのを選ぶかもしれません。
Baker, et al. Standards Track [Page 8] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[8ページ]。
To maximize the information made available to the Deaggregator, whenever the Aggregator signals an Aggregate Path, the Aggregator should include an ADSPEC with fragments for all service types supported in the aggregation region (even if the Aggregate Path corresponds to an Aggregate Reservation that only supports a subset of those service types). Providing this information to the Deaggregator for every possible service type facilitates accurate and timely update of the E2E ADSPEC by the Deaggregator.
AggregatorがAggregate Pathに合図するときはいつも、Deaggregatorが入手した情報を最大にするために、Aggregatorは集合領域で支持されたすべてのサービスタイプのための断片があるADSPECを含んでいるはずです(Aggregate Pathがそれらのサービスタイプの部分集合をサポートするだけであるAggregate予約に対応していても)。 すべての可能なサービスタイプのためにこの情報をDeaggregatorに供給すると、Deaggregatorによる2EのE ADSPECの正確でタイムリーなアップデートは容易にされます。
Depending on the environment and on the policy for mapping E2E reservations onto Aggregate Reservations, to accurately update the E2E Path ADSPEC, the Deaggregator may for example:
正確に2EのE Path ADSPECをアップデートするために2ユーロのEの予約をAggregate予約に写像するために環境と、そして、方針によって、例えば、Deaggregatorはよります:
- update all the E2E Path ADSPEC segments (Default General
Parameters Fragment, Guaranteed Service Fragment, Controlled-Load
Service Fragment) based on the ADSPEC of a single Aggregate Path,
or
- または独身のAggregate PathのADSPECに基づくすべての2EのE Path ADSPECセグメント(デフォルトParameters Fragment司令官、Guaranteed Service Fragment、Controlled-負荷Service Fragment)をアップデートしてください。
- update the E2E Path ADSPEC by taking into account the ADSPEC from
multiple Aggregate Path messages (e.g.,. update the Default
General Parameters Fragment using the "worst" value for each
parameter across all the Aggregate Paths' ADSPECs, update the
Guaranteed Service Fragment using the Guaranteed Service Fragment
from the ADSPEC of the Aggregate Path for the reservation used for
Guaranteed Services).
- 複数のAggregate PathメッセージからADSPECを考慮に入れることによって、2EのE Path ADSPECをアップデートしてください。(例えば、各パラメタにAggregate PathsのADSPECsの向こう側に「最もひどく」値を使用することでDefaultの司令官のParameters Fragmentをアップデートしてくださいといって、Guaranteed Servicesに使用される予約にAggregate PathのADSPECからGuaranteed Service Fragmentを使用することでGuaranteed Service Fragmentをアップデートしてください、)
By taking into account the information contained in the ADSPEC of Aggregate Path(s) as mentioned above, the Deaggregator should be able to accurately update the E2E Path ADSPEC in most situations.
以上のようのAggregate Path(s)のADSPECに含まれた情報を考慮に入れることによって、Deaggregatorはほとんどの状況で正確に2EのE Path ADSPECをアップデートするはずであることができます。
However, we note that there may be particular situations where the E2E Path ADSPEC update cannot be made entirely accurately by the Deaggregator. This is most likely to happen when the path taken across the aggregation region depends on the service requested in the E2E Resv, which is yet to arrive. Such a situation could arise if, for example:
しかしながら、私たちは、特定の状況がDeaggregatorが完全に正確に2ユーロのE Path ADSPECアップデートをすることができないところにあるかもしれないことに注意します。 集合領域の向こう側に取られた経路がまだ到着していない2EのE Resvで要求されたサービスによるとき、これは最も起こりそうです。 そのような状況が起こるかもしれない、例えば:
- The service mapping policy for the aggregation region is such that
E2E reservations requesting Guaranteed Service are mapped to a
different PHB that those requesting Controlled Load service.
- 集合領域へのサービス対応表方針がそのようなものであるので、Guaranteed Serviceを要求する2ユーロのEの予約がそれらの要求Controlled Loadが調整する異なったPHBに写像されます。
- Diff-Serv aware routing is used in the aggregation region, so that
packets with different DSCPs follow different paths (sending them
over different MPLS label switched paths, for example).
- デフ-Servの意識しているルーティングは集合領域で使用されます、異なったDSCPsがあるパケットが異なった経路(例えば、それらを異なったMPLSが切り換えられた経路とラベルする移動する)に続くように。
As a result, the ADSPEC for the aggregate reservation that supports guaranteed service may differ from the ADSPEC for the aggregate reservation that supports controlled load.
その結果、サポートがサポートが制御されたという集合条件のためのADSPECと異なるかもしれないのがサービスに保証される集合予約のためのADSPECはロードします。
Baker, et al. Standards Track [Page 9] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[9ページ]。
Assume that the sender sends an E2E Path with an ADSPEC containing segments for both Guaranteed Services and Controlled Load. Then, at the time of updating the E2E ADSPEC, the Deaggregator does not know which service type will actually be requested by the receiver and therefore cannot know which PHB will be used to transport this E2E flow and, in turn, cannot pick the right parameter values to factor in when updating the Default General Parameters Fragment. As mentioned above, in this particular case, a conservative approach would be to always take into account the worst value for every parameter. Regardless of whether this conservative approach is followed or some simpler approach such as taking into account one of the two Aggregate Path ADSPEC, the E2E Path ADSPEC will be inaccurate (over-optimistic or over-pessimistic) for at least one service type actually requested by the destination.
ADSPECがGuaranteed ServicesとControlled Loadの両方のためのセグメントを含んでいて送付者がE2E Pathを送ると仮定してください。 次に、2EのE ADSPECをアップデートする時点で、Deaggregatorは、どのサービスタイプが実際に受信機によって要求されるかを知らないで、したがって、この2EのE流動を輸送するためにどのPHBが使用されるかを知ることができないで、Defaultの司令官のParameters Fragmentをアップデートするとき、計算に入れるために順番に正しいパラメタ値を選ぶことができません。 この特定の場合で以上のようです、保守的なアプローチはあらゆるパラメタのためにいつも最も悪い値を考慮に入れるだろうことです。 この保守的なアプローチが続かれているか、そして、2Aggregate Path ADSPECの1つを考慮に入れなどなどの、より簡単な何らかのアプローチにかかわらず、2EのE Path ADSPECが実際に目的地によって要求された少なくとも1つのサービスタイプに不正確になるでしょう(過剰楽観的であるか過剰悲観的な)。
Recognizing that entirely accurate update of E2E Path ADSPEC may not be possible in all situations, we recommend that a conservative approach be taken in such situations (over-pessimistic rather than over-optimistic) and that the E2E Path ADSPEC be corrected as soon as possible. In the example described above, this would mean that as soon as the Deaggregator receives the E2E Resv from the receiver, the Deaggregator should generate another E2E Path with an accurately updated ADSPEC based on the knowledge of which aggregate reservation will actually carry the E2E flow.
2EのE Path ADSPECの完全に正確なアップデートがすべての状況で可能でないかもしれないと認めて、私たちは、そのような状況(過剰楽観的であるというよりむしろ過剰悲観的な)で保守的なアプローチを取って、できるだけ早く2EのE Path ADSPECを修正することを勧めます。 上で説明された例では、これは、受信機を2EのE Resv受け取るとすぐに、Deaggregatorがどの集合予約が実際に2EのE流動を運ぶかに関する知識に基づく正確にアップデートされたADSPECと共に別の2EのE Pathを発生させるはずであることを意味するでしょう。
1.4.6. Intra-domain Routes
1.4.6. イントラドメインルート
RSVP directly handles route changes, in that reservations follow the routes that their data follow. This follows from the property that Path messages contain the same IP source and destination address as the data flow for which a reservation is to be established. However, since we are now making aggregate reservations by sending a Path message from an aggregating to a deaggregating router, the reserved (E2E) data packets no longer carry the same IP addresses as the relevant (aggregate) Path message. The issue becomes one of making sure that data packets for reserved flows follow the same path as the Path message that established Path state for the aggregate reservation. Several approaches are viable.
それらのデータが従うという条件がそのルートを取るので、RSVPは直接ルート変化を扱います。 これは、特性からPathメッセージが設立される予約がことであるデータフローとして同じIPソースと送付先アドレスを含むのに続きます。 しかしながら、私たちが今集合から「反-集合」ルータにPathメッセージを送ることによって集合予約をしているので、予約された(2EのE)データ・パケットはもう関連している(集合)経路メッセージと同じIPアドレスを運びません。 問題は予約された流れのためのデータ・パケットが集合予約のためにPath状態を設置したPathメッセージと同じ経路に続くのを確実にする1つになります。 いくつかのアプローチが実行可能です。
First, the data may be tunneled from aggregator to deaggregator, using technologies such as IP-in-IP tunnels, GRE tunnels, MPLS label-switched paths, and so on. These each have particular advantages, especially MPLS, which allows traffic engineering. They each also have some cost in link overhead and configuration complexity.
まず最初に、データはアグリゲータから「反-アグリゲータ」までトンネルを堀られるかもしれません、IPにおけるIPトンネルなどの技術を使用して、GREトンネル、ラベルで切り換えられた経路であって、とてもオンなMPLS。 これらには、それぞれ特定の利点、特に交通工学を許容するMPLSがあります。 また、彼らはリンクオーバーヘッドと構成の複雑さでそれぞれ何らかの費用を持っています。
Baker, et al. Standards Track [Page 10] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[10ページ]。
If data is not tunneled, then we are depending on a characteristic of IP best metric routing , which is that if the route from A to Z includes the path from H to L, and the best metric route was chosen all along the way, then the best metric route was chosen from H to L. Therefore, an aggregate path message which crosses a given aggregator and deaggregator will of necessity use the best path between them.
データがトンネルを堀られないなら、私たちはIPの最も良いメートル法のルーティングの特性に依存していて、HからLまで経路を含んでいて、ルートはHからTherefore、与えられたアグリゲータと「反-アグリゲータ」に交差する集合経路メッセージがそうするL.まで初めから終わりまで、必要な状態で最も良いのをメートル法のルートが道、その時に沿って選ばれた中でメートル法のルート最も良い選ばれた含んでいるならどれがそれであるかはそれらの間の最も良い経路を使用します。
If this is a single path, the problem is solved. If it is a multi- path route, and the paths are of equal cost, then we are forced to determine, perhaps by measurement, what proportion of the traffic for a given E2E reservation is passing along each of the paths, and assure ourselves of sufficient bandwidth for the present use. A simple, though wasteful, way of doing this is to reserve the total capacity of the aggregate route down each path.
これがただ一つの経路であるなら、問題は解決されています。 それがマルチ経路ルートであり、経路に等しい費用があるなら、私たちは恐らく測定で与えられたE2Eの予約のための交通のどんな割合がそれぞれの経路を回しているかを決定して、現在の使用のために十分な帯域幅を自分達に保証するのが強制されます。 これをする簡単で、もっとも、無駄な方法は集合ルートの総容積を各経路の下側に予約することです。
For this reason, we believe it is advantageous to use one of the above-mentioned tunneling mechanisms in cases where multiple equal- cost paths may exist.
この理由で、私たちは、複数の等しい費用経路が存在するかもしれない場合に上記のトンネリングメカニズムの1つを使用するのが有利であると信じています。
1.4.7. Inter-domain Routes
1.4.7. 相互ドメインルート
The case of inter-domain routes differs somewhat from the intra- domain case just described. Specifically, best-path considerations do not apply, as routing is by a combination of routing policy and shortest AS path rather than simple best metric.
相互ドメインルートに関するケースはただ説明されたイントラドメインケースといくらか異なっています。 明確に、最も良い経路問題は適用されません、ルーティングが簡単な最善のメートル法であるよりむしろルーティング方針と最も短いAS経路について組み合わせるとき。
In the case of inter-domain routes, data traffic belonging to different E2E sessions (but the same aggregate session) may not enter an aggregation region via the same aggregator interface, and/or may not leave via the same deaggregator interface. It is possible that we could identify this occurrence in some central system which sees the reservation information for both of the apparent sessions, but it is not clear that we could determine a priori how much traffic went one way or the other apart from measurement.
相互ドメインルートの場合では、セッション(しかし、同じ集合セッション)に2異なったEのEで属すデータ通信量は、同じアグリゲータインタフェースを通して集合領域に入らないかもしれない、またそして/または、同じ「反-アグリゲータ」インタフェースを通っていなくならないかもしれません。 私たちが見かけのセッションの両方のための予約情報を見る何らかの主要なシステムにおけるこの発生を特定できたのが、可能ですが、私たちが、どのくらいの交通が測定は別としてどちらかの方向に行ったかを先験的に決心できたのは、明確ではありません。
We simply note that this problem can occur and needs to be allowed for in the implementation. We recommend that each such E2E reservation be summed into its appropriate aggregate reservation, even though this involves over-reservation.
私たちは、この問題が、起こることができて、実現で考慮される必要に単に注意します。 これは過剰の予約にかかわりますが、私たちは、2ユーロのEの予約がそのようなそれぞれの適切な集合予約へまとめられることを勧めます。
1.4.8. Reservations for Multicast Sessions
1.4.8. マルチキャストセッションのための予約
Aggregating reservations for multicast sessions is significantly more complex than for unicast sessions. The first challenge is to construct a multicast tree for distribution of the aggregate Path messages which follows the same path as will be followed by the data packets for which the aggregate reservation is to be made. This is complicated by the fact that the path taken by a data packet may
マルチキャストセッションの予約に集めるのはユニキャストセッションよりかなり複雑です。 最初の挑戦は作られている集合予約がことであるデータ・パケットがあとに続くように同じ経路に続く集合Pathメッセージの分配のためにマルチキャスト木を組み立てることです。 データ・パケットによって取られた経路がそうするかもしれないという事実によってこれは複雑にされます。
Baker, et al. Standards Track [Page 11] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[11ページ]。
depend on many factors such as its source address, the choice of shared trees or source-specific trees, and the location of a rendezvous point for the tree.
木のためにソースアドレスや、共有された木かソース特有の木の選択や、ランデブーポイントの位置などの多くの要素に依存してください。
Once the problem of distributing aggregate Path messages is solved, there are considerable problems in determining the correct amount of resources to reserve at each link along the multicast tree. Because of the amount of heterogeneity that may exist in an aggregate multicast reservation, it appears that it would be necessary to retain information about individual E2E reservations within the aggregation region to allocate resources correctly. Thus, we may end up with a complex set of procedures for forming aggregate reservations that do not actually reduce the amount of stored state significantly for multicast sessions.
集合Pathメッセージを分配するという問題がいったん解決されていると、マルチキャスト木に沿って各リンクで予約するリソースの正しい量を測定するのにおいて相当な問題があります。 集合マルチキャストの予約で存在するかもしれない異種性の量のために、正しくリソースを割り当てるために集合領域の中で2Eの個々のE留保の情報を保有するのが必要であるように見えます。 したがって、私たちはマルチキャストセッションのために実際に格納された状態の量をかなり減少させない集合予約を結ぶための複雑なセットの手順で終わるかもしれません。
As noted above, there are several aspects to RSVP state, and our approach for unicast aggregates all forms of state: classification, scheduling, and reservation state. One possible approach to multicast is to focus only on aggregation of classification and scheduling state, which are arguably the most important because of their impact on the forwarding path. That approach is the one described in the current draft.
上で述べたように、RSVP状態へのいくつかの局面があります、そして、ユニキャストのための私たちのアプローチはすべてのフォームの状態に集められます: 分類、スケジューリング、および予約状態。 マルチキャストへの1つの可能なアプローチは分類とスケジューリング状態の集合だけに焦点を合わせることです。(状態は推進経路へのそれらの影響のために論証上最も重要です)。 そのアプローチは現在の草稿で説明されたものです。
1.4.9. Multi-level Aggregation
1.4.9. マルチレベル集合
Ideally, an aggregation scheme should be able to accommodate recursive aggregation, with aggregate reservations being themselves aggregated. Multi-level aggregation can be accomplished using the procedures described here and a simple extension to the protocol number swapping process.
理想的に、集合予約が集められている状態で、集合計画は再帰的な集合を収容できるべきです。 ここで説明された手順と単純拡大をプロトコル番号スワッピングの過程に使用することでマルチレベル集合を達成できます。
We can consider E2E RSVP reservations to be at aggregation level 0. When we aggregate these reservations, we produce reservations at aggregation level 1. In general, level n reservations may be aggregated to form reservations at level n+1.
私たちは、2ユーロのE RSVPの予約が集合レベル0にあると考えることができます。 これらの予約に集めるとき、私たちは集合レベル1で予約を作成します。 一般に、n平らな予約が、レベルnで+1に予約を結ぶために集められるかもしれません。
When an aggregating router receives an E2E Path, it swaps the protocol number from RSVP to RSVP-E2E-IGNORE. In addition, it should write the aggregation level (1, in this case) in the 2 byte field that is present (and currently unused) in the router alert option. In general, a router which aggregates reservations at level n to create reservations at level n+1 will write the number n+1 in the router alert field. A router which deaggregates level n+1 reservations will examine all messages with IP protocol number RSVP- E2E-IGNORE but will process the message and swap the protocol number back to RSVP only in the case where the router alert field carries the number n+1. For any other value, the message is forwarded unchanged. Interior routers ignore all messages with IP protocol
集合ルータがE2E Pathを受けるとき、それはRSVPから2RSVP EのE-IGNOREまでプロトコル番号を交換します。 さらに、それはルータ警戒オプションで2バイトの現在の、そして、(現在未使用)である分野に集合レベル(この場合、1)を書くべきです。 一般に、レベルnで+1に予約を作成するためにレベルnで予約に集められるルータはルータ警戒分野に数のn+1を書くでしょう。 それの「反-集合」がn+1予約を平らにするルータは、ルータ警戒分野が数のn+1を運ぶ場合だけでRSVPと2EのIPプロトコル番号RSVP E-IGNOREと共にすべてのメッセージを調べますが、メッセージを処理して、プロトコル番号を交換して戻すでしょう。 いかなる他の値においても、変わりがない状態でメッセージを転送します。 内部のルータはIPプロトコルがあるすべてのメッセージを無視します。
Baker, et al. Standards Track [Page 12] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[12ページ]。
number RSVP-E2E-IGNORE. Note that only a few bits of the 2 byte field in the option would be needed, given the likely number of levels of aggregation.
2RSVP Eの数のE-IGNORE。 オプションにおける、2バイトの分野のほんの数ビットが必要であることに注意してください、集合のレベルのありそうな数を考えて。
For IPv6, certain values of the router alert "value" field are reserved. This specification requires IANA assignment of a small number of consecutive values for the purpose of recording the aggregation level.
IPv6に関しては、ルータ警戒「値」分野のある値は予約されています。 この仕様は集合レベルを記録する目的のために少ない数の連続した値のIANA課題を必要とします。
1.4.10. Reliability Issues
1.4.10. 信頼性の問題
There are a variety of issues that arise in the context of aggregation that would benefit from some form of explicit acknowledgment mechanism for RSVP messages. For example, it is possible to configure a set of routers such that an E2E Path of protocol type RSVP-E2E-IGNORE would be effectively "black-holed", if it never reached a router which was appropriately configured to act as a deaggregator. It could then travel all the way to its destination where it would probably be ignored due to its non- standard protocol number. This situation is not easy to detect. The aggregator can be sure this problem has not occurred if an aggregate PathErr message is received from the deaggregator (as described in detail below). It can also be sure there is no problem if an E2E Resv is received. However, the fact that neither of these events has happened may only mean that no receiver wishes to reserve resources for this session, or that an RSVP message loss occurred, or it may mean that the Path was black-holed. However, if a neighbor-to- neighbor acknowledgment mechanism existed, the aggregator would expect to receive an acknowledgment of the E2E Path from the deaggregator, and would interpret the lack of a response as an indication that a problem of configuration existed. It could then refrain from aggregating this particular session. We note that such a reliability mechanism has been proposed for RSVP in [RFC291] and propose that it be used here.
RSVPメッセージのために何らかのフォームの明白な承認メカニズムの利益を得る集合の文脈に起こるさまざまな問題があります。 例えば、1セットのルータを構成するのは事実上、2プロトコルタイプRSVP EのE-IGNOREのE2E Pathが「黒で、掘られる」くらい可能です、「反-アグリゲータ」として機能するように適切に構成されたルータに決して達しなかったなら。 そして、それはそれが非標準のプロトコル番号のためたぶん無視される目的地までのいっぱいに移動できました。 この状況は検出しにくいです。 アグリゲータは「反-アグリゲータ」から集合PathErrメッセージを受け取るなら(以下で詳細に説明されるように)この問題が起こっていないのを確信している場合があります。 また、それもE2E Resvが受け取られているなら問題が全くないのを確信している場合があります。 しかしながら、これらの出来事のどちらも起こっていないという事実が、どんな受信機もこのセッションのためのリソースを予約したがっていませんし、RSVPメッセージの損失が発生もしたことを意味するだけであるかもしれませんか、またはそれは、Pathが黒によって掘られたことを意味するかもしれません。 しかしながら、隣人から隣人への承認メカニズムが存在しているなら、アグリゲータは、「反-アグリゲータ」から2EのE Pathの承認を受けると予想して、構成の問題が存在したという指示として応答の不足を解釈するでしょうに。 そして、それは、この特定のセッションに集めるのを控えるかもしれません。 私たちは、そのような信頼性のメカニズムが[RFC291]のRSVPのために提案されたことに注意して、それがここで使用されるよう提案します。
1.4.11. Message Integrity and Node Authentication
1.4.11. メッセージの保全とノード認証
[RSVP] defines a hop-by-hop authentication and integrity check. The present specification allows use of this check on Aggregate RSVP messages and also preserves this check on E2E RSVP messages for E2E RSVP messages.
[RSVP]はホップごとの認証と保全チェックを定義します。 現在の仕様は、Aggregate RSVPメッセージにおけるこのチェックの使用を許して、また、2EのE RSVPメッセージへの2EのE RSVPメッセージのこのチェックを保存します。
Outside the Aggregation Region, any E2E RSVP message may contain an INTEGRITY object using a keyed cryptographic digest technique which assumes that RSVP neighbors share a secret. Because E2E RSVP messages are not processed by routers in the Aggregation Region, the Aggregator and Deaggregator appear as logical RSVP neighbors of each other. The Deaggregator is the Aggregator's Next Hop for E2E RSVP
Aggregation Regionの外では、どんな2EのE RSVPメッセージも、RSVP隣人が秘密を共有すると仮定する合わせられた暗号のダイジェストのテクニックを使用することでINTEGRITY物を含むかもしれません。 2EのE RSVPメッセージがAggregation Regionのルータによって処理されないので、AggregatorとDeaggregatorは互いの論理的なRSVP隣人として現れます。 Deaggregatorは2EのE RSVPのためのAggregatorのNext Hopです。
Baker, et al. Standards Track [Page 13] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[13ページ]。
messages while the Aggregator is the Deaggregator's Previous Hop. Consequently, INTEGRITY objects which may appear in E2E RSVP messages traversing the Aggregation Region are exchanged directly between the Aggregator and Deaggregator in a manner which is entirely transparent to the Interior routers. Thus, hop-by-hop integrity checking for E2E messages over the Aggregation Region requires that the Aggregator and Deaggregator share a secret. Techniques for establishing that secret are described in [INTEGRITY].
Aggregatorである間、メッセージはDeaggregatorのPrevious Hopです。 その結果、AggregatorとDeaggregatorの直接間でInteriorルータに完全に見え透いた方法でAggregation Regionを横断しながら2EのE RSVPメッセージに現れるかもしれないINTEGRITY物を交換します。 したがって、ホップごとのAggregation Regionの上の2EのEメッセージがないかどうかチェックする保全は、AggregatorとDeaggregatorが秘密を共有するのを必要とします。 その秘密を確立するためのテクニックは[INTEGRITY]で説明されます。
Inside the Aggregation Region, any Aggregate RSVP message may contain an INTEGRITY object which assumes that the corresponding RSVP neighbors inside the Aggregation Region (e.g., Aggregator and Interior Router, two Interior Routers, Interior Router and Deaggregator) share a secret.
Aggregation Regionの中では、どんなAggregate RSVPメッセージもAggregation Region(例えば、Aggregator、Interior Router、2Interior Routers、Interior Router、およびDeaggregator)の中の対応するRSVP隣人が秘密を共有すると仮定するINTEGRITY物を含むかもしれません。
1.4.12. Aggregated reservations without E2E reservations
1.4.12. 2ユーロのEの予約なしで予約に集めます。
Up to this point we have assumed that the aggregate reservation is established as a result of the establishment of E2E reservations from outside the aggregation region. It should be clear that alternative triggers are possible. As discussed in [RFC2998], an aggregate RSVP reservation can be used to manage bandwidth in a diff-serv cloud even if RSVP is not used end-to-end.
この時点までに私たちは、集合予約が2ユーロのEの予約の設立の結果、集合領域の外から確立されると思いました。 代替の引き金が可能であることは、明確であるはずです。 [RFC2998]で議論するように、RSVPが中古の終わりから終わりでなくてもデフ-serv雲で帯域幅を管理するのに集合RSVPの予約を使用できます。
The simplest example of an alternative configuration is the static configuration of an aggregated reservation for a certain amount for traffic from an ingress (aggregator) router to an egress (de- aggregator) router. This would have to be configured in at least the system originating the aggregate PATH message (the aggregator). The deaggregator could detect that the PATH message is directed to it, and could be configured to "turn around" such messages, i.e., it responds with a RESV back to the aggregator. Alternatively, configuration of the aggregate reservation could be performed at both the aggregator and the deaggregator. As before, an aggregate reservation is associated with a DSCP for the traffic that will use the reserved capacity.
代替の構成の最も簡単な例はある量のイングレス(アグリゲータ)ルータから出口(反-アグリゲータ)ルータまでの交通の集められた予約の静的な構成です。 これは、集合PATHメッセージ(アグリゲータ)を溯源しながら、少なくともシステムで構成されなければならないでしょう。 「反-アグリゲータ」は検出されることができました。PATHメッセージがそのようなメッセージ、すなわち、それを「変える」ためにそれに向けて、構成できたのはRESVと共にアグリゲータに応じて戻ります。 あるいはまた、アグリゲータと「反-アグリゲータ」の両方で集合予約の構成を実行できました。 従来と同様、集合予約は予約された容量を使用する交通へのDSCPに関連しています。
In the absence of E2E microflow reservations, the aggregator can use a variety of policies to set the DSCP of packets passing into the aggregation region, thus determining whether they gain access to the resources reserved by the aggregate reservation. These policies are a matter of local configuration, as usual for a device at the edge of a diffserv cloud.
2ユーロのE microflowの予約がないとき、アグリゲータはパケットのDSCPが集合領域に入るように設定するのにさまざまな方針を使用できます、その結果、それらが集合予約で予約されたリソースへのアクセスを得るかどうか決定します。 これらの方針はdiffserv雲の縁の装置における、通常通りの地方の構成の問題です。
Baker, et al. Standards Track [Page 14] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[14ページ]。
Note that the "aggregator" could even be a device such as a PSTN gateway which makes an aggregate reservation for the set of calls to another PSTN gateway (the deaggregator) across an intervening diff- serv region. In this case the reservation may be established in response to call signalling.
「アグリゲータ」が介入しているデフserv領域の向こう側にもう1PSTN門への呼び出しのセットの(「反-アグリゲータ」)の集合予約をするPSTNゲートウェイなどの装置でさえあるかもしれないことに注意してください。 この場合、予約は呼び出し合図に対応して確立されるかもしれません。
From the perspective of RSVP signalling and the handling of data packets in the aggregation region, these cases are equivalent to the case of aggregating E2E RSVP reservations. The only difference is that E2E RSVP signalling does not take place and cannot therefore be used as a trigger, so some additional knowledge is required in setting up the aggregate reservation.
集合領域のデータ・パケットのRSVP合図と取り扱いの見解から、これらのケースは2ユーロのE RSVPの予約に集めるケースに同等です。 唯一の違いは2EのE RSVP合図は行われないで、したがって、引き金として使用できないので、何らかの追加知識が集合予約をセットアップするのにおいて必要であるということです。
2. Elements of Procedure
2. 手順のElements
To implement aggregation, we define a number of elements of procedure.
集合を実行するために、私たちは手順の多くの要素を定義します。
2.1. Receipt of E2E Path Message By Aggregating Router
2.1. ルータに集めるのによる2EのE経路メッセージの領収書
The very first event is the arrival of the E2E Path message at an exterior interface of an aggregator. Standard RSVP procedures [RSVP] are followed for this, including onto what set of interfaces the message should be forwarded. These interfaces comprise zero or more exterior interfaces and zero or more interior interfaces. (If the number of interior interfaces is zero, the router is not acting as an aggregator for this E2E flow.)
かなりの最初の出来事はアグリゲータの外のインタフェースの2EのE Pathメッセージの到着です。 標準のRSVP手順[RSVP]はメッセージが何のセットのインタフェースに転送されるべきであるかを含むこれのために従われています。 これらのインタフェースはゼロか、より外のインタフェースとゼロか、より内部のインタフェースを包括します。 (内部のインタフェースの数がゼロであるなら、ルータはこの2EのE流動のためのアグリゲータとして機能していません。)
Service on exterior interfaces is handled as defined in [RSVP].
外のインタフェースにおけるサービスは[RSVP]で定義されるように扱われます。
Service on interior interfaces is complicated by the fact that the message needs to be included in some aggregate reservation, but at this point it is not known which one, because the deaggregator is not known. Therefore, the E2E Path message is forwarded on the interior interface(s) using the IP Protocol number RSVP-E2E-IGNORE, but in every other respect identically to the way it would be sent by an RSVP router that was not performing aggregation.
メッセージが、何らかの集合予約に含まれる必要があるという事実によって内部のインタフェースにおけるサービスは複雑にされますが、ここに、それは複雑にされるというわけではありません。「反-アグリゲータ」が知られていないので、どれを知っているか。 したがって、2RSVP EのIPプロトコル番号E-IGNOREを使用しますが、同様に他のあらゆる点で集合を実行していなかったRSVPルータでそれを送るだろうという方法に転送して、内部のインタフェースで2EのE Pathメッセージを転送します。
2.2. Handling Of E2E Path Message By Interior Routers
2.2. 内部のルータによる2EのE経路メッセージの取り扱い
At this point, the E2E Path message traverses zero or more interior routers. Interior routers receive the E2E Path message on an interior interface and forward it on another interior interface. The Router Alert IP Option alerts interior routers to check internally, but they find that the IP Protocol is RSVP-E2E-IGNORE and the next hop interface is interior. As such, they simply forward it as a normal IP datagram.
ここに、2EのE Pathメッセージがゼロか、より内部のルータを横断します。 内部のルータは、内部のインタフェースに2EのE Pathメッセージを受け取って、別の内部のインタフェースでそれを進めます。 Router Alert IP Optionは、内部的にチェックするよう内部のルータに注意を促しますが、それらはIPプロトコルが2RSVP EのE-IGNOREであり、次のホップインタフェースが内部であることがわかります。 そういうものとして、彼らは正常なIPデータグラムとして単にそれを進めます。
Baker, et al. Standards Track [Page 15] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[15ページ]。
2.3. Receipt of E2E Path Message By Deaggregating Router
2.3. Deaggregatingルータによる2EのE経路メッセージの領収書
The E2E Path message finally arrives at a deaggregating router, which receives it on an interior interface and forwards it on an exterior interface. Again, the Router Alert IP Option alerts it to intercept the message, but this time the IP Protocol is RSVP-E2E-IGNORE and the next hop interface is an exterior interface.
2EのE Pathメッセージが最終的に「反-集合」ルータに到着します。(それは、内部のインタフェースでそれを受けて、外のインタフェースでそれを進めます)。 今回IPプロトコルは2RSVP EのE-IGNOREです、そして、一方、Router Alert IP Optionは、メッセージを傍受するようそれに注意を促しますが、次のホップインタフェースは外のインタフェースです。
Before forwarding the E2E Path towards the receiver, the Deaggregator should update its ADSPEC. This update is to reflect the impact of the aggregation region onto the QoS to be achieved E2E by the flow. Such information can be collected by the ADSPEC of Aggregate Path messages travelling from the Aggregator to the Deaggregator. Thus, to enable correct updating of the ADSPEC, a deaggregating router may wait as described below for the arrival of an aggregate Path before forwarding the E2E Path.
2EのE Pathを受信機に向かって送る前に、DeaggregatorはADSPECをアップデートするはずです。 このアップデートは流れによって2EのEで達成されるために集合領域の影響をQoSに反映することです。 AggregatorからDeaggregatorまで移動するAggregate PathメッセージのADSPECはそのような情報を集めることができます。 したがって、ADSPECの正しいアップデートを可能にするために、「反-集合」ルータは2EのE Pathを進める前に集合Pathの到着のために以下で説明されるように待つかもしれません。
When receiving the E2E Path, depending on the policy for mapping E2E reservation onto Aggregate Reservations, the Deaggregator may or may not be in a position to decide which DSCP the E2E flow for the processed E2E Path is going to be mapped onto, as described above. If the Deaggregator is in a position to know the mapping at this point, then the Deaggregator first checks that there is an Aggregate Path in place for the corresponding DSCP. If so, then the Deaggregator uses the ADSPEC of this Aggregate Path to update the ADSPEC of the E2E Path and then forwards the E2E Path towards the receiver. If not, then the Deaggregator requests establishment of the corresponding Aggregate Path by sending an E2E PathErr message with an error code of NEW-AGGREGATE-NEEDED and the desired DSCP encoded in the DCLASS Object. The Deaggregator may also at the same time request establishment of an aggregate reservation for other DSCPs. When receiving the Aggregate Path for the desired DSCP, the Deaggregator then uses the ADSPEC of this Aggregate Path to update the ADSPEC of the E2E Path.
2ユーロのEの予約をAggregate予約に写像するために方針によって、2EのE Pathを受けるとき、Deaggregatorが2処理EのE Pathのための2EのE流動がどのDSCPに写像されるかを決める立場にあるかもしれません、上で説明されるように。 Deaggregatorがここにマッピングを知る立場にあるなら、Deaggregatorは、最初に、Aggregate Pathが対応するDSCPのために適所にあるのをチェックします。 そうだとすれば、次に、Deaggregatorは2EのE PathのADSPECをアップデートするのにこのAggregate PathのADSPECを使用して、次に、受信機に向かってPathを2EのEで送ります。そうでなければ、次に、Deaggregatorは、NEW-AGGREGATEによって必要のエラーコードとDCLASS Objectでコード化された必要なDSCPと共にE2E PathErrメッセージを送ることによって、対応するAggregate Pathの設立を要求します。 また、Deaggregatorは同時に、他のDSCPsの集合予約の設立を要求するかもしれません。 必要なDSCPのためにAggregate Pathを受けると、Deaggregatorは、2EのE PathのADSPECをアップデートするのにこのAggregate PathのADSPECを使用します。
If the Deaggregator is not in a position to know the mapping at this point, then the Deaggregator uses the information contained in the ADSPEC of one Aggregate Path or of multiple Aggregate Paths to update the E2E Path ADSPEC. Similarly, if one or more of the necessary Aggregate Paths is not yet established, the Deaggregator requests establishment of the corresponding Aggregate Path by sending an E2E PathErr message with an error code of NEW-AGGREGATE-NEEDED and the desired DSCP encoded in the respective DCLASS Object. When receiving the Aggregate Path for the desired DSCP, the Deaggregator then uses the ADSPEC of this Aggregate Path to update the ADSPEC of the E2E Path.
Deaggregatorがここにマッピングを知る立場にないなら、Deaggregatorは2EのE Path ADSPECをアップデートするために1Aggregate Pathか複数のAggregate PathsのADSPECに含まれた情報を使用します。 同様に、必要なAggregate Pathsの1つ以上がまだ設立されていないなら、Deaggregatorは、NEW-AGGREGATEによって必要のエラーコードとそれぞれのDCLASS Objectでコード化された必要なDSCPと共にE2E PathErrメッセージを送ることによって、対応するAggregate Pathの設立を要求します。 必要なDSCPのためにAggregate Pathを受けると、Deaggregatorは、2EのE PathのADSPECをアップデートするのにこのAggregate PathのADSPECを使用します。
Baker, et al. Standards Track [Page 16] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[16ページ]。
Generating a E2E PathErr message with an error code of NEW- AGGREGATE-NEEDED should not result in any Path state being removed, but should result in the aggregating router initiating the necessary aggregate Path message, as described in the following section.
NEW- AGGREGATEによって必要のエラーコードでE2E PathErrメッセージを発生させると、取り除かれる少しのPath状態ももたらされるべきではありませんが、必要な集合Pathメッセージを開始する集合ルータはもたらされるべきです、以下のセクションで説明されるように。
The deaggregating router changes the E2E Path message's IP Protocol from RSVP-E2E-IGNORE to RSVP and forwards the E2E Path message towards its intended destination.
「反-集合」ルータは、2EのE PathメッセージのIPプロトコルを2RSVP EのE-IGNOREからRSVPに変えて、2EのE Pathメッセージを意図している目的地に向かって転送します。
2.4. Initiation of New Aggregate Path Message By Aggregating Router
2.4. ルータに集めるのによる新しい集合経路メッセージの開始
The aggregating Router is responsible for generating a new Aggregate Path for a DSCP when receiving a E2E PathErr message with the error code NEW-AGGREGATE-NEEDED from the deaggregator. The DSCP value to include in the Aggregate Path Session is found in the DCLASS Object of the received E2E PathErr message. The identity of the deaggregator itself is found in the ERROR SPECIFICATION of the E2E PathErr message. The destination address of the aggregate Path message is the address of the deaggregating router, and the message is sent with IP protocol number RSVP.
集合Routerはコードが「反-アグリゲータ」からNEW-AGGREGATE必要とした誤りでE2E PathErrメッセージを受け取るときDSCPのために新しいAggregate Pathを発生させるのに責任があります。 Aggregate Path Sessionに含んでいるDSCP値は2容認されたEのE PathErrメッセージのDCLASS Objectで見つけられます。 「反-アグリゲータ」自身のアイデンティティは2EのE PathErrメッセージのERROR SPECIFICATIONで見つけられます。 集合Pathメッセージの送付先アドレスは「反-集合」ルータのアドレスです、そして、IPプロトコル番号RSVPと共にメッセージを送ります。
Existing RSVP procedures specify that the size of a reservation established for a flow is set to the minimum of the Path SENDER_TSPEC and the Resv FLOW_SPEC. Consequently, the size of an Aggregate Reservation cannot be larger than the SENDER_TSPEC included in the Aggregate Path by the Aggregator. To ensure that Aggregate Reservations can be sized by the Deaggregator without undesired limitations, the Aggregating router should always attempt to include in the Aggregate Path a SENDER_TSPEC which is at least as large as the size that would actually be required as determined by the Deaggregator. One method to achieve this is to use a SENDER_TSPEC which is obviously larger than the highest load of E2E reservations that may be supported onto this network. Another method is for the Aggregator to keep track of which flows are mapped onto a DSCP and always add their E2E Path SENDER_TSPEC into the Aggregate Path SENDER_TSPEC (and possibly also add some additional bandwidth in anticipation of future E2E reservations).
既存のRSVP手順は、流れのために確立された予約のサイズがPath SENDER_TSPECとResv FLOW_SPECの最小限に設定されると指定します。 その結果、Aggregate予約のサイズはAggregate PathにAggregatorでSENDER_TSPECを含んでいるより大きいはずがありません。 Deaggregatorが望まれない制限なしでAggregate予約を大きさで分けることができるのを保証するために、Aggregatingルータは、いつもAggregate PathにDeaggregatorによって決定されるように実際に必要であるサイズと少なくとも同じくらい大きいSENDER_TSPECを含んでいるのを試みるべきです。 これを達成する1つの方法はこのネットワークに支持されるかもしれない2ユーロのEの予約の最も高い負荷より明らかに大きいSENDER_TSPECを使用することです。 流れがDSCPに写像されて、それらの2EのE Path SENDER_TSPECをAggregate Path SENDER_TSPECにいつも加える別の方法は、Aggregatorが動向をおさえる(ことによるとまた、2Eの今後のEの予約を予測していくらかの追加帯域幅を加えてください)ことです。
The aggregating router is notified of the mapping from an E2E flow to a DSCP in two ways. First, when the aggregating router receives a E2E PathErr with error code NEW-AGGREGATE-NEEDED, the Aggregator is notified that the corresponding E2E flow is (at least temporarily) mapped onto a given DSCP. Secondly, when the aggregating router receives an E2E Resv containing a DCLASS Object (as described further below), the Aggregating Router is notified that the corresponding E2E flow is mapped onto a given DSCP.
集合ルータはマッピングについてE2E流動からDSCPまで2つの方法で通知されます。 NEW-AGGREGATEが必要な状態で集合ルータがエラーコードでE2E PathErrを受けるとき、まず最初に、Aggregatorに2対応するEのE流動が与えられたDSCPに写像されるように(少なくとも一時)通知されます。 集合ルータがDCLASS Objectを含むE2E Resvを受けるとき(以下でさらに説明されるように)、第二に、Aggregating Routerは2対応するEのE流動が与えられたDSCPに写像されるように通知されます。
Baker, et al. Standards Track [Page 17] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[17ページ]。
2.5. Handling of E2E Resv Message by Deaggregating Router
2.5. Deaggregatingルータによる2EのE Resvメッセージの取り扱い
Having sent the E2E Path message on toward the destination, the deaggregator must now expect to receive an E2E Resv for the session. On receipt, its responsibility is to ensure that there is sufficient bandwidth reserved within the aggregation region to support the new E2E reservation, and if there is, then to forward the E2E Resv to the aggregating router.
目的地に向かってオンな2EのE Pathメッセージを送ったので、「反-アグリゲータ」は、現在、セッションのためにE2E Resvを受け取ると予想しなければなりません。 領収書の上では、責任は新しい2ユーロのEの予約を支持するために集合領域の中で予約されて、そして、フォワードに集合ルータへの2EのE Resvがあれば十分な帯域幅があるのを保証することです。
The Deaggregating router first makes the final decision of which Aggregate Reservation (and thus which DSCP) this E2E reservation is to be mapped onto. This decision is made according to the policy selected by the network administrator as described above.
Deaggregatingルータは最初に、どのAggregate予約(そして、その結果、どのDSCP)に写像されるかに関するこの2ユーロのEの予約がことである最終決定をします。 上で説明されるようにネットワーク管理者によって選択された方針によると、この決定をします。
If this final mapping decision is such that the Deaggregator can now make a more accurate update of the E2E Path ADSPEC than done when forwarding the initial E2E Path, the Deaggregator should do so and generate a new E2E Path immediately in order to provide the accurate ADSPEC information to the receiver as soon as possible. Otherwise, normal Refresh procedures should be followed for the E2E Path.
この最終的なマッピング決定がDeaggregatorが今E2つのものの、より正確なアップデートをE Path ADSPECにすることができるようにものであるなら、Deaggregatorは、すぐに、できるだけ早く正確なADSPEC情報を受信機に供給するために2初期のEのE Pathを進めるとき、するより2EのPathをそうして、新しいEで発生させるはずです。 さもなければ、正常なRefresh手順は2EのE Pathのために従われるべきです。
If no Aggregate Reservation currently exists from the corresponding aggregating router with the corresponding DSCP, the Deaggregating router will establish a new Aggregate Reservation as described in the next section.
Aggregate予約が全く現在対応するDSCPと共に対応する集合ルータから存在しないと、Deaggregatingルータは次のセクションで説明されるように新しいAggregate予約を確立するでしょう。
If the corresponding Aggregate Reservation exists but has insufficient bandwidth reserved to accommodate the new E2E reservation (in addition to all the existing E2E reservations currently mapped onto it), it should follow the normal RSVP procedures [RSVP] for a reservation being placed with insufficient bandwidth to support the reservation. It may also first attempt to increase the aggregate reservation that is supplying bandwidth by increasing the size of the FLOW_SPEC that it includes in the aggregate Resv that it sends upstream. As discussed in the previous section, the Aggregating Router should ensure that the SENDER_TSPEC it includes in the Aggregate Path is always in excess of the FLOW_SPEC that may be requested in the Aggregate Resv by the Deaggregator, so that the Deaggregator is not unnecessarily prevented from effectively increasing the Aggregate Reservation bandwidth as required.
対応するAggregate予約で存在していますが、新しい2ユーロのE条件(現在それに写像されているすべての既存の2ユーロのEの予約に加えた)を収容するために不十分な帯域幅を控えるなら、予約を支持すると、不十分な帯域幅に置かれる予約のための正常なRSVP手順[RSVP]は従われるべきです。 また、それは、最初に、それが上流へ送る集合Resvに含んでいるFLOW_SPECのサイズを増加させることによって帯域幅を供給している集合予約を増加させるのを試みるかもしれません。 前項で議論するように、Aggregating Routerは、それがAggregate Pathに含むSENDER_TSPECがいつもAggregate ResvでDeaggregatorによって要求されているかもしれないFLOW_SPECを超えているのを確実にするはずです、Deaggregatorが必要に応じてAggregate予約帯域幅を不必要に事実上増加させてもよいように。
When sufficient bandwidth is available on the corresponding aggregate reservation, the Deaggregating Router may simply send the E2E Resv message with IP Protocol RSVP to the aggregating router. This message should include the DCLASS object to indicate which DSCP the aggregator must use for this E2E flow. The deaggregator will also
十分な帯域幅が対応する集合予約で利用可能であるときに、Deaggregating Routerは単にIPプロトコルRSVPがある2EのE Resvメッセージを集合ルータに送るかもしれません。 このメッセージは、アグリゲータがこの2EのE流動にどのDSCPを使用しなければならないかを示すためにDCLASS物を含むべきです。 また、「反-アグリゲータ」はそうするでしょう。
Baker, et al. Standards Track [Page 18] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[18ページ]。
add the token bucket from the E2E Resv FLOWSPEC object into its internal understanding of how much of the Aggregate reservation is in use.
2EのE Resv FLOWSPEC物からAggregateの予約のいくらが使用中であるかに関する内部の理解に象徴バケツを加えてください。
As discussed above, in order to minimize the occurrence of situations where insufficient bandwidth is reserved on the corresponding Aggregate Reservation at the time of processing an E2E Resv, and in turn to avoid the delay associated with the increase of this aggregate bandwidth, the Deaggregator MAY anticipate the current demand and increase the Aggregate Reservations size ahead of actual requirements by E2E reservations.
上で議論するように、Deaggregatorは不十分な帯域幅がこの集合帯域幅の増加に関連している遅れを避けるためにE2E Resvを処理する時点の対応するAggregate予約に、順番に控えられる状況の発生を最小にするために2ユーロのEの予約で経常需要を予期して、実需の前にAggregate予約サイズを増加させるかもしれません。
2.6. Initiation of New Aggregate Resv Message By Deaggregating Router
2.6. Deaggregatingルータによる新しい集合Resvメッセージの開始
Upon receiving an E2E Resv message on an exterior interface, and having determined the appropriate DSCP for the session according to the mapping policy, the Deaggregator looks for the corresponding path state for a session with the chosen DSCP. If aggregate Path state exists, but no aggregate Resv state exists, the Deaggregator creates a new aggregate Resv.
外のインタフェースにE2E Resvメッセージを受け取って、マッピング方針によると、セッションのために適切なDSCPを決定したとき、Deaggregatorは選ばれたDSCPとのセッションのために対応する経路州を探します。 集合Path状態が存在していますが、どんな集合Resv状態も存在していないなら、Deaggregatorが新しい集合Resvを作成します。
If no aggregate Path state exists for the appropriate DSCP, this may be because the Deaggregator could not decide earlier the final mapping for this E2E flow and elected to not establish Aggregate Path state for all DSCPs. In that case, the Deaggregator should request establishment of the corresponding Aggregate Path by sending a E2E PathErr with error code of NEW-AGGREGATE-NEEDED and with a DCLASS containing the required DSCP. This will trigger the Aggregator to establish the corresponding Aggregate Path. Once the Deaggregator has determined that the aggregate Path state is established, it creates a new Aggregate Resv.
どんな集合Path状態も適切なDSCPのために存在していないならこれはDeaggregatorが、より早くこの2EのE流動のための最終的なマッピングについて決めることができないで、すべてのDSCPsのためにAggregate Path状態を設置しないのを選んだからです。 その場合、Deaggregatorは、NEW-AGGREGATEによって必要のエラーコードとDCLASSが必要なDSCPを含んでいるE2E PathErrを送ることによって、対応するAggregate Pathの設立を要求するはずです。 これは対応するAggregate Pathを設立するAggregatorの引き金となるでしょう。 Deaggregatorが、集合Path状態が設置されることをいったん決定すると、それは新しいAggregate Resvを作成します。
The FLOW_SPEC of the new Aggregate Resv is set to a value not smaller than the requirement of the E2E reservation it is supporting. The Aggregate Resv is sent toward the aggregator (i.e., to the previous hop), using the AGGREGATED-RSVP session and filter specifications defined below. Since the DSCP is in the SESSION object, no DCLASS object is necessary. The message should be reliably delivered using the mechanisms in [RFC2961] or, alternatively, the CONFIRM object may be used, to assure that the aggregate Resv does indeed arrive and is granted. This enables the deaggregator to determine that the requested bandwidth is available to allocate to the E2E flows it supports.
新しいAggregate ResvのFLOW_SPECはそれが支持している2ユーロのEの予約の要件ほど小さくない値に用意ができています。 アグリゲータ(すなわち、前のホップへの)に向かってAggregate Resvを送ります、以下で定義されたAGGREGATED-RSVPセッションとフィルタ仕様を使用して。 DSCPがSESSION物にあるので、どんなDCLASS物も必要ではありません。 [RFC2961]のメカニズムを使用することでメッセージを確かに送るべきであるか、あるいはまた、CONFIRM物を本当に、集合Resvが到着することを保証するのに使用するかもしれなくて、与えます。 これは、「反-アグリゲータ」が、要求された帯域幅がそれが支持する2EのE流れに割り当てるために利用可能であることを決定するのを可能にします。
In order to minimize the occurrence of situations where no corresponding Aggregate Reservation is established at the time of processing an E2E Resv, and in turn to avoid the delay associated with the creation of this aggregate reservation, the Deaggregator MAY
対応していないところで状況の発生を最小にするために、この集合予約の創造に関連している遅れを避けるために順番にE2E Resvを処理する時点でAggregate予約は確立されます、Deaggregator5月
Baker, et al. Standards Track [Page 19] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[19ページ]。
anticipate the current demand and create the Aggregate Reservation before receiving E2E Resv messages requiring bandwidth on those aggregate reservations.
経常需要を予期してください、そして、帯域幅を必要とする2EのE Resvメッセージを受け取る前に、それらの集合予約にAggregate予約を作成してください。
2.7. Handling of Aggregate Resv Message by Interior Routers
2.7. 内部のルータによる集合Resvメッセージの取り扱い
The aggregate Resv message is handled in essentially the same way as defined in [RSVP]. The Session object contains the address of the deaggregating router (or the group address for the session in the case of multicast) and the DSCP that has been chosen for the session. The Filterspec object identifies the aggregating router. These routers perform admission control and resource allocation as usual and send the aggregate Resv on towards the aggregator.
集合Resvメッセージは本質的には[RSVP]で定義されるのと同じように扱われます。 Session物は「反-集合」ルータ(または、マルチキャストの場合におけるセッションのためのグループアドレス)とセッションのために選ばれたDSCPのアドレスを含んでいます。 Filterspec物は集合ルータを特定します。 これらのルータは、入場コントロールと通常通りの資源配分を実行して、アグリゲータに向かってオンな集合Resvを送ります。
2.8. Handling of E2E Resv Message by Aggregating Router
2.8. ルータに集めるのによる2EのE Resvメッセージの取り扱い
The receipt of the E2E Resv message with a DCLASS Object is the final confirmation to the aggregating router of the mapping of the E2E reservation onto an Aggregate Reservation. Under normal circumstances, this is the only way it will be informed of this association. It should now forward the E2E Resv to its previous hop, following normal RSVP processing rules [RSVP].
DCLASS Objectがある2EのE Resvメッセージの領収書はAggregate予約への2ユーロのEの予約に関するマッピングの集合ルータへの終検です。 通常の状況下で、これはこの協会で知識があるようになる唯一の方法です。 正常なRSVP処理規則[RSVP]に従って、それは現在、前のホップに2EのE Resv転送するべきです。
2.9. Removal of E2E Reservation
2.9. 2ユーロのE予約の取り外し
E2E reservations are removed in the usual way via PathTear, ResvTear, timeout, or as the result of an error condition. When they are removed, their FLOWSPEC information must also be removed from the allocated portion of the aggregate reservation. This same bandwidth may be re-used for other traffic in the near future. When E2E Path messages are removed, their SENDER_TSPEC information must also be removed from the aggregate Path.
2ユーロのEの予約を取り除く、不断のとおりPathTear、ResvTear、タイムアウトを通してエラー条件の結果 また、それらを取り除くとき、集合予約の割り当てられた部分からそれらのFLOWSPEC情報を取り除かなければなりません。 この同じ帯域幅は近い将来の他の交通に再使用されるかもしれません。 また、2EのE Pathメッセージが取り除かれるとき、集合PathからそれらのSENDER_TSPEC情報を取り除かなければなりません。
2.10. Removal of Aggregate Reservation
2.10. 集合予約の取り外し
Should an aggregate reservation go away (presumably due to a configuration change, route change, or policy event), the E2E reservations it supports are no longer active. They must be treated accordingly.
集合予約が遠ざかるなら(おそらく、構成変更、ルート変化、または方針イベントのため)、それが支持する2ユーロのEの予約はもう活発ではありません。 それに従って、それらを扱わなければなりません。
2.11. Handling of Data On Reserved E2E Flow by Aggregating Router
2.11. ルータに集めるのによる2予約されたEのE流動におけるデータの取り扱い
Prior to establishment that a given E2E flow is part of a given aggregate, the flow's data should be treated as traffic without a reservation by whatever policies prevail for such. Generally, this will mean being given the same forwarding behavior as best effort traffic. However, upon establishing that the flow belongs to a given aggregate, the aggregating router is responsible for marking any
設立の前に与えられた2E Eが流れるのが、与えられた集合の一部である、流れのデータは予約なしで交通としてそのようなもののために広がっているどんな方針でも扱われるべきです。 一般に、これは、ベストエフォート型交通と同じ推進の振舞いが与えられていることを意味するでしょう。 しかしながら、流れが与えられた集合に属すのを確証するとき、集合ルータはいずれもマークするのに原因となります。
Baker, et al. Standards Track [Page 20] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[20ページ]。
related traffic with the correct DSCP and forwarding it in the manner appropriate to traffic on that reservation. This may imply forwarding it to a given IP next hop, or piping it down a given link layer circuit, tunnel, or MPLS label switched path.
正しいDSCPとの関連する交通とその予約における交通に適切な方法でそれを進めること。 これが、次に与えられたIPにそれを送って、跳ぶように含意するかもしれませんか、または与えられたリンクレイヤサーキット、トンネル、またはMPLSラベルの下側にそれを運ぶのは経路を切り換えました。
The aggregator is responsible for performing per-reservation policing on the E2E flows that it is aggregating. The aggregator performs metering of traffic belonging to each reservation to assess compliance to the token bucket for the corresponding E2E reservation. Packets which are assessed in compliance are forwarded as mentioned above. Packets which are assessed out of compliance must be either dropped, reshaped or marked to a different DSCP. The detailed policing behavior is an aspect of the service mapping described in [RFC2998].
アグリゲータは2EのEでそれが集めている流れを取り締まりながら予約を実行するのに責任があります。 アグリゲータは、交通が対応する2ユーロのEの予約のための象徴バケツにコンプライアンスを評価するために各予約に属すのを計量しながら、働きます。 以上のように承諾で評価されるパケットを進めます。 承諾から評価されるパケットを、異なったDSCPに落とされなければならないか、造り直されなければならないか、またはマークしなければなりません。 詳細な取り締まりの振舞いは[RFC2998]で説明されたサービス対応表の局面です。
2.12. Procedures for Multicast Sessions
2.12. マルチキャストセッションのための手順
Because of the difficulties of aggregating multicast sessions described above, we focus on the aggregation of scheduling and classification state in the multicast case. The main difference between the multicast and unicast cases is that rather than sending an aggregate Path message to the unicast address of a single deaggregating router, in the multicast case we send the "aggregate" Path message to the same group address as the E2E session. This ensures that the aggregate Path message follows the same route as the E2E Path. This difference between unicast and multicast is reflected in the Session objects defined below. A consequence of this approach is that we continue to have reservation state per multicast session inside the aggregation region.
上で説明されたマルチキャストセッションを集めるという困難のために、私たちはマルチキャスト場合における、スケジューリングと分類状態の集合に焦点を合わせます。 マルチキャストとユニキャストケースの主な違いはただ一つの「反-集合」ルータのユニキャストアドレスに集合Pathメッセージを送るよりむしろ、私たちがマルチキャスト場合では、2ユーロのEセッションと同じグループアドレスに「集合」のPathメッセージを送るということです。 これは、集合Pathメッセージが2EのE Pathと同じルートに従うのを確実にします。 ユニキャストとマルチキャストのこの違いは以下で定義されたSession物に反映されます。 このアプローチの結果は私たちが、集合領域の中にマルチキャストセッションあたりの予約状態を持ち続けているということです。
A further challenge arises in multicast sessions with heterogeneous receivers. Consider an interior router which must forward packets for a multicast session on two interfaces, but has only received a reservation request on one of those interfaces. It receives packets marked with the DSCP chosen for the aggregate reservation. When sending them out the interface which has no installed reservation, it has the following options:
さらなる挑戦は異種の受信機とのマルチキャストセッションのときに起こります。 マルチキャストセッションのために2つのインタフェースでパケットを進めなければなりませんが、それらのインタフェースの1つに予約の要請を受け取るだけであった内部のルータを考えてください。 それはDSCPが集合予約に選ばれている状態でマークされたパケットを受けます。 それには、それらを出すとき、いいえを持っているインタフェースは予約をインストールして、以下のオプションがあります:
a) remark those packets to best effort before sending them out the
interface;
a) インタフェースからそれらを送る前に、ベストエフォート型にそれらのパケットを述べさせてください。
b) send the packets out the interface with the DSCP chosen for the
aggregate reservation.
b) 集合予約に選ばれているDSCPとのインタフェースからパケットを送ってください。
The first approach suffers from the drawback that it requires nMF classification at an interior router in order to recognize the flows whose packets must be demoted. The second approach requires over- reservation of resources on the interface on which no reservation was
最初のアプローチは欠点に苦しみます。それは、パケットを格下げしなければならない流れを認識するために内部のルータでnMF分類を必要とします。 2番目のアプローチはインタフェースにおける予約がないのがそうであったリソースの過剰の予約を必要とします。
Baker, et al. Standards Track [Page 21] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[21ページ]。
received. In the absence of such over-reservation, the packets sent with the "wrong" DSCP would be able to degrade the service experienced by packets using that DSCP legitimately.
受け取られている。 そのような過剰の予約がないとき、「間違った」DSCPと共に送られたパケットはパケットによって合法的にそのDSCPを使用することで経験されたサービスを下がらせることができるでしょう。
To make MF classification acceptable in an interior router, it may be possible to treat the case of heterogeneous flows as an exception. That is, an interior router only needs to be able to recognize those individual microflows that have heterogeneous resource needs on the outbound interfaces of this router.
MF分類を内部のルータで許容できるようにするように、異種の流れに関するケースを例外として扱うのは可能であるかもしれません。 すなわち、内部のルータは、このルータの外国行きのインタフェースに異種のリソースの必要性を持っているそれらの個々のmicroflowsを認識できる必要があるだけです。
3. Protocol Elements
3. プロトコル要素
3.1. IP Protocol RSVP-E2E-IGNORE
3.1. RSVP-E2E-が無視するIPプロトコル
This specification requires the assignment of a protocol type RSVP- E2E-IGNORE, whose number is at this point 134. This is used only on E2E messages which require a router alert (Path, PathTear, and ResvConf), and signifies that the message must be treated one way when destined to an interior interface, and another way when destined to an exterior interface. The protocol type is swapped by the Aggregator from RSVP to RSVP-E2E-IGNORE in E2E Path, PathTear, and ResvConf messages when they enter the Aggregation Region. The protocol type is swapped back by the Deaggregator from RSVP-E2E- IGNORE to RSVP in such E2E messages when they exit the Aggregation Region.
この仕様は134にプロトコルタイプRSVP2EのE-IGNOREの課題を必要とします。(ここにIGNOREの番号はことです)。 これは、内部のインタフェースにルータ警戒(経路、PathTear、およびResvConf)を必要とする2EのEメッセージだけで使用されて、運命づけられていると1つの方法でメッセージを扱わなければならないのを意味して、外のインタフェースに運命づけられていると、別の方法で意味します。 Aggregation Regionに入るとき、プロトコルタイプは2EのE Path、PathTear、およびResvConfメッセージでRSVPから2RSVP EのE-IGNOREまでAggregatorによって交換されます。 Aggregation Regionを出るとき、プロトコルタイプはそのような2EのEメッセージで2RSVP EのE-IGNOREからRSVPまでDeaggregatorによって交換されます。
3.2. Path Error Code
3.2. 経路エラーコード
A PathErr code NEW-AGGREGATE-NEEDED is required. This value does not signify that a fatal error has occurred, but that an action is required of the aggregating router to avoid an error condition in the near future.
PathErrコードがNEW-AGGREGATE必要であった、必要です。 この値は、致命的な誤りが発生しましたが、集合ルータが近い将来エラー条件を避けるために動作に要求されるのを意味しません。
3.3. SESSION Object
3.3. セッション物
The SESSION object contains two values: the IP Address of the aggregate session destination, and the DSCP that it will use on the E2E data the reservation contains. For unicast sessions, the session destination address is the address of the deaggregating router. For multicast sessions, the session destination is the multicast address of the E2E session (or sessions) being aggregated. The inclusion of the DSCP in the session allows for multiple sessions toward the same address to be distinguished by their DSCP and queued separately. It also provides the means for aggregating scheduling and classification state. In the case where a session uses a pair of PHBs (e.g., AF11 and AF12), the DSCP used should represent the numerically smallest PHB (e.g., AF11). This follows the same naming convention described in [BRIM].
SESSION物は2つの値を含んでいます: 集合セッションの目的地のIP Address、およびそれが予約が含む2EのEデータで使用するDSCP。 ユニキャストセッションのために、セッション送付先アドレスは「反-集合」ルータのアドレスです。 マルチキャストセッションのために、セッションの目的地は集められる2ユーロのEセッション(または、セッション)のマルチキャストアドレスです。 セッションにおける、DSCPの包含は、同じアドレスに向かった複数のセッションがそれらのDSCPによって区別されて、別々に列に並ばせられるのを許容します。 また、それはスケジューリングに集めて、分類状態に手段を提供します。 セッションが1組のPHBs(例えば、AF11とAF12)を使用する場合では、使用されるDSCPは数の上で最も小さいPHB(例えば、AF11)を表すはずです。 これは[BRIM]で説明された同じ命名規則に続きます。
Baker, et al. Standards Track [Page 22] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[22ページ]。
Session types are defined for IPv4 and IPv6 addresses.
セッションタイプはIPv4とIPv6アドレスのために定義されます。
o IP4 SESSION object: Class = SESSION,
C-Type = RSVP-AGGREGATE-IP4
o IP4 SESSIONは反対します: RSVPの集合クラス=セッション、C-タイプ=IP4
+-------------+-------------+-------------+-------------+
| IPv4 Session Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| /////////// | Flags | ///////// | DSCP |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+ | IPv4 Session Address(4バイト)| +-------------+-------------+-------------+-------------+ | /////////// | 旗| ///////// | DSCP| +-------------+-------------+-------------+-------------+
o IP6 SESSION object: Class = SESSION,
C-Type = RSVP-AGGREGATE-IP6
o IP6 SESSIONは反対します: RSVPの集合クラス=セッション、C-タイプ=IP6
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Session Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| /////////// | Flags | ///////// | DSCP |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+ | | + + | | + IPv6 Session Address(16バイト)+| | + + | | +-------------+-------------+-------------+-------------+ | /////////// | 旗| ///////// | DSCP| +-------------+-------------+-------------+-------------+
3.4. SENDER_TEMPLATE Object
3.4. 送付者_テンプレート物
The SENDER_TEMPLATE object identifies the aggregating router for the aggregate reservation.
SENDER_TEMPLATE物は集合予約のために集合ルータを特定します。
o IP4 SENDER_TEMPLATE object: Class = SENDER_TEMPLATE,
C-Type = RSVP-AGGREGATE-IP4
o IP4 SENDER_TEMPLATEは反対します: RSVPの集合クラス=送付者_テンプレート、C-タイプ=IP4
+-------------+-------------+-------------+-------------+
| IPv4 Aggregator Address (4 bytes) |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+ | IPv4 Aggregator Address(4バイト)| +-------------+-------------+-------------+-------------+
Baker, et al. Standards Track [Page 23] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[23ページ]。
o IP6 SENDER_TEMPLATE object: Class = SENDER_TEMPLATE,
C-Type = RSVP-AGGREGATE-IP6
o IP6 SENDER_TEMPLATEは反対します: RSVPの集合クラス=送付者_テンプレート、C-タイプ=IP6
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Aggregator Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+ | | + + | | + IPv6 Aggregator Address(16バイト)+| | + + | | +-------------+-------------+-------------+-------------+
3.5. FILTER_SPEC Object
3.5. フィルタ_仕様物
The FILTER_SPEC object identifies the aggregating router for the aggregate reservation, and is syntactically identical to the SENDER_TEMPLATE object.
FILTER_SPEC物は、集合予約のために集合ルータを特定して、シンタクス上SENDER_TEMPLATE物と同じです。
4. Policies and Algorithms For Predictive Management Of Blocks Of
Bandwidth
4. ブロックの帯域幅の予言の管理のための方針とアルゴリズム
The exact policies used in determining how much bandwidth should be allocated to an aggregate reservation at any given time are beyond the scope of this document, and may be proprietary to the service provider in question. However, here we explore some of the issues and suggest approaches.
どのくらいの帯域幅がその時々で集合予約に割り当てられるべきであるかを決定する際に使用される正確な方針は、このドキュメントの範囲を超えていて、問題のサービスプロバイダーに独占であるかもしれません。 しかしながら、ここで、私たちは、問題のいくつかを探って、アプローチを勧めます。
In short, the ideal condition is that the aggregate reservation always has enough resources to allocate to any E2E reservation that requires its support, and never takes too much. Simply stated, but more difficult to achieve. Factors that come into account include significant times in the diurnal cycle: one may find that a large number of people start placing calls at 8:00 AM, even though the hour from 7:00 to 8:00 is dead calm. They also include recent history: if more people have been placing calls recently than have been finishing them, a prediction of the necessary bandwidth a few moments hence may call for more bandwidth than is currently allocated. Likewise, at the end of a busy period, we may find that the trend calls for declining reservation amounts.
要するに、理想的な状態は集合予約にはサポートを必要として、決して適量を過ごさないどんな2ユーロのEの予約にも割り当てることができるくらいのリソースがいつもあるということです。 単に述べられていますが、達成するのは、より難しいです。 アカウントに入る要素が概日周期に重要な回を含んでいます: ものによって、多くの人々が電話を午前8時にし始めるのがわかるかもしれません、7:00〜8:00までの時間は静穏ですが。 また、彼らは最近の歴史を含んでいます: より多くの人々が最近それらを終えているより電話をしているなら、したがって、必要な帯域幅少しの間の予測は現在割り当てるよりさらに多くの帯域幅を求めるかもしれません。 同様に、忙しい期間の終わりに、私たちは、傾向が、予約量を低下させるように求めるのがわかったかもしれません。
We recommend a policy something along this line. At any given time, one should expect that the amount of bandwidth required for the aggregate reservation is the larger of the following:
私たちはこの線に沿って何かを方針に推薦します。 その時々で、以下において集合予約に必要である帯域幅の量が多く以上であると予想するべきです:
(a) a requirement known a priori, such as from history of the diurnal
cycle at a particular week day and time of day, and
そして(a) 歴史などのように先験的に事項週の概日周期日、時刻に知られている要件。
Baker, et al. Standards Track [Page 24] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[24ページ]。
(b) the trend line over recent history, with 90 or 99% statistical
confidence.
(b) 90%か99%の統計的な自信を伴う最近の歴史の間の傾向線。
We further expect that changes to that aggregate reservation would be made no more often than every few minutes, and ideally perhaps on larger granularity such as fifteen minute intervals or hourly. The finer the granularity, the greater the level of signaling required, while the coarser the granularity, the greater the chance for error, and the need to recover from that error.
私たちは、15分の間隔や1時間ごとであることのようにその集合予約への変更が恐らくあらゆる数分と、理想的により大きい粒状よりさらにないしばしば行われるとさらに予想します。 粒状がすばらしければすばらしいほど、シグナリングのレベルが必要ですが、粒状が粗ければ粗いほど、すばらしければすばらしいほど、誤りのための機会、およびその誤りから克服する必要性は、より大きいです。
In general, we expect that the aggregate reservation will not ever add up to exactly the sum of the reservations it supports, but rather will be an integer multiple of some block reservation size, which exceeds that value.
一般に、むしろ何らかのブロック予約サイズ(その値を超えている)の整数倍数であるのを除いて、私たちは、集合予約がまさにそれが支持する予約の合計を意味しないと予想します。
5. Security Considerations
5. セキュリティ問題
Numerous security issues pertain to this document; for example, the loss of an aggregate reservation to an aggressor causes many calls to operate unreserved, and the reservation of a great excess of bandwidth may result in a denial of service. However, these issues are not confined to this extension: RSVP itself has them. We believe that the security mechanisms in RSVP address these issues as well.
多数の安全保障問題はこのドキュメントに関係します。 例えば、侵略者への集合予約の損失は無遠慮な状態で作動するという多くの要求を引き起こします、そして、帯域幅のすばらしい過剰の予約はサービスの否定をもたらすかもしれません。 しかしながら、これらの問題はこの拡大に閉じ込められません: RSVP自身には、彼らがいます。 私たちは、RSVPのセキュリティー対策がまた、これらの問題を記述すると信じています。
One security issue specific to RSVP aggregation involves the modification of the IP protocol number in RSVP Path messages that traverse an aggregation region. If that field were maliciously modified in a Path message, it would cause the message to be ignored by all subsequent devices on its path, preventing reservations from being made. It could even be possible to correct the value before it reached the receiver, making it difficult to detect the attack. In theory, it might also be possible for a node to modify the IP protocol number for non-RSVP messages as well, thus interfering with the operation of other protocols.
RSVP集合に特定の1つの安全保障問題が集合領域を横断するRSVP Pathメッセージにおける、IPプロトコル番号の変更にかかわります。 その分野がPathメッセージで陰湿に変更されるなら、経路のすべてのその後の装置によって無視されるべきメッセージを引き起こすでしょうに、予約をするのを防いで。 受信機に達する前に値を修正するのは可能でさえあるかもしれません、攻撃を検出するのを難しくして。 また、理論上、ノードがまた、非RSVPメッセージのIPプロトコル番号を変更するのも、可能であるかもしれません、その結果、他のプロトコルの操作を妨げます。
One way to mitigate the risks of malicious modification of the IP protocol number is to use an IPSEC authentication header, which would ensure that malicious modification of the IP header is detected. This is a desirable approach but imposes some administrative burden in the form of key management for authentication purposes.
IPプロトコル番号の悪意がある変更の危険を緩和する1つの方法はIPSEC認証ヘッダーを使用することです。(ヘッダーは、IPヘッダーの悪意がある変更が検出されるのを保証するでしょう)。 これは、望ましいアプローチですが、認証目的のためのかぎ管理の形で何らかの管理負担を課します。
It is RECOMMENDED that implementations of this specification only support modification of the IP protocol number for RSVP Path, PathTear, and ResvConf messages. That is, a general facility for modification of the IP protocol number SHOULD NOT be made available.
この仕様の実現がRSVP Path、PathTear、およびResvConfメッセージのIPプロトコル番号の変更を支持するだけであるのは、RECOMMENDEDです。 すなわち、IPの変更のための一般的な施設は数のSHOULD NOTについて議定書の中で述べます。利用可能に作られています。
Baker, et al. Standards Track [Page 25] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[25ページ]。
Network operators deploying routers with RSVP aggregation capability should be aware of the risks of inappropriate modification of the IP protocol number and should take appropriate steps (physical security, password protection, etc.) to reduce the risk that a router could be configured by an attacker to perform malicious modification of the protocol number.
RSVP集合能力でルータを配備しているネットワーク・オペレータは、IPプロトコル番号の不適当な変更のリスクを意識しているべきであり、攻撃者がプロトコル番号の悪意がある変更を実行するためにルータを構成できたという危険を減少させるために適切な手段を講じるべきです(物理的なセキュリティ、パスワード保護など)。
6. IANA Considerations
6. IANA問題
Section 1.2 proposes a new protocol type, RSVP-E2E-IGNORE, which is used to identify a message that routers in the network core will see; further processing of such messages may or may not be required, depending on the egress interface type, as described in Section 1.2. The IANA assigned IP protocol number 134, in accordance with [RFC2780], meeting the Standards Track publication criterion.
セクション1.2は新しいプロトコルタイプ、ネットワークコアのルータが見るメッセージを特定するのに使用される2EのRSVP E-IGNOREを提案します。 そのようなメッセージのさらなる処理が必要であるかもしれません、出口インターフェース型に頼っていて、セクション1.2で説明されるように。 Standards Track公表評価基準を満たして、[RFC2780]に従って、IANAはIPプロトコル番号134を割り当てました。
Section 1.4.9 describes the manner in which the Router Alert is used in the context of this specification, which is essentially a simple counter of the depth of nesting of aggregation. The IPv4 Router Alert [RFC2113] has the option simply to ask the router to look at the protocol type of the intercepted datagram and decide what to do with it; the parameter is additional information to that decision. The IPv6 Router Alert [RFC2711] turns the parameter into an option sub-type. As a result, the IPv6 router alert option may not be used algorithmically in the context of the protocol in question. The IANA assigned a block of 32 values (3-35, "Aggregated Reservation Nesting Level") which we may map to nesting depths 0..31, hoping that 32 levels is enough.
セクション1.4 .9 Router Alertが本質的には集合の巣篭もりの深さの簡単なカウンタであるこの仕様の文脈で使用される方法を説明します。 IPv4 Router Alert[RFC2113]には、妨害されたデータグラムのプロトコルタイプを見て、それで何をしたらよいか決めるようにルータに単に頼むオプションがあります。 パラメタはその決定への追加情報です。 IPv6 Router Alert[RFC2711]はパラメタをオプションサブタイプに変えます。 その結果、IPv6ルータ警戒オプションは問題のプロトコルの文脈でalgorithmicallyに使用されないかもしれません。 IANAは私たちが深層0を入れ子にするのに写像するかもしれない32の値(3-35、「集められた予約入れ子のレベル」)のブロックを割り当てました。31 32が平らにする望みは十分です。
Section 3.2 discusses a new, required path error code. The IANA has assigned RSVP Parameters Error Code 26 to NEW-AGGREGATE-NEEDED.
セクション3.2は新しくて、必要な経路エラーコードについて論じます。 IANAはRSVP Parameters Error Code26をNEW-AGGREGATEによって必要に割り当てました。
Sections 3.3, 3.4, and 3.5 describe extensions to three object classes: Session, Filter Specification, and Sender Template. The IANA has assigned two new common C-Types to be specified for the aggregator's address. RSVP-AGGREGATE-IP4 is C-Type 9 and RSVP- AGGREGATE-IP6 is C-Type 10. In adding these C-types to IANA RSVP Class Names, Class Numbers and Class Types registry, the same numbering for them is used in all three Classes, as is done for IPv4 and IPv6 address tuples in [RSVP].
セクション3.3、3.4、および3.5 拡大について3つの物のクラスまで説明してください: セッション、フィルタ仕様、および送付者テンプレート。 IANAは、アグリゲータのアドレスに指定されるために2つの新しい一般的なC-タイプを選任しました。 RSVP-AGGREGATE-IP4は9C-タイプ歳です、そして、RSVP- AGGREGATE-IP6は10C-タイプ歳です。 IANA RSVP Class Names、Class民数記、およびClass Types登録にこれらのC-タイプを追加する際に、彼らのための同じ付番は[RSVP]でそのままなすべての3ClassesでIPv4とIPv6アドレスtuplesのためにしていた状態で使用されます。
Baker, et al. Standards Track [Page 26] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[26ページ]。
7. Acknowledgments
7. 承認
The authors acknowledge that published documents and discussion with several people, notably John Wroclawski, Steve Berson, and Andreas Terzis materially contributed to this document. The design is influenced by the RSVP tunnels document [TERZIS].
作者は、数人、著しくジョンWroclawski、スティーブBerson、およびアンドレアスTerzisとの公表された文書と議論が物質的にこのドキュメントに貢献したと認めます。 デザインはRSVPトンネルドキュメント[TERZIS]によって影響を及ぼされます。
Baker, et al. Standards Track [Page 27] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[27ページ]。
APPENDIX 1: Example Signalling Flow For First E2E Flow
付録1: 最初に、2EのE流動のための例の合図流動
This Appendix does not provide additional specification. It only illustrates the specification detailed above through a possible flow of RSVP signalling messages involved in the successful establishment of a unicast E2E reservation which is the first between a given pair of Aggregator/Deaggregator.
このAppendixは追加仕様を提供しません。 それはAggregator/Deaggregatorの与えられた組の間の1番目である2EのユニキャストEの予約のうまくいっている設立にかかわるRSVP合図メッセージの可能な流れによる上で詳細な仕様を例証するだけです。
Aggregator Deaggregator
アグリゲータDeaggregator
E2E Path
---------------->
(1)
E2E Path
------------------------------->
(2)
E2E PathErr(New-agg-needed, DCLASS=x)
<-------------------------------
E2E PathErr(New-agg-needed, DCLASS=y)
<-------------------------------
(3)
AggPath(DSCP=x)
------------------------------->
AggPath(DSCP=y)
------------------------------->
(4)
E2E Path
----------->
(5)
AggResv (DSCP=x)
<-------------------------------
AggResv (DSCP=y)
<-------------------------------
(6)
AggResvConfirm (DSCP=x)
------------------------------>
AggResvConfirm (DSCP=y)
------------------------------>
(7)
E2E Resv
<----------
(8)
E2E Resv (DCLASS=x)
<-----------------------------
(9)
E2E Resv
<---------------
2EのE経路----------------2>(1)EのE経路-------------------------------2>(2)EのE PathErr(必要である、新しいagg、DCLASS=x)<。------------------------------- 2EのE PathErr(必要である、新しいagg、DCLASS=y)<。------------------------------- (3) AggPath(DSCP=x)------------------------------->AggPath(DSCP=y)-------------------------------2>(4)EのE経路----------->(5)AggResv(DSCP=x)<。------------------------------- AggResv(DSCP=y)<。------------------------------- (6) AggResvConfirm(DSCP=x)------------------------------>AggResvConfirm(DSCP=y)------------------------------2>(7)EのE Resv<。---------- (8) 2EのE Resv(DCLASS=x)<。----------------------------- (9) 2EのE Resv<。---------------
Baker, et al. Standards Track [Page 28] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[28ページ]。
(1) Aggregator forwards E2E Path into aggregation region after
modifying its IP Protocol Number to RSVP-E2E-IGNORE
(1) 2RSVP EのE-IGNOREにIPプロトコルNumberを変更した後に、アグリゲータは2EのE Pathを集合領域に送ります。
(2) Let's assume no Aggregate Path exists. To be able to accurately
update the ADSPEC of the E2E Path, the Deaggregator needs the
ADSPEC of Aggregate PATH. In this example the Deaggregator
elects to instruct the Aggregator to set up Aggregate Path
states for the two supported DSCPs by sending a New-Agg-Needed
PathErr code for each DSCP.
(2) どんなAggregate Pathも存在しないと仮定しましょう。 正確に2EのE PathのADSPECをアップデートできるように、DeaggregatorはAggregate PATHのADSPECを必要とします。 この例では、Deaggregatorは、2支持されたDSCPsのために各DSCPのためにNew-Aggによって必要なPathErrコードを送ることによってAggregate Path州を設立するようAggregatorに命令するのを選びます。
(3) The Aggregator follows the request from the Deaggregator and
signals an Aggregate Path for both DSCPs.
(3) AggregatorはDeaggregatorから要求に続いて、両方のDSCPsのためにAggregate Pathに合図します。
(4) The Deaggregator takes into account the information contained in
the ADSPEC from both Aggregate Path and updates the E2E Path
ADSPEC accordingly. The Deaggregator also modifies the E2E Path
IP Protocol Number to RSVP before forwarding it.
(4) DeaggregatorはAggregate Pathとアップデートの両方からADSPECに含まれた情報を2EのE Path ADSPECそれに従って、考慮に入れます。 また、それを進める前に、Deaggregatorは2EのE Path IPプロトコルNumberをRSVPに変更します。
(5) In this example, the Deaggregator elects to immediately proceed
with establishment of Aggregate Reservations for both DSCPs. In
effect, the Deaggregator can be seen as anticipating the actual
demand of E2E reservations so that resources are available on
Aggregate Reservations when the E2E Resv requests arrive in
order to speed up establishment of E2E reservations. Assume
also that the Deaggregator includes the optional Resv Confirm
Request in these Aggregate Resv.
(5) この例では、Deaggregatorは、すぐに両方のDSCPsのためにAggregate予約の設立を続けるのを選びます。 事実上、2ユーロのEの予約の実需を予期するのをDeaggregatorを見ることができるので、2ユーロのE Resv要求がAggregate予約のときに2ユーロのEの予約の設立を早くするために到着するとき、リソースは利用可能です。 また、DeaggregatorがこれらのAggregate Resvに任意のResv Confirm Requestを含んでいると仮定してください。
(6) The Aggregator merely complies with the received ResvConfirm
Request and returns the corresponding Aggregate ResvConfirm.
(6) Aggregatorは単に容認されたResvConfirm Requestに従って、対応するAggregate ResvConfirmを返します。
(7) The Deaggregator has explicit confirmation that both Aggregate
Resv are established.
(7) Deaggregatorには明白な確認がある、そんなに両方、Aggregate Resvは設立されます。
(8) On receipt of the E2E Resv, the Deaggregator applies the mapping
policy defined by the network administrator to map the E2E Resv
onto an Aggregate Reservation. Let's assume that this policy is
such that the E2E reservation is to be mapped onto the Aggregate
Reservation with DSCP=x. The Deaggregator knows that an
Aggregate Reservation is in place for the corresponding DSCP
since (7). The Deaggregator performs admission control of the
E2E Resv onto the Aggregate Resv for DSCP=x. Assuming that the
Aggregate Resv for DSCP=x had been established with sufficient
bandwidth to support the E2E Resv, the Deaggregator adjusts its
counter tracking the unused bandwidth on the Aggregate
Reservation and forwards the E2E Resv to the Aggregator
including a DCLASS object conveying the selected mapping onto
DSCP=x.
(8) 2EのE Resvを受け取り次第、Deaggregatorは2EのE ResvをAggregate予約に写像するためにネットワーク管理者によって定義されたマッピング方針を適用します。 2ユーロのEの予約がこの方針がそのようなものであるのでDSCP=xとのAggregate予約に写像されることであると仮定しましょう。 Deaggregatorは、(7)以来Aggregate予約が対応するDSCPのために適所にあるのを知っています。 DeaggregatorはDSCP=xであるときに2EのE ResvのAggregate Resvへの入場コントロールを実行します。 DSCP=xであることのAggregate Resvが2EのE Resvを支持できるくらいの帯域幅で設立されたと仮定して、Deaggregatorは、選択されたマッピングをDSCP=xに伝えながら、Aggregate予約における未使用の帯域幅を追跡するカウンタを調整して、DCLASS物を含むAggregatorに2EのE Resv転送します。
Baker, et al. Standards Track [Page 29] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[29ページ]。
(9) The Aggregator records the mapping of the E2E Resv onto DSCP=x.
The Aggregator removes the DCLASS object and forwards the E2E
Resv towards the sender.
(9) Aggregatorは2EのE Resvに関するマッピングをDSCP=xに記録します。 Aggregatorは送付者に向かってDCLASS物を移して、2EのE Resvを送ります。
APPENDIX 2: Example Signalling Flow For Subsequent E2E Flow Without
Reservation Resizing
付録2: 予約リサイズのない2その後のEのE流動のための例の合図流動
This Appendix does not provide additional specification. It only illustrates the specification detailed above through a possible flow of RSVP signalling messages involved in the successful establishment of a unicast E2E reservation which follows other E2E reservations between a given pair of Aggregator/Deaggregator. This flow could be imagined as following the flow of messages illustrated in Appendix 1.
このAppendixは追加仕様を提供しません。 それはAggregator/Deaggregatorの与えられた組の間で他の2ユーロのEの予約に従う2EのユニキャストEの予約のうまくいっている設立にかかわるRSVP合図メッセージの可能な流れによる上で詳細な仕様を例証するだけです。 Appendix1で例証されたメッセージの流れに続くとこの流れを想像できました。
Aggregator Deaggregator
アグリゲータDeaggregator
E2E Path
---------------->
(10)
E2E Path
------------------------------->
(11)
E2E Path
----------->
E2E Resv
<-----------
(12)
E2E Resv (DCLASS=x)
<-----------------------------
(13)
E2E Resv
<---------------
2EのE経路----------------2>(10)EのE経路-------------------------------2>(11)EのE経路----------->E2E Resv<。----------- (12) 2EのE Resv(DCLASS=x)<。----------------------------- (13) 2EのE Resv<。---------------
(10) Aggregator forwards E2E Path into aggregation region after
modifying its IP Protocol Number to RSVP-E2E-IGNORE
(10) 2RSVP EのE-IGNOREにIPプロトコルNumberを変更した後に、アグリゲータは2EのE Pathを集合領域に送ります。
(11) Because previous E2E reservations have been established, let's
assume that Aggregate Path exists for all supported DSCPs. The
Deaggregator takes into account the information contained in the
ADSPEC from the Aggregate Paths and updates the E2E Path ADSPEC
accordingly. The Deaggregator also modifies the E2E Path IP
Protocol Number to RSVP before forwarding it.
(11) 前の2ユーロのEの予約が確立されたので、Aggregate Pathがすべての支持されたDSCPsのために存在すると仮定しましょう。 DeaggregatorはAggregate PathsからADSPECに含まれた情報を考慮に入れて、それに従って、2EのE Path ADSPECをアップデートします。 また、それを進める前に、Deaggregatorは2EのE Path IPプロトコルNumberをRSVPに変更します。
(12) On receipt of the E2E Resv, the Deaggregator applies the mapping
policy defined by the network administrator to map the E2E Resv
onto an Aggregate Reservation. Let's assume that this policy is
such that the E2E reservation is to be mapped onto the Aggregate
Reservation with DSCP=x. Because previous E2E reservations have
(12) 2EのE Resvを受け取り次第、Deaggregatorは2EのE ResvをAggregate予約に写像するためにネットワーク管理者によって定義されたマッピング方針を適用します。 2ユーロのEの予約がこの方針がそのようなものであるのでDSCP=xとのAggregate予約に写像されることであると仮定しましょう。 前の2ユーロのEの予約がそうしたので
Baker, et al. Standards Track [Page 30] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[30ページ]。
been established, let's assume that an Aggregate Reservation is
in place for DSCP=x. The Deaggregator performs admission
control of the E2E Resv onto the Aggregate Resv for DSCP=x.
Assuming that the Aggregate Resv for DSCP=x has sufficient
unused bandwidth to support the new E2E Resv, the Deaggregator
then adjusts its counter tracking the unused bandwidth on the
Aggregate Reservation and forwards the E2E Resv to the
Aggregator including a DCLASS object conveying the selected
mapping onto DSCP=x.
確証されて、Aggregate予約がDSCP=xであるときに適所にあると仮定しましょう。 DeaggregatorはDSCP=xであるときに2EのE ResvのAggregate Resvへの入場コントロールを実行します。 DSCP=xであることのAggregate Resvには2新しいEのE Resvを支持できるくらいの未使用の帯域幅があると仮定して、Deaggregatorは、選択されたマッピングをDSCP=xに伝えながら、次に、Aggregate予約における未使用の帯域幅を追跡するカウンタを調整して、DCLASS物を含むAggregatorに2EのE Resv転送します。
(13) The Aggregator records the mapping of the E2E Resv onto DSCP=x.
The Aggregator removes the DCLASS object and forwards the E2E
Resv towards the sender.
(13) Aggregatorは2EのE Resvに関するマッピングをDSCP=xに記録します。 Aggregatorは送付者に向かってDCLASS物を移して、2EのE Resvを送ります。
APPENDIX 3: Example Signalling Flow For Subsequent E2E Flow With
Reservation Resizing
付録3: 予約リサイズを伴う2その後のEのE流動のための例の合図流動
This Appendix does not provide additional specification. It only illustrates the specification detailed above through a possible flow of RSVP signalling messages involved in the successful establishment of a unicast E2E reservation which follows other E2E reservations between a given pair of Aggregator/Deaggregator. This flow could be imagined as following the flow of messages illustrated in Appendix 2.
このAppendixは追加仕様を提供しません。 それはAggregator/Deaggregatorの与えられた組の間で他の2ユーロのEの予約に従う2EのユニキャストEの予約のうまくいっている設立にかかわるRSVP合図メッセージの可能な流れによる上で詳細な仕様を例証するだけです。 Appendix2で例証されたメッセージの流れに続くとこの流れを想像できました。
Baker, et al. Standards Track [Page 31] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[31ページ]。
Aggregator Deaggregator
アグリゲータDeaggregator
E2E Path
---------------->
(14)
E2E Path
------------------------------->
(15)
E2E Path
----------->
2EのE経路----------------2>(14)EのE経路-------------------------------2>(15)EのE経路----------->。
E2E Resv
<-----------
2EのE Resv<。-----------
(16)
AggResv (DSCP=x, increased Bw)
<-------------------------------
(17)
AggResvConfirm (DSCP=x, increased Bw)
------------------------------>
(18)
E2E Resv (DCLASS=x)
<-----------------------------
(19)
E2E Resv
<---------------
(16) AggResv(DSCP=x、増加するBw)<。------------------------------- (17) AggResvConfirm(DSCP=x、増加するBw)------------------------------2>(18)EのE Resv(DCLASS=x)<。----------------------------- (19) 2EのE Resv<。---------------
(14) Aggregator forwards E2E Path into aggregation region after
modifying its IP Protocol Number to RSVP-E2E-IGNORE
(14) 2RSVP EのE-IGNOREにIPプロトコルNumberを変更した後に、アグリゲータは2EのE Pathを集合領域に送ります。
(15) Because previous E2E reservations have been established, let's
assume that Aggregate Path exists for all supported DSCPs. The
Deaggregator takes into account the information contained in the
ADSPEC from the Aggregate Paths and updates the E2E Path ADSPEC
accordingly. The Deaggregator also modifies the E2E Path IP
Protocol Number to RSVP before forwarding it.
(15) 前の2ユーロのEの予約が確立されたので、Aggregate Pathがすべての支持されたDSCPsのために存在すると仮定しましょう。 DeaggregatorはAggregate PathsからADSPECに含まれた情報を考慮に入れて、それに従って、2EのE Path ADSPECをアップデートします。 また、それを進める前に、Deaggregatorは2EのE Path IPプロトコルNumberをRSVPに変更します。
(16) On receipt of the E2E Resv, the Deaggregator applies the mapping
policy defined by the network administrator to map the E2E Resv
onto an Aggregate Reservation. Let's assume that this policy is
such that the E2E reservation is to be mapped onto the Aggregate
Reservation with DSCP=x. Because previous E2E reservations have
been established, let's assume that an Aggregate Reservation is
in place for DSCP=x. The Deaggregator performs admission
control of the E2E Resv onto the Agg Resv for DSCP=x. Let's
assume that the Aggregate Resv for DSCP=x does NOT have
sufficient unused bandwidth to support the new E2E Resv. The
(16) 2EのE Resvを受け取り次第、Deaggregatorは2EのE ResvをAggregate予約に写像するためにネットワーク管理者によって定義されたマッピング方針を適用します。 2ユーロのEの予約がこの方針がそのようなものであるのでDSCP=xとのAggregate予約に写像されることであると仮定しましょう。 前の2ユーロのEの予約が確立されたので、Aggregate予約がDSCP=xであるときに適所にあると仮定しましょう。 DeaggregatorはDSCP=xであるときに2EのE ResvのAgg Resvへの入場コントロールを実行します。 DSCP=xであることのAggregate Resvには2新しいEのE Resvを支持できるくらいの未使用の帯域幅がないと仮定しましょう。 The
Baker, et al. Standards Track [Page 32] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[32ページ]。
Deaggregator then attempts to increase the Aggregate Reservation
bandwidth for DSCP=x by sending a new Aggregate Resv with an
increased bandwidth sufficient to accommodate all the E2E
reservations already mapped onto that Aggregate reservation plus
the new E2E reservation plus possibly some additional spare
bandwidth in anticipation of additional E2E reservations to
come. Assume also that the Deaggregator includes the optional
Resv Confirm Request in these Aggregate Resv.
そして、Deaggregatorは、来るために増加する帯域幅が十分な状態で新しいAggregate Resvを送るのによるDSCP=xが追加2ユーロのEの予約を予測して既にそのAggregateの予約、新しい2ユーロのEの予約、およびことによるといくらかの追加予備帯域幅に写像されたすべての2ユーロのEの予約を収容するようにAggregate予約帯域幅を増加させるのを試みます。 また、DeaggregatorがこれらのAggregate Resvに任意のResv Confirm Requestを含んでいると仮定してください。
(17) The Aggregator merely complies with the received ResvConfirm
Request and returns the corresponding Aggregate ResvConfirm.
(17) Aggregatorは単に容認されたResvConfirm Requestに従って、対応するAggregate ResvConfirmを返します。
(18) The Deaggregator has explicit confirmation that the Aggregate
Resv has been successfully increased. The Deaggregator performs
again admission control of the E2E Resv onto the increased
Aggregate Reservation for DSCP=x. Assuming that the increased
Aggregate Reservation for DSCP=x now has sufficient unused
bandwidth and resources to support the new E2E Resv, the
Deaggregator then adjusts its counter tracking the unused
bandwidth on the Aggregate Reservation and forwards the E2E Resv
to the Aggregator including a DCLASS object conveying the
selected mapping onto DSCP=x.
(18) Deaggregatorには、増加して、Aggregate Resvが首尾よくそうである明白な確認があります。 DeaggregatorはDSCP=xであるときに再び2EのE Resvの増加するAggregate予約への入場コントロールを実行します。 DSCP=xであることの増加するAggregate予約には十分な未使用の帯域幅と支持するリソースが現在2新しいEのE Resvあると仮定して、Deaggregatorは、選択されたマッピングをDSCP=xに伝えながら、次に、Aggregate予約における未使用の帯域幅を追跡するカウンタを調整して、DCLASS物を含むAggregatorに2EのE Resv転送します。
(19) The Aggregator records the mapping of the E2E Resv onto DSCP=x.
The Aggregator removes the DCLASS object and forwards the E2E
Resv towards the sender.
(19) Aggregatorは2EのE Resvに関するマッピングをDSCP=xに記録します。 Aggregatorは送付者に向かってDCLASS物を移して、2EのE Resvを送ります。
References
参照
[CSZ] Clark, D., S. Shenker, and L. Zhang, "Supporting Real-
Time Applications in an Integrated Services Packet
Network: Architecture and Mechanism," in Proc.
SIGCOMM'92, September 1992.
[CSZ] クラーク、D.、S.Shenker、およびL.チャン、「レアルを支持して、統合サービスパケット網におけるアプリケーションを調節してください」 Procの「構造とメカニズム。」 1992年9月のSIGCOMM92年。
[IP] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[IP] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[HOSTREQ] Braden, R., "Requirements for Internet hosts -
communication layers", STD 3, RFC 1122, October 1989.
[HOSTREQ]ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[DSFIELD] 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.
[DSFIELD]ニコルズとK.とブレークとS.、ベイカーとF.とD.黒、「IPv4とIPv6ヘッダーとの微分されたサービス分野(DS分野)の定義」RFC2474(1998年12月)。
[PRINCIPLES] Carpenter, B., "Architectural Principles of the
Internet", RFC 1958, June 1996.
[原則] 1996年6月の大工、B.、「インターネットの建築プリンシプルズ」RFC1958。
Baker, et al. Standards Track [Page 33] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[33ページ]。
[ASSURED] Heinanen, J, Baker, F., Weiss, W. and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[保証されます] HeinanenとJとベイカーとF.とウィスとW.とJ.Wroclawski、「相対的優先転送PHBは分類する」RFC2597、1999年6月。
[BROKER] Jacobson, V., Nichols K. and L. Zhang, "A Two-bit
Differentiated Services Architecture for the Internet",
RFC 2638, June 1999.
[仲介します] ジェーコブソンとV.とニコルズK.とL.チャン、「インターネットへの安っぽい微分されたサービス構造」、RFC2638、1999年6月。
[BRIM] Brim, S., Carpenter, B. and F. LeFaucheur, "Per Hop
Behavior Identification Codes", RFC 2836, May 2000.
「ホップ振舞い識別コード」あたりの[縁]縁、S.、大工、B.、およびF.LeFaucheur(RFC2836)は2000がそうするかもしれません。
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
Jamin, "Resource Reservation Protocol (RSVP) Version 1
Functional Specification", RFC 2205, September 1997.
[RSVP] ブレーデンとR.とチャンとL.とBersonとS.とハーツォグとS.とS.ジャマン、「資源予約プロトコル(RSVP)バージョン1の機能的な仕様」、RFC2205、1997年9月。
[TERZIS] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang,
"RSVP Operation Over IP Tunnels", RFC 2746, January
2000.
[TERZIS] TerzisとA.とKrawczykとJ.とWroclawskiとJ.とL.チャン、「IP Tunnelsの上のRSVP操作」、RFC2746、2000年1月。
[DCLASS] Bernet, Y., "Format of the RSVP DCLASS Object", RFC
2996, November 2000.
[DCLASS]Bernet、Y.、「RSVP DCLASS物の形式」、RFC2996、2000年11月。
[INTEGRITY] Baker, F., Lindell, B. and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747, January 2000.
[保全] ベイカーとF.とリンデルとB.とM.Talwar、「RSVPの暗号の認証」、RFC2747、2000年1月。
[RFC2998] Bernet Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L.,
Speer, M., Braden, R., Davie, B., Wroclawski, J. and E.
Felstaine, "Integrated Services Operation Over Diffserv
Networks", RFC 2998, November 2000.
[RFC2998]Bernet Y.(フォード、P.、Yavatkar、R.、ベイカー、F.、チャン、L.、シュペーア、M.、ブレーデン、R.、デイビー、B.、Wroclawski、J.、およびE.Felstaine)は「Diffservネットワークの上でサービス操作を統合しました」、RFC2998、2000年11月。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P. and F.
Tommasi, "RSVP Refresh Reduction Extensions", RFC 2961,
April 2001.
[RFC2961] バーガーとL.とガンとD.とツバメとG.となべとP.とF.トンマージ、「RSVPは減少拡大をリフレッシュする」RFC2961、2001年4月。
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines
For Values In the Internet Protocol and Related
Headers", RFC 2780, March 2000.
[RFC2780] ブラドナー、S.、および「インターネットプロトコルと関連ヘッダーの値のためのIANA配分ガイドライン」、RFC2780(2000年3月)対パクソン
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert
Option", RFC 2711, October 1999.
[RFC2711] ヤマウズラとC.とA.ジャクソン、「IPv6ルータ警戒オプション」、RFC2711、1999年10月。
[RFC2113] Katz, D. "IP Router Alert Option", RFC 2113, February
1997.
[RFC2113]キャッツ、D.「IPルータ警戒オプション」、RFC2113、1997年2月。
Baker, et al. Standards Track [Page 34] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[34ページ]。
Authors' Addresses
作者のアドレス
Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, CA, 93117 USA
レイサンタバーバラ、デル・カリフォルニア93117米国経由でフレッドベイカーシスコシステムズ1121
Phone: (408) 526-4257 EMail: fred@cisco.com
以下に電話をしてください。 (408) 526-4257 メールしてください: fred@cisco.com
Carol Iturralde Cisco Systems 250 Apollo Drive Chelmsford MA, 01824 USA
キャロルイトゥラルデシスコシステムズ250アポロドライブチェルムズフォード01824MA(米国)
Phone: 978-244-8532 EMail: cei@cisco.com
以下に電話をしてください。 978-244-8532 メールしてください: cei@cisco.com
Francois Le Faucheur Cisco Systems Domaine Green Side 400, Avenue de Roumanille 06410 Biot - Sophia Antipolis France
フランソアLe FaucheurシスコシステムズドメーヌグリーンSide400、アベニューdeルーマニーユ06410Biot--ソフィア・Antipolisフランス
Phone: +33.4.97.23.26.19 EMail: flefauch@cisco.com
以下に電話をしてください。 +33.4 .97 .23 .26 .19 メール: flefauch@cisco.com
Bruce Davie Cisco Systems 250 Apollo Drive Chelmsford MA,01824 USA
ブルースデイビーシスコシステムズ250アポロドライブチェルムズフォード01824MA(米国)
Phone: 978-244-8921 EMail: bdavie@cisco.com
以下に電話をしてください。 978-244-8921 メールしてください: bdavie@cisco.com
Baker, et al. Standards Track [Page 35] RFC 3175 RSVP Reservation Aggregation September 2001
ベイカー、他 規格はRSVP予約集合2001年9月にRFC3175を追跡します[35ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Baker, et al. Standards Track [Page 36]
ベイカー、他 標準化過程[36ページ]
一覧
スポンサーリンク
