number of switches that connects them. We define two types of traffic steering functionalities as follows, depending on the information needed for identifying the steering policies. Basic traffic steering is based only on the Layer 3 and Layer 4 (L3-L4) headers, without any deeper inspection of packets. The policy is derived from subscriber and application policies. It does not involve any per-flow forwarding rules or state. Rather, it involves 5.2 Service Function Chaining setting up forwarding rules a priori, which are derived from configuration and can apply to an aggregate of many flows (e.g., all flows to a particular IP address block and/or port number). Basic traffic steering includes per-subscriber and application configuration, SO that different services may be applied according to individual subscriber preferences, as well as the other L3-L4 criteria described earlier. Service chains defined by the basic traffic steering mechanism are in effect starting from the first packet of a flow (e.g., TCP SYN packet). Therefore, services that are bypassed using basic steering do not see this first packet. Complex traffic steering is based on installing per-flow forwarding rules dynamically, in response to the first few packets of the flow being processed by the service. This implies the possibility of using deep packet inspection to analyze L5-L7 flow contents. Allowing more granular control over traffic flows based on higher-level application information, such as URLs, is a key advantage of complex steering. These per-flow rules are installed by the OF controller in response to notifications from an inline service such as DPI. Since these rules are installed reactively rather than a priori, and especially since TCP flow contents are not available for inspection by DPI until after the three-way handshake, the first packets of a flow will traverse a different initial service chain before a final service chain is established for that flow. So, any services that are only bypassed via complex steering will see the fi