product overview - oracle · product overview – third edition preface preface about this document...

Product Overview

Third EditionDecember 2008

Oracle Communications IP Service Activator™ Version 5.2.4

Copyright © 1997, 2008, Oracle. All rights reserved.The Programs (which include both the software and documentation) contain proprietary information; they are provided under a license agreement containing restrictions on use and disclosure and are also protected by copyright, patent, and other intellectual and industrial property laws. Reverse engineering, disassembly, or decompilation of the Programs, except to the extent required to obtain interoperability with other independently created software or as specified by law, is prohibited.The information contained in this document is subject to change without notice. If you find any problems in the documentation, please report them to us in writing. This document is not warranted to be error-free. Except as may be expressly permitted in your license agreement for these Programs, no part of these Programs may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose.If the programs are delivered to the United States Government or anyone licensing or using the Programs on behalf of the United States Government, the following notice is applicable:U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the Programs, including documentation and technical data, shall be subject to the licensing restrictions set forth in the applicable Oracle license agreement, and, to the extent applicable, the additional rights set forth in FAR 52.227-19, Commercial Computer Software--Restricted Rights (June 1987). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.The Programs are not intended for use in any nuclear, aviation, mass transit, medical, or other inherently dangerous applications. It shall be the licensee’s responsibility to take all appropriate fail-safe, backup, redundancy and other measures to ensure the safe use of such applications if the Programs are used for such purposes, and we disclaim liability for any damages caused by such use of the Programs.The Programs may provide links to Web sites and access to content, products, and services from third parties. Oracle is not responsible for the availability of, or any content provided on, third-party Web sites. You bear all risks associated with the use of such content. If you choose to purchase any products or services from a third party, the relationship is directly between you and the third party. Oracle is not responsible for: (a) the quality of third-party products or services; or (b) fulfilling any of the terms of the agreement with the third party, including delivery of products or services and warranty obligations related to purchased products or services. Oracle is not responsible for any loss or damage of any sort that you may incur from dealing with any third party.Oracle, JD Edwards, and PeopleSoft are registered trademarks of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

Product Overview – Third Edition Contents

Contents

Preface ........................................................................................... vii

About this document ................................................................................ vii

Before contacting Oracle Global Customer Support (GCS) .............................viii

Contacting Oracle Global Customer Support (GCS) ......................................viii

Downloading products and documentation ..................................................viii

Downloading a media pack ................................................................... ix

Service Activator publications .................................................................... ix

............................................................................................................. ix

Chapter 1 Introduction ................................................................... 11

Summary ............................................................................................... 12

What makes Service Activator unique? ....................................................... 12

Expert Service Modules ....................................................................... 12

Flexible multi-vendor support ............................................................... 13

Sophisticated device discovery and management .................................... 13

Powerful policy-based management ...................................................... 14

Intelligent data modelling .................................................................... 14

Comprehensive OSS integration capabilities ........................................... 15

Event Handler .................................................................................... 15

Flexible Activation Extensibility ............................................................. 15

Scalability ......................................................................................... 15

IPv6 Support ..................................................................................... 16

Distributed architecture ............................................................................ 16

Core components .................................................................................... 17

Policy server and database .................................................................. 17

Proxy Agent and Device Drivers ........................................................... 18

Network Processor and cartridges ......................................................... 19

Component manager .......................................................................... 20

User interfaces ................................................................................... 20

Service Activator 5.2.4 iii

Contents Product Overview – Third Edition

Service Assurance modules ...................................................................... 20

Common module ................................................................................ 20

VLAN Activation Module ....................................................................... 20

MPLS LSP module ............................................................................... 21

IPsec VPN module .............................................................................. 21

InfoVista Integration module ............................................................... 21

Dynamic User VPN module .................................................................. 21

Configuration Template module ............................................................ 21

Chapter 2 Service Activator Solution ............................................... 23

The core Service Activator solution ............................................................ 24

Network discovery and representation ........................................................ 24

The discovery process ......................................................................... 25

Access and authentication ................................................................... 25

Device and interface capabilities ........................................................... 25

The topology model ............................................................................ 26

Mapping the network .......................................................................... 28

Device management and integrity ............................................................. 30

Communicating with the device ............................................................ 30

Modeling device configuration .............................................................. 31

Ensuring consistency and integrity ........................................................ 31

Managing data ........................................................................................ 32

The knowledge store ........................................................................... 32

Transaction-based processing .............................................................. 34

Security access .................................................................................. 36

Chapter 3 VPN/Connectivity Services ............................................. 39

Layer 3 MPLS VPNs (RFC 2547) ................................................................. 40

Key concepts ..................................................................................... 40

Summary of Layer 3 MPLS VPN support ................................................. 45

VRF tables ......................................................................................... 46

PE-PE routing - iBGP ........................................................................... 48

PE-CE configuration ............................................................................ 49

eBGP configuration ............................................................................. 50

iv Service Activator 5.2.4

Product Overview – Third Edition Contents

Dynamic User VPNs (DU VPNs) ................................................................. 51

Layer 3 IPsec VPNs .................................................................................. 53

Supported services ............................................................................. 53

Layer 2 MPLS VPNs (Martini) ..................................................................... 54

Implementation scenarios ................................................................... 54

Supported devices and data types ........................................................ 54

Layer 2 MPLS Label Switched Paths (LSPs) ................................................. 56

Supported services ............................................................................. 56

Layer 2 Transparent LAN Services ............................................................. 57

Key concepts ..................................................................................... 57

Service Activator’s implementation ....................................................... 59

Metro Ethernet Virtual LAN (VLAN) Services ................................................ 61

Circuit Cross Connect ............................................................................... 63

Layer 2 switching CCCs ....................................................................... 64

MPLS tunneling CCCs .......................................................................... 64

Alcatel HTML Generation .......................................................................... 65

Chapter 4 Policy-based Services ..................................................... 67

QoS and access control support ............................................................ 68

Policy configuration – key concepts ............................................................ 68

Policy elements – what is to be configured ............................................. 68

Policy targets – where policies are applied ............................................. 70

Configuring QoS policies ........................................................................... 74

QoS and CoS ..................................................................................... 74

Classifying traffic ................................................................................ 75

Marking traffic ................................................................................... 76

Traffic shaping and queuing ................................................................. 79

Policing ............................................................................................. 80

Modular QoS CLI ................................................................................ 81

Configuring access control policies ............................................................. 82

Overview of access control .................................................................. 82

How Service Activator implements access control ................................... 82

Chapter 5 Activation Extensibility ................................................... 85

Service Activator 5.2.4 v

Contents Product Overview – Third Edition

Pre-defined scripts ............................................................................. 85

Running scripts .................................................................................. 85

Developing scripts .............................................................................. 86

Configuration Template Module ................................................................. 87

Chapter 6 Integration Features ....................................................... 89

The OSS Integration Manager ................................................................... 90

Command set .................................................................................... 91

The External Object Model ................................................................... 91

Transaction monitoring functions .......................................................... 92

Uses of OIM ....................................................................................... 92

Fault and event reporting ......................................................................... 92

Subscriptions ..................................................................................... 94

Collection and filtering ........................................................................ 94

Delivery methods ............................................................................... 95

The OSS Java Development Library (OJDL) ................................................. 96

Out-of the-box integrations ...................................................................... 97

SLA monitoring .................................................................................. 97

Integration with InfoVista .................................................................... 99

..................................................................................................... 101

ASAP-IPSA Process Integration Pack (ASAP-IPSA PIP) ........................... 101

Fault management ........................................................................... 101

Index ............................................................................................ 105

vi Service Activator 5.2.4

Product Overview – Third Edition Preface

Preface

About this documentThe Product Overview is the first document you should read. It provides an outline of the key features and benefits of Service Activator, an overview of the distributed architecture, an explanation of the basic concepts of VPN services, policy-based services and of the capabilities extended by the Configuration Development Kit.

This document is intended for Sales and Marketing, Planners, and Training (new users of Service Activator). It consists of the following chapters:

Chapter 1: Introduction outlines the key features and strengths of Service Activator. It also gives an overview of Service Activator’s distributed architecture, and explains the role of each component and module.

Chapter 2: The Service Activator Solution explains the key characteristics of Service Activator, including how the network is modeled, how data is managed and how the physical network can be discovered and represented.

Chapter 3: VPN/Connectivity Services introduces the connectivity and network services that Service Activator can configure at Layer 2 and Layer 3, including MPLS-based Virtual Private Networks (VPNs), Transparent LAN Services (TLSs) and Circuit Cross Connects (CCCs).

Chapter 4: Policy-based Services introduces Service Activator’s Quality of Service (QoS) and access control features, providing an overview of QoS and the Service Activator elements used to implement policy-based services.

Chapter 5: Activation Extensibility explains how a number of applications (such as the CDK, CTM, and Network Processor) can be used to extend the activation capabilities of Service Activator.

Chapter 6: Integration Features explains how Service Activator can integrate with Operational Support System (OSS) applications and other third-party software using integration tools like the OSS Integration Manager, the Event Handler, and the OSS Java Development Library.

Service Activator 5.2.4 vii

Before contacting Oracle Global Customer Support (GCS) Product Overview – Third Edition

Before contacting Oracle Global Customer Support (GCS)

If you have an issue or question, Oracle recommends reviewing the product documentation and articles on MetaLink in the Top Technical Documents section to see if you can find a solution. MetaLink is located at http://metalink.oracle.com.

In addition to MetaLink, product documentation can also be found on the product CDs and in the product set on Oracle E-Delivery.

Within the product documentation, the following publications may contain problem resolutions, work-arounds and troubleshooting information:

— Release Notes

— Oracle Installation and User's Guide

— README files

Contacting Oracle Global Customer Support (GCS)You can submit, update, and review service requests (SRs) of all severities on MetaLink, which is available 24 hours a day, 7 days a week. For technical issues of an urgent nature, you may call Oracle Global Customer Support (GCS) directly.

Oracle prefers that you use MetaLink to log your SR electronically, but if you need to contact GCS by telephone regarding a new SR, a support engineer will take down the information about your technical issue and then assign the SR to a technical engineer. A technical support representative for the Oracle and/or former MetaSolv products will then contact you.

Note that logging a new SR in a language other than English is only supported during your local country business hours. Outside of your local country business hours, technical issues are supported in English only. All SRs not logged in English outside of your local country business hours will be received the next business day. For broader access to skilled technical support, Oracle recommends logging new SRs in English.

Oracle GCS can be reached locally in each country. Refer to the Oracle website for the support contact information in your country. The Oracle support website is located at http://www.oracle.com/support/contact.html.

Downloading products and documentationTo download the Oracle and/or former MetaSolv products and documentation, go to the Oracle E-Delivery site, located at http://edelivery.oracle.com.

viii Service Activator 5.2.4

http://metalink.oracle.com

http://www.oracle.com/support/contact.html

http://edelivery.oracle.com

Product Overview – Third Edition Service Activator publications

You can purchase a hard copy of Oracle product documentation on the Oracle store site, located at http://oraclestore.oracle.com.

For a complete selection of Oracle documentation, go to the Oracle documentation site, located at http://www.oracle.com/technology/documentation.

Downloading a media pack

To download a media pack from Oracle E-Delivery

1. Go to http://edelivery.oracle.com.

2. Select the appropriate language and click Continue.

3. Enter the appropriate Export Validation information, accept the license agreements and click Continue.

4. For Product Pack, select Oracle Communications Applications.

5. For Platform, select the appropriate platform for your installation.

6. Click Go.

7. Select the appropriate media pack and click Continue.

8. Click Download for the items you wish to download.

9. Follow the installation documentation for each component you wish to install.

Service Activator publicationsThe Service Activator documentation suite includes a full range of publications. Refer to the Service Activator Release Notes for more information.

Service Activator 5.2.4 ix

http://oraclestore.oracle.com

http://www.oracle.com/technology/documentation

http://edelivery.oracle.com

Product Overview – Third Edition

x Service Activator 5.2.4

Product Overview – Third Edition Introduction

Chapter 1

Introduction

This chapter covers the following topics:

high level summary of Service Activator

key features and specific strengths of Service Activator

architecture and components of Service Activator

Service Activator 5.2.4 11

Introduction Product Overview – Third Edition

SummaryService Activator is a software solution that allows Service Providers to define and fully automate the activation of profitable services on large-scale multi-vendor IP networks. 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, 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 QoS, perform SLA monitoring, and apply access control measures in your network from one point of control. Service Activator translates your service and policy definitions into the complex, device-specific configuration commands needed to implement the requested services. Distributed, intelligent Device Drivers then update all relevant devices throughout the network in real-time, making the implementation and day-to-day management of the network as simple as possible.

What makes Service Activator unique?Service Activator helps Service Providers address the issues of delivering value-added services such as IP VPNs by dispensing with the time-consuming, error-prone processes often employed for service activation. Service Activator’s rich feature set and unique characteristics ensure that Service Providers can deliver new services quickly and profitably.

Expert Service ModulesService Activator delivers a set of extensive and sophisticated “expert service modules”. They model the services and parameters, network-wide configuration relationships, policy-based activation logic, and service validation rules. These models are vendor-agnostic, so new device plug-ins can be simply developed and installed to support a given service on new vendor equipment.

The expert service modules comprise very elaborate intrinsic knowledge of the different services. Yet they provide very simplified service and functional-oriented views and activation methods to network operators. So they remove users from the real complexities of service management. Effectively, very complex tasks can be achieved with few mouse-clicks and little knowledge of the network implementation.

Expert service modules supported out-of-the-box include:

Layer 3 MPLS VPNs (RFC 2547)

Dynamic User VPNs (DU VPNs)

Layer 3 IPsec VPNs

Layer 2 MPLS VPNs (Martini-draft)

12 Service Activator 5.2.4


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 Assurance modules on page 20

Flexible multi-vendor supportService Activator is designed as a multi-vendor solution, enabling Service Providers to deploy the most suitable devices for their service offerings without having to be tied to a single vendor. Version 5.2.4 supports devices from Cisco Systems, Juniper Networks (M-series and E-series), Alcatel, Extreme, and Huawei. The architecture of Service Activator is modular in design; device management is the responsibility of specific Device Drivers, which are clearly separated from the service activation and distribution components. This architecture is designed to ensure that new Device Drivers can be added quickly and easily. Oracle Communications is continually updating the list of supported vendors, device models and operating systems to meet market requirements.

The fully-featured Device Drivers manage devices intelligently, converting requests for services and policies into device and vendor-specific configuration without the need to use templates and scripts. Service Activator determines which routers are affected by policies, the protocol to be used by the Device Driver when updating device configurations, and the exact commands that are issued to the network, enabling network engineers to focus on other critical tasks.

The Network Processor is an XML-based equivalent to the existing Proxy Agent/Device Driver architecture. It uses the Oracle Communications Activation "cartridge" plug-in concept for supporting specific services on specific vendor equipment and OS versions. Its data-driven nature makes it extremely flexible, and new vendor support going forward will be based on the Network Processor and cartridges.

