[要約] RFC 2998は、DiffServネットワーク上での統合サービスの運用に関するフレームワークを提供しています。このRFCの目的は、統合サービスの効率的な運用を実現するためのガイドラインを提供することです。

Network Working Group                                           Y. Bernet
Request for Comments: 2998                                        P. Ford
Category: Informational                                         Microsoft
                                                              R. Yavatkar
                                                                    Intel
                                                                 F. Baker
                                                                    Cisco
                                                                 L. Zhang
                                                                     UCLA
                                                                 M. Speer
                                                         Sun Microsystems
                                                                R. Braden
                                                                      ISI
                                                                 B. Davie
                                                                    Cisco
                                                            J. Wroclawski
                                                                  MIT LCS
                                                             E. Felstaine
                                                                   SANRAD
                                                            November 2000
        

A Framework for Integrated Services Operation over Diffserv Networks

Diffservネットワークを介した統合サービス操作のフレームワーク

Status of this Memo

本文書の位置付け

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The Internet Society (2000). All Rights Reserved.

Copyright(c)The Internet Society(2000)。無断転載を禁じます。

Abstract

概要

The Integrated Services (Intserv) architecture provides a means for the delivery of end-to-end Quality of Service (QoS) to applications over heterogeneous networks. To support this end-to-end model, the Intserv architecture must be supported over a wide variety of different types of network elements. In this context, a network that supports Differentiated Services (Diffserv) may be viewed as a network element in the total end-to-end path. This document describes a framework by which Integrated Services may be supported over Diffserv networks.

統合サービス(INTSERV)アーキテクチャは、異種ネットワークを介したアプリケーションにエンドツーエンドのサービス品質(QO)を提供する手段を提供します。このエンドツーエンドモデルをサポートするには、IntServアーキテクチャをさまざまな種類のネットワーク要素でサポートする必要があります。これに関連して、差別化されたサービス(diffserv)をサポートするネットワークは、総エンドツーエンドパスのネットワーク要素として表示される場合があります。このドキュメントでは、統合サービスがDiffServネットワークでサポートされるフレームワークについて説明します。

Table of Contents

目次

   1. Introduction .................................................  3
   1.1 Integrated Services Architecture ............................  3
   1.2 RSVP ........................................................  3
   1.3 Diffserv ....................................................  4
   1.4 Roles of Intserv, RSVP and Diffserv .........................  4
   1.5 Components of Intserv, RSVP and Diffserv ....................  5
   1.6 The Framework ...............................................  6
   1.7 Contents ....................................................  6
   2. Benefits of Using Intserv with Diffserv ......................  7
   2.1 Resource Based Admission Control ............................  7
   2.2 Policy Based Admission Control ..............................  8
   2.3 Assistance in Traffic Identification/Classification .........  8
   2.3.1 Host Marking ..............................................  9
   2.3.2 Router Marking ............................................  9
   2.4 Traffic Conditioning ........................................ 10
   3. The Framework ................................................ 10
   3.1 Reference Network ........................................... 11
   3.1.1 Hosts ..................................................... 11
   3.1.2 End-to-End RSVP Signaling ................................. 12
   3.1.3 Edge Routers .............................................. 12
   3.1.4 Border Routers ............................................ 12
   3.1.5 Diffserv Network Region ................................... 13
   3.1.6 Non-Diffserv Network Regions .............................. 13
   3.2 Service Mapping ............................................. 13
   3.2.1 Default Mapping ........................................... 14
   3.2.2 Network Driven Mapping .................................... 14
   3.2.3 Microflow Separation ...................................... 14
   3.3 Resource Management in Diffserv Regions ..................... 15
   4. Detailed Examples of the Operation of
      Intserv over Diffserv Regions ................................ 16
   4.1 Statically Provisioned Diffserv Network Region .............. 16
   4.1.1 Sequence of Events in Obtaining End-to-end QoS ............ 16
   4.2 RSVP-Aware Diffserv Network Region .......................... 18
   4.2.1 Aggregated or Tunneled RSVP ............................... 19
   4.2.3 Per-flow RSVP ............................................. 20
   4.2.4 Granularity of Deployment of RSVP Aware Routers ........... 20
   4.3 Dynamically Provisioned, Non-RSVP-aware Diffserv Region ..... 21
   5. Implications of the Framework for Diffserv Network Regions ... 21
   5.1 Requirements from Diffserv Network Regions .................. 21
   5.2 Protection of Intserv Traffic from Other Traffic ............ 22
   6. Multicast .................................................... 22
   6.1 Remarking of packets in branch point routers ................ 24
   6.2 Multicast SLSs and Heterogeneous Trees ...................... 25
   7. Security Considerations ...................................... 26
   7.1 General RSVP Security ....................................... 26
   7.2 Host Marking ................................................ 26
      8. Acknowledgments .............................................. 27
   9. References ................................................... 27
   10. Authors' Addresses .......................................... 29
   11.  Full Copyright Statement ................................... 31
        
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ネットワークの作業により、統合サービスアーキテクチャ(INTSERV)[10]とそれに付随するシグナル伝達プロトコル、RSVP [1]、および差別化されたサービスアーキテクチャ(DIFFSERV)[8]の2つの異なるアプローチが発生しました。このドキュメントでは、intservアーキテクチャのコンテキストでdiffservネットワークを使用して、エンドツーエンドQosの配信をサポートする方法について説明します。

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つは、サービス定義のセットです。現在のサービスセットは、制御された負荷と保証されたサービスで構成されています。アーキテクチャは、いくつかの明示的なセットアップメカニズムを使用して、情報をルーターに伝えるために使用され、それらを必要とするフローに要求されたサービスを提供できると想定しています。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 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は、INTSV情報を運ぶ可能性のあるシグナル伝達プロトコルです。INTSERVは、サービスタイプを表現し、リソース要件を定量化し、関連するネットワーク要素で要求されたリソースの可用性を決定するためのモデルを定義します(入場制御)。

The current prevailing model of RSVP usage is based on a combined RSVP/Intserv architecture. In this model, RSVP signals per-flow resource requirements to network elements, using Intserv parameters. These network elements apply Intserv admission control to signaled requests. In addition, traffic control mechanisms on the network element are configured to ensure that each admitted flow receives the service requested in strict isolation from other traffic. To this end, RSVP signaling configures microflow (MF) [8] packet classifiers in Intserv capable routers along the path of the traffic flow. These classifiers enable per-flow classification of packets based on IP addresses and port numbers.

RSVP使用の現在の一般的なモデルは、RSVP/IntServアーキテクチャの組み合わせに基づいています。このモデルでは、RSVPは、IntServパラメーターを使用して、ネットワーク要素にフローごとのリソース要件を信号します。これらのネットワーク要素は、intserv入学制御を信号済み要求に適用します。さらに、ネットワーク要素のトラフィック制御メカニズムは、認められた各フローが他のトラフィックから厳密に分離して要求されたサービスを受信するように構成されています。この目的のために、RSVPシグナリングは、トラフィックフローの経路に沿って、IntServ対応ルーターにマイクロフロー(MF)[8]パケット分類子を構成します。これらの分類器は、IPアドレスとポート番号に基づいてパケットのフローごとの分類を有効にします。

The following factors have impeded deployment of RSVP (and the Intserv architecture) in the Internet at large:

次の要因は、インターネット全体にRSVP(およびIntServアーキテクチャ)の展開を妨げています。

1. The use of per-flow state and per-flow processing raises scalability concerns for large networks.

1. 流量あたりの状態と流量あたりの処理を使用すると、大規模なネットワークのスケーラビリティの懸念が生じます。

2. Only a small number of hosts currently generate RSVP signaling. While this number is expected to grow dramatically, many applications may never generate RSVP signaling.

