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

  • No labels

3 Comments

  1. Zhuoyao Huang

    Hi Ravi, in Casablanca Release, we proved the concept of ONF CIM based modeling in CCVPN and deployed SOTN in T-API south bound interface. The refrence is showed below:

    information model: https://wiki.onap.org/display/DW/Wan+Connection+IM+proposal
    SDC model design: https://wiki.onap.org/display/DW/CCVPN+Wan+Connection+Service+Design
    5G MH/BH: https://wiki.onap.org/display/DW/ONAP+Meetup+-+August+9+to+10%2C+2018%2C+Xi%27an%2C+China?preview=%2F38112588%2F38119851%2F3-0809-5G+Midhaul+Backhaul+Modeling+and+Orchestrating+-+upload.pptx

    Wish the reference may help and maybe we could have a chance to cooperate in this use case extension. 

    Best regards!

  2. Aihua Guo

    Hi Ravi,

    ONAP internal models for CCVPN are constructed in a standard-independent way. SOTN APIs beween SDN-C and 3rd party controller has implemented specific IETF group of YANG models for abstracted topology discovery, service provisioning, notifications, etc. I think it would be good if we extend L0/L1 support following the same logic - extending but not introducing a new model family to the internal model. We could try to align on an extended generic internal model in ONAP and construct specific model plugins to allow SDN-C to interface with a 3rd party controller at SBI that supports different standards, e.g. IETF YANG or T-API. 

    Also as a reference, the following (base and augmented) YANG models from IETF may be considered for implementation when ONAP interfaces with an IETF-ACTN based controller for L0/L1/L2:

  3. Chuanyu Chen

    Hi Ravi，

          I think the current ONAP  CCVPN Models implemented are not totally any standard based, just for model-driven solution  to support the CCVPN scenario in SDC. 

    To get  the detailed data model you can refer to :CCVPN Use Case Resource IM Proposal and CCVPN Service Design

    I suggest we can discuss the models based on the current implementation in ONAP to check if there is any gap .

    Any good suggestion are appreciated. We can discuss this in modeling sub committee.

    Best wishes!