Use case of MPLS in a service provider environment

Transcription

1 WHITE PAPER MPLS Network Management Visionael OSS Suite Use case of MPLS in a service provider environment Author

2 2 Table of Content: Introduction... 3 Achieving a balanced COTS approach...3 Multi vendor considerations...3 Product Family Overview...3 Network Resource Manager Physical and logical management of networks... 4 Network Communications Manager Discovery and activation of networks... 4 Service Manager Provisioning and visualization of products and services... 5 Automation Framework Workflow management and business processes... 6 Resource Orchestrator Resource allocation and asset management... 6 The Management Life Cycle...6 Fictive Network and Example Uses Cases...7 Discovery... 8 The Network Mirror...8 Discovery Manager...9 Level one discovery... 9 Level-two discovery...11 Reconciliation into NRM...12 Resource Management Product & Service Catalogs Resource-, Service- and Product Definitions...15 Service Provisioning...17 Actions and business rules...17 Order decomposition...18 Custom order entry and entity views...20 Transaction and exception management...22 Service Discovery and Correlation...22 Network Activation Model based activation...23 Action based activation...24 Asynchronous activation...25 Network communication...25 Template engine and vendor specific configuration statements...26 Transaction management and rollbacks...26 Standard configuration templates...27 Using the file area with boot- configurations...27 Service Feasibility and Service Assurance APPENDIX A. Service Examples...29 L2 Point-to-Point MPLS Access...29 L2 Local switching...31 L2 Point-to-Point L2 Access...34 L2 E-Tree service...34 E-LAN Hierarchical-VPLS...35 E-LAN Flat VPLS...38 L3 MPLS VPN, PW Access...39 L3 MPLS VPN, L2 Access...40 Multicast over MPLS VPN...40

3 3 Introduction Achieving a balanced COTS approach The Visionael Suite is a set of loosely coupled applications that may work independently, together or as part of a larger OSS environment. A clear focus from the start has been to design and develop a modular suite, where applications and their modules have crisp scopes allowing them to fit in true SOA environments. One of the first directions with the next generation Visionael Suite was to eliminate the concept of internal and external integration and give every application a strict contract to the rest of the world, including any other products within our own suite. This philosophy has proven very successful as it gives our teams clearer goals and visions, and provides our customers with better possibilities to build true best- of- breed environments. All this being said The Visionael Suite is a true COTS application suite, which out of the box has a tremendous amount of knowledge about all aspects of modern network management. Multi vendor considerations Even though the Visionael Suite is network element vendor agnostic many of the out- of- the- box components are shipped with plug- and- play adaptations for Cisco, Juniper and other large vendors, however, all vendor support created by Visionael has been done so using tools that are part of the products. This means that as long as our customers choose vendors that have interfaces that avail network management (CLI, SNMP, NETCONF etc.) such vendor support can, and is meant to, be built on- site, by PSO, a contractor or, most importantly, the customer himself. Product Family Overview The new generation Visionael OSS Suite consists of five product families with different scopes within Enterprise- and Service Provider network and service management. The suite is deployed in a Java EE (Glassfish) environment and all API s are exposed over an Enterprise Service Bus providing a common suite API known as the Visionael Composite Application.

4 Conceptual overview of the Visionael Suite Despite the fact that the different product families in most cases are integrated and make extensive use of each other in various deployment scenarios they are conceptually separated and may be deployed standalone or in conjunction with other third- party products. Network Resource Manager Physical and logical management of networks NRM is the heart of the Visionael Suite. It contains the network repository with physical and logical resources and the complete meta- layer on top of it providing utilization claims, planned work, historic changes and much more. NRM is the application where you define sites, racks, devices and logical paths and circuits. NRM is also the application where you see you network from a network management perspective, rather than a service perspective. Network Communications Manager Discovery and activation of networks The NCM product family consists of products providing abstracted, synchronized and secure communication with legacy and next generation Enterprise and Service Provider networks. This involves both northbound oriented operations i.e. discovery, and southbound oriented operations i.e. activation. A conceptual overview of the NCM product family can be seen in the diagram to the right. It is worth noting that reconciliation of north bound network data (i.e. discovered network information) is not within the NCM scope, but rather stakeholders such as NRM. 4

