Network Working Group K. Nichols
Request for Comments: 2638 V. Jacobson
Category: Informational Cisco
L. Zhang
UCLA
July 1999
A Two-bit Differentiated Services Architecture for the Internet
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 (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
This document was originally submitted as an internet draft in November of 1997. As one of the documents predating the formation of the IETF's Differentiated Services Working Group, many of the ideas presented here, in concert with Dave Clark's subsequent presentation to the December 1997 meeting of the IETF Integrated Services Working Group, were key to the work which led to RFCs 2474 and 2475 and the section on allocation remains a timely proposal. For this reason, and to provide a reference, it is being submitted in its original form. The forwarding path portion of this document is intended as a record of where we were at in late 1997 and not as an indication of future direction.
この文書は、元々の1997年12月の会議にデーブクラークのその後のプレゼンテーションと協調して、アイデアの多くは、ここで紹介するIETFの差別化サービスワーキンググループの形成をより以前のドキュメントの1つとして、1997年の11月にインターネットドラフトとして提出されましたIETF統合サービスワーキンググループは、RFCの2474年と2475年につながったと割り当てのセクションでは、タイムリーな提案のまま仕事への鍵でした。この理由のために、基準を提供するために、それは元の形式で送信されています。この文書の転送経路部分は、我々は1997年末ではなく、未来方向の指標としてであった場合の記録として意図されています。
The postscript version of this document includes Clark's slides as an appendix. The postscript version of this document also includes many figures that aid greatly in its readability.
このドキュメントのPostScript版は付録としてクラークのスライドが含まれています。このドキュメントのPostScript版もその読みやすさに大いに役立つ多くの数字が含まれています。
This document presents a differentiated services architecture for the internet. Dave Clark and Van Jacobson each presented work on differentiated services at the Munich IETF meeting [2,3]. Each explained how to use one bit of the IP header to deliver a new kind of service to packets in the internet. These were two very different kinds of service with quite different policy assumptions. Ensuing discussion has convinced us that both service types have merit and that both service types can be implemented with a set of very similar mechanisms. We propose an architectural framework that permits the use of both of these service types and exploits their similarities in forwarding path mechanisms. The major goals of this architecture are each shared with one or both of those two proposals: keep the forwarding path simple, push complexity to the edges of the network to the extent possible, provide a service that avoids assumptions about the type of traffic using it, employ an allocation policy that will be compatible with both long-term and short-term provisioning, make it possible for the dominant Internet traffic model to remain best-effort.
この文書では、インターネットのための差別化サービスアーキテクチャを提示します。デイブ・クラークとバン・ジェイコブソンは、それぞれ[2,3]ミュンヘンIETFミーティングで差別化されたサービス上の作業を発表しました。それぞれ、インターネットでのパケットにサービスの新しい種類を提供するために、IPヘッダの1ビットを使用する方法を説明しました。これらは全く異なる政策の前提とサービスの2つの非常に異なる種類のでした。議論をその後のことは、両方のサービスタイプがメリットを持っていることと、両方のサービスの種類が非常によく似たメカニズムのセットで実施することができることが私たちを納得させました。我々は、これらのサービスタイプの両方を使用することを可能にし、パスのメカニズムを転送するには、その類似性を悪用するアーキテクチャフレームワークを提案します。このアーキテクチャの主要な目標は、それぞれ1またはこれら二つの提案の両方で共有されています、簡単な転送パスを維持可能な範囲でのネットワークのエッジに複雑さをプッシュし、それを使用してトラフィックの種類についての仮定を回避したサービスを提供します、長期および短期のプロビジョニングの両方と互換性があります割り当てポリシーを採用し、それが可能な支配的なインターネットトラフィックモデルはベストエフォート型を維持するために作ります。
The major contributions of this document are to present two distinct service types, a set of general mechanisms for the forwarding path that can be used to implement a range of differentiated services and to propose a flexible framework for provisioning a differentiated services network. It is precisely this kind of architecture that is needed for expedient deployment of differentiated services: we need a framework and set of primitives that can be implemented in the short-term and provide interoperable services, yet can provide a "sandbox" for experimentation and elaboration that can lead in time to more levels of differentiation within each service as needed.
この文書の主要な貢献は、2つの異なるサービスタイプ、差別化サービスの範囲を実装し、差別化サービスネットワークをプロビジョニングするための柔軟なフレームワークを提案するために使用できる転送パスのための一般的な機構のセットを提示することです。それは正確に差別化されたサービスの便宜の展開のために必要とされるアーキテクチャのこの種である：我々は短期的に実装することができるプリミティブのフレームワークとセットが必要と相互運用可能なサービスを提供し、まだ実験や精緻化のための「サンドボックス」を提供することができます必要に応じてそれは、各サービス内の分化のより多くのレベルまでの時間につながることができます。
At the risk of belaboring an analogy, we are motivated to provide services tiers in somewhat the same fashion as the airlines do with first class, business class and coach class. The latter also has tiering built in due to the various restrictions put on the purchase. A part of the analogy we want to stress is that best effort traffic, like coach class seats on an airplane, is still expected to make up the bulk of internet traffic. Business and first class carry a small number of passengers, but are quite important to the economics of the airline industry. The various economic forces and realities combine to dictate the relative allocation of the seats and to try to fill the airplane. We don't expect that differentiated services will comprise all the traffic on the internet, but we do expect that new services will lead to a healthy economic and service environment.
アナロジーをbelaboringのリスクで、私たちは、航空会社は、ファーストクラス、ビジネスクラスとエコノミークラスでそうであるように、多少同じ方法でサービス階層を提供するために動機づけられています。後者はまた、購入の上に置く様々な制限のために構築された階層化されています。私たちが強調したいの類似の部分には、飛行機のエコノミークラスの座席のようなベストエフォート型トラフィックは、まだインターネットトラフィックの大部分を占めると予想されていることです。ビジネスとファーストクラスの乗客の数が少ないを運ぶが、航空業界の経済に非常に重要です。様々な経済力と現実が座席の相対的な配分を決定するために組み合わせて、飛行機を埋めるためにしようとします。私たちは、差別化されたサービスは、インターネット上のすべてのトラフィックを含むことになることを期待していないが、我々は新しいサービスが健全な経済およびサービス環境につながることを期待します。
This document is organized into sections describing service architecture, mechanisms, the bandwidth allocation architecture, how this architecture might interoperate with RSVP/int-serv work, and gives recommendations for deployment.
この文書では、このアーキテクチャはRSVP / INT-SERVの仕事との相互運用性、および展開のための勧告を与える可能性がどのようにサービスアーキテクチャ、メカニズム、帯域幅割り当てアーキテクチャを、記述のセクションで構成されています。
The current internet delivers one type of service, best-effort, to all traffic. A number of proposals have been made concerning the addition of enhanced services to the Internet. We focus on two particular methods of adding a differentiated level of service to IP, each designated by one bit [1,2,3]. These services represent a radical departure from the Internet's traditional service, but they are also a radical departure from traditional "quality of service" architectures which rely on circuit-based models. Both these proposals seek to define a single common mechanism that is used by interior network routers, pushing most of the complexity and state of differentiated services to the network edges. Both use bandwidth as the resource that is being requested and allocated. Clark and Wroclawski defined an "Assured" service that follows "expected capacity" usage profiles that are statistically provisioned [3]. The assurance that the user of such a service receives is that such traffic is unlikely to be dropped as long as it stays within the expected capacity profile. The exact meaning of "unlikely" depends on how well provisioned the service is. An Assured service traffic flow may exceed its Profile, but the excess traffic is not given the same assurance level. Jacobson defined a "Premium" service that is provisioned according to peak capacity Profiles that are strictly not oversubscribed and that is given its own high-priority queue in routers [2]. A Premium service traffic flow is shaped and hard-limited to its provisioned peak rate and shaped so that bursts are not injected into the network. Premium service presents a "virtual wire" where a flow's bursts may queue at the shaper at the edge of the network, but thereafter only in proportion to the indegree of each router. Despite their many similarities, these two approaches result in fundamentally different services. The former uses buffer management to provide a "better effort" service while the latter creates a service with little jitter and queueing delay and no need for queue management on the Premium packets's queue.
現在のインターネットはすべてのトラフィックに、サービスの一種で、ベストエフォートを提供します。多くの提案は、インターネットへの拡張サービスの追加について行われています。我々は、IPへのサービスの差別化のレベルを追加する2つの特定の方法、1ビット[1,2,3]によって指定それぞれに焦点を当てます。これらのサービスは、インターネットの伝統的なサービスからラジカル出発を表し、彼らはまた、回路ベースのモデルに依存しているアーキテクチャ伝統的な「サービスの品質」からラジカル出発です。両方のこれらの提案は、ネットワークエッジに複雑さと差別化サービスの状態のほとんどを押し、内部ネットワークのルータによって使用される単一の共通のメカニズムを定義しよう。両方が要求され、割り当てられているリソースとしての帯域幅を使用します。クラークとWroclawski [3]は、統計的にプロビジョニングされている「予想容量」使用プロファイルを以下、「確実な」サービスを定義しました。このようなサービスの利用者が受け取ることを保証は、このようなトラフィックがある限り、それは予想される容量のプロファイル内に留まるとしてドロップされる可能性が低いということです。 「そう」の正確な意味は、サービスがどのようにうまくプロビジョニングによって異なります。確実なサービスのトラフィックフローは、そのプロファイルを超えてもよいが、過剰トラフィックは同じ保証レベルを与えられていません。ヤコブソンは、厳密にオーバーサブスクライブされておらず、それはルータ[2]で独自の高優先度キューが与えられるピーク容量プロファイルに応じてプロビジョニングされる「プレミアム」サービスを定義しました。プレミアムサービスのトラフィックフローは、形やバーストがネットワークに注入されないように、その提供された最大レートにハード制限して成形されています。プレミアムサービスは、フローのバーストは、ネットワークのエッジでシェイパーのキューが、その後にのみ、各ルータの入力度に比例して、「仮想ワイヤ」を提示しています。彼らの多くの類似性にもかかわらず、これらの2つのアプローチは根本的に異なるサービスになり。かつての用途は、後者は少しジッタおよびキューイング遅延やプレミアムパケットのキューのキュー管理を必要とせず、サービスを作成しながら、「よりよい努力」サービスを提供するために、バッファ管理。
An Assured service was introduced in [3] by Clark and Wroclawski, though we have made some alterations in its specification for our architecture. Further refinements and an "Expected Capacity" framework are given in Clark and Fang [10]. This framework is focused on "providing different levels of best-effort service at times of network congestion" but also mentions that it is possible to have a separate router queue to implement a "guaranteed" level of assurance. We believe this framework and our Two-bit architecture are compatible but this needs further exploration. As Premium service has not been documented elsewhere, we describe it next and follow this with a description of the two-bit architecture.
我々はアーキテクチャのその仕様にいくつかの変更を行っているものの確実なサービスは、クラークとWroclawskiにより、[3]で紹介されました。さらなる改良及び「期待容量」フレームワークは、クラークと牙[10]に記載されています。このフレームワークは、「ネットワークの混雑の時間にベストエフォート型サービスの異なるレベルを提供する」に焦点を当てても、保証の「保証」レベルを実現するために別のルータのキューを持つことが可能であることを言及しています。私たちは、このフレームワークと我々の2つのビット・アーキテクチャに互換性があると考えているが、これはさらなる調査が必要です。プレミアムサービスは他の場所で文書化されていないとして、我々は次のことを説明し、2ビットアーキテクチャの記述でこれに従ってください。
In [2], a Premium service was presented that is fundamentally different from the Internet's current best effort service. This service is not meant to replace best effort but primarily to meet an emerging demand for a commercial service that can share the network with best effort traffic. This is desirable economically, since the same network can be used for both kinds of traffic. It is expected that Premium traffic would be allocated a small percentage of the total network capacity, but that it would be priced much higher. One use of such a service might be to create "virtual leased lines", saving the cost of building and maintaining a separate network. Premium service, not unlike a standard telephone line, is a capacity which the customer expects to be there when the receiver is lifted, although it may, depending on the household, be idle a good deal of the time. Provisioning Premium traffic in this way reduces the capacity of the best effort internet by the amount of Premium allocated, in the worst case, thus it would have to be priced accordingly. On the other hand, whenever that capacity is not being used it is available to best effort traffic. In contrast to normal best effort traffic which is bursty and requires queue management to deal fairly with congestive episodes, this Premium service by design creates very regular traffic patterns and small or nonexistent queues.
[2]では、プレミアムサービスは、インターネットの現在のベストエフォート型サービスとは根本的に異なっているが提示されました。このサービスはベストエフォートに代わるものではありませんが、主にベストエフォートトラフィックとネットワークを共有することができ、商用サービスのための新たな需要を満たすために。同一のネットワークトラフィックの両方の種類のために使用することができるので、これは、経済的に望ましいです。プレミアムトラフィックが総ネットワーク容量の小さな割合を割り当てられるだろうと、それははるかに高い価格設定されることが期待されます。このようなサービスの1つの使用は、個別のネットワークを構築し、維持するためのコストを節約し、「仮想専用線」を作成することがあります。プレミアムサービスは、標準の電話回線とは異なり、顧客はそれは、家庭によっては、時間のかなりのアイドルかもしれないが、受信機が、解除されたときにそこにあることを期待容量ではありません。このように、プレミアムトラフィックのプロビジョニングは、最悪の場合には、割り当てられたプレミアムの量によってベストエフォートインターネットの容量を低減し、したがってそれに応じて価格設定されなければなりません。一方、その容量が使用されていないときには、ベストエフォートトラフィックに使用可能です。バースト性で、うっ血性エピソードを公正に対応するキュー管理を必要とし、通常のベストエフォートトラフィックとは対照的に、設計することにより、このプレミアムサービスは非常に規則的なトラフィックパターンと小さなまたは存在しないキューを作成します。
Premium service levels are specified as a desired peak bit-rate for a specific flow (or aggregation of flows). The user contract with the network is not to exceed the peak rate. The network contract is that the contracted bandwidth will be available when traffic is sent. First-hop routers (or other edge devices) filter the packets entering the network, set the Premium bit of those that match a Premium service specification, and perform traffic shaping on the flow that smooths all traffic bursts before they enter the network. This approach requires no changes in hosts. A compliant router along the path needs two levels of priority queueing, sending all packets with the Premium bit set first. Best-effort traffic is unmarked and queued and sent at the lower priority. This results in two "virtual networks": one which is identical to today's Internet with buffers designed to absorb traffic bursts; and one where traffic is limited and shaped to a contracted peak-rate, but packets move through a network of queues where they experience almost no queueing delay.
プレミアムサービスレベルは、特定のフロー（または流れの集合）のために所望のピークビットレートとして指定されています。ネットワークとユーザーの契約は、ピークレートを超えることはありません。ネットワークの契約は、トラフィックが送信されたときに契約帯域が利用可能になるということです。最初のホップルータ（または他のエッジデバイス）は、ネットワークに入るパケットをフィルタリングプレミアムサービス仕様に一致するもののプレミアムビットを設定し、それらがネットワークに入る前に、すべてのトラフィックバーストを平滑化フローにトラフィックシェーピングを行います。このアプローチは、宿主内で変更する必要はありません。経路に沿った対応ルータは、最初に設定プレミアムビットを有するすべてのパケットを送信し、プライオリティキューイング2つのレベルを必要とします。ベストエフォート型トラフィックはマークされていないと、キューに入れられ、低い優先度で送信されています。これは、二つの「仮想ネットワーク」につながる：トラフィックバーストを吸収するように設計さバッファと、今日のインターネットと同じです1。そして、トラフィックが収縮ピークレートに制限さと形状ですが、パケットは、彼らはほとんどキューイング遅延を経験していないキューのネットワークを通じて移動する1。
In this architecture, forwarding path decisions are made separately and more simply than the setting up of the service agreements and traffic profiles. With the exception of policing and shaping at administrative or "trust" boundaries, the only actions that need to be handled in the forwarding path are to classify a packet into one of two queues on a single bit and to service the two queues using simple priority. Shaping must include both rate and burst parameters; the latter is expected to be small, in the one or two packet range. Policing at boundaries enforces rate compliance, and may be implemented by a simple token bucket. The admission and set-up procedures are expected to evolve, in time, to be dynamically configurable and fairly complex while the mechanisms in the forwarding path remain simple.
このアーキテクチャでは、転送パスの決定は、サービス契約およびトラフィックプロファイルの設定よりも、個別に、より簡単に作られています。行政や「信頼」の境界でポリシングとシェーピングを除いて、転送パスで処理する必要がある唯一のアクションは、単一のビットに2つのキューのいずれかにパケットを分類するために、簡単な優先順位を使用して、2つのキューにサービスを提供しています。シェーピングレートとバーストパラメータの両方を含まなければなりません。後者は、1つのまたは2つのパケットの範囲内で、小さいことが期待されます。境界でのポリシングは、レート遵守を強制し、簡単なトークンバケットによって実現することができます。入院とセットアップ手順は、転送パス内の機構は単純なまま時に、動的に構成し、かなり複雑であることが、発展することが期待されます。
A Premium service built on this architecture can be deployed in a useful way once the forwarding path mechanisms are in place by making static allocations. Traffic flows can be designated for special treatment through network management configuration. Traffic flows should be designated by the source, the destination, or any combination of fields in the packet header. First-hop (of leaf) routers will filter flows on all or part of the header tuple consisting of the source IP address, destination IP address, protocol identifier, source port number, and destination port number. Based on this classification, a first-hop router performs traffic shaping and sets the designated Premium bit of the precedence field. End-hosts are thus not required to be "differentiated services aware", though if and when end-systems become universally "aware", they might do their own shaping and first-hop routers merely police.
転送パスのメカニズムは、静的な割り当てを行うことにより、所定の位置にあるいったんこのアーキテクチャ上に構築されたプレミアムサービスが便利な方法で展開することができます。トラフィックフローは、ネットワーク管理の設定を通じて特別な治療のために指定することができます。トラフィックフローは、ソース、宛先、またはパケットヘッダのフィールドの任意の組み合わせによって指定されなければなりません。 （葉の）最初のホップルータはフィルタリングするソースIPアドレス、宛先IPアドレス、プロトコル識別子、送信元ポート番号、宛先ポート番号からなるヘッダタプルのすべてまたは一部に流れます。この分類に基づいて、最初のホップルータは、トラフィックシェーピングを実行し、優先順位フィールドの指定されたプレミアムビットをセットします。エンドホストは、このように、エンドシステムは普遍的「意識」になった場合とするとき、彼らは単に自分の整形およびファーストホップルータ警察を行うかもしれませんが、「差別化サービス対応」である必要はありません。
Adherence to the subscribed rate and burst size must be enforced at the entry to the network, either by the end-system or by the first-hop router. Within an intranet, administrative domain, or "trust region" the packets can then be classified and serviced solely on the Premium bit. Where packets cross a boundary, the policing function is critical. The entered region will check the prioritized packet flow for conformance to a rate the two regions have agreed upon, discarding packets that exceed the rate. It is thus in the best interests of a region to ensure conformance to the agreed-upon rate at the egress. This requirement means that Premium traffic is burst-free and, together with the no oversubscription rule, leads directly to the observation that Premium queues can easily be sized to prevent the need to drop packets and thus the need for a queue management policy. At each router, the largest queue size is related to the in-degree of other routers and is thus quite small, on the order of ten packets.
購読レートとバーストサイズへの付着は、エンドシステムによって、または最初のホップルータのいずれかによって、ネットワークへのエントリに適用されなければなりません。イントラネット、管理ドメイン、または「信頼領域」内のパケットは、分類することができ、プレミアムビットのみにサービスを提供します。パケットが境界を越える場合は、ポリシング機能は重要です。入力された領域はレートを超えたパケットを破棄し、2つの領域が合意されているレートに準拠のための優先順位のパケットの流れをチェックします。これは、出口で合意されたレートへの適合性を保証するために、地域の最善の利益であるため。この要件は、プレミアムトラフィックが自由バーストと、一緒にいないオーバーサブスクリプションルールとされていることを意味し、プレミアム・キューは、簡単にパケットを廃棄する必要があり、これキュー管理政策の必要性を防ぐために、サイズにすることができる観察に直結します。各ルータでは、最大キューサイズは、他のルータの中度に関連し、10のパケットの順序で、これは非常に小さいです。
Premium bandwidth allocations must not be oversubscribed as they represent a commitment by the network and should be priced accordingly. Note that, in this architecture, Premium traffic will also experience considerably less delay variation than either best effort traffic or the Assured data traffic of [3]. Premium rates might be configured on a subscription basis in the near-term, or on-demand when dynamic set-up or signaling is available.
彼らはネットワークのコミットメントを表しており、それに応じて価格設定されるべきであるプレミアム帯域幅の割り当ては、オーバーサブスクライブしてはいけません。このアーキテクチャでは、プレミアムトラフィックもベストエフォートトラフィックまたは[3]の確実なデータトラフィックのいずれかよりもかなり少ない遅延変動を経験する、ということに注意してください。プレミアム率は短期的にはサブスクリプションベースで設定されている場合、またはオンデマンドで動的なセットアップやシグナリングが利用可能になったとき。
Figure 1 shows how a Premium packet flow is established within a particular administrative domain, Company A, and sent across the access link to Company A's ISP. Assume that the host's first-hop router has been configured to match a flow from the host's IP address to a destination IP address that is reached through ISP. A Premium flow is configured from a host with a rate which is both smaller than the total Premium allocation Company A has from the ISP, r bytes per second, and smaller than the amount of that allocation has been assigned to other hosts in Company A. Packets are not marked in any special way when they leave the host. The first-hop router clears the Premium bit on all arriving packets, sets the Premium bit on all packets in the designated flow, shapes packets in the Premium flow to a configured rate and burst size, queues best-effort unmarked packets in the low priority queue and shaped Premium packets in the high priority queue, and sends packets from those two queues at simple priority. Intermediate routers internal to Company A enqueue packets in one of two output queues based on the Premium bit and service the queues with simple priority. Border routers perform quite different tasks, depending on whether they are processing an egress flow or an ingress flow. An egress border router may perform some reshaping on the aggregate Premium traffic to conform to rate r, depending on the number of Premium flows aggregated. Ingress border routers only need to perform a simple policing function that can be implemented with a token bucket. In the example, the ISP accepts all Premium packets from A as long as the flow does not exceed r bytes per second.
図1は、プレミアムパケットフローは、特定の管理ドメイン、A社の中に設置し、A社のISPへのアクセスリンクを介して送信される方法を示しています。ホストのファーストホップルータがISPを介して到達された送信先IPアドレスへのホストのIPアドレスからの流れと一致するように設定されていることを前提としています。プレミアム・フローは、全プレミアム割り当て会社Aが毎秒ISP、Rバイトであり、その割当量がA社の他のホストに割り当てられているよりもより小さい両方小さいレートでホストから構成されています彼らはホストを離れるとき、パケットは、任意の特別な方法でマークされていません。最初のホップルータは、全ての到着パケットにプレミアムビットをクリア指定フロー内のすべてのパケットにプレミアムビットを設定し、設定されたレートにプレミアムフローのパケットを整形し、バーストサイズ、低優先のベストエフォートマークされていないパケットをキューイングキューと優先度の高いキュー内の形状のプレミアムパケット、および簡単な優先順位でこれらの2つのキューからパケットを送信します。プレミアムビットおよびサービスの簡単な優先順位のキューに基づいて2つの出力キューの1でA社エンキューパケットに内部中間ルータ。境界ルータは、彼らは出口の流れや侵入の流れを処理しているかどうかに応じて、まったく異なるタスクを実行します。出口境界ルータは、集約フロープレミアムの数に応じて、Rを評価するために適合するように集約プレミアムトラフィックに一部再形成を行うことができます。イングレス境界ルータは、トークンバケットで実現することができるシンプルなポリシング機能を実行する必要があります。一例では、ISPであれば、フローが毎秒Rバイトを超えないように、すべてのプレミアムパケットを受け入れます。
Figure 1. Premium traffic flow from end-host to organization's ISP
組織のISPへのエンドホストから図1.プレミアムトラフィックフロー
Clark's and Jacobson's proposals are markedly similar in the location and type of functional blocks that are needed to implement them. Furthermore, they implement quite different services which are not incompatible in a network. The Premium service implements a guaranteed peak bandwidth service with negligible queueing delay that cannot starve best effort traffic and can be allocated in a fairly straightforward fashion. This service would seem to have a strong appeal for commercial applications, video broadcasts, voice-over-IP, and VPNs. On the other hand, this service may prove both too restrictive (in its hard limits) and overdesigned (no overallocation) for some applications. The Assured service implements a service that has the same delay characteristics as (undropped) best effort packets and the firmness of its guarantee depends on how well individual links are provisioned for bursts of Assured packets. On the other hand, it permits traffic flows to use any additional available capacity without penalty and occasional dropped packets for short congestive periods may be acceptable to many users. This service might be what an ISP would provide to individual customers who are willing to pay a bit more for internet service that seems unaffected by congestive periods. Both services are only as good as their admission control schemes, though this can be more difficult for traffic which is not peak-rate allocated.
クラークさんとヤコブソンの提案は、それらを実装するために必要な機能ブロックの場所や種類に著しく類似しています。さらに、彼らは、ネットワーク内の互換性がありませんかなり異なるサービスを実装しています。プレミアムサービスはベストエフォートトラフィックを餓死することはできませんし、かなり簡単な方法で割り当てることができ、無視できるキューイング遅延と保証ピーク帯域幅サービスを実装しています。このサービスは、商用アプリケーション、ビデオ放送、ボイスオーバーIP、およびVPNのための強力な魅力を持っているように思われます。一方、このサービスは、いくつかのアプリケーションのための（なし割り当て超過）の両方あまりにも（そのハードの限界で）制限や過剰設計を証明することがあります。確実なサービスは、個々のリンクが保証パケットのバースト用にプロビジョニングされてどれだけに依存します（ごみ箱から戻す）ベストエフォートパケットとその保証の硬さと同じ遅延特性を持っているサービスを実装しています。一方、トラフィックが短いうっ血期間は多くのユーザーに受け入れてもよいためペナルティと時折ドロップされたパケットせずに任意の追加の空き容量を使用するように流れることが可能になります。このサービスは、ISPがうっ血期間の影響を受けないと思われるインターネットサービスのために少し多くを支払うことを喜んでいる個々の顧客に提供するどのようなことがあります。これは、ピークレートが割り当てられていないトラフィックのために、より困難になることができますが、両方のサービスは、唯一の自分のアドミッション制御スキームと同じくらい良いです。
There may be some additional benefits of deploying both services. To the extent that Premium service is a conservative allocation of resources, unused bandwidth that had been allocated to Premium might provide some "headroom" for underallocated or burst periods of Assured traffic or for best effort. Network elements that deploy both services will be performing RED queue management on all non-Premium traffic, as suggested in [4], and the effects of mixing the Premium streams with best effort might serve to reduce burstiness in the latter. A strength of the Assured service is that it allows bursts to happen in their natural fashion, but this also makes the provisioning, admission control and allocation problem more difficult so it may take more time and experimentation before this admission policy for this service is completely defined. A Premium service could be deployed that employs static allocations on peak rates with no statistical sharing.
両方のサービスを展開するいくつかの追加の利点があるかもしれません。プレミアムサービスは、リソースの保守的な配分である限り、プレミアムに割り当てられていた未使用の帯域幅アシュアードトラフィックのunderallocatedまたはバースト期間のためか、最善の努力のためにいくつかの「ヘッドルーム」を提供することがあります。 [4]で提案されているよう両方のサービスを展開するネットワーク要素は、すべての非プレミアムトラフィックにREDキュー管理を実行され、プレミアムの混合の効果はベストエフォート後者でバースト性を軽減するのに役立つかもしれないとストリーム。確実なサービスの強みは、バーストが彼らの自然な形で起こることを可能にするということですが、このサービスのために、この入場方針が完全に定義される前に、それはより多くの時間と実験がかかる場合がありますので、これはまた、プロビジョニング、アドミッション制御と割り当ての問題がより困難に。プレミアムサービスは、統計的な共有でピークレートに静的割り当てを採用している展開することができます。
As there appear to be a number of advantages to an architecture that permits these two types of service and because, as we shall see, they can be made to share many of the same mechanisms, we propose designating two bit-patterns from the IP header precedence field. We leave the explicit designation of these bit-patterns to the standards process thus we use the shorthand notation of denoting each pattern by a bit, one we will call the Premium or P-bit, the other we call the assurance or A-bit. It is possible for a network to implement only one of these services and to have network elements that only look at the one applicable bit, but we focus on the two service architecture. Further, we assume the case where no changes are made in the hosts, appropriate packet marking all being done in the network, at the first-hop, or leaf, router. We describe the forwarding path architecture in this section, assuming that the service has been allocated through mechanisms we will discuss in section 4.
サービスのこれらの2つのタイプを可能にし、我々が見るであろうように、それらは同一の機構の多くを共有させることができるので、アーキテクチャに多くの利点があるように見えるように、我々は、IPヘッダから2ビット・パターンを指定する提案しますprecedenceフィールド。我々は、プレミアムまたはPビット、我々は保証またはビット呼び出す他を呼び出す一従って我々はビットで各パターンを表すの簡略表記を使用する標準化プロセスへのこれらのビットパターンの明示的な指定を残します。ネットワークは、これらのサービスの一つだけを実装するために、唯一の該当ビットを見てネットワーク要素を有することが可能であるが、我々は2つのサービスアーキテクチャに焦点を当てます。さらに、我々は、最初のホップ、または葉で、適切なパケットは、すべてがネットワークで行われているマーキングルータの変更がホストで行われていない場合を想定します。私たちは、サービスは、我々は第4章で議論するメカニズムを通じて割り当てられていると仮定して、このセクションに転送パスアーキテクチャを説明します。
In a more general sense, Premium service denotes packets that are enqueued at a higher priority than the ordinary best-effort queue. Similarly, Assured service denotes packets that are treated preferentially with respect to the dropping probability within the "normal" queue. There are a number of ways to add more service levels within each of these service types [7], but this document takes the position of specifying the base-level services of Premium and Assured.
より一般的な意味では、プレミアムサービスは、通常のベストエフォートキューよりも高い優先度でエンキューされたパケットを示しています。同様に、確実なサービスは、「通常の」キュー内滴下確率に対して優先的に処理されたパケットを意味します。そこにこれらのサービスタイプの各々内の複数のサービス・レベルを追加するいくつかの方法[7]であるが、この文書は、プレミアムおよびアシュアードのベースレベルのサービスを特定の位置をとります。
The forwarding path mechanisms can be broken down into those that happen at the input interface, before packet forwarding, and those that happen at the output interface, after packet forwarding. Intermediate routers only need to implement the post packet forwarding functions, while leaf and border routers must perform functions on arriving packets before forwarding. We describe the mechanisms this way for illustration; other ways of composing their functions are possible.
転送パスのメカニズムは、パケット転送後、パケット転送前の入力インタフェースで発生するもの、および出力インタフェースで発生するものに分けることができます。中間ルータは、葉と境界ルータが転送する前にパケットを到着上の機能を実行しなければならないが、ポストパケット転送機能を実装する必要があります。我々は、説明のためのメカニズムをこのように説明します。その機能を構成する他の方法も可能です。
Leaf routers are configured with a traffic profile for a particular flow based on its packet header. This functionality has been defined by the RSVP Working Group in RFC 2205. Figure 2 shows what happens to a packet that arrives at the leaf router, before it is passed to the forwarding engine. All arriving packets must have both the A-bit and the P-bit cleared after which packets are classified on their header. If the header does not match any configured values, it is immediately forwarded. Matched flows pass through individual Markers that have been configured from the usage profile for that flow: service class (Premium or Assured), rate (peak for Premium, "expected" for Assured), and permissible burst size (may be optional for Premium). Assured flow packets emerge from the Marker with their A-bits set when the flow is in conformance to its Profile, but the flow is otherwise unchanged. For a Premium flow, the Marker will hold packets when necessary to enforce their configured rate. Thus Premium flow packets emerge from the Marker in a shaped flow with their P-bits set. (It is possible for Premium flow packets to be dropped inside of the Marker as we describe below.) Packets are passed to the forwarding engine when they emerge from Markers. Packets that have either their P or A bits set we will refer to as Marked packets.
リーフルータは、そのパケットのヘッダに基づいて、特定のフローのためのトラフィックプロファイルで構成されています。この機能は、それが転送エンジンに渡される前に、2205図2は、リーフルータに到着するパケットに何が起こるかを示しているRFCにRSVPワーキンググループによって定義されています。すべて到着するパケットは、パケットは、そのヘッダに分類された後、AビットとPビットの両方がクリアされている必要があります。ヘッダは、任意の設定された値と一致しない場合、それが即座に転送されます。 （プレミアムのためにオプションであってもよい）（、確実なため、「期待される」プレミアムのピーク）速度、サービスクラス（Premiumまたはアシュアード）、および許容バーストサイズ：マッチしたフローは、そのフローのための利用状況プロファイルから構成されている個々のマーカーを通過します。確実なフローのパケットは、フローがそのプロファイルに準拠しているときに設定され、そのA-ビットのマーカーから出現するが、流れがそうでなければ変化しません。その設定されたレートを適用するために、必要なときにプレミアム流れについて、マーカーは、パケットを保持します。したがってプレミアム・フローのパケットは、それらのPビットが設定された形状の流れにおけるマーカーから明らかになる。 （プレミアムフローパケットは、我々は以下説明するように、マーカーの内側にドロップされることが可能である。）は、マーカーから出てくるときにパケットが転送エンジンに渡されます。そのPまたはビットのいずれかを持っているパケットは、我々はとしてマークされたパケットを参照します設定します。
Figure 2. Block diagram of leaf router input functionality
リーフルータの入力機能の図2のブロック図
Figure 3 shows the inner workings of the Marker. For both Assured and Premium packets, a token bucket "fills" at the flow rate that was specified in the usage profile. For Assured service, the token bucket depth is set by the Profile's burst size. For Premium service, the token bucket depth must be limited to the equivalent of only one or two packets. (We suggest a depth of one packet in early deployments.) When a token is present, Assured flow packets have their A-bit set to one, otherwise the packet is passed to the forwarding engine. For Premium-configured Marker, arriving packets that see a token present have their P-bits set and are forwarded, but when no token is present, Premium flow packets are held until a token arrives. If a Premium flow bursts enough to overflow the holding queue, its packets will be dropped. Though the flow set up data can be used to configure a size limit for the holding queue (this would be the meaning of a "burst" in Premium service), it is not necessary. Unconfigured holding queues should be capable of holding at least two bandwidth- delay products, adequate for TCP connections. A smaller value might be used to suit delay requirements of a specific application.
図3は、マーカーの内部の仕組みを示しています。確実なとプレミアム両方のパケットの場合は、トークンバケットが使用プロファイルで指定された流量で、「塗りつぶし」。確実なサービスのために、トークンバケットの深さは、プロファイルのバーストサイズによって設定されています。プレミアムサービスでは、トークンバケットの深さは、1つまたは2つのパケットの同等に限定されなければなりません。 （私たちは、早い展開で1つのパケットの深さを示唆している。）トークンが存在する場合、アシュアードフローパケットは、そのA-ビットが1に設定されているそれ以外の場合はパケットが転送エンジンに渡されます。プレミアム構成マーカーについて、本トークンを参照パケット到着すると、それらのPビットがセットされ、転送されていますが、何のトークンが存在しないとき、トークンが到着するまで、プレミアムフローパケットが保持されています。プレミアムフローが保留キューがオーバーフローするのに十分なバーストした場合、そのパケットはドロップされます。データの設定フローが保留キューのサイズ制限を（これはプレミアムサービスの「バースト」の意味になります）を設定するために使用することができますが、それは必要ありません。未設定の保持キューは、少なくとも2つの、帯域幅遅延製品、TCP接続のための適切なを保持することが可能でなければなりません。小さい値は、特定のアプリケーションの遅延要件に適合するために使用される可能性があります。
Figure 3. Markers to implement the two different services
二つの異なるサービスを実現するために3マーカーを図
In practice, the token bucket should be implemented in bytes and a token is considered to be present if the number of bytes in the bucket is equal or larger to the size of the packet. For Premium, the bucket can only be allowed to fill to the maximum packet size; while Assured may fill to the configured burst parameter. Premium traffic is held until a sufficient byte credit has accumulated and this holding buffer provides the only real queue the flow sees in the network. For Assured, traffic, we just test if the bytes in the bucket are sufficient for the packet size and set A if so. If not, the only difference is that A is not set. Assured traffic goes into a queue following this step and potentially sees a queue at every hop along its path.
実際には、トークンバケットは、バイト単位で実施されるべきであり、トークンがバケット内のバイト数が等しいか、またはパケットのサイズに対して大きい場合に存在すると考えられます。プレミアムの場合、バケットは、最大パケットサイズに記入させることができます。アシュアードながら構成されるバーストパラメータに充填することができます。十分なバイトの信用が蓄積されるまでプレミアムトラフィックが開催され、この保持バッファは、フローがネットワークに見ているだけで、実際のキューを提供します。バケット内のバイトは、パケットサイズのために十分であり、もしそうであればAを設定した場合は確実な、トラフィックのために、私達はちょうどテストします。ない場合は、唯一の違いは、Aが設定されていないことです。確実なトラフィックは、このステップの後にキューに入り、潜在的にそのパスに沿ったすべてのホップでキューを見ています。
Each output interface of a router must have two queues and must implement a test on the P-bit to select a packet's output queue. The two queues must be serviced by simple priority, Premium packets first. Each output interface must implement the RED-based RIO mechanism described in [3] on the lower priority queue. RIO uses two thresholds for when to begin dropping packets, a lower one based on total queue occupancy for ordinary best effort traffic and one based on the number of packets enqueued that have their A-bit set. This means that any action preferential to Assured service traffic will only be taken when the queue's capacity exceeds the threshold value for ordinary best effort service. In this case, only unmarked packets will be dropped (using the RED algorithm) unless the threshold value for Assured service is also reached. Keeping an accurate count of the number of A-bit packets currently in a queue requires either testing the A-bit at both entry and exit of the queue or some additional state in the router. Figure 4 is a block diagram of the output interface for all routers.
ルータの各出力インタフェースは、2つのキューを持っている必要がありますし、パケットの出力キューを選択するために、Pビットのテストを実装する必要があります。 2つのキューは、プレミアムパケットまず、簡単な優先順位によってサービスされなければなりません。各出力インタフェースは、優先度の低いキューの[3]に記載のREDベースRIOメカニズムを実装しなければなりません。 RIOは、パケットをドロップ開始するときのための2つの閾値、最高の経常エフォートトラフィックとそのA-ビットがセットされているキューに入れられたパケットの数に基づいて、いずれかの合計キュー占有に基づいて、下位1を使用しています。これは、キューの容量は、通常のベストエフォート型サービスのためのしきい値を超えたときに確実なサービスのトラフィックに優先何らかのアクションが唯一取られることを意味します。この場合、唯一のマークされていないパケットは、確実なサービスのための閾値も到達していない限り（REDのアルゴリズムを使用して）削除されます。現在キューにビットパケットの数の正確なカウントを維持することのいずれかが必要ですルータのキューまたはいくつかの追加の状態の入り口と出口の両方でAビットをテストします。図4は、すべてのルータの出力インタフェースのブロック図です。
Figure 4. Router output interface for two-bit architecture
2ビットのアーキテクチャについては、図4のルータ出力インタフェース
The packet output of a leaf router is thus a shaped stream of packets with P-bits set mingled with an unshaped best effort stream of packets, some of which may have A-bits set. Premium service clearly cannot starve best effort traffic because it is both burst and bandwidth controlled. Assured service might rely only on a conservative allocation to prevent starvation of unmarked traffic, but bursts of Assured traffic might then close out best-effort traffic at bottleneck queues during congestive periods.
リーフルータのパケット出力は、このように設定ビットを有することができるいくつかのパケットの不定形ベストエフォートストリーム混じりPビットがセットされたパケットの成形ストリームです。それはバーストと帯域制御の両方であるため、プレミアムサービスは明らかにベストエフォートトラフィックを餓死することはできません。確実なサービスは、マークされていないトラフィックの飢餓を防ぐために、保守的な配分に依存しているかもしれませんが、確実なトラフィックのバーストは、うっ血性期間中のボトルネックキューでベストエフォート型トラフィックを閉じるかもしれません。
After [3], we designate the forwarding path objects that test flows against their usage profiles "Profile Meters". Border routers will require Profile Meters at their input interfaces. The bilateral agreement between adjacent administrative domains must specify a peak rate on all P traffic and a rate and burst for A traffic (and possibly a start time and duration). A Profile Meter is required at the ingress of a trust region to ensure that differentiated service packet flows are in compliance with their agreed-upon rates. Non-compliant packets of Premium flows are discarded while non-compliant packets of Assured flows have their A-bits reset. For example, in figure 1, if the ISP has agreed to supply Company A with r bytes/sec of Premium service, P-bit marked packets that enter the ISP through the link from Company A will be dropped if they exceed r. If instead, the service in figure 1 was Assured service, the packets would simply be unmarked, forwarded as best effort.
[3]の後、我々は、転送パス試験は、それらの使用プロファイル「プロファイルメーター」に対して流れるオブジェクトを指定します。ボーダールータは入力インターフェイスでのプロフィールメーターが必要になります。隣接する管理ドメイン間の双務契約は、すべてのPトラフィックのピーク速度と速度を指定し、（おそらくと開始時刻と継続時間）トラフィックのためにバーストしなければなりません。プロフィールメーターは差別化されたサービスのパケットフローがその合意された速度に適合していることを確認するために、信頼領域の入口で必要とされます。確実な流れの非準拠のパケットはそのA-ビットがリセットされていながら、プレミアム・フローの非準拠のパケットが破棄されます。それらがRを超えた場合、例えば、図1に、ISPは、プレミアムサービスのRバイト/秒でA社に供給することに同意した場合、A社からのリンクを介してISPに入るPビットマーキングされたパケットはドロップされます。代わりに、図1のサービスは、サービスをアシュアードた場合、パケットは単にベストエフォートとして転送、マークされていないだろう。
The simplest border router input interface is a Profile Meter constructed from a token bucket configured with the contracted rate across that ingress link (see figure 5). Each type, Premium or Assured, and each interface must have its own profile meter corresponding to a particular class across a particular boundary. (This is in contrast to models where every flow that crosses the boundary must be separately policed and/or shaped.) The exact mechanisms required at a border router input interface depend on the allocation policy deployed; a more complex approach is presented in section 4.
最も単純な境界ルータの入力インタフェースは、入力リンク（図5参照）の両端の収縮率で設定トークンバケットから構成プロファイルメーターです。各タイプ、Premiumまたはアシュアード、および各インターフェイスは、特定の境界を越えて特定のクラスに対応した独自のプロファイルメーターを持っている必要があります。 （これは、境界を越えるすべての流れが別々にポリシングおよび/または成形されなければならないモデルとは対照的である。）境界ルータ入力インタフェースに必要とされる正確な機構は展開割り当てポリシーに依存します。より複雑なアプローチがセクション4に示されています。
Figure 5. Border router input interface Profile Meters
図5.ボーダールータの入力インターフェイスプロフィールメータ
Section 2.3 introduced the forwarding path objects of Markers and Profile Meters. In this section we specify the primitive building blocks required to compose them. The primitives are: general classifier, bit-pattern classifier, bit setter, priority queues, policing token bucket and shaping token bucket. These primitives can compose a Marker (either a policing or a shaping token bucket plus a bit setter) and a Profile Meter (a policing token bucket plus a dropper or bit setter).
2.3節は、マーカーの転送パスオブジェクトとプロファイルメーターを導入しました。このセクションでは、それらを構成するために必要な原始的なビルディングブロックを指定します。プリミティブは以下のとおりです。一般的な分類器、ビット・パターン分類、ビットセッター、プライオリティキュー、トークンバケットポリシングおよびトークンバケットを形作ります。これらのプリミティブは、マーカー（ポリシングまたはシェーピングトークンバケットプラスビット設定部のいずれか）とプロファイルメーター（トークンバケットポリシングプラススポイト又はビットセッター）を構成することができます。
General Classifier: Leaf or first-hop routers must perform a transport-level signature matching based on a tuple in the packet header, a functionality which is part of any RSVP-capable router. As described above, packets whose tuples match one of the configured flows are conformance tested and have the appropriate service bit set. This function is memory- and processing-intensive, but is kept at the edges of the network where there are fewer flows.
一般的な分類：葉又はファーストホップルータは、パケットヘッダ内のタプルに基づいてトランスポートレベル署名マッチング、任意のRSVP対応ルータの一部である機能を実行しなければなりません。上述したように、そのタプルのマッチ構成フローのパケットは、適合試験し、適切なサービス・ビット・セットを有しています。この関数は、メモリ - と処理集約的であるが、少数のフローが存在するネットワークのエッジで保持されます。
Bit-pattern classifier: This primitive comprises a simple two-way decision based on whether a particular bit-pattern in the IP header is set or not. As in figure 4, the P-bit is tested when a packet arrives at a non-leaf router to determine whether to enqueue it in the high priority output queue or the low priority packet queue. The A-bit of packets bound for the low priority queue is tested to 1) increment the count of Assured packets in the queue if set and 2) determine which drop probability will be used for that packet. Packets exiting the low priority queue must also have the A-bit tested so that the count of enqueued Assured packets can be decremented if necessary.
ビットパターン分類器：このプリミティブは、IPヘッダ内の特定のビットパターンが設定されているか否かに基づいて、単純な双方向の決定を含みます。パケットが高優先度出力キューまたは低優先パケットキューにエンキューするかどうかを決定するために、非リーフ・ルータに到着したとき、図4のように、Pビットが検査されます。低優先度キューに向かうパケットのAビットが設定されている場合、キューで保証パケットのカウントをインクリメントし、2）そのパケットのために使用されるドロップ確率を決定）1に試験されます。低優先度のキューを出たパケットはまた、必要に応じて、キューに入れられた確実なパケットのカウントをデクリメントすることができるようにAビットをテストしている必要があります。
Bit setter: The A-bits and P-bits must be set or cleared in several places. A functional block that sets the appropriate bits of the IP header to a configured bit-pattern would be the most general.
ビットセッター：A-ビットとPビットがいくつかの場所で設定またはクリアする必要があります。構成されたビットパターンにIPヘッダの適切なビットを設定し、機能ブロックは、最も一般的であろう。
Priority queues: Every network element must include (at least) two levels of simple priority queueing. The high priority queue is for the Premium traffic and the service rule is to send packets in that queue first and to exhaustion. Recall that Premium traffic must never be oversubscribed, thus Premium traffic should see little or no queue.
プライオリティキューは：すべてのネットワーク要素は、（少なくとも）シンプルなプライオリティキューイングの2つのレベルが含まれている必要があります。高優先度キューは、プレミアムトラフィックのためのものであり、サービスルールは、第一および枯渇にそのキューにパケットを送信することです。プレミアムトラフィックがオーバーサブスクライブしてはならないことを思い出して、これプレミアムトラフィックがほとんど、あるいはまったくキューが表示されるはずです。
Shaping token bucket:This is the token bucket required at the leaf router for Premium traffic and shown in figure 3. As we shall see, shaping is also useful at egress points of a trust region. An arriving packet is immediately forwarded if there is a token present in the bucket, otherwise the packet is enqueued until the bucket contains tokens sufficient to send it. Shaping requires clocking mechanisms, packet memory, and some state block for each flow and is thus a memory and computation-intensive process.
トークンバケットシェーピング：これはプレミアム・トラフィックのためのリーフルータで必要なトークンバケットであり、我々は見るように、図3に示すように、整形はまた、信頼領域の出口点で便利です。バケツに存在するトークンがある場合、バケツはそれを送信するのに十分なトークンが含まれるまで、到着したパケットは、すぐにそれ以外のパケットがキューイングされ、転送されます。成形は、クロック機構、パケットメモリ、及び各フローのためのいくつかの状態のブロックを必要とし、したがってメモリおよび計算集約的なプロセスです。
Policing token bucket: This is the token bucket required for Profile Meters and shown in figure 5. Policing token buckets never hold arriving packets, but check on arrival to see if a token is available for the packet's service class. If so, the packet is forwarded immediately. If not, the policing action is taken, dropping for Premium and reclassifying or unmarking for Assured.
トークンバケットポリシング：これは、プロファイルメータに必要と5.ポリシングトークンバケットは、到着パケットを保持しませんが、トークンは、パケットのサービスクラスのために利用可能であるかどうかを確認するために到着時にチェック決して図のトークンバケットです。その場合、パケットは即座に転送されます。ない場合は、ポリシングアクションは、プレミアムのために落下し、再分類するか、確実なのためにマーク解除、取られます。
Clearly, mechanisms are required to communicate the information about the request to the leaf router. This configuration information is the rate, burst, and whether it is a Premium or Assured type. There may also need to be a specific field to set or clear this configuration. This information can be passed in a number of ways, including using the semantics of RSVP, SNMP, or directly set by a network administrator in some other way. There must be some mechanisms for authenticating the sender of this information. We expect configuration to be done in a variety of ways in early deployments and a protocol and mechanism for this to be a topic for future standards work.
明らかに、機構は、リーフルータへの要求に関する情報を通信するために必要とされます。この構成情報はバーストレートであり、プレミアムまたは確実なタイプであるかどうか。また、この構成を設定するか、クリアする特定のフィールドがあるように必要があるかもしれません。この情報は、RSVP、SNMPのセマンティクスを使用することを含むいくつかの方法で渡された、または直接、他のいくつかの方法で、ネットワーク管理者によって設定することができます。この情報の送信者を認証するためのいくつかのメカニズムが存在しなければなりません。私たちは、早い展開で様々な方法で行うべき設定し、このためのプロトコルやメカニズムは将来の標準化作業のためのトピックであることを期待しています。
The requirements of shapers motivate their placement at the edges of the network where the state per router can be smaller than in the middle of a network. The greatest burden of flow matching and shaping will be at leaf routers where the speeds and buffering required should be less than those that might be required deeper in the network. This functionality is not required at every network element on the path. Routers that are internal to a trust region will not need to shape traffic. Border routers may need or desire to shape the aggregate flow of Marked packets at their egress in order to ensure that they will not burst into non-compliance with the policing mechanism at the ingress to the other domain (though this may not be necessary if the in-degree of the router is low). Further, the shaping would be applied to an aggregation of all the Premium flows that exit the domain via that path, not to each flow individually.
シェイパーの要件は、ルータごとに状態がネットワークの途中でよりも小さくすることができるネットワークのエッジでその配置のやる気を引き出します。フロー・マッチングとシェーピングの最大の負担が必要な速度とバッファリングがネットワークに深く必要とされるかもしれないものよりも小さくなければならないリーフルータになります。この機能は、パス上のすべてのネットワーク要素で必要とされていません。信頼領域の内部にあるルータは、トラフィックをシェーピングする必要はありません。境界ルータがあれば、これは必要ではないかもしれないけれども、彼らは（他のドメインへの入口でポリシング機構の不遵守に破裂しないことを確実にするために、その出口でマーキングされたパケットの集約フローを成形するために必要又は望むかもしれません中度のルータの）低いです。さらに、成形は個々にその経路を介してではなく、各フローにその出口にドメインを流れる全プレミアムの集合に適用されます。
These mechanisms are within reach of today's technology and it seems plausible to us that Premium and Assured services are all that is needed in the Internet. If, in time, these services are found insufficient, this architecture provides a migration path for delivering other kinds of service levels to traffic. The A- and P-bits would continue to be used to identify traffic that gets Marked service, but further filter matching could be done on packet headers to differentiate service levels further. Using the bits this way reduces the number of packets that have to have further matching done on them rather than filtering every incoming packet. More queue levels and more complex scheduling could be added for P-bit traffic and more levels of drop priority could be added for A-bit traffic if experience shows them to be necessary and processing speeds are sufficient. We propose that the services described here be considered as "at least" services. Thus, a network element should at least be capable of mapping all P-bit traffic to Premium service and of mapping all A-bit traffic to be treated with one level of priority in the "best effort" queue (it appears that the single level of A-bit traffic should map to a priority that is equivalent to the best level in a multi-level element that is also in the path).
これらのメカニズムは、今日の技術の適用範囲内にあり、プレミアムと確実なサービスがインターネットで必要とされるすべてであることを私たちにもっともらしく思えます。時間的に、これらのサービスが不十分発見された場合、このアーキテクチャは、トラフィックにサービスレベルの他の種類を提供するための移行パスを提供します。 A-及びPビットは、サービスマーク取得したトラフィックを識別するために使用され続けるだろうが、さらにフィルタマッチングは、さらにサービスレベルを区別するためにパケットヘッダに行うことができます。ビットを使用して、この方法は、むしろすべての着信パケットをフィルタリングよりもマッチングがそれらに行っているしなければならないパケットの数を減少させます。複数のキュー・レベルおよびより複雑なスケジューリングが経験は彼らが必要であると示しており、処理速度が十分である場合Pビットトラフィックとドロップ優先順位のより多くのレベルがビットトラフィックに付加することができるために添加することができます。私たちは、ここで説明するサービスは、「少なくとも」のサービスとして考えられることを提案します。このように、ネットワーク要素は、少なくともプレミアムサービスにし、「ベストエフォート」キュー内の優先順位の1つのレベルで処理されるすべてのビットのトラフィックをマッピングするすべてのPビットのトラフィックをマッピングすることが可能でなければならない（それが表示される単一レベルビットのトラフィックパスでも）であるマルチレベル要素で最高のレベルに相当する優先度にマッピングするべきです。
On the other hand, what is the downside of deploying an architecture for both classes of service if later experience convinces us that only one of them is needed? The functional blocks of both service classes are similar and can be provided by the same mechanism, parameterized differently. If Assured service is not used, very little is lost. A RED-managed best effort queue has been strongly recommended in [4] and, to the extent that the deployment of this architecture pushes the deployment of RED-managed best effort queues, it is clearly a positive. If Premium service goes unused, the two-queues with simple priority service is not required and the shaping function of the Marker may be unused, thus these would impose an unnecessary implementation cost.
一方、後で経験がそれらの一方のみが必要とされていることを私たちを説得する場合、サービスの両方のクラスのためのアーキテクチャを展開する欠点は何ですか？両方のサービスクラスの機能ブロックは類似しており、異なる、同一の機構によってパラメータ化を提供することができます。アシュアードサービスを使用しない場合は、非常に少ないが失われます。 RED-管理のベストエフォートキューを強くで推奨されている[4]と、このアーキテクチャの展開がRED-管理のベストエフォートキューの展開をプッシュする程度に、それは明らかに陽性です。プレミアムサービスが未使用になった場合、簡単な優先サービスを持つ2つの-キューが必要とされず、マーカーのシェーピング機能が未使用であってもよいし、従って、これらは、不必要な実装コストを課します。
Thus far we have focused on the service definitions and the forwarding path mechanisms. We now turn to the problem of allocating the level of Marked traffic throughout the Internet. We observe that most organizations have fixed portions of their budgets, including data communications, that are determined on an annual or quarterly basis. Some additional monies might be attached to specific projects for discretionary costs that arise in the shorter term. In turn, service providers (ISPs and NSPs) must do their planning on annual and quarterly bases and thus cannot be expected to provide differentiated services purely "on call". Provisioning sets up static levels of Marked traffic while call set-up creates an allocation of Marked traffic for a single flow's duration. Static levels can be provisioned with time-of-day specifications, but cannot be changed in response to a dynamic message. We expect both kinds of bandwidth allocation to be important. The purchasers of Marked services can generally be expected to work on longer-term budget cycles where these services will be accounted for similarly to many information services today. A mail-order house may wish to purchase a fixed allocation of bandwidth in and out of its web-server to give potential customers a "fast" feel when browsing their site. This allocation might be based on hit rates of the previous quarter or some sort of industry-based averages. In addition, there needs to be a dynamic allocation capability to respond to particular events, such as a demonstration, a network broadcast by a company's CEO, or a particular network test. Furthermore, a dynamic capability may be needed in order to meet a precommitted service level when the particular source or destination is allowed to be "anywhere on the Internet". "Dynamic" covers the range from a telephoned or e-mailed request to a signalling type model. A strictly statically allocated scenario is expected to be useful in initial deployment of differentiated services and to make up a major portion of the Marked traffic for the forseeable future.
これまでのところ、我々はサービスの定義と転送パスメカニズムに焦点を当てています。私たちは今、インターネット全体でマークされたトラフィックのレベルを割り当てるの問題に目を向けます。私たちは、ほとんどの組織では、年間または四半期ごとに決定されたデータ通信を含む彼らの予算の一部を、固定されていることを確認します。いくつかの追加の資金は、短期的に発生する自由裁量経費のために、特定のプロジェクトに添付される可能性があります。ターンでは、サービス・プロバイダー（ISPやNSPのは）年次および四半期ベースでの彼らの計画を行う必要がありますので、「コールで」純粋に差別化されたサービスを提供することを期待することはできません。呼設定は、単一のフローの持続のためにマークトラフィックの割り当てを作成しながら、プロビジョニングは、マークトラフィックの静的レベルを設定します。静的レベルは、時刻仕様にプロビジョニングすることができるが、動的なメッセージに応答して変更することができません。私たちは、帯域幅の割り当ての両方の種類が重要であると期待しています。マーク・サービスの購入者は、一般的に、これらのサービスは、今日、多くの情報サービスと同様に計上される長期的な予算サイクルで動作するように期待することができます。通販家は自分のサイトを閲覧する際、「速い」と感じ潜在的な顧客を与えることで、そのWebサーバのうち、帯域幅の固定割り当てを購入することもできます。この割り当ては、ヒット前四半期の速度や業界ベースの平均値のいくつかの並べ替えに基づいてされる可能性があります。また、このようなデモは、同社の最高経営責任者（CEO）によってブロードキャストネットワーク、または特定のネットワークテストなどの特定のイベントに対応するための動的割り当て機能が必要です。さらに、動的能力は、特定の送信元または送信先が「どこでもインターネット上で」が許可されるプリコミットサービスレベルを満たすために必要とされ得ます。 「動的」に電話または電子メールで要求からのシグナリング型モデルの範囲をカバーします。厳密に静的に割り当てられたシナリオは、差別化サービスの初期導入に有用であるとし、予見可能な将来のためにマークトラフィックの大部分を占めると予想されます。
Without a "per call" dynamic set up, the preconfiguring of usage profiles can always be construed as "paying for bits you don't use" whether the type of service is Premium or Assured. We prefer to think of this as paying for the level of service that one expects to have available at any time, for example paying for a telephone line. A customer might pay an additional flat fee to have the privilege of calling a wide local area for no additional charge or might pay by the call. Although a customer might pay on a "per call" basis for every call made anywhere, it generally turns out not to be the most economical option for most customers. It's possible similar pricing structures might arise in the internet.
「呼び出しごと」のダイナミックなセットアップがなければ、使用プロファイルの事前設定は、常にサービスの種類がPremiumまたは保証されているかどうか「のビットのために支払うことは、あなたが使用していない」と解釈することができます。私たちは、電話回線の支払い例えば、1がいつでも利用できる持っていることを期待するサービスのレベルを支払うと考えることを好みます。お客様は、追加料金なしの広い地域を呼び出しまたはコールで支払う可能性があるの権限を持っているために追加の定額料金を支払うことがあります。顧客はどこでも行われたすべてのコールのための「呼び出しごと」に基づき支払うかもしれませんが、それは一般的に、ほとんどの顧客のための最も経済的な選択肢ではないことが判明します。これは、同様の価格体系は、インターネットで発生する可能性が可能です。
We use Allocation to refer to the process of making Marked traffic commitments anywhere along this continuum from strictly preallocated to dynamic call set-up and we require an Allocation architecture capable of encompassing this entire spectrum in any mix. We further observe that Allocation must follow organizational hierarchies, that is each organization must have complete responsibility for the Allocation of the Marked traffic resource within its domain. Finally, we observe that the only chance of success for incremental deployment lies in an Allocation architecture that is made up of bilateral agreements, as multilateral agreements are much too complex to administer. Thus, the Allocation architecture is made up of agreements across boundaries as to the amount of Marked traffic that will be allowed to pass. This is similar to "settlement" models used today.
私たちは、どこでも、厳密ダイナミックコールセットアップに事前に割り当てから、この連続体に沿ってマークされたトラフィックの約束を作るプロセスを参照するために割り当てを使用して、我々はすべてのミックスの中で、このスペクトル全体を網羅できる割り当てアーキテクチャが必要です。我々はさらにその配分は、組織階層に従わなければならない観察、それはそれぞれの組織がそのドメイン内のマークされたトラフィック資源の配分のための完全な責任を持っている必要があります。最後に、我々は、増分の展開の成功の唯一のチャンスは、多国間協定があまりにも複雑で管理するにはあるとして、二国間協定で構成されて割り当てアーキテクチャであることを確認します。このように、割り当てアーキテクチャは通過を許可されるマークされたトラフィックの量についての境界を越えた協定で構成されています。これは、今日使用される「決済」のモデルに似ています。
The goal of differentiated services is controlled sharing of some organization's Internet bandwidth. The control can be done independently by individuals, i.e., users set bit(s) in their packets to distinguish their most important traffic, or it can be done by agents that have some knowledge of the organization's priorities and policies and allocate bandwidth with respect to those policies. Independent labeling by individuals is simple to implement but unlikely to be sufficient since it's unreasonable to expect all individuals to know all their organization's priorities and current network use and always mark their traffic accordingly. Thus this architecture is designed with agents called bandwidth brokers (BB) [2], that can be configured with organizational policies, keep track of the current allocation of marked traffic, and interpret new requests to mark traffic in light of the policies and current allocation.
差別化されたサービスの目標は、いくつかの組織のインターネット帯域幅の共有を制御しています。コントロールは、個人が独立して行うことができ、すなわち、ユーザーが彼らの最も重要なトラフィックを区別するために、そのパケット内のビット（複数可）を設定し、またはそれは、組織の優先事項のいくつかの知識を持っているエージェントおよびポリシーによって行われ、に対する帯域幅を割り当てることができますこれらのポリシー。それはすべて、組織の優先順位と現在のネットワークの使用を知っているすべての個人を期待するのは無理だし、常にそれに応じてトラフィックをマーキングするので個人による独立した標識は、実装が簡単ではあるが十分ではないようです。したがって、このアーキテクチャは、マークされたトラフィックの現在の割り当てを追跡し、政策や現在の割り当ての光の中でトラフィックをマーキングするための新たな要求を解釈し、[2]、それは組織のポリシーを設定することができますエージェントと呼ばれる帯域幅ブローカー（BB）で設計されています。
We note that such agents are inherent in any but the most trivial notions of sharing. Neither individuals nor the routers their packets transit have the information necessary to decide which packets are most important to the organization. Since these agents must exist, they can be used to allocate bandwidth for end-to-end connections with far less state and simpler trust relationships than deploying per flow or per filter guarantees in all network elements on an end-to-end path. BBs make it possible for bandwidth allocation to follow organizational hierarchies and, in concert with the forwarding path mechanisms discussed in section 3, reduce the state required to set up and maintain a flow over architectures that require checking the full flow header at every network element. Organizationally, the BB architecture is motivated by the observation that multilateral agreements rarely work and this architecture allows end-to-end services to be constructed out of purely bilateral agreements. BBs only need to establish relationships of limited trust with their peers in adjacent domains, unlike schemes that require the setting of flow specifications in routers throughout an end-to-end path. In practical technical terms, the BB architecture makes it possible to keep state on an administrative domain basis, rather than at every router and the service definitions of Premium and Assured service make it possible to confine per flow state to just the leaf routers.
私たちは、このような薬剤は、共有の最も些細な概念が、いずれにも固有のものであることに注意してください。どちらも個人も、ルータ、そのパケットの通過は、組織にとって最も重要であるパケットを決定するために必要な情報を持っています。これらの薬剤が存在しなければならないので、彼らははるかに少ない状態とエンドツーエンドのパス上のすべてのネットワーク要素にフローごとまたはフィルタの保証ごとに配備するよりも単純な信頼関係で、エンドツーエンド接続の帯域幅を割り当てるために使用することができます。掲示板ことにより帯域幅割り当て組織階層に従うと、セクション3で説明した転送パス機構と協働して、設定およびすべてのネットワーク要素において全流ヘッダをチェックする必要がアーキテクチャ上の流れを維持するために必要な状態を低減するために作ります。組織的、BBアーキテクチャは多国間協定はほとんど機能していないという観察によって動機づけと、このアーキテクチャは、エンドツーエンドのサービスは純粋に二国間協定の外に構築することができますされています。 BBSが唯一のエンド・ツー・エンドのパスを通じてルータにおけるフロー仕様の設定を必要とするスキームとは異なり、隣接するドメインでの仲間との限られた信頼関係を確立する必要があります。実用的な専門用語では、BBアーキテクチャは、それが可能ではなく、すべてのルータでかつプレミアムアシュアードサービスのサービス定義は、それが可能なだけでリーフルータへの流れ状態ごとに制限するように作り、管理ドメインごとに状態を保つことができます。
BBs have two responsibilities. Their primary one is to parcel out their region's Marked traffic allocations and set up the leaf routers within the local domain. The other is to manage the messages that are sent across boundaries to adjacent regions' BBs. A BB is associated with a particular trust region, one per domain. A BB has a policy database that keeps the information on who can do what when and a method of using that database to authenticate requesters. Only a BB can configure the leaf routers to deliver a particular service to flows, crucial for deploying a secure system. If the deployment of Differentiated Services has advanced to the stage where dynamically allocated, marked flows are possible between two adjacent domains, BBs also provide the hook needed to implement this. Each domain's BB establishes a secure association with its peer in the adjacent domain to negotiate or configure a rate and a service class (Premium or Assured) across the shared boundary and through the peer's domain. As we shall see, it is possible for some types of service and particularly in early implementations, that this "secure association" is not automatic but accomplished through human negotiation and subsequent manual configuration of the adjacent BBs according to the negotiated agreement. This negotiated rate is a capability that a BB controls for all hosts in its region.
BBSが2つの責任を持っています。彼らの主な一つは、その地域の著しい交通配分を区分けし、ローカルドメイン内のリーフルータを設定することです。他には、隣接する領域ベストバンドに境界を越えて送信されるメッセージを管理することです。 BBは、特定の信頼領域、ドメインごとに1つに関連付けられています。 BBは、どのようなときにリクエスタを認証するために、そのデータベースを使用する方法を行うことができる人に関する情報を保持ポリシーデータベースを持っています。唯一のBBは、安全なシステムを展開するための重要な、フローに特定のサービスを提供するために、リーフルータを設定することができます。差別化サービスの展開が動的に割り当てられ、マークフローは隣接する二つのドメイン間で可能な段階まで進んだ場合は、掲示板にも、これを実現するために必要なフックを提供しています。各ドメインのBBは、交渉または共有境界を横切ってピアのドメインを介してレート及びサービスクラス（Premiumまたはアシュアード）を設定する隣接ドメイン内のピアとのセキュアなアソシエーションを確立します。私たちが見るように、それがこの「安全な関連付けは、」自動人間交渉と交渉し合意によると、隣接するベストバンドのその後の手動構成を介して行わないことを、サービスの、特に初期の実装では、いくつかのタイプのために可能です。これで交渉レートは、BBは、その地域内のすべてのホストのための制御機能です。
When an allocation is desired for a particular flow, a request is sent to the BB. Requests include a service type, a target rate, a maximum burst, and the time period when service is required. The request can be made manually by a network administrator or a user or it might come from another region's BB. A BB first authenticates the credentials of the requester, then verifies there exists unallocated bandwidth sufficient to meet the request. If a request passes these tests, the available bandwidth is reduced by the requested amount and the flow specification is recorded. In the case where the flow has a destination outside this trust region, the request must fall within the class allocation through the "next hop" trust region that was established through a bilateral agreement of the two trust regions. The requester's BB informs the adjacent region's BB that it will be using some of this rate allocation. The BB configures the appropriate leaf router with the information about the packet flow to be given a service at the time that the service is to commence. This configuration is "soft state" that the BB will periodically refresh. The BB in the adjacent region is responsible for configuring the border router to permit the allocated packet flow to pass and for any additional configurations and negotiations within and across its borders that will allow the flow to reach its final destination.
割り当てが特定のフローのために所望される場合、要求はBBに送られます。要求は、サービスタイプ、目標速度、最大バースト、およびサービスが必要とされる時間を含みます。リクエストは、ネットワーク管理者またはユーザーが手動で行うことができるか、それは別の領域のBBから来るかもしれません。 BBは、最初の要求を満たすために十分な未割り当て帯域幅が存在を確認し、その後、依頼者の資格情報を認証します。要求がこれらのテストに合格した場合、利用可能な帯域幅は、要求された量だけ減少され、フロー仕様が記録されます。流れがこの信頼領域外の宛先を有する場合、要求は、二つの信頼領域の両側の合意を介して確立された「次のホップ」信頼領域を介してクラスの割り当て内に入らなければなりません。要求者のBBは、このレート割り当ての一部を使用することに隣接する地域のBBを通知します。 BBは、サービスが開始している時にサービスを与えられるべきパケットのフローに関する情報を適切なリーフルータを設定します。この構成は、BBが定期的に更新されますことを「ソフト状態」です。隣接する領域におけるBBは、合格のために割り当てられたパケットフローを可能にするために、境界ルータを設定するため、フローはその最終目的地に到達することができます内およびその国境を越えたいかなる追加の構成との交渉を担当しています。
At DMZs, there must be an unambiguous way to determine the local source of a packet. An interface's source could be determined from its MAC address which would then be used to classify packets as coming across a logical link directly from the source domain corresponding to that MAC address. Thus with this understanding we can continue to use figures illustrating a single pipe between two different domains.
DMZのでは、パケットのローカルソースを決定する明白な方法がなければなりません。インタフェースのソースは、そのMACアドレスに対応するソースドメインから直接論理リンクを横切って来たようにパケットを分類するために使用されるであろう、そのMACアドレスから決定することができます。したがって、この理解して、我々は2つの異なるドメイン間に単一のパイプを示す数値を使用し続けることができます。
In this way, all agreements and negotiations are performed between two adjacent domains. An initial request might cause communication between BBs on several domains along a path, but each communication is only between two adjacent BBs. Initially, these agreements will be prenegotiated and fairly static. Some may become more dynamic as the service evolves.
このように、全ての契約交渉は、隣接する2つのドメイン間で行われます。最初の要求は、パスに沿って複数のドメイン掲示板間の通信が発生することがありますが、各通信は、2個のだけの隣接するベストバンドの間にあります。最初は、これらの契約はprenegotiatedされ、かなり静的。いくつかのサービスが進化するにつれ、よりダイナミックになることがあります。
This section gives examples of BB transactions in a non-trivial, multi-transit-domain Internet. The BB framework allows operating points across a spectrum from "no signalling across boundaries" to "each flow set up dynamically". We might expect to move across this spectrum over time, as the necessary mechanisms are ubiquitously deployed and BBs become more sophisticated, but the statically allocated portions of the spectrum should always have uses. We believe the ability to support this wide spectrum of choices simultaneously will be important both in incremental deployment and in allowing ISPs to make a wide range of offerings and pricings to users. The examples of this section roughly follow the spectrum of increasing sophistication. Note that we assume that domains contract for some amount of Marked traffic which can be requested as either Assured or Premium in each individual flow setup transaction. The examples say "Marked" although actual transactions would have to specify either Assured or Premium.
このセクションでは、非自明な、マルチトランジットドメインのインターネットにおけるBB取引の例を示します。 BBフレームワークは、「動的に設定各フロー」から「境界を越えないシグナル」からスペクトルにわたって動作点を可能にします。我々は必要なメカニズムが普遍的に展開し、ベストバンドがより高度になるが、スペクトルの静的に割り当てられた部分はいつもの用途を持つべきであるされているように、時間をかけてこのスペクトルを横切って移動することが予想されます。私たちは、同時に選択肢のこの広いスペクトルをサポートする能力は、増分の展開にし、ISPがユーザーに提供し、pricingsの広い範囲を作成することが可能で、両方が重要になると考えています。このセクションの例は、おおよそ高度化のスペクトルに従います。私たちは、個々のフローのセットアップトランザクションで保証またはプレミアムいずれかとして要求することができるマークされたトラフィックの一部金額をそのドメインの契約を前提としています。実際の取引アシュアードまたはプレミアムのいずれかを指定する必要がありますが、例として、「マーク」と言います。
A statically configured example with no BB messages exchanged: Here all allocations are statically preallocated through purely bilateral agreements between users (individual TCPs, individual hosts, campus networks, or whole ISPs) [6]. The allocations are in the form of usage profiles of rate, burst, and a time during which that profile is to be active. Users and providers negotiate these Profiles which are then installed in the user domain BB and in the provider domain BB. No BB messages cross the boundary; we assume this negotiation is done by human representatives of each domain. In this case, BBs only have to perform one of their two functions, that of allocating this Profile within their local domain. It is even possible to set all of this suballocations up in advance and then the BB only needs to set up and tear down the Profile at the proper time and to refresh the soft state in the leaf routers. From the user domain BB, the Profile is sent as soft state to the first hop router of the flow during the specified time. These Profiles might be set using RSVP, a variant of RSVP, SNMP, or some vendor-specific mechanism. Although this static approach can work for all Marked traffic, due to the strictly not oversubscribed requirement, it is only appropriate for Premium traffic as long as it is kept to a small percentage of the bottleneck path through a domain or is otherwise constrained to a well-known behavior. Similar restrictions might hold for Assured depending on the expectation associated with the service.
なしBBメッセージで静的に設定例では、交換：ここではすべての割り当てが静的ユーザ間純粋双務契約（個々のTCP、個々のホスト、キャンパスネットワーク、または全体のISP）を介して事前に割り当てられた[6]。割り当ては、レート、バースト、及びそのプロファイルがアクティブであることである時間の使用プロファイルの形態です。ユーザーとプロバイダは、ユーザーのドメインBBにし、プロバイダドメインBBにインストールされているこれらのプロファイルを交渉します。いいえBBメッセージが境界を越えていません。私たちは、この交渉は、各ドメインの人間の代表によって行われると仮定します。この場合、掲示板は、その二つの機能のいずれか、それらのローカルドメイン内でこのプロファイルを割り当てることを実行しなければなりません。事前にこのsuballocationsのすべてを設定することも可能ですし、その後BBしか設定し、適切な時間にプロフィールを取り壊すとリーフルータに柔らかい状態をリフレッシュする必要があります。ユーザードメインBBからは、プロファイルが指定された時間の間、流れの最初のホップルータに柔らかい状態として送信されます。これらのプロファイルは、RSVP、RSVP、SNMP、またはいくつかのベンダー固有のメカニズムのバリアントを使用して設定されることがあります。この静的なアプローチが原因厳密にオーバーサブスクライブない要求に、すべてのマークされたトラフィックのために働くことができますが、それは限り、それはドメインを介してボトルネックパスの小さな割合に保たれているか、それ以外のウェルに制約されているようプレミアムトラフィックにのみ適して-known行動。同様の制限は、サービスに関連付けられている期待に応じて、確実なのために保持しているかもしれません。
In figure 6, we show an example of setting a Profile in a leaf router. A usage profile has been negotiated with the ISP for the entire domain and the BB parcels it out among individual flows as requested. The leaf router mechanism is that shown in figure 3, with the token bucket set to the parameters from the usage profile. The ISP's BB would configure its own Profile Meter at the ingress router from that customer to ensure the Profile was maintained. This mechanism was shown in figure 5. We assume that the time duration and start times for any Profile to be active are maintained in the BB. The Profile is sent to the ingress device or cleared from the ingress device by messages sent from the BB. In this example, we assume that van@lbl wants to talk to ddc@mit. The LBL-BB is sent a request from Van asking that premium service be assigned to a flow that is designated as having source address "V:4" and going to destination address "D:8". This flow should be configured for a rate of 128kb/sec and allocated from 1pm to 3pm. The request must be "signed" in a secure, verifiable manner. The request might be sent as data to the LBL-BB, an e-mail message to a network administrator, or in a phone call to a network administrator. The LBL-BB receives this message, verifies that there is 128kb/sec of unused Premium service for the domain from 1-3pm, then sends a message to Leaf1 that sets up an appropriate Profile Meter. The message to Leaf1 might be an RSVP message, or SNMP, or some proprietary method. All the domains passed must have sufficient reserve capacity to meet this request.
図6では、我々は、リーフルータでプロファイルを設定する例を示しています。使用プロファイルは、要求されるように、個々のフローの中で、ドメイン全体およびBB小包それをのためのISPと交渉してきました。リーフルータ機構が使用プロファイルからのパラメータに設定トークンバケットと、図3に示したものです。 ISPのBBは、プロフィールが維持されたことを確認するために、顧客からの入口ルータで、独自のプロファイルメーターを設定します。このメカニズムは、図5に示した。我々は、すべてのプロファイルのための持続時間と開始時間はBBで維持されているアクティブにすることを前提としています。プロフィールをBBから送信されたメッセージで進入デバイスに送信または入力デバイスから消去されます。この例では、バンの@ LBLはDDCする@ MITに話をしたいと仮定します。 「4：V」、宛先アドレス「D：8」に行くLBL-BBは、プレミアムサービスは送信元アドレスを有するものとして指定されているフローに割り当てることが求めヴァンからの要求を送信します。このフローは、128キロバイト/秒と午後1時から午後3時に割り当てられたの速度のために構成されるべきです。リクエストは、安全、検証可能な方法で「署名」しなければなりません。リクエストは、電子メールメッセージは、ネットワーク管理者に、または電話で、ネットワーク管理者に、LBL-BBにデータとして送信される可能性があります。 LBL-BBがこのメッセージを受信し、その後、適切なプロファイルメーターを設定Leaf1にメッセージを送信し、1-3pmからのドメインのための未使用のプレミアムサービスの128キロバイト/秒であることを検証します。 Leaf1へのメッセージは、RSVPメッセージ、またはSNMP、またはいくつかの独自の方法かもしれません。渡されたすべてのドメインは、この要求を満たすのに十分な余力を持っている必要があります。
Figure 6. Bandwidth Broker setting Profiles in leaf routers
図6.帯域幅ブローカーは、リーフルータでのプロファイルを設定します
A statically configured example with BB messages exchanged: Next we present an example where all allocations are statically preallocated but BB messages are exchanged for greater flexibility. Figure 7 shows an end-to-end example for Marked traffic in a statically allocated internet. The numbers at the trust region boundaries indicate the total statically allocated Marked packet rates that will be accepted across those boundaries. For example, 100kbps of Marked traffic can be sent from LBL to ESNet; a Profile Meter at the ESNet egress boundary would have a token bucket set to rate 100kbps. (There MAY be a shaper set at LBL's egress to ensure that the Marked traffic conforms to the aggregate Profile.) The tables inside the transit network "bubbles" show their policy databases and reflect the values after the transaction is complete. In Figure 7, V wants to transmit a flow from LBL to D at MIT at 10 Kbps. As in figure 6, a request for this profile is made of LBL's BB. LBL's BB authenticates the request and checks to see if there is 10kbps left in its Marked allocation going in that direction. There is, so the LBL-BB passes a message to the ESNet-BB saying that it would like to use 10kbps of its Marked allocation for this flow. ESNet authenticates the message, checks its database and sees that it has a 10kbps Marked allocation to NEARNet (the next region in that direction) that is being unused. The policy is that ESNet-BB must always inform ("ask") NEARNet-BB when it is about to use part of its allocation. NEARNET-BB authenticates the message, checks its database and discovers that 20kbps of the allocation to MIT is unused and the policy at that boundary is to not inform MIT when part of the allocation is about to be used ("<50 ok" where the total allocation is 50). The dotted lines indicate the "implied" transaction, that is the transaction that would have happened if the policy hadn't said "don't ask me". Now each BB can pass an "ok" message to this request across its boundary. This allows V to send to D, but not vice versa. It would also be possible for the request to originate from D.
BBメッセージで静的に設定例では、交換：次に、我々はすべての割り当ては、静的に事前に割り当てされているが、BBメッセージはより大きな柔軟性のために交換される例を提示します。図7は、静的に割り当てられたインターネットの著しいトラフィックのエンドツーエンドの例を示しています。信頼領域の境界での数字は、合計が静的にそれらの境界を越えて受け入れられるマーク付きパケットのレートを割り当てられ示しています。例えば、マークされたトラフィックの最高100kbpsはESNetにLBLから送信することができます。 ESNet出口境界でのプロファイルのメーターは、最大100kbpsのレートに設定トークンバケットを持っているでしょう。 （マークされたトラフィックが集約プロファイルに準拠していることを保証するために、LBLの出口に設定シェイパーがあるかもしれません。）トランジットネットワーク内のテーブルは、そのポリシーのデータベースを表示し、トランザクションが完了した後の値を反映して「泡」。図7において、Vは、10 KbpsでMITのDにLBLからの流れを送信したいです。図6のように、このプロファイルの要求はLBLのBBで作られています。 LBLのBBは10kbpsそのマークの割り当てがその方向に行くに残っているかどうかを確認するために、要求とチェックを認証します。ありますので、LBL-BBは、それがこの流れのためにそのマークされた割り当ての10kbpsを使用したいと言っESNet-BBにメッセージを渡します。 ESNetは、メッセージを認証し、そのデータベースをチェックし、未使用中であるNEARNet（その方向の次の領域）への割り当てをマーク10kbpsを有することを見ます。ポリシーはESNet-BBは、常にその割り当ての一部を使用しようとしたときNEARNet-BBを（「頼む」）に通知しなければならないということです。 NEARNET-BBは、メッセージを認証し、そのデータベースをチェックし、MITへの割り当ての20kbpsのは、未使用であり、その境界でのポリシーが割り当ての一部がここで「50 OK <」（使用されようとしているときにMITを通知しないことであることを発見します総割当）が50です。点線は、そのポリシーが「私に聞かないでください」と言っていなかった場合に起こっていた取引で、「暗黙の」トランザクションを示しています。今、各BBは、その境界を越えて、この要求に「OK」メッセージを渡すことができます。これは、VはDに送信することができますが、その逆はありません。リクエストがD.から発信することも可能です
Figure 7. End-to-end example with static allocation.
静的割り当て7.エンドツーエンドの例を図。
Consider the same example where the ESNet-BB finds all of its Marked allocation to NEARNet, 10 kbps, in use. With static allocations, ESNet must transmit a "no" to this request back to the LBL-BB. Presumably, the LBL-BB would record this information to complain to ESNet about the overbooking at the end of the month! One solution to this sort of "busy signal" is for ESNet to get better at anticipating its customers needs or require long advance bookings for every flow, but it's also possible for bandwidth brokerage decisions to become dynamic.
ESNet-BBは使用中、NEARNet、10 kbpsのそのマーク割り当ての全てを検索し、同じ例を考えます。静的割り当てでは、ESNetはバックLBL-BBにこの要求に「ノー」を送信しなければなりません。おそらく、LBL-BBは、今月末にオーバーブッキングについてESNetに文句を言うためにこの情報を記録します！ ESNetが顧客のニーズを先取りで良くなるか、すべてのフローのための長い事前予約が必要とするため、「ビジー信号」のこの種に対する1つの解決策はありますが、帯域幅の仲介決定がダイナミックになるすることも可能です。
Figure 8. End-to-end static allocation example with no remaining allocation
ない残りの割り当てと図8エンドツーエンドの静的割り当て例
Dynamic Allocation and additional mechanism: As we shall see, dynamic allocation requires more complex BBs as well as more complex border policing, including the necessity to keep more state. However, it enables an important service with a small increase in state.
動的な割り当てと、追加のメカニズム：私たちが見るように、動的割り当ては、より多くの状態を維持する必要性など、より複雑な掲示板やだけでなく、より複雑な国境警備を必要とします。しかし、それは状態のわずかな増加との重要なサービスを可能にします。
The next set of figures (starting with figure 9) show what happens in the case of dynamic allocation. As before, V requests 10kbps to talk to D at MIT. Since the allocation is dynamic, the border policers do not have a preset value, instead being set to reflect the current peak value of Marked traffic permitted to cross that boundary. The request is sent to the LBL-BB.
図面の次のセットは、動的割り当ての場合に何が起こるかを示している（図9で始まります）。前と同様に、Vは、MITのDに話を10kbpsを要求します。割り当ては動的であるため、境界ポリサーではなくマークトラフィックの電流ピーク値を反映するように設定される設定値は、その境界を横断することを許可していません。要求はLBL-BBに送信されます。
Figure 9. First step in end-to-end dynamic allocation example.
エンドツーエンドの動的割当て例でまずステップ図。
In figure 10, note that ESNet has no allocation set up to NEARNet. This system is capable of dynamic allocations in addition to static, so it asks NEARNet if it can "add 10" to its allocation from ESNet. As in the figure 7 example, MIT's policy is set to "don't ask" for this case, so the dotted lines represent "implicit transactions" where no messages were exchanged. However, NEARNet does update its table to indicate that it is now using 20kbps of the Marked allocation to MIT.
図10では、ESNetはNEARNetまで設定何の割り当てを持っていないことに注意してください。このシステムは、静的に加えて、動的割り当てが可能であるので、それはESNetからその割当に「10を追加する」ことができる場合にはNEARNetを尋ねます。図7の例のように、MITの方針は、点線は何のメッセージが交換されなかった「暗黙の取引」を表すので、この場合は、「求めない」に設定されています。しかし、NEARNetは、それが今、MITにマークされた割り当ての20kbpsのを使用していることを示すために、そのテーブルを更新しません。
Figure 10. Second step in end-to-end dynamic allocation example
エンドツーエンドの動的割り当て例における図10第二工程
In figure 11, we see the third step where MIT's "virtual ok" allows the NEARNet-BB to tell its border router to increase the Marked allocation across the ESNet-NEARNet boundary by 10 kbps.
図11には、我々はMITの「仮想OK」はNEARNet-BBは10 kbpsのでESNet-NEARNet境界を越えてマークされた割り当てを増やすために、その境界ルータに伝えることを可能にする第三のステップを参照してください。
Figure 11. Third step in end-to-end dynamic allocation example
エンドツーエンドの動的割り当て例における図11第三工程
Figure 11 shows NEARNet-BB's "ok" for that request transmitted back to ESNet-BB. This causes ESNet-BB to send its border router a message to create a 10 kbps subclass for the flow "V->D". This is required in order to ensure that the 10kpbs that has just been dynamically allocated gets used only for that connection. Note that this does require that the per flow state be passed from LBL-BB to ESNet-BB, but this is the only boundary that needs that level of flow information and this further classification will only need to be done at that one boundary router and only on packets coming from LBL. Thus dynamic allocation requires more complex Profile Metering than that shown in figure 5.
図11に示すNEARNet-BB ESNet-BBに返送その要求のための「OK」。これは、その境界ルータ流れ「V-> D」のための10 kbpsのサブクラスを作成するためのメッセージを送信するためにESNet-BBの原因となります。これはちょうど、動的に割り当てられた10kpbsのみその接続に使用されることを保証するために必要とされます。これは、フロー状態ごとLBL-BBからESNet-BBに渡されることを必要としないことに注意してください、これはフロー情報のレベルを必要とし、この別の分類はそれだけで1つの境界ルータで実行する必要があります唯一の境界であるとLBLから来るパケットにのみ。こうして動的割り当てが図5に示されたものよりも複雑なプロファイルメーターを必要とします。
Figure 12. Fourth step in end-to-end dynamic allocation example.
エンドツーエンドの動的割り当て例12.第4工程を図。
In figure 12, the ESNet border router gives the "ok" that a subclass has been created, causing the ESNet-BB to send an "ok" to the LBL-BB which lets V know the request has been approved.
図12では、ESNet境界ルータは、Vは、要求が承認された知ることができますLBL-BBに「OK」を送信するためにESNet-BBを引き起こし、サブクラスが作成されていることを「OK」を与えます。
Figure 13. Final step in end-to-end dynamic allocation example
エンドツーエンドの動的割り当て例における図13の最終ステップ
For dynamic allocation, a basic version of a CBQ scheduler [5] would have all the required functionality to set up the subclasses. RSVP currently provides a way to move the TSpec for the flow.
動的割り当てのために、CBQスケジューラの基本的なバージョンは、[5]のサブクラスを設定するために必要なすべての機能を持っているでしょう。 RSVPは、現在のフローのためのTSpecのを移動するための方法を提供します。
For multicast flows, we assume that packets that are bound for at least one egress can be carried through a domain at that level of service to all egress points. If a particular multicast branch has been subscribed to at best-effort when upstream branches are Marked, it will have its bit settings cleared before it crosses the boundary. The information required for this flow identification is used to augment the existing state that is already kept on this flow because it is a multicast flow. We note that we are already "catching" this flow, but now we must potentially clear the bit-pattern.
マルチキャストフローのために、我々は、少なくとも一つの出口のためにバインドされたパケットは、すべての出力ポイントへのサービスのレベルでドメインを介して行うことができることを前提としています。特定のマルチキャストブランチは、ベストエフォート型に加入されている場合は上流の枝がマークされているとき、それは境界を越える前に、そのビットの設定がクリアされます。このフロー識別に必要な情報は、マルチキャストフローであるため、既にこのフローに保持されている既存の状態を増強するために使用されます。我々はすでに、この流れを「キャッチ」しているが、今、我々は潜在的ビットパターンをクリアしなければならないことに注意してください。
Much work has been done in recent years on the definition of related integrated services for the internet and the specification of the RSVP signalling protocol. The two-bit architecture proposed in this work can easily interoperate with those specifications. In this section we first discuss how the forwarding mechanisms described in section 3 can be used to support integrated services. Second, we discuss how RSVP could interoperate with the administrative structure of the BBs to provide better scaling.
多くの研究は、インターネットのために、関連する統合されたサービスの定義、およびRSVPシグナリングプロトコルの仕様上、近年で行われています。この作品で提案された2ビットアーキテクチャは、簡単にそれらの仕様と相互運用することができます。このセクションでは、最初のセクション3に記載の転送メカニズムが統合されたサービスをサポートするために使用することができる方法について説明します。第二に、私たちは、RSVPがより良いスケーリングを提供するために、ベストバンドの行政構造と相互運用できるか話し合います。
We believe that the forwarding path mechanisms described in section 3 are general enough that they can also be used to provide the Controlled-Load service [8] and a version of the Guaranteed Quality of Service [9], as developed by the int-serv WG. First note that Premium service can be thought of as a constrained case of Controlled-Load service where the burst size is limited to one packet and where non-conforming packets are dropped. A network element that has implemented the mechanisms to support premium service can easily support the more general controlled-load service by making one or more minor parameter adjustments, e.g. by lifting the constraint on the token bucket size, or configuring the Premium service rate with the peak traffic rate parameter in the Controlled-Load specification, and by changing the policing action on out-of-profile packets from dropping to sending the packets to the Best-effort queue.
私たちは、セクション3で説明した転送パスメカニズムが、彼らはまた、制御され、ロードサービス[8]と保証されたサービスの質のバージョンを提供するために使用することができることを十分に一般的であると信じている[9]、INT-SERVによって開発されましたWG。プレミアムサービスは、バーストサイズが1つのパケットに限定されるものではなく、不適合パケットがドロップされる制御負荷サービスの制約ケースと考えることができることを最初の音符。プレミアムサービスをサポートするためのメカニズムを実装しているネットワーク要素は容易に、例えば、一つ以上のマイナーなパラメータ調整を行うことで、より一般的な制御されたロード・サービスをサポートすることができトークンバケットサイズに制約を持ち上げ、または制御ロード仕様でピーク時のトラフィックレートパラメータプレミアムサービスレートを設定することにより、および落下からプロファイル外のパケットのポリシングアクションを変更することでにパケットを送信しますベストエフォートキュー。
It is also possible to implement Guaranteed Quality of Service using the mechanisms of Premium service. From RFC 2212 [9]: "The definition of guaranteed service relies on the result that the fluid delay of a flow obeying a token bucket (r, b) and being served by a line with bandwidth R is bounded by b/R as long as R is no less than r. Guaranteed service with a service rate R, where now R is a share of bandwidth rather than the bandwidth of a dedicated line approximates this behavior." The service model of Premium clearly fits this model. RFC 2212 states that "Non-conforming datagrams SHOULD be treated as best-effort datagrams." Thus, a policing Profile Meter that drops non-conforming datagrams would be acceptable, but it's also possible to change the action for non-compliant packets from a drop to sending to the best-effort queue.
プレミアムサービスの仕組みを利用してサービスの品質保証を実現することも可能です。 RFC 2212から[9]：「保証されたサービスの定義は、フロートークンバケット（R、B）に従うと帯域幅Rとの線によって提供されているの流体遅延があれば、B / Rによって制限されるという結果に依存していますRは現在、Rは、帯域幅のシェアではなく、専用回線の帯域幅は、この動作に近似している。」サービスレートR、とはrよりも小さい。保証サービスではありませんとしてプレミアムのサービスモデルは明らかに、このモデルに適合します。 RFC 2212は「非準拠のデータグラムは、ベストエフォート型のデータグラムを処理する必要があります。」と述べていますこのように、データグラムを非準拠の低下ポリシングプロフィールメーターは許容可能であるが、それはベストエフォートキューに送信するドロップから非準拠のパケットのためのアクションを変更することも可能です。
In this section we discuss how RSVP signaling can be used in conjunction with the BBs described in section 4 to deliver a more scalable end-to-end resource set up for Integrated Services. First we note that the BB architecture has three major differences with the original RSVP resource set up model:
このセクションでは、RSVPシグナリングが統合サービス用に設定、よりスケーラブルなエンド・ツー・エンドのリソースを提供するためにセクション4で説明したBBSで組み合わせて使用することができる方法について説明します。まず、BBアーキテクチャはモデルを設定、元のRSVPリソースを持つ三つの主要な違いがあることに注意してください：
1. There exist apriori bilateral business relations between BBs of adjacent trust regions before one can set up end-to-end resource allocation; real-time signaling is used only to activate/confirm the availability of pre-negotiated Marked bandwidth, and to dynamically readjust the allocation amount when necessary. We note that this real-time signaling across domains is not required, but depends on the nature of the bilateral agreement (e.g., the agreement might state "I'll tell you whenever I'm going to use some of my allocation" or not).
1は、エンドツーエンドのリソース割り当てを設定することができます前に、1隣接信頼領域のベストバンド間のアプリオリ二国間のビジネス関係が存在します。リアルタイムシグナリングはのみ有効/事前に交渉著しい帯域幅の利用可能性を確認し、必要なときに動的に割り当て量を再調整するために使用されます。私たちは、ドメイン間でのシグナリングこのリアルタイムは必要ですが、二国間協定の性質に依存していないことに注意してください（例えば、契約が述べるかもしれないかどうか「私は私の割り当ての一部を使用するつもりだ時はいつでもあなたを教えてあげます」 ）。
2. A few bits in the packet header, i.e. the P-bit and A-bit, are used to mark the service class of each packet, therefore a full packet classification (by checking all relevant fields in the header) need be done only once at the leaf router; after that packets will be served according to their class bit settings.
Pビットとビットは、（ヘッダ内のすべての関連フィールドをチェックして）各パケットのサービスクラス、従って完全なパケット分類をマークするために使用されている、すなわち、パケットヘッダ内の2ビット数は、のみ行われる必要がリーフルータを一度。そのパケットの後に自分のクラスビットの設定に応じて提供されます。
3. RSVP resource set up assumes that resources will be reserved hop-by-hop at each router along the entire end-to-end path.
設定3. RSVPリソースはリソース全体のエンドツーエンドパスに沿った各ルータでホップバイホップ予約されることを前提としています。
RSVP messages sent to leaf routers by hosts can be intercepted and sent to the local domain's BB. The BB processes the message and, if the request is approved, forwards a message to the leaf router that sets up appropriate per-flow packet classification. A message should also be sent to the egress border router to add to the aggregate Marked traffic allocation for packet shaping by the Profile Meter on outbound traffic. (Its possible that this is always set to the full allocation.) An RSVP message must be sent across the boundary to adjacent ISP's border router, either from the local domain's border router or from the local domain's BB. If the ISP is also implementing the RSVP with a BB and diff-serv framework, its border router forwards the message to the ISP's local BB. A similar process (to what happened in the first domain) can be carried out in the ISP domain, then an RSVP message gets forwarded to the next ISP along the path. Inside a domain, packets are served solely according to the Marked bits. The local BB knows exactly how much Premium traffic is permitted to enter at each border router and from which border router packets exit.
ホストによってリーフルータに送信されたRSVPメッセージを傍受し、ローカルドメインのBBに送信することができます。 BBは、要求が承認された場合、適切なフローごとのパケット分類を設定リーフルータにメッセージを転送し、メッセージを処理し。メッセージはまた、アウトバウンドトラフィックのプロフィール計でパケット整形のためのトラフィックの割り当てをマーク集計に追加する出口境界ルータに送信する必要があります。 （これは常にフル配分に設定されていること、その可能性。）RSVPメッセージは、ローカルドメインの境界ルータからまたはローカルドメインのBBのいずれかから、隣接するISPの境界ルータに境界を越えて送信する必要があります。 ISPもBBとRSVPと差分-SERVフレームワークを実装している場合は、その境界ルータは、ISPのローカルBBにメッセージを転送します。 （第一ドメインに起こったことに）同様のプロセスが、ISPのドメインで行うことができ、その後、RSVPメッセージは、経路に沿って次のISPに転送されます。ドメイン内では、パケットは単にマークビットに応じて提供しています。地元のBBは、各境界ルータで、どの境界ルータのパケット出口から入ることを許されている正確にどのくらいのプレミアムトラフィックを知っています。
This document has presented a reference architecture for differentiated services. Several variations can be envisioned, particularly for early and partial deployments, but we do not enumerate all of these variations here. There has been a great market demand for differentiated services lately. As one of the many efforts to meet that demand this memo sketches out the framework of a flexible architecture for offering differential services, and in particular defines a simple set of packet forwarding path mechanisms to support two basic types of differential services. Although there remain a number of issues and parameters that need further exploration and refinement, we believe it is both possible and feasible at this time to start deployment of differentiated services incrementally. First, given that the basic mechanisms required in the packet forwarding path are clearly understood, both Assured and Premium services can be implemented today with manually configured BBs and static resource allocation. Initially we recommend conservative choices on the amount of Marked traffic that is admitted into the network. Second, we plan to continue the effort started with this memo and the experimental work of the authors to define and deploy increasingly sophisticated BBs. We hope to turn the experience gained from in-progress trial implementations on ESNet and CAIRN into future proposals to the IETF.
この文書では、差別化されたサービスのためのリファレンスアーキテクチャを発表しました。いくつかのバリエーションが特に早期かつ部分的な展開のために、想定することができますが、ここではこれらの変化の全てを列挙しません。最近差別化されたサービスのための偉大な市場の需要がありました。その要求を満たすために多くの努力の一つとして、このメモは、差動サービスを提供するための柔軟なアーキテクチャの枠組みをスケッチ、特に差動サービスの2つの基本的なタイプをサポートするためのパケット転送パスメカニズムの簡単なセットを定義します。問題やさらなる調査と改善を必要とするパラメータの数が残っているが、我々はそれを段階差別化されたサービスの展開を開始するには、この時点で可能かつ実現可能の両方であると考えています。まず、パケット転送経路に必要な基本的なメカニズムが明確に理解されていることを考えると、両方の確実なプレミアムサービスを手動で設定ベストバンドと静的リソース割り当てと今日実現することができます。当初、私たちは、ネットワーク内に導入されてマークされたトラフィックの量に保守的な選択をお勧めします。第二に、我々は努力がこのメモと定義し、ますます洗練されたベストバンドを展開する著者の実験作業を開始していく予定。私たちは、IETFへの将来の提案にESNetとCAIRNに進行中の裁判の実装から得られた経験を回すために願っています。
Future revisions of this memo will present the receiver-based and multicast flow allocations in detail. After this step is finished, we believe the basic picture of an scalable, robust, secure resource management and allocation system will be completed. In this memo, we described how the proposed architecture supports two services that seem to us to provide at least a good starting point for trial deployment of differentiated services. Our main intent is to define an architecture with three services, Premium, Assured, and Best effort, that can be determined by specific bit- patterns, but not to preclude additional levels of differentiation within each service. It seems that more experimentation and experience is required before we could standardize more than one level per service class. Our base-level approach says that everyone has to provide "at least" Premium service and Assured service as documented. We feel rather strongly about both 1) that we should not try to define, at this time, something beyond the minimalist two service approach and 2) that the architecture we define must be open-ended so that more levels of differentiation might be standardized in the future. We believe this architecture is completely compatible with approaches that would define more levels of differentiation within a particular service, if the benefits of doing so become well understood.
このメモの将来の改訂は、詳細に、受信機ベースおよびマルチキャストフローの割り当てを提示します。このステップが終了した後、我々はスケーラブルで堅牢、セキュアなリソース管理と割り当てシステムの基本的な絵が完成すると信じています。このメモでは、提案アーキテクチャは差別化されたサービスの試験的導入のための、少なくとも良い出発点を提供するために、私たちのように見える2つのサービスをサポートしています方法について説明しました。私たちの主な目的は3つのサービス、プレミアム、アシュアード、および特定のbit-パターンによって決定することができるが、各サービス内分化の追加レベルを排除しないベストエフォート、とのアーキテクチャを定義することです。我々がサービスクラスごとに複数のレベルを標準化することができる前に多くの実験と経験が必要とされているようです。私たちの基本レベルのアプローチは、誰もが文書化されているように、「少なくとも」プレミアムサービスと確実なサービスを提供しなければならないと述べています。私たちは、分化のより多くのレベルがで標準化される可能性がありますように、我々が定義するアーキテクチャはオープンエンドでなければならないことの両方1）私たちは、この時点では、ミニマリストの2つのサービス・アプローチと2を超えた何かを定義しようとするべきではないということ）について、かなり強く感じます未来。私たちは、このアーキテクチャはそうすることのメリットは十分に理解されるようになる場合には、特定のサービス内の分化のより多くのレベルを定義するアプローチと完全に互換性があると信じています。
The authors have benefited from many discussions, both in person and electronically and wish to particularly thank Dave Clark who has been responsible for the genesis of many of the ideas presented here, though he does not agree with all of the content this document. We also thank Sally Floyd for comments on an earlier draft. A comment from Jon Crowcroft was partially responsible for our including section 5. Comments from Fred Baker made us try to make it clearer that we are defining two base-level services, irrespective of the bit patterns used to encode them.
著者は、人に及び電子の両方の、多くの議論の恩恵を受け、特に、彼はすべてのコンテンツ、この文書に同意しませんが、ここで紹介するアイデアの多くの起源を担当している者デイブ・クラークに感謝したいです。また、以前の草案に対するコメントのためのサリーフロイドに感謝します。ジョン・クロークロフトからのコメントは、フレッド・ベイカーから5のコメントは、私たちは、我々は関係なく、それらを符号化するのに使用されるビットパターンの、二つの基地レベルのサービスを定義していること、それをより明確にしようと作られた私たちを含む部分に部分的に関与しました。
There are no security considerations associated with this document.
この文書に関連付けられたセキュリティ上の考慮事項はありません。
[1] D. Clark, "Adding Service Discrimination to the Internet", Proceedings of the 23rd Annual Telecommunications Policy Research Conference (TPRC), Solomons, MD, October 1995.
[1] D.クラーク、「インターネットへのサービスの差別を追加」、第23回電気通信政策研究会議（TPRC）、ソロモン、MD、1995年10月の議事録を。
[2] V. Jacobson, "Differentiated Services Architecture", talk in the Int-Serv WG at the Munich IETF, August, 1997.
[2] V. Jacobson氏、 "差別化サービスアーキテクチャ"、ミュンヘンIETF、1997年8月でのInt-ServのWGで話します。
[3] Clark, D. and J. Wroclawski, "An Approach to Service Allocation in the Internet", Work in Progress, also talk by D. Clark in the Int-Serv WG at the Munich IETF, August, 1997.
[3]クラーク、D.とJ. Wroclawski、「インターネットでのサービス配分へのアプローチ」が進行中で働いていますが、またミュンヘンIETF、1997年8月でのInt-ServのWGでD.クラークで話しています。
[4] Braden, et al., "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
[4]らブレーデンを、。、「インターネットの待ち行列管理と輻輳回避に関する提言」、RFC 2309、1998年4月。
[4] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource Reservation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997.
[4]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1機能仕様"、RFC 2205、1997年9月。
[5] S. Floyd and V. Jacobson, "Link-sharing and Resource Management Models for Packet Networks", IEEE/ACM Transactions on Networking, pp 365-386, August 1995.
[5] S.フロイドとV. Jacobson氏、「パケットネットワークのリンクを共有し、リソース管理モデル」、ネットワーク上のIEEE / ACM取引、頁365から386まで、1995年8月。
[6] D. Clark, private communication, October 26, 1997.
[6] D.クラーク、民間の通信、1997年10月26日。
[7] "Advanced QoS Services for the Intelligent Internet", Cisco Systems White Paper, 1997.
[7]「インテリジェントインターネットのための高度なQoSサービス」、シスコシステムズホワイトペーパー、1997。
[8] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[8] Wroclawski、J.、RFC 2211 "制御負荷ネットワーク要素サービスの仕様"、1997年9月。
[9] Shenker, S., Partirdge, C. and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[9] Shenker、S.、Partirdge、C.とR.ゲラン、 "保証されたサービスの質の仕様"、RFC 2212、1997年9月。
[10] D. Clark and W. Fang, "Explicit Allocation of Best Effort packet Delivery Service", IEEE/ACM Transactions on Networking, August, 1998, Vol6, No 4, pp. 362-373. also at: http:// diffserv.lcs.mit.edu/Papers/exp-alloc-ddc-wf.pdf
[10] D.クラークとW.牙、 "ベストエフォートパケット配信サービスの明示的な配分"、ネットワーキング、1998年8月、VOL6上のIEEE / ACM取引、4番、頁362から373まで。また、でます。http：// diffserv.lcs.mit.edu/Papers/exp-alloc-ddc-wf.pdf
Authors' Addresses
著者のアドレス
Kathleen Nichols Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706
キャスリーン・ニコルズシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134-1706
Phone: 408-525-4857 EMail: kmn@cisco.com
電話：408-525-4857 Eメール：kmn@cisco.com
Van Jacobson Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706
ヴァンヤコブソンシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134-1706
EMail: van@cisco.com
メールアドレス：van@cisco.com
Lixia Zhang UCLA 4531G Boelter Hall Los Angeles, CA 90095
L I老人張UCLA 4531ギガバイトOEホールロサンゼルス、CA 90095
Phone: 310-825-2695 EMail: lixia@cs.ucla.edu
電話：310-825-2695 Eメール：lixia@cs.ucla.edu
Appendix: A Combined Approach to Differential Service in the Internet by David D. Clark
付録：デビッド・D.クラークによって、インターネットでの差動サービスを組み合わせるアプローチ
After the draft-nichols-diff-svc-00 was submitted, the co-authors had a discussion with Dave Clark and John Wroclawski which resulted in Clark's using the presentation slot for the draft at the December 1997 IETF Integrated Services Working Group meeting. A reading of the slides shows that it was Clark's proposal on "mechanisms", "services", and "rules" and how to proceed in the standards process that has guided much of the process in the subsequently formed IETF Differentiated Services Working Group. We believe Dave Clark's talk gave us a solid approach for bringing quality of service to the Internet in a manner that is compatible with its strengths.
ドラフト・ニコルズ-diffを-SVC-00が提出された後、共著者は、1997年12月IETF統合サービスワーキンググループの会合で草案のプレゼンテーションスロットを使用して、クラークさんが生じたデイブ・クラークとジョンWroclawskiとの議論がありました。スライドの読み取りは、クラークの「仕組み」、「サービス」、および「ルール」の提案とどのように続いて形成されるIETFのDifferentiated Servicesの作業部会でのプロセスの多くを導いた標準化プロセスで進行するとあったことを示しています。私たちは、デイブ・クラークの話は、私たちの強みと互換性のある方法で、インターネットへのサービスの品質をもたらすための強固なアプローチを与えたと考えています。
The slides presented at the December 1997 IETF Integrated Services Working Group are included with the Postscript version.
1997年12月IETF統合サービスワーキンググループで発表スライドは、ポストスクリプトバージョンに含まれています。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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機能のための基金は現在、インターネット協会によって提供されます。