# Software-Defined Reconfigurability, White Boxes, and Abstraction

Nicola Sambo, Alessio Giorgetti, Andrea Sgambelluri, Piero Castoldi, Luca Valcarenghi

► To cite this version:

Nicola Sambo, Alessio Giorgetti, Andrea Sgambelluri, Piero Castoldi, Luca Valcarenghi. Software-Defined Reconfigurability, White Boxes, and Abstraction. 23th International IFIP Conference on Optical Network Design and Modeling (ONDM), May 2019, Athens, Greece. pp.15-25, 10.1007/978-3-030-38085-4_2. hal-03200693

HAL Id: hal-03200693

https://inria.hal.science/hal-03200693

Submitted on 16 Apr 2021

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Software-defined reconfigurability, white boxes, and abstraction

N. Sambo, A. Giorgetti, A. Sgambelluri, P. Castoldi, L. Valcarenghi

Scuola Superiore Sant'Anna, Pisa, Italy
nicola.sambo@santannapisa.it

**Abstract.** Next generation networks – spanning from wide area networks to intra-datacenters – are expected to encompass devices and sub-devices from different vendors. Inter operability and vendor neutrality are now key topics for researchers and companies as a way to reduce costs avoiding to be tied to a single vendor. Also the management system is expected to be disaggregated from the hardware and possibly developed by a different company. An example is the *white box*, which disaggregates the software from the hardware and can be composed of modules from different vendors. Currently, NETCONF – based on YANG – is the protocol considered for the (re)configuration of white boxes. Discussions are being carried on to identify commonly agreed information models to guarantee vendor-neutral configuration and management of next generation networks.

In addition, emerging services (e.g., 5G) will impose the involvement of a variety of technologies (e.g., networks, datacenters) and resources (e.g., compute, storage, radio). Such heterogeneity will imply the cooperation of several business actors to bring services to the users. In such a scenario, the management of resources will require their abstraction in order to satisfy confidentiality as well as to increase scalability and, again, to provide information that is neutral with respect to the related vendor and technology.

In this paper, we propose to use NETCONF also for the exchange of resource information among different business actors considering the several network segments (wide area network, data centers, radio segment) involved in a 5G vertical. To this purpose, resource abstraction is proposed based on a YANG data model. An experiment will involve the (re)configuration of a wide area network composed of white boxes. Moreover, resource information (virtual links) will be exchanged through NETCONF with the objective of orchestrating resources.

**Keywords:** 5G, white box, disaggregated networks, YANG, NETCONF

## 1 Introduction

In the last years, a lot of interest within research and market has been directed to vendor-neutrality, inter-operability, and disaggregation of software from the hardware [1]. This movement started from network operators
and service providers with the objective of removing the traditional vendor-lock-in of their networks. Indeed, up to now, multi-vendor-interoperability is not guaranteed, thus network upgrades must be performed by the same vendor. Similarly, the management system is tied to the network and typically proprietary of the vendor. These limitations impede the market. Interoperability and vendor-neutral control and management permit operators and service providers to lower the costs avoiding to be tied to a single vendor and adopting the best of breed technologies. An example is the *white box* [2, 3], a node disaggregating the hardware from the software (e.g., management systems) that can also be assembled by modules from different vendors. The control of white box is performed via the NETCONF protocol [4] supporting vendor-neutral YANG data models [5–8].

In addition, emerging services such as automotive, e-health, video streaming, documentation of mega events will be supported through the coordination of several heterogeneous technologies in different network segments. Datacenters, radio, and network technologies will be involved in the service delivery to the user requiring the cooperation of different business actors, each one administrating a network segment [9]. Such business actors will have to exchange their domain information (e.g., latency) so that services can be orchestrated. In such a scenario, the management of resources in play will require their abstraction (i.e., a simplification exchanging a reduced set of information) [10] in order to satisfy confidentiality as well as to increase scalability and provide information that is neutral with respect to the related vendor and technology. In particular, regarding resources, 5G services will exploit *network slice*: i.e., a set of virtualized functions, connectivity, compute, and storage resources [11]. The European Telecommunications Standards Institute (ETSI) is defining standard interfaces to enable domain managers (each belonging to the related company) in the exchange of their resource information (e.g., abstracted connectivity and compute resources) [12].

