2.8 Per-Flow Consistent Updates
2.8.1 Service Chaining
It is possible that due to network load or other dynamic considerations, some of the flows in a network need to be rerouted [76]. In Figure 2.1(a), let us assume that some of the
flows traversingsa−s1a−s1b−s1c−sc need to be re-routed tosa−s2a−s2b−s2c−sc. At the same time, instead of the Service Chain N F1a−N F1b, now they must traverse N F2a−N F2b, where N F2a is another instance of N F1a and N F2b is another instance of N F1b. Besides, let us assume that the switch s1c maintains the state associated with a flow, for instance, to check which flows are large [118]. Therefore, if flows are moved from the first path to the second, the states associated with the NFs as well as the switches must be moved. Instead, a PFC update may be performed, where only the flows that begin after the RU is effective (the new flows), are moved to the new path, while the rest of the flows (the old flows), continue to use the old path. The forward and reverse flows of a given flow, new or old, will thus traverse the same SC. In this example, all the switches are affected - the switches in the new path are affected because new rules for the forward and reverse flows need to be added to them, and in the old path, because rules need to be deleted from them. We shall first examine the existing PFC solutions and why they are inadequate.
Existing PFC solutions: In order to keep track of each individual flow, a microrule is added for each flow, where the match for the rule is based on the header fields that uniquely identify a flow. A time-out is associated with each microrule which is triggered when no matches take place for the time-out period and a suitable associated action is taken. The microrule is an exact copy of the original rule, except that its headers match exactly that of a flow.
Devoflow [32] proposes a switch that can support a “clone” command and usage of this to support PFC is examined by Reitblatt et al. [111]. When this command is set for a rule with wildcards in an ingress switch, the switch installs a microrule for each new header seen that signals a new flow. Subsequent packets of that flow match that microrule.
Consider an SDN whose switches have a set of rules of version 0 (v0) installed first, that needs to be updated to version 1 (v1). The algorithm uses clone rules when any update is installed. Thus, for example, allv0 rules are clone rules. This results in v0 microrules being generated and installed for every flow, right after thev0 update. To update withv1 rules, they are installed and they too are made clone rules;v0 rules are deleted at the same time (v0 microrules are not deleted now). Now a new flow will create a new microrule and v1 rules will apply while old flows will match their existing microrules and sov0 rules will apply. However, this solution has the following issues: 1) Microrules are always present and
the overheads of these microrules will affect the performance of a switch. 2) It is unclear when the microrules must get deleted. 3) Since the rules are versioned, all the tables in all the affected switches need to be modified for one RU, thus making the solution inefficient and limiting the number of disjoint RUs to 1. Alternately, all the paths affected by an RU may be found and rules with the new version installed only in all the tables in all the switches in those paths, which is computation intensive and inefficient, especially so if wildcarded rules are used in switches. 4) This solution does not consider synchronizing forward and reverse flows. 5) Cloning rules is not supported on real switches. Softcell [61]
is the only existing solution as far as we know, that performs PFC updates considering forward and reverse flows, but it usessoftware switches at the edge that can generate one rule per flow and is meant only for a specific network architecture for a cellular network.
Existing non-PFC solutions:Instead of a PFC update, a loss-free and order-preserving state migration (LOSM) [130, 45], intended for scaling NFs in and out, where the state of all flows and the flows themselves are moved consistently with the migrated state to the new NFs may be considered. Another solution, TFM, decouples state migration and packet transfer using a TFM Box, developed as a virtual NF implemented on the source and destination NFs, thus impacting scalability. It also incurs additional updates to switches to forward packets to the TFM box. However, these solutions are specified only for individual NF instances and not for NF chains [136]. A simple extension of the state of the art mechanism intended for NF migration to be able to support movement of a flow from one service chain to another (such as TFM [130]), is complex and inefficient as it requires movement of packets already in transit involving several NFs, and buffering packets. Another LOSM solution, OpenNF [45], forwards packets to the controller and requires further consistency preserving updates, for steering flows in and out of the con- troller, besides making the controller a bottleneck. Stratos [44] migrates the affected NF instances themselves to the new path, in the case of a network bottleneck, which is an expensive solution. Besides, it requires one rule per flow. Split/Merge [107] also provides state migration but it is not loss-free and order-preserving. E2, which does not require state migration, routes all flows through the old NF first [103], thus expecting NFs to have high processing capability; additionally, it requires installation of rules other than those warranted by the RU. All the above require changes to NFs themselves [52]. While none of the above migrates switch states, SwingState [82] does, but it does not migrate
the states of NFs. Woo et al. [132] use a Distributed State Object to store states associ- ated with flows to facilitate easy migration of flows. However, this requires all NFs to be written using their framework and does not consider stateful switches. Using a PFC RU circumvents the need for migrating the states of switches as well as NFs. Additionally, any number of NFs and stateful switches may be present in the path of the flow.
Session based solutions: Nicutar et al. [98] propose using MPTCP to insert middle- boxes into sessions. But this requires a TCP session to be first established before insertion of a middlebox. If a particular session needs to be blocked, the middlebox/NF is not al- ready in place to take that decision, thus preventing the inserted NFs from blocking sessions if required and causing security issues. Dysco [135] uses a session level protocol that requires an agent installed in all hosts, including NFs, and therefore does not consider stateful switches in the path. Also, it requires buffering of packets at the agents during migration, like the LOSM solutions.
Timed update and flow migration solutions: Existing timed update solutions [138, 91,92] do not preserve PFC or tolerate practical time asynchrony, scheduling inaccuracies of switches or variable controller-switch delays. Ludwig et al. present an algorithm to [79]
preserve waypoint enforcement only forpackets, and do not preserve PFC. A large body of work (Table 3 in [41]) deals with migrating flows while preventing congestion. However, these do not preserve PFC.
In summary, we need PFC RUs to modify only the affected switches and the affected rules, and support wild carded rules. They must be able to perform an unlimited number of concurrent disjoint updates. They must not require changes to NFs or buffering of packets or addition of new rules, yet must be practical. They must be able to support migration of flows from more than one NF (a service chain) or a set of stateful switches or a combination of both. No existing solution addresses all the above.