• Proposed name for the project: Connectivity Services LSO
• Proposed name for the repository: LSO-api
• Project Categories: Requirements

The objective of this project is to develop, document and validate a new Ethernet Services Lifecycle Service Orchestration (LSO) feature plug-in for OpenDaylight (ODL) and northbound APIs that use the plug-in to expose capabilities of ODL to configure and fulfill MEF-defined Ethernet services in physical and virtual network components through ODL. The project will reference existing data models defined by MEF for Ethernet services and will develop new data model components if needed.

In its initial phase this project will develop service provisioning data models, ODL plug-in for configuring User Network Interface (UNI) functionality in physical or virtual network elements, and northbound APIs for Ethernet Private Line (EPL) service as defined by MEF, as the first use case. Other use cases such as Ethernet Virtual Private Line (EVPL) service and Ethernet LAN (ELAN) service provide opportunity for future extension.

Figure 1 OpenDaylight Helium Architecture with Proposed MEF-Compliant Ethernet Service Feature Plug-in

The EPL Service Provisioning northbound APIs and ODL plug-in will allow applications to create EPL services on physical and virtual devices through existing ODL southbound interfaces.

• EPL Service Management API endpoint (RESTful web service)
  • Reference: Metro Ethernet Forum Technical Specification MEF 6.2 EVC Ethernet Services Definitions – Phase 3
• Ethernet Virtual Connections (EVC) Management API endpoint (RESTful web service)
  • References:
    • Metro Ethernet Forum Technical Specification MEF 10.3 Ethernet Services Attributes Phase 3;
    • Metro Ethernet Forum Technical Specification MEF 6.2 EVC Ethernet Services Definitions – Phase 3
• Class of Service Management API endpoint (RESTful web service)
  • Reference: Metro Ethernet Forum Implementation Agreement MEF 23.1 Carrier Ethernet Class of Service - Phase 2
• User Network Interface (UNI) Management feature plug-in for OpenDaylight
  • Reference: Metro Ethernet Forum Technical Specification MEF 7.2 Carrier Ethernet Management Information Model

The APIs and data models provide an interface for Ethernet services applications – including virtual network functions – to provision Ethernet services by configuring virtual or physical devices and the connections between them using OpenDaylight.

The Ethernet Services Manager, EVC Manager, CoS Manager and UNI Management plug-in are established as foundation services for future Ethernet services use cases. MEF defines a UNI as the physical demarcation point between the responsibility of the Service Provider and the responsibility of the Subscriber. The UNI terminates connections between customer locations and some characteristics of the Ethernet service such as line rate are enforced at the UNI. The UNI must therefore be deployed and configured to support the Ethernet service.

MEF defines an Ethernet Virtual Connection as an association of two or more UNIs that limits the exchange of Service Frames to UNIs in the Ethernet Virtual Connection. The EVC creates the link between UNI and therefore is also necessary for the service.

The proposed APIs have been reviewed and validated by members active in MEF projects related to this work. MEF has several on-going projects updating their service definitions and object models, so it is possible that these APIs will evolve with MEF changes.

The proposed APIs are based on the capabilities of OpenDaylight to create and provision UNIs and EVCs on virtual or physical devices in the network.

Proposed APIs follow the ETSI ISG NFV reference architecture, incorporating the UNI control and management planes into OpenDaylight and exposing MEF service definitions to the Virtualized Infrastructure Manager (VIM) through the Nf-Vi interface as indicated in Figure 2.

The Ethernet Services Management API provides services to Ethernet Services applications so it may interface the applications in the OSS/BSS indirectly via the Os-Ma interface.

Figure 2 MEF Services APIs Relationship to ETSI ISG NFV Reference Architecture

An initial UML representation of the EPL information model based on MEF Technical Specification 7.2 Carrier Ethernet Management Information Model is shown in Figure 3. The project will develop UML and YANG versions of the model and evolve them as MEF specifications evolve. The data model will be used as reference for development of the MEF APIs.

