ILMI NHRP Discovery: ILMI-Based Server Discovery for NHRP
How an ATM host or router asks its switch where the NHRP server is, instead of being told by hand.
Davison, M., "ILMI-Based Server Discovery for NHRP", RFC 2603, DOI 10.17487/RFC2603, June 1999, <https://www.rfc-editor.org/info/rfc2603>.
@misc{rfc2603,
series = {Request for Comments},
number = 2603,
howpublished = {RFC 2603},
publisher = {RFC Editor},
doi = {10.17487/RFC2603},
url = {https://www.rfc-editor.org/info/rfc2603},
author = {M. Davison},
title = {{ILMI-Based Server Discovery for NHRP}},
pagetotal = 6,
year = 1999,
month = jun,
} RFC text
Contents
Network Working Group M. Davison
Request for Comments: 2603 Cisco Systems
Category: Standards Track June 1999
ILMI-Based Server Discovery for NHRP
Status 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 NHRP servers.
1. Introduction
Presently, configuring a host or router to use NHRP [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 NHRP
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 NHRP 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 supports
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 in Section 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. (See Section 3.2 for NHRP 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.
3.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 NHRP shall be:
ar$pro.type 16 bits Protocol type
ar$pro.snap 40 bits Optional extension to 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.type - See [1]. (IPv4 is 0x0800, IPv6 is 0x86DD)
ar$pro.snap - See [1]. (IPv4 and IPv6 are 0)
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 order
3.2 Service Object Identifier
This OID, assigned in the ATM Forum Service Registry MIB, names
ATMARP within the context of server discovery.
atmfSrvcRegNHRP OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.353.1.5.5 }
It does not name any managed objects, rather is used to locate
appropriate rows in the service registery table.
4. Next Hop Client Behavior
An Next Hop Client NHC) 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 = <see Section
3.2>, Index = 0} while holding the port number and the serviceID
constant. (Port number 0 is used within ILMI to indicate "this
port.")
An NHC with no local configuration, such as a diskless workstation,
must use the row with the lowest index value if multiple Next Hop
Server (NHS), possibly for multiple networks, are listed.
NHC 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 rows that have atmfSrvcRegParm1 values as shown below:
Net number/mask atmfSrvcRegParm1
---------------- --------------------------------------------------
1.0.0.0/8 08 00 00 00 00 00 00 04 01 00 00 00 ff 00 00 00
128.10.0.0/16 08 00 00 00 00 00 00 04 80 0a 00 00 ff ff 00 00
171.69.150.0/24 08 00 00 00 00 00 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 NHS and perform the appropriate
protocol operations.
Redundant NHS are supported with multiple rows in the service
registry table. This list of NHS is ordered with the primary NHS
having the lowest index value. The NHC must attempt to utilize the
primary NHS before utilizing a secondary NHS. Administrators must
ensure that the listed NHS are synchronized.
5. NHRP Server (NHS) Behavior
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.
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 NHS
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.
7. 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] Luciani, J., et al., "NBMA Next Hop Resolution Protocol", RFC
2332, 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
Full 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.
AI ELI5
On this page
§1The Configuration Problem
Setting up a host or router to use NHRP (the NBMA Next Hop Resolution Protocol, RFC 2332) is described as cumbersome and error-prone. At least one ATM address has to be statically configured on every host or router in the network.
It also rules out some machines entirely: a diskless host cannot use NHRP, because NHRP would need local configuration. ILMI-based Server Discovery (called "server discovery" in the memo) lets ATM-attached hosts and routers learn the ATM addresses of servers dynamically. This RFC defines how that method is used to locate NHRP servers.
Writing the server's address on every computer by hand is slow and easy to get wrong. This memo lets the computers just ask the network where to go.
§2ILMI and the Service Registry
The Integrated Local Management Interface (ILMI) lets ATM-attached devices such as hosts, routers and ATM switches exchange management information. It is based on SNMP version 1 and supports get, get-next, set and trap operations.
ILMI calls the switch side of an ATM link the network side and the host or router side the user side. The Service Registry MIB, defined by the ATM Forum in ILMI Specification Version 4.0, is implemented on the network side and queried from the user side. To support the existing framework for IP over ATM, ATM switches must support it.
The switch keeps a phone book of services. Computers on the user side are allowed to look things up in it.
§3The Service Registry Table
Each row of the service registry table has five fields: atmfSrvcRegPort, atmfSrvcRegServiceID, atmfSrvcRegATMAddress, atmfSrvcRegAddressIndex and atmfSrvcRegParm1. The table is indexed by port, service ID and address index.
The service ID is an object identifier naming the type of service. For NHRP it is atmfSrvcRegNHRP, 1.3.6.1.4.1.353.1.5.5. It names no managed objects; it is only used to find the right rows. The address field holds the full ATM address that a client uses to connect to the service. The address index is an arbitrary integer that tells apart several addresses for the same service on the same port. A port of zero means the ATM interface over which the request arrived.
The atmfSrvcRegParm1 octet string is a generic parameter string whose meaning depends on the service ID. For NHRP, to match RFC 2332, it carries the protocol type (16 bits), an optional extension (40 bits), the length of the protocol address (8 bits), the network address and the network mask. For IPv4 the type is 0x0800 and the length is 4; for IPv6 the type is 0x86DD and the length is 16. Addresses and masks are in network byte order.
Each row is like a card in the phone book: what kind of service, its address, and which network it serves.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
PRO-TYPE | ar$pro.type | 2 bytes | Protocol type; IPv4 is 0x0800, IPv6 is 0x86DD. | |
PRO-SNAP | ar$pro.snap | 5 bytes | Optional extension to protocol type; 0 for IPv4 and IPv6. | |
PLEN | ar$plen | 1 byte | Length of the protocol address; 4 for IPv4, 16 for IPv6. |
§4Next Hop Client Behavior
A Next Hop Client (NHC) reads the table with the SNMP GetNext operator, a linear "sweep" that starts at port 0, the NHRP service ID and index 0, while holding the port and service ID constant.
What the client does with the rows depends on how it is configured. An NHC with no local configuration, such as a diskless workstation, must use the row with the lowest index value when several Next Hop Servers (NHS), possibly for multiple networks, are listed. An NHC with local IP configuration must use a row that has the appropriate IP address. The RFC's example is a router with three logical interfaces (1.0.0.1/8, 128.10.0.1/16 and 171.69.150.226/24) that looks for three matching atmfSrvcRegParm1 values, one per network.
Once it finds the right row, the router may set up an SVC to the chosen NHS and carry on with the normal protocol operations.
The computer reads down the phone book until it finds the card for its own neighborhood, then calls that number.
§5Redundancy and Server Behavior
Several rows can list several servers. The list is ordered, and the primary NHS has the lowest index value. The NHC must try the primary before using a secondary NHS. Administrators must make sure the listed servers are synchronized.
An NHS itself is locally configured. It may read the NHRP service registry data to check the results, and if it finds an incorrect row it may flag the error in a locally significant way.
The RFC also notes that the ATM Forum's PNNI Augmented Routing (PAR), and a proxy mechanism for it, could be used to manage the registry tables on switches. Hosts and routers would keep using the same discovery mechanism, so nothing in this memo would need to change.
If the first number is busy, the computer tries the next card in order. The helpers on the list have to know the same things.
§6Security Considerations
Server discovery relies on the security of the ILMI management framework. Access to user-side or network-side information is controlled by the design of the MIB rather than by protocol security mechanisms.
The service registry MIB is defined with read-only access. Any user-side device may query the registry, but cannot change it over ILMI. Changes have to be made by local configuration on the ATM switch.
Anyone can read the phone book, but only the people who run the switch can write in it.