5 5 Service Manager Provisioning and visualization of products and services The Visionael Automation Suite enables the automation of services across multiple types of networks, linking the three interlocking dimensions of next- generation offerings: customers, networks and services. SM is a critical component to the suite. It offers an unprecedented level of automation for manual processes and repetitive tasks associated with the definition, creation, provisioning and activation of next generation services rolled out in both legacy and NGN networks. SM is designed for Service Providers, Managed Service Providers and large Enterprises that market and operate virtualized services to the corporate and residential market, and who want to get ahead of their competition in regards to service time- to- market, provisioning and activation efficiency and accuracy. SM significantly reduces the complexity in defining, instantiating, provisioning and activating configuration- heavy next generation services, and, if integrated with the appropriate databases for customer and contract management, simultaneously associating customers with the consumption of physical and logical resources through a contract and a service by: Relying on an accurate representation of the network and its logical resources supplied by NRM and Resource Orchestrator (described later) Instantiating defined product families and products with minimal or no manual interaction Sharing unified discovery and reconciliation with other parts of the suite, enabling Service Discovery and Service Audit capabilities Dynamically relating administrative data with technical data, allowing a detailed representation of physical and logical resource consumption and availability. Accurately provisioning of services by using next available resource of the various relevant entities to be reserved for the service instance, and release of resources at service termination Availing a unique combination of web administered workflow, task management, configuration modeling and product management

6 6 Automation Framework Workflow management and business processes The AF is Systems Orchestrator that is a workflow engine allowing PSO and the end- customer to define custom behavior and integration with other systems on top of the native applications. SO adds tremendous value in its secure workflow management. Resource Orchestrator Resource allocation and asset management RO is a central product in the suite responsible for the technical definition of physical and logical network resources and their respective life cycles. RO works closely with SO (custom life cycle logic) and NRM (network repository) to achieve this. The Management Life Cycle In the next section a fictive network will be described. Throughout this document the different aspects of network management will be described and demonstrated based on hypothetical use cases of this network. The Visionael OSS Suite product families have clear scopes that address different parts of the overall network lifecycle. This allows for more straightforward integration with third- party products that may already be deployed in a given OSS environment. This document tries to cover the different steps in the network management lifecycle in a fairly logical fashion by beginning with discovering the fictive network already deployed. In a green field scenario this step might not be the first logical step initiating the management life cycle, however it s always an essential step in future life cycles to keep good integrity in the network repositories.

7 7 Fictive Network and Example Uses Cases Figure X contains fictive service provider network. Both the Core the Head- End and the POP routers are Cisco based routers. Each PE router has a distribution network attached to it with a POP site at the end (seen in figure X). Site A CPE ADSL DSLAM ACC 1 VDSL DSLAM The POP- site called Site A in which there are two Paradyne DSLAM s, one based on VDSL technology, and one based on ADSL. The VDSL platform can deliver an 8 or 10 Mbit/s customer uplink and an 8, 10 or 12 Mbit/s downlink, whereas the ADSL platform can deliver a 1 or 2 Mbit/s uplink and a 2, 8, or 24 Mbit/s downlink. They both support the QoS option UBR (unspecified bit rate).

8 8 The distribution network deployed consists of two Extreme Networks Ethernet based switches. These switches interconnect the DSLAMs in Site A with the MPLS enabled IP core. This document is to a large extent organized to follow the logical steps in the life cycle described in the previous chapter. Every section gives a brief overview of the functionality of the domain in general, then a more in- depth elaboration on how this applied to the fictive network. Sections containing elaboration on the fictive network are presented like this. Discovery The Network Mirror The Visionael Network Mirror is a unique repository of information exposed to network inventories and other systems that desire raw, but fresh network data. Compared to NRM, which exposes a high level, abstracted network documentation including derived topology information, future designs and allocated logical and physical resources it provides an as- is view of the network from a technical perspective. As such the Network Mirror offers other applications high quality network data to be reconciled into their more high level repositories or being used as rapid network state information in scenarios where appropriate. Conceptually the network mirror consists of one or more hierarchical trees of information about networks and their nodes and entities. The discovery engine is responsible for feeding the network mirror with fresh data about network entities using different techniques. Different parts of the network can furthermore be setup to have different timeouts that triggers new discovery and rules can be set up that control the precedence of different discovery techniques and how certain events may trigger follow- up discovery. A client using the network mirror API s to fetch raw network data may define how fresh the data it desires must be. If the current network mirror representation of the desired elements doesn t need the required state discovery may be triggered in real- time. Another area where the network mirror differs from a traditional network repository is that it contains both configurational data (applied settings) and runtime information (acquired state), such as routing tables, layer 2 forwarding tables etc. This is seldom information desired in a network repository, but can be very valuable in other scenarios, such as fault management, root cause analysis and secure and robust activation.

9 9 Discovery Manager The Visionael Discovery Manger is a discovery framework providing an out- of- the- box set of discovery engines to fetch network related data using different technologies such as SNMP or parsing of device configurations. The framework provides an SPI (Service Provider Interface) that allows the discovery framework to be extended with new implementations focusing on specific sources of information. These implementations use the common discovery infrastructure to populate the Visionael Network Mirror using public API s over the Enterprise Service Bus (ESB). Regardless of discovery source the information is always consolidated in the Network Mirror for further exposure to reconciliation engines through the ESB bus. Level one discovery As mentioned earlier the Visionael OSS Suite is by no means limited to MPLS enabled networks, and even in modern NG Network the ability to effectively discover basic network information is often a requirement to fulfill the overall business case. The Visionael OSS Suite address discovery through the Disovery Manager product, a part of the Network Communication Manager product family. When the Discovery Manager is configured to discover our fictive network described in section X.X it would for example scan a set of supplied IP ranges to find starting points for further crawling. Based on supplied SNMP communities it fetches information in SNMP MIBs to establish a physical overview of the elements found in the network. All the information is then populated in the Network Mirror. If we simplify it a bit a conceptual overview of the information populated in the Network Mirror could look something in the line of: Some elements are omitted for better overview.

