## 5 System Model
### Causal Order Delivery  
Causal order delivery is a fundamental property in the field of distributed systems, and it is required for various distributed applications (e.g., distributed simulation). In fact, it is useful for synchronizing distributed protocols by inducing the causal order of events. Indeed, this property means that if two send messages are causally related and are sent to the same process \(p_{i}\), then their delivery should be held according to the causal order, that is by respecting the send order. The author of [29] showed that in order to ensure a causal order delivery for a multicast communication, it suffices to ensure the causal delivery of immediately related send events. Therefore, to ensure message-data packet causal order delivery in SDNs, the set of events is determined to be \(R=\{SdM(m),FwdP(pkt)|m,pkt\in MP\}\). For simplicity, we represent the two send events \(SdM(m),FwdP(pkt)\) as \(send(mp)\). Formally, the message causal delivery based on the IDR (see Definition 2) is defined for the SDN context as follows:  
**Definition 3**. : _Causal order delivery in the SDN context:_  
\[\forall((send(mp),send(mp^{\prime})|mp,mp^{\prime}\stackrel{{ \triangle}}{{=}}match)\in R,send(mp)\downarrow send(mp^{\prime})\]  
_where \(Dest(mp)=Dest(mp^{\prime})\)_  
\(\Rightarrow delivery(mp)\rightarrowdelivery(mp^{\prime})\)_._  
Therefore, causal order delivery establishes that if the diffusion of a message-data packet \(mp\) causally precedes the diffusion of message \(mp^{\prime}\), then the delivery of \(mp\) should precede the delivery of \(mp^{\prime}\) at a common destination process. **6. Modeling the TFL Pattern from a Temporal Perspective**  
In this section, we study the use of physical time as a tool to ensure consistent network updates, and we analyze if physical time will be sufficient to deal with the TFL inconsistency problem. We return to the flow swap update scenario of Figure 2. In this scenario, the topology is composed of an OpenFlow controller and two switches (\(S_{1}\) and \(S_{2}\)). According to our network model (see Section 5), the set of processes for this scenario is \(P=\{cp,rp_{1},rp_{2}\}\), where \(cp\) is the OpenFlow controller and \(rp_{1},rp_{2}\) represent the switches \(S_{1}\) and \(S_{2}\). During the update, the OpenFlow controller \(cp\) sends to \(rp_{1}\) a _FlowMod_ message \(m_{1}=(cp,1,(match,delete),rp_{1})\) where a \(pflow\triangleq match\), and then, it sends to \(rp_{2}\) a _FlowMod_ message \(m_{2}=(cp,2,(match,add),rp_{2})\) where also \(pflow\triangleq match\). The routing process \(rp_{2}\) receives \(m_{2}\) and installs the entry directing all \(pkt_{i}\in pflow\) to \(rp_{1}\). Accordingly, \(rp_{2}\) directs \(pkt_{1}\in pflow\) to \(rp_{1}\) (see Figure 3). Subsequently, \(pkt_{1}\) enters \(rp_{1}\) before \(m_{1}\) is delivered to \(rp_{1}\) due to a delay of the reception. Finally, as \(pkt_{1}\) matches the entry already installed in \(rp_{1}\), the former ends by redirecting \(pkt_{1}\) to \(rp_{2}\), generating a TFL between \(rp_{1}\) and \(rp_{2}\). Upon analyzing the communication diagram corresponding to the execution diagram of Figure 3, we can observe that the TFL between \(rp_{1}\) and \(rp_{2}\) is created when the transmission time interval of \(m_{1}\) is greater than the transmission time interval of \(m_{2}\) plus the packet forwarding time of \(pkt_{1}\in pflow\) to \(rp_{1}\). We formally define the TFL pattern from a temporal perspective. **Definition 4**. : _We have a \(match_{\lambda}\in MATCH\) and two OpenFlow messages \(m\) and \(m^{\prime}\), where \(m=(cp,t_{cp},(match_{\lambda},delete),rp_{i})\) and \(m^{\prime}=(cp,t^{\prime}_{cp},(match_{\lambda},add),rp_{i})\), such that (i) \(time(m)<time(m^{\prime})\), (ii) \((rp_{i}\
eq rp_{j})\) and (iii) \(\exists\) a forwarding path \(fpath_{\mu}=\{rp_{i},\ldots,rp_{j}\}\) from \(rp_{i}\) to \(rp_{j}\), such that intermediates \(rp_{r}\) may exist where \(fpath_{\mu}\in FPATH\ \mid\ fpath_{\mu}\triangleq match_{\lambda}\).