# A Secure Link-Layer Connectivity Platform for Multi-Site NFV Services
## 2 Background on Multi-Site VNF Communications
### Layer-3 Inter-Site Communications
Going back to our example from Figure 1, edge router \(A\) should not only be configured to avoid data traffic flowing from the virtual link allocated to NS2 onto the virtual link of NS1. It should also be provided with filtering rules to prevent VNF2c and VNF2d from sending traffic towards VNF1b. These rules must necessarily be specified in terms of the IP addresses of the VNFs deployed at remote sites which may be problematic from a management perspective (e.g., to only allow the traffic addressed to VNF1b that is originated either at VNF1c or VNF1d). These addresses should be communicated among sites, hindering the automated deployment of isolated multi-site services. Moreover, the filtering rule set would have to be dynamically updated at the edge routers of every site upon the deployment, modification, and termination of multi-site network services. **(2) The multi-site nature of the NFV ecosystem is not oblivious to tenants**. In our reference example, the VNF forwarding graph of NS1, specified by the tenant re questing the service deployment in the corresponding network service descriptor, indicates that VNF1b and VNF1c should be directly interconnected at the link-layer. Nevertheless, in a layer-3 communications approach, traffic between both VNFs is forwarded by a chain of network routers. This necessarily means that the ten-ant needs to verify the network configuration of the VNFs after their deployment, to guarantee the functionality of the network service. Assuming that VNF1b and VNF1c provide network routing functionalities within NS1, VNF1c would be the next hop of VNF1b to reach VNF1d. However, to provide the expected service, the routing table of VNF1b must have an entry towards VNF1d using edge router \(A\) as next hop. Hence, the route set at VNF1b (and VNF1c) must be accordingly updated by the user as part of day-2 configuration. On the other hand, the network service may require VNF1b and VNF1c to share a LAN segment or a point-to-point link for their proper operation (e.g., because they might need to exchange local multicast traffic or execute specific routing functions [17]). In that case, the tenant may have to configure a tunneling scheme (for instance, VXLAN [18] or GRE [8]) to support link-layer communications between both VNFs over the layer-3 network interconnecting sites \(A\) and \(B\). We want to note that these day-2 configuration operations are generally undesirable, as they specifically require the intervention of the service tenant to set up a functional network service. Ideally, the multi-site nature of the NFV ecosystem should be concealed from the end user, who should be provided with a functional deployment of the network service honoring the VNF forwarding graph (that is, as if the network service were deployed on a single site). **(3)**: **Providing layer-3 inter-site communications among VNFs may require specific forwarding state to be set up at intermediate routers**. As an example, to make VNF1d reachable from VNF1a and VNF1b, the routing table of edge router \(B\) must be updated, to include an entry pointing out to VNF1d via VNF1c. To this purpose, either VNF1c runs a dynamic routing protocol supported by the edge router, and uses it to advertise a route to the LAN segment of VNF1d; or a static route is configured at the edge router by the site administrator. As another example, if multicast traffic is to be transmitted within a multi-site network service, a layer-3 communications approach would require multicast forwarding state to be created in the routers interconnecting the sites. However, multicast traffic may be prohibited by the policy rules of the sites and/or the Internet service providers involved in the inter-site communications. **(4)**: **Use of Network Address Translation (NAT) functionalities**.