RFC2998 日本語訳
2998 A Framework for Integrated Services Operation over DiffservNetworks. Y. Bernet, P. Ford, R. Yavatkar, F. Baker, L. Zhang, M.Speer, R. Braden, B. Davie, J. Wroclawski, E. Felstaine. November 2000. (Format: TXT=76378 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
Bernetがコメントのために要求するワーキンググループY.をネットワークでつないでください: 2998年のP.フォードカテゴリ: 情報のマイクロソフトのWroclawski MIT LCS E.Felstaine SANRAD R.YavatkarインテルF.ベイカーコクチマスL.チャンUCLA M.シュペーアサン・マイクロシステムズR.ブレーデンISI B.デイビーコクチマスJ.2000年11月
A Framework for Integrated Services Operation over Diffserv Networks
Diffservネットワークの上の統合サービス操作のためのフレームワーク
Status of this Memo
この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.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
Integrated Services(Intserv)アーキテクチャは異機種ネットワークの上でService(QoS)の終わりから終わりへのQualityの配送のための手段をアプリケーションに提供します。 終わりから終わりへのこのモデルをサポートするために、Intservアーキテクチャをさまざまな異なったタイプのネットワーク要素の上サポートしなければなりません。 このような関係においては、Differentiated Services(Diffserv)をサポートするネットワークはネットワーク要素として終わりから端への総経路で見なされるかもしれません。 このドキュメントはIntegrated ServicesがDiffservネットワークの上でサポートされるかもしれないフレームワークについて説明します。
Bernet, et al. Informational [Page 1] RFC 2998 Integrated Services Over Diffserv Networks November 2000
Bernet、他 情報[1ページ]のRFC2998は2000年11月に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
1. 序論… 3 1.1 統合サービスアーキテクチャ… 3 1.2RSVP… 3 1.3Diffserv… 4 Intserv、RSVP、およびDiffservの1.4の役割… 4 Intserv、RSVP、およびDiffservの1.5の部品… 5 1.6 フレームワーク… 6 1.7の内容… 6 2. DiffservとIntservを使用する利益… 7 2.1リソースは入場コントロールを基礎づけました… 7 2.2方針は入場コントロールを基礎づけました… 8 トラフィック識別/分類における2.3支援… 8 2.3 .1 マークを接待してください… 9 2.3 .2 ルータマーク… 9 2.4 トラフィック調節… 10 3. フレームワーク… 10 3.1参照ネットワーク… 11 3.1 .1 接待します。 11 3.1 .2 終わりから終わりへのRSVPシグナリング… 12 3.1 .3 ルータを斜めに進ませてください… 12 3.1 .4 ルータに接してください… 12 3.1 .5 Diffservは領域をネットワークでつなぎます… 13 3.1 .6 非Diffservは地方をネットワークでつなぎます… 13 3.2 マッピングを修理してください… 13 3.2 .1デフォルトマッピング… 14 3.2 .2 駆動マッピングをネットワークでつないでください… 14 3.2 .3 Microflow分離… 14 3.3 Diffserv地方でのリソース管理… 15 4. Diffserv地方の上のIntservの操作の詳細な例… 16 4.1 静的に食糧を供給されたDiffservは領域をネットワークでつなぎます… 16 4.1 .1 終わりから終わりへのQoSを入手することにおける、イベントの系列… 16 4.2 RSVP意識しているDiffservは領域をネットワークでつなぎます… 18 4.2 .1は、RSVPに集めたか、またはトンネルを堀りました… 19 4.2 .3 1流れあたりのRSVP… 20 4.2 RSVPの意識しているルータの展開の.4粒状… 20 4.3 ダイナミックに食糧を供給される、非RSVP意識する、Diffserv領域… 21 5. Diffservのためのフレームワークの含意は地方をネットワークでつなぎます… 21 Diffservからの5.1の要件が地方をネットワークでつなぎます… 21 5.2 他のトラフィックからのIntservトラフィックの保護… 22 6. マルチキャスト… 22 6.1 パケットについてブランチポイントルータで述べます。 24 6.2本のマルチキャストSLSsと異種の木… 25 7. セキュリティ問題… 26 7.1 一般RSVPセキュリティ… 26 7.2 マークを接待してください… 26
Bernet, et al. Informational [Page 2] RFC 2998 Integrated Services Over Diffserv Networks November 2000
Bernet、他 情報[2ページ]のRFC2998は2000年11月にDiffservネットワークの上でサービスを統合しました。
8. Acknowledgments .............................................. 27 9. References ................................................... 27 10. Authors' Addresses .......................................... 29 11. Full Copyright Statement ................................... 31
8. 承認… 27 9. 参照… 27 10. 作者のアドレス… 29 11. 完全な著作権宣言文… 31
1. Introduction
1. 序論
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.
QoSによって可能にされたIPネットワークに対する仕事は2つの異なったアプローチにつながりました: Integrated Servicesアーキテクチャ(Intserv)[10]、付随のシグナリングプロトコル、RSVP[1]、およびDifferentiated Servicesアーキテクチャ(Diffserv)[8]。 このドキュメントは終わりから終わりへのQOSの配送をサポートするのにIntservアーキテクチャの文脈でDiffservネットワークを使用できる方法を述べます。
1.1 Integrated Services Architecture
1.1 統合サービスアーキテクチャ
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セットの拡大を定義しました。 アーキテクチャの主要な成分の1つは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ネットワークの中で見なされるかもしれません。
1.2 RSVP
1.2 RSVP
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はサービスタイプを言い表すためにモデルを定義します、要件と関連ネットワーク要素(入場コントロール)で要求されたリソースの有用性を決定するためにリソースを定量化して。
Bernet, et al. Informational [Page 3] RFC 2998 Integrated Services Over Diffserv Networks November 2000
Bernet、他 情報[3ページ]のRFC2998は2000年11月にDiffservネットワークの上でサービスを統合しました。
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アーキテクチャに基づいています。 このモデルでは、Intservパラメタを使用して、RSVPは要素をネットワークでつなぐという1流れあたりのリソース要件に合図します。 これらのネットワーク要素はIntserv入場コントロールを合図された要求に適用します。 さらに、ネットワーク要素の上のトラフィックコントロールメカニズムは、それぞれの認められた流れが他のトラフィックから厳しい分離で要求されたサービスを受けるのを保証するために構成されます。 このために、RSVPシグナリングは交通の流れの経路に沿ったIntservのできるルータでmicroflow(MF)[8]パケットクラシファイアを構成します。 これらのクラシファイアはIPアドレスとポートナンバーに基づくパケットの1流れあたりの分類を可能にします。
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. 1流れあたりの状態と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]になるだけでした。
1.3 Diffserv
1.3 Diffserv
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の1流れあたりのオリエンテーションと対照して、Diffservネットワークはパケットを少ない数の集められた流れか「クラス」の1つに分類します、パケットのIPヘッダーのDiffserv codepoint(DSCP)に基づいて。 これは振舞いの集合(BA)分類[8]として知られています。 それぞれのDiffservルータでは、パケットは「1ホップあたりの振舞い」(PHB)にかけられます。(それは、DSCPによって呼び出されます)。 Diffservの主要便益はそのスケーラビリティです。 Diffservは1流れあたりの状態、1流れあたりの処理、およびしたがって、スケールの必要性を大きいネットワークによく排除します。
1.4 Roles of Intserv, RSVP and Diffserv
1.4 Intserv、RSVP、および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の追求における補足的な技術としてIntserv、RSVP、およびDiffservを見なします。 これらのメカニズムはIP電話技術などのアプリケーション、ビデオの要求次第の、そして、様々な非マルチメディア必要不可欠なアプリケーションの展開を一緒に、容易にすることができます。 Intservは、ホストが終わりから端へのデータ経路に沿って流れ、定量化可能なリソースを要求して、これらの要求の許容性に関するフィードバックを得るのを可能にします。 Diffservは大きいネットワークの向こう側にスケーラビリティを可能にします。
Bernet, et al. Informational [Page 4] RFC 2998 Integrated Services Over Diffserv Networks November 2000
Bernet、他 情報[4ページ]のRFC2998は2000年11月にDiffservネットワークの上でサービスを統合しました。
1.5 Components of Intserv, RSVP and Diffserv
1.5 Intserv、RSVP、および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.
1流れあたりのRSVP。 個々のmicroflowsの資源予約を実行する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入場コントロール、および1流れあたりのトラフィックコントロールで合図する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が分類とトラフィックコントロールであるとサポートする1セットの隣接のルータ。 また、そのような領域が、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領域の外のネットワークの一部。 また、そのような領域はさまざまな異なったタイプの分類とトラフィックコントロールを提供するかもしれません。
Bernet, et al. Informational [Page 5] RFC 2998 Integrated Services Over Diffserv Networks November 2000
Bernet、他 情報[5ページ]のRFC2998は2000年11月に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」であると認識するのが可能でないかもしれませんが、トラフィックの処理の見解からただ一つのアプリケーションからそれをこのように定義するのは可能です。
1.6 The Framework
1.6 フレームワーク
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.
私たちが提示するフレームワーク、終わらせる終わりでは、1つ以上のDiffserv領域を含んでいて、ネットワークの向こう側にIntservのモデルの終わりから端を適用することによって、量的なQoSを提供します。 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領域が、特定のPHBsが(集合トラフィックコントロール)であると実装します。 あるPHBを受けるDiffserv領域を認められるトラフィックの総量は、縁で取り締まることによって、制限されるかもしれません。 その結果、私たちは、ネットワークのDiffserv領域が、Intservスタイルが周辺から要求されたサービスであるとサポートすることができると予想します。 フレームワークでは、私たちはネットワークのDiffserv領域の上で終わりから終わりへのIntegrated Servicesのサポートを扱います。 私たちの目標はシームレスの相互操作を可能にすることです。 その結果、ネットワーク管理者はDiffserv領域として自由にネットワーク条例のどの領域を選ぶことができるか。 1つの極端では、Diffserv領域は周辺までのいっぱいに押されます、完全なIntserv能力を持っているホストだけと共に。 全く正反対では、IntservはDiffserv領域なしでコアまでのいっぱいに押されます。
1.7 Contents
1.7 コンテンツ
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で、私たちはIntservアーキテクチャの、より広い文脈のDiffservネットワーク領域によって提供された集合トラフィックコントロールを使用することによって実現できる利益について議論します。 セクション4では、私たちはフレームワークと参照ネットワークを提示します。 セクション5はフレームワークの2つの可能な実現を詳しく述べます。 セクション6はDiffservのためにフレームワークの含意について論じます。 セクション7はマルチキャスト流れに特定のいくつかの問題を提示します。
Bernet, et al. Informational [Page 6] RFC 2998 Integrated Services Over Diffserv Networks November 2000
Bernet、他 情報[6ページ]のRFC2998は2000年11月にDiffservネットワークの上でサービスを統合しました。
2. Benefits of Using Intserv with Diffserv
2. DiffservとIntservを使用する利益
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の集合トラフィックコントロールの主要便益はそのスケーラビリティです。 このセクションで、私たちはIntservとinteroperationがDiffservネットワーク領域にもたらすことができる利益について議論します。 この議論が明確に量的なQoSアプリケーションを供給することの文脈にあることに注意してください。 これで、私たちはそれらのトラフィックとQoS要件を定量化できるそれらのアプリケーションを言っています。
2.1 Resource Based Admission Control
2.1 リソースのベースの入場コントロール
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ネットワーク領域では、入場コントロールが、ネットワーク要素で取り締まりパラメタに食糧を供給することによって、比較的静的な方法で適用されます。 例えば、EF DSCPのためにトラフィックの50Kbpsだけを受け入れるためにDiffservネットワーク領域へのイングレスにおけるネットワーク要素に食糧を供給することができました。
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ネットワーク領域の外で起因する10のIP電話技術セッションがあるかもしれないと考えてください、Diffservネットワーク領域から10KbpsにEFサービスをそれぞれ要求して。 Diffservネットワーク領域を保護するネットワーク要素がEF DSCPのためにトラフィックの50Kbpsだけを受け入れるために食糧を供給されるので、それは提供されたトラフィックの半分を捨てるでしょう。 このトラフィックはEFであるとマークされたトラフィックの集合から捨てられるでしょう、それが起因したmicroflowへの尊敬なしで。 事実上、Diffservネットワーク領域で利用可能な5つのセッションを満たすことができるくらいのリソースがあるとき、その結果、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
明らかに合図されて、ダイナミックな入場コントロールの場合では、50Kbps限界を超えているリソースに関する要求に対応してネットワークは拒絶を示すでしょう。 その結果、上流のネットワーク要素(送信元ホストを含んでいる)とアプリケーションには、彼らが修正措置を取るのを必要とする情報があるでしょう。 アプリケーションは、伝わるのを控えるか、または、より少ないトラフィックプロフィールのための入場を要求することによって、反応するかもしれません。 ホスト・オペレーティング・システムは、ベストエフォート型サービスに対応するDSCPのためにアプリケーションのトラフィックをマークすることによって、反応するかもしれません。 上流のネットワーク要素は、下側のサービスへの拒絶された流れでパケットを述べさせることによって、応じるかもしれません。
Bernet, et al. Informational [Page 7] RFC 2998 Integrated Services Over Diffserv Networks November 2000
Bernet、他 情報[7ページ]のRFC2998は2000年11月にDiffservネットワークの上でサービスを統合しました。
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.
レベル。 いくつかの場合、代替パスか代替のネットワーク(例えば、音声通話のためのPSTN)の上でさえ交通ルートを変更するのは可能であるかもしれません。 どのような場合でも、認められたそれらの流れの保全は保持されるでしょう、認められなかった流れを犠牲にして。 したがって、Intserv詳しい入場コントロールエージェントをネットワークのDiffserv領域に任命することによって、ネットワークが量的なQoSアプリケーションに提供されることができるのは、サービスを機能アップするのにおいて可能です。
2.2 Policy Based Admission Control
2.2 方針のベースの入場コントロール
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意識しているネットワーク要素で妨害できて、方針データベースに保存された方針に対して再検討できます。 これらの資源要求はしっかりと、リソースが要求されているユーザとアプリケーションを特定します。 資源要求を認めるかどうか決めるとき、その結果、ネットワーク要素はユーザアプリケーションあたりの方針を考えることができます。 それで、詳しい状態でDiffservネットワーク領域(3.1で議論するように)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顧客ネットワークに基づいて通常適用されます。
2.3 Assistance in Traffic Identification/Classification
2.3 トラフィック識別/分類における支援
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がルータであるとマークするために構成されます。 各体系への利点と難点があります。 体系にかかわらず、中古の、そして、明白なシグナリングは重要な利益を提供します。
Bernet, et al. Informational [Page 8] RFC 2998 Integrated Services Over Diffserv Networks November 2000
Bernet、他 情報[8ページ]のRFC2998は2000年11月にDiffservネットワークの上でサービスを統合しました。
2.3.1 Host Marking
2.3.1 ホストマーク
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をマークします。 このアプローチは1流れあたりの移行している分類の恩恵とマークをトラフィックの源に持っています。そこでは、それが最もよく比例します。 また、それは、ホストがそれぞれの伝えられたパケットに、適切なマークに関する決定としたがって、各パケットに置かれた相対的な重要性をするのを可能にします。 一般に、この決定をするようにネットワークよりホストに持たせるほうがよいです。 その上、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].
ホストマークは、ホストがネットワークによるDSCPsの解釈を意識しているのを必要とします。 この情報を各ホストに構成できます。 しかしながら、そのような構成は管理負担を課します。 あるいはまた、ホストは、あるIntservサービスが要求されているパケットに適用するDSCPsの適当なDSCPかセットを入手するためにネットワークについて質問するのにRSVPなどの明白なシグナリングプロトコルを使用できます。 どうこれを達成できるかに関する例は[14]で説明されます。
2.3.2 Router Marking
2.3.2 ルータマーク
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
静的な構成への魅力的な代替手段はホスト・オペレーティング・システムがユーザとアプリケーションを代表して分類評価基準をルータに示すのを許容することです。 私たちが後でこれで目立つように
Bernet, et al. Informational [Page 9] RFC 2998 Integrated Services Over Diffserv Networks November 2000
Bernet、他 情報[9ページ]のRFC2998は2000年11月にDiffservネットワークの上でサービスを統合しました。
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シグナリングはそうでなければ認知できないIPSEC[13]パケット(SPIの使用による)の分類を可能にします。
2.4 Traffic Conditioning
2.4 トラフィック調節
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できるネットワーク要素は1流れあたり1つの粒状で形成、そして/または、取り締まりの何らかの組み合わせでトラフィックを条件とさせることができます。 ネットワークのDiffserv領域にそれを提出する前にこの様にトラフィックをあらかじめ条件とさせるのは有益です。 特に、それはネットワークのDiffserv領域が集合トラフィックコントロールを使用することで量的なサービスを提供する能力を高めます。
3. The Framework
3. フレームワーク
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.
一般的なフレームワークでは、私たちはIntegrated Servicesアーキテクチャが終わりから終わりへの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つの特定の実現を考えるつもりです。 1番目では、ネットワークのDiffserv領域の中のリソースは静的に食糧を供給されます、そして、これらの領域はどんなRSVPの意識しているデバイスも含んでいません。 2番目では、ネットワークのDiffserv領域の中のリソースはダイナミックに食糧を供給されます、そして、Diffservネットワーク領域の中の選んだデバイスはRSVPシグナリングに参加します。
Bernet, et al. Informational [Page 10] RFC 2998 Integrated Services Over Diffserv Networks November 2000
Bernet、他 情報[10ページ]のRFC2998は2000年11月にDiffservネットワークの上でサービスを統合しました。
3.1 Reference Network
3.1 参照ネットワーク
The two realizations of the framework will be discussed in the context of the following reference network:
以下の参照ネットワークの文脈でフレームワークの2つの実現について議論するでしょう:
________ ______________ ________
/ \ / \ / \
/ \ / \ / \
|---| | |---| |---| |---| |---| | |---|
|Tx |-| |ER1|---|BR1| |BR2|---|ER2| |-|Rx |
|---| | |-- | |---| |---| |---| | |---|
\ / \ / \ /
\________/ \______________/ \________/
________ ______________ ________ / \ / \ / \ / \ / \ / \ |---| | |---| |---| |---| |---| | |---| |Tx|-| |ER1|---|BR1| |BR2|---|ER2| |-|Rx| |---| | |-- | |---| |---| |---| | |---| \ / \ / \ / \________/ \______________/ \________/
Non-Diffserv region Diffserv region Non-Diffserv region
非Diffserv領域のDiffserv領域のNon-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の領域)の外の領域はルータと付属ホストのメッシュを含んでいます。少なくともその或るものはIntegrated Servicesがアーキテクチャであるとサポートします。
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受信機で交信して、Rx。 Diffserv領域に隣接している縁のルータ(ER1、ER2)はDiffserv領域の中の境界ルータ(BR1、BR2)に連結します。
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.
私たちは現在、参照ネットワークの主要コンポーネントを定義します。
3.1.1 Hosts
3.1.1 ホスト
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,
私たちは、発信と受信ホストの両方がQoS意識しているアプリケーションの量的なQoS要件を伝えるのにホストで走りながらRSVPを使用すると思います。 原則として、他のメカニズムは、Intservできるノードに資源予約を証明するのに使用されるかもしれません。
Bernet, et al. Informational [Page 11] RFC 2998 Integrated Services Over Diffserv Networks November 2000
Bernet、他 情報[11ページ]のRFC2998は2000年11月にDiffservネットワークの上でサービスを統合しました。
but RSVP is clearly the prevalent mechanism for this purpose.
しかし、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できるルータ川下はこれらのトラフィック制御機能を提供するかもしれません。
3.1.2 End-to-End RSVP Signaling
3.1.2 終わりから終わりへのRSVPシグナリング
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領域でルータのなにも、いくつかまたはすべてによって処理されるかもしれません。
3.1.3 Edge Routers
3.1.3 縁のルータ
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ネットワークに務めてください。 彼らは、Diffservネットワーク領域以内と顧客の定義された方針の上にTxとRxの両方からシグナリングメッセージを処理して、リソースの有用性に基づく入場コントロールを適用します。 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.
私たちは後でそれぞれのフレームワークの2つの実現のために、より大きい深さの縁のルータの機能性について説明するつもりです。
3.1.4 Border Routers
3.1.4 境界ルータ
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
BR1とBR2はDiffservネットワーク領域にある境界ルータです。 フレームワークの特定の実現によって、境界ルータの機能性は異なります。 Diffservネットワーク領域がどれであるかでRSVP気づかない場合では、これらのルータは純粋なDiffservルータとして機能します。 そういうものとして、提出されたトラフィックがDSCPで指定されたサービスレベルに基礎づけた警察と顧客と交渉された協定にはそれらの唯一の責任がある、(集合
Bernet, et al. Informational [Page 12] RFC 2998 Integrated Services Over Diffserv Networks November 2000
Bernet、他 情報[12ページ]のRFC2998は2000年11月にDiffservネットワークの上でサービスを統合しました。
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.
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つの実現のために、より大きい深さの境界ルータの機能性について説明するつもりです。
3.1.5 Diffserv Network Region
3.1.5 Diffservネットワーク領域
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つ以上のレベルのサービスを提供します。 それは、ただ一つの管理ドメインであるかもしれないか複数のドメインにかかるかもしれません。
3.1.6 Non-Diffserv Network Regions
3.1.6 非Diffservネットワーク地方
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をサポートすると合理的に思われるかもしれません、これは食糧を供給し過ぎることの場合では必要でないかもしれませんが。 これらの要素がIntservできないでも、私たちは、それらがメッセージをRSVPに通過すると思います。妨害されていない。 Diffservネットワーク領域における外のルータはトラフィック通過の何らかの部分集合に集合トラフィックコントロールを提供するのからそれらまで排除されません。
3.2 Service Mapping
3.2 サービス対応表
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サービスのリクエストは"flowspec"として知られている量的なパラメタの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ネットワーク領域の基本的な能力にIntservサービスを求める要求を写像しなければなりません。 マッピングの局面は:
Bernet, et al. Informational [Page 13] RFC 2998 Integrated Services Over Diffserv Networks November 2000
Bernet、他 情報[13ページ]のRFC2998は2000年11月に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.
- 要求されたサービスのために適切なPHB、またはPHBsのセットを選択します。 - Diffserv領域の縁で適切な取り締まりを実行します(恐らく含んでいるか、形成するか、または述べます)。 - Diffserv領域(例えば、ADSPECsのアップデートのための)からの輸出Intservパラメタ。 - 入場コントロールをIntservに実行するのは、それがDiffserv領域でリソースの有用性を考慮に入れるよう要求します。
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.
これらの機能がちょうどどう実行されるかは帯域幅がDiffservネットワーク領域の中で管理される方法の機能になるでしょう。領域は私たちがセクション4.3で議論する話題です。
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(または、PHBsのセット)が特定のIntserv流動のために選択されたとき、他のネットワーク要素への流れのためにDSCPの選択を伝えるのが必要であるかもしれません。 2つの体系が、この終わりを達成するのに以下で議論するように使用されるかもしれません。
3.2.1 Default Mapping
3.2.1 デフォルトマッピング
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.
この体系には、IntservサービスタイプからDiffservネットワークで適切な行動を呼び出すDSCPまで何らかの標準の、そして、よく知られるマッピングがあります。
3.2.2 Network Driven Mapping
3.2.2 ネットワークの駆動マッピング
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].
この体系、RSVPで詳しい、Diffservネットワーク領域(恐らく縁の)のルータが中で説明されたよく知られるマッピングに優越するかもしれない、4.2、.1 DSCPsがイングレスでDiffserv領域にマークされて、DSCPsは境界ルータで単に述べることができます。 しかしながら、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ネットワーク領域の管理者によって決められるべき方針のお母さんです。
3.2.3 Microflow Separation
3.2.3 Microflow分離
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,
Diffserv領域の縁に住むと警察のトラフィックが通常望んでいる境界ルータは、Diffserv領域の中にリソースを保護するために外部からDiffserv領域を提出しました。 個々のmicroflowsへの尊敬が各集合を作らないで、この取り締まりは集合ベースで適用されるでしょう。 その結果
Bernet, et al. Informational [Page 14] RFC 2998 Integrated Services Over Diffserv Networks November 2000
Bernet、他 情報[14ページ]のRFC2998は2000年11月にDiffservネットワークの上でサービスを統合しました。
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:
その結果、サービスを下がらせるのが集合の中のリソースの正当な分け前より他のmicroflowsに供給されたと、ふらちな事するmicroflowが、主張するのは、可能です。 この問題は以下によって扱われるかもしれません。
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. 縁のルータにおけるmicroflowの取り締まり単位で提供します--これはmicroflowの取り締まりのための一般に最も適切な位置です、それが、よりよく比例するネットワークの縁に1流れあたりの仕事を押すので。 さらに、Diffserv領域の外のIntservできるルータが彼らの顧客に対するmicroflowサービスを提供するのに原因となって、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. 境界ルータにおけるmicroflowの取り締まり単位で提供します--このアプローチは、前のアプローチほどスケーラブルでない傾向があります。 また、それはネットワークのDiffserv領域に管理負担を課します。 しかしながら、Diffservに、ある場合には、aとしてのmicroflowの取り締まり単位で提供する境界ルータがIntserv顧客に値で加えるのは、適切であるかもしれません。
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領域の境界で造り直すか、または取り締まるのを保証できないくらい顧客はホストのあるグループの形成を信じるかもしれません。 ホストが適切にmicroflowsを形成していてもネットワークの非Diffserv領域を通って通過するのに応じてこれらの形成流れがひずみになるかもしれないことに注意してください。 ひずみの度合いによって、Diffserv領域か、1か2を使用する再警察の上への集合能力にいくらか食糧を供給し過ぎるのが必要であるかもしれません。 何らかのメカニズムの選択はDiffserv領域の外でネットワークの管理者によって決められるべき方針の問題です。
3.3 Resource Management in Diffserv Regions
3.3 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:
Diffservネットワーク領域のリソース(例えば、帯域幅)の経営者側が終わりへの終わりのIntserv流れの需要を満たすように、さまざまなオプションが存在しています。 これらのオプションは:
- statically provisioned resources;
- resources dynamically provisioned by RSVP;
- resources dynamically provisioned by other means (e.g., a form of
Bandwidth Broker).
- 静的に、リソースに食糧を供給します。 - RSVPによってダイナミックに食糧を供給されたリソース。 - 他の手段(例えば、Bandwidth Brokerのフォーム)でダイナミックに食糧を供給されたリソース。
Some of the details of using each of these different approaches are discussed in the following section.
以下のセクションでそれぞれのこれらの異なるアプローチを使用する詳細のいくつかについて議論します。
Bernet, et al. Informational [Page 15] RFC 2998 Integrated Services Over Diffserv Networks November 2000
Bernet、他 情報[15ページ]のRFC2998は2000年11月にDiffservネットワークの上でサービスを統合しました。
4. Detailed Examples of the Operation of Intserv over Diffserv Regions
4. Diffserv地方の上のIntservの操作の詳細な例
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.
このセクションに、私たちは私たちの動作中のフレームワークの詳細な例を供給します。 私たちは気づかない状態で2つの例、Diffservネットワーク領域がRSVPであるものについて議論します、Diffservネットワーク領域がRSVP意識しているもう片方。
4.1 Statically Provisioned Diffserv Network Region
4.1 静的に食糧を供給されたDiffservネットワーク領域
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ネットワーク領域の所有者が静的な契約(サービスレベルの仕様、またはSLS)を交渉した、それぞれの多くの標準のDiffservサービスレベルで顧客に提供されるべき容量を伝えてください。 「容量を伝えてください」は単に帯域幅の量であるかもしれませんかそれが放出量、ピーク時刻レートなどの多くの要因にかかわるより複雑な「プロフィール」であるかもしれません。
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から成るとしての顧客ネットワークにおけるそれぞれの縁のルータが半分、標準のIntserv半分であると考えるのは役立っています。(半分はDiffservネットワーク領域へのどのインタフェースの半分を顧客のネットワーク領域とDiffservに連結するか)。 Intserv半分は、1流れあたりの粒状にトラフィックを特定して、処理できます。
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つ)を伝えます。 ルータがそれが示すテーブルを含んでいる、SLS単位でそれぞれのDiffservサービスレベルで食糧を供給した容量を伝えてください。 中で説明されたデフォルトマッピングに関連したこのテーブル、4.2、.1、Diffservネットワーク領域に交差するIntserv流れの入場コントロール決定を実行するために、使用されます。
4.1.1 Sequence of Events in Obtaining End-to-end QoS
4.1.1 終わりから終わりへのQoSを入手することにおける、イベントの系列
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メッセージは受信ホスト、Rxに向かって伝えられます。 送付者が付けているネットワーク領域では、標準の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
3. 縁のルータER1では、PATHメッセージは標準のRSVP処理にかけられます、そして、PATH状態はルータにインストールされます。 経路
Bernet, et al. Informational [Page 16] RFC 2998 Integrated Services Over Diffserv Networks November 2000
Bernet、他 情報[16ページ]のRFC2998は2000年11月にDiffservネットワークの上でサービスを統合しました。
message is sent onward to the Diffserv network region.
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. 標準のRSVP処理規則に従って、PATHメッセージは、Diffservネットワーク領域のルータによって無視されて、次に、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に達すると、オペレーティングシステムはRSVP RESVメッセージを生成します、あるIntservサービスタイプの提供されたトラフィックへの関心を示して。
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.
7. ER2では、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.
8. ER1では、RESVメッセージは入場コントロール処理の引き金となります。 ER1はRSVP/Intserv要求でDiffservネットワーク領域で対応するDiffservサービスレベルで利用可能なリソースに要求されたリソースを比較します。 対応するサービスレベルは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.
9. ER1が要求を承認するなら、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メッセージは送付ホスト、Txに到着するでしょう。
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. Txでは、QoSプロセスはRESVメッセージを受け取ります。 中指定されたトラフィックが流れるという指示が指定されたIntservサービスタイプのために認められたときそれがメッセージの領収書を解釈する、(。
Bernet, et al. Informational [Page 17] RFC 2998 Integrated Services Over Diffserv Networks November 2000
Bernet、他 情報[17ページ]のRFC2998は2000年11月にDiffservネットワークの上でサービスを統合しました。
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はIntservサービスタイプへの地図が認められたRESVメッセージで指定したデフォルト値であるかもしれませんかそれが明らかに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を入手します。
4.2 RSVP-Aware Diffserv Network Region
4.2 RSVP意識しているDiffservネットワーク領域
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意識しています。 さらに、Diffservネットワーク領域の中に他のRSVP意識しているルータがあるかもしれません。 評価基準が標準のRSVP/Intservルータで使用した1流れあたりの分類ではなく、DSCPに基づいて集合のトラフィックをこれらのルータが何らかのフォームのRSVPシグナリングに参加できますが、分類して、計画をすることに注意してください。 それらのデータ飛行機が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つのネットワーク領域の間のリソース有用性情報の唯一の明白な交換です。 SLSによって表される情報、そのようなものがDiffservネットワーク領域への入場コントロールエージェントとして務めることができるので、ER1は構成されます。 SLSが変化するたびにER1が再構成を必要とするので、そのような構成は容易にダイナミックに変化している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
Diffservネットワーク領域がRSVP意識しているとき、対照的に、入場コントロールエージェントはDiffservネットワークの一部です。 その結果、RSVPを通したDiffserv領域の外のIntservできるノードにDiffservネットワーク領域で有効な容量における変化を示すことができます。 RSVPシグナリングにDiffservネットワーク領域への内部のルータを含んでいることによって、同時に、Diffserv領域の中でリソース用法の効率を高めて、信用のレベルを改良するのが可能である、それ
Bernet, et al. Informational [Page 18] RFC 2998 Integrated Services Over Diffserv Networks November 2000
Bernet、他 情報[18ページ]のRFC2998は2000年11月にDiffservネットワークの上でサービスを統合しました。
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.
本当に、入場コントロールで要求されたリソースは時間内に、この特定のポイントで利用可能です。 これは影響を与えられる特定の経路に沿って入場コントロールをリソースの有用性にリンクできるからです。 私たちは「トポロジーの意識している入場コントロール」にRSVPシグナリングのこの利益について言及します。 Diffservネットワーク領域の中でRSVPがシグナリングであるとサポートするさらなる利益はそれがDiffserv領域の外部からの資源要求に対応してDiffservネットワーク領域(例えば、多少、ルータにおけるEF待ち行列に帯域幅を割り当てる)の食糧を供給することにおける効果変化に可能であるということです。
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、1流れあたりのRSVP、および帯域幅ブローカーを含んでいます。
4.2.1 Aggregated or Tunneled RSVP
4.2.1 集められたかトンネルを堀られた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領域からの1流れあたりの累積している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領域の外のノードからの1流れあたりのRSVP要求の入場は数えられるでしょう。 集合予約のサイズは、1流れあたりの予約における変化に対処するようにダイナミックに調整されるかもしれません。
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領域の資源管理がただ一つの管理ドメインだけの中で可能である最も傾向があることに注意します、各ドメインがリソースを管理するためにたぶんそれ自身のメカニズムを選ぶとき。
Bernet, et al. Informational [Page 19] RFC 2998 Integrated Services Over Diffserv Networks November 2000
Bernet、他 情報[19ページ]のRFC2998は2000年11月にDiffservネットワークの上でサービスを統合しました。
4.2.3 Per-flow RSVP
4.2.3 1流れあたりのRSVP
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できるノードから発しながら合図する1流れあたりの標準のRSVPに応じます。 集められたRSVPサポートを必要としないで、このアプローチは前のアプローチ(動力、トポロジーの意識している入場コントロール)の恩恵を提供します。 また、リソースは1流れあたりの入場コントロールの結果、より効率的に使用されます。 しかしながら、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.
1流れあたりのRSVPと集められたRSVPがただ一つのDiffserv領域で互いに排他的でないことに注意してください。 Diffserv領域の中の何らかの「コア」領域だけのDiffserv領域と集合の縁で1流れあたりのRSVPを使用するのは可能です。
4.2.4 Granularity of Deployment of RSVP Aware Routers
4.2.4 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集合はリソース利用における、最適のいくらかの損失の費用におけるシグナリングオーバーヘッドを制限することにおいて一方通行です。
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の気づかないルータの食糧を供給され過ぎるか、または静的に食糧を供給された領域でおそらく主要なトラフィック切り換えポイントを表すでしょう。
Bernet, et al. Informational [Page 20] RFC 2998 Integrated Services Over Diffserv Networks November 2000
Bernet、他 情報[20ページ]のRFC2998は2000年11月にDiffservネットワークの上でサービスを統合しました。
4.3 Dynamically Provisioned, Non-RSVP-aware Diffserv Region
4.3 ダイナミックに食糧を供給される、非RSVP意識する、Diffserv領域
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]の様々な定義では、それは集結された神託として機能できます。
5. Implications of the Framework for Diffserv Network Regions
5. Diffservネットワーク地方へのフレームワークの含意
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.
私たちは終わりから端へのDiffservネットワーク領域を含んでいる経路の向こう側にRSVP/IntservスタイルQoSを提供できるフレームワークについて説明しました。 このセクションはこのフレームワークの含意のいくつかについてDiffservネットワーク領域に論じます。
5.1 Requirements from Diffserv Network Regions
Diffservからの5.1の要件が地方をネットワークでつなぎます。
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. Diffservネットワーク領域は標準のIntserv QoSサービスのサポートを境界ルータの間に提供できなければなりません。 Diffserv領域の縁でのDiffserv領域と適切な行動の中に標準のPHBsの使用でこれらのサービスを呼び出すのは可能であるに違いありません。
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ネットワーク領域はメッセージをRSVPに通過できなければなりません、Diffservネットワーク領域の出口でそれらを回復できるくらいの方法で。 必要でなく、これらのメッセージを処理して、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.
1. マッピングIntservはDiffservネットワーク領域で提供できるサービスにサービス仕様を流行に合わせます。
Bernet, et al. Informational [Page 21] RFC 2998 Integrated Services Over Diffserv Networks November 2000
Bernet、他 情報[21ページ]のRFC2998は2000年11月にDiffservネットワークの上でサービスを統合しました。
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].
2. 機能性の定義がネットワーク要素で集合トラフィックコントロール(Diffservネットワーク領域にあるネットワーク要素のための)でRSVPがシグナリングであるとサポートするのが必要です。 3. Diffservネットワーク領域(例えば、RSVP、トンネリング、MPLSなどに集める)で効率的にダイナミックにリソースに食糧を供給するメカニズムの定義。 これは「神託」がルータに接するためにDiffserv領域の中でリソースの有用性に関して情報を伝達するプロトコルを含むかもしれません。 そのようなメカニズムに関する1つの例が[19、20、21]で提案されたいわゆる「帯域幅ブローカー」です。
5.2 Protection of Intserv Traffic from Other Traffic
5.2 他のトラフィックからのIntservトラフィックの保護
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。 非Intservトラフィック。 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。 他のすべての(ベストエフォート型)のトラフィック。 互いからDiffservネットワーク領域へのイングレスポイントでのpolicersとクラシファイアの適切な構成、Diffservネットワーク領域の中の適切なおよび食糧を供給することでこれらの3つのクラスのトラフィックを隔離しなければなりません。 ネットワークのDiffserv領域のIntservトラフィックのための保護を提供するために、私たちは、そのようなトラフィックに割り当てられたDSCPsが他のトラフィックに割り当てられるDSCPsに重ならないことを提案します。
6. Multicast
6. マルチキャスト
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領域に関連しています。 (マルチキャスト木に沿ったあらゆるIntservできるルータが各流れのために状態を保存するので、Diffserv領域の外のマルチキャストの機能性のサポートは比較的簡単です。)
Consider the following reference network:
以下の参照ネットワークを考えてください:
Bernet, et al. Informational [Page 22] RFC 2998 Integrated Services Over Diffserv Networks November 2000
Bernet、他 情報[22ページ]のRFC2998は2000年11月にDiffservネットワークの上でサービスを統合しました。
Non-Diffserv region 2
________
/ \
| | |---|
________ _____________ | |-|Rx1|
/ \ / |--\ |---| | |---|
/ \ / /|BR2\-----\ER2| /
|---| | |---| |---| |--|/ |---| \--|____/
|Tx |-| |ER1|---|BR1|--|RR| | ________
|---| | |-- | |---| |--|\ |---| /--| \
\ / \ \|BR3/-----|ER3| | |---|
\________/ \__________|--/ |---| |-|Rx2|
| | |---|
Non-Diffserv region 1 Diffserv region \ /
\______/
非Diffserv領域2________ / \ | | |---| ________ _____________ | |-|Rx1| / \ / |--\ |---| | |---| / \ / /|BR2\-----\ER2| / |---| | |---| |---| |--|/ |---| \--|____/ |Tx|-| |ER1|---|BR1|--|RR| | ________ |---| | |-- | |---| |--|\ |---| /--| \ \ / \ \|BR3/-----|ER3| | |---| \________/ \__________|--/ |---| |-|Rx2| | | |---| 1非Diffserv領域Diffserv領域\/円______/
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によって送られたパケットのコピーはDiffserv領域の外で数台の受信機に提供されます、すなわち、Rx1とRx2に。 そのうえ、パケットは「ブランチポイント」ルータRRのDiffserv領域の中にコピーされます。 参照ネットワークでは、BR1はDiffserv領域へのイングレスルータですが、BR2とBR3は出口ルータです。
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)であると出口ルータの1、いくつかまたはイングレスルータからすべてまでサポートします。 これはDiffserv領域の中でBR1からBR2とBR3まで「多くへの1」SLSを求めます。 Diffserv領域でSLSを与えるなら、イングレスルータBR1、または恐らくER1などの上流のノードが、適切なDSCPと共にDiffserv領域に入りながら、パケットをマークします。 パケットは、オリジナルのマルチキャストアドレスを使用することでDiffservドメインの出口に発送されます。
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にもかかわらず、1つだけからマルチキャストデータを受け取る必要があるこの件がベストエフォート型の上でサービスのレベルを要求したということです。 私たちは以下のパラグラフのそのようなシナリオを考えます。
Bernet, et al. Informational [Page 23] RFC 2998 Integrated Services Over Diffserv Networks November 2000
Bernet、他 情報[23ページ]のRFC2998は2000年11月にDiffservネットワークの上でサービスを統合しました。
6.1 Remarking of packets in branch point routers
6.1 ブランチポイントルータにおける、パケットの異状
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に送ります。 ブランチポイントに到着するパケットを同じDSCPとBR2に向かって送らなければなりません。そうでなければ、Rx1に対するサービスは降格しています。 しかしながら、RRからBR3に向かって行くパケットはそれ以上高い保証レベルを維持する必要はありません。 それらがベストエフォート型に格下げされるかもしれないので、木のこの枝に沿って他のパケットに提供された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.
- Diffserv領域では、ブランチポイントルータがコアルータであるかもしれませんが、縁のルータ(イングレス)でDSCPマークをします。(それは、パケットをマークしません)。
- 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.
- と対照的に、コアDiffservルータであり、RRが集合トラフィックに基づいてストリーム(BA)を分類する、流れ(MF)分類単位で。 したがって、それには、特定のマルチキャスト木に属すそれらのパケットを区別して、振舞い集合の同じ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分類と異状をサポートして、1流れあたりの状態を保持するでしょう。 この場合、ブランチポイントルータには本質的には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
2. 「非予約された」ブランチ(BR3に向かったRRからの)で送られたパケットは「間違った」DSCPと共にマークされます。 すなわち、彼らは、ベストエフォート型に格下げされませんが、自分達のDSCPを保有します。 それに沿ったリソースの予約の上でリンクするか、または合法的に同じDSCPを持っているパケットに下劣なサービスの危険を冒しますこれが、順番に必要である。
Bernet, et al. Informational [Page 24] RFC 2998 Integrated Services Over Diffserv Networks November 2000
Bernet、他 情報[24ページ]のRFC2998は2000年11月にDiffservネットワークの上でサービスを統合しました。
along this path. However, it allows the Diffserv routers to remain free of per-flow state.
この経路に沿って。 しかしながら、それで、Diffservルータは1流れあたりの状態から無料で残っています。
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].
4. Diffserv領域の管理者は、それらのドメインで異種の下位木を可能にしないと決めるかもしれません。 異なった川下の予約の場合では、RSVP規則に従って、ResvErrメッセージを送るでしょう。 これはIEEE802Networks[2、5]の上でIntservに取られたアプローチと同様です。
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.
5. [3]では、集合領域(すなわち、Diffserv領域)の内陸部のルータが予約の減少している州の情報であることを測定を使用することによって保つブランチポイントが入場コントロールを基礎づけた体系を導入しました。 この体系の下では、詳細なIntserv状態に代わって使用されるスケジューリング情報がある、より博識なIntserv縁のルータはパケットにタグ付けをします。 そのフレームワークに続いて、Diffserv領域とブランチポイントルータが設計されるなら、パケットの格下げは可能になります。
6.2 Multicast SLSs and Heterogeneous Trees
6.2 マルチキャストSLSsと異種の木
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領域を認められる単一のパケットはその領域の多くの経路に沿ってリソースを消費するかもしれません。 あるいはまた、それはただ一つの経路に沿って流れるかもしれません。 この状況は何らかのより高いQOS処理が他のものに沿って上で説明されて、図2に表現された可能性によってさらに複雑にされます。そこでは、マルチキャストパケットが受信している間、いくつかの支店に沿ったベストエフォート型として扱われるかもしれません。 私たちは、ここで異種の流れの需要を満たして、会うことができる重要な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
ダイナミックなSLSsは、これらの問題を扱うのを助けるかもしれません。 例えば、マルチキャスト木の異なった枝に沿って必要であるリソースに合図するのにRSVPを使用することによって、より密接に、適切なリソースだけを割り当てるというそれらが木のある枝に沿って過剰食糧を供給するか、またはunderprovisioningするよりむしろ必要である目標に近づくのは可能であるかもしれません。 これは本質的にはアプローチです。
Bernet, et al. Informational [Page 25] RFC 2998 Integrated Services Over Diffserv Networks November 2000
Bernet、他 情報[25ページ]のRFC2998は2000年11月にDiffservネットワークの上でサービスを統合しました。
described in [15].
[15]では、説明されます。
7. Security Considerations
7. セキュリティ問題
7.1 General RSVP Security
7.1 一般RSVPセキュリティ
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]を当てはまります。 さらに、ネットワーク管理者が信頼されていない顧客とのインタフェースで安全なpolicersを構成することによってネットワーク資源を保護すると予想されます。
7.2 Host Marking
7.2 ホストマーク
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を設定することによって)か間接的(それがルータをマークする中間介在物で特定のDSCPに分類するトラフィックを提出することによって)にこのサービスレベルを呼び出すかどうかにかかわらずDiffservネットワーク領域で特定のサービスレベルで交渉された容量を超えているのを試みるかもしれません。
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.
どちらかの場合では、一般に、それぞれのDiffservネットワーク領域が保護されるために、顧客がそれらより多くのリソースを使用しないことを保証するために取り締まるのによるリソースが権利を与えられるのが必要でしょう、各サービスレベル(DSCP)で。 この規則への例外はホストが信じられるのが知られている時です、例えばネットワーク管理者のコントロールの下にあるサーバ。 信頼されていない送付ホストが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で説明したネットワークの縁まで責任を形成して、取り締まって、境界ルータがそうしなければならない粒状を減少させます。 より広大なDiffservネットワーク地域はこのようにしてそれらのネットワークを保護するタスクに焦点を合わせられます、Intservできるノードがそれらの交渉されたIntservパラメタに従ってあるようにそれら自身のトラフィックを形成して、取り締まるタスクに集中していますが。
Bernet, et al. Informational [Page 26] RFC 2998 Integrated Services Over Diffserv Networks November 2000
Bernet、他 情報[26ページ]のRFC2998は2000年11月にDiffservネットワークの上でサービスを統合しました。
8. Acknowledgments
8. 承認
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.
作者はこのドキュメントの旧バージョンへの改良につながった彼らのコメントについて以下の個人に感謝します: デヴィッド・オラン、アンディ・ビーチ、カーティスVillamizer、ウォルター・ウィス、フランソアle Faucheur、およびラッセル・ホワイト。
Many of the ideas in this document have been previously discussed in the original Intserv architecture document [10].
以前に、オリジナルのIntservアーキテクチャドキュメント[10]で本書では考えの多くについて議論しました。
9. References
9. 参照
[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の機能的な仕様」、RFC2205、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(サブネット帯域幅マネージャ):」 「IEEE802様式ネットワークのRSVPベースの入場コントロールのためのプロトコル」(RFC2814)は2000がそうするかもしれません。
[3] Berson, S. and R. Vincent, "Aggregation of Internet Integrated
Services State", Work in Progress.
[3] 「インターネットの統合サービス州の集合」というBerson、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.チャン、「インターネットへの安っぽい差別化されたサービスアーキテクチャ」、RFC2638、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)は、「IEEE802ネットワークに関するサービス対応表を統合しました」、RFC2815、2000年5月。
[6] Guerin, R., Blake, S. and Herzog, S., "Aggregating RSVP based
QoS Requests", Work in Progress.
[6] ゲランとR.とブレークとS.とハーツォグ、S.、「RSVPに集めるのはQoS Requestsを基礎づけた」ProgressのWork。
[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分野)の定義」RFC2474(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.ウィス、「差別化されたサービスのためのアーキテクチャ」、RFC2475、1998年12月。
[9] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000.
[9] ベイカーとF.とリンデルとB.とM.Talwar、「RSVPの暗号の認証」、RFC2747、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、「インターネットアーキテクチャにおける統合サービス:」 「概要」、RFC1633、1994年6月。
Bernet, et al. Informational [Page 27] RFC 2998 Integrated Services Over Diffserv Networks November 2000
Bernet、他 情報[27ページ]のRFC2998は2000年11月にDiffservネットワークの上でサービスを統合しました。
[11] Garrett, M. and M. Borden, "Interoperation of Controlled-Load
Service and Guaranteed Service with ATM", RFC 2381, August 1998.
[11] ギャレットとM.とM.ボーデン、「気圧との制御負荷サービスと保証されたサービスのInteroperation」、RFC2381、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.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[14] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996,
November 2000.
[14]Bernet、Y.、「RSVP DCLASSオブジェクトの形式」、RFC2996、2000年11月。
[15] Baker, F., Iturralde, C., le Faucheur, F., and Davie, B. "RSVP
Reservation Aggregation", Work in Progress.
[15] ベイカーとF.とイトゥラルデとC.とle Faucheur、F.とデイビー、B.「RSVP予約集合」、ProgressのWork。
[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.チャン、「IP Tunnelsの上のRSVP操作」、RFC2746、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.、Rajan、D.、およびA.Sastry)は、「RSVPのために用法を獲得します」、RFC2749、2000年1月。
[18] Bernet, Y., "A Framework for Differentiated Services", Work in
Progress.
[18] Y.、「差別化されたサービスのためのフレームワーク」というBernetは進行中で働いています。
[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.チャン、「インターネットへの安っぽい差別化されたサービスアーキテクチャ」、RFC2638、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/ 相互オプアート/index.htm
Bernet, et al. Informational [Page 28] RFC 2998 Integrated Services Over Diffserv Networks November 2000
Bernet、他 情報[28ページ]のRFC2998は2000年11月にDiffservネットワークの上でサービスを統合しました。
10. Authors' Addresses
10. 作者のアドレス
Yoram Bernet Microsoft One Microsoft Way Redmond, WA 98052
ヨラムBernetマイクロソフト1マイクロソフト道、レッドモンド、ワシントン 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 2111Ne、25番目。 Avenueヒースボロー、または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のLado Driveサンタバーバラ、カリフォルニア 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
Lixiaチャン・UCLA 4531G Boelter Hallロサンゼルス、カリフォルニア 90095
Phone: +1 310-825-2695 EMail: lixia@cs.ucla.edu
以下に電話をしてください。 +1 310-825-2695 メールしてください: lixia@cs.ucla.edu
Bernet, et al. Informational [Page 29] RFC 2998 Integrated Services Over Diffserv Networks November 2000
Bernet、他 情報[29ページ]のRFC2998は2000年11月にDiffservネットワークの上でサービスを統合しました。
Michael Speer Sun Microsystems 901 San Antonio Road, UMPK15-215 Palo Alto, CA 94303
マイケルシュペーアサン・マイクロシステムズ901サンアントニオ道路、UMPK15-215パロアルト、カリフォルニア 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/Information Sciences Institute4676海軍本部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アポロDriveチェルムズフォード、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 Inc.24ラウル・ワレンバーグ、第テルアビブ(イスラエル)
Phone: +972-50-747672 Email: eyal@sanrad.com
以下に電話をしてください。 +972-50-747672はメールされます: eyal@sanrad.com
John Wroclawski MIT Laboratory for Computer Science 545 Technology Sq. Cambridge, MA 02139
ジョンWroclawski MIT Laboratory for Computer Science545技術平方です。 ケンブリッジ、MA 02139
Phone: +1 617-253-7885 EMail: jtw@lcs.mit.edu
以下に電話をしてください。 +1 617-253-7885 メールしてください: jtw@lcs.mit.edu
Bernet, et al. Informational [Page 30] RFC 2998 Integrated Services Over Diffserv Networks November 2000
Bernet、他 情報[30ページ]のRFC2998は2000年11月にDiffservネットワークの上でサービスを統合しました。
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Bernet, et al. Informational [Page 31]
Bernet、他 情報[31ページ]
一覧
スポンサーリンク
