Interim Local Management Interface ILMI

ILMI is an ATM Forum standard that specifies the use of mechanisms and formats previously defined by the Simple Network Management Protocol (SNMP). Although it is based on SNMP, ILMI communication uses a transport other than IP that traverses only the physical ATM link. ILMI messages are carried over a well-known PVC. The ATM Forum PVC for ILMI uses the VCI 16.

ILMI provides the following:

• Configuration, status, and control information about physical and ATM-layer parameters of the ATM interface

• Interface attributes organized in a standard Management Information Base (MIB) structure

• Access to the adjacent ATM Interface Management Entity (IME) through the ILMI communication protocol

• Address registration across a UNI

• Auto-configuration of a LAN Emulation Client (LEC)

The ILMI protocol supports bidirectional exchanges of ATM interface parameters between IMEs. Using SNMP queries, a network management system can report on the status of the physical layer, ATM layer, VCs or VPs, ES address registration, and service registration such as LAN emulation (LANE) service.

When ILMI is enabled on both ends of a link, a management system can retrieve information on the interface number, interface address, media type, number of VPIs and VCI supported, number of VCs or VPs active, type of interface (NNI or UNI), QoS parameters, adjacent node identification, plus much more.

For PNNI, SVC signaling operation, adjacent node discovery, and LANE registration, ILMI must be enabled and configured.

When configuring ILMI, the following parameters must be configured to the same values at both ends of the link:

• ILMI VPI/VCI—The VPI and VCI reserved for ILMI messages; typically 0/16.

• ILMI Polling—Enabled or disabled.

• Trap Enabled—Enables or disables the sending of unsolicited event and alarm reports.

• T491 Polling Interval—The time period between status polls.

• N491 Error Threshold—If the number of messages defined by N491 is missing out of a total number of messages defined by N492, a communication failure is reported.

• N492 Event Threshold—The number of attempted messages in conjunction with the N491 threshold, to determine a communication failure.

ILMI supports ES address registration. ES address registration allows ESs to automatically be assigned an AESA without operator intervention.

As specified in the UNI 4.0 specification, the Private ATM Address Structure consists of multiple fields. Two of these fields, the end system identifier (ESI) and the selector (SEL) fields form the user part and are supplied by the user-side IME.

All other fields form a network prefix for ATM addresses that typically have the same value for all ATM addresses on the same ATM UNI. The network side of the UNI supplies the value of the network prefix. An ATM address for an ES on the user side of a Private UNI is obtained by appending values for the ESI and SEL fields to the network prefix for that UNI.


IISP is a static routing protocol for ATM. IISP allows a UNI signaling request to be routed across multiple switches based on static routes. However, IISP does not support QoS. IISP is useful where PNNI is not supported.

IISP requires the configuration of static routes. Use the following rules for configuring IISP:

• IISP static routes must avoid routing loops.

• Each switch is given an ATM address.

• A route can have a primary path and a secondary path.

In each switch a routing table is configured that contains the address prefixes that are reachable through each interface on the switch.

When UNI signaling is enabled, the switch arbitrarily takes the role of a UNI user on the network side.

Figure 5-26 shows an ATM network with UNI signaling enabled for IISP.

When the switch receives a signaling request, the switch matches the destination ATM address with the table entry with the longest prefix match. Each ATM switch that receives the connection setup message selects the next outgoing interface to which to forward the setup message. This process is less efficient than PNNI source routing.

The ability to crank back and compute an alternate route when congestion or connection failure occurs is not inherent in IISP. However, redundant or alternate paths can be configured.

Figure 5-26 IISP Routing

Router A

47.0091.8112.3400.1222.0ca7... 47.0091.8112.3400.1111.0ca7...

U = User side N = Network side

IISP can also provide a route between different PNNI peer groups. This is useful when the PNNI peer groups are administered separately or support different versions of PNNI.

Classical IP over ATM (CIA) (RFC 2225)

CIA is specified in RFC 2225. The purpose of RFC 2225 is to provide a method to send IP packets over ATM. In the RFC 2225 approach, each device that wants to send an IP packet over ATM is directly attached to the ATM network. This device can be a workstation or a router that acts as a proxy for an entire LAN.

For each logical IP subnet (LIS), an ATM ARP server is configured. The job of the ATM ARP server is to map IP addresses to the ATM network service access point (NSAP) or ITU-T E-164 addresses. Figure 5-27 shows how the ATM ARP server learns the addresses of the ARP clients.

Figure 5-27 CIA Registration

ATM ARP server

Each device in a LIS is configured with the ATM address of the ATM ARP server and acts as an ARP client. When the ARP client starts up, it sends a request for a SVC over a well-known VC using VCI 5. The ATM ARP server then establishes an SVC with the ARP client. The ATM ARP server uses Inverse ARP to learn the IP and ATM addresses of the client and registers the client. Figure 5-28 shows how the originating ARP client establishes a connection with the destination ARP client.

Figure 5-28 CIA SVC Establishment

ATM ARP server

When the device wants to send an IP packet to another device, it sends an ARP request to the ATM ARP server. If the destination device is already registered with the ATM ARP server, the server sends an ARP response to the client. After the originating device has the ATM address of the destination device, it can establish an SVC to the destination using UNI signaling.

If the ATM ARP server does not have an entry for the requested destination device, it sends a negative response to the ARP client.

RFC 2225 uses LLC/Subnetwork Access Protocol (SNAP), as defined in RFC 2684, for encapsulation of IP packets. LLC/SNAP encapsulation allows sharing of VCs. RFC 2225 specifies the use of AAL5 for transport of IP packets.

0 0

Post a comment