[要約] 要約:RFC 3052は、サービス管理アーキテクチャの問題とレビューに関する情報を提供しています。 目的:このRFCの目的は、サービス管理アーキテクチャの問題を特定し、改善策を提案することです。

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.

Copyright(c)The Internet Society(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.

さまざまなレベルのサービスを提供できるメカニズムを活用するために必要なサポート機能の多くは範囲が制限されており、完全なフレームワークは存在しません。このようなフレームワークでのさまざまな努力は、大きな注目を集めており、この問題に対処しようとしている多くの組織にとって、範囲の歴史的な変化を表しています。このドキュメントの目的は、サービス管理フレームワークを定義する問題を調査し、まだ解決する必要がある問題のいくつかを調べることです。

1. Introduction
1. はじめに

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ネットワークでは、ベストエフォートサービスは、ネットワークが提供するのではなく、ネットワークが提供する多くのサービスの1つにすぎません。提供される唯一のサービスです。残念ながら、ネットワークレベルのサービスを提供できるメカニズムを活用するために必要なサポート機能の多くは範囲が制限されており、完全なフレームワークは存在しません。問題を悪化させるのは、「サービス」の範囲が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.

ネットワークとサービス管理の問題は、将来のネットワークが直面している大きな問題になるでしょう。この実現は、IPコミュニティ内のさまざまな努力における重要な動機付けの要因であり、伝統的にこのタイプの問題を引き受けることに消極的でした[1]。このドキュメントの目的は、ネットワークとサービスを管理するためのフレームワークを開発する問題を調査し、最近の努力が明らかにした問題のいくつかを調べることです。

2. The Problem of Management Standards
2. 管理基準の問題

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ネットワークでは、これらの新しいサービスを提供、維持、検証、請求するために、膨大な量の管理情報が必要です。複雑な通信ネットワークにおける管理情報の制御と配布は、ネットワーク管理フレームワークが解決しなければならない最も洗練されたタスクの1つです。これは、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.

ネットワークオペレーターの要件は、ネットワークの集中管理を可能にし、操作と維持するための最小限のリソースを必要とするフレームワークを求めています。オペレーターは、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.

ルールベースの管理は、従来の管理システムで必要なオーバーヘッドおよびオペレーターの介入の多くを減らす方法として多くの注目を集めています。ルールベースのシステムは、管理情報が増加している速度を下げることができる可能性がありますが、この情報の大幅な成長を考えると、その情報の制御に関する問題は引き続き存在します。ルールは、ネットワークの管理の複雑さに追加の問題を追加するため、情報管理の問題に貢献します。

2.1. IP QoS Management
2.1. IP QOS管理

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 QOの制御問題の解決に焦点を当てています[3]。IP QoSアーキテクチャには、管理アーキテクチャが解決されるまで定義することが難しくなることがあるといういくつかの公開質問が存在します。これらは「IP QOSアーキテクチャの次のステップ」[4]で十分に文書化されていますが、管理の観点からは強調されています。

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]で提起された問題に加えて、Best Expect Pathルーティングは、著名なサービストラフィックを維持できるルートを識別できるパラメーターを特定できない場合があります。

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.

プレミアムサービスが提供されるアーキテクチャでは、サービスが測定可能で持続可能であることが強い要件です。そのサービスのプロビジョニングには、ほとんどのネットワークで現在実装されているデバイス管理ビューだけでなく、ネットワークのコヒーレントビューが必要になります。

2.2. Promise of rules-based Management
2.2. ルールベースの管理の約束

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]。一般に、要素管理の範囲に関して合意があります。明確な境界に沿ってそのタスクを分割するそのドメインの努力の外側が、電気通信業界でルーツを持っている多くの用語が使用されており、IP管理の使用が潜在的に使用される可能性があることがわかりにくいことが証明されました[1]。要素を意図したものを超えて管理を構成する機能に関連するあいまいさに起因する混乱は、ネットワークとサービス管理の基準が適用される広範な範囲によって悪化します。条件などのビジネス目標、サービス管理、アプリケーション管理は、必要な管理機能の実際の範囲とそれらの間にどの程度相互関係が存在するかについて意見の相違がないことを保証するために十分に定義されていません。

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.

このかすんだドメイン内では、ルールベースの管理における最近の取り組みの多くが潜在的な解決策として提案されています。政策管理のためのフレームワークを考案する努力は、最も人気のある最近の活動の1つの例です。ポリシー管理の提案された要件は、既存のネットワーク管理要件[2]に非常によく似ていますが、ポリシー自体を定義するために必要な特定のモデルと、DiffServおよびRSVPベースのQOを制御するためのポリシーの定義に関連して開発中です。

