U.S. patent application number 09/088463 was filed with the patent office on 2001-12-13 for method for computer internet remote management of a telecommunication network element.
Invention is credited to BARKER, WILLIAM E., CONNELLY, LISA M., EGGERT, MARVIN A., FOLEY, MICHAEL P., MACFARLANE, KENNETH R., PARSONS, PHILIP M., RAI, GIRISH, ROG, JEROME E., VANGSNESS, KURT A..
Application Number | 20010052006 09/088463 |
Document ID | / |
Family ID | 22211533 |
Filed Date | 2001-12-13 |
United States Patent
Application |
20010052006 |
Kind Code |
A1 |
BARKER, WILLIAM E. ; et
al. |
December 13, 2001 |
METHOD FOR COMPUTER INTERNET REMOTE MANAGEMENT OF A
TELECOMMUNICATION NETWORK ELEMENT
Abstract
In accordance with the invention, a method is provided for
remotely managing a plurality of network element of a
telecommunications network through a special communication link
including a computer internet such as a local area network, the
world wide web or the Internet. A management computer is connected
to an element management system server through a communication link
including the computer internet At least one of the plurality of
network elements is also coupled to the element management server
through the computer internet and the at least one of the plurality
of network elements is managed via communications conveyed through
the element management server between the management computer and
the at least one network element. Preferably, management is
facilitated by the management server generating an interactive web
page at a client workstation with objects associated with
management of the at least one network element. The interactive web
page is transmitting from the management server through the
computer internet to the management computer and displayed at the
interactive web page at the management computer for management
communications between the management computer and the network
element. Objects of the interactive web page include objects
associated with preferably all three of operation, administration
and maintenance of the network lement. The interactive web page
includes detailed status summary page for each network element of
the telecommunications network, a relatively high system status
summary of all the plurality of network elements and a list of all
active alarms within the telecommunications network. The plurality
of network elements each have an associated applications processor
with a management agent application for interfacing the element
management server with the network element. The application
processor includes a maintenance application for performing
maintenance of the network element command request are interfaced
from the element management server through the management agent
application to the maintenance application to selectively perform
maintenance tasks. The element management server is provided with
application processor specific events and command
acknowledgments.
Inventors: |
BARKER, WILLIAM E.; (GENEVA,
IL) ; CONNELLY, LISA M.; (LISLE, IL) ; EGGERT,
MARVIN A.; (AURORA, IL) ; FOLEY, MICHAEL P.;
(ELMWOOD PARK, IL) ; MACFARLANE, KENNETH R.;
(WHEATON, IL) ; PARSONS, PHILIP M.; (LISLE,
IL) ; RAI, GIRISH; (BARTLETT, IL) ; ROG,
JEROME E.; (BARTLETT, IL) ; VANGSNESS, KURT A.;
(AURORA, IL) |
Correspondence
Address: |
CARMEN B. PATTI
211 WINSLOW COURT
NAPERVILLE
IL
60565
|
Family ID: |
22211533 |
Appl. No.: |
09/088463 |
Filed: |
May 31, 1998 |
Current U.S.
Class: |
709/223 ;
709/203 |
Current CPC
Class: |
H04L 41/046 20130101;
H04L 41/0213 20130101; H04L 41/045 20220501; H04L 41/028 20130101;
H04L 41/22 20130101; H04L 41/0253 20130101 |
Class at
Publication: |
709/223 ;
709/203 |
International
Class: |
G06F 015/16; G06F
015/173 |
Claims
What is claimed is:
1. In a telecommunications network having a plurality of network
elements, a method of managing at least one of the network
elements, comprising the steps of: connecting a management computer
to an element management server through a communication link
including a computer internet; coupling the at least one of the
plurality of network elements to the element management server
through the computer internet; and managing the at least one of the
plurality of network elements via communications conveyed through
the element management server between the management computer and
the at least one network element.
2. The method of claim 1 in which the step of managing includes the
steps of generating from the management server an interactive web
page with objects associated with management of the at least one
network element, transmitting the interactive web page from the
management server through the computer internet to the management
computer, and displaying the interactive web page at the management
computer for management communications between the management
computer and the at least one network element.
3. The method of claim 2 in which the objects of the interactive
web page include objects associated with at least one of operation,
administration and maintenance of the at least one network
element.
4. The method of claim 3 in which the web page includes objects
associated with all three of operation, administration and
maintenance of the at least one network element.
5. The method of claim 2 including the step of generating signals
through interaction with the interactive web page at the management
computer to achieve at least one of command, control and fault
management of the network element.
6. The method of claim 5 in which the step of generating includes
the step of generating signals through interaction with the
interactive web page at the management computer to achieve all
three of command, control and fault management of the network
element.
7. The method of claim 2 in which the interactive web page includes
a menu of individual maintenance unit command options.
8. The method of claim 2 in which the interactive web page includes
a detailed status summary page for the at least one individual
network element.
9. The method of claim 2 in which the interactive web page includes
a high level system status summary of all the plurality of network
elements.
10. The method of claim 2 in which the interactive web page
includes a list of all active alarms within the telecommunications
network.
11. The method of claim 1 in which the step of coupling includes
the step of coupling the at least one of the plurality of network
elements to an associated applications processor with a management
agent application for interfacing the element management server
with the network element.
12. The method of claim 11 in which the AP includes a maintenance
application for performing maintenance of the network element, and
the step of coupling includes the step of interfacing command
request from the element management server through the management
agent application to the maintenance application to selectively
perform maintenance tasks.
13. The method of claim 11 in which the step of interfacing by the
network element includes the step of providing the element
management server with AP specific events and command
acknowledgments.
14. The method of claim 1 in which the computer internet is the
world wide web and the steps of connecting and coupling include the
step of operating world wide web based JAVA applications at the
management computer and the element management server.
15. The method of claim 1 in which the network element has a
management agent application which responds to various actions and
the step of managing includes the step of correlating responses
from the agent with the actions which caused the actions.
16. The method of claim 1 in which the step of managing includes
the step of automatically routing command responses, polling
results and traps back to the management computer.
17. The method of claim 1 in which the network element has a
management agent application, and including the steps of queuing
multiple commands simultaneously received from a plurality of
different management computers including the one management
computer, and successive responding to the multiple commands by
sending reponses to appropriated ones of the different management
computers that originated the commands, respectively.
18. The method of claim 1 in which the step of connecting includes
the step of enabling the connection in response to entry of a
correct password at the management computer.
19. The method of claim 18 including the step of encrypting the
password prior to sending to the management server.
20. The method of claim 1 in which the step of managing includes
the steps of selecting network element attributes from a plurality
of network element attributes available for polling, and polling
for only the selected network element attributes.
21. The method of claim 1 in which the step of managing includes
the steps of receiving requests at the network element from a
plurality of different management computers to poll for network
element attributes which are the same, polling for the attributes
which are the same only as if there were only one request for
polling of the same attributes, and providing the results of the
polling of the same attributes to all of the different management
computers that requested polling of the same attributes.
22. The method of claim 1 including the step of automatically
updating a list of active alarms of the network element upon
occurrence of either one of actuation of a new alarm and clearing
of a former alarm.
23. In a communication network having a plurality of network
elements, a method for managing the network element, comprising the
steps of: selectively running a management application at a
plurality of different work station for command, control and fault
management of the network element; interfacing an element
management server through a computer internet to the plurality of
different work stations to provide distributed network element
management services to the client application at all of the
plurality of work stations; and interfacing the network element
with the element management server through a management agent
application associated with the network element for communicating
command acknowledgment and command requests through the computer
internet between the network management server and the network
element.
24. The method of claim 23 in which the element management server
includes an object server having managed objects representing the
network element and other resources of the system.
25. The method of claim 23 in which the step of communicating
command acknowledgment and command request between the element
management server and the network element is conducted using a
simple node management protocol.
26. The method of claim 23 in which the step of communicating
includes the steps of establishing a set of SNMP service objects
that communicate with the SNMP network element; establishing a SNMP
mediator process that communicates with the SNMP service objects;
polling for the SNMP service objects; and converting commands of
the managed object to SNMP set commands.
27. The method of claim 23 including the step of filtering events
of the network element.
28. The method of claim 27 in which the events of the step of
filtering events includes at least one of the events of alarm
notification, state change and configuration change to the element
network system server.
29. The method of claim 23 in which the step of interfacing the
network element includes the step of maintaining within the element
management server a list of current active alarms within the
network.
30. The method of claim 23 including the steps of monitoring the
operation of events within the communication network, and
diminishing the operation of events to prevent overloading of the
communication system.
31. The method of claim 23 in which the management application is
written in JAVA, and the step of interfacing the work stations with
the element management server is performed through an interactive
web page that visually displays a menu of command, control and
fault management options.
32. The method of claim 31 in which the web page includes a
separate status summary display for each of the command, control
and fault management options.
33. The method of claim 3 in which the web page includes a display
of a list of active alarms for all network elements within the
communication network.
Description
BACKGROUND OF THE INVENTION
[0001] This invention generally relates to a telecommunication
network and more particularly to managing network elements of the
telecommunications network.
[0002] Network management systems in which a management computer,
or work station, runs a management computer program, or management
application, to manage a set of management agent computer programs,
or management agents, associated with a corresponding set of
network elements are known. Such known management systems employ a
communication protocol that employs a management information base
for each network that defines the interface between the management
application and the network element. These management systems are
implemented only at the individual network elements and have not
been successfully employed for large scale management of a
telecommunications network.
SUMMARY OF THE INVENTION
[0003] In accordance with the invention, a method is provided for
remotely managing a network element of a telecommunications network
through a special communication link including a computer internet.
A management computer is connected to an element management system
server through a communication link including a computer internet.
At least one of the plurality of network elements is also coupled
to the element management server through the computer internet and
the at least one of the plurality of network elements is managed
via communications conveyed through the element management server
between the management computer and the at least one network
element.
[0004] Preferably, management is facilitated by the management
server generating an interactive web page at a client workstation
with objects associated with management of the at least one network
element. The interactive web page is transmitting from the
management server through the computer internet to the management
computer and displayed at the interactive web page at the
management computer for management communications between the
management computer and the network element. Objects of the
interactive web page include objects associated with preferably all
three of operation, administration and maintenance of the network
element.
[0005] In an embodiment, the interactive web page includes a
detailed status summary page for each network element of the
telecommunications network, a relatively high system status summary
of all the plurality of network elements and a list of all active
alarms within the telecommunications network.
[0006] The plurality of network elements each have an associated
applications processor with a management agent application for
interfacing the element management server with the network element.
The application processor includes a maintenance application for
performing maintenance of the network element command request are
interfaced from the element management server through the
management agent application to the maintenance application to
selectively perform maintenance tasks. The element management
server is provided with application processor specific events and
command acknowledgments.
[0007] Preferably, the computer internet is the world wide web, or
Internet, connections and communications are achieved through
operating world wide web based JAVA applications at the management
computer and the element management server. Alternatively, the
computer internet is a local area network. In this way, multiple
management computers at different remote locations are capable of
accessing any and all of the network elements of the
telecommunications network. Multiple commands simultaneously
received from a plurality of different management computers are
queued and the multiple commands are responded to by sending
responses to only the appropriate ones of the different management
computers that originated the corresponding commands. Connection of
the management computers to the special element management server
is preferably enabled only in response to entry of a correct
password at the management computer. Preferably, the password is
encrypted prior to being sent to the element management server.
[0008] Thus, the invention also includes the concept of managing
all of the plurality of network elements from a plurality of
different remote management computers by performing the steps of
selectively running a management application at a plurality of
different work station for command, control and fault management of
the network elements, interfacing an element management server
through a computer internet to the plurality of different work
stations to provide distributed network element management services
to the management application at all of the plurality of work
stations, and interfacing the network element with the element
management server through a management agent application associated
with the network element for communicating command acknowledgment
and command requests through the computer internet between the
network management server and the network element.
[0009] Thus, a method is provided which overcomes the deficiencies
of known network element management systems and methods that
provides distributed network management for enhanced efficiency and
convenience which has the features needed for large scale
management of a telecommunications system.
[0010] Appendix A provides a definition of terms and a glossary of
acronyms included in this application.
BRIEF DESCRIPTION OF THE DRAWINGS
[0011] The forgoing advantageous features will be made apparent and
other features of the invention will be described in the detailed
description of the preferred embodiment that is given with
reference to the several figures of the drawing, in which:
[0012] FIG. 1A is a functional block diagram of an embodiment of
the network element management system in which the management
computer, or work station, is employed to control, or manage, a
plurality of network elements of a telecommunication network
through a public switched telephone network (PSTN);
[0013] FIG. 1B is a functional block diagram of an embodiment of
the network element management system in which the management
computer, a work station, is employed to control, or manage, a
plurality of network elements of a telecommunications network
through a computer internet;
[0014] FIG. 1C is a functional block diagram of an embodiment of
the network element management system in which the management
computer, or work station, is employed to control, or manage, a
plurality of network elements of a telecommunication network
through a local area network;
[0015] FIG. 2 is a functional block diagram of an element
management system in which the management of a network element is
accomplished at a web enabled workstation with offthe-shelf
components and proprietary applications;
[0016] FIG. 3 is a functional block diagram of the major software
of the architecture of the invention;
[0017] FIG. 4 is a functional block diagram for the element
management system server and a client workstation with an
associated network element and its associated simple management
protocol (SNMP) agent.
[0018] FIG. 5 is a functional block diagram showing element
management system client configuration;
[0019] FIG. 6 is a table of terms associated with the managed
object model in accordance with the invention;
[0020] FIG. 7 is a functional block diagram showing the derivation
of application process;
[0021] FIG. 8 is a functional block diagram of managed object
classes and their containment relationship that may be used to
manage to application process;
[0022] FIG. 9 is a block diagram showing a network element, AP,
service object and the data it contains and an ECP managed object
using a protocol other than SNMP for communication;
[0023] FIGS. 10, 11, 12 and 13 show representative web pages in
accordance with the invention;
[0024] FIG. 14 is a functional block diagram of a network element,
AP, software architecture;
[0025] FIG. 15 shows element manager client application programming
interfaces;
[0026] FIG. 16 shows the service objects resident on the server
with which client applications interact;
[0027] FIG. 17 shows the callback interfaces defined in the
EMAPI;
[0028] FIG. 18 shows data types defined in the EMAPI;
[0029] FIG. 19 shows the relationship between client, application,
specific service object, and the internal server representation of
managed object instances;
[0030] FIG. 20 shows filter criteria which are valid for each event
category; and
[0031] FIG. 21 shows an EMAPI specific exception defined with an
EMAPI exception code containing one of a plurality of values.
DETAILED DESCRIPTION
[0032] FIG. 1A illustrates a system 10 in which the method of
managing a network element 14 at a web enabled workstation 16 is
shown. A management computer 26 associated with an element
management system client 28 is connected to a network element 14
and element management system client 32 through a public switched
telephone network (PSTN) 33.
[0033] FIG. 1B illustrates a system 34 in which the method of
managing the network element 14 in a telephonic network at web
enabled workstation 16 is shown. Network element 14 is connected
through a telephonic computer network 35 to a computer internet 36.
The management computer 26 associated with the element management
system client 28 is connected to the element system management
system sever 32 over a telephonic system network 34 through the
computer internet 35 and a telephonic link 38.
[0034] FIG. 1C illustrates a system 40 in which the managing of the
network element 14 is performed from the management computer 26
with the associated element management system client 28 with the
element management system 32 via a local area network 42.
[0035] The method in accordance with a the invention enables the
leveraging of off-the-shelf technology to enable additional client
visible features, while extending to subsequent releases and other
projects, with little to no increase to cost of goods.
[0036] Referring to FIG. 2, the network element 14 is provided
through the element management system client 28 and a SNMP-based
element management platform. The method in accordance with the
invention works with off-the-shelf components 44, 45, 46, 47, 48
and 49 and propriety applications 50, 52, 54, 55 and 56. The
off-the-shelf technologies include: the HTML and Java apps 44, the
web browser 45, the web server 46, Transport Protocols [TCP/IP
UDP/IP] 47, CORBA 48, and the SNMP element management platform (HP
OpenView Network Node Manager [HPOVNNM]) 49, alternatively a
Carnegie-Mellon University (CMU) SNMP library is used, and the
Transport Protocols (TCP/IP protocol suite).
[0037] The client executes the Client Interface and propriety
applications via Web pages. Microsoft Internet Explorer and
netscape browsers are supported as are the web-enabling devices for
PCs and X-terminals. Through a Web-based graphical client
interface, clients' commands generate HTTP requests to the element
management system server. The server gathers information,
dynamically generates a Web page, and sends the results/output to
the web browser for display.
[0038] Client applications (JAVA Applets) include proprietary
applications such as, an active alarm list browser, a system alarm
summary, and a network element detailed status display. Client
applications communicate with the server via an object oriented
interface to the element manager API (EMAPI) 55 through the
distributed object request architecture (CORBA) 48. This interface
provides a consistent interface to all managed objects in the
network, and hides the implementation details associated with the
element manager platform.
[0039] The element management system server 32 executes
applications to serve information to clients via CORBA middleware.
CORBA will serve as the IPC for functions residing on the server,
thereby eliminating any platform-specific IPC from the
implementation, and providing for distribution of functionality to
multiple processors if needed in the future for performance.
Communication between the element management system and the managed
elements is via SNMP. System status is obtained through SNMP
polling and audits, SNMP traps are used for real-time
notifications, and SNMP sets are used for command and control. The
element management system has no persistent store over a system
boot, and requires a handshake with each network element when the
element management system is initialized; however, it does store
information for use by multiple clients, so it does not need to get
this information for each request from a new client. Command and
alarm output is displayed via the Web browser based display, as
well as sent to an executive control processor read only
printer.
[0040] The network element 14 is responsible for processing event
and alarm notifications to the element management system via SNMP,
and for issuing commands for obtaining information from
applications. A management information base (MIB) 56 conventions is
defined for managing network elements in the system. The MMB 56
conventions define command execution, message sequencing, and audit
provisions, that are used within the element management system
architecture but are not provided for in SNMP.
[0041] The following is a description of the functional block
diagram shown in FIG. 3 of the software components of the
invention.
[0042] Element Management Server Software Components
[0043] The element management system client 28 is the client's
interface to the element management system server 32. It consists
of the web browser 45 and the JAVA applets 44.
[0044] Web Browser: The web browser 45 is the interface to end
client, a host for JAVA applets 44, and a virtual machine for JAVA
execution. Netscape and MS Explorer are both supported (for
platforms that support these browsers).
[0045] JAVA Applets: JAVA Applets 44 include but are not limited to
the following:
[0046] System Summary Application: provides a hierarchical view of
alarm status, summary icons for parent nodes, color encoding of
alarm states, and point/click navigation to Network Element
Detailed Status screens;
[0047] Network Element Detailed Status Application: provides a
custom view of each network element, displays static configuration
data, and maintenance state of all managed objects;
[0048] Active Alarm List Browser Application: displays the current
list of outstanding alarms in the system.
[0049] The major software components of the Element management
system server include:
[0050] HTTP Web Server 58: processes HTTP requests from the element
management system Client that retrieve and download HTML pages and
Java applets (from the element management system Server hard disk)
associated with the element management system Client application
(from the element management system Server hard disk).
[0051] Orbixd 60: Iona Orbix daemon, the object request broker
[0052] Orbix Naming Service 64: an Orbix process that services
object locator requests
[0053] Object Server 66: a single UNIX process that provides most
of the element management system server functionality. It is
described in detail in later sections of this document.
[0054] Active Alarm Manager 68: provides for client access to
alarms currently active in the system and represents the element
management system component of the Client Alarm List
application.
[0055] HPOV processes 70: provide the network management system
infrastructure (SNMP API, trapd, postmaster daemon). Alternatively,
the network management system is performed by a CMU SNMP
library.
[0056] ROP Formatter 72: translates binary message codes into ASCII
text in accordance to ECP ROP formatting practices. It then directs
the formatted ASCII output to the ROP stream.
[0057] Command Line Interpreter 76: provides an ASCII command
language interface to allow the technician to enter commands at the
element management system and observe results.
[0058] LX Proxy 78: UX message interface (bridge between System V
message queues and sockets) to an internal database subsystem (IDS)
79.
[0059] INTERNAL DATABASE SUBSYSTEM (IDS) 79: ECP Ring Database
Update triggers the object server (through UX Proxy) when an AP is
added to the system.
[0060] Application Processor (AP) Components
[0061] The following components reside on the AP 80:
[0062] SNMP Agent 81: sends and receives messages between the AP
and element management system infrastructure. It is also
responsible for the throttling traps to prevent overloading the
system.
[0063] the internal database subsystem (IDS) 79: ECP Ring Database
Update downloads AP configuration data and updates from a ECP
82.
[0064] ECP Agent 86: processes IDS triggers, notifies AP
applications of changes to their configuration data, and send
configuration changes (events) to the event handler.
[0065] Command Handler 88: Handles AP administration command
requests issued from either the GUI based or text based client
interfaces. Executes a RAP 90 to complete the administration
request. Returns the completion information back to the element
management system server. Keeps list of active commands in AP
Command Table.
[0066] Text Command Interpreter 92: A text based interface for
special situations in which the GUI based interface presented by
the element management system Server is not available to the
client.
[0067] Event Handler 94: The Event Handler is responsible for
handling both the filtering and forwarding of events (alarms,
notifications, state changes, configuration changes) to the element
management system. Updates the State and Alarm Tables in NEST.
[0068] NE Status Table 96: also known as the NEST, stores
maintenance object state and alarm information, as well as the list
of active commands.
[0069] RAPs 90: The Resource Administration Process is an
application processing interface (API) for fork-exec'ing a process
and obtaining the results of the process execution
[0070] Other platform and application software 98: encompasses all
the entities involved in command execution that aren't otherwise
displayed on the diagram due to the desire not to get into too much
detail. This includes the RCC resource monitors and resource
daemons that come into play when executing an RCC 100 based element
management system command (e.g., remove DS1 digital switch), as
well as the software application specific to a given resource
(e.g., RCS, MMA, CCM, SS7).
[0071] RCC 100: as shown it is the call to RCC 100 APIs to generate
RCC events for taking a resource out of service. This bubble only
comes into play when RCC-based element management system commands
are executed. Since this is only an overview, the case for
non-RCC-based element management system commands (e.g., diagnose
DS1) is not shown.
[0072] AP State Monitor 104: a bridge mapping RCC 100 events into
locally understood AP 80 events.
REFERENCES
[0073] The following describes the architecture of the element
management system server and the distributed client
applications.
[0074] The following provides reference material that may be useful
as background information, the disclosures of which are
incorporated by reference.
[0075] Object Oriented Technology
[0076] Taylor, David A. "Object Oriented Technology: A Managers
Guide". Addison-Wesley, 1993. ISBN 0-201-56358-4.
[0077] Booch, Grady. "Object Oriented Analysis and Design with
Applications". Benjamin/Cummings. 1994. ISBN 0-8053-5340-2
[0078] Network Management
[0079] Stallings, William. "SNMP, SNMPv2, and CMIP. The Practical
Guide to Network-Management Standards". Addison-Wesley, 1993. ISBN
0-201-63331-0.
[0080] Rose, Marshall T. "The Simple Book--An Introduction To
Internet Management" Prentice-Hall. 1994. ISBN 0-13-177254-6.
[0081] "Hewlett-Packard OpenView Network Node Manager 4.1 Technical
Evaluation Guide", Hewlett Packard Corporation. April 1996.
[0082] "HP OpenView Using Network Node Manager", Hewlett Packard
Corporation. April 1996.
[0083] Carnegie-Mellon SNMP libraries;
http://www.net.cmu.edulprojects/SNM- P.
[0084] Web Technology
[0085] The World Wide Web Consortium Web Site
<http://www.w3.org/> Contains references, white papers and
RFCs relating to web technology.
[0086] Corba
[0087] Orfali, Robert et. al. "The Essential Distributed Objects
Survival Guide". John Wiley and Sons. 1996. ISBN 0-471-12993-3.
[0088] Vinoski, Steve. "distributed Object Computing With CORBA".
Hewlett-Packard Company, 1993. (Article published in the
July/August 1993 issue of C++ Report magazine.
[0089] The Object Management Group Web Site
<http://www.omg.org/>. Contains standards documents, white
papers and links to information on CORBA.
[0090] FIG. 4 shows a summary of the principle functional
components on the element management system server and a single
client workstation. A single managed network element 14 is shown
with its associated SNMP Agent. A table in FIG. 4 provides a
definition of terms used in the subsequent description.
[0091] Element Management System Client Components
[0092] Element management system client 28 components consist of
web browser hosted applications that provide network element
command and control and fault management. These web browser hosted
applications provide a graphical client interface based client
interface in a cross platform environment. The server
infrastructure supports applications for performance and security
management.
[0093] The client interface to the server is described in the EMAPI
55 described in a pending patent application previously
incorporated by reference herein. The EMAPI 55 is implemented
utilizing an industry standard object management group interface
description language (IDL). The interfaces and semantics of the
EMAPI 55 enable client application processes to utilize this
interface to provide management of the system. Distribution of this
interface is achieved through use of the Common Object Request
Broker Architecture (CORBA) which provides a distributed object
request architecture.
[0094] Client applications utilize the EMAPI 55 to access service
objects on the server which provide access to attributes of the
managed objects, provide maintenance operations for those managed
objects, and allow the client to register for notifications of
attribute changes and event notifications (which typically will be
command acknowledgments and command results).
[0095] The development of client applications depends only on the
EMAPI 55 interface specification. The use of CORBA allows the
clients to be distributed and implemented in a different language
(such as Java) than the server (in C++).
[0096] The element management system server 32 consists of a set of
software components that provide an SNMP network management
framework and distributed network management services to client
applications. The method in accordance with the invention uses
off-the-shelf software components. The off-the-shelf software
components included in the element management system are:
[0097] (a) HTTP Web Server
[0098] (b) Netscape or Microsoft.RTM. Internet Explorer Web
Browser
[0099] (c) Orbix Daemon
[0100] (d) Orbix Naming Service
[0101] (e) HP OpenView Network Node Manager (HPOVNNM) or
alternatively, a CMU SNMP library package
[0102] The element management system server 32 software components
that are provided by the applicant include:
[0103] (a) object server 66
[0104] (b) active alarm manager 120
[0105] (c) unix subsystem proxy
[0106] (d) read only printer formatter
[0107] (e) command line interpreter
[0108] The first two components, the object server 66 and the
active alarm manager 120, provide the bulk of the server
functionality required to support the element management system
client applications. The other three components serve important
supporting roles.
[0109] Off the Shelf Element Management System Server
Components
[0110] HTTP Web Server (Generally called Web Server)
[0111] This off the shelf functionality serves static and dynamic
web pages to client browsers. The web server must provide support
for HTTP 1.0 (or greater), CGI scripts and provide a built in API
for the creation of dynamic web pages "on the fly". The Web server
supports the following:
[0112] CGI script execution.
[0113] Automatic startup from init (no human intervention to start
server)
[0114] logging of page access. A log file containing the IP address
and the URL referenced. This is used to examine access patterns and
detect and trace access from unauthorized sources.
[0115] Web page access control based on client name and password.
The server supports basic server authentication, and can be
enhanced to support SSL (Secure Socket Layer) if encryption of the
browser to server connection is required.
[0116] Secure administrator administration of web server including
administration of the client name and password for access
control.
[0117] Orbix Web Server
[0118] Part of the Orbix product. Required to support CORBA within
a Web browser. Enables JAVA applets downloaded to the client to
communicate via CORBA to the element management system Server.
[0119] Orbix Daemon (CORBA ORB)
[0120] The CORBA ORB represents the server side of CORBA and is
provided by an offthe-shelf CORBA implementation. The Common Object
Request Broker Architecture (CORBA) is utilized in this
architecture to provide inter-process and inter-processor
communication between clients using the EMAPI 55.
[0121] CORBA is a platform-independent and language-independent
programming and execution environment for distributed objects.
[0122] CORBA automates many common network programming tasks:
[0123] object registration
[0124] location and activation
[0125] request multiplexing/de-multiplexing
[0126] framing and error-handling
[0127] parameter marshaling and de-marshaling
[0128] operation dispatching
[0129] Access to remote object services is transparent to the
caller. Clients do not need to know:
[0130] where the object is located
[0131] its programming language
[0132] its operating system
[0133] any other system aspects that are not part of an object's
interface
[0134] Orbix Naming Service
[0135] The Orbix Naming Service daemon provides symbolic lookup of
servers on the network and is necessary to support the IIOP
protocol.
[0136] HP Open View or Alternatively CMU SNMP Library
[0137] Functional Description
[0138] The HP OpenView Network Node Manager (HPOVNNM) or CMU SNMP
library product provide the lowest-level network management
infrastructure for delivery of SNMP SET and GET requests and
receipt of SNMP traps. This infrastructure will deliver GET and SET
requests from the element management system Server to the SNMP
agent and receive traps on the standard trap UDP port and forward
them to the SNMP Mediator.
[0139] Role of HP OpenView Network Node Manager
[0140] When used in the invention, HP OpenView Network Node Manager
(HPOVNNM) is used as part of the element management system server
32 infrastructure. While only a subset of the HPOVNNM runtime
system will be in active use, the full HPOVNNM system will be
installed on the element management system server. The following
major components will be installed. Those pieces of HPOVNNM that
will be a part of the element management system server
infrastructure are shown in bold typeface.
[0141] ovspmd (OpenView System Process Management Daemon): This
process must be running to enable client-interface status-checking
programs such as ovstart to work. Since this monitor does not
support restarting terminated system processes, it will not be of
particular use in the EM Server process management scheme.
[0142] OVLicenseMgr: the license manager that controls the startup
of critical HPOVNNM runtime components and the ovw browser
application.
[0143] ovtrapd (OpenView Trap Daemon): Receive incoming SNMP traps
from each SNMP agent on a standard port and forward them to the
postmaster daemon (see below).
[0144] pmd (Postmaster Daemon): Serves as a general packet router
in the HPOVNNM infrastructure. The pmd process receives traps from
ovtrapd and forwards them to the element management system Object
Server, which has registered to receive all traps.
[0145] ovactiond: the OpenView process that manages the association
of traps to UNIXlevel actions as defined through the HP OpenView
event management software.
[0146] ovtopmd: the OpenView Topology Manager Daemon, which handles
IP discovery and layout for the HPOVNNM topology database.
[0147] netmon (Network Monitor): Discovers and monitors nodes on
the network. It processes ICMP ping to monitor nodes, and it does
simple SNMP periodic polling using the system group of MIB-2.
[0148] snmpCollect: SNMP Collection Daemon which allows clients to
define, via the HP OpenView Windows X-based GUI interface, SNMP MIB
values that are to be collected periodically. It provides ways to
define thresholds and associated actions (UNIX shell commands).
[0149] ovw (OpenView Windows): The OpenView Windows X-based GUI
provides access to map applications, an event browser, and a MIB
browser.
[0150] ovwdb (OpenView Windows Database): The OpenView Windows
topology database manager.
[0151] The HPOV SNMP API, a C-language interface to this runtime
system, is provided as part of the HPOVNNM Developer's Kit and will
be used to:
[0152] Encode and decode SNMP packets.
[0153] Set up and tear down SNMP trap sessions.
[0154] The entire platform as described is installed and active is
to support 3.sup.rd-party SNMP management applications written
specifically for HP OpenView and making use of the ovw map
framework. These applications are incorporated with minimal effort,
since off-the-shelf 3.sup.rd-party applications use the ovwdb-based
managed-object database rather than the CORBA-based Object Server
mechanism.
[0155] Administration
[0156] Some administration of the HPOVNNM infrastructure is
required if used instead of a CMU SNMP library package.
[0157] Initial configuration:
[0158] Definition of the local registration files used by HPOVNNM
to determine which processes run and to define the specific
attributes of each of these processes
[0159] Definition of the trap configuration file: this defines what
processing (including just logging) is performed on each trap
received by the HPOVNNM infrastructure
[0160] Inclusion of the HPOVNNM ovstart command in the appropriate
RCC initialization file for automatic startup of infrastructure
[0161] Configuration of the network license manager used by
HPOVNNM
[0162] Ongoing maintenance
[0163] MIB updates
[0164] License updates to the network license manager used by
HPOVNNM
[0165] Element Management System Server Components in Accordance
with the Invention
[0166] Object Sever
[0167] The object server provides a way for client applications to
receive information about network elements and other associated
managed objects and to issue commands that are executed on the
network element. To accomplish these functions, the object server
provides the following services: (1) client session registration,
(2) event distribution and screening, (3) command management, (4)
SNMP mediation, and (5) services specific to each managed object
class.
[0168] The object server is implemented as a single-threaded
process using a central event queue. However, the architecture does
not dictate this implementation. The architecture does require that
the implementation be platform and operating system neutral, and
the concern is that a multi-threaded approach would have operating
system dependencies. The sub-components that comprise the object
server could be implemented as separate processes. An example of
the latter approach is the decision to implement a second major
server component, the active alarm manager, as a separate process.
As the element management system infrastructure evolves, other
components that are currently part of the object server might be
implemented as separate processes, if necessary and feasible.
[0169] Various forms of inter-process communication may be used to
communicate between these components, but the method recommended by
this architecture is to use CORBA to remove platform-specific IPC
from the implementation, and to provide for distribution of
functionality to multiple processors if necessary for performance
optimization.
[0170] As shown in FIG. 3, the object server consists of the
following set of components, each of which supports a particular
service:
[0171] Client Session Manager 130 maintains a list of active client
sessions and audits for sessions that have terminated without
notifying the manager.
[0172] Event Distributor 140 provides event routing and
distribution. Events include SNMP Traps (received via the SNMP
Mediator) from network elements, commands, command acknowledgments,
command responses, and events generated within the element
management system. Clients of the Event distributor register a
filter with the Event Distributor to request delivery (via a
callback function) of Events matching the filter.
[0173] Event Screener 150 is for use by the Object Server only, and
supports screening events before they are seen by the event
distributor for purposes of open-ended event correlation.
[0174] Element Management System Command Handler 155 tracks active
commands and releases resources when the commands complete. The
element management system Command Handler also coordinates the
execution of commands within the element management system.
[0175] SNMP Mediator 160 provides translation between the MIB ASN.1
format and the managed object notation used in this architecture.
The SNMP Mediator also provides polling services for the SNMP
Service Objects, and conversion of managed object commands (e.g.
remove, restore) into appropriate SNMP set commands.
[0176] Managed Objects: As shown in FIG. 3, each object that
represents a network element or maintenance unit in a network
element utilizing SNMP for its protocol (e.g. AP, DS1, EIN, LAN) is
represented as a "SnmpMO" class object 170. A single instance of an
object is used for all instances of that objects class in the
system. For example, the AP service object provides attributes and
methods for all instances of AP processors in the system. In
addition to SnmpMOs, the architecture supports "Logical managed
objects" that represent managed objects that aren't directly tied
to a network element or maintenance unit. An example would be a
"System" managed object class that would provide system level
status and commands.
[0177] Active Alarm Manager
[0178] The active alarm manager 120 provides for client access to
alarms currently active in the system and represents the element
management system component of the client alarm list application.
There are two communicating entities: the AP Active Alarm Table
(AAT) managed object (of class ApActiveAlarms) residing in the
Object Server; and the Active Alarm Manager (AAM), a separate UNIX
system process on the element management system that provides
access (as defined by class AlarmManager) to client applications.
The AAM is implemented as a separate system process on the element
management system to avoid blocking the execution of the object
server when potentially large volumes of alarm data must be
delivered by the AAM (e.g., at client application startup. Since
the AAT and AAM communicate across process boundaries, all
interfaces between them are defined in IDL. Similarly, all
interfaces offered by the AAM to client applications are defined in
IDL.
[0179] Alarms for all APs are represented in the AAT managed
object, such that there is an alarm record for every class of
maintenance unit that has an alarm currently active in an AP.
Additional managed objects are introduced in the object server to
track alarms in other maintenance units related to the AP (e.g.
ApFrameActiveAlarms) or in another network element 14. As with the
AAT, however, the alarms tracked by these managed objects will be
reported to client applications via the AAM process.
[0180] The AAM system process contains a table of active alarm
records which mirrors that of the AAT managed object. At
initialization, the AAM registers with the AAT managed object for
delivery of current alarm records and notifications of subsequent
updates. Multiple clients can register alarm filters and callbacks
for delivery of alarm records that match specified filter criteria.
Client applications can change or cancel their specified filter
criteria.
[0181] UX Proxy
[0182] Provides UX messaging interface to the IDS 79 to receive and
process IDS triggers. A trigger is needed to notify the element
management system when an AP is added to or deleted from the
system. The element management system then polls the AP for its
equipage data.
[0183] ROP Formatter
[0184] Formats the events in a format consistent with the ECP ROP
formatting requirements, and sends the formatted event to the ECP
for logging and printing at the ECP ROP.
[0185] This component is a client that resides on the element
management system server and provides the following
functionalities:
[0186] Registers with the Event Distributor for all events
[0187] Utilizes the locale text formatting services to format the
raw event as a TI/OP message
[0188] Formats the events in a format consistent with the ECP ROP
formatting requirements
[0189] Includes in the message the appropriate alarm indication
[0190] Sends the formatted event to the ECP for logging and
printing at the ECP ROP
[0191] Utilizes a new message class at the ECP for reports
[0192] This mechanism will rely on a single message type for
forwarding all element management system-generated TI/OP messages.
The current interface from a mobile switch center (MSC) ECP ROP
supports specifying Alarm Level (MAN, INFO, CRIT, MAJ, MIN).
[0193] Command Line Interpreter
[0194] The command line interpreter provides an ASCII command
language to allow the technician to enter commands and observe the
command results. The input command syntax is the same PDS format
used by a proprietary system. Command reports are also formatted in
the same syntax as the existing proprietary system.
[0195] Provides ASCII based input language access to all commands
for network elements (and their maintenance units) supported by the
element management system.
[0196] Provides an acknowledgment to the input command to indicate
the disposition of the command.
[0197] Allows for multiple commands to be outstanding at one
time
[0198] Provides command sequence numbers to correlate
acknowledgments and responses with commands
[0199] Provides a final report indication for command
responses.
[0200] Infrastructure and Application Specific Components
[0201] The architecture contains components that provide a general
infrastructure for network management and components that are
application specific. This section lists the components from FIG. 4
in infrastructure and application specific categories. Some
components consist of infrastructure and application specific code
(e.g. command line interpreter) and are noted as such.
[0202] The following components are considered to be infrastructure
related:
[0203] Object Server
[0204] Client Session Manager
[0205] Event Distributor and Screener
[0206] element management system Command Handler
[0207] SNMP Mediator
[0208] Managed Object Base Classes (ManagedObject, NEMO, SnmpMO,
SnmpNE, see FIG. 7).
[0209] UX Proxy
[0210] Active Alarm Manager
[0211] Client Active Alarm Browser Application
[0212] Client System Alarm Summary Application
[0213] Client Network Element Detailed Status Application
[0214] ROP Formatter
[0215] Command Line Interpreter. Portions of these components are
specific to the application, e.g., the screen contents and layout
will vary depending on the particular traits of the application
managed.
[0216] The following components are considered to be application
specific:
[0217] Commands and reports for the network element
[0218] Application-specific Service Objects of type Managed Object,
SnmpMO, SnmpNE
[0219] Managed Object Model
[0220] In this architecture, all resources and elements that can be
managed are represented in the system as a managed object. Each
managed object provides attributes, methods and notifications that
are used by client applications to manage the object. In order to
describe the managed object model used by this architecture, the
following terms are defined and used in subsequent
descriptions.
[0221] All instances of a type of managed object share definition
of attributes, operations, notifications and behavior, but will
have attribute values that are unique for each instance of managed
object. This approach allows common behaviors for managed objects
to be defined in base classes, and for specialized behavior to be
placed in the managed object class for that specific type of
managed object (while inheriting the common behavior and attributes
of the base class). More specialized forms of managed object
classes can be developed by subclassing existing managed object
classes, providing for reuse of existing classes. Subclasses will
often add attributes, extend or restrict ranges of existing
attributes, and add or restrict operations and notifications. This
concept helps to encapsulate rules regarding the behavior of
managed objects within the managed object class. This prevents the
common practice of replicating this functionality (often in varying
ways) in the different applications that provide management for the
element. FIG. 7 shows an example of how this approach can be used
to define some of the managed objects. It also shows how it could
be used to derive specific types of AP managed objects. Note that
this is only an example to demonstrate the concepts described
above.
[0222] For SNMP based managed objects, the definition of the
managed object and most of the managed object's attributes can be
derived from the definition of the MIB 55 (generated by a tool that
parses the MIB). Also, most of the code necessary for translation
between the MIB ASN.1 format and the EMAPI 55 object notation
(performed in the SNMP Mediator) can also be derived from the
definition of the MIB 55. Automation of this translation will
reduce maintenance of the system and will reduce development of new
managed objects when new network elements are added to the
system.
[0223] The client interface to the services and the managed object
attributes and methods is described in the EMAPI 55. The EMAPI 55
and managed object notation provide a consistent model of all
managed objects in the network, hiding the implementation details
associated with the element manager platform from client
applications (for example, clients do not need to know whether the
underlying protocol to the network element is SNMP, CMIP or a
proprietary interface). Managed object specific logic is
encapsulated within the managed object instead of scattered
throughout various applications, thus simplifying client
application development.
[0224] Managed Object Notation
[0225] A distinction is made in this model between the actual
objects present in the server to provide services for a class of
managed objects and the specific instances of those managed objects
(and their attributes). Instead of creating object instances for
all managed objects in the system which can become prohibitive on
large element management systems where network elements contain a
large number of managed objects, a single service object is created
to provide services for a class of managed objects. Specific
managed object instances and their attributes are referenced by use
of a set of object class identifiers and attribute codes. The
definition of these managed object class identifiers and attribute
codes is part of the interface definition between all service
objects and their clients.
[0226] Managed Object Identifiers
[0227] A specific instance of a managed object is referenced using
its object identifier which consists of the object class code and
an instance identifier. The object class code is a static
enumeration or constant, and the instance identifier is an integer
value (defined at run time based on configuration) that is unique
to the object class. Although the instance identifier is unique to
the managed object class, it is not the same as the logical number
for that instance. Each managed object class provides methods for
translating between the instance ID and an appropriate set of
network element and unit identifiers.
[0228] For example, AP network elements are referenced by logical
number in the system (e.g. 1 to n). The number of Aps in the system
is not fixed at a specific number (such as 8) but will be based on
the equipage information found in a database. Each AP also can have
some number of application virtual machines, each identified by a
logical number (e.g., RCS 1).
[0229] A specific instance of an application managed object is
referenced by calling a lookup function in the application's
service object to convert the AP network element instance
identifier and application key into its associated instance ID. The
combination of these two values in the object identifier uniquely
identifies a specific managed object instance.
[0230] In many cases, the use of a service object for a class of
managed objects will take the place of the object class code. For
example, the AP object class code is not specified by a client when
requests are made through the AP service object. Conversely, the AP
object class code would be present in any events sent to a client
so that the client can identify the specific managed object
instance that generated the event.
[0231] Attribute Codes
[0232] Each managed object contains a set of attributes specific to
that instance of that managed object class. These attributes
describe various maintenance, operational, configuration and
measurement information about the managed object. Each attribute is
defined with an attribute code that is local to the name space of
the managed object to which it belongs. For example, the AP managed
object class will have a State attribute (as will the RCS managed
object class). Each attribute code is unique to the managed object
class to which it belongs.
[0233] Attribute Value Definitions
[0234] The type definition for any attribute value that is not of a
basic "primitive" type (for example, short or octet) and is used
between the clients and the server must be defined in the IDL. The
scope of these definitions may be limited to the managed object
that uses them, or may be at a higher system level (for example,
alarm level definitions would be at a system level).
[0235] Adding New Managed Objects
[0236] When adding new types of managed objects in the system, a
choice must be made to create a new type of managed object service
class, or to use an existing service class and provide the ability
to distinguish between different versions or types of managed
objects in that class. The decision to use a new class or extend an
existing class will depend on how similar the new type or version
of managed object is to the existing managed object. When using a
common service class, an attribute of a that class could be used to
provide discrimination between various versions/types of the same
managed object. If a new managed object type is created, any common
attributes and functionality with other similar managed object
classes should be placed in a common base class to reduce
maintenance. To summarize the guidelines:
[0237] Create a New Managed Object for new maintenance unit types
that are unique to the system.
[0238] Subclass an existing Managed Object (or move common
functionality to a base class if it doesn't exist) for new
maintenance unit types that provide common existing attributes.
Note that this will still result in a new managed object type. An
example of this is the Ethernet interfaces on the AP. They both
provide common Ethernet functionality but there is an ethernet
interface node (EIN) and a LAN managed object.
[0239] Use version attributes for different versions of the same
managed object. Support both hardware version and firmware revision
attributes is needed.
[0240] When adding new AP processors that support additional
functionality (examples of this may be IS-634 applications) new
types of managed objects will be defined to manage the new types of
objects within that type of AP. If all AP processors are capable of
hosting the additional hardware and software entities (for example,
in later releases an AP hosting RCS virtual machines could also
have SS7 hardware and host IS-634 functionality), then a MIB
supporting the superset of possible managed objects must be
constructed and made available for compilation into element
management system runtime processes. This approach makes use of
automatic code generation, and is intended to save time when adding
new objects to the element management system. At the element
management system, additional service objects must be created to
support management of the instances of the new classes of managed
objects (e.g. MMA).
[0241] Portability
[0242] The development of this architecture must ensure portability
of the client and server components. This can be accomplished in
several ways. Machine and operating system (OS) dependent code
should be hidden as much as possible (especially when there are
multiple interfaces to it within the server) by placing it within
wrapper libraries. For example, the Element management system
Logger class will provide object-oriented wrappers for all existing
propriety UX logging services (UX_ELOG, UX_DLOG, UX_PLOG and
UX_ALOG). This allows for platform retargetting by changing the
implementation of the machine/OS dependent libraries with no impact
on the calling functions or objects. Interprocess communication
will make use of industry standard software such as CORBA which is
available on most machine and OS platforms.
[0243] Object Server Components
[0244] This section describes the major components of the Object
Server in detail. Each of the components may be represented as the
element management system, processes or classes but are treated as
general components in this section. Note that many of the
descriptions provide general examples (not AP specific) since most
of the components provide an infrastructure that is intended to
support the migration of all OA&M for additional
applications.
[0245] Client Session Manager
[0246] The Client Session Manager will maintain a list of active
client sessions and applications. It will periodically audit that
list to detect sessions that have gone away without explicit
termination (e.g., loss of connection).
[0247] The following functionality will be provided:
[0248] Interface to clients for starting a session
[0249] Creating a unique session identifier
[0250] In the fixture, validate client security and permissions
(see earlier section, "Security", for a more detailed
discussion)
[0251] Interface to clients for manually ending a session
[0252] Interface to clients for periodic check-in (heartbeat)
[0253] Interface to other server components for registering
interest in notifications of session/application termination. The
components that have such an interest are:
[0254] The Event Distributor, which is interested in all such
terminations
[0255] Managed Object Service Classes, which are interested only in
specific client session/applications.
[0256] Periodic audit of active sessions/applications to see if any
session/application has failed to check in recently.
Sessions/applications that have failed to check in within a
reasonable (to be determined in design) amount of time will be
removed from the session manager's active session/application
list
[0257] Notification to registered entities when a
session/application has been ended via the callback notification
interface described above.
[0258] Event Distributor and Screener
[0259] The Event Distributor is responsible for filtering and
routing of all events in the system. A client that wishes to be
notified upon the occurrence of one or more events (other than
attribute-change notifications) registers a filter with the Event
Distributor specifying criteria to be matched against whenever an
event occurs. Examples of clients include the Summary Alarm/Status
Manager, ROP Formatter, Managed Objects, and clients issuing manual
maintenance requests. No formatting of events is performed within
the Event Distributor--this is left to the application. Events are
typically generated as a result of a trap from an SNMP agent, but
can also be generated by element management system components on
the same machine, or even by other legacy network elements. The
Event Distributor may be implemented as a set of objects within the
Object Server.
[0260] The Event Screener supports screening of events before they
are seen by the Event Distributor for the purpose of simple,
open-ended event correlation. The Event Screener supports the same
interface (although not available to clients) as the Event
Distributor, but is only for use within the Object Server.
[0261] The following subsections show the functionality provided by
the Event Screener and Event Distributor.
[0262] Client Registration and Filtering
[0263] Provide an IDL interface (Event Distributor Only) for
registering filters based on the following:
[0264] Session and Application ID
[0265] Callback object, used to deliver events to the interested
registrant.
[0266] Filter object containing a specification describing events
to be delivered to the client. This filter allows for a limited set
of parameters that provides for specification of a set of event
attributes that may be combined to limit the set of events.
Specific values for event attributes can be given or a special
don't-care value that can be used to ignore the attribute.
[0267] The event filter will contain the fields in the list below.
Note that not all these fields must be set; those that do not
matter can be marked don't-care as described above.
[0268] Event Category
[0269] Network Element instance ID and class code
[0270] Network Element alarm level
[0271] Maintenance Unit instance ID and class code
[0272] Maintenance Unit alarm level
[0273] Command ID (client session ID and command sequence
number)
[0274] Provide an IDL interface for clients (Event Distributor
only) and other Object Server components to explicitly cancel a
specific filter.
[0275] Provide a means for Object Server components to remove all
filters associated with a specific session and application.
[0276] Provide an efficient method to store client registrations
and filter criteria and an efficient method to examine these filter
criteria on incoming traps.
[0277] Event Receipt
[0278] The Event Screener receives events from the SNMP Mediator
(which receives traps from SNMP agents and translates them into
EMAPI 55 event headers)
[0279] The Event Distributor receives events from the Event
Screener and other Object Server Service Objects.
[0280] Match an incoming event header against each stored event
filter. The event header will contain fields that match those of
the event filter (given above). In addition, the event header will
contain:
[0281] A time stamp indicating when the event was generated
[0282] Provide delivery of traps to clients using the
client-supplied callback function (for events that match their
supplied filter criteria)
[0283] The Event Distributor will play no role in event throttling:
throttling will occur at the SNMP agent.
[0284] Auditing:
[0285] Support cleanup of the filter list, through audits performed
by other Object Server components. This support is provided through
the interfaces described above or via internal callback mechanisms.
For example, when the Client Session Manager removes a session
and/or application from its internal structures, it notifies the
Event Distributor via a callback, at which point the Event
Distributor removes all filters associated with the session and/or
application.
[0286] Filters associated with commands need to be cleaned up under
several circumstances:
[0287] When the final report indication is seen in a command
event
[0288] When the trap containing the final report indication is
lost
[0289] The Event Distributor will receive a notification when
either of the above circumstances are detected, at which point the
filter matching the affected command or commands will be
removed.
[0290] Command Handler
[0291] Because various resources are utilized within the element
management system server to process managed object commands, the
Command Handler must track active commands and release resources
when the commands are completed. Active commands are modeled as
another class of managed objects within this system, and the
Command Handler represents the service object for all instances of
active commands. The Command Handler provides the centralized
tracking and management of these commands. Since command responses
are delivered via unreliable SNMP traps, an audit of command
activity between the network element and the Command Handler must
be performed.
[0292] Command Block
[0293] Command blocks will contain at least the following
fields:
[0294] Command Sequence Number
[0295] Session Identifier
[0296] Object Instance Identifier (for example, which AP? Or which
DS1?)
[0297] Command Type
[0298] Command Qualifier (optional)
[0299] Some commands may require additional arguments. Since each
command block is defined separately, it is simple to implement
additional arguments.
[0300] Command Responses/Acknowledgments
[0301] Each agent must generate an acknowledgment trap in response
to each command request containing the originating session
identifier and command sequence number along with an acknowledgment
value indicating whether the command request is invalid or could
not be processed, processed as requested with no further response,
or in progress with additional response pending. In the latter
case, one or more command response traps will be generated which
also contain originating session id and command sequence number,
along with a response sequence number and final report indication.
Since UDP messages may be received out-of-sequence, the response
sequence number may be used by a client application to reorder
multiple responses for the same command.
[0302] Command Filter Cleanup
[0303] The final report indication will be used by client
applications to note when a command-initiated action is completed,
and will also be used by the server to automatically de-register
event filters associated with that command. Each agent will support
an active command table listing the session IDS and command
sequence number of all commands in-progress. This table will be
audited periodically by the server to initiate filter removal when
final report traps are lost.
[0304] SNMP Mediator
[0305] This functionality provides translation between the EMAPI 55
class and attributes and the IP addresses and object identifiers of
the SNMP MIB. It is also responsible for formulating appropriate
SNMP requests (SNMP SET requests for maintenance requests, SNMP GET
requests for polling and auditing) and routing responses back to
the requester(s). It queues SNMP requests and ensures that no
single Network Element SNMP Agent is overwhelmed by a burst of
requests. Note that there is no client access to this component; it
exists solely for internal use within the Object Server.
[0306] SNMP to EMAPI 55 Translation
[0307] This functionality will perform translations between the
EMAPI 55 Object Class, Instance Class and Attribute Code notation
and the SNMP IP Address, SNMP MIB Object Identifier (OID) and zero
or more SNMP variable bindings. It may be implemented as a set of
objects and methods within the Object Server.
[0308] The types of translations this service must perform are:
[0309] EMAPI 55 Command object to SNMP Command Block * EMAPI 55
Poll-Request object to SNMP Get * EMAPI 55 Instance ID/Class Code
to SNMP IP Address * SNMP Get Response to EMAPI 55 Poll-Response
object * SNMP Trap to EMAPI 55 Event Header * SNMP IP Address to
EMAPI 55 Instance ID/Class Code
[0310] Object Server Interface
[0311] Provide an interface to managed object classes in the object
server to support:
[0312] Auditing: the periodic polling of configuration data and
persistent attributes (persistent in element management system
memory) that the Object Server tries to keep on the server at all
times (these attributes are stored in memory for use by multiple
clients, and are not saved over a reboot of the element management
system).
[0313] Polling: the periodic polling of attributes that are
requested by one or more EM Clients.
[0314] One-Time Status Requests: a single request for an attribute
or attributes.
[0315] Command Execution: issuing commands using SNMP SET
requests.
[0316] SNMP Interface
[0317] The SNMP Mediator handles all interfacing with SNMP agents
on network elements. The SNMP interface consists of Attribute
Polling, Configuration Auditing, Command Execution, SNMP Retry
Mechanism, and Trap Delivery. Attribute polling
[0318] Use the HPOV SNMP API or the CMU SNMP library to establish
an SNMP session to each AP agent
[0319] Use the EMAPI 55 to SNMP Translation component to translate
between EMAPI 55 notation and the appropriate SNMP get request
[0320] Translate the response to an SNMP get request to EMAPI 55
notation and route it back to the associated managed object, which
then checks for and propagates only those values which have
actually changed
[0321] Provide control over the number of outstanding get and set
requests to an agent. This is necessary to prevent overloading the
socket at the agent.
[0322] Configuration Auditing
[0323] AP equipage is maintained via recent change. Configuration
information for sub-network-element level components is maintained
by each AP agent. When more than one managed object instance may be
associated with an AP (e.g. RCS), the respective managed object is
defined by a MIB table which is indexed by one or more
configuration attributes (e.g. cell number). Associated with each
table is another MIB object identifying the current number of table
entries (the table count). Configuration information for any table
may be retrieved by sending a GET request to the agent for the
table count, and one or more GET-BULK requests to retrieve index
information (also known as keys) for all valid rows in the table.
The SNMP Mediator will perform a periodic audit of each table in
this manner to report current configuration information to each
associated managed object.
[0324] Command Execution
[0325] The SNMP Mediator will use the EMAPI 55 to SNMP Translation
component to translate from EMAPI 55 commands into the appropriate
MIB command block settings. The SNMP Mediator will translate EMAPI
55 commands into the appropriate MIB command block and issue an
SNMP SET.
[0326] Command Oueing
[0327] Because SNMP requests are sent via UDP and may be received
by an agent out of sequence, a command request/response convention
between manager and agent will be utilized to insure that an agent
will respond only once to a single command (i.e. SET operation)
regardless of the number of retries which may be generated. The
manager will maintain a separate command SET queue for each network
element. The size of the command SET queue per network element is
preferably tunable. Only one SET request for any given network
element will be pending at any one time. That is, a command
protocol data unit (PDU) will not be sent to the associated agent
until the SET response from the previous command is received. Once
the SET response has been received, other commands are initiated
and sent to the associated agent. Each PDU contains a monotonically
increasing request id, which will be examined by the agent on all
SET requests. If the id is greater than the last processed, the PDU
is presumed to contain a new request and will be acted on
accordingly. If the request id is equal to the last processed, the
agent will assume the duplicate packet is the result of a retry,
and will return the response last generated. If the id is less than
that last processed, it is presumed to be a duplicate packet for a
command to which the manager must have already received a response
(or timeout), so the packet is ignored.
[0328] Failure Handling
[0329] When the SNMP Mediator receives a SET request from a managed
object for delivery to a network element that is known to be not
responding, the request will still be processed as received. If an
associated PDU can not be sent, a negative acknowledgment will be
generated locally, and returned to the originating client via the
event distributor.
[0330] SNMP Retry Mechanism
[0331] Since SNMP relies on UDP as the underlying transport
protocol, SNMP GET, GET-BULK, and SET operations can be lost. To
recover from losses, the SNMP Mediator will use a mechanism for
retrying SNMP transactions that will be consistent for all GET,
GET-BULK and SET operations and will conform to the interface
prescribed by the HPOVNNM SNMP library or the CMU SNMP library. For
further information, see the reference to HPOVNNM or CMU SNMP
library, previously incorporated by reference herein. A predefined
maximum number of retries may be attempted for each request. There
is a tunable timeout that is logarithmically increasing (defaults
to a maximum retry delay of 12 seconds per request is suggested).
If a response for any request is not received after the maximum
number of retries, each of the managed objects associated with this
network element is notified of the loss of communication and a
local event is generated, resulting in an alarmed output message
being delivered to the ECP ROP. State values in the internal status
tables will be set accordingly, and these changes will be
propagated to registered clients via callback. The polling queue
for the network element is made idle until a subsequent audit or
any trap indicates that the agent is back online.
[0332] Trap Receipt and Delivery
[0333] The SNMP Mediator will receive traps from SNMP agents. The
outline of this mechanism is as follows:
[0334] At initialization, open a trap session with the HPOV SNMP
infrastructure
[0335] For each trap, translate the SNMP trap PDU into an EMAPI 55
event header
[0336] Deliver each EMAPI 55 event to the Event Screener for
filtering and delivery to registered clients.
[0337] MIB-to-IDL Mapping
[0338] A means will be provided to automate the maintenance of MIB
changes and the corresponding EMAPI 55 managed-object notation. An
engine that includes an ASNI MIB parser will be used to generate
IDL and other files that depend on the MIB. The goal will be to
minimize the amount of hand-crafted and maintained IDL.
[0339] MIB Conventions
[0340] MIB conventions will be defined and documented in
coordination with the development of the AP agent.
[0341] Service Object Description and Infrastructure
[0342] A service object exists for each class of network element,
maintenance unit or logical object within the system. As shown in
FIG. 4, these are labeled SnmpNEMO and SnmpMO Class Objects. Each
service object instance provides services for client application
access, and maintains a view of the attributes (as needed) for all
instances of managed objects in that class. Example service objects
include the AP, RCS and DS1. Examples of logical service objects
include System and APSummary. FIG. 8 shows managed object classes
and their containment relationships that may be used to manage the
AP. FIG. 8 also shows some example Service Objects that may be
added in the near future to manage other telecommunication network
elements. The OA&M shown can host the element management
system.
[0343] To maintain attribute values and provide client
notifications for attribute changes, each service object maintains
a status table dynamically sized according to current configuration
data and client polling needs. Information in this table will be
identified through a class dictionary containing attribute codes
and type information, available via common interface definition to
both server and client code. For example, the AP object may contain
attributes for maintenance state. Client applications will gain
access to that state information for a specific AP via class
methods which accept instance identifiers and attribute codes. The
service object provides a centralized place where network element
status is recorded. Instead of each application polling for
attributes it needs, the service object manages a list of the
registered clients and the attributes they are registered for. The
combined set is then polled for by the SNMP Mediator. Additional
class methods will be provided for performing operations specific
to the unit type, such as remove, restore and diagnose. The
specific protocol used for communication with the network element
is specified by the service object. The SNMP protocol is used for
communication between service objects associated with the AP and
the AP network element. Other managed object classes could be added
that utilize a different protocol and encapsulate that knowledge in
the managed object class. FIG. 9 depicts an AP service object and
the data it contains. It also shows an example ECP managed object
that could use a protocol other than SNMP for communication.
[0344] Client Notification and Request/Resonse
[0345] Each service object will provide methods for client access
to attributes of its managed object instances. In addition to
requesting the current value of attributes, clients can register
for notifications of any changes to attribute values. Client access
to attributes and registration for attribute notification is
specified in terms of the following.
[0346] A set of attributes for a specific instance of a managed
object
[0347] A client callback function for delivery of initial attribute
values and subsequent changes
[0348] All attribute values are delivered to the client by the
client supplied callback object reference. A sequence of attribute
code and value pairs are sent as an argument to the callback object
reference. For the initial notification, the sequence contains the
values of all requested attributes. For subsequent notifications of
attribute changes, the sequence contains only those attributes that
have changed.
[0349] Client Command Request/Resonse
[0350] Each service object for a class of network elements or
maintenance units provides member functions to implement requests
for operations on specific instances of the class of network
element or maintenance unit. For example, to remove a DS1 unit from
service in the AP, the remove method of the DS1 service class is
invoked. As with any other client requests, the client must have
created a session prior to performing this operation. The specific
instance of the maintenance unit and any command specific
parameters must be specified. The operation will return a command
sequence identifier (commandSeq) that is unique to the client
session. The command sequence identifier is present in the header
for all subsequent events (Acknowledgment and Command responses)
for the command.
[0351] Once the operation is validated at the server, a filter is
registered for the client with the Event Distributor for all events
that match the client's session and the command sequence identifier
associated with the command. After successfully registering the
event filter, a command request is sent to the SNMP Mediator where
the instance is converted to the appropriate IP addresses and MIB
command block values and generates the appropriate SNMP Set
request. Command acknowledgments and command responses are
transmitted from the SNMP agent by means of SNMP Traps. At the
server, they are converted to Events and routed to clients with
matching event filters. Note that there is a retry mechanism for
SET requests where the element management system does not receive
an associated SETRSP (detailed in the SNMP Mediator section) but no
retry is attempted when a command fails (such as in the case where
a failover was in progress).
[0352] System initiated commands and responses will be routed
similarly, using unique system session identifiers and callback
functions. An example of this type of command would include a
request to output the system status (OP) where a logical service
object is responsible for servicing the request and generating the
responses. These commands are processed within the element
management system server and not by a network element through the
SNMP interface. The element management system server must generate
the command acknowledgment and command response events itself since
it is responding to the command internally.
[0353] The network element agent is responsible for providing an
acknowledgment trap indicating if the command request was accepted.
Results of the command are then delivered from the network element
agent by a series of 1 or more command response traps. The last
command response trap contains a last response or final report
indication which is to be used within the server to detect the end
of the command and to release server resources associated with the
command (e.g. event filters). Since the command responses could be
lost, a low level audit of command activity must be performed
between the manager and the network element agent. The audit does
not require that the agent keep command response information. The
audit only checks to see if the command is still running at the
agent. If a command response or trap is lost there is no recovery
to regenerate the lost response. For cases where the network
element cannot generate a command acknowledgment, or the
acknowledgment is not received at the element management system
server, the element management system server is responsible for
generating an appropriate acknowledgment back to the client. The
following summarize cases where the element management system
Server is responsible for generating the acknowledgment event back
to the client:
[0354] 1. Can't transmit command block SET PDU to agent
[0355] 2. No SETRSP received from the agent (after repeated retry
of SET request)
[0356] 3. SETRSP from agent indicates an error (such as an invalid
object identifier)
[0357] In all other cases where the agent receives the SET request
and is able to "understand" its contents the agent is then
responsible for generating the acknowledgment (either positive or
negative).
[0358] Object Attributes
[0359] The following types of attributes can be associated with
each managed object. For each category of attribute, the source of
the attribute data differs (e.g. network element trap, network
element polling, element management system local data). It is not
required that all managed objects support all categories of
attributes, instead the presence of the attributes is based on the
needs of the managed object (for example, some managed objects have
no state attribute, but have an alarm attribute.
[0360] Persistent Attributes
[0361] State and alarm attributes for managed objects are always
maintained even if no clients are registered for the attribute.
These attributes are updated by trap notification from the network
element (and are audited by a low level periodic audit poll
controlled by the Snmp Mediator). Maintenance state is delivered by
state change notifications, and alarm level attributes are
delivered by alarm set/clear notifications.
[0362] Configuration Attributes
[0363] These attributes constitute configuration related
information. These attributes are updated as a result of an event
notification of configuration change on the managed object. When a
configuration event notification is received noting either an
insert or update of configuration, the managed object performs a
single request to get the current values of all attributes for the
specified (this is also known in SNMP as trap directed polling).
When the configuration event indicates a configuration delete, the
managed object performs the associated deletion of the instance. As
with Persistent attributes, config attributes are audited by a low
level periodic poll controlled by the Snmp Mediator (in fact it is
the same audit). An example of this type of attribute is
apLogicalld. Note that some attributes marked as Config only change
when the SNMP agent reboots. Therefore, the network element will
never issue any config change notifications on these attributes.
They are categorized as config because the managed object requests
their values along with other config attributes when the config
notification is received for a new instance of the managed
object.
[0364] Audit Attributes
[0365] The value of these attributes are only maintained through a
periodic low level audit. Examples of this type of attribute are
the active command table command session and command sequence
number.
[0366] Polled Attributes
[0367] The current value of these attributes are only maintained if
a client is registered for notifications of changes to the
attribute. These attributes are polled for at a 15 second polling
rate by the SNMP Mediator. An example is the AP sysUpTime
attribute.
[0368] Internal Attributes
[0369] These attributes are based on internal data or derived from
other attributes. An example is the isolated attribute in the AP
network element. Its value is based on an isolation indication
detected by the SNMP Mediator when communication is lost to a
network element (or subsequently restored). For SNMP based managed
objects, all attributes that are not internal, directly represent
an associated MIB attribute.
[0370] Service Object Base Class Functionality
[0371] Much of the basic behavior of each object is present by
means of inheriting base classes that contain the specific manager
functionality. For example, client registration and polling will be
defined in base classes shared across all service objects. The
following sections describe these common behaviors available to all
service object classes.
[0372] Managed Object Base Class
[0373] This class pro4vides definitions of the basic interfaces
that all managed objects must support. This includes providing
client interfaces for things such as managed object configuration
notification and attribute update notification. Specific service
objects would all inherit this base class.
[0374] NE Managed Object Base Class
[0375] This class (derived from managed object base class),
provides network element specific functionality on top of the basic
managed object class. This includes providing client interfaces for
network element configuration notification. It is responsible for
handling network element related equipage notifications from
configuration data services (AP equipage changes) and notifying the
SNMP Mediator of these changes. The SNMP Mediator must be notified
of these changes in order to provide appropriate routing and
translation between the Managed Objects and the network element.
Specific network element service objects would all inherit this
base class.
[0376] Client Notification Registration
[0377] Each service object must manage a list of clients and the
attributes for which they are registered. This list must contain a
session handle, the list of attribute codes, and the instance
identifier(s) for specific managed object instances. This
functionality must also provide methods to efficiently search this
list based on attribute code and instance identifier so that
registered clients can be notified of changes. Client registration
must be coordinated with the Client Session Manager to provide for
graceful cleanup when abnormal client termination is detected.
[0378] The Client Registration Functionality:
[0379] Provides interface to clients for attribute registration
given the following parameters
[0380] client session id
[0381] managed object instance identifier (specific id, range, or
all in class)
[0382] set of attribute codes
[0383] callback function for delivery of changes
[0384] Provides general container and data structures for managing
a list of client registrations
[0385] Provides methods for construction and delivery of client
callback with attribute code/values.
[0386] Provides interface with client for de-registration
[0387] Provides interface with Client Session Manager for
de-registration when abnormal client termination is detected via
audit.
[0388] Polled Attribute Management
[0389] Attribute polling is needed for element management system
initialization (e.g., upon element management system
initialization, the only way to obtain status is through polling),
attribute values that are not trap-directed, and audits (i.e., UDP
is an unreliable transport and as such, traps may be lost).
Trap-directed attributes are stored on the element management
system in memory for use by multiple clients. There may also exist
other attributes whose value is only obtained through polling, and
that polling will only be initiated when a client has informed the
object that it is interested in notifications of state changes to
those variables. In that case, the object must request that the
SNMP Mediator poll network element at regular intervals (15
seconds) to determine if any of the variables of interest have
changed. If a change is detected, registered clients must be
notified by means of a client callback. These polled attributes are
also stored in memory. The manager of these attributes are as
follows:
[0390] Maintains the attribute table (allocation of attribute
table, instance identifier management, changes to the attribute
table based on configuration changes)
[0391] Informs the SNMP Mediator of the current set of attributes
that are to be polled. When a client registers (or de-registers)
the set of attributes that must be polled for may change. If it
does, the SNMP Mediator must be informed.
[0392] Handles poll responses from the SNMP Mediator. When a set of
polled data is delivered (via server callback function) attribute
values must be compared with the current values in the attribute
table. When the value has changed, the value in the attribute table
is updated and clients must be notified of the change. Note that if
more than one attribute has changed for a managed object instance,
the changes will be grouped and delivered to each registered client
on a managed object instance basis.
[0393] Trap Directed Attrebute Polling Management
[0394] For network elements utilizing SNMP, all alarm,
configuration changes and basic state changes (including non
alarmed maintenance states) are delivered to the manager from the
Agent through the use of an enterprise specific SNMP trap. These
traps are received by the SNMP Mediator where they are translated
into EMAPI 55 Events and passed along to the Event Distributor.
They are then delivered to all clients that have registered a
filter matching the data in the associated Event. The Summary
Alarm/Status functionality of each class of objects registers a
filter with the Event Distributor to request delivery of all alarm
and state change events for all instances of objects within its
class. When a alarm or state change event is received by the
Summary Alarm/Status Manager, the attributes for the appropriate
instance are updated, the summary attributes for the class are
updated, and all clients registered with the object for state
change notification on the affected attributes are notified via
their client callback functions.
[0395] Registers appropriate filter with Event Distributor for all
events on instances of this managed object class (alarms, state
changes, configuration notifications).
[0396] Handles events from the Event Distributor. When a trap is
received, attribute values in the Event are compared with the
current values in the attribute table. When the value has changed,
the value in the attribute table is updated and clients must be
notified of the change.
[0397] Interfaces with SNMP Mediator to perform low frequency
(audit) poll of attributes in the managed object class associated
with traps.
[0398] Handles low frequency audit poll responses from SNMP
Mediator.
[0399] Client Interface Components
[0400] The following sections describe the components present on a
client of the element management system server to provide the
client interface to NE management. Specific client interface style
and content will be addressed after the architecture with input
from human factors and element management system engineering. In
addition to making the client interface as easy to use as possible,
the client interface must retain similarities with the current
maintenance model such that little retraining of the end client
(technician) is necessary. Sample Web pages can be found in the
attachments to this document.
[0401] AP or Network Element Telnet Access
[0402] Direct cut-through access to the AP is required to perform
system administration and some configuration functions, and as a
means to access the AP command line interpreter if the element
management system is not operational. To provide this access, the
client platform must support a telnet application and a suitable
terminal emulation to run a visual editor such as vi. On an X
terminal, an xterm terminal emulator and use of the telnet
application will be sufficient. On the Microsoft Windows platform,
use of an X terminal emulator will provide the same access as an X
terminal, or the Windows telnet application on a PC may be
used.
[0403] Web Browser
[0404] The primary client interface is provided by an HTML web
browser. Both Netscape navigator and Microsoft Internet Explorer
are to be supported. The web browser must support the execution of
Java 1.1 applets and at least HTML version 3.2. The following
client terminal configurations must be supported:
[0405] X Terminal with Netscape browser running on the element
management system.
[0406] Sun workstation with Netscape browser running on
workstation.
[0407] PC (Windows 95 or NT 4.0) with either Netscape or Microsoft
IE running on PC. WEB PAGES
[0408] To provide web based network management access for the AP,
web pages providing the following functionality must be developed.
FIGS. 10, 11, 12 and 13 show sample page layouts):
[0409] 1. Top level page: Initial entry to system. Presents a menu
of options and potentially high level system status.
[0410] 2. Network page: Hosts AP system level summary
application
[0411] 3 . AP page Hosts AP detailed NE status page for a single
AP. A version of the page is constructed "on the fly" based on the
AP logical number in the URL. The AP logical number and any other
parameters are passed to the AP detailed NE status applet.
[0412] 4. Alarms page: Hosts the Alarm list applet.
[0413] Note that page layout and navigation is determined by
working with human engineering factors.
[0414] Client must be able to:
[0415] 1. Access each page directly. Secure access (through web ID
validation) must be provided for the initial access to these pages,
but not for requests for subsequent pages as long as the same
browser session is used.
[0416] Java-based GUI Infrastructure
[0417] This section describes base components that are necessary
for implementing the AP specific GUI applets. A number of these
components (especially the GUI components) may be satisfied (or
based upon) commercial 3.sup.rd party products (for example Rogue
Wave JWidgets, or Microline's Grid widget). Also, 3.sup.rd party
non GUI container and algorithm classes (either Rogue Wave or JGL
for example) should be considered to enhance the set that comes
with the Java Development Kit.
[0418] The following sections describe applications that use this
architecture.
[0419] AP Summary Application
[0420] This application provides summary information for all AP
processors in the system. The summary information consists of the
highest alarm level, administrative state and equipage status of
all AP processors. Any changes to the configuration of displayed
summary information are updated on the display within 30 seconds of
the change. State changes are to be displayed within 15 seconds of
the state change in the AP. In addition to presenting summary and
equipage information, the application supports navigation to
detailed status pages for each of the AP processors. It also
provides a pop up menu (and any necessary dialog boxes) for
execution of AP commands (e.g. RMV AP). A command response area or
dialog box is also provided for display of command responses.
[0421] This application initiates a session with the element
management system server (through the Client Session object) and
registers with the network element service objects (the AP object)
for the configuration information and attributes that it needs to
provide a display of the AP network element summary (e.g. highest
alarm level and status summary). An initial set of attribute values
is delivered to the client and any subsequent changes to those
attributes are delivered (from the summary alarm/status manager in
the service object). Note that only the changed attributes are
delivered in the subsequent callbacks unless the client requests a
"reload" of attributes.
[0422] A sample Network Web page can be found in the
attachments.
[0423] Network Element (NE) Detailed Status Application
[0424] This application presents a detailed view of the status of
maintenance units within an AP network element. Any changes to the
configuration of displayed summary information are updated on the
display within 30 seconds of the change. State changes are to be
displayed within 15 seconds of the state change in the AP. This
application initiates a session with the object server (through the
System object) and registers with the AP service objects (specific
network element instance and maintenance units) for attributes that
it needs to provide a display of the AP element status. An initial
set of attribute values is delivered to the client and any
subsequent changes to those attributes are delivered (from the
attribute manager in the service object). Note that only the
changed attributes are delivered in the subsequent callbacks unless
the client requests a "reload" of attributes. The detailed status
application may also provide context sensitive command execution
through the use of pull down (or pop up) menus. The interface for
command execution and display of command results is the same as the
interface described in the "Command Handler" section above.
[0425] A sample AP Web page can be found in the attachments.
[0426] Alarm List (Active Alarm Browser) Application
[0427] This application provides an alarm browser interface to
active alarms within the system. The client can specify a filter to
limit the set of alarms (e.g. by network element, alarm level etc).
The application registers it's filter and a callback function with
the active alarm manager through the EMAPI 55. An initial set of
active alarms matching the filter criteria is delivered to the
client along with subsequent updates to set or clear alarms. Upon
graceful termination the client disconnects from the active alarm
manager (or an internal audit in the active alarm manager detects
this and cleans up).
[0428] A sample Alarms Web page can be found in the
attachments.
[0429] Locale Text Formatting Services
[0430] This service provides the infrastructure for multiple human
language support. This service is used by any application that
interacts with an end client through display of text: this includes
the ROP formatting process, the web-based client applications, and
any local logging on the element management system.
[0431] The following functionality will be provided:
[0432] Access to a database of text formatting strings used by
clients for formatting
[0433] Lookups are based on an integral key and a corresponding
ASCII string is returned
[0434] The database contains key and ASCII values and will reside
on disk. The storage format and caching mechanisms will be designed
so minimize lookup speed.
[0435] Both local and remote clients can be served.
[0436] Adherence to X/Open CAE (XPG4) source message file
format.
[0437] Commands and Reports
[0438] Each managed object class will adhere to the interface
specified by the managed object base class (provide for client
attribute registration, notification, configuration registration
and notification), and will manage equipage, alarm and status for
all instances of managed objects in that class. Each class will
also provide methods to implement managed object specific commands.
These methods will incorporate appropriate argument validation
(e.g. range checks, target network element is equipped before the
command is executed.
[0439] Besides the AP generated reports, the element management
system will generate reports for the following conditions:
communication is lost with an AP, communication is established with
an AP (cold start trap), and all APs are out of service.
[0440] Overload Control
[0441] Overload control in the element management system server is
accounted for primarily in the design (as opposed to here in this
document). Specifically, status requests (polling, auditing and
one-time GET requests) are limited by the number of simultaneous
HPOV sessions supported by the element management system and the
size of the tunable sliding window managed for each AP. Further,
the event stream is limited by the throttling mechanism implemented
by each SNMP agent. On the client side, the element management
system will support a limited number of active client sessions,
each of which may run a limited number of applications. The bottom
line is there won't be enough network or client generated traffic
to warrant the development of additional overload controls for the
first phase.
[0442] Additional development should extend overload controls to
safeguard against an uncontrolled event stream, and monitor and
restrict the number and scope of client requests associated with
each application.
[0443] The following areas of concern have been identified and will
be used as the starting point to examining overload control:
[0444] Client Overload:
[0445] Registering for too high a volume of data
[0446] Creating too many sessions: note that adequate resources are
currently allocated for internal server sessions
[0447] igh-frequency callbacks (traps for example)
[0448] Server Overload:
[0449] Too high a volume of polling from SNMP Mediator to NE
agents
[0450] Trap floods: too many traps received over short period from
NE agents
[0451] Softwre Version Management
[0452] The plan of record for overall AP/element management
system/ECP software version management is as follows:
[0453] For software retrofit for other applications, the element
management system Server and the AP are retrofited to the same new
version of element management system software.
[0454] At element management system Software Update:
[0455] The element management system Server is updated first
[0456] The APs are updated one at a time
[0457] The element management system Clients will detect the
element management system Server is down, and will need to
reinitialize when the element management system Server is back
online.
[0458] For element management system SUs, the element management
system software on the element management system server must be
compatible with the old version and new version of software on the
AP. To support this compatibility, the element management system
server is required to support MIB versions j and j+1
simultaneously. Element management system version management
extends to element management system client applications as well,
which must have knowledge of the MIB version on a given AP and be
able to act accordingly.
[0459] During a software retrofit application and element
management system Server SU, the element management system Clients
will go down and will need to re-initialize once the element
management system server is back up. The definitive requirements
for element management system GUI Client version management will be
described in the element management system GUI Client Capability
Requirements/High-Level Design document The design of the MIB is
that it contains a very detailed description of the element
management system/AP interface. The MIB is intended to serve as
much as possible as a single element management system/AP interface
definition. As such, its details may need to be modified more
frequently than at each Generic Retrofit. The SU approach will not
guarantee that an element management system Server running a
different MIB version than a corresponding AP SNMP Agent will be
able to conduct error-free operations, but rather will enumerate
the possible ways a MIB could change from one release to another
and will specify the way version mismatches in each case will be
handled and the kind of error handling that will be needed. The
overriding goal is to maximize a technician's ability to perform
the method in accordance with the invention on any available AP
even if that AP is not running the same MIB version as the element
management system server.
[0460] Security
[0461] This functionality provides a method of client based access
control of network elements, maintenance units and operations on
network elements/maintenance units. Upon startup, a client
application must register with the server by providing
identification of the client host, port, client, and a password.
The server retrieves the client record from local data services and
returns a session object to the client noting the client's access
permissions. This information may be used to provide some level of
access control in the client application (e.g. deactivating menu
element management system for maintenance operations that are not
allowed). In any case, all client requests are validated at the
server. Each managed object class requires the session identifier
as a parameter to each public method. The access permissions
associated with the session are examined before authorizing client
execution (e.g. remove operation). Note that there is a predefined
"system session" with global access permissions for use by
infrastructure components which make use of the same interface
definition.
[0462] The version of SNMP that will be used by this architecture
is SNMP V2c. This version of SNMP provides no further security
enhancements over the community name based security in SNMP V1. It
provides no mechanism to authenticate the source of a management
message, or to prevent eavesdropping on the messages on the
network. Because of this, it is strongly recommended that the
network that is utilized for the element management system to AP
SNMP traffic be a closed network and not part of the service
providers public LAN or intranet .
[0463] The command line interpreter application (which resides only
on the element management system server) is applicable to any
client with a login on the element management system server. Thus,
the client based access control described above provides a means to
restrict access on a command/client basis.
[0464] Major Sub-components of the AP
[0465] A functional block diagram of the AP is shown in FIG.
14.
[0466] SNMP Agent: Provides the interface to the element management
system Server using the SNMP protocol and a MIB defined
specifically for the AP. Sends AP events and command acks/responses
to the element management system Server as SNMP TRAPs; responds to
requests for managed object data (SNMP GETs); passes command
requests (SNMP SETs) to the Command Handler.
[0467] AP MIB: An SNMP MIB defined specifically for the AP.
Contains the definition of all AP objects to be managed from the
element management system Server, as well as the definition of all
AP TRAPs to be sent to the element management system Server.
[0468] Agent Configuration File: contains values need by the Agent
to communicate with the Manager, which resides on the element
management system Server.
[0469] Event Handler: responsible for both the filtering and
forwarding of events to the SNMP Agent. In response to events that
are generated, updates the Network Element Status Table with data
that is to be "remembered" by the AP (so that the element
management system Server may query or poll for it later).
[0470] Event API: AP applications use this API to generate an event
(state change, alarm, informational message, configuration). The
event is passed to the Event Handler.
[0471] Network Element Status Table (NEST): a repository for all
status that the element management system Server may query for.
Current status, including state variables and list of outstanding
alarms, for each Managed Object will be maintained here. In
addition, the list of outstanding commands will be maintained
here.
[0472] NE Status API: an interface for writing to and reading from
the Network Element Status Table.
[0473] Event Configuration File (ECF): text file, (possibly
editable by the technician), which defines which events are to be
logged locally on the AP and/or passed to the SNMP Agent for
transmission to the element management system Server. As per
requirements, there will be a set of events that will always be
logged and forwarded to the element management system Server--the
technician will not be able to modify these. There may be other
events defined (as the development phase proceeds) which may be
edited by the technician. The ECF also defines X.733 values (e.g.
severity) associated with alarms and informational messages.
[0474] Admin Log: file containing a customer-viewable log of events
generated on the AP; which events are logged is controlled by the
ECF.
[0475] The following sub-components are considered part of the AP
infra-structure software.
[0476] Command Handler: manages all commands that are to be
executed on the AP. Interfaces to a command source (also known as a
Command Handler Access Point, or CHAP), such as the SNMP Agent, the
AP Text Client, or the ECP Agent via the Command/Response API.
Responsible for triggering and monitoring the command to be
executed via the RAP API. Generates the command acknowledgment.
Routes the command acknowledgment and command responses back to the
command source. Maintains list of active commands in the NE Status
Table.
[0477] Command/Response API: interface between a command source and
the Command Handler for the purpose of issuing commands and
obtaining command acknowledgments and responses.
[0478] RAP API: a general API for spawning a process and obtaining
the results of the process execution. Generally, RAPs will be used
to carry out a maintenance command on an AP resource. RAPs may
spawn other processes, if necessary.
[0479] Text Command Interpreter: text-based command client for
generating commands and receiving responses locally on the AP.
Intended to be used when the element management system Server is
unavailable.
[0480] IDS-AP: maintains the data tables of the IDS on the AP;
receives triggers, representing changes in data, from the IDS on
the ECP.
[0481] IDS (Configuration) Data: a repository for AP configuration
data obtained from the ECP via IDS-AP.
[0482] IDS API: an API for obtaining configuration data provided by
IDS-AP.
[0483] ECP Agent: interface to Status Display on the ECP; interface
to IDS-AP for processing triggers indicating change in data. Passes
triggers on to interested application processes.
[0484] Audit Controller: audits status and alarms among RCC, NEST,
and resource managers (e.g. CCM).
[0485] AP State Monitor: detects and reports RCC-related state
changes and alarms. This includes state changes and alarms reported
by Resource Monitors RCC process monitoring software.
[0486] SNMP Agent
[0487] The element management system interfaces to the AP via the
SNMP Agent. A MIB is used to define the interface between the
element management system Server and the Agent and is common to
both the element management system Server and the Agent. The Agent
is described here and the MIB is described in the following
section. The Agent communicates with the element management system
Server using the Internet standard Simple Network Management
Protocol (SNMP) (see Internet document RFC-1157) via a standard
UDP/IP port. In this architecture, the intent is to use SNMPv2c,
which provides enhanced capabilities over SNMPv1, such as the
GETBULK operation.
[0488] SNMP provides three basic management functions:
[0489] GET (also GETNEXT and GETBULK): obtains data from a managed
system (retrieves attributes associated with a managed object, as
defined in the MIB). The managed system must respond to a GET with
a GET-RESPONSE.
[0490] SET: usually used to make modifications to the managed
system. The managed system must respond to a SET with a
SET-RESPONSE. In this architecture, SETs are used to trigger
commands to be executed on the AP.
[0491] TRAP: a way for the managed system to send asynchronous
notifications to the Manager.
[0492] SNMP Agent Functionality
[0493] The SNMP Agent will perform the following basic
functions:
[0494] I. Receive SNMP packets sent by the SNMP Manager at the
element management system Server and process each one as
follows:
[0495] A. GET/GET-NEXT/GETBULK packet: Obtain the current values of
the managed object attributes requested in the packet by accessing
either the Network Element Status Table or the Configuration (IDS)
Data, as appropriate. The requested attributes and their values are
stored in a GET-RESPONSE packet and returned to the Manager.
[0496] B. SET packet: Map an SNMP SET request into a command
request message, as defined by the common Command/Response API. The
command attributes, as specified in the SNMP packet and defined in
the MIB, will be mapped in to corresponding message elements. The
message will be passed to the Command Handler via the
Command/Response API.
[0497] The Agent will send a SET-RESPONSE back to the Manager. If
the SET request was invalid such that the Command handler could not
determine a command to run, or if the command could not be passed
to the Command Handler, the SET-RESPONSE will indicate an error.
The Manager must interpret a SET RESPONSE error and generate a
command acknowledgment indicating an error occurred.
[0498] The Agent must allow for the case where the Manager may send
an identical SET request. This can occur if the Manager does not
receive the SETRESPONSE (lost). The Agent will remember the last
SET request processed for a given client session (the client
session info is defined in the MIB as common attributes for all
commands) and will only pass the command to the Command Handler if
the request is new. If the request is old, the Agent will simply
send another SET-RESPONSE to the Manager.
[0499] II. Receive messages from the Command Handler and process
each one as follows:
[0500] A. If the message is a Command Acknowledgment, map it into a
Command Acknowledgment TRAP packet. The MIB will define a Command
Acknowledgment TRAP that will be used for all commands. A command
acknowledgment will take the form of a simple value to indicate the
status of the command, such as the command was rejected, timed-out,
is complete, or is in progress with command responses to
follow.
[0501] B. If the message is a Command Response, map it into a
Command Response TRAP packet. The MIB will define a common Command
Response TRAP block that will be passed back in all command
responses. In addition to the common Command Response TRAP block,
there will be specific definitions in the MIB for each type of
command response than can be generated. Note that there is no
provision made to save Command Responses in case they are lost
(perhaps the command response handling at the element management
system Server can report on lost responses). Nor, is there any
provision to guarantee that responses are returned in the correct
order.
[0502] III. Receive messages from the Event Handler and process
each one as follows:
[0503] A. Map the particular event into a corresponding TRAP
packet. There are four possible types of events that can be
received by the Agent and each event type will be mapped to a
specific TRAP, as defined in the AP MIB.
[0504] 1. State Change: indicates a change in value of one or more
of the variables associated with a managed object. Managed object
states will be maintained in the NE Status Table and the Manager
may query the Agent for any or all states associated with the
managed object. The Agent will map the variables and new state
values in the event message into their corresponding MIB object
identifiers and values in a TRAP packet, and send the packet to the
Manager.
[0505] 2. Alarm: indicates a condition of an unexpected nature
which requires special and persistent technician notification. May
also be used to indicate a clearing of such a condition. Each alarm
is associated with a managed object and has a definition specific
to that managed object in the MIB. There is an alarm block defined
in the MIB that is common to all alarms. Alarms, like managed
object states, will be maintained in the NE Status Table, and the
Manager may query for active alarms. The Agent will map the alarmed
event into the common MIB alarm block plus the specific attributes
defined for the managed object.
[0506] 3. Informational message: is similar in substance to an
alarm, but is a condition that does not require the persistence of
an alarm. The intent of an informational message is a condition
which requires logging (say at the element management system Server
and/or on the ROP) but is either not considered important enough to
be maintained as an alarm (i.e. persistent view to the technician),
or is a condition which can not be automatically retired when the
condition disappears. An alarm defines a condition which must be
able to be retired, either automatically or as a result of some
technician action. The Agent will map the Informational message
event into the common MIB Informational message block plus the
specific attributes defined for the managed object and send it to
the Manager.
[0507] 4. Configuration Change: indicates that the configuration
data for a given managed object has changed in some way (i.e., the
managed object was created or deleted, or the configuration data
associated with the managed object was updated). The Agent will map
the Configuration Change event into the common MIB Configuration
Change block and send it to the Manager. The Manager is then
responsible for querying the AP to obtain the new/updated
configuration data.
[0508] IV. The Agent will throttle TRAPS going to the element
management system Server so as not to overwhelm the Manager.
Throttling will be based on a fixed maximum rate coming from the
AP. The throttling performed by the Agent will be priority-based,
such that command acks and responses would take precedence over
configuration changes, which would take precedence over alarms,
which would take precedence over informational messages. The
details of TRAP throttling will be specified during the design
phase.
[0509] SNMP Agent Initialization
[0510] In order to communicate with the SNMP Manager on the element
management system Server, the Agent requires certain
information:
[0511] 1. The IP address of the SNMP Manager is required in order
to send SNMP TRAPs; a standard hostname will be assumed to exist in
the /etc/hosts file on the AP and the Agent will obtain the IP
address of this host on startup. Default IP addresses will be setup
at staging of the AP.
[0512] 2. The SNMP read and write community strings. Community
strings are a form of SNMP security: the strings that the Manager
will send must match what the Agent is expecting in order for the
Agent to allow a GET (read)/SET (Write). These strings will be
obtained from a command-line option when the Agent is started.
Commandline parameters are specified in the RCC configuration
file.
[0513] The SNMP Agent will exist as part of the Element Management
Infrastructure Platform Virtual Machine (PVM) on the AP , and as
such will be started by the Reliable Cluster Computing
infrastructure.
[0514] Upon startup, the SNMP Agent will perform the steps
necessary to gain access to the NE Status Table and Configuration
Data; determine the Manager's IP address (as stated above); and
will send a standard SNMP Cold Start TRAP to the Manager.
[0515] The Agent will respond to SNMP GETs on the standard Internet
"system" group objects. This is required by the HP OpenView package
that is being used on the element management system Server.
[0516] AP MIB
[0517] The AP MIB is the data definition shared between the SNMP
Manager on the element management system Server and the SNMP Agent
on the AP. It contains the definition of:
[0518] Common attribute blocks ("headers"), such as those defined
for commands, command acknowledgments, alarms, etc. (see "MIB
Conventions" below).
[0519] All state variables, commands, command responses, alarms,
and informational messages associated with the objects that are to
be managed from the element management system Server. The managed
objects are intended to include the AP itself, RCS virtual
machines, the ethernet, etc.
[0520] Objects required for auditing, such as the list of active
commands (so that the element management system Server may audit
its view of outstanding commands with the AP's view).
[0521] MIB Conventions
[0522] As mentioned previously, several conventions will be applied
to the MIB to support this architecture. They are listed in the
following sections "Binary" versus "ASCII" Attributes.
[0523] The intent is that the attributes defined in the MIB will,
in general, be defined as binary values, as opposed to ASCII
strings. This allows the text-formatting of the attribute values
(at the element management system Server) to use locale text
formatting (so that the text appears in the appropriate human
language).
[0524] SNMP agents preferably support the above variable. It is
used by the Manager to determine whether this is an MIB (supporting
the other interface conventions described in this section), and
also to provide a versioning mechanism to support MIB changes. Upon
initialization, the Manager will attempt to perform a GET operation
on this variable. If it does not exist, the Agent does not support
the enhancements required by this architecture.
[0525] Common Command Block
[0526] To support command requests, the MIB must support a specific
set of variables to allow for all parameters for command execution
to be specified in an atomic operation. This set of variables is
called the command block. The command block provides a way to
"register" a command request with an identifying tag that is used
to route the final response (delivered by a TRAP) to the
originating requester. The command block will contain such
parameters as:
[0527] A session ID that relates the command to a particular client
session.
[0528] A command sequence that makes the command unique within a
particular client session.
[0529] An object instance identifier (e.g. "7" for an "RCS" managed
object) to identify the particular instance of the object that the
command is to be performed on.
[0530] A command operation (e.g. REMOVE).
[0531] Additional parameters specific to the command are not part
of the common command block.
[0532] Common Command Acknowledgment and Command Response
Blocks
[0533] In order to route Command Acknowledgments and Command
Responses back to the originating client, the TRAPs that are
generated to produce acks and responses must contain the common
command block attributes (see above) from the initial command
request. Command Responses must also contain a response sequence
and a flag indicating last response. The common command block
attributes will be passed to the Command Handler by the SNMP Agent
and must be returned from the Command Handler to the Agent (i.e.
this must be part of the Command/Response API), so that the Agent
can return them in a Command Response TRAP.
[0534] Common Alarm and Informational Message Blocks
[0535] Alarms and Informational messages will have a common
attribute block defined. Attributes such as alarm level, alarm
cause, alarm ID (a unique value per outstanding alarm) will be
defined.
[0536] Common Configuration Change Event Block
[0537] There will be a common attribute block defined for all
Configuration Event TRAPs. Attributes such as the managed object
instance identifier and the configuration operation (insert,
update, delete) will be defined.
[0538] Unit Hierarchy Addressing within the MIB
[0539] SNMP MIBs currently provide only one method to structure
data: a simple twodimensional table with scalar-valued entries.
This limited way of structuring M variables does not directly
support the more complex structure of a network element such as a
cell site. A cell site has many units, each of which has a set of
variables specific to that unit. The units are structured in a
hierarchy.
[0540] To reference a specific attribute (or a set of attributes)
of a sub-unit lower in the hierarchy, a multi-column key consisting
of an identifier for each unit in the hierarchy will be used (e.g.
to reference a sub-unit like CCC 2, CCU 1, the last two digits of
the SNMP object identifier would be "2.1"). The SNMP GETNEXT
operation supports a convention (which must be supported by the
Agent) to request an attribute by specifying the multicolumn key as
an object identifier.
[0541] Note: Currently, there has been no such unit hierarchy
deemed necessary for the AP managed objects.
[0542] Event Generation and Processing
[0543] Applications on the AP are responsible for generating events
to reflect:
[0544] Current status and alarms associated with AP managed
objects.
[0545] Changes in configuration data associated with AP managed
objects.
[0546] Informational messages that may be of interest to Network
Management applications.
[0547] In order to prevent inconsistencies, it is assumed that one
and only one application will be responsible for the status and
alarms of a particular managed object instance, and thus, be
responsible for maintaining an accurate view of the managed object
at all times by use of the Event API.
[0548] The following sections describe the major components
involved in event generation and processing.
[0549] Event API
[0550] The Event API provides a mechanism for applications on the
AP to generate events, and communicate these events to the Event
Handler for possible recording, logging and/or forwarding to the
element management system Server. The API includes:
[0551] The definition of all possible events in the system. Each
event will be classified into one of the four possible types of
events, as discussed earlier in this document: state change, alarm,
informational message, or configuration change.
[0552] A means to initialize the API. Internally, the API will use
the UX inter-process communication library to send messages to the
Event Handler.
[0553] A means to pass the alarm text associated with a given alarm
occurrence. The text will be encoded in a machine- and
language-independent form for transmission to the element
management system. The means to encode text will be provided by a
National Language Support (NLS) library.
[0554] A means to clear all alarms previously generated by this
application. This is intended to be used when an application
re-initializes and must clear all outstanding alarms related to all
managed objects for which it is responsible. This capability may or
may not be needed in Generic 13.
[0555] A means to clear all alarms associated with a particular
managed object instance. This is intended to be used when a
particular managed object is initialized or brought in to service.
For example, there may be several outstanding alarms on a DS1
object related to in-service operation. When the DS1 goes
out-of-service, the application managing the DS1 may want to clear
all outstanding alarms on that DS1.
[0556] Event Handler
[0557] The Event Handler will exist as part of the Platform Virtual
Machine on the AP, and as such will be started by the Reliable
Cluster Computing infrastructure.
[0558] The major functions of the Event Handler are:
[0559] I. Read the Event Configuration File to determine which
events are to be recorded (attribute changes and alarms), logged,
and/or passed to the SNMP Agent for transmission to the element
management system Server. The ECF also defines whether an event is
an alarm or an informational message, and the X.733 values
associated with alarms and informational messages.
[0560] II. Monitor the ECF (e.g. UNIX stat system call) on a
regular basis to detect changes in the ECF.
[0561] III. Receive messages from applications on the AP and
process each one as follows:
[0562] A. If the event is to be logged, do so.
[0563] B. If the event is one which requires recording (an
attribute change or an alarm), update the NE Status Table using the
NE Status API.
[0564] C. If the event is to be passed on to the element management
system Server (by default, all events will be passed), send it to
the SNMP Agent using the UX inter-process communication
library.
[0565] Network Element Status Table
[0566] A repository for all non-configuration data that the element
management system Server may query for. This includes:
[0567] Current managed object status, on a
per-managed-object-instance basis.
[0568] List of outstanding alarms, on a per-managed-object-instance
basis.
[0569] Active Command Table, so that the SNMP Agent has access to
the list of commands that are currently outstanding from the
element management system Server, for audit purposes.
[0570] Network Element Status API
[0571] Provides a mechanism to read and write the Network Element
Status Table. The API blocks readers while the table is being
updated so that the data is kept consistent (e.g., by using a
semaphore). Supports "wildcard" clearing of alarms as described
above in the "Event API" section. The intention is that the Event
Handler will be the one and only one application that will use the
write API, while other applications, such as the ECP Agent and the
SNMP Agent, will use the read API.
[0572] Event Configuration File (ECF)
[0573] A text file, (possibly editable by the technician), which
defines which events are to be logged locally on the AP and/or
passed to the SNMP Agent for transmission to the element management
system Server. Events that are required to be logged and passed to
the element management system Server as defined by the system
requirements will not be allowed to be changed. The ECF also allows
the technician to set the X.733 values associated with alarms and
informational messages. An ECF-checker application (e.g. shewawk)
will be written to prevent invalid modifications to the file.
[0574] ADMIN Log
[0575] An ASCII file, written by the Event Handler, that contains
events that are to be logged as defined by the ECF, with common
fields in a fixed format. This file will be based on the existing
OMP Admin logging mechanism.The fields for Alarm entries will match
the content and order of the fields that appear on the element
management system Server Alarm List application and will be tab
delineated.The amount of data contained in the Event Log will be
maintained through the standard logfile mechanisms. Access to the
Event Log will be through standard mechanisms (cut-through to the
AP, use of a standard editor).
[0576] EMAPI
[0577] Overview
[0578] The Element Management System (EMS) provides a framework for
monitoring and controlling network elements. Each physical and
logical component in the network is modeled as a managed object,
which the Server makes visible to distributed client applications
through the facilities of the Common Object Request Broker
Architecture (CORBA). EM Clients need only be concerned about the
attributes and operations defined for each application managed
object, and not the details of network-level protocol and the
server infrastructure required to support object services. The
following is the Element Management Application Programming
Interface (EMAPI) 55 in accordance with the invention utilized by
EM Clients.
[0579] EMAPI Object Definitions
[0580] FIG. 15 shows all of the interfaces visible to client
applications:
[0581] FIG. 15 does not depict process or processor boundaries,
which are made transparent by the client and server object request
brokers (ORBs). Application services are provided through object
interfaces formally defined in the CORBA Interface Definition
Language (IDL).
[0582] The service objects resident on the server with which client
applications interact are shown in Tablelin FIG. 16.
[0583] Client applications which register for real-time status
updates or notification of events, alarms or configuration changes
must provide a reference to a local callback object which the
Server will use to propagate information asynchronously. The
callback interfaces defined in the EMAPI are listed in Table 2
shown in FIG. 17. Classes which implement these interfaces must be
defined and instantiated in Client code.
[0584] Data Representation
[0585] There are several fundamental data types defined in the
EMAPI, which fall into one of two categories shown in FIG. 18.
[0586] Session Management
[0587] Each EM Client session is logically associated with a login.
Session identifiers are assigned by the EM Server when the client
registers with the user session manager at initialization. Each
Client application is logically associated with a session.
Application identifiers are assigned by the Client. For the Element
Manager Graphical User Interface, each "window" will be assigned a
unique application id. Note that each Client is required to
register a periodic heartbeat to validate for the Server that its
associated session is still active.
[0588] The UserSession service object provides the following
interfaces:
[0589] start
[0590] This method must be invoked by a Client at initialization to
register a new session.
[0591] stop
[0592] A Client invokes this method to notify the Server that the
associated session is terminating, and that all resources utilized
by any of the applications associated with the session should be
released.
[0593] stopApplication
[0594] A Client uses this method to notify the user session manager
of termination of a single application.
[0595] heartbeat
[0596] This method must be invoked at least every
UserSession::HeartbeatPe- riod seconds to avoid a timeout condition
which, when detected by a Server audit, will result in the release
of all resources utilized by any application associated with the
respective session.
[0597] Managed Objects
[0598] A managed object (MO) is an abstract representation of a
physical or logical resource which may be managed by the EMS, such
as a network element, maintenance unit or data link. The EM Server
will implement one application-specific service object for each
type of physical or logical resource to be managed. Each of these
service objects defines a set of attributes which identify managed
object properties, as well as the operations which may be performed
on a specified managed object instance. (The decision to provide
access to instance information through a single "service object"
stems from the fact that current ORB implementations become
unstable when managing large numbers of remote references.) The
diagram shown in FIG. 19 depicts the relationship between Client,
application-specific service object, and the internal Server
representation of managed object instances.
[0599] Each managed object service class is uniquely identified by
a ClassCode. Each managed object instance is uniquely identified by
an InstId. Any object instance in the system may be uniquely
referenced by a managed object identifier (Oid), which is the
combination of ClassCode and InstId.
[0600] Managed object status information is reported by a service
object as a sequence of attribute code-value pairs. Each attribute
value is defined as a union of all of the EMAPI fundamental data
types described in the section herein pertaining to DATA
[0601] Representation.
[0602] Configuration information is reported as a sequence of
ConfigData structures, which are defined to contain:
[0603] network element instance id
[0604] managed object instance id
[0605] a managed object key list reported as a sequence of
attribute-value pairs (when length is greater than 0, the key list
usually specifies one or more LogicalIds)
[0606] Each managed object service class must implement the MO
interface, which defines the following configuration and status
services:
[0607] viewConfig
[0608] A client uses this method to obtain the current EMS view of
the managed object configuration for a specified network element
instance. Note that the reserved instance identifier AnyInstance
may be used to obtain configuration information for all network
elements.
[0609] notifyConfig
[0610] A client may also register for managed object configuration
information via callback. In this case, an initial view is returned
with a notification type CONFIG_INIT.
[0611] Subsequent changes are reported with type CONFIG_CREATE or
CONFIG_DELETE.
[0612] cancelNotify
[0613] A client uses this method to cancel registration for managed
object configuration notifications associated with a specified
client application.
[0614] getPersistent
[0615] A client may use this method to retrieve the set of
attribute codes (SeqAttrCode) identifying all "persistent" data
maintained by this service object. The associated attribute values
for each managed object instance are stored and kept current
irrespective of any client requests.
[0616] viewStatus
[0617] A client may invoke this method to obtain the EMS view of
the current values for a specified set of persistent attributes for
a specified managed object instance.
[0618] getstatus
[0619] A client may use this method to register for a snapshot of
current status information. This interface differs from the
previous one in that the requested attribute list may specify any
managed object attribute codes--not just those associated with
persistent data, and the information is returned via client status
callback (StatusCB).
[0620] startUpdate
[0621] A client may also register for an initial view and
notification of any updates to a list of selected attributes for a
specified managed object instance. In this case, an initial view is
reported via client callback with a notification type STATUS_INIT.
Subsequent changes are reported with type STATUS_CHANGE. Note that
managed object instance deletions are reported only through
configuration change notification (to avoid a potential flurry of
client callbacks when a network element is unequipped).
[0622] stopUpdate
[0623] A client uses this method to cancel registration for managed
object status updates.
[0624] getlnst
[0625] A client may use this method to obtain a managed object
instance identifier for a specified network element instance id and
managed object key list.
[0626] Note that each method requires a client session application
identifier (SessionAppId) to validate user access. In the case of
configuration or status change notification registration, this
identifier is also used to keep track of the additional server
resources utilized while the client application is active.
[0627] Network Element Level Managed Objects
[0628] Each network-element level managed object must also
implement the NEMO interface which defines additional
network-element level configuration services:
[0629] viewNEconfig
[0630] A client may invoke this method to obtain the current EMS
view of the network element configuration.
[0631] notifyNEconfig
[0632] A client may also register for network element-level managed
object configuration information via callback. In this case, an
initial view is returned with a notification type CONFIG_INIT.
Subsequent changes are reported with type CONFIG_CREATE or
CONFIG_DELETE.
[0633] canceNEnotify
[0634] A client should use this method to cancel registration for
network element managed object configuration updates.
[0635] Note that each method requires a client session application
identifier to validate user access. In the case of configuration
change notification registration, this identifier is also used to
keep track of the additional server resources utilized while the
client application is active.
[0636] Descriptive Entity Objects
[0637] Application objects of this type are defined to provide type
and attribute information for abstract entities, such as data
communicated between the EMS and network elements which are not
part of a managed object description (e.g. SNMP trap definitions
and command groups). Descriptive entity objects provide no
implementation-they are defined and known by client applications at
compile time.
[0638] Event Distributor
[0639] An event is reported as a combination of the following:
[0640] 1. A header, which contains information of most general
interest:
[0641] Time of the event
[0642] Event category defined to be one of the following:
[0643] Alarm Set
[0644] Alarm Clear
[0645] Command Acknowledgment
[0646] Command Response
[0647] Configuration Change
[0648] Informational Message
[0649] Initialization
[0650] State Change
[0651] Network element object identifier
[0652] Network element alarm level (meaningful only for alarm
set)
[0653] Maintenance unit object identifier (if applicable)
[0654] Maintenance unit alarm level (meaningful only for alarm
set)
[0655] A command identifier (Cmdld) defined as a user session id
& command sequence number (meaningful only for command
acknowledgment & response)
[0656] 2. Event data defined as a sequence of structures which
contain:
[0657] A ClassCode of a managed object, network element or
descriptive entity
[0658] A sequence of attribute code-value pairs
[0659] Client applications may request a copy of the event stream,
as processed by the event distributor, filtered on information
specified in the event header. Filter wildcards are implemented
with "out-of-band" values:
[0660] Any Category
[0661] Any Class
[0662] Any Instance
[0663] Any Alarm
[0664] Any Cmd
[0665] The Table 3 described in FIG. 20 summarizes which filter
criteria are valid for each event category:
[0666] The event distributor processes filters by examining the
specified category and AND'ing together valid criteria. Clients may
simulate OR operations by registering multiple filters.
[0667] The EvtDist service object implements the following client
interfaces:
[0668] registerFilter
[0669] A client uses this method to register an event filter. A
filter identifier is returned.
[0670] cancelFilter
[0671] A client invokes this method to remove a specified event
filter, using the filter id returned from the associated
registration.
[0672] Note that each method requires a client session application
identifier to validate user access.
[0673] Alarm Manager
[0674] Alarm information is reported as a sequence of AlarmData
structures which contain:
[0675] The ClassCode of a managed object which defines a
network-element specific alarm record. Note that in the first
release of the EMS, only one network element active alarm table is
defined (ApActiveAlarms).
[0676] A sequence of alarm records, each of which contains an alarm
instance identifier and sequence of attribute code-value pairs.
[0677] Client applications may request a copy of all active alarms
filtered on any combination of the following:
[0678] Network element
[0679] Maintenance unit
[0680] Alarm level
[0681] Similar to the interfaces provided by the event distributor,
out-of-band values may be used to represent wildcards.
[0682] Since managed object instance information may not be
available at the time an alarm is reported, the actual alarm filter
criteria are specified in terms of logical identifiers. Logical IDS
are integer values which represent the logical numbers of devices
and interfaces (e.g. AP 4). The correlation between logical ids and
managed object instance identifiers is provided in the
configuration information made available by each managed object
service object, and through the utility method getInst. Refer to
the section on Managed Objects for additional details.
[0683] The AlarmManager client interfaces are written specifically
for the Active Alarm List application:
[0684] requestAlarms
[0685] A client invokes this method to register a filter for active
alarms.
[0686] changeFilter
[0687] A client may invoke this method to change filter
criteria.
[0688] refreshAlarms
[0689] A client may invoke this method to refresh the active alarm
list.
[0690] cancelAlarms
[0691] A client should invoke this method to de-register a
filter.
[0692] All operations except for de-registration return all active
alarms filtered on the specified criteria. Also, each of these
methods requires a valid client session application identifier to
validate user access, and to keep track of the additional server
resources which may be utilized while each client is active.
[0693] Exceptions
[0694] Exceptions are used for consistent and structured error
handling in both the EM Server and Client.
[0695] The CORBA specification defines many system exceptions:
[0696] BAD_PARAM
[0697] INV_OBJREF
[0698] NO_PERMISSION
[0699] BAD_OPERATION
[0700] NO_RESPONSE
[0701] OBJ_ADAPTER
[0702] .diamond-solid. .diamond-solid. .diamond-solid.
[0703] Refer to "The Common Object Request Broker: Architecture and
Specification" for an exhaustive list of mnemonics and the
associated exception descriptions.
[0704] Vendor-specific object request broker exceptions are also
defined (using the Minor identifier of the SystemException):
[0705] NO_IT_DAEMON_PORT
[0706] LICENCE_EXPIRED
[0707] .diamond-solid. .diamond-solid. .diamond-solid.
[0708] Currently, the EMS uses lona's Orbix product. Refer to the
"Orbix 2.1 Reference Guide" for an exhaustive list of mnemonics and
the associated exception descriptions.
[0709] In FIG. 21 an EMAPI-specific exception is defined, with an
EmapiExceptionCode containing one of a plurality of values.
[0710] In most cases, exceptions will be treated as fatal errors by
a Client resulting in termination of all associated
applications.
[0711] Those skilled in the art who now have the benefit of the
present disclosure will appreciate that the present invention may
take many forms and embodiments. Some embodiments have been
presented and described so as to give an understanding of the
invention. It is intended that these embodiments should be
illustrative, and not limiting of the present invention. Rather, it
is intended that the invention cover all modifications, equivalents
and alternatives falling within the spirit and scope of the
invention as defined by the appended claims.
APPENDIX A
[0712] Definition of Terms
[0713] Alarm A condition, usually of an unexpected nature, which
requires special and persistent technician notification.
[0714] Active Alarm A JAVA applet displaying the current active
alarms in the system for all
[0715] List Browser managed objects. A sample Active Alarm List
Browser Applet can be found
[0716] Applet in Attachment 2 on the Alarms Web Page.
[0717] ASN.1 Abstract Syntax Notation One: A formal language used
to define syntax. In the case of SNMP, ASN.1 notation is used to
define the format of SNMP protocol data units and of objects.
[0718] AP Application Processor refers to a commercial computing
system that provides generic computing facilities.
[0719] APCC Application Processor Cluster Complex: the
highly-available platform, or cluster computing environment, in
which an AP in the cluster can run the application services of
another AP in the cluster should that AP fail.
[0720] AP EMS The OA&M software architecture components that
reside on the AP to
[0721] Infrastructure support the APCC OA&M architecture. These
include the MIB on the AP, the SNMP agent on the AP, the event
handler, and other components described in section 4 of this
document.
[0722] API Application Programming Interface: a well-defined
software interface, usually abstracting the details of the
underlying implementation from the client of the interface.
[0723] Applet small Java program which is dynamically downloaded by
a Web browser and executed by its virtual machine. Though a Java
applet has access to many of the services provided by the browser
execution environment (e.g. audio, network access), it is also
restricted by the browser Security Manager (e.g. no access to local
file system).
[0724] Attribute A property of a managed object. An attribute has a
value.
[0725] Attribute Code A code that identifies a specific attribute
of a managed object class.
[0726] Class Code An integer value which uniquely identifies a
managed object class.
[0727] Client A function passed by the client to the server that is
used by the server to
[0728] Callback deliver asynchronous notifications of attribute
changes, configuration changes
[0729] Function or event notifications.
[0730] Client/Server A type of distributed computing
architecture.
[0731] Client An X-TerminallWorkstation or Windows 95 PC that can
host the EMS client
[0732] Terminal applications. These Client Terminals are commonly
referred to as a Client Application Workstation.
[0733] CMU SNMP Carnegie Mellon University SNMP Library that can
used to create a SNMP
[0734] Library manager and a SNMP agent.
[0735] Command A "short" reply to a command to indicate whether the
command was rejected,
[0736] Acknowledgm executed, or is in progress.
[0737] ent
[0738] Command "Lengthier" replies to a command, giving the results
of executing the
[0739] Response command. A command may have multiple responses.
[0740] Configuration Data of a non-transient nature. This is data
that is provisioned by the
[0741] Data technician (e.g. via Recent Change and Verify at the
ECP), as opposed to data associated with the operation/execution of
a managed object.
[0742] Configuration Generic term which has one of two meanings
depending on its context:
[0743] Information
[0744] With respect to a managed object class, this term applies to
the identification of all instances of the class, either for a
specific network element or for all network elements in the
system.
[0745] With respect to a managed object instance, this term may
apply to one or more attributes which are associated with database
values, such as the primary/alternate role of a duplex
component.
[0746] Containment A structuring relationship for managed object
instances in which the existence of a managed object instance is
dependent on the existence of a containing managed object instance.
An example is the RCS object contained within the AP object.
[0747] CORBA Common Object Request Broker Architecture: A
specification authored by the Object Management Group, a consortium
of more than 600 companies, for producing interoperable
applications that are based on distributed, interoperating
objects.
[0748] Element Manages network elements. In the initial releases of
PlanR, management is
[0749] Management limited to fault management.
[0750] System
[0751] Element A term used to encompass the OA&M infrastructure
components that do not
[0752] Management reside on the managed element (see AP EMS
Infrastructure).
[0753] System Server
[0754] EMAPI Element Management Application Programming
Interface
[0755] Event Generally, an autonomous notification. We have defined
four types of events that the AP can generate: alarms, reports,
state changes, configuration changes.
[0756] IS-634 An international standard suite that defines the
interfaces required to attach base stations from one vendor to the
MSC of another vendor.
[0757] IDL Interface Definition Language: A C++-like notation for
describing CORBA object interfaces. IDL is used to describe any
resource or service a server component wants to expose to its
clients without regard to its implementation language or operating
system
[0758] Inheritance The conceptual mechanism by which attributes,
notifications, operations, and behavior are acquired by a subclass
from its superclass.
[0759] Instance An integer value that identifies a specific
instance of a managed object and is
[0760] Identifier unique within its managed object class.
[0761] JAVA An object oriented programming language from Sun
Microsystems that is interpreted, allowing applications to run on
many platforms without change.
[0762] Logical An integer value which represents the logical number
of a device or interface
[0763] Identifier (e.g., AP4). Note that there is no direct
correlation between a logical id and instance id.
[0764] Managed An abstract representation of a resource that may be
managed by the network
[0765] Object management platform. Examples include a network
element, a maintenance unit, network element summary, datalink.
[0766] Managed A named set of managed objects that share the same
sets of attributes,
[0767] Object Class notifications and management operations. An
example is the AP managed object class.
[0768] Managed A code that identifies a specific managed object
class (unique to the system).
[0769] Object Class This code is a constant (enumeration or integer
definition).
[0770] Code
[0771] Managed The combination of managed object class code and
instance identifier defines
[0772] Object the managed object identifier. Also abbreviated as an
MOID.
[0773] Identifier
[0774] Method or An operation or method on a managed object
performs an action.
[0775] Operation
[0776] MIB Management Information Base: a data definition of
Network Element objects to be managed by a Element Manager, written
in an Internet-standard language, specific to the SNMP
protocol.
[0777] MMA Message Mapping Application: the application which maps
between the Autoplex Base Station Interface (ABI) call state and
message sequence and the IS-634 call state and message sequence.
MMA is sometimes referred to as Open A Interface (OAI).
[0778] Network A functional component of the Autoplex system such
as a cell site,
[0779] Element Application Processor (AP), Call Processing Data
Node (CDN), Executive Cellular Processor (ECP).
[0780] Network A JAVA applet depicting detailed status on the
managed objects belonging to
[0781] Element the network element. A sample view of the Network
Element Detailed Status
[0782] Detailed Applet can be found in Attachment 2 on the AP Web
Page.
[0783] Status Applet
[0784] Network Managed object attributes and their corresponding
values that represent the
[0785] Element Status status of the NE. The PlanR APCC NE status
consists of status for the RCS-AP, and IS-634-AP managed objects,
an active alarm list, and a table of outstanding commands.
[0786] Notification Information sent by an agent to a manager when
an event occurs at the associated network element. This includes
alarmed and informational messages, notification of configuration
changes within the network element, as well as acknowledgments to
technician input commands.
[0787] OAI AP An AP running the OAI application.
[0788] ORB Object Request Broker
[0789] Object The combination of managed object class code and
instance identifier which
[0790] Identifier uniquely identifies any managed object instance
in the system.
[0791] Persistent Information stored and kept current irrespective
of any client requests (e.g.,
[0792] Attribute maintenance state).
[0793] RAP API A general API for spawning a process and obtaining
the results of the process execution. Generally, RAPs will be used
to carry out a maintenance command on an AP resource. RAPs may
spawn other processes, if necessary.
[0794] RCC Reliable Cluster Computing. A Highly-Available (HA)
product from Lucent Technologies that provides the software and
hardware components to enhance the reliability, availability and
maintainability of a HA or clustered system.
[0795] RCS Radio Cluster Server. The application runs on the AP to
provide call processing and OA&M functionality for the PlanR
microcell. The software for this application is ported from the
Radio Cluster Controller of a Series II cell.
[0796] RCS AP The AP that hosts the RCS application.
[0797] Service Object The object that provides services for a
managed object class. Client applications acquire a reference to
this object (in CORBA they bind to the object). An example is the
AP service object and the Session service object.
[0798] Session Each client must establish a unique session that is
used to validate access permissions and for subsequent routing of
notifications.
[0799] SNMP Simple Network Management Protocol: an
Internet-standard protocol for managing Network Elements from a
Network Manager; provides three basic operations: GET, SET, and
TRAP (autonomous notification).
[0800] SNMP Agent The Software entity that resides on the Network
Element and interfaces to the Network Manager via the SNMP
protocol. This process listens on a specific UDP port in order to
receive SNMP requests from the Manager and forwards TRAPs from the
NE to the Manager.
[0801] SNMP Trap An autonomous notification from the Network
Element to the Network Manager.
[0802] State Change A change in one or more of the attributes
associated with a managed object.
[0803] Status Current attribute values for a managed object
instance.
[0804] Information
[0805] System A JAVA applet that displays a summary of the status
of all network elements
[0806] Summary in the system. In Attachment 2, an example of the
System Summary Applet
[0807] Applet can be found on the Network Web Page.
[0808] TI/OP Technician Interface and Output Processor. The
Autoplex subsystem where input commands and output reports are
handled.
[0809] X Terminal A type of client terminal that only displays the
X protocol and can not host the EMS client applications. Instead,
the client applications run on the Server and are displayed (via
the X protocol) on the X terminal.
[0810] Glossary of Acronyms
[0811] 1. GLOSSARY
[0812] ACF Agent Configuration File
[0813] AP Application Processor
[0814] APCC Application Processor Cluster Complex
[0815] API Application Programming Interface
[0816] ASN.1 Abstract Syntax Notation One
[0817] C/S Client/Server
[0818] CDPD Cellular Digital Packet Data
[0819] CD-ROM Compact Disk--Read Only Memory
[0820] CHAP Command Handler Access Point
[0821] CMIP Common Management Information Protocol
[0822] COGS Cost of Goods
[0823] CORBA Common Object Request Broker Architecture
[0824] DAT Digital Audio Tape
[0825] DCI Digital Computer Interface
[0826] DELPHI Desktop Windows Visual Development Tool from
Borland
[0827] EAI Emergency Action Interface
[0828] EI Emergency Interface
[0829] ECF Event Configuration File
[0830] ECP Executive Control Processor
[0831] ECPC Executive Control Processor Complex
[0832] EIN Ethernet Interface Node
[0833] EMAPI Element Management Application Programming
Interface
[0834] EMS Element Management System
[0835] FTP File Transfer Protocol
[0836] GUI Graphical Client Interface
[0837] HA High Availability
[0838] HA-OMP High Availability Operations and Management
Platform
[0839] HP Hewlett Packard
[0840] HPOV HP OpenView
[0841] HPOVNNM HP OpenView Network Node Manager
[0842] HTML HyperText Markup Language
[0843] HTTP Hypertext Transfer Protocol
[0844] ICMP Internet Control Message Protocol
[0845] IDL Interface Definition Language
[0846] IDS internal database subsystem
[0847] IP Internet Protocol
[0848] ipmap HPOVNNM component used to monitor up/down status of
network elements
[0849] JAR JAVA Archive
[0850] LAN Local Area Network
[0851] LMT Local Maintenance Terminal
[0852] Mbytes Megabytes
[0853] MIB Management Information Base
[0854] MMA Message Mapping Application
[0855] MO Managed Object
[0856] MOID Managed Object Identifier
[0857] NE Network Element
[0858] NEST Network Element Status Table
[0859] NLS Network Language Support
[0860] NMS Network Management System--obsolete term, replaced by
EMS
[0861] OAI Open A Interface
[0862] OA&M Operations, Administration and Maintenance
[0863] OMG Object Management Group
[0864] OMP Operations and Management Platform
[0865] ORB Object Request Broker
[0866] ovspmd OpenView System Process Management Daemon
[0867] ovstart HPOVNNM startup script, used to start up HP OpenView
runtime
[0868] ovtrapd OpenView Trap Daemon
[0869] ovw OpenView Windows
[0870] ovwdb HPOVNNM map database manager
[0871] pmd PostMaster Daemon (part of HPOVNNM)
[0872] PVM Platform Virtual Machine
[0873] RAP Resource Administration Process
[0874] RCC Reliable Cluster Computing
[0875] RCS Radio Control System
[0876] ROP Read Only Printer
[0877] SCANS Software Change Administration and Notification
System
[0878] SDP Status Display Pages
[0879] SLIQ Qmodem's defined scripting language
[0880] SNMP Simple Network Management Protocol
[0881] SSL Secure Socket Layer
[0882] SU Software Update
[0883] TCP Transmission Control Protocol
[0884] TI/OP Technician Interface and Output Processor
[0885] UDP Client Datagram Protocol
[0886] UX UNIX subsystem
[0887] WAN Wide Area Network
[0888] xnmevents X Network Management Events Browser (part of
HPOVNNM)
* * * * *
References