2. 現在、少数のホストがRSVPシグナル伝達を生成しています。この数は劇的に増加すると予想されますが、多くのアプリケーションがRSVPシグナル伝達を生成することはありません。

3. The necessary policy control mechanisms -- access control, authentication, and accounting -- have only recently become available [17].

3. 必要なポリシー制御メカニズム(アクセス制御、認証、会計)は、ごく最近利用可能になりました[17]。

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の流量あたりの方向とは対照的に、DiffServネットワークは、パケットのIPヘッダーのDiffserv CodePoint(DSCP)に基づいて、パケットを少数の集計フローまたは「クラス」の1つに分類します。これは、行動集計(BA)分類[8]として知られています。各diffservルーターで、パケットは「ホップごとの動作」(PHB)にさらされ、DSCPによって呼び出されます。DiffServの主な利点は、そのスケーラビリティです。DiffServは、流量あたりの状態と流量あたりの処理の必要性を排除するため、大規模なネットワークを十分にスケーリングします。

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.

End-To-End QOSの追求におけるIntServ、RSVP、およびDiffServは補完的な技術と見なしています。一緒に、これらのメカニズムは、IP-Telephony、ビデオオンデマンド、およびさまざまな非マルチメディアミッションクリティカルなアプリケーションなどのアプリケーションの展開を容易にすることができます。INTSERVは、ホストがエンドツーエンドのデータパスに沿って、流量ごとの定量化可能なリソースを要求し、これらのリクエストの許容性に関するフィードバックを取得できるようにします。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シグナル伝達は、INTSVパラメーターを搭載している場合と搭載する場合があります。

Admission control at a network element may or may not be based on the Intserv model.

ネットワーク要素での入場制御は、INTSERVモデルに基づいている場合とそうでない場合があります。

MF traffic control - This term refers to traffic control which is applied independently to individual traffic flows and therefore requires recognizing individual traffic flows via MF classification.

MFトラフィックコントロール - この用語とは、個々の交通フローに独立して適用されるトラフィックコントロールを指し、したがってMF分類を介して個々の交通フローを認識する必要があります。

Aggregate traffic control - This term refers to traffic control which is applied collectively to sets of traffic flows. These sets of traffic flows are recognized based on BA (DSCP) classification. In this document, we use the terms "aggregate traffic control" and "Diffserv" interchangeably.

集約交通制御 - この用語とは、交通流のセットに集合的に適用されるトラフィックコントロールを指します。これらのトラフィックフローセットは、BA(DSCP)分類に基づいて認識されます。このドキュメントでは、「集約交通制御」と「diffserv」という用語を同じ意味で使用します。

Aggregate RSVP. While the existing definition of RSVP supports only per-flow reservations, extensions to RSVP are being developed to enable RSVP reservations to be made for aggregated traffic, i.e., sets of flows that may be recognized by BA classification. This use of RSVP may be useful in controlling the allocation of bandwidth in Diffserv networks.

集約RSVP。RSVPの既存の定義はフローごとの予約のみをサポートしていますが、RSVPへの拡張は、集約されたトラフィック、つまりBA分類によって認識される可能性のあるフローのセットのためにRSVP予約を行うことを可能にするために開発されています。このRSVPの使用は、diffservネットワークの帯域幅の割り当てを制御するのに役立つ可能性があります。

Per-flow RSVP. The conventional usage of RSVP to perform resource reservations for individual microflows.

フローごとのRSVP。個々のマイクロフローのリソース予約を実行するためのRSVPの従来の使用。

RSVP/Intserv - This term is used to refer to the prevailing model of RSVP usage which includes RSVP signaling with Intserv parameters, Intserv admission control and per-flow traffic control at network elements.

RSVP/INTSERV-この用語は、INTSVパラメーターを使用したRSVPシグナル伝達、INTSERV入院制御、およびネットワーク要素での流量あたりの交通制御を含むRSVP使用の一般的なモデルを参照するために使用されます。

Diffserv Region. A set of contiguous routers which support BA classification and traffic control. While such a region may also support MF classification, the goal of this document is to describe how such a region may be used in delivery of end-to-end QOS when only BA classification is performed inside the Diffserv region.

Diffserv領域。BAの分類と交通制御をサポートする一連の連続的なルーター。このような地域はMF分類もサポートする可能性がありますが、このドキュメントの目標は、BA分類のみがdiffserv領域内で実行される場合、エンドツーエンドQosの配信にそのような地域をどのように使用できるかを説明することです。

Non-Diffserv Region. The portions of the network outside the Diffserv region. Such a region may also offer a variety of different types of classification and traffic control.

非ディフェルブ地域。diffserv領域以外のネットワークの部分。このような地域は、さまざまな種類の分類と交通制御も提供する場合があります。

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の提供に使用される分類と交通制御のタイプであることに注意してください。したがって、特定の領域を、地域を流れるすべてのトラフィックに関して「純粋に拡散」として識別することはできないかもしれませんが、単一のアプリケーションからのトラフィックの扱いの観点からこのように定義することは可能です。

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.

私たちが提示するフレームワークでは、エンドツーエンドの定量的QoSは、1つ以上のDiffServ領域を含むネットワーク全体にintServモデルのエンドツーエンドを適用することにより提供されます。diffserv領域は、リソースの割り当てを最適化し、入学制御をサポートする目的で、エンドツーエンドのRSVPシグナリングに参加することができますが、必要ではありません。

From the perspective of Intserv, Diffserv regions of the network are treated as virtual links connecting Intserv capable routers or hosts (much as an 802.1p network region is treated as a virtual link in [5]). Within the Diffserv regions of the network routers implement specific PHBs (aggregate traffic control). The total amount of traffic that is admitted into the Diffserv region that will receive a certain PHB may be limited by policing at the edge. As a result we expect that the Diffserv regions of the network will be able to support the Intserv style services requested from the periphery. In our framework, we address the support of end-to-end Integrated Services over the Diffserv regions of the network. Our goal is to enable seamless inter-operation. As a result, the network administrator is free to choose which regions of the network act as Diffserv regions. In one extreme the Diffserv region is pushed all the way to the periphery, with hosts alone having full Intserv capability. In the other extreme, Intserv is pushed all the way to the core, with no Diffserv region.

INTSERVの観点から、ネットワークのDiffServ領域は、IntServ対応ルーターまたはホストを接続する仮想リンクとして扱われます(802.1pネットワーク領域は[5]の仮想リンクとして扱われます)。 ネットワークルーターのdiffserv領域内では、特定のPHB(集約トラフィックコントロール)を実装します。 特定のPHBを受け取るDiffserv領域に入院するトラフィックの総量は、エッジでポリシングすることで制限される場合があります。 その結果、ネットワークのDiffserv領域は、周辺から要求されたIntServスタイルサービスをサポートできると予想しています。 私たちのフレームワークでは、ネットワークのdiffserv領域を介したエンドツーエンドの統合サービスのサポートに対処します。 私たちの目標は、シームレスな操作を可能にすることです。 その結果、ネットワーク管理者は、ネットワークのどの領域がdiffserv領域として機能するかを自由に選択できます。 極端に、diffserv領域は周辺までずっと押し込まれ、ホストだけが完全なintserv機能を備えています。 他の極端では、diffserv領域がなく、intservがコアまでずっと押し込まれます。

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では、マルチキャストフローに固有のいくつかの問題を示します。

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との相互操作が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ネットワーク領域では、ネットワーク要素でポリシングパラメーターをプロビジョニングすることにより、入場制御が比較的静的な方法で適用されます。たとえば、IngressのDiffServネットワーク領域へのネットワーク要素は、EF DSCPの50 kbpsのトラフィックのみを受け入れるようにプロビジョニングできます。

