ATM Management - Semantic Scholar

ATM Management: Challenges and Solutions for the Heterogeneous Environment J. Soldatos*, G. Kormentzas**, E. Vayias*, K. Kontovasilis**, N. Mitrou*

∗

National Technical University of Athens, Electrical & Computer Eng. Dept., Computer Science Division, 9 Heroon Polytechneiou Str., GR-15773 Zografou, GREECE, e-mails: {jsoldat; evayias}@telecom.ntua.gr, [email protected]

**

National Center for Scientific Research “Demokritos”, Institute for Informatics & Telecommunications, GR-15310 Ag. Paraskevi, POB 60228, GREECE, e-mails: {gkorm; kimon}@cyclades.nrcps.ariadne-t.gr

Abstract

This paper reviews ATM management information models proposed (mainly by standardisation bodies such as ATM Forum, IETF, ITU-T) as a global solution to the management of multi-vendor ATM equipment in a heterogeneous environment. After a brief presentation of the management model advocated by the ATM Forum, the paper proceeds to examine further the five interfaces (M1-5) of this management model and relate them with existing implementations of major MIBs (such as the ILMI MIB). Building on the M4 paradigm, the paper proposes a unified ATM management information model that integrates information fields from various existing MIB trees. Lastly, the paper discusses the perspective of using such unified information models in building management systems for heterogeneous environments.

1

2

1.

INTRODUCTION

ATM has emerged with the intention of becoming the basic infrastructure for all future broadband communications. The relevant technology integrates essential features, such as quality of service and traffic loss prioritisation, and allows for scalability and technological longevity. Although much work has been undertaken towards its standardisation, it is widely accepted that ATM has not been developed to the point where every issue is resolved. Among the major challenges faced currently by ATM technology, a primary one, is certainly the network management. ATM networks require management procedures of a scope far beyond of what may be found in traditional networks. To name only one particular distinction, ATM management does not concentrate only on the physical level (e.g., monitoring the status of a switch port), with a view to dealing with defects, failures and malfunctions in wires, switches and other hardware, but focuses mainly on the logical level, with the overall goal of offering the preferred quality of service and exploiting, to the maximum extent possible, the multiple service levels and the traffic control mechanisms of ATM. Furthermore, management procedures used in traditional shared-media LANs, are not sufficient when it comes to managing virtual channel connections at a much higher speed. Lastly, ATM administration must address implications of multimedia networks carrying not only data, but also video and audio. Tasks related to ATM management are further complicated due to the complex and heterogeneous nature of the networking environment. Indeed, most of the present networks are composed of diverse equipment from different vendors. Furthermore, new technologies and services are introduced and integrated in a rapid pace. Hence, future ATM management applications should support the complex procedures imposed by the ATM technology itself, while at the same time being suited to composite networks. It is evident that a management framework is needed, so as to efficiently deal with the inevitable complexities of ATM management. The Network Management Working Group of the ATM Forum has finalised a five layer network management model that provides a structured approach towards managing ATM networks [1,2]. Among the major characteristics of this model is that it will be applicable both to public and private networks, by featuring interfaces to existing SNMP (Simple Network Management Protocol), CMIP (Common Management Information Protocol) and proprietary management systems. In addition, it allows for distribution of management information over ATM networks through OAM (Operations and Maintenance) cells. However, even now that this standard is in place, it

ATM Management: Challenges and Solutions for the Heterogeneous Environment

3

