RFC2638 日本語訳
2638 A Two-bit Differentiated Services Architecture for the Internet.K. Nichols, V. Jacobson, L. Zhang. July 1999. (Format: TXT=72785, PS=1610846, PDF=315195 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Nichols
Request for Comments: 2638 V. Jacobson
Category: Informational Cisco
L. Zhang
UCLA
July 1999
コメントを求めるワーキンググループK.ニコルズ要求をネットワークでつないでください: 2638年のV.ジェーコブソンカテゴリ: 情報のコクチマスL.チャンUCLA1999年7月
A Two-bit Differentiated Services Architecture for the Internet
インターネットへの安っぽい微分されたサービス構造
Status of this Memo
この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)インターネット協会(1999)。 All rights reserved。
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 Integrated Services作業部会の1997年12月のミーティングへのデーブ・クラークのその後のプレゼンテーションと協力してIETFのDifferentiated Services作業部会の構成、ここに提示された考えの多くより前に起こって、配分のときにRFCs2474と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.
このドキュメントの追伸バージョンは付録としてクラークのスライドを含んでいます。 また、このドキュメントの追伸バージョンは読み易さで大いに支援する多くの数字を含んでいます。
1. Introduction
1. 序論
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
このドキュメントはインターネットのために微分されたサービスに構造を提示します。 デーブ・クラークとヴァン・ジェーコブソンはミュンヘンのIETFミーティング[2、3]にそれぞれ微分されたサービスに対する仕事を提示しました。 それぞれで、インターネットでパケットに対する新しい種類のサービスを提供するのにIPヘッダーの1ビットを使用する方法がわかりました。 全く異なった方針仮定でこれらは非常に異なった2種類のサービスでした。 続く議論は両方のサービスタイプには長所があって、非常に同様のセットで両方のサービスタイプは実行できると私たちに納得させました。
Nichols, et al. Informational [Page 1] RFC 2638 Two-bit Differentiated Services Architecture July 1999
ニコルズ、他 微分されたサービス構造1999年7月に安っぽい情報[1ページ]のRFC2638
mechanisms. We propose an architectural framework that permits the use of both of these service types and exploits their similarities in forwarding path mechanisms. The major goals of this architecture are each shared with one or both of those two proposals: keep the forwarding path simple, push complexity to the edges of the network to the extent possible, provide a service that avoids assumptions about the type of traffic using it, employ an allocation policy that will be compatible with both long-term and short-term provisioning, make it possible for the dominant Internet traffic model to remain best-effort.
私たちは経路メカニズムを進める際にこれらのサービスタイプと功績の両方の使用にそれらの類似性を可能にする建築枠組みを提案します。メカニズムこの構造の主要な目標はそれぞれそれらの2つの提案の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つの異なったサービスタイプ(さまざまな微分されたサービスを実行して、微分されたサービスネットワークに食糧を供給するためにフレキシブルな枠組みを提案するのに使用できる推進経路への1セットの一般的機構)を提示することです。 それは正確に微分されたサービスの好都合な展開に必要であるこの種類の構造です: 私たちは、短期的で実行できる基関数の枠組みとセットを必要として、共同利用できるサービスを提供しますが、時間内に必要に応じて各サービスの中で、より多くのレベルの分化につながることができる実験と労作に「砂場」を供給できます。
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仕事で共同利用するかもしれなくて、展開のために推薦を与えるか。
Nichols, et al. Informational [Page 2] RFC 2638 Two-bit Differentiated Services Architecture July 1999
ニコルズ、他 微分されたサービス構造1999年7月に安っぽい情報[2ページ]のRFC2638
2. Architecture
2. 構造
2.1 Background
2.1 バックグラウンド
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つのタイプのすべての交通へのベストエフォート型のサービスを提供します。 インターネットへの高度サービスの添加に関して多くの提案をしました。 私たちはIPに対する微分されたレベルのサービス(1ビット[1、2、3]によって指定されたそれぞれ)を加える2つの特定の方法に焦点を合わせます。 これらのサービスはインターネットの伝統的なサービスから急進的な出発を表しますが、また、それらはサーキットベースのモデルを当てにする伝統的な「サービスの質」建築からの急進的な出発です。 これらの提案の両方がネットワーク縁への内部のネットワークルータによって使用される、ただ一つの一般的なメカニズム、複雑さの大部分を押して、および微分されたサービスの状態を定義しようとします。 両方が要求されていて、割り当てられているリソースとして帯域幅を使用します。 クラークとWroclawskiは用法が輪郭を描く統計的に食糧を供給される「予想された容量」[3]に続く「確実な」サービスを定義しました。 そのようなサービスのユーザが受信するという保証は予想された容量プロフィールの範囲内にとどまる限り、そのような交通が落とされそうにないということです。 「ありそうもないこと」の正確な意味は食糧を供給されて、サービスがどれくらいよくそうであるかによります。 Assuredサービス交通の流れはProfileを超えるかもしれませんが、同じ保証レベルは余分な交通に与えられていません。 ジェーコブソンはルータ[2]で厳密に申込みが超過していないピーク容量Profilesに従って食糧を供給されて、それ自身の高い優先待ち行列が与えられている「プレミアム」サービスを定義しました。 炸裂がネットワークに注がれないように食糧を供給されたピークレートに制限されて、形成されて、Premiumサービス交通の流れは、形成されていて困難です。 プレミアムサービスは単にそれぞれのルータの「不-度」に比例して流れの炸裂がネットワークの縁の整形器にもかかわらず、その後列を作るかもしれない「仮想のワイヤ」を提示します。 それらの多くの類似性にもかかわらず、これらの2つのアプローチが基本的に異なったサービスをもたらします。 前者は、後者がPremiumパケットsの待ち行列のときに小さいジターにもかかわらず、待ち行列遅れにもかかわらず、待ち行列管理の必要性がないのをもってサービスを作成している間、「より良い努力」サービスを提供するのにバッファ管理を使用します。
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.
Assuredサービスは[3]でクラークとWroclawskiによって導入されました、私たちは私たちの構造のための仕様でいくつかの変更をしましたが。 さらに、クラークとFang[10]で気品と「予想された容量」枠組みを与えます。 この枠組みは、「時には、ネットワークの混雑について異なったレベルのベストエフォート型サービスを提供します」に焦点を合わせられますが、「保証された」レベルを保証を実行するために別々のルータ待ち行列を持っているのが可能であるとまた言及します。 私たちは、この枠組みと私たちのTwo-ビット構造は互換性がありますが、これがさらなる探検を必要とすると信じています。 Premiumサービスがほかの場所に記録されていないとき、私たちは、安っぽい構造の記述で次に、それについて説明して、これの後をつけます。
Nichols, et al. Informational [Page 3] RFC 2638 Two-bit Differentiated Services Architecture July 1999
ニコルズ、他 微分されたサービス構造1999年7月に安っぽい情報[3ページ]のRFC2638
2.2 Premium service
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]では、インターネットの現在のベストエフォート型サービスと基本的に異なったPremiumサービスは提示されました。 しかし、このサービスが取り替えることになっていない、ベストエフォート型、主として商業サービスの現れている需要にこたえるために、それはベストエフォート型交通とネットワークを共有できます。 これは、両方の種類の交通に同じネットワークを使用できるので、経済的に望ましいです。 総ネットワーク容量のわずかな百分率をPremium交通に割り当てるでしょうが、それにはるかに高く値を付けると予想されます。 そのようなサービスの1つの使用は「仮想の専用線」を作成することであるかもしれません、建築費を節約して、別々のネットワークを維持して。 標準の電話回線と似て、プレミアムサービスは受信機が持ち上げられるとき顧客がそこにいる予定である容量です、家庭によって、それが多くの時間を空費することであるかもしれませんが。 このようにPremium交通に食糧を供給すると、最悪の場合で割り当てられたPremiumの量に従って、ベストエフォート型インターネットの容量は減少します、その結果、それが時価でなければならないでしょう。 他方では、その容量が使用されていないときはいつも、それはベストエフォート型交通に利用可能です。 burstyであり、待ち行列管理が充血性のエピソードに公正に対処するのを必要とする通常のベストエフォート型交通と対照して、このPremiumサービスは故意に非常に通常のトラフィック・パターンと小さいか実在しない待ち行列を作成します。
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.
プレミアムサービスレベルは特定の流れ(または、流れの集合)のための必要なピークビット伝送速度として指定されます。 ネットワークとのユーザ契約はピークレートを超えないことです。 ネットワーク契約は交通を送るとき、収縮した帯域幅が利用可能になるということです。 最初に、ホップルータ(または、他のエッジデバイス)は、ネットワークに入るパケットをフィルターにかけて、Premiumサービス仕様に合っているもののPremiumビットを設定して、ネットワークに入る前に流れですべての交通が押し破くそのsmoothsを形成する交通を実行します。 このアプローチはホストにおける変化を全く必要としません。 経路に沿った対応するルータは2つのレベルの優先権待ち行列を必要とします、最初に設定されたPremiumビットですべてのパケットを送って。 低優先度でベストエフォート型交通を無印であり、列に並ばせて、送ります。 これは2「仮想ネットワーク」をもたらします: バッファが交通を吸収するように設計されている状態で今日のインターネットと同じものははち切れます。 そして、交通が収縮したピークレートに制限されて、形成されますが、パケットが待ち行列のネットワークを通ってそれらが待ち行列遅れをほとんど全く経験しない動くもの。
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
この構造では、別々に、サービス契約を上がっている設定と交通プロフィールより単に推進経路決定をします。 管理か「信用」境界で取り締まって、形成するのを除いて、推進経路で扱われる必要がある唯一の動作がパケットを1ビットにおける2つの待ち行列の1つに分類することであり、2を修理するのは使用を列に並ばせます。
Nichols, et al. Informational [Page 4] RFC 2638 Two-bit Differentiated Services Architecture July 1999
ニコルズ、他 微分されたサービス構造1999年7月に安っぽい情報[4ページ]のRFC2638
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パケット範囲で小さいと予想されます。 境界の政策は、レートコンプライアンスを実施して、簡単な象徴バケツによって実施されるかもしれません。 推進経路のメカニズムが簡単なままで残っている間、ダイナミックに構成可能であって、かなり複雑になるように入場と設定の手順が時間内に発展すると予想されます。
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.
推進経路メカニズムが適所に静的割り付けをすることによっていったんあると、役に立つ方法でこの構造で組み込まれたPremiumサービスは配備できます。 ネットワークマネージメント構成を通した特別な処理のために交通の流れを指定できます。 交通の流れはパケットのヘッダーのソース、目的地、または分野のどんな組み合わせでも指定されるべきです。 最初に、ホップ(葉の)ルータは、ソースIPアドレス、送付先IPアドレス、プロトコル識別子、ソースポートナンバー、および目的地ポートナンバーから成りながら、ヘッダーtupleのすべてか一部で流れをフィルターにかけるでしょう。 この分類に基づいて、最初に、ホップルータは、交通形成を実行して、先行分野の指定されたPremiumビットを設定します。 終わりホストはエンドシステムが一般に「意識する」ようになるなら、それら自身の形成をするかもしれませんが、「意識していた状態でサービスを微分し」て、最初にルータを飛び越すことであることがこのようにして必要ではありません。単に警察。
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.
申し込まれたレートと放出量への固守はネットワークへのエントリーにおいて、または、エンドシステムか最初のホップルータで励行されなければなりません。 イントラネット、管理ドメイン、または「信用領域」の中では、次に、唯一Premiumビットの上でパケットを分類して、調整できます。 パケットが境界を越えるところでは、取り締まり機能はきわどいです。 入られた領域は順応がないかどうか最優先するパケット流動を2つの領域が同意したレートまでチェックするでしょう、レートを超えているパケットを捨てて。 その結果、確実にする領域の利益のためでは、同意することへの順応が出口で評価するということです。 この要件は、Premium交通がバースト無料であることを意味します、そして、応募超過が統治するノー、直接Premium待ち行列が容易にそうすることができるという観測への先導と共に、大きさで分けられて、パケットを落とす必要性とその結果待ち行列経営政策の必要性を防いでください。 各ルータでは、最も大きい待ち行列サイズは、他のルータのコネ度合いに関連して、その結果、かなり小さいです、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.
プレミアム帯域幅配分は、彼らがネットワークで委任を表すとき申込みが超過しるはずがなくて、時価であるべきです。 また、Premium交通がこの構造で[3]のベストエフォート型交通かAssuredデータ通信量のどちらかよりかなり少ない遅れ変化になることに注意してください。 保険料率は、短期間購読ベースで構成されているか、またはオンであるかもしれません。ダイナミックなセットアップかシグナリングが利用可能であるときに、要求します。
Nichols, et al. Informational [Page 5] RFC 2638 Two-bit Differentiated Services Architecture July 1999
ニコルズ、他 微分されたサービス構造1999年7月に安っぽい情報[5ページ]のRFC2638
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はどうPremiumパケット流動を特定の管理ドメイン、A社の中で確立して、アクセスリンクの向こう側にA社のISPに送るかを示しています。 ホストの最初に、ホップルータがホストのIPアドレスからISPを通して達している送付先IPアドレスまでの流れを合わせるために構成されたと仮定してください。 Premium流動はA総Premium配分会社がISPから持っているよりともにわずかなレートによってホストから構成されます、1秒あたりのrバイト、そして、彼らがホストを置き去りにするとき、会社でその配分の量を他のホストに割り当ててあるより小さいA.Packetsがどんな特別な方法でもマークされません。 最初に、ホップルータは、すべて到着しているパケットのPremiumビットをきれいにして、すべてのパケットのPremiumビットを指定された流れにはめ込んで、Premium流動で構成されたレートと放出量にパケットを形成して、低い優先待ち行列でベストエフォート型無印のパケットを列に並ばせて、高い優先待ち行列でPremiumパケットを形成して、それらの2つの待ち行列から簡単な優先権でパケットを送ります。 A社への内部の中間的ルータは、簡単な優先権でPremiumビットに基づく2つの出力キューとサービスの1つにおけるパケットが待ち行列であると待ち行列に入れます。 それらが出口流動かイングレス流動を処理しているかどうかによって、境界ルータは全く異なったタスクを実行します。 出口境界ルータはレートrに従うために集合Premium交通にいくつかの造り直すことを実行するかもしれません、流れが集めたPremiumの数によって。 イングレス境界ルータは、象徴バケツで実行できる簡単な取り締まり機能を実行する必要があるだけです。 例では、流れが1秒あたりのrバイトを超えていない限り、ISPはAからすべてのPremiumパケットを受け入れます。
Figure 1. Premium traffic flow from end-host to organization's ISP
図1。 終わりホストから組織のISPまでのプレミアム交通の流れ
2.3 Two-bit differentiated services architecture
2.3 安っぽい微分されたサービス構造
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
クラークとジェーコブソンの提案はそれらを実行するのが必要である機能ブロックの位置とタイプにおいて著しく同様です。 その上、彼らはネットワークで両立しなくない全く異なったサービスを実行します。 Premiumサービスはベストエフォート型交通を飢えさせることができないで、かなり簡単なやり方で割り当てることができる取るにたらない待ち行列遅れで保証されたピーク帯域幅サービスを実行します。 このサービスは市販のアプリケーション、ビデオ放送、ナレーターの声IP、およびVPNsの強い上告を持っているように思えるでしょう。 他方では、このサービスは制限過ぎ(困難な限界における)て、かついくつかのアプリケーションのために過剰設計されていると(過剰配分がありません)判明するかもしれません。 Assuredサービスは(非低下しました)ベストエフォート型パケットと保証の堅さがよく個々のリンクがAssuredパケットの炸裂のためにどう食糧を供給されるかによるとき同じくらいが特性を遅らせるサービスを実行します。 他方では、交通の流れが刑罰なしでどんな追加有効な容量も使用することを許可します、そして、多くのユーザにとって、短い充血性の期間の時々の低下しているパケットは許容できるかもしれません。 このサービスはISPがそうする個々の顧客に提供するものであるかもしれません。
Nichols, et al. Informational [Page 6] RFC 2638 Two-bit Differentiated Services Architecture July 1999
ニコルズ、他 微分されたサービス構造1999年7月に安っぽい情報[6ページ]のRFC2638
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.
もう少し充血性の期間で影響を受けなく見えるインターネットサービスの代価を払うことを望んでいます。 両方のサービスは単に彼らの入場コントロールが計画されるのと同じくらい良いです、割り当てられたピークレートでない交通には、これが、より難しい場合がありますが。
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.
両方のサービスを配備するいくつかの付加的な利益があるかもしれません。 または、Premiumサービスがリソースの保守的な配分であるという範囲に、Premiumに割り当てられた未使用の帯域幅がAssured交通のunderallocatedされるか炸裂一区切りにいくつかの「空間」を提供するかもしれない、ベストエフォート型です。 両方のサービスを配備するネットワーク要素が[4]に示されるようにすべての非プレミアム交通にRED待ち行列管理を実行するでしょう、そして、Premiumの流れをベストエフォート型に混合するという効果は後者でburstinessを減少させるのに役立つかもしれません。 Assuredサービスの強さは炸裂がそれでそれらの自然なファッションで起こるということですが、また、これで食糧を供給すること、入場コントロール、および配分問題が、より難しくなるので、このサービスのためのこの入場方針が完全に定義される前にそれは、より多くの時間と実験がかかるかもしれません。 ピークレートで統計的な共有なしで静的割り付けを使うPremiumサービスは配備できました。
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つのビット・パターンを指定するよう提案します。 私たちはこれらのビット・パターンの明白な名称を標準化過程に残します、その結果、それぞれを指示する記法が少し型に基づいて作る速記を使用します、私たちがPremiumかP-ビットを呼ぶつもりであるもの、私たちが保証かA-ビットを呼ぶもう片方。 ネットワークがこれらのサービスの1つだけを実行して、適切な1ビットしか見ないネットワーク要素を持っているのが可能ですが、私たちは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.
より一般的な意味で、Premiumサービスは普通のベストエフォート型待ち行列より高い優先度で待ち行列に入れられるパケットを指示します。 同様に、Assuredサービスは「正常な」待ち行列の中で低下確率に関して優先的に扱われるパケットを指示します。 これらのサービスタイプ各人[7]の中で、より多くのサービスレベルを加える多くの方法がありますが、このドキュメントはPremiumとAssuredの基準面サービスを指定する立場を取ります。
Nichols, et al. Informational [Page 7] RFC 2638 Two-bit Differentiated Services Architecture July 1999
ニコルズ、他 微分されたサービス構造1999年7月に安っぽい情報[7ページ]のRFC2638
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.
葉のルータはパケットのヘッダーに基づく特定の流れのための交通プロフィールによって構成されます。 この機能性はRFC2205でRSVP作業部会によって定義されました。 図2は、何が葉のルータに到着するパケットに起こるかを示します、それが推進エンジンに通過される前に。 すべての到着パケットには、A-ビットときれいにされたパケットが彼らのヘッダーの上に分類されるP-ビットの両方がなければなりません。 ヘッダーが少しの構成された値にも合っていないなら、すぐに、それを進めます。 取り組んでいる流れはその流れのための用法プロフィールから構成された個々のMarkersを通り抜けます: クラス(プレミアムかAssured)、レート(Assuredのために「予想された」Premiumのために、最大限にする)、および許されている放出量(Premiumに任意であるかもしれない)にサービスを提供してください。 確実な流れパケットは流れが順応中であるときに設定されたそれらのA-ビットがあるMarkerからProfileまで現れますが、そうでなければ、流れは変わりがありません。 それらの構成されたレートを実施するのに必要であるときに、Premium流動のために、Markerはパケットを保持するでしょう。 したがって、Premium流れパケットはそれらのP-ビットセットに従った形成流れでMarkerから現れます。 (私たちが以下で説明するようにPremium流れパケットがMarkerの低下している内部であることは可能です。) Markersから現れるとき、パケットは推進エンジンに通過されます。 それらのPを持っているパケットか私たちがMarkedパケットと呼ぶつもりであるAビットセット。
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-
図3はMarkerの内側の作業を示しています。 AssuredとPremiumパケットの両方に関しては、象徴バケツは用法プロフィールで指定された流速で「いっぱいになります」。 Assuredサービスにおいて、象徴バケツの深さはProfileの放出量によって設定されます。 Premiumサービスにおいて、象徴バケツの深さを1か2つのパケットだけの同等物に制限しなければなりません。 (私たちは早めの展開で1つのパケットの深さを勧めます。) 象徴が存在しているとき、Assured流れパケットはそれらのA-ビットを1つに設定します。さもなければ、パケットは推進エンジンに通過されます。 どんな象徴も存在していないとき、Premiumによって構成されたMarkerに関しては、現在の象徴でそれらのP-ビットを設定するのを見て、進められる到着パケットであり、象徴が届くまで、Premium流れパケットは保持されます。 Premium流動が把持待ち行列からはみ出すことができるくらいはち切れると、パケットは落とされるでしょう。 把持待ち行列のためのサイズ限界を構成するのにデータに設定された流れは使用できますが(これはPremiumサービスにおける「炸裂」の意味でしょう)、それは必要ではありません。 Unconfigured把持待ち行列は把持少なくともtwo帯域幅ができるべきです。
Nichols, et al. Informational [Page 8] RFC 2638 Two-bit Differentiated Services Architecture July 1999
ニコルズ、他 微分されたサービス構造1999年7月に安っぽい情報[8ページ]のRFC2638
delay products, adequate for TCP connections. A smaller value might be used to suit delay requirements of a specific application.
TCP接続に、適切な製品を遅らせてください。 より小さい値は、特定のアプリケーションの遅れ要件に合うのに使用されるかもしれません。
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.
実際には、象徴バケツはバイトで実行されるべきであり、バケツの中のバイト数がパケットのサイズに等しいか、または、より大きいなら、象徴を存在させていると考えられます。 Premiumに関しては、バケツは最大のパケットサイズにいっぱいになることができるだけです。 Assuredは構成された炸裂パラメタにいっぱいになるかもしれませんが。 十分なバイト、クレジットが蓄積して、この把持バッファが流れがネットワークで見る唯一の本当の待ち行列を提供するまで、プレミアム交通は保持されます。 バケツの中のバイトがパケットサイズに十分であり、そうだとすれば、Aを設定するなら、Assured、交通がないかどうか、私たちはただテストします。 そうでなければ、唯一の違いは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-ビットのテストを実行しなければなりません。 最初に、簡単な優先権、Premiumパケットで2つの待ち行列を修理しなければなりません。 それぞれの出力インタフェースは低優先度待ち行列のときに[3]で説明されたREDベースのRIOメカニズムを実行しなければなりません。 いつパケットを落とし始めるか間の2つの敷居、普通のベストエフォート型交通のための総待ち行列占有に基づく下側のもの、および1つがそれが待ち行列に入れられたパケットの数に基礎づけたRIO用途で、それらのA-ビットを設定します。 これは、待ち行列の容量が普通のベストエフォート型サービスのために閾値を超えているとAssured業務用輸送への優先ののどんな行動も取られるだけであることを意味します。 この場合、また、Assuredサービスのための閾値に達していないと、無印のパケットだけが落とされるでしょう(REDアルゴリズムを使用します)。 現在待ち行列における、A-ビットパケットの数の正確な計算を保つのはルータで待ち行列のAで両方で噛み付いているエントリーと出口をテストするか、何らかの追加状態のどちらかを必要とします。 図4はすべてのルータのための出力インタフェースのブロック図です。
Figure 4. Router output interface for two-bit architecture
図4。 安っぽい構造のためのルータ出力インタフェース
The packet output of a leaf router is thus a shaped stream of packets with P-bits set mingled with an unshaped best effort stream of packets, some of which may have A-bits set. Premium service clearly cannot starve best effort traffic because it is both burst and bandwidth controlled. Assured service might rely only on a conservative allocation to prevent starvation of unmarked traffic, but bursts of Assured traffic might then close out best-effort traffic at bottleneck queues during congestive periods.
その結果、葉のルータのパケット出力はP-ビットセットがパケットの非形成ベストエフォート型流れによって混ぜられているパケットの形成流れです。その或るもので、A-ビットを設定するかもしれません。 それが押し破かれて、帯域幅が制御されたので、プレミアムサービスはベストエフォート型交通を明確に飢えさせることができません。 確実なサービスは無印の交通の飢餓を防ぐために保守的な配分だけに依存するかもしれませんが、そして、Assured交通の炸裂はボトルネック待ち行列のときに充血性の期間ベストエフォート型交通を見切り売りするかもしれません。
Nichols, et al. Informational [Page 9] RFC 2638 Two-bit Differentiated Services Architecture July 1999
ニコルズ、他 微分されたサービス構造1999年7月に安っぽい情報[9ページ]のRFC2638
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]の後に、私たちはそれらの用法プロフィールに対して流れをテストする推進経路物を「Profile Meters」に指定します。 境界ルータはそれらの入力インタフェースでProfile Metersを必要とするでしょう。 隣接している管理ドメインの間の二国間条約は、すべてのP交通のピーク速度とレートを指定して、A交通(そして、ことによると開始時刻と持続時間)にはち切れなければなりません。 Profile Meterが、微分されたサービスパケット流れがそれらの同意しているレートに従ってあるのを保証するのに信用領域のイングレスで必要です。 Assured流れの不従順なパケットでそれらのA-ビットをリセットしますが、Premium流れの非対応することのパケットは捨てられます。 例えば、リンクを通して会社からISPに入る1のPで噛み付いているISPが、Premiumサービスのrバイト/秒をA社に供給するのに同意したなら著しいパケットが中で計算します。rを超えていると、Aは落とされるでしょう。 1図におけるサービスが代わりにAssuredサービスであるなら、パケットは、ベストエフォート型として単に無印で、進められるでしょうに。
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.
最も簡単な境界ルータ入力インタフェースはそのイングレスリンクの向こう側に契約率によって構成された象徴バケツから組み立てられたProfile Meter(5が計算するのを確実にする)です。 各タイプかPremiumかAssuredと、各インタフェースで、それ自身のプロフィールメーターは特定の境界の向こう側に特定のクラスに対応するようにならなければなりません。 (これは境界に交差するあらゆる流れを別々に取り締まられる、そして/または、形成しなければならないところにモデルと対照的になっています。) 境界ルータ入力インタフェースで必要である正確なメカニズムは配備された配分方針によります。 より複雑なアプローチはセクション4に示されます。
Figure 5. Border router input interface Profile Meters
図5。 境界ルータはインタフェースProfile Metersを入力しました。
3. Mechanisms
3. メカニズム
3.1 Forwarding Path Primitives
3.1 推進経路基関数
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はMarkersとProfile Metersの推進経路物を紹介しました。 このセクションでは、私たちはそれらを構成しなければならなかった原始のブロックを指定します。 基関数は以下の通りです。 象徴バケツを取り締まって、象徴バケツを形成して、一般的なクラシファイア(ビット・パターンクラシファイア)はセッター、優先待ち行列に噛み付きました。 これらの基関数はMarker(形成象徴バケツとaの取り締まりかしばらくセッターのどちらか)とProfile Meter(取り締まっている象徴バケツと点滴器か噛み付いているセッター)を構成できます。
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
一般クラシファイア: 葉か最初に、ホップルータはパケットのヘッダー(どんなRSVPできるルータの一部である機能性も)のtupleに基づいて合っている輸送レベル署名を実行しなければなりません。 上で説明されるように、構成された流れのtuplesマッチ1が順応であるパケットは、テストして、適切なサービス・ビットを設定します。 この機能は、メモリ的で処理徹底的ですが、保たれます。
Nichols, et al. Informational [Page 10] RFC 2638 Two-bit Differentiated Services Architecture July 1999
ニコルズ、他 微分されたサービス構造1999年7月に安っぽい情報[10ページ]のRFC2638
at the edges of the network where there are fewer flows.
より少ない流れがあるネットワークの縁で。
Bit-pattern classifier: This primitive comprises a simple two-way decision based on whether a particular bit-pattern in the IP header is set or not. As in figure 4, the P-bit is tested when a packet arrives at a non-leaf router to determine whether to enqueue it in the high priority output queue or the low priority packet queue. The A-bit of packets bound for the low priority queue is tested to 1) increment the count of Assured packets in the queue if set and 2) determine which drop probability will be used for that packet. Packets exiting the low priority queue must also have the A-bit tested so that the count of enqueued Assured packets can be decremented if necessary.
ビット・パターンクラシファイア: この基関数はIPヘッダーの特定のビット・パターンが設定されるかどうか基づく簡単な両用決定を包括します。 パケットが高い優先権出力キューか低い優先権パケットでそれを待ち行列に入れるかどうか決定するために非葉のルータに到着するとき、4、図のP-ビットがテストされるように、列を作ってください。 低い優先待ち行列のためのバウンドがテストされるパケットのA-ビット1) 設定されるなら、待ち行列における、Assuredパケットのカウントを増加してください。そうすれば、2は、)どれが確率を落とすかがそのパケットに使用されることを決定します。 また、低い優先待ち行列を出るパケットで、必要なら、待ち行列に入れられた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つのレベルの簡単な優先権待ち行列を含まなければなりません。 Premium交通には高い優先待ち行列があります、そして、サービス規則はその待ち行列で最初に、そして、疲労困憊にパケットを送ることです。 Premium交通が決して申込みが超過していないに違いないと思い出してください、そして、その結果、Premium交通はまず待ち行列を見るべきではありません。
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.
象徴バケツを形成します: これは葉のルータでPremium交通に必要であり、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.
象徴バケツを取り締まります: これはProfile Metersに必要であり、5が中で計算するのが示された象徴バケツです。 象徴バケツを取り締まって、到着パケットを決して保持しないでくださいが、到着について検査して、象徴がパケットのサービスのクラスに利用可能であるかどうか確認してください。 そうだとすれば、すぐに、パケットを進めます。 そうでなければ、AssuredのためにPremiumのために低下して、分類し直すか、または非マークして、取り締まり行動を取ります。
3.2 Passing configuration information
3.2 設定情報を通過すること。
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,
明確に、メカニズムは要求の情報を葉のルータに伝えなければなりません。 この設定情報は押し破かれたレートです、そして、それがPremiumであるか、そして、Assuredがタイプします。 また、そこでは、この構成を設定するか、またはクリアするのに特定の分野であることが必要であるかもしれません。 多くの方法でこの情報を通過できます。
Nichols, et al. Informational [Page 11] RFC 2638 Two-bit Differentiated Services Architecture July 1999
ニコルズ、他 微分されたサービス構造1999年7月に安っぽい情報[11ページ]のRFC2638
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を使用するか、またはネットワーク管理者が直接用意ができていて、ある他の方法で含んでいます。 この情報の送付者を認証するためのいくつかのメカニズムがあるに違いありません。 私たちは、今後の標準化作業のためにこれが話題である早めの展開、プロトコル、およびメカニズムのさまざまな方法で構成すると予想します。
3.3 Discussion
3.3 議論
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.
整形器の要件は1ルータあたりの州がネットワークの中央より小さい場合があるネットワークの縁で彼らのプレースメントを動機づけます。 葉のルータには流れが合って、形成される最も大きい負担が必要である速度とバッファリングが、より深く必要であるかもしれないもの以下であるべきであるところにネットワークにあるでしょう。 この機能性が経路のあらゆるネットワーク要素で必要であるというわけではありません。 信用領域に内部であることのルータは交通を形成する必要はないでしょう。 ルータが必要とするかもしれない境界かそうするのを確実にするためにそれらの出口でMarkedパケットの集合流れを形成する願望がイングレスにおける取り締まりメカニズムによる不承諾にもう片方のドメインに乱入しませんでした(ルータの度が低いなら、これは必要でないかもしれませんが)。 さらに、形成は各流れで出るのではなく、その経路を通して個別にドメインを出るすべてのPremium流れの集合に適用されるでしょう。
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).
今日の技術の範囲の中にこれらのメカニズムがあります、そして、PremiumとAssuredサービスがインターネットで必要であるすべてであることが私たちにとってもっともらしく思えます。 時間内にこれらのサービスが不十分であることがわかるなら、この構造は他の種類のサービスレベルを交通に届けるのに移行パスを提供します。 AとPビットは、パケットのヘッダーでマッチングをできたMarkedサービスにもかかわらず、一層のフィルタがさらにサービスレベルを微分する交通を特定するのに使用され続けているでしょう。 ビットを使用して、この道はそれらであらゆる入って来るパケットをフィルターにかけるよりむしろさらなるマッチングをしなければならないパケットの数を減少させます。 より多くの待ち行列レベルと、より複雑なスケジューリングをP-ビット交通に追加できました、そして、経験が、それらが必要であることを示して、処理速度が十分であるなら、より多くのレベルの低下優先権はA-ビット交通に追加されるかもしれません。 私たちは、ここで説明されたサービスが「少なくとも」サービスであるとみなされるよう提案します。 したがって、PremiumサービスへのすべてのP-ビット交通を写像して、ネットワーク要素は、「ベストエフォート型」の待ち行列における、1つのレベルの優先権で扱われるためにすべてのA-ビット交通を少なくとも写像できるべきです(ただ一つのレベルの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
他方では、後の経験が、それらの1つだけが必要であると私たちに納得させるなら両方のクラスのサービスのために構造を配備する下落傾向は何ですか? ブロックの両方が修理する機能的
Nichols, et al. Informational [Page 12] RFC 2638 Two-bit Differentiated Services Architecture July 1999
ニコルズ、他 微分されたサービス構造1999年7月に安っぽい情報[12ページ]のRFC2638
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.
クラスを同様であり、異なってparameterizedされた同じメカニズムは提供できます。 Assuredサービスが使用されていないなら、わずか、が無くなっています。 REDによって管理されたベストエフォート型待ち行列は[4]で強く推薦されました、そして、この構造の展開がREDによって管理されたベストエフォート型待ち行列の展開を押すという範囲に、それは明確に正数です。 Premiumサービスが未使用になるなら、簡単な優先サービスによる2待ち行列は必要ではありません、そして、Markerの形成機能が未使用であるかもしれない、その結果、これらは不要な実現費用を課すでしょう。
4. The Architectural Framework for Marked Traffic Allocation
4. 著しい交通配分のための建築枠組み
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.
これまでのところ、私たちはサービス定義と推進経路メカニズムに焦点を合わせました。今、Marked交通のレベルをインターネットに割り当てるという問題に変わります。 私たちは、ほとんどの組織がデータ通信を含むそれらの年に一度の、または、四半期の基準で決定している予算の部分を修理したのを観測します。 いくつかの追加お金がもっと短期的に見れば起こる任意のコストのための特定のプロジェクトに取り付けられるかもしれません。 順番に、サービスプロバイダー(ISPとNSPs)は、年に一度の、そして、四半期のベースで彼らの計画をしなければならなくて、その結果、「呼び出し」のときに純粋に微分されたサービスを提供することを期待できません。 呼び出しセットアップはただ一つの流れの持続時間のためにMarked交通の配分を作成しますが、食糧を供給するのは静水位のMarked交通をセットアップします。 静水位を時刻仕様で食糧を供給することができますが、ダイナミックなメッセージに対応して変えることができません。 私たちは、両方の種類の帯域幅配分が重要であると予想します。 一般に、これらのサービスが今日同様に多くの情報サービスを説明されるところでMarkedサービスの購入者が、より長い期間予算サイクルに働くと予想できます。 通信販売店は、彼らのサイトをブラウズするとき、「速い」感じを見込み客に与えるためにウェブサーバーとそのウェブサーバーから帯域幅の固定配分を購入したがっているかもしれません。 この配分は前の4分の1のもののヒット率かある種の産業ベースの平均に基づくかもしれません。 さらに、特定の出来事に応じる動的割当て能力があるのが必要です、デモンストレーション、会社の最高経営責任者によるネットワーク放送、または特定のネットワークテストなどのように。 その上、ダイナミックな能力が、特定のソースか目的地が「インターネットでどこでも」あることができるとき、前遂行されたサービスレベルを満たすのに必要であるかもしれません。 「動力」は電話をされたかメールされた要求から合図タイプモデルまでの範囲をカバーしています。 厳密に静的に割り当てられたシナリオは、微分されたサービスの初期の展開で役に立って、forseeable未来のMarked交通の主要部を作ると予想されます。
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
上がっている「呼び出し」ダイナミックなセットがなければ、サービスのタイプがPremiumかAssuredであることにかかわらず「あなたが使用しないビットの代金を支払います」に用法プロフィールのあらかじめ設定をいつも理解できます。 私たちは、思うのを好みます。
Nichols, et al. Informational [Page 13] RFC 2638 Two-bit Differentiated Services Architecture July 1999
ニコルズ、他 微分されたサービス構造1999年7月に安っぽい情報[13ページ]のRFC2638
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.
私たちは厳密に「前-割り当て」られたセットアップからダイナミックな呼び出しセットアップまで作成Marked交通委任の過程をこの連続に沿ってどこでもと呼ぶのにAllocationを使用します、そして、どんなミックスでもこの全体のスペクトルを取り囲むことができるAllocation構造を必要とします。 私たちは、Allocationが組織階層に従わなければならないのをさらに観測します、すなわち、各組織がMarked交通リソースのAllocationのためにドメインの中で全責任がなければなりません。 最終的に、私たちは、二国間条約で作られるAllocation構造には増加の展開のための唯一の勝算があるのを観測します、多面的な協定が管理できないくらい複雑であるときに。 したがって、Allocation構造は境界の向こう側に通ることができるMarked交通の量に関して協定で作られます。 これは今日使用されている「解決」モデルと同様です。
4.1 Bandwidth Brokers: Allocating and Controlling Bandwidth Shares
4.1 帯域幅ブローカー: 帯域幅シェアを割り当てて、制御します。
The goal of differentiated services is controlled sharing of some organization's Internet bandwidth. The control can be done independently by individuals, i.e., users set bit(s) in their packets to distinguish their most important traffic, or it can be done by agents that have some knowledge of the organization's priorities and policies and allocate bandwidth with respect to those policies. Independent labeling by individuals is simple to implement but unlikely to be sufficient since it's unreasonable to expect all individuals to know all their organization's priorities and current network use and always mark their traffic accordingly. Thus this architecture is designed with agents called bandwidth brokers (BB) [2], that can be configured with organizational policies, keep track of the current allocation of marked traffic, and interpret new requests to mark traffic in light of the policies and current allocation.
微分されたサービスの目標は、何らかの組織のインターネット帯域幅を共有しながら、制御されています。 個人が独自にコントロールできますか、すなわち、ユーザが、彼らのパケットのビットにそれらの最も重要な交通を区別するように設定するか、または組織のプライオリティと方針に関する何らかの知識を持って、それらの方針に関して帯域幅を割り当てるエージェントはそれを終わることができます。 すべての個人が彼らのすべての組織のプライオリティと現在のネットワーク使用を知って、いつもそれに従って、それらの交通を示すと予想するのが無理であるので、個人による独立しているラベリングは、実行するのが簡単ですが、十分でありそうにはありません。 したがって、エージェントが帯域幅ブローカー(掲示板)[2]と呼ばれている状態でこの構造が設計されていて、それは、組織的な方針によって構成されて、著しい交通の現在の配分の動向をおさえて、方針の観点から交通を示すという新しい要求と現在の配分を解釈できます。
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
私たちは、そのようなエージェントがいずれにもかかわらず、共有するという最も些細な概念に固有であることに注意します。 個人もそれらのパケットが通過しないルータも、パケットがどれであるかを最も決めるのに必要な情報は組織に重要になります。 これらのエージェントが存在しなければならないので、はるかに少ない状態と、より簡単な信用関係との終わりから終わりへの関係のために帯域幅を割り当てるのに彼らを使用できます。
Nichols, et al. Informational [Page 14] RFC 2638 Two-bit Differentiated Services Architecture July 1999
ニコルズ、他 微分されたサービス構造1999年7月に安っぽい情報[14ページ]のRFC2638
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で議論した推進経路メカニズムと協力してあらゆるネットワーク要素でフル・フローヘッダーをチェックするのを必要とする構造の上で減少させるのが可能になります。 組織的では、多面的な協定がめったに働かないで、この構造が、終わりから終わりに対するサービスが純粋に二国間条約から構成されるのを許容するという観測で掲示板構造は動機づけられています。 BBsは、隣接しているドメインの彼らの同輩と共に限られた信用の関係を確立する必要があるだけです、終わりから端への経路中のルータにおける流れ仕様の設定を必要とする計画と異なって。 実用的な専門用語では、掲示板構造であらゆるルータでというよりむしろ管理ドメインベースで状態を維持するのは可能になります、そして、Premiumの、そして、Assuredサービスのサービス定義で、それは流れ状態単位でまさしく葉のルータに閉じ込めるのにおいて可能になります。
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つの責任があります。 それらの第一のものは、それらの領域のMarked交通配分を分配して、局所領域の中で葉のルータをセットアップすることです。 もう片方は境界の向こう側に隣接している領域のBBsに送られるメッセージを管理することです。 掲示板は特定の信用領域、1ドメインあたり1つに関連しています。 掲示板には、だれができるかの情報がそのデータベースを使用するとリクエスタが認証されるどんな時と方法であるかを保つ方針データベースがあります。 掲示板だけが流れに対する特定のサービスを提供するために葉のルータを構成できます、安全なシステムを配備するのにおいて、重要です。 Differentiated Servicesの展開がダイナミックに割り当てられるところで舞台に達したなら、著しい流れが2つの隣接しているドメインの間で可能である、また、BBsはこれを実行するのに必要であるフックを提供します。 各ドメインの掲示板はレートを交渉するか、または構成する同輩との隣接しているドメインの安全な仲間と共有された境界と同輩のドメインを通したサービスのクラス(プレミアムかAssured)を設立します。 私たちが見るように、何人かのタイプのサービス、および特に早めの実現におけるそれに、この「安全な協会」が自動でなく、交渉された協定通りに隣接しているBBsの人間の交渉とその後の手動の構成を通して達成されるのは、可能です。 この交渉されたレートは掲示板が領域のすべてのホストのために制御する能力です。
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
特定の流れのために配分を望んでいるとき、要求を掲示板に送ります。 要求はサービスタイプ、目標金利、最大の炸裂、およびサービスが必要である期間を含んでいます。 ネットワーク管理者かユーザが手動で要求をすることができますか、またはそれは別の領域の掲示板から来るかもしれません。 その時は、掲示板が最初にリクエスタの信任状を認証することを確かめます。要求を満たすことができるくらいの「非-割り当て」られた帯域幅は存在しています。 そして要求がこれらのテストに合格するなら、利用可能な帯域幅が要求された量で減少する。
Nichols, et al. Informational [Page 15] RFC 2638 Two-bit Differentiated Services Architecture July 1999
ニコルズ、他 微分されたサービス構造1999年7月に安っぽい情報[15ページ]のRFC2638
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.
流れ仕様は記録されています。 流れがこの信用領域の外に目的地を持っている場合では、要求は2つの信用領域の二国間条約を通して確立された「次のホップ」信用領域を通るクラス配分の中に下がらなければなりません。 リクエスタの掲示板は、このレート配分のいくつかを使用することを隣接している領域の掲示板に知らせます。 掲示板は、始まるサービスがことである時間のサービスを与えるためにパケット流動の情報で適切な葉のルータを構成します。 この構成は掲示板が定期的にリフレッシュする「軟性国家」です。 隣接している領域の掲示板は境界以内と流れが最終的な目的地に達するその境界の向こう側にどんな割り当てられたパケット流動が終わることを許可するために境界ルータを構成して、追加構成と交渉にも原因となります。
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隣接しているBBsだけの間には、各コミュニケーションがあります。 初めは、これらの協定は、前交渉されていてかなり静的になるでしょう。 サービスが発展するのに従って、或るものは、よりダイナミックになるかもしれません。
4.2 Examples
4.2 例
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.
このセクションは重要なマルチトランジットのドメインインターネットで掲示板取引に関する例を出します。 掲示板枠組みで、スペクトルの向こう側に「境界の向こう側の合図でないの」から「ダイナミックにセットアップされた各流れ」までポイントを操作します。 必要なメカニズムが遍在して配備されて、BBsが、より洗練されるようになるとき、私たちは、時間がたつにつれてこのスペクトルの向こう側に動くと予想するかもしれませんが、スペクトルの静的に割り当てられた部分には、用途がいつもあるべきです。 私たちは、増加の展開とISPがさまざまな提供と価格設定をユーザに作るのを許容する際に同時に選択のこの広いスペクトルを支持する能力が重要になると信じています。 このセクションに関する例はおよそ増加する洗練のスペクトルに続きます。 私たちが、ドメインがそれぞれの個々の流れにおけるAssuredかPremiumのどちらかが取引をセットアップするとき要求できるいくらかの量のMarked交通を請け負うと思うことに注意してください。 現物売買はAssuredかPremiumのどちらかを指定しなければならないでしょうが、例は「著しい」状態で言います。
Nichols, et al. Informational [Page 16] RFC 2638 Two-bit Differentiated Services Architecture July 1999
ニコルズ、他 微分されたサービス構造1999年7月に安っぽい情報[16ページ]のRFC2638
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.
掲示板メッセージを全く交換していない静的に構成された例: ここに、すべての配分が純粋にユーザ(個々のTCPs、個々のホスト、キャンパスネットワーク、または全体のISP)[6]の間の二国間条約を通して静的に「前-割り当て」られます。 配分が押し破かれたレートの用法プロフィールのフォームとそのプロフィールがアクティブであることになっている時間、あります。 ユーザとプロバイダーは次にユーザドメイン掲示板とプロバイダードメイン掲示板にインストールされるこれらのProfilesを交渉します。 どんな掲示板メッセージも境界に交差していません。 私たちは、それぞれのドメインの人間の代表がこの交渉を完了していると思います。 この場合、BBsだけが彼らの2つの機能の1つ、それらの局所領域の中にこのProfileを割り当てるものを実行しなければなりません。 掲示板は、あらかじめこの細分割当てのすべてをセットアップするのが可能でさえあり、次に、適切な時にProfileをセットアップして、取りこわして、葉のルータにおける軟性国家をリフレッシュする必要があるだけです。 ユーザドメイン掲示板から、指定された時間、軟性国家としてProfileを流れの最初のホップルータに送ります。 これらのProfilesはRSVP、RSVPの異形、SNMP、または何らかの業者特有のメカニズムを使用するのを用意ができるかもしれません。 この静的なアプローチはすべてのMarked交通に取り組むことができますが、厳密に申込みが超過していない要件のために、ドメインを通してボトルネック経路のわずかな百分率まで保たれるか、または別の方法で周知の振舞いに抑制される限り、Premium交通だけに、それは適切です。 同様の制限はサービスに関連している期待によるAssuredのために成立するかもしれません。
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が中で計算するのを葉のルータにProfileをはめ込む例を示しています。 用法プロフィールは全体のドメインのためにISPと交渉されました、そして、掲示板は要求された通り個々の流れにそれを分配します。 葉のルータメカニズムは象徴バケツがある3が中で計算するのが示されたそれが用法プロフィールからのパラメタにセットしたということです。 ISPの掲示板は、Profileが維持されたのを保証するためにその顧客からイングレスルータでそれ自身のProfile Meterを構成するでしょう。 このメカニズムは5が中で計算するのが示されました。 私たちは、どんなProfileもアクティブである時間持続時間とスタート時間が掲示板で維持されると思います。 掲示板から送られたメッセージは、Profileをイングレス装置に送るか、またはイングレス装置からきれいにします。 この例では、私たちは、 van@lbl が ddc@mit と話したがっていると思います。 プレミアムサービスが割り当てられるように頼むヴァンからソースアドレスを持ちながら任じられる流れまでの要求をLBL-掲示板に送る、「V: 4インチ、送付先アドレスに行く「D: 8インチ。」 この流れを128kb/秒の速度のために構成して、午後1時から午後3時まで割り当てるべきです。 安全で、証明可能な方法で要求は「サインされなければなりません」。 データとしてLBL-掲示板、ネットワーク管理者、またはネットワーク管理者への電話におけるメールメッセージに要求を送るかもしれません。 LBL-掲示板は、このメッセージを受け取って、適切なProfile MeterをセットアップするLeaf1へのメッセージが午後1時から3時までの間のドメインのための未使用のPremiumサービスの128kb/秒であり、次に、発信することを確かめます。 Leaf1へのメッセージは、RSVPメッセージ、SNMP、または何らかの独占方法であるかもしれません。 ドメインが通過したすべてがこの要求を満たすことができるくらいの余力を持たなければなりません。
Nichols, et al. Informational [Page 17] RFC 2638 Two-bit Differentiated Services Architecture July 1999
ニコルズ、他 微分されたサービス構造1999年7月に安っぽい情報[17ページ]のRFC2638
Figure 6. Bandwidth Broker setting Profiles in leaf routers
図6。 葉のルータにProfilesをはめ込む帯域幅Broker
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.
掲示板メッセージを交換している静的に構成された例: 次に、私たちはすべての配分が静的に「前-割り当て」られますが、掲示板メッセージが、より大きい柔軟性と交換される例を提示します。 図7は静的に割り当てられたインターネットにおけるMarked交通のための終わりから終わりへの例を示しています。 信用領域境界における数は、合計が静的にそれらの境界の向こう側に受け入れられるパケットレートをMarkedに割り当てたのを示します。 例えば、Marked交通の100kbpsをLBLからESNetに送ることができます。 ESNet出口境界のProfile Meterは象徴バケツをレート100kbpsに設定させるでしょう。 (LBLの出口にMarked交通が集合Profileに従うのを保証するように設定された整形器があるかもしれません。) トランジットネットワーク「気泡」のテーブルは、それらの方針データベースを示していて、取引が完全になった後に値を反映します。 図7では、Vは10KbpsでMITでLBLからDまでの流れを伝えたがっています。 図のように、LBLの掲示板で6、このプロフィールに関する要求をします。 LBLの掲示板は、要求を認証して、10kbpsがその方向に行くMarked配分に残っているかどうか確認するためにチェックします。 あるので、この流れにMarked配分の10kbpsを使用したがっていると言いながら、LBL-掲示板はESNet-掲示板にメッセージを通過します。 ESNetは、メッセージを認証して、データベースをチェックして、それで10kbps Marked配分が存在であるNEARNet(その方向への次の領域)に未使用になるのがわかります。 方針はESNet-掲示板が、いつもそれがいつ配分の一部を使用しようとしているかをNEARNet-掲示板に知らせなければならないという(「尋ねる」)ことです。 NEARNET-掲示板は、メッセージを認証して、データベースをチェックして、MITへの配分の20kbpsが未使用であると発見します、そして、その境界の方針は使用されようとしている(総配分が50である「<50OK」)ために配分の一部がいつであるかをMITに知らせないことです。 点線は「暗示している」取引、すなわち、「私に尋ねないでください」と、方針が言わなかったなら起こった取引を示します。 現在の、各掲示板は境界の向こう側に「間違いありません、な」メッセージをこの要求に通過できます。 これは、VがDに発信するのを許容しますが、逆もまた同様に許容するというわけではありません。 また、Dから発するという要求に、それも可能でしょう。
Figure 7. End-to-end example with static allocation.
図7。 静的割り付けがある終わりから終わりへの例。
Consider the same example where the ESNet-BB finds all of its Marked allocation to NEARNet, 10 kbps, in use. With static allocations, ESNet must transmit a "no" to this request back to the LBL-BB. Presumably, the LBL-BB would record this information to complain to ESNet about the overbooking at the end of the month! One solution to this sort of "busy signal" is for ESNet to get better at anticipating its customers needs or require long advance bookings for every flow, but it's also possible for bandwidth brokerage decisions to become dynamic.
ESNet-掲示板がNEARNet、使用中の10キロビット毎秒にMarked配分のすべてを見つけるのと同じ例を考えてください。 静的割り付けで、ESNetはLBL-掲示板へのこの要求に「いいえ」を伝えなければなりません。 おそらく、LBL-掲示板は、月末にオーバーブッキングに関してESNetに不平を言うためにこの情報を記録します! この種類の「話中音」の1つの解決策がESNetが顧客の必要性を予期するのに回復するか、またはあらゆる流れのために長い前売りの予約を必要とすることですが、ダイナミックになるという帯域幅仲買業決定に、また、それも可能です。
Nichols, et al. Informational [Page 18] RFC 2638 Two-bit Differentiated Services Architecture July 1999
ニコルズ、他 微分されたサービス構造1999年7月に安っぽい情報[18ページ]のRFC2638
Figure 8. End-to-end static allocation example with no remaining allocation
エイト環。 終わりから終わりへの静的割り付け配分のままで残っていることのない例
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.
ダイナミックなAllocationと追加メカニズム: 私たちが見るように、動的割当ては、より複雑な境界の取り締まりと同様により複雑な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は、MITでDと話すよう10kbpsに要求します。 配分がダイナミックであるので、境界policersには、設定値がありません、代わりにその境界に交差することが許可されたMarked交通のピーク電流値を反映するように設定されて。 LBL-掲示板に要求を送ります。
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インチを加えることができるかどうか」NEARNetに尋ねます。 図7の例のように、MITの方針がこのような場合「尋ねないでください」に設定されるので、点線はメッセージが全く交換されなかった「準取引」を表します。 しかしながら、NEARNetは、現在Marked配分の20kbpsをMITに使用しているのを示すためにテーブルをアップデートします。
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図では、私たちはNEARNet-掲示板がESNet-NEARNet境界の向こう側に10キロビット毎秒でMarked配分を増加させるようにMITの「仮想のOK」で境界ルータを言うことができる第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は、その要求のためのNEARNet-掲示板の「OK」がESNet-掲示板に伝わって戻ったのを示します。 これで、ESNet-掲示板は流れ「V>D」のために10キロビット毎秒サブクラスを作成するメッセージを境界ルータに送ります。 これが、ちょうどダイナミックに割り当てられた10kpbsがその接続にだけ使用されるのを確実にするのに必要です。 これがそれを必要とすることに注意してください、状態がLBL-掲示板からESNet-掲示板まで通り過ぎられて、1流れあたり、唯一のこれは流れ情報のレベルとこのさらなる分類が、単にLBLから来ながらその1つの境界ルータにおいてパケットだけの上でする必要である必要がある唯一の境界です。 したがって、動的割当ては5が中で計算するのが示されたそれより複雑なProfile Meteringを必要とします。
Figure 12. Fourth step in end-to-end dynamic allocation example.
図12。 終わりから終わりへの動的割当て例で4番目に踏んでください。
Nichols, et al. Informational [Page 19] RFC 2638 Two-bit Differentiated Services Architecture July 1999
ニコルズ、他 微分されたサービス構造1999年7月に安っぽい情報[19ページ]のRFC2638
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、図の境界ルータがサブクラスが持っている「OK」を与えるESNetが作成されて、ESNet-掲示板が要求をVに知らせるLBL-掲示板に「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つの出口に向かっているパケットは運ぶことができると思います。 境界に交差する前に、上流のブランチがMarkedであるときに、特定のマルチキャストブランチがせいぜい努力に申し込まれたなら、それには、設定がきれいにしたビットがあるでしょう。 この流れ識別に必要である情報は、それがマルチキャスト流動であるのでこの流れに既に維持される現状を増大させるのに使用されます。 既にこの流れを「捕らえている」と述べますが、今、私たちは潜在的にビット・パターンをクリアしなければなりません。
5. RSVP/int-serv and this architecture
5. RSVP/int-servとこの構造
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合図プロトコルの仕様で多くの仕事をしました。 この仕事で提案された安っぽい構造で、容易にそれらの仕様と相互運用性を持つことができます。 このセクションで、私たちは最初に、統合サービスを支持するのにどうセクション3で説明された推進メカニズムを使用できるかについて議論します。 2番目に、私たちは、比例するほうがよくしながら、RSVPが提供するためにBBsの運営機構でどう共同利用できたかについて議論します。
5.1 Providing Controlled-Load and Guaranteed Service
5.1 制御負荷の、そして、保証されたサービスを提供すること。
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で説明された推進経路メカニズムがまた、Controlled-負荷サービス[8]とService[9]のGuaranteed Qualityのバージョンを提供するのにそれらを使用できるくらい一般的であると信じています、int-serv WGによって開発されるように。 まず最初に、放出量が1つのパケットに制限されて、非の従うパケットが落とされる制約つきControlled-負荷サービスのケースとしてPremiumサービスを考えることができることに注意してください。 プレミアムサービスを支持するためにメカニズムを実行したネットワーク要素は、1つ以上の小さい方のパラメータ調整をして、例えば、Controlled-負荷仕様によるピーク交通レートパラメタで象徴バケツサイズで規制を撤廃するか、またはPremiumサービス率を構成して、プロフィールの外のパケットを送るのに低下するのからBest-努力までのパケットが列に並ばせる取り締まり動作を変えることによって、容易により一般的な制御負荷サービスを支持できます。
Nichols, et al. Informational [Page 20] RFC 2638 Two-bit Differentiated Services Architecture July 1999
ニコルズ、他 微分されたサービス構造1999年7月に安っぽい情報[20ページ]のRFC2638
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.
また、Premiumサービスのメカニズムを使用するServiceのGuaranteed Qualityを実行するのも可能です。 RFC2212[9]から: 「保証されたサービスの定義はrのようにRが長い同じくらいb/Rであるのにもかかわらずの、象徴バケツ(r、b)に従って、帯域幅Rがある線によって役立たれている流れの流体遅れによって制限されるという結果を当てにします。」 「サービス率Rがある保証されたサービス、現在のRがそうでは、専用線の帯域幅よりむしろ帯域幅のシェアはこの振舞いに近似します。」 Premiumのサービスモデルは明確にこのモデルに合います。 RFC2212がそれを述べる、「非の従うデータグラムSHOULDが. 」 ベストエフォート型データグラムThusとして扱われて、非の従うデータグラムを落とす取り締まりProfile Meterは許容できるでしょうが、また、ベストエフォート型待ち行列への不従順な低下から発信までのパケットのための動作を変えるのも可能です。
5.2 RSVP and BBs
5.2 RSVPとBBs
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:
このセクションで、私たちはどう終わりから終わりへのリソースIntegrated Servicesにおいて、上がっているよりスケーラブルなセットを届けるためにセクション4で説明されたBBsに関連してRSVPシグナリングを使用できるかについて議論します。 まず最初に、私たちは、オリジナルの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. アプリオリに、1つが終わりから終わりへの資源配分をセットアップできる前に双方のビジネス関係は隣接している信用領域のBBsの間に存在しています。 必要であるときに、リアルタイムのシグナリングは単にあらかじめ交渉されたMarked帯域幅の有用性を活性化するか、または確認して、ダイナミックに配分量を再調整するのにおいて使用されています。 私たちは、ドメイン中のこのリアルタイムのシグナリングが必要ではありませんが、二国間条約の本質によることに注意します(例えば、協定は「私の配分のいくつかを使用するつもりであるときはいつも、私はあなたに言うつもりである」状態であるか否かに関係なく、そうするかもしれません)。
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
ホストによって葉のルータに送られたRSVPメッセージは、局所領域の掲示板に傍受して、送ることができます。 掲示板は、メッセージを処理して、要求が承認されているなら、1流れあたりの適切なパケット分類をセットアップする葉のルータにメッセージを転送します。 また、アウトバウンドトラフィックでパケット形成のためのProfile Meterによる集合Marked交通配分に加える出口境界ルータにメッセージを送るべきです。 (それはこれがいつも完全に設定されるのが可能です。
Nichols, et al. Informational [Page 21] RFC 2638 Two-bit Differentiated Services Architecture July 1999
ニコルズ、他 微分されたサービス構造1999年7月に安っぽい情報[21ページ]のRFC2638
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.
配分。) ISPの境界ルータに隣接したどちらか局所領域のものからルータに接する境界の向こう側に、または、局所領域の掲示板からRSVPメッセージを送らなければなりません。 また、ISPが掲示板とデフ-serv枠組みでRSVPを実行しているなら、境界ルータはISPの地方の掲示板にメッセージを転送します。 ISPドメインで同様の過程(最初のドメインで起こったことへの)を行うことができて、次に、経路に沿った次のISPにRSVPメッセージを送ります。 ドメインの中では、唯一Markedビットに従って、パケットは役立たれています。 地方の掲示板はPremium交通が各境界ルータで入ることがちょうどいくらに許可されているか、そして、パケットがどの境界ルータから出るかを知っています。
6. Recommendations
6. 推薦
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と静的な資源配分でAssuredとPremiumサービスの両方を実行できます。 初めは、私たちはネットワークに認められるMarked交通の量で保守的な選択を推薦します。 2番目に、私たちは、ますます高性能のBBsを定義して、配備するためにこのメモから始められた努力と作者の実験研究を続けているのを計画しています。 私たちは、今後の提案へのESNetとCAIRNにおける進行中のトライアル実現から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
このメモの今後の改正は詳細に受信機ベースとマルチキャスト流れ配分を提示するでしょう。 このステップが終わっていた後に、私たちは、スケーラブルで、強健で、安全な資源管理と割り当て制度の基本的な絵が完成すると信じています。 このメモでは、私たちは提案された構造がどう微分されたサービスのトライアル展開のための少なくとも良い出発点を提供するように私たちにとって思える2つのサービスを支持するかを説明しました。 私たちの主な意図は各サービスの中で追加レベルの分化を排除するのではなく、特定のビットパターンで決定できる3つのサービス、Premium、Assured、およびBestの努力で構造を定義することです。 より多くの実験と経験が以前必要であるように思える、私たち
Nichols, et al. Informational [Page 22] RFC 2638 Two-bit Differentiated Services Architecture July 1999
ニコルズ、他 微分されたサービス構造1999年7月に安っぽい情報[22ページ]のRFC2638
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.
サービスのクラスあたり1つ以上のレベルを標準化できました。 私たちのベースの平らなアプローチは、皆が記録されるように「少なくとも」PremiumにサービスとAssuredサービスを供給しなければならないと言います。 私たちは、むしろ強い1時両方の、)頃に私たちはこのとき、ミニマリストtwoサービスアプローチと2を超えて何かを定義しようとするべきではありません) 私たちが定義する構造が将来より多くのレベルの分化を標準化できるくらい制限のなくなければならないと感じます。 私たちは、この構造が特定のサービスの中で、より多くのレベルの分化を定義するアプローチと完全に互換性があると信じています、そうする利益がよく理解されるようになるなら。
7. Acknowledgments
7. 承認
The authors have benefited from many discussions, both in person and electronically and wish to particularly thank Dave Clark who has been responsible for the genesis of many of the ideas presented here, though he does not agree with all of the content this document. We also thank Sally Floyd for comments on an earlier draft. A comment from Jon Crowcroft was partially responsible for our including section 5. Comments from Fred Baker made us try to make it clearer that we are defining two base-level services, irrespective of the bit patterns used to encode them.
作者は、自分で、電子的に多くの議論の利益を得て、特にここに提示された考えの多くの起源に責任があるデーブ・クラークに感謝したがっています、彼はこのドキュメントに内容のすべてに同意しませんが。 また、私たちは以前の草稿のコメントについてサリー・フロイドに感謝します。 ジョン・クロウクロフトからのコメントは私たちがセクション5を入れるのに部分的に原因となりました。 私たちが、2つの基準面サービスを定義していると断言しようとするのをフレッド・ベイカーからのコメントはさせました、それらをコード化するのに使用されるビット・パターンの如何にかかわらず。
8. Security Considerations
8. セキュリティ問題
There are no security considerations associated with this document.
このドキュメントに関連しているどんなセキュリティ問題もありません。
9. References
9. 参照
[1] D. Clark, "Adding Service Discrimination to the Internet",
Proceedings of the 23rd Annual Telecommunications Policy Research
Conference (TPRC), Solomons, MD, October 1995.
[1] D.クラーク、「加えて、インターネットに区別を修理してください」、第23例年の電気通信政策研究会議(TPRC)の議事、ソロモン、Md、1995年10月。
[2] V. Jacobson, "Differentiated Services Architecture", talk in the
Int-Serv WG at the Munich IETF, August, 1997.
[2] ジェーコブソンに対して「微分されたサービス構造」はミュンヘンIETF、1997年8月にInt-Serv WGで話します。
[3] Clark, D. and J. Wroclawski, "An Approach to Service Allocation
in the Internet", Work in Progress, also talk by D. Clark in the
Int-Serv WG at the Munich IETF, August, 1997.
[3] また、クラーク、D.、およびJ.Wroclawski(「サービス配分へのインターネットでのアプローチ」、ProgressのWork)はミュンヘンIETF(1997年8月)のInt-Serv WGでD.クラークで話します。
[4] Braden, et al., "Recommendations on Queue Management and
Congestion Avoidance in the Internet", RFC 2309, April 1998.
[4] ブレーデン、他、「インターネットの待ち行列管理と輻輳回避の推薦」、RFC2309、1998年4月。
[4] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource Reservation Protocol (RSVP) - Version 1 Functional
Specification", RFC 2205, September 1997.
[4] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
Nichols, et al. Informational [Page 23] RFC 2638 Two-bit Differentiated Services Architecture July 1999
ニコルズ、他 微分されたサービス構造1999年7月に安っぽい情報[23ページ]のRFC2638
[5] S. Floyd and V. Jacobson, "Link-sharing and Resource Management
Models for Packet Networks", IEEE/ACM Transactions on Networking,
pp 365-386, August 1995.
[5] S.フロイドとV.ジェーコブソン、「リンク共有と資源管理はパケット網のためにモデル化します」、Networkingの上のIEEE/ACM Transactions、pp365-386、1995年8月。
[6] D. Clark, private communication, October 26, 1997.
[6] D.クラーク、私信、1997年10月26日。
[7] "Advanced QoS Services for the Intelligent Internet", Cisco
Systems White Paper, 1997.
[7] 「知的なインターネットのための高度なQoSサービス」、シスコシステムズ白書、1997。
[8] Wroclawski, J., "Specification of the Controlled-Load Network
Element Service", RFC 2211, September 1997.
[8]Wroclawski、J.、「制御負荷ネットワーク要素サービスの仕様」、RFC2211、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.ゲラン、「保証されたサービスの質の仕様」、RFC2212、1997年9月。
[10] D. Clark and W. Fang, "Explicit Allocation of Best Effort packet
Delivery Service", IEEE/ACM Transactions on Networking, August,
1998, Vol6, No 4, pp. 362-373. also at: http://
diffserv.lcs.mit.edu/Papers/exp-alloc-ddc-wf.pdf
[10] D.クラークとW.Fang、「Best EffortパケットDelivery Serviceの明白なAllocation」、Networking、1998年8月のVol6、いいえ4、ページのIEEE/ACM Transactions 362-373 以下でも http://diffserv.lcs.mit.edu/書類/exp-alloc-ddc-wf.pdf
Authors' Addresses
作者のアドレス
Kathleen Nichols Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706
西タスマン・Driveサンノゼ、キャサリーンニコルズシスコシステムズInc.170カリフォルニア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
西タスマン・Driveサンノゼ、ヴァンジェーコブソンシスコシステムズInc.170カリフォルニア95134-1706
EMail: van@cisco.com
メール: van@cisco.com
Lixia Zhang UCLA 4531G Boelter Hall Los Angeles, CA 90095
Lixiaチャン・UCLA 4531G Boelter Hallロサンゼルス、カリフォルニア 90095
Phone: 310-825-2695 EMail: lixia@cs.ucla.edu
以下に電話をしてください。 310-825-2695 メールしてください: lixia@cs.ucla.edu
Nichols, et al. Informational [Page 24] RFC 2638 Two-bit Differentiated Services Architecture July 1999
ニコルズ、他 微分されたサービス構造1999年7月に安っぽい情報[24ページ]のRFC2638
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.
草稿nicholsデフsvc-00を提出した後に、共著者は草稿に1997年12月のIETF Integrated Services作業部会のミーティングでプレゼンテーションスロットを使用するクラークのものをもたらしたデーブ・クラークとジョンWroclawskiと共に話し合いました。 スライドの読みは、次に形成されたIETF Differentiated Services作業部会の過程の多くを誘導したのが、「メカニズム」と、「サービス」と、「規則」と標準化過程でどう続くかに関するクラークの提案であったのを示します。 私たちは、デーブ・クラークの話が強さと互換性がある方法でサービスの質をインターネットにもたらすための確実なアプローチを私たちに与えたと信じています。
The slides presented at the December 1997 IETF Integrated Services Working Group are included with the Postscript version.
1997年12月のIETF Integrated Services作業部会で贈られたスライドは補遣版で含まれています。
Nichols, et al. Informational [Page 25] RFC 2638 Two-bit Differentiated Services Architecture July 1999
ニコルズ、他 微分されたサービス構造1999年7月に安っぽい情報[25ページ]のRFC2638
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Nichols, et al. Informational [Page 26]
ニコルズ、他 情報[26ページ]
一覧
スポンサーリンク