10 10 Even though much more information is gathered as part of the level one discovery process it will not be covered here. Instead we ll take a look at the MPLS related information gathered by the discovery process. As the discovery engine proceeds in it s pursue to find more detailed information about network elements it will, if configured to, try to make use of element configurations to extract valuable information. One such domain is MPLS related data. The discovery engine will parse configurations and search for configuration statements related to (but not limited to): MPLS BGP Core Setup MPLS 2547 o VRFs o Interfaces configured in VRFs o Route Target Imports and Exports o Route Distinguishers o Routing protocols configured in VRFs BGP OSPF IS- IS RIP EIGRP o Static routes configured in VRFs Route Maps MPLS L2VPN VSIs Interfaces configured to reside within VSIs All this information is initially stored raw in the network mirror, just as the physical information was stored.

11 11 If we include some of the information from our fictive network it might look something like this: Some elements are omitted for better overview. Level- two discovery Level one discovery uses different techniques such as SNMP and configuration parsing to create a central, mirror like, repository of the network. Some information, however, makes more sense to derive from the network mirror once a discovery cycle is complete. Such information include derived physical topology, VPN topology and VLAN broadcast domains. The NCM is equipped with an expandable level two discovery engine capable of all this. In terms of MPLS, business rules can be applied (using Systems Orchestrator) that connect physical ports and sort out which VRFs that are connected through route- target import and export statements. As much of this is defined in Systems Orchestrator it can easily be modified to fit local requirements. When we perform a level two discovery on our network all interconnected ports are associated in the network mirror. We also sort out two VPNs, Cust1 and Cust2 and interconnect their VRFs all based on import and export statements. All this information is very valuable in later service discovery operations.

12 12 Reconciliation into NRM NRM is the core network repository in the Visionael Suite. Compared to the network mirror, which only mirrors the network as- is, NRM contains all the meta date required to successfully manage and operate a service provider network, such as resource claims, historic and planned work, physical equipment not discoverable (such as sites etc) and much more. NRM carries out its own reconciliation from the network mirror to keep its data up to date. Rules can be applied to the reconciliation process to notify staff members if certain changes have occurred etc. If we don t pre- populate NRM at all with any aspects of our fictive network routers, switches and DSLAMs would be reconciled into NRM by its reconciliation process from the network mirror. We must, however, provide some meta data to support later operations. We place our DSLAMs in sites and organize our equipment in racks. Resource Management A central product in the Visionael Suite is the RO. It contains all definitions and logic for how different resources may be consumed, used and discontinued in the network. It supports other applications such as SM and NRM with life cycle operations that may be invoked to allocate query or discontinue resources. RO does typically not maintain the actual resources itself, but rather meta- data defining their characteristics and allocation logic. Most of the resources are actually tracked and maintained in NRM or any other network repository. RO is closely coupled with SO allowing the professional services organization or end customers to define how life cycle operations are to be carried out according to local policies and with local network repositories. Even though RO has support for basic network resources out of the box any customer could re- define the allocation logic to fit their needs. When RO has been customized to support all resources required by network management systems and service provisioning systems it becomes a central part in maintaining a good integrity of resources in the network.

13 13 To create resource definitions that match our fictive network we would end up with something like this: Resource Type Definition Repository Logical Termination Point PE Subinterface NRM Physical Termination Point ADSL Port NRM Physical Termination Point VDSL Port NRM Logical Path Access VLAN NRM Logical Address Space VPN IP Address Local or NRM Logical Address Space Route Target Local or NRM Logical Address Space VRF Local or NRM Physical Device ADSL Router NRM Physical Device VDSL Router NRM It is important to understand that RO does not contain business rules for these resources, merely life cycle operations on a technical level. Business rules in provisioning processes such as when to use VDSL and when to use ADSL is within Service Managers scope and part of its product- and service definitions. The resources defined in the table above are not part of any particular service yet; they are just, as pointed out, logical and physical resources with life cycle operations attached to them. This means that resources may be used in multiple services in SM at a later stage. It also means that several stake holders, both Visionael products and third- party systems may consume these resources. Most of these resources would be defined with typical life cycle operations such as create, allocate next, discontinue etc. Some of the resources that go under a global network scope may not need input values for the resource workflow to do its job, while others, such as the DSL ports would require the desired site in which the customer is to be terminated to be supplied to be able to allocate ports in the right DSLAMs.

