Network Working Group M. Eder
Request for Comments: 3052 Nokia
Category: Informational S. Nag
January 2001
Service Management Architectures Issues and Review
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 (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
Many of the support functions necessary to exploit the mechanisms by which differing levels of service can be provided are limited in scope and a complete framework is non-existent. Various efforts at such a framework have received a great deal of attention and represent a historical shift in scope for many of the organizations looking to address this problem. The purpose of this document is to explore the problems of defining a Service management framework and to examine some of the issues that still need to be resolved.
サービスの異なるレベルを提供することが可能な機構を利用するために必要なサポート機能の多くは、範囲が限定されており、完全なフレームワークは、非存在です。このようなフレームワークで様々な取り組みが注目を集めてこの問題に対処するために探している組織の多くのスコープでの歴史的な変化を表しています。このドキュメントの目的は、サービス管理フレームワークを定義する問題を調査するために、まだ解決すべき問題のいくつかを検討することです。
Efforts to provide mechanisms to distinguish the priority given to one set of packets, or flows, relative to another are well underway and in many modern IP networks, best effort service will be just one of the many services being offered by the network as opposed to it being the only service provided. Unfortunately, many of the support functions necessary to exploit the mechanisms by which network level service can be provided are limited in scope and a complete framework is non-existent. Compounding the problem is the varied understanding of exactly what the scope of "service" is in an IP network. IP, in contrast to connection oriented network technologies, will not be able to limit the definition of service management simply to end to end connectivity, but will combine service management with regards to transport with the service requirements of the actual applications and how they are using the network. The phenomenal growth in data networks as well as the growth in application bandwidth usage has had the consequence that the existing methods of management are not sufficient to handle the growing demands of scale and complexity.
パケット、またはフローの一組に与えられた優先順位を区別するためのメカニズムを提供するための努力は、互いに対しては順調に進んで、多くの近代的なIPネットワークであり、ベストエフォート型サービスでは、多くのサービスのひとつとは対照的に、ネットワークによって提供されているだろうそれが唯一のサービスが提供されています。残念ながら、ネットワークレベルのサービスを提供することが可能な機構を利用するために必要なサポート機能の多くは、範囲が限定されており、完全なフレームワークは、非存在です。問題を配合することは、「サービス」の範囲は、IPネットワーク内にあるまさにの様々な理解です。 IPは、コネクション指向のネットワーク技術とは対照的に、単に接続を終了するには終了し、サービスマネジメントの定義を制限することはできませんが、実際のアプリケーションのサービス要件に輸送するに関してサービス管理を統合し、それらがどのように使用されていますネットワーク。データネットワークでの驚異的な成長だけでなく、アプリケーションの帯域幅の使用量の増加は、経営の既存の方法は、規模や複雑さの増大する需要に対応するのに十分ではないという結果がありました。
The network and service management issue is going to be a major problem facing the networks of the future. This realization is a significant motivating factor in various efforts within the IP community which has been traditionally reluctant to take on issues of this type [1]. The purpose of this document is to explore the problems of developing a framework for managing the network and services and to examine some of the issues that recent efforts have uncovered.
ネットワークとサービス管理の問題は、将来のネットワークが直面する大きな問題になるだろう。この実現には、[1]、この種の問題に取ることが伝統的に難色を示してきたIPコミュニティ内のさまざまな取り組みにおいて重要な動機要因です。このドキュメントの目的は、ネットワークおよびサービスを管理するためのフレームワークを開発する問題を探求すると、最近の努力が発見した問題のいくつかを検討することです。
Network and service level issues traditionally are handled in IP networks by engineering the network to provide the best service possible for a single class of service. Increasingly there is a desire that IP networks be used to carry data with specific QoS constraints. IP networks will require a tremendous amount of management information to provision, maintain, validate, and bill for these new services. The control and distribution of management information in complex communications networks is one of the most sophisticated tasks a network management framework must resolve. This is compounded by the likelihood that devices in IP networks will be varied and have differing management capabilities, ranging from complex computing and switching platforms to personal hand held devices and everything in between. Scaling and performance requirements will make the task of defining a single management framework for these networks extremely complex.
ネットワークとサービスレベルの問題は、伝統的にサービスの単一のクラスのために可能な限り最高のサービスを提供するために、ネットワークを操作することによって、IPネットワークで処理されます。ますますIPネットワークは、特定のQoS制約を持つデータを運ぶために使用されることが望まれています。 IPネットワークは、提供する管理情報の膨大な量を必要と維持、検証、およびこれらの新しいサービスのための法案ます。複雑な通信ネットワークの制御および管理情報の配信は、ネットワーク管理フレームワークは、解決しなければならない最も洗練された課題の一つです。これは、IPネットワーク内のデバイスを変化させることや、複雑なコンピューティングに至るまでの間に個人的な手持ちのデバイスへのプラットフォーム、すべてを切り替え、管理能力の違いがあります可能性により配合されます。スケーリングとパフォーマンスの要件は、非常に複雑なこれらのネットワークのための単一の管理フレームワークを定義するタスクを行います。
In the past standardization efforts have suggested a simplified model for management on the hypothesis that it can be extrapolated to solve complex systems. This premise has often proved to be without merit because of the difficulty of developing such a model that meets both the operators heterogeneous, multi-vendor need and network equipment vendors specific needs. At the center of efforts to devise a standard management model are attempts to develop an architecture or framework to control the management information. The same conflicting operator vs. vendor forces are present in the effort to establish a common framework architecture as are in the efforts to develop a common information model.
過去の標準化活動では、複雑なシステムを解決するために推定することができるという仮説に管理するための簡略化モデルを提案しています。この前提はしばしば異質事業者は、マルチベンダーの必要性とネットワーク機器が特定のニーズを満たしているベンダーの両方のようなモデルを開発することの難しさのメリットなしであることが証明されました。標準管理モデルを考案する努力の中心に管理情報を制御するためのアーキテクチャまたはフレームワークを開発する試みがあります。ベンダーの力対同じ競合事業者は、共通情報モデルを開発する努力しているような共通のフレームワークのアーキテクチャを確立するための努力に存在しています。
Network operators requirements call for a framework that will permit centralized management of the network and require the minimal resources to operate and maintain while still providing tremendous flexibility in choice of equipment and creativity of defining services [2]. Operators may be less able to support change in their Operational Support Systems (OSS) then they are in the network infrastructure because the OSS is tightly integrated into the organizations business practices. The need for flexibility, and the other desires identified above, operators expect to have meet by having equipment vendors support open and common interfaces.
まだ機器の選択や定義の創造性に優れた柔軟性を提供しながら、ネットワークオペレータの要件は、ネットワークの集中管理を可能にするフレームワークのために電話して動作し、維持するための最小限のリソースを必要とするサービス[2]。オペレータは、OSSがしっかりと組織のビジネス慣行に統合されているので、彼らはネットワークインフラストラクチャである彼らの運用支援システム（OSS）の変化をサポートする少なくできる可能性があります。柔軟性の必要性、及び上記特定された他の欲望、オペレータは、機器ベンダーがオープンし、共通のインタフェースをサポートすることによって満たしを持っていることを期待しています。
Device manufactures have a need for management that will best represent the features and capabilities of the equipment they are developing and any management solution that hinders the ability of the equipment vendors to efficiently bring innovation to the market is contrary to their objectives.
デバイスは、最高の機能と、彼らが開発している機器やその目的に反して効率的に市場に革新をもたらすための機器ベンダーの能力を妨げるいかなる管理ソリューションの機能を表します管理の必要性を持って製造しています。
The common framework for solving the management needs of operators and equipment vendors has been based on a centralized approach with a the manager agent architecture. While providing a very straightforward approach to the problem of information management, this approach, and its variations, has not proved to scale well or allowed the flexibility required in today's modern data networks. Scaling and flexibility are especially a problem where there are many sophisticated network devices present. Methods of control must be found that work and scale at the same speeds as that of the control plane of the network itself if a major concern of the management system is with the dynamic control of traffic in a network. Increasingly it is a requirement that customers at the edge of the network be able to have access to management functionality. A centralized management approach may not provide the most convenient architecture to allow this capability.
事業者や機器ベンダーの管理のニーズを解決するための共通のフレームワークは、マネージャ・エージェント・アーキテクチャを備えた集中的なアプローチに基づいています。情報管理の問題に非常に簡単なアプローチ、このアプローチ、およびそのバリエーションを提供しながら、うまくスケールが分かったか、今日の近代的なデータネットワークに必要な柔軟性を許可されていません。スケーリングと柔軟性は、特に多くの洗練されたネットワークデバイスが存在している問題です。管理システムの主要な関心事は、ネットワーク内のトラフィックを動的に制御している場合、コントロールの方法は、ネットワーク自体の制御プレーンのと同じ速度でその仕事とスケールを見つけなければなりません。次第にそれは、ネットワークのエッジで顧客が管理機能へのアクセス権を持つことができる要件です。集中管理のアプローチは、この機能を可能にするために最も便利なアーキテクチャを提供することはできません。
Frameworks based on a decentralized approach to the management architecture have gained momentum in recent years, but must address the possibility of having redundant management information throughout the network. A decentralized framework may have advantages with regards to scaling and speed of operation, but information and state management becomes complex in this approach, resulting in additional complication in developing such systems.
管理アーキテクチャへの分散型アプローチに基づくフレームワークは、近年の勢いを得ているが、ネットワーク全体の冗長管理情報を持つ可能性に対処しなければなりません。分散フレームワークは、スケーリング及び動作速度に関して利点を有することができるが、情報及び状態管理は、そのようなシステムの開発に追加の複雑で、その結果、このアプローチでは複雑になります。
The complexity of managing a network increases dramatically as the number of services and the number and complexity of devices in the network increases. The success of IP networks can be partially traced to the successful separation of transport control mechanisms from the complexity of service management, including billing. As the trend in IP is to allow for classes of traffic that will have both transport and service dependencies it has become apparent that many of the management problems are becoming more complex in nature and are starting to resemble those of the traditional telecom provisioned service environment. In the telecom environment no such separation exists between transport control mechanisms and service. The Telecom community has struggled for years to come up with a standard solution for the problem in national and international standardization bodies and achieved a debatable amount of industry acceptance.
ネットワーク管理の複雑さは、サービスの数とネットワークが増大するデバイスの数と複雑さと飛躍的に増加します。 IPネットワークの成功は、部分的に課金を含むサービス管理の複雑さから、輸送制御機構の分離の成功に遡ることができます。 IPの傾向は、それが管理上の問題の多くは、自然の中で、より複雑になっていると、伝統的な電気通信プロビジョニングサービス環境のそれに似ているし始めていることが明らかになったの両方の輸送とサービスの依存関係を持つことになり、トラフィックのクラスを可能にすることです。通信環境では、このような分離は、トランスポート制御機構とサービスとの間に存在しません。テレコムコミュニティは、国内および国際的な標準化団体での問題のための標準的な解決策を考え出す年間の苦労や業界の受け入れの議論の余地量を達成しました。
Unfortunately, the hard learned lessons of how to manage the interdependencies between service and transport will be of questionable use to the IP community because of the much more limited concept of service in the telecommunications environment.
残念ながら、サービスおよび輸送の間に相互依存性を管理する方法のハード学んだ教訓はあるため、通信環境におけるサービスのより一層制限されたコンセプトのIPコミュニティへの疑問使用されるであろう。
Rules based management has received much attention as a method to reduce much of the overhead and operator intervention that was necessary in traditional management systems. The potential exists that a rules-based system could reduce the rate at which management information is increasing, but given the tremendous growth in this information, the problems with the control of that information will continue to exist. Rules add additional issues to the complexity of managing a network and as such will contribute to the information control problem.
ルールベースの管理は、従来の管理システムに必要だったのオーバーヘッドの多くのオペレータの介入を軽減する方法として注目されています。電位は、ルールベースのシステムは、管理情報が増加される速度を低下させることができ、この情報に驚異的な成長を考えると、その情報の制御の問題が存在し続けることに存在します。ルールは、ネットワークの管理の複雑さに別の問題を追加して、などは、情報制御の問題に貢献していきます。
Much of the current management efforts are focused on solving control issues for IP QoS [3]. A number of open questions exist with the IP QoS architecture which will make it difficult to define a management architecture until they are resolved. These are well documented in "Next steps for the IP QoS architecture" [4], but from the management perspective warrant emphasizing.
現在の経営努力の多くはIPのQoSのための制御の問題を解決するに焦点を当てている[3]。オープン質問の数は、それらが解決されるまで、それが困難な管理アーキテクチャを定義することになりますIP QoSアーキテクチャが存在します。これらはよく[4]が、強調管理の観点令状から「IP QoSのアーキテクチャのための次の手順」に記載されています。
Current IP QoS architectures have not defined if the service will be per-application or only a transport-layer option. This will have significant impact both from a control perspective and from a billing and service assurance one.
サービスごとのアプリケーションのみのトランスポート層のオプションになります場合は、現在のIP QoSのアーキテクチャが定義されていません。これは、コントロールの観点からと課金およびサービス保証1の両方から大きな影響を与えます。
The assumption is that the routing best effort path will be used for both best effort traffic and for traffic of a different service level. In addition to those issues raised in [4], best effort path routing may not be able to identify the parameters necessary to identify routes capable of sustaining distinguished service traffic.
仮定は、ルーティングのベストエフォートパスは両方のベストエフォートトラフィックのために、異なるサービスレベルのトラフィックに使用されるということです。 [4]で提起されたこれらの問題に加えて、ベストエフォートパスルーティングは区別サービストラフィックを維持することが可能な経路を特定するために必要なパラメータを識別することができないかもしれません。
In any architecture where a premium service will be offered it is a strong requirement that the service be measurable and sustainable. Provisioning that service will require a coherent view of the network and not just the device management view that is currently implemented in most networks.
プレミアムサービスが提供される任意のアーキテクチャでは、サービスが測定可能と持続可能なものに強い要求です。そのサービスのプロビジョニングは、現在、ほとんどのネットワークに実装されているだけで、デバイス管理ビューネットワークの一貫したビューを必要としません。
Management standardization efforts in the IP community have so far been concerned primarily with what is commonly referred to as "element management" or "device management" [5]. Generally there is agreement as to the scope of element management. Once outside that domain efforts to divide that task along clear boundaries have proved elusive with many of the terms being used having their roots in the telecommunications industry and as such being of potentially limited use for IP management [1]. Confusion resulting from the ambiguity associated with what functions compose management beyond those intended for the element, is compounded by the broad scope for which network and service management standards apply. Terms such a business goals, service management, and application management are not sufficiently defined to insure there will not be disagreement as to the actual scope of the management functions needed and to what extent interrelationships will exists between them.
IPコミュニティの管理標準化の努力は、これまで一般に「要素の管理」または「デバイス管理」と呼ばれるもので、主に懸念されている[5]。一般的にはエレメント管理の範囲に関して合意があります。明確な境界に沿って、そのタスクを分割する一度そのドメイン外の努力は、[1]電気通信業界で自分のルーツを持ち、IP管理のための潜在的に限られた使用の、このような存在として使われている用語の多くは、とらえどころのない証明しています。機能素子のために意図されるものを越えて管理を構成するものに関連付けられた曖昧さに起因する混乱は、ネットワークおよびサービス管理基準が適用されるため、広い範囲によって配合されます。このような事業目標、サービス管理、およびアプリケーション管理を十分に確保するために定義されていない用語は、必要な管理機能の実際の範囲についての意見の相違がないだろうと意志は、それらの間に存在するためにどの程度の相互関係。
It is within this hazy domain that much of the recent efforts in rules-based management have been proposed as a potential solution. Efforts to devise a framework for policy management is an example of one of the most popular recent activities. Proposed requirements for policy management look very much like pre-existing network management requirements [2], but specific models needed to define policy itself and related to the definition of policy to control DiffServ and RSVP based QoS are under development.
それは、ルールベースの管理の最近の取り組みの多くは潜在的な解決策として提案されているこのかすんドメイン内にあります。ポリシー管理のための枠組みを考案する努力は、最も人気の最近の活動の一つの例です。政策自体とのDiffServとRSVPベースのQoSを制御するためのポリシーの定義に関連を定義するために必要な[2]ポリシー管理のための要件が非常に多く、既存のネットワーク管理要件のように見える提案したが、具体的なモデルが開発されています。
Efforts to define the requirements for a service management system are hindered by the different needs of network operators. In an industry where much has been written about the trend towards convergence there still exist fundamental differences in the business needs of operators.
サービス管理システムの要件を定義するための努力は、ネットワーク事業者のさまざまなニーズによって妨げられます。収束傾向について書かれている多くの業界では、まだ事業者のビジネスニーズの根本的な違いが存在します。
The management requirements from both the operations and the network perspective have some interesting characteristics in the enterprise environment when compared to the public network. In the enterprise end to end traffic management is implemented without the burden of complex tariff issues. Service Level Agreements, while increasing in the enterprise, do not have the same operations impact as in the public network. The high costs associated with implementing non-reputable auditing systems are usually not present. This results in a substantial reduction in the number of expressions necessary to represent a particular networks business model.
パブリックネットワークと比較すると、操作やネットワークの両方の観点から、管理要件は、エンタープライズ環境におけるいくつかの興味深い特徴を持っています。トラフィック管理を終了するには、企業側では、複雑な関税の問題の負担なしに実装されています。サービスレベル契約は、企業内で増加しながら、パブリックネットワークと同様の操作への影響はありません。非評判監査システムの実装に関連した高いコストは、通常は存在しません。これは、特定のネットワークのビジネスモデルを表現するのに必要な式の数の大幅な減少をもたらします。
In the world of best effort service, rules-based management presents the possibility to give the IT department a tool the make the network appear to not be overloaded by prioritizing traffic. This is done by prioritizing delay sensitive traffic (Web browsing) from traffic that is not delay sensitive (Email) or by prioritizing the traffic from a particular location or source. This will, depending on the composite of an enterprises traffic, increase the useful life of the network without adding additional capacity. This does not come without tradeoffs. Both the purchase and management costs associated with the system must be calculated as well as the cost of the added complexity of adding additional control information to the network.
ベストエフォートサービスの世界では、ルールベースの管理は、IT部門にインクルードは、ネットワークトラフィックに優先順位を付けることで、オーバーロードされないように見えるようなツールを提供する可能性を提示します。これは、遅延に敏感なトラフィック（Web閲覧）遅延に敏感されていないトラフィック（メール）から、または特定の場所またはソースからのトラフィックに優先順位を付けることにより、優先順位を付けることによって行われます。これは、企業トラフィックの複合によっては、追加の容量を追加することなく、ネットワークの寿命を増加します。これはトレードオフなしで付属していません。どちらのシステムに関連した購入や管理コストがネットワークに追加の制御情報を付加する追加複雑さのコストと同様に計算する必要があります。
It has for a long time been a goal of service providers to have a centralized management system. While the motivation for this is very straightforward there exist some fundamental obstacles in achieving this goal. Service providers often do not want to be tied to a single vendor and certainly do not want to be limited to only one model of any single vendors equipment. At the same time bottom line costs are of paramount importance which often result in networks not being as heterogeneous as operators would like. Centralized management implies a scalable system able to manage potentially many heterogeneous pieces of equipment. The amount of data necessary to achieve this is contrary to the scalability requirement. In response to this problem it has been attempted many times to identify the common model that represents the subset common to all devices. Unfortunately all too often this set is either too complex, increasing the cost of devices, or too limited to preclude large amounts of device specific data thus defeating the purpose. For such a management model to be successful at the service level, the services being modeled must be standardized. This is counter intuitive to the competitive model of which the service provider operates. To be successful speed to market has become a key element that differentiates one service provider from another. Constraints placed on equipment manufacturers and the management infrastructure by a centralized management system are also detrimental to this goal. While for a limited set of well defined services a central management approach is feasible, such a system can very quickly become a major contributor to the very problems it was intended to solve.
長い時間のために集中管理システムを持っているサービスプロバイダーの目標でした。このためモチベーションが非常に簡単ですが、この目標を達成するためのいくつかの基本的な障害を存在します。サービスプロバイダは、多くの場合、単一のベンダーに縛られたくないと確かに、任意の単一のベンダーの機器の1つのモデルのみに限定されることは望んでいません。同時に、ボトムラインのコストは、多くの場合、ネットワークは、オペレータが希望として異質とされていないにつながる最も重要です。集中管理は、機器の潜在的に多くの異種の作品を管理することができるスケーラブルなシステムを意味します。これを達成するために必要なデータの量は、スケーラビリティの要件に反しています。この問題への対応では、すべてのデバイスに共通のサブセットを表し、共通のモデルを識別するために、何度も試みられています。残念ながら、あまりにも頻繁にこのセットはどちらか複雑すぎる、デバイスのコストを増加させ、またはこれの目的を破って、デバイス固有の大量のデータを排除するにはあまりにも限られています。サービスレベルで成功するためにそのような管理モデルについて、モデル化されたサービスは、標準化されなければなりません。これは、サービスプロバイダが動作するの競争力のあるモデルにカウンター直感的です。市場に成功した速さであるためには、別の1つのサービスプロバイダを区別重要な要素となっています。集中管理システムにより、機器メーカーや管理インフラストラクチャの上に置かれた制約もこの目標に有害です。明確に定義されたサービスの限られたセットのために中央管理アプローチが実現可能であるが、そのようなシステムは非常に迅速にそれを解決することを意図していた非常に問題に大きく貢献になることができます。
Currently many of the efforts to define a framework for management are described in very implementation independent terms. In actual fact the implementation of that framework directly affects for what situations the management system will be most beneficial. While many past attempts to define a common management framework have failed it may be in the area of service management that such efforts finally gain industry acceptance. It may be in the domain of service management that information models can be defined that are sufficiently specific to be useful and at that same time not have a negative impact on the equipment or service providers business needs.
現在、管理のためのフレームワークを定義するための努力の多くは非常に実装に依存しない用語で説明されています。実際にはそのフレームワークの実装が直接管理システムが最も有益でどうなるか状況に影響を与えます。共通の管理フレームワークを定義するために、多くの過去の試みが失敗しているが、それはそのような努力が最終的に業界の承認を得ていること、サービス管理の分野であってもよいです。それは有用であるために十分に特定されている情報モデルを定義することができるというサービス管理のドメインであることと、その同時に、機器やサービスプロバイダーのビジネス・ニーズにマイナスの影響を持っていないかもしれません。
This section will discuss some of the issues that need to be resolved with regards to a service management framework to meet the requirements of the modern IP network.
このセクションでは、近代的なIPネットワークの要件を満たすために、サービス管理フレームワークに関して解決すべき問題のいくつかを説明します。
Some of the key concerns looking at a management system architecture include:
管理システムのアーキテクチャを見てキーの懸念のいくつかは、次のとおりです。
- The management interface and models supported - The management system architecture - Where and how functionality is realized
- サポートされる管理インタフェースとモデル - 管理システムアーキテクチャ - 機能が実現されている方法と
Networks will consist of network elements that have existed prior to efforts to define a standard information model, rules-based or otherwise, and elements deployed after. This problem has been addressed by some of the recent efforts in policy management. Those elements that take into account policy are termed policy aware while those that do not are termed policy unaware. The distinction being made that aware devices can interpret the policy information model or schema. These issues apply equally to other standard management information. In reality it is unlikely that any device will be fully policy aware for long, as the policy information model evolves, early devices will be only policy aware for those aspects of the model that had been defined at the time. Key to success of any management framework is ability to handle revision and evolution. A number methods exists provide this functionality. One is designing the information models so that it can be extended but still be practically used in their original form. A second is to provide an adaptation or proxy layer. Each has advantages and disadvantages.
ネットワークは、事前の標準情報モデルを定義するための努力に存在していたネットワーク要素から構成されます、ルールベースまたはそれ以外の場合は、および要素は後の展開します。この問題は、ポリシー管理の最近の取り組みのいくつかによって対処されています。アカウントポリシーに取るそれらの要素は気づいていないポリシーと呼ばれていないものしばらく意識ポリシーと呼ばれています。違いは、対応デバイスがポリシー情報モデルやスキーマを解釈できるよう作られています。これらの問題は、他の標準的な管理情報にも同様に適用されます。現実には、任意のデバイスは、完全にポリシー長いために承知しているであろう政策情報モデルが進化するにつれ、初期のデバイスは一度に定義されていたモデルのこれらの側面のための意識だけで政策になることはほとんどありません。任意の管理フレームワークの成功の鍵は、リビジョンと進化を処理する能力です。数の方法は、この機能を提供する存在します。一つは、それが拡張することができますが、依然として実質的に元の形で使用されるように情報モデルを設計しています。第二は、適応またはプロキシ層を提供することです。それぞれ長所と短所があります。
Methods that attempt to extend the original model often overly constrain themselves. Where the existing model cannot be extended new branches must be formed in the model that contain core management functionality.
オリジナルモデルを拡張しようとする方法は、多くの場合、過度に自分自身を制限します。既存のモデルは、新しい枝を拡張することができない場合はコア管理機能が含まれているモデルで形成されなければなりません。
Adaptation methods can create performance and scalability problems and add complexity to the network by creating additional network elements. A similar situation exists if the management framework is so flexible as to allow network elements to store locally information or choose to have information stored remotely. From a device perspective, the criteria will be if the device can afford the logic based on other requirements it is designed to meet, and if the information can be retrieved in such a way as to support the performance and scalability requirements that are the subject of the information. A dichotomy exists where there will be information that for reasons of performance and scalability will be transferred directly to the network elements in some situations, and in other situations, will exist in the management plan. IP management efforts have left the level of detail needed to define the actual location of the management information to the implementation. In a service management framework it may be necessary to achieve the desired results to supply a more complete framework along the lines of detail provided by the ITU-T telecommunications management network efforts where the interfaces and functionality across interfaces has been clearly defined.
適応方法は、パフォーマンスとスケーラビリティの問題を作成し、追加のネットワーク要素を作成することによって、ネットワークに複雑さを追加することができます。管理フレームワークは、ネットワーク要素がローカルに情報を格納するか、リモート格納情報を有することを選択することを可能にするように可撓性である場合、同様の状況が存在します。デバイスの観点から、基準デバイスが論理に余裕があれば、満たすように設計されたその他の要件に基づいてなり、情報は次のような方法で取得することができる場合の主題である性能とスケーラビリティ要件をサポートします情報。二分法は、性能とスケーラビリティの理由のために、いくつかの状況では、ネットワーク要素に直接転送されること情報が存在するであろう場所に存在し、他の状況では、管理計画に存在します。 IP管理努力が実装への管理情報の実際の位置を定義するために必要な詳細レベルを残しています。サービス管理フレームワークでは、インターフェースを横切るインタフェースと機能が明確に定義されたITU-T電気通信管理ネットワークの努力によって提供される詳細の線に沿って、より完全なフレームワークを供給するために、所望の結果を達成するために必要であり得ます。
Information will need to exist in multiple locations simultaneously in any network architecture. As the quantity and complexity of that information increases limitations quickly develop. Changes in the information may need to be propagated in close to real time, further adding to the complication.
情報は、任意のネットワークアーキテクチャで同時に複数の場所に存在する必要があります。その情報の量及び複雑さが制限を増加させるように迅速に開発します。情報の変化はさらに複雑に追加して、リアルタイムに近いで伝播する必要があるかもしれません。
A network management framework can be viewed as being divided into two essential functions. The first deals with the aspects of managing the management information while the second deals with the aspects of transferring that management information into the network. The fundamental difference between rules based management and existing network management standards is that the management information is expressed as rules that reflect a desired level of service from the network as opposed to device specific management information. Many of the information management requirements of traditional management systems still apply in a rules-based environment. The network is composed of specific devices and it is at the point where rules are conveyed as device specific management information that this form of management will encounter some of its greatest challenges. A necessary component of a solution to this problem will be a generic information model to which rules can be applied and a framework architecture for distributing rules throughout the network. The task of finding the proper generic model that is not too great a burden to implement and yet provides a level of detail sufficient to manage a network has proved to be historically extremely difficult. In many ways the degree to which rules based management will be able to solve management problems is dependent on the success of efforts to define a generic model and have it be widely implemented [1].
ネットワーク管理フレームワークは、2つの基本的な機能に分割されているとみなすことができます。ネットワークにその管理情報を転送する側面を有する第2取引しながら、管理情報を管理するの局面に最初の取引。ルールベースの管理、既存のネットワーク管理規格との間の基本的な違いは、管理情報は、デバイス固有の管理情報とは対照的に、ネットワークからのサービスの所望のレベルを反映するルールとして表現されていることです。伝統的な管理システムの情報管理要件の多くは、まだルールベースの環境に適用されます。ネットワークは、特定のデバイスで構成され、それはルールが管理のこの形態は、その最大の課題のいくつかに遭遇することは、デバイス固有の管理情報として伝達される点にあります。この問題に対する解決策の必要な成分は、ルールを適用可能な一般的な情報モデルとネットワーク全体ルールを配信するためのフレームワークのアーキテクチャであろう。負担が実装するにはあまりにも偉大なものではなく、まだネットワークを管理するのに十分な詳細レベルを提供し、適切な汎用的なモデルを見つける作業は、歴史的に極めて困難であることが証明されました。いろいろな意味での管理は、管理上の問題を解決することができるようになりますベースのルールの度合いは、[1]一般的なモデルを定義し、それが広く実装されていするための努力の成功に依存しています。
One concept often discussed along with policy deals with the integration of legacy devices into the policy framework. The presumption is that legacy devices would be able to participate in the policy decision by having policy information translated into the native management interface. For this to succeed a device would have to support a functionality for which policy would be specified. This would limit the usefulness of this approach to only information logically abstracted to the native interface of the device. Given that existing standard management interfaces do not support such functionality, all such devices would need to have a proprietary interface implemented. The interface being based on the existing interface supported by the device would potentially not have the scaling capabilities needed for a policy management system. Unlike a standard network management interface, were management information can be distributed between the adaptation layer and the network element, rules based management information may not be so easily distributed.
一つの概念は、多くの場合、政策枠組みへのレガシー・デバイスの統合と政策プランと一緒に議論しました。推定は、レガシーデバイスは、ネイティブの管理インターフェイスに翻訳ポリシー情報を持つことにより、政策決定に参加することができるだろうということです。これを成功させるには、デバイスは、ポリシーが指定されるであろうための機能をサポートしなければなりません。これは、論理的に、デバイスのネイティブインターフェースに抽象化された情報だけに、このアプローチの有用性を制限します。既存の標準的な管理インターフェイスは、このような機能をサポートしていないことを考えると、このようなすべてのデバイスは、独自のインタフェースを実装している必要があります。デバイスでサポートされている既存のインタフェースに基づいているインタフェースは、潜在的にポリシー管理システムに必要なスケーリング機能を持っていないでしょう。標準的なネットワーク管理インターフェイスとは異なり、管理情報は、アダプテーション層及びネットワーク要素間に分散することができた、ルールベースの管理情報は、そう簡単に配布することはできません。
The framework for integrating rules based management system with existing network devices is not readily apparent and further study is needed. The problem exists further when one considers that there will be early policy aware devices that may not be aware as the policy models are extended. The partially policy aware devices may represent additional architectural issues as it may not be possible to expect consistency in what aspects of policy a given devices implements if there does not exist formal sets of mandatory functionality with clear evolution paths. It is paramount if the policy management framework is going to able to evolve to accommodate the ever-increasing number of services likely to be supported by IP networks of the future that an evolution path be built into the framework.
既存のネットワークデバイスとルールベースの管理システムを統合するためのフレームワークが容易に明らかではなく、さらなる研究が必要です。 1ポリシーモデルが拡張されているとして認識していない可能性が早期の政策対応デバイスがあるだろうと考えたときに問題がさらに存在します。明確な進化のパスで必須機能の正式なセットが存在しない場合は与えられたデバイスが実装してどのような政策の面で一貫性を期待することはできないかもしれないとして、部分的に政策対応デバイスは、追加のアーキテクチャ上の問題を表すことができます。ポリシー管理フレームワークは、進化のパスがフレームワークに組み込まれることを将来のIPネットワークでサポートされる可能性が高いサービスの増え続けるに適応するように進化することが可能に起こっているかどうかは非常に重要です。
The need for a policy protocol is important in the context of a policy aware element that is performing a certain 'service'. It is important to note here that not all elements will be aware of all service policies related to every service at all times. Therefore it makes sense for an element to be aware of a certain service policy if that element is required for a given service at any instant in time.
ポリシープロトコルの必要性は、特定の「サービス」を実施している政策を意識要素の文脈で重要です。ないすべての要素がすべての回ですべてのサービスに関連するすべてのサービスポリシーを承知しているであろうことを、ここで注意することが重要です。その要素は、任意の瞬間における特定のサービスのために必要とされる場合要素は、特定のサービスポリシーを認識するためにしたがって、それは理にかなっています。
With the dynamics of a network where elements and links go up and down, a notion of a 'policy protocol' may become necessary. The idea of a 'policy protocol' that runs in a multi-service network requiring multi-service policies. For example; consider two arbitrary end nodes having multiple routing paths between them. Let's then assume that a certain path carries a certain service based on some Intserv bandwidth reservation technique. Let's also then deduce that the elements along that path have some element specific policy statements that have been configured on them to support that requirement. If now at any given instance any link or any element were to be unavailable along that path, the 'policy protocol' should be initiated to automatically go and configure the same service-policies on the elements along another routed path connecting the very same end points, so that there is no disruption in service and so that no human/operator intervention is required.
要素やリンクが上下に行くネットワークのダイナミクスと、「ポリシープロトコル」の概念が必要になる場合があります。マルチサービス・ポリシーを必要とするマルチサービス・ネットワークで実行「ポリシープロトコル」のアイデア。例えば;それらの間の複数のルーティング経路を有する任意の二つのエンドノードを考えます。さんはその後、特定のパスがいくつかイントサーブ帯域予約技術に基づいて、特定のサービスを運ぶと仮定しよう。のも、そのパスに沿った要素は、その要件をサポートするために、それらに設定されているいくつかの要素の特定のポリシーステートメントを持っていることを推測してみましょう。今任意のインスタンスで任意のリンクまたは任意の要素は、そのパスに沿って使用できなくしていた場合は、「ポリシーのプロトコルが」自動的に行くと非常に同じエンドポイントを結ぶ別のルーティングパスに沿った要素に同じサービス・ポリシーを設定するために開始すべきですそこのサービスには混乱がなく、なるようになるように、何も人間/オペレータの介入は必要ありません。
The association of policy with the policy target is an area where considerable study may need to be done. Some issues are if this needs to be explicitly done or if the policy can be so written that a common description of the target is also included? Allowing a policy target to retrieve those policies that are relevant to it.
政策目標と政策の関連性は、かなりの研究が行われる必要があるかもしれない領域です。これは明示的に行う必要がある場合やポリシーがとてもターゲットの一般的な説明も含まれていること書くことができるならばいくつかの問題がありますか？それに関連するこれらのポリシーを取得するために、政策目標を許可します。
Understanding the set of problems facing IP network management in general will be key in defining a comprehensive framework architecture that meets the needs of operators. Additional risks are created by applying new management techniques to the management of IP networks. The consequence of implementing management operations based on architectures that may not be compatible with existing management systems will still need to be explored.
一般的に、IPネットワークの管理が直面している問題のセットを理解することは、事業者のニーズを満たす包括的な枠組みのアーキテクチャを定義する上で鍵となるでしょう。追加のリスクは、IPネットワークの管理に新たな管理手法を適用して作成されます。既存の管理システムとの互換性がない可能性がありアーキテクチャに基づいて管理操作を実行した結果は、まだ模索する必要があります。
Given that many network devices in IP networks are making routing decisions based on information received via routing protocols it seems sensible that they also make QoS decisions in a similar fashion.
IPネットワークにおける多くのネットワーク機器は、ルーティングプロトコルを経由して受信した情報に基づいてルーティング決定を作っていることを考えると、彼らはまた、同様の方法でのQoSの決定を行うことを賢明なようです。
Historically the broader the scope of a network management standardization effort the less likely it has been to succeed. Management standardization efforts must be careful to have clearly defined goals and requirements less they to experience the same fate as previous such efforts.
歴史的に、それは成功したようになっている可能性が低いネットワーク管理の標準化努力の範囲広いです。管理標準化の努力は、彼らが以前のような努力と同じ運命を体験するあまり明確に定義された目標と要件を持っているように注意する必要があります。
As IP continues to extend it's concept of service beyond that of best effort to include, among other things, differentiate treatment of packets, it will become increasingly necessary to have mechanisms capable of supporting these extensions. Efforts to define a common management model and framework have proven to be historically elusive. Information models, whether they be traditional or rules-based, must address these past problems. The desire to keep a competitive advantage, and the reality that a common model, to be truly common, will not provide sufficient detail to fully manage a device, has often slowed the acceptance on the part of equipment vendors to this approach.
IPパケットの治療を、とりわけ、それが含まれるように最善の努力のそれを超えたサービスの概念だ延ばす区別し続けると、それはこれらの拡張機能をサポートできる仕組みを持つことがますます必要になります。一般的な管理モデルとフレームワークを定義するための努力は、歴史的にとらえどころのないことが証明されています。情報モデルは、彼らは伝統的であるか、ルールベースかどうか、これらの過去の問題に対処しなければなりません。競争上の優位性を維持し、現実の一般的なモデルという、本当に一般的であると、デバイスを完全に管理するために十分な詳細を提供することはありませんしたいが、多くの場合、このアプローチには機器ベンダーの一部に受け入れを鈍化しています。
As IP continues to extend it's concept of service beyond that of best effort to include, among other things, differentiate treatment of packets it will become increasingly necessary to have mechanisms capable of supporting these extensions.
IPは、それが含まれるように最善の努力のそれを超えたサービスの概念だ拡張し続けると、とりわけ、それはこれらの拡張機能をサポートできる仕組みを持っていることがますます必要となるパケットの治療を区別します。
The exchange of management information in a network is one of the most sensitive from a security perspective. Management protocols must address security to insure the integrity of the data. A management architecture must provide for security considerations from its inception to insure the authenticity of the information provider and that the security mechanisms not be so cumbersome as to make them not feasible to implement.
ネットワークの管理情報の交換は、セキュリティの観点から、最も敏感なの一つです。管理プロトコルは、データの整合性を保証するために、セキュリティに対処しなければなりません。管理アーキテクチャは、情報提供者の信憑性を保証するために、創業からとセキュリティメカニズムが実装するためにそれらが不可能になるように面倒なことではないというセキュリティ上の配慮のために提供する必要があります。
[1] Michael Eder, Sid Nag, Raj Bansal, "IP Service Management Framework", Work in Progress, October 1999.
[1]マイケル・エダー、シドナグ、ラジBansalは、「IPサービス管理フレームワーク」、進歩、1999年10月の作業。
[2] Hugh Mahon, Yoram Bernet, and Shai Herzog, "Requirements for a Policy Management System", Work in Progress.
[2]ヒュー・マオン、Yoram Bernet、およびシャイヘルツォーク、「ポリシー管理システムの要件」、進行中の作業。
[3] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.
[3] Yavatkar、R.、Pendarakis、D.とR.ゲラン、 "ポリシーベースのアドミッション制御のためのフレームワーク"、RFC 2753、2000年1月。
[4] Huston, G., "Next Steps for the IP QoS Architecture", RFC 2990, November 2000.
[4]ヒューストン、G.、 "IP QoSのアーキテクチャーのための次のステップ"、RFC 2990、2000年11月。
[5] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets" RFC 1156, May 1990.
[5] McCloghrie、K.とM.ローズ、RFC 1156 "TCP / IPベースのインターネットのネットワーク管理のための管理情報ベース"、1990年5月を。
Michael Eder Nokia 5 Wayside Road Burlington, MA 01803
マイケル・エダーノキア5ウェイサイド道路バーリントン、MA 01803
EMail: michael.eder@nokia.com
メールアドレス：michael.eder@nokia.com
Sid Nag PO Box 104 Holmdel, NJ 07733
それシド私書箱104ホルムデル、NJ 07733
EMail: thinker@monmouth.com
メールアドレス：thinker@monmouth.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。