esigned according to a VNF forwarding graph (VNF-FG) Chaining based on customer policy/service Several VNFs can be defined in a chain including host and middle box VNFs as defined in Section 3.1.3. Middle boxes can alter the flow of traffic. For example, a firewall can drop packets or an appli- cation gateway can change the path based on the type of traffic. A NAT function can modify the packet. So a service chain replaces the traditional cabling that was used to interconnect functions, it does not necessarily dictate the end-to-end flow across all VFs for every packet flow. Service chains are not a new concept; we have been chaining functions together in service pro- vider networks for many years. The challenge in the existing architecture is that those chains were static and dictated by the physical cabling installed between the devices. The key difference now is that these chains can be defined in software and implemented using SDN capabilities within the NFVI. This allows for on-demand deployment of services where interconnection between multiple functions is needed to provide an end-to-end service. For example, consider the introduction of a security service into an enterprise VPN or extending a VPN into a cloud service provider. These are capabilities supported today with AT&T Flexware and Netbond services, respectively; this is covered in more detail in Chapter 10. Figure 3.8 depicts an example of a service chain that can be defined through a series of physical functions. When these functions become VFs on an NFVI, the connection between them can be defined in software and controlled by the SDN infrastructure. This is illustrated in Figure 3.9 and will be covered in more detail in Chapter 4. Service chains require connectivity between functions that may be distributed on different net- work segments, different servers, and maybe even located at different physical locations. In order Building the Network of the Future Physical Data Path Service Chain Intrusion Detection Switch Firewall Switch Switch Router 