RFC3387 日本語訳
3387 Considerations from the Service Management Research Group (SMRG)on Quality of Service (QoS) in the IP Network. M. Eder, H. Chaskar,S. Nag. September 2002. (Format: TXT=52693 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Eder
Request for Comments: 3387 H. Chaskar
Category: Informational Nokia
S. Nag
September 2002
コメントを求めるワーキンググループM.エーダーの要求をネットワークでつないでください: 3387時間Chaskarカテゴリ: 情報のノキアS.小煩い人2002年9月
Considerations from the Service Management Research Group (SMRG)
on Quality of Service (QoS) in the IP Network
IPネットワークにおけるサービスの質(QoS)に関するサービス管理研究グループ(SMRG)からの問題
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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ネットワークが発展するとき、過去のマネージメント・アプローチはいくつかによって未来に思い描かれたService(QoS)のできるネットワークのQualityに適用されないかもしれません。 このドキュメントはQoSが扱われるために残っているいくつかの問題への管理と一見に持っていそうである影響力の領域のいくつかを調べます。
1. Introduction
1. 序論
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
他の何よりも簡単さはIPネットワークのデザインにおける指導原理の1つでした。 しかしながら、IPネットワークが発展するのに従って、また、IPにおけるサービスの概念は発展しています、そして、過去の戦略はいくつかによって未来に思い描かれたフルサービスのQoSできるネットワークに適用されないかもしれません。 IP共同体の中でそれら、存在、ネットワークが、IPの約束が実現することであるなら、増加するバラエティーのサービスを提供する必要があるという主張のための多くの起動力。 IPとのこれらの新種業務の定義はIPネットワークによって利用された現在の制御機構の再査定の必要性をもたらしました。 別のものに比例して1セットのパケットか流れに与えられたサービスを区別するためにメカニズムを提供する取り組みはよく進行中です、そして、しかし、これらのメカニズムを利用するのに必要な支援機能の多くが範囲で制限されます、そして、完全なフレームワークは制限されます。
Eder, et. al. Informational [Page 1] RFC 3387 IP Service Management in the QoS Network September 2002
etエーダー、アル。 QoSの経営者側が2002年9月にネットワークでつなぐ情報[1ページ]のRFC3387IPサービス
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.
実在しません。 また、これらの新種業務の多くがコントロール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ネットワークがどんな種類の重要な方法でもまさしく伝統的なベストエフォート型サービス以上を提供するなら。
2. Background
2. バックグラウンド
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
簡単さを他の何もかもに[1]を優先させるように、QoSのために管理フレームワークを定義するタスクは過去に、IPのコアにあって、明確なデザイン戦略を持っていたベストエフォート型サービスモデルから急進的な出発を表すという事実で難しくなるでしょう。 この哲学はどこにもありませんでした。ネットワークとサービス管理領域よりIP[2]には明らかです。 さまざまなQoSが特徴であるとサポートする変更案は非常に劇的な方法で既存の制御構造に影響を与えるでしょう。 問題を悪化させるのは、IP[3]で「サービス」を作ることに関する無理解です。 ある他のネットワーク技術と異なって、IPでは、単にサービス管理の範囲を終わりから終わりへの接続性に制限するために十分ではありませんが、また、パケットに提供された輸送サービスと輸送が使用されている方法を含んでいなければなりません。 QoS管理は、より一般的なサービス管理の部分集合です。 QoS管理問題を解決するために見る際に、サービス管理問題の問題と制限のいくつかを理解しているのは役に立つ場合があります。 QoSはスタンドアロン実体として扱うことができないで、一般的なより高い平らなサービス要件で管理要件を動かさせるでしょう。 IPにおける利用可能な輸送サービスが広がると、結果はサービスであると考えられることに関して一層の拡張になるでしょう。 現在のデファクト包含、IPの範囲でのWEBサービスでは、サービス(IPが最初に発明されたとき、WEBが存在しなかったとしても、顕著である)はこの状況をよく例証します。 この現象は、現在の傾向に従ってネットワークの限界に向かった動くネットワーク決定ポイントに向かって増加すると予想されて、その結果アプリケーションと顧客により近い場合があります。 さらに、議論はQoSの必要性の上で全くIPネットワークで続きます。 ファイバーに基づく新技術と波長分割多重技術で、多くの人々が帯域幅が非常に安価になるので分化をQoSに供給するための明白なコントロールフレームワークを持つのは必要でないと確信しています。 どのように不経済であっても、ピーク用法のためにネットワークを設計することになっていて、確かに、この討論における主要な議論はQoSネットワークの操作上のサポート・システムを開発して、既存のネットワークで彼らを配布する費用です。 それが知られているように顧客が追加サービスの代価を払うのが、全面的な建築変化がそれであると実装するための正当化でないかもしれないことを望むかもしれないというまさしく事実は重大にインターネットに影響するかもしれません。
Eder, et. al. Informational [Page 2] RFC 3387 IP Service Management in the QoS Network September 2002
etエーダー、アル。 QoSの経営者側が2002年9月にネットワークでつなぐ情報[2ページ]のRFC3387IPサービス
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.
今日。 IP共同体は非常に関係がなければなりません。ベストエフォート型インターネットを特徴付けた平等は完全に異なったビジネスモデルを持っているサービスを支持して犠牲にされるかもしれません。 コアネットワークが、より多くの収入であると生成されたそれをサービスに提供し始めるなら、それは容易にベストエフォート型サービスを生成するより少ない収入を犠牲にして来ることができるでしょうに。
3. IP Management Standardization
3. 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でのPolicy作業であり、DMTFはCIMとDENに勤めます。 サービス管理フレームワークの重要な要素は見解に入っていますが、過去の制御機構からのかなり急進的な出発である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によってされるでしょう。
Eder, et. al. Informational [Page 3] RFC 3387 IP Service Management in the QoS Network September 2002
etエーダー、アル。 QoSの経営者側が2002年9月にネットワークでつなぐ情報[3ページ]のRFC3387IPサービス
4. Telecommunications Service Management
4. テレコムサービス管理
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ネットワークにどれくらい適切になるかは明確ではありません。 サービス管理はテレコミュニケーションネットワークで見つけられたサービスのセットで定義されます、そして、管理フレームワークはこれらのネットワークの階層的な集中制御構造を反映します。 サービス管理が電気通信管理課Network(TMN)に基づいているので、フレームワークは管理へのアプローチを層にしました。 現在のIP規格は大いに特に要素管理層と分散アプローチが強調されている統計データの集会に向かって重みを加えられます。 TMNアーキテクチャでは、依存は層の間に存在しています、そして、境界の明確なインタフェースは定義されます。 層[6]の間のインタフェースを正式にしたという要件への抵抗がどこにおそらくあるかが、TMN規格で定義されるサービス管理はIPに適用できるというどんな範囲により遠いに違いないかが調査されました。
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管理フレームワークはそれであるならいずれのテレコミュニケーションレガシーのためにもしないところでこれらの区別さえしていないかもしれません。
Eder, et. al. Informational [Page 4] RFC 3387 IP Service Management in the QoS Network September 2002
etエーダー、アル。 QoSの経営者側が2002年9月にネットワークでつなぐ情報[4ページ]のRFC3387IPサービス
5. IP Service Management: Problem Statement
5. 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のためにService Management Frameworkを定義する際に、管理される必要があるサービスの本質を扱わなければなりません。 伝統的に、ネットワークマネージメントフレームワークは、ネットワークデバイスに情報を分配するために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.
これらのネットワークで管理されるべき要素の数は、この情報が非常に分配されるのを必要とするでしょう。 非常に分配されたディレクトリは静的に自然な情報の主要な候補でしょう。 ダイナミックに自然な情報に関しては、問題は、はるかに複雑になっていなくて、またまだ満足に扱われていません。 政策管理はネットワークで利用可能なディレクトリサービスを広げた論理的な拡大です。 IETFとDMTFは、あるサービス管理問題を扱うためにPolicy管理がフレームワークであることを当てにしています。 特定のネットワーク要素とただ一つの管理ドメイン[8]だけにおいて、通貨政策取り組みの多くがアクセスとトラフィック優先順位づけに集中しています。 入場問題に焦点を合わせる意図をもって交通の流れを分類して、縁で方針を実施すると、終わりから終わりが問題の性格であると扱わない、いくつかの最も複雑なQoSが管理問題へまだ答えがない状態でおかれます。 証明可能な商品レベルのサービスをIPに提供すると、ネットワークのあらゆる一面が作用するでしょう、そして、問題の運営方法はそれが作動するスケールと力学を扱わなければならないでしょう。
5.1 Common Management Domain
5.1 一般的な管理ドメイン
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
標準化取り組みは、ぴったりしたマルチドメインである管理問題に集中する必要があります。 マルチドメインのためのテストはそこらのしばしば多くの1〜1つへの多くである、2のかかわり合いを必要とする関係または以上への別個の物を中心に置きます。 ドメインは、ドメインを発送して、管理ドメインを反映するか、またはドメインの間の協定を含むかもしれません。 the
Eder, et. al. Informational [Page 5] RFC 3387 IP Service Management in the QoS Network September 2002
etエーダー、アル。 QoSの経営者側が2002年9月にネットワークでつなぐ情報[5ページ]のRFC3387IPサービス
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.
トラフィックが比較的少ない数のドメインだけを横断するテレコミュニケーションネットワーク、IPネットワークにおけるトラフィックは別々の運営管理コントロールの下の多数のドメインを横断しそうです。 さらに状況を複雑にするのは、そうであり、異なったサービスレベル協定を提供して、対応して、テレコミュニケーションネットワークと異なって、これらのドメインの多くが現実に非常に競争力があるようになるでしょう。 テレコミュニケーショントラフィックはアクセスプロバイダーネットワークからコアネットワークとその時まで規制緩和があっても終わります、それが国際電話であるなら、国境の向こう側に。 ドメインの数は小さくIPに比例していますが、それぞれでサポートされたサービスは実際には同じですが、ドメインがありそうであるそれぞれがもう片方からの異なったビジネスモデルを持っています。 対照的に、IPには、多くのドメイン、多くのサービスがあるでしょう、そして、ドメインはおそらく非常に競争力があるようになるでしょう。 異なったサービスモデルはただ一つの流れに責任があるのを持ちながら、うまくいっているIPであることが、それぞれ多くの独立しているネットワークを持ちながら起こる複雑さを減少させる方法でドメイン問題をモデル化する必要があるでしょう。 また、ソリューションが1つのドメインネットワークの能力のあまりに多くの情報を競争相手に暴露してはいけないので、互いのダイレクト競争相手であるドメインの向こう側にサービス管理が問題であると扱うのがプロセスを複雑にするでしょう。 ソリューションは同時に機密情報が1つからもう片方に変化しないのを保障している間、必要な管理機能を提供すると両方によって信じられた第3のパーティーを必要とするかもしれません。
5.2 Service Management Business Processes
5.2 サービス管理ビジネスプロセス
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
それがそれを能力に写像するのにおいて可能であるに違いないサービスを指定することにおける基本的なネットワークアーキテクチャ。 サービスは、サービスのコントロールを可能にするために適所にメカニズムを置くことができるように明白な方法で指定される必要があります。 それは、オブジェクト指向モデルとのそのオブジェクトの具体化へのオブジェクトの定義の間の関係に対するそのサービスのインスタンスに対するサービスの定義の関係を見るためには有益な手段であるかもしれません。 ネットワークが発展するのに従って個々の領域とドメインを超えるのは、サービス、IPネットワークが分類が利用可能に作られているために必要とするそのように断片化している特定のサービスであるのでネットワーク能力について論理的に説明するのに必要でありに行くことです。 そしてそれが定義するインタフェース。
Eder, et. al. Informational [Page 6] RFC 3387 IP Service Management in the QoS Network September 2002
etエーダー、アル。 QoSの経営者側が2002年9月にネットワークでつなぐ情報[6ページ]のRFC3387IPサービス
controls the network capabilities, abstracted for the service perspective, allows for the administration of the network by the service management systems.
サービス見解のために抜き取られたネットワーク能力がネットワークの管理のためにサービスマネージメントシステムで許すコントロール。
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.
サービスはしばしばそれらに、特定の管理能力で設計されています。 これらのサービスは、ネットワークについてサービス局面を当てにするのではなく、輸送能力だけに関して当てにする傾向がありました。 サービスがネットワークにより依存するようになるので、共有されたフレームワークの上のManagementは必要になるでしょう。 オペレータはユーザにはそれら自身のサービスの管理のできるだけ多くのコントロールがあるのを許容するビジネスの必要性を認めました。 サービスの管理をある一層の非常に多様でカスタマイズ可能な必要とするのが人工であったなら、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環境で、これは重要な管理挑戦を作成するでしょう。
5.3 Billing and Security
5.3 支払いとセキュリティ
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.
何かサービスの成功へのパラマウントは、そのサービスがどのように請求されるかを決定しています。 サービス始まりで支払いが行われるプロセスを定義しなければなりません。 支払いに必要なネットワークサポートが扱われるべきであるのが、ここにそれがあります。 また、類似して、サービス定義の最も多くの初期段階にセキュリティを扱わなければなりません。 あらゆるサービスのために支払いとセキュリティ機能を明確に設計させるのが支払いとセキュリティー・サービスがサービス自体と同じプロバイダーによって主催されるか、または可能になると仮定するのは実用的ではありません。 これらの機能はネットワークの汎用パーツにならなければならないでしょう。
5.4 Standards
5.4 規格
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
異なった管理支援機能の間の関係を正式にするテレコミュニケーション標準化団体取り組みの限られた成功を考えて、そのような取り組みがさらにさまざまのネットワークの、そして、サービスの概念を持っているIPネットワークに成功するのは、非常に疑わしいです。 IPネットワークが等しい統治権の同輩ドメインで構成されるつもりであると、これらのドメインを横断できる管理の機能性を持つのが必要でしょう。 もちろん、経営者の責任があるところの見解は基準点に主に依存しています。 中心の有利な地位は、責任が異なったドメインの中で等しく共有されたのを示します。 中から、どんな特定のドメイン経営者の責任もそのドメインとそのドメインだけの中に存在しています。 管理フレームワークがIPネットワークで論理的な管理機能を引き継ぐのは、これらの管理機能とインタフェースを定義するために非常にフレキシブルな定義言語と共に特定されなければならないでしょう。 よりmore
Eder, et. al. Informational [Page 7] RFC 3387 IP Service Management in the QoS Network September 2002
etエーダー、アル。 QoSの経営者側が2002年9月にネットワークでつなぐ情報[7ページ]のRFC3387IPサービス
management functionality will have to cross boundaries of responsibility, the more the network management functions have to be distributed throughout the network.
管理の機能性は責任(ネットワークマネージメント機能がネットワーク中で分配されるために持っているより多く)の境界に交差しなければならないでしょう。
5.5 Core Inter-domain Functions
5.5 コア相互ドメイン機能
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.
帯域幅Brokersは、ビジネス見解からトラフィックに関連しながら、問題の多くに対処するためのメソッドとしてドメインの間で発想されました。 Bandwidth Brokersの前提は、また、同じくらい定量化可能である傾向がないしかし、トラフィック、セキュリティへの尊敬とのネットワークドメインの間の協定と支払い問題が、扱われる必要であるのを保障することになっています。 サービスプロバイダーはそのようなツールが競争相手と顧客に自分の弱さをさらけ出すと恐れるとき機能の帯域幅ブローカーか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
複雑な交通網のための建築フレームワークに対する以前の仕事のいくつかが、二国間条約が管理ドメイン[10]の間で利くメソッドに唯一なると示唆しました。 多面的な協定は管理するために本当に複雑であるかもしれませんが、よく、トラフィックが、定量化しにくい多くの管理ドメインを横断する必要があると、二国間条約は比例しないでしょう。
Eder, et. al. Informational [Page 8] RFC 3387 IP Service Management in the QoS Network September 2002
etエーダー、アル。 QoSの経営者側が2002年9月にネットワークでつなぐ情報[8ページ]のRFC3387IPサービス
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.
終わりから終わりに対する提供されるサービス。 また、ドメインの所有権と管理における不安定性は終わりから終わりに対するサービスを予測することにおける、二国間条約のユーザビリティを制限するでしょう。
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ネットワークが平凡になるなら、他のプロバイダーがそれらと対にされるのを引き起こすことができないプロバイダーは競争できないかもしれません。 小さくて中型のサービスプロバイダーにおいて、これは特に目に見えるでしょう。(サービスプロバイダーはサービスの最高水準を提供できないより大きいプロバイダーか表面に結合するように圧力をかけられるでしょう)。 この現象が国境の向こう側に展開するなら、最終的な結果が何であるだろうかを予測しにくいです。
5.6 Network Services
5.6 ネットワークサービス
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
サービスがアプリケーションレベルサービスに分類されて、平らなサービスを輸送できるのは、妥当です。 輸送サービスはネットワークがどんなアプリケーションの如何にかかわらず提供するサービスです。 これらはPacket Forwardingやルート設定、QoS Traffic Engineering分化などのサービスを含んでいます。 また、これらはセキュリティ(Ipsec)とディレクトリサービスのような機能を含むかもしれません。 IPネットワークでは、終わりから終わりへの(RSVP)か1ホップあたりの(Diffserv)として見なされるQoS輸送サービスの間で区別をしばしばします。 経営的視点から、2は非常に同様です。 輸送フレームワークに収まるようにアプリケーションレベルサービスを必要として、輸送レベルサービスはそれほどフレキシブルではありません。 追加輸送レベルサービスを必要とするアプリケーションは、新社会資本への投資を正当化できる大衆市場アプリケーションである必要があるでしょう。 輸送を変更することにおける取り組み
Eder, et. al. Informational [Page 9] RFC 3387 IP Service Management in the QoS Network September 2002
etエーダー、アル。 QoSの経営者側が2002年9月にネットワークでつなぐ情報[9ページ]のRFC3387IPサービス
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.
サービス、新しいものを必要とするアプリケーションが売り出すより長い時間を持つでしょう、そして、新しい輸送がサービスであるとサポートするのに必要なフレームワークを開発する取り組みと費用を過小評価するべきではありません。
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.
アプリケーションレベルサービスはアプリケーションに特定のそれらです。 多くのサービス管理機能がアプリケーション供給者とアプリケーション消費者の間に起こります(既存のネットワークによる知識かサポートを全く必要としません)。 サービスがこのレベルにおいて管理機能であることを保つことによって、売り出す時間とコストを大いに削減できます。 損失は多くのアプリケーションがネットワーク資源の効率の悪い使用を引き起こす同じ機能性を必要とするということです。 ネットワークによって供給されたサービスは、より強壮に建てることができて、追加機能性を提供できます、アプリケーションがそうすることができないという情報に近づく手段を持っていることによる、アプリケーションレベルサービスの上に追加利益を提供して。 Networkサービスの利益を得ることができたアプリケーションレベルサービスの例はウェブのベースのE-商業のためのAAAパラダイムです。(それは、クレジットカード情報のユーザ入力に主に制限されます)。 アプリケーションレベルサービス要件には、時々、輸送サービスとアプリケーションサービスレベルの両方の損失があります。 例えば、IP電話技術では、これはIP電話技術に特定のゲートウェイか他のネットワークデバイスによって提供された、推進かキャッチホンと呼ぶようなサービスをサポートしたサービスを含むかもしれません。 IP電話技術のマス・アピールでかなりのインフラストラクチャ変化を示すのは可能になりますが、この種類の変化の自然はIP電話技術アプリケーションの遅い侵入に貢献しました。
6. The Way to a QoS Management Architecture
6. QoS管理体系への道
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をサポートするためにネットワークの食糧を供給することを必要とします。 政策管理、オブジェクト指向情報モデル、およびドメインゲートウェイはドメインの向こう側にネットワークにフルサービスを提供するさらに集結された経営組織につながっています。 ありえそうな費用を与えて、規格と共に来るそのようなシステム障害の複雑さはそれが事実上のものであっても将来、インターネットへの重大な意味を持つでしょう。
Eder, et. al. Informational [Page 10] RFC 3387 IP Service Management in the QoS Network September 2002
etエーダー、アル。 QoSの経営者側が2002年9月にネットワークでつなぐ情報[10ページ]のRFC3387IPサービス
6.1 Point to Point QoS
6.1はポイント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
ネットワークを通した流れの数を考えて、コアは個々の流れ州[11]に関して知ることができません。 同時に、エッジデバイスがネットワーク資源を最適に利用する経路を決定できると予想するのは実用的ではありません。 ネットワークを通してトラフィックを進めるのに必要である情報が関連するようになるように、複雑なそうすることができないパラメタにホップ基礎あたりのaで断固としてください、そして、何もパケットの推進を処理するそれがルートをネットワーク要素に決定する機能がタスクのために明確に設計した移動に最もよく、理解できるかもしれないものを持たないでください。ルータはパケットをします。 QoSネットワークでは、ルーティング決定はますますデータからのルータが自分たちを論理的に平等に割り当てるかもしれないという容易にどんな情報明察可能にも依存するようにならないでしょう。 追加機能性がデータのルーティングを決定するように、これは必要性を必要とするでしょう。
Eder, et. al. Informational [Page 11] RFC 3387 IP Service Management in the QoS Network September 2002
etエーダー、アル。 QoSの経営者側が2002年9月にネットワークでつなぐ情報[11ページ]のRFC3387IPサービス
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.
ネットワークにさらに、ルータがパケットを進めるのを許容するのに必要であるすべての情報がルータのパケット推進機能への外部のネットワーク要素によって提供されないほうがよいのを示します。
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番目はプレ予約された経路でしょう、したがって、中心で実行できた決断を発送するあいさつと同じです。 既存のベストエフォート型ルーティングはこれらの新しいレベルのサービスのための最適なルートを提供しないでしょう、そして、これを達成するために、経路を構成するために最適な経路発見をサポートしたプロトコルかメカニズムを発送するのを必要なサービスをサポートするのに必要にするのが必要でしょう。 また、特定のサービスに加えて、パラメタの信頼性は潜在的サービス弁別器になるでしょう。 伝統的な経路定量法を使用することで、失敗の場合、新しい経路が同意されたサービスレベルを維持することを十分すぐに決定するかもしれないのはありそうもないです。 これはある場合に複数の経路の予約の必要性を含意するでしょう。 Per流れの予約がまた、そうので、リソースの徹底的な仮想のトランクスは、ブロックの容量を予約することによって管理トラフィックの量を減少させる早道を提供して、失敗の場合、資源予約とルート選択機能に安定性を提供するでしょう。
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
ネットワーク限界で形成しながら提供する含意があります。 形成はレートと炸裂パラメタと可能な遅れ局面の両方を含んでいるでしょう。 特定のサービスパラメタがあるサービスを支給に持っていると、ネットワーク資源をよりよく利用するのに利用する妥当な望みは技術的問題主要なビジネスとプロバイダーがそうすることができたセッションの間の怠惰の期間の定義上現実にburstyであり、存在しているパケットデータの両方に提示されるでしょう。 サービスのためにプレミアムを支払う消費者が、本当に、サービスが利用可能であったのをチェックしないと予想するのは実用的ではありません。 サービスモデルが危険で満たされるように見えるそのようなもの
Eder, et. al. Informational [Page 12] RFC 3387 IP Service Management in the QoS Network September 2002
etエーダー、アル。 QoSの経営者側が2002年9月にネットワークでつなぐ情報[12ページ]のRFC3387IPサービス
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.
ネットワーク自体の中のトラフィックに関して、ルートをあらかじめ設定して、ルートをダイナミックに構成させる能力を提供する必要があるでしょう。 あらかじめ構成されたトラフィックに関する問題のいくつかがトラフィックが現在管理ドメインの間でインターネットと困難を通して展開しているアレンジメントで設計される方法がある基本的な矛盾を含んでいます。 帯域幅を共有する今まで最も平等主義者の安易なメソッドの1つで現在のインターネットを開発してあります。 他のクラスのサービスが潜在的に物凄い量の複雑さをQoS体系に加えるかもしれないので、同時に提供する間、不遍の方法で既存のベストエフォート型サービスをサポートします。 他方では、予約された帯域幅が共有されないなら、私たちが今日それを知っているようにそれはインターネットの帯域幅の有用性で重要な影響をもたらすかもしれません。 QoSは潜在的に彼らが不十分な帯域幅であるのにさらに貢献するかもしれません、他のサービスで使用できないネットワークの中に帯域幅を控えることによって、この帯域幅が多くの現代のためにunderutilizedされると予想できますが。 商品帯域幅を販売したい際にサービスプロバイダーの動機をそれに加えてください。そうすれば、インターネット帯域幅の有用性に対する物凄い圧力があるかもしれません。
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ネットワークの中で何らかの形式の分類できるサービスをサポートする特定の技術を使用するのに関係しました。
6.2 QoS Service Management Scope
6.2QoSが管理範囲を調整します。
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
人はQoS管理の議論の範囲を2つの終点の間の経路の構成だけに制限する場合があります。 この限られた範囲の中にさえ、多くの未解決問題がまだ残っています。 2ポイントの間のトラフィックのためのQoS経路が必要がある期待であることが全くあるべきではありませんか、またはあるべきです、両方の方向と同じです。 リターンパスが異なったプロバイダーによって確立されるなら、決議されてください。それがある接続の創始者がどのように請求して説明するのに関して質問するかということであるためにそこで望んでいる当然のこと、そして接続の創始者のもの。 メソッドが存在するように必要とする支払いを容易にするために、それはまた、リターンパスの代価を払って、コレクトコールがまた、されるという要求をアプリケーションの起因するのに可能にします。 3番目のパーティー
Eder, et. al. Informational [Page 13] RFC 3387 IP Service Management in the QoS Network September 2002
etエーダー、アル。 QoSの経営者側が2002年9月にネットワークでつなぐ情報[13ページ]のRFC3387IPサービス
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.
プロバイダーは、請求していて保証された支払いを保障するのに設立されて、それがデータ経路のすべてのパーティーによって信じられるということである必要があるでしょう。 IETFと非IETFのプロトコルの両方に造られる仮想のDCNのサービスを利用して、サービスプロバイダーと3番目のパーティー検証制度の間のメッセージを保証できます。 シグナリングプロトコルは呼び出しの費用とだれがそれの代価を払うかを証明するために必要になるでしょう、そして、各プロバイダーはサービスのための請求書への証明可能なメソッドを提供する必要があるでしょう。 より早く指摘されるように、この機能性は既存の電話網に使用されることと同様になるでしょう、はるかに大きいスケールであって、潜在的に互いと共に非常に競争力があるプロバイダーにかかわるのを除いて。
7. The DiffServ Architecture
7. DiffServアーキテクチャ
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.
ホップ基礎あたりのaでサービスのクラスを保証するのは、決して終わりから終わりへのベースにおけるサービスの保証ではありません。 遅れの帯域幅と量的な領域における保証を含まないで、誤り率が終わらせる終わりを保証するなら、顧客は、改良されたレベルのサービスの代価を払っても構わないと思っていそうにないでしょうに。 これは、必要な終わりから結末を獲得するためにネットワークを通して経路を設計するのを必要とするでしょう。 この種類のサービスを提供することへの初期の試みが特定のイングレスと出口の境界だけを非常に指定しそうな間、そのような制限なしでそのようなサービスをサポートすることができるネットワークを持っているのは丈夫さと柔軟性に、望ましくなるでしょう。 Intservアプローチは、DiffServアーキテクチャと対照的にコアネットワークで流れ単位で情報を必要として、これの結果、スケーラブルな[11]でないと判明するかもしれません。 ネットワークの実際の力学をサポートするために、あらかじめ食糧を供給される、および変更されていて、保証されたネットワーク事情としてDiffServタイプアーキテクチャは限られた数のサービスのクラスと共にあるかもしれません。
Eder, et. al. Informational [Page 14] RFC 3387 IP Service Management in the QoS Network September 2002
etエーダー、アル。 QoSの経営者側が2002年9月にネットワークでつなぐ情報[14ページ]のRFC3387IPサービス
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の間に存在している間、これらの種類の要件を実装するのに必要である取り組みのレベルに関する何らかの洞察を提供してください。 考えて、皮肉にも、過去のインターネットコミュニティはテレコミュニケーションネットワークの経営のために提案される標準化のレベルを拒絶して、それは今までに必要なサービスを提供するならそのような要件を完成するのが実際に必須になるところのフルサービスインターネットであるかもしれません。
8. A Summary of the QoS Functional Areas
8. 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.
管理領域会計と、サービスシグナリングと、サービスの間では、検証が必要でしょう。 ネットワークの管理限界では、縁で提供されたものと同様の機能は必要になるでしょう。 異なった管理ドメインの同輩実体は境界の向こう側に彼らの必要性を示すでしょう。 そして、境界での検証は縁での検証と一致していた状態で起こることができました。 境界を通した実際のトラフィックは測定されて請求している情報であるかもしれません。ドメインの間に移します。 中枢管理機能は失敗の場合、交通ルートを変更するか、または既存のネットワーク資源をよりよく利用するのにおいて原因となるでしょう。
Eder, et. al. Informational [Page 15] RFC 3387 IP Service Management in the QoS Network September 2002
etエーダー、アル。 QoSの経営者側が2002年9月にネットワークでつなぐ情報[15ページ]のRFC3387IPサービス
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サービスのプロバイダーに利用可能なパーティー検証と3番目の合法化機能の必要性を示します。 トランザクションの機能性の半面の上に、価格設定情報を提供して、支払い支払請求書要求をするインタフェースが価格設定と支払いを承認するのに必要であって、側がそこで必要があるもう片方にあります。
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 Service Management Research Groupの今後の活動はこれらの要件で詳細の中を見るつもりです。
9. Security Considerations
9. セキュリティ問題
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からプロトコルと対話するService Managementアーキテクチャと同じくらい複雑な問題に関しては、特定のワーキンググループで標準化されるのは同時に問題の特定の部分を開ける間、全体像を覚えておくのに必要に思えます。 したがって、総合的なService Managementアーキテクチャアドレスセキュリティが関する要件は、必ずセキュリティー対策が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.
このドキュメントは、どんな新しいプロトコルも提案しないで、またしたがって、その意味で、どんなセキュリティ問題にもかかわりません。 しかしながら、セキュリティのこのドキュメントの考慮の間中、建築議論で提起された問題は扱われます。
10. Summary
10. 概要
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
IP共同体は現在、輸送QoS問題に関連することにおける問題を解決するのにおいて非常に活動的です。 これらの活動はDiffserv、Intserv、およびPolicyワーキンググループの仕事で例証されます。 対照的に、十分な取り組みはどんなアプリケーションに関連するサービス問題に焦点を合わせられていません。 現在のソリューションはアプリケーションがそれら自身のサービス管理の機能性に建てられることです。 これはそうです。
Eder, et. al. Informational [Page 16] RFC 3387 IP Service Management in the QoS Network September 2002
etエーダー、アル。 QoSの経営者側が2002年9月にネットワークでつなぐ情報[16ページ]のRFC3387IPサービス
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.
しばしばネットワーク資源の効率の悪い使用、以上だけがそれらが提供する平らなサービスと機能性を輸送するために重要にアクセスに備えないでしょう。
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サービスを定義するために行われた仕事を広げるのは、これが機能性を必要としたと展開するための出発点に約束しています。
11. References
11. 参照
[1] L. Mathy, C. Edwards, and D. Hutchison, "The Internet: A Global
Telecommunications Solution?", IEEE Network, July/August 2000.
[1] L.マティ、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] et B.Leiner、アル、「インターネットバージョン3.31インチのBrief歴史、改訂された2000年8月4日。」
[3] Eder, M. and S. Nag, "Service Management Architectures Issues
and Review", RFC 3052, January 2001.
[3] RFC3052、エーダー、M.、およびS.は「サービス管理体系問題とレビュー」と口喧しく言って、1月は2001です。
[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、「開いているPluggable縁のサービスのためのIAB建築するのと方針問題」、RFC3238、2002年1月。
[6] Recommendation M.3010 "Principles for a telecommunications
management network", ITU-T, February 2000.
[6] 推薦M.3010、「テレコミュニケーションマネジメント・ネットワークのためのプリンシプルズ」、ITU-T、2月2000
[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仕様」、RFC3060、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] ニコルズとK.とジェーコブソンとV.とL.チャン、「インターネットへの安っぽい微分されたサービス構造」、RFC2638、1999年7月。
Eder, et. al. Informational [Page 17] RFC 3387 IP Service Management in the QoS Network September 2002
etエーダー、アル。 QoSの経営者側が2002年9月にネットワークでつなぐ情報[17ページ]のRFC3387IPサービス
[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.チャン、「資源予約がバージョン1つの(RSVP)適用性証明についていくつか議定書の中で述べる、展開に関するガイドライン、」、RFC2208(1997年9月)
12. Authors' Addresses
12. 作者のアドレス
Michael Eder Nokia Research Center 5 Wayside Road Burlington, MA 01803, USA
マイケルエーダーノキアResearch Center5の道端の道路バーリントン、MA 01803、米国
Phone: +1-781-993-3636 Fax: +1-781-993-1907 EMail: Michael.eder@nokia.com
以下に電話をしてください。 +1-781-993-3636 Fax: +1-781-993-1907 メールしてください: Michael.eder@nokia.com
Sid Nag PO Box 104 Holmdel, NJ 07733, USA
Holmdel、シド小煩い人PO Box104ニュージャージー 07733、米国
Phone: +1-732-687-1762 EMail: thinker@monmouth.com
以下に電話をしてください。 +1-732-687-1762 メールしてください: thinker@monmouth.com
Hemant Chaskar Nokia Research Center 5 Wayside Road Burlington, MA 01803, USA
Hemant Chaskarノキアリサーチセンター5の道端の道路バーリントン、MA 01803、米国
Phone: +1-781-993-3785 Fax: +1-781-993-1907 EMail: hemant.chaskar@nokia.com
以下に電話をしてください。 +1-781-993-3785 Fax: +1-781-993-1907 メールしてください: hemant.chaskar@nokia.com
Eder, et. al. Informational [Page 18] RFC 3387 IP Service Management in the QoS Network September 2002
etエーダー、アル。 QoSの経営者側が2002年9月にネットワークでつなぐ情報[18ページ]のRFC3387IPサービス
13. Full Copyright Statement
13. 完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Eder, et. al. Informational [Page 19]
etエーダー、アル。 情報[19ページ]
一覧
スポンサーリンク
