Extension for L0/L1 (Dublin) - Proposal

Owned by Karthik Jeevanige
Last updated: Jan 09, 2019 by ravi.rao
3 min read

Overview

  • Extend CCVPN use case for Optical ( L0) and L1

  • This project aims to provide end to end multi-layer(L0/L1) and multi-vendor service orchestration across multiple optical transport domains

  • This project also aims to enable service orchestration over multiple 5G transport network management systems across FH and MH/BH domains

Dublin release Plan enhancements

  • A Test bed that provides a L1 network with simulators for NEs running as containers on a dedicated test cluster

  • Provide a plugin for SDN-C that can be used to communicate to the local SDN controller which can discover the NEs in the above similated network and export the network topology using a standard T-API interface to AAI components of ONAP

  • Provide additions to the SDC model to describe the new resources that are needed to create and end to end L1 service

  • Provide a T-API compliant interface t o SDN-C which can be invoked by SO to create/update/delete a L1 service between any two end points

  • Support notification endpoints as per T-API standard to monitor the created L1 service

  • Notifications can also be streamed to DCAE which can then be used to update the underlying L1 service if required , to achieve intelligent bandwidth on demand, to allow third party analytics apps to trigger ONAP closed loop adjustment of the active CCVPN service instances (e.g: the bandwidth between specified sites)



Dublin Goals

  • Enable T-API based service provisioning for SDN-C for L0/L1

  • service orchestration over optical domain

  • PNF collectors for DCAE

Business Requirements

Adding support for optical layer to CCVPN gives operators the flexibility to dynamically configure and create end to end service. Operators will be allowed to configure optical layer for different slicing requirements (in case of 5G ).

Operators will have additional capabilities for monitoring Quality of services for Optical layer

T-API is a common standardized API that allows access to domain/vendor specific attributes without the need of vendor specific API. Enabling T-API based provisioning for SDN-C will allow operators to deploy ONAP across multi-domain, multi-vendor infrastructure enabling end to end Programmability for their networks for speed of deployment, efficiency and revenue generating services.



Service provider priority for Dublin

Components

SP priority  Dublin

DCAE

External API enhancements

SDN-C

Service modelling extensions for T-API

AAI

External API enhancements

SDC

Service design template extensions for Service design

MSO

orchestration over multiple optical domains



Participating companies



Fujitsu

Scope

  • Provide Optical restoration capabilities leveraging ONAP SDN-C

  • APIs/interfaces

  • Transport-API (T-API 2.X) – NBI enhancements for L0

  • MEF 60 APIs – NBI enhancement for L1 services

  • OpenROADM / IETF models – L0/L1 Device models

  • xRAN – 5G Fronthaul devices

  • Testing and integration plans

  • E2E Openroadm and ONAP testing and integration

  • Features and functionality

  • Can be extended across multiple service provider networks



Use case presentation

GINNIS ONAP Project Proposal rv2.pptx

Use case meetings

Impacts

SDN-C

  • T-API 2.0 Interface support (REST API)

  • MEF 60 support for L1 service provisioning

  • Contribute a Plugin to control Local SDN controller to manage L0/L1 devices

A&AI

  • T-API support to for topology across network domains

  • Registration mechanisms for Transport NEs

SDC

  • Sample Service template for E2E service creation & monitoring across optical transport domains (RAN & Core)

  • Incorporating network requirements for topology, path computation, restoration etc.

  • Policy definition for closed-loop automation & event handling

DCAE

  • VES compliant enhancements to for PM/Alarms streaming from Optical network elements

  • Analytics Application / Micro-service

SO

  • Workflow definition to orchestrate services across multiple optical transport domains

Project Commitments

  1. T-API Interface support from SDN controller to A&AI

  2. Defining Service template

    1. Optical requirements (SRG/Degree)

    2. Network slicing requirements

  3. SBI interface to SDN controller

    1. Usage of simulators & HW modelling

    2. OpenROADM / OpenConfig

    3. IETF models

  4. External controller Plugin / API into SDN-C

    1. External controller support for T-API

  5. PNF collector (VES formatted) into DCAE for Alarms/PMs management

  6. Policy definition for closed-loop automation and event handling

  7. Portal / UI & external interface display for control & monitoring



Resources

Contact person: Ravi Rao Ravi.Rao@us.fujitsu.com

Initial Committers