# A Secure Link-Layer Connectivity Platform for Multi-Site NFV Services
## 2 Background on Multi-Site VNF Communications
### Layer-2 Inter-Site Communications  
The capability to provide layer-2 mechanisms to interconnect VNFs, at any level (intra- or inter-site) is an extremely beneficial asset for NFV providers. On the one hand, per-service layer-2 communications addresses the concerns described above for the layer-3 approach (e.g., isolation). On the other hand, developers are normally used to implement and validate their applications in their own local environments. This usually implies that connectivity is achieved using a simple switching function (physical or virtual), and also that all the VNFs share the same IP addressing space. It would be simpler for them to export their applications if NFV providers offered an equivalent communications environ ment. In fact, benefits resemble those that originated the creation of layer-2 end-to-end connectivity services to offer layer-2 VPN services for enterprises years ago [19]. In layer-2 scenarios, communication is based on the information located at the Ethernet header, mainly MAC addresses that need to be learnt by the different switches participating in the communication path, and on switching/bridging mechanisms. As for layer-3 communications, such path may be direct (e.g., a dark fiber communicating two switches at different sites) or can be provided by any of the different transport services that are normally supported by current routers (i.e., layer-2 VPNs [20]). The latter type of solutions permits in fact traversing third-party networks (e.g., the Internet). In the layer-2 communications approach, the VNF whose communication peer is at a remote site is typically provided with a VLAN (non-VLAN layer-2 forwarding is of course also possible, but there would be no isolation, incurring in the same issues as the layer-3 mechanisms above). That VLAN, or VLANs, instead of terminating at the edge router, are extended to the remote edge router (e.g., bridging), which in turn extends them to its local VNFs. Edge routers no longer act as IP next hops; on the contrary, all VNFs of a multi-site service share the same VLAN and the same IP address space, and have link-layer visibility. In our reference example shown in Figure 1, VNF1b and VNF1c would be attached to the same VLAN, which would be provided by the administrators of sites \(A\) and \(B\), and by the transport providers that maintain the network path between both sites (in this case, edge routers \(A\) and \(B\) would provide bridging functionalities). In layer-2 connectivity services, the learning procedures of the involved MAC addresses are exactly equivalent to those that happen on a single switch, which implies a certain level of complexity. Other notable problems that may occur are the traffic storms, caused by BUM (Broadcast, Unknown Unicast or Multicast) traffic, the appearance of loops, which demand the use of spanning-tree-like protocols, and the limited scalability that due to these factors (and others) can be achieved, to name just a few. Conversely, benefits of layer-2 multi-site communications include the support of any type of layer-3 communication, even broadcast/multicast, the capability of running any layer-3 protocol transparently to the connectivity provider, the lack of routing interaction with the edge routers, or the already mentioned resemblance with simple local scenarios (i.e., those formed by a single switch) [19]. Having said this, it is worth mentioning that it is still not trivial to offer inter-site layer-2 connectivity services on the edge routers of NFV sites. Two reasons can be cited as the most relevant, as detailed in the following:  
**(1)**: **Scalability at the edge routers themselves**. It is a well-known fact that providing layer-2 services in a massive way demands a huge number of resources at the involved edge nodes. If all inter-site VNF connectivity services were to be provided at layer-2, and considering the amount of potentially interconnected VNFs, current implementations would just not scale.