## 6 Verification and Results
### Episode 1: Packet Forwarding and Provisioning (req: i, iii, iv, vi)
#### 6.1.1 Service Provisioning Times  
From an end-user perspective, it is expected that their NFV ISP provides them with on-demand service provisioning and a secure infrastructure. We developed episode 1 in order to provide a Proof-of-Concept demonstration of the implemented architecture with respect to service provisioning. This demonstration also shows that the layered NSH header architecture is capable of forwarding encrypted SFCs according to a network forwarding policy in a relatively fast and reliable manner. Specifically, we developed a test that demonstrates that the designed architecture is able to set up an SFC according to the requirement of hop-by-hop encryption with a new NSH header (req: i, iii) and by the use of RESTconf flow distribution (req: iv). We provide these demonstrations by monitoring the provisioning time of a subset of the services in the architecture. The creation of VMs, the altering of the routing paths and the reestablishment of the encryption keys, result in network outage from an end-user perspective. Hence, we measured this time by monitoring network outage during service provisioning. We set up a simple Iperf measuring test between the client and server and experimented with altering the SFC. We altered the SFC from SF1 \(->\) SF3 to SF1 \(->\) SF2 \(->\) SF3. This simulated turning on and off the SF located at ISP-B and implicitly adding and removing a service from the SFC. By sending a fixed stream of 64 packets per seconds from the client to the server, we measured the network provisioning time by monitoring the packet loss during these service alternations. One packet loss of 64 packets corresponds to approximately 15,63 ms of a network outage. The measurements were aiming to measure seconds. Therefore, we set the packet rate at 64 pps. This also ensured a minimisation of a potential packet loss due to unrelated reasons such as collisions, traffic congestion or buffers overflows. We differentiated the measurements (Table 1) in three types. Full provisioning (1a) with no traffic flow during provisioning, Soft provisioning (1b) where the data traffic runs while new services are instantiating and (1c) we also measured the periodic key change provisioning times. Setting up an additional SF with encrypted links includes; (1.a-1) instantiating the SF VM, (1.a-2) instantiating two EF VMs, (1.a-3) authenticating the EFs and distribute the encryption keys and (1.a-4) distribute the new flow routes. Hence, we measured the provisioning time for each of the sub-processes and summarized the total provisioning time (1.a). The instantiation of the SFs (1.a-1) and the EFs (1.a-2) are the most time-consuming processes. However, these processes can be instantiated before the traffic flows are redirected into the new VMs. This also includes the setup and authentication of the EFs (1.a-3). We refer to this process as soft provisioning (1.b). It is expected that such a planned provisioning is most common. Here,the distribution of the flow rules is not assigned before the VMs are fully provisioned and EFs are authenticated. This scheduling of network provisioning significantly decreases the network outage time. However, for non-controlled events, such as hardware failure, the re-provisioning time increases due to the failure detection time and due to the lack of pre-instantiated VMs (see Section 6.2). The periodic key change provisioning time is the most frequent provisioning process. It is assumed that the encryption keys are set up to change once every hour. However, for measurement purposes, we set the periodic key change interval to 5 s. Our previous work [7] indicated that the periodic key change provisioning had limited effects on the network outage time. This is also confirmed by these measurements where the network outage time for each key change is about 0.1 s (1c). From an end-user's perspective, the most relevant network outage times are the outages during the soft provisioning and during periodic key changes.