Network Working Group F. Baker
Request for Comments: 3175 C. Iturralde
Category: Standards Track F. Le Faucheur
B. Davie
Cisco Systems
September 2001
Aggregation of RSVP for IPv4 and IPv6 Reservations
Status of this 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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.
この文書では、ATM（非同期転送モード）網における仮想パスを使用すると概念的に同様の方法で、トランジットルーティング領域を横切って他のRSVP予約を集約する単一のRSVP（リソース予約プロトコル）予約の使用を記載しています。サブ予約は不要になったときには、動的に帯域幅を、集計予約が適用されるトラフィックを分類、集計予約を作成する要件を達成するために必要とされるどのくらいの帯域幅を決定し、回復するための方法を提案していません。また、予測の予約のためのアルゴリズムと政策に関する提言が含まれています。
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 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.
凝集の問題は、さまざまな方法で対処することができます。例えば、単にこのようなスケジューリングと分類状態の集約を可能にする、適切なDSCP（例えば、EF）と予約トラフィックをマークするために十分であり得ます。また、各集約予約フローの多数から同様にマーキングされたパケットを運ぶ「集合領域」（以下に定義）の出口に入口から1つの以上の集計予約をインストールすることが望ましい場合があります。これは、予約状態を可能にすると同時に凝集させながら、予約フローのエンド・ツー・エンドの要件が満たされる保証の高レベルを提供することです。
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.
私たちは集合領域の入口および出口端でルーターに言及、「集約」と「デアグリゲータ」についてお話します。正確ルータは、それがアグリゲータ又はデアグリゲーターの役割を実行すべきか否かを判定する方法について説明します。
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".
私たちは、「エンドツーエンド」の予約（略して「E2E」）として、およびE2Eパス/ RESVメッセージとして、それぞれのパス/ RESVメッセージに個別に予約セッション（私たちが集約しようとしているセッション）を参照します。我々は、「集約」予約として（多くのE2Eの予約を表す）より大きな予約、および「集約パス/ RESVメッセージ」として、その各パス/ RESVメッセージを指します。
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.
集計は、しかし、独自の課題をもたらします。特に、一つのフローが別のバーストからの遅延を被ることができることを意味し、個々のフローとの間のアイソレーションのレベルを低下させます。異なるフローからのバーストの同期が発生する可能性があります。しかし、流れの凝集を示唆する証拠[CSZ]フローの平均遅延に影響はありませんし、実際に遅延分布の「尾」の遅延の低減につながる（例えば、99％パーセンタイル遅延があります）フローの。ある程度の凝集のこれらの利点は、厳格な分離の損失を相殺しました。
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.
我々が提案する解決策は、「凝集領域」を横断し、入口から出口へのうち大きい方の予約に共通の入口および出口ルータを共有するいくつかのE2Eの予約の集合を含みます。我々は、この連続したセットを介して任意の可能なルートに沿って（以下に定義）RSVPアグリゲーションを行うことができるシステムの連続セットとして「集合領域」を定義します。
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つのカテゴリに分類します。彼らは脱凝集、凝集、またはそれらは、アグリゲータとデアグリゲーターの間です。
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.
凝集は、凝集領域内のRSVP対応ルータからのE2E RSVPメッセージを隠すことができることに依存します。この目的を達成するために、E2E予約のパス、PathTear、およびResvConfメッセージにおけるIPプロトコル番号は、凝集領域に入る（134）RSVP-E2Eは、無視するRSVP（46）から変更、及びデアグリゲーター点で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.
E2E予約のトークンバケット（SENDER_TSPECs及びフロースペック）が集約パスとRESVメッセージに対応する情報要素に加算されます。集約PathメッセージはRSVPの通常のIPプロトコル番号を使用してアグリゲーター（複数可）にアグリゲータから送信されます。集約RESVメッセージは、このように、このアグリゲータとデアグリゲーターを使用E2Eフローのセットの代わりに集計予約を確立し、アグリゲータに戻すデアグリゲーターから送信されます。
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.
そのようなE2E予約の多数の代わりに集約予約の少ない数の確立記憶する状態の量の対応する減少をもたらすとシグナリングメッセージの量は、凝集領域に交換しました。
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.
分類および集約の予約によってサポートされるトラフィックのスケジューリングのための差別化サービス・メカニズムを使用して（というより集約予約分類及びスケジューリングごとに行う）ことにより、凝集領域における分類及びスケジューリング状態の量がさらに低減されます。それだけでなく、E2Eの予約数とは独立して、それはまた、集約地域における総予約数とは無関係です。一つ以上のDiff-ServのののDSCPは、このトラフィックに必要な転送処理を提供するために使用される骨材の予約および1つまたは複数のDiff-ServののPHBによって覆われたトラフィックを識別するために使用されます。それぞれが異なるDSCPと異なるPHBを使用してトラフィックと各々の異なるクラスを表す、ルータの同一の対の間の複数の集約の予約があってもよいです。
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つのルータの外部インターフェイスに到達するE2EのRSVPメッセージ（この、おそらくセット内の他のルータの）一つ以上の内部インターフェイスを横切ることになるため、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).
我々は、それが凝集領域に入るとE2E Pathメッセージを処理する最初のルータ（すなわち、内部インターフェイスの外部インタフェースからのメッセージを転送するもの）として本E2Eフローの「凝集」ルータを定義します。
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).
我々は、それが凝集領域を残すようE2Eパスを処理するために、最後のルータ（すなわち、外部インターフェイスに内部インタフェースからのメッセージを転送するもの）として本E2Eフローの「解凝集」ルータを定義します。
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.
我々は、内部インターフェイス上でこのメッセージを受信し、別の内部インタフェースに転送集合領域内の任意のルータとしてE2Eフローの「内部」ルータを定義します。インテリアルータは、このフローのどちらの集約や脱凝集を行います。
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.
これらの定義により、内部および外部インターフェースが混在する単一のルータは、いくつかのE2Eフローに集約、他のE2Eフローにデアグリゲーター、さらに他のフローに対する内部ルータとして動作する能力を有していてもよいことに留意されたいです。
A number of issues jump to mind in considering this model.
多くの問題は、このモデルを考慮して、心にジャンプ。
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が集約セッションへの道を識別しなかった理由の一つは、集計を分類する明確な方法がなかったということでした。差別化サービスアーキテクチャの発展に伴い、これは、少なくとも部分的に解決されます。特定のクラスのトラフィックは、指定された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 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.
我々は、ルート、キュー、WDM色、または類似の管理コンポーネントEN各リンク上の同じクラスのすべての集約トラフィックのために確保されていることを前提とし、十分な帯域幅がそれに割り当てられたトラフィックを搬送するために利用可能になります。この帯域幅は、同じクラスに割り当てられた凝集予約トラフィックの総量に基づいて調整することができます。
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ののPHBはトラフィックの異なるクラスのために使用される可能性があります正確にするための多くのオプションがあります。これは、[RFC2998]で説明した「サービスマッピング」の問題であり、この文書に記載されているものよりも広い状況に適用されます。引数が集約トラフィック用EFまたは1つ以上のAFのPHBのいずれかを使用するために作製することができます。制御された負荷は、トラフィックは、ベストエフォートトラフィックとして転送するのではなく、廃棄する（ポリシング）非TSpecの準拠必要とするので、例えば、非準拠のパケットのためのより高いドロップ優先を使用して、制御された負荷のためのAFクラスを使用することが適切であるかもしれません。
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動作では、セッションは、宛先アドレスおよび任意プロトコルポートによって識別されます。集約の予約に属するデータは、DSCPによって識別されるので、セッションは、宛先アドレスとDSCPによって定義されます。 （上述のように、準拠および非準拠のパケットのために）は、2つのDSCPが使用されているような場合のために、セッションを適合パケットのDSCPによって識別されます。一般的に、我々は、DSCP（第2 DSCP非準拠トラフィックのために使用することができる場合でも）に集約されたトラフィックをマッピングすることについてお話します。
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又はのPHB、ケアは、単一のPHBの合計入院負荷リンクを超えないことを確実にするために、同一のネットワークで使用されている差分-SERVと集約RSVPをプロビジョニング環境で取るする必要がありますそのPHBに割り当てられた容量。これに対する一つの解決策は、プロビジョニングされた（例えば、AF2、AF3およびAF4クラス）のDiff-Servのための他のPHBを使用しながら凝集予約トラフィック（例えば、AF1クラス）のために厳密に1つのPHB（またはそれ以上）を確保することです。
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.
分類及びスケジューリング状態（トラフィックを分類するために使用される、例えば、のDSCP）を（むしろ凝集予約あたりより）当たり総計予約クラスごとに維持しながら凝集領域内に、いくつかのRSVPの予約状態は、集約の予約ごとに維持されます。例えば、保証型サービス予約が凝集領域全体EF DSCPにマッピングされる場合、各ルータの各アグリゲータ/デアグリゲーターペアの予約があってもよいが、唯一のEF DSCPは、各内部界面で検査する必要がある、とのみ単一のキューは、すべてのEFトラフィックに使用されます。
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フローを集約する責任がありアグリゲータ/デアグリゲータのペアを決定する方法は？」です
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.
アグリゲータの決定は簡単です：私たちは、E2EフローがそのPathメッセージは、外部インターフェイス上のルータに到着すると、アグリゲータに到着したと内部インターフェイスに転送されなければならないことを知っています。
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やIS-ISなどSPFルーティングプロトコルは、使用中である、そしてそれは脱凝集の役割についての情報を宣伝するために拡張されている場合、それは私たちにデアグリゲータが選択されるから、ルータのセットを伝えることができます。アグリゲーター及びデアグリゲーターが同じ領域にある場合、原理的には、次にデアグリゲーターの識別は、リンク状態データベースから決定することができます。しかし、このアプローチは、マルチエリア環境でまたは距離ベクトルプロトコルでは動作しないであろう。
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.
デアグリゲーターの決意のための一つの方法は、手動の構成です。この方法では、ネットワークオペレータは、必要な情報を集約し、デアグリゲータを設定します。
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.
別の方法は、自動デアグリゲーターの決意と対応する集約通知を可能にします。 E2E RSVP Pathメッセージは、外部インターフェイスへの内部インターフェイスから遷移した場合に、解凝集ルータは、それ自体と流れとの間の相関の集約ルータに助言しなければなりません。これは、ルーティングプロトコルに特定されていないの素敵な属性を持っています。また、自動的にルート変更に調整する性質を有しています。例えば、なぜならトポロジの変更の場合は、別のデアグリゲータは、今で最短経路上で、このメソッドは自動的にそれに新しいデアグリゲータとスワップを識別します。
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.
上述したように、同じアグリゲータ/デアグリゲーターのペア間に複数の集合予約があってもよいです。集計予約にマッピングするE2Eの予約のためのルールは、ネットワーク環境やネットワーク管理者の目的に依存政策決定です。このような政策は、この仕様の範囲外であり、我々は単に、このような政策は、ネットワーク管理者によって定義されていることを前提としています。また、この仕様の範囲外である、そのような政策は何とかアグリゲータ/デアグリゲータが、このポリシーがアグリゲータ/デアグリゲータ（その他のローカル設定、COPS、LDAP、）にアクセス可能にする方法の詳細にアクセス可能であることを前提としています。
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.
非常に単純なポリシーの例では、すべてのE2E予約がアグリゲータ/デアグリゲーターの所与の対の間に単一の集約予約（すなわち、単一の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.
保証されたサービスE2E予約が凝集領域と制御負荷E2Eの予約の一方DSCPにマッピングされるアカウントに、受信機によって要求されたINT-Servのサービスタイプ（およびE2EのResvでシグナリング）かかりポリシーの別の例は、あろう別のDSCP上にマッピングされています。
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の例は、集合予約へE2Eの予約のマッピングは、E2E経路に及び/又は中に受信機によって送信者が含まれていてもよい（例えば、エンドユーザの認証情報など）アカウントポリシーオブジェクトに取るものであろうE2EのResv。
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予約をマッピングするための決定が行われると方法について考えられます。アグリゲータとデアグリゲータの両方が独立して、このような決定を下すものと仮定することができます。しかし、これは矛盾マッピング決定を解決するために、追加の手順の定義を必要とするであろういずれか（すなわち、アグリゲータとデアグリゲーターは、異なる集合予約に与えられたE2E予約をマッピングすることを決定する）、または一貫性のない決定の場合に可能な未検出の不正行為をもたらすであろう。
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.
シンプルさと信頼性のために、私たちは完全デアグリゲータへのマッピングの決定の責任を割り当てます。アグリゲータは、デアグリゲータによって選択されたマッピングを通知し、この決定に従います。デアグリゲーターによりシグナリング情報を要求のInt-Servのサービスタイプを示し、含まE2EのResvの特定の受信で、そのような決定を行うために必要なすべての情報へのアクセスを（持っている最初のものであるため、デアグリゲーターは、アグリゲータではなく、選択しました受信機）。これは、より速いE2E予約の確立をもたらす状況の数で集計予約のセットアップやサイズ調整等の高速動作を可能にします。
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 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の予約の帯域幅の合計に等しいことが必要であり、そのバースト容量がより大きいまたはそれらバースト容量の合計に等しくなければなりません。宗教的に続く場合は、これは集約予約の帯域幅ごとに集計の主要な利点の一つ、集約地域におけるメッセージ処理コストの削減を失う基本的なE2E予約の変更を、変更することが私たちをリード。
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.
（サンプルポリシーが必要な特性を持っている提案されているが）私たちは、この仕様で定義されていない、いくつかのポリシーがあること、そのため、想定しています。このポリシーは、まれにそれを変更するために努力しながら、その根底にあるE2Eの予約の帯域幅の合計を考慮して与えられた集計予約に必要な帯域幅の量を維持します。これは、傾向分析のいくつかのレベルが必要な場合があります。次の時間間隔で、現在の集計予約が排出されるという重大な可能性がある場合、ルータは必要な帯域幅を予測し、それを要求しなければなりません。ルーターが予約された帯域幅を大量に持っているが、それを使用しての非常に少ない確率を持っている場合、ポリシーは必要な帯域幅の量を予測し、過剰を解放することであってもよいです。
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.
彼らは技術的なもの、そしてこの文書の範囲外であるとして明らかに、そのような政策の定義や操作はできるだけ多くのビジネス上の問題です。
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.
上述したように、E2EのRSVPメッセージは、凝集領域内の内側のルータから隠されます。彼らは集約領域を通って移動するにつれてその結果、E2EのPathメッセージのADSPECsは更新されません。したがって、フローのためのデアグリゲーターは、エンドツーエンドを達成することができるQoSに凝集領域の影響を反映するために、対応するE2E経路内のADSPECを更新する責任があります。デアグリゲータは、できるだけ正確にE2Eパスの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.
集約Pathメッセージは、凝集領域内で処理されているので、それらのADSPECは、内部領域内で達成することができるQoSに凝集領域の影響を反映するために、内部ルータによって更新されます。その結果、デアグリゲータは、利用可能な集約パスからADSPECに含まれる情報を利用する必要があります。デアグリゲータは、このような情報が正確にそのADSPECを更新するためにE2Eパスを転送する前に利用可能になるまで待つことを選ぶことができます。
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.
アグリゲータは、集約パスを通知するたびにデアグリゲータに利用可能な情報を最大限にするために、アグリゲータが集約地域でサポートされているすべてのサービスタイプのための断片とのADSPECを含める必要があります（集計パスが集計予約に対応しても場合にのみサポートしますこれらのサービスタイプのサブセット）。あらゆる可能なサービスタイプのデアグリゲータにこの情報を提供することは、アグリゲーターによってE2E 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:
正確例えばE2EパスADSPEC、デアグリゲータ月を更新するために、集計予約の上、環境上およびマッピングE2Eの予約のためのポリシーに応じて：
- 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
- 単一の集約パスのADSPECに基づいて（デフォルトの一般的なパラメータフラグメント、保証サービスフラグメント、制御・ロード・サービスフラグメント）をすべてE2EパスADSPECセグメントを更新する、または
- 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).
- 複数の集約Pathメッセージ（例えば,.から考慮にADSPECを取ることによって、E2EパスADSPECを更新し、すべての集約パスADSPECsにわたって各パラメータの「最悪」の値を使用してデフォルトの一般的なパラメータ断片を更新し、使用して保証サービスフラグメントを更新保証サービスのために使用された予約）のための集約パスのADSPECからの保証されたサービスフラグメント。
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.
アカウントに前述のように集約パス（複数可）のADSPECに含まれる情報をとることによって、デアグリゲーターを正確ほとんどの状況でE2Eパス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:
しかし、我々はE2EパスADSPECの更新がデアグリゲータによって完全に正確に行うことができない特定の状況があるかもしれないことに注意してください。これは、集約地域全体で撮影したパスが到着するのはまだあるE2Eの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.
- 凝集領域のためのサービス・マッピング・ポリシーは、これらの要求負荷制御サービスことが保証されたサービスを要求するE2E予約が異なる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).
- 別のDSCPを持つパケットが（異なるMPLSラベルは、例えば、パスの切り替えの上にそれらを送信する）異なる経路をたどるように差分-SERVアウェアルーティングは、凝集領域で使用されています。
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と異なる場合があります。
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でE2Eパスを送ると仮定します。その後、E2E ADSPECを更新する時に、デアグリゲータは、実際に受信機によって要求されるサービスの種類を知っていないため、このE2Eフローを転送するために使用されるPHBを知ることができないと、今度は、右のパラメータを選択することはできませんデフォルトの一般的なパラメータフラグメントを更新する際の要因とする値。前述したように、この特定のケースでは、保守的なアプローチは、常に考慮にすべてのパラメータのための最悪値をとることであろう。かかわらず、このような2つの集約パスADSPECの一つは、E2Eパス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.
E2EパスADSPECの完全に正確で更新を認識すると、すべての状況で可能ではないかもしれないが、我々は保守的なアプローチは、（悲観的-上ではなく、過剰に楽観的）な状況で撮影することをお勧めしますとE2EパスADSPECはできるだけ早く修正すること。上記の例では、これはデアグリゲーターは、受信機からE2EのResvを受信するとすぐに、デアグリゲーター集約予約が実際E2Eフローを運ぶれるの知識に基づいて正確に更新ADSPECを有する別のE2E経路を生成する必要があることを意味します。
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メッセージを送信することにより、集約の予約をしているので、予約済み（E2E）のデータパケットは、もはや関連（集約）Pathメッセージと同じIPアドレスを運びません。問題は、予約フローのデータパケットが集約予約のためのパスの状態を確立したPathメッセージと同じ道をたどることを確認することの一つになります。いくつかのアプローチが実行可能です。
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、特定の利点を有しています。彼らはそれぞれ、リンクのオーバーヘッドと設定の複雑さで、いくつかのコストを持っています。
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最良のメトリックルーティングの特性に依存していることからZまでの経路がHからLへのパスを含み、最良メトリック経路は、その後、すべての道に沿って選択された場合最良メトリック経路がHからしたがって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.
この理由のため、我々は、複数の等コスト・パスが存在し得る場合には、上記トンネリングメカニズムのいずれかを使用することが有利であると考えています。
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.
ドメイン間ルートの場合、異なったE2Eセッションに属するデータトラフィック（同じ集計セッション）に同じアグリゲーターインターフェースを介して凝集領域に入らない可能性があり、及び/又は同じデアグリゲーターインターフェースを介して残さないことができます。私たちが見かけたセッションの両方のための予約情報を見て、いくつかの中央システムでは、この発生を識別できることは可能であるが、我々はトラフィックが一つの方法または他の離れた測定から行ってきましたどのくらいの演繹的に決定することができることは明らかではありません。
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.
私たちは、単にこの問題が発生する可能性があることに注意して実装で許可する必要があります。私たちは、そのような各E2Eの予約はこれが過剰予約含まれていても、その適切な集計予約に加算することをお勧めします。
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 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.
マルチキャストセッションの予約を集約するユニキャストセッションよりもかなり複雑です。最初の課題は、集合予約がなさされるべきデータパケットが続くと同じ経路をたどる集約Pathメッセージの配信のためのマルチキャストツリーを構築することです。これは、データパケットによって取られる経路は、そのソースアドレス、共有ツリーまたはソース固有のツリーの選択、およびツリーのランデブーポイントの位置などの多くの要因に依存し得るという事実によって複雑になります。
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メッセージを配信する問題が解決されると、マルチキャストツリーに沿った各リンクで予約するリソースの正確な量を決定するにはかなりの問題があります。なぜなら凝集マルチキャスト予約で存在することができる不均一の量の、正しくリソースを割り当てるために集合領域内の個々のE2Eの予約に関する情報を保持する必要があると思われます。したがって、我々は実際にマルチキャストセッションのために大幅に保存された状態の量を低下させない集計予約を形成するための手続きの複雑なセットで終わることがあります。
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つの可能なアプローチは、理由は転送パスへの影響を間違いなく最も重要である、唯一の分類とスケジューリング状態の集約に焦点を当てることです。このアプローチは、現在のドラフトで説明したものです。
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.
我々は、これらの予約を集約するとき、我々は一般的に集約レベル1で予約を生産集約レベル0であることがE2EのRSVP予約を検討することができ、レベル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 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.
集約ルータがE2Eパスを受信すると、RSVP-E2Eは、無視するRSVPからプロトコル番号を入れ替え。また、ルータ警告オプションに存在する（現在未使用）である2バイトのフィールドで（この場合は1）アグリゲーションレベルを書き込む必要があります。一般的に、レベルの予約を作成するために、レベルnでの予約を集約ルータN + 1は、ルータアラートフィールドに番号N + 1を書き込みます。レベルN + 1の予約は、IPプロトコル番号RSVP-E2E-IGNOREとのすべてのメッセージを検討するが、メッセージを処理し、唯一のルータアラートフィールド番号N + 1を搬送する場合にRSVPに戻るプロトコル番号を交換しますdeaggregatesルータ。他の値の場合は、メッセージがそのまま転送されます。インテリアのルータは、IPプロトコル番号-IGNORE RSVP-E2Eとのすべてのメッセージを無視します。オプションで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割り当てを必要とします。
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メッセージに対する明示的な確認応答メカニズムのいくつかのフォームから恩恵を受ける集計のコンテキストで発生するさまざまな問題があります。例えば、適切にデアグリゲーターとして機能するように構成されたルータに到達したことがない場合にプロトコルタイプRSVP-E2E-IGNOREのE2E経路は、効果的に「ブラックホール」となるようにルータのセットを構成することが可能です。それは、それはおそらく、その非標準のプロトコル番号のために無視され、その先にすべての道を進むことができます。このような状況を検出することは容易ではありません。アグリゲータは、（以下に詳細に記載されるように）凝集体のPathErrメッセージがデアグリゲーターから受信される場合、この問題は発生していないことを確認することができ。また、E2EのResvを受信した場合に問題がないことを確認することができます。しかし、これらのイベントのどちらが起こったという事実だけで何の受信機がこのセッションのためのリソースを確保することを希望しない、またはRSVPメッセージの損失が発生したこと、またはパスがブラックホールであったことを意味するかもしれないことを意味します。近隣の隣確認応答メカニズムが存在する場合は、アグリゲータがデアグリゲータからE2Eパスの承認を受けることを期待する、と設定の問題が存在していたことを示す指標として、応答の欠如を解釈します。それは、この特定のセッションを集約することを控えることができます。私たちは、このような信頼性のメカニズムは[RFC291]でRSVPのために提案されていることに注意して、それがここで使用することを提案します。
[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]はホップバイホップ認証及び完全性チェックを定義します。本明細書は集約RSVPメッセージには、このチェックの使用を可能にし、また、E2EのRSVPメッセージのためのE2E 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 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].
集約地域外で、任意のE2EのRSVPメッセージは、RSVP隣人が秘密を共有することを前提として鍵付きダイジェスト暗号技術を使用してINTEGRITYオブジェクトが含まれていてもよいです。 E2EのRSVPメッセージが集約地域内のルータによって処理されていないので、アグリゲータおよびデアグリゲータは、互いの論理的なRSVP隣人が表示されます。アグリゲータは、デアグリゲータの前のホップである一方、デアグリゲータは、E2EのRSVPメッセージのためのアグリゲータのネクストホップです。したがって、集約地域を横断するE2EのRSVPメッセージに表示されることがINTEGRITYオブジェクトが内部ルータに対して完全に透過的な方法で集約及びデアグリゲーターの間で直接交換されます。このように、集約領域にわたってE2Eメッセージをチェックするホップバイホップの完全性は、アグリゲータとデアグリゲータは、秘密を共有することが必要です。その秘密を確立するための技術は、[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.
凝集領域内に、任意の集約RSVPメッセージは、集約地域（例えば、アグリゲータと内部ルータ、2つの内部ルータ、内部ルータとデアグリゲーター）内部の対応するRSVP隣人が秘密を共有することを前提としINTEGRITYオブジェクトを含んでいてもよいです。
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.
これまで我々は、集約予約が集約領域外からのE2Eの予約の確立の結果として確立されていることを前提としています。代替のトリガが可能であることは明らかです。 [RFC2998]で説明したように、集約RSVP予約は、RSVPがエンドツーエンドで使用されていない場合でも、差分-SERVクラウドに帯域幅を管理するために使用することができます。
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.
E2Eマイクロフロー予約の非存在下では、アグリゲータは、したがって、それらが凝集予約によって予約されたリソースへのアクセスを得るかどうかを決定する、凝集領域へ通過するパケットのDSCPを設定するポリシーの様々なを使用することができます。これらのポリシーは、DiffServのクラウドのエッジでデバイスのためいつものように、ローカル設定の問題です。
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領域を横切って別のPSTNゲートウェイへのコールのセット（デアグリゲーター）の集計予約を行う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シグナリングと凝集領域におけるデータパケットの取り扱いの観点から、これらの場合には、E2EのRSVP予約を集約する場合に相当します。唯一の違いは、E2EのRSVPシグナリングが行われていないため、トリガとして使用することはできませんので、いくつかの追加の知識が集約予約を設定する際に必要とされることです。
To implement aggregation, we define a number of elements of procedure.
集約を実現するために、我々は、手順の要素の数を定義します。
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.)
非常に最初のイベントは、アグリゲータの外部インタフェースでE2E Pathメッセージの到着です。標準RSVP手順[RSVP]はメッセージが転送されるべきインターフェースのどの組に含め、これに続いています。これらのインタフェースは、ゼロまたはそれ以上の外部インターフェースおよびゼロ以上の内部インターフェイスを含みます。 （内部インターフェイスの数がゼロである場合、ルータは、このE2Eフローのアグリゲータとして機能していません。）
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.
内部インターフェイス上のサービスでは、メッセージは、いくつかの集計予約に含まれる必要があるという事実によって複雑化しているが、デアグリゲータが知られていないので1、それは知られていないこの時点で。したがって、E2E PathメッセージはRSVPは、E2Eは、IGNORE IPプロトコル番号を使用して、内部インターフェース（複数可）に転送されるが、方法と同じ他のすべての点においては、アグリゲーションを行うなかったRSVPルータによって送信されます。
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.
この時点で、E2E Pathメッセージは、ゼロ以上の内部ルータを通過します。インテリアのルータは、内部インターフェイス上のE2E Pathメッセージを受信して、別の内部インターフェイス上でそれを転送します。ルータアラートIPオプションは、内部的にチェックするために内部ルータに警告し、彼らはIPプロトコルRSVP-E2E-IGNOREで、ネクストホップインターフェイスが内部であることがわかります。そのように、彼らは単に通常のIPデータグラムとしてそれを転送します。
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.
E2E Pathメッセージは最終的に内部インターフェイス上で、それを受信して、外部インターフェイス上で、それを転送する解凝集ルータに到着します。ここでも、ルータアラートIPオプションの警告は、メッセージを傍受するために、今回IPプロトコルは、RSVP-E2E-IGNOREで、ネクストホップインターフェイスは、外部インターフェースです。
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.
受信機に向けてE2Eパスを転送する前に、デアグリゲータは、そのADSPECを更新する必要があります。この更新は、流れによってE2Eを達成するのQoSに凝集領域の影響を反映することです。このような情報は、デアグリゲータにアグリゲータから旅行集約PathメッセージのADSPECによって収集することができます。 E2Eパスを転送する前に、集約経路の到着のために、以下に説明したように、ADSPECの正確な更新を可能にするために、解凝集ルータが待機してもよいです。
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.
集合予約へのマッピングE2E予約のポリシーに応じE2Eパスを受信した場合、デアグリゲーターは、以上説明したように、処理されたE2E経路に対するE2Eフローが上にマッピングされようとしているDSCPかを決定する立場にあってもなくてもよいです。デアグリゲーターは、この時点でマッピングを知る位置にある場合、対応するDSCPのための場所に集約パスデアグリゲーター最初にチェックがあること。もしそうなら、デアグリゲータは、E2EパスのADSPECを更新するには、この集約パスのADSPECを使用して、受信機に向けてE2Eパスを転送します。そうでない場合には、デアグリゲーターは、NEW-AGGREGATE-必要とさDCLASSオブジェクト内の符号化された所望のDSCPのエラーコードでE2EのPathErrメッセージを送信することにより、対応する集約パスの確立を要求します。デアグリゲーター他のDSCPの集約予約の同時要求の確立でもよいです。所望のDSCPの集約パスを受信した場合、デアグリゲーターは、次いで、E2E経路のADSPECを更新するには、この集約経路の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.
デアグリゲーターは、この時点でマッピングを知る位置にない場合、デアグリゲーターは、E2E経路ADSPECを更新するために、1つの集約パス又は複数パス集約のADSPECに含まれる情報を使用します。必要集約経路の一つ以上がまだ確立されていない場合は同様に、デアグリゲーターは、NEW-AGGREGATE-必要でそれぞれDCLASSにコードされる所望のDSCPのエラーコードでE2EたPathErrメッセージを送信することにより、対応する集約パスの確立を要求しますオブジェクト。所望のDSCPの集約パスを受信した場合、デアグリゲーターは、次いで、E2E経路のADSPECを更新するには、この集約経路のADSPECを使用します。
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メッセージを開始する集約ルータをもたらすはずです。
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.
解凝集ルータは、RSVPに-E2Eは-IGNORE RSVPからE2E PathメッセージのIPプロトコルを変更し、その意図した宛先に向けてE2E Pathメッセージを転送します。
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.
集約ルータはデアグリゲーターからNEW-AGGREGATE必要に応じたエラーコードでE2EたPathErrメッセージを受信するとDSCPのための新しい集約経路を生成する責任があります。集約パスセッションに含めるDSCP値は、受信されたE2EのPathErrメッセージのDCLASSオブジェクトに見出されます。デアグリゲータ自身のアイデンティティはE2EのPathErrメッセージのERROR仕様で発見されました。集約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手順は、フローのために確立された予約のサイズはパスSENDER_TSPECとのResv FLOW_SPECの最小値に設定されていることを指定します。したがって、集約予約のサイズは、SENDER_TSPECがアグリゲータによって集約経路に含まれるよりも大きくすることができません。集計予約は望ましくない制限なしでデアグリゲータによってサイズにすることができることを保証するために、集約ルータは常にデアグリゲータによって決定され、実際に必要とされるであろう大きさと少なくとも同じ大きさである集約パスSENDER_TSPECに含めるしようとしなければなりません。これを達成する一つの方法は、明らかに、このネットワーク上に支持されていてもよいE2Eの予約の最高負荷より大きいSENDER_TSPECを使用することです。アグリゲータは、フローがDSCPにマッピングされるのを追跡し、常に集約パスSENDER_TSPECに彼らのE2EパスSENDER_TSPECを追加するための別の方法は（そしておそらく将来E2Eの予約を見越して、いくつかの追加の帯域幅を追加）です。
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.
集約ルータは、2つの方法のDSCPへE2Eフローからマッピングが通知されます。集約ルータは、エラーコードNEW-AGGREGATE必要に応じたとE2EのPathErrを受信した場合、まず、集約は、所与のDSCPにマッピングされた（少なくとも一時的に）対応するE2Eフローであることを通知します。 （以下にさらに記載されるように）凝集ルータはDCLASSオブジェクトを含むE2EのResvを受信したときに第二、集約ルータは、対応するE2Eフローが与えられたDSCPにマッピングされることが通知されます。
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.
目的地に向けてE2E Pathメッセージを送った、デアグリゲータは現在のセッションのためにE2EのResvを受け取ることを期待しなければなりません。領収書には、その責任は新しいE2Eの予約をサポートするために、集約領域内に確保十分な帯域幅があることを確認するためのものであり、存在する場合、集約ルータにE2Eた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.
解凝集ルータは最初の集約予約（したがってどのDSCP）の最終的な決定を下すこのE2E予約が上にマッピングされます。この決定は、上述のように、ネットワーク管理者によって選択されたポリシーに従って行われます。
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.
この最終マッピングの決定は、初期E2Eパスを転送するときに行うよりも、アグリゲーターは今E2EパスADSPECのより正確な更新を行うことができるようになっている場合は、デアグリゲータはそうと、正確なADSPECを提供するために、すぐに新しいE2Eパスを生成する必要がありますできるだけ早く受信機への情報。それ以外の場合は、通常の更新手順は、E2Eパスのために従うべきです。
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.
何の集計予約は現在、対応するDSCPと対応する集約ルータから存在しない場合は、次のセクションで説明するように、解凝集ルータは新しい集計予約を確立します。
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.
対応する集約の予約が存在するが（現在はそれにマッピングされたすべての既存のE2Eの予約に加えて）新しいE2E予約を収容するために予約され不十分な帯域幅を有する場合、不十分な帯域幅で配置されている予約のための通常のRSVP手順[RSVP]を従わなければなりません予約をサポートします。また、それは上流送信する集計のResvに含まれていることFLOW_SPECのサイズを増加させることによって帯域幅を供給している集約の予約を増加させる最初の試みをしてもよいです。前のセクションで説明したように、集約ルータはSENDER_TSPECそれが集約パスに含まデアグリゲーターが不必要効果的に防止されないように、デアグリゲーターによって集計のResvで要求されてもよいFLOW_SPECの過剰に常にあることを保証すべきです必要に応じて集計予約の帯域幅を増やします。
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 add the token bucket from the E2E Resv FLOWSPEC object into its internal understanding of how much of the Aggregate reservation is in use.
十分な帯域幅が対応する集計予約に利用可能である場合、解凝集ルータは単に集約ルータにIPプロトコルRSVPとE2E Resvメッセージを送信することができます。このメッセージは、アグリゲータこのE2Eフローのために使用しなければならないDSCPかを示すためにDCLASSオブジェクトを含むべきです。デアグリゲータも使用されているどのくらいの集計予約の、その内部の理解にE2EのResv FLOWSPECオブジェクトからトークンバケットを追加します。
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.
不十分な帯域幅がE2EたResvを処理する時に対応する集合予約に予約されている状況の発生を最小限にするために、ひいてはこの総帯域幅の増加に関連する遅延、デアグリゲーターMAYを回避するために、上述したように現在の需要を予測し、E2Eの予約で先に実際の要件の集計予約サイズを増やします。
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を決定した、デアグリゲーターは、選択されたDSCPとのセッションのために対応する経路状態を探します。集約パスの状態が存在しますが、何の集計のResv状態が存在しない場合、デアグリゲータは、新しい集計の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.
何の集約パスの状態が適切なDSCPのために存在しない場合はデアグリゲータは、以前このE2Eフローのための最終的なマッピングを決定し、すべてのDSCPのための集約パスの状態を確立しないことを選択できなかったので、これであってもよいです。その場合、デアグリゲーターは、NEW-AGGREGATE必要に応じたエラーコードと、必要なDSCPを含むDCLASSとE2EのPathErrを送信することによって、対応する集約パスの確立を要求すべきです。これは、対応する集約パスを確立するアグリゲータの引き金となるでしょう。デアグリゲータは、集約パスの状態が確立されることが決定したら、それは新しい集計の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.
新しい集計したResvのFLOW_SPECは、それがサポートしているE2E予約の要件よりも小さくない値に設定されています。集約のResvは以下に定義される凝集-RSVPセッションおよびフィルタ仕様を使用して、（すなわち、前のホップに）アグリゲータ向けて送信されます。 DSCPは、SESSIONオブジェクトであるため、全くDCLASSオブジェクトは不要です。メッセージは、[RFC2961]にメカニズムを使用して確実に送達されるべきである、あるいは、CONFIRMオブジェクトは、集約のResvが実際に到着しないことを保証するために、使用することができ、許可されています。これは、要求された帯域幅は、それがサポートしE2Eフローに割り当てることが可能であることを決定するためにデアグリゲータを可能にします。
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 anticipate the current demand and create the Aggregate Reservation before receiving E2E Resv messages requiring bandwidth on those aggregate reservations.
該当する集計予約この集約予約の作成に関連する遅延を回避するために、E2EのResvを処理する時に確立されていない、ひいてはされる状況の発生を最小限にするために、デアグリゲーターは、現在の需要を予測し、作成することができますこれらの集約予約の帯域幅を必要とするE2E 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]で定義されるように本質的に同じ方法で処理されます。セッションオブジェクトは、解凝集ルータ（またはマルチキャストの場合のセッションのためのグループアドレス）、セッションのために選択されたDSCPのアドレスを含みます。 FILTERSPECオブジェクトは、集約ルータを識別する。これらのルータは、通常通りアドミッション制御及びリソース割り当てを実行し、アグリゲータに向かって上に集計の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オブジェクトにE2E Resvメッセージの受信は、集合予約へE2E予約のマッピングの集約ルータに最終確認です。通常の状況下では、これはこの協会が通知されます唯一の方法です。今通常のRSVP処理規則[RSVP]以下、その前ホップにE2EたResvを転送しなければなりません。
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.
E2E予約がPathTearを介して通常の方法で除去され、たResvTear、タイムアウト、またはエラー状態の結果として。それらが削除される場合、それらのFLOWSPEC情報も集約予約の割り当てられた部分から除去されなければなりません。これと同じ帯域幅は、近い将来に他のトラフィックのために再使用することができます。 E2Eパスメッセージが削除されると、そのSENDER_TSPEC情報も集約パスから削除する必要があります。
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.
集計予約は（おそらく設定変更、ルート変更、またはポリシーイベントに）離れて行く必要があり、それがサポートするE2Eの予約は、もはや有効ではありません。彼らはそれに応じて処理されなければなりません。
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 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.
所与E2Eフローが与えられた集合体の一部であり、フローのデータは、ポリシーは、このようなために優先どんなによって予約なしトラフィックとして扱われるべきであることを確立する前に。一般的に、これはベストエフォートトラフィックと同じ転送動作を与えられている意味します。しかし、流れが所与の集合体に属していることを確立する際に、集約ルータは、正しいDSCPとの任意の関連するトラフィックをマーキングし、その予約のトラフィックに適切な方法でそれを転送する責任があります。これは、所与のリンク層回路、トンネル、またはMPLSラベルスイッチパス所与のIPネクストホップに転送する、またはそれを配管意味し得ます。
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].
アグリゲータは、E2Eは、それが集約されていることを流れる上ごと予約ポリシングを実行する責任があります。アグリゲータは、対応するE2E予約のためのトークンバケットにコンプライアンスを評価するために、各予約に属するトラフィックの計量を行います。上述したように準拠して評価されるパケットが転送されます。準拠して評価されたパケットは、異なるDSCPに対する再構成またはマークし、ドロップする必要があります。詳細なポリシング動作は、[RFC2998]に記載のサービスマッピングの一態様です。
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.
そのため、上記のマルチキャストセッションを集約の難しさを、私たちは、マルチキャストの場合におけるスケジューリングと分類状態の集約に焦点を当てます。マルチキャストとユニキャストの場合の主な違いはなく、我々はE2Eセッションと同じグループアドレスに「集約」Pathメッセージを送信するマルチキャスト場合には、単一の解凝集ルータのユニキャストアドレスに集約Pathメッセージを送信するよりも、ということです。これは、集約PathメッセージがE2Eパスと同じルートをたどることを保証します。ユニキャストとマルチキャストとの間のこの違いは、以下に定義されるセッションオブジェクトに反映されます。このアプローチの結果は、我々が集約領域内のマルチキャストセッションあたりの予約状態を持ち続けるということです。
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つのインターフェイス上でマルチキャストセッションのためにパケットを転送する必要がありますが、それらのいずれかのインタフェース上で予約要求を受けただけた内部ルータを考えてみましょう。これは、集計の予約のために選ばれた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 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.
第1のアプローチは、それがパケット降格されなければならないフローを認識するために内部ルータでNMF分類を必要とするという欠点があります。第二のアプローチには、予約を受信しなかったインタフェース上のリソースの過剰予約を必要とします。こうした過剰予約がない場合には、「間違った」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分類を行うために、例外として、異種フローのケースを処理することが可能です。これは、内部ルータはこのルータの発信インターフェイス上の異種リソースニーズを持っているそれらの個々のマイクロフローを認識できるようにする必要があり、です。
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であり、こののみルータアラート（パス、PathTear、およびResvConf）を必要E2Eメッセージに使用され、メッセージがなければならないことを意味し、RSVP-E2E-IGNOREの割り当てを必要とします内部インタフェース、及び外部インターフェースを宛先別の方法宛場合一方向に治療すること。プロトコルタイプは、それらが集約地域を入力するときE2Eパス、PathTear、およびResvConfメッセージにRSVP-E2Eは、無視するRSVPからアグリゲータによってスワップされます。プロトコルタイプはから彼らは集約リージョンを終了するときに、このようなE2EメッセージにRSVPにRSVP-E2E-IGNOREデアグリゲータによってバックスワップされます。
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必要に応じた必要とされます。この値は、致命的なエラーが発生したことを意味するものではないが、アクションは、近い将来におけるエラー状態を回避するために、集約ルータに要求されていること。
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].
それは予約が含まれていE2Eデータに使用することを集約セッションの宛先のIPアドレス、およびDSCP：SESSIONオブジェクトは、2つの値が含まれています。ユニキャストセッションでは、セッションの宛先アドレスが解凝集ルータのアドレスです。マルチキャストセッションの場合、セッション先がE2Eセッション（またはセッション）のマルチキャストアドレスが集約されています。セッション中のDSCPを含めることは、それらのDSCPによって区別し、別々にキューに入れられるため、同じアドレスに向けて複数のセッションを可能にします。また、スケジューリングと分類状態を集約するための手段を提供します。セッションのPHBのペアを使用する場合（例えば、AF11及びAF12）において、DSCPは、数値的に最小のPHB（例えば、AF11）を表すべきである使用しました。これは、[BRIM]で説明したのと同じ命名規則に従います。
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オブジェクト：クラス= SESSION、C型= RSVP-AGGREGATE-IP4
+-------------+-------------+-------------+-------------+
| IPv4 Session Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| /////////// | Flags | ///////// | DSCP |
+-------------+-------------+-------------+-------------+
o IP6 SESSION object: Class = SESSION, C-Type = RSVP-AGGREGATE-IP6
O IP6セッション・オブジェクト：クラス= SESSION、C型= RSVP-AGGREGATE-IP6
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Session Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| /////////// | Flags | ///////// | DSCP |
+-------------+-------------+-------------+-------------+
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オブジェクト：クラス= SENDER_TEMPLATE、C型= RSVP-AGGREGATE-IP4
+-------------+-------------+-------------+-------------+
| IPv4 Aggregator Address (4 bytes) |
+-------------+-------------+-------------+-------------+
o IP6 SENDER_TEMPLATE object: Class = SENDER_TEMPLATE, C-Type = RSVP-AGGREGATE-IP6
O IP6 SENDER_TEMPLATEオブジェクト：クラス= SENDER_TEMPLATE、C型= RSVP-AGGREGATE-IP6
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Aggregator Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
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.
要するに、理想的な状態は、集約予約は常にそのサポートを必要とするE2Eの予約に割り当てるための十分なリソースを持っているし、あまりを要したことがないということです。簡単に言えば、しかし、達成するのがより難しいです。アカウントに来る要因が日周サイクルで重要な回を含める：1は、多くの人々が、7時から8時まで時間が死んで穏やかであるにもかかわらず、午前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:
我々は、この線に沿って政策何かをお勧めします。任意の時点で、1は、集約の予約のために必要な帯域幅の量は、次の大きいことを期待してください：
(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）は、特定の曜日や時間帯にそのような概日周期の履歴などから演繹的に、既知の要件、および
(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分間隔または時間ごとに理想的におそらく数分ごとよりも何より頻繁に行われていない、とされることを期待しています。細かい粒度、必要なシグナリングのより高いレベル、粗い粒度、エラーの大きなチャンス、そしてそのエラーから回復する必要があります。
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.
一般的に、我々は、集約の予約が今までそれがサポートしている予約の正確合計にならないだろうが、むしろその値を超えたいくつかのブロックの予約サイズの整数倍になることを期待しています。
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に、特定の一つのセキュリティの問題が集約地域を横断する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プロトコル番号の悪意のある変更のリスクを軽減する一つの方法は、IPヘッダの悪意のある変更が検出されたことを保証するIPsec認証ヘッダを使用することです。これは望ましい方法であるが、認証のための鍵管理の形でいくつかの管理負担を課します。
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パス、PathTear、およびResvConfメッセージのIPプロトコル番号の変更をサポートすることが推奨されます。これは、IPプロトコル番号の変更のための一般的な機能が利用できるようにすべきではないです。
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プロトコル番号の不適切な変更のリスクを認識しておく必要があり、適切な手順（物理的なセキュリティ、パスワード保護など）を取るべきであるルータが攻撃者によって構成されることができるというリスクを減らすためにプロトコル番号の悪質な変更を実行します。
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は、ネットワークコア内のルータが表示されるメッセージを識別するために使用される新しいプロトコルタイプ、RSVP-E2E-IGNOREを、提案しています。 1.2節に記載されているようなメッセージのさらなる処理は、または、出力インターフェイスのタイプに応じて、必要とされなくてもよいです。 IANAは、標準化過程公開基準を満たす、[RFC2780]に従って、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は、ルータ警告は、本質的に、凝集のネストの深さの単純なカウンタであり、本明細書の文脈で使用される方法を記載しています。 IPv4ルーター警告[RFC2113]は、単純に、インターセプトデータグラムのプロトコルタイプを見て、それをどうするかを決定するためにルータを依頼するオプションがあります。パラメータは、その決定に追加情報です。 IPv6ルーター警告[RFC2711]はオプションサブタイプにパラメータを回します。その結果、IPv6ルータ警告オプションは、問題のプロトコルの文脈でアルゴリズムを使用することはできません。 IANAは、我々は32個のレベルが十分であることを期待して、ネストの深さ0..31にマッピングすることができる32の値（3-35、「集約予約ネストレベル」）のブロックを割り当てます。
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は、NEW-AGGREGATE必要に応じたにRSVPパラメータエラーコード26が割り当てられています。
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は、アグリゲータのアドレスに指定する二つの新しい一般的なC-タイプが割り当てられています。 RSVP-AGGREGATE-IP4は、C型9とRSVP-AGGREGATE-IP6はIANA RSVPクラス名、クラス番号とクラスの型レジストリにこれらのC-タイプを追加するにはC型10で、彼らのために同じ番号がすべてで使用されています[RSVP]にIPv4およびIPv6アドレスのタプルのために行われているように三つのクラス、。
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、スティーブ・ベルソン、およびアンドレアスTerzisで発表された文書と議論が著しく、この文書に貢献することを認めます。デザインは、RSVPトンネルドキュメント[TERZIS]の影響を受けています。
APPENDIX 1: Example Signalling Flow For First E2E Flow
付録1：まずE2Eフローのための例シグナリングフロー
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.
この付録では、追加の仕様を提供していません。それだけアグリゲータ/デアグリゲーターの所与の対の間で最初にユニキャストE2E予約の成功確立に関与RSVPシグナリングメッセージの可能フローを上記詳細な仕様を示します。
Aggregator 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
<--------------- (1) Aggregator forwards E2E Path into aggregation region after
modifying its IP Protocol Number to RSVP-E2E-IGNORE
(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）のは、何の集約パスが存在しないと仮定しましょう。正確E2EパスのADSPECを更新できるようにするには、デアグリゲータは、集計PATHのADSPECを必要とします。この例では、デアグリゲータは、各DSCPのための新しい-AGG-必要なのPathErrコードを送信することにより、2つのサポートのDSCPのための集約パスの状態を設定するアグリゲータに指示することを選択します。
(3) The Aggregator follows the request from the Deaggregator and signals an Aggregate Path for both DSCPs.
（3）集約はデアグリゲーターからの要求に従い、両方のDSCPの集約パスの信号。
(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）デアグリゲーターを考慮両方集約パスからADSPECに含まれる情報を取得し、それに応じてE2EパスADSPECを更新します。デアグリゲータはまた、それを転送する前に、RSVPにE2EパスIPプロトコル番号を変更します。
(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）本例では、デアグリゲーターは直ちに両方のDSCPの集約予約の確立を続行することを選択します。実際には、デアグリゲーターは、E2EのResv要求がE2Eの予約の確立を高速化するために到着したときにリソースが集約予約に利用可能であるように、E2Eの予約の実際の需要を予想として見ることができます。デアグリゲータは、これらの集計のResvではオプションのResv確認要求が含まれていることも前提としています。
(6) The Aggregator merely complies with the received ResvConfirm Request and returns the corresponding Aggregate ResvConfirm.
（6）集約は、単に受信ResvConfirm要求に準拠し、対応する集約ResvConfirmを返します。
(7) The Deaggregator has explicit confirmation that both Aggregate Resv are established.
（7）デアグリゲーターは、両方の集合の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）E2EたResvを受信すると、デアグリゲーターは、集合予約にE2EたResvをマッピングするために、ネットワーク管理者によって定義されたマッピングポリシーを適用します。のは、このポリシーはE2Eの予約がDSCP = xでと集計予約上にマッピングされるようなものであると仮定しよう。デアグリゲータは、集約の予約（7）ので、対応するDSCPのための場所であることを知ります。デアグリゲータは、DSCP = xでの集計のResvにE2EたResvのアドミッション制御を行います。 DSCP = xでの集約のResvがE2EたResvをサポートするのに十分な帯域幅を用いて確立された、デアグリゲーターが集合予約に未使用の帯域幅を追跡し、そのカウンタを調整し、選択されたマッピングを搬送DCLASSオブジェクトを含むアグリゲータにE2EたResvを転送すると仮定するとDSCP = xで上へ。
(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）アグリゲータは、DSCP = xで上E2EたResvのマッピングを記録します。アグリゲータはDCLASSオブジェクトを削除し、送信者に向けてE2EのResvを転送します。
APPENDIX 2: Example Signalling Flow For Subsequent E2E Flow Without Reservation Resizing
付録2：予約リサイズすることなく、次のE2Eフローのための例シグナリングフロー
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.
この付録では、追加の仕様を提供していません。それだけアグリゲータ/デアグリゲーターの所与の対の間に他のE2E予約を次のユニキャストE2E予約の成功確立に関与RSVPシグナリングメッセージの可能フローを上記詳細な仕様を示します。この流れは、付録1に示されたメッセージの流れを次のように想像することができます。
Aggregator Deaggregator
アグリゲータデアグリゲータ
E2E Path
---------------->
(10)
E2E Path
------------------------------->
(11)
E2E Path
----------->
E2E Resv
<-----------
(12)
E2E Resv (DCLASS=x)
<-----------------------------
(13)
E2E Resv
<---------------
(10) Aggregator forwards E2E Path into aggregation region after modifying its IP Protocol Number to RSVP-E2E-IGNORE
そのIPプロトコル番号はRSVP-E2Eは、無視するように変更した後の凝集領域に（10）アグリゲータ転送E2E経路
(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.
前回のE2Eの予約が確立されているので（11）、の集計パスがサポートされているすべてのDSCPのために存在すると仮定しましょう。デアグリゲータは、アカウントに集約パスからADSPECに含まれる情報を受け取り、それに応じE2EパスADSPECを更新します。デアグリゲータはまた、それを転送する前に、RSVPにE2EパスIPプロトコル番号を変更します。
(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 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.
（12）E2EたResvを受信すると、デアグリゲーターは、集合予約にE2EたResvをマッピングするために、ネットワーク管理者によって定義されたマッピングポリシーを適用します。のは、このポリシーはE2Eの予約がDSCP = xでと集計予約上にマッピングされるようなものであると仮定しよう。前回のE2Eの予約が確立されているので、のは、集計予約がDSCP = xでのための場所であると仮定しましょう。デアグリゲータは、DSCP = xでの集計のResvにE2EたResvのアドミッション制御を行います。集約のResvはDSCPのため= xは新しいE2EたResvをサポートするのに十分な未使用の帯域幅を有する、デアグリゲーターは、次に集約の予約に未使用の帯域幅を追跡し、そのカウンタを調整し、選択されたマッピングを搬送DCLASSオブジェクトを含むアグリゲータにE2EたResvを転送すると仮定するとDSCP = xで上へ。
(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）アグリゲータは、DSCP = xで上E2EたResvのマッピングを記録します。アグリゲータはDCLASSオブジェクトを削除し、送信者に向けてE2EのResvを転送します。
APPENDIX 3: Example Signalling Flow For Subsequent E2E Flow With Reservation Resizing
付録3：予約のサイズ変更によるその後のE2Eフローのための例シグナリングフロー
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.
この付録では、追加の仕様を提供していません。それだけアグリゲータ/デアグリゲーターの所与の対の間に他のE2E予約を次のユニキャストE2E予約の成功確立に関与RSVPシグナリングメッセージの可能フローを上記詳細な仕様を示します。この流れは、付録2に示されたメッセージの流れを次のように想像することができます。
Aggregator Deaggregator
アグリゲータデアグリゲータ
E2E Path
---------------->
(14)
E2E Path
------------------------------->
(15)
E2E Path
----------->
E2E Resv
<-----------
(16)
AggResv (DSCP=x, increased Bw)
<-------------------------------
(17)
AggResvConfirm (DSCP=x, increased Bw)
------------------------------>
(18)
E2E Resv (DCLASS=x)
<-----------------------------
(19)
E2E Resv
<---------------
(14) Aggregator forwards E2E Path into aggregation region after modifying its IP Protocol Number to RSVP-E2E-IGNORE
そのIPプロトコル番号はRSVP-E2Eは、無視するように変更した後の凝集領域に（14）アグリゲータ転送E2E経路
(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.
前回のE2Eの予約が確立されているので（15）、の集計パスがサポートされているすべてのDSCPのために存在すると仮定しましょう。デアグリゲータは、アカウントに集約パスからADSPECに含まれる情報を受け取り、それに応じE2EパスADSPECを更新します。デアグリゲータはまた、それを転送する前に、RSVPにE2EパスIPプロトコル番号を変更します。
(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）E2EたResvを受信すると、デアグリゲーターは、集合予約にE2EたResvをマッピングするために、ネットワーク管理者によって定義されたマッピングポリシーを適用します。のは、このポリシーはE2Eの予約がDSCP = xでと集計予約上にマッピングされるようなものであると仮定しよう。前回のE2Eの予約が確立されているので、のは、集計予約がDSCP = xでのための場所であると仮定しましょう。デアグリゲータは、DSCPの= xに対してAGGのResvにE2EたResvのアドミッション制御を行います。のは、DSCP = xの集計のResvが新しいE2EのResvをサポートするのに十分な未使用の帯域幅を持っていないと仮定しましょう。ザ・
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.
(17) The Aggregator merely complies with the received ResvConfirm Request and returns the corresponding Aggregate ResvConfirm.
（17）集約は、単に受信ResvConfirm要求に準拠し、対応する集約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）デアグリゲーターは、集約のResvが正常に増加していることを明示的な確認を有しています。デアグリゲータは、再度のDSCP = xの増加集約予約へE2EたResvのアドミッション制御を実行します。 DSCP = xで用が増加集計予約は今、新しいE2EのResvをサポートするのに十分な未使用の帯域幅とリソースを持っていると仮定すると、デアグリゲータは、集計予約に未使用の帯域幅を追跡し、そのカウンタを調整し、DCLASSオブジェクトを含むアグリゲータにE2EたResvを転送しますDSCP = xで上に選択されたマッピングを搬送します。
(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）アグリゲータは、DSCP = xで上E2EたResvのマッピングを記録します。アグリゲータはDCLASSオブジェクトを削除し、送信者に向けてE2Eの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でを。 SIGCOMM'92、1992年9月。
[IP] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[IP]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[HOSTREQ] Braden, R., "Requirements for Internet hosts - communication layers", STD 3, RFC 1122, October 1989.
【HOSTREQ]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[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分野）の定義"、RFC 2474、1998年12月。
[PRINCIPLES] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[原則]大工、B.、 "インターネットの建築原則"、RFC 1958、1996年6月。
[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グループ"、RFC 2597、1999年6月[ASSURED]。
[BROKER] Jacobson, V., Nichols K. and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", RFC 2638, June 1999.
[BROKER]ジェーコブソン、V.、ニコルズK.とL.チャン、「インターネットのための2ビットの差別化サービスアーキテクチャ」、RFC 2638、1999年6月。
[BRIM] Brim, S., Carpenter, B. and F. LeFaucheur, "Per Hop Behavior Identification Codes", RFC 2836, May 2000.
【BRIM】つば、S.、大工、B.およびF. LeFaucheur、 "当たりホップ行動識別コード"、RFC 2836、2000年5月。
[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機能仕様"、RFC 2205、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.チャン、 "RSVPオペレーションオーバーIPトンネル"、RFC 2746、2000年1月。
[DCLASS] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000.
[DCLASS] Bernet、Y.、 "RSVP DCLASSオブジェクトのフォーマット"、RFC 2996、2000年11月。
[INTEGRITY] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
【INTEGRITY]ベーカー、F.、リンデル、B.及びM. Talwar、 "RSVP暗号化認証"、RFC 2747、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ネットワーク"、RFC 2998、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. Tommasi、 "RSVPのリフレッシュ削減機能拡張"、RFC 2961、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.とV.パクソン、「インターネットプロトコルと関連ヘッダーの値のためのIANA配分ガイドライン」、RFC 2780、2000年3月。
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[RFC2711]ウズラ、C.とA.ジャクソン、 "IPv6のルータアラートオプション"、RFC 2711、1999年10月。
[RFC2113] Katz, D. "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113]カッツ、D. "IPルータアラートオプション"、RFC 2113、1997年2月。
Authors' Addresses
著者のアドレス
Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, CA, 93117 USA
フレッドベイカーシスコシステムズ1121ヴィアデル・レイサンタバーバラ、CA、93117 USA
Phone: (408) 526-4257 EMail: fred@cisco.com
電話：（408）526-4257 Eメール：fred@cisco.com
Carol Iturralde Cisco Systems 250 Apollo Drive Chelmsford MA, 01824 USA
キャロルIturraldeシスコシステムズ250アポロドライブチェルムズフォードMA、01824 USA
Phone: 978-244-8532 EMail: cei@cisco.com
電話：978-244-8532 Eメール：cei@cisco.com
Francois Le Faucheur Cisco Systems Domaine Green Side 400, Avenue de Roumanille 06410 Biot - Sophia Antipolis France
フランソワ・リーパーシスコシステムズのドメイングリーンサイド400アベニューRoumanille 06410ビオ - ソフィアアンティポリス、フランス
Phone: +33.4.97.23.26.19 EMail: flefauch@cisco.com
電話：+33.4.97.23.26.19 Eメール：flefauch@cisco.com
Bruce Davie Cisco Systems 250 Apollo Drive Chelmsford MA,01824 USA
ブルース・デイビーシスコシステムズ250アポロドライブチェルムズフォードMA、01824 USA
Phone: 978-244-8921 EMail: bdavie@cisco.com
電話：978-244-8921 Eメール：bdavie@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。