14 14 Product & Service Catalogs Visionael s philosophy on deploying a good service delivery platform is that it must constitute a good reflection of the actual offerings to the market. When a service provider offers for example MPLS L3 VPNs to the market the end- customer will not care whether his VRFs uses route target 1:1 or 1:2, what he cares about is whether his New York office can communicate with his San Francisco office. Applying the Visionael philosophy means that underlying technical details not important for the customer should not pollute the order entry of the service delivery platform either. Service delivery departments must be equipped with tools that abstract technical details and present them with options and operations that match the business aspect of the products. This reduces the requirement on technical skill on the staff, it provides a better platform for product managers and business analysts to work in, and it reduces delivery times significantly. A good service delivery platform should allow for detailed business rules that constrain and streamline actions and operations minimizing faults and wrongful provisioning. SM allows the service provider to define a combination of entity catalogs (products, services and resources) and uses a business rule engine to model and provision high level services. Advanced business processes that incorporate human interactions and third- party systems can also be defined by incorporating custom workflows using Systems Orchestrator. Even though SM is totally generic in nature it comes bundled with out- of- the- box entities to support many standard Enterprise and Service Provider services, such as DSL services, MPLS services, QoS etc. In SM a resource is a physical or logical entity, such as a port or and IP address, that can be consumed and used by services and/or products. A service is a superset of resources and other services defined with specific life cycle operations and business rules. A service constitutes a technical representation of desired states and life cycle operations that can be carried out using different resources in the network. A product is a superset of resources, services and other products with specific life cycle operations and business rules. A product constitutes a commercial representation of desired states and life cycle operations. A product is meant to match product representations on the BSS side. Catalog Specification Request Item Request Catalog Entity Product Specification Product OrderItem Product Order Product Service Specification Action RuleSet Outcome OutcomeItem Service OrderItem Resource OrderItem Service Order Resource Order Service Resource Resource Peer Resource Specification Context Specification Context Attribute Specification Attribute

15 15 A catalog entity provides, by its definition, a contract that may be incorporated in other entities. As such, it is in itself, agnostic to whether it is part of entities higher up in the hierarchy and may therefore be re- used to architect new products and services as long as its contract fits the business requirements. The typical work order is that resources (i.e. physical and logical network entities) that can be used to create services and products are defined in RO or any other third- party system with resource allocation capabilities. An example of this would be defining an IP Address resource once and reuse the same resource in many services and products. Resource-, Service- and Product Definitions It is important to realize that resource definitions in SM do not constitute any technical resource allocation logic they simply constitute references to other sources that maintain resources, such as RM or a third- party system. The resource definitions in SM also contain commercial business logic, such as when to use VDSL and when to use ADSL based on different business metrics.

16 16 Based on the resources defined previously in RM we can start our modeling in SM. In this case we want to define a DSL product over which we can deliver both Internet access and/or MPLS L3 VPN access. We start by defining an umbrella product called DSL Product. This constitutes a base product that we will offer to the market. Based on the network we have built and the resources we have defined we want the DSL Product to deliver a DSL access that based on desired bandwidth automatically chooses (in case of external invocation) or recommends (in case of internal invocation) the appropriate DSL platform (for both the DSLAM and CPE) for deployment. If the desired options do not exclude any technology option, the service catalog should prefer the option with the highest margin, which in this case is ADSL. We also create a product called L3 VPN and two services on the DSL Product Internet access and L3 VPN Connection. The L3 VPN Connection is also a subservice of the L3 VPN. We model it this way because multiple DSL subscriptions will want to have VPN access to different common VPNs. We also want to deliver a CPE as part of the DSL Product. The VDSL and ADSL options require different CPE devices. We have decided to simply call them VDSL CPE and ADSL CPE. The Internet or L3 VPN add- on- service could extend or override these options to identify further requirements on the CPE side by the add- on- product, but in this case that is not necessary. DSL Product L3VPN DSLAM Port CPE RT Virtual Router VDSL VDSL ADSL ADSL Internet VPN Connection IP ADDRESS Access Path Logical Termination Point IP ADDRESS Access Path Logical Termination Point VLAN L3 Interface VLAN L3 Interface The task of ordering the last-mile connection from a third-party is not the scope of this example, but would be feasible to achieve through RO and SO.

17 17 Service Provisioning Actions and business rules Products, services and resources are modeled in hierarchies in SM by combining re- usable catalog entities. The model however, only constitutes a base line for how the catalog entity may take form, not specific business rules, or actions that define the life cycle operations of the entity. The model must therefore be augmented with business rules, such as when to use a certain technology before another, and which combinations of services that are valid. Business rules are expressed in a rule expression language that is easy to comprehend. Products may even define their own rule language semantics allowing product managers to easily go in and change business rules on their products. OSS Engineer PSO Partner Product Specification Semantics Business Rules Business Analyst Product Owner Products (Subscriptions)