is estimated that it will take a few years for full in-band OAM capabilities to be developed [3]. In other, independent attempts, several management models have been proposed as potential solutions for integrated management. The TMN (Telecommunication Management Network) is one prominent such model, which however has not come up to initial expectations [4]. A consideration of the potential use of TMN for ATM networks is given in [5]. Another protocol that has been proposed in order to render the management of ATM switches independent of vendor specific details, is the General Switch Management Protocol (GSMP) [6]. However, the scope of GSMP is limited to a small set of capabilities. Currently, several distributed approaches, such as CORBA (Common Object Result Broker Architecture) [7], and TINA (Telecommunication Information Networking Architecture) [8], are also emerging as candidate schemes that could remedy heterogeneity issues. Although, these modern strategies are looming as promising solutions, they are not mature enough yet to act as frameworks for implementation of management applications. As a result, most of the current management applications are only compatible with proposals of interim specifications. This unsatisfactory situation is furthermore pronounced by the fact that network operators resort very often to proprietary implementations in order to satisfy their needs. In an attempt to provide a more unified view towards the effective management of heterogeneous ATM environments, this paper proposes a mechanism for designing MIBs through the integration of information from other existing MIB trees. This strategy, based on the paradigm set by the M4 interface of the ATM Forum information model, involves reviewing the structure and content of the MIBs of the various devices in a heterogeneous environment and identifying common information items that can be retrieved from these MIBs, through the use of a proper management protocol. The common abstract information model that is the outcome of this review has the ability to semantically represent the different MIB trees of the managed ATM devices with a small yet comprehensive number of constructs. Thus, the management application based on such a common abstract model does not have to deal with the particularities of each managed device at a high-level, but only through a “translation” interface, for the purpose of “mapping” the abstract information to the actual underlying network management structure. The rest of the paper is structured as follows: Section 2 reports briefly on the five management interfaces of the ATM Forum management model. Some of these interfaces are detailed further in the following subsections. In particular, the M1/M2 interfaces are discussed in connection with the ILMI implementation in Subsection 2.1. The following Subsection 2.2 outlines the

4 M3 (Customer Network Management) interface, while Subsection 2.3 is dedicated to M4. Building on the M4 paradigm, the strategy for designing integrated MIBs is discussed in Section 3. Finally, Section 4 concludes the paper.

2.

ATM FORUM MANAGEMENT MODEL

The Network Management Working Group of the ATM Forum has developed an end-to-end generic management model that encompasses both private and public networks and lays out standards for interworking between them. The model defines gateways between SNMP and CMIP systems, and between standards-based and proprietary systems. Five key management interfaces are defined in this model; they are labelled M1 through M5 in Figure 1 below. M3 Corporate/Enterprise Network M anagem ent System M1 User Device

M5 Carrier Network M anagem en t System

M2

M4

Private ATM Network

Public ATM Network

Carrier Network M anagem en t System M4

Public ATM Network

Public/Private Network Boun dary

Figure 1 - ATM Forum Management Model Private ATM network management is addressed through M1 combined with M2. M1 is concerned with the management of the end user equipment connecting to either private or public switches. M2 undertakes with the management of private ATM switches and networks, while M4 deals with their public counterpart. M3 is the link between private and public networks, used for exchanging fault, performance and configuration information. Finally, M5 supports interactions and exchange of management information between any two public networks. The definition of these interfaces empowers a complete management service, ranging from a global view of the network (M5 interface) to the management of individual elements (M1 interface). For an exhaustive description of these interfaces, one may resort to the corresponding specifications ([1,2,9-10]).


5

Table 1 maps the structure of the major MIBs proposed by ATM Forum, IETF, and other standard bodies and vendors to the five management interfaces of the ATM Forum management model. ATM Forum Interface M1

Applicable MIBs AToM MIB, LANE MIB, ILMI MIB, DXI MIB, and Proprietary MIBs (ATM Adapter MIBs) AtoM MIB, LANE MIB, ILMI MIB, CBS MIB, M2 (SNMP) PNNI MIB, Transmission MIBs (RFC 1406, RFC 1407, and RFC 1595), IMA MIB, RMON MIB, and Proprietary MIBs M4 Network View MIB, M4 Network Element M2 (CMIP) MIB, M2 SVC MIB, ITU-T SONET MIB and E1/E3 MIBs M3 M3 MIB and AToM MIB ILMI MIB, LANE MIB, CES MIB, M4 SNMP M4 (SNMP) MIB, ATM AAL MIB, Transmission MIBs (RFC 1406, RFC 1407, and RFC 1595), ATM IMA MIB, and RMON MIB M4 NE MIB, ITU-T I.751 MIB, M4 SVC MIB, M4 (CMIP) ATM AAL MIB, Transmission MIBs (ITU-T G.704, G.706, G.774, G.826, and G.882), Bellcore G.114, and NM Forum MIB M5 ATM Forum Network-to-Network MIB and ETSI NA5-2212 carrier-to-carrier MIB Table 1 - Mapping of MIBs to the ATM Forum Model [11]

