RFC3052 日本語訳

Network Working Group                                            M. Eder
Request for Comments: 3052                                         Nokia
Category: Informational                                           S. Nag
                                                            January 2001

コメントを求めるワーキンググループM.エーダーの要求をネットワークでつないでください: 3052年のノキアカテゴリ: 情報のS.小煩い人2001年1月

          Service Management Architectures Issues and Review

サービス管理体系問題とレビュー

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 (2001).  All Rights Reserved.

Copyright(C)インターネット協会(2001)。 All rights reserved。

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.

異なったレベルのサービスを提供できるメカニズムを利用するのに必要な支援機能の多くが範囲で制限されます、そして、完全なフレームワークは実在しません。 そのようなフレームワークにおける様々な取り組みは、このその問題を訴えるのを目指す組織の多くのための範囲に大きな配慮を受けて、歴史的なシフトを表します。 このドキュメントの目的は、Service管理フレームワークを定義するという問題を探って、まだ決議される必要がある問題のいくつかを調べることです。

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.

1セットのパケット、または流れが優先するのを区別するために別のものに比例してメカニズムを提供する取り組みはよく進行中です、そして、多くの現代のIPネットワークでは、ベストエフォート型サービスは提供された唯一のサービスであるのでそれと対照的にネットワークによって提供される多くのサービスの1つになるでしょうただ。 残念ながら、それのネットワークレベルでサービスを提供できるメカニズムを利用するのに必要な支援機能の多くが範囲で制限されます、そして、完全なフレームワークは実在しません。 問題を悪化させるのは、IPネットワークで「サービス」の範囲がまさに何であるかに関する様々な理解です。 IPは接続指向のネットワーク技術と対照して単に接続性を終わらせるために終わるためにサービス管理の定義を制限できませんが、本番適用に関するサービス要件で輸送するあいさつとそれらがどうネットワークを使用しているかとサービス管理を合併するでしょう。 アプリケーション帯域幅用法における成長に管理の既存の方法が十分でない結果があったとき、また、データ網の驚くべき成長はスケールと複雑さの高まる需要を扱います。

Eder & Nag                   Informational                      [Page 1]

RFC 3052            Service Management Architectures        January 2001

エーダーと小煩い人の情報[1ページ]のRFC3052は2001年1月に管理体系を修理します。

   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共同体の中の様々な取り組みの重要な動機づけている要素です。 このドキュメントの目的は、ネットワークとサービスを経営するためにフレームワークを開発するという問題を探って、最近の取り組みが発見した問題のいくつかを調べることです。

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ネットワークで1つのクラスのサービスに、可能な最も良いサービスを提供するためにネットワークを設計することによって、伝統的に扱われます。 ますます、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

要件が、ネットワークの集中的管理を可能にして、最小量のリソースを必要とするフレームワークがまだ設備の選択とサービス[2]を定義する創造性に物凄い柔軟性を提供している間、操作して、維持するように求めるオペレータをネットワークでつないでください。 しっかりOSSと統合されるので、オペレータは彼らのOperational Support Systems(OSS)における変化をよりサポートすることができないかもしれなくて、次に、ネットワークインフラには彼らがいます。

Eder & Nag                   Informational                      [Page 2]

RFC 3052            Service Management Architectures        January 2001

エーダーと小煩い人の情報[2ページ]のRFC3052は2001年1月に管理体系を修理します。

   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.

組織商習慣。 柔軟性、および上で特定された願望、オペレータが設備ベンダーに開いていて一般的なインタフェースをサポートさせることによって会わせると予想するもう片方の必要性。

   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における傾向が輸送とサービスの依存の両方を持っているトラフィックのクラスを考慮することであるときに、管理問題の多くが現実により複雑になっていて、伝統的なテレコム食糧を供給されたサービス環境のものに類似してい始めているのは明らかになりました。 テレコム環境で、どんなそのような分離も輸送制御機構とサービスの間に存在していません。 テレコム共同体は、国家と国際標準化本体の問題の標準液と戦って、論争の余地がある量の産業承認を達成しました。

Eder & Nag                   Informational                      [Page 3]

RFC 3052            Service Management Architectures        January 2001

エーダーと小煩い人の情報[3ページ]のRFC3052は2001年1月に管理体系を修理します。

   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 QoS[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]で提起されたそれらの問題に加えて、ベストエフォート型経路ルーティングは偉勲トラフィックを支えることができるルートを特定するのに必要なパラメタを特定できないかもしれません。

   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の約束

   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

IP共同体の管理標準化取り組みは今までのところ、主として一般的に「要素管理」か「デバイス管理」[5]と呼ばれることに関係がありました。 一般に、要素管理の範囲に関して協定があります。 それの外でかつてのそのタスクを分割する透明な境界が立証したドメイン取り組み

Eder & Nag                   Informational                      [Page 4]

RFC 3052            Service Management Architectures        January 2001