18 18 To match our network equipment we create actions and business rules that match the bandwidth options available for VDSL and ADSL respectively. We also define priorities so that an ambigous uplink/downlink bandwidth combination would yeild ADSL as the preferred platform. We add actions so that the Internet service and the L3 VPN service can be added and removed. We also create business rules stating that a DSL Product subscription only can have one Internet connection but multiple L3 VPN Connections. Order decomposition SM is an order- oriented system. Orders, or requests, are submitted either through the SM graphical interface, or through the SM APIs. Requests may contain multiple request items (operations) that the order should carry out. When an order is submitted to SM the order decomposition engine starts breaking the order down into steps based on the model definitions, business rules and attached workflows. OPEN CLOSDED RUNNING Complete NOT RUNNING CREATE NOT STARTED SUSPENDED AWAITING INPUT ABORTED ABORTED BY CLIENT CREATE AWAITING VALIDATION ABORTED BY PROVIDER

19 19 When we created the DSL Product we gave it options regarding uplink and downlink bandwidth based on our two DSL delivery platforms. When we submit an order on this product, either through the APIs or through the graphical interface, we must provide appropriate values for these attributes. An example order could contain the following attribute values: Attribute Location Uplink Bandwidth Downlink Bandwidth Value Site A 2 20 Based on these attributes the business rules that we have defined will come to the conclusion that ADSL is the only valid platform for these options. Resource allocation will be carried out against RM where an appropriate port according to the provided site will be allocated and populated in the order context. Network activation is also part of the provisioning process but will be describer in more detail later in this document. Before we can add VPN access functionality to our new DSL subscription we have to create the VPN subscription in itself. The VPN subscription does not really represent any deployed configuration in the network itself, but is a common reference point for our DSL subscriptions when they want to communicate over common VPNs. Attribute Name Value Cust1 Even though multiple technical attributes will be attached to the VPN subscription, such as the route target, the name is the only attribute we have defined as mandatory when placing an order to create the VPN subscription. During order decomposition of the VPN order a local reference will be supplied to the RM giving us route targets and a VRF- name (according to a naming schema defined in RM). These resources will furthermore be consumed on the RM side. In this case the RT is 1:1 and the VRF name is Cust1.

20 20 When our DSL Product subscription is deployed in the network we may examine it in SM and trigger any defined maintenance actions. We may also initiate orders on any service defined on the product. Since our customer has a VPN product now we may place an order on the product for our VPN service. Attribute VPN (product reference) Value Cust1 We could also place an order on the VPN product, in that case we would provide the DSL subscription as the sole order attribute. Attribute DSL Subscription (product reference) Custom order entry and entity views Value Cust1 DSL Any action on a product, service or resource will provide a default order entry generated based on input parameters. For basic actions this is often sufficient, however, for more advanced actions it is often natural to provide a custom order entry. Obviously one could always create a standalone order entry platform invoking the SM APIs, but that adds a lot of overhead when maintaining and changing the product, as the order entry has to be tested and maintained on the side. Another option is to use a built- in widget and visualization component in SM called VSML. VSML is a new, unique way to address frontend customization and integration. While many OSS solutions have their integration and customization focus almost exclusively on backend aspects of these areas, VSML was created to allow customers and the Visionael PSO to, in a predefined way, make customization and adjust the frontend experience to fit any context it will reside in. VSML also defines a robust boundary between the SM applications and carried out frontend customization allowing third parties to adapt the application without risking the upgrade path of the suite. VSML was created to mainly serve the following purposes: Allow customers to customize and adjust the visualization and information layout of their products and subscriptions Allow customers to customize and adjust forms and the visual aspects of the management capabilities of products and subscriptions

21 21 Allow customers to populate their frontend with third party information without complex backend integration and without compromising the upgrade path of SM Supply a rich set of generic and more specific visual components that is used both internally and by customers to define the frontend experience in many contexts Allow customers decide whether to include or exclude certain technologies, such as Java Applets, Flash and advanced JavaScript applications Supply good means to customize a customer portal The VSML concept mainly consists of two things, a tag library, and contextual data containers. VSML also comes in a set of different flavors, with different degrees of complexity, but also with the same different degree of flexibility. For the most advanced flavor of VSML, remote invocation, there is also a complete data navigation API available, on top of the contextual data that fetches data from SM remote. Depending on where the VSML is uses and inserted different contextual data is available. The product catalog management pages with VSML various product and subscription related data is available in the contextual data holder. An example of a VSML tag expressing a hyperbolic tree representation

