Network Working Group G. Huston
Request for Comments: 2990 Telstra
Category: Informational November 2000
Next Steps for the IP QoS Architecture
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
While there has been significant progress in the definition of Quality of Service (QoS) architectures for internet networks, there are a number of aspects of QoS that appear to need further elaboration as they relate to translating a set of tools into a coherent platform for end-to-end service delivery. This document highlights the outstanding architectural issues relating to the deployment and use of QoS mechanisms within internet networks, noting those areas where further standards work may assist with the deployment of QoS internets.
インターネット・ネットワークのサービス品質（QoS）アーキテクチャの定義で重要な進展があったものの、彼らは最後のための一貫したプラットフォームにツールのセットを翻訳に関連して、さらに説明が必要なように見えるのQoSの側面の数があります-to-エンドサービスの提供。この文書では、さらに基準が動作し、それらの領域は、QoSのインターネットの展開を支援することを指摘、インターネット網内のQoSメカニズムの展開と使用に関する優れた建築の問題を強調しています。
This document is the outcome of a collaborative exercise on the part of the Internet Architecture Board.
このドキュメントはインターネットアーキテクチャ委員会の一部に関する共同運動の成果です。
Table of Contents
目次
1. Introduction ........................................... 2
2. State and Stateless QoS ................................ 4
3. Next Steps for QoS Architectures ....................... 6
3.1 QoS-Enabled Applications ........................... 7
3.2 The Service Environment ............................ 9
3.3 QoS Discovery ...................................... 10
3.4 QoS Routing and Resource Management ................ 10
3.5 TCP and QoS ........................................ 11
3.6 Per-Flow States and Per-Packet classifiers ......... 13
3.7 The Service Set .................................... 14
3.8 Measuring Service Delivery ......................... 14
3.9 QoS Accounting ..................................... 15
3.10 QoS Deployment Diversity .......................... 16
3.11 QoS Inter-Domain signaling ........................ 17
3.12 QoS Deployment Logistics .......................... 17
4. The objective of the QoS architecture .................. 18
5. Towards an end-to-end QoS architecture ................. 19
6. Conclusions ............................................ 21
7. Security Considerations ................................ 21
8. References ............................................. 22
9. Acknowledgments ........................................ 23
10. Author's Address ....................................... 23
11. Full Copyright Statement ............................... 24
The default service offering associated with the Internet is characterized as a best-effort variable service response. Within this service profile the network makes no attempt to actively differentiate its service response between the traffic streams generated by concurrent users of the network. As the load generated by the active traffic flows within the network varies, the network's best effort service response will also vary.
インターネットに関連したデフォルトのサービス提供は、ベストエフォート型の変数サービス応答として特徴付けられます。このサービスプロファイル内のネットワークを積極的にネットワークの同時ユーザーによって生成されたトラフィックストリーム間でそのサービス応答を区別を試みません。アクティブなトラフィックによって発生する負荷は、ネットワークが変動内を流れるように、ネットワークのベストエフォート型サービスの応答も異なります。
The objective of various Internet Quality of Service (QoS) efforts is to augment this base service with a number of selectable service responses. These service responses may be distinguished from the best-effort service by some form of superior service level, or they may be distinguished by providing a predictable service response which is unaffected by external conditions such as the number of concurrent traffic flows, or their generated traffic load.
様々なサービスのインターネット品質（QoS）の取り組みの目的は、選択可能なサービス応答の数と、このベースのサービスを強化することです。これらのサービスの応答は、優れたサービスレベルの何らかの形でのベストエフォート型のサービスと区別することができる、またはそれらは、同時トラフィックフローの数などの外部条件に影響されない、予測可能なサービス応答を提供することによって区別することができる、またはその生成されたトラフィック負荷。
Any network service response is an outcome of the resources available to service a load, and the level of the load itself. To offer such distinguished services there is not only a requirement to provide a differentiated service response within the network, there is also a requirement to control the service-qualified load admitted into the network, so that the resources allocated by the network to support a particular service response are capable of providing that response for the imposed load. This combination of admission control agents and service management elements can be summarized as "rules plus behaviors". To use the terminology of the Differentiated Service architecture [4], this admission control function is undertaken by a traffic conditioner (an entity which performs traffic conditioning functions and which may contain meters, markers, droppers, and shapers), where the actions of the conditioner are governed by explicit or implicit admission control agents.
任意のネットワークサービス応答は、負荷をサービスするために利用可能なリソース、および負荷自体のレベルの結果です。ネットワークによって割り当てられたリソースが特定のをサポートするために、ように、ネットワーク内で差別化されたサービスの応答を提供するための唯一の要件はありません、このような著名なサービスを提供するために、ネットワークに入院サービス資格の負荷を制御するための要件もあり、サービス応答は、負荷のためにその応答を提供することが可能です。入場制御剤およびサービス管理要素のこの組み合わせは、「ルールプラス行動」のように要約することができます。差別化サービスアーキテクチャの用語を使用する[4]、このアドミッション制御機能は、トラフィックコンディショナのアクション（トラフィック調整機能を実行し、メーター、マーカー、点滴、及びシェーパを含むことができるエンティティ）によって行われますコンディショナーは、明示的または暗黙的なアドミッション制御エージェントによって管理されています。
As a general observation of QoS architectures, the service load control aspect of QoS is perhaps the most troubling component of the architecture. While there are a wide array of well understood service response mechanisms that are available to IP networks, matching a set of such mechanisms within a controlled environment to respond to a set of service loads to achieve a completely consistent service response remains an area of weakness within existing IP QoS architectures. The control elements span a number of generic requirements, including end-to-end application signaling, end-to-network service signaling and resource management signaling to allow policy-based control of network resources. This control may also span a particular scope, and use 'edge to edge' signaling, intended to support particular service responses within a defined network scope.
QoSアーキテクチャの一般的な観察として、のQoSのサービス負荷制御態様は、おそらくアーキテクチャの最も厄介な成分です。 IPネットワークに利用可能である十分に理解サービス応答メカニズムの広い配列があるが、完全に一致するサービス応答を達成するために、サービス負荷のセットに応答するように制御された環境内でそのようなメカニズムのセットに一致する弱さの領域内のまま既存のIPのQoSアーキテクチャ。制御要素は、エンドツーエンドのアプリケーションシグナリング、エンドツーネットワークサービスシグナリングおよびネットワーク・リソースのポリシーベースの制御を可能にするためのシグナリングリソース管理を含む一般的な要件の数に及びます。この制御は、特定の範囲に及ぶ、と定義されたネットワーク範囲内の特定のサービス応答をサポートすることを意図し、シグナリングを「エッジにエッジ」を使用することができます。
One way of implementing this control of imposed load to match the level of available resources is through an application-driven process of service level negotiation (also known as application signaled QoS). Here, the application first signals its service requirements to the network, and the network responds to this request. The application will proceed if the network has indicated that it is able to carry the additional load at the requested service level. If the network indicates that it cannot accommodate the service requirements the application may proceed in any case, on the basis that the network will service the application's data on a best effort basis. This negotiation between the application and the network can take the form of explicit negotiation and commitment, where there is a single negotiation phase, followed by a commitment to the service level on the part of the network. This application-signaled approach can be used within the Integrated Services architecture, where the application frames its service request within the resource reservation protocol (RSVP), and then passes this request into the network. The network can either respond positively in terms of its agreement to commit to this service profile, or it can reject the request. If the network commits to the request with a resource reservation, the application can then pass traffic into the network with the expectation that as long as the traffic remains within the traffic load profile that was originally associated with the request, the network will meet the requested service levels. There is no requirement for the application to periodically reconfirm the service reservation itself, as the interaction between RSVP and the network constantly refreshes the reservation while it remains active. The reservation remains in force until the application explicitly requests termination of the reservation, or the network signals to the application that it is unable to continue with a service commitment to the reservation [3]. There are variations to this model, including an aggregation model where a proxy agent can fold a number of application-signaled reservations into a common aggregate reservation along a common sub-path, and a matching deaggregator can reestablish the collection of individual resource reservations upon leaving the aggregate region [5]. The essential feature of this Integrated Services model is the "all or nothing" nature of the model. Either the network commits to the reservation, in which case the requestor does not have to subsequently monitor the network's level of response to the service, or the network indicates that it cannot meet the resource reservation.
利用可能なリソースのレベルに一致するように負荷のこの制御を実現する一つの方法は、サービス・レベル・ネゴシエーションのアプリケーション駆動のプロセス（アプリケーションがQoSを合図としても知られる）によるものです。ここでは、アプリケーションが最初にネットワークへのサービス要件に信号を送り、そしてネットワークは、この要求に応答します。ネットワークは、要求されたサービスレベルで追加の負荷を運ぶことができるであることが示された場合、アプリケーションは続行されます。ネットワークは、アプリケーションがネットワークはベストエフォートベースでアプリケーションのデータをサービスすることに基づいて、どのような場合には進むことができ、サービス要件に対応できないことを示している場合。アプリケーションとネットワークの間のこの交渉は、ネットワークの一部のサービスレベルへのコミットメントが続く単一ネゴシエーションフェーズがあり、明示的な交渉とコミットメントの形を取ることができます。このアプリケーションシグナリングアプローチは、アプリケーションがリソース予約プロトコル（RSVP）内にそのサービス要求フレーム、その後ネットワークにこの要求を渡すサービス統合アーキテクチャ内で使用することができます。ネットワークはどちらか、このサービスプロファイルにコミットするために、その契約書の条項に積極的に対応することができ、またはそれは要求を拒否することができます。ネットワークは、リソース予約で要求にコミットしている場合、アプリケーションは、トラフィックは、もともと要求に関連付けられたトラフィック負荷プロファイル内にとどまる限り、ネットワークが要求を満たすことを期待してネットワークにトラフィックを渡すことができますサービスレベル。それはアクティブなままRSVPとネットワーク間の相互作用は常に予約をリフレッシュするよう、定期的にサービス予約自体を再確認するためのアプリケーションのための要件は、ありません。アプリケーションは、明示的に[3]予約へのサービスのコミットメントを継続することができませんアプリケーションに予約の終了、またはネットワーク信号を要求するまでの予約は力に残っています。そこプロキシエージェントは、共通のサブ経路に沿って共通の集計予約にアプリケーションシグナリング予約数を折り畳むことができ、凝集モデルを含むこのモデルのバリエーションは、であり、マッチングデアグリゲータは、脱離時に個々のリソース予約のコレクションを再確立することができ凝集領域[5]。このサービス統合型モデルの本質的な特徴は、モデルの「オール・オア・ナッシング」性質です。どちらのネットワークは、要求者が、その後のサービスへの応答のネットワークのレベルを監視する必要がない場合には予約にコミット、またはネットワークは、リソース予約を満たすことができないことを示しています。
An alternative approach to load control is to decouple the network load control function from the application. This is the basis of the Differentiated Services architecture. Here, a network implements a load control function as part of the function of admission of traffic into the network, admitting no more traffic within each service category as there are assumed to be resources in the network to deliver the intended service response. Necessarily there is some element of imprecision in this function given that traffic may take an arbitrary path through the network. In terms of the interaction between the network and the application, this takes the form of a service request without prior negotiation, where the application requests a particular service response by simply marking each packet with a code to indicate the desired service. Architecturally, this approach decouples the end systems and the network, allowing a network to implement an active admission function in order to moderate the workload that is placed upon the network's resources without specific reference to individual resource requests from end systems. While this decoupling of control allows a network's operator greater ability to manage its resources and a greater ability to ensure the integrity of its services, there is a greater potential level of imprecision in attempting to match applications' service requirements to the network's service capabilities.
負荷制御への別のアプローチは、アプリケーションからネットワーク負荷制御機能を分離することです。これは、差別化サービスアーキテクチャの基礎です。ここで、ネットワークは、意図したサービス応答を提供するために、ネットワーク内のリソースがあると仮定され、各サービスカテゴリ内には多くのトラフィックを認めていない、ネットワークへのトラフィックの入場の機能の一部として、負荷制御機能を実装しています。必ずしもトラフィックがネットワークを介して任意の経路をとることができることを考えると、この関数の不正確のいくつかの要素があります。ネットワークとアプリケーションの間の相互作用の点で、これは、アプリケーションが単に所望のサービスを示すコードで各パケットをマーキングすることによって、特定サービス応答を要求する前に交渉することなく、サービス要求の形態をとります。アーキテクチャ上、このアプローチは、ネットワークがエンドシステムから個々のリソース要求を特に参照することなく、ネットワークのリソース上に配置されている作業負荷を緩和するために、アクティブ入場機能を実現することができ、エンド・システムおよびネットワークを切り離します。この制御のデカップリングは、ネットワークのオペレータにそのリソースを管理するためのより大きな能力とそのサービスの整合性を確保するためのより大きな能力を可能にしながら、ネットワークのサービス機能へのアプリケーションのサービス要件に合致するようにしようとの不正確の大きな潜在的なレベルがあります。
These two approaches to load control can be characterized as state-based and stateless approaches respectively.
コントロールをロードするために、これらの2つのアプローチは、それぞれ、状態ベースとステートレスアプローチとして特徴付けることができます。
The architecture of the Integrated Services model equates the cumulative sum of honored service requests to the current reserved resource levels of the network. In order for a resource reservation to be honored by the network, the network must maintain some form of remembered state to describe the resources that have been reserved, and the network path over which the reserved service will operate. This is to ensure integrity of the reservation. In addition, each active network element within the network path must maintain a local state that allows incoming IP packets to be correctly classified into a reservation class. This classification allows the packet to be placed into a packet flow context that is associated with an appropriate service response consistent with the original end-to-end service reservation. This local state also extends to the function of metering packets for conformance on a flow-by-flow basis, and the additional overheads associated with maintenance of the state of each of these meters.
サービス統合型モデルのアーキテクチャは、ネットワークの現在の予約リソースレベルに光栄サービス要求の累積合計を相当します。ネットワークによって表彰されるリソース予約のためのためには、ネットワークは、予約のサービスが動作する上で予約されたリソース、およびネットワークパスを記述するために思い出した状態のいくつかのフォームを維持しなければなりません。これは、予約の整合性を確保することです。また、ネットワーク経路内の各アクティブなネットワーク要素は、着信IPパケットが正しく予約クラスに分類されることを可能にするローカル状態を維持しなければなりません。この分類は、パケットが、元のエンドツーエンドのサービスの予約と一致する適切なサービス応答に関連付けられたパケットフローコンテキストに配置されることを可能にします。この局所的な状態も計量流によってフローに基づいて適合性のためのパケット、及びこれらの計器のそれぞれの状態の維持に関連する追加のオーバーヘッドの機能にまで及びます。
In the second approach, that of a Differentiated Services model, the packet is marked with a code to trigger the appropriate service response from the network elements that handles the packet, so that there is no strict requirement to install a per-reservation state on these network elements. Also, the end application or the service requestor is not required to provide the network with advance notice relating to the destination of the traffic, nor any indication of the intended traffic profile or the associated service profile. In the absence of such information any form of per-application or per-path resource reservation is not feasible. In this model there is no maintained per-flow state within the network.
これらに当たり、予約状態をインストールするための厳密な要件が存在しないように、第2のアプローチでは、差別化サービスモデルとは、パケットは、パケットを処理するネットワーク要素から適切なサービス応答を誘発するためのコードでマークされていますネットワーク要素。また、エンド・アプリケーションまたはサービス・リクエスタは、トラフィックの宛先に関連する事前通知を使用してネットワーク、また意図したトラフィックプロファイルまたは関連するサービスプロファイルの兆候を提供するために必要とされません。そのような情報がない場合に、アプリケーション単位またはパスリソース予約の任意の形式は不可能です。このモデルではないネットワーク内のフローごとの状態が維持されません。
The state-based Integrated Services architectural model admits the potential to support greater level of accuracy, and a finer level of granularity on the part of the network to respond to service requests. Each individual application's service request can be used to generate a reservation state within the network that is intended to prevent the resources associated with the reservation to be reassigned or otherwise preempted to service other reservations or to service best effort traffic loads. The state-based model is intended to be exclusionary, where other traffic is displaced in order to meet the reservation's service targets.
状態ベースのサービス統合型アーキテクチャモデルは、サービス要求に応答するネットワークの一部で、より高い精度のレベル、および粒度の細かいレベルをサポートする可能性を認めています。個々のアプリケーションのサービス要求を再割り当てする予約に関連したリソースを防止するためのものか、そうでなければ他の予約サービスを提供したり、ベストエフォートトラフィック負荷をサービスするように先取りされているネットワーク内の予約状態を生成するために使用することができます。他のトラフィックは、予約のサービス目標を達成するために変位した状態ベースのモデルは、排他的であることを意図しています。
As noted in RFC2208 [2], there are several areas of concern about the deployment of this form of service architecture. With regard to concerns of per-flow service scalability, the resource requirements (computational processing and memory consumption) for running per-flow resource reservations on routers increase in direct proportion to the number of separate reservations that need to be accommodated. By the same token, router forwarding performance may be impacted adversely by the packet-classification and scheduling mechanisms intended to provide differentiated services for these resource-reserved flows. This service architecture also poses some challenges to the queuing mechanisms, where there is the requirement to allocate absolute levels of egress bandwidth to individual flows, while still supporting an unmanaged low priority best effort traffic class.
RFC2208に述べたように、[2]、サービスアーキテクチャのこの形式の展開についての懸念のいくつかの領域があります。フローごとのサービスのスケーラビリティの懸念に関しては、ルータ上でフローごとのリソース予約を実行するためのリソース要件（演算処理とメモリ消費量）が収容される必要がある別々の予約数に直接比例して増加します。同様に、ルータの転送パフォーマンスは、これらのリソース予約フローの差別化サービスを提供することを目的とし、パケット分類およびスケジューリングメカニズムによって悪影響を受けることができます。まだ管理されていない優先度の低いベストエフォートトラフィッククラスをサポートしながら、このサービスのアーキテクチャは、個々のフローへの出力帯域幅の絶対レベルを割り当てる必要があるキューイングメカニズム、にいくつかの課題を提起します。
The stateless approach to service management is more approximate in the nature of its outcomes. Here there is no explicit negotiation between the application's signaling of the service request and the network's capability to deliver a particular service response. If the network is incapable of meeting the service request, then the request simply will not be honored. In such a situation there is no requirement for the network to inform the application that the request cannot be honored, and it is left to the application to determine if the service has not been delivered. The major attribute of this approach is that it can possess excellent scaling properties from the perspective of the network. If the network is capable of supporting a limited number of discrete service responses, and the routers uses per-packet marking to trigger the service response, then the processor and memory requirements in each router do not increase in proportion to the level of traffic passed through the router. Of course this approach does introduce some degree of compromise in that the service response is more approximate as seen by the end client, and scaling the number of clients and applications in such an environment may not necessarily result in a highly accurate service response to every client's application.
サービス管理へのステートレスなアプローチは、その成果の自然の中で、より近似しています。ここでは、サービス要求のアプリケーションのシグナリングと特定のサービス応答を提供するネットワークの能力との間に明示的な交渉はありません。ネットワークは、サービス要求を満たすことができない場合、その要求は単純に表彰されることはありません。このような状況では、要求が受け入れられないことができるアプリケーションを通知するネットワークのための必要がない、そしてサービスが配信されていないかどうかを判断するためにアプリケーションに任されています。このアプローチの主要な属性は、ネットワークの観点から優れたスケーリング特性を有することができるということです。ネットワークは、個別のサービス応答の限られた数をサポートすることが可能である、とルータがサービス応答をトリガするためにマーキングパケットごとの使用している場合、各ルータのプロセッサとメモリの要件が通過したトラフィックのレベルに比例して増加しませんルータ。もちろん、このアプローチは、サービス応答は、エンドクライアントで見られるように、より近似しており、このような環境でクライアントとアプリケーションの数をスケーリングすることは、必ずしもすべてのクライアントのに高精度なサービス応答が得られないことがあり、その中で妥協のいくつかの学位を紹介しません応用。
It is not intended to describe these service architectures in further detail within this document. The reader is referred to RFC1633 [3] for an overview of the Integrated Services Architecture (IntServ) and RFC2475 [4] for an overview of the Differentiated Services architecture (DiffServ).
この文書の中でさらに詳細にこれらのサービスのアーキテクチャを説明することを意図するものではありません。読者は、差別化サービスアーキテクチャ（のDiffServ）の概要については、[4] [3]統合サービスアーキテクチャ（のIntServ）とRFC2475の概要については、RFC1633と呼ばれます。
These two approaches are the endpoints of what can be seen as a continuum of control models, where the fine-grained precision of the per application invocation reservation model can be aggregated into larger, more general and potentially more approximate aggregate reservation states, and the end-to-end element-by-element reservation control can be progressively approximated by treating a collection of subnetworks or an entire transit network as an aggregate service element. There are a number of work in progress efforts which are directed towards these aggregated control models, including aggregation of RSVP [5], the RSVP DCLASS Object [6] to allow Differentiated Services Code Points (DSCPs) to be carried in RSVP message objects, and operation of Integrated Services over Differentiated Services networks [7].
これらの2つのアプローチは、制御モデルの連続として見ることができるもののエンドポイント、アプリケーションごとの呼び出し予約モデルは、より大きな、より一般的かつ潜在的近似集計予約状態、および終了に集約することができるのきめ細かな精度であります-to-エンド要素ごとの予約制御を徐々に集約サービス要素としてサブネットワークの集合全体トランジットネットワークを処理することによって近似することができます。 RSVPの集合を含む、これらの凝集制御モデルに向けられる進行努力における作業の数がある[5]、差別化サービスコードポイント（DSCPを）は、RSVPメッセージオブジェクトで運ばれることを可能にするRSVP DCLASSオブジェクト[6]そして、差別化サービスネットワーク上で統合サービスの動作[7]。
Both the Integrated Services architecture and the Differentiated Services architecture have some critical elements in terms of their current definition which appear to be acting as deterrents to widespread deployment. Some of these issues will probably be addressed within the efforts to introduce aggregated control and response models into these QoS architectures, while others may require further refinement through standards-related activities.
どちらのサービス統合型アーキテクチャと差別化サービスアーキテクチャは、広範囲の展開への抑止力として機能しているように見える彼らの現在の定義の面でいくつかの重要な要素を持っています。他の人が標準規格に関連する活動を通じて、さらなる改良が必要になる場合がありながら、これらの問題のいくつかは、おそらく、これらのQoSアーキテクチャに集約された制御および応答モデルを導入するための取り組みの中に対処されることになります。
One of the basic areas of uncertainty with QoS architectures is whether QoS is a per-application service, whether QoS is a transport-layer option, or both. Per-application services have obvious implications of extending the QoS architecture into some form of Application Protocol Interface (API), so that applications could negotiate a QoS response from the network and alter their behavior according to the outcome of the response. Examples of this approach include GQOS [8], and RAPI [9]. As a transport layer option, it could be envisaged that any application could have its traffic carried by some form of QoS-enabled network services by changing the host configuration, or by changing the configuration at some other network control point, without making any explicit changes to the application itself. The strength of the transport layer approach is that there is no requirement to substantially alter application behavior, as the application is itself unaware of the administratively assigned QoS. The weakness of this approach is that the application is unable to communicate what may be useful information to the network or to the policy systems that are managing the network's service responses. In the absence of such information the network may provide a service response that is far superior than the application's true requirements, or far inferior than what is required for the application to function correctly. An additional weakness of a transport level approach refers to those class of applications that can adapt their traffic profile to meet the available resources within the network. As a transport level mechanism, such network availability information as may be available to the transport level is not passed back to the application.
QoSのアーキテクチャと不確実性の基本的な分野の一つは、QoSは、トランスポート層のオプション、またはその両方であるかを、QoSがアプリケーションごとのサービスであるかどうかです。アプリケーションがネットワークからQoS応答を交渉し、応答の結果に応じて自分の行動を変えることができるように、アプリケーションごとのサービスは、アプリケーションプロトコルインタフェース（API）のいくつかのフォームにQoSアーキテクチャを拡張する明白な意味を持ちます。このアプローチの例は、GQOS [8]、およびRAPIを含む[9]。トランスポート層のオプションとして、どのアプリケーションがそのトラフィックは明示的な変更を加えることなく、ホストの設定を変更することによって、または他のネットワーク制御の時点で、設定を変更することにより、QoS対応のネットワークサービスのいくつかのフォームによって運ばれていることが考えられますアプリケーション自体へ。トランスポート層アプローチの強みは、アプリケーションが管理割り当てられたQoSの自身が気づかないように、実質的にアプリケーションの動作を変更する必要がないことです。このアプローチの弱点は、アプリケーションがネットワークまたはネットワークのサービス応答を管理しているポリシー・システムに有用な情報であるかもしれないものに通信することができないということです。そのような情報がない場合には、ネットワーク、アプリケーションの真の要件よりもはるかに優れた、またはアプリケーションが正しく機能するために必要なものよりもはるかに劣っているサービス応答を提供することができます。トランスポート・レベルのアプローチの追加の弱点は、ネットワーク内で利用可能なリソースを満たすために彼らのトラフィックプロファイルを適応させることができ、アプリケーションのこれらのクラスを指します。トランスポート・レベル機構として、トランスポートレベルに利用可能とすることができるようなネットワーク利用可能性情報は、バックアプリケーションに渡されません。
In the case of the Integrated Services architecture, this transport layer approach does not appear to be an available option, as the application does require some alteration to function correctly in this environment. The application must be able to provide to the service reservation module a profile of its anticipated traffic, or in other words the application must be able to predict its traffic load. In addition, the application must be able to share the reservation state with the network, so that if the network state fails, the application can be informed of the failure. The more general observation is that a network can only formulate an accurate response to an application's requirements if the application is willing to offer precise statement of its traffic profile, and is willing to be policed in order to have its traffic fit within this profile.
アプリケーションがこの環境で正しく機能するためにいくつかの変更を必要としてサービス統合型アーキテクチャの場合には、このトランスポート層アプローチは、可能な選択肢であることが表示されません。アプリケーションは、サービス予約モジュールにその予想されるトラフィックのプロファイルを提供することができなければならない、つまりアプリケーションがそのトラフィック負荷を予測することができなければなりません。また、アプリケーションは、ネットワークの状態が失敗した場合、アプリケーションは失敗を知ることができるように、ネットワークと予約状況を共有できなければなりません。より一般的な観察は、アプリケーションがそのトラフィックプロファイルの正確な声明を提供する意思がある場合は、ネットワークが唯一のアプリケーションの要件に的確な対応を策定できることであり、このプロファイル内のトラフィックのフィット感を持たせるためにポリシングすることに喜んでいます。
In the case of the Differentiated Services architecture there is no explicit provision for the application to communicate with the network regarding service levels. This does allow the use of a transport level option within the end system that does not require explicit alteration of the application to mark its generated traffic with one of the available Differentiated Services service profiles. However, whether the application is aware of such service profiles or not, there is no level of service assurance to the application in such a model. If the Differentiated Services boundary traffic conditioners enter a load shedding state, the application is not signaled of this condition, and is not explicitly aware that the requested service response is not being provided by the network. If the network itself changes state and is unable to meet the cumulative traffic loads admitted by the ingress traffic conditioners, neither the ingress traffic conditioners, nor the client applications, are informed of this failure to maintain the associated service quality. While there is no explicit need to alter application behavior in this architecture, as the basic DiffServ mechanism is one that is managed within the network itself, the consequence is that an application may not be aware whether a particular service state is being delivered to the application.
差別化サービスアーキテクチャの場合、アプリケーションは、サービスレベルに関するネットワークと通信するための明示的な規定は存在しません。これは、利用可能な差別化サービスサービスプロファイルの一つで、その生成されたトラフィックをマークするために、アプリケーションの明示的な変更を必要としないエンドシステム内のトランスポート・レベルのオプションを使用することができません。しかし、アプリケーションがこのようなサービスプロファイルかどうかを認識しているかどうか、そのようなモデルで、アプリケーションへのサービス保証のないレベルではありません。差別化サービス境界トラフィックコンディショナーは、状態を負荷制限を入力した場合、アプリケーションはこの条件の合図ではない、と要求されたサービスの応答がネットワークによって提供されていないことを明確に認識していないです。ネットワーク自体の状態が変化し、入力トラフィックコンディショナーによって認め累積トラフィック負荷、どちらの入力トラフィックコンディショナー、またクライアントアプリケーションを満たすことができない場合は、関連するサービスの品質を維持するために、この障害が通知されます。このアーキテクチャでは、アプリケーションの動作を変更する明示的な必要はありませんが、基本的なDiffServのメカニズムは、ネットワーク自体内で管理されているものであるとして、その結果は、アプリケーションが特定のサービスの状態がアプリケーションに配信されているかどうかを認識していなくてもよいということです。
There is potential in using an explicit signaling model, such as used by IntServ, but carrying a signal which allows the network to manage the application's traffic within an aggregated service class [6]. Here the application does not pass a complete picture of its intended service profile to the network, but instead is providing some level of additional information to the network to assist in managing its resources, both in terms of the generic service class that the network can associate with the application's traffic, and the intended path of the traffic through the network.
IntServによって用いられるような明示的なシグナリング・モデルを使用して、しかしネットワークは集約サービス・クラス内のアプリケーションのトラフィックを管理することを可能にする信号を搬送するに可能性がある[6]。ここでのアプリケーションは、ネットワークに、その意図されたサービスプロファイルの全体像を渡し、代わりにそのリソースを管理するのを支援するために、ネットワークに付加的な情報のいくつかのレベルを提供して、両方のネットワークを関連付けることができ、一般的なサービスクラスの面ではありませんアプリケーションのトラフィック、およびネットワークを介したトラフィックの意図パスを持ちます。
An additional factor for QoS enabled applications is that of receiver capability negotiation. There is no value in the sender establishing a QoS-enabled path across a network to the receiver if the receiver is incapable of absorbing the consequent data flow. This implies that QoS enabled applications also require some form of end-to-end capability negotiation, possibly through a generic protocol to allow the sender to match its QoS requirements to the minimum of the flow resources that can be provided by the network and the flow resources that can be processed by the receiver. In the case of the Integrated services architecture the application end-to-end interaction can be integrated into the RSVP negotiation. In the case of the Differentiated Services architecture there is no clear path of integrating such receiver control into the signaling model of the architecture as it stands.
QoSの有効なアプリケーションのための追加的な要因は、その受信機の機能ネゴシエーションです。受信機は、結果としてのデータフローを吸収することができない場合、受信機にネットワークを介してQoS対応パスを確立する送信者には値がありません。これは、QoS対応のアプリケーションはまた、送信者がネットワークとフローによって提供することができるフローリソースの最小値にそのQoS要件に合致することを可能にするために、おそらく一般的なプロトコルを介して、エンド・ツー・エンドの能力交渉のいくつかのフォームを必要とすることを意味します受信機によって処理できるリソース。統合されたサービスアーキテクチャの場合、アプリケーションのエンドツーエンドの相互作用は、RSVP交渉に統合することができます。差別化サービスアーキテクチャの場合には、そのままアーキテクチャのシグナリング・モデルにそのような受信機の制御を統合する明確な経路が存在しません。
If high quality services are to be provided, where `high quality' is implied as being `high precision with a fine level of granularity', then the implication is that all parts of the network that may be involved with servicing the request either have to be over- provisioned such that no load state can compromise the service quality, or the network element must undertake explicit allocation of resources to each flow that is associated with each service request.
高品質のサービスが '高品質「は粒度の細かいレベルで `高精度であると暗示される」場合、提供される場合、含意は、要求をサービスに関与することができるネットワークのすべての部分のいずれかに持っていることです過無負荷状態は、サービス品質を損なうことができない、またはネットワーク要素が、各サービス要求に関連付けられている各フローにリソースの明示的な割り当てを行う必要がありますようにプロビジョニングします。
For end-to-end service delivery it does appear that QoS architectures will need to extend to the level of the application requesting the service profile. It appears that further refinement of the QoS architecture is required to integrate DiffServ network services into an end-to-end service delivery model, as noted in [7].
エンドツーエンドのサービス提供のために、QoSアーキテクチャは、サービスプロファイルを要求するアプリケーションのレベルにまで拡張する必要がありますように見えるん。 QoSアーキテクチャのさらなる改良は、[7]で述べたように、エンドツーエンドのサービス提供モデルへのDiffServネットワークサービスを統合するために必要であることが表示されます。
The outcome of the considerations of these two approaches to QoS architecture within the network is that there appears to be no single comprehensive service environment that possesses both service accuracy and scaling properties.
ネットワーク内のQoSアーキテクチャにこれら2つのアプローチの検討事項の結果は、サービスの正確性およびスケーリング特性の両方を所有している単一の包括的なサービス環境がないように見えることです。
The maintained reservation state of the Integrated Services architecture and the end-to-end signaling function of RSVP are part of a service management architecture, but it is not cost effective, or even feasible, to operate a per-application reservation and classification state across the high speed core of a network [2].
統合サービスアーキテクチャとRSVPのエンド・ツー・エンドのシグナリング機能の維持予約状態は、サービス管理アーキテクチャの一部であるが、それは両端のアプリケーションごとの予約および分類状態を操作するために、効果的な、あるいは可能費用されていませんネットワークの高速コア[2]。
While the aggregated behavior state of the Differentiated Services architecture does offer excellent scaling properties, the lack of end-to-end signaling facilities makes such an approach one that cannot operate in isolation within any environment. The Differentiated Services architecture can be characterized as a boundary-centric operational model. With this boundary-centric architecture, the signaling of resource availability from the interior of the network to the boundary traffic conditioners is not defined, nor is the signaling from the traffic conditioners to the application that is resident on the end system. This has been noted as an additional work item in the IntServ operations over DiffServ work, concerning "definition of mechanisms to efficiently and dynamically provision resources in a DiffServ network region". This might include protocols by which an "oracle" (...) conveys information about resource availability within a DiffServ region to border routers." [7]
差別化サービスアーキテクチャの凝集挙動状態が優れたスケーリング特性を提供しないが、エンド・ツー・エンドのシグナリング機能の欠如は、任意の環境内で孤立して動作することができないようなアプローチのいずれかを行います。差別化サービスアーキテクチャは、境界中心の運用モデルとして特徴付けることができます。この境界中心のアーキテクチャにより、境界トラフィックコンディショナーにネットワーク内部からのリソースの可用性のシグナリングが定義され、またエンドシステムに常駐しているアプリケーションへのトラフィックコンディショナーからのシグナリングではありません。これは、「DiffServのネットワーク領域内の効率的かつ動的にプロビジョニングリソースへの機構の定義」について、DiffServの作業上のIntServ操作で追加のワークアイテムとして注目されています。これは、「オラクル」（...）は境界ルータへのDiffServ領域内のリソースの可用性に関する情報を搬送することにより、プロトコルが含まれる場合があります。」[7]
What appears to be required within the Differentiated Services service model is both resource availability signaling from the core of the network to the DiffServ boundary and some form of signaling from the boundary to the client application.
どのような差別化サービスのサービスモデル内で必要とされるように見えることはDiffServの境界にネットワークの中核とクライアントアプリケーションとの境界からのシグナル伝達のいくつかのフォームからのシグナルの両方リソースの利用可能です。
There is no robust mechanism for network path discovery with specific service performance attributes. The assumption within both IntServ and DiffServ architectures is that the best effort routing path is used, where the path is either capable of sustaining the service load, or not.
特定のサービスのパフォーマンス属性を持つネットワーク経路探索のための堅牢なメカニズムはありません。両方のIntServおよびDiffServのアーキテクチャ内の仮定は、パスは、サービス負荷を維持する、またはしないことができるいずれかであるベストエフォートのルーティングパスは、使用されることです。
Assuming that the deployment of service differentiating infrastructure will be piecemeal, even if only in the initial stages of a QoS rollout, such an assumption may be unwarranted. If this is the case, then how can a host application determine if there is a distinguished service path to the destination? No existing mechanisms exist within either of these architectures to query the network for the potential to support a specific service profile. Such a query would need to examine a number of candidate paths, rather than simply examining the lowest metric routing path, so that this discovery function is likely to be associated with some form of QoS routing functionality.
サービス差別化インフラストラクチャの展開があっても唯一のQoS展開の初期段階では、断片的になると仮定すると、そのような仮定が不当なかもしれません。このような場合は、その後、どのようにホストアプリケーションは、先に功労のパスがあるかどうかを決定することができますか？既存のメカニズムは、特定のサービスプロファイルをサポートする可能性のためのネットワークを照会するためにこれらのアーキテクチャのいずれかの内に存在しません。このようなクエリは、この発見機能は、QoSルーティング機能のいくつかのフォームに関連付けされる可能性があるように、というだけで最小のメトリックのルーティング経路を調べるよりも、候補パスの数を検討する必要があります。
From this perspective, there is still further refinement that may be required in the model of service discovery and the associated task of resource reservation.
このような観点から、サービスの発見のモデルとリソース予約の関連するタスクで必要とされるさらなる改良が依然として存在します。
To date QoS routing has been developed at some distance from the task of development of QoS architectures. The implicit assumption within the current QoS architectural models is that the routing best effort path will be used for both best effort traffic and distinguished service traffic.
日付のQoSへのルーティングは、QoSアーキテクチャの開発の仕事からいくつかの距離で開発されてきました。現在のQoSアーキテクチャ・モデル内の暗黙の前提は、ルーティングのベストエフォートパスはベストエフォートトラフィックと区別サービストラフィックの両方に使用されるということです。
There is no explicit architectural option to allow the network service path to be aligned along other than the single best routing metric path, so that available network resources can be efficiently applied to meet service requests. Considerations of maximizing network efficiency would imply that some form of path selection is necessary within a QoS architecture, allowing the set of service requirements to be optimally supported within the network's aggregate resource capability.
利用可能なネットワークリソースを効率的にサービス要求を満たすために適用することができるように、ネットワーク・サービス・パスは、単一の最良のルーティングメトリックパス以外に沿って整列されることを可能にする明示的な建築のオプションはありません。ネットワーク効率を最大の考慮事項は、経路選択のいくつかのフォームは、サービス要件のセットが最適ネットワークの集合リソースの能力の範囲内に支持されることを可能にする、QoSアーキテクチャ内で必要であることを暗示します。
In addition to path selection, SPF-based interior routing protocols allow for the flooding of link metric information across all network elements. This mechanism appears to be a productive direction to provide the control-level signaling between the interior of the network and the network admission elements, allowing the admission systems to admit traffic based on current resource availability rather than on necessarily conservative statically defined admission criteria.
パス選択に加えて、SPFベースの内部ルーティングプロトコルは、すべてのネットワーク要素を横切ってリンクメトリック情報のフラッディングを可能にします。この機構は、入場システムが現在のリソースの可用性にではなく、必ずしも保存的静的に定義された承認基準に基づいてトラフィックを許可することができ、ネットワークの内部及びネットワークアドミッション要素間の制御レベルシグナリングを提供するために生産向きであるように見えます。
There is a more fundamental issue here concerning resource management and traffic engineering. The approach of single path selection with static load characteristics does not match a networked environment which contains a richer mesh of connectivity and dynamic load characteristics. In order to make efficient use of a rich connectivity mesh, it is necessary to be able to direct traffic with a common ingress and egress point across a set of available network paths, spreading the load across a broader collection of network links. At its basic form this is essentially a traffic engineering problem. To support this function it is necessary to calculate per-path dynamic load metrics, and allow the network's ingress system the ability to distribute incoming traffic across these paths in accordance with some model of desired traffic balance. To apply this approach to a QoS architecture would imply that each path has some form of vector of quality attributes, and incoming traffic is balanced across a subset of available paths where the quality attribute of the traffic is matched with the quality vector of each available path. This augmentation to the semantics of the traffic engineering is matched by a corresponding shift in the calculation and interpretation of the path's quality vector. In this approach what needs to be measured is not the path's resource availability level (or idle proportion), but the path's potential to carry additional traffic at a certain level of quality. This potential metric is one that allows existing lower priority traffic to be displaced to alternative paths. The path's quality metric can be interpreted as a metric describing the displacement capability of the path, rather than a resource availability metric.
ここでは、リソース管理およびトラフィックエンジニアリングに関するより根本的な問題があります。静的負荷特性を有する単一の経路選択のアプローチは、接続性と動的負荷特性の豊かなメッシュを含んでいるネットワーク環境と一致しません。豊富な接続性メッシュを効率的に使用するためには、ネットワークリンクの広いコレクション間で負荷を分散、利用可能なネットワークパスのセットに共通の入力および出力の点でトラフィックを指示できるようにする必要があります。その基本的な形で、これは、本質的にトラフィックエンジニアリングの問題です。この機能をサポートするためには、単位のパスの動的負荷メトリックを計算し、ネットワークの入口システムに所望のトラフィックバランスのいくつかのモデルに応じてこれらの経路を横切って着信トラフィックを分配する能力を可能にするために必要です。各パス品質属性のベクトルの何らかの形態を有しており、着信トラフィックをトラフィックの品質属性が使用可能な各パスの品質ベクトルと一致する利用可能なパスのサブセットを横切ってバランスされていることを暗示するQoSアーキテクチャにこの方法を適用します。トラフィックエンジニアリングのセマンティクスにこの増加は、パスの品質ベクトルの計算および解釈で対応するシフトで一致しています。測定する必要があるもの。このアプローチでは、パスのリソースの可用性レベル（またはアイドル割合）が、品質の一定のレベルで追加のトラフィックを運ぶために、パスの可能性ではありません。この潜在的なメトリックは、代替パスに変位される既存の低い優先度のトラフィックを可能にするものです。パスの品質メトリックは、パスの変位能力ではなく、リソースの可用性メトリックを記述するメトリックとして解釈することができます。
This area of active network resource management, coupled with dynamic network resource discovery, and the associated control level signaling to network admission systems appears to be a topic for further research at this point in time.
この動的ネットワーク資源発見に結合されたアクティブネットワークリソース管理の領域、および承認システムをネットワークにシグナリング関連した対照レベルはこの時点で、さらなる研究の課題であると思われます。
A congestion-managed rate-adaptive traffic flow (such as used by TCP) uses the feedback from the ACK packet stream to time subsequent data transmissions. The resultant traffic flow rate is an outcome of the service quality provided to both the forward data packets and the reverse ACK packets. If the ACK stream is treated by the network with a different service profile to the outgoing data packets, it remains an open question as to what extent will the data forwarding service be compromised in terms of achievable throughput. High rates of jitter on the ACK stream can cause ACK compression, that in turn will cause high burst rates on the subsequent data send. Such bursts will stress the service capacity of the network and will compromise TCP throughput rates.
（TCPによって使用されるなど）、混雑管理のレート適応型トラフィックフローは、時間後続のデータ送信にACKパケットストリームからのフィードバックを使用しています。その結果、トラフィック流量は、順方向データパケットと逆ACKパケットの両方に提供されるサービスの質の結果です。 ACKストリームが送信データパケットに異なるサービスプロファイルとのネットワークによって処理される場合にどの程度のデータ転送サービスは、達成可能なスループットの点で妥協されるであろうように、未解決の問題のままです。 ACKストリーム上のジッタ率の高さは、後続のデータが送信に順番に高いバースト率の原因となりますことを、ACK圧縮を引き起こす可能性があります。このようなバーストは、ネットワークのサービス能力を強調し、TCPのスループット・レートを妥協します。
One way to address this is to use some form of symmetric service, where the ACK packets are handled using the same service class as the forward data packets. If symmetric service profiles are important for TCP sessions, how can this be structured in a fashion that does not incorrectly account for service usage? In other words, how can both directions of a TCP flow be accurately accounted to one party?
これに対処する1つの方法は、ACKパケットが転送データパケットと同じサービスクラスを使用して処理され、対称サービスのいくつかのフォームを使用することです。対称サービスプロファイルは、TCPセッションのために重要である場合には、どのようにこれは間違ってサービスの利用を考慮していないやり方で構成することができますか？言い換えれば、どのようにTCPフローの両方向を正確に一方の当事者に計上することができますか？
Additionally, there is the interaction between the routing system and the two TCP data flows. The Internet routing architecture does not intrinsically preserve TCP flow symmetry, and the network path taken by the forward packets of a TCP session may not exactly correspond to the path used by the reverse packet flow.
また、ルーティングシステムと2つのTCPデータフローとの間の相互作用があります。インターネットルーティングアーキテクチャは、本質的にTCPフロー対称性を保持せず、TCPセッションのフォワードパケットによって取られるネットワークパスが正確に逆パケットフローによって使用されるパスに対応していなくてもよいです。
TCP also exposes an additional performance constraint in the manner of the traffic conditioning elements in a QoS-enabled network. Traffic conditioners within QoS architectures are typically specified using a rate enforcement mechanism of token buckets. Token bucket traffic conditioners behave in a manner that is analogous to a First In First Out queue. Such traffic conditioning systems impose tail drop behavior on TCP streams. This tail drop behavior can produce TCP timeout retransmission, unduly penalizing the average TCP goodput rate to a level that may be well below the level specified by the token bucket traffic conditioner. Token buckets can be considered as TCP-hostile network elements.
TCPはまた、QoS対応ネットワークにおけるトラフィック調整要素の形で追加のパフォーマンスの制約を公開します。 QoSのアーキテクチャ内のトラフィックコンディショナーは、一般的にトークンバケットの割合執行メカニズムを使用して指定されています。トークンバケットトラフィックコンディショナーは、先入れ先出しキューに類似した方法で動作します。このようなトラフィック調整システムは、TCPストリーム上のテールドロップの動作を課します。このテールドロップの動作は、過度ウェルトークンバケットトラフィックコンディショナによって指定されたレベル以下とすることができるレベルまでの平均のTCPグッドプット率を不利に、TCPタイムアウト再送を生成することができます。トークンバケットは、TCP-敵対的なネットワーク要素とみなすことができます。
The larger issue exposed in this consideration is that provision of some form of assured service to congestion-managed traffic flows requires traffic conditioning elements that operate using weighted RED-like control behaviors within the network, with less deterministic traffic patterns as an outcome. A requirement to manage TCP burst behavior through token bucket control mechanisms is most appropriately managed in the sender's TCP stack.
この考慮にさらさ大きな問題は、輻輳管理のトラフィックに保証されたサービスのいくつかのフォームの提供は、結果としてあまり確定的なトラフィックパターンで、ネットワーク内で加重REDのような制御動作を使用して動作するトラフィック調整要素を必要と流れています。トークンバケット制御機構を通じてTCPのバースト動作を管理するための要件は、最も適切な送信者のTCPスタックで管理されています。
There are a number of open areas in this topic that would benefit from further research. The nature of the interaction between the end-to-end TCP control system and a collection of service differentiation mechanisms with a network is has a large number of variables. The issues concern the time constants of the control systems, the amplitude of feedback loops, and the extent to which each control system assumes an operating model of other active control systems that are applied to the same traffic flow, and the mode of convergence to a stable operational state for each control system.
さらなる研究の恩恵を受けるこのトピックのオープンエリアの数があります。ネットワークとエンドツーエンドのTCP制御システムおよびサービス差別化機構の集合との間の相互作用の性質は、多数の変数を有しています。問題は、制御システムの時定数、フィードバックループの振幅、及び各制御システムは、同じトラフィックフローに適用される他のアクティブ制御システムの動作モデルを想定している程度、およびへの収束のモードに関係します各制御システムのための安定した動作状態。
Both the IntServ and DiffServ architectures use packet classifiers as an intrinsic part of their architecture. These classifiers can be considered as coarse or fine level classifiers. Fine-grained classifiers can be considered as classifiers that attempt to isolate elements of traffic from an invocation of an application (a `micro-flow') and use a number of fields in the IP packet header to assist in this, typically including the source and destination IP addresses and source and source and destination port addresses. Coarse-grained classifiers attempt to isolate traffic that belongs to an aggregated service state, and typically use the DiffServ code field as the classifying field. In the case of DiffServ there is the potential to use fine-grained classifiers as part of the network ingress element, and coarse-gained classifiers within the interior of the network.
両方のIntServおよびDiffServのアーキテクチャは、そのアーキテクチャの本質的な部分としてパケット分類子を使用します。これらの分類は、粗いまたは細かいレベルの分類とみなすことができます。きめの細かい分類は、典型的には、ソースを含むアプリケーション（ `マイクロ流 '）の呼び出しからのトラフィックの要素を分離し、これを支援するために、IPパケットヘッダ内のフィールドの数を使用しようとする分類、と考えることができますそして、宛先IPアドレスと送信元と送信元と宛先ポートアドレス。粗い分類は、集約サービス状態に属するトラフィックを分離し、そして典型的には、分類フィールドとしてのDiffServコードフィールドを使用することを試みます。 DiffServの場合には、ネットワークの内部ネットワーク進入要素の一部、及び粗い獲得分類としてきめ細かい分類器を使用する可能性があります。
Within flow-sensitive IntServ deployments, every active network element that undertakes active service discrimination is requirement to operate fine-grained packet classifiers. The granularity of the classifiers can be relaxed with the specification of aggregate classifiers [5], but at the expense of the precision and accuracy of the service response.
流れに敏感イントサーブの展開の中で、アクティブなサービスの差別を引き受けるすべてのアクティブなネットワーク要素は、きめの細かいパケット分類器を動作させるための必要条件です。分類の精度は、[5]が、サービス応答の精度と正確さを犠牲にして集計分類の仕様に緩和することができます。
Within the IntServ architecture the fine-grained classifiers are defined to the level of granularity of an individual traffic flow, using the packet's 5-tuple of (source address, destination address, source port, destination port, protocol) as the means to identify an individual traffic flow. The DiffServ Multi-Field (MF) classifiers are also able to use this 5-tuple to map individual traffic flows into supported behavior aggregates.
IntServアーキテクチャ内きめ細かい分類手段を識別するように（ソースアドレス、宛先アドレス、送信元ポート、宛先ポート、プロトコル）のパケットの5タプルを使用して、個々のトラフィックフローの細分性のレベルに定義されています個々のトラフィックフロー。 DiffServのマルチフィールド（MF）分類は、個々のトラフィックをマップするために、この5タプルを使用することができるサポートされている行動の凝集体に流入します。
The use of IPSEC, NAT and various forms of IP tunnels result in a occlusion of the flow identification within the IP packet header, combining individual flows into a larger aggregate state that may be too coarse for the network's service policies. The issue with such mechanisms is that they may occur within the network path in a fashion that is not visible to the end application, compromising the ability for the application to determine whether the requested service profile is being delivered by the network. In the case of IPSEC there is a proposal to carry the IPSEC Security Parameter Index (SPI) in the RSVP object [10], as a surrogate for the port addresses. In the case of NAT and various forms of IP tunnels, there appears to be no coherent way to preserve fine-grained classification characteristics across NAT devices, or across tunnel encapsulation.
IPSEC、NATおよびIPトンネルの様々な形の使用は、ネットワークのサービスポリシーの粗すぎるかもしれより大きな凝集状態に個々のフローを組み合わせ、IPパケットヘッダ内のフロー識別の閉塞をもたらします。そのようなメカニズムの問題は、それらが要求されたサービス・プロファイルがネットワークによって配信されているかどうかを決定するアプリケーションの能力を損なう、エンドアプリケーションに見えない方法でネットワーク経路内で発生する可能性があることです。 IPSECの場合にはポートアドレスの代わりとして、RSVPオブジェクト[10]のIPsecセキュリティパラメータインデックス（SPI）を実行する提案があります。 NATおよびIPトンネルの様々な形態の場合には、何のコヒーレントNATデバイス間きめ細かい分類特性を維持する方法、またはトンネルカプセル化を横断しないようです。
IP packet fragmentation also affects the ability of the network to identify individual flows, as the trailing fragments of the IP packet will not include the TCP or UDP port address information. This admits the possibility of trailing fragments of a packet within a distinguished service class being classified into the base best effort service category, and delaying the ultimate delivery of the IP packet to the destination until the trailing best effort delivered fragments have arrived.
IPパケットの断片化は、IPパケットの末尾のフラグメントはTCPやUDPポートアドレス情報を含まないので、個々のフローを識別するためのネットワークの能力に影響を与えます。これは、ベースのベストエフォート型サービスのカテゴリに分類されている著名なサービスクラス内のパケットのフラグメントを末尾、および末尾のベストエフォート配信断片が到着するまでの宛先にIPパケットの究極の配信を遅らせる可能性を認めています。
The observation made here is that QoS services do have a number of caveats that should be placed on both the application and the network. Applications should perform path MTU discovery in order to avoid packet fragmentation. Deployment of various forms of payload encryption, header address translation and header encapsulation should be undertaken with due attention to their potential impacts on service delivery packet classifiers.
ここでの観察は、QoSサービスは、アプリケーションとネットワークの両方の上に置かれるべき注意点の数を持っているということです。アプリケーションは、パケットの断片化を避けるために、パスMTUディスカバリを実行する必要があります。ペイロード暗号化、ヘッダのアドレス変換とヘッダのカプセル化の様々な形の展開は、サービスデリバリのパケット分類上の彼らの潜在的な影響に十分配慮して行われるべきです。
The underlying question posed here is how many distinguished service responses are adequate to provide a functionally adequate range of service responses?
ここで提起根本的な疑問は、功労応答がサービス応答の機能的に十分な範囲を提供するのに十分であるどのように多くのですか？
The Differentiated Services architecture does not make any limiting restrictions on the number of potential services that a network operator can offer. The network operator may be limited to a choice of up to 64 discrete services in terms of the 6 bit service code point in the IP header but as the mapping from service to code point can be defined by each network operator, there can be any number of potential services.
差別化サービスアーキテクチャは、ネットワークオペレータが提供できる潜在的なサービスの数の任意の制限の制限がありません。ネットワークオペレータは、IPヘッダ内の6ビットのサービス・コード・ポイントの点で最大64のディスクリートサービスの選択に制限することができるが、コード・ポイントへのサービスのマッピングは、各ネットワークオペレータによって定義することができるように、任意の数が存在することができます潜在的なサービスの。
As always, there is such a thing as too much of a good thing, and a large number of potential services leads to a set of issues around end-to-end service coherency when spanning multiple network domains. A small set of distinguished services can be supported across a large set of service providers by equipment vendors and by application designers alike. An ill-defined large set of potential services often serves little productive purpose. This does point to a potential refinement of the QoS architecture to define a small core set of service profiles as "well-known" service profiles, and place all other profiles within a "private use" category.
いつものように、良いことのあまりのようなものがあり、複数のネットワークドメインにまたがるとき、潜在的な多数のサービスは、エンドツーエンドのサービスの一貫性の周りの問題のセットにつながります。功績の小さなセットは、機器ベンダーによってと同様にアプリケーション設計により、サービスプロバイダーの大規模なセットでサポートすることができます。潜在的なサービスの不明確な大規模なセットは、多くの場合、少し生産的目的を果たします。これは、「既知の」サービスプロファイルとしてサービスプロファイルの小さなコアセットを定義し、「私的使用」のカテゴリ内の他のすべてのプロファイルを配置するためにQoSアーキテクチャの潜在的な洗練を指すん。
There is a strong requirement within any QoS architecture for network management approaches that provide a coherent view of the operating state of the network. This differs from a conventional element-by-element management view of the network in that the desire here is to be able to provide a view of the available resources along a particular path within a network, and map this view to an admission control function which can determine whether to admit a service differentiated flow along the nominated network path.
ネットワークの動作状態のコヒーレントなビューを提供するネットワーク管理アプローチのための任意のQoSアーキテクチャ内の強力な要件があります。これは、ここで欲求は、ネットワーク内の特定のパスに沿って利用可能なリソースのビューを提供し、アドミッション制御機能にこのビューをマッピングすることができるようになるという点で、ネットワークの従来の要素ごとの管理ビューと異なりますノミネートネットワーク経路に沿ってサービス差別化の流れを認めるかどうかを判断することができます。
As well as managing the admission systems through resource availability measurement, there is a requirement to be able to measure the operating parameters of the delivered service. Such measurement methodologies are required in order to answer the question of how the network operator provides objective measurements to substantiate the claim that the delivered service quality conformed to the service specifications. Equally, there is a requirement for a measurement methodology to allow the client to measure the delivered service quality so that any additional expense that may be associated with the use of premium services can be justified in terms of superior application performance.
同様に、リソース可用性測定により入場システムを管理するように、提供されるサービスの動作パラメータを測定することができるようにする必要があります。このような測定方法は、ネットワークオペレータが提供されるサービス品質がサービス仕様に準拠した主張を立証する客観的な測定をどのように提供するかの質問に答えるために必要とされています。同様に、プレミアムサービスの使用に関連することができる任意の追加費用は、優れたアプリケーションパフォーマンスの面で正当化することができるように、クライアントが提供されるサービスの品質を測定することを可能にする測定方法のための要件があります。
Such measurement methodologies appear to fall within the realm of additional refinement to the QoS architecture.
このような測定方法は、QoSアーキテクチャに追加洗練された領域内に収まるように表示されます。
It is reasonable to anticipate that such forms of premium service and customized service will attract an increment on the service tariff. The provision of a distinguished service is undertaken with some level of additional network resources to support the service, and the tariff premium should reflect this altered resource allocation. Not only does such an incremental tariff shift the added cost burden to those clients who are requesting a disproportionate level of resources, but it provides a means to control the level of demand for premium service levels.
プレミアムサービスおよびカスタマイズされたサービスのような形態は、サービス料金の増分を誘致することを期待するのが妥当です。著名なサービスの提供は、サービスをサポートするために追加のネットワークリソースの一部のレベルで行われ、および関税プレミアムは、この変更されたリソースの割り当てを反映すべきです。インクリメンタル関税は、資源の不均衡なレベルを要求しているこれらのクライアントに追加のコスト負担をシフトしますが、プレミアムサービスレベルの需要のレベルを制御する手段を提供するだけでなく。
If there are to be incremental tariffs on the use of premium services, then some accounting of the use of the premium service would appear to be necessary relating use of the service to a particular client. So far there is no definition of such an accounting model nor a definition as to how to gather the data to support the resource accounting function.
プレミアムサービスの利用上の増分関税があるとされている場合は、プレミアムサービスの利用の一部の会計処理は、特定のクライアントへのサービスの利用に関連する必要があるように思われます。これまでのところ、このような会計モデルのない定義やリソースアカウンティング機能をサポートするためのデータを収集する方法についての定義がありません。
The impact of this QoS service model may be quite profound to the models of Internet service provision. The commonly adopted model in both the public internet and within enterprise networks is that of a model of access, where the clients service tariff is based on the characteristics of access to the services, rather than that of the actual use of the service. The introduction of QoS services creates a strong impetus to move to usage-based tariffs, where the tariff is based on the level of use of the network's resources. This, in turn, generates a requirement to meter resource use, which is a form of usage accounting. This topic was been previously studied within the
このQoSサービスモデルの影響は、インターネットサービス提供のモデルに非常に深いかもしれません。公共のインターネットの両方でと企業ネットワーク内で一般的に採用したモデルでは、クライアントのサービス料金は、むしろサービスの実際の使用に比べてサービスへのアクセスの特性に基づいてアクセスのモデル、のそれです。 QoSサービスの導入は、関税は、ネットワークのリソースの使用のレベルに基づいて使用量ベース関税に移動するための強力な推進力を作成します。これは、順番に、使用量会計の形式でメーター資源利用への要求を生成します。このトピックでは、以前以内に研究されてきました。
IETF under the topic of "Internet Accounting" [11], and further refinement of the concepts used in this model, as they apply to QoS accounting may prove to be a productive initial step in formulating a standards-based model for QoS accounting.
IETFは、「インターネット会計」[11]、このモデルで使用される概念の更なる改良のトピックの下、彼らはQoSの会計に適用されるQoSの会計のための標準ベースのモデルを策定における生産の初期段階であることを証明することがあります。
It is extremely improbable that any single form of service differentiation technology will be rolled out across the Internet and across all enterprise networks.
サービスの差別化技術の任意の単一のフォームは、インターネットを介して、すべての企業ネットワーク全体に展開されることが非常にありそうです。
Some networks will deploy some form of service differentiation technology while others will not. Some of these service platforms will interoperate seamlessly and other less so. To expect all applications, host systems, network routers, network policies, and inter-provider arrangements to coalesce into a single homogeneous service environment that can support a broad range of service responses is an somewhat unlikely outcome given the diverse nature of the available technologies and industry business models. It is more likely that we will see a number of small scale deployment of service differentiation mechanisms and some efforts to bridge these environments together in some way.
他はありませんが、いくつかのネットワークでは、サービスの差別化技術のいくつかのフォームを展開します。これらのサービスプラットフォームの中には、そう、他の少ないシームレスに相互運用となります。サービス応答の広い範囲をサポートすることができ、単一の均質なサービス環境に合体するすべてのアプリケーションは、ホスト・システム、ネットワークルータ、ネットワークポリシー、およびインタープロバイダの手配を期待するにはやや低い結果が利用可能な技術の多様な性質を与えられ、業界のビジネスモデル。我々がサービスの差別化メカニズムと何らかの方法でこれらの環境を一緒に埋めるためにいくつかの努力の小規模な展開の数が表示されます可能性が高いです。
In this heterogeneous service environment the task of service capability discovery is as critical as being able to invoke service responses and measure the service outcomes. QoS architectures will need to include protocol capabilities in supporting service discovery mechanisms.
この異種サービス環境でサービス能力発見のタスクは、サービス応答を起動し、サービスの成果を測定することができることと同じくらい重要です。 QoSのアーキテクチャは、サービスディスカバリメカニズムをサポートするには、プロトコル機能を含める必要があります。
In addition, such a heterogeneous deployment environment will create further scaling pressure on the operational network as now there is an additional dimension to the size of the network. Each potential path to each host is potentially qualified by the service capabilities of the path. While one path may be considered as a candidate best effort path, another path may offer a more precise match between the desired service attributes and the capabilities of the path to sustain the service. Inter-domain policy also impacts upon this path choice, where inter-domain transit agreements may specifically limit the types and total level of quality requests than may be supported between the domains. Much of the brunt of such scaling pressures will be seen in the inter-domain and intra-domain routing domain where there are pressures to increase the number of attributes of a routing entry, and also to use the routing protocol in some form of service signaling role.
また、このような異種のデプロイメント環境は、今のようにネットワークのサイズに追加の次元がある運用ネットワーク上の更なるスケーリング圧力を作成します。各ホストに各潜在的なパスは、潜在的にパスのサービス機能によって修飾されます。一方の経路候補ベストエフォートパスとみなすことができるが、別の経路は、所望のサービス属性とサービスを維持するためのパスの能力との間のより正確な一致を提供することができます。ドメイン間のトランジット契約は、特にドメイン間に支持することができるより種類と品質要求の合計レベルを制限することができる。このパス選択、時ドメイン間のポリシーにも影響を与えます。このようなスケーリング圧力の矛先の多くは、ルーティングエントリの属性の数を増加させる圧力が存在するドメイン間およびドメイン内ルーティングドメインに見られる、そして、サービスシグナリングの何らかの形でルーティングプロトコルを使用します役割。
QoS Path selection is both an intra-domain (interior) and an inter-domain (exterior) issue. Within the inter-domain space, the current routing technologies allow each domain to connect to a number of other domains, and to express its policies with respect to received traffic in terms of inter-domain route object attributes. Additionally, each domain may express its policies with respect to sending traffic through the use of boundary route object filters, allowing a domain to express its preference for selecting one domain's advertised routes over another. The inter-domain routing space is a state of dynamic equilibrium between these various route policies.
QoS経路の選択は、（内部）ドメイン内およびドメイン間（外装）の問題でもあります。ドメイン間の空間内に、現在のルーティング技術は、各ドメインが他のドメインの数に接続するため、およびドメイン間ルートオブジェクト属性の点で受信したトラフィックに対して、そのポリシーを表現することを可能にします。また、各ドメインは、他の上にあるドメインのアドバタイズされたルートを選択するためにその嗜好を表現するドメインを可能にする、境界ルートオブジェクトフィルタの使用を介してトラフィックを送信することに関連して、そのポリシーを表現することができます。ドメイン間ルーティングスペースはこれらの様々なルートポリシーの間の動的平衡の状態です。
The introduction of differentiated services adds a further dimension to this policy space. For example, while a providers may execute an interconnection agreement with one party to exchange best effort traffic, it may execute another agreement with a second party to exchange service qualified traffic. The outcome of this form of interconnection is that the service provider will require external route advertisements to be qualified by the accepted service profiles. Generalizing from this scenario, it is reasonable to suggest that we will require the qualification of routing advertisements with some form of service quality attributes. This implies that we will require some form of quality vector-based forwarding function, at least in the inter-domain space, and some associated routing protocol can pass a quality of service vector in an operationally stable fashion.
差別化サービスの導入は、このポリシーのスペースにさらに次元を追加します。プロバイダはベストエフォートトラフィックを交換するために一方の当事者との相互接続契約を実行することができる。一方、例えば、それはサービス資格のトラフィックを交換するために第2のパーティとの別の契約を実行することもできます。相互接続のこの形式の結果は、サービスプロバイダが受け入れられたサービスプロファイルで修飾される外部ルートのアドバタイズメントを必要とすることです。このシナリオから一般化、我々がサービス品質属性のいくつかのフォームに広告をルーティングの資格が必要になることを示唆するのが妥当です。これは、少なくともドメイン間の空間に、高品質のベクトルベースの転送機能のいくつかのフォームを必要とすることを意味し、そしていくつかの関連するルーティングプロトコルが動作可能安定的にサービスベクトルの質を通過することができます。
The implication of this requirement is that the number of objects being managed by routing systems must expand dramatically, as the size and number of objects managed within the routing domain increases, and the calculation of a dynamic equilibrium of import and export policies between interconnected providers will also be subject to the same level of scaling pressure.
この要件の意味は、システムをルーティングすることによって管理されるオブジェクトの数、サイズおよびルーティングドメイン増大内の管理対象オブジェクトの数、及び相互接続プロバイダ間のインポートおよびエクスポートポリシーの動的平衡の計算として、劇的に展開しなければならないことである意志また、スケーリング圧力と同じレベルの対象となります。
This has implications within the inter-domain forwarding space as well, as the forwarding decision in such a services differentiated environment is then qualified by some form of service quality vector. This is required in order to pass exterior traffic to the appropriate exterior interconnection gateway.
これは、サービスの品質ベクトルの何らかの形で修飾されたようなサービス差別化環境での転送の決定として、だけでなく、ドメイン間の転送空間内の意味合いを持っています。これは、適切な外部配線ゲートウェイの外部トラフィックを通過させるために必要とされます。
How does the widespread deployment of service-aware networks commence? Which gets built first - host applications or network infrastructure?
サービスアウェアネットワークの広範な展開はどのように始めるのですか？どちらが最初に構築されます - ホストアプリケーションやネットワークインフラストラクチャを？
No network operator will make the significant investment in deployment and support of distinguished service infrastructure unless there is a set of clients and applications available to make immediate use of such facilities. Clients will not make the investment in enhanced services unless they see performance gains in applications that are designed to take advantage of such enhanced services. No application designer will attempt to integrate service quality features into the application unless there is a model of operation supported by widespread deployment that makes the additional investment in application complexity worthwhile and clients who are willing to purchase such applications. With all parts of the deployment scenario waiting for the others to move, widespread deployment of distinguished services may require some other external impetus.
クライアントとこのような施設の即時利用することが可能なアプリケーションのセットがあるない限り、ネットワークオペレータは、著名なサービスインフラストラクチャの展開とサポートに多大な投資をしないでしょう。彼らは、このような高度なサービスを利用するように設計されたアプリケーションにおけるパフォーマンスの向上を参照してくださいしない限り、クライアントは、強化されたサービスへの投資をすることはありません。このようなアプリケーションを購入して喜んでいるアプリケーションの複雑さに価値と顧客への追加投資を行い広範囲の展開でサポートされている操作のモデルが存在しない限り、アプリケーション設計者は、アプリケーションにサービス品質の機能を統合しようとしません。移動する他の人を待っている展開シナリオのすべての部分では、区別のサービスの広範な展開は、いくつかの他の外部刺激を必要とするかもしれません。
Further aspects of this deployment picture lie in the issues of network provisioning and the associated task of traffic engineering. Engineering a network to meet the demands of best effort flows follows a well understood pattern of matching network points of user concentrations to content delivery network points with best effort paths. Integrating QoS-mediated traffic engineering into the provisioning model suggests a provisioning requirement that also requires input from a QoS demand model.
この展開画像のさらなる態様は、ネットワークプロビジョニングおよびトラフィックエンジニアリングの関連するタスクの問題にあります。ベストエフォートの要求を満たすためにネットワークを操作すると、ベストエフォートパスとコンテンツ配信ネットワークポイントにユーザ濃度の網点のマッチングよく理解パターンに従う流れます。プロビジョニングモデルにQoSの媒介トラフィックエンジニアリングを統合することも、QoSの需要モデルからの入力を必要とプロビジョニング要件を示唆しています。
What is the precise nature of the problem that QoS is attempting to solve? Perhaps this is one of the more fundamental questions underlying the QoS effort, and the diversity of potential responses is a pointer to the breadth of scope of the QoS effort.
QoSが解決しようとしている問題の正確な性質は何ですか？おそらくこれは、QoS努力の基礎となる、より根本的な問題の一つであり、潜在的な応答の多様性は、QoS努力の範囲の広さへのポインタです。
All of the following responses form a part of the QoS intention:
次の応答のすべては、QoS意思の一部を形成します：
- To control the network service response such that the response to a specific service element is consistent and predictable.
- 特定のサービス要素への応答が一貫して予測可能であるように、ネットワークサービス応答を制御します。
- To control the network service response such that a service element is provided with a level of response equal to or above a guaranteed minimum.
- サービス要素が保証最小に以上等しい応答のレベルを備えているようなネットワークサービス応答を制御します。
- To allow a service element to establish in advance the service response that can or will be obtained from the network.
- サービス要素は、事前に、またはネットワークから取得されることができ、サービスの応答を確立できるようにするには。
- To control the contention for network resources such that a service element is provided with a superior level of network resource.
- サービス要素は、ネットワークリソースのより優れたレベルで提供されるようにネットワークリソースの競合を制御します。
- To control the contention for network resources such that a service element does not obtain an unfair allocation of resources (to some definition of 'fairness').
- サービス要素は、リソースの不公平な割当を取得しないように（「公平」のいくつかの定義に）ネットワークリソースの競合を制御します。
- To allow for efficient total utilization of network resources while servicing a spectrum of directed network service outcomes.
- 指向ネットワークサービス結果のスペクトルにサービスを提供しながら、ネットワークリソースの効率的な総利用を可能にします。
Broadly speaking, the first three responses can be regarded as 'application-centric', and the latter as 'network-centric'. It is critical to bear in mind that none of these responses can be addressed in isolation within any effective QoS architecture. Within the end-to-end architectural model of the Internet, applications make minimal demands on the underlying IP network. In the case of TCP, the protocol uses an end-to-end control signal approach to dynamically adjust to the prevailing network state. QoS architectures add a somewhat different constraint, in that the network is placed in an active role within the task of resource allocation and service delivery, rather than being a passive object that requires end systems to adapt.
大まかに言えば、最初の3つの応答は、「アプリケーション中心」、および「ネットワーク中心」として後者とみなすことができます。これらの応答のどれもが任意の有効なQoSアーキテクチャの中に孤立して対処できないことを心に留めすることが重要です。インターネットのエンド・ツー・エンドのアーキテクチャモデルの中では、アプリケーションは、基盤となるIPネットワーク上の最低限の要求をします。 TCPの場合、プロトコルは、動的に優勢なネットワーク状態に調整するために、エンドツーエンド制御信号アプローチを使用します。ネットワークはなく適応させるためにエンドシステムを必要とするパッシブオブジェクトであるよりも、リソース割り当てとサービス配信のタスク内で積極的な役割に配置されるという点でのQoSアーキテクチャは、多少異なる制約を加えます。
The challenge facing the QoS architecture lies in addressing the weaknesses noted above, and in integrating the various elements of the architecture into a cohesive whole that is capable of sustaining end-to-end service models across a wide diversity of internet platforms. It should be noted that such an effort may not necessarily result in a single resultant architecture, and that it is possible to see a number of end-to-end approaches based on different combinations of the existing components.
QoSアーキテクチャが直面する課題は、上記の弱点に対処する上で、インターネット・プラットフォームの幅広い多様性全体にエンドツーエンドのサービスモデルを維持することのできる凝集全体にアーキテクチャの様々な要素を統合することにあります。そのような努力は、必ずしも単一得アーキテクチャをもたらし、既存のコンポーネントの異なる組合せに基づいて、エンド・ツー・エンドのアプローチの数を確認することが可能であることはないことに留意すべきです。
One approach is to attempt to combine both architectures into an end-to-end model, using IntServ as the architecture which allows applications to interact with the network, and DiffServ as the architecture to manage admission the network's resources [7]. In this approach, the basic tension that needs to be resolved lies in difference between the per-application view of the IntServ architecture and the network boundary-centric view of the DiffServ architecture.
一つのアプローチは、入場を管理するためのアーキテクチャとして、アプリケーションがネットワークと対話することを可能にするアーキテクチャとしてイントサーブ使用して、エンドツーエンドモデルに両方のアーキテクチャを組み合わせることを試みることで、DiffServのネットワークのリソース[7]。このアプローチのIntServアーキテクチャのアプリケーションごとのビューおよびDiffServアーキテクチャのネットワーク境界を中心ビューとの間の差に嘘を解決する必要がある基本的な張力。
One building block for such an end-to-end service architecture is a service signaling protocol. The RSVP signaling protocol can address the needs of applications that require a per-service end-to-end service signaling environment. The abstracted model of RSVP is that of a discovery signaling protocol that allows an application to use a single transaction to communicate its service requirements to both the network and the remote party, and through the response mechanism, to allow these network elements to commit to the service requirements. The barriers to deployment for this model lie in an element-by element approach to service commitment, implying that each network element must undertake some level of signaling and processing as dictated by this imposed state. For high precision services this implies per-flow signaling and per-flow processing to support this service model. This fine-grained high precision approach to service management is seen as imposing an unacceptable level of overhead on the central core elements of large carrier networks.
このようなエンドツーエンドサービスアーキテクチャの一個のビルディングブロックは、サービスシグナリングプロトコルです。 RSVPシグナリングプロトコルは、サービスごとのエンドツーエンドのサービスシグナリング環境を必要とするアプリケーションのニーズに対応することができます。 RSVPの抽象化モデルは、これらのネットワーク要素は、にコミットできるようにするために、アプリケーションは、ネットワーク及び相手側の両方にそのサービス要求を通信するために単一のトランザクションを使用することができ、及び応答機構を介して発見シグナリングプロトコルのものですサービス要件。この課される状態によって決まるように、各ネットワーク要素がシグナリングおよび処理のいくつかのレベルに着手しなければならないことを意味素子によって素子アプローチコミットメントをサービスにこのモデル位置、の展開に対する障壁。高精度なサービスの場合、これは、このサービス・モデルをサポートするために、フローごとのシグナリングおよびフローごとの処理を意味しています。サービス管理このきめの細かい高精度なアプローチは、大規模なキャリアネットワークの中央コア要素のオーバーヘッドの許容できないレベルを与えると見られています。
The DiffServ approach uses a model of abstraction which attempts to create an external view of a compound network as a single subnetwork. From this external perspective the network can be perceived as two boundary service points, ingress and egress. The advantage of this approach is that there exists the potential to eliminate the requirement for per-flow state and per-flow processing on the interior elements of such a network, and instead provide aggregate service responses.
DiffServのアプローチは、単一のサブネットワーク等の化合物のネットワークの外観を作成しようと抽象化のモデルを使用します。この外部の視点からネットワークは二つの境界サービスポイント、入力および出力として認識することができます。このアプローチの利点は、そのようなネットワークの内部構成要素にフロー毎の状態とフローごとの処理の必要性を排除し、その代わりに集約サービス応答を提供する可能性が存在することです。
One approach is for applications to use RSVP to request that their flows be admitted into the network. If a request is accepted, it would imply that there is a committed resource reservation within the IntServ-capable components of the network, and that the service requirements have been mapped into a compatible aggregate service class within the DiffServ-capable network [7]. The DiffServ core must be capable of carrying the RSVP messages across the DiffServ network, so that further resource reservation is possible within the IntServ network upon egress from the DiffServ environment. The approach calls for the DiffServ network to use per-flow multi-field (MF) classifier, where the MF classification is based on the RSVP-signaled flow specification. The service specification of the RSVP-signaled resource reservation is mapped into a compatible aggregate DiffServ behavior aggregate and the MF classifier marks packets according to the selected behavior. Alternatively the boundary of the IntServ and DiffServ networks can use the IntServ egress to mark the flow packets with the appropriate DSCP, allowing the DiffServ ingress element to use the BA classifier, and dispense with the per-flow MF classifier.
一つのアプローチは、彼らのフローがネットワークに認められることを要求するためにRSVPを使用するアプリケーションのためです。要求が受け入れられた場合、それはネットワークのIntServ可能なコンポーネント内コミットリソース予約があることを意味するものとなるサービス要件のDiffServ対応ネットワーク内で互換性の集約サービス・クラスにマップされていること[7]。さらに、リソース予約がDiffServの環境から退出時のIntServネットワーク内で可能であるようにDiffServのコアは、DiffServのネットワークを介してRSVPメッセージを運ぶことができなければなりません。アプローチは、MF分類がRSVP-シグナリングフロー仕様に基づいてフローごとマルチフィールド（MF）分類器を使用するのDiffServネットワークを必要とします。 RSVP-シグナリングリソース予約のサービス仕様は、互換性のある骨材のDiffServ挙動集合体にマッピングされ、MF分類器は、選択された動作に従ってパケットをマークします。代替としてのIntServおよびDiffServのネットワークの境界は、DiffServの侵入要素がBA分類子を使用することができ、適切なDSCPとフローパケットをマークするためのIntServの出力を使用し、フロー毎MF分類器を省くことができます。
A high precision end-to-end QoS model requires that any admission failure within the DiffServ network be communicated to the end application, presumably via RSVP. This allows the application to take some form of corrective action, either by modifying it's service requirements or terminating the application. If the service agreement between the DiffServ network is statically provisioned, then this static information can be loaded into the IntServ boundary systems, and IntServ can manage the allocation of available DiffServ behavior aggregate resources. If the service agreement is dynamically variable, some form of signaling is required between the two networks to pass this resource availability information back into the RSVP signaling environment.
高精度エンドツーエンドのQoSモデルは、DiffServのネットワーク内の任意のアドミッション障害は、おそらくRSVPを介して、エンド・アプリケーションに伝達されることを必要とします。これは、アプリケーションがそれのサービス要件を変更したり、アプリケーションを終了するのいずれか、是正措置のいくつかのフォームを取ることができます。 DiffServのネットワークの間のサービス契約が静的にプロビジョニングされている場合、この静的な情報はイントサーブ境界システムにロードすることができ、かつイントサーブは、利用可能なDiffServの行動の総計リソースの割り当てを管理することができます。サービス契約が動的に変動する場合は、シグナリングのいくつかのフォームは、バックRSVPシグナリング環境にこのリソースの可用性情報を渡すために、2つのネットワークとの間に必要とされます。
None of these observations are intended to be any reason to condemn the QoS architectures as completely impractical, nor are they intended to provide any reason to believe that the efforts of deploying QoS architectures will not come to fruition.
これらの観察のいずれも、完全に非現実的としてのQoSアーキテクチャを非難する理由であることを意図されていない、また彼らは、QoSアーキテクチャを展開する努力が実を結ぶに来ないだろうと信じるあらゆる理由を提供することを意図しています。
What this document is intended to illustrate is that there are still a number of activities that are essential precursors to widespread deployment and use of such QoS networks, and that there is a need to fill in the missing sections with something substantial in terms of adoption of additional refinements to the existing QoS model.
何この文書は説明することを意図していることなどのQoSネットワークの広範な展開と使用に不可欠な前駆体である多くの活動がまだあるということである、との養子縁組の面で大幅な何かで行方不明のセクションに記入する必要があること既存のQoSモデルへの追加改良。
The architectural direction that appears to offer the most promising outcome for QoS is not one of universal adoption of a single architecture, but instead use a tailored approach where aggregated service elements are used in the core of a network where scalability is a major design objective and use per-flow service elements at the edge of the network where accuracy of the service response is a sustainable outcome.
QoSのための最も有望な結果を提供するように見えるアーキテクチャの方向は、単一のアーキテクチャの普遍的な採用の一つではなく、集約サービス要素はスケーラビリティが主要な設計目標であるネットワークのコアに使用されている合わせたアプローチを使用し、サービス応答の精度が持続的結果であるネットワークのエッジでフローごとのサービス要素を使用します。
Architecturally, this points to no single QoS architecture, but rather to a set of QoS mechanisms and a number of ways these mechanisms can be configured to interoperate in a stable and consistent fashion.
アーキテクチャは、これは、単一のQoSアーキテクチャに、むしろQoSメカニズムのセット及びこれらの機構は、安定かつ一貫した方法で相互運用するように構成することができるいくつかの方法を指します。
The Internet is not an architecture that includes a strict implementation of fairness of access to the common transmission and switching resource. The introduction of any form of fairness, and, in the case of QoS, weighted fairness, implies a requirement for transparency in the implementation of the fairness contract between the network provider and the network's users. This requires some form of resource accounting and auditing, which, in turn, requires the use of authentication and access control. The balancing factor is that a shared resource should not overtly expose the level of resource usage of any one user to any other, so that some level of secrecy is required in this environment
インターネットは、共通の伝送及びスイッチングリソースへのアクセスの公平性の厳格な実施を含むアーキテクチャではありません。公正の任意の形式の導入、および、QoSの場合には、加重公平性が、ネットワークプロバイダやネットワークの利用者間の公平性契約の実装で透明性の要件を意味します。これは、順番に、認証とアクセス制御を使用する必要があり、資源会計と監査、のいくつかのフォームを必要とします。均衡要因は、秘密のいくつかのレベルがこの環境で必要とされるように、共有リソースはあからさまに、他のいずれかのユーザーのリソース使用量のレベルを公開するべきではないということです
The QoS environment also exposes the potential of theft of resources through the unauthorized admission of traffic with an associated service profile. QoS signaling protocols which are intended to undertake resource management and admission control require the use of identity authentication and integrity protection in order to mitigate this potential for theft of resources.
QoSの環境は、関連するサービスプロファイルを持つトラフィックの不正入場してリソースの盗難の可能性を公開します。リソース管理およびアドミッション制御を実施することを意図しているのQoSシグナリングプロトコルは、リソースの盗難のために、この可能性を軽減するために、ID認証と完全性保護を使用する必要があります。
Both forms of QoS architecture require the internal elements of the network to be able to undertake classification of traffic based on some form of identification that is carried in the packet header in the clear. Classifications systems that use multi-field specifiers, or per-flow specifiers rely on the carriage of end-to-end packet header fields being carried in the clear. This has conflicting requirements for security architectures that attempt to mask such end-to-end identifiers within an encrypted payload.
QoSアーキテクチャの両方の形態が明確にパケットヘッダで運ばれる識別の何らかの形態に基づいてトラフィックの分類を行うことができるように、ネットワークの内部の構成要素を必要とします。マルチフィールド指定子を使用して分類システム、またはフローごとの指定子は明らかで運ばれて、エンドツーエンドのパケットヘッダフィールドのキャリッジに依存しています。これは、暗号化されたペイロードの中に、このようなエンド・ツー・エンドの識別子を隠蔽しようとセキュリティ・アーキテクチャのための相反する要件があります。
QoS architectures can be considered as a means of exerting control over network resource allocation. In the event of a rapid change in resource availability (e.g. disaster) it is an undesirable outcome if the remaining resources are completely allocated to a single class of service to the exclusion of all other classes. Such an outcome constitutes a denial of service, where the traffic control system (routing) selects paths that are incapable of carrying any traffic of a particular service class.
QoSのアーキテクチャは、ネットワークリソースの割り当てを制御を発揮する手段として考えることができます。残りのリソースは完全に他のすべてのクラスを除外して、サービスの単一のクラスに割り当てられる場合に、リソースの可用性の急激な変化（例えば、災害）の場合には望ましくない結果です。そのような結果は、交通制御システム（ルーティング）は、特定のサービス・クラスのすべてのトラフィックを運ぶことができないパスを選択し、サービスの拒否を構成しています。
[1] Bradner, S., "The Internet Standards Process- Revision 3", BCP 9, RFC 2026, October 1996.
[1]ブラドナーの、S.、 "インターネット標準処理 - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[2] Mankin, A., Baker, F., Braden, R., O'Dell, M., Romanow, A., Weinrib, A. and L. Zhang, "Resource ReSerVation Protocol (RSVP) Version 1 Applicability Statement", RFC 2208, September 1997.
[2]マンキン、A.、ベイカー、F.、ブレーデン、R.、オデル、M.、Romanow、A.、Weinrib、A.およびL.チャン、「リソース予約プロトコル（RSVP）バージョン1適用ステートメント」、RFC 2208、1997年9月。
[3] Braden. R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[3]ブレーデン。 R.、クラーク、D.とS. Shenker、 "インターネットアーキテクチャにおける統合サービス：概要"、RFC 1633、1994年6月。
[4] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[4]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[5] Baker, F., Iturralde, C., Le Faucher, F., Davie, B., "Aggregation of RSVP for IPv4 and IPv6 Reservations", Work in Progress.
[5]ベーカー、F.、Iturralde、C.、ルFaucher、F.、デイビー、B.、 "IPv4とIPv6の予約のためのRSVPの集約"、ProgressのWork。
[6] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000.
[6] Bernet、Y.、 "RSVP DCLASSオブジェクトのフォーマット"、RFC 2996、2000年11月。
[7] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, "A Framework for Integrated Services Operation Over DiffServ Networks", RFC 2998, November 2000.
[7] Bernet、Y.、Yavatkar、R.、フォード、P.、ベイカー、F.、チャン、L.、シュペーア、M.、ブレーデン、R.、デイビー、B.、Wroclawski、J.、およびE. Felstaine、RFC 2998、2000年11月「統合サービスオペレーション以上のDiffServネットワークのためのフレームワーク」。
[8] "Quality of Service Technical Overview", Microsoft Technical Library, Microsoft Corporation, September 1999.
[8]、マイクロソフトテクニカルライブラリ、マイクロソフト社、1999年9月「サービス技術概要の品質を」。
[9] "Resource Reservation Protocol API (RAPI)", Open Group Technical Standard, C809 ISBN 1-85912-226-4, The Open Group, December 1998.
[9] "リソース予約プロトコルのAPI（RAPI）"、Open Groupの技術標準、C809 ISBN 1-85912-226-4、オープングループ、1998年12月。
[10] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2007, September 1997.
[10]バーガー、L.とT.オマリー、 "IPSECデータフローのためのRSVP拡張機能"、RFC 2007、1997年9月。
[11] Mills, C., Hirsh, D. and G. Ruth, "Internet Accounting: Background", RFC 1272, November 1991.
[11]ミルズ、C.、Hirsh、D.とG.ルース、 "インターネット会計：背景"、RFC 1272、1991年11月。
Valuable contributions to this document came from Yoram Bernet, Brian Carpenter, Jon Crowcroft, Tony Hain and Henning Schulzrinne.
このドキュメントへの貴重な貢献はYoram Bernet、ブライアン・カーペンター、ジョンクロウクロフト、トニーハインとヘニングSchulzrinneとから来ました。
Geoff Huston Telstra 5/490 Northbourne Ave Dickson ACT 2602 AUSTRALIA
ジェフ・ヒューストンテルストラ490分の5ノースボーンアベニューディクソンACT 2602 AUSTRALIA
EMail: gih@telstra.net
メールアドレス：gih@telstra.net
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。