# A Secure Link-Layer Connectivity Platform for Multi-Site NFV Services
## 4 Implementation and Validation
### Functional Validation
#### 4.3.5 Validation Results  
After the successful deployment of the IPTV service, the multicast routing functions (VNF\({}_{\text{a2}}\), VNF\({}_{\text{b}}\), and VNF\({}_{\text{c}}\)) started exchanging PIM-SM protocol messages through the L2S platform. These routing functions were effectively connected at layer 2 as expected as if they were on the same local area network, despite being placed at different NFVI sites. The IPTV server (VNF\({}_{\text{a1}}\)) was configured to start the transmission of the video corresponding to a TV channel. To emulate a realistic TV channel stream, the server transmitted the content of a high-definition video file. The video was streamed to a specific multicast host group, represented by the IP multicast address 239.0.0.10. Figure 7b shows the transmission rate of the video content, measured at the multicast router of the head end (VNF\({}_{\text{a2}}\)). Approximately ten seconds after the video transmission is started, the virtual machine acting as the IPTV subscriber equipment at site \(B\) executed the _VLC_ tool, joining the multicast host group corresponding to the TV channel (the virtual machine was already active when the IPTV service was deployed). This caused the transmission of IGMP messages by the IPTV subscriber on the virtual link that connects it with the multicast router of site \(B\) (VNF\({}_{\text{b}}\)), to report its membership to the host group. In addition, the execution of the _VLC_ tool resulted in the exchange of PIM-SM messages by the multicast router VNFs across the L2S platform. This created state in the multicast router VNFs, supporting the dissemination of the multicast video traffic from VNF\({}_{\text{a1}}\) to VNF\({}_{\text{b}}\). The latter forwarded the received video traffic onto the virtual link towards the IPTV subscriber equipment of site \(B\), where it was consumed. Figure 7a exhibits the throughput of IGMP traffic received and transmitted by the multicast router of site \(B\) (\(\mathrm{VNF_{b}}\)) on the link towards the IPTV subscriber equipment, for the whole duration of the validation process. It also shows the throughput of the PIM-SM traffic observed by that multicast router. The picture reflects the periodic nature of IGMP and PIM-SM traffic, which is needed to maintain the multicast state at the different entities of the IPTV service. Figure 7c shows the throughput of the video traffic delivered on the link to the IPTV subscriber equipment of site \(B\), measured at the interface of \(\mathrm{VNF_{b}}\) on that link. The IPTV subscriber equipment of site \(C\) tuned in to the IPTV channel 30 seconds after beginning the video transmission, starting the _VLC_ tool. This resulted in the corresponding execution of IGMP and PIM-SM procedures, and the consequent delivery of the solicited video on the virtual link towards the IPTV subscriber equipment of site \(C\). Figure 7d represents the throughput of the received video, measured at the interface of \(\mathrm{VNF_{c}}\) towards the IPTV subscriber equipment. We want to highlight that our platform enabled the exchange of inter-site multicast traffic among VNFs, even though multicast routing was currently disabled at the edge routers of our NFVIs (note that whereas multicast routing could be enabled within 5 TONIC premises,  
Figure 7: Operation of the IPTV service. this feature is not available over the commercial fiber-optic Internet access of the portable NFVI). The distribution of video content within the IPTV service proceeded as expected. The video was played out normally at the laptop acting as the IPTV subscriber equipment at site \(C\), with no skipped or freezing video frames. The throughput of the received video streams (represented in Figure 7c,d for sites \(B\) and \(C\), respectively) closely matched the rate at which the video was transmitted from the IPTV server (shown in Figure 7b). For reference, the throughput graphs also indicate the average bitrate of the high-definition video file used in the validation.