エーダーと小煩い人の情報[4ページ]のRFC3052は2001年1月に管理体系を修理します。

   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管理[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つに関する例です。 特定のモデルは、方針自体を定義するのが必要であり、DiffServを制御するために方針の定義に関連しました、そして、政策管理のための提案された要件は、たいへんネットワークマネージメント要件[2]を先在させるように見えますが、RSVPのベースのQoSは開発中です。

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

ベストエフォート型サービスの世界では、規則を拠点とする経営者側がネットワークが積みすぎられないように見える造をIT部のaツールに与えるトラフィックを最優先させる可能性を提示します。 敏感な(メール)を遅らせないことであるトラフィックから遅れの敏感なトラフィック(ウェブ閲覧)を最優先させるか、または特定の位置かソースからトラフィックを最優先させることによって、これをします。 企業トラフィックの合成物によって、これはネットワークの役に立つ寿命を増強するでしょう。

Eder & Nag                   Informational                      [Page 5]

RFC 3052            Service Management Architectures        January 2001

エーダーと小煩い人の情報[5ページ]のRFC3052は2001年1月に管理体系を修理します。

   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.

追加容量を加えないで。 これは見返りなしで来ません。 追加制御情報をネットワークに追加する加えられた複雑さの費用と同様に購買と管理コストのシステムに関連している両方について計算しなければなりません。

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つのモデルだけにも制限されたくはありません。 同時に、結論コストは最高のに重要です(しばしばオペレータと同じくらい異種のどんな存在も必要としないネットワークをもたらします)。 集中的管理は潜在的に多くの異種の設備に対処できるスケーラブルなシステムを含意します。 これを達成するのに必要なデータ量はスケーラビリティ要件に合いません。 この問題に対応して、すべてのデバイスに共通の部分集合を表す一般的なモデルを特定するために何回もそれを試みてあります。 残念ながらあまりにも頻繁に、このセットは複雑過ぎます、目的をくつがえしながらデバイスについて費用を増強するか、またはその結果、多量のデバイスの特定のデータを排除するために制限されて、また、増強して。 そのようなマネジメント・モデルがサービスレベルでうまくいっているために、モデル化されるサービスを標準化しなければなりません。 これはサービスプロバイダーが作動する対抗機種に直感的なカウンタです。 売り出すうまくいっている速度であることは別のものと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.

現在の、管理のためにフレームワークを定義する取り組みの多くが実装から非常に独立している用語で説明されます。実際にそのフレームワークの実装は、マネージメントシステムがどんな状況に最も有益であるかなるかに直接影響します。 一般的な管理フレームワークを定義する過去の多くの試みが失敗している間、サービス管理の領域では、そのような取り組みが最終的に産業承認を獲得するかもしれません。 サービス管理のドメインでは、役に立って、設備かサービスプロバイダービジネスの必要性でその同時期においてマイナスの影響があることができないくらい特定の情報モデルは定義できるかもしれません。

Eder & Nag                   Informational                      [Page 6]

RFC 3052            Service Management Architectures        January 2001

エーダーと小煩い人の情報[6ページ]のRFC3052は2001年1月に管理体系を修理します。

   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つはそれを広げることができるように情報モデルを設計していますが、それでも、実際に元の形のまま使用されてください。 1秒は適合かプロキシ層を提供することです。 それぞれには、利点と損失があります。

   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

適合メソッドは、性能とスケーラビリティ問題を生じさせて、追加ネットワーク要素を作成することによって、複雑さをネットワークに追加できます。 管理フレームワークがネットワーク要素が、局所的に情報を保存するか、または情報を離れて保存させるのを選ぶのを許容するほどフレキシブルであるなら、同様の状況は存在しています。 デバイス見解から、評価基準はデバイスが会うためにそれが設計されているという他の要件に基づく論理を提供できるかどうかと、性能とスケーラビリティが情報の対象である要件であるとサポートするほど情報はそのような方法で検索できるかどうかということでしょう。 二分は性能とスケーラビリティの理由で直接ネットワーク要素に移される情報がいくつかの状況、および他にあるところに存在しています。

Eder & Nag                   Informational                      [Page 7]

RFC 3052            Service Management Architectures        January 2001

エーダーと小煩い人の情報[7ページ]のRFC3052は2001年1月に管理体系を修理します。

   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]であるとそれを広く実装させる取り組みの成功に依存しています。

   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

方針と共にしばしば議論した1つの概念が方針フレームワークにレガシーデバイスの統合に対処します。 推定はネイティブの管理インタフェースに方針情報を翻訳させることによってレガシーデバイスが政策決定に参加できるだろうということです。 これがデバイスを引き継ぐのが方針が指定される機能性をサポートしなければならないでしょう。 これはこのアプローチの有用性を情報だけに制限するでしょう。

Eder & Nag                   Informational                      [Page 8]

RFC 3052            Service Management Architectures        January 2001

エーダーと小煩い人の情報[8ページ]のRFC3052は2001年1月に管理体系を修理します。

   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.

