Participants:
AT&T, Orange, Fujitsu (member list below)
Description:
Provide end to end multi-operator L1 services orchestrated by ONAP across multiple optical transport domains
Goals:
- Incorporate & harmonize with MEF L1 Subscriber and Operator service definitions
- E2E optical service work flow definitions & on-boarding of network resources
- Align, harmonize, reconcile common information/data models in ONAP to enable Optical Transport services design & instantiation
- Optical Transport domain management through standard models / APIs. Eg: OpenROADM, Transport API
BUSINESS DRIVER
This section describes Business Drivers needs.
Executive Summary - This use case is to automate the service design and activation resulting from an optical (L0/L1) service request that requires "off-net" resources to complete, requiring coordination between two or more service providers.
Business Impact - Automation of the design and activation of services spanning service provider networks will speed time to revenue.
Business Markets - This use case is applicable to any service provider offering global enterprise services or services that otherwise extend beyond their own network resources. It may also apply to service providers with independent operational units that effectively operate as separate service providers.
Funding/Financial Impacts - While this automation may result in some CAPEX savings due to improved management of interconnect points, it will primarily reduce OPEX by automating some of the manual steps required for service provider interconnections. It will also allow service providers to respond more quickly to service orders requiring off-net resources, thus reducing time to revenue. A goal of this use case is to ensure support for SLAs and adherence to service constraints that potentially allow for the development of new premium service offerings.
Organization Mgmt, Sales Strategies - There is no additional organizational management or sales strategies for this use case outside of a service provider's "normal" ONAP deployment and its attendant organizational resources.
Team Accomplishments:
First draft Frankfurt accomplishments
April 8th MDONS demo conducted by THIRILOSHINI KRISHNAKUMAR and Xin Miao (Unlicensed) 
- Scroll down to April 8th meeting notes for demo link
Frankfurt Integration testing status link
Initial use-case proposal (Frankfurt):
ONAP-optical-usecase-proposal.pptx
Proposed MDONS enhancements (Guilin): 
Service-Assurance-in-MDONS-042020-v0.1.pdf
Link to MDONS extensions in Guilin: MDONS Extension in R7
Architecture Subcommittee presentation: mdons-guilin-archcom.pptx
Event drive reconfiguration discussion: Event-driven-reconfiguration.pptx
Business requirements:
L1 interconnect business reqts agreed 5-16.pptx
EUAG Proposal
EUAG L1 Interconnect PoC final - 05.pptx
EUAG L1 Interconnect PoC draft - 04..pptx
EUAG L1 Interconnect PoC draft.pptx
Archiecture and Workflow Proposals:
ONAP-Project-Proposal-rv12OrangeContribV3.pptx
ONAP-optical-usecase-proposal-with-cds-4/29
ONAP-optical-usecase-proposal-with-cds
Modeling
MDON-Service-Use-Case-2019.pptx
Optical Modeling_L1 Subscriber and Operator Services_v2.pptx
Other items of interest
ONAP_Transport_Slicing_briefing.pptx
| Member Name | Company | ||||
|---|---|---|---|---|---|
| david.allabaugh@us.fujitsu.com | Fujitsu | ||||
| olivier.augizeau@orange.com | Orange | ||||
Martin Birk | mb4962@att.com | AT&T | |||
| Yici Guo | yg2473@att.com | AT&T | |||
| eric.debeau@orange.com | Orange | ||||
| bf1936@att.com | AT&T | ||||
| Yici Guo | yg2473@att.com | AT&T | |||
| denise.provencher@usTHIRILOSHINI KRISHNAKUMAR | thiriloshini.thoppekrishnakumar@us.fujitsu.com | Fujitsu | |||
| Fujitsu | |||||
| denise.provencher@us.fujitsu.com | Fujitsu | ||||
| Olivier Renais | olivier.renais@orange.com | Orange | |||
| raghavan.subramanian@us.fujitsu.com | Fujitsu | THIRILOSHINI KRISHNAKUMAR | thiriloshini.thoppekrishnakumar@us.fujitsu.com | Fujitsu |
Functional Requirements:
| ONAP Components | Comments | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CDS (future release) | Started Discussion with CDS group to identify the required changes to support this blue print. Have provided the initial sequence flow. (Future Release) | ||||||||||||||||||||
| SDC Have to start discussions. Mostly for now we will just be using existing features of SDC. May require small tweaks. | Use existing feature support w/o change code in Frankfurt | ||||||||||||||||||||
| SO | Will need some changes in SO to accomplish the decomposition of end to end optical service. More details need to be ironed out.
| ||||||||||||||||||||
| SDN-C | Have done some prototyping in Dublin for adding new DGs to extract topology from external domain controllers and map them to A&AI schema. Will need additional work to integrate this with proposed CDS workflow in Future release.
| ||||||||||||||||||||
| A&AI | Have done some prototyping in Dublin to ingest topology from external controllers and show them in A&AI. Will need more work to act on notifications from controllers and keep the topology in sync
| ||||||||||||||||||||
| OOF (Phase 2for future release) | Need more detailed discussions with OOF PTL to understand how we can use OOF to provide the intermediate endpoints /inter-connection selection that will support to form the end to end L1 service
| ||||||||||||||||||||
| Policy ( future release/Phase 2) | Need to understand how we can use the policy to store inter SP agreements which can later be translated by OOF to determine the partner SP and also the end points at the partner side. (Future release) | ||||||||||||||||||||
| EXT-API | Need to have alignment on how we can use the MEF interlude API for inter SP interactions. EXT-API and SO communications also has to be flushed out. | ||||||||||||||||||||
| Modeling | Need to define the extensions to the currently agreed upon service model so that we can use it to represent an end to end Layer1(L1) Optical service. This L1 Optical service can span across multiple service providers which are controlled by one or more ONAP instances. Every SP can in turn have multiple domains that are controlled by external domain controllers. | ||||||||||||||||||||
| UUI | Modify the component for the user to be able to initial L1 service from user interface and verify APIs.
|
Interested Parties
| Viewtracker report |
|---|