As per Relevance of the word registry, we have this rfc below:
Network Working Group M.
Request for Comments: 2602 Cisco
Category: Standards Track June 1999
ILMI-Based Server Discovery for
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This memo defines how ILMI-based Server Discovery, which provides
method for ATM-attached hosts and routers to dynamically
the ATM addresses of servers, shall be used to locate MARS servers
1.
Presently, configuring a host or router to use MARS [1] is
and error-prone since it requires at least one ATM address to
statically configured on each host or router in the network
Further, it is impossible to implement a diskless host to use
since local configuration is required. ILMI-based Server Discovery
hereafter referred to as "server discovery," provides a solution
these problems
A brief overview of the Integrated Local Management Interface (ILMI
and the Service Registry MIB, as defined by the ATM Forum,
provided in this memo. The reader should consult [2] for a
description of ILMI and this MIB, but the information contained
is sufficient for an understanding of its use to support MARS
discovery
Davison Standards Track [Page 1]
RFC 2602 ILMI-Based Server Discovery for MARS June 1999
2. Integrated Local Management
The Integrated Local Management Interface (ILMI) [2] provides
mechanism for ATM-attached devices, such as hosts, routers, and
switches, to transfer management information. It is based on
Simple Network Management Protocol (SNMP), Version 1, and
get, get-next, set and trap operations
The ILMI specification designates the switch side of the ATM link
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
3. ILMI 4.0 Service Registry
Server discovery utilizes the Service Registry MIB defined by the
Forum in ILMI Specification Version 4.0 [2]. To support the
framework for IP over ATM, as embodied by ATMARP and MARS,
switches must support the Service Registry MIB
A row in the service registry table [2] is defined as
AtmfSrvcRegEntry ::= SEQUENCE {
atmfSrvcRegPort INTEGER
atmfSrvcRegServiceID OBJECT IDENTIFIER
atmfSrvcRegATMAddress AtmAddress
atmfSrvcRegAddressIndex INTEGER
atmfSrvcRegParm1 OCTET
}
The definition of each field in this structure is
atmfSrvcRegPort - The ATM port number for which this
contains management information. The value of zero may be
to indicate the ATM interface over which a management
was received
atmfSrvcRegServiceID - This is the service identifier
uniquely identifies the type of service at the
provided in the table. (See Section 3.2 for MARS OID.)
atmfSrvcRegATMAddress - This is the full address of the service
The ATM client will use this address to establish a
with the service
atmfSrvcRegAddressIndex - An arbitrary integer to
multiple rows containing different ATM addresses for the
service on the same port
Davison Standards Track [Page 2]
RFC 2602 ILMI-Based Server Discovery for MARS June 1999
atmfSrvcRegParm1 - An octet string whose size and meaning
determined by the value of atmfSrvcRegServiceID
The service registry table is indexed by atmfSrvcRegPort
atmfSrvcRegServiceID and atmfSrvcRegAddressIndex
3.1 Service Parameter
A generic parameter string is defined in the service registry table
thus allowing protocol-specific parameters to be specified. To
consistent with [1], the parameter string for MARS shall be
mar$pro.type 16 bits Protocol
mar$pro.snap 40 bits Optional extension to protocol
mar$plen 8 bits Length of protocol
mar$addr plen octets Network
mar$mask plen octets Network
mar$pro.type - See [1]. (IPv4 is 0x0800, IPv6 is 0x86DD
mar$pro.snap - See [1]. (IPv4 and IPv6 are 0)
mar$plen - Length of the protocol address
(IPv4 is 4, IPv6 is 16)
mar$addr - Network address represented in network
mar$mask - Network mask represented in network byte
3.2 Service Object
This OID, assigned in the ATM Forum Service Registry MIB, names
within the context of server discovery
atmfSrvcRegMARS OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.353.1.5.4 }
It does not name any managed objects, rather is used to
appropriate rows in the service registery table
4. MARS Client
A MARS client will access the service registry table via ILMI
the SNMP GetNext operator to "sweep" (SNMP parlance for a
search) beginning with {Port = 0, ServiceID = ,
Index = 0} while holding the port number and the serviceID constant
Davison Standards Track [Page 3]
RFC 2602 ILMI-Based Server Discovery for MARS June 1999
(Port number 0 is used within ILMI to indicate "this port.")
An MARS client with no local configuration, such as a
workstation, must use the row with the lowest index value if
MARS servers, possibly for multiple networks, are listed
MARS clients that have local IP configuration must use a row that
the appropriate IP address. For example, consider the case where
IP router has 3 logical interfaces defined on a single
interface with IP addresses 1.0.0.1/8, 128.10.0.1/16
171.69.150.226/24. The router will sweep the service registry
looking for rows that have atmfSrvcRegParm1 values as shown below
Net number/mask atmfSrvcRegParm
---------------- --------------------------------------------------
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
then establish an SVC to the selected server and perform
appropriate protocol operations
Redundant MARS servers are supported with multiple rows in
service registry table. This list of MARS servers is ordered with
primary MARS server having the lowest index value. The MARS
must attempt to utilize the primary MARS server before utilizing
secondary MARS server. Administrators must ensure that the
MARS servers are synchronized
5. MARS Server
An MARS server shall be locally configured. The MARS server
retrieve the MARS service registry data to validate the results.
an incorrect row is retrieved the error may be flagged in a
significant way
Davison Standards Track [Page 4]
RFC 2602 ILMI-Based Server Discovery for MARS June 1999
6. Relationship with PNNI Augmented
An augmented version PNNI ("PNNI Augmented Routing," or PAR) [3]
been developed by the ATM Forum. PAR can distribute data such as
server addresses. Further, the ATM Forum is developing a
mechanism for PAR (Proxy PAR) that would allow a UNI-attached host
router to access PAR data without a full PAR implementation
These mechanisms offer a promising way to manage the service
tables maintained on each switch in an ATM network, yet would
require changes to the mechanism defined in this memo. Hosts
routers can continue to utilize ILMI-based or Proxy PAR-based
discovery and network administrators could manage the
registry data with local configuration or via PAR and Proxy PAR
7. Security
The server discovery mechanism is built on the ILMI
framework and the security embodied in that framework. Access,
user- or network-side information is controlled by MIB design
than protocol security mechanisms
The service registery MIB, the table containing information
server discovery, is defined in [2] with read-only access. This
that any user-side device may query the service registry, but may
modify the service registry via ILMI. Instead, the sevice
table must be modified via local configuration on the ATM switch
[1] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based
Networks", RFC 2022, November 1996.
[2] ATM Forum, "Integrated Local Management Interface (ILMI
Specification Version 4.0," af-ilmi-0065.000, September 1996.
[3] ATM Forum, "PNNI Augmented Routing (PAR) Version 1.0," af-ra
0104, January 1999.
Author's
Mike
Cisco
170 West Tasman
San Jose, California 95134
Phone: (408) 526-4000
EMail: mike.davison@cisco.
Davison Standards Track [Page 5]
RFC 2602 ILMI-Based Server Discovery for MARS June 1999
Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Davison Standards Track [Page 6]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
