RFC1609 日本語訳
1609 Charting Networks in the X.500 Directory. G. Mansfield, T.Johannsen, M. Knopper. March 1994. (Format: TXT=30044 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group G. Mansfield
Request for Comments: 1609 AIC Systems Laboratory
Category: Experimental T. Johannsen
Dresden University
M. Knopper
Merit Networks, Inc.
March 1994
コメントを求めるワーキンググループG.マンスフィールド要求をネットワークでつないでください: 1609年のアイクシステム研究所カテゴリ: 実験的なT.ヨハンセンドレスデン大学M.Knopperは1994年のInc.行進のときにネットワークに値します。
Charting Networks in the X.500 Directory
X.500ディレクトリでネットワークを図にします。
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 このメモはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Abstract
要約
There is a need for a framework wherein the infrastructural and service related information about communication networks can be made accessible from all places and at all times in a reasonably efficient manner and with reasonable accuracy. This document presents a model in which a communication network with all its related details and descriptions can be represented in the X.500 Directory. Schemas of objects and their attributes which may be used for this purpose are presented. The model envisages physical objects and several logical abstractions of the physical objects.
かなり効率的な方法にまずまず正確に通信ネットワークに関するインフラストラクチャとサービス関連情報をすべての場所からアクセスしやすくいつもすることができるフレームワークの必要があります。 このドキュメントはX.500ディレクトリでそのすべての関連する詳細と記述がある通信ネットワークを代表することができるモデルを提示します。 このために使用されるかもしれないオブジェクトとそれらの属性のSchemasを寄贈します。 モデルは対象物の対象物といくつかの論理的な抽象化を考えます。
Mansfield, Johannsen & Knopper [Page 1] RFC 1609 Charting Networks in the X.500 Directory March 1994
マンスフィールド、ヨハンセン、および1994年3月にX.500ディレクトリでネットワークを図にするKnopper[1ページ]RFC1609
Table of Contents
目次
1. Introduction 2
2. Infrastructural information requirements 2
3. The Nature of the Network Map - The X.500 Solution 4
4. The hierarchical model of a network 5
4.1 Network maps 5
4.2 Representation in the X.500 Directory 6
5. Position in The Directory Information Tree(DIT) 7
6. Proposed Schemes 8
6.1 Communication Object Classes 9
6.2 Physical elements 10
6.2.1 Network 10
6.2.2 Node 11
6.2.3 NetworkInterface 12
6.3 Logical Elements 12
6.3.1 Network 13
6.3.2 Node 13
6.3.3 NetworkInterface 13
7. Security Considerations 14
8. Authors' Addresses 14
9. References 15
1. 序論2 2。 インフラストラクチャの情報必須条件2 3。 ネットワーク地図の本質--X.500ソリューション4 4。 ネットワーク5 4.1Networkの階層的なモデルは4.2に5を写像します。X.500ディレクトリ6 5におけるRepresentation。 ディレクトリでは、情報木の(デイット)7 6を置いてください。 Schemes8 6.1Communication Object Classes9 6.2のPhysical要素10 6.2.1Network10 6.2.2Node11 6.2.3NetworkInterface12 6.3Logical Elements12 6.3.1Network13 6.3.2Node13 6.3に.3NetworkInterfaceを提案する、13、7 セキュリティ問題14 8。 作者のアドレス14 9。 参照15
1. Introduction
1. 序論
The rapid and widespread use of computer networking has highlighted the importance of holding and servicing information about the networking infrastructure itself. The growing and active interest in network management, which has concentrated mainly in the areas of fault and performance management on a local scale, is severely constrained by the lack of any organized pool of information about the network infrastructure itself. Some attempts have been made, on a piecemeal basis, to provide a larger view of some particular aspect of the network (WHOIS, DNS, .. in the case of the Internet; [1], [2]). But to date, little or no effort has been made in setting up the infrastructural framework, for such an information pool. In this work we explore the possibility of setting up a framework to hold and serve the infrastructural information of a network.
コンピュータのネットワーク化の急速で広範囲の使用はネットワークインフラストラクチャ自体の情報を保持して、修理する重要性を強調しました。 ネットワークマネージメントへの成長と積極的関心はネットワークインフラ自体の情報のどんな組織化されたプールの不足によっても厳しく抑制されます。(ネットワークマネージメントは主に欠点とパフォーマンス管理の領域で地方のスケールに集中しました)。 ばらばらベースでネットワークの何らかの特定の局面の、より大きい意見を提供するのをいくつかの試みをしました。中、(WHOIS、DNS、インターネットに関するケース; [1]([2]))。 しかし、これまで取り組みはインフラストラクチャのフレームワークをセットアップする際にまず作られていません、そのような情報プールに。 この仕事では、私たちは枠組を設定するのがネットワークのインフラストラクチャの情報を保持して、役立つ可能性を探ります。
2. Infrastructural information requirements
2. インフラストラクチャの情報必須条件
Network operation and management requires information about the structure of the network, the nodes, links and their properties. Further, with current networks extending literally beyond bounds, the scope of the information covers networks beyond the span of local domain of authority or administration. When the Network was relatively small and simple the map was already known to the knowledgable network administrator. Based on this knowledge the
ネットワーク操作と経営者側はネットワーク、ノード、リンク、および彼らの特性の構造の情報を必要とします。 さらに、文字通り領域を超えて広がっている現在のネットワークで情報の範囲は権威か管理の局所領域の長さを超えてネットワークをカバーしています。 Networkが比較的小さくて、簡単であったときに、地図は博識なネットワーク管理者にとって既に知られていました。 この知識に基づいています。
Mansfield, Johannsen & Knopper [Page 2] RFC 1609 Charting Networks in the X.500 Directory March 1994
マンスフィールド、ヨハンセン、および1994年3月にX.500ディレクトリでネットワークを図にするKnopper[2ページ]RFC1609
course of the packets to different destinations would be charted. But presently the size of the Network is already beyond such usages. The current growth of the Network is near explosive. This is giving rise to the urgent necessity of having infrastructural and service related information made accessible from all places and at all times in a reasonably efficient manner and with reasonable accuracy. In the rest of this work a network is the media for transmitting information. Network elements are equipment with one or more network interfaces whereby it is possible to exchange information with the network. Network elements with multiple interfaces e.g., gateways/routers/bridges/repeaters... may be used to connect networks. Network related information, referred to as 'network map' in the rest of this paper, should
異なった目的地へのパケットのコースは計画されるでしょう。 しかし、現在のNetworkのサイズはそのような用法を超えて既にいます。 Networkの現在の成長が爆発的近くにあります。 これは有の差し迫った必要への上昇をインフラストラクチャに与えています、そして、サービスはいつもかなり効率的な方法にまずまず正確にすべての場所からアクセスしやすくされた情報について話しました。 この仕事の残りでは、ネットワークは、情報を伝えるためのメディアです。 ネットワーク要素はネットワークと共に情報交換するのが可能である1つ以上のネットワーク・インターフェースがある設備です。 複数のインタフェースがある要素をネットワークでつないでください、そして、例えば、ゲートウェイ/ルータ/ブリッジ/リピータは、…ネットワークを接続するのに使用されてもよいです。 この紙の残りで'ネットワーク地図'と呼ばれたネットワーク関連情報はそうするべきです。
1. Show the interconnection between the various network
elements. This will basically represent the Network as a graph
where vertices represent objects like gateways/workstations/
subnetworks and edges indicate the connections.
1. 様々なネットワーク要素の間のインタコネクトを示してください。 これはgateways/workstations/サブネットワークと縁が接続を示すように頭頂がオブジェクトを表すグラフとして基本的にNetworkを表すでしょう。
2. Show properties and functions of the various network elements
and the interconnections. Attributes of vertices will represent
various properties of the objects e.g., speed, charge, protocol, OS,
etc. Functions include services offered by a network element.
2. 特性と様々なネットワーク要素とインタコネクトの機能を示してください。 頭頂の属性は例えば、速度、充電が議定書の中で述べるオブジェクト、OSなどの様々な特性を表すでしょう。 機能はネットワーク要素によって提供されたサービスを含んでいます。
3. Contain various name and address information of the networks
and network elements
3. ネットワークとネットワーク要素に関する様々な名前とアドレス情報を含んでください。
4. Contain information about various administrative and management
details related to the networks and network elements.
4. ネットワークとネットワーク要素に関連する管理と管理の様々な詳細の情報を含んでください。
5. Contain the policy related information, part of which may be
private while the other part may be made public.
5. 方針関連情報を含んでください。もう片方の部分が公表されるかもしれない間、その部分は個人的であるかもしれません。
Using this map the following services may be provided
以下のサービスが提供されるかもしれないこの地図を使用します。
1. Configuration management:
1. 構成管理:
- Display the physical configuration of a network,
i.e., nodes and their physical interconnections
- Display the logical configuration of a network,
i.e., nodes and their logical interconnections.
- すなわち、ネットワーク、ノードの物理的な構成とそれらの物理的なインタコネクトを表示してください--すなわち、ネットワーク、ノードの論理的な構成とそれらの論理的なインタコネクトを表示してください。
2. Route management:
2. 管理を発送してください:
- Find alternate routes by referring to the physical
and logical configurations.
- Generate routing tables considering local policy and
policy of transit domains
- 物理的で論理的な構成について言及することによって、代替経路を見つけてください。 - ローカルの方針とトランジットドメインの方針を考えて、ルーティングがテーブルであると生成してください。
Mansfield, Johannsen & Knopper [Page 3] RFC 1609 Charting Networks in the X.500 Directory March 1994
マンスフィールド、ヨハンセン、および1994年3月にX.500ディレクトリでネットワークを図にするKnopper[3ページ]RFC1609
- Check routing tables for routing loops,
non-optimality, incorrect paths, etc.
- ルーティング輪、非最適の、そして、不正確な経路などがないかどうか経路指定テーブルをチェックしてください。
3. Fault management: In case of network failures
alternatives may be found and used to bypass the
problem node or link.
3. 障害管理: ネットワーク失敗の場合には、代替手段は、問題ノードを迂回させるか、またはリンクするのに見つけられて、使用されるかもしれません。
4. Service management: Locate various services and
servers in the Network.
4. 管理にサービスを提供してください: Networkで様々なサービスとサーバの場所を見つけてください。
5. Optimization: The information available can be used
to carry out various optimizations, for example cost,
traffic, response-time, etc.
5. 最適化: 様々な最適化、例えば、費用、トラフィック、応答時間などを行うのに利用可能な情報を使用できます。
6. Provide mappings between the various names and
addresses of elements
6. 要素の様々な名前とアドレスの間にマッピングを提供してください。
7. Depict administrative/autonomous domains.
7. 管理の、または、自治のドメインについて表現してください。
8. Network Administration and Management: References to
people responsible for administering and technically
maintaining a network will be useful.
8. 政権と管理をネットワークでつないでください: ネットワークを管理して、技術的、維持するのに責任がある人々についての言及は役に立ちます。
Examples of such usages are described in [3], [4].
そのような用法に関する例は[3]、[4]で説明されます。
3. The Nature of the Network Map - The X.500 solution
3. Network Mapのネイチャー--X.500ソリューション
Implementing and maintaining a detailed map of the network poses a serious problem. The scope of the map is global and the network itself is expanding. Some of the problems that are peculiar to the network map are listed below.
ネットワークの精密な地図を実装して、維持するのは重要問題を提起します。 地図の範囲はグローバルです、そして、ネットワーク自体は拡張しています。 ネットワーク地図に独特の問題のいくつかが以下に記載されています。
o The Network configuration is quasi-static. Nodes,
links and networks are being added,updated and deleted
someplace or the other.
o Network構成は準静的です。 ノード、リンク、およびネットワークは、どこかで加えられて、アップデートされて削除された存在かもう片方です。
o The Network is huge and geographically distributed.
o Networkは巨大で地理的に分配されています。
o The network spans several political and administrative
areas. The related information is also controlled and
maintained in a distributed fashion.
o ネットワークはいくつかの政治犯と行政区域にかかっています。 関連情報は、分配されたファッションでまた、制御されて、維持されます。
In short, global network configuration information is unwieldy and growing continuously. It is impossible to service such information in a centralized fashion. There is need for a distributed framework which allows users and applications to access information about users, services, networks, ... easily and globally. The OSI X.500 Directory services [5] provides a rich framework to support a
要するに、世界的なネットワーク設定情報は、絶え間なく扱いにくくて、増加しています。 集結されたファッションによるそのような情報を修理するのは不可能です。 ユーザを許容する分配されたフレームワークとアプリケーションがユーザの情報にアクセスする必要があります、サービス、ネットワーク… 簡単に、そしてグローバルに。 OSI X.500ディレクトリサービス[5]は、aをサポートするために豊かなフレームワークを提供します。
Mansfield, Johannsen & Knopper [Page 4] RFC 1609 Charting Networks in the X.500 Directory March 1994
マンスフィールド、ヨハンセン、および1994年3月にX.500ディレクトリでネットワークを図にするKnopper[4ページ]RFC1609
globally distributed information service system. The X.500 Directory is intended to be a very large and highly distributed database. It is structured hierarchically with entries arranged in the form of a tree in which each object corresponds to a node or an entry. Information is stored about an object as a set of attributes.
グローバルに分配された情報サービス・システム。 X.500ディレクトリは非常にまさしくその大きさであることを意図します。分散データベース。 エントリーが各オブジェクトがノードかエントリーに対応する樹形でアレンジされている状態で、それは階層的で構造化されます。 情報は1セットの属性としてオブジェクトに関して保存されます。
4. The hierarchical model of a network
4. ネットワークの階層的なモデル
For representing networks in the Directory we use the following hierarchical model.
ディレクトリでネットワークを代表するために、私たちは以下の階層的なモデルを使用します。
A network is the media for transmitting information with zero or more network elements each having at least one network interface on the media. The media may be any kind of a line (physical circuit/virtual circuit), or a collection of interconnected networks.
ネットワークはゼロで情報を伝えるためのメディアであるかそれぞれ少なくとも1つのネットワークを持っているより多くのネットワーク要素がメディアで連結します。 メディアは、系列(実回線/仮想の回路)のどんな種類、または相互接続ネットワークの収集であるかもしれません。
< The postscript version of this document >
< has a figure here. However, the figure >
<is too complex to be drawn in simple ASCII.>
aがここでこのドキュメント><の追伸バージョンで計算する<。 しかしながら、図><は簡単なASCII>に描くことができないくらい複雑です。
Figure 1: Simple and composite networks and their mapping to the DIT.
図1: 簡単で合成しているネットワークとDITへのそれらのマッピング。
The model allows hierarchy of subnetworks. Network elements with multiple interfaces may act as external gateways to the attached network and to networks higher up in the hierarchy. Thus, a gateway may be the external gateway of several networks which are either interconnected or have a hierarchical relationship.
モデルはサブネットワークの階層構造を許容します。 複数のインタフェースがあるネットワーク要素は付属ネットワークと、そして、ネットワークへの外部のゲートウェイとして階層構造で、より高く作用するかもしれません。 したがって、ゲートウェイには、インタコネクトされるいくつかのネットワークの外部のゲートウェイであるか上下関係があるかもしれません。
A network may be simple consisting of zero or more network elements or composite consisting of several sub-networks. Examples of simple networks are ethernets, optical fiber/copper cables, free space, .. .
ネットワークがゼロから成るのにおいて簡単であるかもしれませんか、または以上はいくつかのサブネットワークの要素か合成成ることをネットワークでつなぎます。 簡単なネットワークに関する例はイーサネット、光ファイバ/銅のケーブル、空きスペースです。 .
4.1 Network Maps
4.1 ネットワーク地図
Using the above model it is straight forward to draw the topological graph of the network where the vertices represent the components of the network and edges indicate the connections. For visual representation the graph may be translated to a more "physical" illustration (figure 1).
上のモデルを使用して、頭頂がネットワークの成分を表して、縁が接続を示すネットワークの位相的なグラフを描くのは前方でまっすぐです。 視覚表現において、グラフは、より「物理的な」イラスト(1について計算する)に翻訳されるかもしれません。
Just as there are several maps of the same geographical domain (political, natural...) one can envisage several views of the same network and its components. A view (called "image" in the remainder) could pertain to a particular protocol suite (IP/OSI/...), an administrative domain or purpose. Using images, several abstractions of the same object are possible.
ちょうど同じ地理的なドメインの数個の地図があるとき、(政治上で、自然)の人は同じネットワークとそのコンポーネントのいくつかの視点を考えることができます。 意見(残りにおける「イメージ」と呼ばれる)は特定のプロトコル群(IP/OSI/…)、管理ドメインまたは目的に関係するかもしれません。 イメージを使用して、同じオブジェクトのいくつかの抽象化が可能です。
Mansfield, Johannsen & Knopper [Page 5] RFC 1609 Charting Networks in the X.500 Directory March 1994
マンスフィールド、ヨハンセン、および1994年3月にX.500ディレクトリでネットワークを図にするKnopper[5ページ]RFC1609
4.2 Representation in the X.500 Directory
4.2 X.500ディレクトリにおける表現
To represent the various images of networks and its components along with the real-image relationship among the various objects we introduce the following classes of objects:
様々なオブジェクトの中にネットワークの様々なイメージと実像関係に伴うそのコンポーネントを表すために、私たちは以下のクラスのオブジェクトを導入します:
o Communication Object Class (CO): All objects defined
furtheron in this document belong to this class.
Common attributes for all communication objects are
defined in section 6.
o コミュニケーションオブジェクトのクラス(CO): これの定義されたfurtheronがこのクラスのものと記録するすべてのオブジェクト。 すべてのコミュニケーションオブジェクトのための一般的な属性はセクション6で定義されます。
o Physical Communication Object Class (PCO): A subclass
of CO-class, this class defines common properties for
all objects representing physical communication objects.
o 物理的なコミュニケーションオブジェクトのクラス(PCO): CO-クラスのサブクラスであり、このクラスは物理的なコミュニケーションオブジェクトを表すすべてのオブジェクトのために通有性を定義します。
o Image Communication Object Class (ICO): A subclass of
CO-class, this class defines common properties for all
objects representing images of communication objects.
o イメージコミュニケーションオブジェクトのクラス(ICO): CO-クラスのサブクラスであり、このクラスはコミュニケーションオブジェクトのイメージを表すすべてのオブジェクトのために通有性を定義します。
The above classes sort communication objects into physical or image object. As is implied in the nomenclature a physical object will have several attributes describing it physical properties - location, weight, size, .... etc. An image object will have an Image-of attribute. The Image-of attribute will point to a physical object or to another image object.
上のクラスはコミュニケーションオブジェクトを物理的であるかイメージオブジェクトに分類します。 それについて説明する物理的性質--位置が重みを加えるサイズを用語体系a対象物が数個にする暗示しているコネは結果と考えます… そのままで、など イメージオブジェクトが持つ、Image、-、属性。 Image、-、属性は対象物、または、別のイメージオブジェクトに指すでしょう。
Using this schema it is possible to represent the case of several logical network systems (running different protocol stacks - IP, XNS, SNA, OSI, ...) which coexist on the same physical network. Information related to different types of networks, no matter what the underlying communication protocol is, will reside in the Directory in harmony. Also, their interrelation will be represented and accessed in a fashion independent of the source/destination network, namely, using the OSI X.500 protocol.
この図式を使用して、同じ物理ネットワークに共存する数個の論理的なネットワーク・システム(実行している異なったプロトコル・スタック(IP、XNS、SNA、OSI))に関するケースを表すのは可能です。 基本的な通信プロトコルが何であっても異なったタイプのネットワークに関連する情報は調和におけるディレクトリであるでしょう。 また、ファッションで、それらの相互関係は、ソース/送信先ネットワークの如何にかかわらずすなわち、OSI X.500プロトコルを使用しながら、表されて、アクセスされるでしょう。
Schemes for physical networks and logical images of physical networks are defined in section 6.
物理ネットワークの物理ネットワークと論理的なイメージの体系はセクション6で定義されます。
All objects are defined in section 6.
すべてのオブジェクトがセクション6で定義されます。
Mansfield, Johannsen & Knopper [Page 6] RFC 1609 Charting Networks in the X.500 Directory March 1994
マンスフィールド、ヨハンセン、および1994年3月にX.500ディレクトリでネットワークを図にするKnopper[6ページ]RFC1609
...............
: :
: IP OSI :
: +-+ +-+ :
: |A| |B| :
NetWork -----> : +-+ +-+ :
/ \ : | | :
/ \ : ============ :
/ \ : | :
/ \ : +-+ :
/ \ : |C| :
/ \ : +-+ :
OSI-image IP-image : IP + OSI :
| | +..............+
V V
........ ........
: : : :
IP : OSI : : IP : OSI
+-+ : +-+ : : +-+ : +-+
|A| : |B| : : |A| : |B|
+-+ : +-+ : : +-+ : +-+
....|...: | : : | :..|...
: ============ : : ============ :
: | : : | :
: +-+ : : +-+ :
: |C| : : |C| :
: +-+ : : +-+ :
: IP + OSI : : IP + OSI :
+..............+ +..............+
............... : : : IPオウシ: : +-+ +-+ : : |A| |B| : ネットワーク----->: +-+ +-+ : / \ : | | : / \ : ============ : / \ : | : / \ : +-+ : / \ : |C| : / \ : +-+ : OSI-イメージIP-イメージ: + IPオウシ: | | +..............+ V V… ........ : : : : IP: オウシ: : IP: オウシ++: +-+ : : +-+ : +-+ |A| : |B| : : |A| : |B| +-+ : +-+ : : +-+ : +-+ ....|...: | : : | :..|... : ============ : : ============ : : | : : | : : +-+ : : +-+ : : |C| : : |C| : : +-+ : : +-+ : : + IPオウシ: : + IPオウシ: +..............+ +..............+
Figure 2: Several logical views of the same physical network
図2: 同じ物理ネットワークのいくつかの論理的な視点
5. Position in the Directory Information Tree (DIT)
5. ディレクトリ情報木の位置(デイット)
Information about networks usually will be contained in the DIT as subordinate of the organization maintaining the network. The network model gets mapped into a tree structure for network elements. There is one network object giving general descriptions of the network. Subordinates of this network object are node objects for each node element present in the network. Node objects hold networkInterface objects as subordinates. A network can be physically or logically subdivided into several (sub)networks. In this case, a network entry will have network objects as subordinates which again build the same structure. These entries may be kept as subordinates of organizationalUnit entries as well, with pointers from the "root" network.
通常、ネットワークに関する情報はネットワークを維持する組織の部下としてDITに含まれるでしょう。 ネットワークモデルはネットワーク要素のために木構造に写像されます。 ネットワークの概説を与える1個のネットワークオブジェクトがあります。 ネットワークがノードであることを反対させるこの部下はネットワークにおける現在のそれぞれのノード要素のために反対します。 ノードオブジェクトは部下としてnetworkInterfaceオブジェクトを持っています。 ネットワークをいくつかの(潜水艦)ネットワークに物理的か論理的に細分できます。 この場合、ネットワークエントリーには、再び同じ構造を建設する部下としてネットワークオブジェクトがあるでしょう。 これらのエントリーはまた、organizationalUnitエントリーの部下として指針で「根」ネットワークから保たれるかもしれません。
Mansfield, Johannsen & Knopper [Page 7] RFC 1609 Charting Networks in the X.500 Directory March 1994
マンスフィールド、ヨハンセン、および1994年3月にX.500ディレクトリでネットワークを図にするKnopper[7ページ]RFC1609
This structure holds for physical and logical elements. Physical elements are named network, node and networkInterface, and logical elements are named networkImage, nodeImage and networkInterfaceImage.
この構造は物理的、そして、論理要素のために持ちこたえます。 物理的な要素はネットワーク、ノード、およびnetworkInterfaceと命名されます、そして、論理要素はnetworkImage、nodeImage、およびnetworkInterfaceImageと命名されます。
_root_
/ \
/ \
/ \
country \
/ \
/ organization
/ / | \
/ / | \
/ / | \
/ / | \
/ organizationalUnit* | \
/ / \ \ | \
/ / \ \__|_________ \
/ / \ | \ \
Person Network*<====>NetworkImage*
| |
| |
Node NodeImage
| |
| |
NetworkInterface NetworkInterfaceImage
_根の_/\/\/\国の\/\/組織//| \ / / | \ / / | \ / / | \/organizationalUnit*| \ / / \ \ | \ / / \ \__|_________ \ / / \ | \\人のネットワーク*<。====>NetworkImage*| | | | ノードNodeImage| | | | NetworkInterface NetworkInterfaceImage
Legends: * the object may recursively contain objects of
same class as children
レジェンズ: * オブジェクトは子供として同類のオブジェクトを再帰的に含むかもしれません。
Figure 3: Part of the Directory Information Tree,
showing relations of White Pages and network objects
図3: ホワイトPagesとネットワークオブジェクトの関係を示しているディレクトリ情報Treeの一部
6. Proposed Schemes
6. 提案された体系
A physical network comprises of wires and machines. The physical map of the network will show the interconnections of these nodes by these circuits.
物理ネットワークはワイヤとマシンで包括します。 ネットワークの物理的地図はこれらの回路のそばにこれらのノードのインタコネクトを示すでしょう。
For each physical network element, one or more images may exist. Similarly, an image may be attached to one or more physical objects. The types of images can grow along with the requirements. Relationship between elements (physical or logical) are expressed by attributes or the position in the Directory tree.
それぞれの物理ネットワーク要素のために、1つ以上のイメージが存在するかもしれません。 同様に、イメージは1個以上の対象物に添付されるかもしれません。 イメージのタイプは要件と共に成長できます。 要素(物理的であるか論理的な)の間の関係はディレクトリ木で属性か位置によって言い表されます。
Mansfield, Johannsen & Knopper [Page 8] RFC 1609 Charting Networks in the X.500 Directory March 1994
マンスフィールド、ヨハンセン、および1994年3月にX.500ディレクトリでネットワークを図にするKnopper[8ページ]RFC1609
Problems that are addressed in the schema:
図式で扱われる問題:
1. Avoiding data duplication
2. Preserving administrative boundaries/controls.
3. Simple representation (minimal number of pointers)
4. Security: Though no special emphasis has been placed
in this work we believe the X.500 access control policies
policies will provide a reasonable secure framework for security
and privacy.
1. データ重複2を避けます。 管理境界/コントロールを保持します。 3. 簡単な表現(最小量の数の指針)4。 セキュリティ: どんな特別な強調もこの仕事に置かれていませんが、私たちは、X.500アクセス制御方針方針が妥当な安全なフレームワークをセキュリティとプライバシーに提供すると信じています。
Problems that are not addressed:
扱われない問題:
1. Caching policies, etc.: to be decided locally
1. キャッシング方針など: 局所的に決められるために
6.1 Communication Object Classes
6.1 コミュニケーションオブジェクトのクラス
The object classes introduced in section 4 are defined as follows:
セクション4で導入されたオブジェクトのクラスは以下の通り定義されます:
CommunicationObject OBJECT CLASS
SUBCLASS of top
MAY CONTAIN {
description :: CaseIgnoreStringSyntax,
/* can contain any information about the object,
however, wherever an appropriate attribute
exists, this should be used first to hold
information */
adminContact :: distinguishedNameSyntax,
/* points to the person which is responsible for
the administration of the instance this object
describes;
This refers to the instance only in the context
of the concrete object class */
technContact :: distinguishedNameSyntax,
/* points to the person which is responsible for
the technical maintenance of the instance this
object describes;
This refers to the instance only in the context
of the concrete object class;
Availability (e.g. hours of service) is not
covered by this attribute. */
}
最高MAY CONTAINのCommunicationObject OBJECT CLASS SUBCLASS{ 記述:、: しかしながら、CaseIgnoreStringSyntax、/*はオブジェクトのどんな情報も含むことができて、適切な属性が存在していて、これは最初に、情報*/adminContactを持つのに使用されるべきです:、: distinguishedNameSyntax、人へのこのオブジェクトが説明するインスタンスの管理に原因となる/*ポイント。 これは具体的なオブジェクトのクラス*/technContactの文脈だけのインスタンスを示します:、: distinguishedNameSyntax、人へのこのオブジェクトが説明するインスタンスの技術的メンテナンスに原因となる/*ポイント。 これは具体的なオブジェクトのクラスの文脈だけのインスタンスを示します。 有用性(例えば、何時間もの仕事)はこの属性でカバーされていません。 */ }
PhysicalCommunicationObject OBJECT CLASS
SUBCLASS of CommunicationObject
MAY CONTAIN{
owner :: distinguishedNameSyntax,
/* refers to organization or person owning the
physical element;
CommunicationObject MAY CONTAINのPhysicalCommunicationObject OBJECT CLASS SUBCLASS、所有者: : distinguishedNameSyntax、/*は物理的な要素を所有している組織か人について言及します。
Mansfield, Johannsen & Knopper [Page 9] RFC 1609 Charting Networks in the X.500 Directory March 1994
マンスフィールド、ヨハンセン、および1994年3月にX.500ディレクトリでネットワークを図にするKnopper[9ページ]RFC1609
Note that more detailed information (like lease,
rental, etc.) can be covered in a specific image
(ownerImage) of this element */
localityName :: CaseIgnoreStringSyntax
/* where the object is located;
can be used freely to "spot" a network element,
e.g. state/city/street/building/floor/room/
desk/... */
ICO :: distinguishedNameSyntax
/* points to image object the physical object
is related to;
might have several values if physical object is
used for several applications at the same time */
}
この要素*/localityNameの特定のイメージ(ownerImage)で、より詳細な情報(リース、レンタルなどのような)をカバーできることに注意してください:、: オブジェクトが位置しているCaseIgnoreStringSyntax/*。 ネットワーク要素、例えばstate/city/street/building/floor/room/ desk/を「見つけること」に自由に使用できます… */、イコー:、: distinguishedNameSyntax/*は対象物が関連するイメージオブジェクトを示します。 対象物が同じ時間*/のいくつかのアプリケーションに使用されるなら、いくつかの値を持っているかもしれません。
ImageCommunicationObject OBJECT CLASS
SUBCLASS of CommunicationObject
MAY CONTAIN{
type :: caseIgnoreStringSyntax,
/* expresses the view this object refers to, e.g.
view of provider/user/IP/OSI/...;
Note that this information can be covered by
the object class in some cases
(e.g. ipNetworkImage gives the IP view) */
imageOf :: distinguishedNameSyntax,
/* points to physical/image object the image
is related to;
might have several values if view applies to
several physical objects at the same time */
}
CommunicationObjectのクラスサブクラスが含むかもしれないImageCommunicationObjectオブジェクト以下をタイプしてください: caseIgnoreStringSyntax、/*はこのオブジェクトが示す視点を言い表します、例えば、provider/user/IP/OSI/の視点… いくつかの場合(例えば、ipNetworkImageはIP意見を与える)オブジェクトのクラス*/imageOfでこの情報をカバーできることに注意してください: : distinguishedNameSyntax、/*はイメージが関連する物理的な/イメージオブジェクト; 視点が同じ時間*/の数個の対象物に適用されるならいくつかの値を持っているかもしれないのを示します。
6.2 Physical elements
6.2 物理的な要素
The following objects describe network elements without saying anything about their usage. All objects inherit properties of the PhysicalCommunicationObject class.
それらの用法に関して何も言わないで、以下のオブジェクトはネットワーク要素について説明します。 すべてのオブジェクトがPhysicalCommunicationObjectのクラスの特性を引き継ぎます。
6.2.1 Network
6.2.1 ネットワーク
The network object supplies general descriptions which are common for a set of nodes and circuits comprising one network. This includes information about the type of circuits (medium, broadcast or point- to- point, etc.) and properties (speed etc.).
ネットワークオブジェクトは1つのネットワークを包括する1セットのノードと回路に、一般的な概説を供給します。 これが回路のタイプの情報を含んでいる、(媒体、放送またはポイント、-、ポイントなど) そして、特性(速度など)。
network OBJECT CLASS
SUBCLASS of PhysicalCommunicationObject
MUST CONTAIN {
networkName :: caseIgnoreStringSyntax }
PhysicalCommunicationObject MUST CONTAINのネットワークOBJECT CLASS SUBCLASSnetworkName: : caseIgnoreStringSyntax
Mansfield, Johannsen & Knopper [Page 10] RFC 1609 Charting Networks in the X.500 Directory March 1994
マンスフィールド、ヨハンセン、および1994年3月にX.500ディレクトリでネットワークを図にするKnopper[10ページ]RFC1609
MAY CONTAIN {
externalGateway :: distinguishedNameSyntax,
/* points to one or more nodes that connect
this network to neighbor networks;
whether a node actually is used as gateway
for one or the other protocol, is defined
in a related networkImageObject */
nwType :: caseIgnoreStringSyntax,
/* type of this network;
either "composite" (if consisting of subnetworks)
or type of a line:
bus, ring, star, mesh, point-to-point */
media :: caseIgnoreStringSyntax,
/* if network is not composite,
describes physical media:
copper, fiber optic, etc. */
speed :: numericStringSyntax,
/* nominal bandwidth, e.g. 64 kbps */
traffic :: numericStringSyntax
/* (average) use in percent of nominal bandwidth
[ this needs more specification later ] */
configurationDate :: uTCTimeSyntax,
/* date when network was configured in current
shape */
configurationHistory :: caseIgnoreStringSyntax
/* list of configuration changes, like:
added/removed nodes, lines */
}
含むかもしれません。{ externalGateway:、: distinguishedNameSyntax、/*はこのネットワークを隣人ネットワークに接続する1つ以上のノードを示します。 ノードが1かもう片方のプロトコルに実際にゲートウェイとして使用されて、関連するnetworkImageObject*/nwTypeで定義されるか否かに関係なく、以下のこと、: caseIgnoreStringSyntax、このネットワークの/*タイプ。 系列の「合成物」(サブネットワークから成るなら)かタイプのどちらか: バス、リング、星、メッシュ、二地点間*/メディア:、: caseIgnoreStringSyntax、/、*ネットワークが合成していなくて、物理的なメディアを説明するなら: 銅、光ファイバーなど */は以下を促進します: numericStringSyntax、/*呼び帯域幅、例えば、64キロビット毎秒*/は以下を取引します: numericStringSyntax/*(平均した)はパーセントの呼び帯域幅[これは後でより多くの仕様を必要とする]*/configurationDateで以下を使用します: uTCTimeSyntax、ネットワークが現在の形の*/configurationHistoryで構成された/*日付:、: 構成のcaseIgnoreStringSyntax/*リストは以下のように変化します。 加えられたか取り除かれたノード、系列*/}
6.2.2 Node
6.2.2 ノード
The node object describes any kind of device that is part of the network, such as simple nodes, printer, bridges.
ノードオブジェクトはどんな種類のデバイスについても説明します、すなわち、ネットワークの簡単なノードなどの一部(プリンタ)がブリッジします。
node OBJECT CLASS
SUBCLASS of PhysicalCommunicationObject
MUST CONTAIN{
nodeName :: caseIgnoreStringSyntax }
MAY CONTAIN {
machineType :: caseIgnoreStringSyntax,
/* e.g. main frame, work station, PC, printer;
might include manufacturer */
OS :: caseIgnoreStringSyntax,
/* e.g. VM, UNIX, DOS; might include release */
}
PhysicalCommunicationObject MUST CONTAINのノードOBJECT CLASS SUBCLASS、nodeName: : caseIgnoreStringSyntax、MAY CONTAINmachineType: : caseIgnoreStringSyntax、例えば、本体、ワークステーション、PC、プリンタ; 力のインクルードメーカー*/OS: : caseIgnoreStringSyntax、例えば、/*VM、UNIX、DOS; 力が含む/*は*/をリリースします。
Mansfield, Johannsen & Knopper [Page 11] RFC 1609 Charting Networks in the X.500 Directory March 1994
マンスフィールド、ヨハンセン、および1994年3月にX.500ディレクトリでネットワークを図にするKnopper[11ページ]RFC1609
6.2.3 NetworkInterface
6.2.3 NetworkInterface
Each node object will have one or more networkInterface objects as subordinates. NetworkInterface objects provide information about interfaces of the node and connectivity.
それぞれのノードオブジェクトには、部下として1個以上のnetworkInterfaceオブジェクトがあるでしょう。 NetworkInterfaceオブジェクトはノードと接続性のインタフェースの情報を提供します。
networkInterface OBJECT CLASS
SUBCLASS of PhysicalCommunicationObject
MUST CONTAIN {
networkInterfaceName :: caseIgnoreStringSyntax
/* It is suggested that the networkInterface
name is derived from the name of the logical
device this networkInterface represents for
the operating system, e.g. le0, COM1 */
}
MAY CONTAIN {
networkInterfaceAddress :: caseIgnoreStringSyntax,
/* this should contain a protocol-independent
interface address, e.g. Ethernet board number */
connectedNetwork :: distinguishedNameSyntax,
/* pointer to object of network which this networkInterface is
connected to */
}
PhysicalCommunicationObject MUST CONTAINのnetworkInterface OBJECT CLASS SUBCLASS、networkInterfaceName: : caseIgnoreStringSyntax/、*networkInterface名がこのnetworkInterfaceがオペレーティングシステムのために表す論理的なデバイスの名前から導いていると示唆されます、例えば、le0、COM1*/、MAY CONTAINnetworkInterfaceAddress: : caseIgnoreStringSyntax、これが*/に接続されて、このnetworkInterfaceがそうであるネットワークについて反対するためにプロトコルから独立しているインタフェースアドレス、*/connectedNetwork: : 例えば、イーサネットボード番号distinguishedNameSyntax、/*指針を含むべきである/*
6.3 Logical Elements
6.3 論理要素
An abstract view of a physical element is called image in this document. The word image gets appended to the object type, leading to the new objects networkImage, nodeImage and networkInterfaceImage. Images will either build Directory trees of themselves or be stored as part of the physical network tree (see section 5).
物理的な要素の抽象的な視点は本書ではイメージと呼ばれます。 新しいオブジェクトのnetworkImage、nodeImage、およびnetworkInterfaceImageに通じて、単語イメージをオブジェクト・タイプに追加します。 イメージズは、自分たちのディレクトリ木を建てるか、または物理ネットワーク木の一部として保存されるでしょう(セクション5を見てください)。
Image objects inherit properties of the ImageCommunicationObject class.
イメージオブジェクトはImageCommunicationObjectのクラスの特性を引き継ぎます。
Each image object has specific attributes which vary depending on the point of view (IP, OSI, ...). Also, the user and provider of an image will view an object differently; further a user of an object may also be providing the services of the same object to another user.
それぞれのイメージオブジェクトには、観点(IP、OSI)によって、異なる特定の属性があります。 また、イメージのユーザとプロバイダーはオブジェクトを異なって見るでしょう。 また、さらに、オブジェクトのユーザは別のユーザに対する同じオブジェクトのサービスを提供しているかもしれません。
Therefore, in the following a complete and general list of attributes cannot be given. We recommend to define subclasses of Image classes for each logical view. These subclasses inherit all attributes defined with the object classes below and add more specific attributes. Examples for an IP-view are given in [1].
したがって、以下の属性の完全で一般的なリストを与えることができません。 私たちは、Imageのサブクラスを定義するのがそれぞれの論理的な視点のために属することを勧めます。 これらのサブクラスは、オブジェクトのクラスが以下にある状態で定義されたすべての属性を引き継いで、より特定の属性を加えます。 IP-視点のための例は[1]で出されます。
Mansfield, Johannsen & Knopper [Page 12] RFC 1609 Charting Networks in the X.500 Directory March 1994
マンスフィールド、ヨハンセン、および1994年3月にX.500ディレクトリでネットワークを図にするKnopper[12ページ]RFC1609
6.3.1 Network
6.3.1 ネットワーク
There may be several network images for one and the same physical network: one for each protocol, application, etc.
全く同じ物理ネットワークのためのいくつかのネットワークイメージがあるかもしれません: 各プロトコル、アプリケーションなどのためのもの
networkImage OBJECT CLASS
SUBCLASS of ImageCommunicationObject
MAY CONTAIN {
externalGateway :: distinguishedNameSyntax,
/* points to one or more nodes that act
as gateway for the protocol application
this images refers to */
speed :: numericStringSyntax,
/* nominal bandwidth for the channel dedicated
to this protocol or application ,
e.g. 64 kbps */
traffic :: numericStringSyntax,
/* (average) use in percent of nominal bandwidth
[this needs more specification later ] */
charge :: numericStringSyntax
/* amount of money that has to be paid to
service provider for usage;
[it is felt that this needs further definition:
e.g. monetary unit / time unit, monetary unit /
data unit ] */
}
ImageCommunicationObjectのクラスサブクラスが含むかもしれないnetworkImageオブジェクト{ externalGateway: : distinguishedNameSyntax、/*はこのイメージが*を参照するか、または促進するプロトコルアプリケーションのためのゲートウェイとして以下を機能させる1つ以上のノード: numericStringSyntax、このプロトコルかアプリケーション、例えば、64キロビット毎秒*/トラフィックに専念したチャンネルのための/*呼び帯域幅に以下を指します; numericStringSyntax、これが、より多くの仕様の後の*/充電: : それが持っているnumericStringSyntax/*金額が用法のためにサービスプロバイダーに支払われる必要がある呼び帯域幅のパーセントにおける/*(平均する)の使用; これがさらなる定義を必要とすると感じられます: 例えば、通貨のユニット/タイム・ユニット、通貨のユニット/データ単位*/; }
6.3.2 Node
6.3.2 ノード
Name and functionality within the network might vary for a node from protocol to protocol considered. In particular, a node might act as gateway for one protocol but not for the other. Routing policy is stored in the case of policy gateways.
プロトコルからのノードが考えられた状態で議定書を作るように、名前と機能性はネットワークの中で異なるかもしれません。 ノードは、特に、1つのプロトコルのためのゲートウェイとして機能しますが、もう片方のために機能しないかもしれません。 ルート設定方針は方針ゲートウェイの場合で保存されます。
nodeImage OBJECT CLASS
SUBCLASS of ImageCommunicationObject
/* no attributes common for all nodeImages have been
defined yet */
nodeImage OBJECT CLASS SUBCLASS、ImageCommunicationObject/*では、すべてのnodeImagesのためのどんな属性コモンも定義されるのにもかかわらずの、*/ではありません。
6.3.3 NetworkInterface
6.3.3 NetworkInterface
As with physical nodes, nodeImages have networkInterfaces (networkInterfaceImages) which describe connectivity to other network elements. NetworkInterfaceImages are only given if the protocol is establishing connections via this networkInterface.
物理的なノードのように、nodeImagesには接続性について他のネットワーク要素まで説明するnetworkInterfaces(networkInterfaceImages)があります。 プロトコルがこのnetworkInterfaceを通して関係を樹立している場合にだけ、NetworkInterfaceImagesを与えます。
networkInterfaceImage OBJECT CLASS
SUBCLASS of ImageCommunicationObject
ImageCommunicationObjectのnetworkInterfaceImageオブジェクトクラスサブクラス
Mansfield, Johannsen & Knopper [Page 13] RFC 1609 Charting Networks in the X.500 Directory March 1994
マンスフィールド、ヨハンセン、および1994年3月にX.500ディレクトリでネットワークを図にするKnopper[13ページ]RFC1609
MAY CONTAIN {
networkInterfaceAddress :: caseIgnoreStringSyntax,
/* the networkInterface address in the image
context, e.g. IP number, NSAP */
connectedNetwork :: distinguishedNameSyntax
/* pointer to networkImageObject that describes
the network this networkInterface is attached
to in terms of the protocol or application the
image indicates */
}
含むかもしれません。networkInterfaceAddress: : caseIgnoreStringSyntax、networkInterfaceがNSAP*/connectedNetwork: : 画像のコンテキスト、例えば、IP番号、このnetworkInterfaceがプロトコルかアプリケーションで取り付けられるネットワークについて説明するnetworkImageObjectへのdistinguishedNameSyntax/*指針でイメージを扱う/*は*/を示します。
7. Security Considerations
7. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
8. Authors' Addresses
8. 作者のアドレス
Glenn Mansfield AIC Systems Laboratory 6-6-3 Minami Yoshinari Aoba-ku, Sendai 989-32 Japan
研究所6-6-3南Yoshinari Aoba区、グレンマンスフィールドアイクシステム日本仙台989-32
Phone: +81 22 279-3310 EMail: glenn@aic.co.jp
以下に電話をしてください。 +81 22 279-3310 メールしてください: glenn@aic.co.jp
Thomas Johannsen Dresden University of Technology Institute of Communication Technology D-01062 Dresden Germany
コミュニケーション技術D-01062ドレスデンドイツの技術研究所のトーマスヨハンセンドレスデン大学
Phone: +49 351 463-4621 EMail: Thomas.Johannsen@ifn.et.tu-dresden.de
以下に電話をしてください。 +49 351 463-4621 メールしてください: Thomas.Johannsen@ifn.et.tu-dresden.de
Mark Knopper Merit Network, Inc. 1071 Beal Avenue Ann Arbor, MI 48109
マークKnopper長所ネットワークInc.1071ビール・Avenueアナーバー、MI 48109
EMail: mak@merit.edu
メール: mak@merit.edu
Mansfield, Johannsen & Knopper [Page 14] RFC 1609 Charting Networks in the X.500 Directory March 1994
マンスフィールド、ヨハンセン、および1994年3月にX.500ディレクトリでネットワークを図にするKnopper[14ページ]RFC1609
9. References
9. 参照
[1] Harrenstein, K., Stahl, M., and E. Feinler, "NICNAME/WHOIS", RFC
954, SRI, October 1985.
[1]HarrensteinとK.とスタール、M.とE.Feinler、「NICNAME/WHOIS」RFC954、様、1985年10月。
[2] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, USC/Information Sciences
Institute, November 1987.
[2]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、科学が設けるUSC/情報、11月1987日
[3] Johannsen, T., Mansfield, G., Kosters, M., and S. Sataluri,
"Representing IP information in the X.500 Directory", RFC 1609,
Dresden University, AIC Systems Laboratory, Network
Solutions,Inc., AT&T Bell Laboratories, March 1994.
[3] ヨハンセン、T.、マンスフィールド、G.、Kosters、M.、およびS.Sataluri、「X.500ディレクトリにおけるIP情報を表します」、RFC1609、ドレスデン大学、アイクSystems研究所、Networkソリューション、株式会社、AT&Tベル研究所(1994年3月)。
[4] Johannsen, T., and G. Mansfield, "The Soft Pages Project", OSI-DS
WG document, OSI-DS-39, Dresden University, AIC Systems
Laboratory, February 1993.
[4] ヨハンセン、T.とG.マンスフィールド、「柔らかいページプロジェクト」と、OSI-DS WGは記録します、OSI-DS-39、ドレスデン大学、アイクSystems研究所、1993年2月。
[5] CCITT Blue Book, "Data Communication Networks: Directory",
Recommendations X.500-X.521, December 1988.
[5] CCITT紳士録、「データ通信は以下をネットワークでつなぎます」。 「ディレクトリ」、推薦X.500-X.521、1988年12月。
Mansfield, Johannsen & Knopper [Page 15]
マンスフィールド、ヨハンセン、およびKnopper[15ページ]
一覧
スポンサーリンク