In this paper, we will first describe the NETCONF protocol (which operates in a client/server way) and its use for the (re)configuration of a white box acted by a Software Defined Networking (SDN) controller. Then, we will propose to exploit NETCONF also to manage abstracted domain information in a 5G scenario, leveraging the native characteristics of NETCONF in handling servers. An experiment will be presented showing the configurability of a wide area network (WAN) based on white boxes. The information exchanged between the different business actors will permit to set up resources satisfying the proper level of quality of service (in terms of latency). To this purpose, reconfiguration will be acted without exchanging information about the technology or detailed information of the network.
<figure><img src="image_2.png" /><figcaption>Fig. 1. White box</figcaption></figure>

<table><caption>**Table 1.** Server describing configuration parameters of a cross connection</caption><thead><tr><td>Parameter</td><td>Value</td></tr></thead><tbody><tr><td>Input port</td><td>C</td></tr><tr><td>Output port</td><td>B</td></tr><tr><td>Central frequency</td><td>193.1</td></tr><tr><td>Width</td><td>37.5</td></tr></tbody></table>

## 2 NETCONF for white box configuration

A wide area network (WAN) based on flexible grid optical technology is assumed. In such a network scenario, white boxes (as the one shown in Fig. 1) assembled with several transponders, monitors, and filters (wavelength selective switches —WSSs) for switching and add/drop is considered as in [2]. The agent is the interface with the SDN controller. Regarding monitors, WSSs support the power monitor per channel, then other power monitors can be placed in the incoming and outgoing ports to measure the total channel power of the lines, as well as at the input and output of transponders. More advanced monitors (e.g., for filtering effects [2]) can be also assumed.

NETCONF, operating in a client server way, is responsible for the (re-)configuration of the white box. More specifically, NETCONF messages write or reports parameters’ values stored into a server describing the configuration and the state of the white box. Such server reflects the information model describing the white box through a set of parameters. NETCONF messages contain fields associated to these parameters. In particular, configuration parameters are written to the proper configuration values via the NETCONF <edit-config> message. Tab. 1 shows an entry of
<table><caption>**Table 2.** Server describing configuration parameters of a transponder</caption><thead><tr><td>Parameter</td><td>Value</td></tr></thead><tbody><tr><td>net bit rate</td><td>100</td></tr><tr><td>baudrate</td><td>28</td></tr><tr><td>modulation format</td><td>pm-qpsk</td></tr><tr><td>FEC</td><td>7</td></tr><tr><td>launch power</td><td>0</td></tr><tr><td>central frequency</td><td>193.1</td></tr></tbody></table>

<table><caption>**Table 3.** State parameters of a transponder</caption><thead><tr><td>Parameter</td><td>Value</td></tr></thead><tbody><tr><td>pre-FEC BER</td><td>0.00213</td></tr><tr><td>osnr</td><td>16.4</td></tr><tr><td>cd</td><td>5133</td></tr><tr><td>pmd</td><td>5.19</td></tr><tr><td>B</td><td>33.2</td></tr></tbody></table>

the server related to a node cross-connection. In particular, the NETCONF <edit-config> message, sent from the SDN controller to the agent, writes the values of the proper parameters: input and output ports, and the frequency slot characterized by a central frequency (in THz) and a width (in GHz). Then, the agent is responsible to locally act, according to these entries, the cross connection configuration by properly configuring the WSSs. In the case of transponders, the <edit-config> message writes into the server the configuration parameters of a specific transponder (identified with an id). An example of configured values is reported in Tab. 2: net bit rate to 100 Gb/s achieved with polarization multiplexing quadrature phase shift keying (PM-QPSK) modulation format, 7% of forward error correction (FEC), and 28 Gbaud of symbol rate, at a central frequency of 193.1 THz with a launch power of 0 dBm.

Then, besides configuration parameters, even state parameters are included. They can only be read and are typically used to describe monitoring information. There are two ways to report monitoring information to an SDN controller. The SDN controller can send a <get> message to the agent requesting for the value of a specific parameter. The second way is asynchronous and based on a subscription and notification mechanism. The SDN controller, through the <create-subscription> message, asks to be notified when a state parameter exceeds a given value decided by the SDN controller. Tab. 3 shows parameters monitored by a transponder through the coherent receiver: pre-FEC bit error rate (pre-FEC BER), optical signal to noise ratio (OSNR), chromatic dispersion (CD), polarization mode dispersion (PMD), and signal bandwidth B. Then, other servers will be present for power monitors.
<figure><img src="image_3.png" /><figcaption>Fig. 2. Scenario involving multiple network technologies and domains</figcaption></figure>

The next section describes how NETCONF messages can be used also for exchanging information about different network segments hiding the technology.

# 3 NETCONF for slice management