22 22 Transaction and exception management The entity definitions in SM contain cascading exception handling allowing the user to define how to take action if a provisioning process is aborted or if en error occurs. Import aspects of this include returning allocated resources to RM, removing partial configuration in network elements and notifying parties such as delivery staff and the customer. Service Discovery and Correlation A very important aspect to maintain a good revenue assurance process is to keep a tight correlation of resources in the network and the customers utilizing them. In service provider environments where a provisioning system hasn t had the full responsibility for activating services or when there is a mixture between manual and automatic activation of services it becomes very important to constantly make sure that allocated resources in the network are accounted for and that there is a revenue stream associated with it. Depending on the specific circumstances SM can be used in combination with SO to set up custom workflows that use NRM and the network mirror to discover resources those are not accounted for. The workflows in SO may even be setup to query BSS systems such as a CRM system to verify that everything is in order. Network Activation Network activation is a complex task, especially when incorporated in advanced long- running provisioning processes involving local and external resources that require secure and robust distributed transactions against the network. The Activation Manager provides a modern approach to meet these challenges by offering a layered API availing both a generic model- to- action engine as well as more traditional activation based on autonomous actions. As such the activation engine is designed to provide activation capabilities to upstream stakeholders, such as OSS systems with diverse service catalogs, while still being able to support more static operations originating from network management platforms with less knowledge on how the activation is carried out. In both cases a template engine can be used to convert normalized configuration, i.e. a model, to configuration statements that are vendor specific. A conceptual overview of the activation framework can be seen in the diagram below.

23 23 Figure X Conceptual overview of the Activation Manager Model based activation Model based activation is the more advanced flavors of network activation and provides a more flexible way of supplying the activation engine with the desired changes to be carried out to a network. Instead of invoking specific actions a model containing a normalized representation of the network configuration is supplied. The model may contain multiple transactions with multiple operations distributed over multiple network elements. The model schema is a derivate of the network mirror schema, which makes it easy for clients to work with models when working both with the activation engine and the network mirror as they share the same data structure. Model based activation makes it easier for clients to build up larger transactions and allows them to maintain more control over sequencing, however it also requires a higher level of intelligence on the client side.

24 24 In the figure below you see an example of how an activation model from SM could look like. The nodes in the model tree represent normalized configuration statements and values. The nodes have metadata attributes such as create, merge or delete and sequence information telling the activation engine in which order the model entities should be handled. The metadata layer also contains information on when it s desired to perform the activation in the network elements. When a model is processed in the activation engine it uses a combination of a local lookup processing mechanism and an ESB driven lookup mechanism to generate the actual configuration. The local lookup mechanism matches nodes in the model to locally defined rules, policies and templates to generate appropriate vendor specific configuration whereas the ESB driven lookup mechanism uses an external source to supply it with protocol information (such as telnet or ssh), means of activation (such as CLI, SNMP or Netconf) and required authentication information (logins and passwords). The latter information may come from the client providing the model to activate, or a network inventory. Model based activation is especially suitable when clients make use of complex catalogs of services resulting in very diverse and irregular activation patterns. Action based activation Action based activation is easier to define and provides a more straightforward way of defining autonomous actions that allow clients to simply invoke actions in the activation engine with a predefined configuration model supplied. These actions define subsets of the overall model schema and are therefore much more strict in terms of what they perform. Actions may also contain rules and policies that are more granular than those usually invoked during model based activation. Action based activation puts less

25 25 requirements on the clients, as they do not need to supply sequence information and less general metadata in general. In figure X a conceptual overview is illustrated on how a simple action model schema could look like. This action takes a small model used to activate an MPLS based VRF. Different rules and policies are tied to the different actions and, in case of legacy activation based on CLI, vendor specific configuration templates are attached. The actions may contain rules and policies that consider metadata such as network element software version etc. Asynchronous activation As activation is often performed during service windows or during nighttime, communication with the activation engine over the ESB is in most cases asynchronous, meaning that clients cannot expect an immediate feedback on results of the activation other than that the supplied message passes initial feasibility checks. Clients send messages containing models and actions, which are processed by the activation engine and then queued appropriately based on various rules. If clients depend on the feedback of the activation, which is true in most cases, they have to subscribe to feedback channels over the ESB and be able to handle such incoming messages. If a client application is not capable of asynchronous communication a Systems Orchestrator flow can be used to bridge the communication between the applications. Network communication The activation engine may make use of different communication protocols and activation techniques to push configuration to the network. As both action and model based activation is vendor agnostic in general the same action or the breakdown of a single model may result in different outcomes in regards to how to push the configuration to the network. The activation engine uses its lookup mechanisms over the ESB to query network inventories to determine which technique to make use of. Rules on the specific actions may also affect the decision. In general Netconf statements or CLI commands are sent over a secure SSH channel. The activation engine acquires authentication information on a need- to- know- basis, and may make use of credentials

