Network Working Group Y. Bernet
Request for Comments: 2998 P. Ford
Category: Informational Microsoft
R. Yavatkar
Intel
F. Baker
Cisco
L. Zhang
UCLA
M. Speer
Sun Microsystems
R. Braden
ISI
B. Davie
Cisco
J. Wroclawski
MIT LCS
E. Felstaine
SANRAD
November 2000
A Framework for Integrated Services Operation over Diffserv Networks
Diffservのネットワーク経由の統合サービス運用のためのフレームワーク
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
The Integrated Services (Intserv) architecture provides a means for the delivery of end-to-end Quality of Service (QoS) to applications over heterogeneous networks. To support this end-to-end model, the Intserv architecture must be supported over a wide variety of different types of network elements. In this context, a network that supports Differentiated Services (Diffserv) may be viewed as a network element in the total end-to-end path. This document describes a framework by which Integrated Services may be supported over Diffserv networks.
統合サービス（IntServの）アーキテクチャは、異種ネットワーク経由のアプリケーションへのサービス（QoS）のエンドツーエンドの品質の送達のための手段を提供します。このエンドツーエンドのモデルをサポートするために、IntServのアーキテクチャは、ネットワーク要素の異なる多種多様なタイプの上で支持されなければなりません。この文脈では、差別化サービス（Diffservの）をサポートするネットワークは、全エンドツーエンドパスにおけるネットワーク要素と見なすことができます。この文書では、統合サービスは、Diffservのネットワーク上でサポートされるかもしれないフレームワークについて説明します。
Table of Contents
目次
1. Introduction ................................................. 3
1.1 Integrated Services Architecture ............................ 3
1.2 RSVP ........................................................ 3
1.3 Diffserv .................................................... 4
1.4 Roles of Intserv, RSVP and Diffserv ......................... 4
1.5 Components of Intserv, RSVP and Diffserv .................... 5
1.6 The Framework ............................................... 6
1.7 Contents .................................................... 6
2. Benefits of Using Intserv with Diffserv ...................... 7
2.1 Resource Based Admission Control ............................ 7
2.2 Policy Based Admission Control .............................. 8
2.3 Assistance in Traffic Identification/Classification ......... 8
2.3.1 Host Marking .............................................. 9
2.3.2 Router Marking ............................................ 9
2.4 Traffic Conditioning ........................................ 10
3. The Framework ................................................ 10
3.1 Reference Network ........................................... 11
3.1.1 Hosts ..................................................... 11
3.1.2 End-to-End RSVP Signaling ................................. 12
3.1.3 Edge Routers .............................................. 12
3.1.4 Border Routers ............................................ 12
3.1.5 Diffserv Network Region ................................... 13
3.1.6 Non-Diffserv Network Regions .............................. 13
3.2 Service Mapping ............................................. 13
3.2.1 Default Mapping ........................................... 14
3.2.2 Network Driven Mapping .................................... 14
3.2.3 Microflow Separation ...................................... 14
3.3 Resource Management in Diffserv Regions ..................... 15
4. Detailed Examples of the Operation of
Intserv over Diffserv Regions ................................ 16
4.1 Statically Provisioned Diffserv Network Region .............. 16
4.1.1 Sequence of Events in Obtaining End-to-end QoS ............ 16
4.2 RSVP-Aware Diffserv Network Region .......................... 18
4.2.1 Aggregated or Tunneled RSVP ............................... 19
4.2.3 Per-flow RSVP ............................................. 20
4.2.4 Granularity of Deployment of RSVP Aware Routers ........... 20
4.3 Dynamically Provisioned, Non-RSVP-aware Diffserv Region ..... 21
5. Implications of the Framework for Diffserv Network Regions ... 21
5.1 Requirements from Diffserv Network Regions .................. 21
5.2 Protection of Intserv Traffic from Other Traffic ............ 22
6. Multicast .................................................... 22
6.1 Remarking of packets in branch point routers ................ 24
6.2 Multicast SLSs and Heterogeneous Trees ...................... 25
7. Security Considerations ...................................... 26
7.1 General RSVP Security ....................................... 26
7.2 Host Marking ................................................ 26
8. Acknowledgments .............................................. 27
9. References ................................................... 27
10. Authors' Addresses .......................................... 29
11. Full Copyright Statement ................................... 31
Work on QoS-enabled IP networks has led to two distinct approaches: the Integrated Services architecture (Intserv) [10] and its accompanying signaling protocol, RSVP [1], and the Differentiated Services architecture (Diffserv) [8]. This document describes ways in which a Diffserv network can be used in the context of the Intserv architecture to support the delivery of end-to-end QOS.
[8]統合サービスアーキテクチャ（のIntServ）[10]とそれに付随するシグナリングプロトコル、RSVP [1]、および差別化サービスアーキテクチャ（Diffservの）QoS対応のIPネットワーク上の作業は、2つの異なるアプローチをもたらしました。この文書では、Diffservのネットワークは、エンドツーエンドのQoSの配信をサポートするためのIntServアーキテクチャの文脈で使用することができる方法を記載しています。
The integrated services architecture defined a set of extensions to the traditional best effort model of the Internet with the goal of allowing end-to-end QOS to be provided to applications. One of the key components of the architecture is a set of service definitions; the current set of services consists of the controlled load and guaranteed services. The architecture assumes that some explicit setup mechanism is used to convey information to routers so that they can provide requested services to flows that require them. While RSVP is the most widely known example of such a setup mechanism, the Intserv architecture is designed to accommodate other mechanisms.
サービス統合型アーキテクチャは、エンドツーエンドのQoSをアプリケーションに提供できるようにすることを目標に、インターネットの伝統的なベストエフォート型モデルへの拡張機能のセットを定義しました。アーキテクチャの重要な要素の1つは、サービス定義のセットです。サービスの現在のセットは、制御された負荷および保証サービスで構成されています。このアーキテクチャは、いくつかの明示的な設定機構は、彼らがそれらを必要とフローに要求されたサービスを提供できるように、ルータに情報を伝達するために使用されていることを前提としています。 RSVPは、設定機構の最も広く知られた例であるが、のIntServアーキテクチャは、他の機構を収容するように設計されています。
Intserv services are implemented by "network elements". While it is common for network elements to be individual nodes such as routers or links, more complex entities, such as ATM "clouds" or 802.3 networks may also function as network elements. As discussed in more detail below, a Diffserv network (or "cloud") may be viewed as a network element within a larger Intserv network.
IntServのサービスは、「ネットワーク要素」によって実現されています。ネットワーク要素は、ルータやリンクなどの個々のノードであるために、それが一般的であるが、そのようなATM「雲」又は802.3ネットワークのようなより複雑なエンティティは、また、ネットワーク要素として機能することができます。以下でより詳細に議論されるように、Diffservのネットワーク（または「クラウド」）が大きいのIntServネットワーク内のネットワーク要素と見なすことができます。
RSVP is a signaling protocol that applications may use to request resources from the network. The network responds by explicitly admitting or rejecting RSVP requests. Certain applications that have quantifiable resource requirements express these requirements using Intserv parameters as defined in the appropriate Intserv service specification. As noted above, RSVP and Intserv are separable. RSVP is a signaling protocol which may carry Intserv information. Intserv defines the models for expressing service types, quantifying resource requirements and for determining the availability of the requested resources at relevant network elements (admission control).
RSVPは、アプリケーションがネットワークからリソースを要求するために使用することができるシグナリングプロトコルです。ネットワークは、明示的に認めるか、RSVP要求を拒否することによって応答します。定量化可能なリソース要件を持っている特定のアプリケーションが適切なのIntServサービス仕様で定義されているのIntServパラメータを使用してこれらの要件を発現します。上述したように、RSVPとのIntServは分離可能です。 RSVPは、IntServの情報を運ぶことができるシグナリングプロトコルです。 IntServは、サービスタイプを発現するリソース要件を定量化し、関連するネットワーク要素（アドミッション制御）で要求されたリソースの利用可能性を決定するためのモデルを定義します。
The current prevailing model of RSVP usage is based on a combined RSVP/Intserv architecture. In this model, RSVP signals per-flow resource requirements to network elements, using Intserv parameters. These network elements apply Intserv admission control to signaled requests. In addition, traffic control mechanisms on the network element are configured to ensure that each admitted flow receives the service requested in strict isolation from other traffic. To this end, RSVP signaling configures microflow (MF) [8] packet classifiers in Intserv capable routers along the path of the traffic flow. These classifiers enable per-flow classification of packets based on IP addresses and port numbers.
RSVPの使用の現在の支配的なモデルを組み合わせRSVP /のIntServアーキテクチャに基づいています。このモデルでは、RSVP信号フロー毎のリソース要件は、のIntServパラメータを使用して、要素をネットワークします。これらのネットワーク要素は、合図の要求にイントサーブアドミッション制御を適用します。加えて、ネットワーク要素のトラフィック制御機構は、各入院フローが他のトラフィックから分離厳密に要求されたサービスを受けることを保証するように構成されています。この目的のために、RSVPシグナリングは、マイクロフロー（MF）トラフィックフローの経路に沿ってのIntServ可能なルータで[8]のパケット分類を構成します。これらの分類は、IPアドレスとポート番号に基づいてパケットのフローごとの分類を可能にします。
The following factors have impeded deployment of RSVP (and the Intserv architecture) in the Internet at large:
次の要因は、大規模で、インターネットでのRSVPの展開（とIntServのアーキテクチャを）妨げています：
1. The use of per-flow state and per-flow processing raises scalability concerns for large networks.
1.フロー毎の状態とフローごとの処理の使用は、大規模ネットワークのスケーラビリティの問題を提起します。
2. Only a small number of hosts currently generate RSVP signaling. While this number is expected to grow dramatically, many applications may never generate RSVP signaling.
ホストの2だけ小さい数が現在RSVPシグナリングを生成します。この数は飛躍的に成長すると予想されるが、多くのアプリケーションは、RSVPシグナリングを生成しないことがあります。
3. The necessary policy control mechanisms -- access control, authentication, and accounting -- have only recently become available [17].
3.必要なポリシー制御メカニズム - アクセス制御、認証、および会計は - ごく最近利用可能となっている[17]。
In contrast to the per-flow orientation of RSVP, Diffserv networks classify packets into one of a small number of aggregated flows or "classes", based on the Diffserv codepoint (DSCP) in the packet's IP header. This is known as behavior aggregate (BA) classification [8]. At each Diffserv router, packets are subjected to a "per-hop behavior" (PHB), which is invoked by the DSCP. The primary benefit of Diffserv is its scalability. Diffserv eliminates the need for per-flow state and per-flow processing and therefore scales well to large networks.
RSVPのフロー毎の向きとは対照的に、DiffservのネットワークはパケットのIPヘッダ内のDiffservコードポイント（DSCP）に基づいて、集約フローまたは「クラス」の少数の一つにパケットを分類します。これは、動作の集合体（BA）分類として知られている[8]。それぞれのDiffservルータにおいて、パケットはDSCPによって呼び出される「ホップ単位動作」（PHB）に供されます。 Diffservのの主な利点は、そのスケーラビリティです。 DiffServはフロー毎の状態とフローごとの処理の必要性を排除し、したがって、大規模なネットワークに適切に拡張します。
We view Intserv, RSVP and Diffserv as complementary technologies in the pursuit of end-to-end QoS. Together, these mechanisms can facilitate deployment of applications such as IP-telephony, video-on-demand, and various non-multimedia mission-critical applications. Intserv enables hosts to request per-flow, quantifiable resources, along end-to-end data paths and to obtain feedback regarding admissibility of these requests. Diffserv enables scalability across large networks.
我々は、エンドツーエンドのQoSの追求の補完的な技術としてイントサーブ、RSVPとDiffservのを見ます。一緒に、これらのメカニズムは、IPテレフォニー、ビデオオンデマンド、および様々な非マルチメディアミッションクリティカルなアプリケーションなどのアプリケーションの展開を容易にすることができます。 IntServは、エンド・ツー・エンドのデータパスに沿って、フロー毎、定量化可能なリソースを要求し、これらの要求の許容性に関するフィードバックを得るためにホストを可能にします。 DiffServは大規模ネットワーク全体に拡張性を可能にします。
Before proceeding, it is helpful to identify the following components of the QoS technologies described:
進む前に、説明のQoS技術の次のコンポーネントを識別するために役立ちます。
RSVP signaling - This term refers to the standard RSVP signaling protocol. RSVP signaling is used by hosts to signal application resource requirements to the network (and to each other). Network elements use RSVP signaling to return an admission control decision to hosts. RSVP signaling may or may not carry Intserv parameters.
RSVPシグナリング - この用語は、標準的なRSVPシグナリングプロトコルを指します。 RSVPシグナリングは、ネットワークに（及び互いに）アプリケーションのリソース要件を知らせるためにホストによって使用されます。ネットワーク要素は、ホストにアドミッション制御の決定を返すためにRSVPシグナリングを使用します。 RSVPシグナリングは、またはのIntServパラメータを搬送することができるかもしれません。
Admission control at a network element may or may not be based on the Intserv model.
ネットワーク要素におけるアドミッション制御は、またはのIntServモデルに基づいていてもいなくてもよいです。
MF traffic control - This term refers to traffic control which is applied independently to individual traffic flows and therefore requires recognizing individual traffic flows via MF classification.
MFトラフィック制御 - この用語は、個々のトラフィックフローに独立に適用され、したがって、MF分類を介して個々のトラフィックフローを認識する必要とするトラフィック制御を指します。
Aggregate traffic control - This term refers to traffic control which is applied collectively to sets of traffic flows. These sets of traffic flows are recognized based on BA (DSCP) classification. In this document, we use the terms "aggregate traffic control" and "Diffserv" interchangeably.
集約トラフィック制御 - この用語は、トラフィックフローのセットにまとめて適用されるトラフィックの制御を指します。トラフィックフローのこれらのセットは、BA（DSCP）の分類に基づいて認識されています。この文書では、用語「集約トラフィック制御」と同義的に「Diffservの」を使用します。
Aggregate RSVP. While the existing definition of RSVP supports only per-flow reservations, extensions to RSVP are being developed to enable RSVP reservations to be made for aggregated traffic, i.e., sets of flows that may be recognized by BA classification. This use of RSVP may be useful in controlling the allocation of bandwidth in Diffserv networks.
集計RSVP。 RSVPの既存の定義のみフローごとの予約をサポートしながら、RSVPの拡張は、BA分類によって認識され得る流れの、すなわち、セット、集約トラフィックのために作られるべきRSVP予約を有効にするために開発されています。 RSVPのこの使用は、Diffservのネットワークにおける帯域幅の割り当てを制御するのに有用であり得ます。
Per-flow RSVP. The conventional usage of RSVP to perform resource reservations for individual microflows.
フローごとのRSVP。 RSVPの従来の使用法は、個々のマイクロフローのためのリソース予約を実行します。
RSVP/Intserv - This term is used to refer to the prevailing model of RSVP usage which includes RSVP signaling with Intserv parameters, Intserv admission control and per-flow traffic control at network elements.
RSVP / IntServの - この用語は、IntServのパラメータ、のIntServアドミッション制御及びネットワーク要素にフロー毎のトラフィック制御とシグナリングRSVPを含むRSVPの使用の支配モデルを指すために使用されます。
Diffserv Region. A set of contiguous routers which support BA classification and traffic control. While such a region may also support MF classification, the goal of this document is to describe how such a region may be used in delivery of end-to-end QOS when only BA classification is performed inside the Diffserv region.
Diffservの地域。 BAの分類とトラフィック制御をサポートして連続したルータのセット。そのような領域はまた、MF分類をサポートすることができるが、この文書の目的は、BAの分類はDiffservの領域内で実行されたときに、このような領域は、エンド・ツー・エンドのQoSの送達に使用することができる方法を説明することです。
Non-Diffserv Region. The portions of the network outside the Diffserv region. Such a region may also offer a variety of different types of classification and traffic control.
非Diffservの地域。 Diffservの領域外のネットワークの一部。そのような領域はまた、分類およびトラフィック制御の様々な異なるタイプのを提供することができます。
Note that, for the purposes of this document, the defining features of a Diffserv region is the type of classification and traffic control that is used for the delivery of end-to-end QOS for a particular application. Thus, while it may not be possible to identify a certain region as "purely Diffserv" with respect to all traffic flowing through the region, it is possible to define it in this way from the perspective of the treatment of traffic from a single application.
本文書の目的のために、Diffservの領域の決定的な特徴は、特定の用途のためのエンドツーエンドのQoSの送達のために使用される分類とトラフィック制御の一種である、ということに注意してください。それは領域を流れるすべてのトラフィックに対して「純粋Diffservの」などの特定の領域を同定することが可能ではないかもしれないしつつ、単一のアプリケーションからのトラフィックの治療の観点から、このようにそれを定義することが可能です。
In the framework we present, end-to-end, quantitative QoS is provided by applying the Intserv model end-to-end across a network containing one or more Diffserv regions. The Diffserv regions may, but are not required to, participate in end-to-end RSVP signaling for the purpose of optimizing resource allocation and supporting admission control.
我々は、本フレームワークでは、エンドツーエンドのQoSの定量は、一つ以上のDiffservの領域を含むネットワーク全体のIntServモデルエンドツーエンドを適用することによって提供されます。 Diffservの領域が、しかしは、資源配分を最適化し、アドミッション制御をサポートする目的のためのシグナリングエンドツーエンドRSVPに参加するために必要とされないことがあります。
From the perspective of Intserv, Diffserv regions of the network are treated as virtual links connecting Intserv capable routers or hosts (much as an 802.1p network region is treated as a virtual link in [5]). Within the Diffserv regions of the network routers implement specific PHBs (aggregate traffic control). The total amount of traffic that is admitted into the Diffserv region that will receive a certain PHB may be limited by policing at the edge. As a result we expect that the Diffserv regions of the network will be able to support the Intserv style services requested from the periphery. In our framework, we address the support of end-to-end Integrated Services over the Diffserv regions of the network. Our goal is to enable seamless inter-operation. As a result, the network administrator is free to choose which regions of the network act as Diffserv regions. In one extreme the Diffserv region is pushed all the way to the periphery, with hosts alone having full Intserv capability. In the other extreme, Intserv is pushed all the way to the core, with no Diffserv region.
IntServの観点から、ネットワークのDiffservの領域が可能なルータまたはホストのIntServ結ぶ仮想リンクとして扱われる（802.1Pネットワーク領域だけを仮想リンクとして扱われる[5]）。ネットワークルータのDiffservの領域内の特定のPHB（集約トラフィック制御）を実現します。特定のPHBを受信するDiffservの領域内に導入されるトラフィックの総量は、エッジでポリシングによって制限され得ます。その結果として、我々はネットワークのDiffservの領域が周辺から要求されたイントサーブスタイルのサービスをサポートできるようになることを期待しています。私たちの枠組みの中で、我々は、ネットワークのDiffservの領域上のエンドツーエンドの統合サービスのサポートに取り組みます。私たちの目標は、シームレスな相互運用を可能にするためです。その結果、ネットワーク管理者は、Diffservの領域としてネットワーク行為のどの領域を自由に選択することができます。一方の極端ではDiffservの領域が単独でホストがフルのIntServ能力を有する、すべての方法周囲に押し込まれます。他の極端では、のIntServはないDiffservの領域と、すべての方法コアに押し込まれます。
In section 3 we discuss the benefits that can be realized by using the aggregate traffic control provided by Diffserv network regions in the broader context of the Intserv architecture. In section 4, we present the framework and the reference network. Section 5 details two possible realizations of the framework. Section 6 discusses the implications of the framework for Diffserv. Section 7 presents some issues specific to multicast flows.
セクション3では、私たちはイントサーブアーキテクチャのより広い文脈でのDiffservネットワーク領域が提供する集約トラフィック制御を用いて実現することができるメリットを議論します。セクション4では、我々は、フレームワークと基準ネットワークを提示します。第5節は、フレームワークの2つの可能性のある実現を詳しく説明します。第6節は、Diffservのためのフレームワークの意義を論じています。第7節は、マルチキャストフローに固有のいくつかの問題を提示します。
The primary benefit of Diffserv aggregate traffic control is its scalability. In this section, we discuss the benefits that interoperation with Intserv can bring to a Diffserv network region. Note that this discussion is in the context of servicing quantitative QoS applications specifically. By this we mean those applications that are able to quantify their traffic and QoS requirements.
Diffservの集約トラフィック制御の主な利点は、そのスケーラビリティです。このセクションでは、我々はイントサーブとの相互運用がDiffservのネットワーク領域にもたらすことができるというメリットを議論します。この議論は、具体的、定量的なQoSアプリケーションにサービスを提供するのコンテキストであることに注意してください。これにより、我々は彼らのトラフィックとQoS要件を定量化することができ、それらのアプリケーションを意味します。
In Intserv networks, quantitative QoS applications use an explicit setup mechanism (e.g., RSVP) to request resources from the network. The network may accept or reject these requests in response. This is "explicit admission control". Explicit and dynamic admission control helps to assure that network resources are optimally used. To further understand this issue, consider a Diffserv network region providing only aggregate traffic control with no signaling. In the Diffserv network region, admission control is applied in a relatively static way by provisioning policing parameters at network elements. For example, a network element at the ingress to a Diffserv network region could be provisioned to accept only 50 Kbps of traffic for the EF DSCP.
IntServのネットワークでは、定量的なQoSアプリケーションは、ネットワークからリソースを要求するために明示的な設定機構（例えば、RSVP）を使用します。ネットワークは、応答でこれらの要求を受け入れるか拒否することができます。これは、「明示的な許可制御」です。明示的および動的なアドミッション制御は、ネットワークリソースを最適に使用されていることを保証するのに役立ちます。この問題をさらに理解するために、シグナリングなしで唯一の集約トラフィック制御を提供したDiffservネットワーク領域を考えます。 Diffservのネットワーク領域において、アドミッション制御は、ネットワーク要素でポリシングパラメータをプロビジョニングすることにより、比較的静的な方法で適用されます。例えば、Diffservのネットワーク領域への入口におけるネットワーク要素はEF DSCPのトラフィックの50 Kbpsのを受け入れるようにプロビジョニングすることができます。
While such static forms of admission control do protect the network to some degree, they can be quite ineffective. For example, consider that there may be 10 IP telephony sessions originating outside the Diffserv network region, each requiring 10 Kbps of EF service from the Diffserv network region. Since the network element protecting the Diffserv network region is provisioned to accept only 50 Kbps of traffic for the EF DSCP, it will discard half the offered traffic. This traffic will be discarded from the aggregation of traffic marked EF, with no regard to the microflow from which it originated. As a result, it is likely that of the ten IP telephony sessions, none will obtain satisfactory service when in fact, there are sufficient resources available in the Diffserv network region to satisfy five sessions.
アドミッションコントロールの静的なフォームはある程度のネットワークを保護しないが、彼らは非常に効果がないことができます。例えば、Diffservのネットワーク領域から、Diffservのネットワーク領域外EFサービスの各要求10 Kbpsの発信10回のIP電話セッションが存在し得ることを考えます。たDiffservネットワーク地域を保護するネットワーク要素は、EF DSCPのトラフィックの50 Kbpsのを受け入れるようにプロビジョニングされているので、それは半分提供されたトラフィックを破棄します。このトラフィックは、トラフィックの集約から破棄され、それが発信されたマイクロフローに関係なくして、EFをマーク。その結果、実際には、5つのセッションを満たすためのDiffservネットワーク地域で利用可能な十分なリソースがある場合に10回のIPテレフォニーセッションの、どれも満足のいくサービスを取得しないだろうと思われます。
In the case of explicitly signaled, dynamic admission control, the network will signal rejection in response to requests for resources that would exceed the 50 Kbps limit. As a result, upstream network elements (including originating hosts) and applications will have the information they require to take corrective action. The application might respond by refraining from transmitting, or by requesting admission for a lesser traffic profile. The host operating system might respond by marking the application's traffic for the DSCP that corresponds to best-effort service. Upstream network elements might respond by re-marking packets on the rejected flow to a lower service level. In some cases, it may be possible to reroute traffic over alternate paths or even alternate networks (e.g., the PSTN for voice calls). In any case, the integrity of those flows that were admitted would be preserved, at the expense of the flows that were not admitted. Thus, by appointing an Intserv-conversant admission control agent for the Diffserv region of the network it is possible to enhance the service that the network can provide to quantitative QoS applications.
明示的にシグナリング、動的アドミッション制御の場合、ネットワークは、50 Kbpsの限界を超えるリソースに対する要求に応じて拒絶を通知します。結果として、上流のネットワーク（ホスト発信含む）の要素とアプリケーションは、修正アクションを取るために必要な情報を有することになります。アプリケーションは、送信から、または少ないトラフィックプロファイルの入場を要求することにより控えることによって応答することがあります。ホストオペレーティングシステムは、ベストエフォート型のサービスに対応するDSCPのために、アプリケーションのトラフィックをマーキングすることによって応答することがあります。上流のネットワーク要素は、下のサービスレベルに拒否されたフローに再マーキングパケットによって応答することがあります。場合によっては、代替パス、あるいは代替ネットワーク（音声通話のために、例えば、PSTN）を介してトラフィックを再ルーティングすることも可能です。いずれの場合も、入院したこれらのフローの整合性は認められなかった流れを犠牲にして、保存されます。したがって、ネットワークのDiffservの領域についてのIntServ-精通アドミッション制御剤を指名することによって、ネットワークは、定量的なQoSアプリケーションに提供することができるサービスを向上させることができます。
In network regions where RSVP is used, resource requests can be intercepted by RSVP-aware network elements and can be reviewed against policies stored in policy databases. These resource requests securely identify the user and the application for which the resources are requested. Consequently, the network element is able to consider per-user and/or per-application policy when deciding whether or not to admit a resource request. So, in addition to optimizing the use of resources in a Diffserv network region (as discussed in 3.1) RSVP conversant admission control agents can be used to apply specific customer policies in determining the specific customer traffic flows entitled to use the Diffserv network region's resources. Customer policies can be used to allocate resources to specific users and/or applications.
RSVPが使用されているネットワーク領域では、リソース要求は、RSVPアウェアネットワーク要素によって傍受することができ、ポリシーデータベースに保存されているポリシーに照らして検討することができます。これらのリソース要求が確実にユーザーとリソースが要求されるアプリケーションを識別します。その結果、ネットワーク要素は、リソース要求を認めるか否かを決定するときに、ユーザーごとのおよび/またはアプリケーションごとのポリシーを検討することができます。だから、（3.1で説明したように）たDiffservネットワーク領域内のリソースの使用を最適化に加えて、RSVP精通アドミッション制御剤としては、特定の顧客のトラフィックを決定する際に、特定の顧客のポリシーを適用するために使用することができたDiffservネットワーク地域の資源を使用する権利を流れます。カスタマー・ポリシーは、特定のユーザおよび/またはアプリケーションにリソースを割り当てるために使用することができます。
By comparison, in Diffserv network regions without RSVP signaling, policies are typically applied based on the Diffserv customer network from which traffic originates, not on the originating user or application within the customer network.
比較によって、RSVPシグナリングなしのDiffservのネットワーク領域では、ポリシーは、典型的には、トラフィックがない顧客ネットワーク内の発信元のユーザまたはアプリケーションに、発信元のDiffservの顧客ネットワークに基づいて適用されます。
Within Diffserv network regions, traffic is allotted service based on the DSCP marked in each packet's IP header. Thus, in order to obtain a particular level of service within the Diffserv network region, it is necessary to effect the marking of the correct DSCP in packet headers. There are two mechanisms for doing so, host marking and router marking. In the case of host marking, the host operating system marks the DSCP in transmitted packets. In the case of router marking, routers in the network are configured to identify specific traffic (typically based on MF classification) and to mark the DSCP as packets transit the router. There are advantages and disadvantages to each scheme. Regardless of the scheme used, explicit signaling offers significant benefits.
Diffservのネットワーク領域内では、トラフィックは、各パケットのIPヘッダにマークされたDSCPに基づいてサービスを割り当てられています。したがって、Diffservのネットワーク領域内のサービスの特定のレベルを得るためには、パケットヘッダに正しいDSCPマーキングを行うことが必要です。 、そうするホストはマーキングおよびルータはマーキングのための2つのメカニズムがあります。マーキングホストの場合には、ホスト・オペレーティング・システムは、送信されたパケットのDSCPをマークします。マーキングルータの場合には、ネットワーク内のルータは、特定のトラフィックを識別するために、（典型的には、MFの分類に基づいて）パケットの中継としてルータをDSCPをマークするように構成されています。各スキームの長所と短所があります。関係なく使用スキームの、明示的なシグナリングは、大きなメリットを提供しています。
In the case of host marking, the host operating system marks the DSCP in transmitted packets. This approach has the benefit of shifting per-flow classification and marking to the source of the traffic, where it scales best. It also enables the host to make decisions regarding the mark that is appropriate for each transmitted packet and hence the relative importance attached to each packet. The host is generally better equipped to make this decision than the network. Furthermore, if IPSEC encryption is used, the host may be the only device in the network that is able to make a meaningful determination of the appropriate marking for each packet, since various fields such as port numbers would be unavailable to routers for MF classification.
マーキングホストの場合には、ホスト・オペレーティング・システムは、送信されたパケットのDSCPをマークします。このアプローチは、フローごとの分類をシフトし、それが最高のスケールトラフィックの送信元にマーキングする利点を有します。また、各送信パケットおよび各パケットに付加ので、相対的な重要性のために適切であるマークに関する決定を行うためにホストを可能にします。ホストは、一般的に、より良いネットワークよりも、この決定を行うために装備されています。 IPsec暗号化を使用する場合、ポート番号など様々な分野でMF分類のためのルータに利用できなくなるので、ホストは、パケットごとに適切なマーキングの意味の決定を行うことができるネットワーク内の唯一のデバイスであってもよいです。
Host marking requires that the host be aware of the interpretation of DSCPs by the network. This information can be configured into each host. However, such configuration imposes a management burden. Alternatively, hosts can use an explicit signaling protocol such as RSVP to query the network to obtain a suitable DSCP or set of DSCPs to apply to packets for which a certain Intserv service has been requested. An example of how this can be achieved is described in [14].
マーキングホストは、ホストがネットワークによるのDSCPの解釈を認識する必要があります。この情報は、各ホストに設定することができます。しかし、このような構成は、管理負担を課します。あるいはまた、ホストは、特定のIntServサービスが要求されたパケットに適用するために適切なDSCPまたはのDSCPのセットを取得するためにネットワークを照会するようなRSVPのような明示的なシグナリングプロトコルを使用することができます。これを達成することができる方法の例は、[14]に記載されています。
In the case of router marking, MF classification criteria must be configured in the router in some way. This may be done dynamically (e.g., using COPS provisioning), by request from the host operating system, or statically via manual configuration or via automated scripts.
マーキングルータの場合は、MFの分類基準は、いくつかの方法で、ルータに設定する必要があります。これは、ホスト・オペレーティング・システムから、または静的に手動設定を介して、または自動化されたスクリプトを介して要求することによって、動的に（例えば、プロビジョニングCOPSを使用して）行うことができます。
There are significant difficulties in doing so statically. In many cases, it is desirable to allot service to traffic based on the application and/or user originating the traffic. At times it is possible to identify packets associated with a specific application by the IP port numbers in the headers. It may also be possible to identify packets originating from a specific user by the source IP address. However, such classification criteria may change frequently. Users may be assigned different IP addresses by DHCP. Applications may use transient ports. To further complicate matters, multiple users may share an IP address. These factors make it very difficult to manage static configuration of the classification information required to mark traffic in routers.
静的にそうすることで大きな困難があります。多くの場合、アプリケーションおよび/またはトラフィックを発信ユーザに基づいてトラフィックにサービスを割り当てることが望ましいです。時間にはヘッダ内のIPポート番号によって特定のアプリケーションに関連付けられたパケットを識別することが可能です。また、送信元IPアドレスにより、特定のユーザから発信パケットを識別することが可能です。しかし、このような分類基準は、頻繁に変更されることがあります。ユーザーは、DHCPによって異なるIPアドレスを割り当ててもよいです。アプリケーションは、一時ポートを使用することができます。さらに問題を複雑にするには、複数のユーザーがIPアドレスを共有する場合があります。これらの要因は、それは非常に困難ルータにトラフィックをマークするために必要な分類情報の静的な構成を管理するために作ります。
An attractive alternative to static configuration is to allow host operating systems to signal classification criteria to the router on behalf of users and applications. As we will show later in this document, RSVP signaling is ideally suited for this task. In addition to enabling dynamic and accurate updating of MF classification criteria, RSVP signaling enables classification of IPSEC [13] packets (by use of the SPI) which would otherwise be unrecognizable.
静的な設定に魅力的な代替は、ホストオペレーティングシステムは、ユーザーやアプリケーションの代わりにルータに分類基準を通知できるようにすることです。私たちはこのドキュメントで表示されるように、RSVPシグナリングは、このタスクのために理想的に適しています。 MF分類基準の動的かつ正確な更新を可能にすることに加えて、RSVPシグナリングは、そうでなければ認識できないであろう（SPIを使用することによって）IPSEC [13]パケットの分類を可能にします。
Intserv-capable network elements are able to condition traffic at a per-flow granularity, by some combination of shaping and/or policing. Pre-conditioning traffic in this manner before it is submitted to the Diffserv region of the network is beneficial. In particular, it enhances the ability of the Diffserv region of the network to provide quantitative services using aggregate traffic control.
IntServの対応ネットワーク要素は、成形及び/又はポリシングのいくつかの組み合わせによって、フローごとの単位でトラフィックを調整することができます。それはネットワークのDiffservの領域に提出される前に、このようにプリコンディショニングトラフィックが有益です。特に、集約トラフィック制御を用いた定量的サービスを提供するネットワークのDiffservの領域の能力を高めます。
In the general framework we envision an Internet in which the Integrated Services architecture is used to deliver end-to-end QOS to applications. The network includes some combination of Intserv capable nodes (in which MF classification and per-flow traffic control is applied) and Diffserv regions (in which aggregate traffic control is applied). Individual routers may or may not participate in RSVP signaling regardless of where in the network they reside.
一般的なフレームワークでは、サービス統合型アーキテクチャがアプリケーションにエンドツーエンドのQoSを提供するために使用されているインターネットを想定します。ネットワークのIntServできるノード（MF分類とフロー毎のトラフィック制御が適用される）、および（集約トラフィック制御が適用される）のDiffserv領域のいくつかの組み合わせを含みます。個々のルータは関わらず、ネットワークにそれらが存在する場所のRSVPシグナリングに関与してもしなくてもよいです。
We will consider two specific realizations of the framework. In the first, resources within the Diffserv regions of the network are statically provisioned and these regions include no RSVP aware devices. In the second, resources within the Diffserv region of the network are dynamically provisioned and select devices within the Diffserv network regions participate in RSVP signaling.
私たちは、フレームワークの2つの特定の実現を検討します。最初に、ネットワークのDiffservの領域内のリソースは、静的にプロビジョニングされ、これらの領域にはRSVPアウェア装置を含みません。第二に、ネットワークのDiffservの領域内のリソースを動的にプロビジョニングされているとDiffservネットワーク領域内の選択デバイスは、RSVPシグナリングに関与します。
The two realizations of the framework will be discussed in the context of the following reference network:
フレームワーク二の実現は、以下の基準ネットワークの文脈で説明します。
________ ______________ ________
/ \ / \ / \
/ \ / \ / \
|---| | |---| |---| |---| |---| | |---|
|Tx |-| |ER1|---|BR1| |BR2|---|ER2| |-|Rx |
|---| | |-- | |---| |---| |---| | |---|
\ / \ / \ /
\________/ \______________/ \________/
Non-Diffserv region Diffserv region Non-Diffserv region
非Diffservの領域Diffservの地域以外のDiffserv地域
Figure 1: Sample Network Configuration
図1：ネットワーク構成のサンプル
The reference network includes a Diffserv region in the middle of a larger network supporting Intserv end-to-end. The Diffserv region contains a mesh of routers, at least some of which provide aggregate traffic control. The regions outside the Diffserv region (non-Diffserv regions) contain meshes of routers and attached hosts, at least some of which support the Integrated Services architecture.
基準ネットワークのIntServは、エンドツーエンドサポートする大規模なネットワークの途中でDiffservの領域を含みます。 Diffservの領域は、少なくともそのうちのいくつかは、集約トラフィック制御を提供し、ルータのメッシュが含まれています。 Diffservの領域（非Diffservの領域）の外側の領域には、サービス統合型アーキテクチャをサポートし、少なくともいくつかのルータと接続されたホストのメッシュを含みます。
In the interest of simplicity we consider a single QoS sender, Tx communicating across this network with a single QoS receiver, Rx. The edge routers (ER1, ER2) which are adjacent to the Diffserv region interface to the border routers (BR1, BR2) within the Diffserv region.
シンプルさの興味では、我々は、単一のQoS送信者は、Txは単一のQoS受信機、受信して、このネットワークを介して通信を検討してください。 Diffservの領域内の境界ルータ（BR1、BR2）へのDiffserv領域界面に隣接するエッジルータ（ER1、ER2）。
From an economic viewpoint, we may consider that the Diffserv region sells service to the network outside the Diffserv region, which in turn provides service to hosts. Thus, we may think of the non-Diffserv regions as clients or customers of the Diffserv region. In the following, we use the term "customer" for the non-Diffserv regions. Note that the boundaries of the regions may or may not align with administrative domain boundaries, and that a single region might contain multiple administrative domains.
経済的な観点から、我々はDiffservの領域が順番にホストにサービスを提供するDiffservの領域外のネットワークにサービスを販売することを検討することができます。したがって、我々は、Diffservの領域のクライアントや顧客などの非Diffservの地域を考えることがあります。以下では、非Diffservの領域のための「顧客」という用語を使用します。領域の境界が、または管理ドメインの境界に位置合わせしてもしなくてもよいこと、及び単一の領域が複数の管理ドメインを含むかもしれないことに留意されたいです。
We now define the major components of the reference network.
私たちは今、基準ネットワークの主要コンポーネントを定義します。
We assume that both sending and receiving hosts use RSVP to communicate the quantitative QoS requirements of QoS-aware applications running on the host. In principle, other mechanisms may be used to establish resource reservations in Intserv-capable nodes, but RSVP is clearly the prevalent mechanism for this purpose.
我々は両方の送信側と受信側のホストがホスト上で実行されているQoSに対応したアプリケーションの量的なQoS要件を伝達するためにRSVPを使用することを前提としています。原則的に、他の機構のIntServ可能なノードにリソース予約を確立するために使用されてもよいが、RSVPは、明らかにこの目的のために普及している機構です。
Typically, a QoS process within the host operating system generates RSVP signaling on behalf of applications. This process may also invoke local traffic control.
典型的には、ホスト・オペレーティング・システム内のQoS処理は、アプリケーションに代わってRSVPシグナリングを生成します。このプロセスは、ローカルトラフィック制御を呼び出すことができます。
As discussed above, traffic control in the host may mark the DSCP in transmitted packets, and shape transmitted traffic to the requirements of the Intserv service in use. Alternatively, the first Intserv-capable router downstream from the host may provide these traffic control functions.
上述したように、ホストにおけるトラフィック制御は、送信されたパケットのDSCPをマークし、使用中のIntServサービスの要求に送信されたトラフィックをシェーピングしてもよいです。あるいは、ホストから下流最初のIntServ対応ルータは、これらのトラフィック制御機能を提供することができます。
We assume that RSVP signaling messages travel end-to-end between hosts Tx and Rx to support RSVP/Intserv reservations outside the Diffserv network region. We require that these end-to-end RSVP messages are at least carried across the Diffserv region. Depending on the specific realization of the framework, these messages may be processed by none, some or all of the routers in the Diffserv region.
我々は、RSVPシグナリングメッセージは、Diffservのネットワーク領域外RSVP / IntServのは、予約をサポートするために、エンドツーエンドホストのTxとRxの間を移動すると仮定します。我々は、これらのエンドツーエンドのRSVPメッセージは、少なくともDiffservの地域全体で行われている必要があります。フレームワークの特定の実現に応じて、これらのメッセージはどれも、Diffservの地域内のルータの一部または全てによって処理することができます。
ER1 and ER2 are edge routers, residing adjacent to the Diffserv network regions. The functionality of the edge routers varies depending on the specific realization of the framework. In the case in which the Diffserv network region is RSVP unaware, edge routers act as admission control agents to the Diffserv network. They process signaling messages from both Tx and Rx, and apply admission control based on resource availability within the Diffserv network region and on customer defined policy. In the case in which the Diffserv network region is RSVP aware, the edge routers apply admission control based on local resource availability and on customer defined policy. In this case, the border routers act as the admission control agent to the Diffserv network region.
ER1およびER2はDiffservのネットワーク領域に隣接して存在する、エッジルータです。エッジルータの機能は、フレームワークの特定の実現に依存して変化します。 Diffservのネットワーク領域がRSVP非認識である場合には、エッジルータはDiffservのネットワークにアドミッション制御剤として作用します。彼らは、TxとRxの両方から信号メッセージを処理し、Diffservのネットワーク領域内および顧客定義されたポリシーにリソースの可用性に基づいたアドミッション制御を適用します。 Diffservのネットワーク領域は、RSVPアウェアである場合には、エッジルータは、ローカルリソースの可用性に、顧客定義されたポリシーに基づいたアドミッション制御を適用します。この場合には、境界ルータはDiffservのネットワーク領域にアドミッション制御剤として作用します。
We will later describe the functionality of the edge routers in greater depth for each of the two realizations of the framework.
我々は後にフレームワーク二実現のそれぞれについてより深くエッジルータの機能を説明します。
BR1 and BR2 are border routers, residing in the Diffserv network region. The functionality of the border routers varies depending on the specific realization of the framework. In the case in which the Diffserv network region is RSVP-unaware, these routers act as pure Diffserv routers. As such, their sole responsibility is to police submitted traffic based on the service level specified in the DSCP and the agreement negotiated with the customer (aggregate trafficcontrol). In the case in which the Diffserv network region is RSVP-aware, the border routers participate in RSVP signaling and act as admission control agents for the Diffserv network region.
BR1とBR2はDiffservのネットワーク領域に常駐している、境界ルータです。境界ルータの機能は、フレームワークの特定の実現に依存して変化します。 Diffservのネットワーク領域がRSVP非対応である場合には、これらのルータは、純粋なDiffservのルータとして作用します。警察はDSCPおよび顧客（集計trafficcontrol）と交渉の合意で指定されたサービスレベルに基づいてトラフィックを提出するなど、彼らの唯一の責任です。 Diffservのネットワーク領域がRSVP対応である場合には、境界ルータはDiffservのネットワーク領域のためのアドミッション制御剤としてRSVPシグナリング及び作用に関与します。
We will later describe the functionality of the border routers in greater depth for each of the two realizations of the framework.
私たちは、後にフレームワークの2つの実現のそれぞれについて、より深く境界ルータの機能について説明します。
The Diffserv network region supports aggregate traffic control and is assumed not to be capable of MF classification. Depending on the specific realization of the framework, some number of routers within the Diffserv region may be RSVP aware and therefore capable of per-flow signaling and admission control. If devices in the Diffserv region are not RSVP aware, they will pass RSVP messages transparently with negligible performance impact (see [6]).
Diffservのネットワーク領域は、集約トラフィック制御をサポートし、MF分類することができるようにしないと仮定されます。フレームワークの特定の実現に依存して、Diffservの領域内のルータのいくつかの数は、RSVPアウェアおよびフローごとのシグナリングおよびアドミッション制御の、したがってことが可能であってもよいです。 Diffservの領域内のデバイスが認識RSVPされていない場合、それらは無視できるパフォーマンスへの影響と透過RSVPメッセージを通過する（参照[6]）。
The Diffserv network region provides two or more levels of service based on the DSCP in packet headers. It may be a single administrative domain or may span multiple domains.
Diffservのネットワーク領域は、パケットヘッダ内のDSCPに基づいて、サービスの2つ以上のレベルを提供します。これは、単一の管理ドメインであってもよいし、複数のドメインにまたがることがあります。
The network outside of the Diffserv region consists of Intserv capable hosts and other network elements. Other elements may include routers and perhaps various types of network (e.g., 802, ATM, etc.). These network elements may reasonably be assumed to support Intserv, although this might not be required in the case of over-provisioning. Even if these elements are not Intserv capable, we assume that they will pass RSVP messages unhindered. Routers outside of the Diffserv network region are not precluded from providing aggregate traffic control to some subset of the traffic passing through them.
Diffservの領域の外部ネットワークは、IntServのできるホストと他のネットワーク要素から成ります。他の要素は、ルータ、ネットワークのおそらく様々な種類（例えば、802、ATMなど）を含むことができます。これは、オーバープロビジョニングの場合には必要とされないかもしれないが、これらのネットワーク要素は、合理的に、のIntServをサポートすると仮定することができます。これらの要素ができるイントサーブされていない場合でも、我々は、彼らがRSVPメッセージを妨害されずに通過しますと仮定します。 Diffservのネットワーク領域の外のルータがそれらを通過するトラフィックのサブセットを集約トラフィック制御を提供するから除外されません。
Intserv service requests specify an Intserv service type and a set of quantitative parameters known as a "flowspec". At each hop in an Intserv network, the Intserv service requests are interpreted in a form meaningful to the specific link layer medium. For example at an 802.1 hop, the Intserv parameters are mapped to an appropriate 802.1p priority level [5].
IntServのサービス要求は、IntServのサービスタイプと「フロースペック」として知られている定量的なパラメータのセットを指定します。 IntServネットワークの各ホップで、IntServのサービス要求は、特定のリンク層媒体への意味のある形で解釈されます。 802.1ホップで、例えば、のIntServパラメータは、適切な802.1pプライオリティレベル[5]にマッピングされます。
In our framework, Diffserv regions of the network are analogous to the 802.1p capable switched segments described in [5]. Requests for Intserv services must be mapped onto the underlying capabilities of the Diffserv network region. Aspects of the mapping include:
我々のフレームワークでは、ネットワークのDiffservの領域ができる[5]に記載のセグメントを切り替え802.1Pに類似しています。イントサーブサービスに対する要求は、Diffservのネットワーク領域の基礎となる能力上にマッピングする必要があります。マッピングの側面が含まれます：
- selecting an appropriate PHB, or set of PHBs, for the requested
service;
- performing appropriate policing (including, perhaps, shaping or
remarking) at the edges of the Diffserv region;
- exporting Intserv parameters from the Diffserv region (e.g., for
the updating of ADSPECs);
- performing admission control on the Intserv requests that takes
into account the resource availability in the Diffserv region.
Exactly how these functions are performed will be a function of the way bandwidth is managed inside the Diffserv network region, which is a topic we discuss in Section 4.3.
正確には、これらの機能がどのように実行されるか、帯域幅が、我々は4.3節で議論する話題でたDiffservネットワーク領域、内部で管理されている方法の関数であろう。
When the PHB (or set of PHBs) has been selected for a particular Intserv flow, it may be necessary to communicate the choice of DSCP for the flow to other network elements. Two schemes may be used to achieve this end, as discussed below.
PHB（またはのPHBのセット）は特定のIntServフローのために選択された場合、他のネットワーク要素への流れのためのDSCPの選択を通信するために必要であってもよいです。以下に説明するように、2つの方式は、この目的を達成するために使用されてもよいです。
In this scheme, there is some standard, well-known mapping from Intserv service type to a DSCP that will invoke the appropriate behavior in the Diffserv network.
この方式では、Diffservのネットワーク内の適切な動作を呼び出すDSCPへのIntServサービスタイプからのいくつかの標準的な、周知のマッピングがあります。
In this scheme, RSVP conversant routers in the Diffserv network region (perhaps at its edge) may override the well-known mapping described in 4.2.1. In the case that DSCPs are marked at the ingress to the Diffserv region, the DSCPs can simply be remarked at the boundary routers. However, in the case that DSCP marking occurs upstream of the Diffserv region, either in a host or a router, then the appropriate mapping needs to be communicated upstream, to the marking device. This may be accomplished using RSVP, as described in [14].
この方式では、（おそらく、その縁部で）のDiffservネットワーク領域に精通ルータをRSVP 4.2.1に記載の周知のマッピングを無効にしてもよいです。 DSCPは、Diffservの地域への入口でマークされている場合は、DSCPを、単に境界ルータで発言することができます。ただし、DSCPマーキングは、ホスト又はルータのいずれかで、Diffservの領域の上流に発生した場合に、適切なマッピングがマーキング装置に、上流通信する必要があります。 [14]に記載されているように、これは、RSVPを使用して達成することができます。
The decision regarding where to mark DSCP and whether to override the well-known service mapping is a mater of policy to be decided by the administrator of the Diffserv network region in cooperation with the administrator of the network adjacent to the Diffserv region.
DSCPをマークするためにどこでよく知られているサービスのマッピングを上書きするか否かに関する決定は、ポリシーの母校は、Diffservの領域に隣接するネットワークの管理者と連携したDiffservネットワーク領域の管理者によって決定されるべきです。
Boundary routers residing at the edge of the Diffserv region will typically police traffic submitted from the outside the Diffserv region in order to protect resources within the Diffserv region. This policing will be applied on an aggregate basis, with no regard for the individual microflows making up each aggregate. As a result, it is possible for a misbehaving microflow to claim more than its fair share of resources within the aggregate, thereby degrading the service provided to other microflows. This problem may be addressed by:
Diffservの領域の端に常駐する境界ルータは、一般的に警察のトラフィックは、Diffservの領域内のリソースを保護するためにDiffservの領域外から提出されます。このポリシングは、各集計を構成する個々のマイクロフローとは関係なく、集計ベースで適用されます。誤動作マイクロそれにより他のマイクロフローに提供されるサービスを分解、凝集内のリソースの公正なシェア以上を主張する結果として、それが可能です。この問題は、によって対処することができます。
1. Providing per microflow policing at the edge routers - this is generally the most appropriate location for microflow policing, since it pushes per-flow work to the edges of the network, where it scales better. In addition, since Intserv-capable routers outside the Diffserv region are responsible for providing microflow service to their customers and the Diffserv region is responsible for providing aggregate service to its customers, this distribution of functionality mirrors the distribution of responsibility.
1.エッジルータでマイクロフローポリシングごと提供 - それは、より良いスケーリングネットワークのエッジにフローごとの作業を押すので、これは、一般的にマイクロフローポリシングのために最も適切な場所です。 Diffservの領域外イントサーブ対応ルータが顧客にマイクロフローサービスを提供する責任があるとDiffservの領域は、顧客に集約サービスを提供する責任があるので、また、機能のこの分布は、責任の分布を反映しています。
2. Providing per microflow policing at the border routers - this approach tends to be less scalable than the previous approach. It also imposes a management burden on the Diffserv region of the network. However, it may be appropriate in certain cases, for the Diffserv boundary routers to offer per microflow policing as a value-add to its Intserv customers.
2.境界ルータでマイクロフローポリシングごと提供 - この手法は、従来のアプローチよりも少ないスケーラブルになる傾向があります。また、ネットワークのDiffservの領域上の管理負担を課します。 Diffservの境界ルータがそのイントサーブ顧客に付加価値として、マイクロフローポリシングごとに提供するためにしかし、それは、特定の場合には適切かもしれません。
3. Relying on upstream shaping and policing - in certain cases, the customer may trust the shaping of certain groups of hosts sufficiently to not warrant reshaping or policing at the boundary of the Diffserv region. Note that, even if the hosts are shaping microflows properly, these shaped flows may become distorted as they transit through the non-Diffserv region of the network. Depending on the degree of distortion, it may be necessary to somewhat over-provision the aggregate capacities in the Diffserv region, or to re-police using either 1 or 2 above. The choice of one mechanism or another is a matter of policy to be decided by the administrator of the network outside the Diffserv region.
3.上流シェーピングおよびポリシングに依存する - 特定のケースでは、顧客が十分に整形またはDiffservの領域の境界でポリシングを保証しないようにホストの特定のグループの整形を信頼することができます。ホストが正しくマイクロフローを成形している場合でも、これらの形状のフローがネットワークの非Diffservの領域を介してそれらトランジットとして歪むことができることに留意されたいです。歪みの程度に応じて、それは、集約のDiffserv領域において容量、又は1又は上記2のいずれかを使用して再警察に多少オーバープロビジョニングする必要があるかもしれません。一つのメカニズムまたは他の選択は、ポリシーの問題はDiffservの領域外のネットワークの管理者によって決定されることになっています。
A variety of options exist for management of resources (e.g., bandwidth) in the Diffserv network regions to meet the needs of end-to-end Intserv flows. These options include:
さまざまなオプションは、エンドツーエンドのIntServフローのニーズを満たすためにDiffservのネットワーク領域内のリソース（例えば、帯域幅）の管理のために存在します。これらのオプションは、次のとおりです。
- statically provisioned resources;
- resources dynamically provisioned by RSVP;
- resources dynamically provisioned by other means (e.g., a form of
Bandwidth Broker).
Some of the details of using each of these different approaches are discussed in the following section.
これらの異なるアプローチの各々を用いての詳細のいくつかは、以下のセクションで説明されています。
In this section we provide detailed examples of our framework in action. We discuss two examples, one in which the Diffserv network region is RSVP unaware, the other in which the Diffserv network region is RSVP aware.
このセクションでは、アクションで私たちのフレームワークの詳細な例を提供します。私たちは、Diffservのネットワーク領域がRSVP認識している他のどの二つの例、Diffservのネットワーク領域がRSVP認識していないでものを、議論します。
In this example, no devices in the Diffserv network region are RSVP aware. The Diffserv network region is statically provisioned. The customer(s) of the Diffserv network regions and the owner of the Diffserv network region have negotiated a static contract (service level specification, or SLS) for the transmit capacity to be provided to the customer at each of a number of standard Diffserv service levels. The "transmit capacity" may be simply an amount of bandwidth or it could be a more complex "profile" involving a number of factors such as burst size, peak rate, time of day etc.
この例では、Diffservのネットワーク地域にはデバイスがRSVP認識していません。 Diffservのネットワーク領域が静的にプロビジョニングされます。 Diffservのネットワーク領域とDiffservネットワーク領域の所有者の顧客（複数可）は、標準のDiffservサービスの数のそれぞれに顧客に提供される送信能力のための静的な契約（サービスレベル仕様、またはSLS）をネゴシエートしていますレベル。 「送信容量」は、単に帯域幅の量であってもよく、または、より複雑なようなバーストサイズのような多くの要因が関与する「プロファイル」、ピーク速度、時刻等とすることができます
It is helpful to consider each edge router in the customer network as consisting of two halves, a standard Intserv half, which interfaces to the customer's network regions and a Diffserv half which interfaces to the Diffserv network region. The Intserv half is able to identify and process traffic on per-flow granularity.
2つの半体、顧客のネットワーク領域とDiffservネットワーク領域にインタフェースDiffservの半分とインタフェース標準のIntServの半分、からなるように、顧客のネットワーク内の各エッジルータを考慮することが有用です。イントサーブの半分は、フロー単位の細かさでトラフィックを識別し、処理することができます。
The Diffserv half of the router can be considered to consist of a number of virtual transmit interfaces, one for each Diffserv service level negotiated in the SLS. The router contains a table that indicates the transmit capacity provisioned, per the SLS at each Diffserv service level. This table, in conjunction with the default mapping described in 4.2.1, is used to perform admission control decisions on Intserv flows which cross the Diffserv network region.
ルータのDiffservの半分は、仮想送信インターフェイス、SLSで交渉各Diffservのサービスレベルのための1つの数から成ると考えることができます。ルータは、各DiffservのサービスレベルのSLSあたり、プロビジョニングされた送信容量を示すテーブルを含みます。このテーブルは、4.2.1で説明したデフォルトのマッピングと併せて、Diffservのネットワーク領域を横切るのIntServフローにアドミッション制御決定を行うために使用されます。
The following sequence illustrates the process by which an application obtains end-to-end QoS when RSVP is used by the hosts.
以下のシーケンスは、RSVPは、ホストによって使用されているときに、アプリケーションは、エンドツーエンドのQoSを取得するプロセスを示します。
1. The QoS process on the sending host Tx generates an RSVP PATH message that describes the traffic offered by the sending application.
1.送信側ホストのTxのQoSプロセスは、送信側アプリケーションによって提供されるトラフィックを記述するRSVP PATHメッセージを生成します。
2. The PATH message is carried toward the receiving host, Rx. In the network region to which the sender is attached, standard RSVP/Intserv processing is applied at capable network elements.
2. PATHメッセージは、受信側ホスト、受信に向けて搬送されます。送信側が接続されているネットワーク領域では、標準RSVP / IntServの処理が可能なネットワーク要素に適用されます。
3. At the edge router ER1, the PATH message is subjected to standard RSVP processing and PATH state is installed in the router. The PATH message is sent onward to the Diffserv network region.
3.エッジルータER1で、PATHメッセージは、標準RSVP処理が施され、PATH状態がルータにインストールされています。 PATHメッセージは、Diffservのネットワーク領域に以降送信されます。
4. The PATH message is ignored by routers in the Diffserv network region and then processed at ER2 according to standard RSVP processing rules.
4. PATHメッセージは、Diffservのネットワーク領域内のルータによって無視され、次いで、標準的なRSVP処理ルールに従ってER2で処理されます。
5. When the PATH message reaches the receiving host Rx, the operating system generates an RSVP RESV message, indicating interest in offered traffic of a certain Intserv service type.
5. PATHメッセージが受信側ホストのRxに到達すると、オペレーティングシステムは、特定のIntServサービスタイプの提供されたトラフィックに関心を示し、RSVP RESVメッセージを生成します。
6. The RESV message is carried back towards the Diffserv network region and the sending host. Consistent with standard RSVP/Intserv processing, it may be rejected at any RSVP-capable node in the path if resources are deemed insufficient to carry the traffic requested.
6. RESVメッセージはバックDiffservのネットワーク領域と送信側ホストに向けて搬送されます。リソースが要求されたトラフィックを運ぶためには不十分と考えられる場合、標準的なRSVP / IntServの処理と一致し、それは経路内の任意のRSVP対応ノードで拒否されてもよいです。
7. At ER2, the RESV message is subjected to standard RSVP/Intserv processing. It may be rejected if resources on the downstream interface of ER2 are deemed insufficient to carry the resources requested. If it is not rejected, it will be carried transparently through the Diffserv network region, arriving at ER1.
ER2において7は、RESVメッセージは、標準RSVP / IntServの処理が行われます。 ER2のダウンストリームインターフェイス上のリソースが要求されたリソースを運ぶためには不十分と認められる場合には拒否することができます。それは却下されていない場合、それはER1に到着し、Diffservのネットワーク領域を介して透過的に実行されます。
8. In ER1, the RESV message triggers admission control processing. ER1 compares the resources requested in the RSVP/Intserv request to the resources available in the Diffserv network region at the corresponding Diffserv service level. The corresponding service level is determined by the Intserv to Diffserv mapping discussed previously. The availability of resources is determined by the capacity provisioned in the SLS. ER1 may also apply a policy decision such that the resource request may be rejected based on the customer's specific policy criteria, even though the aggregate resources are determined to be available per the SLS.
ER1 8.、RESVメッセージは、受付制御処理をトリガします。 ER1は、対応するDiffservのサービスレベルでのDiffservのネットワーク領域内の利用可能なリソースへのRSVP / IntServの要求で要求されたリソースを比較します。対応するサービスレベルは、前述のIntServのDiffservにマッピングすることによって決定されます。リソースの可用性はSLSでプロビジョニング容量によって決定されます。 ER1は、リソース要求を集約リソースはSLSごとに利用可能であることが決定されているにもかかわらず、顧客の特定のポリシー基準に基づいて拒否することができるような政策決定を適用することができます。
9. If ER1 approves the request, the RESV message is admitted and is allowed to continue upstream towards the sender. If it rejects the request, the RESV is not forwarded and the appropriate RSVP error messages are sent. If the request is approved, ER1 updates its internal tables to indicate the reduced capacity available at the admitted service level on its transmit interface.
ER1が要求を承認した場合9.、RESVメッセージが入院され、送信者に向けて上流に継続させています。それは要求を拒否した場合、RESVは転送されず、適切なRSVPエラーメッセージが送信されます。リクエストが承認された場合、ER1は、その送信インターフェイス上の入院サービスレベルで利用可能能力の減少を示すために、その内部テーブルを更新します。
10. The RESV message proceeds through the network region to which the sender is attached. Any RSVP node in this region may reject the reservation request due to inadequate resources or policy. If the request is not rejected, the RESV message will arrive at the sending host, Tx.
10. RESVメッセージは、送信側が接続されているネットワーク領域を通って進みます。この領域内の任意のRSVPノードは不十分なリソースまたはポリシーに予約要求を拒否することができます。要求が拒否されていない場合は、RESVメッセージが送信側ホスト、テキサス州に到着します。
11. At Tx, the QoS process receives the RESV message. It interprets receipt of the message as indication that the specified traffic flow has been admitted for the specified Intserv service type (in the
テキサス州11と、QoS処理がRESVメッセージを受信します。それに（指定されたトラフィックフローは、指定のIntServサービスタイプのために入院されたという指示としてメッセージの受信を解釈します
Intserv-capable nodes). It may also learn the appropriate DSCP marking to apply to packets for this flow from information provided in the RESV.
IntServの対応ノード）。また、RESVで提供された情報から、このフローのパケットに適用する適切なマーキングDSCPを学ぶことがあります。
12. Tx may mark the DSCP in the headers of packets that are transmitted on the admitted traffic flow. The DSCP may be the default value which maps to the Intserv service type specified in the admitted RESV message, or it may be a value explicitly provided in the RESV.
12. Txが認めトラフィックフロー上で送信されるパケットのヘッダにDSCPをマークすることができます。 DSCPは認めRESVメッセージで指定のIntServサービスタイプにマップするデフォルト値であってもよいし、明示的RESVに設けられた値であってもよいです。
In this manner, we obtain end-to-end QoS through a combination of networks that support RSVP/Intserv and networks that support Diffserv.
このように、我々は、RSVP / IntServのとDiffservのをサポートするネットワークをサポートするネットワークの組み合わせを通じて、エンドツーエンドのQoSを得ます。
In this example, the customer's edge routers are standard RSVP routers. The border router, BR1 is RSVP aware. In addition, there may be other routers within the Diffserv network region which are RSVP aware. Note that although these routers are able to participate in some form of RSVP signaling, they classify and schedule traffic in aggregate, based on DSCP, not on the per-flow classification criteria used by standard RSVP/Intserv routers. It can be said that their control-plane is RSVP while their data-plane is Diffserv. This approach exploits the benefits of RSVP signaling while maintaining much of the scalability associated with Diffserv.
この例では、顧客のエッジルータは、標準のRSVPルータです。境界ルータ、BR1は、RSVP認識しています。また、RSVPアウェアであるDiffservのネットワーク領域内の他のルータが存在してもよいです。これらのルータは、RSVPシグナリングの何らかの形で関与することがあるが、それらはDSCPではなく、標準RSVP / IntServのルータによって使用されるフローごとの分類基準に基づいて、合計で分類し、スケジュールトラフィックことに留意されたいです。彼らのデータプレーンはDiffservのであるが、それらの制御プレーンは、RSVPといえます。 Diffservのに関連したスケーラビリティの多くを維持しながら、このアプローチは、RSVPシグナリングのメリットを活用します。
In the preceding example, there is no signaling between the Diffserv network region and network elements outside it. The negotiation of an SLS is the only explicit exchange of resource availability information between the two network regions. ER1 is configured with the information represented by the SLS and as such, is able to act as an admission control agent for the Diffserv network region. Such configuration does not readily support dynamically changing SLSs, since ER1 requires reconfiguration each time the SLS changes. It is also difficult to make efficient use of the resources in the Diffserv network region. This is because admission control does not consider the availability of resources in the Diffserv network region along the specific path that would be impacted.
前述の例では、外部のDiffservネットワーク領域とネットワーク要素との間にシグナリングは存在しません。 SLSのネゴシエーションは、2つのネットワーク領域間の資源可用性情報の明示的な交換です。 ER1は、SLSによって表される情報で構成さなど、Diffservのネットワーク領域のためのアドミッション制御剤として作用することが可能です。 ER1はたびSLSの変更を再設定を必要とするため、このような構成は、容易に動的に、SLSSの変更をサポートしません。たDiffservネットワーク領域内のリソースを効率的に使用することも困難です。アドミッションコントロールが影響を受けることになる特定のパスに沿ったDiffservネットワーク領域内のリソースの利用可能性を考慮していないためです。
By contrast, when the Diffserv network region is RSVP aware, the admission control agent is part of the Diffserv network. As a result, changes in the capacity available in the Diffserv network region can be indicated to the Intserv-capable nodes outside the Diffserv region via RSVP. By including routers interior to the Diffserv network region in RSVP signaling, it is possible to simultaneously improve the efficiency of resource usage within the Diffserv region and to improve the level of confidence that the resources requested at admission control are indeed available at this particular point in time. This is because admission control can be linked to the availability of resources along the specific path that would be impacted. We refer to this benefit of RSVP signaling as "topology aware admission control". A further benefit of supporting RSVP signaling within the Diffserv network region is that it is possible to effect changes in the provisioning of the Diffserv network region (e.g., allocating more or less bandwidth to the EF queue in a router) in response to resource requests from outside of the Diffserv region.
Diffservのネットワーク領域がRSVP認識している場合、コントラストによって、アドミッション制御剤は、Diffservのネットワークの一部です。結果として、Diffservのネットワーク領域内の空き容量の変化は、RSVPを介して、Diffservの領域外のIntServ対応ノードに示すことができます。 RSVPシグナリングにDiffservのネットワーク領域への内部ルータを含むことによって、同時にDiffservの領域内のリソースの使用の効率を改善し、アドミッション制御で要求されたリソースは、この特定の時点で実際に利用可能であることを信頼性のレベルを向上させることができます時間。アドミッションコントロールが影響を受けることになる特定のパスに沿ってリソースの可用性にリンクすることができるからです。私たちは、「トポロジーを意識アドミッション制御」としてRSVPシグナリングのこの利点を参照してください。 Diffservのネットワーク領域内のRSVPシグナリングをサポートする更なる利点は、Diffservのネットワーク領域のプロビジョニングの変更を行うことが可能であるということである（例えば、より多くの又はより少ない帯域幅EFキューにルータに割り当てる）からリソース要求に応答してDiffservの領域の外側。
Various mechanisms may be used within the Diffserv network region to support dynamic provisioning and topology aware admission control. These include aggregated RSVP, per-flow RSVP and bandwidth brokers, as described in the following paragraphs.
様々なメカニズムは、動的プロビジョニングおよびトポロジー認識アドミッション制御をサポートするために、Diffservのネットワーク領域内で使用されてもよいです。以下の段落で説明したように、これらは、集約RSVP、フローごとのRSVPと帯域幅ブローカーが挙げられます。
A number of documents [3,6,15,16] propose mechanisms for extending RSVP to reserve resources for an aggregation of flows between edges of a network. Border routers may interact with core routers and other border routers using aggregated RSVP to reserve resources between edges of the Diffserv network region. Initial reservation levels for each service level may be established between major border routers, based on anticipated traffic patterns. Border routers could trigger changes in reservation levels as a result of the cumulative per-flow RSVP requests from the non-Diffserv regions reaching high or low-water marks.
ドキュメントの数は[3,6,15,16]ネットワークのエッジとの間のフローの集合のためのリソースを予約するRSVPを拡張するためのメカニズムを提案します。境界ルータはDiffservのネットワーク領域のエッジ間でリソースを予約するために、集約RSVPを使用して、コア・ルータと他の境界ルータと相互作用することができます。各サービスレベルの初期予約レベルが予想されるトラフィックパターンに基づいて、主要な境界ルータ間で確立することができます。境界ルータは、高または低ウォーターマークに到達する非Diffservの領域からの累積的なフローごとのRSVP要求の結果として、予約レベルの変化を引き起こす可能性。
In this approach, admission of per-flow RSVP requests from nodes outside the Diffserv region would be counted against the appropriate aggregate reservations for the corresponding service level. The size of the aggregate reservations may or may not be dynamically adjusted to deal with the changes in per-flow reservations.
このアプローチでは、Diffservの領域外のノードからフローごとのRSVP要求の入場は、対応するサービス・レベルに適した凝集体の予約に対してカウントされることになります。集約の予約のサイズは、動的フローごとの予約の変化に対処するように調整してもしなくてもよいです。
The advantage of this approach is that it offers dynamic, topology aware admission control to the Diffserv network region without requiring the level of RSVP signaling processing that would be required to support per-flow RSVP.
このアプローチの利点は、フローごとのRSVPを支援するために必要とされるRSVPシグナリング処理のレベルを必要とすることなく、Diffservのネットワーク領域への動的トポロジ認識アドミッション制御を提供することです。
We note that resource management of a Diffserv region using aggregated RSVP is most likely to be feasible only within a single administrative domain, as each domain will probably choose its own mechanism to manage its resources.
私たちは、各ドメインは、おそらくそのリソースを管理するための独自のメカニズムを選択すると、集約RSVPを使用したDiffserv地域の資源管理は、単一の管理ドメイン内で実行可能である可能性が最も高いことに注意してください。
In this approach, described in [3], routers in the Diffserv network region respond to the standard per-flow RSVP signaling originating from the Intserv-capable nodes outside the Diffserv region. This approach provides the benefits of the previous approach (dynamic, topology aware admission control) without requiring aggregated RSVP support. Resources are also used more efficiently as a result of the per-flow admission control. However, the demands on RSVP signaling resources within the Diffserv network region may be significantly higher than in an aggregated RSVP approach.
このアプローチでは、[3]に記載の、Diffservのネットワーク領域内のルータはDiffservの領域外のIntServ対応ノードから発信シグナリング標準フロー毎RSVPに応答します。このアプローチは、集約RSVP支援を必要とすることなく、従来のアプローチ（動的、トポロジー認識アドミッション制御）の利点を提供します。リソースはまた、フローごとのアドミッション制御の結果として、より効率的に使用されます。しかし、Diffservのネットワーク領域内のRSVPシグナリングリソースに対する要求が集約RSVPアプローチよりも有意に高くてもよいです。
Note that per-flow RSVP and aggregated RSVP are not mutually exclusive in a single Diffserv region. It is possible to use per-flow RSVP at the edges of the Diffserv region and aggregation only in some "core" region within the Diffserv region.
フローごとのRSVPと集約RSVPは、単一のDiffserv領域において相互に排他的ではないことに留意されたいです。 Diffservの領域内でのみ、いくつかの「コア」領域内のDiffserv領域および凝集の縁に当たりフローRSVPを使用することが可能です。
In 4.2.2 and 4.2.3 some subset of the routers within the Diffserv network is RSVP signaling aware (though traffic control is aggregated as opposed to per-flow). The relative number of routers in the core that participate in RSVP signaling is a provisioning decision that must be made by the network administrator.
4.2.2及び4.2.3にDiffservのネットワーク内のルータのいくつかのサブセットは、RSVPシグナリングを認識し（パーフローとは対照的に、トラフィック制御が集約されるが）です。 RSVPシグナリングに関与するコア内のルータの相対数は、ネットワーク管理者によって行われなければならないプロビジョニングの決定です。
In one extreme case, only the border routers participate in RSVP signaling. In this case, either the Diffserv network region must be extremely over-provisioned and therefore, inefficiently used, or else it must be carefully and statically provisioned for limited traffic patterns. The border routers must enforce these patterns.
極端なケースでは、唯一の境界ルータは、RSVPシグナリングに参加します。この場合、いずれかのDiffservネットワーク領域は、プロビジョニングされた上で、極めてなるため、非効率的に使用し、またはそうでなければ、慎重かつ静的に限定されたトラフィックパターンにプロビジョニングされなければならない必要があります。境界ルータは、これらのパターンを適用する必要があります。
In the other extreme case, each router in the Diffserv network region might participate in RSVP signaling. In this case, resources can be used with optimal efficiency, but signaling processing requirements and associated overhead increase. As noted above, RSVP aggregation is one way to limit the signaling overhead at the cost of some loss of optimality in resource utilization.
他の極端な場合では、Diffservのネットワーク領域内の各ルータは、RSVPシグナリングに関与する可能性があります。この場合、リソースは、最適な効率で使用されるが、処理要件および関連するオーバーヘッドの増加をシグナリングすることができます。上述したように、RSVP集約は、リソース使用率の最適のいくらかの損失を犠牲にし、シグナリングオーバーヘッドを制限する1つの方法です。
It is likely that some network administrators will compromise by enabling RSVP signaling on some subset of routers in the Diffserv network region. These routers will likely represent major traffic switching points with over-provisioned or statically provisioned regions of RSVP unaware routers between them.
いくつかのネットワーク管理者はたDiffservネットワーク領域内のルータのいくつかのサブセットにRSVPシグナリングを有効にすることで妥協する可能性があります。これらのルータは、おそらくそれらの間のRSVP気づかないルータのプロビジョニングオーバープロビジョニングまたは静的領域を持つ主要なトラフィック切り替え点を表します。
Border routers might not use any form of RSVP signaling within the Diffserv network region but might instead use custom protocols to interact with an "oracle". The oracle is an agent that has sufficient knowledge of resource availability and network topology to make admission control decisions. The set of RSVP aware routers in the previous two examples can be considered collectively as a form of distributed oracle. In various definitions of the "bandwidth broker" [4], it is able to act as a centralized oracle.
境界ルータはDiffservのネットワーク領域内のRSVPシグナリングのいずれかの形式を使用しない場合がありますが、代わりに「オラクル」と対話するためにカスタムプロトコルを使用することがあります。オラクルは、アドミッション制御の決定を行うために、リソースの可用性とネットワークトポロジの十分な知識を持っている薬剤です。前の2つの例でRSVPアウェアルータのセットは、分散オラクルの形態として一括して考えることができます。 「帯域幅ブローカー」の様々な定義で[4]、集中oracleとして作用することができます。
We have described a framework in which RSVP/Intserv style QoS can be provided across end-to-end paths that include Diffserv network regions. This section discusses some of the implications of this framework for the Diffserv network region.
我々は、RSVP / IntServのスタイルのQoSはDiffservのネットワーク領域を含む、エンドツーエンドのパス間で提供することができるフレームワークを記載しています。このセクションでは、Diffservのネットワーク領域に対して、この枠組みの意味のいくつかを説明します。
A Diffserv network region must meet the following requirements in order for it to support the framework described in this document.
Diffservのネットワーク領域が、それは、この文書で説明するフレームワークをサポートするために、次の要件を満たす必要があります。
1. A Diffserv network region must be able to provide support for the standard Intserv QoS services between its border routers. It must be possible to invoke these services by use of standard PHBs within the Diffserv region and appropriate behavior at the edge of the Diffserv region.
1. AのDiffservネットワーク領域は、その境界ルータ間の標準イントサーブのQoSサービスのためのサポートを提供できなければなりません。 Diffservの領域のエッジでのDiffserv領域および適切な行動の中に、標準のPHBを使用することにより、これらのサービスを呼び出すことが可能でなければなりません。
2. Diffserv network regions must provide admission control information to their "customer" (non-Diffserv) network regions. This information can be provided by a dynamic protocol or through static service level agreements enforced at the edges of the Diffserv region.
2. Diffservのネットワーク領域は、彼らの「顧客」（非DiffServ）のネットワーク領域へのアドミッション制御情報を提供する必要があります。この情報は、ダイナミックプロトコルによって、またはDiffservの領域の縁部に強制静的なサービス・レベル・アグリーメントを介して提供することができます。
3. Diffserv network regions must be able to pass RSVP messages, in such a manner that they can be recovered at the egress of the Diffserv network region. The Diffserv network region may, but is not required to, process these messages. Mechanisms for transparently carrying RSVP messages across a transit network are described in [3,6,15,16].
3. Diffservのネットワーク領域は、それらがDiffservのネットワーク領域の出口で回収することができるように、RSVPメッセージを渡すことができなければなりません。 Diffservのネットワーク領域は、そのプロセスにこれらのメッセージを必要とされていないことがあります。透過中継ネットワークを介してRSVPメッセージを搬送するためのメカニズムは[3,6,15,16]に記載されています。
To meet these requirements, additional work is required in the areas of:
これらの要件を満たすために、追加の作業はの分野で必要とされています。
1. Mapping Intserv style service specifications to services that can be provided by Diffserv network regions.
Diffservのネットワーク領域で提供可能なサービスへのマッピング1.イントサーブスタイルのサービス仕様。
2. Definition of the functionality required in network elements to support RSVP signaling with aggregate traffic control (for network elements residing in the Diffserv network region). 3. Definition of mechanisms to efficiently and dynamically provision resources in a Diffserv network region (e.g., aggregated RSVP, tunneling, MPLS, etc.). This might include protocols by which an "oracle" conveys information about resource availability within a Diffserv region to border routers. One example of such a mechanism is the so-called "bandwidth broker" proposed in [19,20,21].
（Diffservのネットワーク領域内に存在するネットワーク要素のための）集約トラフィック制御とシグナリングRSVPをサポートするためのネットワーク要素に要求される機能の2の定義。 Diffservのネットワーク領域内の機構に効率的かつ動的にプロビジョニングリソース3.定義（例えば、集約RSVP、トンネル、MPLSなど）。これは、「Oracleは」境界ルータにDiffservの領域内のリソースの可用性に関する情報を搬送することにより、プロトコルが含まれる場合があります。そのような機構の一例は、[19,20,21]で提案されている、いわゆる「帯域ブローカー」です。
Network administrators must be able to share resources in the Diffserv network region between three types of traffic:
ネットワーク管理者はトラフィックの3種類の間のDiffservネットワーク領域内のリソースを共有することができなければなりません。
a. End-to-end Intserv traffic. This is typically traffic associated with quantitative QoS applications. It requires a specific quantity of resources with a high degree of assurance.
A。エンドツーエンドのIntServトラフィック。これは、一般的に定量的なQoSアプリケーションに関連するトラフィックです。これは、保証度の高いリソースの特定の量が必要です。
b. Non-Intserv traffic. The Diffserv region may allocate resources to traffic that does not make use of Intserv techniques to quantify its requirements, e.g., through the use of static provisioning and SLSs enforced at the edges of the region. Such traffic might be associated with applications whose QoS requirements are not readily quantifiable but which require a "better than best-effort" level of service.
B。非イントサーブトラフィック。 Diffservの領域は、領域の縁部に適用静的プロビジョニングおよびSLSSの使用を介して、例えば、その要件を定量化するためのIntServ技術を利用しないトラフィックにリソースを割り当てることができます。このようなトラフィックは、そのQoSの要件を容易に定量化できるものではなく、サービスの「ベストエフォート型よりも良い」レベルを必要とするアプリケーションに関連付けられている可能性があります。
c. All other (best-effort) traffic. These three classes of traffic must be isolated from each other by the appropriate configuration of policers and classifiers at ingress points to the Diffserv network region, and by appropriate provisioning within the Diffserv network region. To provide protection for Intserv traffic in Diffserv regions of the network, we suggest that the DSCPs assigned to such traffic not overlap with the DSCPs assigned to other traffic.
C。他のすべての（ベストエフォート）トラフィック。トラフィックこれらの3つのクラスは、Diffservのネットワーク領域への入口点でポリサーと分類の適切な構成によって互いに分離され、Diffservのネットワーク領域内の適切なプロビジョニングによってなければなりません。ネットワークのDiffservの領域でのIntServトラフィックに対する保護を提供するために、我々は、このようなトラフィックに割り当てられたのDSCPは、他のトラフィックに割り当てられたのDSCPと重複していないことを示唆しています。
The use of integrated services over Diffserv networks is significantly more complex for multicast sessions than for unicast sessions. With respect to a multicast connection, each participating region has a single ingress router and zero, one or several egress routers. The difficulties of multicast are associated with Diffserv regions that contain several egress routers. (Support of multicast functionality outside the Diffserv region is relatively straightforward since every Intserv-capable router along the multicast tree stores state for each flow.)
Diffservのネットワーク上で統合されたサービスの利用には、ユニキャストセッションのためのよりマルチキャストセッションのためにかなり複雑です。マルチキャスト接続に関しては、各参加領域は、単一の入口ルータと、ゼロ、1つまたはいくつかの出口ルータを有しています。マルチキャストの難しさは、いくつかの出口ルーターが含まれているDiffservの領域に関連しています。 （Diffservの領域外マルチキャスト機能のサポートは、各フローのマルチキャストツリーを格納する状態に沿った全てのIntServ対応ルータので、比較的簡単です。）
Consider the following reference network:
以下の基準ネットワークを考えてみます。
Non-Diffserv region 2
________
/ \
| | |---|
________ _____________ | |-|Rx1|
/ \ / |--\ |---| | |---|
/ \ / /|BR2\-----\ER2| /
|---| | |---| |---| |--|/ |---| \--|____/
|Tx |-| |ER1|---|BR1|--|RR| | ________
|---| | |-- | |---| |--|\ |---| /--| \
\ / \ \|BR3/-----|ER3| | |---|
\________/ \__________|--/ |---| |-|Rx2|
| | |---|
Non-Diffserv region 1 Diffserv region \ /
\______/
Non-Diffserv region 3
非Diffservの領域3
Figure 2: Sample Multicast Network Configuration
図2：マルチキャストネットワークの設定例
The reference network is similar to that of Figure 1. However, in Figure 2, copies of the packets sent by Tx are delivered to several receivers outside of the Diffserv region, namely to Rx1 and Rx2. Moreover, packets are copied within the Diffserv region in a "branch point" router RR. In the reference network BR1 is the ingress router to the Diffserv region whereas BR2 and BR3 are the egress routers.
基準ネットワークしかし、図1と同様である、図2において、TXによって送信されたパケットのコピー、すなわちRx1と及びRx2とに、Diffservの領域の外にいくつかの受信機に配信されます。また、パケットは、「分岐点」ルータRRにDiffservの領域内にコピーされます。 BR2とBR3が出口ルータであるのに対し、基準ネットワークにBR1は、Diffservの領域への入口ルータです。
In the simplest case the receivers, Rx1 and Rx2 in the reference network, require identical reservations. The Diffserv framework [18] supports service level specifications (SLS) from an ingress router to one, some or all of the egress routers. This calls for a "one to many" SLS within the Diffserv region, from BR1 to BR2 and BR3. Given that the SLS is granted by the Diffserv region, the ingress router BR1, or perhaps an upstream node such as ER1, marks packets entering the Diffserv region with the appropriate DSCP. The packets are routed to the egresses of the Diffserv domain using the original multicast address.
最も簡単な場合では、基準ネットワークにおいて受信機Rx1と及びRx2とは、同一の予約を必要とします。 Diffservのフレームワーク[18]一、出口ルータの一部または全部に、入口ルータからサービスレベル仕様（SLS）をサポートします。これは、BR1からBR2とBR3に、Diffservの領域内のSLS「多くの1つ」を求めています。 SLSは、ER1などのDiffserv領域、入口ルーターBR1、またはおそらく上流ノードによって許可されていることを考えると、適切なDSCPとDiffservの領域に入るパケットをマーク。パケットは、元のマルチキャストアドレスを使用したDiffservドメインのegressesにルーティングされます。
The two major problems, explained in the following, are associated with heterogeneous multicast trees containing branch points within the Diffserv region, i.e., multicast trees where the level of resource requirement is not uniform among all receivers. An example of such a scenario in the network of Figure 2 is the case where both Rx1 and Rx2 need to receive multicast data from Tx1 but only one of the receivers has requested a level of service above best effort. We consider such scenarios in the following paragraphs.
2つの大きな問題は、以下に説明する、Diffservの領域内に分岐点を含む異種マルチキャストツリー、リソース要件のレベルが全ての受信機の間で均一ではない、すなわち、マルチキャストツリーに関連付けられます。図2のネットワークにおけるそのようなシナリオの例は、Rx1と及びRx2との両方がTx1とからマルチキャストデータを受信する必要がなく、受信機の一方のみがサービス上記ベストエフォートのレベルを要求した場合です。私たちは、次の段落では、このようなシナリオを検討してください。
In the above scenario, the packets that arrive at BR1 are marked with an appropriate DSCP for the requested Intserv service and are sent to RR. Packets arriving at the branch point must be sent towards BR2 with the same DSCP otherwise the service to Rx1 is degraded. However, the packets going from RR towards BR3 need not maintain the high assurance level anymore. They may be demoted to best effort so that the QoS provided to other packets along this branch of the tree is not disrupted. Several problems can be observed in the given scenario:
上記のシナリオでは、BR1に到着するパケットは、要求のIntServサービスのための適切なDSCPとマークされ、RRに送られます。分岐点に到達したパケットは、そうでない場合はRx1とするサービスが劣化しているのと同じDSCPとBR2に向けて送信する必要があります。しかし、BR3に向けてRRから行くパケットはもうハイ保証レベルを維持する必要はありません。木の枝に沿って、この他のパケットに提供されるQoSが中断されないように、彼らはベストエフォートに降格することができます。いくつかの問題が特定のシナリオで観察することができます。
- In the Diffserv region, DSCP marking is done at edge routers
(ingress), whereas a branch point router might be a core
router, which does not mark packets.
- Being a core Diffserv router, RR classifies based on aggregate traffic streams (BA), as opposed to per flow (MF) classification. Hence, it does not necessarily have the capability to distinguish those packets which belong to a specific multicast tree and require demotion from the other packets in the behavior aggregate, which carry the same DSCP.
- フローごと（MF）分類とは対照的に、コアのDiffservルータなので、RRは、集約トラフィックストリーム（BA）に基づいて分類します。したがって、それは必ずしも特定のマルチキャストツリーに属し、同じDSCPを運ぶ行動集合内の他のパケットから降格を必要とするそれらのパケットを区別する能力を有していません。
- Since RR may be RSVP-unaware, it may not participate in the admission control process, and would thus not store any per-flow state about the reservations for the multicast tree. Hence, even if RR were able to perform MF classification and DSCP remarking, it would not know enough about downstream reservations to remark the DSCP intelligently.
- RRは、RSVP-気づかないかもしれないので、それは、アドミッション制御プロセスに参加しないことがあり、したがって、マルチキャストツリーの予約に関するフローごとの状態を保存しないであろう。したがって、RRはMF分類およびDSCPの再マーキングを行うことができたとしても、それはインテリジェントにDSCPを指摘すべき下流の予約について十分に知ることはできません。
These problems could be addressed by a variety of mechanisms. We list some below, while noting that none is ideal in all cases and that further mechanisms may be developed in the future:
これらの問題は、様々なメカニズムによって対処することができます。どれもすべての場合に理想的ではありませんし、その更なるメカニズムが将来開発される可能性があることに留意しながら、私たちは、以下のいくつかをリスト：
1. If some Intserv-capable routers are placed within the Diffserv region, it might be possible to administer the network topology and routing parameters so as to ensure that branch points occur only within such routers. These routers would support MF classification and remarking and hold per-flow state for the heterogeneous reservations for which they are the branch point. Note that in this case, branch point routers would have essentially the same functionality as ingress routers of an RSVP-aware Diffserv domain.
1.いくつかのIntServ対応ルータはDiffservの領域内に配置されている場合、その分岐点でのみ、ルータ内で発生保証するようにネットワークトポロジ及びルーティングパラメータを投与することが可能かもしれません。これらのルータは、MFの分類および再マーキングをサポートし、それらが分岐点であるため、異種の予約のためのフローごとの状態を保持します。この場合には、分岐点ルータはRSVP対応のDiffservドメインの入口ルータと本質的に同じ機能を持っていることに注意してください。
2. Packets sent on the "non-reserved" branch (from RR towards BR3) are marked with the "wrong" DSCP; that is, they are not demoted to best effort but retain their DSCP. This in turn requires over reservation of resources along that link or runs the risk of degrading service to packets that legitimately bear the same DSCP along this path. However, it allows the Diffserv routers to remain free of per-flow state.
2.パケットは、「間違った」DSCPでマークされます（BR3へのRRから）「非予約」ブランチで送信しました。つまり、彼らはベストエフォートに降格が、そのDSCPを保持していません。これは、順番にそのリンクに沿ってリソースの予約上必要とするか、または合法的にこのパスに沿って同じDSCPを負担パケットに分解サービスのリスクを実行します。しかし、それはDiffservのルータはフローごとの状態のまま自由にできるようになります。
3. A combination of mechanism 1 and 2 may be an effective compromise. In this case, there are some Intserv-capable routers in the core of the network, but the network cannot be administered so that ALL branch points fall at such routers.
3.機構1及び2の組合せは、効果的な妥協であってもよいです。この場合には、ネットワークのコア内のいくつかのIntServ対応ルータがあるが、全ての分岐点は、ルータに落ちるように、ネットワークを投与することができません。
4. Administrators of Diffserv regions may decide not to enable heterogeneous sub-trees in their domains. In the case of different downstream reservations, a ResvErr message would be sent according to the RSVP rules. This is similar to the approach taken for Intserv over IEEE 802 Networks [2,5].
Diffservの領域の4管理者は、ドメイン内の異種サブツリーを有効にしないことを決定してもよいです。異なる下流の予約の場合には、ResvErrメッセージはRSVPの規則に従って送信されます。これは、IEEE上のIntServために取られたアプローチに類似している802のネットワーク[2,5]。
5. In [3], a scheme was introduced whereby branch point routers in the interior of the aggregation region (i.e., the Diffserv region) keep reduced state information regarding the reservations by using measurement based admission control. Under this scheme, packets are tagged by the more knowledgeable Intserv edges routers with scheduling information that is used in place of the detailed Intserv state. If the Diffserv region and branch point routers are designed following that framework, demotion of packets becomes possible.
[3]、方式が導入された5.れる凝集領域の内部に分岐点ルータ（すなわち、Diffservの領域）計測ベースのアドミッション制御を使用して予約に関する還元状態情報を保持します。この方式では、パケットがより多くの知識が豊富イントサーブによってタグ付けされている詳細なイントサーブ状態の代わりに使用された情報をスケジュールして、ルータをエッジ。 Diffservの領域と分岐点ルータは、そのフレームワーク、以下のように設計されている場合は、パケットの降格が可能となります。
Multicast flows with heterogeneous reservations present some challenges in the area of SLSs. For example, a common example of an SLS is one where a certain amount of traffic is allowed to enter a Diffserv region marked with a certain DSCP, and such traffic may be destined to any egress router of that region. We call such an SLS a homogeneous, or uniform, SLS. However, in a multicast environment, a single packet that is admitted to the Diffserv region may consume resources along many paths in the region as it is replicated and forwarded towards many egress routers; alternatively, it may flow along a single path. This situation is further complicated by the possibility described above and depicted in Figure 2, in which a multicast packet might be treated as best effort along some branches while receiving some higher QOS treatment along others. We simply note here that the specification of meaningful SLSs which meet the needs of heterogeneous flows and which can be met be providers is likely to be challenging.
異種予約はSLSSの分野でいくつかの課題を提示してマルチキャストが流れます。例えば、SLSの一般的な例では、トラフィックの特定の量は、特定のDSCPでマークDiffservの領域に入ることを許可され、そのようなトラフィックは、その領域の任意の出口ルータ宛することができるものです。私たちは、均質な、または均一な、SLS、このようなSLSを呼び出します。それは複製され、多くの出口ルータに向けて転送されるが、マルチキャスト環境では、Diffservの領域に収容された単一のパケットは、領域内の多くのパスに沿ってリソースを消費することができます。あるいは、それは単一の経路に沿って流れることができます。この状況は、別の可能性によって複雑になる上述の図2に示され、他に沿っていくつかのより高いQoS処理を受信中に、マルチキャストパケットがいくつかの枝に沿ってベストエフォートとして扱われるかもしれません。私たちは、単に異種フローのニーズを満たす有意義SLSSの仕様とプロバイダも満たされることに挑戦する可能性があることをここで注意します。
Dynamic SLSs may help to address these issues. For example, by using RSVP to signal the resources that are required along different branches of a multicast tree, it may be possible to more closely approach the goal of allocating appropriate resources only where they are needed rather than overprovisioning or underprovisioning along certain branches of a tree. This is essentially the approach described in [15].
ダイナミックSLSSは、これらの問題に対処するのを助けることができます。例えば、マルチキャストツリーの異なるブランチに沿って必要とされるリソースを通知するRSVPを使用することにより、より密接にそれらが必要とされる場合にのみ、適切なリソースを割り当てるのではなくオーバープロビジョニングまたは特定の枝に沿ってunderprovisioningの目標に近づくことが可能です木。これは、本質的に[15]に記載されたアプローチです。
We are proposing that RSVP signaling be used to obtain resources in both Diffserv and non-Diffserv regions of a network. Therefore, all RSVP security considerations apply [9]. In addition, network administrators are expected to protect network resources by configuring secure policers at interfaces with untrusted customers.
我々は、RSVPシグナリングがネットワークの両方のDiffservと非Diffservの地域内のリソースを取得するために使用することを提案しています。したがって、すべてのRSVPのセキュリティに関する考慮事項が適用されます[9]。また、ネットワーク管理者は、信頼できない顧客との界面での安全なポリサーを設定することにより、ネットワークリソースを保護するために期待されています。
Though it does not mandate host marking of the DSCP, our proposal does allow it. Allowing hosts to set the DSCP directly may alarm network administrators. The obvious concern is that hosts may attempt to "steal" resources. In fact, hosts may attempt to exceed negotiated capacity in Diffserv network regions at a particular service level regardless of whether they invoke this service level directly (by setting the DSCP) or indirectly (by submitting traffic that classifies in an intermediate marking router to a particular DSCP).
それはDSCPのマーキングホストを強制しませんが、私たちの提案は、それを認めていません。ホストはDSCP直接月警報ネットワーク管理者を設定することができます。明白な懸念は、ホストがリソースを「盗む」を試みることです。実際には、ホストは関係なく、特定の中間マーキングルータに分類するトラフィックを送信することにより（直接（DSCPを設定することにより）、または間接的にこのサービスレベルを呼び出すかどうかの特定のサービスレベルでのDiffservネットワーク領域にネゴシエート容量を超過することを試みることができますDSCP）。
In either case, it will generally be necessary for each Diffserv network region to protect its resources by policing to assure that customers do not use more resources than they are entitled to, at each service level (DSCP). The exception to this rule is when the host is known to be trusted, e.g., a server that is under the control of the network administrators. If an untrusted sending host does not perform DSCP marking, the boundary router (or trusted intermediate routers) must provide MF classification, mark and police. If an untrusted sending host does perform marking, the boundary router needs only to provide BA classification and to police to ensure that the customer is not exceeding the aggregate capacity negotiated for the service level.
いずれの場合も、それは一般的に、顧客がそれぞれのサービスレベル（DSCP）で、それらが権利を有しているよりも多くのリソースを使用しないことを保証するためにポリシングすることにより、その資源を保護するために、それぞれのDiffservネットワーク地域のために必要であろう。この規則の例外は、ホストは、例えば、ネットワーク管理者の制御下にあるサーバを信頼することが知られている場合です。信頼できない送信ホストがDSCPマーキングを行っていない場合は、境界ルータ（または信頼できる中間ルータ）は、MFの分類、マークと警察を提供しなければなりません。信頼できない送信ホストがマーキングを行ってない場合は、境界ルータはBAの分類を提供し、顧客がサービス・レベルのために交渉総容量を超えていないことを確認するために警察にのみ必要です。
In summary, there are no additional security concerns raised by marking the DSCP at the edge of the network since Diffserv providers will have to police at their boundaries anyway. Furthermore, this approach reduces the granularity at which border routers must police, thereby pushing finer grain shaping and policing responsibility to the edges of the network, where it scales better and provides other benefits described in Section 3.3.1. The larger Diffserv network regions are thus focused on the task of protecting their networks, while the Intserv-capable nodes are focused on the task of shaping and policing their own traffic to be in compliance with their negotiated Intserv parameters.
要約すると、Diffservのプロバイダは、とにかく自分の境界で警察に持っていますので、ネットワークのエッジでDSCPマーキングによって発生する追加のセキュリティ上の懸念はありません。さらに、このアプローチは、境界ルータは、警察、それによって、より細かい粒整形を押し、それがより良いスケールし、セクション3.3.1で説明した他の利点を提供するネットワークのエッジに責任をポリシングしなければならないの粒度を低減します。 IntServの対応ノードは、それらのネゴシエートのIntServパラメータに準拠するために、独自のトラフィックシェーピング及びポリシングのタスクに焦点を当てている間に大きなDiffservのネットワーク領域は、したがって、それらのネットワークを保護するためのタスクに焦点を当てています。
Authors thank the following individuals for their comments that led to improvements to the previous version(s) of this document: David Oran, Andy Veitch, Curtis Villamizer, Walter Weiss, Francois le Faucheur and Russell White.
デビッド・オラン、アンディVeitchは、カーティスVillamizer、ウォルター・ワイス、フランソワ・ルFaucheurとラッセル・ホワイト：著者は、この文書の以前のバージョン（複数可）の改善につながった彼らのコメントについて以下の個人に感謝します。
Many of the ideas in this document have been previously discussed in the original Intserv architecture document [10].
この文書のアイデアの多くは、以前にオリジナルのIntServアーキテクチャドキュメント[10]で議論されています。
[1] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource Reservation Protocol (RSVP) Version 1 Functional Specification", RFC 2205, September 1997.
[1]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP）バージョン1機能仕様"、RFC 2205、1997年9月。
[2] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F. and M. Speer, "SBM (Subnet Bandwidth Manager): A Protocol For RSVP-based Admission Control Over IEEE 802 Style Networks", RFC 2814, May 2000.
[2] Yavatkar、R.、ホフマン、D.、Bernet、Y.、ベイカー、F.およびM.シュペーア、 "SBM（サブネット帯域幅マネージャー）：IEEE 802スタイルのネットワークを介してRSVPベースのアドミッション制御のためのプロトコル"、 RFC 2814、2000年5月。
[3] Berson, S. and R. Vincent, "Aggregation of Internet Integrated Services State", Work in Progress.
[3]ベルソン、S.とR.ヴィンセント、「インターネット統合サービス状態の集約」が進行中で働いています。
[4] Nichols, K., Jacobson, V. and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", RFC 2638, July 1999.
[4]ニコルズ、K.、ヤコブソン、V.、およびL.チャン、 "インターネットのための2ビット差別化サービスアーキテクチャ"、RFC 2638、1999年7月。
[5] Seaman, M., Smith, A., Crawley, E. and J. Wroclawski, "Integrated Service Mappings on IEEE 802 Networks", RFC 2815, May 2000.
[5]シーマン、M.、スミス、A.、クローリー、E.およびJ. Wroclawski、 "統合サービスマッピングIEEE 802のにネットワーク"、RFC 2815、2000年5月。
[6] Guerin, R., Blake, S. and Herzog, S., "Aggregating RSVP based QoS Requests", Work in Progress.
[6]ゲラン、R.、ブレイク、S.及びヘルツォークを、S.、進行中の作業 "RSVPベースのQoS要求を集約"。
[7] 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.
[7]ニコルズ、K.、ブレイク、S.、ベイカー、F.とD.ブラック、 "IPv4とIPv6ヘッダーの差別化されたサービス分野（DSフィールド）の定義"、RFC 2474、1998年12月。
[8] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[8]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[9] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[9]ベーカー、F.、リンデル、B.及びM. Talwar、 "RSVP暗号化認証"、RFC 2747、2000年1月。
[10] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[10]ブレーデン、R.、クラーク、D.とS. Shenker、 "インターネットアーキテクチャにおける統合サービス：概要"、RFC 1633、1994年6月。
[11] Garrett, M. and M. Borden, "Interoperation of Controlled-Load Service and Guaranteed Service with ATM", RFC 2381, August 1998.
[11]ギャレット、M.とM.ボーデン、「制御・ロード・サービスの相互運用およびATMでの保証サービス」、RFC 2381、1998年8月。
[12] Weiss, Walter, Private communication, November 1998.
[12]ワイス、ウォルター、プライベート通信、1998年11月。
[13] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[13]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[14] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000.
[14] Bernet、Y.、 "RSVP DCLASSオブジェクトのフォーマット"、RFC 2996、2000年11月。
[15] Baker, F., Iturralde, C., le Faucheur, F., and Davie, B. "RSVP Reservation Aggregation", Work in Progress.
[15]ベーカー、F.、Iturralde、C.、ルFaucheur、F.、及びデイビー、B. "RSVP予約集約"、進行中の作業。
[16] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[16] Terzis、A.、Krawczyk、J.、Wroclawski、J.とL.チャン、 "RSVPオペレーションオーバーIPトンネル"、RFC 2746、2000年1月。
[17] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, D. and A. Sastry, "COPS Usage for RSVP", RFC 2749, January 2000.
[17]ボイル、J.、コーエン、R.、ダラム、D.、ヘルツォーク、S.、ラジャン、D.およびA. Sastry、 "RSVPの使用をCOPS"、RFC 2749、2000年1月。
[18] Bernet, Y., "A Framework for Differentiated Services", Work in Progress.
[18] Bernet、Y.、 "差別化サービスのためのフレームワーク"、ProgressのWork。
[19] Jacobson Van, "Differentiated Services Architecture", talk in the Int-Serv WG at the Munich IETF, August 1997.
[19]ヤコブソンヴァン、 "差別化サービスアーキテクチャ"、ミュンヘンIETF、1997年8月でのInt-ServのWGで話します。
[20] Jacobson, V., Nichols K. and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", RFC 2638, June 1999.
[20]ジェーコブソン、V.、ニコルズK.とL.チャン、「インターネットのための2ビットの差別化サービスアーキテクチャ」、RFC 2638、1999年6月。
[21] First Internet2 bandwidth broker operability event http://www.merit.edu/internet/working.groups/i2-qbone-bb/ inter-op/index.htm
[21]まずInternet2の帯域幅ブローカー操作性イベントhttp://www.merit.edu/internet/working.groups/i2-qbone-bb/間OP / index.htmを
Yoram Bernet Microsoft One Microsoft Way Redmond, WA 98052
よらｍ べｒねｔ みｃろそｆｔ おね みｃろそｆｔ わｙ れｄもんｄ、 わ ９８０５２
Phone: +1 425-936-9568 EMail: yoramb@microsoft.com
電話：+1 425-936-9568電子メール：yoramb@microsoft.com
Raj Yavatkar Intel Corporation JF3-206 2111 NE 25th. Avenue Hillsboro, OR 97124
ラジYavatkarインテルコーポレーションJF3-206 2111 NE 25日。アベニューヒルズボロ、OR 97124
Phone: +1 503-264-9077 EMail: raj.yavatkar@intel.com
電話：+1 503-264-9077電子メール：raj.yavatkar@intel.com
Peter Ford Microsoft One Microsoft Way Redmond, WA 98052
ピーター・フォードマイクロソフト1マイクロソフト道、レッドモンド、ワシントン98052
Phone: +1 425-703-2032 EMail: peterf@microsoft.com
電話：+1 425-703-2032電子メール：peterf@microsoft.com
Fred Baker Cisco Systems 519 Lado Drive Santa Barbara, CA 93111
フレッドベイカーシスコシステムズ519ラドドライブサンタバーバラ、CA 93111
Phone: +1 408-526-4257 EMail: fred@cisco.com
電話：+1 408-526-4257電子メール：fred@cisco.com
Lixia Zhang UCLA 4531G Boelter Hall Los Angeles, CA 90095
L I老人張UCLA 4531ギガバイトOEホールロサンゼルス、CA 90095
Phone: +1 310-825-2695 EMail: lixia@cs.ucla.edu
電話：+1 310-825-2695電子メール：lixia@cs.ucla.edu
Michael Speer Sun Microsystems 901 San Antonio Road, UMPK15-215 Palo Alto, CA 94303
マイケル・シュペーアSun Microsystemsの901サンアントニオの道、UMPK15-215パロアルト、CA 94303
Phone: +1 650-786-6368 EMail: speer@Eng.Sun.COM
電話：+1 650-786-6368電子メール：speer@Eng.Sun.COM
Bob Braden USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292-6695
ボブブレーデンUSC /情報科学研究所4676アドミラルティWayマリナデルレイ、カリフォルニア州90292から6695
Phone: +1 310-822-1511 EMail: braden@isi.edu
電話：+1 310-822-1511電子メール：braden@isi.edu
Bruce Davie Cisco Systems 250 Apollo Drive Chelmsford, MA 01824
ブルース・デイビーシスコシステムズ250アポロドライブチェルムズフォード、MA 01824
Phone: +1 978-244-8000 EMail: bsd@cisco.com
電話：+1 978-244-8000電子メール：bsd@cisco.com
Eyal Felstaine SANRAD Inc. 24 Raul Wallenberg st Tel Aviv, Israel
エヤルFelstaine SANRAD株式会社24ラウル・ワレンバーグ聖テルアビブ、イスラエル
Phone: +972-50-747672 Email: eyal@sanrad.com
電話：+ 972-50-747672 Eメール：eyal@sanrad.com
John Wroclawski MIT Laboratory for Computer Science 545 Technology Sq. Cambridge, MA 02139
コンピュータサイエンス545平方技術のためのジョンWroclawski MIT研究所。ケンブリッジ、MA 02139
Phone: +1 617-253-7885 EMail: jtw@lcs.mit.edu
電話：+1 617-253-7885電子メール：jtw@lcs.mit.edu
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。