This comprehensive multi-vendor support increases a Service Provider’s leverage with hardware vendors and enables them to deploy best of breed products to enhance service differentiation.

Sophisticated device discovery and management Service Activator incorporates device discovery software enabling it 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, defining the services and policies that can be supported.

The managed network can be displayed in the form of one or more topology maps providing a logical and hierarchical representation of your network.



Service Activator keeps an internal model of the configuration of each device in the network, comprising the services and policies requested by the user. 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 Service Activator.

For the Service Provider, this removes the need for time consuming manual intervention to track device capabilities and device configuration.

Powerful policy-based managementService 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 ensures complete flexibility in the way in which service and policies can be applied across the network. Device and interface roles enable the user 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 an 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 user.

Intelligent data modellingService Activator’s 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 users to exercise control over when and how changes take place. Used in conjunction with different levels of user access, the use of transactions provides a granular and secure method for updating the knowledge store and configuring the network.

The intelligent data management within Service Activator automates the complex mapping of service changes to network device configurations. In addition, the data model can be shared with other OSS tools, thereby speeding time to deployment of new services.



Comprehensive OSS integration capabilitiesService Activator has been designed for easy integration with the IP Operation Support System (OSS) applications that are vital to the business of Service Providers today.

The OSS Integration Manager (OIM) enables Service Activator to be easily integrated 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 Service Activator’s powerful features without requiring knowledge of the underlying complexity.

Oracle Communications has developed out-of-the-box support for applications from leading OSS providers such as InfoVista.

Support for rapid OSS integration means that Service Providers can quickly establish their support infrastructure and so improve their time to revenue.

For more information, see The OSS Integration Manager on page 90.

Event HandlerThe event handler collects, filters and delivers details of faults and other events occurring anywhere in the network managed by Service Activator. For more information, see Fault and event reporting on page 92.

Flexible Activation ExtensibilityService Activator comprises multiple capabilities to extend its activation capabilities based on custom requirements from Service Providers. 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.

The Service Activator OSS Java Development Library (OJDL) provides an Integrated Development Environment for general extensibility. The OJDL is a generic Java API to Service Activator, allowing Java developers to develop or customize interfaces, including web-based or intranet-based user interfaces.

ScalabilityService Activator is designed to scale to carrier-class deployments, using its distributed software architecture. Additional servers can be added to increase its



scalability. They can even be installed geographically close to large groups of network elements, which can dramatically reduce the amount of management traffic running across the network.

IPv6 SupportAll interface management configuration policies, which currently support IPv4 addresses and which are supported by the Cisco IOS cartridge, have been extended to support IPv6 addresses. However, this does not include the staticRoutes configuration policy, which is a separate feature.

IPv6 or "Internet Protocol Version 6"is the "next generation" protocol designed to replace the current version Internet Protocol, IP Version 4 ("IPv4"). Most of today's internet uses IPv4, which is now almost twenty years old. IPv6 fixes a number of problems in IPv4, such as the limited number of available IPv4 addresses. It also adds many improvements to IPv4 in areas such as routing and network autoconfiguration.

Distributed architectureThe modular, distributed architecture of Service Activator is designed for scalability and resilience. It comprises a central policy server co-ordinating 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).



Core components

Policy server and databaseThe policy server is the central component of Service Activator; there is only one policy server per Service Activator installation.

Functions of the policy server include the following:

Validating data

Proxy Agent Host (multiple instances)

Device DriverDevice Driver Device

Driver

Proxy Agent

User Interface Host

OIM Client

Host

Component Manager

Host

Third-party tool

User Interface

Network Processor Host (multiple instances)

Cartridge Cartridge Cartridge

Network Processor

OIM

Component Manager

Naming Service

Policy Server Host

Policy Server

Oracle Database

System Logger

Component Manager

DatabaseHost

Alcatel Discovery

Alcatel Discovery

OracleUpdateServer

Event Handler

Host

Component Manager

Host

Component Manager



Managing user and system transactions

Calculating all policies and services requested via user interfaces and third-party applications

Discovering and modeling the physical network

Co-ordinating 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.

Naming service

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.

System logger

The system logger records system messages reported from Service Activator components or the managed network.

Database

Persistent storage of system data is maintained by a database, managed from the policy server. The database is typically located on a different host than the policy server. In live deployments, an Oracle9i database is recommended.

Proxy Agent and Device DriversThe 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 VPNs and QoS – into the appropriate commands required to configure each device.

Multiple Proxy Agent/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.

Network Processor and cartridgesThe 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 OS versions.

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 GUI or by using the OIM or OJDL.

Anonymous Login – Supports anonymous login to the device.



Component managerThe component manager is required on all host servers on which one or more 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.

User interfacesThe graphical user interface 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 Service Activator components, and it reports faults and events occurring throughout the network.

The user interface is a distributed multi-user program, enabling users logged on to different hosts to control Service Activator and maintain the database. The policy server co-ordinates the information between these components, ensuring that each user’s view of Service Activator remains consistent.

Each user interface host maintains a local version of the object model which reflects locally made changes.

The permissions defined for a user define what is displayed on the user interface; where access to a class of objects is denied, the objects do not appear.

Service Assurance modulesService assurance modules consist of InfoVista , Micromuse, and Topology exporter. In addition to the core components of Service Activator, the following service modules provide additional functionality.

Common moduleThe Common module provides the common module framework for the other modules.

VLAN Activation ModuleThe Service Activator VLAN Activation Module allows you to provision end-to-end Metro Ethernet VLANs on the following devices:

Cisco IOS-based Catalyst devices



Cisco ML1000

Extreme Networks Alpine, Summit, and Black Diamond 6800

From the Service Activator GUI, the user can create, modify and delete Metro Ethernet VLANs.

MPLS LSP moduleMPLS (Multi-Protocol Label Switching) LSP (Label Switched Path) is a Service Activator module that allows the user to provision LSPs on the following Cisco devices:

Cisco 7600

Cisco 10K

From the Service Activator GUI, the user can create, query and delete MPLS LSPs. More information is provided on page 56.

IPsec VPN moduleThe IPsec VPN module enables Service Activator to provision secure VPN connections over the public Internet. More information is provided on page 53.

InfoVista Integration moduleThe InfoVista Integration module allows InfoVista to monitor and report on 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. More information is provided on page 99.

Dynamic User VPN moduleThe Service Activator Dynamic User VPN module allows you to:

perform discovery of Juniper E-series (ERX) devices in Service Activator

create duplicate loopback interfaces for use in each VRF

configure SNMP, DNS, and IP pool settings for VRFs used by Dynamic User Sites

More information is provided on page 51.

Configuration Template moduleThe Service Activator Configuration Template module (CTM) provides the following features:



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 (enter field data and send the resulting command set to devices or interfaces)

perform related activities (view template events, set the lifetime of events, manage user access to CTM, and match templates to schema versions)

More information is provided on page 87.


Product Overview – Third Edition Service Activator Solution

Chapter 2

Service Activator Solution

This chapter describes the key features of the Service Activator solution. It includes the following:

Network discovery and representation – the information Service Activator holds about the managed network, and how it discovers it

Device management and integrity – how Service Activator communicates with network devices and ensures device configuration is accurately maintained

Managing data – how Service Activator stores and models information, how access is controlled to this data and how changes are applied by means of transactions


Service Activator Solution Product Overview – Third Edition

The core Service Activator solutionThe following diagram illustrates the core Service Activator solution:

These aspects are discussed further in the following sections.

Network discovery and representationService Activator incorporates a network discovery engine that is able to discover information about the physical network – routers, interfaces and network segments – and create a detailed internal model.

The discovery process includes the following stages:

Discovering devices, segments and hosts

Assigning devices to the components that are responsible for managing them

Assigning policy roles to devices and interfaces

Setting up the security and authentication parameters that Service Activator needs to configure devices

Deviceconfiguration

Knowledgestore

Multi-vendor IP network

High-level service andconfiguration requests are

delivered toService Activator

Service Activator turnsservice requests into device-specific commands, keeps

track of changes in theknowledge store and passes

information to peer OSScomponents

Commands are delivered tonetwork nodes. Devices areconfigured dynamically and

configuration checkedregularly to trap errors

Device managementand integrity

Intelligent datamanagement

Capabilitymapping

Network discoveryand representation

User access

Service definitions(VPN/connectivity, policy, measurement, customized)

Key features



Ascertaining the capabilities of devices and interfaces – the VPN, QoS and measurement options that are available at each network node

The discovery processGiven a valid IP address or DNS name of a device in the network, Service Activator can retrieve details of the device, its interfaces, and any sub-interfaces and ATM or Frame Relay virtual circuit (VC) endpoints present. Connectivity information is also obtained from querying the routing table.

It is possible to enter a number of IP addresses or a subnet mask and discover multiple devices at once. In addition, if public IP addresses are used, it is possible to search for connected devices by specifying the number of hops to go from the initial device. In this way, it is possible to discover the entire network in one pass.

If any changes are made to the network configuration at any time, the discovery process can be re-run. You can either update the entire domain, or rediscover a single device.

The discovery process can also be set up to run automatically on a regular basis to ensure that the network topology is kept up-to-date. For example, you can configure Service Activator to run device discovery as an overnight process.

Access and authenticationFor each device, appropriate security parameters, such as user IDs and passwords must be specified to allow Service Activator to configure the device. This information need only be set up once.

The method used to communicate with the device depends on the options supported by the vendor and the level of security implemented in your network. SSH (Secure Shell) can be used to ensure secure communication between Device Drivers and routers. Access can be controlled by passwords or an RSA key file. On Cisco devices, Service Activator supports the use of a TACACS+ server for authenticating and authorizing access to devices.

If standard security information is set up prior to discovery it will be applied automatically to all discovered devices. This can save time if you use the same access methods and passwords for a number of devices in your network.

Device and interface capabilitiesAt the end of the discovery process, Service Activator determines the hardware and software versions of the device and then sets the capabilities of each discovered device accordingly.

Capabilities are set for each device and its interfaces, sub-interfaces and VC endpoints to precisely define the VPN, QoS, access control and measurement



options available. For interfaces and sub-interfaces, inbound and outbound capabilities are reported separately:

The topology modelOnce discovery is complete, Service Activator updates its representation of the topology model in the Knowledge Store:

Networks. A network is a logical object only, representing all or part of the network to be managed. For each domain, a root-level network object is automatically created, which equates directly to the domain.

To simplify the management of large and complex networks, you can set up subsidiary networks, each with its own topology map. Depending on the complexity of the network, you can create a multi-level hierarchy of subsidiary networks.

Devices. Within Service Activator, a device can be defined as a network node that forwards IP packets, that is, a router or Layer 3 switch. Each device in the network is classified according to vendor type, which defines the Device Driver or Network Processor cartridge that will be used to manage the device. Note though, that it is possible to discover devices that cannot be managed.

It is possible to create a virtual device manually in the user interface to represent a device that Service Activator has not discovered. This means that devices not managed by Service Activator – such as those in the core network or in the customer’s domain – can be modeled.



Interfaces and sub-interfaces. Interface and sub-interface objects represent the physical and logical interfaces on a device. This information is obtained from the interface table of the device during device discovery and the corresponding objects are created automatically.

PVCs. For ATM and Frame Relay interfaces, Service Activator looks for PVCs (Permanent Virtual Circuits) on the device and creates VC endpoints to represent them. These endpoints can be connected in the user interface to create a representation of the virtual circuit.

Segments. A segment object represents a locally-connected segment on an interface. Segments are classified according to type, for example, serial, bus or ATM cloud.

Hosts. A host can be defined as a network node that does not forward IP packets, for example, a PC, workstation, server or network printer. Hosts are found during the discovery process, and can be included for completeness although Service Activator does not manage them.

The hierarchical representation of the network topology on the user interface is as follows:



Mapping the networkThe managed network is displayed in the form of one or more topology maps on the user interface. As illustrated, the user interface provides a graphical and hierarchical representation of the managed network.

Map views

The options for producing maps are very flexible, and each network can have a number of alternate map views. For example, you can have one map showing the entire network and additional maps illustrating different portions of the network, such as the specific geographical or management regions. Alternatively, one map could display the network devices and segments and another could display the device interfaces and sub-interfaces. VPNs and their connected sites can also be mapped.

If the network is subdivided into two or more network objects, you can create maps for each sub-network, and drag and drop objects between maps.



The scale of the map can be changed to enable you to see the entire map at once or zoom into a particular section in more detail.

Manual mapping

Network topology maps can be set up manually, by dragging and dropping network objects from an on-screen palette. You can control the positioning of objects by snapping them to an invisible grid layout. Connections between objects appear automatically.

The objects that appear in the palette are relevant to the object currently selected. For example if you choose a device, those interfaces that are not currently mapped are listed in the palette. If you select an interface, unmapped sub-interfaces and segments are listed. This context-sensitivity can be turned off, in which case it is possible to select the types of objects to be listed.

Automatic mapping

It is also possible to apply an automatic layout option to the map. This arranges selected network objects in a logical manner. If automatic layout is selected before discovery, objects are automatically added to the map as they are discovered.



Device management and integrityService Activator incorporates a number of techniques to ensure device integrity, as shown in the following diagram.

Communicating with the deviceThe Device Drivers and Network Processor are the Service Activator components that are responsible for configuring individual network elements. They convert the abstract expressions of services, which have been calculated and validated by the central server, into the appropriate commands required to configure each element.

The device configuration is updated by issuing commands via the command-line interface (CLI). Access can be authenticated in a number of ways, including as a named or anonymous user, via a TACACS+ server or via the SSH protocol.

Service Activator maintains the appropriate authentication information for all devices. If the same access and authentication methods are used throughout the network, the appropriate parameters can be set up before device discovery and will then be applied to all devices. Where devices have unique passwords, they will need to have their security parameters set up separately.

Device Driver

ManualConfigurationAlarm

O/S ChangeDetection

ResyncConfigurationon DeviceReboot

DevicePoll

NetworkDiscovery

FetchDevice

Capabilities

CheckConfig

CorrectConfig

DevicePolling

DeviceCapabilities

Check andForce Audit Trails

Policy Server

Discovery



Modeling device configurationRather than simply pushing commands out to each router, the Device Driver or Network Processor manages the configuration intelligently, ensuring that the required configuration is not affected by the device going down or someone else making changes to the configuration. It does this by using an internal model of the configuration of each managed device, comprising the services and policies that have been requested by the user.

The Device Driver extracts the real configuration from the device and compares this with its internal model. If there are differences in the specific parts of the configuration that Service Activator configures, the configuration is updated. This comparison and update process is run every time the virtual configuration changes – that is, whenever any changes are made to requested services. If there is a mismatch, the configuration is updated.