規則を統合するとマネージメントシステムが既存のネットワークデバイスで基づいたので、フレームワークは容易に明らかではありません、そして、さらなる研究が必要です。 さらに人が、政策モデルが拡張されているのに従って意識しないかもしれない方針意識しているデバイスが早くあると考えるとき、問題は存在しています。 明確な発展経路がある正式な義務的な機能性が存在していないなら、与えられたデバイスが実施する政策のどんな局面で一貫性を予想するかが可能でないときに、方針部分的に意識しているデバイスは追加構造的な問題を表すかもしれません。 政策管理フレームワークが最高のに未来の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

要素とリンクが上下するネットワークの力学で、'方針プロトコル'の概念は必要になるかもしれません。 マルチサービス方策を必要とするマルチサービスネットワークに遺伝する'方針プロトコル'の考え。 例えば。 2の任意の終わりがそれらの間の複数のルーティング経路を持っているノードであると考えてください。 そして、ある一定の経路が何らかのIntserv帯域幅予約のテクニックに基づくあるサービスを提供すると仮定しましょう。 また、そして、その経路に沿った要素にはその要件をサポートするためにそれらの上で構成されたいくつかの要素特定保険証券声明があると推論しましょう。 現在、どんな与えられたインスタンスでも、どんなリンクか何か要素もその経路に沿って入手できないことであるなら、'方針プロトコル'は、同じサービス方策を構成しに自動的に行くために開始されます。

Eder & Nag                   Informational                      [Page 9]

RFC 3052            Service Management Architectures        January 2001

エーダーと小煩い人の情報[9ページ]のRFC3052は2001年1月に管理体系を修理します。

   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.

政策目標がある方針の協会はかなりの研究がする必要があるかもしれない領域です。 いくつかの問題はこれが、明らかにする必要があるかどうか、またはまた、目標の一般的な記述が含まれているように方針を書くことができるかどうかということですか? 政策目標がそれに関連しているそれらの方針を検索するのを許容します。

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が、広がり続けているとき、それは含むためにはベストエフォート型では、特に、パケットの処理を差別化してください、メカニズムをこれらの拡大をサポートすることができるようにするのがますます必要になるという向こうでのサービスの概念です。 一般的なマネジメント・モデルとフレームワークを定義する取り組みは歴史的にとらえどころがないと判明しました。 情報は、それらが伝統的であるか否かに関係なく、モデル化するか、またはベースで統治されて、必須アドレスは問題でこれらです。意志は、競争力において有利な立場、および現実がそのa一般的なモデルであることを保つ願望、本当に、一般的であるのがこのアプローチへの設備ベンダー側のしばしば承認を遅くしたのをデバイスを完全に管理できるくらいの詳細を明らかにしません。

   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が、それを広げ続けているのに従って、向こうでの特に含むためにはベストエフォート型についてパケットの処理を差別化するそれがそうするサービスの概念はメカニズムをこれらの拡大をサポートすることができるようにするのにますます必要になりましたか?

Eder & Nag                   Informational                     [Page 10]

RFC 3052            Service Management Architectures        January 2001

エーダーと小煩い人の情報[10ページ]のRFC3052は2001年1月に管理体系を修理します。

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.

ネットワークの経営情報の交換はセキュリティ見解から最も敏感な人間のひとりです。 管理プロトコルは、データの保全を保障するためにセキュリティを扱わなければなりません。 管理体系は、情報提供者の信憑性であって、セキュリティー対策がそれらを実装するのにおいて可能にしないくらいには扱いにくくないのを保障するために始まりからセキュリティ問題に備えなければなりません。

6. Reference

6. 参照

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

[1] マイケル・エーダー、シドNag、「IPサービス管理フレームワーク」という主権Bansalは進歩、1999年10月に働いています。

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

[2] ヒューマホン、ヨラムBernet、およびShaiハーツォグ、「政策管理システムのための要件」は進行中で働いています。

   [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.ゲラン、「方針ベースの入場コントロールのためのフレームワーク」、RFC2753、2000年1月。

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

[4] ヒューストン、G.、「IP QoSアーキテクチャのための次のステップ」、RFC2990、2000年11月。

   [5] McCloghrie, K. and M. Rose, "Management Information Base for
       Network Management of TCP/IP-based internets" RFC 1156, May 1990.

1990年5月の[5]McCloghrieとK.とM.ローズ、「TCP/IPベースのインターネットのNetwork Managementのための管理Information基地」RFC1156。

7. Authors' Addresses

7. 作者のアドレス

   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

Holmdel、シド小煩い人PO Box104ニュージャージー 07733

   EMail: thinker@monmouth.com

メール: thinker@monmouth.com

Eder & Nag                   Informational                     [Page 11]

RFC 3052            Service Management Architectures        January 2001

エーダーと小煩い人の情報[11ページ]のRFC3052は2001年1月に管理体系を修理します。

8. Full Copyright Statement

8. 完全な著作権宣言文

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

Copyright(C)インターネット協会(2001)。 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 & Nag                   Informational                     [Page 12]

エーダーと小煩い人情報です。[12ページ]