Network Working Group M. Eder
Request for Comments: 3387 H. Chaskar
Category: Informational Nokia
S. Nag
September 2002
Considerations from the Service Management Research Group (SMRG)
on Quality of Service (QoS) in the IP Network
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
The guiding principles in the design of IP network management were simplicity and no centralized control. The best effort service paradigm was a result of the original management principles and the other way around. New methods to distinguish the service given to one set of packets or flows relative to another are well underway. However, as IP networks evolve the management approach of the past may not apply to the Quality of Service (QoS)-capable network envisioned by some for the future. This document examines some of the areas of impact that QoS is likely to have on management and look at some questions that remain to be addressed.
IPネットワーク管理の設計における指導原理は、シンプルさと集中制御なしでした。ベストエフォート型サービスパラダイムは、オリジナルの経営理念や他の方法で回避の結果でした。サービスパケットの1つのセットに与えられたか、他に比べて流れを区別するための新しい方法が順調に進んでいます。しかし、IPなどのネットワークは、過去の管理アプローチは、将来のためにいくつかのことで想定されるサービス品質（QoS：Quality of Service）対応ネットワークには適用されない場合があります進化します。この文書では、QoSが経営に持って対処されずに残っているいくつかの質問を見てそうなインパクトの領域のいくつかを調べます。
Simplicity above all else was one of the guiding principles in the design of IP networks. However, as IP networks evolve, the concept of service in IP is also evolving, and the strategies of the past may not apply to the full-service QoS-capable network envisioned by some for the future. Within the IP community, their exists a good deal of impetus for the argument that if the promise of IP is to be fulfilled, networks will need to offer an increasing variety of services. The definition of these new services in IP has resulted in a need for reassessment of the current control mechanism utilized by IP networks. Efforts to provide mechanisms to distinguish the service given to one set of packets or flows relative to another are well underway, yet many of the support functions necessary to exploit these mechanisms are limited in scope and a complete framework is non-existent. This is complicated by the fact that many of these new services will also demand some form of billing framework in addition to a control one, something radically new for IP.
何よりもシンプルさがIPネットワークの設計における指導原理の一つでした。 IPネットワークが進化しかし、IPにおけるサービスのコンセプトも進化しており、過去の戦略は、将来のためにいくつかによって想定されるフルサービスのQoS対応のネットワークには適用されない場合があります。 IPコミュニティ内では、IPの約束が果たされるのであれば、ネットワークがサービスの増加、さまざまなを提供する必要があること、引数の推進力の良い取引を彼らの存在。 IPでのこれらの新しいサービスの定義は、IPネットワークが利用する電流制御機構の再評価の必要性をもたらしました。パケットの一組に所定のサービスを区別するためのメカニズムを提供するための努力または互いに対して流れがよく行われている、まだこれらのメカニズムを利用するために必要なサポート機能の多くは、範囲が限定されており、完全なフレームワークは、非存在です。これは、これらの新しいサービスの多くはまた、制御1に加えて、IPのための全く新しい何かを課金フレームワークのいくつかのフォームを要求するという事実によって複雑になります。
This document intends to evaluate the network and service management issues that will need to be addressed, if the IP networks of the future are going to offer more than just the traditional best effort service in any kind of significant way.
この文書では、将来のIPネットワークが重要な方法のいずれかの種類の中だけで、従来のベストエフォート型のサービス以上のものを提供しようとしている場合は、対処する必要がありますネットワークおよびサービス管理の問題を評価する予定。
The task of defining a management framework for QoS will be difficult due to the fact that it represents a radical departure from the best effort service model that was at the core of IP in the past, and had a clear design strategy to have simplicity take precedence over everything else [1]. This philosophy was nowhere more apparent than in the network and service management area for IP [2]. Proposed changes to support a variety of QoS features will impact the existing control structure in a very dramatic way. Compounding the problem is the lack of understanding of what makes up a "service" in IP [3]. Unlike some other network technologies, in IP it does not suffice to limit the scope of service management simply to end-to-end connectivity, but the transport service offered to packets and the way the transport is used must also be covered. QoS management is a subset of the more general service management. In looking to solve the QoS management problem it can be useful to understand some of the issues and limitations of the service management problem. QoS can not be treated as a standalone entity and will have its management requirements driven by the general higher level service requirements. If the available transport services in IP expand, the result will be the further expansion of what is considered a service. The now de-facto inclusion of WEB services in the scope of IP service, which is remarkable given that the WEB did not even exist when IP was first invented, illustrates this situation well. This phenomenon can be expected to increase with the current trend towards moving network decision points towards the boundary of the network and, as a result, closer to the applications and customers. Additionally, the argument continues over the need for QoS in IP networks at all. New technologies based on fiber and wavelength-division multiplexing have many people convinced that bandwidth will be so inexpensive it is not going to be necessary to have an explicit control framework for providing QoS differentiation. However uneconomical it is to engineer a network for peak usage, a major argument in this debate certainly is the cost of developing operational support systems for a QoS network and deploying them in the existing networks. Just the fact that customers might be willing to pay for additional service may not be justification for implementing sweeping architectural changes that could seriously affect the Internet as it is known today. The IP community must be very concerned that the equality that characterized the best effort Internet may be sacrificed in favor of a service that has a completely different business model. If the core network started to provide services that generated more revenue, it could easily come at the expense of the less revenue generating best effort service.
QoSの管理フレームワークを定義するタスクが原因、それは過去のIPのコアにあったベストエフォート型サービスモデルからの根本的出発を表しているという事実のために困難であること、そしてシンプルさが優先持っている明確な設計戦略を持っています他のすべての上に[1]。この理念はどこにもIP [2]のためのネットワークおよびサービス管理領域におけるよりも明らかではなかったです。 QoS機能の多様性をサポートするために提案された変更は、非常に劇的な方法で、既存の制御構造に影響を与えます。問題を配合すること[3] IPで「サービス」を構成するものの理解の欠如です。いくつかの他のネットワーク技術とは異なり、IPで、エンドツーエンドへの接続を簡単にサービス管理の範囲を制限するために十分ではありませんが、パケット及びトランスポートが使用されている方法に提供されるトランスポート・サービスもカバーしなければなりません。 QoS管理は、より一般的なサービス管理のサブセットです。 QoS管理の問題を解決するために探して、サービス管理の問題の問題と制限のいくつかを理解するのに役立ちます。 QoSは、スタンドアロンのエンティティとして扱わすることはできませんし、その管理要件は、一般的な、より高いレベルのサービス要件によって駆動されます。 IPで利用可能な輸送サービスを展開すると、結果はサービスとみなされるものの更なる拡大になります。 IPが最初に発明されたとき、WEBでも存在していなかったことを考えると顕著であるIPサービスの範囲におけるWEBサービスの今事実上のインクルージョン、よくこのような状況を示しています。この現象は、アプリケーションや顧客に近い結果として、ネットワークの境界に向けてネットワークの意思決定ポイントを移動し、に向けた現在の傾向に伴って増加することが期待されます。また、引数はすべてのIPネットワークにおけるQoSの必要性以上継続します。繊維と波長分割多重化に基づく新技術は、多くの人々がその帯域幅は、QoS差別化を提供するための明示的な制御の枠組みが必要であることを行っていないので、安価になります確信しています。それはピーク時の使用のためのネットワークを操作することであるしかし不経済、この議論の主要な引数は、確かなQoSネットワークの運用支援システムを開発し、既存のネットワークに展開するのコストです。顧客が追加サービスのために支払うことをいとわないかもしれないことだけ事実は、それが今日知られているように真剣にインターネットに影響を与える可能性の抜本的なアーキテクチャの変更を実装するための正当化できない場合があります。 IPコミュニティはベストエフォート型のインターネットを特徴平等が全く異なるビジネスモデルを持っているサービスを支持して犠牲にすることができることを非常に心配しなければなりません。コアネットワークは、より多くの収入を生成したサービスの提供を開始した場合、それは簡単にベストエフォート型のサービスを生成少ない収入を犠牲にして来ることができました。
Management standardization efforts in the IP community have traditionally been concerned with what is commonly referred to as "element management" or "device management". Recently, new efforts in IP management have added the ability to address service issues and to look at the network in more abstract terms. These efforts which included a logical representation of services as well as the representation of resources in the network, combined with the notion of a user of a service, has made possible the much talked about concept of 'policy'. Notable among these efforts are the Policy work in the IETF and the DMTF work on CIM and DEN. Crucial elements of the service management framework are coming into perspective, but point to a trend in IP that is a quite radical departure from the control mechanisms of the past. As the service model evolves from being what was sufficient to support best effort to being able to support variable levels of service, a trend towards a centralized management architecture has become quite apparent.
IPコミュニティの管理標準化の努力は、伝統的に、一般的に、「要素の管理」または「デバイス管理」と呼ばれるものと懸念されています。最近、IP管理における新たな取り組みは、サービスの問題に対処するために、より抽象的にネットワークを見て能力を追加しました。サービスの利用者の概念と組み合わせて、サービスの論理的な表現だけでなく、ネットワーク内のリソースの表現が含まれてこれらの努力は、多くが「政策」の概念について話を可能にしました。これらの取り組みの中で注目すべきは、IETFにおける政策ワークとCIMとDENにDMTFの仕事です。サービス管理フレームワークの重要な要素は、視点に入ってくるが、過去の制御機構とは全くラジカル出発あるIPの傾向を指しています。サービスモデルは、サービスの様々なレベルをサポートすることができることに最善の努力をサポートするのに十分だったものであることから発展するにつれ、集中管理アーキテクチャへの傾向はかなり明らかになってきました。
This is becoming increasingly apparent for two reasons. QoS mechanisms need network wide information [4], and for them to succeed, they must not require a tremendous amount of support from the core network. It is becoming increasingly accepted that only at the edge of the network will there be sufficient resources to provide the mechanisms necessary to admit and control various QoS flows.
これは、2つの理由のためにますます明らかになってきています。 QoSメカニズムは、[4]全体の情報をネットワーク必要があり、彼らが成功するために、彼らは、コアネットワークからのサポートの膨大な量を必要としない必要があります。ますますのみ、ネットワークのエッジで認めると流れる様々なQoSを制御するために必要なメカニズムを提供するのに十分なリソースが存在するであろうことが認められつつあります。
A question often asked these days is if "the architectural benefits of providing services in the middle of the network outweigh the architectural costs"[5]. This same question should be asked of service management. As new network elements are needed to support service management, even if they are not contributing directly to the forwarding of packets, the cost both in the increased complexity and the possibility of destabilizing the networks needs to be considered. An analyses of this issue will be made by the SMRG when we start to look more in detail at some of the issues raised in this survey document.
質問は、多くの場合、「ネットワークの途中でサービスを提供するアーキテクチャの利点は、建築コストを上回る」場合は、これらの日は尋ねた[5]。この同じ質問は、サービス管理の求めるべきです。新しいネットワーク要素は、それらがパケットの転送に直接寄与しない場合であっても、サービス管理をサポートするために必要なため、複雑化の両方のコストとネットワークを不安定化する可能性を考慮する必要があります。私たちは、この調査文書で提起された問題のいくつかをより詳細に見て起動したときに、この問題の分析は、SMRGによって行われます。
One place to start an effort to define service management in IP networks is by looking at what has been done previously in telecommunications networks. The telecommunications standards for a service management framework have not received wide scale acceptance even in an environment in which the service is fairly constrained. Many proprietary protocols still dominate in the market even though regulation has made it necessary for network operators to open their networks sufficiently to allow for multiple vendor participation in providing the service. This indicates that some formalized boundaries exist or the markets are sufficiently large to justify the development of interfaces. International telecommunications management standards look at the complete management problem by dividing it into separate but highly related layers. Much of the terminology used to describe the management problem in IP has diffused from the telecommunications standards [6]. These standards were designed specifically to address telecommunications networks and services, and it is not clear how applicable they will be to IP networks. Service management is defined in terms of the set of services found in telecommunications networks and the management framework reflects the hierarchical centralized control structure of these networks. The framework for service management is based on the Telecommunications Management Network (TMN) layered approach to management. Current IP standards are heavily weighted towards the element management layer and especially towards the gathering of statistical data with a decentralized approach being emphasized. In the TMN architecture a dependency exists between layers and clear interfaces at the boundaries are defined. To what extent service management, as defined in the TMN standards, can be applied to IP where there would likely be resistance to a requirement to have formalized interfaces between layers [6] must be further investigated.
IPネットワークでサービス管理を定義するための努力を開始する場所の一つは、通信ネットワークで以前に行われているものを見ることです。サービス管理フレームワークのための通信規格であっても、サービスがかなり制約されている環境で広いスケールの承認を受けていません。多くの独自のプロトコルはまだ規制が、それは必要なネットワークオペレータがサービスを提供する複数のベンダーの参加を可能にするために十分に自社のネットワークを開くために作られているにもかかわらず、市場で支配しています。これは、いくつかの正式な境界が存在するか、市場はインターフェースの開発を正当化するのに十分な大きさであることを示しています。国際通信管理基準は、別々であるが関連性の高い層に分割して、完全な管理の問題を見てください。 IPでの管理の問題を記述するために使用される用語の多くは、通信規格から拡散している[6]。これらの規格は、通信ネットワークとサービスに対処するために特別に設計され、彼らはIPネットワークになりますどのように適用されるかは明らかではありませんました。サービス管理は、通信ネットワークで見つかった一連のサービスと管理フレームワークで定義されたこれらのネットワークの階層集中制御構造を反映しています。サービス管理のためのフレームワークは、電気通信管理ネットワーク（TMN）の管理に階層化アプローチに基づいています。現在のIP規格は大きく要素管理層に向けて、特に強調されている分散型のアプローチと、統計データの収集に向けて重み付けされています。 TMNアーキテクチャに依存性が定義されている境界で層及び透明なインターフェイスとの間に存在します。どの程度サービス管理に、TMN規格で定義されるように、可能性の層の間の界面を定式化しているという要件に耐性があるであろうIPに適用することができる[6]さらに調査しなければなりません。
TMN concepts must be applied carefully to IP networks because fundamental differences exist. Control of IP networks is highly distributed especially in the network layer. Management is non-hierarchical and decentralized with many peer-to-peer relationships. A formal division of management into layers, where management dependencies exist at the borders of these layers, may not be applicable to IP. Any effort to define service management in IP must be constantly vigilant that it does not assume the telecommunications concepts can be applied directly to IP networks. The most basic abstraction of the network management problem into element, network, and service management has its origins in the telecommunications industry's standardization work and the IP management framework might not have made even these distinctions if it where not for the telecommunications legacy.
根本的な違いが存在するため、TMNの概念は、IPネットワークに慎重に適用する必要があります。 IPネットワークの制御が非常に特にネットワーク層に分布しています。経営陣は、多くのピア・ツー・ピア関係を持つ非階層と分散です。管理の依存関係は、これらの層の境界に存在する層への管理の正式な分割は、IPに適用可能でないかもしれません。 IPでサービス管理を定義するために何の努力は、それが電気通信の概念は、IPネットワークに直接適用することができると仮定していないことを常に警戒する必要があります。最も基本的な要素へのネットワーク管理の問題を抽象化し、ネットワーク、およびサービス管理は、通信業界の標準化作業中にその起源を持っており、それどこではない電気通信レガシーのための場合はIP管理フレームワークも、これらの区別がなされていない可能性があります。
In defining the Service Management Framework for IP, the nature of services that are going to need to be managed must be addressed. Traditionally network management frameworks consist of two parts, an informational framework and the framework to distribute information to the network devices. A very straight forward relationship exists in that the distribution framework must support the informational one, but also more subtle relationships exists with what the informational and distribution frameworks imply about the management of the system. The informational framework appears to be the easier problem to address and the one that is principally being focused on by the IP community.
IPのサービス管理フレームワークを定義するには、管理対象とする必要があるとしているサービスの性質に対処しなければなりません。従来、ネットワーク管理フレームワークは二つの部分、情報フレームワークとネットワークデバイスに情報を配信するためのフレームワークで構成されています。非常にまっすぐ進むの関係が配信フレームワークは、情報1をサポートしなければならないという点で存在しているだけでなく、より微妙な関係の情報と配信フレームワークは、システムの管理について暗示するものとが存在します。情報提供のフレームワークは、対処するためのより簡単な問題と主にIPコミュニティによって着目されている1つであると考えられます。
Efforts like the DMTF CIM are currently trying to define network, and to a lesser extent service, information models. These efforts show a surprising similarity to those of the telecommunications industry to define information models [7]. What has not emerged is a standard for defining how the information contained in the models is to be used to manage a network.
DMTF CIMのような取り組みは、現在、ネットワークを定義しようとすると、より少ない程度のサービス、情報モデルにしています。これらの努力は、情報モデルを定義するために通信業界のものに驚くべき類似性を示す[7]。何浮上していないと、モデルに含まれている情報は、ネットワークを管理するために使用される方法を定義するための規格です。
The number of elements to be managed in these networks will require this information to be highly distributed. Highly distributed directories would be a prime candidate for the information that is of a static nature. For information that is of a dynamic nature the problem becomes far more complex and has yet to be satisfactorily addressed. Policy management is a logical extension of having distributed directories services available in the network. The IETF and DMTF are looking to Policy management to be a framework to handle certain service management issues. Much of the current policy efforts are focused on access and traffic prioritization within a particular network element and only for a single administrative domain [8]. Classifying traffic flows and enforcing policies at the edge with the intent of focusing on admission issues, without addressing the end-to-end nature of the problem, leaves some of the most complex QoS management issues still unanswered. Providing a verifiable commodity level of service, in IP, will effect every facet of the network and a management solution to the problem will have to address the scale and the dynamics by which it operates.
これらのネットワークで管理される要素の数は、高度に分散されるように、この情報が必要になります。高度に分散ディレクトリは、静的な性質のものである情報のための最有力候補になります。動的な性質のものである情報については、問題ははるかに複雑になり、満足に対処するためには至っていません。ポリシー管理は、ネットワーク内で利用可能な分散ディレクトリサービスを持つことの論理的な拡張です。 IETFやDMTFは、特定のサービス管理の問題を処理するためのフレームワークであることをポリシー管理に探しています。現在の政策努力の多くは、特定のネットワーク要素内にのみ単一の管理ドメイン[8]のアクセスやトラフィックの優先順位付けに焦点を当てています。トラフィックフローを分類し、入場の問題に焦点を当てたのを意図してエッジでポリシーを実施、問題のエンドツーエンドな性質に対処せず、まだ未回答の最も複雑なQoS管理の問題のいくつかを残します。 IPで、サービスの検証可能な商品のレベルを提供し、ネットワークのあらゆる面に影響を与えるだろうし、問題の管理ソリューションは、それが動作することにより、スケールとダイナミクスに対処する必要があります。
Standardization efforts need to concentrate on the management problems that are multi-domain in character. The test for multi-domain often centers around there being a many-to-one or a one-to-many relationship requiring the involvement of two or more distinct entities. Domains could reflect the administrative domain, routing domain, or include agreements between domains. Unlike the telecommunications network in which traffic traverses only a relatively small number of domains, traffic in IP networks is likely to traverse numerous domains under separate administrative control. Further complicating the situation is, that unlike the telecommunications network, many of these domains will be highly competitive in nature, offering and accommodating varying service level agreements. Telecommunications traffic, even with deregulation, passes from the access providers network to a core network and then, if it is an international call, across international boundaries. The number of domains is relative to IP small, the service supported in each is virtually identical, and yet each domains is likely to have a different business model from the other. In contrast IP will have many domains, many services, and domains will likely be highly competitive. To be successful IP will need to model the domain problem in a way that reduces the complexity that arises from having many independent networks each having a different service model being responsible for a single flow. Addressing service management issues across domains that are direct competitors of each other will also complicate the process because a solution must not expose too much information about the capabilities of one domains network to the competitor. Solutions may require a 3rd party trusted by both to provide the needed management functions while at the same time insuring that sensitive information does not pass from one to the other.
標準化の努力は、文字でのマルチドメインいる管理上の問題に集中する必要があります。マルチドメインのためのテストは、多くの場合に、1対多または2つ以上の異なるエンティティの関与を必要とする1対多の関係であることが周りの中央に配置します。ドメインは、管理ドメインを反映ルーティングドメイン、またはドメイン間の合意を含めることができます。トラフィックは、ドメインの比較的小さな数を横断する電気通信ネットワークとは異なり、IPネットワークのトラフィックは、別個の管理制御下に多数のドメインを通過する可能性があります。さらに、電気通信ネットワークとは異なり、これらのドメインの多くは自然の中で非常に競争力になることを、状況を複雑にされて提供し、さまざまなサービス・レベル・アグリーメントを収容。それは国際的な境界を越えて、国際通話の場合は通信トラフィックがあっても規制緩和で、その後、コアネットワークへのアクセスプロバイダネットワークから渡されます。ドメインの数が小さなIP、それぞれに支持されたサービスに対するものである実質的に同一であり、しかも各ドメインは、異なるビジネスモデルを持っている可能性があります。対照的に、IPは多くのドメイン、多くのサービス、およびドメインはおそらく非常に競争力になる必要があります。成功するためにIPはそれぞれ、多くの独立したネットワークを持つ単一のフローを担当しているさまざまなサービスモデルを持つから生じる複雑さを軽減する方法で、ドメインの問題をモデル化する必要があります。ソリューションは、競合他社に1つのドメインネットワークの機能についてはあまり情報を公開してはならないので、お互いの直接の競争相手であるドメイン間でのサービス管理の問題に対処することも、プロセスが複雑になります。同時に、機密情報が一方から他方へ通過させないことを保証しながらソリューションは、必要な管理機能を提供するために、両方から信頼サードパーティが必要な場合があります。
A service management framework must address the business processes that operate when providing a service. A service can be separated into two fundamental divisions. The first is the definition of the service and the second is the embodiment of the service. While this division may seem intuitive, a formal process that addresses these two aspects of a service needs to be in place if management of the service is to be actually realized.
サービス管理フレームワークは、サービスを提供する際に操作するビジネスプロセスに対処しなければなりません。サービスは、2つの基本的な部門に分けることができます。最初は、サービスの定義であり、第二は、サービスの実施形態です。この部門は、直感的に見えるかもしれませんが、サービスの管理を実際に実現する場合には、サービスのこれらの二つの側面に対処し、正式なプロセスは、所定の位置にする必要があります。
In specifying a service it must be possible to map it onto the capabilities of the underlying network architecture. The service needs to be specified in an unambiguous way so that mechanisms can be put in place to enable the control of the service. It can be a useful tool to view the relationship of the definition of a service to an instance of that service to the relationship between the definition of an object to the instantiation of that object in object oriented modeling. As networks evolve it is going to be necessary to logically describe the network capabilities to the service and because IP networks are so fragmented specific service classifications will need to be made available that transcend the individual regions and domains. An interface that defines and controls the network capabilities, abstracted for the service perspective, allows for the administration of the network by the service management systems.
サービスを指定することで、基盤となるネットワークアーキテクチャの機能にそれをマップすることが可能でなければなりません。サービスはメカニズムがサービスの制御を可能にする場所に置くことができるように、明確な方法で指定する必要があります。オブジェクト指向モデリングにおけるそのオブジェクトのインスタンスへのオブジェクトの定義との間の関係にそのサービスのインスタンスへのサービスの定義の関係を表示するための有用なツールであることができます。ネットワークは、論理的にサービスへとIPネットワークのためにネットワーク機能を記述する必要があることを行っている進化するように断片化された特定のサービスの分類は、個々の領域およびドメインを超越している利用できるようにする必要がありますされています。サービス視点ため抽象化ネットワーク機能を定義し、制御インタフェースは、サービス管理システムによりネットワークの投与を可能にします。
Services are often designed with management capabilities specific to them. These services have tended to not rely on the service aspects of the network, but only on its transport capabilities. As services become more dependent on the network, Management over a shared framework will be required. Operators have recognized the business need to allow the user to have as much control over the management of their own services as possible. IP services will be highly diverse and customizable further necessitating that the management of the service be made available to the user to the extent possible.
サービスは、多くの場合、それらに固有の管理機能で設計されています。これらのサービスは、ネットワークのサービス面ではなく、唯一の輸送能力に依存しない傾向がありました。サービスは、ネットワーク上でより依存するようになったように、共有の枠組みを超える管理が必要となります。オペレータは、ユーザは可能な限り、独自サービスの管理を超えるほどに制御することができるようにするビジネスの必要性を認識しています。 IPサービスは非常に多様で、さらにサービスの管理が可能な範囲でユーザーが利用できるようにすることを必要とカスタマイズされます。
In the IP environment where they may be many separate entities required to provide the service this will create a significant management challenge.
IP環境では、彼らは、これは重要な経営課題を作成するサービスを提供するために必要な多くの別々のエンティティであってもよいです。
Paramount to the success of any service is determining how that service will be billed. The process by which billing will take place must be defined at the service inception. It is here that the network support necessary for billing should be addressed. Analogously, security must also be addressed in the most early stages of the service definition. It is not practical to assume that the billing and the security services will be hosted by the same provider as the service itself or that it will be possible to have the billing and security functions specifically designed for every service. These functions will have to be a generic part of the network.
任意のサービスの成功へのパラマウントは、そのサービスが請求される方法を決定しています。課金が行われることにより、プロセスは、サービス開始時に定義する必要があります。それは、課金のために必要なネットワークサポートに対処する必要があることをここにあります。同様に、セキュリティは、サービス定義の最も初期の段階で対処しなければなりません。課金およびセキュリティサービスは、サービス自体と同じプロバイダによってホストされているか、特異的、すべてのサービスのために設計された課金およびセキュリティ機能を持つことが可能となることであろうと仮定することは現実的ではありません。これらの機能は、ネットワークの一般的な部分である必要があります。
Given the limited success of the telecommunications standards bodies efforts to formalize the relationship between different management support functions it is highly suspect that such efforts would succeed in IP networks which have an even more diverse concept of network and services. If the IP network is to be made up of peer domains of equal dominion it will be necessary to have management functionality that is able to traverse these domains. Of course the perspective of where management responsibility lies is largely dependent on the reference point. A centric vantage point indicates responsibility shared equally among different domains. From within any particular domain management responsibility exists within that domain and that domain only. For a management framework to succeed in IP networks logical management functions will have to be identified along with an extremely flexible definition language to define the interface to these management functions. The more the management functionality will have to cross boundaries of responsibility, the more the network management functions have to be distributed throughout the network.
異なる管理サポート機能との関係を形式化するための電気通信標準化団体の取り組みの限られた成功を考えると、非常にそのような努力は、ネットワークとサービスの一層の多様な考え方を持っているIPネットワークで成功するだろうと疑っています。 IPネットワークは、同じ支配のピア・ドメインから構成されるする場合には、これらのドメインを横断することができる管理機能を有することが必要であろう。もちろん、経営責任の所在の視点を基準点に大きく依存しています。中心の視点は、異なるドメイン間で均等に共有責任を示しています。内から任意の特定のドメインの管理責任は、そのドメインだけそのドメイン内に存在します。管理フレームワークは、IPネットワークで成功するために論理的な管理機能は、これらの管理機能へのインタフェースを定義するための非常に柔軟な定義言語と一緒に識別される必要があります。より多くの管理機能は、責任の境界を横断する必要がありますが、より多くのネットワーク管理機能は、ネットワーク全体に分散する必要があります。
The service management paradigm for IP must address management from a perspective that is a combination of technical solutions as well as a formula for representing vendor business relationships. Currently services that need support between domains require that the service level agreements (SLAs) be negotiated between the providers. At some point these agreements will likely become unmanageable, if the number of agreements becomes very large and/or the nature of the agreements is highly variable. This will result in there being sufficient need for some form of standardization to control these agreements.
IPのためのサービス管理パラダイムは、技術的なソリューションの組み合わせだけでなく、ベンダーのビジネス関係を表現するための式である観点から、経営に取り組む必要があります。現在、ドメイン間のサポートを必要とするサービスは、サービスレベルアグリーメント（SLA）はプロバイダの間で交渉する必要があります。協定の数が非常に大きくなり、および/または契約の性質が非常に変化した場合、いくつかの時点で、これらの契約は、おそらく、管理不能になります。これは、そこにこれらの契約を制御するために、標準化のいくつかのフォームのための十分な必要性であることになります。
Bandwidth Brokers have been conceived as a method for dealing with many of the problems between the domains relating to traffic from a business perspective. The premise of the Bandwidth Brokers is to insure agreement between the network domains with regards to traffic, but security and billing issues, that are not likely to be as quantifiable, will also need to be addressed. Service providers have traditionally been reluctant to use bandwidth broker or SLA types of functions as they fear such tools expose their weaknesses to competitors and customers. While this is not a technical problem, it does pose a real practical problem in managing a service effectively. Looking at the basic requirements of the QoS network of the future two competing philosophies become apparent. The network providers are interested in having more control over the traffic to allow them to choose what traffic gets priority especially in a congested environment. Users desire the ability to identify a path that has the characteristics very similar to a leased line [9]. In either situation as IP bandwidth goes from being delivered on an equal basis, to being delivered based on complex formulas, there will become an increasing need to provide authentication and validation to verify who gets what service and that they pay for it. This will include the ability to measure that the service specified is being provided, to define the exact parameters of the service, and to verify that only an authorized level of service is being provided.
帯域幅ブローカーは、ビジネスの観点からのトラフィックに関連するドメイン間の問題の多くに対処するための方法として考えられています。また、対処する必要があります帯域幅ブローカーの前提は、のように定量化する可能性はありませんトラフィックに関して、しかし、セキュリティおよび課金の問題、とのネットワークドメインとの間の合意を保証するためです。サービスプロバイダは、伝統的に、彼らはそのようなツールは、競合他社や顧客に彼らの弱点をさらす恐れて帯域ブローカーや機能のSLAタイプを使用することに消極的でした。これは技術的な問題ではありませんが、それは効果的にサービスを管理するには、実際の実用上問題ありません。今後の2つの競合する哲学のQoSのネットワークの基本的な要件を見ると明らかになる。ネットワークプロバイダは、彼らが特に混雑した環境での優先順位を取得するものトラフィックを選択できるようにするトラフィックをより細かく制御を持つことに興味があります。ユーザは、専用線[9]と非常に類似した特性を持つパスを識別する能力を望みます。 IP帯域幅が複雑な数式に基づいて配信されることに、対等に配信されてから行くようにいずれかの状況では、どのようなサービスを取得し、彼らはそれを支払うことを誰が確認するための認証および検証を提供する必要性が高まっになります。これは、指定されたサービスは、サービスの正確なパラメータを定義するために、サービスの唯一の認可レベルが提供されていることを確認するために、提供されていることを測定する能力を含むであろう。
Some of the earlier work on an architectural framework for mixed traffic networks has suggested that bilateral agreements will be the only method that will work between administrative domains [10]. Multilateral agreements may indeed be complex to administer, but bilateral agreements will not scale well and if the traffic needs to traverse many administrative domains it will be hard to quantify the end-to-end service being provided. Instability in the ownership and administration of domains will also limit the usability of bilateral agreements in predicting end-to-end service.
混合交通ネットワークのアーキテクチャフレームワーク上の以前の仕事の一部は、二国間協定は、管理ドメイン[10]との間で動作する唯一の方法であろうことを示唆しています。多国間協定は確かに管理が複雑になるかもしれませんが、二国間協定はうまくスケールしませんし、トラフィックが多くの管理ドメインを横断する必要がある場合には、エンドツーエンドのサービスが提供されている定量化することは難しいでしょう。ドメインの所有者と管理における不安定性はまた、エンドツーエンドのサービスを予測する二国間協定の有用性を制限します。
As the convergence towards all IP continues it will be interesting to understand what effects existing telecommunications regulations might have on IP networks as more regulated traffic is carried over them. Regulation has been used in the telecommunications world to open the network, but it has had mixed results. A regulated process could possibly eliminate the effects competitive pressures will have on bilateral types of agreements and make it possible to get a truly open environment, but it could also have an opposite effect. Unfortunately the answer to this question may not come in the form of the best technical solution but in the politically most acceptable one. If traffic agreements between the boundaries of networks is not standardized a continuing consolidation of network providers would result. Providers unable to induce other providers to pair with them may not be able to compete if QoS networks become commonplace. This would be especially visible for small and midsize service providers, who would be pressured to combine with a larger provider or face not being able to offer the highest levels of service. If this phenomenon plays out across international boundaries it is hard to predict what the final outcome might be.
すべてのIPへの収束が続くと、より多くの規制トラフィックがそれらの上に運ばれるような効果既存の通信規制がIPネットワーク上で持っているかもしれないものを理解することは興味深いだろう。規制は、ネットワークを開くには、通信の世界で使用されてきたが、それは混合結果がありました。調節されたプロセスは、おそらく競争圧力が契約の二国間のタイプであり、真にオープンな環境を取得することを可能にし、それはまた、逆の効果を持つことができます影響を排除することができます。残念ながら、この質問に対する答えは、最高の技術ソリューションの形ではなく、政治的に最も受け入れ一つに来ないかもしれません。ネットワークの境界の間のトラフィック契約が標準化されていない場合は、ネットワークプロバイダの継続的な統合がもたらすであろう。それらと対に他のプロバイダを誘導することができないプロバイダは、QoSネットワークが一般的になっている場合に競争することができないかもしれません。これは、サービスの最高レベルを提供することができない大きなプロバイダと組み合わせたり、直面する圧力をかけられる中小サービスプロバイダにとって特に目に見えるだろう。この現象は国境を越えて果たしている場合、最終的な結果が何であるかを予測することは困難です。
The majority of current activity on higher level management functions for IP networks have been restricted to the issue of providing QoS. Many service issues still remain to be resolved with respect to the current best effort paradigm and many more can be expected if true QoS support is realized. Authentication, authorization and accounting services still inadequate for the existing best effort service will need additional work to support QoS services.
IPネットワークのためのより高いレベルの管理機能の現在の活動の大半は、QoSを提供するという問題に限定されています。多くのサービスの問題は、まだ現在のベストエフォート型パラダイムに関して解決されずに残っていると真のQoSサポートが実現されている場合は、さらに多くを期待することができます。既存のベストエフォート型サービスのため、まだ不十分な認証、許可およびアカウンティングサービスは、QoSサービスをサポートするための追加作業が必要になります。
It is reasonable that services can be classified into application level services and transport level services. Transport services are the services that the network provides independent of any application. These include services such as Packet Forwarding and Routing, QoS differentiation, Traffic Engineering etc. These might also include such functions as security (Ipsec) and Directory services. In IP networks a distinction is often made between QoS transport services that are viewed as end-to-end (RSVP) or per-hop (Diffserv). From a management perspective the two are very similar. Transport level services are not very flexible, requiring application level services to fit into the transport framework. An application that needs additional transport level services will need to be a mass-market application where the investment in new infrastructure can be justified. Because of the effort in altering transport services, applications that need new ones will have a longer time to market and the effort and cost to develop a framework necessary to support new transport services should not be underestimated.
サービスがアプリケーションレベルのサービスとトランスポートレベルのサービスに分類できることが合理的です。トランスポートサービスは、ネットワークが任意のアプリケーションから独立して提供するサービスです。これらは、パケット転送と経路、QoSの分化、トラフィックエンジニアリングなどが挙げられる。これらはまた、セキュリティ（IPsec）とディレクトリサービスなどの機能が含まれる可能性があるなどのサービスが含まれます。 IPネットワークでは区別は、多くの場合、エンドツーエンド（RSVP）またはホップごと（Diffservの）とみなされるQoSの輸送サービスとの間に形成されています。管理の観点から、二人は非常に似ています。トランスポートレベルのサービスは、トランスポートフレームワークに収まるようにアプリケーションレベルのサービスを必要とする、非常に柔軟ではありません。追加のトランスポート・レベルのサービスを必要とするアプリケーションは、新しいインフラストラクチャへの投資を正当化することができる大衆市場のアプリケーションが必要になります。そのため輸送サービスを変更することで努力を、新しいものを必要とするアプリケーションは、市場投入までの長い時間を持つことになり、新たな輸送サービスをサポートするために必要なフレームワークを開発するための労力とコストを過小評価すべきではありません。
Application level services are those specific to the application. Many service management functions occur between the application supplier and the application consumer which require no knowledge or support by the existing network. By keeping service management functions at this level time to market and costs can be greatly reduced. The disadvantages are that many applications need the same functionality causing inefficient use of the network resources. Services supplied by the network are able to be built more robustly and can provide additional functionality, by virtue of having access to information that applications can not, providing additional benefit over application level services. An example of an application level service that could benefit from a Network service is the AAA paradigm for Web based E-Commerce, which is largely restricted to user input of credit card information. Sometimes application level service requirements have the disadvantages of both transport service and application service level. For instance, in IP telephony, this may include services provided by a gateway or other network device specific to IP telephony to support such services as call forwarding or call waiting. The mass appeal of IP telephony makes it possible to suggest considerable infrastructure changes, but the nature of this kind of change has contributed to the slow penetration of IP telephony applications.
アプリケーションレベルのサービスは、アプリケーションに固有のものです。多くのサービス管理機能は、アプリケーションのサプライヤーと既存のネットワークによる知識やサポートを必要としないアプリケーションの消費者の間で発生します。このレベルの時点でサービス管理機能を維持し、市場にするとコストが大幅に削減することができます。欠点は、多くのアプリケーションがネットワークリソースの非効率的な使用を原因と同じ機能を必要とするということです。ネットワークによって供給されるサービスは、よりロバストに構築することが可能であり、アプリケーションは、アプリケーション・レベルのサービスの上に追加の利点を提供することができない情報へのアクセスを有することにより、追加の機能を提供することができます。ネットワークサービスから利益を得ることができるアプリケーションレベルのサービスの例としては、主にクレジットカード情報のユーザの入力に制限されたWebベースの電子商取引のためのAAAパラダイムです。時には、アプリケーションレベルのサービス要件は、トランスポート・サービスとアプリケーション・サービス・レベルの両方の欠点を持っています。例えば、IP電話では、これはゲートウェイまたは呼転送またはキャッチホンなどのサービスをサポートするIP電話に固有の他のネットワーク・デバイスによって提供されるサービスを含むことができます。 IPテレフォニーの質量の魅力は、かなりのインフラストラクチャの変更を提案することが可能となりますが、変更のこの種の性質は、IPテレフォニーアプリケーションの遅い浸透に貢献してきました。
An overview of some of the problems in the previous sections shows a need for a consolidated framework. Transport level QoS will demand traffic engineering that has a view of the complete network that is far more comprehensive than what is currently available via the Routing protocols. This view will need to including dynamic network congestion information as well as connectivity information. The current existing best-effort transport control may become more of a hindrance to new services and may be of questionable value if the IP network will truly become a full service QoS network. Both IntServ and DiffServ QoS schemes require network provisioning to adequately support QoS within a particular domain and agreements for traffic traversing domains. Policy management, object oriented information models, and domain gateways are leading to a more centralized management structure that provides full service across domains and throughout the network. Given the probable cost and complexity of such a system failure to come up with a standard, even if it is a de facto one, will have serious implications for the Internet in the future.
前のセクションでの問題のいくつかの概要については、連結フレームワークの必要性を示しています。トランスポートレベルのQoSルーティングプロトコルを経由して、現在利用可能なものよりもはるかに包括的で完全なネットワークのビューを持つトラフィックエンジニアリングを要求します。このビューには、動的なネットワークの輻輳情報だけでなく、接続情報を含むにする必要があります。現在、既存のベストエフォート型のトランスポート・コントロールは、新しいサービスへの障害の多くをなるかもしれないし、IPネットワークが本当にフルサービスのQoSネットワークになります場合は、疑わしい値であってもよいです。両方のIntServとDiffServのQoSのスキームが適切にトラフィック横断ドメインの特定のドメインや協定の中にQoSをサポートするために、ネットワークのプロビジョニングが必要です。ポリシー管理、オブジェクト指向の情報モデル、およびドメイン・ゲートウェイは、ドメイン間で、ネットワーク全体でのフルサービスを提供し、より集中管理構造につながっています。標準を思い付くためにそのようなシステム障害の可能性、コストと複雑さを考えると、それは事実上の1であったとしても、将来的にインターネットに深刻な影響を持つことになります。
For the current trends in QoS to succeed, there will need to be harmonization across the new and existing control structures. By utilizing a structure very similar to the existing routing control structures, it should be possible develop functionality, not in the data path, that can allocate traffic within a domain and use inter-domain signaling to distribute between domains. Additional functionality, necessary to support QoS-like authorization and authentication functions for edge devices admitting QoS traffic and administering and allocating traffic between administrative domains could also be supported. While meeting the requirements for a bandwidth broker network element [10], additional functionality of making more general policy decisions and QoS routing could also be performed. Given that these tasks are interrelated it makes sense to integrate them if possible.
成功するためのQoSの現在の傾向については、新規および既存の制御構造全体に、調和させる必要性が存在します。既存のルーティング制御構造に非常に類似した構造を利用することにより、ないドメイン内のトラフィックを割り当て、ドメイン間で分配するドメイン間シグナリングを使用することができ、データパスで、機能を開発することが可能であるべきです。追加機能は、エッジデバイスは、QoSトラフィックを認めると管理と管理ドメイン間のトラフィックを割り当てるためのQoSのような認可と認証機能をサポートするために必要なもサポートすることができます。帯域ブローカーのネットワーク要素[10]、より一般的な政策決定とQoSルーティングを行うの追加機能のための要件を満たしながらも実行することができます。これらのタスクは、それが可能であればそれらを統合することに意味が相互にしていることを考えます。
The new service architecture must allocate traffic within a particular administrative domain and signal traffic requirements across domains, while at the same time it must be compatible with the current method for routing traffic. This could be accomplished by redirecting routing messages to a central function, which would then calculate paths based on the entire network transport requirements. Across domains, communication would occur as necessary to establish and maintain service levels at the gateways. At the edges, devices would provide traffic information to billing interfaces and verify that the service level agreed to was being provided. For scalability any central function would need to be able to be distributed in large networks. Routing messages, very similar in content to the existing ones, would provide information sufficient to support the traffic engineering requirements without changing the basic forwarding functions of the devices. Having routes computed centrally would simplify network devices by alleviating them from performing computationally intensive routing related tasks.
同時に、それがトラフィックをルーティングするための現在の方法と互換性がなければならないしながら、新たなサービス・アーキテクチャは、特定の管理ドメイン内のトラフィックを割り当て、ドメイン間のトラフィック要件を通知しなければなりません。これは、次に、ネットワーク全体の輸送要件に基づいて経路を計算することになる中枢機能にルーティングメッセージをリダイレクトすることによって達成することができます。ドメイン間で、通信がゲートウェイのサービスレベルを確立し、維持するために必要に応じて生じます。エッジで、デバイスは、課金インタフェースに交通情報を提供し、合意したサービスレベルが提供されたことを確認するであろう。スケーラビリティのために、任意の中心的な機能は、大規模なネットワークに分散させることができるようにする必要があります。既存のコンテンツに非常に類似したメッセージを、ルーティング、デバイスの基本的な転送機能を変更することなく、トラフィックエンジニアリング要件をサポートするのに十分な情報を提供するであろう。計算集約的なルーティング関連のタスクを実行することから、それらを緩和することによって、ネットワークデバイスを単純化する中央計算経路を有します。
Given the number of flows through the network the core can not know about individual flow states [11]. At the same time it is not practical to expect that the edge devices can determine paths that will optimally utilize the network resources. As the information needed to forward traffic through the network becomes related to complex parameters that can not be determined on a per hop basis and have nothing to do with the forwarding of packets, which routers do best, it might make sense to move the function of determining routes to network components specifically designed for the task. In a QoS network routing decisions will become increasingly dependent on information not easily discernable from the data that routers could logically share between themselves. This will necessitate the need to for additional functionality to determine the routing of data through the network and further suggests that all the information needed to allow a router to forward packets might not be better provided by a network element external to the packet forwarding functions of a router.
コアは、個々のフロー状態[11]について知ることができないネットワークを介してフローの数を考えます。同時に、エッジデバイスが最適にネットワークリソースを利用する経路を決定することができることを期待するのは現実的ではありません。ネットワーク経由でトラフィックを転送するために必要な情報は、ルータが最善を尽くすホップごとに決定され、パケットの転送とは何の関係もないことができない複雑なパラメータに関連なると、それはの機能を移動しても意味があります具体的タスクのために設計されたネットワーク構成要素へのルートを決定します。 QoSのネットワークではルーティングの決定を簡単にルータが論理的にそれらの間で共有できるデータから識別できない情報にますます依存するようになるだろう。これは、ネットワークを介して、さらにデータのルーティングを決定するための追加機能は、パケットを転送するルータを可能にするために必要なすべての情報がより良いのパケット転送機能への外部ネットワーク要素によって提供されていない可能性がありますことを示唆しているために必要性を必要としますルータ。
At the edges of the network where the traffic is admitted it will be necessary to have mechanisms that will insure the traffic is within the bounds of what has been specified. To achieve this it will be necessary to buffer and control the input traffic. Second the traffic would need to be marked so the other network elements are able to identify that this is preferred traffic without having to keep flow information. Conversely, a path could be chosen for the traffic that was dedicated to the level of service being requested that was per flow based. A combination of the two would be possible that would allow a reservation of resources that would accommodate multiple flows. Both methods are similar from a management perspective and are really identical with regards to route determination that could be performed centrally in that one method represents just a virtual path based on the handling of the packets by the device in the network and the second would be a pre-reserved path through the network. Existing best effort routing will not provide the optimum routes for these new levels of service and to achieve this it would be necessary to have either routing protocols that supported optimum path discovery or mechanisms to configure paths necessary to support the required services. In addition to specific service parameters reliability will also be a potential service discriminator. It is unlikely using traditional path determination methods that in the event of a failure a new path could be determined sufficiently quickly to maintain the agreed service level. This would imply the need for multiple path reservations in some instances. Because Per flow reservations are too resource intensive virtual trunks would provide a good way to reduce the amount of management traffic by reserving blocks of capacity and would provide stability in the event of a failure in the resource reservation and route selection functions.
トラフィックが許可されているネットワークのエッジでは、トラフィックは、指定された内容の範囲内で保証する機構を有することが必要であろう。これを達成するためには、入力トラフィックをバッファリングして制御することが必要になります。他のネットワーク要素は、フロー情報を保持することなく、これがトラフィックを優先していることを識別することができるので、第二に、トラフィックがマークされる必要があるであろう。逆に、経路は、フローごとに基づいた要求されたサービスのレベルに捧げられたトラフィックのために選択することができます。二つの組み合わせは、複数のフローを受け入れることになるリソースの予約を可能にすることが可能であろう。両方の方法は管理の観点から類似しており、その1つの方法で集中的に実行することができる経路決意に関して本当に同一であるネットワーク内の装置によるパケットの処理に基づいて、単に仮想パスを表し、第二のようになりネットワークを介して事前予約パス。既存のベストエフォート型ルーティングはサービスのこれらの新しいレベルの最適なルートを提供することはありませんし、必要なサービスをサポートするために必要なパスを設定するには、最適経路の発見やメカニズムをサポートするルーティングプロトコルのいずれかを持っていることが必要であろう、これを達成するために。特定のサービスパラメータの信頼性に加えて、潜在的なサービス弁別になります。それはそう障害が発生した場合に新しいパスが合意されたサービスレベルを維持するのに十分迅速に決定することができ、伝統的なパスの決意の方法を使用しています。これは、いくつかの例では、複数のパスの予約の必要性を暗示します。パーフローの予約があまりにもリソースを集中しているため、仮想トランクは、容量のブロックを予約することによって、管理トラフィックの量を減らすための良い方法を提供すると、リソース予約および経路選択機能で障害が発生した場合の安定性を提供するだろう。
There are implications of providing shaping at the network boundaries. Shaping would include both rate and burst parameters as well as possible delay aspects. Having to provision services with specific service parameters would present both major business and technical problems. By definition, packet data is bursty in nature and there exist periods of idleness during the session that a provider could reasonable hope to exploit to better utilize the network resources. It is not practical to expect a consumer paying a premium for a service would not check that the service was truly available. Such a service model seems to be filled with peril for the existing best effort Internet, because any significant amount of bandwidth that was reserved for exclusive use or a high priority flow would not be available for best effort data.
ネットワークの境界で整形を提供する意味合いがあります。シェーピングレートとバーストパラメータ並びに可能な遅延の側面の両方を含むであろう。特定のサービスパラメータと提供サービスに持つことは、主要なビジネスおよび技術的な問題の両方を提示します。定義では、パケットデータは、本質的にバースト性で、プロバイダは、合理的な希望がより良いネットワークリソースを利用するために利用することができ、セッション中に怠惰の期間が存在します。サービスのためのプレミアムを支払う消費者はサービスが本当に利用可能であったことを確認しないと期待するのは現実的ではありません。このようなサービスモデルは、排他的使用のために予約された帯域幅の大幅な量や優先度の高いフローがベストエフォートデータのために利用できないでしょうので、既存のベストエフォート型インターネットのため危険で満たされているように見えます。
With respect to traffic within the network itself there will be the need to pre-configure routes and to provide the ability to have routes be dynamically configured. Some of the problems with pre-configured traffic include the basic inconsistency with the way traffic is currently engineered through the Internet and the difficulty in developing arrangements between administrative domains. The current Internet has been developed with one of the most egalitarian yet simplistic methods of sharing bandwidth. Supporting the existing best effort service, in an unbiased way, while at the same time providing for other classes of service could potentially add a tremendous amount of complexity to the QoS scheme. On the other hand, if the reserved bandwidth is not shared it could result in a significant impact on the availability of the bandwidth in the Internet as we know it today. QoS could potentially contribute more to their being insufficient bandwidth, by reserving bandwidth within the network that can not be used by other services, even though it can be expected that this bandwidth will be underutilized for much of the time. Add to that the motivation of the service providers in wanting to sell commodity bandwidth, and there could be tremendous pressures on the availability of Internet bandwidth.
ネットワーク内のトラフィックに関しては、それ自体は、ルートをあらかじめ設定するとルートが動的に設定することが持っている能力を提供する必要があるでしょう。事前に設定したトラフィックの問題点のいくつかは、トラフィックが現在、インターネットや管理ドメイン間の取り決めを開発することの困難によって設計されている方法と基本的な矛盾を含んでいます。現在のインターネットは、共有帯域幅の最も平等主義はまだ単純な方法の一つで開発されてきました。同時に、潜在的なQoS方式に複雑の膨大な量を追加することができ、サービスの他のクラスのために提供しながら、公平な方法で、既存のベストエフォート型サービスをサポートします。一方、予約された帯域幅が共有されていない場合、それは我々が今日それを知っているように、インターネットでの帯域幅の利用可能性に重大な影響が生じる可能性があります。 QoSは、潜在的に、この帯域幅は、時間の多くを十分に活用されることが期待できても、他のサービスで使用することはできませんネットワーク内の帯域幅を確保することによって、彼らのこと不十分な帯域幅に多くを貢献できます。商品の帯域幅を販売したいのものにサービスプロバイダのモチベーションを追加し、インターネットの帯域幅の利用可能性に多大な圧力があるかもしれません。
Current work within the IP community on defining mechanisms to provide QoS have centered on a particular few architectures and a handful of new protocols. In the following sections, we will examine some of the particular issues with regards to the current IP community efforts as they relate to the previous discussions. It is not the goal of this document to serve as a tutorial on these efforts but rather to identify some of the support issues related to using particular technologies that support some form of classifiable service within an IP network.
QoSを提供するためのメカニズムを定義する上でIPコミュニティ内の現在の仕事は、特定の数のアーキテクチャと新しいプロトコルの一握りに集中しています。彼らは以前の議論に関連して、次のセクションでは、我々は、現在のIPコミュニティの努力に関して、特定の問題のいくつかを検討します。これは、これらの取り組みのチュートリアルとして機能するのではなく、IPネットワーク内の分類サービスのいくつかのフォームをサポートする特定の技術を使用してに関連するサポートの問題のいくつかを識別するために、このドキュメントの目的ではありません。
One can restrict the scope of a discussion of QoS management only to the configuration of a path between two endpoints. Even within this limited scope there still remains many unresolved issues. There is no expectation that a QoS path for traffic between two points needs to be, or should be, the same in both directions. Given that there will be an originator of the connection there are questions about how billing and accounting with be resolved if the return path is established by a different provider then that of the originator of the connection. To facilitate billing a method will need to exist that permits the application originating the call to pay also for the return path and also for collect calls to be made. 3rd party providers will need to be established that are trusted by all parties in the data path to insure billing and guaranteed payment. Utilizing the service of a virtual DCN that is built upon both IETF and non-IETF protocols, messages between service providers and the 3rd party verification system can be secured. A signaling protocol will be necessary to establish the cost of the call and who will be paying for it, and each provider will need a verifiable method to bill for the service provided. As pointed out earlier this functionality will be similar to what is used in the existing telephone network, but will be at a much larger scale and potentially involve providers that are highly competitive with each other.
一つは、2つのエンドポイント間のパスの構成にQoS管理の議論の範囲を制限することができます。でも、この限られた範囲内でまだ多くの未解決の問題が残っています。 2点間のトラフィックのためのQoS経路が両方向で同じであることが必要である、またはあるべきという期待がありません。接続の発信元があることを考えると、リターンパスが異なるプロバイダによって確立された場合、課金及び会計は、接続の発信元のもの、その後解決されると方法についての質問があります。メソッドを課金容易にするためにリターンパスのためにも行われるコレクトコールのためにも支払うためにコールを発信するアプリケーションを許可するように存在する必要があります。サードパーティプロバイダは、課金および保証の支払いを保証するために、データ・パス内のすべての関係者から信頼されていることを確立する必要があります。 IETFおよび非IETFプロトコルの両方に基づいて構築された仮想DCNのサービスを利用して、サービスプロバイダやサードパーティの検証システム間のメッセージを確保することができます。シグナリングプロトコルはそれを支払うことになり、コールのコストとを確立することが必要であろうと、各プロバイダが提供するサービスのために請求する検証可能な方法が必要になります。先に指摘したように、この機能は、既存の電話網で使用されるものに似ていますが、はるかに大規模でも、潜在的に互いに非常に競争しているプロバイダーが参加します。
The DiffServ management problem is two pronged. First there is the management within the administrative domain that must be addressed, and then the management between the domains. There has been little actual work on the second in the architecture. What work there has been anticipates that service level agreements will be reached between the administrative domains, and that end-to-end service will be a concatenation of these various service level agreements. This is problematic for many reasons. It presumes that agreements reached bilaterally could be concatenated and continue to provide a level of end-to-end service the customer would be willing to pay a premium for. Problems discussed earlier, with trying to maintain large numbers of these agreements between competitive networks would also apply, and tend to limit the effectiveness of this approach. To efficiently establish the chain necessary to get end to end service it might take an infinite number of iterations.
DiffServの管理の問題が二又2です。まず取り組まなければならない管理ドメイン内の管理、そしてその後、ドメイン間の管理があります。アーキテクチャ第二にはほとんど実際の作業が行われています。どのような仕事があったことは、サービスレベル契約は、管理ドメイン間で到達され、そのエンドツーエンドのサービスは、これらの様々なサービス・レベル・アグリーメントの連結になると予想しています。これは多くの理由から問題があります。これは、二国間の合意が連結され、顧客はのために保険料を支払うことをいとわない、エンドツーエンドのサービスレベルを提供し続けることができることを前提としています。競争力のあるネットワーク間でこれらの契約の多くを維持しようとすると前述した問題が、また適用し、このアプローチの有効性を制限する傾向があります。効率的にエンドサービスへの終わりを取得するために必要なチェーンを確立するためには、繰り返しの無限の数がかかる場合があります。
Guaranteeing a class of service on a per hop basis is in no way a guarantee of the service on an end-to-end basis. It is not likely that a customer would be willing to pay for an improved level of service if it did not include guarantees on the bandwidth and the quantitative bounds on delay and error rates guaranteed end-to-end. This would necessitate engineering the paths through the network so as to achieve a desired end-to-end result. While it is very likely that an initial attempt at providing this kind of service will specify only a particular ingress and egress border, for robustness and flexibility it will be desirable to have a network that can support such service without such limitations. The Intserv approach, as opposed to the DiffServ architecture, would require per flow information in the core network and may as a result of this prove not to be scalable [11]. A DiffServ type architecture, with a limited number of service classes, could be pre-provisioned, and as network circumstances warranted, be modified to support the actual dynamics of the network.
ホップごとにサービスのクラスを保証することは決してエンド・ツー・エンドベースでのサービスの保証です。エンドツーエンドの保証帯域幅の保証および遅延に関する定量限界とエラー率が含まれていなかった場合、顧客はサービスの改善レベルを支払うことをいとわない可能性が高いではありません。所望のエンドツーエンドの結果を達成するように、これは、ネットワークを介して経路を設計必要とします。それはこの種のサービスを提供する時の初期の試みは、堅牢性と柔軟性のためにのみ、特定の入力および出力のボーダーを、指定した可能性が非常に高いですが、そのような制限がなく、このようなサービスをサポートできるネットワークを有することが望ましいだろう。 IntServのアプローチは、DiffServアーキテクチャとは対照的に、コアネットワークにおけるフロー情報ごとに必要となり、この結果、スケーラブルでないと証明することができる[11]。 DiffServの型アーキテクチャ、サービスクラスの限定された数と、事前にプロビジョニングすることができ、保証ネットワーク状況として、ネットワークの実際のダイナミクスをサポートするように変更すること。
The high level functional requirements for edge routers has been quite well defined in the DiffServ architecture, but the true scope of the effort to implement this functionality has not been well recognized. While interesting differences exist between the QoS architecture of the Internet and the circuit switched network used for telecommunications much of the lessons learned in telecommunications should, even if they might do little else, provide some insight into the level of effort needed to implement these kinds of requirements. Ironically, given the Internet community in the past has rejected the level of standardization that was proposed for management of telecommunications networks, it may be the full service internet where it becomes actually imperative that such requirements be completed if the desired services will ever be offered.
エッジルータのための高レベルの機能要件は、非常によくDiffServアーキテクチャで定義されているが、この機能を実装するための努力の真の範囲は、よく認識されていません。興味深い違いは、インターネットのQoSアーキテクチャの間に存在すると教訓の多くは電気通信で学んだ電気通信のために使用される回路スイッチドネットワークは、彼らは他にほとんどないかもしれない場合でも、これらの種類を実装するために必要な労力のレベルにいくつかの洞察を提供する必要がありますが要件。皮肉なことに、電気通信ネットワークの管理のために提案された標準化のレベルを拒否した、過去にインターネットコミュニティを与えられ、それが必要なサービスがこれまでに提供されるならば、このような要件が完了することを、実際に必要不可欠となり、フルサービス、インターネットであってもよいです。
The management of QoS will need to provide functionality to the application and/or at the access, at the core, and at the boundaries to administrative regions.
QoSの管理は、アプリケーションおよび/またはアクセスで、コアで、かつ境界で行政地域に機能を提供する必要があります。
QoS traffic functions will need to include admission control, authentication and authorization, and billing. Verification that traffic is within agreed parameters and programmatic interfaces to advise when the service is outside the agreed limits. Interfaces that provide service verification, fault notification, and re-instantiation and termination will also be necessary.
QoSトラフィック機能は、アドミッション制御、認証と承認、および課金を含める必要があります。トラフィックは、サービスが合意された範囲外にあるときに助言することに同意したパラメータやプログラム・インタフェース内であることを確認。サービスの検証、障害通知、および再インスタンス化および終端を提供インターフェースも必要になります。
Core functions will include traffic engineering, network device configuration, fault detection, and recovery. Network devices will need to inform the management system of their available resources and the management system will need to tell devices how and where to forward data.
コア機能は、トラフィックエンジニアリング、ネットワーク機器の設定、障害検出、および回復が含まれます。ネットワークデバイスは、利用可能なリソースの管理システムに通知する必要がありますし、管理システムは、どこでどのようにデータを転送するデバイスを指示する必要があります。
Between administrative regions accounting, service signaling, and service verification will be needed. At the administrative boundaries of the network functions similar to those provided at the edge will be necessary. Peer entities in different administrative domains would signal their needs across the boundary. Verification at the boundary could then occur consistent with the verification at the edge. Actual traffic through the boundaries could be measured and billing information be transferred between the domains. The central management function would be responsible for re-routing traffic in the event of a failure or to better utilize the existing network resources.
管理領域の間経理、サービスシグナリング、およびサービスの検証が必要になります。縁部に設けられたものと同様のネットワーク機能の管理境界に必要であろう。異なる管理ドメイン内のピアエンティティは、境界を越えて彼らのニーズに信号を送ります。境界での検証は、エッジでの検証と矛盾発生する可能性があります。境界を通じて実際のトラフィックを測定することができ、課金情報は、ドメイン間で転送すること。中央管理機能は、障害が発生した場合にトラフィックを再ルーティングまたはより良い、既存のネットワークリソースを利用するための責任を負うことになります。
Billing requirements suggest the need for 3rd party verification and validation functions available to each provider of QoS service within the flow. On one side of the transaction functionality is needed to approve pricing and payment and on the other side there will need to be an interface to provide the pricing information and make payment request for payment demands.
課金要件は、フロー内のQoSサービスの各プロバイダが利用可能なサードパーティの検証と妥当性確認機能の必要性を示唆しています。トランザクション機能の片側には価格と支払いを承認すると、他の側に価格情報を提供し、支払いの要求のための支払い要求を行うためのインタフェースがあるように必要になります必要とされています。
These requirements will raise a host of issues not the least of which is security. For the most part security considerations will be addressed both by securing the protocols (like with IPsec) and by establishing a dedicated network for control information [6]. While it will be in most instances too costly to create a physically separated DCN it will be possible to create a virtually separated network that will provide the same security benefits. Future work in the IRTF Service Management Research Group intends to look in detail at these requirements.
これらの要件は、セキュリティではなく、少なくともその問題のホストが発生します。大部分のセキュリティ問題のため（IPsecのと同じように）プロトコルを確保することと、制御情報のための専用ネットワークを確立することによって、両方に対処する[6]。それは物理的に分離DCNを作成するにはあまりにもコストがかかり、ほとんどの場合になりますが、同じセキュリティ上の利点を提供します事実上分離されたネットワークを作成することが可能になります。 IRTFサービスマネジメント研究グループでは今後の作業は、これらの要件の詳細に見てまいります。
For an issue as complex as a Service Management architecture, which interacts with protocols from other standards bodies as well as from the IETF, it seems necessary to keep in mind the overall picture while, at the same time, breaking out specific parts of the problem to be standardized in particular working groups. Thus, a requirement that the overall Service Management architecture address security concerns does not necessarily mean that the security mechanisms will be developed in the IETF.
同時に、問題の特定の部分を壊し、中に他の標準化団体からだけでなく、IETFからのプロトコルと対話するサービス管理アーキテクチャ、のような複雑な問題のために、心の中で全体像を維持するために必要と思われます特定の作業グループで標準化されます。このように、全体的なサービス管理アーキテクチャアドレスセキュリティ上の懸念は、必ずしもセキュリティメカニズムは、IETFで開発されることを意味するものではありません要件。
This document does not propose any new protocols, and therefore does not involve any security considerations in that sense. However, throughout this document consideration of the security issues raised by the architectural discussions are addressed.
このドキュメントは、新しいプロトコルを提案していないので、その意味ではどのようなセキュリティ上の考慮を必要としません。しかし、建築の議論が提起したセキュリティ問題のこの資料の検討を通じて対処されています。
The paradigm for service management in IP networks has been adopted from that of telecommunications networks. Basic differences between the service models of these networks call into question if this is realistic. Further analysis is needed to determine what is the proper paradigm for IP service management and to define a common vocabulary for it.
IPネットワークにおけるサービス管理のためのパラダイムは、通信ネットワークのものから採用されています。これは現実的である場合、これらのネットワークのサービスモデルの基本的な違いが問題と呼んでいます。さらなる分析は、IPサービス管理のための適切なパラダイムであるかを判断するために、そのための共通の語彙を定義するのに必要とされています。
The IP community is currently very active in solving problems relating to transport QoS issues. These activities are illustrated by the work of the Diffserv, Intserv, and Policy working groups. In contrast not enough effort is being focused on service issues relating to applications. The present solution is for applications to build in their own service management functionality. This is often an inefficient use of network resources, but more importantly will not provide for access to transport level services and the functionality that they offer.
IPコミュニティは、現在のQoSの問題を輸送するために関連する問題を解決する上で非常に有効です。これらの活動は、Diffservの、イントサーブ、および政策ワーキンググループの作業によって示されています。これとは対照的に十分な努力は、アプリケーションに関連するサービスの問題に焦点を当てています。本解決策は、独自のサービス管理機能で構築するアプリケーションのためです。これは、多くの場合、ネットワークリソースの非効率的な使用であるが、より重要なのは、トランスポートレベルのサービスと彼らが提供機能へのアクセスを提供しません。
The IP community needs to focus on adding service functionality that is flexible enough to be molded to specific application needs, yet will have access to service information that will be necessary to provide superior application functionality. Principal needs to be addressed relate to developing transport level services for billing and security. Directory services and extending the work done to define AAA services are promising starting points for developing this needed functionality.
IPコミュニティは、特定のアプリケーションのニーズに成形されるのに十分に柔軟で、まだ優れたアプリケーション機能を提供することが必要になるサービス情報へのアクセスを必要がありますサービスの機能を追加することに焦点を当てる必要があります。対処すべき主なニーズは、課金やセキュリティのためのトランスポート・レベルのサービスの開発に関連しています。ディレクトリサービスとAAAサービスは、この必要な機能を開発するための出発点を期待されている定義するために行われる作業を拡張します。
[1] L. Mathy, C. Edwards, and D. Hutchison, "The Internet: A Global Telecommunications Solution?", IEEE Network, July/August 2000.
[1] L. Mathyさん、C.エドワーズ、およびD.ハチソン、 "インターネット：？グローバル通信ソリューション"、IEEEネットワーク、2000年7月/ 8月。
[2] B. Leiner, et. al., "A Brief History of the Internet version 3.31", revised 4 Aug 2000.
[2] B.レイナー、ら。アル。、「インターネット版3.31の歴史」、2000年8月4を改訂。
[3] Eder, M. and S. Nag, "Service Management Architectures Issues and Review", RFC 3052, January 2001.
[3]エダー、M.とS.ナグ、 "サービス管理アーキテクチャの問題やレビュー"、RFC 3052、2001年1月。
[4] Y. Bernet, "The Complementary Roles of RSVP and Differentiated Services in the Full-Service QoS Network", IEEE Communications Magazine, February 2000.
[4] Y. Bernet、「フルサービスのQoSネットワークにおけるRSVPと差別化サービスの補完的な役割」、IEEE通信誌、2000年2月。
[5] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[5]フロイド、S.とL. Daigle氏、 "オープン・プラグイン可能なエッジサービスのためのIAB建築・ポリシーに関する注意事項"、RFC 3238、2002年1月。
[6] Recommendation M.3010 "Principles for a telecommunications management network", ITU-T, February 2000.
[6]勧告M.3010、ITU-T、2000年2月 "電気通信管理ネットワークのための原則"。
[7] Recommendation M.3100 "Generic network information model", ITU-T, July 1995.
[7]勧告M.3100 "汎用ネットワーク情報モデル"、ITU-T、1995年7月。
[8] Moore, B., Ellesson, E., Strassner, J. and A. Westerinen, "Policy Core Information Model -- Version 1 Specification", RFC 3060, February 2001.
[8]ムーア、B.、Ellesson、E.、Strassner、J.およびA. Westerinen、 "方針コア情報モデル - バージョン1つの仕"、RFC 3060、2001年2月。
[9] V. Jacobson, "Differentiated Services for the Internet", Internet2 Joint Applications/Engineering QoS Workshop.
[9] V. Jacobson氏、 "インターネットのための差別化サービス"、Internet2の共同アプリケーション/エンジニアリングQoSワークショップ。
[10] Nichols, K., Jacobson, V. and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", RFC 2638, July 1999.
[10]ニコルズ、K.、ヤコブソン、V.およびL.チャン、 "インターネットのための2ビットの差別化サービスアーキテクチャ"、RFC 2638、1999年7月。
[11] Mankin, A., Baker, F., Braden, B., Bradner, S., O'Dell, M., Romanow, A., Weinrib, A. and L. Zhang, "Resource ReSerVation Protocol (RSVP) Version 1 Applicability Statement Some Guidelines on Deployment", RFC 2208, September 1997.
[11]マンキン、A.、ベイカー、F.、ブレーデン、B.、ブラドナー、S.、オデル、M.、Romanow、A.、Weinrib、A.およびL.チャン、「リソース予約プロトコル（RSVP ）バージョン1適用性に関する声明展開に関するいくつかのガイドライン」、RFC 2208、1997年9月。
Michael Eder Nokia Research Center 5 Wayside Road Burlington, MA 01803, USA
マイケル・エダーノキア・リサーチセンター5道端の道路バーリントン、MA 01803、USA
Phone: +1-781-993-3636 Fax: +1-781-993-1907 EMail: Michael.eder@nokia.com
電話：+ 1-781-993-3636ファックス：+ 1-781-993-1907 Eメール：Michael.eder@nokia.com
Sid Nag PO Box 104 Holmdel, NJ 07733, USA
シド私書箱104ホルムデル、NJ 07733、USA
Phone: +1-732-687-1762 EMail: thinker@monmouth.com
電話：+ 1-732-687-1762 Eメール：thinker@monmouth.com
Hemant Chaskar Nokia Research Center 5 Wayside Road Burlington, MA 01803, USA
Hemant Chaskarノキア・リサーチセンター5道端の道路バーリントン、MA 01803、USA
Phone: +1-781-993-3785 Fax: +1-781-993-1907 EMail: hemant.chaskar@nokia.com
電話：+ 1-781-993-3785ファックス：+ 1-781-993-1907 Eメール：hemant.chaskar@nokia.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。