26 26 associated with the end user of the actual provisioning solution providing the activation order. This makes it possible to trace back changes in the network to a certain user easier, even though the changes were pushed by the activation engine. Template engine and vendor specific configuration statements Configuration templates in the activation engine are stored in the Visionael File Repository (or any other repository). As such they are revisioned and all historical changes can be tracked. The templates are constituted by text blocks with key values and attributes replaced with references to values in an expected configuration model. This allows the author of the template to combine static syntax with resources and values that are allocated, generated or retrieved in any other way as part of a provisioning process, such as a data submission from a customer. As the configuration model utilizes namespaces to organize data ownership the author of a template can refer to values in a local private namespace, allowing him to pass on information in the provisioning process that may not be part of the default schema. This can for example be certain customer related information that is used in a description field etc. interface ${config["config/vis:logicalinterface/vis:name"]} ip address ${config["config/vis:logicalinterface/vis:ip"]} netmask encapsulation dot1q vlan- id ${config["config/vis:logicalinterface/vis:vlan"]} description This is an interface configured by Visionael Activation Engine version ${version} example template of a sub-interface prepared for a Cisco IOS router. end An Transaction management and rollbacks The activation engine contract is to supply overlying applications with a decoupled black box for secure network activation. This means that it is the responsibility of the activation engine to handle errors or exceptions that may occur during activation and simply update the client with whether activation was successful, and if not, why (to the extent it understands). The activation engine achieves this by a combination of rollback rules on the actions and transaction management. Resources that are part of the pushed configuration may already be used in a network element, or devices may not be communicable at all. If the activation engine is unable to complete a transaction it must return, if possible, all network elements within the transaction to the initial state. The technique to achieve this is vendor and protocol specific and may be different for different actions and vendors. In rare cases where rollbacks are not possible, either by the support of the device or by the use of configuration statements the activation engine will report the current state back to the stake holder and will fire alarms to alert engineers to examine the state manually.

27 27 Transactions may also be used in a controlled fashion to achieve transactional support on a higher level, such in an overlying provisioning solution. The client may ask the activation engine to rollback certain transactions if, for example, a customer order was canceled. Transactions can also be used to perform live feasibility checks or tests in the network. Standard configuration templates Standard configuration files can be stored in the file repository much like templates. This makes it easy to bootstrap new network elements and ensure that they receive standard configuration statements related to security such as access lists and firewall policies. The configurations can contain replaceable values making the standard configurations dynamic. Using the file area with boot- configurations It is common to prepare configurations and deploy them in an exposed file (via for example tftp) area for later retrieval by network elements. A common setup is that configurations are prepared as part of an organizational workflow even before the network element is physically connected to the network. By using DHCP option 82 the network element can retrieve a designated IP that in turn determines which configuration it can fetch in the file area. By using this technique a central configuration store can be used to ensure that CPE configurations always confirm to the central setup, even if replacement hardware is distributed. Service Feasibility and Service Assurance An import aspect of a high quality service delivery chain is having a good service feasibility check mechanism. SM provides this by allowing its users to invoke feasibility checks on products to get immediate feedback on whether delivery is possible for a certain set of attributes (such as location or desired bandwidth) or what the delivery time would be on a certain service based on planned roll- outs. Another, equally important aspect, is service assurance, i.e. the ability to verify that provisioned and activated services meet quality criteria. This is especially important for services such as QoS where the customer may not detect configuration that contains errors immediately as oppose to if his port wasn t activated at all.

28 28 In SM products and services can be extended with service assurance actions that can be invoked at the end of a successful provisioning process, on a regular basis, or just by the service provider staff upon request from a customer. Service assurance actions can invoke workflows that analyze network data in the network mirror and take actions upon its contents.

29 29 APPENDIX A. Service Examples This document describes a fairly straightforward setup, however to illustrate the strength of the Visional Suite this appendix contains examples of more complex services that have been modeled and provisioned successfully. L2 Point- to- Point MPLS Access Configuration samples: EPL1: interface GigabitEthernet2/0/7 service instance 1 ethernet encapsulation default xconnect encapsulation mpls EVPL1 AGG.1: interface GigabitEthernet2/0/7 service instance 100 ethernet encapsulation dot1q 102 second-dot1q rewrite ingress tag pop 1 symmetric

30 30 xconnect encapsulation mpls AGG.3: interface GigabitEthernet2/0/7 service instance 100 ethernet encapsulation dot1q 103 second-dot1q rewrite ingress tag pop 1 symmetric xconnect encapsulation mpls EVPL2: AGG.2: interface GigabitEthernet2/0/7 service instance 102 ethernet encapsulation dot1q 60-70,80-90,100 xconnect encapsulation mpls DIST.2: interface GigabitEthernet2/0/7 service instance 102 ethernet encapsulation dot1q 101 second-dot1q 60-70,80-90,100 xconnect encapsulation mpls EVPL3: DIST.2: interface GigabitEthernet2/0/7 service instance 103 ethernet encapsulation dot1q 200 second-dot1q 200 xconnect encapsulation mpls AGG.2: interface GigabitEthernet2/0/7 service instance 103 ethernet