## 3.1 Scenario description

The considered scenario is shown in Fig. 2. A user identified with a mobile phone exploits a service delivered by connecting the user to two virtual network functions (VNFs). This connection is enabled by virtual links involving the radio segment, the WAN, and data centers. VNFs are created using virtual storage and compute resources of datacenters. A Network Function Virtualization Orchestrator (NFVO), associated with a service provider, is responsible to orchestrate all the network, storage, and compute resources of each domain with the objective of satisfying quality of service (QoS). Several service providers exploits a network and each provider holds an NFVO (NFVO_a and NFVO_b in Fig. 2). Each domain can belong to a different business actor and is coordinated by a manager with the view of all the resources. In particular, the WAN Infrastructure Manager (WIM) [12] is responsible for the WAN, a Virtual Infrastructure Manager (VIM) [12] for a datacenter, and a Radio Controller (RC) for the radio. Each WIM, VIM, RC have the detailed view of their domain and can rely on an SDN controller for (re)configuring the domain.

## 3.2 Slice management through NETCONF

According to the slice definition, slice management implies the management of network, storage, compute, and radio resources. ETSI defined a set of interfaces to enable a consumer block (the NFVO) to query information about
<figure><img src="image_4.png" /><figcaption>**Fig. 3.** YANG data models for abstracted (a) virtual link, (b) compute, (c) storage resources, and (d) coverage area.</figcaption></figure>

virtual network, storage, and compute resources to the VIM [12] to reserve, allocate, and terminate such resources. Moreover, an NFVO can also subscribe to notifications if the state of some resource changes and also if some performance parameter falls in a critical range. Network interfaces defined for the VIM are also considered between NFVO and WIM [13]. Based on the ETSI interfaces and operations, in this paper, we propose to use NETCONF to manage resource information about each domain, given the nature of this protocol in manipulating information stored into a server.

- `<get>` message: it can be used by the NFVO to query information about abstracted resources: virtual network topology (in the form of a list of virtual links), virtual compute and storage resources, radio coverage area

- `<rpc-reply>` message: upon query, this message can be used by a manager (e.g., WIM) to inform about abstracted resources. Fig. 3 shows our own-developed YANG models describing the abstracted virtual link, compute, and storage resources and the radio coverage area. The virtual link is described with an identifier, with the IP addresses of ingress and egress nodes, an overall cumulated latency, and the total and available bandwidth. The whole path connecting the ingress and egress node, as well as the used technology, is hidden to NFVO (for scalability or confidentiality reasons), while WIM maintains the complete view of its WAN. Storage resources are mainly described by storage values (maximum and available), while compute resources by CPU and RAM. The radio coverage area is described by a maximum distance (d-max) covered by the antenna and by a maximum and minimum bandwidth that can be used for a service in this coverage area. The maximum bandwidth is computed in proximity of the antenna, while the minimum one is at d-max. These values depend on propagation models, in particular on the signal-to-interference-noise-ratio, sometimes translated into a parameter named Channel Quality Indicator (CQI) [14]
- <rpc> custom message: once the NFVO has decided for a specific resource (e.g., a virtual link characterized by the proper latency), this message is used to request a manager for the allocation of a specific resource. Then, the manager, as an example the WIM, handles the allocation by relying on an SDN controller setting up (thus configuring white box in our case) a new lightpath between the ingress and egress pairs

- <create-subscription> message: an NFVO (e.g., NFVO<sub>a</sub> of Fig. 2) can request to a manager to be notified if a virtual resource changes (e.g., due to a service associated to NFVO<sub>b</sub> of Fig. 2) or if a monitored parameter falls in a critical range

- <notification> message: it is sent by the manager (e.g., a VIM) to NFVO if the event at the previous item occurs

Such use of the NETCONF protocol embraces the new trends of describing network elements and resources in a vendor-neutral way. Moreover, the abstraction models shown in Fig. 3 permit to describe all the resources in play also in a technology-neutral way. Indeed, regarding virtual link resources, NFVO is agnostic with respect to the technology that could be layer-3, optical, or any other. Thus, confidentiality reasons, vendor-neutrality, and also scalability are guaranteed.

# 4 Experimental demonstration