While such static forms of admission control do protect the network to some degree, they can be quite ineffective. For example, consider that there may be 10 IP telephony sessions originating outside the Diffserv network region, each requiring 10 Kbps of EF service from the Diffserv network region. Since the network element protecting the Diffserv network region is provisioned to accept only 50 Kbps of traffic for the EF DSCP, it will discard half the offered traffic. This traffic will be discarded from the aggregation of traffic marked EF, with no regard to the microflow from which it originated. As a result, it is likely that of the ten IP telephony sessions, none will obtain satisfactory service when in fact, there are sufficient resources available in the Diffserv network region to satisfy five sessions.

このような静的な形式の入場制御は、ネットワークをある程度保護しますが、非常に効果がない場合があります。たとえば、DiffServネットワークリージョンの外側に生じた10のIPテレフォニーセッションがある可能性があり、それぞれがDiffServネットワーク地域から10 kbpsのEFサービスを必要とすることを考慮してください。DiffServネットワーク領域を保護するネットワーク要素は、EF DSCPの50 kbpsのトラフィックのみを受け入れるようにプロビジョニングされているため、提供されるトラフィックの半分を破棄します。このトラフィックは、それが発生したマイクロフローに関係なく、マークされたEFのマークされたトラフィックの集約から廃棄されます。その結果、10個のIPテレフォニーセッションのうち、実際には5つのセッションを満たすためにDiffservネットワーク地域に十分なリソースが利用可能な場合、満足のいくサービスを得るものはありません。

In the case of explicitly signaled, dynamic admission control, the network will signal rejection in response to requests for resources that would exceed the 50 Kbps limit. As a result, upstream network elements (including originating hosts) and applications will have the information they require to take corrective action. The application might respond by refraining from transmitting, or by requesting admission for a lesser traffic profile. The host operating system might respond by marking the application's traffic for the DSCP that corresponds to best-effort service. Upstream network elements might respond by re-marking packets on the rejected flow to a lower service level. In some cases, it may be possible to reroute traffic over alternate paths or even alternate networks (e.g., the PSTN for voice calls). In any case, the integrity of those flows that were admitted would be preserved, at the expense of the flows that were not admitted. Thus, by appointing an Intserv-conversant admission control agent for the Diffserv region of the network it is possible to enhance the service that the network can provide to quantitative QoS applications.

明示的に合図された動的な入場制御の場合、ネットワークは50 kbpsの制限を超えるリソースの要求に応じて拒否を信号します。その結果、上流のネットワーク要素(出身のホストを含む)とアプリケーションには、是正措置を講じるために必要な情報があります。アプリケーションは、送信を控えるか、より少ないトラフィックプロファイルの入場を要求することにより応答する場合があります。ホストオペレーティングシステムは、Best-Effortサービスに対応するDSCPのアプリケーションのトラフィックをマークすることで応答する場合があります。上流のネットワーク要素は、拒否されたフローでパケットをより低いサービスレベルに再マークすることで応答する可能性があります。場合によっては、代替パスや代替ネットワーク(音声通話のPSTNなど)のトラフィックを再ルーティングすることが可能になる場合があります。いずれにせよ、認められたフローを犠牲にして、認められた流れの完全性は保存されます。したがって、ネットワークのdiffserv領域のintserv継続的な入学制御エージェントを任命することにより、ネットワークが定量的な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 Consectant Andimant Controlエージェントを使用して、DiffServ Network Regionのリソースを使用する資格のある特定の顧客トラフィックフローを決定するために特定の顧客ポリシーを適用できます。顧客ポリシーを使用して、特定のユーザーやアプリケーションにリソースを割り当てることができます。

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をマークするように構成されています。各スキームには利点と短所があります。使用されるスキームに関係なく、明示的なシグナル伝達には大きな利点があります。

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をマークします。このアプローチには、フローごとの分類をシフトし、トラフィックのソースにマークを付け、最適なスケーリングの利点があります。また、ホストは、送信された各パケット、したがって各パケットに付随する相対的な重要性に適したマークに関して決定を下すことができます。ホストは一般に、ネットワークよりもこの決定を下すのに適しています。さらに、IPSEC暗号化を使用する場合、ポート番号などのさまざまなフィールドがMF分類のルーターが利用できないため、各パケットの適切なマーキングを意味する決定を行うことができるネットワーク内の唯一のデバイスである可能性があります。

Host marking requires that the host be aware of the interpretation of DSCPs by the network. This information can be configured into each host. However, such configuration imposes a management burden. Alternatively, hosts can use an explicit signaling protocol such as RSVP to query the network to obtain a suitable DSCP or set of DSCPs to apply to packets for which a certain Intserv service has been requested. An example of how this can be achieved is described in [14].

ホストマーキングでは、ホストがネットワークによるDSCPの解釈を認識する必要があります。この情報は、各ホストに構成できます。ただし、そのような構成は管理負担を課します。または、ホストはRSVPなどの明示的なシグナル伝達プロトコルを使用してネットワークを照会し、適切なDSCPまたはDSCPのセットを取得して、特定のIntServサービスが要求されているパケットに適用できます。これを達成する方法の例は、[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 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対応ネットワーク要素は、シェーピングおよび/またはポリシングの組み合わせにより、流量あたりの粒度でトラフィックを条件付けることができます。ネットワークの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.

一般的なフレームワークでは、統合されたサービスアーキテクチャがエンドツーエンドのQOをアプリケーションに配信するために使用されるインターネットを想定しています。ネットワークには、INTSERV対応ノード(MF分類と流量あたりのトラフィックコントロールが適用される)とdiffserv領域(凝集トラフィックコントロールが適用される)の組み合わせが含まれます。個々のルーターは、ネットワークのどこに存在するかに関係なく、RSVPシグナル伝達に参加する場合と参加できない場合があります。

We will consider two specific realizations of the framework. In the first, resources within the Diffserv regions of the network are statically provisioned and these regions include no RSVP aware devices. In the second, resources within the Diffserv region of the network are dynamically provisioned and select devices within the Diffserv network regions participate in RSVP signaling.

フレームワークの2つの具体的な実現を検討します。最初に、ネットワークのdiffserv領域内のリソースが静的にプロビジョニングされ、これらの領域にはRSVP認識デバイスが含まれていません。第二に、ネットワークのdiffserv領域内のリソースは動的にプロビジョニングされ、diffservネットワーク領域内の選択デバイスがRSVPシグナリングに参加します。

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 |
    |---| |        |-- |   |---|          |---|   |---|        | |---|
           \          /     \                /     \          /
            \________/       \______________/       \________/
        

Non-Diffserv region Diffserv region Non-Diffserv region

非ディフェルブ地域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領域(非ディフセルブ領域)の外側の領域には、ルーターと接続されたホストのメッシュが含まれており、その一部は統合サービスアーキテクチャをサポートしています。

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領域内の境界ルーター(BR1、BR2)へのdiffserv領域界面に隣接するエッジルーター(ER1、ER2)。

From an economic viewpoint, we may consider that the Diffserv region sells service to the network outside the Diffserv region, which in turn provides service to hosts. Thus, we may think of the non-Diffserv regions as clients or customers of the Diffserv region. In the following, we use the term "customer" for the non-Diffserv regions. Note that the boundaries of the regions may or may not align with administrative domain boundaries, and that a single region might contain multiple administrative domains.

経済的観点から、DiffServ地域はDiffServ地域以外のネットワークへのサービスを販売していると考えるかもしれません。これは、ホストにサービスを提供します。したがって、Diffserv地域以外の地域をDiffServ地域のクライアントまたは顧客と考えることができます。以下では、非ディフサービス地域の「顧客」という用語を使用します。地域の境界には、管理ドメインの境界に沿っている場合と整列していない場合があり、単一の領域には複数の管理ドメインが含まれている可能性があることに注意してください。

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, but RSVP is clearly the prevalent mechanism for this purpose.

送信と受信ホストの両方がRSVPを使用して、ホストで実行されているQoS対応アプリケーションの定量的QoS要件を通知すると想定しています。原則として、他のメカニズムを使用して、intServ対応ノードのリソース予約を確立することができますが、RSVPは明らかにこの目的の一般的なメカニズムです。

Typically, a QoS process within the host operating system generates RSVP signaling on behalf of applications. This process may also invoke local traffic control.

通常、ホストオペレーティングシステム内のQoSプロセスは、アプリケーションに代わってRSVPシグナリングを生成します。このプロセスは、現地の交通制御を呼び起こす可能性もあります。

As discussed above, traffic control in the host may mark the DSCP in transmitted packets, and shape transmitted traffic to the requirements of the Intserv service in use. Alternatively, the first Intserv-capable router downstream from the host may provide these traffic control functions.

上記で説明したように、ホストのトラフィックコントロールは、送信されたパケットのDSCPをマークし、使用中のINTSERVサービスの要件への送信トラフィックを形成する場合があります。あるいは、ホストから下流の最初のintserv対応ルーターは、これらのトラフィック制御機能を提供する場合があります。

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が認識されていない場合、EdgeルーターはDiffServネットワークのアミズミコントロールエージェントとして機能します。TXとRXの両方からのシグナリングメッセージを処理し、DiffServネットワークリージョン内のリソースの可用性と顧客定義のポリシーに基づいて入場制御を適用します。DiffServネットワーク領域がRSVP認識である場合、エッジルーターはローカルリソースの可用性と顧客定義のポリシーに基づいて入場制御を適用します。この場合、ボーダールーターは、DiffServネットワーク領域の入場制御エージェントとして機能します。

We will later describe the functionality of the edge routers in greater depth for each of the two realizations of the framework.

後で、フレームワークの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 trafficcontrol). In the case in which the Diffserv network region is RSVP-aware, the border routers participate in RSVP signaling and act as admission control agents for the Diffserv network region.

