RFC2990 日本語訳
2990 Next Steps for the IP QoS Architecture. G. Huston. November 2000. (Format: TXT=65450 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Huston Request for Comments: 2990 Telstra Category: Informational November 2000
コメントを求めるワーキンググループG.ヒューストン要求をネットワークでつないでください: 2990年のテルストラカテゴリ: 情報の2000年11月
Next Steps for the IP QoS Architecture
IP QoSアーキテクチャのための次のステップ
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
While there has been significant progress in the definition of Quality of Service (QoS) architectures for internet networks, there are a number of aspects of QoS that appear to need further elaboration as they relate to translating a set of tools into a coherent platform for end-to-end service delivery. This document highlights the outstanding architectural issues relating to the deployment and use of QoS mechanisms within internet networks, noting those areas where further standards work may assist with the deployment of QoS internets.
インターネットネットワークのためのService(QoS)アーキテクチャのQualityの定義における重要な進歩がありましたが、終わりから終わりへのサービス配送のための一貫性を持っているプラットホームの中に彼らがツールのセットに翻訳に関連して一層の労作を必要とするように見えるQoSの多くの局面があります。 このドキュメントはインターネットネットワークの中でQoSメカニズムの展開と使用に関連する傑出している構造的な問題を強調します、さらなる標準化作業がQoSインターネットの展開を助けるかもしれないそれらの領域に注意して。
This document is the outcome of a collaborative exercise on the part of the Internet Architecture Board.
このドキュメントはインターネット・アーキテクチャ委員会側の協力的な運動の結果です。
Table of Contents
目次
1. Introduction ........................................... 2
2. State and Stateless QoS ................................ 4
3. Next Steps for QoS Architectures ....................... 6
3.1 QoS-Enabled Applications ........................... 7
3.2 The Service Environment ............................ 9
3.3 QoS Discovery ...................................... 10
3.4 QoS Routing and Resource Management ................ 10
3.5 TCP and QoS ........................................ 11
3.6 Per-Flow States and Per-Packet classifiers ......... 13
3.7 The Service Set .................................... 14
3.8 Measuring Service Delivery ......................... 14
3.9 QoS Accounting ..................................... 15
3.10 QoS Deployment Diversity .......................... 16
3.11 QoS Inter-Domain signaling ........................ 17
1. 序論… 2 2. 状態と状態がないQoS… 4 3. 次に、QoSのために、アーキテクチャは踏まれます… 6 3.1 QoSによって可能にされたアプリケーション… 7 3.2 サービス環境… 9 3.3QoSディスカバリー… 10 3.4のQoSルート設定と資源管理… 10 3.5TCPとQoS… 11 3.6 1流れあたりのStatesとPer-パケットクラシファイア… 13 3.7 サービスはセットしました… 14 3.8 サービス配送を測定します… 14 3.9 QoS会計… 15 3.10 QoS展開の多様性… 16 3.11 QoS Inter-ドメインシグナリング… 17
Huston Informational [Page 1] RFC 2990 Next Steps for QoS Architecture November 2000
QoSアーキテクチャ2000年11月のための次のヒューストンInformational[1ページ]のRFC2990ステップ
3.12 QoS Deployment Logistics .......................... 17
4. The objective of the QoS architecture .................. 18
5. Towards an end-to-end QoS architecture ................. 19
6. Conclusions ............................................ 21
7. Security Considerations ................................ 21
8. References ............................................. 22
9. Acknowledgments ........................................ 23
10. Author's Address ....................................... 23
11. Full Copyright Statement ............................... 24
3.12 QoS展開ロジスティクス… 17 4. QoSアーキテクチャの目的… 18 5. 終わりから終わりへのQoSアーキテクチャに向かって… 19 6. 結論… 21 7. セキュリティ問題… 21 8. 参照… 22 9. 承認… 23 10. 作者のアドレス… 23 11. 完全な著作権宣言文… 24
1. Introduction
1. 序論
The default service offering associated with the Internet is characterized as a best-effort variable service response. Within this service profile the network makes no attempt to actively differentiate its service response between the traffic streams generated by concurrent users of the network. As the load generated by the active traffic flows within the network varies, the network's best effort service response will also vary.
インターネットに関連しているデフォルトサービス提供はベストエフォート型可変サービス応答として特徴付けられます。 このサービスプロフィールの中では、ネットワークは活発にトラフィックの間のサービス応答を差別化する試みを全くネットワークのコンカレントユーザによって生成されたストリームにしません。 また、ネットワークの中のアクティブな交通の流れによって生成された負荷が異なるのに従って、ネットワークのベストエフォート型サービス応答は異なるでしょう。
The objective of various Internet Quality of Service (QoS) efforts is to augment this base service with a number of selectable service responses. These service responses may be distinguished from the best-effort service by some form of superior service level, or they may be distinguished by providing a predictable service response which is unaffected by external conditions such as the number of concurrent traffic flows, or their generated traffic load.
Service(QoS)取り組みの様々なインターネットQualityの目的は多くの選択可能なサービス応答に従ってこのベースサービスを増大させることです。 これらのサービス応答が何らかのフォームの優れたサービスレベルによってベストエフォート型サービスと区別されるかもしれませんか、またはそれらは、同時発生の交通の流れの数、またはそれらの発生しているトラヒック負荷などの外部の状態で影響を受けない予測できるサービス応答を提供することによって、区別されるかもしれません。
Any network service response is an outcome of the resources available to service a load, and the level of the load itself. To offer such distinguished services there is not only a requirement to provide a differentiated service response within the network, there is also a requirement to control the service-qualified load admitted into the network, so that the resources allocated by the network to support a particular service response are capable of providing that response for the imposed load. This combination of admission control agents and service management elements can be summarized as "rules plus behaviors". To use the terminology of the Differentiated Service architecture [4], this admission control function is undertaken by a traffic conditioner (an entity which performs traffic conditioning functions and which may contain meters, markers, droppers, and shapers), where the actions of the conditioner are governed by explicit or implicit admission control agents.
どんなネットワーク・サービス応答も、負荷を修理するために利用可能なリソースの結果、負荷自体のレベルです。 そのような功績をそこに提供するのが、ネットワークの中で差別化されたサービス応答を提供するという要件であるだけではない、また、ネットワークに認められたサービスで適切な負荷を制御するという要件があります、ネットワークによって特定のサービス応答は課す応答であるならできるサポートに割り当てられたリソースがロードされるように。 「規則と振舞い」として入場コントロールエージェントとサービス管理要素のこの組み合わせをまとめることができます。 Differentiated Serviceアーキテクチャ[4]の用語を使用するために、トラフィックコンディショナー(トラフィック調節機能を実行して、メーター、マーカー、点滴器、および整形器を含むかもしれない実体)によってこの入場コントロール機能は引き受けられます。そこでは、コンディショナーの機能が明白であるか内在している入場コントロールエージェントによって治められます。
As a general observation of QoS architectures, the service load control aspect of QoS is perhaps the most troubling component of the architecture. While there are a wide array of well understood service response mechanisms that are available to IP networks,
QoSアーキテクチャの一般的な観測として、QoSの使用荷重コントロール局面は恐らくアーキテクチャの最も厄介な成分です。 ありましたが、井戸の広い配列はIPネットワークに利用可能なサービス反応機構を理解していました。
Huston Informational [Page 2] RFC 2990 Next Steps for QoS Architecture November 2000
QoSアーキテクチャ2000年11月のための次のヒューストンInformational[2ページ]のRFC2990ステップ
matching a set of such mechanisms within a controlled environment to respond to a set of service loads to achieve a completely consistent service response remains an area of weakness within existing IP QoS architectures. The control elements span a number of generic requirements, including end-to-end application signaling, end-to- network service signaling and resource management signaling to allow policy-based control of network resources. This control may also span a particular scope, and use 'edge to edge' signaling, intended to support particular service responses within a defined network scope.
完全に一貫したサービス応答を達成するために1セットの使用荷重まで応じるために制御環境の中で1セットのそのようなメカニズムを合わせるのは既存のIP QoSアーキテクチャの中に弱点の領域のままで残っています。 制御要素は多くのジェネリック要件にかかっています、終わりから終わりへのアプリケーションシグナリング、終わりからネットワーク・サービスへのシグナリング、およびネットワーク資源の方針ベースのコントロールを許すのを示す資源管理を含んでいて。 このコントロールは、また、特定の範囲にかかっていて、定義されたネットワーク範囲の中で特定のサービスが応答であるとサポートすることを意図して、合図する'斜めに進ませる縁'を使用するかもしれません。
One way of implementing this control of imposed load to match the level of available resources is through an application-driven process of service level negotiation (also known as application signaled QoS). Here, the application first signals its service requirements to the network, and the network responds to this request. The application will proceed if the network has indicated that it is able to carry the additional load at the requested service level. If the network indicates that it cannot accommodate the service requirements the application may proceed in any case, on the basis that the network will service the application's data on a best effort basis. This negotiation between the application and the network can take the form of explicit negotiation and commitment, where there is a single negotiation phase, followed by a commitment to the service level on the part of the network. This application-signaled approach can be used within the Integrated Services architecture, where the application frames its service request within the resource reservation protocol (RSVP), and then passes this request into the network. The network can either respond positively in terms of its agreement to commit to this service profile, or it can reject the request. If the network commits to the request with a resource reservation, the application can then pass traffic into the network with the expectation that as long as the traffic remains within the traffic load profile that was originally associated with the request, the network will meet the requested service levels. There is no requirement for the application to periodically reconfirm the service reservation itself, as the interaction between RSVP and the network constantly refreshes the reservation while it remains active. The reservation remains in force until the application explicitly requests termination of the reservation, or the network signals to the application that it is unable to continue with a service commitment to the reservation [3]. There are variations to this model, including an aggregation model where a proxy agent can fold a number of application-signaled reservations into a common aggregate reservation along a common sub-path, and a matching deaggregator can reestablish the collection of individual resource reservations upon leaving the aggregate region [5]. The essential feature of this Integrated Services model is the "all or nothing" nature of the
サービスレベル交渉(また、アプリケーションがQoSを示したので、知っている)のアプリケーション駆動のプロセスを通して利用可能資源のレベルを合わせる課された負荷のこのコントロールを実装する1つの方法があります。 ここに、アプリケーションは最初にサービス要件をネットワークに示します、そして、ネットワークはこの要求に応じます。 ネットワークが、要求されたサービスレベルで追加積載物を運ぶことができるのを示したなら、アプリケーションは続くでしょう。 ネットワークが、ネットワークがベストエフォート型ベースに関するアプリケーションのデータを修理するというどのような場合でも、アプリケーションがベースで続かせるかもしれないサービス要件を収容できないのを示すなら。 アプリケーションとネットワークとのこの交渉はサービスレベルの委任がネットワーク側のただ一つの交渉フェーズがあるところにあとに続いた明白な交渉と委任の形を取ることができます。 Integrated Servicesアーキテクチャの中でこのアプリケーションで合図されたアプローチを使用できます。アプリケーションは、そこで資源予約プロトコル(RSVP)の中でサービスのリクエストを縁どっていて、次に、この要求にネットワークに合格します。 ネットワークがこのサービスプロフィールに公約する協定で明確に応じることができますか、またはそれは要求を拒絶できます。 ネットワークが資源予約で要求に公約されるなら、トラフィックが元々要求に関連したトラフィック負荷プロフィールに残っているとき、期待がそれ同じくらい長い状態でアプリケーションはトラフィックをネットワークに通過できて、ネットワークは要求されたサービスレベルを満たすでしょう。 アプリケーションが定期的にサービスの予約自体を再確認するという要件が全くありません、アクティブなままで残っていますが、RSVPとネットワークとの相互作用が絶えず予約をリフレッシュするとき。 アプリケーションが、予約[3]のサービス委任を続行するよう明らかにそれであることができないという予約の終了、またはアプリケーションへのネットワーク信号に要求するまで、予約は有効なままで残っています。 このモデルへの変化があります、プロキシエージェントが一般的なサブ経路に沿って多くのアプリケーションで合図された予約を一般的な集合予約に折り重ねることができて、合っている「反-アグリゲータ」が集合領域を[5]に出るときの個々の資源予約の収集を回復させることができる集合モデルを含んでいて。 不可欠このIntegrated Servicesモデルの特徴が「すべてか何でもない」自然であることを
Huston Informational [Page 3] RFC 2990 Next Steps for QoS Architecture November 2000
QoSアーキテクチャ2000年11月のための次のヒューストンInformational[3ページ]のRFC2990ステップ
model. Either the network commits to the reservation, in which case the requestor does not have to subsequently monitor the network's level of response to the service, or the network indicates that it cannot meet the resource reservation.
モデル化してください。 ネットワークが予約に公約されるか、その場合、要請者が次に、ネットワークのサービスへの応答のレベルをモニターする必要はありませんか、またはネットワークは、資源予約に間に合うことができないのを示します。
An alternative approach to load control is to decouple the network load control function from the application. This is the basis of the Differentiated Services architecture. Here, a network implements a load control function as part of the function of admission of traffic into the network, admitting no more traffic within each service category as there are assumed to be resources in the network to deliver the intended service response. Necessarily there is some element of imprecision in this function given that traffic may take an arbitrary path through the network. In terms of the interaction between the network and the application, this takes the form of a service request without prior negotiation, where the application requests a particular service response by simply marking each packet with a code to indicate the desired service. Architecturally, this approach decouples the end systems and the network, allowing a network to implement an active admission function in order to moderate the workload that is placed upon the network's resources without specific reference to individual resource requests from end systems. While this decoupling of control allows a network's operator greater ability to manage its resources and a greater ability to ensure the integrity of its services, there is a greater potential level of imprecision in attempting to match applications' service requirements to the network's service capabilities.
負荷制御への代替的アプローチはアプリケーションからネットワーク負荷制御機能の衝撃を吸収することです。 これはDifferentiated Servicesアーキテクチャの基礎です。 ここで、ネットワークはトラフィックの入場の機能の一部として負荷制御機能をネットワークに実装します、ネットワークでリソースであると思われるそれぞれのサービスカテゴリの中のそれ以上のトラフィックが意図しているサービス応答を提供しないことを認めて。 必ず、トラフィックがネットワークを通して任意の経路を取るかもしれないなら、この機能には不正確の何らかの要素があります。 ネットワークとアプリケーションとの相互作用に関して、これは先の交渉のないサービスのリクエストの形を取ります。(そこでは、アプリケーションが、必要なサービスを示すために単に各パケットにコードを付けることによって、特定のサービス応答を要求します)。 建築上、このアプローチはエンドシステムとネットワークの衝撃を吸収します、個々の資源要求の特定指示なしでエンドシステムからネットワークのリソースに置かれるワークロードを加減するためにネットワークがアクティブな入場機能を実装するのを許容して; コントロールのこのデカップリングはリソースを管理するネットワークのオペレータの、より大きい能力とサービスの保全を確実にするより大きい能力を許容しますが、ネットワークのサービス能力にアプリケーションのサービス要件を合わせるのを試みるのにおいて、より大きい潜在的レベルの不正確があります。
2. State and Stateless QoS
2. 状態と状態がないQoS
These two approaches to load control can be characterized as state- based and stateless approaches respectively.
州のベースの、そして、状態がないアプローチとしてそれぞれ負荷制御へのこれらの2つのアプローチを特徴付けることができます。
The architecture of the Integrated Services model equates the cumulative sum of honored service requests to the current reserved resource levels of the network. In order for a resource reservation to be honored by the network, the network must maintain some form of remembered state to describe the resources that have been reserved, and the network path over which the reserved service will operate. This is to ensure integrity of the reservation. In addition, each active network element within the network path must maintain a local state that allows incoming IP packets to be correctly classified into a reservation class. This classification allows the packet to be placed into a packet flow context that is associated with an appropriate service response consistent with the original end-to-end service reservation. This local state also extends to the function
Integrated Servicesモデルのアーキテクチャはネットワークの現在の予約されたリソースレベルに光栄に思っているサービスのリクエストの累積合計を等しくします。 資源予約がネットワークによって守られる場合、ネットワークは、予約されたリソース、および予約されたサービスが作動するネットワーク経路について説明するために何らかのフォームの覚えていられた状態を維持しなければなりません。 これは、予約の保全を確実にするためのものです。 さらに、ネットワーク経路の中のそれぞれの活性ネットワーク要素は入って来るIPパケットが正しく予約のクラスに分類されるのを許容する地方の州を維持しなければなりません。 この分類は、パケットが終わりから終わりへのサービス当初の予約と一致した適切なサービス応答に関連しているパケット流れ文脈に置かれるのを許容します。 また、この地方の州は機能に達します。
Huston Informational [Page 4] RFC 2990 Next Steps for QoS Architecture November 2000
QoSアーキテクチャ2000年11月のための次のヒューストンInformational[4ページ]のRFC2990ステップ
of metering packets for conformance on a flow-by-flow basis, and the additional overheads associated with maintenance of the state of each of these meters.
順応のために流れごとの基礎、およびそれぞれのこれらのメーターの状態のメインテナンスに関連している追加オーバーヘッドでパケットを計量するのについて。
In the second approach, that of a Differentiated Services model, the packet is marked with a code to trigger the appropriate service response from the network elements that handles the packet, so that there is no strict requirement to install a per-reservation state on these network elements. Also, the end application or the service requestor is not required to provide the network with advance notice relating to the destination of the traffic, nor any indication of the intended traffic profile or the associated service profile. In the absence of such information any form of per-application or per-path resource reservation is not feasible. In this model there is no maintained per-flow state within the network.
アプローチ、Differentiated Servicesのものがモデル化される秒にパケットはコードでマークされて、ネットワーク要素からのパケットを扱う適切なサービス応答の引き金となります、1予約あたり1つの状態をこれらのネットワーク要素の上にインストールするというどんな厳しい要件もないように。 また、エンドアプリケーションかサービス要請者がトラフィックの目的地、および意図しているトラフィックプロフィールか関連サービスプロフィールのどんなしるしにも関連する事前通知をネットワークに提供する必要はありません。 そのような情報がないとき、どんな形式のアプリケーションか経路あたりの資源予約も可能ではありません。 このモデルには、ネットワークの中に1流れあたりの維持された状態が全くありません。
The state-based Integrated Services architectural model admits the potential to support greater level of accuracy, and a finer level of granularity on the part of the network to respond to service requests. Each individual application's service request can be used to generate a reservation state within the network that is intended to prevent the resources associated with the reservation to be reassigned or otherwise preempted to service other reservations or to service best effort traffic loads. The state-based model is intended to be exclusionary, where other traffic is displaced in order to meet the reservation's service targets.
州のベースのIntegrated Services建築モデルはサービスのリクエストに反応させるネットワーク側のより大きいレベルの精度、および、よりすばらしいレベルの粒状をサポートする可能性を認めます。 ネットワークの中の再選任されるか、または別の方法でサービスに先取りされるために予約に関連しているリソースを防ぐことを意図する予約状態に他の予約を生成するか、またはベストエフォート型トラヒック負荷を修理するのにそれぞれの個々のアプリケーションのサービスのリクエストを使用できます。 州のベースのモデルが排他的であることを意図します、他のトラフィックが予約のサービス目標を達成するために置き換えられるところで。
As noted in RFC2208 [2], there are several areas of concern about the deployment of this form of service architecture. With regard to concerns of per-flow service scalability, the resource requirements (computational processing and memory consumption) for running per- flow resource reservations on routers increase in direct proportion to the number of separate reservations that need to be accommodated. By the same token, router forwarding performance may be impacted adversely by the packet-classification and scheduling mechanisms intended to provide differentiated services for these resource- reserved flows. This service architecture also poses some challenges to the queuing mechanisms, where there is the requirement to allocate absolute levels of egress bandwidth to individual flows, while still supporting an unmanaged low priority best effort traffic class.
RFC2208[2]に述べられるように、このフォームのサービスアーキテクチャの展開に関して重要ないくつかの領域があります。 流れの関心に関して、スケーラビリティを修理してください、実行のためのリソース要件(コンピュータの処理とメモリ消費)、-、ルータの流れ資源予約は設備される必要がある別々の予約の数に直接比例して増加します。 同様に、パケット分類で逆にルータ推進性能に影響を与えるかもしれません、そして、リソースが予約したこれらのための差別化されたサービスを提供することを意図するメカニズムの計画をするのは流れます。 また、このサービスアーキテクチャは列を作りメカニズムへのいくつかの挑戦を引き起こします。(そこに、絶対レベルの出口帯域幅を個々の流れに割り当てるという要件がまだ非管理された低優先権ベストエフォート型トラフィックのクラスをサポートしている間、あります)。
The stateless approach to service management is more approximate in the nature of its outcomes. Here there is no explicit negotiation between the application's signaling of the service request and the network's capability to deliver a particular service response. If the network is incapable of meeting the service request, then the request simply will not be honored. In such a situation there is no requirement for the network to inform the application that the
結果の本質においてサービス管理への状態がないアプローチは、より大体です。 ここには、サービスのリクエストと特定のサービス応答を提供するネットワークの能力に関するアプリケーションのシグナリングの間のどんな明白な交渉もありません。 ネットワークがサービスのリクエストを満たすことができないと、要求は絶対に光栄に思わないようになるでしょう。 そのような状況に、ネットワークがアプリケーションを知らせるという要件が全くない、それ
Huston Informational [Page 5] RFC 2990 Next Steps for QoS Architecture November 2000
QoSアーキテクチャ2000年11月のための次のヒューストンInformational[5ページ]のRFC2990ステップ
request cannot be honored, and it is left to the application to determine if the service has not been delivered. The major attribute of this approach is that it can possess excellent scaling properties from the perspective of the network. If the network is capable of supporting a limited number of discrete service responses, and the routers uses per-packet marking to trigger the service response, then the processor and memory requirements in each router do not increase in proportion to the level of traffic passed through the router. Of course this approach does introduce some degree of compromise in that the service response is more approximate as seen by the end client, and scaling the number of clients and applications in such an environment may not necessarily result in a highly accurate service response to every client's application.
要求を光栄に思うことができません、そして、それが、サービスが提供されていないかどうか決定するのがアプリケーションに残されます。 このアプローチの主要な属性はネットワークの見解からの素晴らしいスケーリング特性を持つことができるということです。 ネットワークが限られた数の離散的なサービス応答をサポートすることができて、ルータがサービス応答の引き金となるのに1パケットあたりのマークを使用するなら、各ルータにおけるプロセッサとメモリ要件はルータを通り抜けるトラフィックのレベルに比例して増加しません。 もちろん、サービス応答が終わりのクライアントによって見られて、クライアントの数をスケーリングするとして、より大体ので、このアプローチはいくらかの感染を導入します、そして、そのような環境におけるアプリケーションは必ずすべてのクライアントのアプリケーションへの高精度なサービス応答をもたらすかもしれないというわけではありません。
It is not intended to describe these service architectures in further detail within this document. The reader is referred to RFC1633 [3] for an overview of the Integrated Services Architecture (IntServ) and RFC2475 [4] for an overview of the Differentiated Services architecture (DiffServ).
それがこのドキュメントの中の詳細のこれらのサービスアーキテクチャについて説明することを意図しません。 読者はDifferentiated Servicesアーキテクチャ(DiffServ)の概要にIntegrated Services Architecture(IntServ)とRFC2475[4]の概要についてRFC1633[3]を参照されます。
These two approaches are the endpoints of what can be seen as a continuum of control models, where the fine-grained precision of the per application invocation reservation model can be aggregated into larger, more general and potentially more approximate aggregate reservation states, and the end-to-end element-by-element reservation control can be progressively approximated by treating a collection of subnetworks or an entire transit network as an aggregate service element. There are a number of work in progress efforts which are directed towards these aggregated control models, including aggregation of RSVP [5], the RSVP DCLASS Object [6] to allow Differentiated Services Code Points (DSCPs) to be carried in RSVP message objects, and operation of Integrated Services over Differentiated Services networks [7].
これらの2つのアプローチ、規制モデル、どこに関する連続と考えることができるものに関する終点がきめ細かに粒状の精度である、アプリケーション実施の予約モデル単位で、より大きくて、より一般的で潜在的により大体の集合予約州に集めることができて、集合サービス要素としてサブネットワークの収集か全体のトランジットネットワークを扱うことによって、要素に従った側ヒーターの端の予約コントロールに次第に近似できます。 これらの集められた規制モデルに向けられる多くの処理中の作業取り組みがあります、RSVP[5](Differentiated Services Code Points(DSCPs)がRSVPメッセージオブジェクト、およびIntegrated Servicesの操作でDifferentiated Servicesネットワーク[7]の上まで運ばれるのを許容するRSVP DCLASS Object[6])の集合を含んでいて
3. Next Steps for QoS Architectures
3. QoSアーキテクチャのための次のステップ
Both the Integrated Services architecture and the Differentiated Services architecture have some critical elements in terms of their current definition which appear to be acting as deterrents to widespread deployment. Some of these issues will probably be addressed within the efforts to introduce aggregated control and response models into these QoS architectures, while others may require further refinement through standards-related activities.
Integrated ServicesアーキテクチャとDifferentiated Servicesアーキテクチャの両方には、広範囲の展開への抑止力として機能しているように見える彼らの現在の定義によるいくつかの重要な要素があります。 これらの問題のいくつかが集められたコントロールと応答モデルをこれらのQoSアーキテクチャに取り入れるためにたぶん取り組みの中で扱われるでしょう、他のものは規格関連の活動でさらなる気品を必要とするかもしれませんが。
Huston Informational [Page 6] RFC 2990 Next Steps for QoS Architecture November 2000
QoSアーキテクチャ2000年11月のための次のヒューストンInformational[6ページ]のRFC2990ステップ
3.1 QoS-Enabled Applications
3.1 QoSによって可能にされたアプリケーション
One of the basic areas of uncertainty with QoS architectures is whether QoS is a per-application service, whether QoS is a transport-layer option, or both. Per-application services have obvious implications of extending the QoS architecture into some form of Application Protocol Interface (API), so that applications could negotiate a QoS response from the network and alter their behavior according to the outcome of the response. Examples of this approach include GQOS [8], and RAPI [9]. As a transport layer option, it could be envisaged that any application could have its traffic carried by some form of QoS-enabled network services by changing the host configuration, or by changing the configuration at some other network control point, without making any explicit changes to the application itself. The strength of the transport layer approach is that there is no requirement to substantially alter application behavior, as the application is itself unaware of the administratively assigned QoS. The weakness of this approach is that the application is unable to communicate what may be useful information to the network or to the policy systems that are managing the network's service responses. In the absence of such information the network may provide a service response that is far superior than the application's true requirements, or far inferior than what is required for the application to function correctly. An additional weakness of a transport level approach refers to those class of applications that can adapt their traffic profile to meet the available resources within the network. As a transport level mechanism, such network availability information as may be available to the transport level is not passed back to the application.
QoSアーキテクチャがある不確実性の基本的な領域の1つはQoSがアプリケーションサービスであるかどうかということです、QoSがトランスポート層オプション、または両方であることにかかわらず。 アプリケーション・サービスには、ApplicationプロトコルInterface(API)の何らかのフォームにQoSアーキテクチャを広げる明白な意味があります、アプリケーションがネットワークからQoS応答を交渉して、応答の結果に従って彼らの振舞いを変更できるように。 このアプローチに関する例はGQOS[8]、およびRAPI[9]を含んでいます。 トランスポート層オプションとして、ある他のネットワーク制御ポイントでホスト構成を変えるか、または構成を変えることによって何らかの形式のQoSによって可能にされたネットワーク・サービスでトラフィックを運ぶかもしれないのをどんなアプリケーションでも考えることができました、アプリケーション自体へのどんな明白な変更も行わないで。 トランスポート層アプローチの強さは実質的にアプリケーションの振舞いを変更するという要件が全くないということです、利用がそれ自体で行政上割り当てられたQoSに気づかない状態であるとき。 このアプローチの弱点はアプリケーションが、何がネットワーク、または、ネットワークのサービス応答を管理している方針システムへの役に立つ情報であるかもしれないかを伝えることができないということです。 そのような情報がないとき、ネットワークは、アプリケーションの本当の要件よりはるかに優れたサービス応答を提供するか、または何がアプリケーションが正しく機能するのに必要であるかというよりも遠い目下を提供するかもしれません。 輸送レベルアプローチの別の弱みはネットワークの中で利用可能資源を満たすためにそれらのトラフィックプロフィールを翻案できるそれらのクラスのアプリケーションを参照します。 輸送レベルメカニズムとして、輸送レベルに利用可能であるかもしれないようなネットワーク有用性情報はアプリケーションに戻されません。
In the case of the Integrated Services architecture, this transport layer approach does not appear to be an available option, as the application does require some alteration to function correctly in this environment. The application must be able to provide to the service reservation module a profile of its anticipated traffic, or in other words the application must be able to predict its traffic load. In addition, the application must be able to share the reservation state with the network, so that if the network state fails, the application can be informed of the failure. The more general observation is that a network can only formulate an accurate response to an application's requirements if the application is willing to offer precise statement of its traffic profile, and is willing to be policed in order to have its traffic fit within this profile.
Integrated Servicesアーキテクチャの場合では、このトランスポート層アプローチは利用可能なオプションであるように見えません、アプリケーションが、何らかの変更がこの環境で正しく機能するのを必要とするとき。 アプリケーションが予期されたトラフィックのプロフィールをサービス予約モジュールに提供できなければなりませんか、または言い換えれば、アプリケーションはトラヒック負荷を予測できなければなりません。 さらに、アプリケーションは予約状態をネットワークと共有できなければなりません、ネットワーク状態が行き詰まるなら、失敗についてアプリケーションを知らすことができます。 より一般的な観測はアプリケーションが、トラフィックプロフィールの的確な陳述を提供することを望んで、トラフィックがこのプロフィールの中に合わせるように取り締まられても構わないと思っている場合にだけネットワークがアプリケーションの要件への正確な応答を定式化できるということです。
In the case of the Differentiated Services architecture there is no explicit provision for the application to communicate with the network regarding service levels. This does allow the use of a
Differentiated Servicesアーキテクチャの場合には、アプリケーションがサービスレベルに関するネットワークとコミュニケートするように、どんな明白な支給もありません。 これはaの使用を許します。
Huston Informational [Page 7] RFC 2990 Next Steps for QoS Architecture November 2000
QoSアーキテクチャ2000年11月のための次のヒューストンInformational[7ページ]のRFC2990ステップ
transport level option within the end system that does not require explicit alteration of the application to mark its generated traffic with one of the available Differentiated Services service profiles. However, whether the application is aware of such service profiles or not, there is no level of service assurance to the application in such a model. If the Differentiated Services boundary traffic conditioners enter a load shedding state, the application is not signaled of this condition, and is not explicitly aware that the requested service response is not being provided by the network. If the network itself changes state and is unable to meet the cumulative traffic loads admitted by the ingress traffic conditioners, neither the ingress traffic conditioners, nor the client applications, are informed of this failure to maintain the associated service quality. While there is no explicit need to alter application behavior in this architecture, as the basic DiffServ mechanism is one that is managed within the network itself, the consequence is that an application may not be aware whether a particular service state is being delivered to the application.
利用可能なDifferentiated Servicesサービスプロフィールの1つを発生しているトラフィックに付けるためにアプリケーションの明白な変更を必要としないエンドシステムの中で平らなオプションを輸送してください。 しかしながら、アプリケーションがそのようなサービスプロフィールを意識しているか否かに関係なく、そのようなモデルにはアプリケーションへのサービス保証のレベルが全くありません。 Differentiated Services境界トラフィックコンディショナーが電力平均分配状態に入るなら、アプリケーションは、この状態について合図されないで、また要求されたサービス応答がネットワークによって提供されていないのを明らかに意識していません。 ネットワーク自体が状態を変えて、会うことができないなら、イングレストラフィックコンディショナーによって認められた累積しているトラヒック負荷(どちらもイングレストラフィックコンディショナーかクライアントアプリケーション)は、関連サービス品質を維持しないこのことにおいて知識があります。 基本的なDiffServメカニズムがネットワーク自体の中で管理されるものであるので、このアーキテクチャにはアプリケーションの振舞いを変更する明白な必要は全くありませんが、結果はアプリケーションが特定のサービス状態がアプリケーションに提供されているかどうかを意識していないかもしれないということです。
There is potential in using an explicit signaling model, such as used by IntServ, but carrying a signal which allows the network to manage the application's traffic within an aggregated service class [6]. Here the application does not pass a complete picture of its intended service profile to the network, but instead is providing some level of additional information to the network to assist in managing its resources, both in terms of the generic service class that the network can associate with the application's traffic, and the intended path of the traffic through the network.
明白なシグナリングモデルを使用するのにおいて可能性があります、IntServによって使用されますが、集められたサービスのクラス[6]の中でネットワークがアプリケーションのトラフィックを管理できる信号を運ぶのなどように。 ここに、アプリケーションは、意図しているサービスプロフィールの完全な画像をネットワークに通過しませんが、代わりにネットワークを通してネットワークがアプリケーションのトラフィックと交際できるという何らかのレベルに関するリソースを管理する助けるネットワークと、ジェネリックサービスのクラスに関する両方の、追加情報、およびトラフィックの意図している経路を提供しています。
An additional factor for QoS enabled applications is that of receiver capability negotiation. There is no value in the sender establishing a QoS-enabled path across a network to the receiver if the receiver is incapable of absorbing the consequent data flow. This implies that QoS enabled applications also require some form of end-to-end capability negotiation, possibly through a generic protocol to allow the sender to match its QoS requirements to the minimum of the flow resources that can be provided by the network and the flow resources that can be processed by the receiver. In the case of the Integrated services architecture the application end-to-end interaction can be integrated into the RSVP negotiation. In the case of the Differentiated Services architecture there is no clear path of integrating such receiver control into the signaling model of the architecture as it stands.
QoSがアプリケーションを可能にしたので、追加要素は受信機能力交渉のものです。 値が全く結果のデータフローを受信機が吸収されることができないならネットワークの向こう側にQoSによって可能にされた経路を受信機に確立する送付者にありません。 これはまた可能にされたアプリケーションが、ネットワークが提供できる流れリソースと受信機で処理できる流れリソースの最小限にQoS要件を合わせるために終わりから終わりとの何らかの形式のことによるとジェネリックプロトコルを通した能力交渉が送付者を許容するのを必要とするそのQoSを含意します。Integratedサービスアーキテクチャの場合に、アプリケーション終わりから終わりへの相互作用はRSVP交渉に統合されることができます。 Differentiated Servicesアーキテクチャの場合には、アーキテクチャのシグナリングモデルへの立つような受信機コントロールを統合するどんな明確な経路もありません。
If high quality services are to be provided, where `high quality' is implied as being `high precision with a fine level of granularity', then the implication is that all parts of the network that may be involved with servicing the request either have to be over-
高い質の高いサービスが'高い品質'が'すばらしいレベルの粒状がある高い精度'であるとして含意されるところで提供することであるなら含意がどちらかが要求でなければならないことを修理するのにそうするかもしれないネットワークのすべての部分が伴われるということである、過剰
Huston Informational [Page 8] RFC 2990 Next Steps for QoS Architecture November 2000
QoSアーキテクチャ2000年11月のための次のヒューストンInformational[8ページ]のRFC2990ステップ
provisioned such that no load state can compromise the service quality, or the network element must undertake explicit allocation of resources to each flow that is associated with each service request.
どんな負荷州も、サービスが品質であると感染することができないか、またはネットワーク要素が各サービスのリクエストに関連しているそれぞれの流れようにリソースの明白な配分を引き受けなければならないようなものに食糧を供給しました。
For end-to-end service delivery it does appear that QoS architectures will need to extend to the level of the application requesting the service profile. It appears that further refinement of the QoS architecture is required to integrate DiffServ network services into an end-to-end service delivery model, as noted in [7].
終わりから終わりへのサービス配送に関しては、QoSアーキテクチャが、サービスプロフィールを要求するアプリケーションのレベルに達する必要なように見えます。 QoSアーキテクチャのさらなる気品が終わりから終わりへのサービス配送モデルとDiffServネットワーク・サービスを統合するのに必要であるように見えます、[7]に述べられるように。
3.2 The Service Environment
3.2 サービス環境
The outcome of the considerations of these two approaches to QoS architecture within the network is that there appears to be no single comprehensive service environment that possesses both service accuracy and scaling properties.
ネットワークの中のQoSアーキテクチャへのこれらの2つのアプローチの問題の結果はサービス精度とスケーリング特性の両方を持っているどんなただ一つの包括的なサービス環境もあるように見えないということです。
The maintained reservation state of the Integrated Services architecture and the end-to-end signaling function of RSVP are part of a service management architecture, but it is not cost effective, or even feasible, to operate a per-application reservation and classification state across the high speed core of a network [2].
Integrated Servicesアーキテクチャの維持された予約事情と終わりから終わりへのRSVPのシグナル伝達機能はサービス管理体系の一部ですが、それは、ネットワーク[2]の高速コアの向こう側に1アプリケーションあたりの予約と分類状態を経営するために費用効率がよくないか、または可能でさえあります。
While the aggregated behavior state of the Differentiated Services architecture does offer excellent scaling properties, the lack of end-to-end signaling facilities makes such an approach one that cannot operate in isolation within any environment. The Differentiated Services architecture can be characterized as a boundary-centric operational model. With this boundary-centric architecture, the signaling of resource availability from the interior of the network to the boundary traffic conditioners is not defined, nor is the signaling from the traffic conditioners to the application that is resident on the end system. This has been noted as an additional work item in the IntServ operations over DiffServ work, concerning "definition of mechanisms to efficiently and dynamically provision resources in a DiffServ network region". This might include protocols by which an "oracle" (...) conveys information about resource availability within a DiffServ region to border routers." [7]
Differentiated Servicesアーキテクチャの集められた振舞い事情は素晴らしいスケーリング特性を提供しますが、終わりから終わりへのシグナリング施設の不足はそのようなアプローチを分離してどんな環境の中でも作動できないものにします。 境界中心のオペレーショナル・モデルとしてDifferentiated Servicesアーキテクチャを特徴付けることができます。 この境界中心のアーキテクチャで、ネットワークの内部から境界トラフィックコンディショナーまでのリソースの有用性のシグナリングは定義されません、そして、トラフィックコンディショナーからエンドシステムの上で居住しているアプリケーションまでシグナリングがありません。 追加仕事項目としてDiffServ仕事の上のIntServ操作でこれに注意しました、「DiffServネットワーク領域で効率的にダイナミックにリソースに食糧を供給するメカニズムの定義」に関して。 「これは「神託」(…)がルータに接するためにDiffServ領域の中でリソースの有用性に関して情報を伝達するプロトコルを含むかもしれません。」 [7]
What appears to be required within the Differentiated Services service model is both resource availability signaling from the core of the network to the DiffServ boundary and some form of signaling from the boundary to the client application.
何がDifferentiated Servicesサービスモデルの中で必要であるように見えるかは、ネットワークのコアからDiffServ境界まで合図するリソースの有用性と何らかのフォームの境界からクライアントアプリケーションまでのシグナリングの両方です。
Huston Informational [Page 9] RFC 2990 Next Steps for QoS Architecture November 2000
QoSアーキテクチャ2000年11月のための次のヒューストンInformational[9ページ]のRFC2990ステップ
3.3 QoS Discovery
3.3 QoS発見
There is no robust mechanism for network path discovery with specific service performance attributes. The assumption within both IntServ and DiffServ architectures is that the best effort routing path is used, where the path is either capable of sustaining the service load, or not.
ネットワーク経路発見のためのどんな強健なメカニズムも特定のサービス性能属性と共にありません。 IntServとDiffServアーキテクチャの両方の中の仮定はベストエフォート型ルーティング経路が使用されているということです、経路が使用荷重を支えることができるところで。
Assuming that the deployment of service differentiating infrastructure will be piecemeal, even if only in the initial stages of a QoS rollout, such an assumption may be unwarranted. If this is the case, then how can a host application determine if there is a distinguished service path to the destination? No existing mechanisms exist within either of these architectures to query the network for the potential to support a specific service profile. Such a query would need to examine a number of candidate paths, rather than simply examining the lowest metric routing path, so that this discovery function is likely to be associated with some form of QoS routing functionality.
QoS初公開の初期だけにおいて、そのような仮定が保証がなくても、インフラストラクチャを差別化するサービスの展開が少しずつなると仮定します。 これがそうであるなら、ホストアプリケーションは、偉勲経路があるかどうかどうしたら目的地に決定できますか? いいえ存在メカニズムは、特定のサービスプロフィールを支える可能性のためにネットワークについて質問するためにこれらのアーキテクチャのどちらかの中に存在しています。 そのような質問は、単に最も低いメートル法のルーティング経路を調べるよりむしろ多くの候補道を調べる必要があるでしょう、この発見機能が何らかのフォームのQoSルーティングの機能性に関連している傾向があるように。
From this perspective, there is still further refinement that may be required in the model of service discovery and the associated task of resource reservation.
この見解から、サービス発見のモデルと資源予約の関連タスクで必要であるかもしれない気品はまださらに来ています。
3.4 QoS Routing and Resource Management
3.4のQoSルート設定と資源管理
To date QoS routing has been developed at some distance from the task of development of QoS architectures. The implicit assumption within the current QoS architectural models is that the routing best effort path will be used for both best effort traffic and distinguished service traffic.
少し離れたところにQoSアーキテクチャの開発に関するタスクからルーティングとQoSをデートするのを開発してあります。 現在のQoS建築モデルの中の暗黙の仮定は掘っているベストエフォート型経路がベストエフォート型トラフィックと偉勲トラフィックの両方に使用されるということです。
There is no explicit architectural option to allow the network service path to be aligned along other than the single best routing metric path, so that available network resources can be efficiently applied to meet service requests. Considerations of maximizing network efficiency would imply that some form of path selection is necessary within a QoS architecture, allowing the set of service requirements to be optimally supported within the network's aggregate resource capability.
ただ一つの最も良い掘っているメートル法の経路を除いて、ネットワーク・サービス経路がずっと並べられるのを許容するために、どんな明白なアーキテクチャの代替案もありません、サービスのリクエストを満たすために効率的に利用可能なネットワーク資源を適用できるように。 効率がそうする最大化ネットワークの問題は、何らかの形式の経路選択がQoSアーキテクチャの中で必要であることを含意します、ネットワークの集合リソース能力の中で最適にサポートされるというサービス要件のセットを許容して。
In addition to path selection, SPF-based interior routing protocols allow for the flooding of link metric information across all network elements. This mechanism appears to be a productive direction to provide the control-level signaling between the interior of the network and the network admission elements, allowing the admission
経路選択に加えて、SPFベースの内部のルーティング・プロトコルはリンクの氾濫によってすべてのネットワーク要素の向こう側にメートル法の情報を許容します。 このメカニズムはネットワークの内部とネットワーク入場要素の間に制御レベルシグナリングを供給するために生産的な方向であるように見えます、入場を許容して
Huston Informational [Page 10] RFC 2990 Next Steps for QoS Architecture November 2000
QoSアーキテクチャ2000年11月のための次のヒューストンInformational[10ページ]のRFC2990ステップ
systems to admit traffic based on current resource availability rather than on necessarily conservative statically defined admission criteria.
必ず保守的な人に関してというよりむしろ現在のリソースの有用性に基づいて静的にトラフィックを認めるシステムは入場評価基準を定義しました。
There is a more fundamental issue here concerning resource management and traffic engineering. The approach of single path selection with static load characteristics does not match a networked environment which contains a richer mesh of connectivity and dynamic load characteristics. In order to make efficient use of a rich connectivity mesh, it is necessary to be able to direct traffic with a common ingress and egress point across a set of available network paths, spreading the load across a broader collection of network links. At its basic form this is essentially a traffic engineering problem. To support this function it is necessary to calculate per- path dynamic load metrics, and allow the network's ingress system the ability to distribute incoming traffic across these paths in accordance with some model of desired traffic balance. To apply this approach to a QoS architecture would imply that each path has some form of vector of quality attributes, and incoming traffic is balanced across a subset of available paths where the quality attribute of the traffic is matched with the quality vector of each available path. This augmentation to the semantics of the traffic engineering is matched by a corresponding shift in the calculation and interpretation of the path's quality vector. In this approach what needs to be measured is not the path's resource availability level (or idle proportion), but the path's potential to carry additional traffic at a certain level of quality. This potential metric is one that allows existing lower priority traffic to be displaced to alternative paths. The path's quality metric can be interpreted as a metric describing the displacement capability of the path, rather than a resource availability metric.
資源管理と交通工学に関して、より基本的な問題がここにあります。 静荷重の特性があるただ一つの経路選択のアプローチは接続性の、より豊かなメッシュを含むネットワークでつながれた環境とダイナミック・ロードの特性に合っていません。 豊かな接続性の効率的な使用をかみ合わせるように、1セットの利用可能なネットワーク経路の向こう側に一般的なイングレスと出口ポイントで交通整理できるのが必要です、ネットワークリンクの、より広い収集の向こう側に負荷を広げて。 基本的なフォームでは、これは本質的にはトラフィック工学の問題です。 この機能を計算するのが必要であるサポートする、-、経路動力は、測定基準をロードして、必要なトラフィックバランスのモデルに従ってこれらの経路の向こう側に入って来るトラフィックを分配する能力をネットワークのイングレスシステムに許容します。 このアプローチをQoSアーキテクチャに適用するのは、各経路には何らかのフォームの上質の属性のベクトルがあるのを含意するでしょう、そして、入って来るトラフィックはトラフィックの上質の属性がそれぞれの利用可能な経路の上質のベクトルに合わせられている利用可能な経路の部分集合の向こう側にバランスをとっています。 経路の上質のベクトルの計算と解釈における対応するシフトで交通工学の意味論へのこの増大は合われています。 このアプローチでは、測定される必要があることは経路のリソース有用性レベル(または、活動していない割合)ではなく、あるレベルの品質で追加トラフィックを運ぶ経路の可能性です。 この可能性に、メートル法であることは、既存の低優先度トラフィックが迂回経路に置き換えられるのを許容するものです。 経路は品質メートル法です。aリソースの有用性メートル法であるよりむしろ経路の置換え能力について説明しながら、aメートル法であると解釈できます。
This area of active network resource management, coupled with dynamic network resource discovery, and the associated control level signaling to network admission systems appears to be a topic for further research at this point in time.
活発なネットワーク資源管理のこの領域、ネットワーク入場システムへのダイナミックなネットワーク資源発見、および関連制御レベルに結びつけられたシグナリングはさらなる調査のためのこの時点で話題であるように見えます。
3.5 TCP and QoS
3.5 TCPとQoS
A congestion-managed rate-adaptive traffic flow (such as used by TCP) uses the feedback from the ACK packet stream to time subsequent data transmissions. The resultant traffic flow rate is an outcome of the service quality provided to both the forward data packets and the reverse ACK packets. If the ACK stream is treated by the network with a different service profile to the outgoing data packets, it remains an open question as to what extent will the data forwarding service be compromised in terms of achievable throughput. High rates of jitter on the ACK stream can cause ACK compression, that in turn
混雑で管理されたレート適応型の交通の流れ(TCPによって使用されるように)はACKパケットストリームから時間順次データ送信までフィードバックを使用します。 結果のトラフィック流速は前進のデータ・パケットと逆のACKパケットの両方に提供されたサービス品質の結果です。 ACKストリームが異なったサービスプロフィールでネットワークによって発信データパケットに扱われるなら、それは達成可能なスループットでデータがサービスを進めて、どんな範囲がそうするかに感染されるように未決問題のままで残っています。 ACKストリームにおける高い率のジターがACKに圧縮を引き起こす場合がある、そんなに順番に。
Huston Informational [Page 11] RFC 2990 Next Steps for QoS Architecture November 2000
QoSアーキテクチャ2000年11月のための次のヒューストンInformational[11ページ]のRFC2990ステップ
will cause high burst rates on the subsequent data send. Such bursts will stress the service capacity of the network and will compromise TCP throughput rates.
順次データのレートが送る高い炸裂を引き起こすでしょう。 そのような炸裂は、ネットワークのサービス容量を強調して、TCPスループットがレートであると感染するでしょう。
One way to address this is to use some form of symmetric service, where the ACK packets are handled using the same service class as the forward data packets. If symmetric service profiles are important for TCP sessions, how can this be structured in a fashion that does not incorrectly account for service usage? In other words, how can both directions of a TCP flow be accurately accounted to one party?
これを扱う1つの方法は何らかの形式の左右対称のサービスを利用することです、ACKパケットが前進のデータ・パケットと同じサービスのクラスを使用することで扱われるところで。 左右対称のサービスプロフィールがTCPセッションのために重要であるなら、不当にサービス用法を説明しないファッションでどうしたらこれを構造化できますか? 言い換えれば、どうしたら正確にTCP流動の両方の方向を1回のパーティーに説明できますか?
Additionally, there is the interaction between the routing system and the two TCP data flows. The Internet routing architecture does not intrinsically preserve TCP flow symmetry, and the network path taken by the forward packets of a TCP session may not exactly correspond to the path used by the reverse packet flow.
さらに、ルーティングシステムと2つのTCPデータフローとの相互作用があります。 インターネット・ルーティングアーキテクチャは本質的にTCP流れ対称を保存しません、そして、TCPセッションの前進のパケットによって取られたネットワーク経路はまさに逆のパケット流動によって使用される経路と食い違うかもしれません。
TCP also exposes an additional performance constraint in the manner of the traffic conditioning elements in a QoS-enabled network. Traffic conditioners within QoS architectures are typically specified using a rate enforcement mechanism of token buckets. Token bucket traffic conditioners behave in a manner that is analogous to a First In First Out queue. Such traffic conditioning systems impose tail drop behavior on TCP streams. This tail drop behavior can produce TCP timeout retransmission, unduly penalizing the average TCP goodput rate to a level that may be well below the level specified by the token bucket traffic conditioner. Token buckets can be considered as TCP-hostile network elements.
また、TCPはトラフィックがQoSによって可能にされたネットワークで要素を条件とさせる方法で追加性能規制を暴露します。 QoSアーキテクチャの中のトラフィックコンディショナーは、トークンバケツのレート実施メカニズムを使用することで通常指定されます。 トークンバケットトラフィックコンディショナーはFirst In First Out待ち行列に類似の態度で反応します。 そのようなトラフィック調節システムはテール低下の振舞いをTCPストリームに課します。このテール低下の振舞いはTCPタイムアウト「再-トランスミッション」を生産できます、トークンバケットトラフィックコンディショナーによって指定されたレベルのかなり下にあるかもしれないレベルに平均したTCP goodputレートを過度に罰して。 TCP敵軍のネットワーク要素であるとトークンバケツをみなすことができます。
The larger issue exposed in this consideration is that provision of some form of assured service to congestion-managed traffic flows requires traffic conditioning elements that operate using weighted RED-like control behaviors within the network, with less deterministic traffic patterns as an outcome. A requirement to manage TCP burst behavior through token bucket control mechanisms is most appropriately managed in the sender's TCP stack.
この考慮で暴露されたより大きい問題は確実に混雑で管理された交通の流れに対する何らかの形式のサービスの支給がネットワークの中で荷重しているREDのようなコントロールの振舞いを使用することで作動するトラフィック調節要素を必要とするということです、結果としてのそれほど決定論的でないトラフィック・パターンで。 トークンバケット制御機構を通したTCP炸裂の振舞いを管理するという要件は送付者のTCPスタックで最も適切に管理されます。
There are a number of open areas in this topic that would benefit from further research. The nature of the interaction between the end-to-end TCP control system and a collection of service differentiation mechanisms with a network is has a large number of variables. The issues concern the time constants of the control systems, the amplitude of feedback loops, and the extent to which each control system assumes an operating model of other active control systems that are applied to the same traffic flow, and the mode of convergence to a stable operational state for each control system.
さらなる研究の利益を得るこの話題には多くの空地があります。 ネットワークによるサービス分化メカニズムのTCP制御システムと収集がある終わりから終わりの間の相互作用の自然には、多くの変数があります。 問題は制御システムの時定数、フィードバックループの振幅、およびそれぞれの制御システムがそれぞれの制御システムのために他の動作制御の操作モデルが同じ交通の流れに適用されるシステムと、安定した操作上の状態への集合の方法であると仮定する範囲に関係があります。
Huston Informational [Page 12] RFC 2990 Next Steps for QoS Architecture November 2000
QoSアーキテクチャ2000年11月のための次のヒューストンInformational[12ページ]のRFC2990ステップ
3.6 Per-Flow States and Per-Packet classifiers
3.6 1流れあたりのStatesとPer-パケットクラシファイア
Both the IntServ and DiffServ architectures use packet classifiers as an intrinsic part of their architecture. These classifiers can be considered as coarse or fine level classifiers. Fine-grained classifiers can be considered as classifiers that attempt to isolate elements of traffic from an invocation of an application (a `micro- flow') and use a number of fields in the IP packet header to assist in this, typically including the source and destination IP addresses and source and source and destination port addresses. Coarse-grained classifiers attempt to isolate traffic that belongs to an aggregated service state, and typically use the DiffServ code field as the classifying field. In the case of DiffServ there is the potential to use fine-grained classifiers as part of the network ingress element, and coarse-gained classifiers within the interior of the network.
IntServとDiffServアーキテクチャの両方が彼らのアーキテクチャの本質的な部分としてパケットクラシファイアを使用します。 粗いかすばらしい平らなクラシファイアであるとこれらのクラシファイアをみなすことができます。 アプリケーション('マイクロ流れ')の実施からトラフィックの要素を隔離して、これを助けるのにIPパケットのヘッダーで多くの分野を使用するのを試みるクラシファイアであると、きめ細かに粒状のクラシファイアをみなすことができます、ソース、送付先IPアドレス、ソース、ソース、および仕向港アドレスを通常含んでいて。 下品なクラシファイアは、集められたサービス状態に属すトラフィックを隔離するのを試みて、分類分野としてDiffServコード分野を通常使用します。 DiffServの場合には、ネットワークの内部の中にネットワークイングレス要素の一部としてきめ細かに粒状のクラシファイアを使用するためには潜在的の、そして、粗く獲得されたクラシファイアがあります。
Within flow-sensitive IntServ deployments, every active network element that undertakes active service discrimination is requirement to operate fine-grained packet classifiers. The granularity of the classifiers can be relaxed with the specification of aggregate classifiers [5], but at the expense of the precision and accuracy of the service response.
流れ敏感なIntServ展開の中では、現役区別を引き受けるあらゆる活性ネットワーク要素がきめ細かに粒状のパケットクラシファイアを操作するという要件です。 クラシファイアの粒状は集合クラシファイア[5]の仕様にもかかわらず、サービス応答の精度と精度を犠牲にしてリラックスできます。
Within the IntServ architecture the fine-grained classifiers are defined to the level of granularity of an individual traffic flow, using the packet's 5-tuple of (source address, destination address, source port, destination port, protocol) as the means to identify an individual traffic flow. The DiffServ Multi-Field (MF) classifiers are also able to use this 5-tuple to map individual traffic flows into supported behavior aggregates.
IntServアーキテクチャの中では、きめ細かに粒状のクラシファイアは個々の交通の流れの粒状のレベルと定義されます、個々の交通の流れを特定する手段としてパケットの(ソースアドレス、送付先アドレス、ソースポート、仕向港、プロトコル)の5-tupleを使用して。 また、DiffServ Multi-分野(MF)クラシファイアは、サポートしている振舞い集合に個々の交通の流れを写像するのにこの5-tupleを使用できます。
The use of IPSEC, NAT and various forms of IP tunnels result in a occlusion of the flow identification within the IP packet header, combining individual flows into a larger aggregate state that may be too coarse for the network's service policies. The issue with such mechanisms is that they may occur within the network path in a fashion that is not visible to the end application, compromising the ability for the application to determine whether the requested service profile is being delivered by the network. In the case of IPSEC there is a proposal to carry the IPSEC Security Parameter Index (SPI) in the RSVP object [10], as a surrogate for the port addresses. In the case of NAT and various forms of IP tunnels, there appears to be no coherent way to preserve fine-grained classification characteristics across NAT devices, or across tunnel encapsulation.
IPのIPSECの使用、NAT、および様々なフォームはIPパケットのヘッダーの中で流れ識別の閉塞における結果にトンネルを堀ります、ネットワークのサービス方策には、下品過ぎるかもしれない集合より大きい州への個々の流れを結合して。 そのようなメカニズムの問題はネットワーク経路の中にエンドアプリケーションに目に見えないファッションで起こるかもしれないということです、アプリケーションが、要求されたサービスプロフィールがネットワークによって提供されているかどうか決定する能力に感染して。 IPSECの場合には、RSVPオブジェクト[10]でIPSEC Security Parameter Index(SPI)を運ぶという提案があります、ポートアドレスへの代理として。 NATに関するケースと様々な形式のIPトンネルでは、あるようにNATデバイスの向こう側に、または、トンネルカプセル化の向こう側にきめ細かに粒状の分類の特性を保存するどんな論理的な方法にも見えません。
IP packet fragmentation also affects the ability of the network to identify individual flows, as the trailing fragments of the IP packet will not include the TCP or UDP port address information. This admits
また、IPパケット断片化はネットワークが個々の流れを特定する能力に影響します、IPパケットの引きずっている断片がTCPかUDPポートアドレス情報を含まないとき。 これは認められます。
Huston Informational [Page 13] RFC 2990 Next Steps for QoS Architecture November 2000
QoSアーキテクチャ2000年11月のための次のヒューストンInformational[13ページ]のRFC2990ステップ
the possibility of trailing fragments of a packet within a distinguished service class being classified into the base best effort service category, and delaying the ultimate delivery of the IP packet to the destination until the trailing best effort delivered fragments have arrived.
引きずっているベストエフォート型提供された断片が届くまでベースのベストエフォート型サービスカテゴリに分類されて、IPパケットの究極の配送を目的地に遅らせるのであるので偉勲のクラスの中でパケットの断片を引きずる可能性。
The observation made here is that QoS services do have a number of caveats that should be placed on both the application and the network. Applications should perform path MTU discovery in order to avoid packet fragmentation. Deployment of various forms of payload encryption, header address translation and header encapsulation should be undertaken with due attention to their potential impacts on service delivery packet classifiers.
ここでされた観測はQoSサービスにはアプリケーションとネットワークの両方に置かれるべきである多くの警告があるということです。 アプリケーションは、パケット断片化を避けるために経路MTU探索を実行するべきです。 様々な形式のペイロード暗号化、ヘッダーアドレス変換、およびヘッダーカプセル化の展開はサービス配送パケットクラシファイアの上でそれらの可能性のある衝撃に関する当然の注意で引き受けられるべきです。
3.7 The Service Set
3.7 サービスはセットしました。
The underlying question posed here is how many distinguished service responses are adequate to provide a functionally adequate range of service responses?
ここで提出された基本的な質問はいくつの偉勲応答が機能上適切な範囲のサービス応答を提供するために適切であるかということですか?
The Differentiated Services architecture does not make any limiting restrictions on the number of potential services that a network operator can offer. The network operator may be limited to a choice of up to 64 discrete services in terms of the 6 bit service code point in the IP header but as the mapping from service to code point can be defined by each network operator, there can be any number of potential services.
Differentiated Servicesアーキテクチャはネットワーク・オペレータが提供できる潜在的サービスの数における少しの制限制限もしません。 ネットワーク・オペレータはIPヘッダーの6つのビット・サービスコード・ポイントで最大64の離散的なサービスの選択に制限されるかもしれませんが、各ネットワーク・オペレータがコード・ポイントに対するサービスからのマッピングを定義できるので、いろいろな潜在的サービスがあることができます。
As always, there is such a thing as too much of a good thing, and a large number of potential services leads to a set of issues around end-to-end service coherency when spanning multiple network domains. A small set of distinguished services can be supported across a large set of service providers by equipment vendors and by application designers alike. An ill-defined large set of potential services often serves little productive purpose. This does point to a potential refinement of the QoS architecture to define a small core set of service profiles as "well-known" service profiles, and place all other profiles within a "private use" category.
いつものように、ありがた迷惑のようなもの、および複数のネットワークドメインにかかるときの終わりから終わりへのサービス一貫性の周りの1セットの問題への多くの潜在的サービス先導があります。 設備ベンダーとアプリケーション設計者は大きいセットのサービスプロバイダーの向こう側に同じく小さいセットの功績をサポートすることができます。 ほとんど定義されなかった大きい潜在的サービスはしばしばほとんど生産目的に役立つというわけではありません。 これは、サービスが輪郭を描く「よく知られる」としてのサービスプロフィールの小さい巻き癖を定義して、「私用」カテゴリの中に他のすべてのプロフィールを置くためにQoSアーキテクチャの潜在的気品を示します。
3.8 Measuring Service Delivery
3.8 測定サービス配送
There is a strong requirement within any QoS architecture for network management approaches that provide a coherent view of the operating state of the network. This differs from a conventional element-by- element management view of the network in that the desire here is to be able to provide a view of the available resources along a
ネットワークの作動状態の論理的な意見を提供するネットワークマネージメントアプローチのためのどんなQoSアーキテクチャの中にも強い要件があります。 これはここでの願望がaに沿って利用可能資源に関する意見を提供することであることができるという点において経営者側が見るネットワークの近く従来の要素原理と異なっています。
Huston Informational [Page 14] RFC 2990 Next Steps for QoS Architecture November 2000
QoSアーキテクチャ2000年11月のための次のヒューストンInformational[14ページ]のRFC2990ステップ
particular path within a network, and map this view to an admission control function which can determine whether to admit a service differentiated flow along the nominated network path.
入場へのこの視点が制御するネットワーク、および地図の中のそれの缶がサービスを認めるかどうか決定する特定の経路は機能します。指名ネットワーク経路に沿って流れを差別化しました。
As well as managing the admission systems through resource availability measurement, there is a requirement to be able to measure the operating parameters of the delivered service. Such measurement methodologies are required in order to answer the question of how the network operator provides objective measurements to substantiate the claim that the delivered service quality conformed to the service specifications. Equally, there is a requirement for a measurement methodology to allow the client to measure the delivered service quality so that any additional expense that may be associated with the use of premium services can be justified in terms of superior application performance.
リソース有用性測定で入場システムを管理することと同様に、提供されたサービスに関する運転パラメータを測定できるという要件があります。 そのような測定方法論が、ネットワーク・オペレータが提供されたサービス品質がサービス仕様に従ったというクレームを実体化するためにどう客観的計測値を提供するかに関する質問に答えるのに必要です。 等しく、クライアントが優れたアプリケーション性能でどんなプレミアムサービスの使用に関連するかもしれない追加費用も正当化できるように測定方法論で提供されたサービス品質を測定できるという要件があります。
Such measurement methodologies appear to fall within the realm of additional refinement to the QoS architecture.
そのような測定方法論は追加気品の分野の中でQoSアーキテクチャに落下するように見えます。
3.9 QoS Accounting
3.9 QoS会計
It is reasonable to anticipate that such forms of premium service and customized service will attract an increment on the service tariff. The provision of a distinguished service is undertaken with some level of additional network resources to support the service, and the tariff premium should reflect this altered resource allocation. Not only does such an incremental tariff shift the added cost burden to those clients who are requesting a disproportionate level of resources, but it provides a means to control the level of demand for premium service levels.
そのような形式のプレミアムサービスとカスタマイズされたサービスがサービス関税で増分を引き付けると予期するのは妥当です。 偉勲の支給は何らかのレベルの追加ネットワーク資源で引き受けられて、サービスをサポートする、関税プレミアムはこの変えられた資源配分を反映するべきです。 そのような増加の関税が不均衡なレベルに関するリソースを要求しているクライアントに加えられた費用負担を移行させるだけではなく、それはプレミアムサービスレベルの要求のレベルを制御する手段を提供します。
If there are to be incremental tariffs on the use of premium services, then some accounting of the use of the premium service would appear to be necessary relating use of the service to a particular client. So far there is no definition of such an accounting model nor a definition as to how to gather the data to support the resource accounting function.
プレミアムサービスの使用に増加の関税があれば、プレミアムサービスの使用の何らかの会計が特定のクライアントとサービスの使用を関係がありながら必要であるように見えるでしょう。 そのような会計モデルの定義が全くありません。または、リソースが会計機能であるとサポートするためにどうデータを集めるかに関する定義。
The impact of this QoS service model may be quite profound to the models of Internet service provision. The commonly adopted model in both the public internet and within enterprise networks is that of a model of access, where the clients service tariff is based on the characteristics of access to the services, rather than that of the actual use of the service. The introduction of QoS services creates a strong impetus to move to usage-based tariffs, where the tariff is based on the level of use of the network's resources. This, in turn, generates a requirement to meter resource use, which is a form of usage accounting. This topic was been previously studied within the
インターネットのサービス支給のモデルに、このQoSサービスモデルの影響はかなり深遠であるかもしれません。 公共のインターネットと企業網の中の両方の一般的に採用されたモデルはアクセスのモデルでは、クライアントがどこで関税を修理するかがサービスの実際の使用のものよりむしろサービスへのアクセスの特性に基づいているということです。 QoSサービスの導入は、用法ベースの関税に移行するために強い起動力を作成します。(そこでは、関税がネットワークのリソースで役に立つレベルに基づいています)。 これは順番に、用法会計のフォームであるリソース使用を計量するという要件を生成します。 この話題がそうであった、以前に、研究されます。
Huston Informational [Page 15] RFC 2990 Next Steps for QoS Architecture November 2000
QoSアーキテクチャ2000年11月のための次のヒューストンInformational[15ページ]のRFC2990ステップ
IETF under the topic of "Internet Accounting" [11], and further refinement of the concepts used in this model, as they apply to QoS accounting may prove to be a productive initial step in formulating a standards-based model for QoS accounting.
「インターネット会計」[11]の話題、会計がQoS会計で規格ベースのモデルを定式化することにおける産出力がある初期段階であると立証するかもしれないQoSに適用するのでこのモデルで使用される概念のさらなる気品でのIETF。
3.10 QoS Deployment Diversity
3.10 QoS展開の多様性
It is extremely improbable that any single form of service differentiation technology will be rolled out across the Internet and across all enterprise networks.
どんなただ一つのフォームのサービス分化技術もインターネットの向こう側にすべての企業網の向こう側に発表されるのは、非常にありそうもないです。
Some networks will deploy some form of service differentiation technology while others will not. Some of these service platforms will interoperate seamlessly and other less so. To expect all applications, host systems, network routers, network policies, and inter-provider arrangements to coalesce into a single homogeneous service environment that can support a broad range of service responses is an somewhat unlikely outcome given the diverse nature of the available technologies and industry business models. It is more likely that we will see a number of small scale deployment of service differentiation mechanisms and some efforts to bridge these environments together in some way.
いくつかのネットワークが他のものが配布しない間、何らかのフォームのサービス分化技術を配布するでしょう。 したがって、これらのサービスプラットホームのいくつかがそれほどシームレスに、そして別に共同利用しないでしょう。 利用可能な技術と産業ビジネスモデルのさまざまの自然を考えて、すべてのアプリケーション、ホストシステム、ネットワークルータ、ネットワーク方針、および相互プロバイダーアレンジメントが広範囲なサービスが応答であるとサポートすることができるただ一つの均質のサービス環境と合体すると予想するのは、いくらかありそうもない結果です。 私たちがこれらの環境を一緒に何らかの方法でブリッジするためにサービス分化メカニズムといくつかの取り組みの多くの小規模展開を見るのは、おそらくです。
In this heterogeneous service environment the task of service capability discovery is as critical as being able to invoke service responses and measure the service outcomes. QoS architectures will need to include protocol capabilities in supporting service discovery mechanisms.
この異種のサービス環境では、サービス能力発見のタスクはサービス応答を呼び出して、サービス結果を測定できるのと同じくらい重要です。 QoSアーキテクチャは、サービス発見がメカニズムであるとサポートする際にプロトコル能力を含む必要があるでしょう。
In addition, such a heterogeneous deployment environment will create further scaling pressure on the operational network as now there is an additional dimension to the size of the network. Each potential path to each host is potentially qualified by the service capabilities of the path. While one path may be considered as a candidate best effort path, another path may offer a more precise match between the desired service attributes and the capabilities of the path to sustain the service. Inter-domain policy also impacts upon this path choice, where inter-domain transit agreements may specifically limit the types and total level of quality requests than may be supported between the domains. Much of the brunt of such scaling pressures will be seen in the inter-domain and intra-domain routing domain where there are pressures to increase the number of attributes of a routing entry, and also to use the routing protocol in some form of service signaling role.
さらに、現在のようにそこでさらに操作上のネットワークに対する圧力をスケーリングする環境が作成するそのような異種の展開はネットワークのサイズへの追加寸法です。 各ホストへのそれぞれの潜在的経路は経路のサービス能力によって潜在的に資格があります。 1つの経路が候補のベストエフォート型道であるとみなされているかもしれない間、別の経路は必要なサービス属性とサービスを維持する経路の能力との、より正確なマッチを提供するかもしれません。 また、相互ドメイン方針にこの経路選択のときに影響を与えます。そこでは、相互ドメイントランジット協定がドメインの間でサポートされるかもしれないより明確にタイプと総レベルの上質の要求を制限するかもしれません。 そのようなスケーリング圧力のほこさきの多くは相互ドメインで見られるのとルーティングエントリーの属性の数を増強して、また、何らかのフォームでルーティング・プロトコルを使用する圧力があるところにドメインを発送するイントラドメインサービスシグナリングが役割であったならそうするでしょう。
Huston Informational [Page 16] RFC 2990 Next Steps for QoS Architecture November 2000
QoSアーキテクチャ2000年11月のための次のヒューストンInformational[16ページ]のRFC2990ステップ
3.11 QoS Inter-Domain signaling
3.11 QoS Inter-ドメインシグナリング
QoS Path selection is both an intra-domain (interior) and an inter- domain (exterior) issue. Within the inter-domain space, the current routing technologies allow each domain to connect to a number of other domains, and to express its policies with respect to received traffic in terms of inter-domain route object attributes. Additionally, each domain may express its policies with respect to sending traffic through the use of boundary route object filters, allowing a domain to express its preference for selecting one domain's advertised routes over another. The inter-domain routing space is a state of dynamic equilibrium between these various route policies.
QoS Path選択はイントラドメイン(内部の)と相互ドメインの(外)の問題の両方です。 相互ドメインスペースの中では、現在のルーティング技術で、各ドメインは、他の多くのドメインに接続して、容認されたトラフィックに関して相互ドメインルートオブジェクト属性に関して方針を言い表します。 さらに、ドメインが好みを言い表すのを許容して、1つのドメインを選択するのが別のものの上にルートの広告を出したので、各ドメインは送付トラフィックに関して境界ルートオブジェクトフィルタの使用で方針を言い表すかもしれません。 相互ドメインルーティングスペースはこれらの様々なルート方針の間の動的平衡の状態です。
The introduction of differentiated services adds a further dimension to this policy space. For example, while a providers may execute an interconnection agreement with one party to exchange best effort traffic, it may execute another agreement with a second party to exchange service qualified traffic. The outcome of this form of interconnection is that the service provider will require external route advertisements to be qualified by the accepted service profiles. Generalizing from this scenario, it is reasonable to suggest that we will require the qualification of routing advertisements with some form of service quality attributes. This implies that we will require some form of quality vector-based forwarding function, at least in the inter-domain space, and some associated routing protocol can pass a quality of service vector in an operationally stable fashion.
差別化されたサービスの導入はこの方針スペースにさらなる寸法を加えます。 例えば、プロバイダーがベストエフォート型トラフィックを交換するために1回のパーティーとのインタコネクト協定を執行しているかもしれない間、それは別の協定を交換サービス適切なトラフィックへの2番目のパーティーと共に執行するかもしれません。 このフォームのインタコネクトの結果はサービスプロバイダーが、外部経路広告が受け入れられたサービスプロフィールによって資格があるのを必要とするということです。 このシナリオから導き出して、私たちが何らかのフォームのサービス品質属性でルーティング広告の資格を必要とするつもりであるのを示すのは妥当です。 これは、私たちが少なくとも相互ドメインスペースで何らかのフォームの上質のベクトルベースの推進関数を必要とするつもりであるのを含意します、そして、何らかの関連ルーティング・プロトコルが操作上安定したファッションでサービスの質ベクトルを通過できます。
The implication of this requirement is that the number of objects being managed by routing systems must expand dramatically, as the size and number of objects managed within the routing domain increases, and the calculation of a dynamic equilibrium of import and export policies between interconnected providers will also be subject to the same level of scaling pressure.
この要件の含意はルーティングシステムによって管理されるオブジェクトの数が劇的に広がらなければならないということです、経路ドメインの中で管理されたオブジェクトのサイズと数が増加して、また、インタコネクトされたプロバイダーの間の輸出入方針の動的平衡の計算が同じレベルのスケーリング圧力を被りやすくなるとき。
This has implications within the inter-domain forwarding space as well, as the forwarding decision in such a services differentiated environment is then qualified by some form of service quality vector. This is required in order to pass exterior traffic to the appropriate exterior interconnection gateway.
これはまた、スペースを進めながら、相互ドメインの中に意味を持っていて、そのようなサービスにおける推進決定が差別化したので、次に、環境は何らかのフォームのサービス品質ベクトルによって資格があります。 これが、適切な外のインタコネクトゲートウェイに外のトラフィックを通過するのに必要です。
3.12 QoS Deployment Logistics
3.12 QoS展開ロジスティクス
How does the widespread deployment of service-aware networks commence? Which gets built first - host applications or network infrastructure?
サービス意識しているネットワークの広範囲の展開はどのように始まりますか? どれが最初に、建てられますか?--ホストアプリケーションですかそれともネットワークインフラですか?
Huston Informational [Page 17] RFC 2990 Next Steps for QoS Architecture November 2000
QoSアーキテクチャ2000年11月のための次のヒューストンInformational[17ページ]のRFC2990ステップ
No network operator will make the significant investment in deployment and support of distinguished service infrastructure unless there is a set of clients and applications available to make immediate use of such facilities. Clients will not make the investment in enhanced services unless they see performance gains in applications that are designed to take advantage of such enhanced services. No application designer will attempt to integrate service quality features into the application unless there is a model of operation supported by widespread deployment that makes the additional investment in application complexity worthwhile and clients who are willing to purchase such applications. With all parts of the deployment scenario waiting for the others to move, widespread deployment of distinguished services may require some other external impetus.
どんなネットワーク・オペレータも1セットのクライアントとそのような施設の即座の使用をするように手があいている利用がないと偉勲インフラストラクチャの展開とサポートへの重要な投資をしないでしょう。 クライアントはそのような高度サービスを利用するように設計されているアプリケーションにおける性能向上を見ないと高度サービスへの投資をしないでしょう。 アプリケーションの複雑さへの追加出資を価値があるようにする広範囲の展開とそのようなアプリケーションを購入しても構わないと思っているクライアントによってサポートされた操作のモデルがないと、どんなアプリケーション設計者も、品質がアプリケーションに特徴とするサービスを統合するのを試みないでしょう。 展開シナリオのすべての部分が、他のものが移行するのを待っていて、功績の広範囲の展開はある他の外部の起動力を必要とするかもしれません。
Further aspects of this deployment picture lie in the issues of network provisioning and the associated task of traffic engineering. Engineering a network to meet the demands of best effort flows follows a well understood pattern of matching network points of user concentrations to content delivery network points with best effort paths. Integrating QoS-mediated traffic engineering into the provisioning model suggests a provisioning requirement that also requires input from a QoS demand model.
この展開画像のさらなる局面がネットワークの食糧を供給することの問題と交通工学の関連タスクにあります。 ベストエフォート型流れの需要にこたえるためにネットワークを設計すると、内容物配送ネットワークポイントへの合っているネットワークポイントのユーザ集中のよく理解されているパターンはベストエフォート型経路で従われます。 QoSによって調停された交通工学を食糧を供給しているモデルと統合すると、また、入力を必要とする食糧を供給する要件はQoS要求モデルから示されます。
4. The objective of the QoS architecture
4. QoSアーキテクチャの目的
What is the precise nature of the problem that QoS is attempting to solve? Perhaps this is one of the more fundamental questions underlying the QoS effort, and the diversity of potential responses is a pointer to the breadth of scope of the QoS effort.
QoSが解決するのを試みている正確な問題の性格は何ですか? 恐らく、これはQoS取り組みの基礎となるより基本的な質問の1つです、そして、潜在的応答の多様性はQoS取り組みの範囲の幅への指針です。
All of the following responses form a part of the QoS intention:
以下の応答のすべてがQoS意志の一部を形成します:
- To control the network service response such that the response
to a specific service element is consistent and predictable.
- 特定のサービス要素への応答は、ネットワークを制御するために、応答を修理してください。そうすれば、一貫していて予測できます。
- To control the network service response such that a service
element is provided with a level of response equal to or above a
guaranteed minimum.
- ネットワークを制御するために、応答を修理してください。そうすれば、最低保証額か最低保証額を超えて等しい応答のレベルをサービス要素に提供します。
- To allow a service element to establish in advance the service
response that can or will be obtained from the network.
- サービス要素があらかじめサービス応答を確立するのを許容するために、それを得ることができるか、またはネットワークから得るでしょう。
- To control the contention for network resources such that a
service element is provided with a superior level of network
resource.
- サービス要素がそのようなものですが、ネットワーク資源のための主張を制御するのは優れたレベルのネットワーク資源に提供しました。
Huston Informational [Page 18] RFC 2990 Next Steps for QoS Architecture November 2000
QoSアーキテクチャ2000年11月のための次のヒューストンInformational[18ページ]のRFC2990ステップ
- To control the contention for network resources such that a
service element does not obtain an unfair allocation of
resources (to some definition of 'fairness').
- ネットワーク資源のための主張を制御するために、サービス要素がするそのようなものはリソース('公正'の何らかの定義への)の不公平な配分を得ません。
- To allow for efficient total utilization of network resources
while servicing a spectrum of directed network service outcomes.
- 指示されたネットワークのスペクトルを修理している間、ネットワーク資源の効率的な総利用を考慮するには、結果を修理してください。
Broadly speaking, the first three responses can be regarded as 'application-centric', and the latter as 'network-centric'. It is critical to bear in mind that none of these responses can be addressed in isolation within any effective QoS architecture. Within the end-to-end architectural model of the Internet, applications make minimal demands on the underlying IP network. In the case of TCP, the protocol uses an end-to-end control signal approach to dynamically adjust to the prevailing network state. QoS architectures add a somewhat different constraint, in that the network is placed in an active role within the task of resource allocation and service delivery, rather than being a passive object that requires end systems to adapt.
概して、最初の3つの応答が、'アプリケーション中心'と見なされて'ネットワーク中心'として後者であるかもしれません。 分離してどんな有効なQoSアーキテクチャの中でもこれらの応答のどれかを扱うことができないのを覚えておくのは重要です。 終わりから終わりへのインターネットの建築モデルの中では、アプリケーションは基本的なIPネットワークで最小量の要求をします。 TCPの場合では、プロトコルは、ダイナミックに行き渡っているネットワーク状態に適応するのに終わりから終わりへのコントロール信号アプローチを使用します。 QoSアーキテクチャはいくらか異なった規制を加えます、ネットワークが適合するようにエンドシステムを必要とする受け身の目的であるより資源配分とサービス配送に関するタスクの中にむしろ積極的役割に置かれるので。
5. Towards an end-to-end QoS architecture
5. 終わりから終わりへのQoSアーキテクチャに向かって
The challenge facing the QoS architecture lies in addressing the weaknesses noted above, and in integrating the various elements of the architecture into a cohesive whole that is capable of sustaining end-to-end service models across a wide diversity of internet platforms. It should be noted that such an effort may not necessarily result in a single resultant architecture, and that it is possible to see a number of end-to-end approaches based on different combinations of the existing components.
上に述べられた弱点を扱って、インターネットプラットホームの広い多様性の向こう側に終わりから終わりへのサービスモデルを支えることができる粘着性がある全体とアーキテクチャの様々な原理を統合するのにおいてQoSアーキテクチャに直面している挑戦があります。そのような取り組みが必ずただ一つの結果のアーキテクチャをもたらすかもしれないというわけではなくて、終わりから終わりへの多くのアプローチが既存のコンポーネントの異なった組み合わせに基づいているのを見るのが可能であることに注意されるべきです。
One approach is to attempt to combine both architectures into an end-to-end model, using IntServ as the architecture which allows applications to interact with the network, and DiffServ as the architecture to manage admission the network's resources [7]. In this approach, the basic tension that needs to be resolved lies in difference between the per-application view of the IntServ architecture and the network boundary-centric view of the DiffServ architecture.
1つのアプローチは入場を管理するのにアプリケーションがネットワークと対話できるアーキテクチャとしてIntServを使用して、アーキテクチャとしてDiffServを使用して、両方のアーキテクチャを結合するのを試みるために、終わりから終わりまで、ネットワークのリソース[7]にモデル化されているということです。 このアプローチ、IntServアーキテクチャの1アプリケーションあたりの視点とネットワークの違いにおける決心している偽りがDiffServアーキテクチャの境界中心の視点であったなら必要がある基本的な緊張で。
One building block for such an end-to-end service architecture is a service signaling protocol. The RSVP signaling protocol can address the needs of applications that require a per-service end-to-end service signaling environment. The abstracted model of RSVP is that of a discovery signaling protocol that allows an application to use a single transaction to communicate its service requirements to both the network and the remote party, and through the response mechanism, to allow these network elements to commit to the service
終わりから終わりへのサービスそのようなアーキテクチャのための1つのブロックがサービスシグナリングプロトコルです。 RSVPシグナリングプロトコルは1サービスあたりの終わりから終わりへのサービスシグナリング環境を必要とするアプリケーションの必要性を扱うことができます。 RSVPの放心しているモデルは、これらのネットワーク要素がサービスに公約されるのを許容するためにはアプリケーションがネットワークとリモートパーティーの両方と、反応機構を通してサービス要件を伝えるのに単一取引を使用できる発見シグナリングプロトコルのものです。
Huston Informational [Page 19] RFC 2990 Next Steps for QoS Architecture November 2000
QoSアーキテクチャ2000年11月のための次のヒューストンInformational[19ページ]のRFC2990ステップ
requirements. The barriers to deployment for this model lie in an element-by element approach to service commitment, implying that each network element must undertake some level of signaling and processing as dictated by this imposed state. For high precision services this implies per-flow signaling and per-flow processing to support this service model. This fine-grained high precision approach to service management is seen as imposing an unacceptable level of overhead on the central core elements of large carrier networks.
要件。 このモデルのための展開へのバリアは委任を修理するために近く要素要素アプローチで位置しています、この強要された状態によって決められるようにそれぞれのネットワーク要素が何らかのレベルのシグナリングと処理を引き受けなければならないのを含意して。 高い精度サービスのために、これは、このサービスモデルをサポートするために処理しながら、1流れあたりのシグナリングと流れを含意します。 大きいキャリヤーネットワークの主要な炉心構成要素に容認できないレベルのオーバーヘッドを課すとき、サービス管理へのこのきめ細かに粒状の高い精度アプローチは見られます。
The DiffServ approach uses a model of abstraction which attempts to create an external view of a compound network as a single subnetwork. From this external perspective the network can be perceived as two boundary service points, ingress and egress. The advantage of this approach is that there exists the potential to eliminate the requirement for per-flow state and per-flow processing on the interior elements of such a network, and instead provide aggregate service responses.
DiffServアプローチは単一のサブネットワークとして複合ネットワークの外部の視点を作成するのを試みる抽象化のモデルを使用します。 この外部の見解から、2つの境界サービスポイント、イングレス、および出口としてネットワークを知覚できます。 このアプローチの利点はそのようなネットワークの内部の原理で1流れあたりの状態と1流れあたりの処理のための要件を排除する可能性が存在しているということです、そして、代わりに集合サービス応答を提供してください。
One approach is for applications to use RSVP to request that their flows be admitted into the network. If a request is accepted, it would imply that there is a committed resource reservation within the IntServ-capable components of the network, and that the service requirements have been mapped into a compatible aggregate service class within the DiffServ-capable network [7]. The DiffServ core must be capable of carrying the RSVP messages across the DiffServ network, so that further resource reservation is possible within the IntServ network upon egress from the DiffServ environment. The approach calls for the DiffServ network to use per-flow multi-field (MF) classifier, where the MF classification is based on the RSVP- signaled flow specification. The service specification of the RSVP- signaled resource reservation is mapped into a compatible aggregate DiffServ behavior aggregate and the MF classifier marks packets according to the selected behavior. Alternatively the boundary of the IntServ and DiffServ networks can use the IntServ egress to mark the flow packets with the appropriate DSCP, allowing the DiffServ ingress element to use the BA classifier, and dispense with the per- flow MF classifier.
1つのアプローチはアプリケーションがそれらの流れがネットワークに認められるよう要求するのにRSVPを使用することです。 要求を受け入れるなら、それはネットワークのIntServできる成分の中に遂行された資源予約があって、サービス要件がDiffServできるネットワーク[7]の中でコンパチブル集合サービスのクラスに写像されたのを含意するでしょう。 DiffServコアはDiffServネットワークの向こう側にRSVPメッセージを伝えることができなければなりません、さらなる資源予約が出口のIntServネットワークの中でDiffServ環境から可能であるように。 アプローチは、DiffServネットワークが1流れあたりのマルチ分野(MF)クラシファイアを使用するように求めます、MF分類がRSVPの合図された流れ仕様に基づいているところで。 RSVPの合図された資源予約のサービス仕様はコンパチブル集合DiffServ振舞い集合に写像されます、そして、選択された振舞いに従って、MFクラシファイアはパケットをマークします。 あるいはまた、IntServとDiffServネットワークの限界がDiffServイングレス要素がBAクラシファイアを使用するのを許容して、適切なDSCPと共に流れパケットであるとマークして、特免するIntServ出口を使用できる、-、流れMFクラシファイア。
A high precision end-to-end QoS model requires that any admission failure within the DiffServ network be communicated to the end application, presumably via RSVP. This allows the application to take some form of corrective action, either by modifying it's service requirements or terminating the application. If the service agreement between the DiffServ network is statically provisioned, then this static information can be loaded into the IntServ boundary systems, and IntServ can manage the allocation of available DiffServ behavior aggregate resources. If the service agreement is
精度終わりから終わりへのQoS高いモデルは、DiffServネットワークの中のどんな入場失敗もエンドアプリケーションに伝えられるのを必要とします、おそらくRSVPを通して。 それは、どちらか変更することによって、これで、アプリケーションが何らかの形式の修正措置を取ることができますか、サービス要件またはアプリケーションを終えることです。 DiffServネットワークの間のサービス契約が静的に食糧を供給されるなら、この静的な情報をIntServ境界系にロードできます、そして、IntServは利用可能なDiffServ振舞い集合リソースの配分に対処できます。 サービス契約がそうなら
Huston Informational [Page 20] RFC 2990 Next Steps for QoS Architecture November 2000
QoSアーキテクチャ2000年11月のための次のヒューストンInformational[20ページ]のRFC2990ステップ
dynamically variable, some form of signaling is required between the two networks to pass this resource availability information back into the RSVP signaling environment.
ダイナミックに、可変です、何らかのフォームのシグナリングが、このリソース有用性情報をRSVPシグナリング環境に戻すのに2つのネットワークの間で必要です。
6. Conclusions
6. 結論
None of these observations are intended to be any reason to condemn the QoS architectures as completely impractical, nor are they intended to provide any reason to believe that the efforts of deploying QoS architectures will not come to fruition.
これらの観測のいずれも完全に非実用的であるとしてQoSアーキテクチャを非難するどんな理由であることも意図しません、そして、QoSがアーキテクチャであると配布する取り組みが実を結ばないと信じるどんな理由も提供することを意図しません。
What this document is intended to illustrate is that there are still a number of activities that are essential precursors to widespread deployment and use of such QoS networks, and that there is a need to fill in the missing sections with something substantial in terms of adoption of additional refinements to the existing QoS model.
このドキュメントが例証することを意図することはそのようなQoSネットワークの広範囲の展開と使用への不可欠の先駆である多くの活動がまだあって、既存のQoSモデルに、追加気品の採用で何か実質的なものでなくなったセクションに記入する必要があるということです。
The architectural direction that appears to offer the most promising outcome for QoS is not one of universal adoption of a single architecture, but instead use a tailored approach where aggregated service elements are used in the core of a network where scalability is a major design objective and use per-flow service elements at the edge of the network where accuracy of the service response is a sustainable outcome.
集められたサービス要素がスケーラビリティが主要な設計目標であるネットワークのコアで使用されるところで代わりにオーダーメイドのアプローチを使用して、サービス応答の精度が持続可能な結果であるネットワークの縁で1流れあたりのサービス要素を使用するのを除いた大部分が1でないとQoSのための結果に約束するただ一つのアーキテクチャの普遍的な採用の申し出に現れる建築方向。
Architecturally, this points to no single QoS architecture, but rather to a set of QoS mechanisms and a number of ways these mechanisms can be configured to interoperate in a stable and consistent fashion.
建築上、これは、安定して一貫したファッションで共同利用するためにメカニズムとこれらのメカニズムを構成できる多くの方法をむしろただ一つのQoSアーキテクチャではなく、QoSの1セットに示します。
7. Security Considerations
7. セキュリティ問題
The Internet is not an architecture that includes a strict implementation of fairness of access to the common transmission and switching resource. The introduction of any form of fairness, and, in the case of QoS, weighted fairness, implies a requirement for transparency in the implementation of the fairness contract between the network provider and the network's users. This requires some form of resource accounting and auditing, which, in turn, requires the use of authentication and access control. The balancing factor is that a shared resource should not overtly expose the level of resource usage of any one user to any other, so that some level of secrecy is required in this environment
インターネットは一般的なトランスミッションと切り換えリソースへのアクセスの公正の厳しい実装を含んでいるアーキテクチャではありません。 どんなフォームの公正の導入、およびQoSの場合における荷重している公正もネットワーク内の提供者とネットワークのユーザとの公正契約の実装における透明のための要件を含意します。 これは何らかのフォームのリソース会計学と会計監査学を必要とします。(順番に、会計学と会計監査学は認証とアクセスコントロールの使用を必要とします)。 釣り合いを保つ要因は共用資源がどんなユーザのリソース使用法のレベルもいかなる他のも明白に暴露するべきでないということです、何らかのレベルの秘密保持がこの環境で必要であるように
The QoS environment also exposes the potential of theft of resources through the unauthorized admission of traffic with an associated service profile. QoS signaling protocols which are intended to
また、QoS環境は関連サービスプロフィールによるトラフィックの権限のない入場によるリソースの窃盗の可能性を暴露します。 意図するQoSシグナリングプロトコル
Huston Informational [Page 21] RFC 2990 Next Steps for QoS Architecture November 2000
QoSアーキテクチャ2000年11月のための次のヒューストンInformational[21ページ]のRFC2990ステップ
undertake resource management and admission control require the use of identity authentication and integrity protection in order to mitigate this potential for theft of resources.
資源管理を引き受けてください。そうすれば、入場コントロールは、リソースの窃盗のこの可能性を緩和するためにアイデンティティ認証と保全保護の使用を必要とします。
Both forms of QoS architecture require the internal elements of the network to be able to undertake classification of traffic based on some form of identification that is carried in the packet header in the clear. Classifications systems that use multi-field specifiers, or per-flow specifiers rely on the carriage of end-to-end packet header fields being carried in the clear. This has conflicting requirements for security architectures that attempt to mask such end-to-end identifiers within an encrypted payload.
QoSアーキテクチャの両方のフォームは、ネットワークの内部の原理が明確でパケットのヘッダーで運ばれる何らかの形式の識別に基づくトラフィックの分類を引き受けることができるのを必要とします。 マルチ分野特許説明書の作成書を使用する分類システム、または特許説明書の作成書がキャリッジを当てにする流れ終わりから終わりへのパケット明確で運ばれるヘッダーフィールド。 これには、暗号化されたペイロードの中に終わりから終わりへのそのような識別子にマスクをかけるのを試みるセキュリティー体系のための競合する要求事項があります。
QoS architectures can be considered as a means of exerting control over network resource allocation. In the event of a rapid change in resource availability (e.g. disaster) it is an undesirable outcome if the remaining resources are completely allocated to a single class of service to the exclusion of all other classes. Such an outcome constitutes a denial of service, where the traffic control system (routing) selects paths that are incapable of carrying any traffic of a particular service class.
ネットワーク資源配分のコントロールを及ぼす手段であるとQoSアーキテクチャをみなすことができます。 リソースの有用性(例えば、災害)における急激な変化の場合、他のすべてのクラスを除外して1つのクラスのサービスに残っているリソースを完全に割り当てるなら、それは望ましくない結果です。 そのような結果はサービスの否定を構成します、交通管制システム(ルーティング)が特定のサービスのクラスの少しのトラフィックも運ぶことができない経路を選択するところで。
8. References
8. 参照
[1] Bradner, S., "The Internet Standards Process- Revision 3", BCP
9, RFC 2026, October 1996.
[1] ブラドナー、S.、「インターネット規格は1996年10月に改正3インチ、BCP9、RFC2026を処理します」。
[2] Mankin, A., Baker, F., Braden, R., O'Dell, M., Romanow, A.,
Weinrib, A. and L. Zhang, "Resource ReSerVation Protocol (RSVP)
Version 1 Applicability Statement", RFC 2208, September 1997.
[2] マンキンとA.とベイカーとF.とブレーデンとR.とオデルとM.とRomanowとA.とWeinribとA.とL.チャン、「資源予約プロトコル(RSVP)バージョン1適用性証明」、RFC2208、1997年9月。
[3] Braden. R., Clark, D. and S. Shenker, "Integrated Services in
the Internet Architecture: an Overview", RFC 1633, June 1994.
[3] ブレーデン。 R.、クラーク、D.、およびS.Shenker、「インターネットアーキテクチャにおける統合サービス:」 「概要」、RFC1633、1994年6月。
[4] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W.
Weiss, "An Architecture for Differentiated Services", RFC 2475,
December 1998.
[4] ブレークとS.と黒とD.とカールソンとM.とデイヴィースとE.とワングとZ.とW.ウィス、「差別化されたサービスのためのアーキテクチャ」、RFC2475、1998年12月。
[5] Baker, F., Iturralde, C., Le Faucher, F., Davie, B.,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", Work in
Progress.
[5] ベイカー、F.、イトゥラルデ、C.、Leファウチャー、F.、デイビー、B.、「IPv4のためのRSVPとIPv6予約の集合」が進行中で働いています。
[6] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996,
November 2000.
[6]Bernet、Y.、「RSVP DCLASSオブジェクトの形式」、RFC2996、2000年11月。
Huston Informational [Page 22] RFC 2990 Next Steps for QoS Architecture November 2000
QoSアーキテクチャ2000年11月のための次のヒューストンInformational[22ページ]のRFC2990ステップ
[7] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., Speer,
M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, "A
Framework for Integrated Services Operation Over DiffServ
Networks", RFC 2998, November 2000.
[7]Bernet、Y.、Yavatkar、R.、フォード、P.、パン屋、F.、チャン、L.、シュペーア、M.、ブレーデン、R.、デイビー、B.、Wroclawski、J.、およびE.Felstaine、「DiffServネットワークの上の統合サービス操作のためのフレームワーク」、RFC2998(2000年11月)。
[8] "Quality of Service Technical Overview", Microsoft Technical
Library, Microsoft Corporation, September 1999.
[8] 「サービスの質の技術的な概要」、マイクロソフトの技術的な図書館、マイクロソフト社、1999年9月。
[9] "Resource Reservation Protocol API (RAPI)", Open Group Technical
Standard, C809 ISBN 1-85912-226-4, The Open Group, December
1998.
[9] 「資源予約プロトコルアピ(RAPI)」は1998年12月にグループ規格、C809 ISBN1-85912-226-4、TheOpenGroupを開きます。
[10] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data
Flows", RFC 2007, September 1997.
[10] バーガーとL.とT.オマリー、「IPSECデータフローのためのRSVP拡張子」、RFC2007、1997年9月。
[11] Mills, C., Hirsh, D. and G. Ruth, "Internet Accounting:
Background", RFC 1272, November 1991.
[11] 工場とC.とハーシュとD.とG.ルース、「以下を説明するインターネット」 「バックグラウンド」、RFC1272、1991年11月。
9. Acknowledgments
9. 承認
Valuable contributions to this document came from Yoram Bernet, Brian Carpenter, Jon Crowcroft, Tony Hain and Henning Schulzrinne.
このドキュメントへの有価約因はヨラムBernet、ブライアンCarpenter、ジョン・クロウクロフト、トニー・ハイン、およびヘニングSchulzrinneから来ました。
10. Author's Address
10. 作者のアドレス
Geoff Huston Telstra 5/490 Northbourne Ave Dickson ACT 2602 AUSTRALIA
ジェフヒューストンテルストラ5/490のNorthbourne Aveディックソンは2602オーストラリアを活動させます。
EMail: gih@telstra.net
メール: gih@telstra.net
Huston Informational [Page 23] RFC 2990 Next Steps for QoS Architecture November 2000
QoSアーキテクチャ2000年11月のための次のヒューストンInformational[23ページ]のRFC2990ステップ
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Huston Informational [Page 24]
ヒューストンInformationalです。[24ページ]
一覧
スポンサーリンク
