[要約] RFC 3175は、IPv4およびIPv6のRSVP予約の集約に関する標準化された手法を提供しています。このRFCの目的は、ネットワークリソースの効率的な利用と管理を可能にすることです。
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
IPv4およびIPv6予約のRSVPの集約
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.
Copyright（c）The Internet Society（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」）と呼び、それぞれのPATH/RESVメッセージをE2E PATH/RESVメッセージと呼びます。より大きな予約（多くのE2E予約を表すもの）を「集約」予約と呼び、それぞれのPATH/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.
ただし、集約は独自の課題をもたらします。特に、個々のフロー間の分離レベルを低下させ、ある流れが別のフローのバーストから遅れをとる可能性があることを意味します。異なるフローからのバーストの同期が発生する可能性があります。ただし、フローの凝集はフローの平均遅延に悪影響を及ぼさず、実際に遅延分布の「テール」の遅延の減少につながることを示唆する証拠があります（たとえば、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.
私たちが提案するソリューションには、「集約領域」を横切り、共通のイングレスと出口ルーターをイングレスから出口までの1つの大きな予約に共有するいくつかの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プロトコル番号は、集約領域に入るとRSVP（46）からRSVP-E2E-IGNORE（134）に変更され、ディーグレジェレジェーターポイントでRSVPに復元されました。。これらのメッセージは無視されます（状態はありませんが、メッセージは、インテリアインターフェイスに転送されるたびに、集約領域内の各ルーターによって、メッセージが通常のIPデータグラムとして転送されます）。Deaggregating Routerは、そのようなメッセージに対する以前の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およびFlowsPecs）は、集約パスおよびRESVメッセージの対応する情報要素に合計されます。集約パスメッセージは、RSVPの通常のIPプロトコル番号を使用して、アグリゲーターからDeaggregatorに送信されます。集約RESVメッセージは、DeaggregatorからAggregatorに送り返され、このアグリゲーターとDeaggregatorを使用する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予約の数とは無関係であるだけでなく、集約領域の総留保の数とは無関係です。1つ以上のDIFF-SERV DSCPは、総予約でカバーされているトラフィックを識別するために使用され、1つまたは複数のDIFSERV-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メッセージが1つ以上のインテリアインターフェイスを通過するRSVP対応ルーターのセットとして定義します（これおよび場合によってはセット内の他のルーターの場合）最終的に外部インターフェイスを横断する前に。
Such an E2E RSVP message is said to have crossed the aggregation region.
このようなE2E RSVPメッセージは、集約領域を越えたと言われています。
We define the "aggregating" router for this E2E flow as the first router that processes the E2E Path message as it enters the aggregation region (i.e., the one which forwards the message from an exterior interface to an interior interface).
このE2Eフローの「集約」ルーターを、Aggregation領域（つまり、外部インターフェイスからインテリアインターフェイスにメッセージを転送する）に入るときに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フロー上の執gegregator、さらに他のフローのインテリアルーターとして機能する可能性があることに注意してください。
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がセッションを集約する方法を特定しなかった理由の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の色、または同様の管理コンポーネントが、同じクラスのすべての集約されたトラフィックに対して確保されており、そのために割り当てられたトラフィックを運ぶのに十分な帯域幅が利用可能であると仮定します。この帯域幅は、同じクラスに割り当てられた集計された予約トラフィックの総額に基づいて調整できます。
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が集約された予約を運ぶために使用される場合でも、同じネットワークでプロビジョニングされたdiff-servと凝集したRSVPが使用される環境に注意を払う必要があります。そのPHBに割り当てられた容量。これに対する解決策の1つは、プロビジョニングされたDIFF-Serv（AF2、AF3、AF4クラスなど）に他のPHBを使用しながら、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.
集約領域内では、いくつかのRSVP予約状態が集約予約ごとに維持されますが、分類とスケジューリング状態（たとえば、トラフィックの分類に使用されるDSCP）は、集計ごとの予約クラスベースではなく（集約予約あたりではなく）維持されます。たとえば、保証されたサービス予約が集約領域全体で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.
アグリゲーターの決定は些細なことです。PATHメッセージが外部インターフェイス上のルーターに到着し、内部インターフェイスに転送する必要がある場合、E2Eフローがアグリゲーターに到着したことを知っています。
Determination of the deaggregator is more involved. If an SPF routing protocol, such as OSPF or IS-IS, is in use, and if it has been extended to advertise information on Deaggregation roles, it can tell us the set of routers from which the deaggregator will be chosen. In principle, if the aggregator and deaggregator are in the same area, then the identity of the deaggregator could be determined from the link state database. However, this approach would not work in multi-area environments or for distance vector protocols.
Deaggregatorの決定がより関与しています。OSPFやIS-ISなどのSPFルーティングプロトコルが使用されている場合、Deaggregationの役割に関する情報を宣伝するために拡張されている場合、Deaggregatorが選択されるルーターのセットを知ることができます。原則として、アグリゲーターとDeaggregatorが同じ領域にある場合、DeaggregatorのIDはLink Stateデータベースから決定できます。ただし、このアプローチは、マルチエリア環境や距離ベクトルプロトコルでは機能しません。
One method for Deaggregator determination is manual configuration. With this method the network operator would configure the Aggregator and the Deaggregator with the necessary information.
Deaggregatorの決定の1つの方法は、手動構成です。この方法により、ネットワーク演算子は、必要な情報をアグリゲーターとDeaggregatorに設定します。
Another method allows automatic Deaggregator determination and corresponding Aggregator notification. When the E2E RSVP Path message transits from an interior interface to an exterior interface, the deaggregating router must advise the aggregating router of the correlation between itself and the flow. This has the nice attribute of not being specific to the routing protocol. It also has the property of automatically adjusting to route changes. For instance, if because of a topology change, another Deaggregator is now on the shortest path, this method will automatically identify the new Deaggregator and swap to it.
別の方法では、自動掘削装置の決定と対応するアグリゲーター通知が可能になります。E2E RSVPパスメッセージがインテリアインターフェイスから外部界面に通過する場合、Deaggregatingルーターは、それ自体と流れの間の相関の集約ルーターにアドバイスする必要があります。これには、ルーティングプロトコルに固有ではないという素晴らしい属性があります。また、ルートの変更に自動的に調整する特性もあります。たとえば、トポロジの変更のために、別のDeaggregatorが最短のパスにある場合、この方法は新しいDeaggregatorを自動的に識別し、それに交換します。
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.
上記で説明したように、同じアグリゲーター/Deaggregatorペアの間に複数の集計予約がある場合があります。E2Eの予約を集約的な予約にマッピングするためのルールは、ネットワーク環境とネットワーク管理者の目標に依存するポリシー決定です。このようなポリシーは、この仕様の範囲外であり、そのようなポリシーはネットワーク管理者によって定義されていると単純に仮定します。また、そのようなポリシーはアグリゲーター/ディーグレジャーターが何らかの形でアクセスできると仮定しますが、このポリシーがどのようにアグリゲーター/ディーグレジャーター（ローカル構成、警官、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予約が、特定のアグリゲーター/Deaggregatorのペア間の単一の集計予約（つまり、単一の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 RESVでシグナル）に要求されたINT-SERVサービスタイプを考慮したポリシーの別の例は、保証されたサービスE2E予約が集約領域の1つのDSCPにマッピングされ、制御された負荷E2E予約がマッピングされる場所です。別の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 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予約を集約予約にマッピングする決定が行われる場所と、この決定がアグリゲーターとDeaggregatorの間でどのように伝えるかについては、さまざまなオプションが考えられます。アグリゲーターとDeaggregatorの両方が、そのような決定を独立して行うと想定される可能性があります。ただし、これには、一貫性のないマッピング決定を解決するための追加の手順の定義が必要です（つまり、アグリゲーターとDeaggregatorは、特定の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.
単純さと信頼性のために、マッピング決定の責任をDeaggregatorに完全に割り当てます。アグリゲーターには、Deaggregatorが選択したマッピングが通知され、この決定に従います。Deaggregatorは、アグリゲーターではなく選択されました。なぜなら、Deaggregatorは、そのような決定を下すために必要なすべての情報に最初にアクセスできるため（特に、要求された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パスメッセージのADSPECは、集約領域を移動するため、更新されません。したがって、フローのDeaggregatorは、対応するE2EパスのADSPECを更新して、エンドツーエンドで達成される可能性のあるQOSに対する集約領域の影響を反映する責任があります。Deaggregatorは、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.
集約パスメッセージは集約領域内で処理されるため、ADSPECは内部ルーターによって更新され、内部領域内で達成されるQoSに対する集約領域の影響を反映しています。したがって、Deaggregatorは、利用可能な総合的なパスからADSPECに含まれる情報を利用する必要があります。Deaggregatorは、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.
Deaggregatorが利用できる情報を最大化するために、アグリゲーターが集約パスを信号するたびに、アグリゲーターには、アグリゲーション領域でサポートされているすべてのサービスタイプのフラグメントを含むADSPECを含める必要があります（集約パスが集計パスがAのみをサポートするだけであっても、これらのサービスタイプのサブセット）。すべての可能なサービスタイプに対してこの情報をDeaggregatorに提供することは、Deaggregatorによる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予約を集約予約にマッピングするためのポリシーに応じて、E2EパスADSPECを正確に更新するために、Deaggregatorは次のようになります。
- update all the E2E Path ADSPEC segments (Default General Parameters Fragment, Guaranteed Service Fragment, Controlled-Load Service Fragment) based on the ADSPEC of a single Aggregate Path, or
- 単一の集計パスの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).
- 複数の集約パスメッセージからADSPECを考慮してE2EパスADSPECを更新します（例：。すべての集計パスのADSPECの各パラメーターの「最悪」値を使用してデフォルトの一般的なパラメーターフラグメントを更新し、保証されたサービスフラグメントを更新します保証されたサービスに使用される予約のための集約パスの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に含まれる情報を考慮に入れることにより、Deaggregatorはほとんどの状況で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:
ただし、DeaggregatorがE2E Path 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).
- dif-serv ealareルーティングは集約領域で使用されるため、異なるDSCPを持つパケットは異なるパスに従います（たとえば、異なるMPLSラベルスイッチパスで送信します）。
As a result, the ADSPEC for the aggregate reservation that supports guaranteed service may differ from the ADSPEC for the aggregate reservation that supports controlled load.
その結果、保証されたサービスをサポートする集約予約のADSPECは、制御された負荷をサポートする集約予約のADSPECとは異なる場合があります。
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を含むADSPECを含むE2Eパスを送信すると仮定します。次に、E2E ADSPECを更新する時点で、Deaggregatorはレシーバーによって実際にどのサービスタイプが要求されるかを知らないため、どのPHBがこのE2Eフローを輸送するために使用され、適切なパラメーターを選択できないかがわかりません。デフォルトの一般的なパラメーターフラグメントを更新するときに考慮する値。上記のように、この特定のケースでは、保守的なアプローチは、すべてのパラメーターで常に最悪の値を考慮することです。この保守的なアプローチに従うか、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の完全に正確な更新がすべての状況で不可能である可能性があることを認識して、そのような状況で保守的なアプローチをとることをお勧めします（過剰な最適ではなく、過度の絶滅的な）ことをお勧めします。。上記の例では、これは、Deaggregatorが受信機からE2E RESVを受信するとすぐに、Deaggregatorが実際に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ソースと宛先アドレスが含まれていることがわかります。ただし、現在、集計から掘削ルーターにパスメッセージを送信することで集約予約を行っているため、予約された（E2E）データパケットは、関連する（集計）パスメッセージと同じIPアドレスを運ぶことはありません。この問題は、予約されたフローのデータパケットが、集約予約のためにパス状態を確立したパスメッセージと同じパスに従うことを確認することの1つになります。いくつかのアプローチが実行可能です。
First, the data may be tunneled from aggregator to deaggregator, using technologies such as IP-in-IP tunnels, GRE tunnels, MPLS label-switched paths, and so on. These each have particular advantages, especially MPLS, which allows traffic engineering. They each also have some cost in link overhead and configuration complexity.
まず、IP-in-IPトンネル、GREトンネル、MPLSラベルスイッチパスなどのテクノロジーを使用して、データをアグリゲーターからDeaggregatorにトンネル化できます。これらにはそれぞれ、特に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最良のメトリックルーティングの特性に依存しています。これは、Aから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.
このため、複数の等コストパスが存在する場合に、上記のトンネルメカニズムの1つを使用することが有利であると考えています。
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.
ドメイン間ルートのケースは、今説明したドメイン内ケースとは多少異なります。具体的には、ルーティングはルーティングポリシーと単純な最良のメトリックではなくパスとしての最短の組み合わせによるものであるため、最良のパスの考慮事項は適用されません。
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.
マルチキャストセッションの予約の集約は、ユニキャストセッションよりもはるかに複雑です。最初の課題は、集約予約が行われるデータパケットが続くのと同じパスに続く集約パスメッセージの配布のためにマルチキャストツリーを構築することです。これは、データパケットがとるパスが、そのソースアドレス、共有ツリーまたはソース固有の木の選択、ツリーのランデブーポイントの位置など、多くの要因に依存する可能性があるという事実によって複雑になっています。
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.
集約パスメッセージを配布する問題が解決されると、マルチキャストツリーに沿った各リンクに予約するための正しい量のリソースを決定する際にかなりの問題があります。集約されたマルチキャスト予約に存在する可能性のある不均一性の量のため、集約領域内の個々の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.
E2E RSVPの予約は集約レベル0であると考えることができます。これらの予約を集約すると、集約レベル1で予約を作成します。一般に、レベルNの予約を集約してレベルn 1で予約を形成できます。
When an aggregating router receives an E2E Path, it swaps the protocol number from RSVP to RSVP-E2E-IGNORE. In addition, it should write the aggregation level (1, in this case) in the 2 byte field that is present (and currently unused) in the router alert option. In general, a router which aggregates reservations at level n to create reservations at level n+1 will write the number n+1 in the router alert field. A router which deaggregates level n+1 reservations will examine all messages with IP protocol number RSVP-E2E-IGNORE but will process the message and swap the protocol number back to RSVP only in the case where the router alert field carries the number n+1. For any other value, the message is forwarded unchanged. Interior routers ignore all messages with IP protocol 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からRSVP-E2Eイグノアに交換します。さらに、ルーターアラートオプションに存在する（および現在使用されていない）2バイトフィールドに集約レベル（1、この場合）を記述する必要があります。一般に、レベルnで予約を集約してレベルn 1で予約を作成するルーターは、ルーターアラートフィールドに数n 1を書き込みます。レベルn 1の予約をディーグレジャーするルーターは、IPプロトコル番号RSVP-E2Eイノーレですべてのメッセージを調べますが、メッセージを処理し、プロトコル番号をRSVPに戻し、ルーターアラートフィールドに数がn 1を運ぶ場合のみ、RSVPに戻ります。その他の価値、メッセージは変更されていません。インテリアルーターは、IPプロトコル番号rsvp-e2e-igroreですべてのメッセージを無視します。集約のレベルの数を考えると、オプション内の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パスが効果的に「ブラックホール」になるように、ルーターのセットを構成することができます。その後、標準以外のプロトコル番号のためにおそらく無視される可能性のある目的地までずっと移動する可能性があります。この状況を検出するのは簡単ではありません。アグリゲーターは、Deaggregatorから集計Patherrメッセージが受信された場合、この問題が発生していないことを確認できます（以下で詳しく説明するように）。また、E2E RESVを受信しても問題がないことを確認できます。ただし、これらのイベントのいずれも発生していないという事実は、このセッションのためにリソースを予約することを希望しないこと、またはRSVPメッセージの損失が発生したこと、またはパスが黒穴であったことを意味する可能性があるということだけを意味するかもしれません。ただし、隣人から隣人の謝辞メカニズムが存在する場合、アグリゲーターはDeaggregatorから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の隣人が秘密を共有すると仮定するキー付き暗号化ダイジェスト技術を使用した整合性オブジェクトが含まれている場合があります。E2E RSVPメッセージは集約領域のルーターによって処理されないため、アグリゲーターとDeaggregatorは互いの論理RSVPネイバーとして表示されます。Deaggregatorは、AggregatorがE2E RSVPメッセージの次のホップであり、アグリゲーターはDeaggregatorの以前のホップです。その結果、集約領域を通過するE2E RSVPメッセージに表示される可能性のある完全性オブジェクトは、インテリアルーターに完全に透過的な方法で、アグリゲーターとディーグレジャーの間で直接交換されます。したがって、集約領域でE2Eメッセージをホップバイホップ整合性チェックするには、アグリゲーターとDeaggregatorが秘密を共有する必要があります。その秘密を確立するためのテクニックは、[整合性]で説明されています。
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メッセージには、集約領域内の対応するRSVPネイバー（アグリゲーターとインテリアルーター、2つのインテリアルーター、インテリアルーターとディーグレジェーター）が秘密を共有すると仮定する整合性オブジェクトを含む場合があります。
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予約を使用してDiff-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.
代替構成の最も単純な例は、入り口（アグリゲーター）ルーターから出口（脱アグゲーター）ルーターへのトラフィックの一定量の集約予約の静的構成です。これは、少なくとも集約パスメッセージ（アグリゲーター）を発信するシステムで構成する必要があります。Deaggregatorは、パスメッセージがそれに向けられていることを検出し、そのようなメッセージを「ターンアラウンド」するように構成できます。つまり、RESVでアグリゲーターに戻ります。または、集約予約の構成は、アグリゲーターとDeaggregatorの両方で実行できます。前と同様に、総予約は、予約容量を使用するトラフィックの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.
「アグリゲーター」は、介在するdiff-serv領域を越えて、別のPSTNゲートウェイ（deaggregator）への一連の呼び出しを集計する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パスメッセージが到着することです。これについては、標準の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.
インテリアインターフェイスでのサービスは、メッセージを何らかの総予約に含める必要があるという事実によって複雑になりますが、この時点では、Deaggregatorが不明であるため、どちらが不明です。したがって、E2Eパスメッセージは、IPプロトコル番号rsvp-e2e-igroreを使用して内部インターフェイスに転送されますが、凝集を実行していない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パスメッセージはゼロ以上の内部ルーターを通過します。インテリアルーターは、インテリアインターフェイスでE2Eパスメッセージを受信し、別のインテリアインターフェイスに転送します。ルーターアラート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パスメッセージは、最終的にディーグレギングルーターに到着し、内部インターフェイスで受信し、外部インターフェイスに転送します。繰り返しますが、Router Alert IPオプションはメッセージをインターセプトするようにアラートしますが、今回はIPプロトコルはRSVP-E2Eイグノアであり、次のホップインターフェイスは外部インターフェイスです。
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パスを受信機に向けて転送する前に、DeaggregatorはADSPECを更新する必要があります。このアップデートは、流れによってE2Eを達成するためのQOSへの集約領域の影響を反映するためです。このような情報は、アグリゲーターからDeaggregatorに移動する集約パスメッセージのADSPECによって収集できます。したがって、ADSPECの正しい更新を有効にするために、E2Eパスを転送する前に、凝集パスの到着を以下に説明するように掘削ルーターが待機する場合があります。
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の予約を集約予約にマッピングするためのポリシーに応じて、Deaggregatorは、上記のように、処理されたE2EパスのE2Eフローがどのdscpをマッピングするかを決定する立場にある場合とそうでない場合があります。。Deaggregatorがこの時点でマッピングを知る立場にある場合、Deaggregatorは最初に、対応するDSCPの集計パスがあることを確認します。その場合、Deaggregatorはこの集約パスのADSPECを使用してE2EパスのADSPECを更新し、E2Eパスを受信機に向かって転送します。そうでない場合、Deaggregatorは、e2e PatherrメッセージをNew-Aggregate-NeededのエラーコードとDCLASSオブジェクトにエンコードする目的のDSCPを送信することにより、対応する集約パスの確立を要求します。Deaggregatorは、同時に、他のDSCPの総予約の確立を要求することもできます。目的のDSCPの集約パスを受信すると、Deaggregatorはこの集約パスのADSPECを使用してE2EパスのADSPECを更新します。
If the Deaggregator is not in a position to know the mapping at this point, then the Deaggregator uses the information contained in the ADSPEC of one Aggregate Path or of multiple Aggregate Paths to update the E2E Path ADSPEC. Similarly, if one or more of the necessary Aggregate Paths is not yet established, the Deaggregator requests establishment of the corresponding Aggregate Path by sending an E2E PathErr message with an error code of NEW-AGGREGATE-NEEDED and the desired DSCP encoded in the respective DCLASS Object. When receiving the Aggregate Path for the desired DSCP, the Deaggregator then uses the ADSPEC of this Aggregate Path to update the ADSPEC of the E2E Path.
Deaggregatorがこの時点でマッピングを知る立場にない場合、Deaggregatorは1つの集約パスまたは複数の集約パスのADSPECに含まれる情報を使用して、E2EパスADSPECを更新します。同様に、必要な集計パスの1つ以上がまだ確立されていない場合、Deaggregatorは、それぞれのDClassでエンコードされたNew-Aggregate-Neededおよび希望のDSCPのエラーコードを使用してE2E PATHERRメッセージを送信することにより、対応する集計パスの確立を要求します。物体。目的のDSCPの集約パスを受信すると、Deaggregatorはこの集約パスのADSPECを使用してE2Eパスの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-Neededのエラーコードを使用してE2E PATHERRメッセージを生成すると、パス状態が削除されることはありませんが、次のセクションで説明されているように、必要な集計パスメッセージを集約するルーターを開始することになります。
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.
Deaggregating Routerは、E2E PATHメッセージのIPプロトコルをRSVP-E2E-IGROREからRSVPに変更し、E2Eパスメッセージを意図した宛先に転送します。
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.
集約ルーターは、DEAGGREGATORから必要なエラーコードを使用してE2E PATHERRメッセージを受信するときに、DSCPの新しい集計パスを生成する責任があります。集約パスセッションに含めるDSCP値は、受信したE2E PATHERRメッセージのDCLASSオブジェクトにあります。Deaggregator自体のIDは、E2E PATHERRメッセージのエラー仕様にあります。集約パスメッセージの宛先アドレスは、Deaggregatingルーターのアドレスであり、メッセージはIPプロトコル番号RSVPで送信されます。
Existing RSVP procedures specify that the size of a reservation established for a flow is set to the minimum of the Path SENDER_TSPEC and the Resv FLOW_SPEC. Consequently, the size of an Aggregate Reservation cannot be larger than the SENDER_TSPEC included in the Aggregate Path by the Aggregator. To ensure that Aggregate Reservations can be sized by the Deaggregator without undesired limitations, the Aggregating router should always attempt to include in the Aggregate Path a SENDER_TSPEC which is at least as large as the size that would actually be required as determined by the Deaggregator. One method to achieve this is to use a SENDER_TSPEC which is obviously larger than the highest load of E2E reservations that may be supported onto this network. Another method is for the Aggregator to keep track of which flows are mapped onto a DSCP and always add their E2E Path SENDER_TSPEC into the Aggregate Path SENDER_TSPEC (and possibly also add some additional bandwidth in anticipation of future E2E reservations).
既存のRSVP手順では、フロー用に確立された予約のサイズが、PATH Sender_TSPECおよびRESV Flow_Specの最小値に設定されることを指定します。したがって、アグリゲーターによる集計パスに含まれるsender_tspecよりも大きくすることはできません。不要な制限なしに総留保がDeaggregatorによってサイズを整えることができるようにするために、集約ルーターは、少なくともDeaggregatorによって決定されるように実際に必要とされるサイズと同じくらい大きいSender_tspecを集約パスに常に含める必要があります。これを達成するための1つの方法は、このネットワークでサポートされる可能性のあるE2E予約の最高荷重よりも明らかに大きいSender_TSPECを使用することです。別の方法は、アグリゲーターがDSCPにマッピングされるフローを追跡し、常にe2eパスsender_tspecを集計パス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つの方法でE2EフローからDSCPへのマッピングが通知されます。第一に、集約ルーターがエラーコードnew-Aggregate-Neededを使用してE2E PATHERRを受信すると、アグリゲーターは、対応するE2Eフローが（少なくとも一時的に）特定のDSCPにマッピングされることを通知されます。第二に、集約ルーターが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パスメッセージを宛先に向かって送信した後、DeaggregatorはセッションのE2E RESVを受信することを期待する必要があります。受領時に、その責任は、新しいE2E予約をサポートするために集合領域内に十分な帯域幅が予約されていることを保証することです。
The Deaggregating router first makes the final decision of which Aggregate Reservation (and thus which DSCP) this E2E reservation is to be mapped onto. This decision is made according to the policy selected by the network administrator as described above.
Deaggregating Routerは、最初に、このE2E予約をマッピングする総計（したがってDSCP）をどの総計（したがってどのDSCP）を決定するかを最終決定します。この決定は、上記のようにネットワーク管理者が選択したポリシーに従って行われます。
If this final mapping decision is such that the Deaggregator can now make a more accurate update of the E2E Path ADSPEC than done when forwarding the initial E2E Path, the Deaggregator should do so and generate a new E2E Path immediately in order to provide the accurate ADSPEC information to the receiver as soon as possible. Otherwise, normal Refresh procedures should be followed for the E2E Path.
この最終マッピングの決定が、Deaggregatorが初期のE2Eパスを転送する際に行うよりもE2EパスADSPECのより正確な更新を行うことができるようにする場合、Deaggregatorは正確な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からの集約予約が現在存在しない場合、Deaggregatingルーターは、次のセクションで説明されているように、新しい集約予約を確立します。
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]に従う必要があります。予約をサポートするため。また、最初に、上流のaggregate RESVに含まれるflow_specのサイズを増やすことにより、帯域幅を供給している骨材の予約を増やそうとするかもしれません。前のセクションで説明したように、集約ルーターは、それに含まれるsender_tspecが集約パスに含まれることを確認する必要があります。必要に応じて、総予約帯域幅を増やします。
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.
対応する集合体予約で十分な帯域幅が利用できる場合、Deaggregatingルーターは、IPプロトコルRSVPを使用してE2E RESVメッセージを集約ルーターに送信するだけです。このメッセージには、アグリゲーターがこのE2Eフローに使用する必要があるDSCPを示すDCLASSオブジェクトを含める必要があります。Deaggregatorはまた、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の処理時に対応する骨材の予約で帯域幅が不十分な状況の発生を最小限に抑え、この骨材の増加に関連する遅延を回避するために、掘削装置は、現在の需要を予測し、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を決定した後、Deaggregatorは選択したDSCPとのセッションに対応するパス状態を探します。集計パス状態が存在するが、集約RESV状態が存在しない場合、Deaggregatorは新しい集約RESVを作成します。
If no aggregate Path state exists for the appropriate DSCP, this may be because the Deaggregator could not decide earlier the final mapping for this E2E flow and elected to not establish Aggregate Path state for all DSCPs. In that case, the Deaggregator should request establishment of the corresponding Aggregate Path by sending a E2E PathErr with error code of NEW-AGGREGATE-NEEDED and with a DCLASS containing the required DSCP. This will trigger the Aggregator to establish the corresponding Aggregate Path. Once the Deaggregator has determined that the aggregate Path state is established, it creates a new Aggregate Resv.
適切なDSCPに集約パス状態が存在しない場合、これはDeaggregatorがこのE2Eフローの最終マッピングを早期に決定できず、すべてのDSCPの集合パス状態を確立しないことを選択したためかもしれません。その場合、Deaggregatorは、New-Aggregate-Neededのエラーコードと必要なDSCPを含むDCLASSを使用してE2E PATHERRを送信することにより、対応する集約パスの確立を要求する必要があります。これにより、アグリゲーターがトリガーして、対応する集計パスを確立します。Deaggregatorが集約パス状態が確立されると判断すると、新しい集約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はセッションオブジェクトにあるため、DCLASSオブジェクトは必要ありません。メッセージは、[RFC2961]のメカニズムを使用して確実に配信する必要があります。あるいは、凝集RESVが実際に到着し、付与されることを保証するために、確認オブジェクトを使用することもできます。これにより、Deaggregatorは、要求された帯域幅がサポートする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の処理時に対応する骨材の予約が確立されない状況の発生を最小限に抑え、この総計予約の作成に関連する遅延を回避するために、Deaggregatorは現在の需要を予測し、これらの集合的な予約の帯域幅を必要とする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でマークし、その予約のトラフィックに適した方法で転送する責任があります。これは、特定のIP次のホップに転送するか、特定のリンクレイヤー回路、トンネル、またはMPLSラベルスイッチ付きパスを配管することを意味する場合があります。
The aggregator is responsible for performing per-reservation policing on the E2E flows that it is aggregating. The aggregator performs metering of traffic belonging to each reservation to assess compliance to the token bucket for the corresponding E2E reservation. Packets which are assessed in compliance are forwarded as mentioned above. Packets which are assessed out of compliance must be either dropped, reshaped or marked to a different DSCP. The detailed policing behavior is an aspect of the service mapping described in [RFC2998].
アグリゲーターは、それが集約している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セッションと同じグループアドレスに「集計」パスメッセージを送信することです。これにより、集約パスメッセージが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つのインターフェイス上のマルチキャストセッションのためにパケットを転送する必要があるが、それらのインターフェイスの1つで予約リクエストのみを受け取っているインテリアルーターを検討してください。集約予約のために選択されたDSCPでマークされたパケットを受信します。インストールされた予約がないインターフェイスを送信する場合、次のオプションがあります。
a) remark those packets to best effort before sending them out the interface;
a) インターフェイスを送信する前に、これらのパケットを最善の努力に注目してください。
b) send the packets out the interface with the DSCP chosen for the aggregate reservation.
b) 集約予約のために選択されたDSCPを使用して、インターフェイスをパケットに送信します。
The first approach suffers from the drawback that it requires nMF classification at an interior router in order to recognize the flows whose packets must be demoted. The second approach requires over-reservation of resources on the interface on which no reservation was 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.
最初のアプローチは、パケットを降格しなければならないフローを認識するために、内部ルーターでのNMF分類が必要であるという欠点に苦しんでいます。2番目のアプローチでは、予約が受け取られなかったインターフェイス上のリソースの過剰保存が必要です。このような過剰な予約がない場合、「間違った」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にあるプロトコルタイプRSVP-E2E-IGNOREの割り当てが必要です。これは、ルーターアラート（PATH、PATHTEAR、およびRESVCONF）を必要とするE2Eメッセージでのみ使用され、メッセージがメッセージが必要であることを意味します。内部インターフェースに運命づけられたときに、そして外部インターフェイスに運命づけられたときに別の方法で扱われます。プロトコルタイプは、Aggregatorが集合領域に入ると、E2Eパス、PATHTEAR、およびRESVCONFメッセージでRSVPからRSVP-E2E-Ignoreに交換されます。プロトコルタイプは、集約領域を終了すると、このようなE2EメッセージでRSVP-E2E-IGNOREからRSVPにDeaggregatorによって交換されます。
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コードは、必要なものが必要です。この値は、致命的なエラーが発生したことを意味するものではなく、近い将来にエラー状態を回避するために集約ルーターにアクションが必要であることを意味します。
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].
セッションオブジェクトには、2つの値が含まれています。集計セッション宛先のIPアドレスと、予約に含まれるE2Eデータで使用するDSCPです。ユニキャストセッションの場合、セッションの宛先アドレスは、ディーグレギングルーターのアドレスです。マルチキャストセッションの場合、セッションの宛先は、集計される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セッションオブジェクト：class = session、c-type = rsvp-aggregate-ip4
+-------------+-------------+-------------+-------------+
| IPv4 Session Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| /////////// | Flags | ///////// | DSCP |
+-------------+-------------+-------------+-------------+
o IP6 SESSION object: Class = SESSION, C-Type = RSVP-AGGREGATE-IP6
o IP6セッションオブジェクト：class = session、c-type = 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オブジェクト：class = sender_template、c-type = 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オブジェクト：class = sender_template、c-type = 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オブジェクトと構文的に同一です。
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予約に割り当てるのに十分なリソースが常にあることです。簡単に述べられていますが、達成するのはより困難です。考慮される要因には、日中のサイクルのかなりの時間が含まれます。午前7時から8時までの時間が穏やかであるにもかかわらず、多くの人が午前8時に電話をかけ始めることがあります。また、最近の歴史も含まれています。最近、より多くの人々がそれらを完成させているよりも電話をかけている場合、必要な帯域幅の予測により、現在割り当てられているよりも多くの帯域幅を呼び出すことがあります。同様に、忙しい期間の終わりに、この傾向は予約額の減少を要求することがわかります。
We recommend a policy something along this line. At any given time, one should expect that the amount of bandwidth required for the aggregate reservation is the larger of the following:
このラインに沿って何かをお勧めします。いつでも、総予約に必要な帯域幅の量は、次のうち大きいと予想されるはずです。
(a) a requirement known a priori, such as from history of the diurnal cycle at a particular week day and time of day, and
(a) 特定の週と時間の日中の日中のサイクルの歴史からのアプリオリを知っている要件、および
(b) the trend line over recent history, with 90 or 99% statistical confidence.
(b) 90または99％の統計的信頼性を備えた最近の歴史の傾向。
We further expect that changes to that aggregate reservation would be made no more often than every few minutes, and ideally perhaps on larger granularity such as fifteen minute intervals or hourly. The finer the granularity, the greater the level of signaling required, while the coarser the granularity, the greater the chance for error, and the need to recover from that error.
さらに、その集合的な予約の変更は、数分ごとに頻繁に行われ、理想的には15分間隔や1時間ごとなどのより大きな粒度で行われることを期待しています。粒度が細かくなるほど、シグナリングのレベルが高くなり、粒度が粗く、エラーの可能性が高くなり、そのエラーから回復する必要性が高くなります。
In general, we expect that the aggregate reservation will not ever add up to exactly the sum of the reservations it supports, but rather will be an integer multiple of some block reservation size, which exceeds that value.
一般に、総予約は、サポートする予約の合計に正確に合計されることはなく、むしろその値を超えるブロック予約サイズの整数倍になると予想しています。
Numerous security issues pertain to this document; for example, the loss of an aggregate reservation to an aggressor causes many calls to operate unreserved, and the reservation of a great excess of bandwidth may result in a denial of service. However, these issues are not confined to this extension: RSVP itself has them. We believe that the security mechanisms in RSVP address these issues as well.
多くのセキュリティの問題がこの文書に関係しています。たとえば、侵略者への総留保が失われると、予約されていない多くの呼びかけを引き起こし、帯域幅を超えた留保はサービスの拒否をもたらす可能性があります。ただし、これらの問題はこの拡張機能に限定されていません。RSVP自体にはそれらがあります。RSVPのセキュリティメカニズムもこれらの問題に対処していると考えています。
One security issue specific to RSVP aggregation involves the modification of the IP protocol number in RSVP Path messages that traverse an aggregation region. If that field were maliciously modified in a Path message, it would cause the message to be ignored by all subsequent devices on its path, preventing reservations from being made. It could even be possible to correct the value before it reached the receiver, making it difficult to detect the attack. In theory, it might also be possible for a node to modify the IP protocol number for non-RSVP messages as well, thus interfering with the operation of other protocols.
RSVP集約に固有のセキュリティ問題の1つは、集約領域を横断するRSVPパスメッセージのIPプロトコル番号の変更を含みます。そのフィールドがパスメッセージで悪意を持って変更された場合、そのパス上の後続のすべてのデバイスによってメッセージが無視され、予約が行われないようになります。レシーバーに到達する前に値を修正することさえ可能である可能性があり、攻撃を検出することが困難になります。理論的には、ノードが非RSVPメッセージのIPプロトコル番号を変更することも可能かもしれないため、他のプロトコルの操作を妨げます。
One way to mitigate the risks of malicious modification of the IP protocol number is to use an IPSEC authentication header, which would ensure that malicious modification of the IP header is detected. This is a desirable approach but imposes some administrative burden in the form of key management for authentication purposes.
IPプロトコル番号の悪意のある変更のリスクを軽減する1つの方法は、IPSEC認証ヘッダーを使用することです。これにより、IPヘッダーの悪意のある変更が検出されることが保証されます。これは望ましいアプローチですが、認証目的のために主要な管理の形で何らかの管理上の負担を課します。
It is RECOMMENDED that implementations of this specification only support modification of the IP protocol number for RSVP Path, PathTear, and ResvConf messages. That is, a general facility for modification of the IP protocol number SHOULD NOT be made available.
この仕様の実装は、RSVPパス、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を割り当て、Standards Track Publication Criterionを満たしています。
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は、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は、アグリゲーターのアドレスに指定する2つの新しい共通Cタイプを割り当てました。RSVP-AGGREGATE-IP4はCタイプ9およびRSVP-AgGregate-IP6はCタイプ10です。これらのCタイプをIANA RSVPクラス名、クラス番号、クラスタイプレジストリに追加する際に、それらのすべての番号が使用されます。[RSVP]のIPv4およびIPv6アドレスタプルで行われる3つのクラス。
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].
著者は、公開された文書と数人の人々、特にジョン・ロクラウスキー、スティーブ・バーソン、アンドレアス・テルツィスがこの文書に重大な貢献をしたことを認めています。この設計は、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.
この付録では、追加の仕様は提供されていません。これは、アグリゲーター/deaggregatorの特定のペアの間で最初のユニキャストE2E予約の成功に関与するRSVPシグナル伝達メッセージの可能性を介して上記の仕様のみを示しています。
Aggregator Deaggregator
アグリゲーターDeaggregator
E2E Path
---------------->
(1)
E2E Path
------------------------------->
(2)
E2E PathErr(New-agg-needed, DCLASS=x)
<-------------------------------
E2E PathErr(New-agg-needed, DCLASS=y)
<-------------------------------
(3)
AggPath(DSCP=x)
------------------------------->
AggPath(DSCP=y)
------------------------------->
(4)
E2E Path
----------->
(5)
AggResv (DSCP=x)
<-------------------------------
AggResv (DSCP=y)
<-------------------------------
(6)
AggResvConfirm (DSCP=x)
------------------------------>
AggResvConfirm (DSCP=y)
------------------------------>
(7)
E2E Resv
<----------
(8)
E2E Resv (DCLASS=x)
<-----------------------------
(9)
E2E Resv
<---------------
(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を正確に更新できるようにするには、Deaggregatorが集約パスのADSPECを必要とします。この例では、Deaggregatorは、各DSCPに新しいAGGが必要とするPatherrコードを送信することにより、サポートされている2つのDSCPの集約パス状態を設定するようにアグリゲーターに指示することを選択します。
(3) The Aggregator follows the request from the Deaggregator and signals an Aggregate Path for both DSCPs.
(3) アグリゲーターは、Deaggregatorからの要求に従い、両方の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) Deaggregatorは、ADSPECに含まれる集計パスの両方から含まれる情報を考慮し、それに応じてE2EパスADSPECを更新します。Deaggregatorは、E2E PATH IPプロトコル番号をRSVPに変更してから転送します。
(5) In this example, the Deaggregator elects to immediately proceed with establishment of Aggregate Reservations for both DSCPs. In effect, the Deaggregator can be seen as anticipating the actual demand of E2E reservations so that resources are available on Aggregate Reservations when the E2E Resv requests arrive in order to speed up establishment of E2E reservations. Assume also that the Deaggregator includes the optional Resv Confirm Request in these Aggregate Resv.
(5) この例では、Deaggregatorは、両方のDSCPの総予約の確立を直ちに進めることを選択します。事実上、Deaggregatorは、E2E予約の実際の需要を予測すると見なすことができ、E2E RESV要求が到着すると、E2E予約の確立をスピードアップするために総予約でリソースが利用可能になります。また、Deaggregatorには、これらの集計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) Deaggregatorは、両方の凝集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を受け取ると、Deaggregatorは、ネットワーク管理者によって定義されたマッピングポリシーを適用して、E2E RESVを集計予約にマッピングします。このポリシーは、E2E予約がDSCP = xを使用して集計予約にマッピングされるようなものであると仮定します。Deaggregatorは、（7）以来、対応するDSCPの総計予約が整っていることを知っています。Deaggregatorは、dscp = xのaggregate RESVにE2E RESVの入場制御を実行します。DSCP = Xの集合体RESVがE2E RESVをサポートするのに十分な帯域幅で確立されていたと仮定すると、Deaggregatorはカウンターを調整して、凝集留置の未使用の帯域幅を追跡し、選択したマッピングを強要したDCLASSオブジェクトを含むAggregatorに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) アグリゲーターは、E2E RESVのdscp = xへのマッピングを記録します。アグリゲーターは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.
この付録では、追加の仕様は提供されていません。これは、特定のアグリゲーター/Deaggregatorのペア間の他のE2E予約に続くユニキャストE2E予約の成功に関与するRSVPシグナル伝達メッセージの可能性を介して上記の仕様を示しています。この流れは、付録1に示されているメッセージの流れに続いて想像できます。
Aggregator Deaggregator
アグリゲーター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
（10）Aggregatorは、IPプロトコル番号をRSVP-E2E-IGOREに変更した後、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.
（11）以前のE2E予約が確立されているため、サポートされているすべてのDSCPに対して集約パスが存在すると仮定しましょう。Deaggregatorは、集計パスからADSPECに含まれる情報を考慮し、それに応じてE2EパスADSPECを更新します。Deaggregatorは、E2E PATH IPプロトコル番号をRSVPに変更してから転送します。
(12) On receipt of the E2E Resv, the Deaggregator applies the mapping policy defined by the network administrator to map the E2E Resv onto an Aggregate Reservation. Let's assume that this policy is such that the E2E reservation is to be mapped onto the Aggregate Reservation with DSCP=x. Because previous E2E reservations have 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を受領すると、Deaggregatorは、ネットワーク管理者によって定義されたマッピングポリシーを適用して、E2E RESVを集計予約にマッピングします。このポリシーは、E2E予約がDSCP = xを使用して集計予約にマッピングされるようなものであると仮定します。以前のE2E予約が確立されているため、DSCP = Xの総予約が整っていると仮定しましょう。Deaggregatorは、dscp = xのaggregate RESVにE2E RESVの入場制御を実行します。DSCP = Xの集合体RESVには、新しいE2E RESVをサポートするのに十分な未使用の帯域幅があると仮定すると、Deaggregatorはカウンターを調整して、総留置の未使用の帯域幅を追跡し、選択したマッピングを強化したDCLASSオブジェクトを含むAggregatorに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）アグリゲーターは、E2E RESVのDSCP = Xへのマッピングを記録します。アグリゲーターは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.
この付録では、追加の仕様は提供されていません。これは、特定のアグリゲーター/Deaggregatorのペア間の他のE2E予約に続くユニキャストE2E予約の成功に関与するRSVPシグナル伝達メッセージの可能性を介して上記の仕様を示しています。この流れは、付録2に示されているメッセージの流れに続いて想像できます。
Aggregator Deaggregator
アグリゲーター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
（14）Aggregatorは、IPプロトコル番号をRSVP-E2E-IGOREに変更した後、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.
（15）以前のE2E予約が確立されているため、サポートされているすべてのDSCPに対して集約パスが存在すると仮定しましょう。Deaggregatorは、集計パスからADSPECに含まれる情報を考慮し、それに応じてE2EパスADSPECを更新します。Deaggregatorは、E2E PATH IPプロトコル番号をRSVPに変更してから転送します。
(16) On receipt of the E2E Resv, the Deaggregator applies the mapping policy defined by the network administrator to map the E2E Resv onto an Aggregate Reservation. Let's assume that this policy is such that the E2E reservation is to be mapped onto the Aggregate Reservation with DSCP=x. Because previous E2E reservations have been established, let's assume that an Aggregate Reservation is in place for DSCP=x. The Deaggregator performs admission control of the E2E Resv onto the Agg Resv for DSCP=x. Let's assume that the Aggregate Resv for DSCP=x does NOT have sufficient unused bandwidth to support the new E2E Resv. The 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.
（16）E2E RESVを受領すると、Deaggregatorは、ネットワーク管理者によって定義されたマッピングポリシーを適用して、E2E RESVを集計予約にマッピングします。このポリシーは、E2E予約がDSCP = xを使用して集計予約にマッピングされるようなものであると仮定します。以前のE2E予約が確立されているため、DSCP = Xの総予約が整っていると仮定しましょう。Deaggregatorは、dscp = xのAGG RESVにE2E RESVの入場制御を実行します。DSCP = Xの集計RESVには、新しいE2E RESVをサポートするのに十分な未使用の帯域幅がないと仮定します。次に、Deaggregatorは、DSCP = Xの総計帯域幅を増加させようとします。新しい集合体予約に適したすべてのE2E予約に適したすべてのE2E予約に加えて、新しいE2E予約に加えて、おそらく予想外の追加の予備の帯域幅に対応しているすべてのE2E予約に対応するのに十分な帯域幅を増やします。今後の追加のE2E予約の。また、Deaggregatorには、これらの集計RESVにオプションの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）Deaggregatorは、凝集RESVが正常に増加したことを明示的に確認しています。Deaggregatorは、DSCP = xの増加した集計予約に対するE2E RESVのAndimment Controlを再度実行します。DSCP = Xの集約予約の増加が、新しいE2E RESVをサポートするのに十分な未使用の帯域幅とリソースがあると仮定すると、Deaggregatorはカウンターを調整して、総予約の未使用の帯域幅を追跡し、E2E RESVをDCLASSオブジェクトを含むアグリゲーターに転送します選択したマッピングを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）アグリゲーターは、E2E RESVのDSCP = Xへのマッピングを記録します。アグリゲーターは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] Clark、D.、S。Shenker、およびL. Zhang、「統合サービスパケットネットワークでのリアルタイムアプリケーションのサポート：アーキテクチャとメカニズム」、Proc。Sigcomm'92、1992年9月。
[IP] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[IP] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[HOSTREQ] Braden, R., "Requirements for Internet hosts - communication layers", STD 3, RFC 1122, October 1989.
[Hostreq] Braden、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] Nichols、K.、Blake、S.、Baker、F。およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[PRINCIPLES] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[原則] Carpenter、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、Baker、F.、Weiss、W。and J. Wroclawski、「Assured Forwarding PHB Group」、RFC 2597、1999年6月。
[BROKER] Jacobson, V., Nichols K. and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", RFC 2638, June 1999.
[Broker] Jacobson、V.、Nichols K.およびL. Zhang、「インターネット用の2ビット差別化されたサービスアーキテクチャ」、RFC 2638、1999年6月。
[BRIM] Brim, S., Carpenter, B. and F. LeFaucheur, "Per Hop Behavior Identification Codes", RFC 2836, May 2000.
[Brim] Brim、S.、Carpenter、B。and F. Lefaucheur、「Per Hopの動作識別コード」、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] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（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. Zhang、「RSVP Operation over IP Tunnels」、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] Baker、F.、Lindell、B。and 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.、Ford、P.、Yavatkar、R.、Baker、F.、Zhang、L.、Speer、M.、Braden、R.、Davie、B.、Wroclawski、J。and E. Felstaine、「Diffserv Networksを介した統合サービスオペレーション」、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] Berger、L.、Gan、D.、Swallow、G.、Pan、P。and 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] Bradner、S。およびV. Paxson、「インターネットプロトコルおよび関連するヘッダーの価値のIANA割り当てガイドライン」、RFC 2780、2000年3月。
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[RFC2711] Partridge、C。およびA. Jackson、「IPv6ルーターアラートオプション」、RFC 2711、1999年10月。
[RFC2113] Katz, D. "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113] Katz、D。「IPルーターアラートオプション」、RFC 2113、1997年2月。
Authors' Addresses
著者のアドレス
Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, CA, 93117 USA
フレッド・ベイカー・シスコ・システム1121
Phone: (408) 526-4257 EMail: fred@cisco.com
電話：（408）526-4257メール：fred@cisco.com
Carol Iturralde Cisco Systems 250 Apollo Drive Chelmsford MA, 01824 USA
Carol Iturralde Cisco Systems 250 Apollo Drive Chelmsford MA、01824 USA
Phone: 978-244-8532 EMail: cei@cisco.com
電話：978-244-8532メール：cei@cisco.com
Francois Le Faucheur Cisco Systems Domaine Green Side 400, Avenue de Roumanille 06410 Biot - Sophia Antipolis France
Francois le Faucheur Cisco Systems Domaine Green Side 400、Avenue de Roumanille 06410 Biot -Sophia Antipolis France
Phone: +33.4.97.23.26.19
EMail: 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メール：bdavie@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。