BR1とBR2はボーダールーターであり、DiffServネットワーク地域に住んでいます。ボーダールーターの機能は、フレームワークの特定の実現によって異なります。DiffServネットワーク領域がRSVPユナウェアである場合、これらのルーターは純粋なDiffServルーターとして機能します。そのため、彼らの唯一の責任は、DSCPで指定されたサービスレベルと顧客と交渉された契約(集計TrafficControl)に基づいて、警察の提出されたトラフィックを警察することです。DiffServ Network RegionがRSVPを認識している場合、Border RouterはRSVPシグナル伝達に参加し、DiffServネットワークリージョンの入場制御エージェントとして機能します。

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 非ディフェルブネットワーク領域

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ホップでは、INTSVパラメーターが適切な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対応のスイッチされたセグメントに類似しています。IntServサービスのリクエストは、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またはPHBのセットを選択します。 - Diffserv領域の端で適切なポリシング(おそらく、シェーピングまたはリマーキングを含む)を実行する。 - diffserv領域からのintservパラメーターのエクスポート(たとえば、ADSPECの更新用);-DiffServ地域でのリソースの可用性を考慮したINTSERVリクエストの入場制御を実行します。

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(またはPHBのセット)が特定の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.

このスキームでは、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].

このスキームでは、diffservネットワーク領域(おそらくその端にある)のRSVP Consontantルーターが4.2.1で説明されているよく知られているマッピングを上書きする可能性があります。DSCPがDiffserv領域への侵入でマークされている場合、DSCPは境界ルーターで単純に注目することができます。ただし、DSCPマーキングがホストまたはルーターのいずれかでDIFFSERV領域の上流に発生する場合、適切なマッピングを上流のマッピングをマーキングデバイスに通知する必要があります。これは、[14]で説明されているように、RSVPを使用して達成できます。

The decision regarding where to mark DSCP and whether to override the well-known service mapping is a mater of policy to be decided by the administrator of the Diffserv network region in cooperation with the administrator of the network adjacent to the Diffserv region.

DSCPをマークする場所と、有名なサービスマッピングをオーバーライドするかどうかに関する決定は、DiffServ地域に隣接するネットワークの管理者と協力して、DiffServネットワーク地域の管理者が決定するポリシーの母性です。

3.2.3 Microflow Separation
3.2.3 マイクロフロー分離

Boundary routers residing at the edge of the Diffserv region will typically police traffic submitted from the outside the Diffserv region in order to protect resources within the Diffserv region. This policing will be applied on an aggregate basis, with no regard for the individual microflows making up each aggregate. As a result, it is possible for a misbehaving microflow to claim more than its fair share of resources within the aggregate, thereby degrading the service provided to other microflows. This problem may be addressed by:

Diffserv領域の端に存在する境界ルーターは、通常、Diffserv領域内のリソースを保護するために、Diffserv領域の外側から提出された警察の交通を警察します。このポリシングは、個々のマイクロフローが各骨材を構成することを考慮せずに、集計ベースで適用されます。その結果、誤っているマイクロフローが、集計内のリソースの公正なシェアを超えて、他のマイクロフローに提供されるサービスを低下させる可能性があります。この問題は、次のように対処できます。

1. Providing per microflow policing at the edge routers - this is generally the most appropriate location for microflow policing, since it pushes per-flow work to the edges of the network, where it scales better. In addition, since Intserv-capable routers outside the Diffserv region are responsible for providing microflow service to their customers and the Diffserv region is responsible for providing aggregate service to its customers, this distribution of functionality mirrors the distribution of responsibility.

1. エッジルーターでマイクロフローポリシングを提供する - これは一般に、マイクロフローポリシングに最も適した場所です。これは、フローごとの作業をネットワークの端に押し進め、より良いスケーリングです。さらに、diffserv地域の外側のintserv対応ルーターは顧客にマイクロフローサービスを提供する責任があるため、diffserv地域は顧客に総サービスを提供する責任があるため、この機能の分布は責任の分布を反映しています。

2. Providing per microflow policing at the border routers - this approach tends to be less scalable than the previous approach. It also imposes a management burden on the Diffserv region of the network. However, it may be appropriate in certain cases, for the Diffserv boundary routers to offer per microflow policing as a value-add to its Intserv customers.

2. ボーダールーターでマイクロフローポリシングを提供する - このアプローチは、以前のアプローチよりもスケーラブルではない傾向があります。また、ネットワークのdiffserv領域に管理負担を課します。ただし、特定の場合、Diffserv境界ルーターがMicroflow Policingを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地域の境界で再構築またはポリシングを保証しないように、ホストの特定のグループの形成を十分に信頼する場合があります。ホストがマイクロフローを適切に形成している場合でも、これらの形状の流れは、ネットワークの非ディフェルサーブ領域を通過すると歪む可能性があることに注意してください。歪みの程度に応じて、diffserv領域の骨材容量を多少過剰に導入するか、上記の1または2を使用して再施行する必要がある場合があります。1つのメカニズムの選択は、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:

エンドツーエンドのIntServフローのニーズを満たすために、DiffServネットワーク領域のリソースの管理(帯域幅など)のためのさまざまなオプションが存在します。これらのオプションは次のとおりです。

- statically provisioned resources; - resources dynamically provisioned by RSVP; - resources dynamically provisioned by other means (e.g., a form of Bandwidth Broker).

- 静的なプロビジョニングリソース。-RSVPによって動的にプロビジョニングされたリソース。 - 他の手段によって動的にプロビジョニングされたリソース(例:帯域幅ブローカーの形式)。