2.3. Service Management Requirements
2.3. サービス管理要件

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.

サービス管理システムの要件を定義する努力は、ネットワークオペレーターのさまざまなニーズによって妨げられています。収束の傾向について多くのことが書かれている業界では、オペレーターのビジネスニーズに依然として根本的な違いが存在しています。

2.3.1. Enterprise
2.3.1. 企業

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.

Best Effect Serviceの世界では、ルールベースの管理は、トラフィックに優先順位を付けることでネットワークが過負荷にならないように見えるIT部門にツールを与える可能性を提示します。これは、遅延感度(電子メール)ではないトラフィックから遅延に敏感なトラフィック(Webブラウジング)を優先順位付けするか、特定の場所またはソースからトラフィックに優先順位を付けることによって行われます。これは、エンタープライズトラフィックの複合に応じて、容量を追加せずにネットワークの耐用年数を増やします。これはトレードオフなしではありません。システムに関連する購入と管理コストの両方を計算する必要があり、追加の制御情報をネットワークに追加する複雑さのコストを計算する必要があります。

2.3.2. Service Provider
2.3.2. サービスプロバイダー

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つのモデルのみに限定されたくないことは確かです。同時に、最終的なコストは最も重要であり、多くの場合、ネットワークがオペレーターが望むほど不均一ではないことがあります。集中管理は、潜在的に多くの不均一な機器を管理できるスケーラブルなシステムを意味します。これを達成するために必要なデータの量は、スケーラビリティ要件に反しています。この問題に応じて、すべてのデバイスに共通するサブセットを表す共通モデルを識別しようと何度も試みられてきました。残念ながら、このセットは複雑すぎる、デバイスのコストを増加させるか、制限が大きすぎて大量のデバイス固有データを排除するために制限されているため、目的を打ち負かすことがよくあります。このような管理モデルがサービスレベルで成功するには、モデル化されるサービスを標準化する必要があります。これは、サービスプロバイダーが運営する競争モデルに直感的です。市場への速度を成功させることは、あるサービスプロバイダーを別のサービスプロバイダーと区別する重要な要素になりました。集中管理システムによる機器メーカーと管理インフラストラクチャに課される制約も、この目標に有害です。適切に定義された限られたサービスの場合、中央管理アプローチは実行可能ですが、そのようなシステムは、解決することを意図したまさに問題に非常に迅速に貢献する可能性があります。

3. Network and Service Management
3. ネットワークとサービス管理

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

- サポートされている管理インターフェイスとモデル - 管理システムアーキテクチャ - 機能がどこでどのように実現されるか

3.1. Architecture for information management
3.1. 情報管理のためのアーキテクチャ

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.

ネットワークは、標準情報モデル、ルールベースまたはその他の標準情報モデルを定義するための取り組みの前に存在していたネットワーク要素で構成され、その後展開されます。この問題は、政策管理における最近の取り組みのいくつかによって対処されています。ポリシーを考慮したこれらの要素は、ポリシーの認識と呼ばれますが、ポリシーと呼ばれない要素は認識されません。意識的なデバイスがポリシー情報モデルまたはスキーマを解釈できることを区別しています。これらの問題は、他の標準管理情報に等しく当てはまります。実際には、ポリシー情報モデルが進化するにつれて、どのデバイスも長い間完全にポリシーを認識することはほとんどありません。初期のデバイスは、当時定義されていたモデルの側面についてのみポリシーを認識することになります。管理フレームワークの成功の鍵は、修正と進化を処理する能力です。数の方法が存在し、この機能を提供します。1つは、情報モデルを設計して、拡張できるが、元の形で実際に使用できるようにすることです。2番目は、適応またはプロキシレイヤーを提供することです。それぞれには利点と短所があります。

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.

任意のネットワークアーキテクチャでは、複数の場所に情報が存在する必要があります。その情報の量と複雑さが増加するにつれて、制限が急速に発展します。情報の変更は、リアルタイムに近づいて伝播する必要がある場合があり、さらに合併症を増します。

3.1.1. Rules-based Management
3.1.1. ルールベースの管理

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つの重要な機能に分割されていると見なすことができます。1つ目は管理情報の管理の側面を扱い、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.

多くの場合、1つの概念は、レガシーデバイスのポリシーフレームワークへの統合に関するポリシー取引とともに議論されています。仮定は、レガシーデバイスがポリシー情報をネイティブ管理インターフェイスに翻訳することにより、ポリシーの決定に参加できるということです。これを成功させるためには、デバイスはポリシーが指定される機能をサポートする必要があります。これにより、このアプローチの有用性は、デバイスのネイティブインターフェイスに論理的に抽象化された情報のみに制限されます。既存の標準管理インターフェイスがそのような機能をサポートしていないことを考えると、そのようなデバイスはすべて独自のインターフェイスを実装する必要があります。デバイスでサポートされている既存のインターフェイスに基づいているインターフェイスには、ポリシー管理システムに必要なスケーリング機能がない可能性があります。標準のネットワーク管理インターフェイスとは異なり、管理情報は適応レイヤーとネットワーク要素の間に配布できます。ルールベースの管理情報はそれほど簡単に分散できない場合があります。

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.