Note that the Device Drivers only ever reconfigure those interfaces that are specifically managed by Service Activator. If the requested configuration would conflict with essential routing and set-up configuration, it is not applied.

The Network Processor functions slightly differently than the Device Drivers. It does not read the configuration on the device. Instead, it calculates the new device configuration based on the current transaction and the last pushed state for the device as stored in persisted data.

Ensuring consistency and integrityService Activator ensures that the configuration of each device is correctly maintained, even if the device goes down and configuration is lost.

Polling, failure and recovery

At regular intervals, all the devices that are under the control of the Device Driver are polled by the proxy agent to check if they are still running.

If any router has re-booted since the last time it was checked, Service Activator automatically runs a resynchronization process. The current device configuration is extracted and compared with the virtual state. If there is a mismatch, the device is reconfigured.

Normally, no user action is required. Occasionally, manual intervention is needed before Service Activator is able to resynchronize, for example, in the case of a hardware or software re-configuration of a device. In this case, the device status is changed to Intervention Required.

Co-existence with manual configuration

It is possible to set up Service Activator to co-exist with manually configured features, such as VRF tables and export maps.



Device Drivers can check for changes to device configuration that have been made manually by other users. Depending on a user-configurable option, a driver can force consistency of configuration automatically or issue a warning so that the device configuration can be investigated. The Network Processor does not force consistency.

Logging and reporting

Each installed Device Driver records all configuration changes that it makes to devices under its control. The log files can be examined to check the date, time, user and details of each configuration change applied to each device.

Errors occurring in devices can be reported as SNMP traps, allowing integration with other network management tools.

Managing dataThe way that Service Activator models and maintains data is fundamental to its operation.

The knowledge storeService Activator’s knowledge store is a repository of all required information. This information falls into three inter-related groups:

Network topology data – a representation of the network being managed by Service Activator. This includes details of devices and their connectivity and the membership of VPNs.

Policy data – information relating to the policies and services that are used to configure the network.

System data – information about the Service Activator components and user details, including status, fault and logging information.



The knowledge store is also known as the object model: every element is modeled as an object instance of a pre-defined class. Each object has a set of attributes that identify it and hold its data, and associations that define its relationship to other objects.

The knowledge store is held in memory, but is mapped to a series of tables within the database for persistent storage. A simplified version of the knowledge store, known as the External Object Model, is available to external applications.

External Object Model (EOM)

The External Object Model (EOM) is a simplified version of Service Activator’s knowledge store. It defines all the objects that can be accessed or updated by external applications, including their attributes and the relationships between them.

Using a subset of the entire object model means that user programs can create and access data objects without needing to know the underlying complexity of the entire object model. The External Object Model is independent of the command syntax – new attributes and objects can be added without requiring new commands.

Objects in the External Object Model are divided into three major categories:

Topology: Represent the topology of the managed network, such as Network, Device and Interface objects.

Policy: Represent elements used to define policies and services that can be configured on network nodes, such as Domain, Rule and Traffic Type objects.

Topology

Policy

Policydistribution in

System

System

Information relating to the policiesand services that are used to

configure the network, e.g. rules,PHB groups, scripts, packet

marking, traffic classifications

NetworkStatus and

Access

Information about the ServiceActivator components and userdetails, including status, faults

and events and logginginformation

A representation of the networkbeing managed. This includes

details of devices and theirconnectivity, and the membership

of VPNs

PolicyApplication to

Network



System: Represent Service Activator components and the event handler subscription model, such as Component, Subscription and Fault objects.

Transaction-based processingAll changes made to the knowledge store are handled in the form of transactions. A transaction model allows users to exercise control over when and how changes take place. For example:

A set of configuration changes can be created and grouped together and stored in the database for later application.

Complex configuration changes can be broken down into a number of small transactions and applied incrementally.

Specific configuration changes can be scheduled to be applied at a specified time in the future.

A committed transaction may be rolled back to restore the device configuration to its previous state.

Defining transactions

A transaction can consist of any sequence of operations, where an operation is one of the following:

Creating or deleting an object

Modifying an object’s attributes

Linking or unlinking two objects

For example, a single transaction could consist of setting up a number of customer sites and linking them together to form a VPN.

As well as transactions performed by users, actions performed by Service Activator are recorded as transactions.

Details of each committed transaction are archived, including the user who created it, its status, timing details and the operations it comprises.

Timing of transactions

Required changes can be broken down into a number of discrete transactions and implemented in a controlled manner. For example, a series of policy rules could be held in a number of transactions and their implementation phased over a period of time.

Additionally, it is possible to schedule a transaction so it is applied at a specific date and time. For example, an operation to update the network could be applied at a time when traffic was at a minimum. At the appropriate time the transaction is automatically committed and the updates made.



Transaction workflows

Depending on the security permissions set up for specific users, different individuals or groups of users can have different access rights for managing transactions. For example, some users may be able to create transactions and save them, while the right to commit or schedule existing transactions may be restricted to supervisory staff.

There are two potential workflows for working with transactions:

One-stage commit model, where a user makes changes through the user interface and immediately commits the changes. For example, a super user might use this to set up additional users or basic data.

Two-stage commit model, where one user saves the changes as a transaction and another merges the transaction to check its changes and finally commits it. For example, an operator might set up a VPN and a supervisor could check the changes before committing the transaction. In this model, the user can also save the transaction, and it can be scheduled to later point of time to commit the transaction.

This two stage process is shown below:

Rollback

A committed transaction can be rolled back in order to undo a set of changes that have been made. When a transaction is rolled back, its changes are removed from the object model and any configuration installed on network devices is removed.

Save MergeCreate

Delete

Modify

Create

Link

Changes are addedto the currenttransaction

Transaction isstored in a pending

state

Commit

Schedule

Transaction is committedand changes propagated

to the network

Transaction's changesare previewed before

committing or scheduling

Transaction's changesare scheduled for afuture date and time



Any committed transaction can be rolled back providing that the changes involved are still valid within the current object model.

Network representation

The user interface almost always reflects the network as it is currently configured. The only point at which it does not reflect the current state is when the user is creating a transaction. Once the transaction is saved, the user interface ‘reverts’ to the true state of the network.

Security accessAccess to Service Activator’s powerful facilities for network configuration (via the user interface or from an external application via an API) can be controlled by extremely flexible security options. Security can be set up to control the following:

Access to the user interface

The operations a user can perform

The information users can see through the user interface or OIM

User permissions on specific objects

The ownership of individual object instances

User authentication

Every user must have a login name and password to access Service Activator. To ensure security, system administrators can specify a minimum length for passwords, set an expiry time for passwords and prevent password re-use. User accounts can be disabled after repeated log-in failure.

User groups and user permissions

Each Service Activator user is allocated to a user group, which defines the functions the user can perform. Each user group can have one of the following access types:

Read Only – group members can view objects but not modify them

Read Write – group members may be able to view and/or modify objects

Super User – group members can view and modify all objects

For Read Write groups, you can set permissions which specify exactly which elements of Service Activator its members can view and modify. This enables you to limit access according to the role that users perform, or the customer accounts they are managing. Permissions can be set for the following:

Access permissions, (such as Read-only, Modify, Create) can be set for specific object classes (for example, a user can be set to have Modify access on all VPNs)



Specific operations (such as running a network discovery operation) can be permitted or denied

The user’s access level can affect the appearance of the user interface. Objects that a user does not have permission to see do not appear.



Object ownership and permissions

For fine-grained control of security, it is possible to control access to specific object instances. Permissions can be set that apply to the owning user, the group to which the user belongs and all other users.

User

Object

Permissions

Permissions

Users can ownobjects

Otherusers

UserGroupUser

Permissions set at anobject restrict access to

that object

Permissions set at grouplevel restrict user's access

to all objects in a class

User Group

Super User

Read Only

Read Write


Product Overview – Third Edition VPN/Connectivity Services

Chapter 3

VPN/Connectivity Services

This chapter provides an overview of the following VPN and network services supported by Service Activator:

Layer 3 MPLS VPNs (RFC 2547) on Cisco, Alcatel, Juniper M-series and Juniper E-series devices

Dynamic User VPNs (DU VPNs) on Juniper E-series devices

Layer 3 IPsec VPNs on Cisco devices

Layer 2 MPLS VPNs (Martini) on Cisco and Juniper M-series devices

Layer 2 MPLS Label Switched Paths (LSPs) on Cisco devices

Layer 2 Transparent LAN Services on Riverstone devices

Metro Ethernet Virtual LAN (VLAN) Services for Cisco Catalyst IOS and ExtremeWare OS

Circuit Cross Connect on Juniper M-series devices


VPN/Connectivity Services Product Overview – Third Edition

Layer 3 MPLS VPNs (RFC 2547)Service Activator supports the established IETF standard (RFC 2547bis) for Layer 3 VPNs on Cisco, Juniper M-series and Juniper E-series devices. MPLS is used to forward packets over the backbone while BGP is used to distribute routes, offering a scalable alternative to fully meshed circuit or tunnel-based IP VPNs. Security and privacy within an MPLS VPN is achieved by limiting the distribution of routing information to members of the VPN.

Using Service Activator allows you to set up VPNs quickly and easily by defining the appropriate customer sites and specifying how they are linked together into VPNs. The relevant routers throughout the network are then configured automatically.

Key conceptsThis section describes some of the key MPLS VPN concepts, as implemented in Service Activator.

MPLS

MPLS uses a technique called label switching to forward data throughout the network. The routers within an MPLS network that are responsible for label processing are known as Label Switched Routers (LSRs), and the path followed by data is known as a Label Switched Path (LSP).

On entry to an MPLS network, one or more fixed-format labels are inserted at the front of each packet. This label tells switching nodes throughout the network how to process and forward the data. The packet’s path through the network is defined by its initial labeling – subsequent mapping of labels is defined by the initial label allocation.

Each LSR in the MPLS network normally runs a Label Distribution Protocol (LDP) that distributes the labels that are to be used to forward packets across the MPLS network using peer-to-peer negotiation from network edge to network edge. These labels are associated with Forwarding Equivalence Classes (FECs) that define an IP address prefix for an egress point from the network. The MPLS labels only have significance between these LSR-peers.

Roles of routers

In an MPLS VPN, routers are classified according to the roles they perform.

Provider Edge (PE) routers are those routers within a Service Provider core network that connect directly to a router at the customer’s site.

Provider (P) routers are all those routers within the VPN core network that are not edge routers.



Customer Edge (CE) routers are those routers at the customer premises that have a direct interface to the PE router. These are sometimes known as CPE (Customer Premises Equipment) devices.

These roles are shown in the following diagram:

The Service Provider is responsible for managing the backbone, comprising the PE and the P routers. From an MPLS point of view, all routers in the core are LSRs. The PE devices are edge LSRs, responsible for attaching label headers at ingress and stripping labels at egress.

As far as MPLS VPNs are concerned, the CE devices are the responsibility of the customer, and they do not need to run MPLS. However, in cases where they are managed by the Service Provider, Service Activator can configure policy-based services on them.

BGP

The various routers within the VPN communicate using BGP, an IP routing protocol that defines how routes can be distributed. BGP transports information about CE routers only to members of the same VPN, ensuring security.

A BGP Autonomous System (AS) is a collection of networks under a common administration that share a common routing strategy. BGP communication that takes place within an autonomous system (for example, between PE routers within a Service Provider network) is known as Internal BGP (iBGP). BGP communication

PE

PE

PE

P

CE

CE

Service ProviderCore

PE

P

P

VPN B

VPN A

CE

VPN A

CE

VPN B

CE

VPN A

CE

VPN B



between different autonomous systems, for example, between a PE and a connected CE, is known as External BGP (eBGP).

Each AS is identified by an Autonomous System Number (ASN), which is required when running BGP. Service Provider networks normally use BGP, so they will already have an assigned ASN. However if eBGP is used as the routing protocol between PEs and CEs, a unique ASN must be assigned to each separate customer site network.

Sites and Route Distinguishers

A VPN comprises a number of customer sites communicating over a shared network infrastructure.

A CE device is always in a single site, but a site may belong to multiple VPNs. A PE router can be connected to CE devices in a number of different sites, in the same or different VPNs.

Obviously, each customer site can be identified by its CE router, but from the Service Provider’s point of view (who may not have visibility of customer equipment), each site is defined by the interface(s) on the PE router connected to the CE router.

MPLS VPNs enable customer site networks to use overlapping address space, rather than globally registered IP addresses. This is achieved by ensuring unique addresses for use within the VPN, by means of Route Distinguishers (RDs), also known as Route Descriptors.

Core VPN NetworkPE

Each site can beeffectively defined byan interface on the

PE router

Site A CE

CESite B



VPN-IPv4 addresses

The PE adds the site RD to the IP address of each node within the customer site to create an extended address, known as a VPN-IPv4 address. This is used to identify the node throughout the VPN. The VPN-IPv4 address uniquely identifies each endpoint in the network, even if the customer site is using unregistered private IP addresses.

VRF tables and route targets

Each PE router maintains a number of separate forwarding tables known as VRF (VPN Routing and Forwarding instance) tables, and each site (i.e. each PE interface or sub-interface connected to a CE device) must be mapped to one of those VRF tables.

Note that a VRF table does not necessarily correspond to a particular VPN. Its purpose is to hold the routes that are available to a particular site connected to a PE device. If a site is in multiple VPNs, the VRF table associated with that site contains routes for all the VPNs of which it is a member.

Routes defined within a PE’s VRF tables are propagated to other PE devices within the same VPN. But since a VRF table is not mapped directly on to a VPN, it is necessary to identify the VPN to which each route applies.

This is achieved by means of route targets. Every route that is distributed from a VRF table is tagged with an export route target attribute identifying its VPN. Each VRF is tagged with one or more import route target attributes, indicating the VPNs for which it wants to import routes.

When routes are distributed, any route marked with a particular export route target attribute will be installed in VRF tables marked with the same import route target attribute.



Routing protocols in the VPN

The various routers within the VPN need to communicate using a routing information distribution protocol that defines who can talk to whom. The following diagram illustrates the routing protocols required in an MPLS VPN.

PE routers that are connected to other PE routers within the same VPN communicate using iBGP. iBGP is used to transport VPN-IPv4 network addresses across the core network to other VRF tables.

Each PE router also needs to communicate with its external neighbors – the CE routers to which it is connected – in order to transport these private routes between the CE routing table and the PE VRF table. Service Activator supports eBGP, OSPF and RIP routing protocols as well as static routing.

In addition to BGP, an Interior Gateway Protocol (IGP), such as OSPF or IS-IS is required within the core network, to enable normal connectivity throughout the core, so that LSPs can be established.

VPN A

Core VPNNetwork

PE

PE

PE

PE

IBGP

CE

CE

EBGPOSPFRIP

Static

Net ANet B

Net CNet D

CE

CEIBGP

P

IGP routingprotocol (e.g.OSPF, IS-IS)

in the core

VPN B

EBGPOSPFRIP

Static

