End-to-End Network Slice Stitching using Blockchain-based Peer-to-Peer Network Slice Managers and Transport SDN Controllers

: This paper presents and experimentally validates a Blockchain-based architecture to manage End-to-End Network Slice Deployment by stitching Network Slice Subnets in edge/cloud computing domains connected through packet/optical transport networks domains managed by different operators. © 2021 The Author(s)

. Blockchain-based MANO Architecture implementation in the ADRENALINE testbed (A), Blockchain-based E2E Network Slice deployment workflow (B) on the type of resources (i.e., NSSs or CSs) that each domain manages. The PDL-NSM is composed with the PDL-slicing manager and the NSM modules. The PDL-slicing manager is responsible for the distribution of the available NSSs from its local NSM with the other PDL-modules, to keep the information of other domain NSSs and, finally,it is in charge of initiating and managing the E2E Network Slices deployment procedure by interacting with its local NSM and the external ones through the PDL-slicing manager in other domains. The NSM in the bottom of the PDL-NSM is in charge of managing the deployment of local network slices (i.e., NSSs in the E2E Network Slice) by interacting with the NFV Orchestrator (NFVO) below and its associated Virtual Infrastructure Managers (VIMs) and the local SDN Controllers. Similarly to the PDL-NSM, the PDL-SDN is composed of two modules: the "PDL-transport manager" is in charge of taking the ONF Transport API (TAPI) [5] context offered by the local Transport SDN Controller and distribute it to the other Blockchain peers. When a context is added or updated, all the peers will keep that information in their local Blockchain to update their vision of all the transport domains involved and their interconnections. Additionally, the PDL-transport manager forwards any CS request affecting its domain to the underlying Transport SDN Controller, so this can execute the corresponding CS action in its domain.
The architecture described allows all computing domains to manage E2E Network Slice deployments. As Fig.1-B shows, only the PDL-slicing elements are able to start the process with a request from the Domain OSS/BSS (1). Then, the PDL-slicing manager requests NSSs deployment; on the one hand, to its local NSM (2) that manages their deployment with the NFVO below (3) and, on the other hand, if the NSS belongs to another domain, it distributes the requests to all the peers in the Blockchain (4)(5). Only the owner (4) of the requested NSS will forward the request to its associated NSM (6) and acknowledge the NSS ownership (7). While the second action is done, the associated NSM manages the NSS deployment with the NFVO below (8). At this point the PDL-slicing manager managing the E2E deployment must wait until all the NSSs are deployed. On the one hand, it checks the local NSSs with its NSM and, once it is deployed, updates the E2E Network Slice information (9). On the other hand, for the NSSs from other domains, it must wait until a transaction arrives (11,12). The transaction is originated when the NSM in another domain finishes its NSS deployment and informs its PDL-slicing manager about it (10). The PDL-slicing manager distributes the transaction to all the peers (11,12) and only the original requester keeps it (12) and acknowledges (13) its reception. Once all the NSSs are ready, the PDL-slicing manager managing the E2E deployment starts stitching action. First, it computes the path for each pair of interconnected NSSs and generates a list of CS (14). Based on the list, it distributes a transaction per each CS (15,16) to all the peers but only the PDL-transport manager with the ownership will take it (16), forward it to its associated Transport SDN Controller (17) and acknowledge its reception. Meanwhile, the Transport SDN Controller configures the CS (18). Once a CS is ready, the PDL-transport manager is informed (20) and then it generates another transaction for all the other peers (21,22). Again, only the CS requester will take it (21, and confirm its reception (23). Finally, once all the CS are ready and the NSSs stitched, the PDL-slicing manager updates the E2E NSI and informs about its completeness. To experimentally validate the presented architecture, we implemented it in our ADRENALINE testbed [6] as Fig.1-A shows. The Blockchain network is based on Ethereum due to its capability of using smart contracts and its faster block generation procedure (faster than e.g. Bitcoin). The testbed has four domains: an edge and cloud computing domains, both with its PDL-NSM module associated to a SONATA Service Platform (which has a NSM and a NFVO) and its VIMs and SDN controllers. In parallel, both packet and optical transport networks have their PDL-SDN associated to a TAPI-enabled Transport SDN controller [7].

Experimental Validation
To study the influence of Blockchain, an E2E Network Slice composed by two NSSs stitched with two unidirectional CSs through the optical transport network was designed. One NSS with a single network service in the Edge-DC 2 and the other NSS with two network services in the Core-DC. Before any deployment, the NSSs information and the SDN controller (optical and packet) transport contexts were distributed to all the Blockchain peers. Then, it was possible to request E2E Network Slices from any computing domain.
A set of tests was done to get the time values for the different actions involved in the E2E deployment: the computing (i.e., NSSs) deployment, the networking (i.e., both directions CSs) deployment and the Blockchain transactions. Analyzing the results in Fig.2-A, the Blockchain actions influence on the total E2E deployment time is very low. Comparing the mean time values between the Blockchain (4.51s) and the total E2E deployment actions (202.28s), the Blockchain time is a 2.23% because most of the E2E deployment time belong to the computing deployments (191.6s for the cloud NSS). Instead, the time to stitch the NSSs (4.08s) is similar to the Blockchain actions time (4.51s). Fig.2-B presents the cumulative distribution function (CDF) for the total E2E deployment time which shows that long time E2E deployments (219.2s) have higher probabilities (89.3%) to occur. Comparing the lowest time obtained (179s) with the Blockchain actions mean time (4.51s), the increment of time is a 2.55%. So, the percentage will reduce for longer E2E deployments.

Conclusions
The presented Blockchain-based MANO architecture allows a new collaborative methodology to deploy E2E Network Slices on a multi-operator infrastructure while maintaining their domain independence. Based on the results presented, a new way to manage computing resources across transport networks is feasible.