RFC1633 日本語訳
1633 Integrated Services in the Internet Architecture: an Overview. R.Braden, D. Clark, S. Shenker. June 1994. (Format: TXT=89691, PS=207016, PDF=201858 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Braden
Request for Comments: 1633 ISI
Category: Informational D. Clark
MIT
S. Shenker
Xerox PARC
June 1994
コメントを求めるワーキンググループR.ブレーデン要求をネットワークでつないでください: 1633年のISIカテゴリ: 情報のD.のMIT S.ShenkerゼロックスPARCクラーク1994年6月
Integrated Services in the Internet Architecture: an Overview
インターネット構造における統合サービス: 概観
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This memo discusses a proposed extension to the Internet architecture and protocols to provide integrated services, i.e., to support real- time as well as the current non-real-time service of IP. This extension is necessary to meet the growing need for real-time service for a variety of new applications, including teleconferencing, remote seminars, telescience, and distributed simulation.
このメモは、すなわち、IPの現在の非リアルタイムのサービスと同様にリアルタイムを支持するために統合サービスを提供するためにインターネット構造とプロトコルと提案された拡大について議論します。 この拡大がさまざまな新しいアプリケーションのために本当の時間指定サービスの増加している需要を満たすのに必要です、電子会議、リモートセミナー、テレサイエンス、および分配されたシミュレーションを含んでいて。
This memo represents the direct product of recent work by Dave Clark, Scott Shenker, Lixia Zhang, Deborah Estrin, Sugih Jamin, John Wroclawski, Shai Herzog, and Bob Braden, and indirectly draws upon the work of many others.
このメモは、デーブ・クラーク、スコットShenker、Lixiaチャン、デボラEstrin、Sugihジャマン、ジョンWroclawski、Shaiハーツォグ、およびボブ・ブレーデンによる近作の直積を表して、間接的に多くの他のものの仕事を引き出します。
Table of Contents
目次
1. Introduction ...................................................2
2. Elements of the Architecture ...................................3
2.1 Integrated Services Model ..................................3
2.2 Reference Implementation Framework .........................6
3. Integrated Services Model ......................................11
3.1 Quality of Service Requirements ............................12
3.2 Resource-Sharing Requirements and Service Models ...........16
3.3 Packet Dropping ............................................18
3.4 Usage Feedback .............................................19
3.5 Reservation Model ..........................................19
4. Traffic Control Mechanisms .....................................20
4.1 Basic Functions ............................................20
4.2 Applying the Mechanisms ....................................23
4.3 An example .................................................24
5. Reservation Setup Protocol .....................................25
1. 序論…2 2. 構造のElements…3 2.1 統合サービスはモデル化されます…3 2.2リファレンスインプリメンテーション枠組み…6 3. 統合サービスはモデル化されます…11 3.1 サービスの質要件…12 3.2 リソース・シェアリング要件とサービスモデル…16 3.3 パケット低下…18 3.4 用法フィードバック…19 3.5予約モデル…19 4. トラフィックコントロールメカニズム…20 4.1 基本的な機能…20 4.2 メカニズムを適用します…23 4.3 例…24 5. 予約セットアッププロトコル…25
Braden, Clark & Shenker [Page 1] RFC 1633 Integrated Services Architecture June 1994
ブレーデン、クラーク、およびサービス構造1994年6月に統合しているShenker[1ページ]RFC1633
5.1 RSVP Overview ..............................................25
5.2 Routing and Reservations ...................................28
6. Acknowledgments ................................................30
References ........................................................31
Security Considerations ...........................................32
Authors' Addresses ................................................33
5.1RSVP概観…25 5.2のルート設定と予約…28 6. 承認…30の参照箇所…31 セキュリティ問題…32人の作者のアドレス…33
1. Introduction
1. 序論
The multicasts of IETF meetings across the Internet have formed a large-scale experiment in sending digitized voice and video through a packet-switched infrastructure. These highly-visible experiments have depended upon three enabling technologies. (1) Many modern workstations now come equipped with built-in multimedia hardware, including audio codecs and video frame-grabbers, and the necessary video gear is now inexpensive. (2) IP multicasting, which is not yet generally available in commercial routers, is being provided by the MBONE, a temporary "multicast backbone". (3) Highly-sophisticated digital audio and video applications have been developed.
インターネット中のIETFミーティングのマルチキャストはパケットで切り換えられたインフラストラクチャを通してデジタル化している声とビデオを送る際に大規模な実験を形成しました。 これらの非常に目に見える実験は3つの可能な技術によりました。 (1) 多くの現代のワークステーションがもうオーディオコーデックとビデオフレームひったくりを含むマルチメディアハードウェア内蔵備えられていた状態で来ます、そして、必要なビデオギヤは現在、安価です。 (2) MBONE、一時的な「マルチキャスト背骨」で、IPマルチキャスティング(商業ルータでまだ一般に利用可能でない)を提供しています。 (3) 非常に精巧なデジタル・オーディオとビデオ・アプリケーションを開発してあります。
These experiments also showed that an important technical element is still missing: real-time applications often do not work well across the Internet because of variable queueing delays and congestion losses. The Internet, as originally conceived, offers only a very simple quality of service (QoS), point-to-point best-effort data delivery. Before real-time applications such as remote video, multimedia conferencing, visualization, and virtual reality can be broadly used, the Internet infrastructure must be modified to support real-time QoS, which provides some control over end-to-end packet delays. This extension must be designed from the beginning for multicasting; simply generalizing from the unicast (point-to-point) case does not work.
また、これらの実験は、重要な技術的な要素がまだなくなっているのを示しました: リアルタイムのアプリケーションは可変待ち行列遅れと混雑の損失のためにインターネットの向こう側にしばしばうまくいくというわけではありません。 元々発想されているとして、インターネットは非常に簡単なサービスの質(QoS)だけ、二地点間ベストエフォート型データ配送を提供します。 リモートビデオや、マルチメディア会議や、想像や、バーチャルリアリティなどのリアルタイムのアプリケーションを広く使用できる前に、リアルタイムのQoSを支持するようにインターネット基盤を変更しなければなりません。(QoSは終わりから終わりへのパケット遅れの何らかのコントロールを提供します)。 マルチキャスティングのために始めからこの拡大を設計しなければなりません。 ユニキャスト(ポイントツーポイント)ケースから単に導き出すのは働いていません。
Real-time QoS is not the only issue for a next generation of traffic management in the Internet. Network operators are requesting the ability to control the sharing of bandwidth on a particular link among different traffic classes. They want to be able to divide traffic into a few administrative classes and assign to each a minimum percentage of the link bandwidth under conditions of overload, while allowing "unused" bandwidth to be available at other times. These classes may represent different user groups or different protocol families, for example. Such a management facility is commonly called controlled link-sharing. We use the term integrated services (IS) for an Internet service model that includes best-effort service, real-time service, and controlled link sharing.
リアルタイムのQoSはインターネットの輸送管理の次世代のための唯一の問題ではありません。 ネットワーク・オペレータは異なった交通のクラスで特定のリンクの上の帯域幅の共有を制御する能力を要求しています。 「未使用」の帯域幅が他の時に利用可能であることを許容している間、彼らは交通を管理数クラスに分割して、オーバーロードに関する条件のもとでリンク帯域幅の最小の百分率をそれぞれに割り当てることができるようになりたがっています。 これらのクラスは異なったユーザ・グループか例えば異なったプロトコル家族の代理をするかもしれません。 そのような管理施設は一般的に制御リンク共有と呼ばれます。 私たちはベストエフォート型サービス、リアルタイムのサービス、および制御リンク共有を含んでいるインターネットのサービスモデルに、用語統合しているサービス(ある)を利用します。
The requirements and mechanisms for integrated services have been the subjects of much discussion and research over the past several years
統合サービスのための要件とメカニズムは過去数年間の多くの議論と研究の対象です。
Braden, Clark & Shenker [Page 2] RFC 1633 Integrated Services Architecture June 1994
ブレーデン、クラーク、およびサービス構造1994年6月に統合しているShenker[2ページ]RFC1633
(the literature is much too large to list even a representative sample here; see the references in [CSZ92, Floyd92, Jacobson91, JSCZ93, Partridge92, SCZ93, RSVP93a] for a partial list). This work has led to the unified approach to integrated services support that is described in this memo. We believe that it is now time to begin the engineering that must precede deployment of integrated services in the Internet.
(文学はここに代表試料さえリストアップできないくらい大きいです; 部分的なリストに関して[CSZ92、Floyd92、Jacobson91、JSCZ93、Partridge92、SCZ93、RSVP93a]での参照を見てください。) この仕事はこのメモで説明される統合サービスサポートへの統一されたアプローチにつながりました。 私たちは、今、それが展開に先行しなければならない工学を始める時間がインターネットでサービスを統合したということであると信じています。
Section 2 of this memo introduces the elements of an IS extension of the Internet. Section 3 discusses real-time service models [SCZ93a, SCZ93b]. Section 4 discusses traffic control, the forwarding algorithms to be used in routers [CSZ92]. Section 5 discusses the design of RSVP, a resource setup protocol compatible with the assumptions of our IS model [RSVP93a, RSVP93b].
このメモのセクション2が要素を紹介する、インターネットの拡大はそうです。 セクション3はリアルタイムのサービスモデル[SCZ93a、SCZ93b]について論じます。 セクション4は、ルータ[CSZ92]に使用されるためにトラフィックコントロール、推進アルゴリズムを論じます。 セクション5がRSVPのデザイン、仮定とのコンパチブルリソースセットアッププロトコルについて論ずる、私たち、モデルは[RSVP93a、RSVP93b]ですか?
2. Elements of the Architecture
2. 構造のElements
The fundamental service model of the Internet, as embodied in the best-effort delivery service of IP, has been unchanged since the beginning of the Internet research project 20 years ago [CerfKahn74]. We are now proposing to alter that model to encompass integrated service. From an academic viewpoint, changing the service model of the Internet is a major undertaking; however, its impact is mitigated by the fact that we wish only to extend the original architecture. The new components and mechanisms to be added will supplement but not replace the basic IP service.
インターネット研究計画の始まり以来IPのベストエフォート型デリバリ・サービスに表現されるインターネットの基本的なサービスモデルは20年前[CerfKahn74]に変わりがありません。 私たちは、現在、統合サービスを成就するためにそのモデルを変更するよう提案しています。 アカデミックな観点から、インターネットのサービスモデルを変えるのは、主要な仕事です。 しかしながら、単にオリジナルの構造を広げたいと思うという事実によって衝撃は緩和されます。 加えられるべき新しいコンポーネントとメカニズムは、補いますが、基本的なIPサービスを取り替えないでしょう。
Abstractly, the proposed architectural extension is comprised of two elements: (1) an extended service model, which we call the IS model, and (2) a reference implementation framework, which gives us a set of vocabulary and a generic program organization to realize the IS model. It is important to separate the service model, which defines the externally visible behavior, from the discussion of the implementation, which may (and should) change during the life of the service model. However, the two are related; to make the service model credible, it is useful to provide an example of how it might be realized.
抽象的に、提案された建築拡大は2つの要素から成ります: (1) (私たちはモデルを呼びます)。(それは、換金するために1セットのボキャブラリーとa一般的なプログラム組織を私たちに与えます)。拡張サービスモデル、モデル、および(2)が参照実現枠組みである、モデル化してください。 (議論は人生の間のサービスモデルの(and should)変化がそうするかもしれません)。サービスモデルを切り離すのは実現の議論によって重要です。(モデルは外部的に目に見える振舞いを定義します)。 しかしながら、2は関係づけられます。 サービスモデルを確かにするように、それがどう実感されるかもしれないかに関する例を提供するのは役に立ちます。
2.1 Integrated Services Model
2.1 統合サービスはモデル化されます。
The IS model we are proposing includes two sorts of service
targeted towards real-time traffic: guaranteed and predictive
service. It integrates these services with controlled link-
sharing, and it is designed to work well with multicast as well as
unicast. Deferring a summary of the IS model to Section 3, we
first discuss some key assumptions behind the model.
私たちが提案しているモデルがリアルタイムの交通に向かって狙う2種類のサービスを入れるということです: 保証されて予言のサービス。 それは制御リンク共有とこれらのサービスを統合します、そして、ユニキャストと同様にマルチキャストでうまくいくために、設計されています。 セクションにはモデルがあります。概要を延期する、3 私たちは最初に、モデルの後ろのいくつかの主要な仮定について議論します。
Braden, Clark & Shenker [Page 3] RFC 1633 Integrated Services Architecture June 1994
ブレーデン、クラーク、およびサービス構造1994年6月に統合しているShenker[3ページ]RFC1633
The first assumption is that resources (e.g., bandwidth) must be
explicitly managed in order to meet application requirements.
This implies that "resource reservation" and "admission control"
are key building blocks of the service. An alternative approach,
which we reject, is to attempt to support real-time traffic
without any explicit changes to the Internet service model.
最初の仮定はアプリケーション要件を満たすために、明らかに、リソース(例えば、帯域幅)を管理しなければならないということです。 これは、「資源予約」と「入場コントロール」が主要なサービスのブロックであることを含意します。 代替的アプローチ(私たちは拒絶する)はインターネットのサービスモデルへの少しも明白な変化なしでリアルタイムの交通を支持するのを試みることです。
The essence of real-time service is the requirement for some
service guarantees, and we argue that guarantees cannot be
achieved without reservations. The term "guarantee" here is to be
broadly interpreted; they may be absolute or statistical, strict
or approximate. However, the user must be able to get a service
whose quality is sufficiently predictable that the application can
operate in an acceptable way over a duration of time determined by
the user. Again, "sufficiently" and "acceptable" are vague terms.
In general, stricter guarantees have a higher cost in resources
that are made unavailable for sharing with others.
リアルタイムでサービスの本質はいくつかのサービス保証のための要件です、そして、私たちは予約なしで保証を達成できないと主張します。 ここの「保証」という用語は露骨に解釈されることになっています。 それらは、絶対、統計的であるか、厳しいかまたは大体であるかもしれません。 しかしながら、ユーザは品質が十分予測できるサービスを得ることができなければなりません。アプリケーションはユーザで決定している時間の持続時間の上で許容できる方法で作動できます。 一方、「十分」、「許容できる」であることは、漠然とした語です。一般に、より厳しい保証には、他のものと共有するのを入手できなくされるリソースの、より高い費用があります。
The following arguments have been raised against resource
guarantees in the Internet.
以下の議論はインターネットのリソース保証に対して上げられました。
o "Bandwidth will be infinite."
o 「帯域幅は無限になるでしょう。」
The incredibly large carrying capacity of an optical fiber
leads some to conclude that in the future bandwidth will be
so abundant, ubiquitous, and cheap that there will be no
communication delays other than the speed of light, and
therefore there will be no need to reserve resources.
However, we believe that this will be impossible in the short
term and unlikely in the medium term. While raw bandwidth
may seem inexpensive, bandwidth provided as a network service
is not likely to become so cheap that wasting it will be the
most cost-effective design principle. Even if low-cost
bandwidth does eventually become commonly available, we do
not accept that it will be available "everywhere" in the
Internet. Unless we provide for the possibility of dealing
with congested links, then real-time services will simply be
precluded in those cases. We find that restriction
unacceptable.
光ファイバの信じられないほど大きい運送容量は、数人が、将来の帯域幅のそれが光速以外に、コミュニケーション遅滞しないほど豊富で、遍在して、安くなると結論づけるように導きます、そして、したがって、リソースを予約する必要は全くないでしょう。 しかしながら、私たちは、これが中期で短期間不可能であって、ありそうもなくなると信じています。 生の帯域幅は安価に見えたかもしれませんが、ネットワーク・サービスがそれを浪費するのが、最も費用対効果に優れた設計原理である安くなりそうにないので、帯域幅は供給されました。 安価の帯域幅が結局一般的に利用可能になっても、私たちは、それが「いたる所でインターネットの」利用可能になると受け入れません。 そして、私たちが混雑しているリンクに対処する可能性に備えないと、リアルタイムのサービスはそれらの場合で単に排除されるでしょう。 私たちは、その制限が容認できないのがわかりました。
o "Simple priority is sufficient."
o 「簡単な優先権は十分です。」
It is true that simply giving higher priority to real-time
traffic would lead to adequate real-time service at some
times and under some conditions. But priority is an
implementation mechanism, not a service model. If we define
the service by means of a specific mechanism, we may not get
the exact features we want. In the case of simple priority,
リアルタイムの交通で単に高い優先順位を置くのがいくつかで回といくつかの条件のもとで適切なリアルタイムのサービスに通じるのは、本当です。 しかし、優先権はサービスモデルではなく、実現メカニズムです。 特定のメカニズムによってサービスを定義するなら、私たちは欲しい正確な特徴を得ないかもしれません。 簡単な優先権の場合で
Braden, Clark & Shenker [Page 4] RFC 1633 Integrated Services Architecture June 1994
ブレーデン、クラーク、およびサービス構造1994年6月に統合しているShenker[4ページ]RFC1633
the issue is that as soon as there are too many real-time
streams competing for the higher priority, every stream is
degraded. Restricting our service to this single failure
mode is unacceptable. In some cases, users will demand that
some streams succeed while some new requests receive a "busy
signal".
問題は、より高い優先度を競争するあまりに多くのリアルタイムの流れがあるとすぐに、あらゆる流れが降格しているということです。 私たちのサービスをこのただ一つの故障モードに制限するのは容認できません。 いくつかの場合、ユーザは、いくつかの新しい要求が「話中音」を受けている間流れが成功するのを要求するでしょう。
o "Applications can adapt."
o 「アプリケーションは適合できます。」
The development of adaptive real-time applications, such as
Jacobson's audio program VAT, does not eliminate the need to
bound packet delivery time. Human requirements for
interaction and intelligibility limit the possible range of
adaptation to network delays. We have seen in real
experiments that, while VAT can adapt to network delays of
many seconds, the users find that interaction is impossible
in these cases.
ジェーコブソンのオーディオプログラムVATなどの適応型のリアルタイムのアプリケーションの開発は制限されたパケット納期まで必要性を排除しません。 相互作用と明瞭さのための人間の要件は可能な範囲の適合をネットワーク遅延に制限します。 私たちは、本当の実験でVATが何秒もネットワーク遅延に順応できる間ユーザが、相互作用がこれらの場合で不可能であることがわかるのを見ました。
We conclude that there is an inescapable requirement for routers
to be able to reserve resources, in order to provide special QoS
for specific user packet streams, or "flows". This in turn
requires flow-specific state in the routers, which represents an
important and fundamental change to the Internet model. The
Internet architecture was been founded on the concept that all
flow-related state should be in the end systems [Clark88].
Designing the TCP/IP protocol suite on this concept led to a
robustness that is one of the keys to its success. In section 5
we discuss how the flow state added to the routers for resource
reservation can be made "soft", to preserve the robustness of the
Internet protocol suite.
私たちは、ルータがリソースを予約できるという不可避的な要件があると結論を下します、特定のユーザパケットの流れ、または「流れ」に特別なQoSを提供するために。 これは順番にルータにおける流れ特有の州を必要とします。(それは、インターネットモデルへの重要で基本的な変化を表します)。 インターネット構造はそうでした。すべての流れ関連の状態がそうするべきであるという概念では、結局システムが[Clark88]であったなら設立されます。 この概念にTCP/IPプロトコル群を設計するのは成功のキーの1つである丈夫さに通じました。 セクション5で、私たちはインターネット・プロトコル群の丈夫さを保存するためにどう資源予約のためにルータに加えられた流れ状態を「柔らかく」することができるかについて議論します。
There is a real-world side effect of resource reservation in
routers. Since it implies that some users are getting privileged
service, resource reservation will need enforcement of policy and
administrative controls. This in turn will lead to two kinds of
authentication requirements: authentication of users who make
reservation requests, and authentication of packets that use the
reserved resources. However, these issues are not unique to "IS";
other aspects of the evolution of the Internet, including
commercialization and commercial security, are leading to the same
requirements. We do not discuss the issues of policy or security
further in this memo, but they will require attention.
ルータにおける、資源予約の本当の世界の副作用があります。 何人かのユーザが特権があるサービスを得ているのを含意するので、資源予約は方針と運営管理コントロールの実施を必要とするでしょう。 これは順番に2種類の認証要件に通じるでしょう: 予約の要請を作るユーザの認証、および予約されたリソースを使用するパケットの認証。 しかしながら、これらの問題は「存在あること」にユニークではありません。 商業化と商業セキュリティを含むインターネットの発展の他の局面は同じ要件につながっています。 私たちはさらにこのメモで方針かセキュリティの問題について議論しませんが、彼らは注意を必要とするでしょう。
We make another fundamental assumption, that it is desirable to
use the Internet as a common infrastructure to support both non-
real-time and real-time communication. One could alternatively
build an entirely new, parallel infrastructure for real-time
services, leaving the Internet unchanged. We reject this
私たちは非リアルタイムでリアルタイムの両方のコミュニケーションを支持するのに一般的なインフラストラクチャとしてインターネットを使用するのが望ましいという別の基本的仮説をします。 あるいはまた、インターネットを変わりがないままにして、人は本当の時間指定サービスのために完全に新しくて、平行なインフラストラクチャを築き上げることができました。 私たちはこれを拒絶します。
Braden, Clark & Shenker [Page 5] RFC 1633 Integrated Services Architecture June 1994
ブレーデン、クラーク、およびサービス構造1994年6月に統合しているShenker[5ページ]RFC1633
approach, as it would lose the significant advantages of
statistical sharing between real-time and non-real-time traffic,
and it would be much more complex to build and administer than a
common infrastructure.
アプローチしてください、リアルタイムで非リアルタイムの交通を平等に割り当てながら統計的の重要な利点を失って、建てて、管理するために一般的なインフラストラクチャよりはるかに複雑であるだろうというときに。
In addition to this assumption of common infrastructure, we adopt
a unified protocol stack model, employing a single internet-layer
protocol for both real-time and non-real-time service. Thus, we
propose to use the existing internet-layer protocol (e.g., IP or
CLNP) for real-time data. Another approach would be to add a new
real-time protocol in the internet layer [ST2-90]. Our unified
stack approach provides economy of mechanism, and it allows us to
fold controlled link-sharing in easily. It also handles the
problem of partial coverage, i.e., allowing interoperation between
IS-capable Internet systems and systems that have not been
extended, without the complexity of tunneling.
一般的なインフラストラクチャのこの仮定に加えて、私たちは統一されたプロトコルスタック・モデルを採用します、リアルタイムで非リアルタイムの両方のサービスにただ一つのインターネット層のプロトコルを使って。 したがって、私たちは、リアルタイムのデータに、既存のインターネット層のプロトコル(例えば、IPかCLNP)を使用するよう提案します。 別のアプローチはインターネット[ST2-90]層の中で新しいリアルタイムのプロトコルを加えるだろうことです。 私たちの統一されたスタックアプローチはメカニズムの経済を前提とします、そして、それは私たちが容易に制御リンク共有を加えるのを許容します。 また、すなわち、間にinteroperationを許容しながら部分的な適用範囲の問題を扱う、-、できる、トンネリングの複雑さなしで拡張されていないインターネット・システムとシステム。
We take the view that there should be a single service model for
the Internet. If there were different service models in different
parts of the Internet, it is very difficult to see how any end-
to-end service quality statements could be made. However, a
single service model does not necessarily imply a single
implementation for packet scheduling or admission control.
Although specific packet scheduling and admission control
mechanisms that satisfy our service model have been developed, it
is quite possible that other mechanisms will also satisfy the
service model. The reference implementation framework, introduced
below, is intended to allow discussion of implementation issues
without mandating a single design.
私たちは単独のサービスモデルがあるべきであるという意見をインターネットに取ります。 異なったサービスモデルがインターネットの異なった地域にあったなら、いずれも終わりに対する上質の声明をすることができたサービスをどう、終わらせるかを見るのは非常に難しいです。 しかしながら、単独のサービスモデルはパケットスケジューリングか入場コントロールのために必ずただ一つの実装について暗示するというわけではありません。 私たちのサービスモデルを満たす特定のパケットスケジューリングと入場制御機構が開発されましたが、また、他のメカニズムがサービスモデルを満たすのは、かなり可能です。 以下で導入された参照実装フレームワークがただ一つのデザインを強制しないで導入問題の議論を許すことを意図します。
Based upon these considerations, we believe that an IS extension
that includes additional flow state in routers and an explicit
setup mechanism is necessary to provide the needed service. A
partial solution short of this point would not be a wise
investment. We believe that the extensions we propose preserve
the essential robustness and efficiency of the Internet
architecture, and they allow efficient management of the network
resources; these will be important goals even if bandwidth becomes
very inexpensive.
これらの問題に基づいて、私たちがそれを信じている、中に追加流れ状態を含んでいる拡大はルータであり、明白なセットアップメカニズムが、必要なサービスを提供するのに必要です。 このポイントの部分的解決ショートは賢明なる投資でないでしょう。 私たちは、私たちが提案する拡大がインターネットアーキテクチャの不可欠の丈夫さと効率を保存すると信じています、そして、ネットワーク資源の能率的経営を許容します。 帯域幅が非常に安価になっても、これらは重要な目標になるでしょう。
2.2 Reference Implementation Framework
2.2 リファレンスインプリメンテーションフレームワーク
We propose a reference implementation framework to realize the IS
model. This framework includes four components: the packet
scheduler, the admission control routine, the classifier, and the
reservation setup protocol. These are discussed briefly below and
more fully in Sections 4 and 5.
私たちが換金するために参照実装フレームワークを提案する、モデル化してください。 このフレームワークは4つのコンポーネントを含んでいます: パケットスケジューラ、入場規制ルーチン、クラシファイア、および予約セットアップは議定書を作ります。 簡潔に以下でこれらについてセクション4と5の、より完全に議論します。
Braden, Clark & Shenker [Page 6] RFC 1633 Integrated Services Architecture June 1994
ブレーデン、クラーク、およびサービスアーキテクチャ1994年6月に統合しているShenker[6ページ]RFC1633
In the ensuing discussion, we define the "flow" abstraction as a
distinguishable stream of related datagrams that results from a
single user activity and requires the same QoS. For example, a
flow might consist of one transport connection or one video stream
between a given host pair. It is the finest granularity of packet
stream distinguishable by the IS. We define a flow to be simplex,
i.e., to have a single source but N destinations. Thus, an N-way
teleconference will generally require N flows, one originating at
each site.
続く議論では、私たちはシングルユーザー活動から生じて、同じQoSを必要とする関連するデータグラムの区別可能なストリームと「流れ」抽象化を定義します。 例えば、流れは与えられたホスト組の間の1つの輸送接続か1つのビデオストリームから成るかもしれません。 それがパケットストリームの区別可能な最もすばらしい粒状である、あります。 私たちは、シンプレクスであり、すなわち、単独のソースにもかかわらず、N目的地を持つために流れを定義します。 したがって、一般に、1つが起因して、N-道の電子会議は各サイトでN流れを必要とするでしょう。
In today's Internet, IP forwarding is completely egalitarian; all
packets receive the same quality of service, and packets are
typically forwarded using a strict FIFO queueing discipline. For
integrated services, a router must implement an appropriate QoS
for each flow, in accordance with the service model. The router
function that creates different qualities of service is called
"traffic control". Traffic control in turn is implemented by
three components: the packet scheduler, the classifier, and
admission control.
今日のインターネットでは、IP推進は完全に平等主義者です。 すべてのパケットが同じサービスの質を受けます、そして、厳しい先入れ先出し法待ち行列規律を使用することでパケットを通常進めます。 統合サービスのために、サービスモデルに従って、ルータは各流れのための適切なQoSを実装しなければなりません。 異なったサービスの品質を作成するルータ機能は「トラフィックコントロール」と呼ばれます。 トラフィックコントロールは3つのコンポーネントによって順番に実装されます: パケットスケジューラ、クラシファイア、および入場は制御されます。
o Packet Scheduler
o パケットスケジューラ
The packet scheduler manages the forwarding of different
packet streams using a set of queues and perhaps other
mechanisms like timers. The packet scheduler must be
implemented at the point where packets are queued; this is
the output driver level of a typical operating system, and
corresponds to the link layer protocol. The details of the
scheduling algorithm may be specific to the particular output
medium. For example, the output driver will need to invoke
the appropriate link-layer controls when interfacing to a
network technology that has an internal bandwidth allocation
mechanism.
パケットスケジューラは、タイマのような待ち行列と恐らく他のメカニズムの1セットを使用することで異なったパケットストリームの推進を管理します。 パケットが列に並ばせられるポイントでパケットスケジューラを実装しなければなりません。 これは、典型的なオペレーティングシステムの出力ドライバーレベルであり、リンクレイヤプロトコルに対応しています。 特定の出力媒体に、スケジューリングアルゴリズムの詳細は特定であるかもしれません。 例えば、出力ドライバーは、内部の帯域幅配分メカニズムを持っているネットワーク技術に連結するとき、適切なリンクレイヤコントロールを呼び出す必要があるでしょう。
An experimental packet scheduler has been built that
implements the IS model described in Section 3 and [SCZ93];
this is known as the CSZ scheduler and is discussed further
in Section 4. We note that the CSZ scheme is not mandatory
to accomplish our service model; indeed for parts of the
network that are known always to be underloaded, FIFO will
deliver satisfactory service.
その道具が実験用パケットスケジューラに組立てられた、セクション3と[SCZ93]で説明されたモデルです。 これについて、CSZスケジューラとして知られていて、セクション4で、より詳しく議論します。 私たちは、CSZ体系が私たちのサービスモデルを達成するために義務的でないことに注意します。 本当に、underloadedされるのがいつも知られているネットワークの部分に関しては、先入れ先出し法は満足できるサービスを提供するでしょう。
There is another component that could be considered part of
the packet scheduler or separate: the estimator [Jacobson91].
This algorithm is used to measure properties of the outgoing
traffic stream, to develop statistics that control packet
scheduling and admission control. This memo will consider
the estimator to be a part of the packet scheduler.
パケットスケジューラの一部であると考えられたか、または分離できた別のコンポーネントがあります: 見積り人[Jacobson91]。 このアルゴリズムは、パケットスケジューリングと入場コントロールを制御する統計を開発するのに外向的なトラフィックストリームの測定の特性に使用されます。 このメモは、見積り人がパケットスケジューラの一部であると考えるでしょう。
Braden, Clark & Shenker [Page 7] RFC 1633 Integrated Services Architecture June 1994
ブレーデン、クラーク、およびサービスアーキテクチャ1994年6月に統合しているShenker[7ページ]RFC1633
o Classifier
o クラシファイア
For the purpose of traffic control (and accounting), each
incoming packet must be mapped into some class; all packets
in the same class get the same treatment from the packet
scheduler. This mapping is performed by the classifier.
Choice of a class may be based upon the contents of the
existing packet header(s) and/or some additional
classification number added to each packet.
トラフィックコントロール(そして、会計)の目的のために、それぞれの入って来るパケットを何らかのクラスに写像しなければなりません。 同じクラスにおけるすべてのパケットがパケットスケジューラから同じ処理を得ます。 このマッピングはクラシファイアによって実行されます。 クラスの選択は既存のパケットのヘッダー、そして/または、各パケットに加えられた何らかの追加職務分類番号のコンテンツに基づくかもしれません。
A class might correspond to a broad category of flows, e.g.,
all video flows or all flows attributable to a particular
organization. On the other hand, a class might hold only a
single flow. A class is an abstraction that may be local to
a particular router; the same packet may be classified
differently by different routers along the path. For
example, backbone routers may choose to map many flows into a
few aggregated classes, while routers nearer the periphery,
where there is much less aggregation, may use a separate
class for each flow.
クラスは流れ、例えば、すべてのビデオ流れの広いカテゴリか特定の組織に起因するすべての流れに対応するかもしれません。 他方では、クラスはただ一つの流れだけを保持するかもしれません。 クラスは特定のルータに地方であるかもしれない抽象化です。 同じパケットは経路に沿った異なったルータによって異なって分類されるかもしれません。 例えば、バックボーンルータは、集められた数クラスへの多くの流れを写像するのを選ぶかもしれません、周辺の、より近くのルータが各流れにまして集合があるところで別々のクラスを使用するかもしれませんが。
o Admission Control
o 入場コントロール
Admission control implements the decision algorithm that a
router or host uses to determine whether a new flow can be
granted the requested QoS without impacting earlier
guarantees. Admission control is invoked at each node to
make a local accept/reject decision, at the time a host
requests a real-time service along some path through the
Internet. The admission control algorithm must be consistent
with the service model, and it is logically part of traffic
control. Although there are still open research issues in
admission control, a first cut exists [JCSZ92].
入場コントロールはルータかホストが、より早く影響を与えないで要求されたQoSを新しい流れに与えることができるかどうか決定するのに使用する決定アルゴリズムに保証を実装します。 入場コントロールはローカルが決定を受け入れるか、または拒絶するのを作るために各ノードに呼び出されます、ホストがインターネットを通して何らかの経路に沿ってリアルタイムのサービスを要求するとき。 入場コントロールアルゴリズムはサービスモデルと一致しているに違いありません、そして、それはトラフィックコントロールを論理的に離れさせることです。 入場コントロールには開いている研究課題がまだありますが、最初のカットは存在しています[JCSZ92]。
Admission control is sometimes confused with policing or
enforcement, which is a packet-by-packet function at the
"edge" of the network to ensure that a host does not violate
its promised traffic characteristics. We consider policing
to be one of the functions of the packet scheduler.
入場コントロールはホストが約束のトラフィックの特性に違反しないのが取り締まりか実施に時々混乱します。(パケットごとに、それは、確実にするネットワークの「縁」での機能です)。 私たちは、取り締まりがパケットスケジューラの機能の1つであると考えます。
In addition to ensuring that QoS guarantees are met,
admission control will be concerned with enforcing
administrative policies on resource reservations. Some
policies will demand authentication of those requesting
reservations. Finally, admission control will play an
QoS保証が迎えられるのを確実にすることに加えて、入場コントロールは施政方針に資源予約に押しつけるのに関係があるでしょう。 いくつかの方針が予約を要求するものの認証を要求するでしょう。 最終的に、入場コントロールはプレーするでしょう。
Braden, Clark & Shenker [Page 8] RFC 1633 Integrated Services Architecture June 1994
ブレーデン、クラーク、およびサービスアーキテクチャ1994年6月に統合しているShenker[8ページ]RFC1633
important role in accounting and administrative reporting.
会計における重要な役割と管理報告。
The fourth and final component of our implementation framework is
a reservation setup protocol, which is necessary to create and
maintain flow-specific state in the endpoint hosts and in routers
along the path of a flow. Section discusses a reservation setup
protocol called RSVP (for "ReSerVation Protocol") [RSVP93a,
RSVP93b]. It may not be possible to insist that there be only one
reservation protocol in the Internet, but we will argue that
multiple choices for reservation protocols will cause confusion.
We believe that multiple protocols should exist only if they
support different modes of reservation.
私たちの実装フレームワークの4番目の、そして、最終的なコンポーネントは予約セットアッププロトコルです。(そのプロトコルが、流れの経路に沿って終点ホストとルータで流れ特有の状態を創設して、維持するのに必要です)。 セクションはRSVP(「予約プロトコル」のための)[RSVP93a、RSVP93b]と呼ばれる予約セットアッププロトコルについて論じます。 そこに、いてください。主張するのが可能でないかもしれない、それ、インターネットの1つの予約プロトコルだけ、私たちだけが予約プロトコルのための選択式は原因混乱がそうすると主張するつもりです。 私たちは、予約の異なった方法をサポートする場合にだけ複数のプロトコルが存在するべきであると信じています。
The setup requirements for the link-sharing portion of the service
model are far less clear than those for resource reservations.
While we expect that much of this can be done through network
management interfaces, and thus need not be part of the overall
architecture, we may also need RSVP to play a role in providing
the required state.
サービスモデルのリンクを共有する部分のためのセットアップ要件は資源予約のためのそれらよりはるかに明確ではありません。 また、この多くがネットワークマネージメントインタフェースを通してすることができて、その結果、総合的なアーキテクチャの一部である必要はないと予想している間、私たちは、RSVPが必要な状態を提供することにおける役割を果たす必要があるかもしれません。
In order to state its resource requirements, an application must
specify the desired QoS using a list of parameters that is called
a "flowspec" [Partridge92]. The flowspec is carried by the
reservation setup protocol, passed to admission control for to
test for acceptability, and ultimately used to parametrize the
packet scheduling mechanism.
リソース要件を述べるために、アプリケーションは"flowspec"[Partridge92]と呼ばれるパラメタのリストを使用することで必要なQoSを指定しなければなりません。 結局受容性がないかどうかテストするのが以前はよくパケットスケジューリングメカニズムをparametrizeしていたので、flowspecは入場コントロールに通過された予約セットアッププロトコルによって運ばれます。
Figure shows how these components might fit into an IP router
that has been extended to provide integrated services. The router
has two broad functional divisions: the forwarding path below the
double horizontal line, and the background code above the line.
図はこれらのコンポーネントがどう統合サービスを提供するために広げられたIPルータに収まるかもしれないかを示しています。 ルータには、2つの広い機能的な部門があります: 二重水平な線の下の推進経路、および系列を超えたバックグラウンドコード。
The forwarding path of the router is executed for every packet and
must therefore be highly optimized. Indeed, in most commercial
routers, its implementation involves a hardware assist. The
forwarding path is divided into three sections: input driver,
internet forwarder, and output driver. The internet forwarder
interprets the internetworking protocol header appropriate to the
protocol suite, e.g., the IP header for TCP/IP, or the CLNP header
for OSI. For each packet, an internet forwarder executes a
suite-dependent classifier and then passes the packet and its
class to the appropriate output driver. A classifier must be both
general and efficient. For efficiency, a common mechanism should
be used for both resource classification and route lookup.
ルータの推進経路をあらゆるパケットのために実行されて、したがって、非常に最適化しなければなりません。 本当に、ほとんどの商業ルータに、実装はハードウェアアシストにかかわります。 推進経路は3つのセクションに分割されます: 入力ドライバー、インターネット混載業者、および出力ドライバーインターネット混載業者は、TCP/IPのためにプロトコル群、例えば、IPヘッダーに、適切なインターネットワーキングプロトコルヘッダーを解釈するか、またはOSIのためにCLNPヘッダーを解釈します。 各パケットに関しては、インターネット混載業者は、スイート依存するクラシファイアを処刑して、次に、パケットとそのクラスを適切な出力ドライバーに渡します。クラシファイアは、一般的であって、かつ有能であるに違いありません。 効率において、一般的なメカニズムはリソース分類とルートルックアップの両方に使用されるべきです。
The output driver implements the packet scheduler. (Layerists
will observe that the output driver now has two distinct sections:
the packet scheduler that is largely independent of the detailed
出力ドライバーはパケットスケジューラを実装します。 (Layeristsは、出力ドライバーが現在2つの異なったセクション: 詳細から主に独立しているパケットスケジューラを持っているのを観測するでしょう。
Braden, Clark & Shenker [Page 9] RFC 1633 Integrated Services Architecture June 1994
ブレーデン、クラーク、およびサービスアーキテクチャ1994年6月に統合しているShenker[9ページ]RFC1633
mechanics of the interface, and the actual I/O driver that is only
concerned with the grittiness of the hardware. The estimator
lives somewhere in between. We only note this fact, without
suggesting that it be elevated to a principle.).
インタフェースの整備士、およびハードウェアの勇気に関するだけである実際の入出力ドライバー。 見積り人はどこかで中間で住んでいます。 示さないで、私たちはこの事実に注意するだけです。それは原則に登用されます)。
_____________________________________________________________
| ____________ ____________ ___________ |
| | | | Reservation| | | |
| | Routing | | Setup | | Management| |
| | Agent | | Agent | | Agent | |
| |______._____| |______._____| |_____._____| |
| . . | . |
| . . _V________ . |
| . . | Admission| . |
| . . | Control | . |
| V . |__________| . |
| [Routing ] V V |
| [Database] [Traffic Control Database] |
|=============================================================|
| | | _______ |
| | __________ | |_|_|_|_| => o |
| | | | | Packet | _____ |
| ====> |Classifier| =====> Scheduler |===>|_|_|_| ===>
| | |__________| | _______ | |
| | | |_|_|_|_| => o |
| Input | Internet | |
| Driver | Forwarder | O u t p u t D r i v e r |
|________|__________________|_________________________________|
_____________________________________________________________ | ____________ ____________ ___________ | | | | | 予約| | | | | | ルート設定| | セットアップ| | 管理| | | | エージェント| | エージェント| | エージェント| | | |______._____| |______._____| |_____._____| | | . . | . | | . . _V________ . | | . . | 入場| . | | . . | コントロール| . | | V。|__________| . | | [ルート設定] V V| | [データベース][トラフィックコントロールデータベース]| |=============================================================| | | | _______ | | | __________ | |_|_|_|_| =>o | | | | | | パケット| _____ | | ====>| クラシファイア| =====>スケジューラ|===>|_|_|_| ===>|| |__________| | _______ | | | | | |_|_|_|_| =>o | | 入力| インターネット| | | ドライバー| 混載業者| ○ e rに対するu t p u t D r i| |________|__________________|_________________________________|
Figure 1: Implementation Reference Model for Routers
図1: ルータのための実装規範モデル
The background code is simply loaded into router memory and
executed by a general-purpose CPU. These background routines
create data structures that control the forwarding path. The
routing agent implements a particular routing protocol and builds
a routing database. The reservation setup agent implements the
protocol used to set up resource reservations; see Section . If
admission control gives the "OK" for a new request, the
appropriate changes are made to the classifier and packet
scheduler database to implement the desired QoS. Finally, every
router supports an agent for network management. This agent must
be able to modify the classifier and packet scheduler databases to
set up controlled link-sharing and to set admission control
policies.
バックグラウンドコードは、単にルータメモリにロードされて、汎用CPUによって実行されます。 これらのバックグラウンドルーチンは推進経路を制御するデータ構造を作成します。 ルーティングエージェントは、特定のルーティング・プロトコルを実装して、ルーティングデータベースを築き上げます。 予約セットアップエージェントは資源予約をセットアップするのに使用されるプロトコルを実装します。 セクションを見てください。入場コントロールが新しい要求のために「OK」を与えるなら、必要なQoSを実装するのを適切な変更をクラシファイアとパケットスケジューラデータベースにします。 最終的に、あらゆるルータがネットワークマネージメントのためにエージェントをサポートします。 このエージェントは、制御リンク共有をセットアップして、入場コントロール方針を設定するようにクラシファイアとパケットスケジューラデータベースを変更できなければなりません。
Braden, Clark & Shenker [Page 10] RFC 1633 Integrated Services Architecture June 1994
ブレーデン、クラーク、およびサービスアーキテクチャ1994年6月に統合しているShenker[10ページ]RFC1633
The implementation framework for a host is generally similar to
that for a router, with the addition of applications. Rather than
being forwarded, host data originates and terminates in an
application. An application needing a real-time QoS for a flow
must somehow invoke a local reservation setup agent. The best way
to interface to applications is still to be determined. For
example, there might be an explicit API for network resource
setup, or the setup might be invoked implicitly as part of the
operating system scheduling function. The IP output routine of a
host may need no classifier, since the class assignment for a
packet can be specified in the local I/O control structure
corresponding to the flow.
一般に、ルータに、ホストのための実装フレームワークはアプリケーションの追加についてそれと同様です。 ホストデータはアプリケーションでむしろ、起因して、終わって、進めます。 リアルタイムのQoSを流れに必要とするアプリケーションはどうにか地元の予約セットアップエージェントを呼び出さなければなりません。 アプリケーションに接続する最も良い方法はまだ断固としていることです。 例えば、ネットワーク資源セットアップのための明白なAPIがあるかもしれませんか、またはセットアップはオペレーティングシステムスケジューリング機能の一部としてそれとなく呼び出されるかもしれません。 ホストのIP出力ルーチンはクラシファイアを全く必要としないかもしれません、流れに対応するローカルの入出力制御構造でパケットのためのクラス課題を指定できるので。
In routers, integrated service will require changes to both the
forwarding path and the background functions. The forwarding
path, which may depend upon hardware acceleration for performance,
will be the more difficult and costly to change. It will be vital
to choose a set of traffic control mechanisms that is general and
adaptable to a wide variety of policy requirements and future
circumstances, and that can be implemented efficiently.
ルータでは、統合サービスは推進経路とバックグラウンド機能の両方への変化を必要とするでしょう。 変えるのは、推進経路(性能のためにハードウェア加速によるかもしれない)が、難しくて、より高価になるでしょう。 さまざまな方針要件と将来の事情に一般的であって、融通がきいて、効率的に実装することができる1セットのトラフィックコントロールメカニズムを選ぶのは重大でしょう。
3. Integrated Services Model
3. 統合サービスモデル
A service model is embedded within the network service interface invoked by applications to define the set of services they can request. While both the underlying network technology and the overlying suite of applications will evolve, the need for compatibility requires that this service interface remain relatively stable (or, more properly, extensible; we do expect to add new services in the future but we also expect that it will be hard to change existing services). Because of its enduring impact, the service model should not be designed in reference to any specific network artifact but rather should be based on fundamental service requirements.
サービスモデルはそれらが要求できるサービスのセットを定義するためにアプリケーションで呼び出されたネットワーク・サービスインタフェースの中で埋め込まれています。 基本的なネットワーク技術とアプリケーションの付加一組の両方が発展しますが、互換性の必要性が、このサービスインタフェースが比較的安定していたままで残っているのを必要とする、(より適切に広げることができる、;、将来新種業務を加えると予想しますが、また、私たちが、既存のサービスを変えにくいと予想する ) 永続的な影響のために、サービスモデルをどんな特定のネットワーク人工物に関して設計するべきではありませんが、むしろ基本的なサービス要件に基礎づけるべきです。
We now briefly describe a proposal for a core set of services for the Internet; this proposed core service model is more fully described in [SCZ93a, SCZ93b]. This core service model addresses those services which relate most directly to the time-of-delivery of packets. We leave the remaining services (such as routing, security, or stream synchronization) for other standardization venues. A service model consists of a set of service commitments; in response to a service request the network commits to deliver some service. These service commitments can be categorized by the entity to whom they are made: they can be made to either individual flows or to collective entities (classes of flows). The service commitments made to individual flows are intended to provide reasonable application performance, and thus are driven by the ergonomic requirements of the applications; these
私たちは現在、簡潔にインターネットのための1人の巻き癖のサービスのための提案について説明します。 この提案されたコアサービスモデルは[SCZ93a、SCZ93b]で、より完全に説明されます。 このコアサービスモデルは最も直接パケットの納期に関連するそれらのサービスを扱います。 私たちは他の標準化開催地のための残っているサービス(ルーティング、セキュリティ、またはストリーム同期などの)を残します。 サービスモデルは1セットのサービス委任から成ります。 サービスのリクエストに対応して、ネットワークは、何らかのサービスを提供するために公約されます。 それらがされる実体はこれらのサービス委任を分類できます: それらを個々の流れ、または、集合体(流れのクラス)にすることができます。 個々の流れようにされたサービス公約は、妥当なアプリケーション性能を提供することを意図して、その結果、アプリケーションの人間工学的な要件によって動かされます。 これら
Braden, Clark & Shenker [Page 11] RFC 1633 Integrated Services Architecture June 1994
ブレーデン、クラーク、およびサービスアーキテクチャ1994年6月に統合しているShenker[11ページ]RFC1633
service commitments relate to the quality of service delivered to an individual flow. The service commitments made to collective entities are driven by resource-sharing, or economic, requirements; these service commitments relate to the aggregate resources made available to the various entities.
サービス委任は個々の流れに提供されたサービスの質に関連します。 集合体にされたサービス公約はリソースを共有しているか、または経済の要件によって動かされます。 これらのサービス委任は様々な実体に集合利用できる資源に関連します。
In this section we start by exploring the service requirements of individual flows and propose a corresponding set of services. We then discuss the service requirements and services for resource sharing. Finally, we conclude with some remarks about packet dropping.
このセクションで、私たちは、個々の流れに関するサービス要件について調査することによって始まって、対応するサービスを提案します。 そして、私たちはリソース・シェアリングのためのサービス要件とサービスについて議論します。 最終的に、私たちはパケット低下に関するいくつかの所見で締めくくります。
3.1 Quality of Service Requirements
3.1 サービスの質要件
The core service model is concerned almost exclusively with the
time-of-delivery of packets. Thus, per-packet delay is the
central quantity about which the network makes quality of service
commitments. We make the even more restrictive assumption that
the only quantity about which we make quantitative service
commitments are bounds on the maximum and minimum delays.
コアサービスモデルは専らパケットの納期に関係があります。 したがって、1パケットあたりの遅れはネットワークがサービスの質公約をする中央の量です。 私たちは最大の、そして、最小の遅れで私たちが量的なサービス公約をする唯一の量があるさらに制限している仮定を領域にします。
The degree to which application performance depends on low delay
service varies widely, and we can make several qualitative
distinctions between applications based on the degree of their
dependence. One class of applications needs the data in each
packet by a certain time and, if the data has not arrived by then,
the data is essentially worthless; we call these real-time
applications. Another class of applications will always wait for
data to arrive; we call these " elastic" applications. We now
consider the delay requirements of these two classes separately.
アプリケーション性能を依存する度合いは低い遅れサービスのときにばらつきが大きいです、そして、私たちは彼らの依存の度合いに基づくアプリケーションの間でいくつかの質的な区別をすることができます。 1つのクラスのアプリケーションはある時間までに各パケットでデータを必要とします、そして、データがその時までに到着していないなら、データは本質的には価値がありません。 私たちはこれらのリアルタイムのアプリケーションを呼びます。 もう1人のクラスのアプリケーションは、いつもデータが到着するのを待つでしょう。 私たちはこれらの「弾性」のアプリケーションを呼びます。 私たちは現在、別々にこれらの2つのクラスの遅れ要件を考えます。
3.1.1 Real-Time Applications
3.1.1 リアルタイムのアプリケーション
An important class of such real-time applications, which are
the only real-time applications we explicitly consider in the
arguments that follow, are "playback" applications. In a
playback application, the source takes some signal, packetizes
it, and then transmits the packets over the network. The
network inevitably introduces some variation in the delay of
the delivered packets. The receiver depacketizes the data and
then attempts to faithfully play back the signal. This is done
by buffering the incoming data and then replaying the signal at
some fixed offset delay from the original departure time; the
term "playback point" refers to the point in time which is
offset from the original departure time by this fixed delay.
Any data that arrives before its associated playback point can
be used to reconstruct the signal; data arriving after the
playback point is essentially useless in reconstructing the
重要なクラスのそのようなリアルタイムのアプリケーション(私たちが続く議論で明らかに考える唯一のリアルタイムのアプリケーションである)は「再生」アプリケーションです。 再生アプリケーションでは、情報筋は、ネットワークの上に何らかの信号を取って、それをpacketizesして、次に、パケットを伝えます。 ネットワークは必然的に提供されたパケットの遅れの何らかの変化を導入します。 受信機は、データをdepacketizesして、次に、信号を忠実に再生するのを試みます。 元の出発時間から受信データをバッファリングして、次に、何らかの固定オフセット遅れで信号を再演することによって、これをします。 「再生ポイント」という用語は時間内にのこの固定遅れによって元の出発時間から相殺されるポイントを示します。 信号を再建するのに関連再生ポイントを使用できる前に到着するどんなデータも。 再建します再生ポイントの後に到着するデータが本質的には役に立たない。
Braden, Clark & Shenker [Page 12] RFC 1633 Integrated Services Architecture June 1994
ブレーデン、クラーク、およびサービスアーキテクチャ1994年6月に統合しているShenker[12ページ]RFC1633
real-time signal.
リアルタイムの信号。
In order to choose a reasonable value for the offset delay, an
application needs some "a priori" characterization of the
maximum delay its packets will experience. This "a priori"
characterization could either be provided by the network in a
quantitative service commitment to a delay bound, or through
the observation of the delays experienced by the previously
arrived packets; the application needs to know what delays to
expect, but this expectation need not be constant for the
entire duration of the flow.
オフセット遅れのための適正価値を選ぶために、アプリケーションはパケットが経験する最大の遅れの「先験的な」何らかの特殊化を必要とします。 ネットワークは以前に到着したパケットによって縛られるか、または遅れの観測で経験された遅れの量的なサービス委任にこの「先験的な」特殊化を提供できました。 アプリケーションは、どんな遅れを予想したらよいかを知る必要がありますが、流れの全体の持続時間に、この期待は一定である必要はありません。
The performance of a playback application is measured along two
dimensions: latency and fidelity. Some playback applications,
in particular those that involve interaction between the two
ends of a connection such as a phone call, are rather sensitive
to the latency; other playback applications, such as
transmitting a movie or lecture, are not. Similarly,
applications exhibit a wide range of sensitivity to loss of
fidelity. We will consider two somewhat artificially
dichotomous classes: intolerant applications, which require an
absolutely faithful playback, and tolerant applications, which
can tolerate some loss of fidelity. We expect that the vast
bulk of audio and video applications will be tolerant, but we
also suspect that there will be other applications, such as
circuit emulation, that are intolerant.
再生アプリケーションの性能は二次元に沿って測定されます: 潜在と信義。 いくつかの再生アプリケーション(特に電話などの接続の2つの終わりの間の相互作用にかかわるもの)が潜在にかなり敏感です。 映画か講演を伝えなどなどの他の再生利用がありません。 同様に、アプリケーションはさまざまな感度を信義の損失に示します。 私たちは2つのいくらか人工的に2分のクラスを考えるつもりです: (アプリケーションは絶対に忠実な再生を必要とします)。偏狭なアプリケーションと許容性があるアプリケーション。(そのアプリケーションは信義のいくらかの損失を黙認できます)。 オーディオとビデオ・アプリケーションのかなりの大半が許容性があると予想しますが、また、私たちは、回路エミュレーションなどの他の偏狭な利用があると疑います。
Delay can affect the performance of playback applications in
two ways. First, the value of the offset delay, which is
determined by predictions about the future packet delays,
determines the latency of the application. Second, the delays
of individual packets can decrease the fidelity of the playback
by exceeding the offset delay; the application then can either
change the offset delay in order to play back late packets
(which introduces distortion) or merely discard late packets
(which creates an incomplete signal). The two different ways
of coping with late packets offer a choice between an
incomplete signal and a distorted one, and the optimal choice
will depend on the details of the application, but the
important point is that late packets necessarily decrease
fidelity.
遅れは2つの方法における、再生アプリケーションの性能に影響できます。 まず最初に、オフセット遅れの値はアプリケーションの潜在を決定します。(遅れは将来のパケット遅れに関する予測で決定します)。 2番目に、個々のパケットの遅れはオフセット遅れを超えていることによって、再生の信義を減少させることができます。 そして、アプリケーションは、遅いパケット(ひずみを導入する)を再生するためにオフセット遅れを変えるか、または単に遅いパケットを捨てることができます(不完全な信号を作成します)。 遅いパケットに対処する2つの異なった方法が不完全な信号とひずみのものの間で好きなのを選んでよいといいます、そして、最適選択はアプリケーションの詳細によるでしょうが、重要なポイントは遅いパケットが必ず信義を減少させるということです。
Intolerant applications must use a fixed offset delay, since
any variation in the offset delay will introduce some
distortion in the playback. For a given distribution of packet
delays, this fixed offset delay must be larger than the
absolute maximum delay, to avoid the possibility of late
packets. Such an application can only set its offset delay
偏狭なアプリケーションは固定オフセット遅れを使用しなければなりません、オフセット遅れのどんな変化も再生で何らかのひずみを導入するので。 パケット遅れの与えられた分配において、この固定オフセット遅れは、遅いパケットの可能性を避けるために絶対最大値遅れより大きくなければなりません。 そのようなアプリケーションはオフセット遅れを設定できるだけです。
Braden, Clark & Shenker [Page 13] RFC 1633 Integrated Services Architecture June 1994
ブレーデン、クラーク、およびサービスアーキテクチャ1994年6月に統合しているShenker[13ページ]RFC1633
appropriately if it is given a perfectly reliable upper bound
on the maximum delay of each packet. We call a service
characterized by a perfectly reliable upper bound on delay "
guaranteed service", and propose this as the appropriate
service model for intolerant playback applications.
最大で完全に信頼できる上限をそれに与えるなら、適切に、各パケットを延着させてください。 私たちは、「サービスは保証された」遅れに完全に信頼できる上限によって特徴付けられたサービスを呼んで、偏狭な再生アプリケーションのための適切なサービスモデルとしてこれを提案します。
In contrast, tolerant applications need not set their offset
delay greater than the absolute maximum delay, since they can
tolerate some late packets. Moreover, instead of using a
single fixed value for the offset delay, they can attempt to
reduce their latency by varying their offset delays in response
to the actual packet delays experienced in the recent past. We
call applications which vary their offset delays in this manner
"adaptive" playback applications.
対照的に、許容性があるアプリケーションはそれらの絶対最大値遅れよりすばらしいオフセット遅れを設定する必要はありません、彼らがいくつかの遅いパケットを許容できるので。 そのうえ、オフセット遅れにただ一つの一定の価値を使用することの代わりに、彼らは、最近において経験された実際のパケット遅れに対応してそれらのオフセット遅れを変えることによってそれらのレイテンシを減少させるのを試みることができます。 私たちは、この様にそれらのオフセット遅れを変えるアプリケーションを「適応型」の再生アプリケーションと呼びます。
For tolerant applications we propose a service model called "
predictive service" which supplies a fairly reliable, but not
perfectly reliable, delay bound. This bound, in contrast to
the bound in the guaranteed service, is not based on worst case
assumptions on the behavior of other flows. Instead, this
bound might be computed with properly conservative predictions
about the behavior of other flows. If the network turns out to
be wrong and the bound is violated, the application's
performance will perhaps suffer, but the users are willing to
tolerate such interruptions in service in return for the
presumed lower cost of the service. Furthermore, because many
of the tolerant applications are adaptive, we augment the
predictive service to also give "minimax" service, which is to
attempt to minimize the ex post maximum delay. This service is
not trying to minimize the delay of every packet, but rather is
trying to pull in the tail of the delay distribution.
許容性があるアプリケーションのために、私たちはかなり信頼できますが、完全に信頼できない遅れバウンドを供給する「予言のサービス」と呼ばれるサービスモデルを提案します。 保証されたサービスにおけるバウンドと対照して、このバウンドは他の流れの振舞いの最悪の場合仮定に基づいていません。 代わりに、このバウンドは他の流れの振舞いに関する適切に保守的な予測で計算されるかもしれません。 ネットワークが間違っていると判明して、バウンドが違反されると、アプリケーションの性能に恐らく苦しむでしょうが、ユーザは、推定された低いサービスの費用のお返しに使用中のそのような中断を許容しても構わないと思っています。 その上、許容性があるアプリケーションの多くが適応型であるので、私たちはまた、元のポスト最大の遅れを最小にするのを試みることである「ミニマックス」サービスを与えるために予言のサービスを増大させます。 このサービスは、あらゆるパケットの遅れを最小にしようとしていませんが、むしろ遅れ分配のテールを引きつけようとしています。
It is clear that given a choice, with all other things being
equal, an application would perform no worse with absolutely
reliable bounds than with fairly reliable bounds. Why, then,
do we offer predictive service? The key consideration here is
efficiency; when one relaxes the service requirements from
perfectly to fairly reliable bounds, this increases the level
of network utilization that can be sustained, and thus the
price of the predictive service will presumably be lower than
that of guaranteed service. The predictive service class is
motivated by the conjecture that the performance penalty will
be small for tolerant applications but the overall efficiency
gain will be quite large.
選択を考えて、他のすべてのものが等しい状態で、アプリケーションが絶対に信頼できる領域でかなり信頼できる領域よりひどく働かないのは、明確です。 そして、私たちはなぜ予言のサービスを提供しますか? ここでの重要な考慮すべき事柄は効率です。 1つがいつからサービス要件を弛緩するかがかなり信頼できるのに完全にバウンドしていて、これが支えることができるネットワーク利用のレベルを増強して、その結果、おそらく、予言的にサービスの価格は保証されたサービスのものよりさらに低くなるでしょう。 パフォーマンスに不利な条件が許容性があるアプリケーションに小さくなるという推測で予言のサービスのクラスは動機づけられていますが、全体的効率利得はかなり大きくなるでしょう。
In order to provide a delay bound, the nature of the traffic
from the source must be characterized, and there must be some
admission control algorithm which insures that a requested flow
遅れバウンドを提供するために、それを保障した何らかの入場コントロールアルゴリズムが要求された流れだったに違いないならそこでソースからのトラフィックの本質を特徴付けなければなりません。
Braden, Clark & Shenker [Page 14] RFC 1633 Integrated Services Architecture June 1994
ブレーデン、クラーク、およびサービスアーキテクチャ1994年6月に統合しているShenker[14ページ]RFC1633
can actually be accommodated. A fundamental point of our
overall architecture is that traffic characterization and
admission control are necessary for these real-time delay bound
services. So far we have assumed that an application's data
generation process is an intrinsic property unaffected by the
network. However, there are likely to be many audio and video
applications which can adjust their coding scheme and thus can
alter the resulting data generation process depending on the
network service available. This alteration of the coding
scheme will present a tradeoff between fidelity (of the coding
scheme itself, not of the playback process) and the bandwidth
requirements of the flow. Such "rate-adaptive" playback
applications have the advantage that they can adjust to the
current network conditions not just by resetting their playback
point but also by adjusting the traffic pattern itself. For
rate-adaptive applications, the traffic characterizations used
in the service commitment are not immutable. We can thus
augment the service model by allowing the network to notify
(either implicitly through packet drops or explicitly through
control packets) rate-adaptive applications to change their
traffic characterization.
実際に、設備することができます。 私たちの総合的なアーキテクチャの基本的なポイントはトラフィックが制限されたサービスを遅らせるという特殊化と入場コントロールがこれらにおいてリアルタイムで状態で必要であることです。 今までのところ、私たちは、アプリケーションのデータ発生経過がネットワークで影響を受けない本質的な特性であると思いました。 しかしながら、利用可能なネットワーク・サービスによる結果として起こるデータ発生経過は、それらのコード構成を調整できる多くのオーディオとビデオアプリケーションであることがありそうであり、その結果、変わることができます。 コード構成のこの変更は信義(再生プロセスではなく、コード構成自体の)と流れに関する帯域幅要件の間の見返りを提示するでしょう。 そのような「レート適応型」の再生アプリケーションには、それらがそれらの再生ポイントをリセットするだけで調整するのではなく、トラフィック・パターン自体をまた調整することによって現在のネットワーク状態に調整できる利点があります。 レート適応型のアプリケーションにおいて、サービス委任に使用されるトラフィック特殊化は不変ではありません。 その結果、ネットワークが、レート適応型のアプリケーションが彼らのトラフィック特殊化を変えるように通知するのを(どちらかがパケットを通してそれとなく低下するか、または明らかに、パケットは通じて制御します)許容することによって、私たちはサービスモデルを増大させることができます。
3.1.2 Elastic Applications
3.1.2 弾性のアプリケーション
While real-time applications do not wait for late data to
arrive, elastic applications will always wait for data to
arrive. It is not that these applications are insensitive to
delay; to the contrary, significantly increasing the delay of a
packet will often harm the application's performance. Rather,
the key point is that the application typically uses the
arriving data immediately, rather than buffering it for some
later time, and will always choose to wait for the incoming
data rather than proceed without it. Because arriving data can
be used immediately, these applications do not require any a
priori characterization of the service in order for the
application to function. Generally speaking, it is likely that
for a given distribution of packet delays, the perceived
performance of elastic applications will depend more on the
average delay than on the tail of the delay distribution. One
can think of several categories of such elastic applications:
interactive burst (Telnet, X, NFS), interactive bulk transfer
(FTP), and asynchronous bulk transfer (electronic mail, FAX).
The delay requirements of these elastic applications vary from
rather demanding for interactive burst applications to rather
lax for asynchronous bulk transfer, with interactive bulk
transfer being intermediate between them.
リアルタイムのアプリケーションは、遅いデータが到着するのを待っていませんが、弾性のアプリケーションは、いつもデータが到着するのを待つでしょう。 これらのアプリケーションが延着するように神経が鈍いということではありません。 それと反対に、パケットの遅れをかなり増強すると、アプリケーションの性能はしばしば害を及ぼすでしょう。 むしろ、要所はアプリケーションが、すぐに何らかの後の時間それをバッファリングするよりむしろ到着データを通常使用して、それなしで続くよりいつも受信データを待つのをむしろ選ぶということです。 すぐに到着データを使用できるので、これらのアプリケーションは、アプリケーションにおいて、整然としているサービスのどんな先験的な特殊化も機能するのを必要としません。 概して、パケット遅れの与えられた分配のために、弾性のアプリケーションの知覚された性能は遅れ分配のテールより平均した遅れに依存しそうでしょう。 人はそのような弾性のアプリケーションのいくつかのカテゴリを考えることができます: 対話的な炸裂(telnet、X、NFS)、対話的なバルク転送(FTP)、および非同期な大量は(電子メール、FAX)を移します。 これらの弾性のアプリケーションの遅れ要件はむしろ対話的な炸裂アプリケーションの要求から非同期なバルク転送にはかなり手緩く異なります、対話的なバルク転送がそれらの間で中間的に。
Braden, Clark & Shenker [Page 15] RFC 1633 Integrated Services Architecture June 1994
ブレーデン、クラーク、およびサービスアーキテクチャ1994年6月に統合しているShenker[15ページ]RFC1633
An appropriate service model for elastic applications is to
provide "as-soon-as-possible", or ASAP service. (For
compatibility with historical usage, we will use the term
best-effort service when referring to ASAP service.). We
furthermore propose to offer several classes of best-effort
service to reflect the relative delay sensitivities of
different elastic applications. This service model allows
interactive burst applications to have lower delays than
interactive bulk applications, which in turn would have lower
delays than asynchronous bulk applications. In contrast to the
real-time service models, applications using this service are
not subject to admission control.
弾性のアプリケーションのための適切なサービスモデルは「できるだけ早い」、またはできるだけ早く、サービスを提供することになっています。 (できるだけ早くサービスについて言及するとき、歴史的な用法との互換性のために、私たちは用語のベストエフォート型サービスを利用するつもりです。) その上、私たちは、異なった弾性のアプリケーションの相対的な遅れの敏感さを反映するために数人のクラスのベストエフォート型サービスを提供するよう提案します。 このサービスモデルは対話的な炸裂アプリケーションに順番に非同期な大量のアプリケーションより低い遅れを持っているだろう対話的な大量のアプリケーションより低い遅れを持たせます。 リアルタイムのサービスモデルと対照して、このサービスを利用するアプリケーションは入場コントロールを受けることがありません。
The taxonomy of applications into tolerant playback, intolerant
playback, and elastic is neither exact nor complete, but was
only used to guide the development of the core service model.
The resulting core service model should be judged not on the
validity of the underlying taxonomy but rather on its ability
to adequately meet the needs of the entire spectrum of
applications. In particular, not all real-time applications
are playback applications; for example, one might imagine a
visualization application which merely displayed the image
encoded in each packet whenever it arrived. However, non-
playback applications can still use either the guaranteed or
predictive real-time service model, although these services are
not specifically tailored to their needs. Similarly, playback
applications cannot be neatly classified as either tolerant or
intolerant, but rather fall along a continuum; offering both
guaranteed and predictive service allows applications to make
their own tradeoff between fidelity, latency, and cost.
Despite these obvious deficiencies in the taxonomy, we expect
that it describes the service requirements of current and
future applications well enough so that our core service model
can adequately meet all application needs.
許容性がある再生、偏狭な再生、およびゴムひもへのアプリケーションの分類学は、正確でなくて、また完全ではありませんが、コアサービスモデルの進化を誘導するのに使用されただけです。 結果として起こるコアサービスモデルは基本的な分類学の正当性で判断されるのではなく、むしろ適切にアプリケーションの全体のスペクトルの需要を満たすその性能で判断されるべきです。 リアルタイムのアプリケーションは特に、すべてではなく、再生アプリケーションです。 例えば、人は、想像が単に到着したときはいつも、各パケットでコード化されたイメージを表示したアプリケーションであると想像するかもしれません。 しかしながら、非再生のアプリケーションはまだ保証されたか予言のリアルタイムのサービスモデルを使用できます、彼らの必要なことに、これらのサービスが明確に適合しませんが。 同様に、再生アプリケーションは、許容性があるか偏狭であるとしてきちんと分類されるのではなく、連続に沿ってむしろ下がることができます。 保証されて予言の両方のサービスを提供するのに、アプリケーションは信義と、潜在と、費用の間でそれら自身の見返りを作ることができます。 分類学のこれらの明白な欠乏にもかかわらず、私たちは、私たちのコアサービスモデルが適切にアプリケーションが必要とするすべてに会うことができるようにそれが現在の、そして、将来のアプリケーションに関するサービス要件について十分よく説明すると予想します。
3.2 Resource-Sharing Requirements and Service Models
3.2 リソース・シェアリング要件とサービスモデル
The last section considered quality of service commitments; these
commitments dictate how the network must allocate its resources
among the individual flows. This allocation of resources is
typically negotiated on a flow-by-flow basis as each flow requests
admission to the network, and does not address any of the policy
issues that arise when one looks at collections of flows. To
address these collective policy issues, we now discuss resource-
sharing service commitments. Recall that for individual quality
of service commitments we focused on delay as the only quantity of
interest. Here, we postulate that the quantity of primary
interest in resource-sharing is aggregate bandwidth on individual
最後のセクションは、サービスの質が委任であると考えました。 これらの委任はネットワークがどう個々の流れにリソースを割り当てなければならないかを決めます。 リソースのこの配分は、各流れがネットワークに入場を要求するとき流れごとのベースに関して通常交渉されて、人が流れの収集を見るとき、起こる政策問題のいずれも扱いません。 これらが集合的な政策問題であると扱うために、私たちは現在、サービス委任を共有しながら、リソースについて議論します。 私たちが興味がある唯一の量として遅れに焦点を合わせた個々のサービスの質委任のためにそれを思い出してください。 ここで、私たちは、主要にリソース・シェアリングへの関心の量が個人における集合帯域幅であることを仮定します。
Braden, Clark & Shenker [Page 16] RFC 1633 Integrated Services Architecture June 1994
ブレーデン、クラーク、およびサービスアーキテクチャ1994年6月に統合しているShenker[16ページ]RFC1633
links. Thus, this component of the service model, called "link-
sharing", addresses the question of how to share the aggregate
bandwidth of a link among various collective entities according to
some set of specified shares. There are several examples that are
commonly used to explain the requirement of link-sharing among
collective entities.
リンク。 したがって、「リンク共有」と呼ばれるサービスモデルのこの部品は何らかのセットの指定された株に従って様々な集合体の中でどうリンクの集合帯域幅を共有するかに関する質問を扱います。 集合体の中でリンク共有の要件について説明するのに一般的に使用されるいくつかの例があります。
Multi-entity link-sharing. -- A link may be purchased and used
jointly by several organizations, government agencies or the like.
They may wish to insure that under overload the link is shared in
a controlled way, perhaps in proportion to the capital investment
of each entity. At the same time, they might wish that when the
link is underloaded, any one of the entities could utilize all the
idle bandwidth.
マルチ実体リンク共有。 -- リンクは、いくつかの組織、政府機関または同様のものによって共同で購入されて、使用されるかもしれません。 彼らは、オーバーロードの下では、リンクが制御方法で共有されるのを保障したがっているかもしれません、恐らくそれぞれの実体の設備投資に比例して。 同時に、彼らは、リンクがunderloadedされると、実体のどれかがすべての活動していない帯域幅を利用することを願うかもしれません。
Multi-protocol link-sharing -- In a multi-protocol Internet, it
may be desired to prevent one protocol family (DECnet, IP, IPX,
OSI, SNA, etc.) from overloading the link and excluding the other
families. This is important because different families may have
different methods of detecting and responding to congestion, and
some methods may be more "aggressive" than others. This could lead
to a situation in which one protocol backs off more rapidly than
another under congestion, and ends up getting no bandwidth.
Explicit control in the router may be required to correct this.
Again, one might expect that this control should apply only under
overload, while permitting an idle link to be used in any
proportion.
マルチプロトコルリンク共有--マルチプロトコルインターネットでは、1つのプロトコルファミリー(DECnet、IP、IPX、OSI、SNAなど)がリンクを積みすぎて、他のファミリーを除くのを防ぐのは必要であるかもしれません。 異なったファミリーには混雑に検出して、応じる異なったメソッドがあるかもしれないのでこれが重要であり、いくつかのメソッドが他のものより「攻撃的であるかもしれません」。 これは、帯域幅を全く得ないことでプロトコルが別のものより急速に混雑で引き返して、終わる状況に通じるかもしれません。 ルータにおける明白なコントロールが、これを修正するのに必要であるかもしれません。 一方、使用されていないリンクがどんな割合にも使用されることを許可している間、人は、このコントロールがオーバーロードの下でだけ申請されるはずであると予想するかもしれません。
Multi-service sharing -- Within a protocol family such as IP, an
administrator might wish to limit the fraction of bandwidth
allocated to various service classes. For example, an
administrator might wish to limit the amount of real-time traffic
to some fraction of the link, to avoid preempting elastic traffic
such as FTP.
マルチサービス共有--IPなどのプロトコルファミリーの中では、管理者は様々なサービスのクラスに割り当てられた帯域幅の部分を制限したがっているかもしれません。 例えば、管理者は、リアルタイムのトラフィックの量をリンクのある部分に制限して、FTPなどの弾性のトラフィックを先取りするのを避けたがっているかもしれません。
In general terms, the link-sharing service model is to share the
aggregate bandwidth according to some specified shares. We can
extend this link-sharing service model to a hierarchical version.
For instance, a link could be divided between a number of
organizations, each of which would divide the resulting allocation
among a number of protocols, each of which would be divided among
a number of services. Here, the sharing is defined by a tree with
shares assigned to each leaf node.
あいまいな言葉で、いくつかの指定されたシェアによると、リンクを共有するサービスモデルは集合帯域幅を共有することになっています。 私たちはこのリンクを共有するサービスモデルを階層的なバージョンに広げることができます。 例えば、多くの組織の間でリンクを分割できました。それは、多くのプロトコルの中でそれぞれ結果として起こる配分を分割するでしょう。それは多くのサービスの中でそれぞれ分割されるでしょう。 ここで、シェアがそれぞれの葉のノードに割り当てられている状態で、共有は木によって定義されます。
An idealized fluid model of instantaneous link-sharing with
proportional sharing of excess is the fluid processor sharing
model (introduced in [DKS89] and further explored in [Parekh92]
and generalized to the hierarchical case) where at every instant
いつも瞬間に過剰の比例している共有との瞬時に起こっているリンク共有の理想化された流体モデルは流体プロセッサ共有モデル([DKS89]で挿入されて、[Parekh92]でさらに探検されて、階層的なケースに一般化される)です。
Braden, Clark & Shenker [Page 17] RFC 1633 Integrated Services Architecture June 1994
ブレーデン、クラーク、およびサービスアーキテクチャ1994年6月に統合しているShenker[17ページ]RFC1633
the available bandwidth is shared between the active entities
(i.e., those having packets in the queue) in proportion to the
assigned shares of the resource. This fluid model exhibits the
desired policy behavior but is, of course, an unrealistic
idealization. We then propose that the actual service model
should be to approximate, as closely as possible, the bandwidth
shares produced by this ideal fluid model. It is not necessary to
require that the specific order of packet departures match those
of the fluid model since we presume that all detailed per-packet
delay requirements of individual flows are addressed through
quality of service commitments and, furthermore, the satisfaction
with the link-sharing service delivered will probably not depend
very sensitively on small deviations from the scheduling implied
by the fluid link-sharing model.
利用可能な帯域幅は同行アクティブな実体(すなわち、待ち行列でパケットを持っているもの)の間で共有されて、割り当てがリソースを共有するということです。 この流体モデルは、必要な方針の振舞いを示しますが、もちろん非現実的な理想化です。 そして、私たちは、就航モデルができるだけ密接にこの理想的な流体モデルによって生産された帯域幅シェアに近似することになっているべきであるよう提案します。 私たちが、個々の流れのすべての1パケットあたりの詳細な遅れ要件がサービスの質委任を通して扱われると推定するのでパケット出発の特定の注文が流体モデルのものに合うのが必要であるのは必要でなく、またその上、提供されるリンクを共有するサービスに対する満足はたぶんそれほど敏感にリンクを共有する流体モデルによって暗示されたスケジューリングからのわずかな逸脱に依存しないでしょう。
We previously observed that admission control was necessary to
ensure that the real-time service commitments could be met.
Similarly, admission control will again be necessary to ensure
that the link-sharing commitments can be met. For each entity,
admission control must keep the cumulative guaranteed and
predictive traffic from exceeding the assigned link-share.
私たちは、以前に、入場コントロールがリアルタイムのサービス委任を満たすことができたのを保証するのに必要であることを観測しました。 同様に、入場コントロールは、リンクを共有する委任を満たすことができるのを保証するために再び必要になるでしょう。 各実体のために、入場コントロールは、累積している保証されて予言のトラフィックが割り当てられたリンクシェアを超えているのを妨げなければなりません。
3.3 Packet Dropping
3.3 パケット低下
So far, we have implicitly assumed that all packets within a flow
were equally important. However, in many audio and video streams,
some packets are more valuable than others. We therefore propose
augmenting the service model with a "preemptable" packet service,
whereby some of the packets within a flow could be marked as
preemptable. When the network was in danger of not meeting some
of its quantitative service commitments, it could exercise a
certain packet's "preemptability option" and discard the packet
(not merely delay it, since that would introduce out-of-order
problems). By discarding these preemptable packets, a router can
reduce the delays of the not-preempted packets.
今までのところ、私たちは、流れの中のすべてのパケットが等しく重要であったとそれとなく思いました。 しかしながら、多くのオーディオとビデオストリームでは、いくつかのパケットが他のものより貴重です。 したがって、私たちは、"先取り可能"パケットサービスに従ってサービスモデルを増大させるよう提案します。(サービスで流れの中のいくつかのパケットを先取り可能であるとマークできるでしょう)。 ネットワークに量的なサービス委任のいくつかを満たさないという危険があったとき、それは、あるパケットの「preemptabilityオプション」を運動させて、パケット(それは不適切な問題を紹介するでしょう、したがって、単に、それを遅らせない)を捨てるかもしれません。 これらの先取り可能パケットを捨てることによって、ルータは先取りされなかったパケットの遅れを減少させることができます。
Furthermore, one can define a class of packets that is not subject
to admission control. In the scenario described above where
preemptable packets are dropped only when quantitative service
commitments are in danger of being violated, the expectation is
that preemptable packets will almost always be delivered and thus
they must included in the traffic description used in admission
control. However, we can extend preemptability to the extreme
case of "expendable" packets (the term expendable is used to
connote an extreme degree of preemptability), where the
expectation is that many of these expendable packets may not be
delivered. One can then exclude expendable packets from the
traffic description used in admission control; i.e., the packets
その上、人はパケットの入場コントロールを受けることがないクラスを定義できます。 量的なサービス委任に違反されるという危険があるときだけ先取り可能パケットが下げられる上で説明されたシナリオでは、期待は先取り可能パケットがほとんどいつも提供されるということです、そして、その結果、入場コントロールに使用されるトラフィック記述に含まれていて、それらはことでなければなりません。 しかしながら、私たちは「消費してよい」パケット(消費してよいという用語は1極度のpreemptabilityを内包するのに使用される)の極端なケースにpreemptabilityを広げることができます。そこでは、期待はこれらの消費してよいパケットの多くが提供されないかもしれないということです。 次に、1つは入場コントロールに使用されるトラフィック記述に消費してよいパケットを入れないようにすることができます。 すなわち、パケット
Braden, Clark & Shenker [Page 18] RFC 1633 Integrated Services Architecture June 1994
ブレーデン、クラーク、およびサービスアーキテクチャ1994年6月に統合しているShenker[18ページ]RFC1633
are not considered part of the flow from the perspective of
admission control, since there is no commitment that they will be
delivered.
それらが提供される委任が全くないので、入場コントロールの見解からの流れの一部であることは考えられません。
3.4 Usage Feedback
3.4 用法フィードバック
Another important issue in the service is the model for usage
feedback, also known as "accounting", to prevent abuse of network
resources. The link-sharing service described earlier can be
used to provide administratively-imposed limits on usage.
However, a more free-market model of network access will require
back-pressure on users for the network resources they reserve.
This is a highly contentious issue, and we are not prepared to say
more about it at this time.
サービスにおける別の切迫した課題はまた、ネットワーク資源の誤用を防ぐために「説明」であるとして知られている用法フィードバックのためのモデルです。 用法における行政上課された限界を提供するのにより早く説明されたリンクを共有するサービスは利用できます。 しかしながら、ネットワークアクセスの自由なより多くの市場のモデルはそれらが予約するネットワーク資源のためにユーザへの逆圧を必要とするでしょう。 これは非常に議論好きな問題です、そして、私たちはこのときそれに関してもう少し言う用意ができていません。
3.5 Reservation Model
3.5 予約モデル
The "reservation model" describes how an application negotiates
for a QoS level. The simplest model is that the application asks
for a particular QoS and the network either grants it or refuses.
Often the situation will be more complex. Many applications will
be able to get acceptable service from a range of QoS levels, or
more generally, from anywhere within some region of the multi-
dimensional space of a flowspec.
「予約モデル」はアプリケーションがどうQoSレベルを交渉するかを説明します。 最も簡単なモデルがアプリケーションが特定のQoSを求めるということであり、ネットワークは、それを与えるか、または拒否します。 しばしば、状況は、より複雑になるでしょう。 より一般に、多くのアプリケーションがさまざまなQoSレベルから許容できるサービスを得ることができるでしょう、flowspecのマルチ次元のスペースの何らかの領域の中でどこでも、から。
For example, rather than simply refusing the request, the network
might grant a lower resource level and inform the application of
what QoS has been actually granted. A more complex example is the
"two-pass" reservation model, In this scheme, an "offered"
flowspec is propagated along the multicast distribution tree from
each sender Si to all receivers Rj. Each router along the path
records these values and perhaps adjusts them to reflect available
capacity. The receivers get these offers, generate corresponding
"requested" flowspecs, and propagate them back along the same
routes to the senders. At each node, a local reconciliation must
be performed between the offered and the requested flowspec to
create a reservation, and an appropriately modified requested
flowspec is passed on. This two-pass scheme allows extensive
properties like allowed delay to be distributed across hops in the
path [Tenet90, ST2-90]. Further work is needed to define the
amount of generality, with a corresponding level of complexity,
that is required in the reservation model.
簡単であるというよりむしろ例えば、要求を拒否して、ネットワークは、下側のリソースレベルを与えて、QoSが実際に与えられた何に関するアプリケーションを知らせるかもしれないか。 より複雑な例は「ツー・パス」予約モデル、これが計画するIn、「提供された」flowspecがマルチキャスト分配木に沿ってそれぞれの送付者Siからすべての受信機Rjまで伝播されるということです。 経路に沿った各ルータは、これらの値を記録して、有効な容量を反映するように恐らくそれらを調整します。 受信機は、これらの申し出を届けて、対応する「要求された」flowspecsを生成して、同じルートに沿ってそれらを送付者に伝播します。 各ノードでは、予約を作成するために提供と要求されたflowspecの間で地方の和解を実行しなければなりません、そして、適切に変更された要求されたflowspecは伝えられます。 遅れが経路[Tenet90、ST2-90]のホップの向こう側に分配されるために許容されているようにこのツー・パス体系は大規模な特性を許容します。 さらなる仕事が、対応するレベルの複雑さがある予約モデルで必要である一般性の量を定義するのに必要です。
Braden, Clark & Shenker [Page 19] RFC 1633 Integrated Services Architecture June 1994
ブレーデン、クラーク、およびサービスアーキテクチャ1994年6月に統合しているShenker[19ページ]RFC1633
4. Traffic Control Mechanisms
4. トラフィックコントロールメカニズム
We first survey very briefly the possible traffic control mechanisms. Then in Section 4.2 we apply a subset of these mechanisms to support the various services that we have proposed.
私たちは最初に、非常に簡潔に可能なトラフィックコントロールメカニズムについて調査します。そして、セクション4.2では、私たちが提案した様々なサービスをサポートするためにこれらのメカニズムの部分集合を適用します。
4.1 Basic Functions
4.1 基本的な機能
In the packet forwarding path, there is actually a very limited
set of actions that a router can take. Given a particular packet,
a router must select a route for it; in addition the router can
either forward it or drop it, and the router may reorder it with
respect to other packets waiting to depart. The router can also
hold the packet, even though the link is idle. These are the
building blocks from which we must fashion the desired behavior.
パケット推進経路に、ルータが取ることができる非常に限られたセットの行動が実際にあります。 特定のパケットを考えて、ルータはそれのためにルートを選択しなければなりません。 さらに、ルータがそれ、およびルータがそうするそれか低下に追加注文を送ることができる、それ、出発するのを待つ他のパケットに関して。 リンクは使用されていないのですが、また、ルータはパケットを保持できます。 これらは私たちが望まれた行動を作成しなければならないブロックです。
4.1.1 Packet Scheduling
4.1.1 パケットスケジューリング
The basic function of packet scheduling is to reorder the
output queue. There are many papers that have been written on
possible ways to manage the output queue, and the resulting
behavior. Perhaps the simplest approach is a priority scheme,
in which packets are ordered by priority, and highest priority
packets always leave first. This has the effect of giving some
packets absolute preference over others; if there are enough of
the higher priority packets, the lower priority class can be
completely prevented from being sent.
パケットスケジューリングの基本機能は追加注文への出力キューです。 出力キューを管理する可能な方法、および結果として起こる振舞いのときに書かれる多くの論文があります。 恐らく最も簡単なアプローチは優先権計画です、そして、最優先パケットは最初に、いつもいなくなります。(パケットはそれで優先的に注文されます)。 これには、他のものの上で絶対優先をいくつかのパケットに与えるという効果があります。 より高い優先権パケットが十分あれば、送られるのを低優先度のクラスを完全に防ぐことができます。
An alternative scheduling scheme is round-robin or some
variant, which gives different classes of packets access to a
share of the link. A variant called Weighted Fair Queueing, or
WFQ, has been demonstrated to allocate the total bandwidth of a
link into specified shares.
代替のスケジューリング計画は、連続かある異形です。(その異形はリンクのシェアへの異なったクラスのパケットアクセスを与えます)。 Weighted Fair Queueingと呼ばれる異形、またはWFQが、リンクの総帯域幅を指定されたシェアに割り当てるためにデモをしました。
There are more complex schemes for queue management, most of
which involve observing the service objectives of individual
packets, such as delivery deadline, and ordering packets based
on these criteria.
待ち行列管理の、より複雑な計画があります、パケットがこれらの評価基準に基礎づけた配送の締め切りや、注文などのように。その大部分は個々のパケットのサービス目的を観測することを伴います。
4.1.2 Packet Dropping
4.1.2 パケット低下
The controlled dropping of packets is as important as their
scheduling.
パケットの制御低下はそれらのスケジューリングと同じくらい重要です。
Most obviously, a router must drop packets when its buffers are
all full. This fact, however, does not determine which packet
should be dropped. Dropping the arriving packet, while simple,
may cause undesired behavior.
バッファがすべて完全であるときに、最も明らかに、ルータはパケットを落とさなければなりません。 しかしながら、この事実は、どのパケットが落とされるべきであるかを決定しません。 簡単である間、到着パケットを落とすと、望まれない振舞いは引き起こされるかもしれません。
Braden, Clark & Shenker [Page 20] RFC 1633 Integrated Services Architecture June 1994
ブレーデン、クラーク、およびサービス構造1994年6月に統合しているShenker[20ページ]RFC1633
In the context of today's Internet, with TCP operating over
best effort IP service, dropping a packet is taken by TCP as a
signal of congestion and causes it to reduce its load on the
network. Thus, picking a packet to drop is the same as picking
a source to throttle. Without going into any particular
algorithm, this simple relation suggests that some specific
dropping controls should be implemented in routers to improve
congestion control.
今日のインターネットの文脈では、パケットを落とすのは、混雑に関する信号としてTCPによって取られて、TCPがベストエフォート型IPサービスの上で作動している状態で、それはネットワークで負荷を減少させます。 したがって、低下するためにパケットを選ぶのは阻止するソースを選ぶのと同じです。 どんな特定のアルゴリズムも調べないで、この簡単な関係は、いくつかの特定の低下管理が輻輳制御を改良するためにルータで実施されるべきであると示唆します。
In the context of real-time services, dropping more directly
relates to achieving the desired quality of service. If a
queue builds up, dropping one packet reduces the delay of all
the packets behind it in the queue. The loss of one can
contribute to the success of many. The problem for the
implementor is to determine when the service objective (the
delay bound) is in danger of being violated. One cannot look
at queue length as an indication of how long packets have sat
in a queue. If there is a priority scheme in place, packets of
lower priority can be pre-empted indefinitely, so even a short
queue may have very old packets in it. While actual time
stamps could be used to measure holding time, the complexity
may be unacceptable.
リアルタイムでサービスの文脈では、低下は、より直接必要なサービスの質を獲得するのに関係します。 待ち行列が増すなら、1つのパケットを落とすと、それの後ろのすべてのパケットの遅れは待ち行列で減少します。 1の損失は多くの成功に貢献できます。 作成者のための問題はいつ、サービス目的(遅れは付いた)には違反されるという危険があるかを決定することです。 人はパケットが待ち行列でどれくらい長い状態で座ったかしるしとして待ち行列の長さを見ることができません。 優先権計画が適所であれば、低優先度のパケットを先取りさえできます。 把持時間を測定するのに実際のタイムスタンプを使用できた間、複雑さは容認できないかもしれません。
Some simple dropping schemes, such as combining all the buffers
in a single global pool, and dropping the arriving packet if
the pool is full, can defeat the service objective of a WFQ
scheduling scheme. Thus, dropping and scheduling must be
coordinated.
単一のグローバルなプールの中ですべてのバッファを結合して、プールが完全であるなら到着パケットを落とすことなどのいくつかの簡単な低下計画がWFQスケジューリング計画のサービス目的をくつがえすことができます。 したがって、低下とスケジューリングを調整しなければなりません。
4.1.3 Packet Classification
4.1.3 パケット分類
The above discussion of scheduling and dropping presumed that
the packet had been classified into some flow or sequence of
packets that should be treated in a specified way. A
preliminary to this sort of processing is the classification
itself. Today a router looks at the destination address and
selects a route. The destination address is not sufficient to
select the class of service a packet must receive; more
information is needed.
スケジューリングと低下の上の議論は、パケットが指定された方法で扱われるべきであるパケットの何らかの流れか系列に分類されたと推定しました。 この種類の処理への準備段階は分類自体です。 今日、ルータは、送付先アドレスを見て、ルートを選択します。 送付先アドレスがパケットが受けなければならないサービスのクラスを選択できないくらいの。 詳しい情報が必要です。
One approach would be to abandon the IP datagram model for a
virtual circuit model, in which a circuit is set up with
specific service attributes, and the packet carries a circuit
identifier. This is the approach of ATM as well as protocols
such as ST-II [ST2-90]. Another model, less hostile to IP, is
to allow the classifier to look at more fields in the packet,
such as the source address, the protocol number and the port
fields. Thus, video streams might be recognized by a
1つのアプローチは事実上の回路モデルのためにIPデータグラムモデルをやめるだろうことです、そして、パケットはサーキット識別子を運びます。(そこでは、サーキットが特定のサービス属性でセットアップされます)。 これはST-II[ST2-90]などのプロトコルと同様にATMのアプローチです。 それほどIPに敵軍でない別のモデルはクラシファイアにパケットの、より多くの分野を見させることになっています、ソースアドレスや、プロトコル番号やポート分野などのように。 したがって、ビデオストリームはaによって認識されるかもしれません。
Braden, Clark & Shenker [Page 21] RFC 1633 Integrated Services Architecture June 1994
ブレーデン、クラーク、およびサービス構造1994年6月に統合しているShenker[21ページ]RFC1633
particular well-known port field in the UDP header, or a
particular flow might be recognized by looking at both the
source and destination port numbers. It would be possible to
look even deeper into the packets, for example testing a field
in the application layer to select a subset of a
hierarchically-encoded video stream.
特定のウェルノウンポートが中でUDPヘッダーをさばくか、または特定の流れは、ソースと目的地ポートナンバーの両方を見ることによって、認識されるかもしれません。 パケットをさらに深く調べるのは可能でしょう、例えば、階層的でコード化されたビデオストリームの部分集合を選択するために応用層の中で分野をテストして。
The classifier implementation issues are complexity and
processing overhead. Current experience suggests that careful
implementation of efficient algorithms can lead to efficient
classification of IP packets. This result is very important,
since it allows us to add QoS support to existing applications,
such as Telnet, which are based on existing IP headers.
クラシファイア導入問題は、複雑さと処理オーバヘッドです。 現在の経験は、効率的なアルゴリズムの慎重な実現がIPパケットの効率的な分類につながることができるのを示します。 この結果は非常に重要です、私たちが、それでQoSが存在するのにアプリケーションを支持すると言い足すことができるので、Telnetなどのように。(Telnetは既存のIPヘッダーに基づいています)。
One approach to reducing the overhead of classification would
be to provide a "flow-id" field in the Internet-layer packet
header. This flow-id would be a handle that could be cached
and used to short-cut classification of the packet. There are
a number of variations of this concept, and engineering is
required to choose the best design.
分類のオーバーヘッドを下げることへの1つのアプローチはインターネット層のパケットのヘッダーの「流れイド」野原を供給するだろうことです。 この流れイドはパケットのショートカット分類にキャッシュして、使用できたハンドルでしょう。 この概念の多くの変化があります、そして、工学が、最も良いデザインを選ぶのに必要です。
4.1.4 Admission Control
4.1.4 入場コントロール
As we stated in the introduction, real-time service depends on
setting up state in the router and making commitments to
certain classes of packets. In order to insure that these
commitments can be met, it is necessary that resources be
explicitly requested, so that the request can be refused if the
resources are not available. The decision about resource
availability is called admission control.
私たちが序論に述べたように、リアルタイムのサービスはルータで状態を設立して、あるクラスのパケットに関する公約をするのによります。 これらの委任を満たすことができるのを保障するために、リソースが明らかに要求されているのが必要です、リソースが利用可能でないなら要求を拒否できるように。 リソースの有用性に関する決定は入場コントロールと呼ばれます。
Admission control requires that the router understand the
demands that are currently being made on its assets. The
approach traditionally proposed is to remember the service
parameters of past requests, and make a computation based on
the worst-case bounds on each service. A recent proposal,
which is likely to provide better link utilization, is to
program the router to measure the actual usage by existing
packet flows, and to use this measured information as a basis
of admitting new flows [JCSZ92]. This approach is subject to
higher risk of overload, but may prove much more effective in
using bandwidth.
入場コントロールは、ルータが現在資産でされている要求を理解しているのを必要とします。 伝統的に提案されたアプローチは、各サービスのときに過去の要求のサービスパラメタを覚えていて、最悪の場合領域に基づく計算をすることです。 最近の提案(より良いリンク利用を提供しそうである)は既存のパケット流れで実際の用法を測定して、新しい流れ[JCSZ92]を認める基礎としてこの測定情報を使用するようにルータにプログラムすることです。 このアプローチは、オーバーロードの、より高いリスクを受けることがありますが、帯域幅を使用する際にはるかに効果的であると判明するかもしれません。
Note that while the need for admission control is part of the
global service model, the details of the algorithm run in each
router is a local matter. Thus, vendors can compete by
developing and marketing better admission control algorithms,
which lead to higher link loadings with fewer service
入場コントロールの必要性がグローバルなサービスモデルの一部、アルゴリズムの詳細が各ルータに立候補するということですが、地域にかかわる事柄である注意。 したがって、業者は、より良い入場コントロールアルゴリズムを開発して、売り出すことによって、競争できます。(アルゴリズムは、より少ないサービスによる、より高いリンク荷重につながります)。
Braden, Clark & Shenker [Page 22] RFC 1633 Integrated Services Architecture June 1994
ブレーデン、クラーク、およびサービス構造1994年6月に統合しているShenker[22ページ]RFC1633
overloads.
積みすぎます。
4.2 Applying the Mechanisms
4.2 メカニズムを適用すること。
The various tools described above can be combined to support the
services which were discussed in section 3.
セクション3で議論したサービスを支持するために上で説明された様々なツールは結合できます。
o Guaranteed delay bounds
o 保証された遅れ領域
A theoretical result by Parekh [Parekh92] shows that if the
router implements a WFQ scheduling discipline, and if the
nature of the traffic source can be characterized (e.g. if it
fits within some bound such as a token bucket) then there
will be an absolute upper bound on the network delay of the
traffic in question. This simple and very powerful result
applies not just to one switch, but to general networks of
routers. The result is a constructive one; that is, Parekh
displays a source behavior which leads to the bound, and then
shows that this behavior is the worst possible. This means
that the bound he computes is the best there can be, under
these assumptions.
Parekh[Parekh92]による理論上の結果は、ルータがWFQスケジューリング規律を実行して、交通源の本質を特徴付けることができると(例えば、象徴バケツのように制限されたいくつか中で合うなら)絶対上限が問題の交通のネットワーク遅延にあるのを示します。 この簡単で非常に強力な結果は1個のスイッチだけではなく、ルータの一般的なネットワークに適用されます。 結果は建設的なものです。 すなわち、Parekhは、バウンドにつながるソースの振舞いを見せて、次に、この振舞いが可能な最悪であることを示します。 これは、彼が計算する中でバウンドがこれらの仮定で最も良い場合があることを意味します。
o Link sharing
o リンク共有
The same WFQ scheme can provide controlled link sharing. The
service objective here is not to bound delay, but to limit
overload shares on a link, while allowing any mix of traffic
to proceed if there is spare capacity. This use of WFQ is
available in commercial routers today, and is used to
segregate traffic into classes based on such things as
protocol type or application. For example, one can allocate
separate shares to TCP, IPX and SNA, and one can assure that
network control traffic gets a guaranteed share of the link.
同じWFQ計画は制御リンク共有を提供できます。 設備余力があれば交通のどんなミックスも続くのを許容している間、リンクの上に制限された遅れではなく、限界オーバーロードシェアにはここのサービス目的があります。 WFQのこの使用は、今日、商業ルータで利用可能であり、交通をタイプかアプリケーションについて議定書の中で述べるようなものに基づくクラスに分けるのに使用されます。 例えば、1つはTCP、IPX、およびSNAに別々のシェアを割り当てることができます、そして、人はネットワーク制御交通がリンクの保証株を得ることを保証できます。
o Predictive real-time service
o 予言のリアルタイムのサービス
This service is actually more subtle than guaranteed service.
Its objective is to give a delay bound which is, on the one
hand, as low as possible, and on the other hand, stable
enough that the receiver can estimate it. The WFQ mechanism
leads to a guaranteed bound, but not necessarily a low bound.
In fact, mixing traffic into one queue, rather than
separating it as in WFQ, leads to lower bounds, so long as
the mixed traffic is generally similar (e.g., mixing traffic
from multiple video coders makes sense, mixing video and FTP
does not).
このサービスは実際にサービスが保証されるより微妙です。 そして、目的が一方では、できるだけ低い遅れバウンドを与えることである、他方では、受信機がそれを見積もることができるくらい安定しています。 WFQメカニズムは必ず低いバウンドではなく、保証されたバウンドにつながります。 事実上、1つの待ち行列に交通を混合するのはWFQのようにそれを切り離すよりむしろ下界に通じます、一般に、複雑な交通が同様である(例えば、複数のビデオ符号化器から交通を混合するのが理解できます、ビデオを混ぜてFTPはそうしません)限り。
Braden, Clark & Shenker [Page 23] RFC 1633 Integrated Services Architecture June 1994
ブレーデン、クラーク、およびサービス構造1994年6月に統合しているShenker[23ページ]RFC1633
This suggests that we need a two-tier mechanism, in which the
first tier separates traffic which has different service
objectives, and the second tier schedules traffic within each
first tier class in order to meet its service objective.
これは、私たちが2層のメカニズムを必要とするのを示します。(そこでは、最初の層が、サービス目的を満たすためにそれぞれの最初の層のクラスの中で異なったサービス目的を持っている交通、および2番目の層のスケジュール交通を切り離します)。
4.3 An example: The CSZ scheme
4.3 例: CSZ計画
As a proof of concept, a code package has been implemented which
realizes the services discussed above. It actually uses a number
of the basic tools, combined in a way specific to the service
needs. We describe in general terms how it works, to suggest how
services can be realized. We stress that there are other ways of
building a router to meet the same service needs, and there are in
fact other implementations being used today.
概念の証拠として、コードパッケージは実行されました(上で議論したサービスがわかります)。 それは実際に多くのサービスの必要性に特定の方法で結合された基本的なツールを使用します。 私たちはそれがどうしたらサービスを実現できるかを示すためにあいまいな言葉でどう働いているかを説明します。 私たちは、同じサービス需要を満たすルータを築き上げる他の方法があると強調します、そして、事実上、今日使用される他の実現があります。
At the top level, the CSZ code uses WFQ as an isolation mechanism
to separate guaranteed flows from each other, as well as from the
rest of the traffic. Guaranteed service gets the highest priority
when and only when it needs the access to meets its deadline. WFQ
provides a separate guarantee for each and every guaranteed flow.
トップレベルでは、切り離す隔離機構が互いからの流れを保証したので、CSZコードはWFQを使用します、よく交通の残りのように。 保証されたサービスはいつを最優先に得るか、そして、それがいつまでアクセスを必要とするだけであるかは締め切りを守ります。 WFQはありとあらゆる保証された流れのための別々の保証を提供します。
Predictive service and best effort service are separated by
priority. Within the predictive service class, a further priority
is used to provide sub-classes with different delay bounds.
Inside each predictive sub-class, simple FIFO queueing is used to
mix the traffic, which seems to produce good overall delay
behavior. This works because the top-tier algorithm has separated
out the best effort traffic such as FTP.
予言のサービスとベストエフォート型サービスは優先的に切り離されます。 予言のサービスのクラスの中では、さらなる優先は、異なった遅れ領域をサブのクラスに提供するのに使用されます。 中では、それぞれの予言のサブクラスの、そして、簡単な先入れ先出し法待ち行列が、交通を混ぜるのに使用されます。(交通は良い総合的な遅れの振舞いを起こすように思えます)。 最高層のアルゴリズムがFTPなどのベストエフォート型交通を分離したので、これは働いています。
Within the best-effort class, WFQ is used to provide link sharing.
Since there is a possible requirement for nested shares, this WFQ
code can be used recursively. There are thus two different uses
of WFQ in this code, one to segregate the guaranteed classes, and
one to segregate the link shares. They are similar, but differ in
detail.
ベストエフォート型クラスの中では、WFQは、リンク共有を提供するのに使用されます。 入れ子にされたシェアのための可能な要件があるので、このWFQコードを再帰的に使用できます。 その結果、リンク株を隔離するために、WFQの2つの異なった用途がこのコード、保証されたクラスを隔離する1、および1にあります。 それらは同様ですが、詳細に異なってください。
Within each link share of the best effort class, priority is used
to permit more time-sensitive elastic traffic to precede other
elastic traffic, e.g., to allow interactive traffic to precede
asynchronous bulk transfers.
ベストエフォート型クラスのそれぞれのリンク株の中では、優先権は、より時間敏感な弾性の交通が、他の弾性の交通に先行して、例えば対話的な通信が非同期なバルク転送に先行するのを許容することを許可するのに使用されます。
The CSZ code thus uses both WFQ and priority in an alternating
manner to build a mechanism to support a range of rather
sophisticated service offerings. This discussion is very brief,
and does not touch on a number of significant issues, such as how
the CSZ code fits real time traffic into the link sharing
objectives. But the basic building blocks are very simple, and
その結果、CSZコードは、さまざまなかなり高性能のサービス提供を支えるためにメカニズムを造るのに交互の方法でWFQと優先権の両方を使用します。 この議論は、非常に簡潔であり、多くの重要な問題に触れません、CSZコードがどう目的を共有するリンクにリアルタイムの交通に合うのなどように。 そしてしかし、基本的なブロックが非常に簡単である。
Braden, Clark & Shenker [Page 24] RFC 1633 Integrated Services Architecture June 1994
ブレーデン、クラーク、およびサービス構造1994年6月に統合しているShenker[24ページ]RFC1633
very powerful. In particular, while priority has been proposed as
a key to real-time services, WFQ may be the more general and
powerful of the two schemes. It, rather than priority, supports
guaranteed service and link sharing.
非常に強力です。 優先権がリアルタイムのサービスのキーとして提案された間、WFQは2つの計画で特に、より一般的であって、強力であるかもしれません。 それは優先権よりむしろ保証されたサービスとリンク共有を支持します。
5. Reservation Setup Protocol
5. 予約セットアッププロトコル
There are a number of requirements to be met by the design of a reservation setuop protocol. It should be fundamentally designed for a multicast environment, and it must accommodate heterogeneous service needs. It must give flexible control over the manner in which reservations can be shared along branches of the multicast delivery trees. It should be designed around the elementary action of adding one sender and/or receiver to an existing set, or deleting one. It must be robust and scale well to large multicast groups. Finally, it must provide for advance reservation of resources, and for the preemption that this implies. The reservation setup protocol RSVP has been designed to meet these requirements [RSVP93a, RSVP93b]. This section gives an overview of the design of RSVP.
予約setuopプロトコルのデザインによって会われるという多くの要件があります。 それはマルチキャスト環境のために基本的に設計されるべきです、そして、異種のサービスの必要性を収容しなければなりません。 それはマルチキャスト配送木の枝に沿って予約を共有できる方法のフレキシブルな支配力を与えなければなりません。 それは1台の送付者、そして/または、受信機を既存のセットに追加するか、または1つを削除する基本動作の周りで設計されるべきです。 それは、大きいマルチキャストグループによく強健であり、比例しなければなりません。 最終的に、それはリソースの事前の予約、およびこれが含意する先取りに提供されなければなりません。 予約セットアッププロトコルRSVPは、これらの必要条件[RSVP93a、RSVP93b]を満たすように設計されています。 このセクションはRSVPのデザインの概観を与えます。
5.1 RSVP Overview
5.1 RSVP概観
Figure shows multi-source, multi-destination data delivery for a
particular shared, distributed application. The arrows indicate
data flow from senders S1 and S2 to receivers R1, R2, and R3, and
the cloud represents the distribution mesh created by the
multicast routing protocol. Multicasting distribution replicates
each data packet from a sender Si, for delivery to every receiver
Rj. We treat uncast delivery from S1 to R1 as a special case, and
we call this multicast distribution mesh a session. A session is
defined by the common IP (multicast) destination address of the
receiver(s).
図は特定の共有されて、分配されたアプリケーションのためのマルチソースの、そして、マルチ目的地のデータ配送を示しています。 矢は受信機のR1、R2、および送付者のS1とS2からR3までデータフローを示します、そして、雲はマルチキャストルーティング・プロトコルによって作成された分配メッシュを表します。 マルチキャスティング分配は配送のための送付者Siからあらゆる受信機Rjまで各データ・パケットを模写します。 私たちは特殊なものとしてS1からR1までの「非-キャスト」配送を扱います、そして、このマルチキャスト分配メッシュをセッションと呼びます。 セッションは受信機の一般的なIP(マルチキャスト)送付先アドレスによって定義されます。
Senders Receivers
_____________________
( ) ===> R1
S1 ===> ( Multicast )
( ) ===> R2
( distribution )
S2 ===> ( )
( ) ===> R3
(_____________________)
送付者受信機_____________________ ( ) ===>R1 S1===>(マルチキャスト)( )===>R2(分配)S2===>( )( )===>R3(_____________________)
Figure 2: Multicast Distribution Session
図2: マルチキャスト分配セッション
Braden, Clark & Shenker [Page 25] RFC 1633 Integrated Services Architecture June 1994
ブレーデン、クラーク、およびサービス構造1994年6月に統合しているShenker[25ページ]RFC1633
5.1.1 Flowspecs and Filter Specs
5.1.1 Flowspecsとフィルタ眼鏡
In general, an RSVP reservation request specifies the amount of
resources to be reserved for all, or some subset of, the
packets in a particular session. The resource quantity is
specified by a flowspec, while the packet subset to receive
those resources is specified by a filter spec. Assuming
admission control succeeds, the flowspec will be used to
parametrize a resource class in the packet scheduler, and the
filter spec will be instantiated in the packet classifier to
map the appropriate packets into this class. The subset of the
classifier state that selects a particular class is referred to
in RSVP documentation as a (packet) "filter".
一般に、RSVP予約の要請がすべて、または何らかの部分集合のために予約されるべきリソースの量を指定する、特定のセッションにおけるパケット。 リソース量はflowspecによって指定されます、それらのリソースを受け取るパケット部分集合がフィルタ仕様によって指定されますが。 入場がコントロールであると仮定するのが成功します、そして、flowspecはパケットスケジューラでリソースのクラスをparametrizeするのに使用されるでしょう、そして、フィルタ仕様は、適切なパケットをこのクラスに写像するためにパケットクラシファイアに例示されるでしょう。 特定のクラスを選択するクラシファイア州の部分集合はRSVPドキュメンテーションに(パケット)「フィルタ」と呼ばれます。
The RSVP protocol mechanisms provide a very general facility
for creating and maintaining distributed reservation state
across the mesh of multicast delivery paths. These mechanisms
treat flowspecs and filter specs as mostly opaque binary data,
handing them to the local traffic control machinery for
interpretation. Of course, the service model presented to an
application must specify how to encode flowspecs and filter
specs.
RSVPプロトコルメカニズムはマルチキャスト配送経路のメッシュの向こう側に分散予約状態を創設して、維持するのに非常に一般的な施設を提供します。 これらのメカニズムはほとんど不明瞭な2進のデータとしてflowspecsとフィルタ眼鏡を扱います、解釈のための地方のトラフィックコントロール機械にそれらを手渡して。 もちろん、アプリケーションに提示されたサービスモデルはflowspecsとフィルタ眼鏡をコード化する方法を指定しなければなりません。
5.1.2 Reservation Styles
5.1.2 予約様式
RSVP offers several different reservation "styles", which
determine the manner in which the resource requirements of
multiple receivers are aggregated in the routers. These styles
allow the reserved resources to more efficiently meet
application requirements. Currently there are three
reservation styles, "wildcard", "fixed-filter", and " dynamic-
filter". A wildcard reservation uses a filter spec that is not
source-specific, so all packets destined for the associated
destination (session) may use a common pool of reserved
resources. This allows a single resource allocation to be made
across all distribution paths for the group. The wildcard
reservation style is useful in support of an audio conference,
where at most a small number of sources are active
simultaneously and may share the resource allocation.
RSVPは数個の異なった予約「スタイル」を提供します。(それは、複数の受信機のリソース要件がルータで集められる方法を決定します)。 これらのスタイルで、予約されたリソースは、より効率的にアプリケーション要件を満たすことができます。 現在、3つの予約スタイル、「ワイルドカード」、「固定フィルタ」、および「ダイナミックなフィルタ」があります。 ワイルドカードの予約がソース特有でないフィルタ仕様を使用するので、関連目的地(セッション)に運命づけられたすべてのパケットが予約されたリソースの一般的なプールを使用するかもしれません。 これで、ただ一つの資源配分はグループのためにすべての分配経路の向こう側に利かせます。 ワイルドカード予約スタイルはオーディオ会議を支持して役に立ちます。そこで、高々少ない数のソースが、同時に、アクティブであり、資源配分を共有するかもしれません。
The other two styles use filter specs that select particular
sources. A receiver may desire to receive from a fixed set of
sources, or instead it may desire the network to switch between
different source, by changing its filter spec(s) dymamically.
A fixed-filter style reservation cannot be changed during its
lifetime without re-invoking admission control. Dynamic-filter
reservations do allow a receiver to modify its choice of
source(s) over time without additional admission control;
他の2つのスタイルが特定のソースを選ぶフィルタ仕様を使用します。 受信機が、固定セットの源から受信することを望むかもしれませんか、または代わりに、ネットワークが異なったソースを切り換えることを望むかもしれません、フィルタ仕様dymamicallyを変えることによって。 入場コントロールを再呼び出さないで、生涯固定フィルタスタイルの予約を変えることができません。 ダイナミックなフィルタの予約で、受信機は時間がたつにつれて、追加入場コントロールなしでソースの選択を変更できます。
Braden, Clark & Shenker [Page 26] RFC 1633 Integrated Services Architecture June 1994
ブレーデン、クラーク、およびサービス構造1994年6月に統合しているShenker[26ページ]RFC1633
however, this requires that sufficient resources be allocated
to handle the worst case when all downstream receivers take
input from different sources.
しかしながら、これは、十分なリソースがすべての川下の受信機がさまざまな原因から入力を取るとき、最悪の場合を扱うために割り当てられるのを必要とします。
5.1.3 Receiver Initiation
5.1.3 受信機開始
An important design question is whether senders or receivers
should have responsibility for initiating reservations. A
sender knows the qualities of the traffic stream it can send,
while a receiver knows what it wants to (or can) receive.
Perhaps the most obvious choice is to let the sender initiate
the reservation. However, this scales poorly for large,
dynamic multicast delivery trees and for heterogeneous
receivers.
重要なデザイン質問は送付者か受信機には予約を開始することへの責任があるはずであるかどうかということです。 送付者は、受信機が、それが(or can)に何が欲しいかを知っている間にそれが送ることができる交通の流れの品質が受信されるのを知っています。 恐らく最も明白な選択は送付者に予約を開始させることです。 しかしながら、これは大きくて、ダイナミックなマルチキャスト配送木と異種の受信機のために不十分に比例します。
Both of these scaling problems are solved by making the
receiver responsible for initiating a reservation. Receiver
initiation handles heterogeneous receivers easily; each
receiver simply asks for a reservation appropriate to itself,
and any differences among reservations from different receivers
are resolved ("merged") within the network by RSVP. Receiver
initiation is also consisent with IP multicast, in which a
multicast group is created implicitly by receivers joining it.
これらのスケーリング問題の両方が、受信機を予約を開始するのに責任があるようにすることによって、解決されています。 受信機開始は容易に異種の受信機を扱います。 各受信機は単にそれ自体に適切な予約を求めます、そして、異なった受信機からの予約の中のどんな違いもネットワークの中でRSVPによって決議されています(「合併されます」)。 また、受信機開始はIPマルチキャストがあるconsisentです。(マルチキャストグループはそれを接合する受信機によってそれでそれとなく創設されます)。
Although receiver-initiated reservation is the natural choice
for multicast sessions, the justification for receiver
initiateion may appear weaker for unicast sessions, where the
sender may be the logical session initiator. However, we
expect that every realtime application will have its higher-
level signalling and control protocol, and this protocol can be
used to signal the receiver to initiate a reservation (and
perhaps indicate the flowspec to be used). For simplicity and
economy, a setup protocol should support only one direction of
initiation, and, and receiver initiation appears to us to be
the clear winner.
受信機で開始している予約はマルチキャストセッションのための自然な選択ですが、受信機initiateionのための正当化はユニキャストセッションに関して、より弱く見えるかもしれません。そこでは、送付者が論理的なセッション創始者であるかもしれません。 しかしながら、私たちは、あらゆるリアルタイムでアプリケーションにはそのより高い平らな合図と制御プロトコルがあると予想します、そして、予約を開始するように受信機に合図するのにこのプロトコルは使用できます(恐らくflowspecを示して、使用されてください)。 簡単さと経済のために、そして、セットアッププロトコルは開始の一方向だけを支持するべきです、そして、受信機開始は完勝者であることを私たちにとって現れさせます。
RSVP uses receiver-initiation of rservations [RSVP93b]. A
receiver is assumed to learn the senders' offered flowspecs by
a higher-level mechanism ("out of band"), it then generates its
own desired flowspec and propagates it towards the senders,
making reservations in each router along the way.
RSVPはrservations[RSVP93b]の受信機開始を使用します。 受信機は、よりハイレベルのメカニズム(「バンド」からの)で送付者がflowspecsを提供して、次に、それ自身の必要なflowspecを発生させることを学ぶと思われて、送付者に向かってそれを伝播します、道に沿って各ルータにおける予約をして。
5.1.4 Soft State
5.1.4 軟性国家
There are two different possible styles for reservation setup
protocols, the "hard state" (HS) approach (also called
"connection-oriented"), and the "soft state" (SS) approach
(also called "connectionless"). In both approaches, multicast
予約セットアッププロトコル、「固い状態」(HS)アプローチ(また、「接続指向である」と呼ばれる)、および「軟性国家」(SS)アプローチ(また、「コネクションレスである」と呼ばれる)のための2つの異なった可能なスタイルがあります。 両方のアプローチ、マルチキャストで
Braden, Clark & Shenker [Page 27] RFC 1633 Integrated Services Architecture June 1994
ブレーデン、クラーク、およびサービス構造1994年6月に統合しているShenker[27ページ]RFC1633
distribution is performed using flow-specific state in each
router along the path. Under the HS approach, this state is
created and deleted in a fully deterministic manner by
cooperation among the routers. Once a host requests a session,
the "network" takes responsibility for creating and later
destroying the necessary state. ST-II is an example of the HS
approach [ST2-90]. Since management of HS session state is
completely deterministic, the HS setup protocol must be
reliable, with acknowledgments and retransmissions. In order
to achieve deterministic cleanup of state after a failure,
there must be some mechanism to detect failures, i.e., an
"up/down" protocol. The router upstream (towards the source)
from a failure takes responsibility for rebuilding the
necessary state on the router(s) along an alternate route.
分配は、経路に沿った各ルータに流れ特有の状態を使用することで実行されます。 HSアプローチで、この状態は、ルータの中で協力によって完全に決定論的な方法で創設されて、削除されます。 ホストがいったんセッションを要求すると、「ネットワーク」は必要な状態を創設して、後で破壊することへの責任を取ります。 ST-IIはHSアプローチ[ST2-90]に関する例です。 HSセッション状態の管理が完全に決定論的であるので、HSセットアッププロトコルは承認と「再-トランスミッション」で信頼できるに違いありません。 失敗の後に状態の決定論的なクリーンアップを達成するために、失敗を検出する何らかのメカニズムがあるに違いありません、すなわち、「/に、ダウンしてください」というプロトコル。 失敗からのルータ上流(ソースに向かった)は代替経路に沿って必要な状態をルータに再建するのに責任を取ります。
RSVP takes the SS approach, which regards the reservation state
as cached information that is installed and periodically
refreshed by the end hosts. Unused state is timed out by the
routers. If the route changes, the refresh messages
automatically install the necessary state along the new route.
The SS approach was chosen to obtain the simplicity and
robustness that have been demonstrated by connectionless
protocols such as IP [Clark88].
RSVPはSSアプローチを取って、どのあいさつがインストールされていて、定期的に終わりのホストによってリフレッシュされるキャッシュされた情報として予約状態であるか。 未使用の状態はルータによる外で調節されています。 自動的にメッセージをリフレッシュしてください。ルートが変化するならインストールする、新しいルートに沿って必要な状態をインストールしてください。 SSアプローチは、IPなどのコネクションレスプロトコルによって示された簡単さと丈夫さを得るために選ばれました[Clark88]。
5.2 Routing and Reservations
5.2 ルート設定と予約
There is a fundamental interaction between resource reservation
set up and routing, since reservation requires the installation of
flow state along the route of data packets. If and when a route
changes, there must be some mechanism to set up a reservation
along the new route.
セットアップされた資源予約とルーティングとの基本的な相互作用があります、予約がデータ・パケットのルートに沿って流れ状態のインストールを必要とするので。 ルートが変化するなら、新しいルートに沿って予約に設定する何らかのメカニズムがあるに違いありません。
Some have suggested that reservation setup necessarily requires
route set up, i.e., the imposition of a virtual-circuit internet
layer. However, our goal is to simply extend the Internet
architecture, not replace it. The fundamental connectionless
internet layer [Clark88] has been highly successful, and we wish
to retain it as an architectural foundation. We propose instead
to modify somewhat the pure datagram forwarding mechanism of the
present Internet to accomodate "IS".
或るものは、予約セットアップが必ずセットアップされたルート、すなわち、仮想のサーキットインターネット層の賦課を必要とするのを示しました。 しかしながら、私たちの目標はそれを取り替えるのではなく、単にインターネット構造を広げることです。 [Clark88]基本的なコネクションレスなインターネット層は非常にうまくいっています、そして、建築基礎としてそれを保有したいと思います。 私たちは、代わりに現在のインターネットの純粋なデータグラム推進メカニズムを「存在accomodate」にいくらか変更するよう提案します。
Braden, Clark & Shenker [Page 28] RFC 1633 Integrated Services Architecture June 1994
ブレーデン、クラーク、およびサービス構造1994年6月に統合しているShenker[28ページ]RFC1633
There are four routing issues faced by a reservation setup
protocol such as RSVP.
RSVPなどの予約セットアッププロトコルによって直面されていた4ルーティング冊があります。
1. Find a route that supports resource reservation.
1. 資源予約を支持するルートを見つけてください。
This is simply "type-of-service" routing, a facility that is
already available in some modern routing protocols.
これは単に「サービスのタイプ」ルーティング、いくつかの現代のルーティング・プロトコルで既に利用可能な施設です。
2. Find a route that has sufficient unreserved capacity for a
new flow.
2. 新しい流れに関して十分な無遠慮な容量を持っているルートを見つけてください。
Early experiments on the ARPANET showed that it is difficult
to do load-dependent dynamic routing on a packet-by-packet
basis without instability problems. However, instability
should not be a problem if load-dependent routing is
performed only at reservation setup time.
アルパネットの早めの実験は、パケットごとのベースで不安定性問題なしで負荷依存するダイナミックルーティングをするのが難しいのを示しました。しかしながら、負荷依存するルーティングが単に予約準備時間に実行されるなら、不安定性は問題であるべきではありません。
Two different approaches might be taken to finding a route
with enough capacity. One could modify the routing
protocol(s) and interface them to the traffic control
mechanism, so the route computation can consider the average
recent load. Alternatively, the routing protocol could be
(re-)designed to provide multiple alternative routes, and
reservation setup could be attempted along each in turn.
十分な容量でルートを見つけるのに2つの異なるアプローチを取るかもしれません。 1つがルーティング・プロトコルを変更して、トラフィックコントロールメカニズムにそれらを連結するかもしれないので、経路計算は平均した最近の負荷を考えることができます。 あるいはまた、ルーティング・プロトコルがそうであるかもしれない、(再、)、設計されていて、複数の代替のルート、および予約セットアップを提供するために、ずっとそれぞれ順番に試みることができてください、そうした。
3. Adapt to a route failure
3. ルートの故障に順応してください。
When some node or link fails, adaptive routing finds an
alternate path. The periodic refresh messages of RSVP will
automatically request a reservation along the new path. Of
course, this reservation may fail because there is
insufficienct available capacity on the new path. This is a
problem of provisioning and network engineering, which cannot
be solved by the routing or setup protocols.
あるノードかリンクが失敗すると、最適経路指定は代替パスを見つけます。 周期的はRSVPに関するメッセージをリフレッシュします。自動的に、新しい経路に沿って予約を要求するでしょう。 もちろん、insufficienctの有効な容量が新しい経路にあるので、この予約は失敗するかもしれません。 これは食糧を供給するのとネットワーク工学の問題です。(ルーティングかセットアッププロトコルはそれを解決できません)。
There is a problem of timeliness of establishing reservation
state on the new path. The end-to-end robustness mechanism
of refreshes is limited in frequency by overhead, which may
cause a gap in realtime service when an old route breaks and
a new one is chosen. It should be possible to engineer RSVP
to sypplement the global refresh mechanism with a local
repair mechanism, using hints about route changes from the
routing mechanism.
予約状態を設置するタイムリーの問題が新しい経路にあります。 終わりから終わりへの丈夫さメカニズム、リフレッシュ、頻度では、オーバーヘッドで、制限されます。(古いルートが壊れて、新しいものが選ばれていると、それは、リアルタイムでサービスにおけるずれを引き起こすかもしれません)。 設計するために、グローバルなsypplementへのRSVPが局部的修繕メカニズムでメカニズムをリフレッシュするのは、可能であるべきです、ルーティングメカニズムからのルート変化に関してヒントを使用して。
4. Adapt to a route change (without failure)
4. ルート変化に順応してください。(失敗のない)
Route changes may occur even without failure in the affected
path. Although RSVP could use the same repair techniques as
ルート変化は影響を受ける経路に失敗がなくても起こるかもしれません。 RSVPは同じ修理のテクニックを使用できました。
Braden, Clark & Shenker [Page 29] RFC 1633 Integrated Services Architecture June 1994
ブレーデン、クラーク、およびサービス構造1994年6月に統合しているShenker[29ページ]RFC1633
those described in (3), this case raises a problem with the
robustness of the QoS guarantees. If it should happen that
admission control fails on the new route, the user will see
service degradation unnecessarily and capriciously, since the
orginal route is still functional.
(3)で説明されたもの、本件はQoS保証の丈夫さで問題を提起します。 入場コントロールが新しいルートで失敗するのが起こると、ユーザは不必要に気紛れにサービス退行を見るでしょう、orginalルートがまだ機能的であるので。
To avoid this problem, a mechanism called "route pinning" has
been suggested. This would modify the routing protocol
implementation and the interface to the classifier, so that
routes associated with resource reservations would be
"pinned". The routing prootocol would not change a pinned
route if it was still viable.
この問題を避けるために、「ルートのピンで止めること」と呼ばれるメカニズムは示されました。 これはルーティング・プロトコル実現とインタフェースをクラシファイアに変更するでしょう、資源予約に関連しているルートが「ピンで止められる」ように。 それがまだ実行可能であるなら、ルーティングprootocolはピンで止められたルートを変えないでしょうに。
It may eventually be possible to fold together the routing and
reservation setup problems, but we do not yet understand enough to
do that. Furthermore, the reservation protocol needs to coexist
with a number of different routing protocols in use in the
Internet. Therefore, RSVP is currently designed to work with any
current-generation routing protocol without modification. This is
a short-term compromise, which may result in an occasional failure
to create the best, or even any, real-time session, or an
occasional service degradation due to a route change. We expect
that future generations of routing protocols will remove this
compromise, by including hooks and mechanisms that, in conjunction
with RSVP, will solve the problems (1) through (4) just listed.
They will support route pinning, notification of RSVP to trigger
local repair, and selection of routes with "IS" support and
adequate capacity.
ルーティングと予約セットアップ問題を一緒に折り重ねるのが結局、可能であるかもしれませんが、私たちはまだそれができるくらいには分かっていません。 その上、予約プロトコルは、インターネットに使用中の多くの異なったルーティング・プロトコルと共存する必要があります。 したがって、RSVPは、現在、どんな現代のルーティング・プロトコルでも変更なしで働くように設計されます。 ルート変化のために、これは、短期的な妥協、いずれ、リアルタイムのセッション、または不定期航路退行になりさえします。(それは、最もよく作成する時々の失敗をもたらすかもしれません)。 私たちは、次世代のルーティング・プロトコルがこの妥協を取り除くと予想します、ただ記載された(4)を通してRSVPに関連して問題(1)を解決するフックとメカニズムを含んでいることによって。 彼らは、「存在」サポートと適切な容量で局部的修繕、およびルートの品揃えの引き金となるようにルートのピンで止めるRSVPの通知を支持するでしょう。
The last routing-related issue is provided by mobile hosts. Our
conjecture is that mobility is not essentially different from
other route changes, so that the mechanism suggested in (3) and
(4) will suffice. More study and experimentation is needed to
prove or disprove this conjecture.
最後のルーティング関連の問題はモバイルホストによって提供されます。 私たちの推測は移動性が他のルート変化と本質的には異なっていないということです、(3)と(4)に示されたメカニズムが十分であるように。 より多くの研究と実験が、この推測に立証するか、または論駁するのに必要です。
6. ACKNOWLEDGMENTS
6. 承認
Many Internet researchers have contributed to the work described in this memo. We want to especially acknowledge, Steve Casner, Steve Deering, Deborah Estrin, Sally Floyd, Shai Herzog, Van Jacobson, Sugih Jamin, Craig Partridge, John Wroclawski, and Lixia Zhang. This approach to Internet integrated services was initially discussed and organized in the End-to-End Research Group of the Internet Research Taskforce, and we are grateful to all members of that group for their interesting (and sometimes heated) discussions.
多くのインターネット情報検索専門家がこのメモで説明された仕事に貢献しました。 特に承認したいと思う、スティーブCasner、スティーブ・デアリング、デボラEstrin、サリー・フロイド、Shaiハーツォグ、ヴァン・ジェーコブソン、Sugihジャマン、クレイグPartridge、ジョンWroclawski、およびLixiaチャン。 インターネット統合しているサービスへのこのアプローチは、Endから終わりへのインターネットResearch TaskforceのResearch Groupで初めは、議論して、組織化されました、そして、私たちは彼らのおもしろくて(時々加熱されています)の議論にそのグループのすべてのメンバーに感謝しています。
Braden, Clark & Shenker [Page 30] RFC 1633 Integrated Services Architecture June 1994
ブレーデン、クラーク、およびサービス構造1994年6月に統合しているShenker[30ページ]RFC1633
REFERENCES
参照
[CerfKahn74] Cerf, V., and R. Kahn, "A Protocol for Packet Network
Intercommunication", IEEE Trans on Comm., Vol. Com-22, No. 5, May
1974.
[CerfKahn74]のサーフ、V.、およびR.カーン、「Aはパケット網相互通信のために議定書を作ります」、IEEE。移-オンなComm、Vol.Com-22、No.5(1974年5月)
[Clark88] Clark, D., "The Design Philosophy of the DARPA Internet
Protocols", ACM SIGCOMM '88, August 1988.
[Clark88] 1988年8月のクラーク、D.、「DARPAインターネットプロトコルの設計理念」ACM SIGCOMM88年。
[CSZ92] Clark, D., Shenker, S., and L. Zhang, "Supporting Real-Time
Applications in an Integrated Services Packet Network: Architecture
and Mechanisms", Proc. SIGCOMM '92, Baltimore, MD, August 1992.
[CSZ92] クラーク、D.、Shenker、S.、およびL.チャン、「統合サービスパケット網におけるリアルタイムのアプリケーションをサポートします:」 「アーキテクチャとメカニズム」、Proc。 ボルチモア(MD)1992年8月のSIGCOMM92年。
[DKS89] Demers, A., Keshav, S., and S. Shenker. "Analysis and
Simulation of a Fair Queueing Algorithm", Journal of
Internetworking: Research and Experience, 1, pp. 3-26, 1990. Also
in Proc. ACM SIGCOMM '89, pp 3-12.
[DKS89] Demers、A.、Keshav、S.、およびS.Shenker。 「公正な待ち行列アルゴリズムの分析とシミュレーション」、インターネットワーキングのジャーナル: 研究とExperience、1、ページ 3-26, 1990. Procでも。 ACM SIGCOMM89年、pp3-12。
[SCZ93a] Shenker, S., Clark, D., and L. Zhang, "A Scheduling Service
Model and a Scheduling Architecture for an Integrated Services
Packet Network", submitted to ACM/IEEE Trans. on Networking.
[SCZ93a]Shenker、S.、クラーク、D.、およびL.チャン、「スケジューリングは統合サービスパケット網のためにモデルとスケジューリングアーキテクチャにサービスを提供します」、提出してACM/IEEE Trans Networkingで。
[SCZ93b] Shenker, S., Clark, D., and L. Zhang, "A Service Model for the
Integrated Services Internet", Work in Progress, October 1993.
S.、クラーク、D.、およびL.チャン、「統合サービスインターネットへのサービスモデル」という[SCZ93b]Shenkerは進行中(1993年10月)で働いています。
[Floyd92] Floyd, S., "Issues in Flexible Resource Management for
Datagram Networks", Proceedings of the 3rd Workshop on Very High
Speed Networks, March 1992.
[Floyd92]フロイド(S.)は「データグラムのためにフレキシブルな資源管理でネットワークを発行します」、非常に高い速度ネットワークにおける第3ワークショップの議事、1992年3月。
[Jacobson91] Jacobson, V., "Private Communication", 1991.
[Jacobson91] ジェーコブソン、V.、「私信」、1991。
[JCSZ92] Jamin, S., Shenker, S., Zhang, L., and D. Clark, "An Admission
Control Algorithm for Predictive Real-Time Service", Extended
abstract, in Proc. Third International Workshop on Network and
Operating System Support for Digital Audio and Video, San Diego, CA,
Nov. 1992, pp. 73-91.
Procの[JCSZ92]ジャマン、S.、Shenker、S.、チャン、L.、およびD.クラーク、「予言のリアルタイムのサービスのための入場コントロールアルゴリズム」Extended要約。 Networkの上の第3国際Workshopとデジタル・オーディオとVideo、サンディエゴ(カリフォルニア)1992年11月、ページのためのOperating System Support 73-91.
[Parekh92] Parekh, A., "A Generalized Processor Sharing Approach to
Flow Control in Integrated Services Networks", Technical Report
LIDS-TR-2089, Laboratory for Information and Decision Systems,
Massachusetts Institute of Technology, 1992.
[Parekh92] Parekh、A.、「統合サービスネットワークにおけるフロー制御への一般化されたプロセッサ共有アプローチ」、技術報告書ふた-TR-2089、情報と決定システムのための研究所、マサチューセッツ工科大学、1992。
[Partridge92] Partridge, C., "A Proposed Flow Specification", RFC 1363,
BBN, July 1992.
[Partridge92] ヤマウズラ、C.、「提案された流れ仕様」、RFC1363、BBN、1992年7月。
[RSVP93a] Zhang, L., Deering, S., Estrin, D., Shenker, S., and D.
Zappala, "RSVP: A New Resource ReSerVation Protocol", Accepted for
publication in IEEE Network, 1993.
[RSVP93a] チャン、L.、デアリング、S.、Estrin、D.、Shenker、S.、およびD.Zappala、「RSVP:」 「New Resource ReSerVationプロトコル」、IEEE Network、1993での公表のためのAccepted。
Braden, Clark & Shenker [Page 31] RFC 1633 Integrated Services Architecture June 1994
ブレーデン、クラーク、およびサービスアーキテクチャ1994年6月に統合しているShenker[31ページ]RFC1633
[RSVP93b] Zhang, L., Braden, R., Estrin, D., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) - Version 1 Functional
Specification", Work in Progress, 1993.
[RSVP93b]チャン、L.、ブレーデン、R.、Estrin、D.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、仕事。進歩、1993年に。
[ST2-90] Topolcic, C., "Experimental Internet Stream Protocol: Version
2 (ST-II)", RFC 1190, BBN, October 1990.
[ST2-90] Topolcic、C.、「実験的なインターネットストリームは以下について議定書の中で述べます」。 「バージョン2、(第-、II、)、」、RFC1190、BBN、10月1990日
[Tenet90] Ferrari, D., and D. Verma, "A Scheme for Real-Time Channel
Establishment in Wide-Area Networks", IEEE JSAC, Vol. 8, No. 3, pp
368-379, April 1990.
[Tenet90] フェラーリ、D.、およびD.Verma、「ワイドエリアネットワークへのリアルタイムのチャンネル設立の体系」、IEEE JSAC、Vol.8、No.3、pp368-379(1990年4月)。
Security Considerations
セキュリティ問題
As noted in Section 2.1, the ability to reserve resources will create a requirement for authentication, both of users requesting resource guarantees and of packets that claim to have the right to use those guarantees. These authentication issues are not otherwise addressed in this memo, but are for further study.
セクション2.1に述べられるように、リソースを予約する能力は認証(それらの保証を使用するために権利があると主張するリソース保証を要求するユーザとパケットの両方)のための要件を作成するでしょう。 これらの認証問題は、別の方法でこのメモで扱われませんが、さらなる研究にはあります。
Braden, Clark & Shenker [Page 32] RFC 1633 Integrated Services Architecture June 1994
ブレーデン、クラーク、およびサービスアーキテクチャ1994年6月に統合しているShenker[32ページ]RFC1633
Authors' Addresses
作者のアドレス
Bob Braden USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292
ボブブレーデンUSC情報Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア 90292
Phone: (310) 822-1511 EMail: Braden@ISI.EDU
以下に電話をしてください。 (310) 822-1511 メールしてください: Braden@ISI.EDU
David Clark MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139-1986
技術の正方形のケンブリッジ、デヴィッドクラークMIT Laboratory for Computer Science545MA02139-1986
Phone: (617) 253-6003 EMail: ddc@LCS.MIT.EDU
以下に電話をしてください。 (617) 253-6003 メールしてください: ddc@LCS.MIT.EDU
Scott Shenker Xerox Palo Alto Research Center 3333 Coyote Hill Road Palo Alto, CA 94304
スコットShenkerゼロックスパロアルト研究センター3333コヨーテヒル・Roadパロアルト、カリフォルニア 94304
Phone: (415) 812-4840 EMail: Shenker@PARC.XEROX.COM
以下に電話をしてください。 (415) 812-4840 メールしてください: Shenker@PARC.XEROX.COM
Braden, Clark & Shenker [Page 33]
ブレーデン、クラーク、およびShenker[33ページ]
一覧
スポンサーリンク
