Table 6.2 shows the activities along with their duration and frequency attributes and their values in a network. These activities are those that can be different in terms of their duration and frequency in a programmable network and traditional (non-programmable) network.
Table 6.2.: List of activities along with their attributes (i.e. duration and frequency) and their values considered in calculation of OPEX (Activity-based approach).
Activity Name Duration Frequency
SDN MPLS SDN MPLS
Service Provi-
sioning 1 hour 8 hours per connection per connection Device-Level
Configuration 1 hour 4 hours
per 9K connec- tions per device
per 2K connec- tions per device Topology-based
Modification 1 hour 4 hours
when new re- source added
when new re- source added Fault Detection 30 mins 2 hours Every 9K hours
per device
Every 2K hours per device
Fault Reparation 2 hours 10 hours Every 9K hours per device
Every 2K hours per device
It is difficult to gather precise input values for these parameters because they are proprietary and relative and companies are not willing to publicly share them either. These value assumptions constitute an average of each parameter based on Internet research, literature review ( [250–254]), and our discussions. “Duration” refers to the time that an activity takes to be finished while “Frequency” refers to the number of times that an activity occurs in a network. In other words, duration refers to “how long”, frequency refers to“how many times” questions, respectively.
“Service Provisioning” activity refers here to providing a service first time to an end-user (or customer) while the service had already been implemented/created in the network. This activity includes all tasks that are necessary to start, update, test and/or stop the customer’s service. Sample tasks in this activity may be, not limited to, updating necessary databases for the customer, traveling to site to configure corre- sponding cabinets on the field, and so on. This activity is applied for each connection request in a network. We assume this activity takes much less time in a SDN network compared to MPLS network due to the automation feature that programmability adds to the network.
“Device-level Configuration” activity can be characterized by converting network- wide policies to device-level configurations. These configurations are different than and/or independent of customer service provisioning requests and applied on the current network devices. Some of the sample tasks in this activity may be, not lim- ited to, routing protocol-based configurations such as updating BGP preferences, or OSPF/IS-IS routing algorithm etc., resource management-based updates to devices, updating ACLs, VLANS for packet filtering, testing devices, and so on. In SDN case, network devices are simple devices without any intelligence (i.e. no routing protocols etc.). Also, they are accessible and configurable from a remote control points (i.e. controllers). Therefore, we assume it takes less time to configure a network device compared to traditional network devices. In traditional networking case, devices are more complex due to the intelligence. It is not easy, if not impossible, to access and configure from a remote point. Also, configuring a device may require some other con- figurations in neighboring devices for a complete and accurate configuration. There- fore, we assume it takes more time to configure a network device compared to SDN devices. In addition, we assume that these types of configurations may be needed more frequent in traditional network devices case compared to SDN case because traditional devices are complex. Therefore, they may require more interventions per device from network administrators to efficiently operate in the network.
Tasks in “Topology-based Modifications” activity can be the similar or same as in the “Device-level Configuration” case. However, this activity is triggered only when a new device and/or link is added (connected), removed, and replaced in the net- work. Also, any modification in the network topology can require configurations by administrators in other (particularly nearby/neighbor) devices to ensure the coordi- nation among the network devices. As explained in the “Device-level Configuration” activity, we assume it takes longer in MPLS case compared to SDN case due to the same reasons. We assume that certain number of connections in the network result in topology based modifications (adding/replacing new device(s)/link(s)) in the net- work. This modifications can be due to limited memory size of the devices, or adding network resources such as bandwidth etc., due to inefficient resource management capabilities of the network architecture and so on. We trigger this activity in this study when there is not enough resources and therefore new links and devices are added to the network in the experiments.
“Fault Detection” activity does not refer to the path failure detection problem, which is well-studied and done in milliseconds in both SDN and traditional networks. Detecting a network failure is the first step to recover from it. However, the failure detection or identifying the failure (i.e. reason(s), location, type, time etc.) may not be a straightforward task in a network. Although there are certain dedicated software tools (e.g. SNMP) to help detect a failure, they may not help pinpoint the aforementioned attributes of the failure since they usually throw a simple alarm(s) when certain monitored network parameters exceed predefined thresholds. However, this process can be done in different duration and with(out) human-device interaction depending on the network architecture. For example, since SDN provides real-time global full network view on network devices and links, this process can be shorter and easier compared to a traditional architecture. Some sample tasks in this activity may be, not limited to, checking network cable(s)/devices with physically or through software tools using probing techniques etc. to pinpoint it, checking network log files, and so on. Frequency attribute of this activity represents the MTBF (Mean Time
Between Failure) and we assume longer MTBF value for traditional devices owing to the complexity they come with and overhead they handle in a network compared to SDN devices.
“Fault Reparation” activity includes tasks necessary to fix a detected failure in the network. After being informed and detected a failure, following tasks may be applied depending on the network architecture: Analysis (interacting multiple devices personally on the site or using a controller), travel by technicians (to the place of failure), fixing the failure (with device configuration), testing devices to verify the repair, and so on. Duration attribute of this activity represents the MTTR (Mean Time To Repair) and we assume longer MTTR value for traditional devices due to the complexity and proprietary status compared to SDN devices.
These activities are not the only ones in a network and may not be precise re- garding their duration and frequency. Network administrators can classify and define different activities depending on their network. Furthermore, the granularity level of activities may result in discrepancy in calculation of OPEX cost in the network.