Posted 03/15/2000
The IP Services Game
Watching Every Piece in Increasingly Complex Networks
Requires Service Automation Systems
By Kevin Vadenais
A chess game has pawns, kings, queens, bishops, rooks and knights. But a player has to look at the board in its entirety--not just these individual pieces--to understand the game.
The same can be said about networks. Yet, current management systems for IP services tend to be centered on device/element management. As a result, these systems fail in three other areas crucial to rapid service delivery--automation of operations, scalability and open interfaces. Service automation systems, however, take a more holistic view of the network. Through customer and service focus, automation and open interfaces that facilitate integration of these systems with service provider systems and third-party applications, end-to-end service automation is enabled.
Limitations of Current Systems
With current management systems, the user may have to first manually configure ports on a device, configure the IP layer and conduct other low-level tasks to begin the service provisioning process. Command line interfaces and rudimentary element management systems are typically used for these operations. Much information, such as IP addresses and customer-specific data, is stored offline or in other systems and requires human intervention to piece together the complex process. This is not cost-effective and is prone to human error. It also delays the service provisioning process, causing lost or delayed revenue opportunities for the service provider and customer dissatisfaction.
A related drawback of existing management systems is the fact that many skilled--hard-to-find, highly paid, difficult-to-retain--engineering resources are required to perform many of the complex and repetitive operations in provisioning IP services such as setting up IP addresses and IP VPN designs/configurations externally to their systems. The user must manually enter this information at the time of service configuration. These systems do not take the complexity out of operations, track information for the user or eliminate repetitive tasks. The "bottom up," device/element design of these systems prevents any possibility for automation.
In addition, existing management systems lack truly open interfaces. Many systems require application partners, system integrators and service providers to interface their systems and applications to either a proprietary application programming interface or an open interface, that is, one the provider of the management system does not use itself and is not tested or proven. Truly open interfaces are required to facilitate rapid integration with third-party applications and carrier OSSs.
Service providers also are concerned about the scalability and fault tolerance of existing management systems. The main concern is how these systems will support large, growing networks and an expanding number of users--both within service providers and externally through advanced customer network management (CNM) services. Existing systems do not use standards-based technologies for building distributed architectures that scale system performance as the networks and number of users of the management systems grow. Because many systems are designed with a device/network element focus, they cannot support large-scale access of the management system, or data contained in the system, by service providers' customers. In addition, these systems are unable to support large-scale, nonstop carrier networks. Many systems use proprietary mechanisms for replicating databases and force service providers to adopt these architectures, including all of the headaches that go with them (such as database administration) to deploy their network equipment.
Another limitation of existing management systems is either their lack of security or complex and proprietary means of achieving some notion of it. Many systems are able to grant different levels of access to different classes of users (read-only, read-write, or "super user" privileges), but they fall short on offering full authentication and encryption among all components of the management system (clients and servers) and their communication with the network.
Fortunately, other options are emerging to help service providers take advantage of the broad IP services opportunity, estimated by International Data Corp. (IDC, www.idc.com) to be worth some $23 billion. Service automation systems, which help overcome the obstacles of existing management systems, are expected to drive the widespread deployment of new IP.
"To take full advantage of the estimated $23 billion IP services opportunity, service providers need to overcome the existing drawbacks of conventional management systems," Deb Mielke, principal of Treillage Network Strategies, says. "Service automation systems provide the type of open, automated and highly scalable solution needed to optimize the service provider's back-office systems, while enabling them to reduce time-to-service along with the rapid modification of these services."
Specifically, these systems allow IP services, such as network-based IP VPNs, to be provisioned on demand on an application- or project-driven basis. These capabilities allow carrier OSS work flows and processes to be optimized and highly integrated, thereby enabling end-to-end flow-through operations between a service provider's customers and their network.
For example, these systems can be used to solve the complex service provisioning and configuration process that has prevented widespread deployment of network-based IP VPN services.
Simplification, automation and rapid software integration capabilities are the key to solving this problem and driving the deployment of high-value IP services.
Harnessing the Knowledge Base
Service automation systems use policies and templates, defined in a standard lightweight directory access protocol (LDAP) server, to simplify and automate complex and repetitive operations.
A major drawback of existing systems is many skilled resources are required to configure and provision services; the ability to attract and train these people becomes the critical path to service activation. Service automation systems allow carriers to leverage the knowledge base of a single or small number of skilled resources.
In essence, policies and templates for tasks, such as IP address allocation, link and IP layer configuration, port allocations, etc., are defined in the directory server, thereby harnessing the knowledge of a small number of skilled resources. The service automation system uses the policies along with customer-specific data (policy driven or user entered) to create IP VPN services.
These capabilities allow service providers to reduce the time required to provision services--positively affecting revenue and customer service, decreasing their cost of operations, and creating advanced customer self-provisioning services that would not be possible if the complexity was not removed from the provisioning process.
"In the next five years, the aggressive ILEC programs to deploy broadband networking to all customers will expand the number of always-on IP customers by over 100 times," says Tom Nolle, president of analyst firm CIMI Corp. (www.cimicorp.com). "Without a service provisioning and management strategy designed to deal with this quantity of customers, and with the multiplicity of IP-based services they'd consume, service providers will be unable to exploit this broadband windfall. Most provisioning and management systems for IP services are polarized into Internet products or private-line products. The former don't offer reasonable support for VPN services, and the latter don't scale to support the tens of millions of low-data-skilled users who will make up the mass market for public IP. What the industry needs is a powerful service-directed management strategy that will support the IP network of the future."
A good service automation system architecture makes innovative use of standard technologies such as: common object request broker architecture (CORBA) and extensible markup language (XML); LDAP directory server; Java browser-based client; and simple network management protocol (SNMP).
Diagram: Service Automation System Architecture
In addition, the system must include standards-based security among all components of the system. The "Service Automation System Architecture" diagram, above, shows four communication paths--all must be capable of ensuring secure communications. The following protocols and technologies could be used to accomplish this:
* Browser client or other application--management server: Internet inter-ORB protocol (IIOP) running over secure sockets layer (SSL);
* Management server--IP services switch: SNMP version 3;
* IP services switch--LDAP directory server: LDAP running over SSL; or
* Management server--LDAP directory server: LDAP running over SSL.
These capabilities provide flexible and granular security options, including customer and object-level locking, for the service provider. They enable service providers to grant secure system access to many different users, including operators, administrators, network engineers and marketing/sales personnel responsible for creating new service offerings.
Each class of user may have different privileges and a distinct view of the information contained in the system. In addition, these features make unique service offerings, such as advanced CNM services, possible. Carriers easily can provide customers with a view into their subscribed portion of the network as well as the ability to modify and change it. This type of a service offering requires the system not only to be secure throughout, but also to be focused on customers and services and be integrated easily with service provider OSSs.
The service automation system architecture shown in the diagram is different from other management architectures in that LDAP (as well as SNMP) is built into the network element/device (IP services switch). This capability-directory-enabled management-allows the device to automatically store a copy of its current working configuration. Users and applications do not need to query a device for its configuration. The current configuration, along with customer and service provisioning information, is stored in the directory and can be accessed easily, thereby saving time and network bandwidth. Any application can access this information through well-defined, standards-based CORBA or XML interfaces.
Open APIs Equals Rapid Integration
An important system requirement for end-to-end service automation between service providers' customers and their networks is truly open interfaces (see "Service Management Drives Automation" diagram).
Diagram: Service Management Drives Automation
To be open, interfaces must use industry standards that facilitate rapid integration--standards that other systems and applications use as well. It is not good enough just to provide open interfaces. The interfaces must be tested, proven and well documented.
For example, the "Service Automation System Architecture" diagram describes an architecture where the browser-based client (through the client applets) uses the CORBA/XML interface to access the system. It uses the same open interface that third-party developers, system integrators or service providers would use. This type of design creates a truly open interface--standards-based, tested, proven and documented--that enables very rapid integration with other systems.
CORBA provides a standards-based framework that allows applications to transfer data and otherwise interoperate. Using this technology, a network service provider or system integrator can, in a relatively short time, integrate OSSs with software components from an external vendor. Similarly, XML is another platform-neutral technology that quickly is becoming an open standard for data transfer between distributed systems.
Service Automation Features |
|
Source: Ennovate Networks Inc. (www.ennovatenetworks.com) |
Using either of these greatly improves the productivity of programmers trying to integrate disparate systems. CORBA is backed as a standard by the Object Management Group (OMG, www.omg.org), a consortium consisting of numerous system vendors. It is a mature technology that has undergone numerous revisions in the last decade. Unlike CORBA, XML was born from the technology that runs the World Wide Web. HTML, which is the data format all web browsers use to display content, is simply a type of XML. Because of its ubiquity in the form of HTML, XML has the potential to become the most popular data transfer mechanism available.
Service Automation Benefits |
|
Source: Ennovate Networks Inc. (www.ennovatenetworks.com) |
Directory-enabled management--the innovative use of an LDAP directory service--is a key component of this architecture. LDAP services are widely used to support intranet applications and Internet e-commerce applications, and their distributed architecture supports wide geographical implementation.
Why not use a conventional database? Directories typically have a higher read-to-write ratio than databases--this makes directories perfect for storage of network configuration information that is "often read, seldom written." Directories are typically more easily extended than databases--directories allow extensions to be made in response to new needs and applications. They are usually more widely distributed than databases. Data distribution is a fundamental factor in designing directories, thereby allowing flexibility in designing centralized or completely distributed management solutions. Directories are often replicated on a higher scale than databases--the reasons for replication include reliability, availability, locality of management information and overall system performance. Compared with databases, which only support a very small number of replicas, directories support replication on a much larger scale. Replication can be used to provide system fault tolerance and to design a large-scale CNM service. By locating replicas close to customers accessing the service, network latency of directory requests is decreased while the number of users supported by the system is amplified. Directories usually have very different performance characteristics than databases. Databases typically handle hundreds of transactions per second while directories typically handle thousands or tens of thousands of queries per second. Support for standards is important in directories, less so in databases. For example, LDAP allows the decoupling of directory clients from directory servers. It allows an LDAP client, embedded in an IP services switch, to speak with any LDAP directory server.
Complexities of IP VPNs |
|
Source: Ennovate Networks Inc. (www.ennovatenetworks.com) |
The LDAP directory not only stores customer, provisioning and configuration information, but also contains a registry of all system components and distributed processes. Users do not need to know where the information is located; they simply ask for it, and the system locates the information and presents it to them. Management operations can be centralized or distributed. Either way, the system provides a unified view of the network. Additionally, customer-specific views can easily be created and supported.
Kevin Vadenais is senior product line manager for Ennovate Networks Inc. (www.ennovatenetworks.com). He can be reached at kevinv@ennovatenetworks.com.
