[要約] RFC 3387は、IPネットワークにおけるサービス品質（QoS）に関するService Management Research Group（SMRG）の考慮事項をまとめたものです。このRFCの目的は、QoSの実装と管理に関するガイドラインを提供することです。
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
IPネットワークのサービス品質（QoS）に関するサービス管理研究グループ（SMRG）からの考慮事項
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.
Copyright（c）The Internet Society（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ネットワーク管理の設計における指針はシンプルであり、集中制御はありませんでした。最良の努力サービスのパラダイムは、元の管理原則の結果であり、その他の方法でした。別のパケットまたはフローのセットに与えられたサービスを別のパケットまたはフローに区別するための新しい方法が順調に進んでいます。ただし、IPネットワークが進化するにつれて、過去の管理アプローチは、サービスの品質（QOS）に想定されている将来の一部が想定している可能性のあるネットワークに適用されない場合があります。このドキュメントでは、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ネットワークの設計における指針の原則の1つでした。ただし、IPネットワークが進化するにつれて、IPのサービスの概念も進化しており、過去の戦略は、将来のために想定されるフルサービスのQoS対応ネットワークには適用されない可能性があります。IPコミュニティ内では、IPの約束が満たされる場合、ネットワークはますます多様なサービスを提供する必要があるという議論のために、彼らはかなりの推進力が存在します。IPにおけるこれらの新しいサービスの定義により、IPネットワークが利用する現在の制御メカニズムの再評価が必要になりました。あるセットのパケットまたはフローに与えられたサービスを別のパケットまたはフローに区別するためのメカニズムを提供する努力は順調に進行していますが、これらのメカニズムを活用するために必要なサポート機能の多くは範囲が制限されており、完全なフレームワークは存在しません。これは、これらの新しいサービスの多くが、コントロールのフレームワークに加えて、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機能をサポートするための提案された変更は、既存の制御構造に非常に劇的な方法で影響を与えます。問題を悪化させるのは、IP [3]の「サービス」を構成するものを理解していないことです。他のいくつかのネットワークテクノロジーとは異なり、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ネットワークでサービス管理を定義する努力を開始する場所の1つは、電気通信ネットワークで以前に行われたことを調べることです。サービス管理フレームワークの電気通信基準は、サービスがかなり制約されている環境でさえ、大規模な受け入れを受けていません。ネットワークオペレーターがサービスの提供に複数のベンダーの参加を可能にするために、ネットワークオペレーターがネットワークを十分に開設する必要があるため、多くの独自のプロトコルが依然として市場で支配しています。これは、いくつかの正式な境界が存在するか、市場がインターフェイスの開発を正当化するのに十分な大きさであることを示しています。国際的な通信管理標準では、それを別々にしかし高度に関連する層に分割することにより、完全な管理問題を検討します。IPの管理問題を説明するために使用される用語の多くは、電気通信基準から拡散されています[6]。これらの標準は、通信ネットワークとサービスに対処するために特別に設計されており、IPネットワークにどの程度適用されるかは明確ではありません。サービス管理は、通信ネットワークに見られるサービスのセットに関して定義されており、管理フレームワークはこれらのネットワークの階層的集中制御構造を反映しています。サービス管理のためのフレームワークは、Managementへの通信管理ネットワーク（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のサービス管理フレームワークを定義する際には、管理する必要があるサービスの性質に対処する必要があります。従来、ネットワーク管理フレームワークは、情報フレームワークと、情報をネットワークデバイスに配布するためのフレームワークの2つの部分で構成されています。分布フレームワークは情報フレームワークをサポートする必要があるという点で非常に簡単な関係が存在しますが、情報と配布のフレームワークがシステムの管理について意味するものとより微妙な関係が存在します。情報フレームワークは、対処するのが簡単な問題であり、主にIPコミュニティによって焦点を当てている問題であると思われます。
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.
これらのネットワークで管理される要素の数には、この情報を高度に分配する必要があります。高度に分散されたディレクトリは、静的な性質の情報の主要な候補者になります。動的な性質の情報については、問題ははるかに複雑になり、まだ十分に対処されていません。ポリシー管理は、ネットワークでDirectriesサービスを配布していることの論理的拡張です。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.
標準化の取り組みは、性格がマルチドメインである管理上の問題に集中する必要があります。マルチドメインのテストは、多くの場合、2つ以上の異なるエンティティの関与を必要とする多面的または1対多数の関係を中心にしています。ドメインは、管理ドメイン、ルーティングドメイン、またはドメイン間の合意を含めることができます。トラフィックが比較的少数のドメインのみを通過する電気通信ネットワークとは異なり、IPネットワークのトラフィックは、個別の管理制御下で多数のドメインを通過する可能性があります。状況をさらに複雑にすることは、通信ネットワークとは異なり、これらのドメインの多くは、さまざまなサービスレベル契約を提供し、対応することで非常に競争力があります。電気通信のトラフィックは、規制緩和の場合でも、アクセスプロバイダーネットワークからコアネットワークに移り、それが国際的な呼び出しである場合、国際的な境界を越えて渡されます。ドメインの数はIP Smallに関連しており、それぞれでサポートされているサービスは実質的に同一ですが、各ドメインは他とは異なるビジネスモデルを持っている可能性があります。対照的に、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つの基本的な部門に分けることができます。1つ目はサービスの定義であり、2つ目はサービスの具体化です。この部門は直感的に見えるかもしれませんが、サービスの管理が実際に実現される場合、サービスのこれらの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タイプの機能を使用することを嫌がりました。これは技術的な問題ではありませんが、サービスを効果的に管理する際に実際の問題をもたらします。将来のQoSネットワークの基本的な要件を見ると、2つの競合する哲学が明らかになります。ネットワークプロバイダーは、特に混雑した環境でトラフィックが優先されるものを選択できるようにするために、トラフィックをより多く制御できることに関心があります。ユーザーは、リースされたラインと非常によく似た特性を持つパスを識別する能力を望んでいます[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サポートが実現された場合、さらに多くのサービスが期待できます。既存のBest Effect Serviceには、認証、承認、会計サービスが依然として不十分な場合、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）またはPERホップ（DIFFSERV）と見なされるQoS輸送サービスとの区別がしばしば行われます。管理の観点からは、2つは非常に似ています。輸送レベルのサービスはあまり柔軟ではなく、輸送フレームワークに適合するためにアプリケーションレベルのサービスが必要です。追加の輸送レベルサービスを必要とするアプリケーションは、新しいインフラストラクチャへの投資を正当化できる大衆市場アプリケーションである必要があります。輸送サービスの変更に取り組んでいるため、新しいものを必要とするアプリケーションは、市場に出る時間が長くなり、新しい輸送サービスをサポートするために必要なフレームワークを開発するための努力とコストは過小評価されるべきではありません。
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ベースのeコマースの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とトラフィックトラバースドメインの合意を適切にサポートするためのネットワークプロビジョニングが必要です。ポリシー管理、オブジェクト指向情報モデル、およびドメインゲートウェイは、ドメイン全体およびネットワーク全体でフルサービスを提供する、より集中化された管理構造につながります。このようなシステムのコストと複雑さを考えると、たとえそれが事実上のものであっても、標準を思い付くことができないことを考えると、将来的にはインターネットに深刻な影響があります。
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]。同時に、エッジデバイスがネットワークリソースを最適に利用するパスを決定できることを期待することは実用的ではありません。ネットワークを介してトラフィックを転送するのに必要な情報は、1ホップごとに決定できない複雑なパラメーターに関連し、パケットの転送とは何の関係もありません。タスクのために特別に設計されたネットワークコンポーネントへのルートの決定。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.
トラフィックが認められているネットワークのエッジでは、トラフィックが指定されたものの境界内にあることを保証するメカニズムを持つ必要があります。これを達成するには、入力トラフィックをバッファリングおよび制御する必要があります。第二に、トラフィックにマークを付ける必要があるため、他のネットワーク要素は、これがフロー情報を保持することなく、これが優先されるトラフィックであることを識別できるようにする必要があります。逆に、フローに基づいて要求されるサービスのレベルに専念していたトラフィックのパスを選択できます。複数のフローに対応するリソースの予約を可能にする2つの組み合わせが可能になります。どちらの方法も管理の観点から類似しており、1つの方法で中央に実行できるルーティングの決定に関して、ネットワーク内のデバイスによるパケットの処理に基づいて仮想パスを表すだけであり、2番目のメソッドは単に仮想パスを表すことと同じです。ネットワークを通る事前に予約されたパス。既存のベストエフェクションルーティングは、これらの新しいレベルのサービスに最適なルートを提供せず、これを達成するには、最適なパス発見をサポートするルーティングプロトコルまたは必要なサービスをサポートするために必要なパスを構成するメカニズムを持つ必要があります。特定のサービスパラメーターに加えて、信頼性は潜在的なサービス差別者にもなります。障害が発生した場合、合意されたサービスレベルを維持するために新しいパスを十分に迅速に決定できるという従来のパス決定方法を使用する可能性は低いです。これは、場合によっては複数のパス予約が必要であることを意味します。フローあたりの予約はリソース集中的な仮想トランクがあまりにも多くのため、容量のブロックを予約することで管理トラフィックの量を減らすための良い方法を提供し、リソースの予約およびルート選択機能に障害が発生した場合に安定性を提供するからです。
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.
ネットワークの境界でシェーピングを提供することには意味があります。シェーピングには、レートパラメーターとバーストパラメーターの両方、および遅延の側面の両方が含まれます。特定のサービスパラメーターを使用してサービスを提供することは、主要なビジネスと技術的な問題の両方を提示することになります。定義上、パケットデータは本質的に爆発的であり、セッション中にプロバイダーがネットワークリソースをより適切に利用するために活用する合理的な希望ができるという怠idleの期間が存在します。サービスのプレミアムを支払う消費者がサービスが本当に利用可能であることを確認しないことを期待することは実用的ではありません。このようなサービスモデルは、排他的な使用または高い優先フローのために予約されていたかなりの量の帯域幅が最高の努力データには利用できないため、既存のベストエフェクションインターネットの危険に満ちているようです。
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.
ネットワーク自体内のトラフィックに関しては、ルートを事前に構成し、ルートを動的に構成する機能を提供する必要があります。事前に構成されたトラフィックの問題には、トラフィックがインターネットを介して現在設計されている方法との基本的な矛盾と、管理ドメイン間の取り決めの開発が難しいことが含まれます。現在のインターネットは、帯域幅を共有する最も平等でありながら単純な方法の1つで開発されています。既存のベスト努力サービスを公平な方法でサポートすると同時に、他のクラスのサービスを提供すると、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.
QoS管理の議論の範囲を、2つのエンドポイント間のパスの構成にのみ制限できます。この限られた範囲内でさえ、まだ多くの未解決の問題が残っています。2つのポイント間のトラフィックのQoSパスは、両方向に同じであるか、または同じである必要があるという期待はありません。接続の創始者があることを考えると、接続の発信者のプロバイダーとは異なるプロバイダーによって戻りパスが確立された場合、請求と会計がどのように解決されるかについての質問があります。請求を容易にするには、リターンパスの支払いの呼び出しを可能にするアプリケーションを許可するメソッドが存在する必要があります。請求を保証し、支払いを保証するために、データパスのすべての当事者によって信頼される第三者プロバイダーを設立する必要があります。IETFプロトコルと非ITFプロトコルの両方に基づいて構築された仮想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つのプロングです。最初に、管理ドメイン内に対処する必要がある管理、次にドメイン間の管理があります。アーキテクチャの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.
1ホップごとにサービスのクラスを保証することは、エンドツーエンドベースでサービスを保証するものではありません。帯域幅の保証とエンドツーエンドを保証するエラー率の定量的境界に保証を含めなかった場合、顧客が改善されたレベルのサービスに対して喜んで支払うことはおそらくありません。これにより、目的のエンドツーエンドの結果を達成するために、ネットワークを通るパスを工学する必要があります。この種のサービスを提供しようとする最初の試みは、特定の侵入と出口の境界のみを指定する可能性が非常に高いですが、堅牢性と柔軟性のために、そのような制限なしにそのようなサービスをサポートできるネットワークを持つことが望ましいでしょう。diffservアーキテクチャとは対照的に、intservアプローチは、コアネットワークのフロー情報を必要とし、これの結果としてスケーラブルではないことが証明される可能性があります[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、IntServ、およびポリシーワーキンググループの作業によって説明されています。対照的に、アプリケーションに関連するサービスの問題に十分な努力が焦点を合わせていません。現在のソリューションは、アプリケーションが独自のサービス管理機能を構築するためのものです。これは多くの場合、ネットワークリソースの非効率的な使用ですが、さらに重要なことには、輸送レベルのサービスとそれらが提供する機能へのアクセスを提供しません。
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。Edwards、およびD. Hutchison、「The Internet：A Global Telecommunications Solution？」、IEEE Network、2000年7月/8月。
[2] B. Leiner, et. al., "A Brief History of the Internet version 3.31", revised 4 Aug 2000.
[2] B.ライナー、他al。、「インターネットバージョン3.31の簡単な歴史」、2000年8月4日改訂。
[3] Eder, M. and S. Nag, "Service Management Architectures Issues and Review", RFC 3052, January 2001.
[3] Eder、M。およびS. Nag、「サービス管理アーキテクチャの問題とレビュー」、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 Communications Magazine、2000年2月。
[5] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[5] Floyd、S。and L. Daigle、「Open Pluggable Edge Servicesの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] Moore、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.ジェイコブソン、「インターネットの差別化されたサービス」、Internet2共同アプリケーション/エンジニアリングQoSワークショップ。
[10] Nichols, K., Jacobson, V. and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", RFC 2638, July 1999.
[10] Nichols、K.、Jacobson、V。、およびL. Zhang、「インターネット用の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] Mankin、A.、Baker、F.、Braden、B.、Bradner、S.、O'Dell、M.、Romanow、A.、Weinrib、A。and L. Zhang、 "リソース予約プロトコル（RSVP）バージョン1適用性声明展開に関するいくつかのガイドライン」、RFC 2208、1997年9月。
Michael Eder Nokia Research Center 5 Wayside Road Burlington, MA 01803, USA
マイケルエダーノキアリサーチセンター5ウェイサイドロードバーリントン、マサチューセッツ州01803、米国
Phone: +1-781-993-3636
Fax: +1-781-993-1907
EMail: Michael.eder@nokia.com
Sid Nag PO Box 104 Holmdel, NJ 07733, USA
Sid Nag PO Box 104 Holmdel、NJ 07733、米国
Phone: +1-732-687-1762
EMail: thinker@monmouth.com
Hemant Chaskar Nokia Research Center 5 Wayside Road Burlington, MA 01803, USA
Hemant Chaskar Nokia Research Center 5ウェイサイドロードバーリントン、マサチューセッツ州01803、米国
Phone: +1-781-993-3785
Fax: +1-781-993-1907
EMail: hemant.chaskar@nokia.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。