RFC 2601

ILMI-Based Server Discovery for ATMARP

📅 published June 1999, from ietf

RFC 2601: ILMI-Based Server Discovery for ATMARP 💖

  • Author: M. Davison, Cisco Systems 🎀
  • Category: Standards Track ✨
  • Date: June 1999 📅
  • Obsoletes or updates: nothing is listed in the title block 🦋

Status of this Memo 🧚

This document is an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 💅.

Copyright (C) The Internet Society (1999). All Rights Reserved.

Abstract 🌸

This memo explains how ILMI-based Server Discovery works. It's a way for ATM-attached hosts and routers to dynamically figure out the ATM addresses of servers, and it SHALL be used to locate ATMARP servers 🔥.

1. Introduction 🎀

Okay so, setting up a host or router to use ATMARP [1] is cumbersome and error-prone right now 😭. You have to statically configure at least one ATM address on every host or router in the network. It's also impossible to make a diskless host use ATMARP, because local configuration is REQUIRED. ILMI-based Server Discovery, which I'll call "server discovery" from here on, fixes all of that 💖.

This memo gives a quick overview of the Integrated Local Management Interface (ILMI) and the Service Registry MIB, which the ATM Forum defined. You can check [2] for the full story on ILMI and this MIB, but what's in here is enough to understand how it helps with ATMARP server discovery ✨.

2. Integrated Local Management Interface 🦋

The Integrated Local Management Interface (ILMI) [2] gives ATM-attached devices, like hosts, routers, and ATM switches, a way to pass management information back and forth. It's built on the Simple Network Management Protocol (SNMP), Version 1, and it supports get, get-next, set and trap operations 🍓.

The ILMI spec calls the switch side of the ATM link the 'network side', and the host or router side the 'user side.' The Service Registry MIB, which Section 3 covers, lives on the network side and gets queried from the user side 👑.

3. ILMI 4.0 Service Registry MIB 💜

Server discovery uses the Service Registry MIB that the ATM Forum defined in ILMI Specification Version 4.0 [2]. To keep the existing IP over ATM setup working, ATM switches MUST support the Service Registry MIB 🫶.

A row in the service registry table [2] is defined like this:

AtmfSrvcRegEntry ::= SEQUENCE {
    atmfSrvcRegPort          INTEGER,
    atmfSrvcRegServiceID     OBJECT IDENTIFIER,
    atmfSrvcRegATMAddress    AtmAddress,
    atmfSrvcRegAddressIndex  INTEGER,
    atmfSrvcRegParm1         OCTET STRING
}

Here's what each field means 🧚:

  • atmfSrvcRegPort: the ATM port number this entry has management info for. A value of zero MAY be used to mean the ATM interface where the management request came in.
  • atmfSrvcRegServiceID: the service identifier that uniquely tells you what type of service lives at the address in the table. (Check Section 3.2 for the ATMARP OID.)
  • atmfSrvcRegATMAddress: the full address of the service. The ATM client uses this address to set up a connection with the service.
  • atmfSrvcRegAddressIndex: an arbitrary integer that tells apart multiple rows with different ATM addresses for the same service on the same port.
  • atmfSrvcRegParm1: an octet string whose size and meaning depend on the value of atmfSrvcRegServiceID.

The service registry table is indexed by atmfSrvcRegPort, atmfSrvcRegServiceID and atmfSrvcRegAddressIndex 🌷.

3.1 Service Parameter String ✨

The service registry table has a generic parameter string, so you can specify protocol-specific parameters. To stay 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: check Assigned Numbers for the protocol type number of the protocol using ATMARP. (IPv4 is 0x0800, IPv6 is 0x86DD.)
  • ar$plen: the length of the protocol address. (IPv4 is 4, IPv6 is 16.)
  • ar$addr: the network address, in network byte order 🍓.
  • ar$mask: the network mask, in network byte order 🍓.

3.2 Service Object Identifier 🦋

This OID was assigned in the ATM Forum Service Registry MIB, and it names ATMARP within the context of server discovery 🔥.

atmfSrvcRegATMARP  OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.353.1.5.3 }

It doesn't name any managed objects. Instead, it's used to find the right rows in the service registry table 💅.

4. ATMARP Client Behavior 💖

An ATMARP client uses ILMI to read the service registry table. It uses the SNMP GetNext operator to "sweep" (SNMP lingo for a linear search), starting at {Port = 0, ServiceID = <see Section 3.2>, Index = 0}, while the port number and serviceID stay constant. (Port number 0 is what ILMI uses to mean "this port.") 🧚

An ATMARP client with no local configuration, like a diskless workstation, MUST use the row with the lowest index value when several ATMARP servers are listed, possibly for multiple networks 🫶.

ATMARP clients that have local IP configuration MUST use a row with the matching IP address. Let's say an IP router has 3 logical interfaces on one physical interface, with IP addresses 1.0.0.1/8, 128.10.0.1/16 and 171.69.150.226/24. The router sweeps the service registry table looking for rows with these atmfSrvcRegParm1 values 👑:

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

Once the right atmfSrvcRegParm1 values turn up, the router MAY then establish an SVC to the chosen server and do the usual protocol operations ✨.

Redundant ATMARP servers are handled with multiple rows in the service registry table. The list of ATMARP servers is ordered, and the primary ATMARP server has the lowest index value. The ATMARP client MUST try the primary ATMARP server before it tries a secondary one. 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 check its results. If it retrieves an incorrect row, the error MAY be flagged in a locally significant way 🫶.

6. Relationship with PNNI Augmented Routing 🌈

The ATM Forum made an augmented version of PNNI, called "PNNI Augmented Routing," or PAR [3]. PAR can distribute data such as ATMARP server addresses. The ATM Forum is also building a proxy mechanism for PAR, called Proxy PAR, which would let a UNI-attached host or router access PAR data without a full PAR implementation. Both mechanisms are a promising way to manage the service registry tables kept on each switch in an ATM network, and neither would need changes to the mechanism defined in this memo 💜. Hosts and routers can keep using ILMI-based or Proxy PAR-based server discovery, and network administrators can manage the service registry data with local configuration or through PAR and Proxy PAR 🦋.

7. Security Considerations 💀

Server discovery is built on the ILMI management framework, and it relies on the security built into that framework. Access to user-side or network-side information is controlled by MIB design, not by protocol security mechanisms 🔥.

The service registry MIB, which holds the server discovery information, is defined in [2] with read-only access. That means any user-side device MAY query the service registry, but it may not modify the service registry through ILMI. Instead, the service registry table MUST be modified through local configuration on the ATM switch 🚨.

References 📚

  • [1] Laubach, M. and J. Halpern, "Classical IP and ARP over ATM," RFC 2225, 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.com

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it MAY be copied and furnished to others. Derivative works that comment on or otherwise explain it, or help with its implementation, MAY be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, as long as 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 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 in it are 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 ✨.

📦 where this page comes from