Some of the details of using each of these different approaches are discussed in the following section.

これらの異なるアプローチのそれぞれを使用する詳細のいくつかについては、次のセクションで説明します。

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.

このセクションでは、アクション中のフレームワークの詳細な例を示します。DiffServネットワーク領域がRSVPが認識されていない2つの例について説明します。

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ネットワーク地域の所有者は、多数の標準DiffServサービスで顧客に提供される送信能力について、静的契約(サービスレベルの仕様、またはSLS)を交渉しました。 レベル。 「送信容量」は、単に帯域幅の量であるか、バーストサイズ、ピークレート、時刻などの多くの要因を含む、より複雑な「プロファイル」である可能性があります。

It is helpful to consider each edge router in the customer network as consisting of two halves, a standard Intserv half, which interfaces to the customer's network regions and a Diffserv half which interfaces to the Diffserv network region. The Intserv half is able to identify and process traffic on per-flow granularity.

カスタマーネットワーク内の各エッジルーターは、顧客のネットワーク領域にインターフェイスする標準的なIntServハーフと、Diffservネットワーク領域にインターフェイスするDiffserv Halfで構成される2つの半分、標準的なIntServハーフで構成されていると考えると役立ちます。IntServの半分は、流量あたりの粒度のトラフィックを特定して処理することができます。

The Diffserv half of the router can be considered to consist of a number of virtual transmit interfaces, one for each Diffserv service level negotiated in the SLS. The router contains a table that indicates the transmit capacity provisioned, per the SLS at each Diffserv service level. This table, in conjunction with the default mapping described in 4.2.1, is used to perform admission control decisions on Intserv flows which cross the Diffserv network region.

ルーターのdiffserv半分は、SLSで交渉された各diffservサービスレベルに1つの仮想送信インターフェイスで構成されていると考えることができます。ルーターには、各diffservサービスレベルのSLSごとに、送信容量がプロビジョニングされたものを示すテーブルが含まれています。この表は、4.2.1で説明されているデフォルトのマッピングと併せて、DiffServネットワーク領域を横断するINTSERVフローの入場制御決定を実行するために使用されます。

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パスメッセージを生成します。

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. パスメッセージは、受信ホストの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 message is sent onward to the Diffserv network region.

3. Edge Router ER1では、パスメッセージが標準のRSVP処理にかけられ、パス状態がルーターにインストールされます。パスメッセージは、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. パスメッセージは、DiffServネットワーク領域のルーターによって無視され、標準のRSVP処理ルールに従ってER2で処理されます。

5. When the PATH message reaches the receiving host Rx, the operating system generates an RSVP RESV message, indicating interest in offered traffic of a certain Intserv service type.

5. パスメッセージが受信ホスト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 Intserv-capable nodes). It may also learn the appropriate DSCP marking to apply to packets for this flow from information provided in the RESV.

11. TXでは、QoSプロセスがRESVメッセージを受信します。指定されたトラフィックフローが指定されたIntServサービスタイプ(IntServ対応ノード)で認められていることを示すこととして、メッセージの受信を解釈します。また、RESVで提供される情報からこのフローにパケットに適用するための適切なDSCPマーキングを学習する場合があります。

12. Tx may mark the DSCP in the headers of packets that are transmitted on the admitted traffic flow. The DSCP may be the default value which maps to the Intserv service type specified in the admitted RESV message, or it may be a value explicitly provided in the RESV.

12. TXは、入院したトラフィックフローに送信されるパケットのヘッダーにDSCPをマークする場合があります。DSCPは、認められたRESVメッセージで指定されたINTSERVサービスタイプにマップするデフォルト値である場合があります。または、RESVで明示的に提供される値である場合があります。

In this manner, we obtain end-to-end QoS through a combination of networks that support RSVP/Intserv and networks that support Diffserv.

この方法で、RSVP/IntServとDiffServをサポートするネットワークをサポートするネットワークの組み合わせを通じて、エンドツーエンドのQoSを取得します。

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ルーターです。Border Router、BR1はRSVP認識です。さらに、RSVPが認識している他のルーターがdiffservネットワーク領域内にある場合があります。これらのルーターは何らかの形のRSVPシグナル伝達に関与することはできますが、標準のRSVP/IntServルーターで使用されるフローごとの分類基準ではなく、DSCPに基づいてトラフィックを分類およびスケジュールします。データプレーンはDiffServである間、コントロールプレーンはRSVPであると言えます。このアプローチは、diffservに関連するスケーラビリティの多くを維持しながら、RSVPシグナル伝達の利点を活用します。

In the preceding example, there is no signaling between the Diffserv network region and network elements outside it. The negotiation of an SLS is the only explicit exchange of resource availability information between the two network regions. ER1 is configured with the information represented by the SLS and as such, is able to act as an admission control agent for the Diffserv network region. Such configuration does not readily support dynamically changing SLSs, since ER1 requires reconfiguration each time the SLS changes. It is also difficult to make efficient use of the resources in the Diffserv network region. This is because admission control does not consider the availability of resources in the Diffserv network region along the specific path that would be impacted.

前の例では、DiffServネットワーク領域とその外側のネットワーク要素の間にシグナル伝達はありません。SLSの交渉は、2つのネットワーク領域間のリソース可用性情報の唯一の明示的な交換です。ER1は、SLSで表される情報で構成されているため、DiffServネットワーク領域の入学制御エージェントとして機能することができます。ER1にはSLSが変更されるたびに再構成が必要なため、このような構成は動的に変化するSLSを容易にサポートしません。また、DiffServネットワーク地域でリソースを効率的に使用することも困難です。これは、入場制御が影響を受ける特定のパスに沿ったDiffServネットワーク地域でのリソースの可用性を考慮していないためです。

By contrast, when the Diffserv network region is RSVP aware, the admission control agent is part of the Diffserv network. As a result, changes in the capacity available in the Diffserv network region can be indicated to the Intserv-capable nodes outside the Diffserv region via RSVP. By including routers interior to the Diffserv network region in RSVP signaling, it is possible to simultaneously improve the efficiency of resource usage within the Diffserv region and to improve the level of confidence that the resources requested at admission control are indeed available at this particular point in time. This is because admission control can be linked to the availability of resources along the specific path that would be impacted. We refer to this benefit of RSVP signaling as "topology aware admission control". A further benefit of supporting RSVP signaling within the Diffserv network region is that it is possible to effect changes in the provisioning of the Diffserv network region (e.g., allocating more or less bandwidth to the EF queue in a router) in response to resource requests from outside of the Diffserv region.

対照的に、diffservネットワーク領域がRSVP認識の場合、入学制御エージェントはdiffservネットワークの一部です。その結果、DiffServネットワーク領域で利用可能な容量の変化は、RSVPを介してDiffServ領域の外側のIntServ対応ノードに示すことができます。RSVPシグナル伝達にDiffServネットワーク領域にルーターの内部を含めることにより、DiffServ領域内のリソース使用の効率を同時に改善し、入学制御で要求されたリソースが実際にこの特定のポイントで利用可能であるという信頼レベルを改善することができます。時間。これは、入場制御が影響を受ける特定のパスに沿ったリソースの可用性にリンクできるためです。RSVPシグナル伝達のこの利点を「トポロジー認識入場管理」と呼びます。DiffServネットワーク領域内でRSVPシグナル伝達をサポートすることのさらなる利点は、DiffServネットワーク領域のプロビジョニングの変更を実施することが可能であることです(たとえば、ルーターのEFキューに多かれ少なかれ帯域幅を割り当てます)。diffserv領域の外。

Various mechanisms may be used within the Diffserv network region to support dynamic provisioning and topology aware admission control. These include aggregated RSVP, per-flow RSVP and bandwidth brokers, as described in the following paragraphs.

