User Tools

Site Tools


lar-e

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
lar-e [2015/06/18 16:20]
Kevin Luehrs
lar-e [2015/07/14 15:45] (current)
Ashlee Young [Committers and Contributors:]
Line 2: Line 2:
 ====== Project Name: Connectivity Services LSO ====== ====== Project Name: Connectivity Services LSO ======
   * Proposed name for the project: Connectivity Services LSO   * Proposed name for the project: Connectivity Services LSO
-  * Proposed name for the repository: ​LSO-api+  * Proposed name for the repository: ​lsoapi
   * Project Categories: Requirements   * Project Categories: Requirements
  
 ===== Project Description:​ ===== ===== Project Description:​ =====
-The objective of this project is to develop, document and validate a new feature plug-in for OpenDaylight (ODL) and northbound APIs using the plug-in ​enabling fulfillment ​of MEF-defined Ethernet services through ODL and/or Open Stack. The project will include developing ​data models for the services and components.+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. 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.
Line 23: Line 23:
       * Metro Ethernet Forum Technical Specification MEF 10.3 Ethernet Services Attributes Phase 3;       * 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       * Metro Ethernet Forum Technical Specification MEF 6.2 EVC Ethernet Services Definitions – Phase 3
-  * User Network Interface (UNI) Management API endpoint (RESTful web service)+  * 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     * 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 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 Management Service ​and UNI Management ​Service APIs 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. ​+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. 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.
Line 36: Line 38:
 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. 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.  ​+Proposed APIs follow the ETSI ISG NFV reference architecture,​ incorporating the UNI control and management planes into OpenDaylight and exposing MEF service definitions to OSS/BSS applications and to Virtual Network Functions ​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. 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.
Line 44: Line 46:
 Figure 2 MEF Services APIs Relationship to ETSI ISG NFV Reference Architecture Figure 2 MEF Services APIs Relationship to ETSI ISG NFV Reference Architecture
  
-An initial UML representation of the EPL data 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.+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.
  
-{{ :eline_data_model.jpg?600 |}}+{{ :mef_classes.png?600 |}}
  
-Figure 3 Ethernet Private Line Service Initial ​Data Model+Figure 3 Ethernet Private Line Service Initial ​Information ​Model
  
 ===== Scope: ===== ===== Scope: =====
Line 98: Line 100:
   * Committers   * Committers
     * Kevin Luehrs, CableLabs ​ K.Luehrs@cablelabs.com     * Kevin Luehrs, CableLabs ​ K.Luehrs@cablelabs.com
-    * Adolfo Perez-Duran, CableLabs ​  A.Perez-Duran@cablelabs.com+    * Mufaddal Makati, CableLabs M.Makati@cablelabs.com 
 +    * Ashlee Young, Huawei ​            ​ashlee@onosfw.com
   * Contributors   * Contributors
     * Kevin Luehrs, CableLabs     * Kevin Luehrs, CableLabs
-    * Adolfo Perez-Duran,​ CableLabs 
     * Mufaddal Makati, CableLabs M.Makati@cablelabs.com     * Mufaddal Makati, CableLabs M.Makati@cablelabs.com
 +    * Prakash Ramchandran,​ Huawei ​      ​Prakash.Ramchandran@huawei.com
     * <TBD additional contributors>​     * <TBD additional contributors>​
  
Line 116: Line 119:
 ===== Proposed Release Schedule: ===== ===== Proposed Release Schedule: =====
  
-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. ​+The first release of the EPL service management API, UNI management API and data models is targeted for OPNFV Brahmaputra ​release and ODL Beryllium ​release
  
lar-e.1434644439.txt.gz · Last modified: 2015/06/18 16:20 by Kevin Luehrs