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

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

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

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

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. 3.1.31 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

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.

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.