|
Service Activation Using Metro Ethernet Forum Written by Jack Pugaczewski Abstract Ethernet has been prevalent in the local area network for years. Recently, Ethernet is being provided by carriers within the wide area network. It is now possible for a customer service, such as a VPN, mobile backhaul or a VoIP service, to traverse the network end-to-end using Ethernet. A major challenge for a carrier in providing metro Ethernet service is design, development and on going support of the activation system. The challenge is complicated as the underlying network technology and/or vendors change. The following paper will examine how to leverage the work done by the Metro Ethernet Forum (MEF) along with general software engineering principles to develop and design metro Ethernet services. The implementation of a well designed service activation solution will greatly reduce the operational costs associated with providing MEF-based services. In addition the carrier will be less impacted by technology and vendor changes in the underlying network as well as have the ability to provide potential revenue generating solutions that require automated activation. The TMN (Telecommunication Management Network) is used as a reference for the software layering and abstraction in the service activation design. Introduction One of the first decisions a carrier must make in the development of a service activation system is whether to build or leverage the vendor’s element management system. Two philosophies are typically at odds when discussing service activation. The first position is to remove all element management systems and functionality and directly communicate with the devices with in-house solutions. The second philosophy incorporates an abstracted and layered approach and leverages vendor’s element management systems which have abstracted the direct communications to devices with an API and/or SDK. The problem with carriers taking on the role of element management system development is two fold. First, the carrier continually is modifying code due to vendor changes in the CLI and/or SNMP access to the device. Second, the carrier is slowed bringing a solution to market because they are spending cycles on the development of multiple element management systems for each device type. By placing the responsibility on the vendor it will be possible for SNMP, CLI and technology changes to track with the element management system APIs. In either case it is recommended that a common architecture and design approach be used across all devices and vendors. If properly implemented the carrier can leverage vendor’s element management systems and focus on integration and service development. The Telecommunication Management Network (TMN) model defines a set of abstraction layers. The concepts defined in this paper leverage the TMN layered abstractions in the development of MEF-based services. The author will argue that it is in the best interest of the carrier to leverage the vendor’s API and reduce the additional upfront and on going cost associated with maintain an in-house element management system. In most cases, each vendor uses their own network object constructs (i.e., CLI structure and commands) for configuring Ethernet-based services. In some cases, differences exist between different devices within the same vendor’s product line. Generally, when a vendor provides an element management system the API (Application Programming Interface) is tightly coupled to the device constructs. The carrier needs to avoid building a set of individual device activation solutions. The remainder of this paper will examine how the specification work done by the Metro Ethernet Forum (MEF) can be used to develop an automated, abstracted, scalable MEF-based service activation solution. The author will argue that it is in the carrier’s best interest to leverage a vendor’s element management system as opposed to being in the element management system business. The carrier can only be successful in this endeavor if they provide clear and concise requirements on the vendors to leverage the specifications that have been provided by the MEF. The following section breaks down the network layering beginning with the service layer and scoping down to the element layer. The Metro Ethernet Forum (MEF) has provided the industry with a number of specifications which define a framework for the design and development of automated service activation systems. MEF defines a service as two or more UNIs (User Network Interface) and an EVC (Ethernet Virtual Connection) that traverse a Metro Ethernet Network (MEN). The UNI is a physical interface/demarcation between the service provider/carrier and subscriber. An EVC is a logical representation of an Ethernet service as defined by the association between two or more UNIs. An EVC can be Point-to-Point (E-Line), Multipoint-to-Multipoint (E-LAN) or Rooted-Multipoint (E-Tree). Included in these specifications are the Service Attributes for UNI and EVC. Using these standard definitions -- along with object-oriented analysis, design and development -- it is possible to define technology-specific, vendor-independent service provisioning solutions for MEF service that traverse a multi-vendor network. The MEN is not defined by any MEF standard or other standard. Various technologies are used to provide MEN functionality. An example network includes a combination of VPLS/H-VPLS, 802.1ad (Q-in-Q) VLANs. Abstraction and layering provides the ability to provide scoped and filtered views or representations of the network. The example below illustrates the scoped and filtered view of a MEF service and how it is decomposed into flow domains and eventually into the devices supporting the network.
Figure 1 – MEF Abstraction and Layering Using a philosophy of building the element management system in-house would require the carrier to make substantial software changes if any of the devices are changed to another vendor and/or the network technology changed. The reason is that when the vendor and/or technology changes, then so does the set of commands or SNMP messaging required to provision the metro Ethernet service. General software engineering principles of layering and abstraction are necessary to gain benefit of future reduced development cycles. Specifically, by implementing a software and architecture layering and abstraction it is possible to reduce the overall exposure to changes in the underlying network. The layering and abstraction is implemented using a clear and concise set of interfaces. The process of a MEF-based service activation begins with a service order received by the Business Management Layer Configuration Management (BML-CM) system. The BML-CM will perform processing such as billing activation and customer record checking. The BML-CM could be a customer portal which allows the customer to generate a service activation or change. The BML-CM will pass the service activation request to the Service Management Layer Configuration Management (SML-CM) system which is responsible for functionality such as tracking and maintaining the portfolio of services each customer requests. The SML-CM will take the MEF-based service activation/change request after processing and send it to the Network Management Layer Configuration Management (NML-CM) system. The NML-CM is responsible for coordinating the communication to sub-network Element Management Layer-Configuration Management (EML-CM) systems to meet the network connectivity request. Each EML-CM is responsible for communicating to elements within their respective sub-domains to meet the sub-network connectivity request. If any component of the request is not success, rollback operations must be performed and failure codes returned to clients making the request. The EML-CM is responsible for handling and processing MEF-based service requests. The EML-CM is responsible for abstracting the NML-CM away from the mechanisms used to process requests. Therefore, the EML-CM is responsible for handling the device mediation. The device mediation typically will process API requests, coordinate and communicate with devices using but not limited to CLI (Command Line Interface) commands, SNMP SETs/GETs and TFTP. Imperative in the EML-CM design is the abstraction from low-level communication changes in SNMP MIB and CLI commands. See Figure 2 below.
Figure 2 – TMN layering of MEF-based Service Activation Carriers will build a Metro Ethernet Network using one or more technologies from multiple device manufacturers. Ideally a MEF-based service could be activated end-to-end with a single request (i.e., SNMP Set, CLI command) which would simplify the activation process and the associated software which needs to be developed. Unfortunately this is typically not the case. It is often necessary for the carrier’s OSSs (Operating Support Systems) to orchestrate and communicate a combination of requests to one or more elements and/or element management systems. The orchestration of these requests may be greatly simplified and better understood by leveraging the MEF defined set of service attributes. Included in a multi-vendor implementation is a requirement to provision services using vendor-specific configuration commands, SNMP commands, and/or API calls. In an attempt to normalize and simplify the provisioning process -- and ultimately to automate the process -- the mapping of MEF UNI and EVC Service Attributes to vendor-specific commands is needed. The process used in the document is to perform a mapping of MEF Service Attributes to each vendor’s low-level command set required to satisfy the configuration. In some cases the low-level configuration will be dependent upon the line card model or the software version. The diagram below illustrates the design of a system for mapping carrier-specific definitions/naming to MEF-defined services. The MEF services are then mapped through each vendor’s supported APIs within the vendor’s element management system. In the event that the vendor does not provide an element management system, an adaptation layer that maps the MEF-service contructs into device CLI commands (or SNMP) is required. The MEF-to-Vendor Mapper is a logical representation of how the service logic must (1) accept a MEF service request via a defined interface, (2) process the underlying network flow domain logic, and (3) send the appropriate activation commands to the set of supported devices. The MEF-to-Vendor Mapper could either be the vendor’s element management system or a system developed in-house. In either case, the underlying software logic should implement the described functionality.
Figure 3 – Mapping Flows These carrier service definitions will have UNI and EVC Service Attributes which are passed to the Carrier-to-MEF Mapper logic. The Carrier-to-MEF Mapper is a carrier Network Management Layer Configuration Management (NML-CM) system which takes a service request from a Service Management Layer Configuration Management (SML-CM) system. The NML-CM system is responsible for taking the MEF service request and determining how to begin the stitching of the service request across the multi-vendor/multi-technology underlying network. The MEF does not specify which underlying technologies should be used to compose the MEN. The software architecture and design discussed in this paper maps the MEF service attributes into a technology-specific implementation of a MEN. Currently, the typical technologies that MEN leverages include, but are not limited to, VPLS and Q-in-Q VLANs. A MEF service is supported with a network of one or more of these underlying technologies or flow domains. The EVC is segmented into multiple flow domains. Multiple flow domains are separated by I/E-NNIs. Flow domains on the edge serve one or more UNIs. The NML-CM system communicates MEF-based service requests to the respective EML-CM systems. The NML-CM is responsible for having the topology awareness of I/E-NNIs. The I/ENNIs provide a clear and concise demarcation between flow domains. The segmented service activation process is coordinated by the NML-CM with segmented MEF-based service requests to each sub-domain controller (EML-CM). The service activation of MEF-based services across a single and/or multi-vendor network can be optimized with a MEF API. The purpose of the API is to abstract the low level constructs used to activate and provision individual devices. A potential set (not necessarily complete) of API objects and methods that are required to support MEF-based service activation and modification using adds/moves/changes are defined below. Each of the TMN layers will have specific additional attributes depending on the layer. For example, the createMefService method at the SML-CM will have customer information attributes which is not necessarily required by the NML-CM. Using this type of architecture allows the underlying CLI/SNMP command/objects to change without impacting the flow domains and MEF API calls. The figure below illustrates an example of how the MEF service is provisioned across a network which supports multiple flow domains and multiple vendor devices.
Figure 4 – Layer Logical MEF-to-Device Network
The respective MEF service requests are sent over the MEF API to the respective EML-CMs. The EML-CM are responsible for sending the appropriate CLI and/or SNMP commands to the devices within their domain of control to provision the EVC segment components. The set of activation requests sent to the respective EML-CMs should be constructed and handled as a single atomic transaction. Therefore, a complete successful activation requires that all individual requests are successfully executed. In addition, the failure of one or more of the individual EML-CM requests must result in a rollback of all of the requests. Once a service has been activated it is likely that in the future, the customer will require an addition, modification or move of a UNI or EVC. Imperative in these activation operations is the ability to verify the existing service prior to making any changes, which implies an ability to discover existing services or derive the service topology down to the device level. Each vendor’s element management system should provide an API which allows clients to derive a service path by inputting attributes -- such as service identifier -- which were created during the activation phase. Developing such APIs in-house by the carrier is expensive and time-consuming. An example of when a service discovery is required is the addition of a new UNI to an existing service. It is ill advised to simply send down an activation request prior to verifying the existing service. This is even more important in an E-LAN service where an incorrect activation may result in connecting two customer services together. There are numerous situations where there is a need to discover an existing service. While segments of the service will be persistently stored, the most accurate view of how a service is actually configured will be obtained by querying the network. A service discovery system is required to be able to function with multiple systems or information sources that are specific to the discovery and derivation of a service. The use of service discovery extends beyond service activation verification. Service discovery is used for fault isolation, performance monitoring, and general operational maintenance. Service discovery is initiated with a given set of parameter inputs. An example service discovery may be initiated given an EVC and UNI as input. The following use case traces a service request with an EVC unique identifier and UNI as input (see Figure 4 below). The response should be a topology path object which contains the EVC object and associated UNI object array. In addition, each UNI must have an association to a corresponding Customer object. The return response for a valid request is either a “Point-to-Point EVC Trace” or a “Multipoint-to-Multipoint EVC Trace”.
Figure 5 – Multipoint-to-Multipoint MEF Service Trace: Input = Unique EVC ID
The topology service will likely be required to communicate with multiple sources of topology resources. Topology is not a single-source solution, especially in a multi-technology/multi-vendor implementation. Figure 5 below shows an example UML representation of a topology service that communicates with multiple topology managers. The TopologyServiceController object is responsible for the coordination and communications with the multiple sources of topology information.
The UML design implements a TopologyService object which supports the methods for various types of service and network path traces. A client of the TopologyService object can make service and network path derivation requests without communicating directly with the network devices. The result of a path trace can be used for verifying a service prior to making a modification, troubleshooting a service, and/or affecting other combined FCAPS functionality. The TopologyService object provides an abstraction by managing a TopologyServiceController object. The TopologyServiceController is responsible for communicating and sending requests to the various sources of topology derivation in supported MEF-based network. The TopologyServiceController will take a TopologyService request, determine what resources (TopologyManagers) it needs to communicate with and then stitch together the path for the result. The TopologyServiceController instantiates and communicates with the BML, SML, NML, EML and device TopologyManagers as necessary to extract and derive the path segments of a service and corresponding network path. The carrier can gain both substantial operational efficiencies and new revenue-generation streams by implementing a service activation solution that leverages MEF constructs. This is especially the case when the MEN is implemented using multiple vendors and technologies. Future work in this area must include service activation, which includes the configuration of Ethernet OAM constructs used for SLA (Service Level Agreement) measurement, collection and validation. In addition, future standards discussions should cover how and why configuration management may be leveraged with other network functional areas, such as fault and performance management, to realize operational tools which support the ongoing troubleshooting and maintenance of MEF-based services. The abstraction and layering discussed in this paper allows the replacement of vendors and/or technologies without requiring wholesale changes at all layers. This significantly reduces development costs, time to market, and time to service activation.
Bibliography [1] Maarten Kockelmans and Eric deJong, “Overview of IN and TMN Harmonization”, IEEE Communications Magazine, March 1995.
Set as favorite
Bookmark
Email This
Hits: 3258 Trackback(0)
Comments
(0)
You must be logged in to a comment. Please register if you do not have an account yet.
|
| Last Updated on Thursday, 20 October 2011 04:39 |
TrackBack URI for this entry
Subscribe to this comment's feed