DiffServネットワーク領域内でさまざまなメカニズムを使用して、動的なプロビジョニングとトポロジの認識入学制御をサポートすることができます。これらには、次の段落で説明されているように、集約されたRSVP、流量あたりのRSVP、および帯域幅ブローカーが含まれます。

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を拡張するためのメカニズムを提案しています。 ボーダールーターは、集約されたRSVPを使用してコアルーターやその他のボーダールーターと相互作用して、DiffServネットワーク領域のエッジ間のリソースを予約できます。 予想されるトラフィックパターンに基づいて、各サービスレベルの初期予約レベルを主要なボーダールーター間で確立できます。 ボーダールーターは、高水または低水準点に達する非ディフェルサーブ領域からの累積累積RSVP要求の結果として、予約レベルの変化を引き起こす可能性があります。

In this approach, admission of per-flow RSVP requests from nodes outside the Diffserv region would be counted against the appropriate aggregate reservations for the corresponding service level. The size of the aggregate reservations may or may not be dynamically adjusted to deal with the changes in per-flow reservations.

このアプローチでは、DiffServ領域以外のノードからの流量ごとのRSVP要求の入場は、対応するサービスレベルの適切な集計予約に対してカウントされます。総予約のサイズは、流量あたりの予約の変更に対処するために動的に調整される場合とそうでない場合があります。

The advantage of this approach is that it offers dynamic, topology aware admission control to the Diffserv network region without requiring the level of RSVP signaling processing that would be required to support per-flow RSVP.

このアプローチの利点は、流量ごとのRSVPをサポートするために必要なRSVPシグナリング処理のレベルを必要とせずに、DiffServネットワークリージョンへの動的でトポロジを認識している入場制御を提供することです。

We note that resource management of a Diffserv region using aggregated RSVP is most likely to be feasible only within a single administrative domain, as each domain will probably choose its own mechanism to manage its resources.

集約されたRSVPを使用したDiffServ領域のリソース管理は、単一の管理ドメイン内でのみ実行可能である可能性が高いことに注意してください。各ドメインは、おそらくリソースを管理する独自のメカニズムを選択する可能性があるためです。

4.2.3 Per-flow RSVP
4.2.3 フローごとの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対応ノードに由来する標準の流量ごとのRSVPシグナル伝達に応答します。このアプローチは、集約されたRSVPサポートを必要とせずに、以前のアプローチ(動的、トポロジ認識の入場制御)の利点を提供します。また、フローごとの入場制御の結果として、リソースはより効率的に使用されます。ただし、DiffServネットワーク領域内のRSVPシグナリングリソースに対する需要は、集計されたRSVPアプローチよりも大幅に高い場合があります。

Note that per-flow RSVP and aggregated RSVP are not mutually exclusive in a single Diffserv region. It is possible to use per-flow RSVP at the edges of the Diffserv region and aggregation only in some "core" region within the Diffserv region.

流量あたりのRSVPと凝集したRSVPは、単一のDiffServ領域では相互に排他的ではないことに注意してください。Diffserv領域の端で流量あたりのRSVPを使用し、DiffServ領域内の一部の「コア」領域でのみ集約を使用することができます。

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集約は、リソース利用における最適性がある程度失われるコストでシグナリングオーバーヘッドを制限する1つの方法です。

It is likely that some network administrators will compromise by enabling RSVP signaling on some subset of routers in the Diffserv network region. These routers will likely represent major traffic switching points with over-provisioned or statically provisioned regions of RSVP unaware routers between them.

一部のネットワーク管理者は、diffservネットワーク領域のルーターの一部のサブセットでRSVPシグナル伝達を有効にすることで妥協する可能性があります。これらのルーターは、RSVPの過剰なプロビジョニング領域または静的にプロビジョニングされた領域の間にあるルーターの間にある主要なトラフィックスイッチングポイントを表している可能性があります。

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シグナルを使用しない場合がありますが、代わりにカスタムプロトコルを使用して「Oracle」と対話する場合があります。Oracleは、リソースの可用性とネットワークトポロジに関する十分な知識を持っているエージェントであり、入場管理の決定を下します。前の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
5.1 DiffServネットワーク地域からの要件

A Diffserv network region must meet the following requirements in order for it to support the framework described in this document.

このドキュメントで説明されているフレームワークをサポートするには、DiffServネットワーク領域が次の要件を満たす必要があります。

1. A Diffserv network region must be able to provide support for the standard Intserv QoS services between its border routers. It must be possible to invoke these services by use of standard PHBs within the Diffserv region and appropriate behavior at the edge of the Diffserv region.

1. DiffServネットワーク領域は、ボーダールーター間の標準的なIntServ QoSサービスをサポートできる必要があります。Diffserv領域内の標準PHBを使用し、Diffserv領域の端で適切な動作を使用することにより、これらのサービスを呼び出すことが可能である必要があります。

2. Diffserv network regions must provide admission control information to their "customer" (non-Diffserv) network regions. This information can be provided by a dynamic protocol or through static service level agreements enforced at the edges of the Diffserv region.

2. DiffServネットワーク領域は、「顧客」(非Diffserv)ネットワーク領域に入学制御情報を提供する必要があります。この情報は、動的プロトコルによって、またはdiffserv領域の端で実施される静的サービスレベル契約によって提供できます。

3. Diffserv network regions must be able to pass RSVP messages, in such a manner that they can be recovered at the egress of the Diffserv network region. The Diffserv network region may, but is not required to, process these messages. Mechanisms for transparently carrying RSVP messages across a transit network are described in [3,6,15,16].

3. DiffServネットワーク領域は、DiffServネットワーク領域の出口で回復できるように、RSVPメッセージを渡すことができる必要があります。diffservネットワーク領域は、これらのメッセージを処理する必要はありませんが、必要ありません。Transitネットワーク全体で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. DiffServネットワーク地域が提供できるサービスへのIntServスタイルのサービス仕様をマッピングします。

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. ネットワーク要素で必要な機能の定義は、総トラフィックコントロールを使用したRSVPシグナル伝達をサポートするために(diffservネットワーク領域に存在するネットワーク要素用)。3. DiffServネットワーク領域(たとえば、RSVP、トンネル、MPLSなど)でリソースを効率的かつ動的に提供するメカニズムの定義。これには、「Oracle」が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. 他のすべての(ベストエフォルト)トラフィック。これらの3つのクラスのトラフィックは、DiffServネットワーク領域へのイングレスポイントでのポリサーと分類器の適切な構成、およびDiffServネットワーク領域内の適切なプロビジョニングによって、互いに分離する必要があります。ネットワークのDIFSERV領域でのIntServトラフィックの保護を提供するために、そのようなトラフィックに割り当てられたDSCPは、他のトラフィックに割り当てられたDSCPと重複しないことをお勧めします。

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領域に関連付けられています。(DiffServ領域以外のマルチキャスト機能のサポートは、各フローについてマルチキャストツリーストアに沿ったすべてのIntServ対応ルーターが状態であるため、比較的簡単です。)

Consider the following reference network:

次の参照ネットワークを検討してください。

                                          Non-Diffserv region 2
                                                    ________
                                                   /        \
                                                  |          | |---|
             ________         _____________       |          |-|Rx1|
            /        \       /          |--\      |---|      | |---|
           /          \     /          /|BR2\-----\ER2|     /
    |---| |        |---|   |---|  |--|/ |---|      \--|____/
    |Tx |-|        |ER1|---|BR1|--|RR|      |       ________
    |---| |        |-- |   |---|  |--|\ |---|      /--|     \
           \          /     \          \|BR3/-----|ER3|      | |---|
            \________/       \__________|--/      |---|      |-|Rx2|
                                                  |          | |---|
    Non-Diffserv region 1   Diffserv region        \        /
                                                    \______/
        