Figure 3 Ethernet Private Line Service Initial Information Model

Currently, VNFs do not have a standard API allowing for the provisioning of Ethernet Private Line services. This project will develop EPL data models and OpenDaylight northbound APIs aligned with MEF to allow VNFs to provide virtualized MEF services.

Features and Functionality to be Developed

• Northbound Open Daylight RESTful APIs:
  • EPL Service Management (Vn-Nf) – calls UNI Service Management and EVC Service Management to create an EPL service between two UNIs.
  • UNI Service Management -configures UNI functionality in virtual or physical network devices.
  • EVC Service Management - creates or destroys an Ethernet Virtual Connection (EVC) between the UNIs.
  • Fault Management - detects and reports faults in the EVC as defined by MEF
  • Performance Management - measures and reports performance of the network as defined by MEF

Ethernet Private Line Service Request: Service Provider Provisioned

An Ethernet Service Provider receives a request from a customer to provide Ethernet Private Line service between the customer’s headquarters office in one geographical location and a branch office in another location. The customer orders service with a particular set of parameters (latency limits, minimum throughput, full duplex).

The service provider enters the geographic locations of the two endpoints and the service parameters (Service Level Agreement, SLA) in an Ethernet Service application that is part of the provider’s BSS/OSS system. The application interfaces with the Virtualized Infrastructure Manager function that checks availability of endpoints to provide the requested connection.

The VIM identifies server hardware available in each customer location and calls the Ethernet Services Manager REST interface with the service request, passing the locations and the SLA parameters. The Ethernet Services Manager calls the EVC Manager to create the connection between the two endpoints, passing the SLA parameters.

The EVC Manager determines that necessary UNI functionality does not currently exist in the endpoint servers so it calls the UNI Manager API with necessary parameters. The UNI Manager calls OpenDaylight northbound APIs to establish UNI functionality in virtual or physical devices then returns status to the EVC Manager.

With the UNI functionality established the EVC Manager calls OpenDaylight northbound APIs to create the connection between the virtual or physical devices then returns status to the Ethernet Services Manager.

CableLabs developed a test harness consisting of a web UI and virtual CPE device, which we will make available to the OPNFV project for development and validation. Other tests will be developed by the project, as necessary. Illustration of one instantiation of the test harness utilizing a laptop PC and Raspberry Pi endpoints is provided in Figure 4.

Figure 4 Portable MEF Services APIs Test Harness

• API documentation
• Data Models (UML and YANG)
• Functional block description

The EPL data model and APIs are based on Ethernet Services Definitions defined in Metro Ethernet Forum specifications (MEF 6.3, 7.2, 10.3). This project will coordinate with MEF and incorporate changes to MEF specifications, if necessary. As OPNFV evolves the APIs within the project, this project will submit the updates to MEF so that the service definitions, data models, and APIs remain consistent between MEF and OPNFV.

This project also needs to align with the ODL Beryllium release (targeted for November). Detailed Beryllium milestones haven’t been released yet.

Since one of the objectives of the project is to enable the instantiation and configuration of UNI functionality and enable connection of UNIs, the management of device/UNI topology is a key capability. OpenDaylight Topology Manager is therefore a dependency for the project.

• Committers
  • Kevin Luehrs, CableLabs K.Luehrs@cablelabs.com
  • Adolfo Perez-Duran, CableLabs A.Perez-Duran@cablelabs.com
• Contributors
  • Kevin Luehrs, CableLabs
  • Adolfo Perez-Duran, CableLabs
  • Mufaddal Makati, CableLabs M.Makati@cablelabs.com
  • <TBD additional contributors>

1. EPL Service Management and UNI Management data models (UML and YANG)
2. Open Daylight northbound RESTful APIs (Nf-Vi):
   1. Ethernet Private Line service Management
   2. Ethernet Virtual Connection Management
   3. User Network Interface Management

The first release of the EPL service management API, UNI management API and data models is targeted for the second OPNFV release and ODL Beryllium.