# On the Rollout of Network Slicing in Carrier Networks: A Technology Radar
## 7 TN Domain
### Transport SDN Fabric
The scope of this module can be summarized into five functionalities: (i) E2E control across the different domains, by coordinating the disparate technologies through their corresponding SDN domain controllers; (ii) per-layer E2E visualization, i.e., per-layer topology composition; (iii) stateful control of provisioned network services; (iv) multi-layer Path Computation Engine (PCE), which has the role of computing paths across multiple technologies based on the per-layer topology composition; and (v) service binding to transport resources, which enables the controller to obtain the best Traffic Engineering (TE) connections for a given transport connectivity service. An example of the functionality described in (v) is as follows: for a VPN having certain bandwidth and latency contraints, compute the set of Label Switched Paths (LSPs). * **E2E SDN controller: NBI**. The focus here is on the E2E transport network abstraction block, in charge of exposing an abstracted topology view of the network resources and the available set of network services to SDTN consumers through an unified NBI. There is no solution yet in the standards, although quite close cooperation between Telecom Infra Project's OOPT [83] and IETF's TEAS [100] exists in this regard. Ongoing discussions reveal the idea to use LxSM models (see Table 4) as a starting point for the NBI implementation. * **Slicing-aware E2E SDN controller**. This consists of incorporating the T-NSC, which will have the awareness of slicing at the transport layer. Though there is not yet an common view of what T-NSC represents, the telco industry agrees on the need (i) to align the T-NSC concept with the IETF Slice Controller developed by the IETF TEAS's network slice design team [101], and (ii) to implement the T-NSC as an additional component of the SDTN controller. For the first point, the focus is to align the T \begin{table}
\begin{tabular}{p{56.9 pt} p{113.8 pt} p{113.8 pt}} \hline \hline
**Domain Controller** & **NBI Models** & **Description** \\ \hline \multirow{6}{*}{IP controller} & L3 SM [91] & These models are used for the provisioning of \\  & L2 SM [92] & L2/L3 connectivity services.They describe a \\  & L3 NM [93] & VPN service from the customer (LxSM) or \\  & L2 NM [94] & network operator (LxNM) viewpoint \\ \cline{2-3}  & & These models allow to manipulate Traffic \\ \cline{2-3}  & TE [95] & Engineering (TE) tunnels. There exist extensions to work with a desired technology (e.g., MPLS RSVP-TE tunnels, Segment Routing paths). \\ \hline \multirow{3}{*}{Optics controller} & \multirow{3}{*}{T-API [97]} & It is the model with higher market adoption. It includes technology-specific information from each transport layer, including DSR/Ethernet, OTN/ODU and photonics media. \\ \hline \multirow{3}{*}{Microwave controller} & OpenBackhaul model set [98] & This repository captures the set of models for the microwave segment. They are extensions from those captured in ONF Core Information Model [99]. \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Overview of network YANG models for the NBI of per-technology domain SDN controllers. NSC with the use cases [102] and YANG network models [103] worked out for the IETF Slice Controller. For the second point, we foresee a solution similar to the one represented in Figure 17. As seen, the T-NSC might be built out of two separate modules: the mapper and the realizer. The mapper module is responsible for collecting the customer-facing view of the TN slice for further processing the TN slice request. Thus, this module would integrate the customer-facing view on the provider view for triggering configuration, control and management actions. On the other hand, there is the realizer module, which is in charge of coordinating different actions on a number of domain SDN controllers for effectively creating the TN slice, according to the original customer request.