Non-Diffserv region 3

非ディフェルブリージョン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.

最も単純な場合、Receiver、RX1およびRX2は参照ネットワークのRX1とRX2が同一の予約を必要とします。DiffServフレームワーク[18]は、侵入ルーターから1つ、またはすべての出力ルーターの一部、またはすべてのルーターまで、サービスレベルの仕様(SLS)をサポートしています。これには、BR1からBR2およびBR3まで、DiffServ領域内の「1対1から多くの」SLSが必要です。SLSは、DiffServ領域、Ingressルーター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つだけが最良の努力よりもレベルのサービスを要求しています。次の段落でこのようなシナリオを検討します。

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.

- Core DiffservルーターであるRRは、Flow(MF)分類とは対照的に、集約トラフィックストリーム(BA)に基づいて分類されます。したがって、特定のマルチキャストツリーに属するパケットを区別し、同じDSCPを運ぶ動作集合体の他のパケットから降格を必要とするパケットを区別する機能を必ずしも持っているわけではありません。

- Since RR may be RSVP-unaware, it may not participate in the admission control process, and would thus not store any per-flow state about the reservations for the multicast tree. Hence, even if RR were able to perform MF classification and DSCP remarking, it would not know enough about downstream reservations to remark the DSCP intelligently.

- RRはRSVP-Unawareである可能性があるため、入学制御プロセスに参加しない可能性があるため、マルチキャストツリーの予約については、1流度ごとの状態を保存しません。したがって、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の分類と発言をサポートし、ブランチポイントである不均一な予約について、流量あたりの状態を保持します。この場合、Branch Pointルーターは、RSVPを認識したDiffServドメインのイングレスルーターと本質的に同じ機能を持つことに注意してください。

2. Packets sent on the "non-reserved" branch (from RR towards BR3) are marked with the "wrong" DSCP; that is, they are not demoted to best effort but retain their DSCP. This in turn requires over reservation of resources along that link or runs the risk of degrading service to packets that legitimately bear the same DSCP along this path. However, it allows the Diffserv routers to remain free of per-flow state.

2. 「非予約されていない」ブランチ(RRからBR3へ)で送信されたパケットには、「間違った」DSCPがマークされています。つまり、彼らは最善の努力に降格されるのではなく、DSCPを保持しています。これには、このリンクに沿ってリソースの予約を過度に留保するか、このパスに沿って同じDSCPを合法的に支えるパケットにサービスを劣化するリスクを実行する必要があります。ただし、Diffservルーターは流量あたりの状態を維持することができます。

3. A combination of mechanism 1 and 2 may be an effective compromise. In this case, there are some Intserv-capable routers in the core of the network, but the network cannot be administered so that ALL branch points fall at such routers.

3. メカニズム1と2の組み合わせは、効果的な妥協です。この場合、ネットワークのコアにはintserv対応のルーターがいくつかありますが、ネットワークは管理できないため、すべての分岐点がそのようなルーターに落ちるようにします。

4. Administrators of Diffserv regions may decide not to enable heterogeneous sub-trees in their domains. In the case of different downstream reservations, a ResvErr message would be sent according to the RSVP rules. This is similar to the approach taken for Intserv over IEEE 802 Networks [2,5].

4. DiffServ地域の管理者は、ドメインで不均一なサブツリーを有効にしないことを決定する場合があります。異なる下流の予約の場合、RSVPルールに従ってRESVERRメッセージが送信されます。これは、IEEE 802ネットワークを介してINTSERVのために取られたアプローチに似ています[2,5]。

5. In [3], a scheme was introduced whereby branch point routers in the interior of the aggregation region (i.e., the Diffserv region) keep reduced state information regarding the reservations by using measurement based admission control. Under this scheme, packets are tagged by the more knowledgeable Intserv edges routers with scheduling information that is used in place of the detailed Intserv state. If the Diffserv region and branch point routers are designed following that framework, demotion of packets becomes possible.

5. [3]では、測定ベースの入場制御を使用して、凝集領域(つまり、Diffserv領域)の内部の分岐点ルーター(つまり、Diffserv領域)が予約に関する状態情報を減らし続けるスキームが導入されました。このスキームでは、パケットは、詳細なIntServ状態の代わりに使用されるスケジューリング情報を備えた、より知識のあるIntServエッジルーターによってタグ付けされます。Diffserv領域と分岐点ルーターがそのフレームワークに従って設計されている場合、パケットの降格が可能になります。

6.2 Multicast SLSs and Heterogeneous Trees
6.2 マルチキャストSLSと不均一な木

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を均質または均一なSLと呼びます。ただし、マルチキャスト環境では、Diffserv領域に認められている単一のパケットは、多くの出力ルーターに複製され、転送されるため、地域の多くの経路に沿ってリソースを消費する場合があります。あるいは、単一のパスに沿って流れる場合があります。この状況は、上記の可能性によってさらに複雑になり、図2に示されています。この状況では、マルチキャストパケットがいくつかのブランチに沿って最善の努力として扱われる可能性があり、他のブランチに沿っていくつかのより高いQoS治療を受けています。ここでは、不均一な流れのニーズを満たし、プロバイダーを満たすことができる意味のあるSLSの仕様が挑戦的である可能性が高いことに注意してください。

Dynamic SLSs may help to address these issues. For example, by using RSVP to signal the resources that are required along different branches of a multicast tree, it may be possible to more closely approach the goal of allocating appropriate resources only where they are needed rather than overprovisioning or underprovisioning along certain branches of a tree. This is essentially the approach described in [15].

動的なSLSSは、これらの問題に対処するのに役立つ場合があります。たとえば、RSVPを使用して、マルチキャストツリーのさまざまなブランチに沿って必要なリソースを信号することにより、特定のブランチに沿って過剰に導入または不足しているのではなく、必要な場合にのみ、適切なリソースを割り当てるという目標をより密接にアプローチすることが可能かもしれません。木。これは基本的に[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領域と非ディフェルサーブ領域の両方でリソースを取得することを提案しています。したがって、すべてのRSVPセキュリティに関する考慮事項が適用されます[9]。さらに、ネットワーク管理者は、信頼されていない顧客とのインターフェースで安全なポリサーを構成することにより、ネットワークリソースを保護することが期待されています。

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を設定する)または間接的に(中間マーキングルーターに分類するトラフィックを特定のものに送信するかどうかに関係なく、特定のサービスレベルでDiffServネットワーク領域の交渉能力を超えようとする場合があります。DSCP)。

In either case, it will generally be necessary for each Diffserv network region to protect its resources by policing to assure that customers do not use more resources than they are entitled to, at each service level (DSCP). The exception to this rule is when the host is known to be trusted, e.g., a server that is under the control of the network administrators. If an untrusted sending host does not perform DSCP marking, the boundary router (or trusted intermediate routers) must provide MF classification, mark and police. If an untrusted sending host does perform marking, the boundary router needs only to provide BA classification and to police to ensure that the customer is not exceeding the aggregate capacity negotiated for the service level.

どちらの場合でも、各サービスレベル(DSCP)で、顧客が資格があるよりも多くのリソースを使用しないことを保証するために、ポリシングによってリソースを保護する必要があります。このルールの例外は、ホストが信頼されていることが知られている場合です。たとえば、ネットワーク管理者の制御下にあるサーバーです。信頼できない送信ホストが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パラメーターに準拠するように自分のトラフィックを形成およびポリシングするタスクに焦点を当てています。

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.

著者は、このドキュメントの以前のバージョンの改善につながったコメントを以下の個人に感謝します:David Oran、Andy Veitch、Curtis Villamizer、Walter Weiss、Francois Le Faucheur、Russell White。

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] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル(RSVP)バージョン1機能仕様」、RFC 2205、1997年9月。

