 approach is to configure one or more static service chains where each service is configured to send traffic to the next service in its chain. A router classifies incoming traffic and forwards it to services at the head of each chain based on the result of the classification. However, this approach does not support the definition of policies in a centralized manner and instead requires that each service to be configured to classify and steer traffic to the appropriate next service. This approach requires a large amount of service-specific configuration and is error prone. It lacks flexibility as it does not support the steering of traffic on a per subscriber basis and limits the different service chains that can be configured. Getting around these limitations would require additional configuration on each service to classify and steer traffic. Policy-based routing: A third approach is to use a router using policy-based routing and for each service to be configured to return traffic back to the router after processing it. The router classifies traffic after each service hop and forwards it to the appropriate service based on the result of the classification. However, it suffers from scalability issues as traffic is forced through the router after every service. The router must be able to handle N times the incoming traffic line rate to support a chain with N + 1 services. Policy-aware switching layer: Recently, it is proposed to use a policy-aware switching layer for data centers, which explicitly forwards traffic through different sequences of middleboxes. Each policy needs to be translated into a set of low-level forwarding rules on all the relevant switches. Often SDN is used for programming these policies. We will elaborate more next. The components of StEERING [108] are shown in Figure 5.5. Our system uses a logically centralized OpenFlow-based controller to manage both switches and middleboxes. The black solid line and grey solid line in Figure 5.5 show two different service paths: the black line traversing 