Note that some MIB trees (e.g., the ILMI MIB) contain necessary information for more than one management interfaces of the ATM Forum management model. The following subsections elaborate further on the management interfaces, except M5, which is still under standardisation process.

2.1

M1/M2 Interfaces and the ILMI Implementation

The Interim Local Management Interface (ILMI) is an implementation of the M1/M2 interfaces. It provides exchange of status, configuration, and control information between any two ATM devices, e.g., two switches, across a UNI. Every ATM switch or end station and every ATM network that deploys a private network UNI or a public network UNI must have a UNI Management Entity (UME), which supports an ILMI MIB. Two adjacent (or peer) UMEs communicate through the ILMI. A UME may obtain or alter (in case of modifiable objects) information contained in its ILMI MIB using SNMP.

6 The ILMI MIB is hierarchically organised, as shown in Figure 2. It contains information concerning the physical-layer group, the ATM-layer group, the ATM-layer statistics group, the virtual connection group, the virtual path connection group, the network prefix group, and the address group.

Address Group

end_station_address

Network Prefix Group ATM_address_prefix Virtual Path Connection Group

status, traffic_descriptors, service_parameters

Virtual Connection Group status, traffic_descriptors, service_parameters total_transmitted_cells, ATM Layer Statistics Group total_received_cells, total_dropped_cells, ATM Layer Group

numVPCs, max_numVPCs, numVCs, max_numVCs

Physical Layer Group

portType, mediaType, status

Figure 2 - The Structure of ILMI MIB Functions that allow retrieval and handling of the information included in the ILMI MIB have been defined. The whole set of ILMI functions and a full description of the ILMI MIB and protocol, with respect to UNI 4.0 specification, are given in [9]. The ILMI has been deployed by some vendors to perform management tasks across the UNI for some devices. For a typical implementation, see [12]. However, the ILMI provides a solution applicable only at the UNI, and, thus is incapable of supporting the management tasks that involve a network consisting of a wide range of diverse ATM devices.

2.2

M3 (Customer Network Management) Interface

The Customer Network Management (CNM) interface defines the interaction taking place between the customer and carrier management systems in order to give the customer a view into the carrier’s network. Ultimately, carriers plan to extend their CNM offerings so that network managers will have real-time control over the services they use. Currently, the most characteristic capabilities of CNM for ATM networks are the performance of tests, the reception of event notifications, the definition of


7

traps, the administration and generation of trouble reports, the support of security features, and the retrieval of configuration, usage, and performance information from the M3 MIB that defines objects for the customer portion of a public network. The CNM applications may regarded as an example of the classical Manager/Agent model. A CNM application is acting as a manager that communicates with a CNM agent residing in an ATM network. The CNM agent is capable of supplying the required management information and carrying out management tasks related to the managed resources. It communicates with the carrier’s Network Management System (NMS) which comprises the whole set of management functions supported by the carrier. Therefore, the CNM agent usually supports only the portion of these management functions that pertain to the service provided to the customer. The interfacing between a CNM agent and a NMS should be based in open standards, in order to ensure that the CNM agent is flexible in taking advantage of new functions and/or services that will be added to the NMS. The initial CNM service supported by carriers targets Cell Relay Service customers. Therefore, CNM services are built based on Cell Relay Service and ATM network requirements that are described in a host of ITU-T and BellCore documents. This set of documents as well as the MIB trees which contain necessary information for CNM can be found in [13].

2.3

M4 Interface