EBGPOSPFRIP

Static

EBGPOSPFRIP

Static



Summary of Layer 3 MPLS VPN support

Service Activator feature Cisco Jun M Jun E Alcatel Huawei

VRF table User-defined VRF table name

VRF re-use/reduction

User-defined RD numbers

User-defined RT numbers

Full mesh, hub and spoke and management topologies

RD per VPN

VRF route limit (max routes)

Co-existence with pre-defined VRFs

Pre-defined export maps

DHCP Helper

Description

PE-PE peering (iBGP)

iBGP peering optional

Maximum paths

Extended/standard community attributes

PE-PE MD5 authentication

PE to CE connectivity

eBGP

OSPF

RIP

Static routing



VRF tables The Service Activator Device Drivers configure the appropriate VRF (VPN Routing/Forwarding Instance) tables and associated route targets on the PE devices. Each customer site connects to a PE interface or sub-interface. This interface is assigned to a VRF table, which defines the VPN membership of a customer site. VRF tables hold routing information that defines how packets from a given site are routed across one or more VPNs to other sites. They are private routing tables containing IPv4 routes that have been learnt from CE routers using eBGP, RIP or OSPF and any explicitly defined static routes. They do not form part of the PE router’s own routing tables.

VRF table names

VRF tables are generally given default names by Service Activator. However, you can define specific names for VRF tables on selected interfaces if you wish.

VRF re-use/reduction

A VRF table is set up on the device for each PE interface that is a member of a VPN. However, if multiple VRF tables contain exactly the same routes Service Activator

eBGP configuration

AS override

Allow AS in


Local Preference

PE-CE authentication

Prefix filters

Prefix limit

Site of origin

Multi-path load sharing

Route dampening

Route redistribution into eBGP

Route redistribution into OSPF

Service Activator feature Cisco Jun M Jun E Alcatel Huawei



will normally reduce them to just one, in order to minimize resource usage. This is known as VRF re-use or VRF reduction.

In some cases automatic VRF re-use may not be required. For example, you may want to provision dual links to customer sites in order to implement load balancing, requiring a separate VRF table for each connecting interface, or to reduce the impact of future re-configuration. In this case you can override VRF re-use by specifying that particular interfaces are always to have their own VRF table.

RD number formats

The RD number can be in either of the following formats:

32-bit IP address:16-bit number

16-bit ASN number:32-bit number

Service Activator normally generates RD numbers automatically, using the second of these formats. However you can override the default and specify your own RD numbers if you wish.

RT number format

A route target (RT) identifies a set of sites within a VPN to which a PE device distributes routes. Route targets are used to create the VPN topology. Each VPN must have a unique route target number.

The RT number can be in either of the following formats:

32-bit IP address:16-bit number

16-bit ASN number:32-bit number

Service Activator normally generates RT numbers automatically, using the second of these formats. However you can override the default and specify your own RT numbers if you wish.

VPN topologies

The connectivity of the VPN can be one of the following:

Mesh – all sites have connectivity to all other sites

Hub and Spoke – one or more hub sites has access to all other sites; spoke sites can access the hub only

Management – works in the same way as hub and spoke, but is used when setting up QoS to ensure connectivity to CE devices

In a hub and spoke VPN topology, Service Activator generates two RT numbers – one for the hub site(s), generated as indicated above, and one for all spoke sites, generated by incrementing the hub low order number by 1.



If you wish, you can specify your own RT numbers for hub, spoke or fully-meshed sites within a VPN if you do not want to use the default values. You can easily reassign RT numbers to sites within a VPN, if for example, it has been imported or exported by a different application.

You can specify any number of RT values per VPN and specify whether a value is used for VRF import, VRF export, or neither for hub, spoke and fully-meshed behaviors.

RDs per VPN

By default, Service Activator automatically generates a site-specific VRF table name and RD number for each site that participates in a VPN.

However you can override the Service Activator default by specifying at the VPN level that the same VRF table name and RD number is applied to all sites that participate in the VPN. You can choose whether to use Service Activator-generated values or specify your own VRF table name and/or RD number.

VRF route limit

The route-limit features enable you to specify the maximum number of routes that can be imported into the VRF table. Two alternative actions can be defined:

A warning message can be generated if the number of imported routes reaches the maximum, but with routes continuing to be accepted.

A warning message can be generated when the number of routes reaches a specified percentage of the maximum, with no further routes accepted when the maximum is reached.

Co-existence with pre-defined VRF tables

If an MPLS VPN has already been manually configured on a network, Service Activator is able to work with the pre-configured VRF tables that exist on devices. You can choose whether Service Activator ignores existing VRF tables or assumes control of them, and if existing content is preserved or removed.

Pre-defined export maps

You can apply a user-defined export map to the export policy configured by Service Activator. The export map exports only the VRF table routes whose prefixes match those specified in the export map to other PE devices. The export map tags these routes with only the RT numbers of sites that need to receive those routes.

PE-PE routing - iBGP iBGP is the protocol used for communication of VPN routes between PE devices in an MPLS VPN. In order for devices to exchange routing information, an iBGP session must be configured between the PE devices that comprise the VPN.



iBGP peering optional

If iBGP peering is already installed on PE routers, for example if Route Reflectors are used, the existing configuration can be preserved.

Load balancing

You can enable load-balancing between iBGP peers by specifying the number of alternative routes to a given prefix that are maintained in a device’s routing table. By default, this option is disabled and all identical routes learned from peer devices are dropped. To enable load-balancing, you can specify the number of routes that are maintained.

PE-PE community attributes

You can specify that routes advertised to the neighbor CE router contain the standard community attribute as well as the extended community attribute which is configured by default.

MD5 authentication

The identity of iBGP peers and the integrity of data exchanged during iBGP sessions can be verified using MD5 authentication. This option uses the MD5 digital signature algorithm and a specified key of up to 255 characters to generate a checksum of the iBGP data that is to be sent from a PE device to its peer. The iBGP data and its checksum are then sent to the peer device using TCP. The recipient device uses MD5 and the same key to generate a checksum of the received iBGP data. If both checksums match, the identity of the sender and the integrity of the received iBGP data is verified.

PE-CE configurationIn order to exchange information to and from customer sites in the VPN, each PE router also needs to communicate with each of its external neighbors – the CE routers to which it is connected.

The effect is to advertise network reachability information between the CE and the PE, which in turn converts IPv4 addresses to VPN-IPv4 addresses for traffic passing from the CE to the PE and vice versa.

PE-CE protocols

Service Activator supports eBGP, RIP and OSPF. Static routes can also be configured in conjunction with eBGP, RIP and OSPF routing or used alone to define routing between the PE and CE.

Route redistribution

Service Activator offers a high level of control over the redistribution of routes between protocols, enabling you to specify the metric to associate with routes



distributed from the selected PE-CE routing protocol into other Internal Gateway Protocols (IGPs) and BGP, and vice versa.

Redistributing routes between protocols brings with it the risk of introducing routing loops and convergence problems. However, you can filter and refine the redistribution of routes by associating a manually pre-configured route map/policy statement with redistributed routes.

eBGP configuration

AS override

You can specify that the ASN of a provider is used to override the ASN of a site. In this case, a PE device that receives route prefixes whose AS_PATH attributes have one or more ASNs matching the ASN of its neighboring CE devices, substitutes those ASN instances with the ASN of the Service Provider network. Prefixes with the substituted ASNs are then re-advertised to neighboring CE devices. The PE device also adds its ASN to routes before exporting them to the CE device.

This allows CE devices to accept routes that have been re-advertised by devices having the same ASN, and which would otherwise be rejected. Normally, a CE device rejects routes whose AS_PATH attribute contains ASNs matching its own ASN, to prevent routing loops.

Allow AS in

You can specify the maximum number of times the same ASN is allowed to occur in the AS_PATH attribute of a route prefix advertised to the PE device for the prefix to be permitted and then re-advertised to neighboring CEs by the PE device.


You can specify that routes advertised to the neighbor CE router contain the standard or extended community attribute or both.

Local preference

Where multiple PE interfaces are associated with a site, the local preference for an interface can be set.

PE-CE authentication

The identity of eBGP peers and the integrity of data exchanged during eBGP sessions can be verified using Authentication.



Prefix filters

You can set up a prefix list file to specify that routes whose prefixes match those in the prefix list will either be allowed or rejected by the PE router depending on their designation in the prefix list.

Prefix limit

You can specify a maximum number of eBGP IP route prefixes that can be received by the PE router from its CE neighbor.

Site of origin

Site of Origin (SOO) is configured automatically for sites that have more than one CE to PE connection. It identifies the site from which the PE router learned the route and prevents routing loops from occurring when a site is multi-homed.

Multi-path load sharing

You can enable load-balancing between eBGP peers by specifying the number of alternative routes that are maintained in a device’s routing table. By default, this option is disabled and all identical routes learned from peer devices are dropped.

Route dampening

Route dampening is a mechanism that attempts to minimize network instability by suppressing the advertisement of poorly-behaved routes. Penalties are applied when a route is withdrawn, readvertised or changed. When a predefined penalty limit is reached, further advertisement of the route is suppressed. The penalty is reduced according to a defined “half-life” setting, and once the penalty decreases below a limit, the route can be readvertised.

Dynamic User VPNs (DU VPNs)Dynamic User VPN (DU VPN) allows the setup of MPLS IP VPN sites for dynamic DSL user connectivity.

Service Activator supports DU VPN on Juniper E-series devices.

Dynamic DSL users connect to the network via a PPP session carried over an ATM PVC terminated at the ERX. The ERX allocates an IP address for the user from a local IP address pool associated with the VPN. The loopback0 interface is used as the source IP address at the ERX side of the PPP session.

A RADIUS server authenticates the user and returns the user’s VRF/VPN. DNS server information is also returned to the user. In effect, the user dynamically



becomes a member of the VPN upon authentication. The PPP session is terminated by the ERX.

Its functionality includes:

management of virtual router/VRFs and multiple loopback0 interfaces for each customer

management of IP pools and IP address ranges per customer

management of DNS IP addresses per customer

management of SNMP options per customer

Customer1Branch Office

user@customer1

ERXPE

P Backbone IP MPLS

P

P

user@isp

Dynamic UsersERXPE

ERXPE

ERXPE

RADIUSserver

Customer1Head Office

ISP 1

DSL/ATM

DSL/ATM



Layer 3 IPsec VPNsIPsec (Internet Protocol Security) is a framework for a set of protocols for security at the network or packet processing layer of network communication. Earlier security approaches have inserted security at the application layer of the communications model. IPsec is said to be especially useful for implementing virtual private networks and for remote user access through dial-up connection to private networks. A big advantage of IPsec is that security arrangements can be handled without requiring changes to individual user computers.

IPsec provides two choices of security service: Authentication Header (AH), which essentially allows authentication of the sender of data, and Encapsulating Security Payload (ESP), which supports both authentication of the sender and encryption of data as well. The specific information associated with each of these services is inserted into the packet in a header that follows the IP packet header. Separate key protocols can be selected, such as the ISAKMP/Oakley protocol.

Supported servicesService Activator supports the following Layer 3 IPsec VPN functionality on Cisco devices:

point-to-point topology

GRE/IPinIP tunnels

IKE/IPsec defaults

pre-shared keys

dynamic (OSPF, EIGRP) and static routing

IP network

GRE/IPinIP tunnel

IPsec Protected Traffic(using Transport Mode)

CECE



Layer 2 MPLS VPNs (Martini)A Layer 2 Martini MPLS VPN is an association of Layer 2 Martini point-to-point connections. A point-to-point connection is a pseudo-wire (or tunnel) configured between two endpoints across an IP network.

