Internet-Draft Mike Davison Cisco Systems July 10, 1997 ILMI-Based Server Discovery for ATMARP Status of this Memo This document was submitted to the IETF Internetworking Over NBMA Working Group (ion). Publication of this document does not imply acceptance by the Internetworking Over NBMA Working Group of any ideas expressed within. Comments should be submitted to the ion@nexen.com mailing list. Distribution of this memo is unlimited. This memo is an internet draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". Please check the lid-abstracts.txt listing contained in the internet-drafts shadow directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.src.com, or munnari.oz.au to learn the current status of any Internet Draft. Abstract This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM address of servers, shall be used to locate ATMARP servers. Davison Expires January 10, 1998 [Page 1] Internet Draft July 10, 1997 1. Introduction Presently, configuring a host or router to use ATMARP [1,2] is cumbersome and error-prone since it requires at least one ATM addresses to be statically configured on each host or router in the network. Further, it is impossible to implement a diskless host to use ATMARP since local configuration is required. ILMI-based Server Discovery, hereafter refered to as "server discovery," provides a solution to these problems. A brief overview of the Service Registry MIB, as defined by the ATM Forum, is provided in this memo. The reader should consult [3] for a complete description of this MIB, but the information contained here is sufficient for an understanding of its use to support ATMARP server discovery. 2. ILMI 4.0 Service Registry MIB Server discovery utilizes the Service Registry MIB defined by the ATM Forum in ILMI Specification Version 4.0 [3]. To support the existing framework for IP over ATM, as embodied by ATMARP and MARS, ATM switches must support the Service Registry MIB. A row in the service registry table [3] is defined as: 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 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. atmfSrvcRegServiceID - This is the service identifier which uniquely identifies the type of service at the address provided in the table. (See Appendix for ATMARP OID.) atmfSrvcRegATMAddress - This is the full address of the service. Davison Expires January 10, 1998 [Page 2] Internet Draft July 10, 1997 The ATM client will use this address to establish a connection with the service. atmfSrvcRegAddressIndex - An arbitrary integer to differentiate multiple rows containing different ATM addresses for the same service on the same port. atmfSrvcRegParm1 - An octet string whose size and meaning is determined by the value of atmfSrvcRegServiceID. The service registry table is indexed by atmfSrvcRegPort, atmfSrvcRegServiceID and atmfSrvcRegAddressIndex. 3. Service Parameter String A generic parameter string is defined in the service registry table, thus allowing protocol-specific parameters to be specified. To be consistant with [1,2], the parameter string for ATMARP shall be: ar$pro 16 bits Protocol type ar$plen 8 bits Length of protocol address (a) ar$addr a octets Network address ar$mask a octets Network mask Where ar$pro - see Assigned Numbers for protocol type number fo protocol using ATMARP. (IP is 0x0800) ar$plen - Length of the protocol address. (IP is 4) ar$addr - Network address represented in network byte order ar$mask - Network mask represented in network byte order 4. ATMARP Client Behavior An ATMARP client 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 = , Index = 0} while holding the port number and the serviceID constant. (Port number 0 is used within ILMI to indicate "this port.") An ATMARP client with no local configuration, such as a diskless Davison Expires January 10, 1998 [Page 3] Internet Draft July 10, 1997 workstation, must use the row with the lowest index value if multiple ATMARP servers, possibly for multiple networks, are listed. ATMARP clients 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 a rows that have atmfSrvcRegParm1 values as shown below: Network number/mask atmfSrvcRegParm1 ---------------------- ---------------------------------- 1.0.0.1/8 8.0. 1.0.0.0. 255.0.0.0 128.10.0.1/16 8.0. 128.10.0.0. 255.255.0.0 171.69.150.1/24 8.0. 171.69.150.0. 255.255.255.0 When the correct atmfSrvcRegParm1 values are located, the router may then establish an SVC to the selected server and perform the appropriate protocol operations. Rudundant ATMARP servers are supported with multiple rows in the service registry table. This list of ATMARP servers is ordered with the primary ATMARP server having the lowest index value. The ATMARP client must attempt to utilize the primary ATMARP server before utilizing a secondary ATMARP server. Adminstrators must ensure that the listed ATMARP servers are sychronized via [4]. 5. ATMARP Server Behavior An ATMARP server shall be locally configured. The ATMARP server may retreive the ATMARP service registry data to validate the results. If an incorrect row is retreived the error may be flagged in a locally significant way. 6. Relationship with PNNI Augmented Routing An augmented version PNNI ("PNNI Augmented Routing," or PAR) [5] is being developed by the ATM Forum. PAR could potentially distribute data such as ATMARP server addresses. Further, the ATM Forum developing a proxy mechanism for PAR (Proxy PAR) [6] that would allow a UNI-attached host or router to access PAR data without a full PAR implmentation. These mechanisms offer a promising way to manage the service registry Davison Expires January 10, 1998 [Page 4] Internet Draft July 10, 1997 tables maintained on each switch in an ATM network, yet would not require changes to the mechanism defined in this memo. Hosts and routers will continue to utilize ILMI-based server discovery and network administrators could manage the service registry data with local configuration or via PAR and Proxy PAR. 7. Security Considerations Security considerations are not discussed in this memo. Appendix - ATMARP Server Discovery MIB SERVER-DISCOVERY-ATMARP DEFINITIONS ::= BEGIN -- -- This OID names ATMARP within the context of server discovery. -- It does not name any managed objects. -- serverDiscoveryATMARP OBJECT IDENTIFIER ::= END References [1] Laubach, M., "Classical IP and ARP over ATM," RFC 1577, Hewlett-Packard Laboratories, December 1993. [2] Laubach, M. Halpern, J., "Classical IP and ARP over ATM," draft-ietf-ion-classic2-02.txt, (update to RFC 1577), March 1997. [3] ATM Forum, "Integrated Local Management Interface (ILMI) Specification Version 4.0," af-ilmi-0065.000, September, 1996. [4] Luciani, J., and Fox, B., "A distributed ATMARP Service Using SCSP," , April, 1997. [5] Callon, R., et al., "An Overview of PNNI Augmented Routing," ATM-Forum 96-0354, April, 1996. [6] Przygienda, T., and Droz, P., "Proxy PAR," ATM-Forum 97-0495, July, 1997. Davison Expires January 10, 1998 [Page 5] Internet Draft July 10, 1997 Author's Address Mike Davison Cisco Systems 170 West Tasman Drive San Jose, California 95134 Phone: (408) 526-4000 EMail: mike.davison@cisco.com Davison Expires January 10, 1998 [Page 6]