[要約] RFC 2638は、インターネットのための2ビットの差別化サービスアーキテクチャについての要約です。このRFCの目的は、トラフィックの優先順位付けとサービス品質の向上を実現するためのフレームワークを提供することです。
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
インターネット用の2ビット差別化されたサービスアーキテクチャ
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.
Copyright（c）The Internet Society（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年11月にインターネットのドラフトとして元々提出されました。IETFの差別化されたサービスワーキンググループの形成に先立つ文書の1つとして、1997年12月の会議へのデイブクラークのその後のプレゼンテーションと協力して、ここに提示されたアイデアの多くがここに提示されました。IETF統合サービスワーキンググループは、RFCS 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バージョンには、Clarkのスライドが付録として含まれています。このドキュメントの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.
このドキュメントでは、インターネット用の差別化されたサービスアーキテクチャを提示します。デイブ・クラークとヴァン・ジェイコブソンはそれぞれ、ミュンヘンIETF会議で差別化されたサービスに関する研究を発表しました[2,3]。それぞれが、IPヘッダーの1ビットを使用して、インターネット内のパケットに新しい種類のサービスを提供する方法を説明しました。これらは、非常に異なるポリシーの仮定を持つ2つの非常に異なる種類のサービスでした。その後の議論により、両方のサービスタイプにはメリットがあり、両方のサービスタイプを一連の非常に類似したメカニズムで実装できると確信しています。これらのサービスタイプの両方を使用することを許可し、パスメカニズムを転送する際の類似点を活用するアーキテクチャのフレームワークを提案します。このアーキテクチャの主要な目標は、それぞれこれらの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.
類推を軽減するリスクがあるので、私たちは航空会社がファーストクラス、ビジネスクラス、コーチクラスと同じようにサービス層を提供するように動機付けられています。後者には、購入に課せられたさまざまな制限のために、階層式が組み込まれています。私たちが強調したい類推の一部は、飛行機のクラスのコーチの席のような最高の努力トラフィックが、まだインターネットトラフィックの大部分を補うことが期待されていることです。ビジネスとファーストクラスには少数の乗客がいますが、航空業界の経済学にとって非常に重要です。さまざまな経済力と現実が組み合わさって、座席の相対的な割り当てを決定し、飛行機を埋めようとします。差別化されたサービスがインターネット上のすべてのトラフィックを構成することを期待していませんが、新しいサービスが健全な経済的およびサービス環境につながることを期待しています。
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.
現在のインターネットは、すべてのトラフィックに1つのタイプのサービス、Best-Effortを提供します。インターネットに拡張サービスを追加することに関して、多くの提案がなされています。差別化されたレベルのサービスをIPに追加する2つの特定の方法に焦点を当て、それぞれが1ビット[1,2,3]で指定されています。これらのサービスは、インターネットの従来のサービスからの根本的な逸脱を表していますが、サーキットベースのモデルに依存する従来の「サービス品質」アーキテクチャからの根本的な逸脱でもあります。これらの提案は両方とも、内部ネットワークルーターで使用される単一の共通メカニズムを定義し、区別されたサービスのほとんどの複雑さと状態をネットワークエッジに押し上げます。どちらも、要求および割り当てられているリソースとして帯域幅を使用します。ClarkとWroclawskiは、統計的にプロビジョニングされた「予想される容量」使用プロファイルに従う「保証された」サービスを定義しました[3]。このようなサービスのユーザーが受け取るという保証は、予想される容量プロファイル内にとどまる限り、このようなトラフィックが削除される可能性は低いことです。「ありそうもない」という正確な意味は、サービスがどれだけうまくプロビジョニングされているかに依存します。保証されたサービストラフィックフローはプロファイルを超える可能性がありますが、過剰なトラフィックには同じ保証レベルが与えられていません。ジェイコブソンは、厳密に過剰に登録されていないピーク容量プロファイルに従ってプロビジョニングされ、ルーターで独自の優先順位のキューが与えられている[2]を定義しました[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.
ClarkとWroclawskiによって[3]に保証されたサービスが導入されましたが、私たちは建築の仕様にいくつかの変更を加えました。Clark and Fang [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つのレベルの優先キューイングが必要で、最初にプレミアムビットセットですべてのパケットを送信します。ベストエフォルトトラフィックはマークされておらず、キューに掲載されており、優先度が低くなっています。これにより、2つの「仮想ネットワーク」が得られます。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.
このアーキテクチャでは、転送パスの決定は、サービス契約とトラフィックプロファイルのセットアップよりも個別に、より単純に行われます。管理または「信頼」境界でのポリシングとシェーピングを除いて、転送パスで処理する必要がある唯一のアクションは、パケットを1つのビットで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 Company AのISPへのアクセスリンク全体に送信されるかを示しています。ホストの最初のホップルーターが、ホストのIPアドレスからISPを介して到達される宛先IPアドレスへのフローを一致させるように構成されていると仮定します。プレミアムフローは、ISPからのプレミアム配分会社Aが総額、Rバイト /秒、およびその割り当ての量よりも小さいレートで、AがA社の他のホストに割り当てられているレートのホストから構成されています。パケットは、ホストを離れるときに特別な方法でマークされていません。ファーストホップルーターは、到着するすべてのパケットのプレミアムビットをクリアし、指定されたフローのすべてのパケットのプレミアムビットを設定し、プレミアムフローのパケットを設定されたレートとバーストサイズに形作り、低優先度の低いマークのないパケットをキューする優先度の高いキューにあるキューと形状のプレミアムパケットは、これら2つのキューから単純な優先順位でパケットを送信します。プレミアムビットに基づいて2つの出力キューのいずれかにあるEnqueueパケットと、単純な優先順位でキューにサービスを提供します。ボーダールーターは、出口の流れを処理しているのか、侵入の流れを処理しているのかに応じて、まったく異なるタスクを実行します。出力ボーダールーターは、集約されたプレミアムフローの数に応じて、総プレミアムトラフィックの再形成を実行するためにRast Rに適合する場合があります。イングレスボーダールーターは、トークンバケットで実装できる単純なポリシング関数を実行するだけです。この例では、ISPは、フローが毎秒Rバイトを超えない限り、すべてのプレミアムパケットをAから受け入れます。
Figure 1. Premium traffic flow from end-host to organization's ISP
図1.エンドホストから組織のISPへのプレミアムトラフィックフロー
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.
両方のサービスを展開することには、いくつかの追加の利点があるかもしれません。プレミアムサービスが保守的なリソースの割り当てである限り、プレミアムに割り当てられた未使用の帯域幅は、保証された交通の過小評価またはバースト期間または最善の努力のために「ヘッドルーム」を提供するかもしれません。両方のサービスを展開するネットワーク要素は、[4]で示唆されているように、すべての非プレミアムトラフィックでレッドキュー管理を実行し、プレミアムストリームを最善の努力と混合することの効果は、後者のバーストを減らすのに役立つ可能性があります。保証されたサービスの強みは、バーストが自然に発生することを可能にすることですが、これにより、プロビジョニング、入場管理、割り当ての問題がより困難になるため、このサービスのこの入場ポリシーが完全に定義されるまでに時間と実験が必要になる可能性があります。。統計的共有なしでピークレートに静的割り当てを使用するプレミアムサービスを展開できます。
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つのビットパターンを指定することを提案します優先順位フィールド。これらのビットパターンの明示的な指定を標準プロセスに任せたままにしておくと、各パターンを少し示すショートハンド表記を使用します。ネットワークは、これらのサービスのいずれかのみを実装し、適用されるビットのみを見るネットワーク要素を持つことができますが、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.
より一般的な意味では、プレミアムサービスは、通常のベストエフォートキューよりも優先度が高いパケットを示します。同様に、Assured Serviceは、「通常の」キュー内の低下確率に関して優先的に扱われるパケットを示します。これらの各サービスタイプ[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.
リーフルーターは、パケットヘッダーに基づいて特定のフローのトラフィックプロファイルで構成されています。この機能は、RFC 2205のRSVPワーキンググループによって定義されています。図2は、転送エンジンに渡される前に、リーフルーターに到着するパケットに何が起こるかを示しています。到着するすべてのパケットには、AビットとPビットの両方がクリアされている必要があります。その後、パケットがヘッダーに分類されます。ヘッダーが構成された値と一致しない場合、すぐに転送されます。一致したフローは、そのフローの使用プロファイルから構成された個々のマーカーを通過します：サービスクラス（プレミアムまたは保証）、レート（保険料のピーク、保証のための「予想」）、許容バーストサイズ（プレミアムの場合はオプションかもしれません）。フローがプロファイルに準拠しているときに、Aビットセットでマーカーから出現しますが、それ以外の場合はフローが変化しません。プレミアムフローの場合、マーカーは、設定されたレートを実施するために必要な場合にパケットを保持します。したがって、プレミアムフローパケットは、Pビットセットを備えた形状のフローのマーカーから出現します。（以下で説明するように、プレミアムフローパケットをマーカーの内側にドロップする可能性があります。）マーカーから出現すると、パケットが転送エンジンに渡されます。マークされたパケットと呼ばれるpまたはbitsセットのいずれかを持つパケット。
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つのパケットの深さをお勧めします。）トークンが存在する場合、Assued FlowパケットがAビットセットを1つに設定します。そうしないと、パケットが転送エンジンに渡されます。プレミアム構成マーカーの場合、トークンプレゼントが表示されているパケットにはPビットが設定され、転送されますが、トークンが存在しない場合、トークンが到着するまでプレミアムフローパケットが保持されます。保持キューにオーバーフローするのに十分なプレミアムフローが破裂すると、そのパケットが削除されます。フローセットアップデータを使用して、保持キューのサイズ制限を構成することができますが（これはプレミアムサービスの「バースト」の意味になります）、必要はありません。固定されていない保持キューは、TCP接続に適した、少なくとも2つの帯域幅遅延製品を保持できる必要があります。特定のアプリケーションの遅延要件に合わせて、より小さな値を使用する場合があります。
Figure 3. Markers to implement the two different services
図3. 2つの異なるサービスを実装するマーカー
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が設定されていないことです。このステップに続いてトラフィックがキューに入り、そのパスに沿ったすべてのホップでキューを見る可能性があります。
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-BITにテストを実装してパケットの出力キューを選択する必要があります。2つのキューは、最初にシンプルな優先順位、プレミアムパケットでサービスを提供する必要があります。各出力インターフェイスは、優先度の下部キューに[3]で説明されているREDベースのRIOメカニズムを実装する必要があります。Rioは、通常のベストエフェクトトラフィックの合計キュー占有率に基づいた低いパケットと、Aビットセットのあるパケットの数に基づいて、パケットの削除を開始するために2つのしきい値を使用します。これは、保証されたサービストラフィックを保証する優先的なアクションが、キューの容量が通常のベスト努力サービスのしきい値を超える場合にのみ行われることを意味します。この場合、保証されたサービスのしきい値にも到達しない限り、マークのないパケットのみがドロップされます（赤いアルゴリズムを使用）。現在キューにあるAビットパケットの数の正確なカウントを維持するには、キューのエントリと出口の両方でAビットをテストするか、ルーターの追加状態の両方をテストする必要があります。図4は、すべてのルーターの出力インターフェイスのブロック図です。
Figure 4. Router output interface for two-bit architecture
図4. 2ビットアーキテクチャ用のルーター出力インターフェイス
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-bitsセットがシェイプのない最良のパケットストリームと混ざり合った形状のパケットストリームであり、その一部にはAビットがセットされている可能性があります。プレミアムサービスは、バーストと帯域幅の両方の制御されているため、明らかにベストエフェクショントラフィックを飢えさせることはできません。保証されたサービスは、マークされていないトラフィックの飢vを防ぐために保守的な割り当てのみに依存する可能性がありますが、保証されたトラフィックの爆発は、うっ血期のボトルネックキューでの最良のトラフィックを閉鎖する可能性があります。
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ビットリセットがあります。たとえば、図1では、ISPがプレミアムサービスのRバイト/秒を会社に提供することに同意した場合、会社Aからリンクを介してISPに入るPビットマークパケットは、Rを超えると削除されます。代わりに、図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を参照）。各タイプ、プレミアムまたは保証、および各インターフェイスには、特定の境界にわたる特定のクラスに対応する独自のプロファイルメーターが必要です。（これは、境界を横切るすべてのフローを個別にポリシングおよび/または形成する必要があるモデルとは対照的です。）ボーダールーター入力インターフェイスで必要な正確なメカニズムは、展開された割り当てポリシーに依存します。より複雑なアプローチをセクション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対応ルーターの一部である機能であるトランスポートレベルの署名マッチングを実行する必要があります。上記のように、タプルが構成されたフローの1つと一致するパケットが適合性テストされ、適切なサービスビットが設定されています。この関数はメモリと加工集約型ですが、フローが少ないネットワークのエッジに保持されます。
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.
Bit-Pattern分類器：このプリミティブは、IPヘッダーの特定のビットパターンが設定されているかどうかに基づいた単純な双方向の決定を含みます。図4のように、P-BITは、パケットが非葉のルーターに到着したときにテストされ、優先度の高い出力キューまたは低優先度パケットキューでそれを排除するかどうかを判断します。低優先度キューにバインドされたパケットのaビットは、1）セットの場合、キュー内の保証されたパケットのカウントをインクリメントし、2）そのパケットに使用するドロップ確率を決定します。低優先度キューを終了するパケットは、必要に応じてEnqueued Assuredパケットのカウントを減らすことができるように、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-Bitトラフィックには、より多くのキューレベルとより複雑なスケジューリングを追加でき、経験が必要であり、処理速度で十分であることが示されている場合、Aビットトラフィックにはより多くのドロップ優先レベルを追加できます。ここで説明するサービスは、少なくとも「少なくとも」サービスと見なされることを提案します。したがって、ネットワーク要素は、少なくともすべてのPビットトラフィックをプレミアムサービスにマッピングし、すべてのAビットトラフィックをマッピングして、「最良の努力」キューで1つの優先度で処理することができる必要があります（単一レベルのように見えますAビットトラフィックは、パスにあるマルチレベル要素の最良のレベルに相当する優先度にマッピングする必要があります）。
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.
一方、後の経験が必要だと私たちに納得させた場合、両方のクラスのサービスのアーキテクチャを展開することの欠点は何ですか？両方のサービスクラスの機能ブロックは類似しており、同じメカニズムによって提供され、パラメーター化されています。保証されたサービスが使用されない場合、ほとんど失われることはほとんどありません。[4]で赤管理された最善の努力のキューが強く推奨されており、このアーキテクチャの展開がレッド管理された最善の努力キューの展開を推進する限り、それは明らかに肯定的です。プレミアムサービスが使用されていない場合、単純な優先サービスを備えた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.
「通話ごと」の動的セットアップがなければ、使用法プロファイルの事前構成は、サービスの種類がプレミアムであるか保証されているかにかかわらず、常に「使用しないビットの支払い」と解釈できます。私たちは、これを、たとえば電話回線の支払いなど、いつでも利用できると予想されるサービスのレベルに支払うと考えることを好みます。顧客は、追加料金を請求せずに幅広いローカルエリアを呼び出すことができるようにするために、追加の定額料金を支払うか、電話で支払う可能性があります。顧客は、どこでも行われたすべてのコールに対して「通話ごと」ベースで支払う場合がありますが、通常、ほとんどの顧客にとって最も経済的な選択肢ではないことがわかります。同様の価格設定構造がインターネットで発生する可能性があります。
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.
差別化されたサービスの目標は、一部の組織のインターネット帯域幅を制御することです。コントロールは個人が独立して行うことができます。つまり、ユーザーは自分のパケットにビットを設定して最も重要なトラフィックを区別できます。また、組織の優先順位とポリシーについてある程度の知識を持ち、帯域幅を割り当てるエージェントが実行できます。それらのポリシー。個人による独立したラベル付けは簡単に実装できますが、すべての個人がすべての組織の優先事項と現在のネットワークの使用を知り、常にそれに応じてトラフィックをマークすることを期待するのは不合理であるため、十分ではありません。したがって、このアーキテクチャは、組織のポリシーで構成され、マークされたトラフィックの現在の割り当てを追跡し、ポリシーと現在の割り当てに照らしてトラフィックをマークする新しい要求を解釈することができる帯域幅ブローカー（BB）[2]と呼ばれるエージェントで設計されています。。
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.
そのようなエージェントは、共有の最も些細な概念以外のいずれかに固有のものであることに注意してください。個人もルーターも、パケットトランジットには、どのパケットが組織にとって最も重要であるかを決定するために必要な情報がありません。これらのエージェントが存在する必要があるため、フローごとまたはエンドツーエンドパスのすべてのネットワーク要素でフィルターごとの保証を展開するよりもはるかに少ない状態およびより単純な信頼関係を持つエンドツーエンド接続に帯域幅を割り当てるために使用できます。BBSにより、帯域幅の割り当ては組織の階層に従い、セクション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つの責任があります。彼らの主なものは、地域のマークされたトラフィック割り当てを分割し、ローカルドメイン内の葉のルーターをセットアップすることです。もう1つは、境界を越えて隣接する地域のBBSに送信されるメッセージを管理することです。BBは、ドメインごとに1つの特定の信頼領域に関連付けられています。BBには、そのデータベースを使用して要求者を認証する方法と方法を誰が実行できるかについての情報を保持するポリシーデータベースがあります。安全なシステムを展開するためには、リーフルーターをフローするために特定のサービスを提供するように葉のルーターを構成できます。差別化されたサービスの展開が、2つの隣接するドメイン間で動的に割り当てられたマークされたフローが可能な段階に進んだ場合、BBSはこれを実装するために必要なフックも提供します。各ドメインのBBは、隣接するドメインでピアとの安全な関連を確立し、共有境界およびピアのドメインを介してレートとサービスクラス（プレミアムまたは保証）をネゴシエートまたは構成します。私たちが見るように、ある種のサービス、特に早期の実装では、この「安全な関連性」は自動的ではなく、交渉された合意に従って隣接するBBSのその後の手動構成を通じて達成される可能性があります。このネゴシエートレートは、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は最初に要求者の資格情報を認証し、次にリクエストを満たすのに十分な未割り当ての帯域幅が存在することを確認します。リクエストがこれらのテストに合格した場合、利用可能な帯域幅は要求された量によって減少し、フロー仕様が記録されます。フローがこの信頼地域の外に目的地を持っている場合、この要求は、2つの信頼地域の二国間協定を通じて確立された「次のホップ」トラスト地域を介してクラスの割り当てに該当する必要があります。リクエスターの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.
DMZSでは、パケットのローカルソースを決定する明確な方法が必要です。インターフェイスのソースを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つの隣接するドメイン間ですべての契約と交渉が行われます。最初の要求は、パスに沿ったいくつかのドメインでBBS間の通信を引き起こす可能性がありますが、各通信は2つの隣接するBBの間のみです。当初、これらの契約は以前の事前に行われ、かなり静的になります。サービスが進化するにつれて、よりダイナミックになる人もいます。
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フレームワークにより、「境界を越えて信号なし」から「各フローが動的にセットアップされる」まで、スペクトル全体の操作ポイントを操作できます。必要なメカニズムは遍在的に展開され、BBSがより洗練されるようになるため、このスペクトルを経時的に移動することを期待するかもしれませんが、スペクトルの静的に割り当てられた部分には常に使用が必要です。この幅広い選択肢を同時にサポートする能力は、インクリメンタルな展開とISPがユーザーに幅広い製品や価格を作成できるようにすることで重要であると考えています。このセクションの例は、洗練度の増加のスペクトルにほぼ従います。個々のフローセットアップトランザクションで保証またはプレミアムとして要求できるマークされたトラフィックの量をドメイン契約することに注意してください。例では、実際のトランザクションは保証またはプレミアムのいずれかを指定する必要がありますが、「マークされた」と書かれています。
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メッセージは境界を越えません。この交渉は、各ドメインの人間の代表者によって行われると仮定します。この場合、BBSは2つの機能のいずれかを実行するだけで、ローカルドメイン内でこのプロファイルを割り当てるものです。このすべての隔離を事前に設定することさえ可能であり、BBは適切な時期にプロファイルをセットアップして解体し、葉のルーターのソフト状態を更新するだけです。ユーザードメインBBから、プロファイルはソフト状態として、指定された時間中にフローの最初のホップルーターに送信されます。これらのプロファイルは、RSVP、RSVP、SNMP、または一部のベンダー固有のメカニズムのバリアントを使用して設定される場合があります。この静的なアプローチは、すべてのマークされたトラフィックで機能しますが、厳密に過度にサブスクライブされた要件ではありませんが、ドメインを通るボトルネックパスのわずかな割合に保持されるか、そうでなければ井戸に制約されている限り、プレミアムトラフィックにのみ適切です - 知られている動作。サービスに関連する期待に応じて、同様の制限が保証される可能性があります。
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に、リーフルーターにプロファイルを設定する例を示します。使用法プロファイルは、ドメイン全体のISPと交渉されており、BBは要求されているように個々のフローの間でそれを分割しています。葉のルーターメカニズムは、図3に示されているもので、トークンバケットが使用法プロファイルのパラメーターに設定されています。ISPのBBは、プロファイルが維持されるように、その顧客のIngressルーターで独自のプロファイルメーターを構成します。このメカニズムを図5に示しました。アクティブなプロファイルの期間と開始時間がBBで維持されると仮定します。プロファイルは、BBから送信されたメッセージによってIngressデバイスに送信されるか、Ingressデバイスからクリアされます。この例では、van@lblがDDC@MITに相談したいと考えています。LBL-BBは、ソースアドレス「V：4」を持ち、宛先アドレス「D：8」に移動すると指定されたフローに割り当てられるように、プレミアムサービスをフローに割り当てることを求めるVANからリクエストが送信されます。このフローは、128kb/秒のレートで構成し、午後1時から午後3時まで割り当てる必要があります。リクエストは、安全で検証可能な方法で「署名」する必要があります。リクエストは、LBL-BBへのデータ、ネットワーク管理者への電子メールメッセージ、またはネットワーク管理者への電話で送信される場合があります。LBL-BBはこのメッセージを受信し、ドメインの未使用プレミアムサービスの128kb/秒が午後1時から3時まであることを確認し、適切なプロファイルメーターを設定するメッセージをLEAF1に送信します。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は、静的に割り当てられたインターネットのマークされたトラフィックのエンドツーエンドの例を示しています。Trust Regionの境界にある数値は、それらの境界で受け入れられる静的に割り当てられたマークされたパケットレートの合計を示しています。たとえば、100kbpsのマークされたトラフィックをLBLからESNETに送信できます。ESNET出口境界のプロファイルメーターには、100kbpsのレートに設定されたトークンバケットが設定されます。（LBLの出口にシェーパーセットがあり、マークされたトラフィックが集約プロファイルに適合するようにします。）トランジットネットワーク内のテーブル「バブル」は、ポリシーデータベースを表示し、トランザクションが完了した後の値を反映しています。図7では、Vは10 kbpsでMITでLBLからDへのフローを送信したいと考えています。図6のように、このプロファイルのリクエストはLBLのBBで作られています。LBLのBBはリクエストを認証し、その方向に進むマークされた割り当てに10kbpsが残っているかどうかを確認するためにチェックします。そのため、LBL-BBはESNET-BBにメッセージを渡し、このフローにマークされた割り当ての10kbpsを使用したいと言っています。ESNETはメッセージを認証し、データベースをチェックし、未使用の10kbps（その方向の次の領域）への10kbpsのマーク付き割り当てがあることを確認します。ポリシーは、ESNET-BBが割り当ての一部を使用しようとしているときに、常に（「尋ねる」）（「尋ねる」）しなければならないということです。Mearnet-BBはメッセージを認証し、データベースをチェックし、MITへの20kbpsの割り当てが未使用であり、その境界でのポリシーは、割り当ての一部が使用されようとしている場合にMITに通知しないことを発見します（「<50 OK」合計割り当ては50です）。点線は、「暗黙の」トランザクション、つまりポリシーが「私に尋ねないで」と言わなかった場合に起こったであろうトランザクションを示しています。これで、各BBはこの要求に「OK」メッセージをその境界を越えて渡すことができます。これにより、vはDに送信できますが、その逆も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が、使用中の10 kbpsへの顕著な割り当てのすべてを見つけるのと同じ例を考えてみましょう。静的割り当てを使用すると、ESNETはこの要求に「いいえ」をLBL-BBに送信する必要があります。おそらく、LBL-BBはこの情報を記録して、月末のオーバーブッキングについてESNETに不満を言うでしょう！この種の「ビジーシグナル」に対する解決策の1つは、ESNETが顧客のニーズを予測するのを改善したり、すべてのフローに対して長い事前予約を必要とすることですが、帯域幅の証券会社の決定が動的になる可能性もあります。
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.
動的割り当てと追加のメカニズム：私たちが見るように、動的割り当てには、より複雑なBBSと、より多くの状態を維持する必要性を含む、より複雑な国境警備が必要です。ただし、状態がわずかに増加する重要なサービスが可能になります。
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は10kbpsにMITでDと話すように要求します。割り当ては動的であるため、国境警備員にはプリセット値がなく、代わりにその境界を越えることが許可されたマークされたトラフィックの現在のピーク値を反映するように設定されています。リクエストはLBL-BBに送信されます。
Figure 9. First step in end-to-end dynamic allocation example.
図9.エンドツーエンドの動的割り当ての例の最初のステップ。
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を追加」できるかどうかをMearnetに要求します。図7の例のように、MITのポリシーはこのケースについて「尋ねない」ように設定されているため、点線の行はメッセージが交換されなかった「暗黙のトランザクション」を表します。ただし、CherowNetはテーブルを更新して、MITにマークされた割り当ての20kbpsを使用していることを示しています。
Figure 10. Second step in end-to-end dynamic allocation example
図10.エンドツーエンドの動的割り当ての例の2番目のステップ
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の「Virtual OK」により、近接BBがBorder RouterにESNET-NEARNET境界を越えてマークされた割り当てを10 kbps増加させることができる3番目のステップが表示されます。
Figure 11. Third step in end-to-end dynamic allocation example
図11.エンドツーエンドの動的割り当ての例の3番目のステップ
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は、その要求の近くのBBの「OK」をESNET-BBに送信したことを示しています。これにより、ESNET-BBはボーダールーターにメッセージを送信して、フロー「V-> D」に10 kbpsサブクラスを作成します。これは、動的に割り当てられたばかりの10kpbsがその接続にのみ使用されるようにするために必要です。これには、1フロー状態を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 Border Routerはサブクラスが作成された「OK」を提供し、ESNET-BBがLBL-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.
マルチキャストフローの場合、少なくとも1つの出口にバインドされているパケットは、そのレベルのサービスのドメインを介してすべての出口ポイントに運ぶことができると想定しています。上流のブランチがマークされている場合、特定のマルチキャストブランチがBest-Effortで購読されている場合、境界を横断する前にビット設定がクリアされます。このフロー識別に必要な情報は、マルチキャストフローであるため、このフローに既に保持されている既存の状態を強化するために使用されます。私たちはすでにこのフローを「キャッチ」していることに注意していますが、今ではビットパターンを潜在的にクリアする必要があります。
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がBBSの管理構造と相互運用して、より良いスケーリングを提供する方法について説明します。
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]のバージョンを提供するために使用できるほど十分に一般的であると考えています。WG。最初に、プレミアムサービスは、バーストサイズが1つのパケットに制限され、不適合なパケットがドロップされる制御されたロードサービスの制約されたケースと考えることができることに注意してください。プレミアムサービスをサポートするメカニズムを実装したネットワーク要素は、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のラインで提供されることに依存しています。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リソースセットアップモデルと3つの大きな違いがあることに注意してください。
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. エンドツーエンドのリソース割り当てを設定する前に、隣接する信託地域のBBS間にaprioriの二国間ビジネス関係が存在します。リアルタイムシグナル伝達は、事前にネゴシエートされたマークされた帯域幅の可用性をアクティブ化/確認し、必要に応じて割り当て量を動的に再調整するためにのみ使用されます。ドメインを横切るこのリアルタイムシグナリングは必須ではありませんが、二国間協定の性質に依存します（たとえば、契約は「私の割り当ての一部を使用するときはいつでもあなたに伝える」と述べるかもしれません。）。
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.
2. パケットヘッダーのいくつかのビット、すなわちPビットとAビットは、各パケットのサービスクラスをマークするために使用されるため、フルパケット分類（ヘッダー内のすべての関連フィールドをチェックすることにより）は、葉のルーター;その後、パケットはクラスビット設定に従って提供されます。
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はメッセージを処理し、リクエストが承認された場合、適切なフローごとのパケット分類をセットアップするLeafルーターにメッセージを転送します。また、出力ボーダールーターにメッセージを送信して、アウトバウンドトラフィックのプロファイルメーターでパケットシェーピングにマークされたマークされたトラフィック割り当てに追加する必要があります。（これが常に完全な割り当てに設定される可能性があります。）RSVPメッセージは、ローカルドメインのボーダールーターまたはローカルドメインのBBから、隣接するISPの境界ルーターに境界を越えて送信する必要があります。ISPがBBとDiff-Servフレームワークを使用してRSVPを実装している場合、そのボーダールーターはメッセージを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.
このドキュメントは、差別化されたサービスのリファレンスアーキテクチャを提示しました。特に早期および部分的な展開については、いくつかのバリエーションを想像できますが、ここではこれらすべてのバリエーションを列挙していません。最近、差別化されたサービスに対する大きな市場需要がありました。その要求を満たすための多くの努力の1つとして、このメモは、差動サービスを提供するための柔軟なアーキテクチャのフレームワークをスケッチし、特に2つの基本的なタイプの微分サービスをサポートするための単純なパケット転送パスメカニズムのセットを定義します。さらなる調査と改良が必要な多くの問題とパラメーターは残っていますが、現時点では差別化されたサービスの展開を段階的に展開することが可能であり、実現可能であると考えています。まず、パケット転送パスで必要な基本的なメカニズムが明確に理解されていることを考えると、手動で構成されたBBSおよび静的リソース割り当てで、保証されたサービスとプレミアムサービスの両方を実装できます。当初、ネットワークに入院するマークされたトラフィックの量に関する保守的な選択をお勧めします。第二に、このメモと著者の実験的作業から始まる努力を続ける予定です。ESNETとケアンに関する進行中の試験の実装から得た経験を、IETFへの将来の提案に変えたいと考えています。
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つのサービス、プレミアム、保証、および最善の努力を備えたアーキテクチャを定義することです。サービスクラスごとに複数のレベルを標準化する前に、より多くの実験と経験が必要であるようです。私たちの基本レベルのアプローチは、誰もが「少なくとも」プレミアムサービスを提供し、文書化されたサービスを保証する必要があると述べています。私たちは両方についてかなり強く感じています1）この時点で、ミニマリストの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.
著者は、直接と電子的に多くの議論の恩恵を受けており、ここで提示された多くのアイデアの起源に責任を負っているデイブ・クラークに特に感謝したいと考えていますが、彼はこの文書のすべてのコンテンツに同意しません。また、以前のドラフトについてのコメントについてサリー・フロイドに感謝します。Jon Crowcroftからのコメントは、セクション5を含めて、私たちが部分的に責任を負いました。FredBakerからのコメントは、それらをエンコードするために使用されるビットパターンに関係なく、2つの基本レベルサービスを定義していることを明確にしようとしました。
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.クラーク、「インターネットへのサービス差別の追加」、1995年10月、メリーランド州ソロモンズ、ソロモンズ、第23回通信政策研究会議（TPRC）の議事録。
[2] V. Jacobson, "Differentiated Services Architecture", talk in the Int-Serv WG at the Munich IETF, August, 1997.
[2] V.ジェイコブソン、「差別化されたサービスアーキテクチャ」は、1997年8月、ミュンヘンIETFの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] Clark、D。およびJ. Wroclawski、「インターネットでのサービス配分へのアプローチ」は、1997年8月、ミュンヘンIETFのInt-Serv WGでD. Clarkの進行中の仕事も話しています。
[4] Braden, et al., "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
[4] Braden、et al。、「インターネットにおけるキュー管理と混雑回避に関する推奨事項」、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] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（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. Floyd and V. Jacobson、「パケットネットワークのリンク共有およびリソース管理モデル」、Networkingに関するIEEE/ACMトランザクション、PP 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サービス」、Cisco Systems White Paper、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. Guerin、「保証されたサービス品質の仕様」、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. Clark and W. Fang、「Best Effect Effect Packet Delivery Serviceの明示的な割り当て」、IEEE/ACMトランザクション、1998年8月、Vol6、No 4、pp。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
Kathleen Nichols Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134-1706
Phone: 408-525-4857 EMail: kmn@cisco.com
電話：408-525-4857メール：kmn@cisco.com
Van Jacobson Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706
Van Jacobson Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134-1706
EMail: van@cisco.com
Lixia Zhang UCLA 4531G Boelter Hall Los Angeles, CA 90095
Lixia Zhang UCLA 4531G Boelter Hall Los Angeles、CA 90095
Phone: 310-825-2695 EMail: lixia@cs.ucla.edu
電話：310-825-2695メール：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.
ドラフト・ニコルズ・ディフSVC-00が提出された後、共著者はデイブ・クラークとジョン・ロクラウスキーと話し合い、1997年12月のIETF統合サービスワーキンググループ会議でドラフトにプレゼンテーションスロットを使用しました。スライドの読み物は、「メカニズム」、「サービス」、「ルール」に関するクラークの提案であり、その後IETF差別化されたサービスワーキンググループを形成したプロセスの多くを導きながら、標準プロセスを進める方法であることを示しています。デイブ・クラークの講演は、その強みと互換性のある方法でインターネットにサービス品質をもたらすための確固たるアプローチを与えてくれたと信じています。
The slides presented at the December 1997 IETF Integrated Services Working Group are included with the Postscript version.
1997年12月のIETF Integrated Servicesワーキンググループで提示されたスライドは、PostScriptバージョンに含まれています。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。