The M4 interface specifies requirements for managing individual network elements. Moreover, it defines a protocol-independent MIB that identifies the information items to be exchanged between ATM devices and the system that manages them. This MIB is a logical information tree, consisting of managed entities, that provides a framework for the development of protocol-specific MIBs, such as those based on SNMP or CMIP, that would potentially enable the management of ATM networks consisting of diverse devices of heterogeneous nature. Another aspect of the M4 interface, revealing its potential for integrated network management, is its relationship with TMN. Several aspects of the M4 interface bear close similarity to the five layer model of operations defined by ITU M.3010 [14]. Specifically, M4 addresses the interactions between the lower three TMN layers, namely the Element Layer, the Element Management Layer and the Network Management Layer. Furthermore, the M4 specification addresses almost every area of ATM management (i.e., fault, performance, configuration, and security management). Undeniably, it is a complete specification that makes

8 provisions for managing both the current and the future public ATM networks. Nevertheless, in practice the M4 interface has not have, as yet, a significant impact on ATM network management. Its poor penetration is mirrored on the fact that it has not been deployed yet. A reason for this phenomenon could be the complexity of the specification, a property inhibits the potential of this specification to outweigh the prevalence of the existing SNMP-based implementations. However, it would be unsound to rule out the possibility of M4 support in the future. For example, the information model of the next section bears pertinence to the M4 interface.

3. The Common Abstract Model for ATM Management Information (CAMMI) Currently, standardisation bodies such as ATM Forum, ITU-T, or IETF have not succeeded in providing a globally acceptable approach for the management of ATM networks and they have been mostly limited to general guidelines, or to addressing very specific areas of ATM management (such as the UNI by means of the ILMI specification). In bridging the gap, towards an effective unified framework for the management of ATM networks, two approaches prevail. The first one refers to the development of an integrated general-purpose management platform based on some generic commercial SNMP-based management platform (such as HP OpenView, IBM NetView, Sun NetManager, only to mention a few). The second approach is the WebBased Management (WBM) that engages the uniform and well-accepted WWW user interface for the retrieval of management information. Both concepts use an abstraction of the management information. Such abstraction is achieved by means of a generic high-level information model, forming the core of the management application. The abstract information model conceals the particularities of each managed device of the heterogeneous environment; these details are visible only at a “translation” interface. We now discuss the structure of the generic information model (called Common Abstract Model for ATM Management Information and abbreviated as CAMMI) that forms the heart of a system for the remote monitoring of the EXPERT, a European prototype heterogeneous ATM network consisting of a variety of ATM devices, such as commercial ATM switches from various vendors, experimental ATM switches, and numerous ATM end stations [15]. This monitoring system was undertaken as a task by the European research project WATT within the ACTS programme [16]. The WATT monitoring system that has been developed is actually a Web-based Management system that follows the gateway approach [17].


9

According to this paradigm, there is a gateway module that gathers the management information requested by the end user. The gateway module possesses knowledge related to all the devices of the experimental ATM network. This knowledge is collected for each network element through the use of management protocols (CMIP or SNMP) supported by the managed devices. As a result, the gateway module is a sophisticated management application that queries the various agents of the managed devices in order to obtain and store the latest values of the information items specified in the information model described in the sequel. The end user queries the gateway module using client software (implemented as a Java applet) [18]. A module of the client software is actually a Graphical User Interface (GUI), capable of displaying ATM network information in a graphical manner. The interaction between the client software and the gateway module is based on a request/reply interface which was specially designed to support experiments on ATM resource allocation, routing, and charging, although the nature of the information of interest is different for each of these three trial categories. The system was used to support a quite large set of trials with virtually no additional customisation. To properly design the monitoring system, an information model common to both the interacting entities, i.e., the gateway module and the client, was called for. To define this information model, the structure and the content of the MIBs of the various devices residing in the monitored platform were reviewed, in order to make sure that the information entities contained in the common abstract model could be retrieved from the MIBs of the monitored devices, through the use of a proper management protocol. Specifically, the following MIB structures were thoroughly examined: • AToM MIB (IETF RFC 1695, “Definitions of Managed Objects for ATM Management”) [19] • M4 Interface Requirements and Logical MIB [2] • CISCO-Switch-MIB • FORE-Switch-MIB • IBM-Switch-MIB • MIB of the experimental switches in the Expert platform A short outline of these MIBs may be found in [20]. The information model that was the outcome of this review (i.e., the CAMMI MIB) has the ability to semantically represent the different MIB structures of the various ATM devices with a small yet comprehensive number of constructs. The objective in the definition of the CAMMI MIB was not to provide an extensive management information structure covering every potential ATM

