ILMI-Based Server Discovery for NHRP
Extracted elements (14)
Access to the service registry is controlled by MIB design (read-only access) rather than protocol security mechanisms. This means any user-side device can query the registry but cannot alter NHS addresses, relying on administrative control of ATM switch configuration as the security boundary.
ILMI-based Server Discovery was introduced to eliminate the need for static ATM address configuration on each NHRP host or router, and to enable diskless hosts (which cannot have local configuration) to use NHRP. This solves the cumbersome and error-prone nature of manual NHRP configuration.
ATM switches must support the Service Registry MIB (ATM Forum ILMI 4.0) to support the existing framework for IP over ATM and enable NHRP server discovery by attached hosts and routers.
PAR (PNNI Augmented Routing) and Proxy PAR offer a mechanism for distributing NHS addresses and managing service registry tables across ATM switches without requiring changes to the ILMI-based discovery mechanism defined in this memo. Hosts can continue to use ILMI-based discovery regardless of how the registry data is managed.
A Next Hop Server (NHS) shall be locally configured. The NHS may retrieve the NHRP service registry data to validate the results; if an incorrect row is retrieved, the error may be flagged in a locally significant way.
An NHC with no local configuration (e.g., a diskless workstation) must use the service registry row with the lowest index value when multiple NHS entries are listed, potentially covering multiple networks.
NHCs that have local IP configuration must use a service registry row that has the appropriate IP address in atmfSrvcRegParm1, matching the network address and mask of their logical interface.
The NHC must attempt to utilize the primary NHS (lowest index value) before utilizing a secondary NHS. Administrators must ensure that the listed NHS are synchronized.
The NHC accesses the service registry table via ILMI using SNMP GetNext to sweep beginning with {Port=0, ServiceID=atmfSrvcRegNHRP, Index=0}, holding port number and serviceID constant. Port 0 indicates 'this port' within ILMI.
The Service Registry MIB table row (AtmfSrvcRegEntry) contains five fields: atmfSrvcRegPort (ATM port number), atmfSrvcRegServiceID (OID identifying the service type), atmfSrvcRegATMAddress (full ATM address of the service), atmfSrvcRegAddressIndex (integer differentiating multiple rows for the same service), and atmfSrvcRegParm1 (protocol-specific parameter octet string).
The service registry table is indexed by the combination of atmfSrvcRegPort, atmfSrvcRegServiceID, and atmfSrvcRegAddressIndex, allowing multiple NHS addresses to be registered for the same service on the same port with distinct index values for redundancy ordering.
The NHRP service is identified by the OID atmfSrvcRegNHRP ::= { 1.3.6.1.4.1.353.1.5.5 }, assigned in the ATM Forum Service Registry MIB. This OID is used to locate appropriate rows in the service registry table, not to name managed objects.
The server discovery mechanism relies on the ILMI management framework for security. The service registry MIB is defined with read-only access, so user-side devices may query but not modify it via ILMI; modifications must be made via local configuration on the ATM switch, preventing unauthorized NHC manipulation of registry data.
The NHRP service parameter string (atmfSrvcRegParm1) encodes: ar$pro.type (16 bits, protocol type, e.g. 0x0800 for IPv4), ar$pro.snap (40 bits, optional protocol type extension, 0 for IPv4/IPv6), ar$plen (8 bits, length of protocol address), ar$addr (plen octets, network address in network byte order), and ar$mask (plen octets, network mask in network byte order).