[2] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F. and M. Speer, "SBM (Subnet Bandwidth Manager): A Protocol For RSVP-based Admission Control Over IEEE 802 Style Networks", RFC 2814, May 2000.

[2] Yavatkar、R.、Hoffman、D.、Bernet、Y.、Baker、F。and M. Speer、 "SBM(Subnet Bandwidth Manager):IEEE 802スタイルネットワークのRSVPベースの入場制御のプロトコル、RFC 2814、2000年5月。

[3] Berson, S. and R. Vincent, "Aggregation of Internet Integrated Services State", Work in Progress.

[3] Berson、S。およびR. Vincent、「インターネット統合サービス状態の集約」、進行中の作業。

[4] Nichols, K., Jacobson, V. and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", RFC 2638, July 1999.

[4] Nichols、K.、Jacobson、V。、およびL. Zhang、「インターネット用の2ビット差別化されたサービスアーキテクチャ」、RFC 2638、1999年7月。

[5] Seaman, M., Smith, A., Crawley, E. and J. Wroclawski, "Integrated Service Mappings on IEEE 802 Networks", RFC 2815, May 2000.

[5] Seaman、M.、Smith、A.、Crawley、E。、およびJ. Wroclawski、「IEEE 802ネットワークの統合サービスマッピング」、RFC 2815、2000年5月。

[6] Guerin, R., Blake, S. and Herzog, S., "Aggregating RSVP based QoS Requests", Work in Progress.

[6] Guerin、R.、Blake、S。、およびHerzog、S。、「RSVPベースのQoSリクエストの集約」、進行中の作業。

[7] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.

[7] Nichols、K.、Blake、S.、Baker、F。and D. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド(DSフィールド)の定義」、RFC 2474、1998年12月。

[8] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.

[8] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスのアーキテクチャ」、RFC 2475、1998年12月。

[9] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.

[9] Baker、F.、Lindell、B。and M. Talwar、「RSVP暗号認証」、RFC 2747、2000年1月。

[10] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.

[10] Braden、R.、Clark、D。、およびS. Shenker、「インターネットアーキテクチャにおける統合サービス:概要」、RFC 1633、1994年6月。

[11] Garrett, M. and M. Borden, "Interoperation of Controlled-Load Service and Guaranteed Service with ATM", RFC 2381, August 1998.

[11] Garrett、M。and M. Borden、「ATMとの制御ロードサービスの相互操作と保証サービス」、RFC 2381、1998年8月。

[12] Weiss, Walter, Private communication, November 1998.

[12] ワイス、ウォルター、プライベートコミュニケーション、1998年11月。

[13] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.

[13] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。

[14] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000.

[14] Bernet、Y。、「RSVP DCLASSオブジェクトの形式」、RFC 2996、2000年11月。

[15] Baker, F., Iturralde, C., le Faucheur, F., and Davie, B. "RSVP Reservation Aggregation", Work in Progress.

[15] Baker、F.、Iturralde、C.、Le Faucheur、F。、およびDavie、B。「RSVP予約集約」、進行中の作業。

[16] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.

[16] Terzis、A.、Krawczyk、J.、Wroclawski、J。、およびL. Zhang、「RSVP Operation over IP Tunnels」、RFC 2746、2000年1月。

[17] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, D. and A. Sastry, "COPS Usage for RSVP", RFC 2749, January 2000.

[17] Boyle、J.、Cohen、R.、Durham、D.、Herzog、S.、Rajan、D.、A。Sastry、「RSVPのCOPS使用」、RFC 2749、2000年1月。

[18] Bernet, Y., "A Framework for Differentiated Services", Work in Progress.

[18] Bernet、Y。、「差別化されたサービスのフレームワーク」、進行中の作業。

[19] Jacobson Van, "Differentiated Services Architecture", talk in the Int-Serv WG at the Munich IETF, August 1997.

[19] 「差別化されたサービスアーキテクチャ」、ジェイコブソンヴァンは、1997年8月、ミュンヘンIETFの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] Jacobson、V.、Nichols K.およびL. Zhang、「インターネット用の2ビット差別化されたサービスアーキテクチャ」、RFC 2638、1999年6月。

[21] First Internet2 bandwidth broker operability event http://www.merit.edu/internet/working.groups/i2-qbone-bb/ inter-op/index.htm

[21] First Internet2帯域幅のブローカー操作性イベントhttp://www.merit.edu/internet/working.groups/i2-qbone-bb/ inter-op/index.htm

10. Authors' Addresses
10. 著者のアドレス

Yoram Bernet Microsoft One Microsoft Way Redmond, WA 98052

Yoram Bernet Microsoft One Microsoft Way Redmond、WA 98052

   Phone: +1 425-936-9568
   EMail: yoramb@microsoft.com
        

Raj Yavatkar Intel Corporation JF3-206 2111 NE 25th. Avenue Hillsboro, OR 97124

Raj Yavatkar Intel Corporation JF3-206 2111 NE 25th。アベニューヒルズボロ、または97124

   Phone: +1 503-264-9077
   EMail: raj.yavatkar@intel.com
        

Peter Ford Microsoft One Microsoft Way Redmond, WA 98052

ピーター・フォード・マイクロソフト・ワン・マイクロソフト・ウェイ・レドモンド、ワシントン州98052

   Phone: +1 425-703-2032
   EMail: peterf@microsoft.com
        

Fred Baker Cisco Systems 519 Lado Drive Santa Barbara, CA 93111

フレッドベイカーシスコシステム519ラドドライブサンタバーバラ、カリフォルニア93111

   Phone: +1 408-526-4257
   EMail: fred@cisco.com
        

Lixia Zhang UCLA 4531G Boelter Hall Los Angeles, CA 90095

Lixia Zhang UCLA 4531G Boelter Hall Los Angeles、CA 90095

Phone: +1 310-825-2695 EMail: lixia@cs.ucla.edu Michael Speer Sun Microsystems 901 San Antonio Road, UMPK15-215 Palo Alto, CA 94303

電話:1 310-825-2695メール:lixia@cs.ucla.edu Michael Speer Sun Microsystems 901 San Antonio Road、UMPK15-215 Palo Alto、CA 94303

   Phone: +1 650-786-6368
   EMail: speer@Eng.Sun.COM
        

Bob Braden USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292-6695

Bob Braden USC/Information Sciences Institute 4676 Admiralty Way Marina Del Rey、CA 90292-6695

   Phone: +1 310-822-1511
   EMail: braden@isi.edu
        

Bruce Davie Cisco Systems 250 Apollo Drive Chelmsford, MA 01824

ブルースデイビーシスコシステム250アポロドライブチェルムスフォード、マサチューセッツ州01824

   Phone: +1 978-244-8000
   EMail: bsd@cisco.com
        

Eyal Felstaine SANRAD Inc. 24 Raul Wallenberg st Tel Aviv, Israel

Eyal Felstaine Sanrad Inc. 24 Raul Wallenberg St Tel Aviv、イスラエル

   Phone: +972-50-747672
   Email: eyal@sanrad.com
        

John Wroclawski MIT Laboratory for Computer Science 545 Technology Sq. Cambridge, MA 02139

コンピューターサイエンスのためのJohn Wroclawski MIT Laboratory 545 Technology Sq。ケンブリッジ、マサチューセッツ州02139

   Phone: +1 617-253-7885
   EMail: jtw@lcs.mit.edu
        
11. 完全な著作権声明

Copyright (C) The Internet Society (2000). All Rights Reserved.

Copyright(c)The Internet Society(2000)。無断転載を禁じます。

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。