10 management aspect, but rather to cover in a comprehensive way the network information entities that were related to the trial activities of interest on the EXPERT platform. Consequently, the design of the CAMMI MIB was based on trial activities on ATM resource allocation, routing, and charging. Specifically, the CAMMI MIB organises the following management information categories: • Configuration: It includes information related to the physical and logical network configuration used for a particular trial. Specifically, information about the nodes participating in a trial (mainly ATM switches, but also other devices, such as terminals and policing units), the links physically connecting those nodes, the capacity and nature of those links, and the Virtual Paths and Virtual Channels established between the active nodes of the respective trial, can be retrieved from the CAMMI MIB. • Performance: Various parameters quantifying the effect of resource allocation and routing operations. Specifically, the parameters that can be retrieved from the CAMMI MIB are the allocated and used bandwidth in a VP/VC, and the accepted and rejected calls in a VP. • Charging: This type of information is generally represented by various scalar quantities pertaining to various objects of the physical and logical configuration (i.e., nodes, VPs, and VCs). Since the exact semantics of these quantities greatly depend on the details of each trial and on the specific hardware used to acquire such information, there is no explicit representation of this type of information in the current CAMMI MIB. However, the structure of this MIB can be easily extended in order to include parameters representing charging information, as attributes of other defined entities. For example, the aggregate cell count can be included in the VP entity. The information categories just described are organised in the CAMMI MIB, whose structure is depicted on Figure 3. The information model defines a tree-structure of classes. Each class possesses several attributes, which demonstrate important properties of the entities represented by the class. Also several other classes are attached under each class, demonstrating other more complex properties of their parent class. For instance, the Name of a network node is an attribute of the class QRGH, while the ports of the node (i.e., network interfaces) are represented by objects of class SRUW, children of the related QRGH class.

ATM Management: Challenges and Solutions for the Heterogeneous Environment node

11

NodeID, nodeType, Name, Address, maxPorts, Status, UpTime ports Outport

OutportID, PeerNodeID, PeerPortID, maxVPs, maxBw VPI, allocBw, usedBw, acceptedCalls, rejectedCalls VPLsOut VCLsOut

Inport

VCI, allocBw, usedBw

InportID, PeerNodeID, PeerPortID, maxVPs, maxBw VPLsIn

VPI, allocBw, usedBw, acceptedCalls,rejectedCalls

VCLsIn

VCI, allocBw, usedBw

CrossConnections VPCrossConnections

PortIn, VPIin, PortOut, VPIout

VCCrossConnections

PortIn, VPIin, VCIin, PortOut, VPIout, VCIout

Figure 3 -The CAMMI MIB The root class is QRGH, a class which represents the main properties of a network node of any type (e.g., switching node, terminal node, etc.) Below QRGH, various child classes are linked. Although, the CAMMI MIB is mainly oriented towards representing switching nodes, other types of nodes can be accommodated, either by omitting meaningless classes, or by extending the MIB with additional classes below the node level. For example, in the case of a terminal adapter, the &URVV&RQQHFWLRQV class is meaningless; instead, an instance of the QRGH class and a single instance of the SRUWV class suffice. On the contrary, in order to represent a specialised device such as a policing unit, several classes may need to be omitted and additional classes or attributes (e.g., the aggregate cell count in the 93/ class) may need to be added. A brief description of the various classes in the CAMMI MIB is given in the sequel:

