ILMI-Based Server Discovery for MARS
Extracted elements (15)
ILMI-based server discovery was introduced because static configuration of MARS server ATM addresses on each host/router is cumbersome, error-prone, and prevents diskless hosts from using MARS. Dynamic discovery via ILMI eliminates the need for local configuration.
The service registry MIB is defined with read-only access rather than requiring protocol-level write authentication, relying instead on MIB design to control access. This means the table can only be modified via local configuration on the ATM switch, simplifying the security model.
PNNI Augmented Routing (PAR) and Proxy PAR can distribute MARS server addresses and manage service registry tables across ATM switches, but would not require changes to the ILMI-based discovery mechanism defined in this memo. Hosts can continue using ILMI-based or Proxy PAR-based discovery interchangeably.
The MARS parameter string format in atmfSrvcRegParm1 is defined to be consistent with RFC 2022 (MARS). IPv4 uses pro.type=0x0800, pro.snap=0, plen=4; IPv6 uses pro.type=0x86DD, pro.snap=0, plen=16.
A MARS client with no local configuration (e.g., a diskless workstation) must use the row with the lowest index value if multiple MARS servers are listed in the service registry table.
A MARS server shall be locally configured. The MARS server may retrieve the MARS service registry data to validate the results, and if an incorrect row is retrieved the error may be flagged in a locally significant way.
Administrators must ensure that listed redundant MARS servers are synchronized.
ATM switches must support the Service Registry MIB to support the existing framework for IP over ATM as embodied by ATMARP and MARS.
MARS clients that have local IP configuration must use a row that has the appropriate IP address matching their network address and mask in atmfSrvcRegParm1.
The MARS client must attempt to utilize the primary MARS server (lowest index value) before utilizing a secondary MARS server when redundant servers are listed.
A MARS client sweeps the service registry table via ILMI using SNMP GetNext, beginning with {Port=0, ServiceID=atmfSrvcRegMARS, Index=0} while holding port number and serviceID constant. Port 0 indicates the interface over which the management request was received.
The ILMI Service Registry MIB defines the AtmfSrvcRegEntry table with fields: atmfSrvcRegPort (ATM port number), atmfSrvcRegServiceID (service OID), atmfSrvcRegATMAddress (full ATM address), atmfSrvcRegAddressIndex (integer differentiating multiple rows), and atmfSrvcRegParm1 (protocol-specific octet string). The table is indexed by port, serviceID, and addressIndex.
The MARS service OID is atmfSrvcRegMARS ::= { 1.3.6.1.4.1.353.1.5.4 }, assigned in the ATM Forum Service Registry MIB. It is used to locate MARS rows in the service registry table, not to name managed objects.
Security for server discovery relies entirely on the ILMI management framework; there are no additional protocol security mechanisms. The service registry MIB is defined with read-only access, so user-side devices may query but not modify it via ILMI — modifications require local configuration on the ATM switch.
The MARS parameter string in atmfSrvcRegParm1 encodes: mar$pro.type (16 bits, protocol type), mar$pro.snap (40 bits, optional protocol type extension), mar$plen (8 bits, protocol address length), mar$addr (plen octets, network address in network byte order), and mar$mask (plen octets, network mask in network byte order).