Network Working Group M. Davison
Request for Comments: 2603 Cisco Systems
Category: Standards Track June 1999
ILMI-Based Server Discovery for NHRP
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate NHRP servers.
このメモは、ATM接続ホストと動的サーバのATMアドレスを決定するためのルータのための方法を提供するサーバーの検出を、ILMIベースの方法を定義する、NHRPサーバを見つけるために使用されなければなりません。
Presently, configuring a host or router to use NHRP [1] is cumbersome and error-prone since it requires at least one ATM address to be statically configured on each host or router in the network. Further, it is impossible to implement a diskless host to use NHRP since local configuration is required. ILMI-based Server Discovery, hereafter referred to as "server discovery," provides a solution to these problems.
それは静的ネットワーク内の各ホストまたはルータで設定される少なくとも一つのATMアドレスを必要とするため、現在、NHRPを使用するホストまたはルータを設定する[1]面倒でエラーが発生しやすいです。さらに、ローカル設定が必要になるので、NHRPを使用するディスクレスホストを実装することは不可能です。今後とも呼ばILMIベースのサーバーの検出、「サーバーの発見は、」これらの問題に対する解決策を提供します。
A brief overview of the Integrated Local Management Interface (ILMI) and the Service Registry MIB, as defined by the ATM Forum, are provided in this memo. The reader should consult [2] for a complete description of ILMI and this MIB, but the information contained here is sufficient for an understanding of its use to support NHRP server discovery.
統合ローカル管理インターフェイス（ILMI）とサービスレジストリMIBの概要は、ATMフォーラムによって定義されるように、このメモで提供されています。読者はILMIと、このMIBの詳細については、[2]を相談する必要がありますが、ここに含まれる情報はNHRPサーバ検出をサポートするためのその使用を理解するのに十分です。
The Integrated Local Management Interface (ILMI) [2] provides a mechanism for ATM-attached devices, such as hosts, routers, and ATM switches, to transfer management information. It is based on the Simple Network Management Protocol (SNMP), Version 1, and supports get, get-next, set and trap operations.
統合ローカル管理インターフェイス（ILMI）は[2]の管理情報を転送するために、そのようなホスト、ルータ、ATMスイッチなどのATM接続デバイスのためのメカニズムを提供します。これは、簡易ネットワーク管理プロトコル（SNMP）、バージョン1、に基づいて取得サポート、取得 - 次の、操作を設定し、トラップされます。
The ILMI specification designates the switch side of the ATM link as the 'network side' and the host/router side of the ATM link as the ' user side.' The Service Registry MIB, which is outlined in Section 3, is implmented on the network side and is queried from the user side.
ILMI仕様はとして「ネットワーク側」とATMリンクのホスト/ルータ側とATMリンクのスイッチ側を指定する「ユーザ側」。セクション3に概説されているサービス・レジストリMIBは、ネットワーク側でimplmentedされ、ユーザ側から照会されます。
Server discovery utilizes the Service Registry MIB defined by the ATM Forum in ILMI Specification Version 4.0 [2]. To support the existing framework for IP over ATM, ATM switches must support the Service Registry MIB.
サーバーの発見は、利用ILMI仕様バージョン4.0にATMフォーラムで定義されたサービスレジストリMIB [2]。 ATM上のIPのための既存のフレームワークをサポートするために、ATMスイッチは、サービスレジストリMIBをサポートしている必要があります。
A row in the service registry table [2] is defined as:
サービス・レジストリテーブルの行[2]のように定義されます。
AtmfSrvcRegEntry ::= SEQUENCE {
atmfSrvcRegPort INTEGER,
atmfSrvcRegServiceID OBJECT IDENTIFIER,
atmfSrvcRegATMAddress AtmAddress,
atmfSrvcRegAddressIndex INTEGER,
atmfSrvcRegParm1 OCTET STRING
}
The definition of each field in this structure is:
この構造体の各フィールドの定義は次のとおりです。
atmfSrvcRegPort - The ATM port number for which this entry contains management information. The value of zero may be used to indicate the ATM interface over which a management request was received.
atmfSrvcRegPort - このエントリは、管理情報が含まれているATMポート番号。ゼロの値は、管理要求を受信した上ATMインターフェイスを示すために使用されてもよいです。
atmfSrvcRegServiceID - This is the service identifier that uniquely identifies the type of service at the address provided in the table. (See Section 3.2 for NHRP OID.)
atmfSrvcRegServiceID - これは、一意の表に提供されたアドレスにサービスの種類を識別するサービス識別子です。 （NHRP OIDについては、セクション3.2を参照してください。）
atmfSrvcRegATMAddress - This is the full address of the service. The ATM client will use this address to establish a connection with the service.
atmfSrvcRegATMAddress - これは、サービスの完全なアドレスです。 ATMクライアントは、サービスとの接続を確立するために、このアドレスを使用します。
atmfSrvcRegAddressIndex - An arbitrary integer to differentiate multiple rows containing different ATM addresses for the same service on the same port.
atmfSrvcRegAddressIndex - 同じポート上で同じサービスの異なるATMアドレスを含む複数の行を区別するための任意の整数。
atmfSrvcRegParm1 - An octet string whose size and meaning is determined by the value of atmfSrvcRegServiceID.
atmfSrvcRegParm1 - その大きさと意味atmfSrvcRegServiceIDの値によって決定されたオクテット文字列。
The service registry table is indexed by atmfSrvcRegPort, atmfSrvcRegServiceID and atmfSrvcRegAddressIndex.
サービスレジストリテーブルはatmfSrvcRegPort、atmfSrvcRegServiceIDとatmfSrvcRegAddressIndexによってインデックスされます。
A generic parameter string is defined in the service registry table, thus allowing protocol-specific parameters to be specified. To be consistent with [1], the parameter string for NHRP shall be:
ジェネリックパラメータ文字列は、このように、プロトコル固有のパラメータを指定することを可能にする、サービス・レジストリテーブルに定義されています。 [1]と一致するように、NHRPのためのパラメータ文字列をしなければなりません。
ar$pro.type 16 bits Protocol type
ar$pro.snap 40 bits Optional extension to protocol type
ar$plen 8 bits Length of protocol address
ar$addr plen octets Network address
ar$mask plen octets Network mask
Where
どこ
ar$pro.type - See [1]. (IPv4 is 0x0800, IPv6 is 0x86DD)
ARの$のpro.type - [1]を参照してください。 （IPv4のは0x0800であり、IPv6は0x86DDあります）
ar$pro.snap - See [1]. (IPv4 and IPv6 are 0)
ARの$のpro.snap - [1]を参照してください。 （IPv4とIPv6は0です）
ar$plen - Length of the protocol address. (IPv4 is 4, IPv6 is 16)
PLEN $ AR - プロトコルアドレスの長さ。 （IPv4がIPv6は16であり、4です）
ar$addr - Network address represented in network byte order
ARの$ addrの - ネットワークアドレスは、ネットワークバイト順で表現します
ar$mask - Network mask represented in network byte order
ARの$マスク - ネットワークバイトオーダーに代表されるネットワークマスク
This OID, assigned in the ATM Forum Service Registry MIB, names ATMARP within the context of server discovery.
ATMフォーラムのサービスレジストリMIBに割り当てられたこのOIDは、名前がサーバー発見の文脈の中でATMARP。
atmfSrvcRegNHRP OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.353.1.5.5 }
It does not name any managed objects, rather is used to locate appropriate rows in the service registery table.
むしろ、サービスregisteryテーブルに適切な行を検索するために使用され、任意の管理対象オブジェクトに名前を付けていません。
An Next Hop Client NHC) will access the service registry table via ILMI using the SNMP GetNext operator to "sweep" (SNMP parlance for a linear search) beginning with {Port = 0, ServiceID = <see Section 3.2>, Index = 0} while holding the port number and the serviceID constant. (Port number 0 is used within ILMI to indicate "this port.")
ネクストホップクライアントNHC）は{ポート= 0、サービスID = <セクション3.2を参照してください>、インデックス= 0}から始まる「スイープ」（線形検索のためのSNMPの用語）にSNMP GetNextの演算子を使用してILMIを介してサービスのレジストリテーブルにアクセスしますポート番号とサービスIDを一定に保持しながら。 （ポート番号0を示すためにILMI内で使用される「このポートを。」）
An NHC with no local configuration, such as a diskless workstation, must use the row with the lowest index value if multiple Next Hop Server (NHS), possibly for multiple networks, are listed.
複数のネクストホップサーバ（NHS）は、おそらく複数のネットワークのために、記載されている場合NHCはローカル構成で、そのようなディスクレス・ワークステーションとして、最も低いインデックス値を持つ行を使用しなければなりません。
NHC that have local IP configuration must use a row that has the appropriate IP address. For example, consider the case where an IP router has 3 logical interfaces defined on a single physical interface with IP addresses 1.0.0.1/8, 128.10.0.1/16 and 171.69.150.226/24. The router will sweep the service registry table looking for rows that have atmfSrvcRegParm1 values as shown below:
適切なIPアドレスを持つ行を使用する必要がありますローカルIPの構成を有しているNHC。例えば、IPルータは、IPが1.0.0.1/8、128.10.0.1/16と171.69.150.226/24のアドレスを持つ単一の物理インターフェイス上で定義された3つの論理インタフェースを有している場合を考えます。ルータは、以下に示すようにatmfSrvcRegParm1値を持つ行を探しているサービスのレジストリテーブルをスイープします。
Net number/mask atmfSrvcRegParm1
---------------- --------------------------------------------------
1.0.0.0/8 08 00 00 00 00 00 00 04 01 00 00 00 ff 00 00 00
128.10.0.0/16 08 00 00 00 00 00 00 04 80 0a 00 00 ff ff 00 00
171.69.150.0/24 08 00 00 00 00 00 00 04 ab 45 96 00 ff ff ff 00
When the correct atmfSrvcRegParm1 values are located, the router may then establish an SVC to the selected NHS and perform the appropriate protocol operations.
正しいatmfSrvcRegParm1値が存在する場合、ルータは、選択されたNHSにSVCを確立し、適切なプロトコル動作を実行することができます。
Redundant NHS are supported with multiple rows in the service registry table. This list of NHS is ordered with the primary NHS having the lowest index value. The NHC must attempt to utilize the primary NHS before utilizing a secondary NHS. Administrators must ensure that the listed NHS are synchronized.
冗長NHSは、サービスレジストリテーブルの複数の行でサポートされています。 NHSのこのリストは、最も低いインデックス値を有する一次NHSと命じています。 NHCは、二次NHSを利用する前に、プライマリNHSを利用することを試みなければなりません。管理者は、リストされたNHSが同期していることを確認する必要があります。
A Next Hop Server (NHS) shall be locally configured. The NHS may retrieve the NHRP service registry data to validate the results. If an incorrect row is retrieved the error may be flagged in a locally significant way.
ネクストホップサーバ（NHS）は、ローカルに設定されなければなりません。 NHSは、結果を検証するためにNHRPサービスレジストリデータを検索することができます。誤った行が取得されると、エラーがローカルで有効な方法でフラグを立てることができます。
An augmented version PNNI ("PNNI Augmented Routing," or PAR) [3] has been developed by the ATM Forum. PAR can distribute data such as NHS addresses. Further, the ATM Forum is developing a proxy mechanism for PAR (Proxy PAR) that would allow a UNI-attached host or router to access PAR data without a full PAR implementation.
拡張バージョンPNNI（「PNNI増補ルーティング」またはPAR）は、[3] ATMフォーラムによって開発されました。 PARは、NHSアドレスなどのデータを配布することができます。さらに、ATMフォーラムは、UNI-接続されたホストまたはルータがフルPAR実装せずにPARデータにアクセスできるようになるPAR（プロキシPAR）のプロキシメカニズムを開発しています。
These mechanisms offer a promising way to manage the service registry tables maintained on each switch in an ATM network, yet would not require changes to the mechanism defined in this memo. Hosts and routers can continue to utilize ILMI-based or Proxy PAR-based server discovery and network administrators could manage the service registry data with local configuration or via PAR and Proxy PAR.
これらのメカニズムは、ATMネットワーク内の各スイッチで維持され、サービスのレジストリテーブルを管理するための有望な方法を提供し、まだこのメモで定義されたメカニズムへの変更を必要としないであろう。ホストとルータが利用し続けることができILMIベースまたはプロキシPARベースのサーバーの検出およびネットワーク管理者は、ローカル設定またはPARとプロキシPARを介してサービスレジストリデータを管理することができます。
The server discovery mechanism is built on the ILMI managment framework and the security embodied in that framework. Access, to user- or network-side information is controlled by MIB design rather than protocol security mechanisms.
サーバー発見メカニズムは、ILMIの経営管理論の枠組みと、その枠組みの中で具現化セキュリティ上に構築されています。アクセスは、USER-またはネットワーク側の情報は、MIBの設計ではなく、プロトコルのセキュリティメカニズムによって制御されます。
The service registery MIB, the table containing information for server discovery, is defined in [2] with read-only access. This means that any user-side device may query the service registry, but may not modify the service registry via ILMI. Instead, the sevice registry table must be modified via local configuration on the ATM switch.
サービスregistery MIB、サーバ発見のための情報を含むテーブルは、読み取り専用アクセスと[2]で定義されています。これは、任意のユーザ側のデバイスは、サービスレジストリを問い合わせることができることを意味するが、ILMIを介してサービスレジストリを変更することはできません。代わりに、流通サービスのレジストリテーブルには、ATMスイッチ上のローカル設定によって変更する必要があります。
References
リファレンス
[1] Luciani, J., et al., "NBMA Next Hop Resolution Protocol", RFC 2332, April 1998.
[1]ルチアーニ、J.ら、 "NBMAネクストホップ解決プロトコル"、RFC 2332、1998年4月。
[2] ATM Forum, "Integrated Local Management Interface (ILMI) Specification Version 4.0," af-ilmi-0065.000, September 1996.
[2] ATMフォーラム、 "統合ローカル管理インターフェイス（ILMI）仕様バージョン4.0、" AF-ILMI-0065.000、1996年9月。
[3] ATM Forum, "PNNI Augmented Routing (PAR) Version 1.0," af-ra-0104, January 1999.
[三] ATMフォーラムは、オフ-0104、1999年1月に "おばさんは、バージョン1.0、（ミルク）ルーティングagmented"。
Author's Address
著者のアドレス
Mike Davison Cisco Systems 170 West Tasman Drive San Jose, California 95134
マイク・デイヴィソンシスコシステムズ170西タスマン・ドライブサンノゼ、カリフォルニア95134
Phone: (408) 526-4000 EMail: mike.davison@cisco.com
電話：（408）526-4000 Eメール：mike.davison@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。