Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
=====Connectivity Services LSO Requirements=====

Release 0.3.0

November 30, 2015


====Contents====


**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:

    - Connectivity Services Manager RESTful API
    - Class of Service Manager RESTful API
    - Ethernet Virtual Connection RESTful API
    - UNI Manager feature plug-in for OpenDaylight

The Connectivity Services LSO project will evolve the above-listed APIs and develop Ethernet Virtual Connection per User Network Interface (EVC per UNI) Manager API and Ethernet Virtual Connection Path Manager API.

===History===

^     Date    ^  Description    ^
|July 14, 2015|Project approved |

===Terms===

<TBD>


====Introduction====

===Problem Statement===

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.


====Use Cases====

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===

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===

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===

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

===E-Access===
E-Access service type is defined by MEF as Ethernet services that use an Operator Virtual Connection (OVC) with at least one UNI OVC end point and one External Network-to-Network Interface (ENNI) OVC end point. This refers to the part of a multiple-service provider Ethernet service that is within a single provider's network.

===Use Case for Initial Project Phase===
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.)

==== Feature Requirements:Initial Phase====
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)


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

====Architecture====

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. 


{{ :vbc_northbound_apis_and_odl_uni_mgr_plug-in_architecture_v2.png?500 |}}
 

===Connectivity Services Manager RESTful API===

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.



===Class of Service Manager RESTful API===

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

===Ethernet Virtual Connection Manager RESTful API===

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


====Information Model====


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


{{ :cablelabs_epl_mef_classes_preliminary.png?600 |}}


====Software Design====

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

Connectivity Services Manager API, Ethernet Virtual Connection Manager API, and Class of Service Manager API architecture is documented on the [[https://wiki.opnfv.org/lsoapi/documents/architecture|LSOAPI Architecture]] page.

Connectivity Services LSO APIs are designed and implemented based on the information model. The APIs are documented using RESTful API Modeling Language (RAML). The RAML description of the APIs developed to date is posted on the [[https://wiki.opnfv.org/lsoapi/documents/apidocumentation|LSOAPI API Documentation]] page. HTML representation of the API documentation is available on the page <page TBD>.
 



====Implementation Plan====

Implementation of the Connectivity Services LSO APIs as currently scoped consists of two phases: \\ \\
 ** Phase 1:** Create, Retrieve, Update and Delete (CRUD) lifecycle for single-operator Ethernet Private Line (EPL) service for the current, limited, CableLabs-developed EPL service YANG model (filename cl-vcpe-mef.yang).\\ 
**Phase 2:** CRUD lifecycle for single-operator EPL service for a comprehensive YANG model that includes all UNI, EVC per UNI, and UNI attributes. \\ \\
Opportunities for later phases include expanding the APIs to support other Carrier Ethernet services, multiple service provider scope, support for Layer 3 services, and support for Virtual Network Functions such as OAM functions. \\ \\

===Phase 1===
Following are tasks defined for Phase 1: \\
* Update/complete EVC per UNI class in information model [Target date: TBD] \\
* Complete EVC Path class in information model  [Target date: TBD] \\
* Implement Create for Connectivity Service Manager API  //complete// \\
* Implement Create for EVC Manager API  //complete// \\
* Implement Create for CoS Manager API //complete// \\
* Implement Create for UNI Manager ODL feature plug-in for OVSDB //complete// \\
* Implement Create for UNI Manager ODL feature plug-in using NetConf - one specific device [Target date: Sept. 18, 2015]  \\
* Implement Retrieve for Connectivity Service Manager API  //complete// \\
* Implement Retrieve for EVC Manager API  //complete// \\
* Implement Retrieve for CoS Manager API //complete// \\
* Implement Retrieve for UNI Manager ODL feature plug-in using OVSDB  //complete// \\
* Implement Retrieve for UNI Manager ODL feature plug-in using NetConf - one specific device  [Target date: Sept. 18, 2015] \\
* Implement Update for Connectivity Service Manager API  //complete// \\
* Implement Update for EVC Manager API  //complete// \\
* Implement Update for CoS Manager API //complete// \\
* Implement Update for UNI Manager ODL feature plug-in (OpenDaylight UNI Manager project) [Target date: TBD] \\
* Implement Delete for Connectivity Service Manager API  //complete// \\
* Implement Delete for EVC Manager API  //complete// \\
* Implement Delete for CoS Manager API //complete// \\
* Implement Delete for UNI Manager ODL feature plug-in (OpenDaylight UNI Manager project)  [Target date: TBD] \\
* Design and implement EVC per UNI Manager API [Target date: TBD] \\
* Design and implement EVC Path Manager API [Target date: TBD] \\
* Integrate APIs and UNI Manager ODL feature plug-in for CRUD operations [Target date: TBD] \\

===Phase 2===
Following are tasks defined for Phase 2: \\
* Develop comprehensive resource-focused MEF EPL Service YANG model  [Target date: October 2, 2015] \\
* Update CRUD for Connectivity Service Manager API  [Target date: December 4, 2015] \\
* Update CRUD for EVC Manager API  [Target date: December 4, 2015] \\
* Update CRUD for CoS Manager API (if needed) [Target date: December 4, 2015] \\
* Update CRUD for UNI Manager ODL feature plug-in  [Target date: November 13, 2015] \\
* Design and implement CRUD for EVC per UNI Manager API [Target date: December 4, 2015] \\
* Design and implement CRUD for EVC Path Manager API [Target date: December 4, 2015] \\
* Integrate APIs and UNI Manager ODL feature plug-in for CRUD operations [Target date: December 18, 2015] \\

Back to LSOAPI [[/lsoapi | main project page]]
Wiki

User Tools

Site Tools

Page Tools
