Movatterモバイル変換

Network Working Group                                       M. DavisonRequest for Comments: 2601                               Cisco SystemsCategory: Standards Track                                    June 1999ILMI-Based Server Discovery for ATMARPStatus 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.Copyright Notice   Copyright (C) The Internet Society (1999).  All Rights Reserved.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 ATMARP servers.1. Introduction   Presently, configuring a host or router to use ATMARP [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 ATMARP   since local configuration is required.  ILMI-based Server Discovery,   hereafter referred to as "server discovery," provides a solution to   these problems.   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 ATMARP   server discovery.2. Integrated Local Management Interface   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 supportsDavison                     Standards Track                     [Page 1]

RFC 2601         ILMI-Based Server Discovery for ATMARP        June 1999   get, get-next, set and trap operations.   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 inSection 3,   is implmented on the network side and is queried from the user side.3. ILMI 4.0 Service Registry MIB   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.   A row in the service registry table [2] 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 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.      atmfSrvcRegServiceID - This is the service identifier that          uniquely identifies the type of service at the address          provided in the table. (SeeSection 3.2 for ATMARP OID.)      atmfSrvcRegATMAddress - This is the full address of the service.          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.Davison                     Standards Track                     [Page 2]

RFC 2601         ILMI-Based Server Discovery for ATMARP        June 19993.1 Service Parameter String   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 ATMARP shall be:       ar$pro   16    bits     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  - see Assigned Numbers for protocol type number for                protocol using ATMARP. (IPv4 is 0x0800, IPv6 is 0x86DD)      ar$plen - Length of the protocol address. (IPv4 is 4, IPv6 is 16)      ar$addr - Network address represented in network byte order      ar$mask - Network mask represented in network byte order3.2 Service Object Identifier   This OID, assigned in the ATM Forum Service Registry MIB, names   ATMARP within the context of server discovery.    atmfSrvcRegATMARP  OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.353.1.5.3 }   It does not name any managed objects, rather is used to locate   appropriate rows in the service registery table.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 = <seeSection3.2>, 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   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 physicalDavison                     Standards Track                     [Page 3]

RFC 2601         ILMI-Based Server Discovery for ATMARP        June 1999   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:       Network number/mask  atmfSrvcRegParm1       -------------------- --------------------------------------       1.0.0.0/8            08 00   04   01 00 00 00   ff 00 00 00       128.10.0.0/16        08 00   04   80 0a 00 00   ff ff 00 00       171.69.150.0/24      08 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 server and perform the   appropriate protocol operations.   Redundant 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. Administrators must ensure that   the listed ATMARP servers are synchronized.5. ATMARP Server Behavior   An ATMARP server shall be locally configured. The ATMARP server may   retrieve the ATMARP service registry data to validate the results. If   an incorrect row is retrieved 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) [3] has   been developed by the ATM Forum. PAR can distribute data such as   ATMARP server 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.  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.Davison                     Standards Track                     [Page 4]

RFC 2601         ILMI-Based Server Discovery for ATMARP        June 19997. Security Considerations   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.   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.References   [1]  Laubach, M. and J. Halpern, "Classical IP and ARP over ATM,"RFC2225, April 1998.   [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  Address   Mike Davison   Cisco Systems   170 West Tasman Drive   San Jose, California 95134   Phone: (408) 526-4000   EMail: mike.davison@cisco.comDavison                     Standards Track                     [Page 5]

RFC 2601         ILMI-Based Server Discovery for ATMARP        June 1999Full Copyright Statement   Copyright (C) The Internet Society (1999).  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.   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.Davison                     Standards Track                     [Page 6]