12 • QRGH: This class contains general information about a network node. There is one instance for each node of the network. Attributes of this class include the node’s identifier, type, name, address, maximum number of ports, status, and uptime. • 3RUWV: These classes contain port information and there is one instance for each port of a specific network node. The meaning of “port” is not limited just to the ports of a switching node, but covers every network interface of a given node, i.e., the point at which the node is connected to another node through a physical link. Attributes of this class include: identifier, maximum number of VPs, and maximun bandwidth. The class is divided in two subclasses: 2XWSRUW and ,QSRUW. Besides the above mentioned common elements, there are other attributes that define the peer node identifier and peer port identifier to which the particular port is connected. • 93/V2XW and 93/V,Q: They contain information about the Virtual Path Links (VPLs). There is one instance for each VPL of the parent port. Each VPL is described by its VPI, the bandwidth allocated to it (allocated bandwidth), the bandwidth used by calls (used bandwidth) and the number of accepted/rejected calls. The Virtual Channel Links (VCLs) within this VPL are represented as child classes of the 93/ class. Attributes of the 9&/V classes include the VCI, the allocated bandwidth and the used bandwidth. • 93&URVV&RQQHFWLRQV: It contains cross-connection information for the various VPLs. Attributes of this class include the in-port identifier and VPI, and the out-port identifier and VPI. • 9&&URVV&RQQHFWLRQV: It contains cross-connection information for the various VCLs. Attributes of this class include the in-port identifier, VPI, and VCI, and the out-port identifier, VPI, and VCI. It is evident that these classes are capable of holding a set of information items that is useful for experiments on resource allocation, routing and charging. However, the information model could well be extended to support additional items of ATM management information. This can be easily done, either by enriching the existing classes with new attributes, or by adding new classes to the tree. For example, one could add a buffer attribute in the SRUW class, in order to allow monitoring of the status of the buffer that is associated with a particular port of an ATM switch. Similarly, the model could be also enhanced with information items that are out of the scope of an ATM device. This is particularly important in cases where the desired management information has to be extracted from various devices of


13

a heterogeneous network. Therefore, this information model should not be viewed as a “finalised” structure, competitive to the numerous MIBs supported by the various vendors. Rather, it should be regarded as an alternative template, whose purpose is to abstract information and thus to facilitate the integrating with these exhaustive and elaborate vendorsupplied MIBs. Such abstraction particularly applies in the case of management applications focusing on specific tasks, which can be easily accommodated by a simple but coherent model. Furthermore, the model may be extended for improving existing management functions or adding new ones. In these cases, however, the overhead of extending the model and enhancing the already existing management applications must be taken into account. As a result, the technique applied in the scope of the WATT project for monitoring ATM switches of different manufactures, can be generalised in order to serve as a guideline for building proprietary management applications in heterogeneous ATM environments. The main step of this systematic approach involves reviewing the MIBs of the managed devices and extracting common items which are of interest with respect to the goals of the management application to be developed. Figure 4 summarises the tactic followed for the identification of the CAMMI MIB in the context of the WATT project, for remote monitoring of trial activities performed on the EXPERT platform.

4.

Conclusions

Currently, standardisation efforts towards a unified framework for the management of ATM networks have been limited to general guidelines, or to addressing very specific areas of ATM management (such as the UNI by means of the ILMI specification). Therefore, most vendors stay attached to traditional management methods such as SNMP and extend these to provide their own proprietary solution. As a result, the development of an integrated platform for managing a heterogeneous, multi-vendor network requires a considerable implementation effort, usually building upon some generic commercial management platform. An alternative approach is that of WebBased Management, which engages the uniform and well-accepted WWW user interface for the retrieval of management information. Modern Internet technologies such as Java combined now with distributed object technologies (e.g. CORBA) make it possible to develop distributed Webbased management applications that deal efficiently with the implications of

