M.001 Administrative Services White Paper
revision 1.0
Note: This document has been renamed to M.001. The original name was S.009. On some of the following pages, this document will be refered to as S.009. In the future, all Administrative Services Interoperability Agreements will be in the M.XXX series.
Abstract
This document provides the vision and a roadmap for ECTF Administrative Services Task Group.
©1996, 1997 Enterprise Computer Telephony Forum
This document is copyrighted and all rights are reserved by the Enterprise Computer Telephony Forum (ECTF). ÒECTF technical implementation agreements are considered public domain and may be copied, downloaded, stored on a server or otherwise re-distributed.Ó
DISCLAIMER
Interoperability Agreements are the result of a collaborative, volunteer effort of ECTF Members, their employees and others. ECTF shall at no time have any responsibility or liability whatsoever to ECTF Members or any other party for the accuracy, completeness, non-obsolescence or any other aspect of any Interoperability Agreement or any response by ECTF to any ECTF Member's or any other party's questions respecting any Interoperability Agreement.
All comments or questions relating to the ECTF or their specifications should be submitted to:
Enterprise Computer Telephony Forum (ECTF)
39355 California Street, Suite 307
Fremont, CA 94538
(510) 608-5915
(510) 608-5917 (Fax)
e-mail :
web site :
About ECTF
As Computer Telephony (CT) becomes an integral part of the entire communications network including the Internet, there are increasing challenges to making diverse communication products work together. The ECTF is focused on solving the technical challenges of interoperability for the benefit of users and developers alike.
Founded in 1995, the ECTF is a non-profit organization composed of Computer Telephony suppliers, developers, systems integrators, and users from the Americas, Europe, and Asia/Pacific. Together we discuss, develop, and test approaches to successful multilayer interoperation within the PSTN, IP, and enterprise information system environments. Successful multilayer interoperation enables application solutions that can exploit the full range of contemporary communications capabilities while lowering costs for both developers and users.
The ECTF Technical Committee has worldwide scope and addresses global technical needs for:
¥Convergence of computing and telephony
¥Interoperability of defacto and de jure computer telephony standards
¥Consistency of computer telephony interfaces
¥Availability of scalable, networked, extensible computer telephony platforms and applications
Its goals are as follows:
¥Provide architectural frameworks for interoperability
¥Foster efficient and effective development of computer telephony products and services
¥Facilitate industry acceptance of interoperability through non-ambiguous common implementation agreements
¥Promote industry cooperation and exchange
The Technical Committee has a number of working groups (WGs) and task groups that underscore the areas of ECTF interest, such as:
¥Administrative Services
¥Application Interoperability
¥Architecture
¥Call Control Interoperability
¥Computer Telephony Services Platform
¥Hardware Components Interoperability
If you are a developer or a user of Computer Telephony products and services, we invite you to join the ECTF and help influence the direction and growth of the Computer Telephony Industry.
Contents
About ECTF
Contents
Section 1 : Introduction
1.1Mission Statement
1.2Overview
1.3Audience
Section 2 : Problem Statement
2.1Necessity of Administration
2.2Complexity in Administration
Section 3 : Solution Statement
3.1Solution Architecture
3.1.1Administration Application
3.1.2Management Application
3.1.3Administration API
3.1.4Administration AIA
3.1.5MIB
3.1.6SNMP
3.1.7SNMP API
3.1.8S.200 Communications
3.1.9SNMP Communications
3.1.10SNMP Master Agent
3.1.11AgentX
3.1.12S.200 < -- > AgentX
3.1.13CT Server Agent
3.1.14CT Server Sub-Agent
3.1.15ACI SDK
3.1.16AgentX Communications
3.2Solution Deliverables
3.2.1S.009 Administrative Services White Paper
3.2.2S.900 Administration Application Interface Specification
3.2.3S.901 Administration Sub-Agent Interface Specification
3.2.4S.910+ Administrative Services Implementation Guidelines
3.2.5S.950+ Administrative Services Implementation Detail
Section 4 : Areas of Administrative Services
4.1Configuration Management
4.2Fault Management
4.3Performance Management
4.4Accounting
4.5Security Management
Section 5 : Levels of Administrative Services
5.1Server Level
5.2Resource Level
Section 6 : Phases of Administrative Services
6.1Installation Phase
6.2Start/Stop/Service Phase
6.3Operational Phase
Section 7 : Classes of Service
Section 8 : Protocol Independence and Guideline Approach
Section 9 : Conclusion
Section 1 : Introduction
1.1Mission Statement
The mission of the ECTF is:
ÒTo support the rapid advancement of an efficient and compatible technology base that promotes a competitive Computer Telephony Integration (CTI) market. The ECTF will facilitate the implementation and acceptance of CTI solutions by bringing together suppliers, developers, systems integrators, and users to discuss, develop and test interoperability techniques for dealing with the diverse technical approaches to computer telephony integration. The ECTF will address both the technical and market education issues necessary to achieve interoperability among CTI standards and technologies across the heterogeneous client and client server enterprise.Ó
The ECTF Administrative Services Task Group's mission is:
ÒTo solve issues associated with managing a Computer Telephony Server by providing a standard data schema for administering ECTF S.100 compliant hardware and software components. The Administrative Services Task Group provides the information that defines an identical infrastructure for otherwise vendor unique implementations of the Computer Telephony Server.Ó
1.2Overview
This document provides the vision and a roadmap for ECTF Administrative Services Task Group. In particular, it:
¥states the problems that are believed should be addressed by this Task Group
¥illustrates the motivations to solve those mentioned problems
¥proposes a roadmap to a general solution to the set of stated problems
In addition, this white paper also discusses issues on how decisions are made when trying to solve the stated problems.
The rest of this white paper is organized as follows:
¥ÒSection 1 : IntroductionÓ presents the mission statement, this overview, and the intended audience.
¥ÒSection 2 : Problem StatementÓ presents the problems by discussing necessity and difficulty of administration.
¥ÒSection 3 : Solution StatementÓ proposes the roadmap to a general solution to the set of stated problems.
¥ÒSection 4 : Areas of Administrative ServicesÓ, ÒSection 5 : Levels of Administrative ServicesÓ, and ÒSection 6 : Phases of Administrative ServicesÓ discusses three dimensions of our roadmap to the solutions respectively: horizontal, vertical, and temporal.
¥ÒSection 7 : Classes of ServiceÓ describes a fourth dimension, class of service, that we plan to define in the future.
¥ÒSection 8 : Protocol Independence and Guideline ApproachÓ proposes that our intended approach is protocol independent.
¥ÒSection 9 : ConclusionÓ covers our concluding remarks.
1.3Audience
This document is for individuals who are working in the areas of Computer Telephony Integration (CTI), enterprise networking, and network management.
Section 2 : Problem Statement
2.1Necessity of Administration
Computer Telephony Integration delivers an exciting array of services and applications from a wide variety of diverse vendors. The ECTF is well positioned to bring order and a high level of interoperability to the various solutions being planned. These solutions are likely to be even more wonderful than anyone could imagine today. Customers will be anxious for the latest advancements and will be adding services and applications at a quick pace as each piece is designed to work together.
But, there is a danger. Without adequate support of sophisticated administration capabilities, these new applications may cause more harm than good. To illustrate the point, here are several key questions that will need to be addressed once the complexity of the CT application base becomes significant.
¥How do I know if all my servers are running okay?
¥How do I start or stop a server?
¥What applications are currently running?
¥How often is each resource used?
¥What interface cards are currently installed on each server?
¥How will I know if a particular network resource becomes unavailable?
¥Are some applications running out of resources?
¥What version of each resource is currently running?
¥What is the performance of a CT Server and its components?
¥If I need to bill the people that are using the resources, how do I know who's using them?
¥How do I get information with similar or even identical structure (e.g., statistics) from different servers (e.g., CT Servers, e-mail servers, and database servers) by using just one tool?
These questions may be easy to answer if you have one or two servers running one or two applications. But if you have many CT Servers geographically separated with many applications running, all interdependent on each other, management tasks performed by human administrators with ad hoc tools will not be effective. Furthermore, if we consider enterprise networking, where CT Servers interact with other types of servers (e.g., e-mail servers and database servers), effective administration is only possible with network management systems based on standards. And management systems are only as good as the information provided by the underlying devices being managed.
2.2Complexity in Administration
Administration amounts to the gathering of information and making adjustments based on that information towards a desired level of operation. To allow CT Server administrators to effectively manage the components in the CT Server, Òinformation gatheringÓ services and Òadjustment makingÓ services must be made available.
Naturally, resource and server vendors providing the low level services could easily create proprietary interfaces, APIs or communication protocols. Such a progression would force application vendors creating administration applications to cope with different interfaces each requiring a separate learning curve and software support base.
Furthermore, resource and server vendors might stress different priorities on the information and choose to postpone access to some areas of information or control until some later date. This would prevent application vendors from creating consistent administration applications and thereby CT Server administrators the ability to make comparisons between resources or servers that perform similar functions but from different vendors.
Each resource and server vendor that needs to develop a low level administration interface will spend the time, effort and money to create an interface design from scratch.
With the advent of Internets and Intranets, enterprise networks have grown dramatically both in size and sophistication. CT Servers, together with the applications they provide, will be integrated with the enterprise networks (actually it is indicated in the term Enterprise Computer Telephony). As a result, the administrative tasks of CT Servers should also be considered in the enterprise networks, which makes the administrative tasks even more difficult.
In summary, there are exciting opportunities in the field of CTI. However, there are also many challenges for administrative services. We are going to provide solutions to the stated problems. Although not all of the problems mentioned will be solved in the first efforts of this task group, our vision is broad and long term.
Note: The statement above uses the term Òadministration interfaceÓ to mean the set of data structures and actions to administer the server and resources. It does not mean the GUI representation that will be presented to an end-user administrator. The Group has purposely avoided describing administration applications. The implementation details of administration applications are beyond the scope of concern for this group. The Group recognizes that the quality and presentation of administration screens and utilities is a potential area of value-add and distinguishability for S.100 implementors and does not find standardization of administration applications a beneficial endeavor.
Section 3 : Solution Statement
3.1Solution Architecture
The solution offered by the Group takes the form as shown in the following architectural diagram:
Figure 3-1Architecture Diagram
3.1.1Administration Application
This is just any application that can configure/start/stop/collect statistics, etc. from the CT Server. A typical administration application uses the Administration API to communicate with the CT Server. An example could be an application that maintains/configures the profiles on the CT Server.
3.1.2Management Application
This is an application that is used to configure/start/stop/collect statistics, etc. from multiple heterogeneous Servers. A typical management application has multiple uses; it can be used to configure a network, CT Server, etc.
3.1.3Administration API
This is a set of functions which administration application developers use.
3.1.4Administration AIA
This is a specific AIA for the administration API. The AIA (Application Interface Adapter) is a component providing the client side of a client server connection to an CT Server.
3.1.5MIB
Management Information Base. A MIB is like an information warehouse and it represents some entity.
3.1.6SNMP
Simple Network Management Protocol. It is used to provide basic monitoring and control services for TCP/IP protocol suites based networking environment.
3.1.7SNMP API
This layer would interpret the MIB variables and operations on them and convert them to an appropriate message. These messages are sent to the Master Agent on a Server.
3.1.8S.200 Communications
This is the method by which an administration application sends and receives messages from the CT Server Agent. This could be different from the communications used for the S.100 based applications.
3.1.9SNMP Communications
This is the method by which a Management Application sends and receives messages from the SNMP Master Agent.
3.1.10SNMP Master Agent
This is a component on the Server that receives SNMP messages from Management Applications. It has built in knowledge to route messages to appropriate Sub-Agents that can handle that message.
3.1.11AgentX
Agent Extensibility. It is a set of technology specifications defined by the IETFÕs (Internet Engineering Task Force) Agent Extensibility working group. It mainly consists of a platform-independent protocol which supports intra-agent communication within a device or a local area network.
3.1.12S.200 AgentX
This is a component that accepts AgentX messages from the SNMP Master Agent, translates the AgentX messages into S.200 messages and sends them to the CT Server Agent. It also processes the messages in the reverse order, that is, receives S.200 messages from the CT Server Agent, translates the S.200 messages into AgentX messages and sends them to the SNMP Master Agent.
3.1.13CT Server Agent
This is a component on the CT Server that manipulates administration messages. These messages can either be from an administration application or a management application. It has built in knowledge to route messages to appropriate CT Server Sub-Agents that can handle that message.
3.1.14CT Server Sub-Agent
This is the component that understands a specialized set of messages and it performs the task requested by the message. This would normally involve sending a message back to the sender.
3.1.15ACI SDK
Administration Communication Interface SDK. This is the set of SDK functions that support the protocol to communicate between the CT Server Agent and the CT Server Sub-Agents. CT Server Sub-Agents utilize these SDK functions to create administration points within the CT Server.
3.1.16AgentX Communications
This is the method used to communicate between master agents and sub-agents based on AgentX technology.
3.2Solution Deliverables
The Task Group will provide solutions in the following forms:
3.2.1S.009 Administrative Services White Paper
The document you are now reading. It provides the vision and a roadmap to the Group's work. Anyone interested in ECTF Administrative Services should read this document.
3.2.2S.900 Administration Application Interface Specification
This document includes the description of data structures and actions that define the interface to be used by administration applications. All vendors wishing to write administration applications should read this document.
3.2.3S.901 Administration Sub-Agent Interface Specification
This document includes the description of data structures and actions that define the low level interface to be provided by the CT Server, resources for administration. All vendors wishing to write servers or resources should read this document.
3.2.4S.910+ Administrative Services Implementation Guidelines
These documents takes the S.900 and S.901 documents one step further by defining the interfaces as embodied in one or more existing standard protocols. See ÒSection 8 : Protocol Independence and Guideline ApproachÓ.
3.2.5S.950+ Administrative Services Implementation Detail
These are not documents but actual machine readable files to be used by vendors. One of the first to be created will be a MIB coded in ASN.1 for SNMP. See ÒSection 8 : Protocol Independence and Guideline ApproachÓ.
An administrative service can be viewed from the following three* dimensions:
¥horizontal (areas) -- configuration, fault, performance, accounting, security
¥vertical (levels) -- resource, server
¥temporal (phases) -- installation, start/stop/service, operational
For example, it could be an instance of configuration management for a type of resource during the installation phase. The solution deliverables by this group are going to address those three dimensions, as reflected in the following table.
Note: *A forth dimension is planned for future revisions of this document. See ÒSection 7 : Classes of ServiceÓ.
Table 3-1Relationships between Solution and DimensionsSolution Deliverables / Dimensions of Administrative Services
S.901, S.950 / All horizontal areas, resource level, all temporal phases.
S.901, S.900 / All horizontal areas, server level, all temporal phases.
In sections 4, 5, and 6, we discuss the three dimensions of administrative services for CT Servers in detail.
Section 4 : Areas of Administrative Services
The Group has adopted the OSI view of network and system management as the guideline to define the administrative services. That is, a CT Server will provide administrative services which satisfy the five functional areas of network and system management, as reflected in figureÊ4-1. The priority of network and system management is generally indicated by the order of the areas in section 4.1 through section 4.5.
Figure 4-1Areas of Administrative Services
4.1Configuration Management
Exercises control over, identifies, collects data from and provides data to managed objects for the purpose of assisting in providing for continuous operation of interconnection services. It names elements in a network and specifies their characteristics and state. This includes the information needed so maps of the network can be drawn, and exploded diagrams of device components can be shown by network management station application programs.
4.2Fault Management
Detects, isolates, and possibly corrects network abnormal operations.
4.3Performance Management