The connection uses MPLS labels to encapsulate and transport various Layer 2 data formats, including VLAN to VLAN, Ethernet, Frame Relay, ATM Cell and ATM AAL5, across an IP network. The tunnel provides a transparent connection, so users see no change in their Layer 2 data. (Note that the tunnel does not aim to meet QoS aspects of the connection, particularly in the ATM case.) The Martini endpoints can be interfaces, sub-interfaces, or other endpoint identifiers (VCI/VPI on ATM, DLCI on Frame Relay, or VLAN ID on Ethernet.

Implementation scenariosA Layer 2 Martini MPLS VPN enables the encapsulation and transport of legacy data types over IP networks. As Service Providers upgrade their network core, connections between legacy networks can be maintained. Customers needing traditional connectivity over a third-party network can be served using the same IP core network, regardless of the packet types they need to transport. Additionally, the tunnel saves the complexity of carrying the customers routes across the network.

Support of Ethernet technologies also permits Service Providers to use inexpensive Metro-Ethernet solutions in the Local Area Network (LAN), reducing the rollout cost of new networks.

Similarly, Martini solutions can reduce the rollout costs associated with mobile networks in transition from 2G to 3G. Using Martini tunnels, legacy 2G connection-oriented networks can traverse the new 3G IP core network. This saves the operational costs of supporting two different networks.

Supported devices and data typesService Activator supports the configuration of Layer 2 Martini MPLS VPNs on the following devices:

Switching IOS Cisco devices

Layer 2 VCPE

MPLS cloudPE

Martini VC-LSP

Layer 2 VC



Non-switching IOS Cisco devices

Juniper devices

Depending on the device, Service Activator supports the encapsulation of a number of different data types.

Encapsulated data Endpoints

Cisco switching

IOS

Cisco non-switching

IOSJuniper

Ethernet (Port)

Any combination of VLAN interfaces.

x x

Ethernet interfaces. x

Ethernet (VLAN)

VLAN endpoints configured under Ethernet interfaces (sub-interfaces).

x x

VC identifiers configured under Ethernet sub-interfaces.

x

ATM Cell Sub-interface with VC identifier. x

ATM AAL5 Sub-interface with VC identifier. x

Frame Relay Main interface with VC identifier. x x

Sub-interface with VC identifier. x x



Layer 2 MPLS Label Switched Paths (LSPs)Layer 2 MPLS Label Switched Path (LSP) Activation enables the provisioning of engineered LSP tunnels. An LSP tunnel is an entity that exists on a specific network device and identifies a hop-by-hop path through the network to another specific device. Once an engineered tunnel is in place between device A and device B, traffic flowing from A to B should travel through the network more efficiently.

A primary LSP on the Service Provider network is configured to be the preferred path. An optional secondary path provides path protection.

In addition to the IP addresses of all the hops (between 0 and 30) in both the primary and backup (secondary) path between the 2 devices, the user can provision a number of attributes which affect the operation of the tunnel.

Supported servicesService Activator supports the following Layer 2 MPLS Label Switched Path (LSP) Activation functionality on Cisco devices:

LSP with primary and secondary paths

explicit paths

LSP parameters:

— bandwidth

— hold and setup priorities

— path option

VPN APE

Primary Path

P

P

CE

PE

Secondary Path

VPN B

CE

CE

VPN C

PE



— affinity

— IGP metric

— fast-reroute

Layer 2 Transparent LAN ServicesA Transparent LAN Service (TLS) connects separate customer Ethernet LAN segments via an MPLS network. The connection across the network appears to the customer as a single LAN segment.

On Riverstone devices, Service Activator supports the encapsulation and transport of normal and 802.1q tagged Ethernet Frames across the TLS as described in the Lasserre TLS draft.

Key conceptsThe TLS is configured on the PE devices of an MPLS network only. Ethernet frames are mapped to a particular service instance based on a combination of the port they arrive at the PE on and the 802.1q tag they have. In common with other VPN solutions, inner and outer tunnels are used. The outer tunnels provide a transport mechanism between the PE routers in the TLS. The inner tunnels, referred to as VC-LSPs, form a full-mesh between all PEs in each TLS instance and are particular to that TLS. Multiple VC-LSPs may be carried by a single transport 'outer' LSP.

VC-LSPs

The Lasserre TLS solution uses VC-LSPs, which are defined in the Layer 2 Martini over MPLS drafts. A targeted LDP peering association between two PEs creates the VC-LSP. The PEs exchange information about the Layer 2 protocol that will be carried – in the TLS case, this is either untagged or 802.1q tagged frames. This exchange will also include information about the TLS instance the VC-LSP is part of. The Forwarding Equivalence Class (FEC) thus describes Layer 2 information, rather than the more usual IP prefix.

Each PE sends back a VC-LSP label, which is mapped to the FEC. When a frame is received at the PE, it examines its forwarding table and applies the correct VC-LSP label. Then the correct transport label is added and the frame is forwarded to the correct destination. At the egress PE router, the VC-LSP label is used to identify the correct Ethernet port over which to forward the enclosed frame.



In the diagram below, VC-LSPs are configured for the Customer A TLS instance between San Francisco, Denver and New York. The VC-LSPs are contained within the transport LSPs that connect these destinations.

Transport LSPs

Transport LSPs are responsible for linking PE routers together. Each VC-LSP must be forwarded to the correct PE by the transport LSP.

802.1Q

This is the IEEE standard that describes a VLAN tag that can be applied to an Ethernet Frame. The tag value is the VLAN ID, a number assigned to switches in an Ethernet network. Tagged frames can only be forwarded to switches that are configured with the same VLAN ID as the tag. Switches may be in more than one VLAN at a time, connected by trunk ports over which tagged frames are sent. Access ports to the Ethernet network may only be assigned a single VLAN ID. The frames arriving at an access port are untagged.

Mapping frames to the TLS

To complete the TLS service, a mapping must be established between incoming Ethernet frames to the PE and the VC-LSPs that are configured over the MPLS core. This mapping can be:

Port based – all frames from a particular port are mapped to the service.

LSP

LSP

LSP

MPLSnetwork

Customer BVLAN

Customer AVLAN

SanFrancisco New

York

Customer BVLAN

Customer AVLAN

Customer AVLAN

Denver

TunnelLSP

VCLSP

VCLSP



VLAN based – all frames with an 802.1Q tag of a given value are mapped to the service.

Port and VLAN based – all frames from a particular port with a given 802.1Q tag are mapped to the service.

Service Activator supports port-based and port and VLAN based. The mapping is to the TLS instance configured on the PE.

The TLS instance on Riverstone devices is identified by the customer-profile and the customer-id. All the VC-LSPs with the same customer-id at the PE form the possible destinations for the Ethernet frames mapped to that TLS instance.

Ethernet is a broadcast service and this must be replicated in the TLS. Hence, when a frame is received at the PE for an unknown destination, it is forwarded over all the VC-LSPs in the TLS. When a response to this frame is received at the PE, before forwarding the frame over the correct Ethernet port, the PE learns which VC-LSP the frames returned over. Future frames to that destination are then only sent over the learned VC-LSP. This mechanism is called 'flood and prune'.

A port that handles incoming traffic to the TLS may therefore receive tagged or untagged frames and tagged frames may belong to one or more VLANs. On Riverstone devices, ingress ports to the TLS may be configured as one of the following, depending on whether tagged or untagged frames are handled:

A trunk port – receives and transmits tagged frames belonging to one or more VLANs; a trunk port may also be configured to transmit untagged frames by making it part of the native VLAN (typically VLAN 1), but this is not supported by Service Activator.

An access port – receives and transmits untagged frames and frames belonging to a maximum of one VLAN. By default, access ports are considered to be part of the native VLAN unless they are explicitly assigned to another VLAN.

Service Activator’s implementationA TLS is represented by a TLS object, and the edge points of the TLS are represented by Layer 2 site objects. Each Layer 2 site is linked to one or more ports that indicate where Service Activator will apply TLS configuration. If Service Activator is to tag incoming frames, VLAN configuration will also be applied.



A Layer 2 site may include ports on both the PE and, optionally, the CE device.

Service Activator applies the concept of port-based and port and VLAN-based entry criteria both to the TLS object and the layer 2 sites that are linked to it:

A port-based TLS consists of a number of port-based Layer 2 sites

A port and VLAN-based TLS consists of a number of port and VLAN-based Layer 2 sites

Port-based TLS

In a port-based TLS, forwarding of frames across the TLS is based on incoming port number.

Incoming frames may be tagged frames or untagged frames.

Any VLAN configuration and management is performed by the Service Provider’s customer. Service Activator simply configures the specified ports at the edge of the TLS to be either Ethernet access ports or 802.1q trunk ports, depending on whether untagged or tagged frames are transmitted across the TLS.

You cannot perform tagging of incoming frames at a port-based site.

The edge points for the TLS are defined by port-based layer 2 sites. Each site may contain a single port. A port-based site may be linked to one port-based TLS.

TLS objectLayer 2 site – represents an access point to the TLS

Port – Service Activator applies TLS and, optionally, VLAN configuration to the linked port



You specify on which ports incoming frames for the TLS will be received by linking the Access interface on the appropriate Gateway (PE) device to a layer 2 site. An interface can be linked to one port-based layer 2 site.

Port and VLAN-based TLS

In a port and VLAN-based TLS, frame forwarding is based on incoming port number and the ID of the VLAN to which the frame belongs.

Incoming frames may have been tagged by the customer before reaching the entry point to the TLS, or you can specify that Service Activator tags incoming frames before forwarding across the TLS.

If Service Activator tags incoming frames, in addition to configuring the TLS it also configures the relevant VLANs and assigns them to the relevant ports. Frames are tagged at the PE device or, if the Service Provider has visibility of the CE device, tagging is performed here.

You specify which VLAN IDs will be carried by the TLS when creating the TLS object. These VLAN IDs form part of the customer profile that is configured on the PE device and specify the range of VLAN traffic the TLS will carry.

Metro Ethernet Virtual LAN (VLAN) ServicesEthernet has become the technology of choice for Metro networks, and is gradually taking over Frame Relay and ATM for access into the IP core network. Service Activator supports the ability to deploy and manage Metro Ethernet Virtual LAN (VLAN) Services in a multi-vendor environment, based on the 802.1Q standard. For example, Service Activator supports VLAN services on Cisco Catalyst IOS devices and Extreme Networks' Alpine, Summit and Black Diamond 6800 equipment.

Ethernet services are provisioned differently than IP services. Ethernet network services are configured at the edge and the core on a per customer basis. IP services are typically configured only at the edge of the Service Provider IP network. For this reason, Oracle Communications is delivering two levels of VLAN application, targeting the core network and edge access into the Ethernet network.

Service Activator's VLAN Activation Manager provides a key advantage for Core activation. Using a device and interface role-based approach, any new VLAN is configured on "all" core ports of the selected switches with a single action. This quickly enables the Metro Ethernet network to transport data across the VLAN. This is achieved without an operator performing the lengthy process of configuring the VLAN one port at a time on each device.

Service Activator also provides fine-grained VLAN control at both the device and interface levels through the VLAN Properties. As an example, you can deactivate or reactivate a set of VLANs against a specific port by simply modifying its VLAN properties. You can also add a new Ethernet switch in the Metro Ethernet network,



and automatically apply the configuration of the whole set (or a subset) of active VLANs in that Metro network. This level of automation represents a significant time-saver for Service Providers. For example, if you add a new switch with 20 core ports into a Metro Ethernet network running 2000 VLANs, this normally translates into 42,000 individual VLAN elements to activate manually. However, using Service Activator, these can be activated in a single step.

Once the Metro Ethernet core is enabled for specific VLANs, the next steps are to:

create Layer 2 (L2) Sites

create a customer Transparent LAN Service

configure the customer-facing Ethernet ports for access to the service

The addition and removal of L2 sites from VLAN services are fully supported.

VLAN options

Service Activator supports multiple VLAN options:

Untagged: Customer traffic comes into the Service Provider as plain, untagged Ethernet traffic. The edge switch and access port then tag the frames with the appropriate VLAN configured against that site. This allows the frames to be transported across the Ethernet core where the VLAN is enabled.

Tagged: Customer traffic comes into the Service Provider with its own set of VLAN tags. In other words, the customer network is already segregated into VLANs which must be transported across the Service Provider network. Service Activator supports the configuration on that site of the specific set of VLANs to match the specified incoming traffic.

Stacked VLANs (or Q-in-Q): A Service Provider can carry up to 4096 VLANs within a single Metro Ethernet network. If each customer were to connect with tagged traffic for multiple VLANs, the Service Provider could run out of VLAN IDs for all of its customers. The Stacked VLAN solution can prevent this from happening. Using Stacked VLANs, the Service Provider can encapsulate incoming customer-tagged traffic into a single VLAN, and remove the encapsulation at the destination site. This approach can transport a whole set of customer VLANs through a single Service Provider VLAN. Stacked VLANs can support over 16 million VLANs in a single Metro Ethernet network.



Circuit Cross ConnectCircuit Cross Connect (CCC) is a point-to-point mechanism specific to Juniper M-series devices that allows transparent connections between two circuits to be configured, effectively creating a Layer 2 MPLS VPN.

The following types of circuit can be connected:

Frame Relay DLCI

ATM VC

Ethernet Virtual Local Area Network (VLAN)

Point to Point Protocol (PPP) interface

Cisco High-level Data Link Control (HDLC) interface.

Using CCC, packets from the source circuit are forwarded to the destination circuit with only the Layer 2 address changed, at most.

Service Activator supports the creation of the following two types of CCC:

Layer 2 switching CCCs – these join logical interfaces on the same device to form what is essentially Layer 2 switching.

MPLS tunneling CCCs – these allow you to connect two distant interface circuits of the same type by creating MPLS tunnels that use LSPs (label switched paths) as the conduit.

Both Layer 2 switching and MPLS tunneling CCCs require MPLS to be enabled on all relevant routers.

MPLS tunneling CCCs also use RSVP (Resource Reservation Protocol) with extensions for RSVP tunnels to signal LSP set-up. This incorporates a number of IETF-approved extensions to standard RSVP that allow RSVP to be used as a signaling protocol within an MPLS network. RSVP therefore must be configured on all relevant routers.



Layer 2 switching CCCsA Layer 2 switching CCC enables you to join two circuits, effectively configuring the interdomain router as a switch. For example, in the diagram below, a CCC connects two Frame Relay circuits. Router B acts as a Frame Relay switch, transparently switching packets between Router A and Router C.

The cross connect is bidirectional, so packets received on the first interface are transmitted out of the second interface, and those received on the second are transmitted out of the first. The only processing performed by Router B is to translate DLCI 600 to 750.

MPLS tunneling CCCsAn MPLS tunneling CCC allows you to join two circuits of the same type across an MPLS cloud. For example in the diagram below, a CCC connects two ATM access networks through an IP backbone. CCC establishes an LSP tunnel between the two domains. ATM traffic from one network is tunneled across the backbone to the second network using an MPLS LSP:

CCC

Frame Relay

DLCI 600 DLCI 750A B C

Frame Relay

Juniper M-seriesdevice

CCC

LSP

LSPA B C D





Alcatel HTML GenerationThe Alcatel cartridge supports Configuration Policies that require custom generated .xml files that are derived from the Alcatel SAM. Since the HTML used for the Configuration Policy is no longer installed on each client, a tool is required to combine the .xml data file with the HTML so it can be imported into the configuration policy.


Product Overview – Third Edition Policy-based Services

Chapter 4

Policy-based Services

This chapter explains the policy-based service activation components that can be used to create a service to users. It includes the following:

An explanation of the concepts used by Service Activator that are common to policy components

Configuring Quality of Service – a summary of the QoS features that Service Activator can configure

Configuring Access Control – how Service Activator can configure access control (filtering)


Policy-based Services Product Overview – Third Edition

QoS and access control supportService Activator supports a variety of policy-based services for a range of devices from different vendors. For more information on the services supported for each device, refer to the Supported features tables in the respective support document, as indicated in the table below.

Policy configuration – key conceptsService Activator uses a policy-based approach to implement QoS, access control and selected measurement features. It is a flexible and powerful model, based on two key concepts:

Policy elements – the definitions of the policies to be applied. Policy elements define what policies are configured.

Policy targets – the points in the network at which the defined policies are applied. Policy targets define where policies are configured.

These two aspects of setting up a policy are described in the following sections.

Policy elements – what is to be configuredIn Service Activator, you can set up specific policy elements, which can then be applied to the relevant points in the network. A policy element can be one of the following:

VendorDevices supported by

device driverDevices supported by

cartridge

Alcatel

Juniper EJuniper E-series Device Support Guide

Juniper MJuniper M-series Device Support Guide

Juniper JUNOS Cartridge Guide

CiscoCisco IOS Device Support Guide Cisco IOS Cartridge Guide

Foundry Foundry IronWare Cartridge Guide

HuaweiHuawei Cartridge Guide



Policy rules. Used to classify traffic and define packet marking, policing requirements and access control.

Per hop behavior (PHB) groups. Used to provide low-level control of the queuing, policing, marking, congestion avoidance and traffic shaping mechanisms available on a particular interface.

Measurement parameters. Used to define NetFlow or MIB-based measurement.

Collector parameters. Used to specify that NetFlow or SNMP MIB data is to be collected.

Driver scripts. Used to implement a specific policy requirement by means of a specially-written Python script. Driver scripts are discussed in detail in Activation Extensibility on page 85.

A configured policy can comprise a combination of these policy elements.

Policy rules

One aim of policy-based network management is that high level policies can be defined by an 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 user.

Although policy-based network management is commonly used to implement quality of service it can also be applied to resource allocation, security issues, measurement and other configuration requirements.

Policy rules can define one or more conditions and the actions associated with them, for example:

Within Service Activator there are three types of rule:

Classification rules are used to identify traffic and mark packets. They also apply bandwidth limits to defined traffic.

Condition Action

Trading traffic is travelling between New York and Chicago

Specify a bandwidth of 128k

Web-browsing traffic transiting the core

Mark as low-priority and drop in times of congestion

Game-playing traffic detected Deny access to identified traffic between 9:00 and 5:00



Policing rules are used to identify traffic and set up policing parameters – the bandwidth requirements and the action to take for conforming and non-conforming traffic.

Access rules are a security measure that can deny or explicitly permit identified traffic to access the network.

All rules identify and classify traffic in the same way. In addition all rules can be made dependent on date and time.

Per Hop Behavior groups

A PHB group is a way of applying one or more policy definitions to a particular interface. There are two types of PHB group:

Standard PHB groups are used to implement QoS mechanisms (queuing, congestion avoidance, policing and traffic shaping) on Cisco and Juniper devices. Although where possible these are generic, such as Weighted round Robin (WRR) the actual forwarding behavior is specific to particular device manufacturers and types.

MQC PHB groups allow you to implement Modular QoS CLI mechanisms developed by Cisco to simplify the configuration of QoS on all device types.

SLA measurement parameters

Measurement parameters and collector parameters are used when configuring SLA monitoring (see SLA monitoring on page 97 for details).

Driver scripts

A driver script is a Python program, specifically written to perform a particular configuration task. Scripts act like any other policy element within Service Activator. For more details, see Activation Extensibility on page 85.

Policy targets – where policies are appliedA policy target is the point in the network at which a policy element is to be applied. Depending on the policy, this can be a device, an interface, a sub-interface or a PVC endpoint.

Service Activator’s policy model is completely flexible: policy elements can be defined at any point in the system, but the policy targets at which they will be implemented depend on the use of policy roles and an inheritance model.

Policy roles

Roles enable you to logically group devices and interfaces, for example by customer or service package, and set up policy specifically targeted at that group. A role is a



way of grouping a set of policy targets so that they “attract” the same policy-based configuration.

A role identifies the function of a configurable network object such as a device or an interface. These roles can then be linked to policy elements (such as rules, PHB groups or driver scripts) to define the policy configuration that is to be applied. Policy elements are only applied to network objects that have matching roles.

Each device and interface to be managed using Service Activator must have at least one allocated role which defines its function.

Service Activator includes a number of pre-defined device and interface roles that define how it works. Pre-defined roles are important because they ensure that VPN configuration is applied to the appropriate devices and interfaces.

The pre-defined roles support a DiffServ model, consisting of Access, Gateway and Core devices:

Access devices are routers on customer premises that provide access to the core Service Provider network – equivalent to Customer Edge (CE) routers in MPLS terminology.

Gateway devices are those on the edge of the core network that have a direct connection to the local or customer access device – equivalent to Provider Edge (PE) routers.

Core devices are those used for routing within the core Service Provider network. They are sometimes known as Provider (P) routers.

In addition, a Shadow device role is pre-defined; this is used when setting up Service Assurance Agent (SAA) measurements.

There are also four system-level interface roles:

Access interfaces connect access and gateway routers

Local interfaces are interfaces on access routers that connect to the customer’s local LAN or hosts

Role

Policy element

Policy rule

PHB group

Measurementelement

Driver script

Policy target

Device

Interface

Subinterface

VC endpoint



Core interfaces connect core and gateway routers or two core routers

Disabled interfaces are not used.

These system-defined device and interface roles are illustrated below:

The system-defined roles allow you to set up a simple QoS policy based on DiffServ, but for a more complex policy, you can create any number of user-defined roles.

Types of interfaces or devices can be grouped together and given a specific role which can then be used to define the policy that is applied. The type of roles required depend on the policy to be applied. For example, roles could be based on interface capacity (64k, 128k, 1Gig), device function, customer or service package.

Role assignment rules

All policy targets (devices, interfaces, sub-interfaces and VC endpoints) that are to be managed by Service Activator must be assigned roles before services and policies can be configured.

Roles can be easily assigned by setting up rules, known as role assignment rules, which classify devices and interfaces automatically when devices are discovered. You can also apply assignment rules independent of device discovery, and you can assign roles manually.

Devices can be assigned roles based on a combination of device type, DNS name and IP address. For example, you can specify that all Cisco 7500 devices are classified as core devices, or allocate a role to all devices with IP addresses within a particular range.

Interfaces can be assigned roles based on a combination of the device characteristics (role, type, DNS name, IP address) and the interface type and the roles of connected devices. For example you can define an interface role to be applied to Ethernet interfaces on Gateway devices.

Accessdevice(CE)

Accessdevice(CE)

Coredevice

(P)

Gatewaydevice(PE)

Gatewaydevice(PE)

Shadowdevice(SR)

Shadowdevice(SR)

Coreinterface

Localinterface

AccessinterfaceAccess

interfaceAccess

interfaceLocal

interface



Sub-interfaces and VC endpoints can be assigned roles based on the roles of their parent object, or alternatively roles can be set independently.

Inheritance

A process of inheritance means that a policy element that is to be implemented only needs to be applied at a single point in the network and will then automatically apply to all appropriate points. For example, a policy rule to mark packets can be applied to a network object and it will be implemented at all relevant interfaces with appropriate matching device and interface roles.

There are two branches in the inheritance model:

Logical – includes domains, customers, sites and VPNs

Physical – includes networks, devices and interfaces



Configuring QoS policies

QoS and CoSQoS can be defined as a set of specific measures, characteristics and properties that defines how well a network is performing, as experienced by particular traffic flows across the network. QoS can be measured in a number of ways:

Delay or latency – how long it takes for a packet to get from source to destination.

Physical

Network

Interface

Network (root)

Device

SubInterface

PVC

PVC

Site

VPN

CE Devices only

PE Interfaces only

PE SubInterfaces only

Customer

Domain

Logical



Jitter – the variation in latency between subsequent packets. This is particularly important for audio or video transmissions.

Throughput – the average and peak transmission rates.

Data loss – how often packets are dropped and have to be re-sent.

Class of Service (CoS) techniques implement QoS by categorizing network traffic into a small number of defined aggregate classes. This enables some identified network traffic to be treated better than the rest; for example by allocating it more bandwidth, ensuring faster handling, or guaranteeing a lower than average loss rate.

Implementing a Quality of Service solution requires a number of techniques:

Identifying and classifying traffic to determine the QoS to be applied

Marking the packets so that they can be recognized by nodes throughout the network

Traffic shaping, to constrain specific outbound traffic to a particular bandwidth range

Queuing techniques, to prioritize different traffic separately on outbound queues

Policing traffic to ensure that traffic classes do not exceed their share of resources

Classifying traffic

Overview of traffic classification

Routers need to identify and classify types of traffic that are to be allocated different QoS. For example, traffic can be identified by source or destination address or by source or destination port. For IP traffic, this requires the IP header to be examined. Ideally, traffic would be classified once only at the edge of the network, as some overhead is involved in checking the packet. Methods of classification depend on the capabilities of the router.

CE PE PE CE

PTrafficshaping

Police

Shape

Mark

Classify

Shape

Shape& Re-markTime of Day Time of Day

MarkTime of Day



How Service Activator classifies traffic

Service Activator can classify traffic on any combination of:

Source address

Destination address

Type of traffic

The identified source and destination can be a specific IP address or a subnet.

The traffic type is generally identified by source or destination port number and IP protocol, since all network devices can classify traffic in this way.

For devices that can support other methods of classification, Service Activator also supports traffic identification and classification by the following:

Packet marking (such as IP Precedence settings or DiffServ codepoints)

DNS domain name

Application or sub-application for HTTP traffic, URL or MIME type

Traffic classifications are set up by means of traffic types, which can then be associated with the policy rule. A number of predefined traffic types identifying the most common TCP and UDP port numbers are included and additional ones can be set up as required.

Global classification categories can be set up, which identify a particular type of traffic, between a source and destination. Any number of these classification types can then be associated with a particular policy rule. Alternatively, the source, destination and traffic type can be defined specifically for each rule.

Marking traffic

Overview of marking

Identified traffic can be marked with a value to indicate the QoS/CoS that is to be applied to it. If CoS techniques are used, a small number of classes are defined, such as Gold, Silver and Bronze, with each one marked with a specific codepoint.

Service Activator supports a number of standards relating to the marking of IP packets.



DiffServ codepoint

The RFC 2474 standard, “Definition of Differentiated Services Field in the IPv4 and IPv6 Headers”, specifies that IPv4 packet headers include a DiffServ field, as follows:

The six DiffServ bits allow the definition of up to 64 different classes of service. However, the standards define a number of recognized codepoint settings and the corresponding packet forwarding treatment, known as a per-hop behavior.

IP Precedence

RFC 791, which defines the format of IPv4 packet headers, specifies that IP packet headers should include a Type of Service byte, structured as follows:

The three-bit IP Precedence field is intended to indicate the importance or priority of the packet. It allows a set of eight values from 0 to 7 to be set, where 0 is the lowest priority and 7 is the highest. Values 6 and 7 are normally reserved for network control traffic, such as routing updates, leaving six values available for normal traffic.

DiffServDiffServfield

0 1 2 3 4 5

DiffServ codepoint (6 bits) Not used (2 bits)

Length ID Controlflags Offset Time to

liveHeaderlengthVersion Protocol Checksum

DiffServType ofService

0 1 2 D T R

IP Precedence(3 bits)

Not used(2 bits)

Type of Service (3 bits)1 bit each for Delay,

Throughput andReliability

Version Headerlength Length ID Control

flags Offset Time tolive Protocol Checksum



The three bits of the Type of Service field are intended to be used as switches which can be used in combination to specify requirements for Delay, Throughput and Reliability respectively.

MPLS experimental bits

For MPLS traffic, a label is attached to each IP packet at the ingress router to the LSP. This label is used by routers when forwarding packets along the path, and the IP packet header is not examined at any point along the LSP. The three IP Precedence bits are copied from the IP header into the three bits within the MPLS label known as the experimental CoS bits.

The application that generates the IPv4 packet controls the original IP Precedence value. However, some devices are able to reset this value, which can be useful if a precedence is set for a packet at the edge of the network and a Service Provider wants to override this value while the packet transits the core.

How Service Activator implements marking

Service Activator is also capable of setting the Diffserv Codepoints, IP Precedence or MPLS experimental bits where they are supported. Marking is implemented by means of classification rules.

Each classification rule defines a set of conditions and the actions that are taken if the conditions are true. The conditions can be any combination of the following:

One or more classification types which identify the source, destination and type of traffic.

Date and time – optionally, specifies the period of time that the rule applies.

Where these conditions are true for a particular packet, a set of actions is performed.

DiffServDiffServfield

0 1 2 3 4 5

DiffServ codepoint (6 bits) Not used (2 bits)

Length ID Controlflags Offset Time to

liveHeaderlengthVersion Protocol Checksum



Traffic shaping and queuing

Traffic shaping

Traffic shaping, or rate limiting, is a mechanism for controlling traffic on an interface by constraining specific outbound traffic to a particular bandwidth range, for example by specifying a particular maximum bandwidth or by defining burst parameters that the traffic cannot exceed.

Traffic shaping is often used to control access to the core network by constraining the outbound traffic. Traffic shaping does not in itself implement queuing and in some cases can be used in conjunction with a queueing mechanism.

Generic Traffic Shaping (GTS) on Cisco routers is an example of rate limiting. Rate limiting is implemented in the form of a “token bucket” mechanism. The average bit rate defines the rate at which tokens are placed into a bucket of fixed capacity. Each token permits a number of bits to be transmitted. To send a packet, an appropriate number of tokens must be removed from the bucket. If there are not enough tokens in the bucket to send a packet, the packet is queued (or dropped if the queue is full). Therefore, the largest burst that can be transmitted is proportional to the size of the bucket.

Queuing mechanisms

Throughout the network, QoS can be applied by the implementation of specific queuing mechanisms implemented at the various routers throughout the network.

These can be defined as congestion management techniques (applying a queuing algorithm to organize and prioritize the traffic), and congestion avoidance techniques (selectively dropping lower priority traffic to ensure that TCP slows down the rate of its transmission, in order to avoid congestion before it starts).

The way in which QoS mechanisms are implemented is specific to particular device types and models, and more detailed information can be obtained from the appropriate manufacturer. In some cases default settings can apply, and in others various parameters can be set.

How Service Activator implements traffic shaping and queuing

Traffic shaping and queuing techniques are implemented by means of PHB groups. A PHB group is a way of applying one or more policy definitions to a particular interface. The actual forwarding behavior is controlled by the QoS mechanisms that control the queuing and dropping of packets on each router, and thus are specific to particular device manufacturers and types. However, Service Activator’s detailed reporting of device and interface capabilities ensure that it is easy to find out what mechanisms are supported.

The PHB group maps one or more defined classes of service on to the queuing and shaping mechanisms available at that interface.



Service Activator supports the following queuing and traffic shaping mechanisms

— Priority Queuing

— Weighted Round Robin (WRR)

— Weighted Fair Queuing (WFQ)

— Weighted Random Early Detection (WRED)

— Rate Limiting

— Frame Relay Traffic Shaping

— ATM Traffic Shaping

PolicingPolicing involves checking the traffic to ensure that the packets meet an agreed profile, for example an average and burst bit rate. Packets that are out of profile may be dropped or remarked to a lower class of service.

How Service Activator implements policing

Policing is implemented by means of policing rules, which can be used to limit and optionally re-mark identified traffic. A rule defines the bandwidth and burst requirements for the identified traffic, and the action to be taken if traffic conforms to or exceeds the requirements.

Each policing rule defines a set of conditions and the actions that are taken if the conditions are true. The conditions can be any combination of the following:

One or more classification types which identify the source, destination and type of traffic

Date and time – optionally, specifies the period of time that the rule applies

The following bandwidth requirements can be set:

Average rate permitted

Maximum burst rate permitted

Burst interval – the period of time over which the traffic is allowed to maintain its maximum burst rate

Policing actions can be defined for traffic that conforms to or exceeds its bandwidth allocation. Actions are:

Transmit – transmit packets as they are. This would be the normal course of action for conforming traffic.

Drop – drop packets immediately. You would normally only choose to drop packets where low priority traffic had exceeded its limitations.



Re-mark and Transmit – re-mark packets with a different packet marking and transmit. The packets may then be treated differently at subsequent routers.

Re-mark and Continue – re-mark traffic with a different codepoint and continue checking traffic against subsequent policing rules. This could be used when traffic exceeds bandwidth or burst rates. For example, if traffic marked as “Gold” exceeds the agreed policing, it can be remarked to “Silver”, and checked against subsequent rules; if this traffic then exceeds the “Silver” policing it can be remarked to “Bronze”

Modular QoS CLIMQC is Cisco’s simplified configuration of policy mechanisms and actions for traffic queuing, shaping, policing, congestion avoidance and re-marking. It is supported on selected devices and IOS versions.

How Service Activator implements MQC

Service Activator supports MQC by means of a specific MQC PHB group, which can be used to define an entire QoS policy that may be used at various points in the network. For example, an MQC PHB group might be used to manage the traffic going into the core network or to maintain the prioritization set up at the network edge throughout the core network.

An MQC PHB group may be applied to one or more classes of service that are based on a classification or classification group. The classification may be defined by factors such as source and/or destination IP address or account and traffic type. A number of classes of service may be linked to an MQC PHB group and one or more different mechanisms applied to each one.

The following traffic management mechanisms can be implemented within an MQC PHB group and applied to traffic by class of service:

Low Latency Queuing (LLQ) – assigns a traffic class to a strict priority queue with a guaranteed maximum bandwidth during congestion

Class-based Weighted Fair Queuing (CB-WFQ) – assigns a traffic class to a queue with a priority based on a guaranteed minimum bandwidth during congestion

Class-based Policing (single-rate or two-rate) – specifies and enforces conditions that define the maximum inbound and outbound bandwidth of a traffic class, packets that exceed the conditions can be dropped or re-marked

Class-based Shaping – specifies and constrains the maximum outbound bandwidth of a traffic class, outbound packets that exceed the conditions are delayed

Class-based Marking – marks packets to allocate a priority status or class



Congestion avoidance (Queue limit and/or WRED) – defines how packets are discarded during congestion

You can specify the order in which packets are evaluated against each CoS’s match criteria to ensure that packets have the correct mechanism applied to them.

You can also nest an MQC PHB group within another MQC PHB group. This enables you to apply a policy to a broad range of traffic (defined by the parent MQC PHB group) and another to a subset of that range (defined by the child MQC PHB group).

Configuring access control policies

Overview of access controlService Activator’s access control features enable Service Providers to block specific applications, protect sensitive data or prevent identified users from accessing certain services. As part of a comprehensive security policy, this can protect sites and users from malicious denial of service attacks, prevent access to services by unauthorized users and prevent data loss.

How Service Activator implements access controlLike QoS services, access control is implemented by means of rule-based policies that can deny or explicitly permit identified traffic. Rules can be set up to apply at specific dates or times

PE

Access Rule

CE PE PE

P

CE

Classifies trafffic on:Source/Destination IP addressSource/Dest PortIP ProtocolMIMEURLApplicationPacket marking

Traffic is Denied or PermittedOutbound or InboundCan be Date/Time specific



Access rules (or filters) are used to provide network security. Identified traffic can be denied or permitted access to the network. Each access rule defines a set of conditions and the actions that are taken if the conditions are true.

The conditions can be any of the following:

One or more classification types which identify the source, destination and type of traffic

Date and time – optionally, specifies the period of time that the rule applies

Where these conditions are true, the identified traffic can be denied or permitted access (either inbound or outbound or both).


Product Overview – Third Edition Activation Extensibility

Chapter 5

Activation Extensibility

This chapter explains features that can be used to extend Service Activator’s activation capabilities, including the Configuration Template Module (CTM).

Pre-defined scriptsIn Service Activator, two pre-defined scripts are supplied:

Running scriptsNo programming experience is required to set up and apply existing scripts. Users can view existing scripts directly from the Service Activator user interface, set up any variables required and associate the scripts with appropriate devices, interfaces or VPNs in the network. Each script has a defined type, which specifies whether it configures devices, interfaces, sub-interfaces, ATM PVCs or Frame Relay PVCs. However, a script can be applied to objects throughout the network topology (networks, VPNs, devices, interfaces, sub-interfaces and PVCs) and will be applied appropriately by the standard inheritance process.

Scripts are treated as policy elements in exactly the same way as rules or PHB groups. Each script is allocated one or more roles, and can be associated with objects at different levels of the hierarchy. The script applies to all relevant lower-level objects by a process of inheritance. For example, if an Interface script is associated with a site object, it will be applied to all appropriate interfaces on devices within that site.

Driver Script name Purpose

Cisco IOS NVRAM.py Copies the running configuration to startup configuration

CatOS CatosAddVlan.py Adds a VLAN to a CatOS switch


Activation Extensibility Product Overview – Third Edition

User-defined variables can be associated with the particular objects to which scripts can be applied, so for example you can define a generic script that when run applies different values to different interfaces.

Users can select when a script is run – for example, a script can be run either before or after any other configuration tasks, and can be run once only or repeated at every subsequent propagate.

Scripts can include an Install section that applies configuration when linked to an object and a Remove section that removes the configuration when the script is unlinked.

Developing scriptsExperienced Python developers can produce their own scripts. Although simple scripts can be entered directly into the user interface, they would normally be written using a text editor and compiled and checked outside Service Activator before being imported.

To ensure that driver scripts are displayed correctly on the user interface and present a consistent approach, a standard template is provided with Service Activator.

Data can be shared between the scripts that are run for a particular device. This powerful feature has a range of applications, including the ability to store and re-use


Product Overview – Third Edition Activation Extensibility

data or functions that are commonly used by scripts and to exercise greater control over the order of script execution.

The Device Driver allocates an area of memory for each device that it manages. This is referred to as the shared data area or shared area. Shared data may be stored for the lifetime of the device – that is, until the device is unmanaged or the Device Driver restarted – or for a single transaction.

Configuration Template ModuleThe Service Activator Configuration Template module (CTM) provides the following features:

create, update, and delete configuration templates

activate a template

perform related activities (view template events, set the lifetime of events, manage user access to CTM, and match templates to schema versions)

The Configuration Template Module helps you to streamline the activation of services on network objects. Through the use of pre-defined or customized templates, the module extends the Service Activator capability to configure devices and interfaces.

The Configuration Template Module consists of three graphical user interfaces (GUIs):

The Activation GUI is used to select a template appropriate to an object or set of objects, to fill in data forms, and to send the resulting configuration command set to objects in the network.

The Administration GUI is used to show all templates, and to create, modify, view, and delete templates. Templates define the layout of the data entry forms and the configuration commands to be sent.

The Audit History GUI is used to review administration events (create, update), provisioning events (activate) and event details.

The user launches these applications from an object context within the IPSA user interface. The launch object can be a network, device, interface, or sub-interface.

The Configuration Template Module requires that the OSS Integration Manager (OIM) be purchased and running. It is also necessary to be running the Service Activator GUI, CTM Request Server, and Oracle database (SQL and Oracle listener).


Activation Extensibility Product Overview – Third Edition


Product Overview – Third Edition Integration Features

Chapter 6

Integration Features

This chapter describes the features of Service Activator that enable it to integrate with other OSS applications. It includes the following:

The OSS Integration Manager – how you can seamlessly integrate Service Activator with other applications

The Event Handler – how you can report faults and events occurring throughout the managed network

The OSS Java Development Library – how you can develop your own interfaces and web-based access to Service Activator

Out-of-the box integrations – solutions allowing seamless integration with Micromuse and InfoVista


Integration Features Product Overview – Third Edition

The OSS Integration ManagerThe OSS Integration Manager (OIM) enables Service Activator to be easily integrated with OSS applications such as order entry, service assurance, fault management and billing.

The OIM consists of an open application program interface (API) that allows systems developers to access subsets of the Service Activator data model. Use of a Common Object Request Broker Architecture (CORBA) interface ensures secure and standardized communication with other applications, and can easily be adapted to use alternative architectures such as Tibco, Vitria or XMP. Developers can develop scripts using any CORBA-compliant programming language (such as C++, Java, or Python), or use a command-line interface which allows user to run the commands interactively.

Deviceconfiguration

Multi-vendor IP network

OSS Applications(Service Assurance, Billing, Fault Reporting, etc)

OSS Integration Manager(Flow-through service activation, browsing topology, event reporting)

External Object Model

Core Service Activator System(Service & policy calculation/validation, distribution,

device configuration)

Object Model

CORBA



The OIM has been specifically designed to simplify the work of system developers wishing to integrate with Service Activator. To write applications to integrate with Service Activator, developers need:

Details of the OIM command set and syntax

Details of the objects that can be accessed and the relationships between them

Command setThe command language comprises a set of commands that provide an interface to the API. It is limited to a small set of generic commands such as create, find or modify that operate on defined objects and their attributes. The use of generic commands means that the command set is not affected by changes to the object model, and is sufficiently flexible to support diverse uses such as integration of OSS applications, service activation or custom web development. Commands are grouped into various modules, but all commands have the same basic format, similar to Unix or other scripting languages:

command [object_path] [parameters]

Commands that execute changes to the database and network are aggregated into transactions, which work in the same way as using transactions from the Service Activator user interface. This logical approach helps ensure straightforward scripting.

The External Object ModelThe External Object Model (EOM) is a simplified version of Service Activator’s knowledge store. It defines all the objects that can be accessed or updated by external applications, including their attributes and the relationships between them.

Using a subset of the entire object model means that user programs can create and access data objects without needing to know the underlying complexity of the entire object model. The External Object Model is independent of the command syntax – new attributes and objects can be added without requiring new commands.

Objects in the External Object Model are divided into three major categories:

Topology: these objects represent the topology of the managed network, such as Network, Device and Interface objects.

Policy: these objects represent elements used to define policies and services that can be configured on network nodes, such as Domain, Rule and Traffic Type objects.

System: these objects represent Service Activator components and the event handler subscription model, such as Component, Subscription and Fault objects.



Transaction monitoring functionsIn Service Activator, the Policy Server performs full transaction monitoring. Service Activator flow-through applications can therefore reliably tracks the progress of all IPSA transactions as the corresponding configuration changes are activated on the network. This allows flow-through application, which generally use IPSA through its OIM APIs, to monitor the success or failure of their IPSA transactions.

The IPSA object model uses the concrete activation status to indicate whether a transaction’s configuration changes, corresponding to each individual concrete, were successfully activated on the network.

The concrete activation status is recorded for the concretes affected by a particular transaction. It is aggregated into the overall provisioning status for the transaction. Both are attributes of the transaction object and can be observed in the Service Activator GUI and the APIs of the OSS Integration Manager:

CORBA

OSS Java Development Library (OJDL)

For more information about OJDL, see page 96.

More information about transaction monitoring functions is provided in the Administrator’s Guide.

Uses of OIMOther software applications can use the OIM API to create and modify services for particular customers. For example, external applications can:

Discover network elements, including details of interfaces, sub-interfaces and PVCs and their capabilities, or create devices for pre-provisioning.

Set up customers and sites, link sites to network elements and create VPNs and Transparent LAN Services.

Set up and apply QoS or access control policies and apply them to specific points in the network topology.

Subscribe to fault and state changes in any object.

Fault and event reportingService Activator can inform external applications of events/faults that occur throughout the network it is managing. This functionality is provided by the Event



Handler, an optional component which is accessible via both OIM and the Service Activator user interface.

The Event Handler enables configurable, software-driven control of event reporting. It includes the following features:

The Event Handler can report various events occurring in the managed network – the occurrence of a fault reported by Service Activator, the creation, deletion, linking or unlinking of an object, the change in the status of an object or the change in an attribute of an object.

Users can define the events they are interested in by setting up subscriptions, which can be viewed, added, deleted and modified through the OIM or via the user interface.

Events can be delivered using different methods (SNMP, CORBA or Netcool Probe).

User-defined filters can enable subscribers to define exactly the events of interest, for example, specific faults and fault categories.

All system events

Event Filter

Event Collector (Scope)

SNMP CORBA NetcoolProbe

Delivery

t

Delivered events

Filters precisely definereported events

Scope definesarea of interest

Subscription



SubscriptionsExternal applications communicate with the Event Handler by means of event subscriptions, which allow users of external applications considerable control over the events reported. For example, you can set up subscriptions to report on the following:

All events and faults occurring anywhere in the system

Faults reported in Service Activator components

All events occurring in a specific VPN

Events occurring on all PE devices in a network

A set of specific faults relating to communication problems

Collection and filteringThe Event Handler gives subscribers considerable control over the events to be reported.

The primary point of interest can be defined. For example, an associated object in the network topology can be selected, such as a network or specific device. You can choose to report on this object only, or the object itself and all objects below it in the hierarchy. The scope can further be restricted by class of object, such as all devices, or all sites in a VPN. If you are reporting on devices and interfaces, you can choose to report only on those with a specific role. So, for example, you can set up a subscription to report on all configuration faults occurring on PE devices and their associated interfaces in VPNs associated with a specific customer.



For faults and attribute changes, you can apply filters to identify even more precisely the events to be reported. For faults, you can set up a filter to report faults in a particular category, or even by individual fault code. For attributes, you can select the individual object attribute to be monitored.

This categorization enables different types of messages to be accessed by different systems. For example, problems with provisioning may be of interest to billing systems, since requested services may have been compromised, while communication faults are more relevant to network engineers

Delivery methodsEvents can be delivered to external applications as SNMP traps, via a CORBA interface or via the Micromuse Netcool API.

SNMP trap reporting

Faults and clears reported from the Service Activator components can be delivered to other applications in the form of SNMP traps.

A basic method, ensuring compatibility with earlier releases of Service Activator, reports the ID, severity and description of the fault.

An upgraded method enables events other than faults to be reported, and provides more information about the event, such as the IP address and status of an affected device.

Traps can be reported in SNMP v1 or v2 format.

CORBA interface

The CORBA delivery mechanism allows CORBA clients to register and receive events via CORBA calls. The events are sent using the same format as defined by the CosNotification standard for structured events. An event channel name is defined in the Service Activator user interface (or through the OIM) when setting up the subscription object. A client may connect to one specific channel or all of the event channels defined in the subscriptions.

Micromuse Netcool integration

Any type of event reported from Service Activator can be forwarded to Netcool/ OMNIbus, the Micromuse Service Level Manager. This means that the network manager benefits from a single point where all events are reported, prioritized and resolved. See Fault management on page 101 for more details of the integration.



The OSS Java Development Library (OJDL)The OSS Java Development Library is a toolkit that enables the development of web-based user interfaces to Service Activator and the integration of data from billing, fault or performance measurement software. Based on the OIM API, it provides a set of Java classes that provide general access to the OIM and Java server pages ready for web deployment. An example web-based user interface is provided, which integrators can use as a basis for their own development.

These features enable Service Providers to offer self-provisioning web interfaces, allowing their customers to order, view and amend their own services without any intervention by the provider. The interface can also be optimized for web self-management or centralized workflow provisioning, for example, for call center usage.

The OJDL consists of the following components:

A toolkit – a set of Java classes and beans that may be used to integrate third-party applications or develop a Java front end to Service Activator.

A sample interface – an example interface that may be used for demonstration purposes or as the basis of your own development.

The elements of the OJDL Toolkit and sample application are shown in the following diagram.

External Object Model

All system events

Java Classes

Java Server Pages

CSS file

Web browser

OJDL(toolkit)

Javabeans



The OJDL interfaces with Service Activator via the EOM. Objects in the EOM can be manipulated using pre-defined Java classes. These classes provide a generic front end to the OIM, supporting quick and easy integration by a Java developer. In addition, pre-defined Java beans simplify the development process, providing reusable collections of the OIM commands required to perform a particular task, such as logging in.

Out-of the-box integrations

SLA monitoringThe ability to offer and monitor Service Level Agreements is essential to Service Providers, who risk substantial losses if network downtime occurs and agreements are violated. Real-time reporting is a valuable tool in preventing network downtime, by highlighting potential problems before they actually occur. Real-time and historical reports provide a valuable tool when selling services, enabling the Service Provider to demonstrate their ability to offer guaranteed service levels.

Service Activator integrates with InfoVista™, enabling Service Providers to offer real-time, customer-oriented IP services with guaranteed levels of service. SLAs can



be monitored through at-a-glance reports, enabling the Service Provider to identify potential problems before they occur.

“Out-of-the-box” integration reduces management and operational costs by providing automated activation and workflow management for the delivery of IP services and SLA reporting, including Service Assurance Agent (SAA) and NetFlow configuration.

Types of measurements supported

A number of range of measurement techniques are supported, enabling measurement of point-to-point performance, or performance at a specific point in the network:

Service Assurance Agent (SAA) – a Cisco technology that performs point-to-point measurement based on key SLA metrics such as response time, network resources, availability, jitter, connect time and packet loss.

NetFlow – a Cisco technology that enables you to characterize and analyze an IP flow on an interface. It is often used as a metering base for other applications, including accounting/billing, network planning, and marketing.

MIB2 statistics – report on Management Information Bases (MIBs) in MIB2 format. Their variables indicate the basic state of the network – for example, load, availability, discards and broadcast rate.

Class-based QoS MIB (CB QoS MIB) statistics – provide information about the policy and class maps that are configured on a device. In Service Activator terms, these statistics map onto the Class-based WFQ, WRED or MQC PHB groups that have been configured through the user interface.

Both SAA and NetFlow involve configuration on the device and this is performed automatically by the Service Activator Device Driver.

Integration architecture

Service Activator employs a basic generic architecture that supports integration with a range of third-party reporting tools. The following diagram illustrates the architecture of the integrated solution for InfoVista.



Integration with InfoVistaThe Service Activator integration with InfoVista offers a very scalable solution – a number of InfoVista Servers and plug-ins can be distributed throughout the network, each one polling a subset of managed devices. Service Providers can specify the type of measurement to apply and the points in the network to monitor. A range of reports is available for each measurement type, and for a range of time periods including real-time, hourly, daily and weekly.

Key components

Four components (one in Service Activator and three in InfoVista) enable InfoVista reporting with Service Activator.

InfoVista Integration module - A Service Activator module that includes the TopologyExporter utility and several integration files. The TopologyExporter exports the object model and converts it to an InfoVista format ready for import.

Proxy Agent Host (multiple instances)

Device DriverDevice Driver Device

Driver

Proxy Agent

User Interface Host

Host

InfoVista Integration Module

Component Manager

Component Manager

Host

Event Handler

Third-party tool

User Interface

Host

Component Manager

Network Processor Host (multiple instances)

Cartridge Cartridge Cartridge

Network Processor

OSS Integration Manager

Component Manager

Naming Service

Policy Server Host

Policy Server

Oracle Database

System Logger

Component Manager

DatabaseHost

InfoVista Server

Host

External system Service Activator

manual file transfer



InfoVista Server - An InfoVista component that uses SNMP to poll and collect SAA and MIB-based data from devices and NetFlow data from Vista Plug-ins for NetFlow. A Service Activator file allocates devices to InfoVista servers.

Vista Plug-in for Netflow - An InfoVista module that collects and aggregates UDP datagrams from NetFlow-enabled devices and exports the data to an InfoVista Server. The component is required only when the NetFlow measurement is applied. A Service Activator file allocates devices to Vista Plug-ins for NetFlow.

Vista Provisioner - An InfoVista utility that enables users to automate a number of key tasks in the administration of an InfoVista Server.

Each InfoVista Server maintains a local object model that reflects the devices assigned to it and the measurement applied. In the InfoVista object model, a class of objects is referred to as a Vista. Service Activator objects (device, interface, PVC, SAA operation, ...) are mapped to InfoVista Vistas. A VistaView is a library of Vistas, report templates and rules.

Integration files

A service provider can customize the integration between Service Activator and InfoVista by modifying the integration files in Service Activator’s InfoVista Integration module. For details, refer to the InfoVista chapter in the Network and SLA Monitoring Guide. Integration highlights include:

Service Activator’s TopologyExporter utility creates the Toplogy.txt file that identifies which data to collect for the InfoVista reports. Other Service Activator files provide validation and structure to the integration.

The Topology.txt file identifies to the Vista Provisioner all devices in Service Activator that are assigned to either an InfoVista Server or a Plug-in for NetFlow collector. The Def.txt file provides the data dictionary that validates the sanity of the Topology.txt file. The report.pl file defines the folder structure to be used by InfoVista for storing reports, and ACL access to reports.

InfoVista imports the Toplogy.txt and other integration files from Service Activator, polls the devices, and generates the necessary reports.

The object model between Service Activator and InfoVista is synchronized when the Topology.txt file is imported by the Vista Provisioner. The InfoVista Server polls the assigned devices for SAA and MIB-based statistics using SNMP. For NetFlow statistics, the InfoVista Server polls the Vista Plug-in for NetFlow, which collects the NetFlow statistics directly from the devices. Group reports are generated by Vista Provisioner based on configuration information provided by the Def.txt file.



ASAP-IPSA Process Integration Pack (ASAP-IPSA PIP) The ASAP-IPSA Process Integration Pack (ASAP-IPSA PIP) enables customers to use ASAP work orders to perform IP service activation tasks through Service Activator (IPSA). The ASAP-IPSA PIP contains a set of Common Service Description Layer commands (CSDLs). Each CSDL contains one or more Atomic Service Description Layer (ASDL) commands. CSDLs are used to accomplish a range of tasks, from the simplest task using a single ASDL command, to more complex tasks incorporating several or many ASDLs.

Oracle strongly advises customers and systems integrators to never modify the ASAP-IPSA process integration pack. Not modifying this cartridge ensures easy upgrades to future releases. Customers can create custom CSDLs in a separate ASAP cartridge which can then invoke the ASAP-IPSA process integration pack.

For flowthrough compatibility, ensure you use the following product releases: IPSA 5.2.3 and ASAP 5.2.3 (and SCE 3.0.0, if you are creating custom CSDLs). The Service Creation Environment (SCE) provides the Studio application, which is the recommended tool for creating custom CSDLs, because its GUI permits easier manipulation of CSDL and ASDL building blocks.

Work orders are used to accomplish activation-related tasks on devices managed by a Service Activator (IPSA) system. A work order can consist of one, several, or many individual actions. A work order is defined in terms of ASDL and CSDL commands.

Flowthrough integration enhancements in ASAP 5.2.3 and IPSA 5.2.3 include:

Work orders exercise full control of Service Activator transactions.

End-to-end transaction monitoring (and rollback capability) is implemented.

Each Configuration policy CSDL has a parameter whose value is the XML file for that configuration policy. Configuration policies include interface policy registration CSDLs.

Configuration template module (CTM) CSDLs are added into the ASAP-IPSA PIP. Prior to version 5.2.3, they were handled by a separate CTM cartridge.

Get/Find/Bind CSDLs are added to improve Service Activator object searching and ASAP context setting.

Fault managementService Activator’s integration with Micromuse Netcool offers an integrated solution for the sending and translation of network faults, clears and events. The network



manager benefits from a single point where all events are reported, prioritized and resolved. This significantly improves operational effectiveness.

Integration is via the Event Handler, which collects, filters and delivers details of faults and other events.

Monitored events are defined by subscriptions – collectors describe the scope of the subscription, while filters precisely define the type of events to be monitored. Event types include faults and attribute changes.

Multiple subscriptions can be defined, with each subscription sending events to a single Netcool/OMNIbus host machine or to distributed host machines.

Example subscriptions might monitor:

All events and faults occurring in the network

A specific customer’s VPNs for provisioning faults and clears

Events occurring on all PE devices within the network

Communication faults

The Event Handler’s behavior is modified by a rules file, which defines how Service Activator faults and events are converted into Netcool/OMNIbus events.

The converted events are forwarded as Netcool events via the NIM to the Netcool Object Server and can be viewed in an event list using the Netcool/OMNIbus Conductor.


Product Overview – Third Edition Index

Index

AAccess

devices 71filters 83interfaces 71rules 70, 83

Access controlpolicies 82support 68

Activation extensibility 85Allow AS in 50Architecture

integration 98overview 16

AS override 50ATM Traffic Shaping 80Authentication

PE-CE 50Automatic mapping 29Autonomous System 41

BBGP 41, 44

CCapabilities 25CCCs

introduction 63Layer 2 switching 64MPLS tunneling 64

CE routers 41Class-based

marking 81policing 81shaping 81Weighted Fair Queuing (CB-WFQ) 81

Classification rules 69CLI 30

Community attributeseBGP 50iBGP 49

Component manager 20Configuration Development Kit (CDK)

developing scripts 86pre-defined scripts 85running scripts 85

Configuration Template Module (CTM) 15, 21, 87

Congestion avoidance 82CORBA 18, 90Core

devices 71interfaces 72

CoSintroduction 74

CPE routers 41customer support viii

DDatabase 18Delay ToS bit 78Device

access 25authentication 25capabilities 25configuration 31discovery 25polling 31

Device Driver 18, 30DiffServ codepoint 77Discovery engine 24documentation

downloading viiiService Activator ix

Driver scriptsas policy element 70



developing scripts 86pre-defined scripts 85running scripts 85

Dynamic User VPN (DUVPN) 12, 21, 51

EeBGP 44, 49

definition 42device support 46

Ethernet VLAN services, Metro 61Event Handler

collection 94CORBA interface 95Delivery methods 95Micromuse Netcool integration 95SNMP trap reporting 95subscriptions 94

Event reporting 92Expert service modules 12Export maps 48Extending activation capabilities 85External Object Model (EOM) 33, 91

FFault and event reporting 92Filters, access 83Frame Relay Traffic Shaping (FRTS) 80

GGateway devices 71Generic Traffic Shaping (GTS) 79Graphical user interface 20

HHosts 27Hub and spoke VPN 47

IiBGP

definition 41device support 45implementation 48purpose 44

IGP 50InfoVista

Integration module 99Server 100Vista 100

Vista Plug-in for Netflow 100Vista Provisioner 100

InfoVista integration 21, 97, 99Inheritance 73Interface

capabilities 25IP Precedence 77IPsec VPNs 12, 21, 53IS-IS 44

JJava server pages 96Juniper M-series devices Circuit cross

connect 63

KKnowledge store 32

LLabel Switched Paths (LSPs) 13, 21, 56Layer 2

MPLS LSPs 13, 21, 56MPLS tunneling CCCs 64MPLS VPN (CCCs) 63MPLS VPN (Martini) 12, 54switching CCCs 64

Layer 3IPsec VPNs 12, 21, 53MPLS VPN (DUVPN) 21, 51MPLS VPN (RFC 2547) 12, 40

Load balancing 47, 49Local interfaces 71Local preference 50Low Latency Queuing (LLQ) 81

MManagement VPN 47Manual

configuration 31mapping 29

Map views 28Mapping

automatic 29manual 29

Marking 76class-based 81

Martini VPN 12, 54Maximum Paths 51



MD5 authenticationPE-PE 49

Mesh VPN 47Metro Ethernet virtual LAN services 13, 61Micromuse Netcool 101Modular QoS CLI 81Modules

expert service 12MPLS 78

experimental bits 78tunneling CCCs 64

MPLS VPNsconcepts 40DUVPN 21, 51IPsec 12, 21, 53LSP activation 13, 21, 56Martini 12, 54RFC 2547 12, 40support 45

MQCintroduction 81PHB group 70, 81

Multi-path load sharing 51

NNaming service 18NetFlow 98Network discovery 24Network Processor and cartridges 13, 19

OObject

ownership 38permissions 38

Object model 33external 33

Object representationdevices 26interfaces 27networks 26PVCs 27segments 27sub-interfaces. 27

OIMcommand set 91External Object Model 91introduction 90uses 92

OJDL 96Optional components 20Oracle database 18OSPF 44, 49OSS Java Development Library 96

PP routers 40Passwords 25PE routers 40PE-CE configuration 49PE-PE configuration 48Per Hop Behavior groups 70Permissions, object 38PHB group

MQC 81standard 79

Policing 80class-based 81rules 70

Policyelements 68roles 70rules 69server 17targets 68, 70

Port and VLAN--based TLS 61Port-based TLS 60Pre-defined

export maps 48VRF tables 48

Prefixfilters 51limit 51

Priority Queuing 80products

downloading viiiProxy agent 18

QQoS 13

classifying traffic 75introduction 74marking traffic 76support 68

Queuingmechanisms 79priority 80


Index Product Overview – Third Edition

RRate Limiting 80RD number 47Read Only access 36Read Write access 36Re-marking 80Reporting 32RFC 2474 77RFC 2547 MPLS VPN 12, 40RFC 791 77RIP 44, 49Riverstone devices

Transparent LAN Service 57Role assignment rules 72Roles, policy 70Route

dampening 51Distinguishers 42, 48redistribution 49Reflectors 49target 43, 47

Routingloops 50protocols 44

RSVP 63RT number

format 47per VPN 48

Rulesaccess 70, 83classification 69policing 70policy 69

SSecurity 36Service Activator

architecture 16Core components 17

Service Assurance Agent (SAA) 71, 98Service modules

expert 12Shaping, class-based 81Single-rate policing 81Site of origin (SOO) 51SLA

measurement policy elements 70monitoring 97

reporting 98SNMP traps 32Specific integrations

InfoVista 97, 99Micromuse Netcool 101

SSH 25authentication 30

Standard PHB groups 70Static routes 44, 49Super User access 36support

customer viiiSystem components

component manager 20Device Driver 18naming service 18Network Processor 19policy server 17proxy agent 18user interface 20

System message 18

TTACACS+ 25, 30Token bucket 79Topology

map 28model 26

ToS bits 78Traffic shaping 79Transactions 34

definition 34monitor 92rollback 35scheduling 34workflows 35

Transparent LAN Service (TLS) 57port and VLAN-based 61port-based 60

Two-rate policing 81Type of Service 77

UUser

authentication 36groups 36IDs 25interface 20



permissions 36

VVirtual Private LAN Services (VPLS) 13Vista

Provisioner 100Vista, definition of 100VLANs

Activation module 20Metro Ethernet 61stacked 62tagged 62untagged 62

VPN topologies 12, 47VPN-IPv4 addresses 43VRF

re-use (reduction) 46route limit 48table names 46tables 43, 48

WWeb-based user interface 96Weighted Fair Queuing (WFQ) 80

Class-based 81Weighted Random Early Detection

(WRED) 80, 82Weighted Round Robin (WRR) 80Workflow provisioning 96


Index Product Overview – Third Edition
