lsoapi:documents:requirements
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
lsoapi:documents:requirements [2015/08/20 03:36] Kevin Luehrs [Feature Requirements:Initial Phase] |
lsoapi:documents:requirements [2015/11/29 21:21] (current) Kevin Luehrs [Connectivity Services LSO: Business Services CPE Virtualization] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | =====Connectivity Services LSO: Business Services CPE Virtualization===== | + | =====Connectivity Services LSO Requirements===== |
| - | Release 0.0.1 | + | Release 0.3.0 |
| - | August 13, 2015 | + | November 30, 2015 |
| Line 28: | Line 28: | ||
| - Ethernet Virtual Connection RESTful API | - Ethernet Virtual Connection RESTful API | ||
| - UNI Manager feature plug-in for OpenDaylight | - 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=== | ===History=== | ||
| Line 70: | Line 72: | ||
| E-LAN is multipoint-to-multipoint service, providing full mesh connectivity between UNI. | 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. | ||
| - | 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. | + | ===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==== | ==== 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 | 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 the following parameters: | + | 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 |
| - | Maximum data rate | + | |
| - | MTU size | + | |
| - | (Other parameters defined by MEF for UNI) | + | |
| | | ||
| - | 3. Allow customer to change class of service at a per-service level without manual intervention | + | |
| + | 3. Allow customer to change the ingress bandwidth profile at a per-service level without manual intervention. | ||
| - | Features to consider for future phases: | + | __Features to consider for future phases:__ |
| - | + | \\ - Ability to create other service types | |
| - | - Ability to create other service types | + | \\ - Ability to create service across service provider boundaries |
| - | + | \\ - Ability detect, measure, and report performance parameters | |
| - | - Ability to create service across service provider boundaries | + | \\ - 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) | |
| - | - 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) | + | |
| Line 100: | Line 98: | ||
| - Reject any request for service other than Ethernet Private Line service | - Reject any request for service other than Ethernet Private Line service | ||
| - Reject EPL service request with missing parameters | - Reject EPL service request with missing parameters | ||
| - | - Reject EPL service request with parameters | + | - Reject EPL service request with parameters that are outside allowable range(s) |
| + | - (More to be added) | ||
| ====Architecture==== | ====Architecture==== | ||
| Line 133: | Line 132: | ||
| - | {{ :mef_classes.png?600 |}} | + | {{ :cablelabs_epl_mef_classes_preliminary.png?600 |}} |
| Line 141: | Line 140: | ||
| git clone https://gerrit.opnfv.org/gerrit/lsoapi (anonymous) | git clone https://gerrit.opnfv.org/gerrit/lsoapi (anonymous) | ||
| - | Full software design documentation TBD. | + | 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>. | ||
| Line 148: | Line 149: | ||
| ====Implementation Plan==== | ====Implementation Plan==== | ||
| - | <TBD> | + | 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]] |
lsoapi/documents/requirements.1440041760.txt.gz · Last modified: 2015/08/20 03:36 by Kevin Luehrs
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: Creative Commons Attribution 4.0 International License
