The Simple Times is an openly-available publication devoted to the promotion of the Simple Network Management Protocol. In each issue, The Simple Times presents: a refereed technical article, an industry comment, and several featured columns. In addition, some issues include brief announcements, summaries of recent publications, and an activities calendar. For information on submissions, see the end of this issue.
The Simple Times is openly-available. You are free to copy, distribute, or cite its contents; however, any use must credit both the contributor and The Simple Times. (Note that any trademarks appearing herein are the property of their respective owners.) Further, this publication is distributed on an "as is" basis, without warranty. Neither the publisher nor any contributor shall have any liability to any person or entity with respect to any liability, loss, or damage caused or alleged to be caused, directly or indirectly, by the information contained in The Simple Times.
The Simple Times is available via both electronic mail and hard copy. For information on subscriptions, see the end of this issue.
In this issue: (Re)Configuration of ATM Virtual Connections with SNMP
The IESG has recently approved a MIB module for the management of ATM interfaces, RFC 1695. This MIB module allows for the configuration of virtual connections (VCs). This article explains by example how this MIB module must be used in order to configure, reconfigure, or release VCs. While this procedure seems elaborate, it actually allows for detailed, step-by-step error checking for a VC (re)configuration in a simply scripted management application.
The ATM MIB treats VCCs and VPCs in much the same way. Thus, in the interest of simplicity this article describes procedures in the general terms of VCs and VLs.
The ATM MIB applies to ATM hosts, to ATM ISs and to ATM service providers who present an ``ATM cloud''. Because of their different roles, some portions of the MIB do not apply to all systems, e.g., the tables describing VL cross-connects only apply to intermediate systems and to ATM service.
VC establishment consists of the following phases:
whilst VC release consists of the following phases:
The order of the phases is important to the procedure. Although the whole procedure may seem complex, each step serves an important function in detecting errors that my occur during VC setup and takedown. Experience with the SNMP set operation has shown that they are, in general, more difficult than the get operation, and that detailing error conditions facilitates debugging.
This article illustrates the above procedure through an example of the configuration of a VCC between ``HostA'' and ``HostB'' through one IS. It assumes that the underlying VPLs are already established:
Device Interface ATM VC id ========= ========== ============= HostAToIS ifIndex=11 VPI/VCI=17,19 ISToHostA ifIndex=13 VPI/VCI=17,19 ISToHostB ifIndex=3 VPI/VCI=5,7 HostBToIS ifIndex=1 VPI/VCI=5,7
Basic interface configuration information is provided through the atmInterfaceConfTable. This table provides some VC constraints such as the maximum number of VCs that can be supported (atmInterfaceMaxVpcs/Vccs), the number of active VCs (atmInterfaceVpcs/Vccs), and the range of appropriate VC identifiers (atmInterfaceMaxActiveVpi/VciBits).
The management application creates a VL entry in the VL table (atmVclTable) by setting the row status to createAndWait. Note that the VC indices are chosen by the manager, and not by the agent. The index clause of the atmVclTable is { ifIndex, atmVclVpi, atmVclVci }. Thus:
HostA set atmVclRowStatus.11.17.19=5
IS set atmVclRowStatus.13.17.19=5
set atmVclRowStatus.3.5.7=5
HostB set atmVclRowStatus.1.5.7=5
This fails (on a particular ATM interface) if:
Otherwise, the agent creates a row and reserves the VPI/VCI values on that port. It also increments atmInterfaceVpcs/Vccs.
The second phase is to characterize traffic on the VLs.
The ATM MIB contains a table atmTrafficDescrParamTable. that contains vectors with traffic parameter values. The ATM VL tables characterize the traffic for the transmit and receive direction by pointing to the appropriate entries in the atmTrafficDescrParamTable. Multiple VLs in the atmVclTable/atmVplTable can point to the same vector in the atmTrafficDescrParamTable. This technique allows the agent to predefine self-consistent traffic vectors in the atmTrafficDescrParamTable. In addition, the agent may support read-create access, allowing the manager to specify additional vectors.
The traffic vector consists of an atmTrafficDescrType column, describing the type of traffic, five columns that parameterize the traffic (atmTrafficDescrParam1 through atmTrafficDescrParam5 -- the number of columns actually used depends on the traffic type), and a column indicating the quality of service (atmTrafficQoSClass). The table is completed by a row status column (atmTrafficDescrRowStatus) and the atmTrafficDescrParamIndex which indexes the table.
Thus, the manager selects an existing row(s) in the atmTrafficDescrParamTable, or, if no suitable row(s) exists, the manager must create a new row(s) in that table. For example, when the next free row is 100:
set atmTrafficDescrRowStatus.100
=creatAndWait
This action fails if:
As an example, a ``best effort'' VL where none of the traffic parameters is used is characterized by:
set atmTrafficDescrType.100
=atmNoTrafficDescriptor
As another example,
an ATM VC with a 64kbps peak rate is characterized by:
set atmTrafficDescrType.100=atmNoClpNoScr
atmTrafficDescrParam1.100=167
(peak cell rate = 64000bps/(48bytes x 8bits), or 167cells/sec.)
The quality of service class is specified by, e.g, set atmTrafficQoSClass.100=bestEffort. These actions fail if:
The manager activates the traffic descriptor parameter row by: set atmTrafficDescrRowStatus.100=active. The management application now characterizes the traffic parameters of all the VLs associated with the VC by pointing the receive and transmit traffic index (atmVpl/VclReceiveTrafficDescrIndex and atmVpl/VclTransmitTrafficDescrIndex) in the VL table atmVpl/VclTable. to the atmTrafficDescrParamTable. rows containing desired ATM traffic parameter values. Thus:
HostA set
atmVclReceiveTrafficDescrIndex.11.17.19
=100
atmVclTransmitTrafficDescrIndex.11.17.19
=100
IS set
atmVclReceiveTrafficDescrIndex.13.17.19
=100
atmVclTransmitTrafficDescrIndex.13.17.19
=100
atmVclReceiveTrafficDescrIndex.3.5.7
=100
atmVclTransmitTrafficDescrIndex.3.5.7
=100
HostB set
atmVclReceiveTrafficDescrIndex.1.5.7
=100
atmVclTransmitTrafficDescrIndex.1.5.7
=100
This action fails (on a particular VL) if:
The manager now activates the VLs by setting the row status (atmVpl/VclRowStatus) to active, thus:
HostA set atmVclRowStatus.11.17.19=active
IS set atmVclRowStatus.13.17.19=active
atmVclRowStatus.3.5.7=active
HostB set atmVclRowStatus.1.5.7=active
If this set is successful,
the agent has reserved the resources to satisfy the requested traffic
parameter values and the QoS Class for that VL.
The third and final phase is to cross-connect the VLs in the intermediate systems.
On the IS, the atmVcCrossConnectTable must be used to cross-connect the VLs. The atmVpl/VclTables have a cross-connect identifier column for this purpose (atmVpl/VclCrossConnectIdentifier). Different rows in the atmVpl/VclTable that have the same cross-connect identifier value are cross-connected. This is achieved through cross-connect tables (atmVp/VcCrossConnectTable).
The first step to cross-connecting VLs is to obtain a unique cross-connect index. An object, atmVp/VcCrossConnectIndexNext. is defined for this purpose. A get-next will obtain a value (e.g., 3333). The object is defined such that after a retrieval operation the agent will increment the value to the next unassigned one.
This operation fails if:
The second step to cross-connecting VLs has the manager connect VCLs through creation of a row in the atmVcCrossConnectTable, which is indexed by:
{ atmVcCrossConnectIndex,
atmVcCrossConnectLowIfIndex,
atmVcCrossConnectLowVpi,
atmVcCrossConnectLowVci,
atmVcCrossConnectHighIfIndex,
atmVcCrossConnectHighVpi,
atmVcCrossConnectHighVci }
(Cross-connecting VPLs works in the same way -- only the
INDEX clause differs.)
The VL indices for the interface with the lowest index value
(i.e., ifIndex=3) must be specified first in the table's index.
Thus:
set atmVcCrossRowStatus.3333.3.5.7.13.17.19
=createAndWait
This request fails (on a particular cross-connect) if:
If the request is successful the agent fills in the atmVcCrossConnectIndex values in the corresponding atmVclTable rows, i.e.,
atmVclCrossConnectIdentifier.13.17.19
= 3333
atmVclCrossConnectIdentifier.3.5.7
= 3333
The manager can now activate the cross-connect row by:
set
atmVcCrossConnectRowStatus.3333.3.5.7.13.17.19
=active
This request fails (on a particular cross-connect) if:
Finally, the manager turns on the traffic through the cross-connected VLs by:
set atmVcCrossConnectAdminStatus.3333.3.5.7.13.17.19
=up
At this point the traffic flow must be actually turned on.
In the hosts the
link to the application must be made.
HostA set atmVclAalType.11.17.19=aal1 HostB set atmVclAalType.1.5.7=aal1This action fails if:
Finally, the manager turns on the traffic at the host by:
HostA set atmVclAdminStatus.11.17.19=up HostB set atmVclAdminStatus.1.5.7=upThis step-by-step process above can be shortened by using the createAndGo value for the row-status objects. However, the advantage of detailed step-wise error checking would be lost. Therefore, the step-wise process is recommended.
To release a VC, all cross-connects and associated VLs must be released by setting the row status of the associated table entries to destroy. Thus, for IS:
set
atmVcCrossConnectRowStatus.3333.3.5.7.13.17.19
=destroy
Removal of all rows with
atmVcCrossConnectRowStatus.3333.*.
will free the value 3333 for future use by the
atmVcCrossConnectIndexNext.
and the
atmVclCrossConnectIdentifier.
values will be removed from the associated VLs,
to signify that they are no longer cross-connected.
Cross-connect resources are released.
The second phase is to release the VLs.
To reclaim the VLs associated with the VC, each associated table entry must be destroyed. Thus:
HostA set atmVclRowStatus.11.17.19=destroy
IS set atmVclRowStatus.13.17.19=destroy
atmVclRowStatus.3.5.7=destroy
HostB set atmVclRowStatus.1.5.7=destroy
Upon these actions the agents will release the associated VL resources,
and decrement atmInterfaceVpcs/Vccs.
It is recommended to release a cross-connect before releasing the individual VLs. The reason is that releasing a VL first may, in some implementations, be interpreted as a request for a configuration change (e.g., a multipoint topology where one leaf is being deleted; see below). Proper agent implementation should release cross-connects automatically if:
The third phase is to release the traffic descriptors.
To release the traffic parameter values associated with the transmit and receive directions of the VLs, the rows of the traffic descriptor table (atmTrafficDescrParamTable) pointed to by the VLs, must be deleted. Deletion proceeds in the normal way with atmTrafficDescrRowStatus. Such a deletion fails if:
Traffic and/or QoS parameter value changes. These do not require additional agent capabilities. The manager takes down the current VC, defines new VLs with the desired parameters, and brings up the new VC following the rules outlined above. This is most simply done as an entirely new set of VLs. If there is a desire to retain the VPI/VCI values, the manager may follow these steps:
Changing the VC application at the hosts (for example, changing the AAL), requires additional agent capabilities.
A VC topology change requires additional agent capabilities. To accomplish a point to multipoint leaf addition, follow these steps:
To accomplish a destination change, follow these steps:
The neighbor information is expressed, for each physical interface on a switch, as the address of the agent on the neighbor switch to which this interface is connected, and the interface name on the neighbor switch to which this interface is connected. ifIndex -> neighborAddress, neighborIfName. Populating the neighbor information objects requires quite specific topological information. It can be manually configured, or auto-discovered. In the latter case, an agent acquires the information by interchanging with other agents its address and its interfaces. The ATM Forum has defined an ILMI MIB and access method which can be used for such a purpose. The ILMI messages are interchanged on a single ATM link, and can access the ILMI MIB objects. Using this, each agent sends an ILMI query out each of its physical interfaces, requesting its neighbor's agent address and the incoming interface name. Upon receiving such a query, a switch must answer with its address and the name of the interface on which the query came in. Full network auto-discovery requires all switches to participate.
The ATM Forum's Network Management Sub-committee has recently approved two new ILMI objects which will support this auto-discovery. They are: atmfMyIpNmAddress (non-tabular) and atmfPortMyIfName in the atmfPortTable, which is indexed by physical interface.
In order to represent this neighbor information at the SNMP level, the ATM MIB contains two objects. They are named: atmInterfaceMyNeighborIpAddress and atmInterfaceMyNeighborIfName, both in the atmInterfaceConfTable, which is indexed by ifIndex. Thus the neighbor information is:
ifIndex
-> atmInterfaceMyNeighborIpAddress,
atmInterfaceMyNeighborIfName
To illustrate this,
consider the neighbor information for our example, which is maintained
by the agents residing on HostA, on the IS, and on HostB:
HostA index11 -> ipAddrIS, ifName13
IS index13 -> ipAddrA, ifName11
index3 -> ipAddrB, ifName1
HostB index1 -> ipAddrIS, ifName3
To trace a VC,
the manager follows a simple algorithm involving the
atmVc/VpCrossConnectTable
and the neighbor information in the
atmInterfaceConfTable.
To start,
it identifies a starting point switch or host,
a VC and a direction,
probably by naming an outgoing interface and VPI/VCI values.
The outgoing VPI/VCI values equal
the incoming VPI/VCI values on the next hop interface.
From the
atmInterfaceConfTable
it determines the next hop switch,
and the incoming interface on that switch.
From the
atmVc/VpCrossConnectTable
on the next hop switch it determines the outgoing interface,
and the outgoing VPI/VCI values.
The algorithm is repeated until the VC terminates at a host. Since it has no cross-connections, a host does not support the atmVc/VpCrossConnectTable.
It's official: this is the last issue of The Simple Times for 1994. The reason is simple: the editorial staff (me) just doesn't have the time to put in on each issue. Look for the third volume at the beginning of 1995.
The ATM Forum is a consortium of member companies and organizations. Its initial charter was to produce ``interoperability agreements''. These agreements are designed to fill in the gaps where no standards are defined. As it has turned out, several of the Forum's specifications have in fact defined new standards. One such new standard is the Interim Local Management Interface (ILMI).
The purpose of the ILMI is to allow the user-side and network-side of a User Network Interface (UNI) to communicate with each other in order to exchange management information concerning the local ATM interface. Rather than defining a new protocol, the ILMI is defined to use the same message formats and semantics as are used by SNMPv1. Thus, it has the same five PDU-types as SNMPv1 (get, get-next, set, get-response, and, trap), and the variables included in these PDUs are defined in MIBs using SNMPv1's SMI.
However, it is most important to realize that the ILMI has a different paradigm from the use of SNMP for network management. In network management, a manager issues requests and an agent responds with responses and generates traps. In contrast, the ILMI is used for interface management between the two UNI management entities (UMEs), one on either side of the UNI; both UMEs can and do send requests as well as responses and traps; the two UMEs have their own (potentially different) values for the same MIB objects.
The term ``Interim'' was chosen in the early days of the ATM Forum, when there was great reluctance to deviate from ITU-T (formerly the CCITT) standards. However, the ITU-T had no suitable protocol defined for interface management, and thus the ILMI was adopted in the ``interim''. With the passage of time and the expanding use of the ILMI, it is now joked that it would make more sense if the ``I'' stood for ``indefinite''.
All of the above were defined to be read-only.
In addition to the ILMI MIB, a UME was expected to support the system group from MIB-II, coldStart, linkUp and linkDown traps, and allowed to support enterprise-specific MIB extensions.
The use of the ILMI to perform address registration specifies that the network-side UME issues a SetRequest to provide the host with the network prefix, so that the user-side UME can combine the prefix and its own MAC address, and then issue its own SetRequest for the combined value. Thus, these address registration procedures allow both the host and the switch to obtain the host's ATM address(es) merely from having the switch know the network prefix and the host know its MAC address(es).
It is not yet determined whether the ILMI will be used at the NNI (the interface between two ATM switches), although it has been suggested as a means of extending the Topology Discovery to cover the whole network. Another possibility is for a switch to be able to automatically distinguish a UNI from an NNI, and perform other auto-configuration.
In the extended time between the last and current issues there have been eleven new RFCs published containing MIB modules. Four of these were updates to existing MIB moduless. These were RFC 1643, the Ether-Like MIB, which is now a full standard; RFC 1658, the character device MIB; RFC 1659, the RS-232 interface type MIB; and, RFC 1660, the Parallel Printer interface type MIB; which are all now Draft standards.
The seven other MIB moduless reflect work that crosses the spectrum of areas where management is now possible. These include RFC 1595, the SONET/SDH interface type MIB; RFC 1604, the Frame Relay Service MIB; RFCs 1611 and 1612, the DNS Server and Resolver MIBs; RFC 1628, the UPS MIB; RFC 1650, the SNMPv2 version of the Ether-Lime MIB; RFC 1657, the MIB for BGP version 4; RFC 1666, the SNA NAU MIB. RFC 1694, the SMDS Interface Protocol (SIP) Interface Type MIB; RFC 1695, the ATM MIB; RFC 1696, the Modem MIB; and, and, RFC 1697, the Relational Database Management System MIB.
Use of the SNMPv2 SMI has been much appreciated since it allows then to be much more precise in specifying in parsable form the grouping and rules for compliance to the MIB.
Two MIB module checkers are currently available via e-mail:
mib-checker@epilogue.com mosy@dbc.mtview.ca.usFor both, the body of the email message should contain the MIB module to be checked (the ``Subject:'' lines are not evaluated). Hopefully other checkers will soon be available.
SNMPv2 Framework (Proposed Standards):
Full Standards:
Draft Standards:
Proposed Standards:
Experimental:
Informational:
Historical:
AToM MIB Working Group:
BGP Working Group:
Bridge MIB Working Group:
Character MIB Working Group:
DECnet Phase IV MIB Working Group:
FDDI MIB Working Group:
Frame Relay Service MIB Working Group:
Host Resources MIB Working Group:
IEEE 802.3 Hub MIB Working Group:
IDPR Working Group:
IDRP for IP Working Group:
Interfaces MIB Working Group:
IPLPDN Working Group:
IS-IS Working Group:
Mail and Directory Management Working Group:
Modem Management Working Group:
NOCtools Working Group:
OSPF Working Group:
PPP Working Group:
RIP Working Group:
Remote Monitoring (RMON) Working Group:
SNA DLC Services MIB Working Group:
SNA NAU Services MIB Working Group:
SNMPv2 Working Group:
TCP Client Identity Protocol:
Trunk MIB Working Group:
Uninterruptible Power Supply Working Group:
X.25 MIB Working Group:
The Simple Times also solicits terse announcements of products and services, publications, and events. These contributions are reviewed only to the extent required to ensure commonly-accepted publication norms.
Submissions are accepted only via e-mail, and must be formatted in HTML version 1.0. Each submission must include the author's full name, title, affiliation, postal and electronic mail addresses, telephone, and fax numbers. Note that by initiating this process, the submitting party agrees to place the contribution into the public domain.
In addition, The Simple Times has numerous hard copy distribution outlets. Contact your favorite SNMP vendor and see if they carry it. If not, contact the publisher and ask for a list.