| Oracle® Communications IP Service Activator Concepts Release 7.2 E47715-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications IP Service Activator Concepts Release 7.2 E47715-01 |
|
|
PDF · Mobi · ePub |
This chapter provides a high-level summary of Oracle Communications IP Service Activator. It describes some of the key features, and the architecture and components of IP Service Activator.
IP Service Activator defines and fully automates the activation of services on large-scale multi-vendor IP networks. IP Service Activator delivers end-to-end network control and gives you the flexibility to react in real time to new service and customer demands.
Using an intelligent, policy-based engine, IP Service Activator generates a detailed model of the managed network and the many features supported by the devices in that network. Based on these reported capabilities, you can then set up VPN-based services, manage Quality of Service (QoS), perform SLA monitoring, and apply access control measures in your network from one point of control.
IP Service Activator translates your service and policy definitions into the complex, device-specific configuration commands needed to implement the requested services. The Network Processor, working through service-specific cartridges, updates all relevant devices throughout the network in real time, making the implementation and day-to-day management of the network as simple as possible.
IP Service Activator helps you address the issues of delivering value-added services, such as IP VPNs, by providing an automated alternative to time-consuming, and potentially error-prone, manual processes typically employed for service activation.
IP Service Activator includes a set of service modules, which model services and parameters, network-wide configuration relationships, policy-based activation logic, and service validation rules to implement services on your network. The service modules are vendor-agnostic. Additional device types are supported through cartridges to extend services to new types of vendor equipment.
The service modules comprise complex implementation details for the different services. However, the user interface interaction required to implement these services can remain simple and functionally oriented, making it easier for network operators to configure them. In other words, very complex tasks can be achieved with minimal operator interaction and no requirement for operators to retain detailed knowledge of the network implementation.
Service modules supported by a standard IP Service Activator implementation include:
Layer 3 MPLS VPNs (RFC 4364)
Layer 2 MPLS VPNs (Martini-draft)
Layer 2 MPLS Label Switched Paths (LSPs)
Virtual Private LAN Services (VPLS)
Metro Ethernet Virtual LAN (VLAN) Services
Quality of Service (QoS)
For more information, see "Service Modules".
IP Service Activator is designed as a multi-vendor solution, enabling you to deploy the most suitable devices for your service offerings without relying on equipment from a single vendor. For information about supported hardware, see IP Service Activator Installation Guide.
IP Service Activator's architecture is modular. Device management is handled through the Network Processor and corresponding cartridges, which are separate from the service activation and distribution components. This architecture allows new cartridges to be added as required. You can create custom cartridges using the IP Service Activator SDK.
The Network Processor is a data-driven XML-based processing engine that uses activation cartridges to support specific services on specific vendor equipment and operating system versions.
Requests for services and policies are converted into device and vendor-specific configuration commands, without the need to use templates and scripts. IP Service Activator determines which routers are affected by policies, the protocol to be used when updating device configurations, and the exact commands to be issued to the network. This frees network engineers to focus on other tasks.
IP Service Activator incorporates device discovery software to discover information about the physical network – routers, interfaces, and network segments – and create a detailed internal topology model. The discovery process also ascertains the capabilities of each device and interface. These capabilities define the services and policies that can be supported on each device.
The managed network can be displayed in the form of one or more topology maps, providing a logical and hierarchical representation of your network.
IP Service Activator keeps an internal model of the configuration of each device in the network, comprising the services and policies requested by users. IP Service Activator monitors each device to ensure that the expected configuration is not impacted by network events such as the device going down or by configuration changes made outside of IP Service Activator.
This removes the need for time-consuming manual interventions to track device capabilities and device configuration.
IP Service Activator uses a flexible policy model, which means that users can apply policies to any point in the network (where supported by the device).
A role-based policy model provides flexibility in the way in which services and policies can be applied across the network. Device and interface roles enable you to logically group devices and interfaces (for example by customer or service package), so policies can be applied specifically to the targeted group.
Use of device roles and an inheritance model means that policies created at a central point can be applied to all relevant points in the network with a single action, eliminating the need for repetitive, error-prone manual processes.
The application of policy rules defining conditions and actions means that high-level policies can be defined by your organization's business requirements and the actual details of implementation – the conversion from a high-level request to the actual configuration of a network device – are hidden from the operator.
The IP Service Activator knowledge store gives users a stateful understanding of network configuration as well as customer and service status. The knowledge store holds three types of inter-related information: a representation of network topology; details of services and policies to be configured; and full system data including status, fault, and logging information.
All changes made to the knowledge store are handled in the form of transactions, allowing you to exercise control over when and how changes take place. Used in conjunction with different levels of user access, transactions provide a granular and secure method for updating the knowledge store and configuring the network.
The intelligent data management within IP Service Activator automates the mapping of service changes to network device configurations. In addition, the data model can be shared with other operational support system (OSS) tools to support the deployment of additional new services.
The OSS Integration Manager (OIM) allows IP Service Activator to integrate with OSS applications, such as order entry, service assurance, fault management, and billing. The OIM consists of a CORBA-based API that allows third-party software to use IP Service Activator features without requiring detailed knowledge of the underlying implementation in IP Service Activator.
Oracle Communications has developed default support for applications from leading OSS providers, such as InfoVista.
IP Service Activator can be integrated with Oracle Communications Order and Service Management (OSM) using an optional Web Services component that is available during installation. For more information, see "Web Services API".
The event handler collects, filters, and delivers details of faults and other events occurring anywhere in the network managed by IP Service Activator. For more information, see "Fault and Event Reporting".
IP Service Activator comprises multiple capabilities to extend its activation capabilities based on custom requirements. This includes extensions at the Device Driver level as well as at User and API levels.
The Configuration Template Module (CTM) is a highly customizable configlet activation module which automates the creation of data-entry GUIs from simple XML configuration templates. The CTM provides automation for two purposes: the creation of configlets incorporating user or API parameter input, and the activation of routers. In this way, CTM replaces manual configurations and ensures configuration consistency for tasks of a repetitive nature.
You can use the CTM template in the IP Service Activator user interface (client) or by importing the CTM template into Design Studio. For more information, see Configuration Template Module on page 101.
IP Service Activator is designed to scale to carrier-class deployments, using its distributed software architecture. Additional servers can be added to increase its capacity. Servers can be installed geographically close to large groups of network elements, which can dramatically reduce the amount of management traffic running across the network.
The modular, distributed architecture of IP Service Activator is designed for scalability and resilience. It comprises a central policy server coordinating the access of multiple user interfaces to a database and controlling multiple distributed proxy agents or Network Processors. Each proxy agent uses one or more vendor-specific Device Drivers to control a number of network elements. Similarly, each Network Processor uses one or more integrated vendor-specific cartridges to communicate to a number of network elements (devices). Figure 1-1 illustrates the IP Service Activator system architecture.
This section describes the core IP Service Activator components illustrated in the diagram above.
The policy server is the central component of IP Service Activator. There is only one policy server for each IP Service Activator installation.
Functions of the policy server include the following:
Validating data
Managing user and system transactions
Calculating all policies and services requested by user interfaces and third-party applications
Discovering and modeling the physical network
Coordinating access to the central database
Downloading new configurations to the proxy agents for transmission to the devices.
Core transaction monitoring functions
Two additional components are always installed with the policy server, the naming service and the system logger.
IP Service Activator uses CORBA (Common Object Request Broker Architecture) for communication between components. The CORBA naming service acts as an intermediary between components by keeping track of each component's naming and location information. As each component starts up, it registers with the naming service, passing the service its details. When one component needs to contact another, it contacts the naming service for details of the component.
The proxy agent components are responsible for distributing the calculated configuration to the Device Drivers. The proxy agent is also responsible for scheduling policy rules that are date or time dependent.
Each proxy agent can manage a number of Device Drivers: the components that configure individual network elements. Each Device Driver converts the abstract expressions of services, such as definitions of virtual private networks (VPNs) and quality of service (QoS), into the appropriate commands required to configure each device.
Multiple Proxy Agent and Device Driver components can be installed to distribute the processing load when managing many devices within a network.
Proxy Agents and Device Drivers are usually located close to the managed devices in a distributed network.
The Network Processor uses Activation Cartridges that include XML-based vendor-specific and service-specific definitions for a number of device types. Oracle Communications offers several cartridges that support a wide range of services across various vendors and operating systems.
The Network Processor component is also responsible for distributing configuration to devices. The integrated Network Processor-Cartridge architecture enables the Network Processor to manage a large range of device types.
Each cartridge is a software unit that provides configuration commands applicable to a family of vendor devices and operating systems, and a service (for example, QoS). Cartridge units apply to specific subsets of devices and operating systems in a vendor family.
The following are some common features of the cartridges:
Connection re-establishment: Consistently retries to re-establish the network connection to the device in case of connection failure.
Save running configuration: Provides option to save the running configuration to non-volatile storage after successful changes in the configuration.
SSH support: Provides SSH connectivity to the device for secure sessions.
Password protection: Encrypts the password for increased security, during configuration auditing process.
Enhanced VRF management: This common VRF function allows you to set the wait time for the VRFs, number of retries; and enables you to choose whether the VRFs are to be deleted or saved in the device.
Threshold: The cartridges provide consistent support for different thresholds, enabling you to monitor the network events regularly and configure alarms.
Failed associations: This feature identifies the failed associations. You can flawlessly supervise and quarantine the failed associations in a configuration, minimizing the possibility of an error.
Offline Maintenance mode: This feature allows you to update concretes and persisted device models, with no commands actually delivered to the device. Offline Maintenance mode can be activated at the interface level or at the device level. You can access Offline Maintenance mode in the IP Service Activator client or by using the OIM or OJDL.
Anonymous Login: Supports anonymous login to the device.
The Web services API is an optional component that provides a Web services interface through which Oracle Communications Order and Service Management (OSM) can manage service activation activities and operations. For more information about OSM, see the Order and Service Management documentation. The interface is defined in the IP Service Activator Web Service Definition Language (WSDL) file. For more information about installing and configuring Web services with IP Service Activator, see IP Service Activator Installation Guide.
Oracle WebLogic Server is a required component for Web services. For information about WebLogic Server, see the WebLogic Server documentation.
IP Service Activator transactions can be transparently handled by the Web service. Each request sent to the Web service contains a list of commands. The commands are then performed using a single transaction. The Web service monitors the transactions and provides status notifications based on the result. For more information about transactions, see "Transactions".
The component manager is required on all host servers on which one or more IP Service Activator components are installed (except the user interface). The component manager is responsible for starting all components, monitoring and reporting their status, restarting any components that fail, and managing an orderly shutdown.
The IP Service Activator graphical user interface (client) is used to display the current view of the managed network and to set up and apply new services and policies. It can represent multiple managed networks in both hierarchical and graphical form. It allows you to set up and apply policy and create VPNs using straightforward drag and drop operations. It reports on the status of applied configuration, the managed network, and IP Service Activator components, and it reports faults and events occurring throughout the network.
The client is a distributed multi-user program, enabling users logged on to different hosts to control IP Service Activator and maintain the database. The policy server coordinates the information between these components, ensuring that each user's view of IP Service Activator remains consistent.
Each client host maintains a local version of the object model, which reflects locally made changes.
The permissions defined for a client what is displayed on the client; where access to a class of objects is denied, the objects do not appear.
Service assurance modules consist of InfoVista, Micromuse, and Topology exporter. In addition to the core components of IP Service Activator, the following service modules provide additional functionality.
The common module provides the common module framework for the other modules.
MPLS Label Switched Path (LSP) is an IP Service Activator module that allows you to provision LSPs on compatible Cisco devices.
From the IP Service Activator client, you can create, query, and delete MPLS LSPs. For more information, see "Layer 2 MPLS Label Switched Paths".
The InfoVista Integration module allows InfoVista to monitor and report on IP Service Activator's IP services. It offers a range of monitoring techniques that support SLA monitoring of point-to-point services, such as VPNs, as well as performance of specific interfaces. For more information, see "Integration with InfoVista".
The IP Service Activator Configuration Template module (CTM) allows you to do the following:
Create, update, and delete configuration templates. To create a template means to define XML code that auto-generates data-entry dialog boxes and commands for configuring specific attributes on specific device or interface types.
Activate templates by entering field data and sending the resulting command set to devices or interfaces
Perform related activities such as viewing template events, setting the lifetime of events, managing user access to CTM, and matching templates to schema versions
Import CTM templates using Oracle Communications Design Studio
For more information, see "About the Configuration Template Module".
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
