1. Transport network requirements for TAPI considering NBI
Yunbin Xu, Xing Zhao, CAICT
Xiang Yun, FiberHome
August 15, 2019

2. 1.1 Introduction (1): Interface needed in SDN based transport network
Orchestrator
NBI: northbound API, interface between orchestrator and multi-domain controller.
I-CPI: inter-controller API, interface between high-lever controller and low-level controller
SBI: southbound API, interface between domain controller and transport device.
NBI
Controller for RAN
Multi-domain controller for transport
Controller for CN
I-CPI
I-CPI
Domain controller for transport
Domain controller for transport
SBI
SBI
RAN
TN1
TN2 CN

3. 1.2 Introduction (2)
Now China Communication Standard Association(CCSA) and China network operators already made national standards of:
I-CPI model based on TAPI 2.0
SBI model of OTN device based on TAPI 2.0 extension
This contribution is to discuss how to extend TAPI to get the NBI model so as to maintain the consistency of the three interfaces.
This contribution aims at:
Doing initial analysis of VN model defined in TAPI, discuss the feasibility of extending the VN model to meet the requirements of NBI.
Calling for advice on using TAPI in NBI modeling
Orchestrator
NBI
Multi-domain controller for transport
I-CPI
Domain controller for transport
SBI
TN1

4. 2. Key demands of transport network NBI
In order to realize automated end-to-end service and network orchestration, transport network (TN) needs to provide standard northbound interface(NBI), which should support:
Exchange of topology information
Orchestration of connectivity service
Whole lifecycle management of VN
Monitoring & maintenance of VN and connectivity service
Orchestrator
NBI
Multi-domain controller for transport
I-CPI
Domain controller for transport
Orchestrator
Topology info
VN creation/
modify/deletion
VN monitoring & optimization
SBI
Connectivity configuration
TN1
Multi-domain controller for transport

5. 3. Use TAPI model for NBI (1)
If use TAPI model for NBI：
Requirement 1: topology information report--Based on the topology information reported by TN controller, implement end-to-end VN orchestration.
Topology information can use the TAPI-topology model to represent and report?
Questions:
Is it appropriate to use SIP to represent the service access point
Is it needed to report the parameters used for route computation?
Should we define the isolation parameters for VN resources, such as link and NEP?
Orchestrator
NBI
Multi-domain controller for transport
I-CPI
Domain controller for transport
建议：调换一下PPT的顺序，从上NBI到下SBI，依次说明应用TAPI需要解决的问题有哪些。
Service access point: End point of connectivity service used for customers from 5G RAN or 5G TN.
G.800/
3.1.2 access point [ITU-T G.805]: A "reference point" that consists of the pair of co-located "unidirectional access" points, and therefore represents the binding between the trail termination and adaptation functions.
unidirectional access point [ITU-T G.805]: A "reference point" where the output of a "trail termination sink" is bound to the input of an "adaptation" sink or the output of an "adaptation" source function is bound to an input of a "trail termination source".
D.1 Overview of transport entity roles
An operational domain is a collection of transport resources falling within the scope of control of a single operator or administrative entity within an operator. The transport service demarcation point between operational domains occurs on a link (the link may be virtual) between the operational domains and is a user to network interface (UNI) or external network to network interface (ENNI) depending on the service relationship between the domains.
SBI
TN1

6. 3.Use TAPI model for NBI (2)
Requirements 2: VN operation—Orchestrator sends a VN operation request to create, modify and delete a VN.
Problems that needs to be solved：
Orchestrator
Multi-domain controller for transport
Domain controller for transport
TN1
NBI
I-CPI
SBI
Parameters carried in VN operation
Corresponding TAPI object
Problems to be solved
VN name
VNS.uuid /
VN topo
VNS.topo
VN type
May need to extend
Service access point
SIP
Capacity
VNS.vnconstraint
Delay
Isolation requirements ?
How to represent the VN isolation mechanism, such as hard/soft isolation?
SLA
Cost policy
VN type: Classification can be based on how to make up a VN, such as the VN type defined in draft-ietf-teas-actn-vn-yang-06
Type 1 VN: The VN can be seen as a set of edge-to-edge abstract links (a Type 1 VN)
Type 2 VN: For some VN members of a VN, the customers are allowed to configure the actual path (i.e., detailed virtual nodes and virtual links) over the VN/abstract topology agreed mutually between CNC and MDSC prior to or a topology created by the MDSC as part of VN instantiation. Type 2 VN is always built on top of a Type 1 VN.
Or based on VN is adjustable or fixed,
Or based on the technology used for VN, such as L1VPN, L2VPN, L3VPN, etc.
VN Level: may be 1-3
1 – shared
2 – soft isolation
3 – hard isolation
Questions:
_diversityExclusion may be used for different links or paths, not for isolation requirements of VN, it might be to define the isolation level for a VN.
Cost or delay is used for link or node, may not be used for the VN, it might be to define some policy, such as the max cost or max delay for a VN.

7. 4. Conclusion & Proposal
NBI is a highly abstract interface which only delivers the user service demands and VN/VNS management operations. Underlying details including detailed topology, intra-domain route, etc. will not be presented in NBI.
We need to do further abstraction based on TAPI by simplifying and extending TAPI to get NBI model.
Call for more advice on NBI modeling.