The experiment is focused on the WAN and involves a WIM and a NFVO (for more details about an implementation related to the exchange of information from a VIM, the reader can refer to [15]). WIM relies on an ONOS SDN controller [16] for WAN (re)configuration. The data plane is emulated except a node, which is based on a Lumentum white box actually configured and reconfigured. Emulated devices are associated to NETCONF servers based on ConfD [17] storing the YANG parameters describing each device. The WAN topology is shown in Fig. 4. A service sensible to the latency is considered. NFVO requests an abstracted topology to WIM between the nodes with IP addresses 10.10.255.9 (the white box) and 10.10.255.6. At this stage, we forced the network to have just one route (shown in Fig. 4) between the two nodes. WIM replies with the message shown in Fig. 5 reporting the available virtual link (with identifier 20) characterized by a latency of 10.0 ms. NFVO evaluates such latency as critical but, given the presence of just this virtual link, NFVO selects it. Then, ONOS establishes the considered lightpath. Fig. 6 shows the cross-connection information at the agent of the white box. Note that the XML content is based on a model proprietary of Lumentum, which describes the frequency slot with a start-frequency and an end-frequency instead of a central frequency and a width. Fig. 6 also shows the input port 5101 and the output port 5202. Given that as policy NFVO prefers virtual links with shorter latency, NFVO periodically interrogates the WIM about the possibility to use another virtual link
<figure><img src="image_5.png" /><figcaption>Fig. 4. WAN topology and lightpath associated to the first virtual link.</figcaption></figure>

```xml
<virtualLink>
  <virtualLinkId>20</virtualLinkId>
  <totalBandwidth>100</totalBandwidth>
  <availableBandwidth>100</availableBandwidth>
  <latency>10.0</latency>
  <ingressNode>10.10.255.9</ingressNode>
  <egressNode>10.10.255.6</egressNode>
</virtualLink>
```

<caption>Fig. 5. <rpc-reply> sent by WIM to NFVO reporting the available virtual link.</caption>

with shorter latency. At this stage we freed resources along an alternative route in the WAN. Consequently, WIM replies to NFVO with another available virtual link (with identifier 21). The related message is shown in Fig. 7 reporting the latency value of 8.5 ms and the same node pairs. Thus, NFVO can request to switch the service to the other virtual link exploiting a make-before-break approach. The new route is shown in Fig. 8, while Fig. 9 shows the cross-connection information at the agent of the white box after reconfiguration. With respect to Fig. 6, Fig. 9 shows a different output port (5201), which is the one attached to the intermediate node 10.10.255.7. The make-before-break approach is implemented by the NFVO by requesting to WIM the allocation of a new virtual link and, once getting the acknowledgement, by terminating the old virtual link. Fig. 10 shows the custom <rpc> including the identifier 21 to allocate the second virtual link, while Fig. 11 shows the custom <rpc> including the identifier 20 to terminate the second virtual link.
<figure><img src="image_6.png" /><figcaption>**Fig. 6.** Cross connection information at the agent of the destination edge associated to the first virtual link.</figcaption></figure>

<figure><img src="image_7.png" /><figcaption>**Fig. 7.** <rpc-reply> sent by WIM to NFVO reporting the second virtual link.</figcaption></figure>

# 5 Conclusions

This paper presented the NETCONF protocol for the (re)configuration of white boxes. A different use of NETCONF was also introduced considering a 5G/inter-datacenter scenario where a service is supported by an heterogeneity of resources (e.g., network, storage) and network domains. In such a scenario service orchestration requires the knowledge of resources at each domain to properly select them. However, given the presence of different business actors involved, resources must be abstracted and some information hidden. Abstraction of networks, datacenters, and radio coverage area were here provided. Thus, we proposed to use the NETCONF protocol not only for configuration but also for the exchange of abstract resource information (e.g., virtual link) between the several managers in play. An experiment focused on the wide area network was presented. In the experiment a service orchestrator (NFVO) interacts with the manager of the wide area network (WIM) with the objective of obtaining a virtual link guaranteeing a proper latency value, thus the QoS. Future works will be focused on the information exchange between NFVO and the radio controller. Then, the objective is to provide an overall demo involving radio segment, wide area network, and datacenters.
<figure><img src="image_8.png" /><figcaption>Fig. 8. WAual link.</figcaption></figure>

<start-freq>193675.00</start-freq>
<end-freq>193725.00</end-freq>
<attenuation>10.0</attenuation>
<blocked>false</blocked>
<power-target>0.00</power-target>
<power-target-tolerance>0.00</power-target-tolerance>
<input-port-reference>ne=1;chassis=1;card=1;port=5101</input-port-reference>
<output-port-reference>ne=1;chassis=1;card=1;port=5201</output-port-reference>

**Fig. 9.** Cross connection information at the agent of the destination edge associated to the second virtual link.