ルールベースの管理システムを既存のネットワークデバイスと統合するためのフレームワークはすぐにはわかりません。さらなる研究が必要です。問題は、ポリシーモデルが拡張されても認識されない可能性のある初期のポリシー認識デバイスがあると考えると、さらに存在します。部分的にポリシー認識デバイスは、明確な進化パスを持つ必須機能の正式なセットが存在しない場合、特定のデバイスがどのような側面が実装するかについての一貫性を期待することができないため、追加のアーキテクチャの問題を表す可能性があります。ポリシー管理のフレームワークが進化して、進化のパスがフレームワークに組み込まれるというIPネットワークによってサポートされる可能性が高いサービスの数に対応するために進化できる場合が最重要です。

3.2. Policy Protocol
3.2. ポリシープロトコル

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.

要素とリンクが上下するネットワークのダイナミクスにより、「ポリシープロトコル」の概念が必要になる場合があります。マルチサービスポリシーを必要とするマルチサービスネットワークで実行される「ポリシープロトコル」のアイデア。例えば;それらの間に複数のルーティングパスを持つ2つの任意のエンドノードを考慮してください。次に、特定のパスが、いくつかのIntServ帯域幅予約技術に基づいて特定のサービスを運ぶと仮定します。また、そのパスに沿った要素には、その要件をサポートするように構成されている要素固有のポリシーステートメントがあると推測しましょう。任意のインスタンスで、リンクまたは要素がそのパスに沿って利用できない場合、「ポリシープロトコル」を開始して、まったく同じエンドポイントを接続する別のルーティングパスに沿って同じサービスポリシーを自動的に移動して構成する必要があります、サービスの混乱がなく、人間/オペレーターの介入が必要ないように。

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.

政策と政策目標の関連は、かなりの研究を行う必要があるかもしれない領域です。いくつかの問題は、これを明示的に行う必要がある場合、またはターゲットの一般的な説明も含まれているポリシーをそのように記述できる場合です。ポリシーターゲットがそれに関連するポリシーを取得できるようにします。

4. Conclusions
4. 結論

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が引き続き拡張するにつれて、特にこれらの拡張機能をサポートできるメカニズムを持つためにますます必要になることを含めるために、最善のサービスの概念を超えてサービスの概念を超えています。

5. Security Considerations
5. セキュリティに関する考慮事項

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つです。管理プロトコルは、データの整合性を保証するためにセキュリティに対処する必要があります。管理アーキテクチャは、情報プロバイダーの信頼性を保証するために、設立からのセキュリティ上の考慮事項を提供する必要があり、セキュリティメカニズムは実装できないほど面倒ではありません。

6. Reference
6. 参照

[1] Michael Eder, Sid Nag, Raj Bansal, "IP Service Management Framework", Work in Progress, October 1999.

[1] Michael Eder、Sid Nag、Raj Bansal、「IP Service Management Framework」、1999年10月、進行中の作業。

[2] Hugh Mahon, Yoram Bernet, and Shai Herzog, "Requirements for a Policy Management System", Work in Progress.

[2] Hugh Mahon、Yoram Bernet、およびShai Herzog、「政策管理システムの要件」が進行中です。

[3] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.

[3] Yavatkar、R.、Pendarakis、D。and R. Guerin、「政策ベースの入場管理の枠組み」、RFC 2753、2000年1月。

[4] Huston, G., "Next Steps for the IP QoS Architecture", RFC 2990, November 2000.

[4] Huston、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. Rose、「TCP/IPベースのインターネットのネットワーク管理のための管理情報ベース」RFC 1156、1990年5月。

7. Authors' Addresses
7. 著者のアドレス

Michael Eder Nokia 5 Wayside Road Burlington, MA 01803

マイケルエダーノキア5ウェイサイドロードバーリントン、マサチューセッツ州01803

   EMail: michael.eder@nokia.com
        

Sid Nag PO Box 104 Holmdel, NJ 07733

Sid Nag Po Box 104 Holmdel、NJ 07733

   EMail: thinker@monmouth.com
        
8. 完全な著作権声明

Copyright (C) The Internet Society (2001). All Rights Reserved.

Copyright(c)The Internet Society(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エディター機能の資金は現在、インターネット協会によって提供されています。