domly distributed to the POP overlay edges, without the knowledge of the underlay, congestion and packet loss could occur, resulting in SLA violations. This happens in the normal course of mapping enterprise flows to vCPE resources and Internet peering, and it is true when remapping enterprise flows in case of failures. SLA verification: By cloudifying and dynamically mapping traffic to resources, we gain savings and decoupled manageability, but we now have to prove per flow that we still meet the enterprise SLA just as well as with static local provisioning. Per-flow SLA and con- nectivity verification can also trigger additional VM provisioning without interrupting services. Resource defragmentation: As we decouple orchestration and the system is running, events will trigger additional allocations, extended service chains, and compensation for blade or CPU failures. But because of cloudification, we can constantly run in the background proceeds that reallocate vCPEs in dense hardware configuration, gracefully ramping down fragmented VNFs till they are "garbage collected" freeing hardware for further dense orchestration. 5.4.1 Requirements The design of our vCPE platform is based on a set of key requirements we identified by analyzing current SLA structure and management models as well as SMEs common pain points. Our approach highlights elasticity, flexibility, efficiency, scalability, reliability, and openness as critical components to support the goals of NFV. 5.4 Virtualized Customer Premises Equipment Elasticity: Building on top of NFV, vCPE should be able to leverage the benefit of running instances in the cloud: multiplexing and dynamical scaling. For multiplexing, it allows the same NF instance to serve multiple end users in order to maximize the resource utilization of the NF. On the other hand, for dynamical scaling, when the demand changes, the network operators should be able to dynamically increase/decrease the number and/or size of each NF type to accommodate the changing demands. This in turn will 