## 3 Proposed Architecture
### Instantiating of Network Slices in SDN Transport Networks  
As described before in the Section 3.1, the OSS/BSS systems may request the deployment of a new network slices with certain transport characteristics. Each network slice must be isolated from any other network slices or different services delivered to particular customers and naturally, other network slices or services must not negatively impact the requested transport network slice's delivery. To provide this isolation and instantiate the slice in the network there are certain implementation options ranging from softer to hardest grades of isolation, as follows:  
* No-isolation, meaning that slices are not separated. * Logical-isolation, where slices are logically separated, only a certain degree of isolation is performed through QoS mechanisms. * Service-isolation, where virtual resources and NFs are shared. * Process-isolation, where slices include process and threads isolation. * Virtual-resource-isolation, where slices have dedicated virtual resources. * Network-functions-isolation, where Network Function (NF) are dedicated to a single network slice. * Physical-isolation, where slices are completely physically separated, for example, in different locations. * Physical-network-isolation, where slices contain physically separated links. As the isolation grade is a significant constraint to consider for the network slice implementation, the selected network infrastructure and the control elements selected would generate different sets of capabilities in the Network Slice Controller. Figure 2 describes three of the possibilities analyzed from the point of view of the mapping and realization tasks of the Network Slice Controller:  
* **Network Slice Controller as part of the hierarchical controller:** When the Network Slice Controller is a Hierarchical SDN controller module, the NSC's and the Hierarchi \begin{table}
\begin{tabular}{p{113.8 pt} p{113.8 pt} p{113.8 pt}} \hline \hline
**Models** & **Description** & **Example** \\ \hline \multirow{3}{*}{LxVPN} & These models describe a VPN service from the customer or network operator point of view. & L3 SM: [15] \\  & These models describe a VPN service from the customer or network operator point of view. & L2 SM: [28] \\  & These models allow to manipulate & L3 SM: [4] \\  & Traffic Engineering & Traffic Engineering tunnels within the network segment. Technology-specific extensions allow to work with a desired technology (e.g., MPLS RSVP-TE tunnels, Segment Routing paths, OTN tunnels, etc.) & TE: [29] \\ \hline TE Service Mapping & These extensions allow to specify for LxVPN the details of an underlay based on Traffic Engineering & Service Mapping: [32] \\ \hline \multirow{3}{*}{ACLs and Routing policies} & Even though ACLs and routing policies are device models, It’s exposure in the NBI of a domain controller allows to provide an additional granularity that the network domain controller is not able to infer on its own. & ACL: [33] \\  & As a part of the transport network, OTN can provide hard pipes with guaranteed data isolation and deterministic low latency, which are highly demanded in the Service Level Agreement (SLA). & Routing Policy: [34; 35] \\ \hline \multirow{3}{*}{Slicing} & Set of data models available to map and realize the network Slices. & Network Slice NBI: [25; 26] \\  & & \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Set of these data models are described as the experimental base of this work. cal Network Controller should share the same internal data and the same NBI. Thus, to process the customer, view the H-SDN module must be able to:  
* _Map_: The customer request received using the must be processed by the NCS. The mapping process takes the network-slice SLAs selected by the customer to available Routing Policies and Forwarding policies. * _Realize_: Create necessary network requests. The slice's realization can be translated into one or several LXNM Network requests, depending on the number of underlay controllers.