14 managing heterogeneous devices. Both approaches require an abstract highlevel information model that contains the management information. This paper proposes a unified ATM management information model that integrates information fields from various existing MIB trees towards the effective management of heterogeneous environments either through integrated, general-purpose management platforms, or through Web-based solutions. In particular, the proposed information model has been used for the development of a Web-based management system for the remote monitoring of trial activities performed on a heterogeneous ATM environment. Whether the approach of using integrated, general-purpose management platforms or the approach of going with a Web-based solution will dominate is still an open question and probably difficult to answer. Anyone could argue convincingly for both. It seems that where lightweight implementations with low installation and operation costs are needed, or the ability to manage networks remotely is required (e.g. CNM), the Web-based solution will prevail. However, for Network Operators with large investments in their network equipment and with the ability and resources to support and maintain complex platforms, the integrated management platforms have a lot to offer towards efficient and consistent management throughout the entire network. ATM Network Environment (EXPERT testbed) ATM Forum M IBs (SNM P and CM IP based) Common Set of Data Proprietary M IBs (SNM P based)

Experimental M IBs (CM IP based)

CAM M I M IB

M anagement Application M onitoring of trial activities on the EXPERT testbed

Figure 4 - Identification of the CAMMI MIB References [1] ATM Forum Technical Committee, af-nm-0019.000, “Customer Network Management (CNM) for ATM Public Network Service (M3 Specification)” , October 1994. [2] ATM Forum Technical Committee, af-nm-0020.000, “M4 Interface Requirements and Logical MIB” , October 1994.


15

[3] Peter Alexander and Kacey Carpenter, Stratacom Inc. “ATM Net Management: A Status Report”, Data Communications Magazine, Sepetember 1995. [4] Roch H. Glitho and Stephen Hayes “Telecommunications Management Network: Vision vs. Reality”, IEEE Communications Magazine, March 1995. [5] Henry J.Fowler “TMN-Based Broadband ATM Network Management”, IEEE Communications Magazine, March 1995. [6] P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall, IETF RFC1987, “Ipsilon’s General Switch Management Protocol Specification, Version 1.1”, August 1997. [7] Object Management Group, “The Common Object Request Broker: Architecture and Specification”, 2.0 ed., July 1995. [8] Telecommunications Information Networking Architecture Consortium (TINA-C), “Overall Concepts and Principles of TINA”, ver. 1.0, February 1995. [9] ATM Forum Technical Committee, af-ilmi-0014.000, “Integrated Local Management Interface (ILMI) Specification Version 4.0” , September 1996. [10] ATM Forum Technical Committee, af-nm-0074.000, “M4 Network-View Requirements and Logical MIB Addendum” , January 1997. [11] K. Krishman, and W. Fuller, “An Overview of MIBs for ATM Network Management”, 53 Bytes, Vol. 5, No 4, December 1997. [12] Fore ASX-200 ATM Switch, User Manual. [13] Daniel Minoli, Thomas Golway, “Planning & Managing ATM Networks”, Manning Publication Co. 1997, ISBN 0-13-262189-4. [14] ITU-T. Recommendation M.3010 “Principles for a Telecommunications Management Network”, Geneva, Switzerland, May 1996. [15] Electronic information on the EXPERT platform, available on the WWW through the URLs: http://www.telecom.ntua.gr/watt/wdb and http://www.snh.ch/projects/watt/expert. [16] WATT AC235, “Technical Annex”, March 1996. [17] E. Vayias, J. Soldatos, N. Mitrou, K. Kontovasilis, and G. Kormentzas, “Monitoring Networks over the Web: Classification of approaches and an implementation”, IEEE International Conference on Telecommunications (ICT98'), Chalkidiki, Greece. [18] WATT AC235 Deliverable 06, AC235/WATT/WP21/DS/R/P/006/A1, “Interface between the Database and the Network & Service Management System”, November 1997. [19] Internet Engineering Task Force: RFC 1695, “Definitions of Managed Objects for ATM Management”. [20] WATT AC235 Deliverable 05, AC235/WATT/WP21/DS/R/P/005/A1, “Specification of Database to Network & Service Management system Interface”, May 1997.