TCAM-like table, with arbitrary bitmasks and rule priorities. Based on the direc- tion bit, it essentially scans the bits in the service set according to the global service ordering in that direction. The first or highest-priority service it finds will be the next destination. If the service set is empty, the next destination will be either the upstream or downstream router, depending on the direction bit. The next destination may be connected to the current switch or another one. If the destination is connected to a different switch, then the destination MAC address is set to the value corresponding to that service or router and the packet is transmitted out through an appropriate transit port. If the destination is directly connected, then the MAC addresses are updated as needed and the packet is transmitted out to the corresponding node port. 5.2.1.3 Handle Dynamics with the Microflow Table The Microflow table is added to handle dynamically generated rules. We assume that operators have static policies for the subscribers and applications. Therefore, the subscriber table and the application table can be programmed with static rules. But in real time, operators may want to add policies dynamically, or add more specific policies, or higher priority policies. Moreover, policies may be added according to the results of another middlebox, for example, DPI. We add the Microflow table to accommodate such dynamics. 5.2 Service Function Chaining If there is a hit in the direction table, the next table to be consulted will be the Microflow table. The key for this table is the direction bit together with the 5-tuples (source and destination IP address, IP protocol field, and TCP/UDP source and destination port) of the packet. The table contains exact-match entries used for selective complex steering of specific TCP/UDP flows. If there is a hit in this table, the next two lookups will be skipped. Thus, the rules in the Microflow table have higher priority than the rules in the subscriber and application tables. 5.2.1.4 En