31 31 encapsulation dot1q 200 rewrite ingress tag push dot1q 200 symmetric xconnect encapsulation mpls EVPL4: DIST.2 interface GigabitEthernet2/0/7 service instance 104 ethernet encapsulation dot1q 220 rewrite ingress tag translate 1-to-1 dot1q 222 symmetric xconnect encapsulation mpls AGG.3 interface GigabitEthernet2/0/7 service instance 104 ethernet encapsulation dot1q 222 xconnect encapsulation mpls L2 Local switching

32 32 Configuration samples: EVPL5: interface GigabitEthernet2/0/11 service instance 1 ethernet encapsulation dot1q 300 interface GigabitEthernet2/0/12 service instance 1 ethernet encapsulation dot1q 300 second-dot1q 301 rewrite ingress tag pop 1 symmetric connect EVPL5 GigabitEthernet2/0/11 1 GigabitEthernet2/0/12 1 EVPL6: nterface GigabitEthernet2/0/12 service instance 2 ethernet encapsulation dot1q 400 second-dot1q rewrite ingress tag pop 1 symmetric interface GigabitEthernet2/0/11 service instance 2 ethernet encapsulation dot1q 401 second-dot1q rewrite ingress tag pop 1 symmetric connect EVPL6 GigabitEthernet2/0/11 2 GigabitEthernet2/0/12 2 EVPL7: interface GigabitEthernet2/0/11 service instance 3 ethernet

33 33 encapsulation dot1q 440 second-dot1q 400 rewrite ingress tag pop 1 symmetric interface GigabitEthernet2/0/12 service instance 3 ethernet encapsulation dot1q 400 second-dot1q 400 rewrite ingress tag pop 1 symmetric connect EVPL7 GigabitEthernet2/0/11 3 GigabitEthernet2/0/12 3 EVPL8: interface GigabitEthernet2/0/11 service instance 4 ethernet encapsulation dot1q 501 rewrite ingress tag pop 1 symmetric interface GigabitEthernet2/0/12 service instance 4 ethernet encapsulation dot1q 502 rewrite ingress tag pop 1 symmetric connect EVPL8 GigabitEthernet2/0/11 4 GigabitEthernet2/0/12 4

34 34 L2 Point- to- Point L2 Access L2 E- Tree service Configuration samples: AGG.3: interface GigabitEthernet2/0/15 service instance 11 ethernet encapsulation dot1q 70 bridge-domain 111 split-horizon interface GigabitEthernet2/0/16 service instance 11 ethernet encapsulation dot1q 70

35 35 bridge-domain 111 split-horizon interface GigabitEthernet2/0/17 service instance 11 ethernet encapsulation dot1q 70 bridge-domain 111 split-horizon interface Vlan111 no ip address xconnect encapsulation mpls DIST.2: interface GigabitEthernet2/0/2 service instance 30 ethernet encapsulation dot1q 118 second-dot1q 70 rewrite ingress tag pop 1 symmetric xconnect encapsulation mpls E- LAN Hierarchical- VPLS Configuration samples:

36 36 For BGP auto-discovery N-PE should be pre-configured with the following: router bgp 1 no bgp default ipv4-unicast bgp log-neighbor-changes address-family l2vpn vpls neighbor x.x.x.x activate neighbor x.x.x.x send-community extended neighbor x.x.x.x activate neighbor x.x.x.x send-community extended exit-address-family l2 router-id (loopback address) DIST.1: l2 vfi VPLS-Domain1 autodiscovery vpn id 1 neighbor encapsulation mpls no-split-horizon interface Vlan2000 no ip address xconnect vfi VPLS-Domain1 DIST.2: l2 vfi VPLS-Domain1 autodiscovery vpn id 1 neighbor encapsulation mpls no-split-horizon interface Vlan2000 no ip address xconnect vfi VPLS-Domain1

37 37 DIST.3: l2 vfi VPLS-Domain1 autodiscovery vpn id 1 neighbor encapsulation mpls no-split-horizon interface Vlan2000 no ip address xconnect vfi VPLS-Domain1 DIST.4: l2 vfi VPLS-Domain1 autodiscovery vpn id 1 neighbor encapsulation mpls no-split-horizon interface Vlan2000 no ip address xconnect vfi VPLS-Domain1 AGG.1: interface GigabitEthernet2/0/2 service instance 200 ethernet encapsulation dot1q 1000 rewrite ingress tag pop 1 symmetric xconnect encapsulation mpls AGG.2: interface GigabitEthernet2/0/2 service instance 200 ethernet encapsulation dot1q 1001 rewrite ingress tag pop 1 symmetric xconnect encapsulation mpls