Wiki

Release 0.2.0

September 3, 2015

Project: Connectivity Services LSO (lsoapi)

Editors: Kevin Luehrs (CableLabs) <more>

Authors: Kevin Luehrs (CableLabs) <more>

Project Creation Date: July 14, 2015

Submission Date: TBD

Abstract: Connectivity Services LSO is an OPNFV Requirements project. The project scope is business services configuration, provisioning and management. The objective is to define open standard APIs exposing capabilities of open source SDN controllers (Controllers) to enable applications to configure and provision Metro Ethernet Forum (MEF)-defined Carrier Ethernet services (and eventually other Connectivity Services) in physical and virtual network components through the Controller. The deliverable will include a clear statement of the problems to be solved, an information model, an architecture description, software design documentation and an initial plan for implementation based on open source components. The project is expected to evolve into a Collaboration Project that will develop open standard APIs included in the OPNFV Brahmaputra release.

The Connectivity Services LSO project is open to any open source SDN controller but an initial proof-of-concept (PoC) implementation using OpenDaylight is contributed to the project as reference and to help initiate the project. The PoC implementation is comprised of the components listed below:

1. Connectivity Services Manager RESTful API
2. Class of Service Manager RESTful API
3. Ethernet Virtual Connection RESTful API
4. UNI Manager feature plug-in for OpenDaylight

<TBD>

1. Carrier Ethernet fulfillment processes are currently too labor intensive and not seamless across vendors.

2. Not all Carrier Ethernet network equipment provides all needed functions, e.g., those defined by ITU Y.1731 *OAM functions and mechanisms for Ethernet based networks*.

3. Carrier Ethernet services deployment and day to day operations are complicated by significant differences in how equipment from different vendors is configured and managed.

4. Currently service providers are unable to deliver Carrier Ethernet services beyond physical locations where Carrier Ethernet equipment is deployed.

5. Service providers are often required to deploy multiple pieces of equipment at customer premises to provide service. This leads to high capital expense, extensive testing effort, management complexity (operational expense), and bookkeeping complexity that may be avoided or reduced if fewer devices could be used to deploy service.

MEF specifications define three Service Types for Carrier Ethernet networks. Each Service Type establishes an Ethernet Virtual Connection (EVC) to transport data between User Network Interfaces (UNI). UNI are defined as the physical demarcation between the service provider's network and the customer's network.

E-Line service is point-to-point service, connecting exactly two UNIs. MEF specifications define two E-Line services: Ethernet Private Line (EPL) and Ethernet Virtual Private Line (EVPL). EPL is defined as a single connection between two UNI and a single interface in each UNI is dedicated to the EVC. EPL does not enable service multiplexing. EVPL is defined to allow a UNI to participate in multiple EVC and thereby enables service multiplexing.

E-Tree is point-to-multipoint service, providing a hub-and-spoke connectivity in which one UNI serves as the root and one or more other UNIs serving as leaf. The root UNI can communicate via the EVC with any leaf UNI but a leaf UNI communicates only with the root UNI.

E-LAN is multipoint-to-multipoint service, providing full mesh connectivity between UNI.==

(Add description)

EPL is selected as the initial use case because it is the simplest service type. It allows the work to focus on the fundamental building blocks of Carrier Ethernet service, UNI and EVC, without having to address more complex configurations. (Include mention UNI-UNI and UNI-ENNI. Also OVC.)

1. Create EPL service between two UNIs within a single service provider's domain. UNIs locations are specified in the request

2. Allow customer to define a class of service (service tier) with Service Level Agreement attributes. The project intends to support attributes defined in Metro Ethernet Forum specification MEF 6.2 EVC Ethernet Services Definitions Phase 3: https://www.mef.net/Assets/Technical_Specifications/PDF/MEF_6.2.pdf

3. Allow customer to change the ingress bandwidth profile at a per-service level without manual intervention.

Features to consider for future phases:
- Ability to create other service types
- Ability to create service across service provider boundaries
- Ability detect, measure, and report performance parameters
- Ability to detect and report system faults
- Ability to make changes to the network, such as adding network capacity, based on performance reporting (self healing)

1. Upon request for service from an application or orchestrator, evaluate the request.
2. Reject any request for service other than Ethernet Private Line service
3. Reject EPL service request with missing parameters
4. Reject EPL service request with parameters that are outside allowable range(s)
5. (More to be added)

Connectivity Services LSO defines a layered architecture for the APIs, with each layer using the services of the layer below it. The proof of concept implementation includes the three RESTful APIs listed above and contributed to the project.

The Connectivity Services Manager is responsible for managing the Create, Retrieve, Update, and Delete (CRUD) requests for the requested Service Type and maintaining information about the Services that have been created. The Connectivity Services Manager uses the Ethernet Virtual Connection Manager for the EVC(s) that must be created and managed to provide the service requested by the customer.

The Connectivity Services Manager provides a REST interface to higher layers, which may be an application or an Orchestration Layer.

The Class of Service Manager allows the application to CRUD service classes, or groups of SLA parameters, to be referenced by the EVC manager.

The EVC Manager provides connection CRUD service for the Connectivity Services Manager and uses the Controller User Network Interface Manager plug-in.

<TBD: Identify and document information to be exchanged and logical grouping. Initial information model provided as a starting point.>

Prototype API software is posted to the project repository here: git clone https://gerrit.opnfv.org/gerrit/lsoapi (anonymous)

Full software design documentation TBD.

<TBD>

-