Wiki

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

===February 16, 2016===
OPNFV TSC approved terminating Connectivity Services LSO project: \\
http://meetbot.opnfv.org/meetings/opnfv-meeting/2016/opnfv-meeting.2016-02-16-14.59.html 

----

=====Project Termination Request=====
**February 1, 2016**
The Connectivity Services LSO project petitions OPNFV Technical Steering Committee to terminate the project in OPNFV.

__Reasons for Termination Being Sought__ \\
The reasons for termination being sought are detailed in project meeting minutes for the January 28 project meeting and summarized below.  Reference:  http://ircbot.wl.linuxfoundation.org/meetings/opnfv-meeting/2016/opnfv-meeting.2016-01-28-17.04.html 

(1) Brahmaputra release is focused on the data center and not on providing services to the network or customer CPEs. The LSOAPI project is specifically about providing business services to service provider customers on the network, so project objectives do not align with Brahmaputra. \\
(2) LSOAPI uses services of OpenDaylight UNI Manager plug-in, which will be introduced with the Beryllium release (Feb. 2016). However OPNFV Brahmaputra will integrate ODL Lithium release (June 2015) which does not include UNI Mgr plug-in so in Brahmaputra LSOAPI will not a supporting ODL functionality and will therefore provide little to no value. \\
(3) In the ODL UNI Manager project current plans are to evolve the plug-in to incorporate Service Layer YANG model and Resource Layer YANG model. This will supersede and obsolete the 'basic' Service Layer functionality currently being provided by LSOAPI. That is, if the current plan for UNI Manager comes to fruition, LSOAPI will not be needed to provide Service Layer functionality as it will be replaced with more complete Service Layer functionality in OpenDaylight. \\
(4) OPNFV requirements for projects to be included in the Brahmaputra release include executing project code on an instance of OPNFV Pharos release and include LSOAPI testing in Brahmaputra continuous integration environment. This presents a challenge that has so far proven intractable to the LSOAPI project due to lack of access to appropriate Pharos resource  and to lack of appropriate resource familiar with Brahmaputra CI environment. \\

Note: The requirement for Service Layer functionality that LSOAPI provides for the initial proof-of-concept for configuration of Carrier Ethernet services using open source controller platform does not go away. Our vision is it will migrate to a more full-featured implementation in OpenDaylight. So while the LSOAPI project is terminated the function it was initially created to provide could be implemented in OpenDaylight and incorporated in OPNFV indirectly, as part of OpenDaylight.

__Estimated Impact on Other OPNFV Projects__ \\
LSOAPI API implementations provide an application that uses the OPNFV framework rather than serving as part of the framework. Therefore terminating the LSOAPI project is not expected to have any impact on other OPNFV projects. Removing LSOAPI removes the preliminary Service Layer for the Carrier Ethernet service provisioning application that uses OpenDaylight UNI Manager project as the Resource Layer (element management system), but the new vision is to implement both the Service Layer and Resource Layer in OpenDaylight.

__Impact on Reference Platform Builds__  \\
LSOAPI is not part of the OPNFV reference platform so terminating it is not expected to have an impact on OPNFV Reference Platform Builds.


===== Project Description: =====
The objective of this project is to develop, document and validate a new Metro Ethernet Forum (MEF)-compliant User Network Interface (UNI) Manager feature plug-in for OpenDaylight (ODL) and northbound APIs that use the plug-in to expose capabilities of ODL to configure and provision MEF-defined Ethernet services (and eventually other Connectivity 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 an Ethernet service provisioning information model, 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.


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

Figure 1 Connectivity Services LSO Architecture


{{ :odl_lithium_architecture_uni_manager.png?900 |}}
     
Figure 2 OpenDaylight Lithium Architecture with Proposed MEF-Compliant UNI Manager 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 RESTful interfaces exposed by the proposed APIs can be leveraged by other SDN controller platforms as well.
 
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.

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.

{{ :mef-classes_preliminary.png?600 |}}

Figure 3 Ethernet Private Line Service Initial Information Model


  * Project proposal page: https://wiki.opnfv.org/lar-e 
  * Meeting minutes:  https://wiki.opnfv.org/meetings/lsoapi
  * Project repository: 
      *<nowiki> git clone ssh://<your opnfv id>@gerrit.opnfv.org:29418/lsoapi  </nowiki> \\ 
      * git clone https://gerrit.opnfv.org/gerrit/lsoapi \\

====Key Project Facts====

**Project:** Connectivity Services LSO (lsoapi)\\
**Project Creation Date: ** July 14, 2015 \\
**Project Category:** Requirements \\
**Lifecycle State:** Incubation \\
**Primary Contact:** Kevin Luehrs, CableLabs (k.luehrs@cablelabs.com) \\
**Project Lead:** Kevin Luehrs\\
**Jira Project Name:** Connectivity Services LSO \\ 
https://jira.opnfv.org/browse/LSOAPI/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel \\
**Mailing list tag: ** [lsoapi] \\
**Jira Project Prefix:** (lsoapi) \\
**IRC:** #opnfv-meeting \\

**Committers**: 
  * Mufaddal Makati, CableLabs M.Makati@cablelabs.com
  * Brian Otte, CableLabs B.Otte@cablelabs.com
  * Ashlee Young, Huawei ashlee@onosfw.com

** Link to TSC approval of the project: ** http://meetbot.opnfv.org/meetings/opnfv-meeting/2015/opnfv-meeting.2015-07-14-14.00.html \\


**Contributors**: 
  * Mufaddal Makati, CableLabs M.Makati@cablelabs.com
  * Prakash Ramchandran, Huawei Prakash.Ramchandran@huawei.com
  * Brian Otte, CableLabs  B.Otte@cablelabs.com

 
**Meetings:** 

Thursdays at 9:00 am US Pacific time  [[http://www.timeanddate.com/worldclock/fixedtime.html?hour=15&min=0&sec=0|16:00 UTC (when US Standard Time)]] / [[http://www.timeanddate.com/worldclock/fixedtime.html?hour=14&min=0&sec=0|15:00 UTC (when US Daylight Saving Time)]]
https://global.gotomeeting.com/join/645827661

https://wiki.opnfv.org/meetings/lsoapi 

**Deliverables**

Requirements document: https://wiki.opnfv.org/lsoapi/documents/Requirements
 

**Documents**

https://wiki.opnfv.org/lsoapi/documents
Wiki

User Tools

Site Tools

Page Tools
