In 1993, the Internet Engineering Task Force (IETF) formed an AToM MIB Working Group to define and develop the necessary management objects using standard SNMP protocol for managing ATM devices. The "o" in "AToM" signifies Sonet and is lowercase for a reason: It's to remind vendors to keep MIBs small and efficient.
The group's original goals were to focus on ATM PVCs providing management of the ATM interface as well as an end-to-end view of the ATM service. It based its efforts on the Sonet MIB, the DS-1/E1 and DS-3/E3 MIBs, and the ILMI MIBs.
Since ATM technology would be implemented both in LANs and WANs, the group needed to understand and define management objects for multiple views, including a local view of ATM-based communication over the local interface, a network view of the local interface, ATM switch management (private and public), ATM-based service information (private and public), and an end-to-end view of the communication path.
The current version of the AToM MIB (otherwise known as IETF RFC 1695, "Definitions of Managed Objects for ATM Management version 8.0") defines object groups that can help net management applications construct some, but not all, of these views of the network. It specifies several SNMP management objects to manage ATM interfaces, ATM virtual links, ATM cross-connects, AAL 5 entities, and AAL 5 connections supported by ATM hosts, ATM switches, and ATM networks. The MIB uses SNMP SMI (structure of management information) version 2 to describe these objects, but it can be accessed by SNMP 1 management applications.
Although the AToM MIB provides much of the same information as the ILMI MIB, it is in some respects more limited. At the moment, the AToM MIB is used primarily to manage ATM PVCs. It can handle partial management of SVCs, but full management-including signaling functions-will require capabilities beyond the scope of RFC 1695.
In addition, the AToM MIB does not define objects needed for ATM service management or for a true end-to-end view of the ATM network. One reason for this is that the MIB is limited to a single ATM end-system or switch and does not support the whole end-to-end span of a VC (or VPC), which spans multiple ATM end-systems and/or switches. Thus the end-to-end management of a VC or VPC is achieved only by appropriate management of its individual segments in combination.
--P.A. and K.C.
[ Home ]
[
Registration
|
Subscriptions
]
[
Contact Us
|
E-Mail
]