[要約] RFC 2990は、IP QoSアーキテクチャの次のステップについての提案をまとめたものです。その目的は、インターネット上での品質の高いサービスを提供するためのガイドラインを提供することです。
Network Working Group G. Huston
Request for Comments: 2990 Telstra
Category: Informational November 2000
Next Steps for the IP QoS Architecture
IP QOSアーキテクチャの次のステップ
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
概要
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の多くの側面があります。 - エンドのサービス配信。このドキュメントは、インターネットネットワーク内の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アーキテクチャ。制御要素は、ネットワークリソースのポリシーベースの制御を可能にするために、エンドツーエンドアプリケーションのシグナリング、エンドツーネットワークサービスシグナリング、リソース管理シグナリングなど、多くの一般的な要件に及びます。このコントロールは、特定の範囲にまたがって、定義されたネットワーク範囲内で特定のサービス応答をサポートすることを目的とした「Edge to Edge」シグナリングを使用する場合があります。
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.
利用可能なリソースのレベルに合わせて課された負荷のこの制御を実装する1つの方法は、アプリケーション主導のサービスレベル交渉のプロセス（アプリケーションシグナルQOSとも呼ばれる）を使用することです。ここで、アプリケーションは最初にネットワークへのサービス要件を示し、ネットワークはこの要求に応答します。ネットワークが要求されたサービスレベルで追加の負荷を携帯できることを示している場合、アプリケーションは続行します。ネットワークがサービス要件に対応できないことを示している場合、ネットワークが最適な努力に基づいてアプリケーションのデータにサービスを提供することに基づいて、アプリケーションはいずれにせよ、アプリケーションが進行することができます。アプリケーションとネットワークの間のこの交渉は、単一の交渉段階がある明示的な交渉とコミットメントの形をとることができ、その後、ネットワーク側のサービスレベルへのコミットメントが続きます。このアプリケーションシグナルアプローチは、統合サービスアーキテクチャ内で使用できます。このアーキテクチャでは、アプリケーションがリソース予約プロトコル（RSVP）内でサービス要求を枠組みし、この要求をネットワークに渡すことができます。ネットワークは、このサービスプロファイルにコミットするという合意の観点から積極的に応答するか、リクエストを拒否することができます。ネットワークがリソースの予約でリクエストにコミットする場合、アプリケーションは、リクエストに最初に関連付けられていたトラフィックロードプロファイル内にトラフィックが残る限り、ネットワークは要求されたものを満たすことを期待して、ネットワークにトラフィックを渡すことができますサービスレベル。RSVPとネットワークの間の相互作用は、アクティブのままである間に予約を絶えず再表示しているため、アプリケーションがサービス予約自体を定期的に再構成するための要件はありません。予約は、申請が予約の終了を明示的に要求するまで、またはネットワークが予約へのサービスコミットメントを継続できないというアプリケーションの信号を要求するまで有効です[3]。このモデルには、プロキシエージェントが一般的なサブパスに沿って多数のアプリケーションシグナル留置を共通の集計予約に折りたたむことができる集合モデルを含む、このモデルにはバリエーションがあり、一致する執deaggregatorは、個々のリソース予約のコレクションを再確立することができます。凝集領域[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).
これらのサービスアーキテクチャをこのドキュメント内でさらに詳細に説明することを意図したものではありません。統合サービスアーキテクチャ（INTSERV）とRFC2475 [4]の概要については、差別化されたサービスアーキテクチャ（DIFFSERV）の概要については、RFC1633 [3]を参照してください。
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つのアプローチは、コントロールモデルの連続体と見なすことができるもののエンドポイントです。ここでは、アプリケーションごとの呼び出しモデルの細かい精度を、より大きく、より一般的で、潜在的に潜在的に潜在的に潜在的に潜在的な集計の予約状態に集約できます。 - サブネットワークのコレクションまたはトランジットネットワーク全体を集計サービス要素として扱うことにより、要素ごとの要素ごとの予約制御を徐々に近似できます。RSVP [5]、RSVP DCLASSオブジェクト[6]の集約を含むこれらの集約された制御モデルに向けられた進行中の作業があり、差別化されたサービスコードポイント（DSCP）をRSVPメッセージオブジェクトに携帯できるようにします。差別化されたサービスネットワークを介した統合サービスの運用[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アーキテクチャを使用した不確実性の基本的な領域の1つは、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.
差別化されたサービスアーキテクチャの場合、アプリケーションがサービスレベルに関してネットワークと通信するための明示的な規定はありません。これにより、利用可能な差別化されたサービスサービスプロファイルの1つで生成されたトラフィックをマークするためにアプリケーションの明示的な変更を必要としないエンドシステム内で輸送レベルオプションを使用することができます。ただし、アプリケーションがそのようなサービスプロファイルを認識しているかどうかにかかわらず、そのようなモデルのアプリケーションに対するサービスの保証はありません。差別化されたサービスの境界トラフィックコンディショナーが負荷制限状態に入る場合、アプリケーションはこの条件の合図されておらず、要求されたサービス応答がネットワークによって提供されていないことを明示的に認識していません。ネットワーク自体が状態を変更し、イングレストラフィックコンディショナーによって認められた累積トラフィック負荷を満たすことができない場合、イングレストラフィックコンディショナーもクライアントアプリケーションも、関連するサービス品質を維持できないことを通知されません。このアーキテクチャでアプリケーションの動作を変更する明示的な必要はありませんが、基本的な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アーキテクチャは、サービスプロファイルを要求するアプリケーションのレベルに拡張する必要があると思われます。[7]に記載されているように、DiffServネットワークサービスをエンドツーエンドのサービス提供モデルに統合するには、QoSアーキテクチャのさらなる改良が必要であると思われます。
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操作における追加の作業項目として認められています。これには、「Oracle」（...）が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.
PATH選択に加えて、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-Hostileネットワーク要素と見なすことができます。
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.
この考慮事項にさらされているより大きな問題は、混雑管理されたトラフィックフローへの何らかの形の保証サービスを提供するには、ネットワーク内の加重赤色のような制御行動を使用して動作するトラフィックコンディショニング要素が必要であり、結果として決定論的なトラフィックパターンが少ないことです。トークンバケット制御メカニズムを介して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.
流れに敏感なIntServ展開内で、アクティブなサービス差別を引き受けるすべてのアクティブネットワーク要素は、細粒パケット分類器を操作するための要件です。分類器の粒度は、凝集分類子[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 Multi-Field（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サービスにはアプリケーションとネットワークの両方に配置する必要がある多くの警告があることです。アプリケーションは、パケットの断片化を避けるために、PATH 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 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.
このQoSサービスモデルの影響は、インターネットサービスの提供のモデルに非常に深いかもしれません。パブリックインターネットとエンタープライズネットワーク内の両方で一般的に採用されているモデルは、クライアントサービスの関税がサービスの実際の使用ではなく、サービスへのアクセスの特性に基づいているアクセスモデルのモデルです。QoSサービスの導入は、使用率ベースの関税に移行するための強力な推進力を生み出します。この関税では、関税はネットワークのリソースの使用レベルに基づいています。これにより、リソースの使用を計算するための要件が生成されます。これは、使用会計の一形態です。このトピックは、「インターネット会計」[11]のトピックの下でIETF内で以前に研究されました。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.
さらに、このような不均一な展開環境は、ネットワークのサイズに追加の次元があるため、運用ネットワークにさらにスケーリング圧力をかけます。各ホストへの各潜在的なパスは、パスのサービス機能によって潜在的に資格があります。1つのパスは候補者の最善の努力パスと見なされる場合がありますが、別のパスは、希望するサービス属性とサービスを維持するパスの機能との間のより正確な一致を提供する場合があります。また、ドメイン間ポリシーは、ドメイン間輸送契約がドメイン間でサポートされるよりも、品質要求のタイプと総レベルを特異的に制限する可能性があるこのパス選択にも影響を与えます。このようなスケーリング圧力の矢面は、ルーティングエントリの属性の数を増やす圧力がある圧力があるドメイン間およびドメイン内のルーティングドメインで見られるでしょう。役割。
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パス選択は、ドメイン内（内部）とドメイン間（エクステリア）問題の両方です。ドメイン間スペース内では、現在のルーティングテクノロジーにより、各ドメインは他の多くのドメインに接続し、ドメイン間ルートオブジェクト属性に関して受信したトラフィックに関するポリシーを表現できます。さらに、各ドメインは、境界ルートオブジェクトフィルターの使用を介したトラフィックの送信に関するポリシーを表現し、ドメインが1つのドメインの広告ルートを別のドメインに選択することを好むことを表現できます。ドメイン間ルーティングスペースは、これらのさまざまなルートポリシー間の動的平衡状態です。
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.
差別化されたサービスの導入は、このポリシー空間にさらに次元を追加します。たとえば、プロバイダーは、最良の努力トラフィックを交換するために1つの当事者との相互接続契約を実行することができますが、資格のあるトラフィックを交換するために、第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の取り組みの根底にあるより根本的な質問の1つであり、潜在的な反応の多様性は、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.
1つのアプローチは、両方のアーキテクチャをエンドツーエンドモデルに組み合わせて、アプリケーションがネットワークと対話できるようにするアーキテクチャとしてIntServを使用し、アーキテクチャとして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.
このようなエンドツーエンドサービスアーキテクチャの1つの構成要素は、サービスシグナリングプロトコルです。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アプローチは、単一のサブネットワークとして複合ネットワークの外部ビューを作成しようとする抽象化のモデルを使用します。この外部の観点から、ネットワークは2つの境界サービスポイント、イングレスと出口として知覚できます。このアプローチの利点は、このようなネットワークの内部要素での流量あたりの状態および流量ごとの処理の要件を排除する可能性が存在し、代わりに総サービス応答を提供する可能性があることです。
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.
1つのアプローチは、アプリケーションがRSVPを使用して、フローをネットワークに入れることを要求することです。要求が受け入れられた場合、ネットワークのIntServ利用コンポーネント内にコミットされたリソース予約があり、サービス要件がDiffServ対応ネットワーク内の互換性のある集約サービスクラスにマッピングされていることを意味します[7]。DiffServコアは、DiffServネットワーク全体にRSVPメッセージを運ぶことができる必要があります。そのため、DiffServ環境から出口時にIntServネットワーク内でさらなるリソース予約が可能になります。このアプローチでは、DiffServネットワークが流量あたりマルチフィールド（MF）分類器を使用することを求めています。MF分類はRSVPシグナルフロー仕様に基づいています。RSVPシグナルリソースのリソース予約のサービス仕様は、選択した動作に従って互換性のある集約型Diffservの動作とMF分類子マークパケットにマッピングされます。あるいは、IntServおよびDiffServネットワークの境界は、IntServ Egressを使用して適切なDSCPでフローパケットをマークし、DiffServ Ingress要素がBA分類器を使用し、Perlow 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モデルでは、おそらくRSVPを介して、DiffServネットワーク内の入場障害を最終アプリケーションに通知する必要があります。これにより、サービスの要件を変更するか、アプリケーションを終了することにより、アプリケーションは何らかの形の修正措置を講じることができます。DiffServネットワーク間のサービス契約が静的にプロビジョニングされている場合、この静的情報はIntServ境界システムにロードでき、IntServは利用可能な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の最も有望な結果を提供するように見える建築の方向性は、単一のアーキテクチャの普遍的な採用の1つではなく、スケーラビリティが主要な設計目標であり、ネットワークのコアで集約されたサービス要素が使用される調整されたアプローチを使用します。サービス応答の正確性が持続可能な結果であるネットワークの端にあるフローごとのサービス要素を使用します。
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の場合、重み付けされた公平性は、ネットワークプロバイダーとネットワークのユーザー間の公正契約の実装における透明性の要件を意味します。これには、何らかの形のリソースアカウンティングと監査が必要であり、その結果、認証とアクセス制御の使用が必要です。バランスの要因は、共有リソースが1人のユーザーのリソース使用のレベルを他のユーザーに公然と公開してはならないため、この環境ではある程度の秘密が必要であることです。
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] Bradner、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] Mankin、A.、Baker、F.、Braden、R.、O'dell、M.、Romanow、A.、Weinrib、A。and L. Zhang、「Resource Reservation Protocol（RSVP）バージョン1アプリケーションステートメント」、RFC2208、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.シェンカー、「インターネットアーキテクチャにおける統合サービス：概要」、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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスのアーキテクチャ」、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] Baker、F.、Iturralde、C.、Le Faucher、F.、Davie、B。、「IPv4およびIPv6予約のRSVPの集約」、進行中の作業。
[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.、Ford、P.、Baker、F.、Zhang、L.、Speer、M.、Braden、R.、Davie、B.、Wroclawski、J. and E. Felstaine、 "DiffServネットワークを介した統合サービス操作のフレームワーク」、RFC 2998、2000年11月。
[8] "Quality of Service Technical Overview", Microsoft Technical Library, Microsoft Corporation, September 1999.
[8] 「サービス品質技術概要」、Microsoft Technical Library、Microsoft Corporation、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 Technical Standard、C809 ISBN 1-85912-226-4、Open Group、1998年12月。
[10] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2007, September 1997.
[10] Berger、L。およびT. O'Malley、「IPSECデータフローのRSVP拡張機能」、RFC 2007、1997年9月。
[11] Mills, C., Hirsh, D. and G. Ruth, "Internet Accounting: Background", RFC 1272, November 1991.
[11] Mills、C.、Hirsh、D.、G。Ruth、「インターネット会計：背景」、RFC 1272、1991年11月。
Valuable contributions to this document came from Yoram Bernet, Brian Carpenter, Jon Crowcroft, Tony Hain and Henning Schulzrinne.
この文書への貴重な貢献は、Yoram Bernet、Brian Carpenter、Jon Crowcroft、Tony Hain、Henning Schulzrinneから来ました。
Geoff Huston Telstra 5/490 Northbourne Ave Dickson ACT 2602 AUSTRALIA
Geoff Huston Telstra 5/490 Northbourne Ave Dickson Act 2602 Australia
EMail: gih@telstra.net
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エディター機能の資金は現在、インターネット協会によって提供されています。