# 6 Acknowledgement

This work was supported by the EC through the Horizon 2020 5G-TRANSFORMER project (grant agreement 761536).

# References

1. E. Riccardi, P. Gunning, O. G. de Dios, M. Quagliotti, V. Lopez, and A. Lord, "An operator view on the introduction of white boxes into optical networks," *Journal of Lightwave Technology*, vol. 36, no. 15, pp. 3062–3072, Aug 2018.

2. N. Sambo, K. Christodoulopoulos, N. Argyris, P. Giardina, C. Delezoide, A. Sgam-belluri, A. Kretsis, G. Kanakis, F. Fresi, G. Bernini, H. Avramopoulos, E. A. Var-varigos, and P. Castoldi, "Experimental demonstration of a fully disaggregated
<add-connection xmlns="http://sssup.it/wim">
  <virtualLinkId>21</virtualLinkId>
  <ingressNode>10.10.255.9</ingressNode>
  <egressNode>10.10.255.6</egressNode>
</add-connection>

<caption>**Fig. 10.** `<rpc>` sent by NFVO to WIM to allocate the second virtual link.</caption>

<terminate-connection xmlns="http://sssup.it/wim">
  <virtualLinkId>20</virtualLinkId>
  <ingressNode>10.10.255.9</ingressNode>
  <egressNode>10.10.255.6</egressNode>
</terminate-connection>

<caption>**Fig. 11.** `<rpc>` sent by NFVO to WIM to terminate the first virtual link.</caption>

and automated white box comprised of different types of transponders and monitors,” *Journal of Lightwave Technology*, pp. 1–1, 2018.

<footnote n="3">3. L. Velasco, A. Sgambelluri, R. Casellas, L. Gifre, J. Izquierdo-Zaragoza, F. Fresi, F. Paolucci, R. Martinez, and E. Riccardi, “Building autonomic optical whitebox-based networks,” *Journal of Lightwave Technology*, vol. 36, no. 15, pp. 3097–3104, Aug 2018.</footnote>

<footnote n="4">4. R. Enns, M. Bjorklund, J. Schoenwaelder, and A. Bierman, IETF RFC 6241, June 2011.</footnote>

<footnote n="5">5. M. Bjorklund, IETF RFC 6020.</footnote>

<footnote n="6">6. M. Dallaglio, N. Sambo, F. Cugini, and P. Castoldi, “YANG models for vendor-neutral optical networks, reconfigurable through state machine,” *IEEE Communications Magazine*, vol. 55, no. 8, pp. 170–178, Aug 2017.</footnote>

<footnote n="7">7. in http://www.openconfig.net.</footnote>

<footnote n="8">8. in http://www.openroadm.org.</footnote>

<footnote n="9">9. P. Iovanna, T. Pepe, C. Guerrero, F. Moscatelli, A. Ksentini, C. F. Chiasserini, C. Casetti, J. Mangues-Bafalluy, L. Valcarenghi, B. Martini, X. Li, and G. Zennaro, “5G mobile transport and computing platform for verticals,” in *2018 IEEE Wireless Communications and Networking Conference Workshops (WCNCW)*, April 2018, pp. 266–271.</footnote>

<footnote n="10">10. M. Fiorani, A. Rostami, L. Wosinska, and P. Monti, “Abstraction models for optical 5g transport networks,” *IEEE/OSA Journal of Optical Communications and Networking*, vol. 8, no. 9, pp. 656–665, September 2016.</footnote>

<footnote n="11">11. “ETSI GR NFV-EVE 012 v3.1.1,” ETSI standard, 2017.</footnote>

<footnote n="12">12. “ETSI GS NFV-IFA 005 v2.1.1,” ETSI standard, 2016.</footnote>

<footnote n="13">13. “ETSI GS NFV-IFA 022 v3.1.1,” ETSI standard, 2018.</footnote>

<footnote n="14">14. “ETSI TS 136 213 V13.0.0,” *ETSI standard*, 2016.</footnote>

<footnote n="15">15. A. Sgambelluri, F. Paolucci, P. Castoldi, N. Sambo, P. Iovanna, G. Imbarlina, T. Pepe, and L. Valcarenghi, “Provisioning RAN as a service (RANaaS) connectivity in an optical metro network through NETCONF and YANG,” in *2018 European Conference on Optical Communication (ECOC)*, Sept 2018, pp. 1–3.</footnote>

<footnote n="16">16. in https://onosproject.org/.</footnote>

<footnote n="17">17. in http://www.confd.io/.</footnote>