Using R EVERSE PTP to Distribute Time in Software Defined Networks

Transcription

1 Using R EVERSE to Distribute Time in Software Defined Networks Tal Mizrahi, Yoram Moses Technion Israel Institute of Technology {dew@tx, moses@ee}.technion.ac.il Abstract Accurate time can be a useful tool in Software Defined Networks (SDN), allowing to coordinate network updates and topology changes, and to timestamp events and notifications. Moreover, accurate time is used in various environments in which software defined networking is being considered, making accurate time distribution an essential feature of SDNs. Accurate timekeeping requires a clock synchronization method, such as the Precision Time Protocol (). Contrary to the centralized SDN paradigm, is by nature a distributed protocol, in which every node is required to run a complex clock servo algorithm. We introduce R EVERSE, a clock synchronization protocol for SDN. R EVERSE is based on, but is conceptually reversed; in R EVERSE all nodes (switches) in the network distribute timing information to a single node, the controller, that tracks the state of all the clocks in the network. Hence, all computations and bookkeeping are performed by the controller, whereas the dumb switches are only required to send it their current time periodically. In accordance with the SDN paradigm, the controller is the brain, making R EVERSE flexible and programmable from an SDN programmer s perspective. We present the R EVERSE architecture, and discuss how SDN applications that require accurate time can use R EVERSE. Our experimental evaluation of a network with 34 R EVERSE enabled nodes shows that R EVERSE can be effectively used for coordinating events in networks at the same level of accuracy as provided by the conventional. I. I NTRODUCTION A. Background Software Defined Networks (SDN) introduce an architecture in which a network is managed by a centralized controller. The controller provides an Application Programming Interface (API) that allows SDN programmers to control the network using a high level programming language. The SDN approach defines a clear distinction between the data plane and the control plane; at the data plane, forwarding decisions are taken locally at each switch in the network, while the control plane is managed by a centralized entity called the controller, overcoming the need for complicated distributed control protocols and providing the network operator with powerful and efficient tools to control the data plane. Using Time in SDN. The most well-known SDN protocol is Open. Open, as defined in [1], [2] does not make explicit use of time and synchronized clocks. However, a recently introduced approach [3], [4] suggests the usage of accurate time to coordinate network updates in a simple1 manner, reducing packet loss and anomalies during configuration or topology changes. Accurate time can be a useful The Israel Pollak academic chair at Technion; this work was supported in part by the ISF grant 1520/11. 1 Compared to other update approaches [5], [6] that require a potentially complex multi-step procedure. (a) Conventional (b) R EVERSE -enabled SDN Fig. 1: Time distribution in and R EVERSE tool in various scenarios in the dynamic SDN setting, e.g., coordinated topology changes, resource allocation updates, and accurate timestamping for event logs and statistics collection. An Open extension [7] has been proposed, allowing timebased updates. This extension is currently under discussion in the ONF Extensibility working group. Distributing Time over an SDN. Accurate time is required in various different environments, from mobile backhaul networks to power substations. The recent interest in SDN in some of these environments (e.g., [8]) gives rise to the problem of distributing accurate time over SDNs. Clock synchronization in SDN. An SDN that either distributes time between its end-points or makes explicit use of accurate time, requires a clock synchronization protocol. The Precision Time Protocol (), defined in the IEEE standard [9], is a natural candidate, as it can provide a very high degree of accuracy, typically on the order of microseconds (e.g. [10]) or better, and is widely supported in switch silicons. However, using in SDNs presents a challenge: one of the key properties of SDN is its centralized control plane. However, is a distributed control protocol; the master clock is elected by the Best Master Clock Algorithm (BMCA), and each of the s runs a complex clock servo algorithm that continuously computes the accurate time based on the protocol messages received from the master clock. Indeed, a hybrid [2] approach can be taken, where the SDN operates alongside traditional control-plane protocols such as. Our approach is to adapt to the SDN philosophy by shifting the core of its functionality to the controller. B. Contributions In this paper we introduce R EVERSE, a novel approach that addresses the dichotomy above; in contrast to the conventional paradigm, where a master clock distributes its time to multiple clocks (Fig. 1a), in R EVERSE (Fig. 1b) there is a single (the controller) and multiple (the switches). Every switch distributes its time to

2 the controller, and the controller keeps track of the offsets between its clock and each of the switches clocks. This relieves the switches of any complicated computations, and does not require message exchange between switches, as all protocol messages are exchanged with the controller. More importantly, leaves the complex algorithmic functionality to the controller; the clock servo algorithm can be modified or reprogrammed at the controller without upgrading switches in the network, or can be dynamically tuned and adapted to the topology and behavior of the network based on a network-wide perspective. Notably, the main difference between and RE- VERSE is the direction of time distribution; in RE- VERSE time is distributed in an all-to-one fashion rather than s one-to-all nature. Hence, the accuracy of conventional and should be similar, given that all other aspects of the network are the same. is defined as an IEEE 1588 profile. 2 Since switches function as conventional, our approach is applicable to existing implementations of -enabled switches. Note that the approach can be applied to other synchronization protocols, e.g., the Network Time Protocol (NTP) [11]. We show how is used in two main scenarios: (i) in an SDN that uses time to coordinate configuration updates and notifications, and (ii) in an SDN that distributes accurate time between its end-points or attached networks. C. Related Work In a short version of this paper [12] we briefly introduced and its main principles. This paper describes the architecture and its building blocks in detail, and includes experimental evaluation results. Previous work can be found in literature on softwarebased implementations of accurate clock synchronization [13], [14], not to be confused with software-defined networking, a centralized network architecture that champions scalable network management and agility. The PTIDES project [15], [16] defines a programming model for time-aware programs. The current paper presents, and focuses on how time-aware SDN applications use it, whereas the programming model is out of the scope of this paper. In conventional synchronization protocols, multiple time sources are sometimes used to improve the accuracy and security of the protocol [11], or for redundancy, allowing a fast recovery when the primary master fails [17]. Contrary to conventional synchronization protocols, is not used for clock synchronization, but for many-to-one time distribution, allowing a central entity that keeps track of all clocks in the network. II. A MODEL FOR USING TIME IN SDN As is standard in the literature (e.g., [18], [19]), we distinguish between real time, which is not observable by nodes in our system, and clock time, as measured by the nodes. Real time values are denoted in lower case, whereas clock time variables and constants in upper case. We assume that each node in our system maintains a clock. As in [20], [19], the value of a clock at time t is a linear function of t, as follows: 2 A profile [9] is a specific selection of features and modes of. T (t) = t + o(t 0 ) + ρ [t t 0 ] (1) Where t 0 is some previous reference time value, o(t 0 ) is the offset at t 0, i.e., T (t 0 ) t 0, and ρ is the clock skew at t 0. The clock skew, also known as the frequency error, is defined, where F is the clock s frequency, and f is the frequency of a clock that runs at real time. 3 For simplicity, we assume that there is no clock drift, i.e., that the clock frequency F is constant and hence ρ is constant. We note that our analysis can be extended to address a model that includes the clock drift; the extension is straightforward, but for ease of presentation we chose to neglect the clock drift. Our system consists of n+1 nodes: a controller c, and a set S of n switches. We define a set A of possible commands that the controller can send to switches, and a set B of notifications that a switch can send to the controller. We use the notation T i to refer to the value of i s clock. The controller can send messages to switch i, denoted M cs (i,α,t i ), implying that i should perform α A at time T i. A switch can send notification messages of the form M sc (i,β,t i ) to the controller, denoting that the message includes the notification β B with the timestamp T i according to i s clock. as ρ := F f f TIMECONF [3], formally defined in Fig. 2, is a simple protocol for time-based updates, where the controller defines a single execution time, T u, for all switches, 4 and A M := {α 1,α 2,...,α n } is a set of n commands, such that the controller assigns the action α i to each i S. TIMECONF(T u,a M ) 1 for i S do 2 send M cs (i,α i,t u ) Fig. 2: A protocol for coordinated network updates III. AN OVERVIEW OF A. The Profile We define as a profile. The profile has two interesting properties with respect to SDN: (i) to the extent possible it simplifies the functionality of the switches, and (ii) all messages are exchanged between a controller and a switch, i.e., no messages are exchanged between switches. domains. A set of clocks that synchronize to a common master forms a domain. In, 3 In this context, by a clock that runs at real time we mean a clock that at every time t shows T (t) = t. 4 The controller should take care to schedule an execution time that allows enough time for the update message to be sent and propagated to all switches in the network. Domain A Domain B Domain C Master + Transparent Clock (TC) Domain A Domain B Domain C Domain D (a) without (b) with on-path support on-path support Fig. 3: : each master forms a separate domain

3 each master- pair forms a separate domain (Fig. 3). When a receives a message it identifies the packet s domain based on its source address. Thus, as in [17], all domains can use the same domain number. 5 On-path support. A -enabled network may use Transparent Clocks (TC) or Boundary Clocks (BC), intermediate switches or routers that take part in the protocol, allowing a high end-to-end accuracy. The usage of TCs or BCs is referred to as on-path support. On-path support in is optional. TCs may be used, allowing to improve the accuracy of the protocol using the correction field [9]. This implies that a -enabled switch may function as both a master, distributing its time to the, and a TC, that relays messages from other Ordinary Clocks (Fig. 3b). For the sake of simplicity, BCs are not used in. 6 It is interesting to note that if Transparent Clocks are used, they can be either syntonized [9] or unsyntonized. A syntonized TC is a TC that is frequency-synchronized to the master s clock, allowing a more accurate correction field than a non-syntonized TC. Our centralized paradigm requires TCs to be as simple as possible, and hence unsyntonized; an unsyntonized TC is simply required to compute the residence time of en-route messages, and is thus not required to run a complex servo algorithm. In Section IV-E we briefly discuss how can be extended to allow syntonized TCs. Best Master Clock Algorithm (BMCA). does not use a BMCA; during the network initialization all switches are configured as and all controllers are configured as s. This approach is aligned with the SDN paradigm, where a bootstrapping procedure (e.g., [21]) is typically used for configuring basic attributes, such as the controllers IP addresses. Unicast and multicast transmission. Sync messages in can be sent either as unicast or as multicast. During network initialization, switches need to be configured with the controller s unicast address, or, in the multiplecontroller case, a multicast address that represents the controllers. Delay Request and Delay Response messages are always sent as unicast. One-step vs. two-step. Both one-step and two-step modes can be used in. Peer delay mechanism. The delay measurement mechanism in has two possible modes of operation: End-to- End (E2E) mode, where delay request and response messages are exchanged between the master and, and Peer-to- Peer (P2P) mode, where intermediate TCs perform delay measurement on a one-hop basis. uses the E2E mode, as this paradigm implies that all delay messages are exchanged between a controller and a switch, and no messages need be exchanged between switches. B. Properties of Accuracy. The clock accuracy in a network depends on a number of factors, including the accuracy of the timestamping mechanisms, the quality of the clock oscillators, 5 A less scalable solution to identify the packet s domain is by using the domain number field in the header. Since this field is 8-bits long, this solution would limit the number of to Note that an SDN can function as a big BC, as described in Section IV-C, but no BCs are used in domains. and whether on-path support is used. For example, when is used in a system without on-path support, the packet delay variation between the and the may significantly affect the accuracy. with onpath support provides the tools to reach an accuracy that is comparable to that of conventional. As stated above, the paradigm implies that TCs are unsyntonized. Although the IEEE 1588 standard does not specify that TCs must be syntonized, syntonized TCs have been shown [22] to provide a higher degree of accuracy, especially over a large number of hops. A possible extension to that mitigates this limitation is discussed in Section IV-E. Security aspects. The potential security vulnerabilities of are similar to those of conventional synchronization protocols [23], [24]. In, a successful attack results in one or more s not being accurately synchronized to the correct time, whereas in, a successful attack causes the controller to have an inaccurate view of the offset to one or more of the switches. An application that requires accurate time is similarly affected in both cases. IV. USING IN SDNS A. Theory of Operation A typical SDN architecture is illustrated in Fig. 4a. The network operating system is a logical entity that manages the control plane of the network, and communicates with switches using an SDN protocol such as Open [2]. The controller may run one or more, a module that performs a network function such as routing or access control, using the SDN control plane. Every switch uses one or more flow tables that perform the switch s data plane decisions, such as forwarding and security decisions. A switch s control plane agent is responsible for managing the flow tables based on commands received from the controller. The logical blocks of in a typical SDN architecture are illustrated in Fig. 4b. Next we describe the main blocks in this architecture. Clocks. Every switch maintains a clock, which keeps the wall-clock time and allows the switch to perform time-triggered actions and to timestamp notifications. RE- VERSE does not require switches clocks to be synchronized or initialized to a common time reference. The controller maintains a local clock. The controller s clock is used as the reference for scheduling network-wide coordinated updates, and for measuring timestamped events. Thus, in some systems the controller s clock may be required to be synchronized to an accurate external reference source such as a GPS receiver. master. Each switch functions as a master, and periodically sends Sync messages to the controller (its ), containing a local timestamp. We emphasize that the master functionality is typically supported by existing implementations of -enabled switches. Ti c The time of reception of the latest Sync message from i. o i The estimated offset between the clocks of master i and the at time Ti c. ρ i The estimated skew between master i and the at Ti c. TABLE I: parameters. The controller maintains n RE- VERSE modules, where n is the number of switches in the network. Each module periodically receives Sync

4 Network Operating System Control plane agent... Controller SDN protocol, e.g., Open Switch Network Operating System Control plane agent SDN protocol, e.g., Open Time dist. app (a) Typical SDN (b) -enabled SDN Fig. 4: The architecture in SDNs... Time-based update app timestamp conversion switch scheduling Controller Slave clock Master clock Switch messages from one of the switches (its ), i, and based on these messages it maintains three values for i ( I). The offset o i, and the skew ρ i are computed by the based on the latest measurement of Ti c, as well as previous measurements. Various well-known algorithms can be used for computing these two parameters, e.g., [20], [14]. Timestamp conversion. This module performs the required translation between the controller s clock time and the switches clock time based on the parameters of I; a timestamp T c according to the controller s clock, is translated into T i according to i s clock by: T i = T c + o i + ρ i (T c T c i ) (2) The latter is derived from Eq. 1. Similarly, a notification from switch i that contains a timestamp T i, can be converted to the controller s timescale by: T c = T i o i + ρ i T c i 1 + ρ i (3) As mentioned in Section II, in our analysis we neglect the clock drift. However, it is possible to add the clock drift, d i, as a fourth parameter to I, and to modify Eq. 2 and 3 to include d i. We note that when the clock skew, ρ i, is negligible it is possible to use a first-order approximation of Eq. 2 and 3, as follows: T i = T c + o i (4) It is a key observation that the timestamp conversion module allows SDN applications that run at the controller to implement any time-based protocol that would require switches to be synchronized when a conventional synchronization protocol is used. This property is inherent in SDN applications, where coordination is not required directly between switches, but only through the controller. We now describe two interesting examples of SDN applications that use : the time-based update application, and the time distribution application. B. Time-based Updates using Time-based update application. This simple SDN application, depicted in Fig. 4b, performs time-based network updates using the TIMECONF protocol (Fig. 2). When the application sends a time-based update, denoted by M cs (i,α i,t u ) on line 2 of Fig. 2, the time conversion module translates T u to T i corresponding to i s clock. Conceptually, the joint operation of the time-based update application and the timestamp conversion block performs the following protocol: REVERSETIMECONF(T u,a M ) 1 for i S do 2 T i T u + o i + ρ i (T u Ti c ) 3 send M cs (i,α i,t i ) Fig. 5: Coordinated updates using As in Eq. 4, a first-order approximation of REVERSETIME- CONF where line 2 is replaced by T i T u + o i can be used when the skew is negligible. Switch scheduling. When switch i receives a scheduled message, M cs (i,α,t i ), from the controller, this module schedules the corresponding command, α, to time T i according to the switch s local clock. C. Time Distribution over SDNs using In some cases time must be distributed between endstations or networks that are attached to an SDN. For instance, an SDN-based mobile backhaul network must allow time distribution between base station sites, allowing the base stations to be synchronized. In this section we present an SDN application, denoted by time dist. app in Fig. 4b, that allows time distribution over an SDN. In conventional -enabled networks time is distributed over one or more Boundary Clocks (BC) [9], as shown in Fig. 6a. A BC is a switch or a router that maintains an accurate clock based on Sync messages that it receives from the master, and distributes its time to the s. When a BC receives a Sync message 7 from the master (step 1 in Fig. 6a), its ingress time is accurately measured. Based on the Sync message and its ingress timestamp the BC adjusts its clock. When the BC generates a Sync message to one of the s, the message is accurately timestamped as it is transmitted through the egress port (step 2 in Fig. 6a). Our approach is illustrated in Fig. 6b; is used within the SDN, allowing the controller to maintain the time offset to each of the switches. An SDN is often viewed as a single big switch. Similarly, in our approach the SDN is a distributed BC that functions as a single logical big BC. When the master sends a Sync message, switch 1 accurately 7 The Sync message procedure is presented as an example. The procedure for other types of messages is similar. Boundary Clock (BC) master Software Defined Network switch 1 switch controller 1 2 switch 2 switch Boundary Clock (BC) (a) A conventional BC (b) An SDN as a big BC Fig. 6: SDN as a Boundary Clock s

5 measures its ingress time, T 1 (step 1 in Fig. 6b), and sends the packet and T 1 to the controller for further processing. The controller converts T 1 to T c using the timestamp conversion module, and the time dist. app (Fig. 4b) adjusts the controller s clock based on the incoming Sync message and T c. When the time dist. app sends a Sync message through switch 2, it uses the packet s correction field [9] to reflect the offset o 2 between switch 2 and the controller, and the packet is timestamped by switch 2 as it is transmitted (step 2 in Fig. 6b). This procedure can be implemented in Open [2], using Packet-In and Packet-Out messages between the controller and the switches. Note that there is currently no standard means for the ingress port of switch 1 to convey T 1 to the controller. A similar problem has been raised in the IEEE 1588 working group (e.g. [25]), and proposals that address it are currently under discussion. The significant advantage of the big BC approach compared to the conventional approach is that it provides the protocol programmability of, while presenting standard behavior to external non-sdn nodes. D. Multiple Controllers SDNs often use multiple controllers in an active-standby mode to provide survivability. In other cases, an SDN is sliced into multiple virtual networks (e.g. [21]), where each network is controlled by a separate controller. Interestingly, the architecture is well-suited for multi-controller configurations; each of the switches () distributes its time to all the controllers, allowing each controller to monitor its own offset information of the switches. In sliced networks, allows each slice to be managed according to a different time reference, by allowing each controller to be synchronized to a different reference source. Notably, this slicing property is exclusive to, and is not possible in conventional clock synchronization methods. E. Synchronizing Clocks using The concept we presented does not require switches to be synchronized to a common wall-clock time. However, can be extended to allow switches to be timesynchronized. allows to query s about the master- offset using management messages. Using these messages in, switches can synchronize their clocks with the controller s clock. Note that the offset only allows switches to get a first-order approximation, as per Eq. 4. can be extended to allow s to periodically send the three parameters Ti c, o i, and ρ i, allowing to maintain an accurately synchronized clock. The latter extension can similarly be used to allow syntonized TCs; an unsyntonized TC may perform inaccurate updates of the correction field due to its inaccurate frequency, whereas a TC that periodically receives the three parameters above can use these parameters to accurately compute the correction field, using well-known methods (e.g., [22]). F. The Centralized Approach of The architecture allows switches to maintain a fairly simple module, while exporting the complex functions to the controller. The switch is not required to run the BMCA or a complex servo algorithm; this significantly reduces the load on the switch, allowing most of the functionality to be implemented in hardware. More significantly, measurement probe Ping DeterLab testbed (a) Coordinated event: nodes 3 to 34 simultaneously send Ping message to node 2. measurement probe Fig. 7: Network setup Ping DeterLab testbed (b) Timestamped event: node 2 sends broadcast Ping message to nodes 3 to 34. the servo algorithm, which is the brain of the protocol runs at the controller. This centralized approach allows easy networkwide modifications by an SDN programmer, at the cost of high computational complexity at the controller, a tradeoff that is at the very core of the SDN paradigm. V. EVALUATION We have implemented a prototype of, based on the open-source d [26], and evaluated its performance in a testbed with 34 nodes (Fig. 7). The purpose of our experiments was to evaluate the effectiveness of scheduling a simultaneous event in the network using, and to verify that and conventional provide a similar degree of accuracy in this context. The experiments were conducted on the DeterLab testbed [27], where every testbed machine (computer) served as a clock running the software-based d. Note that our experiments used software-based clocks in a network with up to two hops without on-path support, and we observed that the achievable accuracy in this software-based environment was on the order of tens to hundreds of microseconds. 8 were implemented by running d in master-only mode, with the BMCA disabled. Our n- node ran n instances of d in -only mode, each at a different domain, using n domain numbers. d, when in mode, periodically provides the current Offset From Master. This value is typically used by the d servo algorithm [14]. In our experiments we used the Offset From Master output to perform the first order approximation of Eq. 4. Nodes 3 to 34 played the role of, node 1 was the, and node 2 served as a measurement probe. The experiment included two parts: (i) Coordinated event. We scheduled nodes 3 to 34 to send a Ping message to node 2 at the same time. The scheduling was based on REVERSETIMECONF using the offsets computed by node 1, the, with the approximation of Eq. 4. To simplify the experiment we did not use a control protocol such as Open. Instead, we used a simple doorbell-based method to distribute the scheduling to nodes 3 to 34; after the scheduling times were computed, they were written to the Network File System (NFS), and each of the nodes 3 to 34 read its scheduling time from the NFS. In 8 Typical hardware-based implementations allow an accuracy on the order of 1 microsecond.

6 PDF Reverse PDF Reverse Acknowledgment. The authors would like to thank Wojciech Owczarek for his dedicated help and support with d Ping Arrival Time [milliseconds] Ping Arrival Time [milliseconds] (a) Coordinated event: PDF of (b) Timestamped event: PDF of the Ping arrival time when the Ping arrival time when node 2 nodes 3 to 34 send a Ping to sends a broadcast Ping to nodes 3 node 2 simultaneously. to 34. Fig. 8: Accuracy measurements of a coordinated Ping node 2 we monitored the distribution of the Ping message arrival times; the arrival time of each packet was captured by Wireshark [28] using the machine s Linux clock. Interestingly, this experiment is the message-based variant of a 1 Pulse Per Second (PPS) signal sent from each of the 32 clocks to a single testing equipment. We repeated the experiment with instead of RE- VERSE, using TIMECONF (Fig. 2). The distribution of the arrival times of the 32 Ping messages at node 2 is illustrated in Fig. 8a. The value 0 on the time axis represents the median of the arrival times. As shown in Fig. 8a, the arrival times were spread over a period of about 8 milliseconds. (ii) Timestamped event. We sent a broadcast Ping message from node 2 to nodes 3 to 34, and measured its arrival time to each of these nodes using Wireshark. We then used Eq. 4 to align the reception times to a common -based time reference. We repeated the experiment using conventional. The empirical PDF of the arrival times measured at nodes 3 to 34 is depicted in Fig. 8b. We observed that in the coordinated event experiment the time elapsed from when the Ping message was scheduled to be transmitted until it was transmitted in practice varied at different nodes on the order of a few milliseconds. Hence, in the coordinated event experiment the accuracy of our measurement was affected by the internal delay of the sending hosts operating systems, thus explaining the fact that the arrival time in Fig. 8a ranges over a period of about 8 milliseconds, a significantly wider range than the one shown in Fig. 8b. The experiment demonstrates how can be effectively used to coordinate events, or to accurately measure the occurrence time of events. is shown to provide the same level of accuracy as the conventional. VI. CONCLUSION Clock synchronization protocols are not one size fits all, as different applications may have different requirements and constraints. We introduced, a clock synchronization protocol that is specifically tailored for the centralized approach of SDN. provides the same level of accuracy as conventional synchronization protocols, while its novel architecture shifts the complex functionality from the switches to the controller, facilitating the agility and programmability that are of key importance in SDNs. REFERENCES [1] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turner, Openflow: enabling innovation in campus networks, SIGCOMM Comput. Commun. Rev., vol. 38, pp , Mar [2] Open Networking Foundation, Openflow switch specification, Version 1.4.0, [3] T. Mizrahi and Y. Moses, Time-based updates in software defined networks, in hot topics in software defined networks (HotSDN), [4] T. Mizrahi and Y. Moses, On the necessity of time-based updates in SDN, in Open Networking Summit (ONS), [5] M. Reitblatt, N. Foster, J. Rexford, C. Schlesinger, and D. Walker, Abstractions for network update, in Proceedings of ACM SIGCOMM, [6] P. Francois and O. Bonaventure, Avoiding transient loops during the convergence of link-state routing protocols, Trans. on Networking, [7] T. Mizrahi and Y. Moses, Time-based Updates in Open: A Proposed Extension to the Open Protocol, technical report, CCIT Report #835, July 2013, EE Pub No. 1792, Technion Israel Institute of Technology, dew/oftimetr.pdf, [8] Open Networking Foundation, Openflow-enabled mobile and wireless networks, ONF Solution Brief, [9] IEEE TC 9, 1588 IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems Version 2, [10] ITU-T G.8271/Y.1366, Time and phase synchronization aspects of packet networks, [11] D. Mills, J. Martin, J. Burbank, and W. Kasch, RFC 5905: Network time protocol version 4: Protocol and algorithms specification, IETF, [12] T. Mizrahi and Y. Moses, : A software defined networking approach to clock synchronization, HotSDN, accepted, [13] D. Veitch, J. Ridoux, and S. B. Korada, Robust synchronization of absolute and difference clocks over networks, IEEE/ACM Transactions on Networking (TON), vol. 17, no. 2, pp , [14] K. Correll, N. Barendt, and M. Branicky, Design considerations for software only implementations of the IEEE 1588 precision time protocol, in Conference on IEEE 1588, pp , [15] P. Derler, T. H. Feng, E. A. Lee, S. Matic, H. D. Patel, Y. Zheo, and J. Zou, Ptides: A programming model for distributed real-time embedded systems, tech. rep., DTIC Document, [16] P. Derler, J. C. Eidson, S. Goose, E. A. Lee, S. Matic, and M. Zimmer, Using ptides and synchronized clocks to design distributed systems with deterministic system wide timing, in Precision Clock Synchronization for Measurement Control and Communication (ISPCS), 2013 International IEEE Symposium on, pp , IEEE, [17] ITU-T G /Y , Precision time protocol telecom profile for frequency synchronization, [18] J. Y. Halpern, B. Simons, R. Strong, and D. Dolev, Fault-tolerant clock synchronization, in PODC, pp , ACM, [19] T. Srikanth and S. Toueg, Optimal clock synchronization, Journal of the ACM (JACM), vol. 34, no. 3, pp , [20] D. L. Mills, Improved algorithms for synchronizing computer network clocks, IEEE/ACM Transactions on Networking (TON), vol. 3, no. 3, pp , [21] Open Networking Foundation, Openflow management and configuration protocol (of-config 1.2), [22] G. M. Garner, Effect of a frequency perturbation in a chain of syntonized transparent, [23] T. Mizrahi, Time synchronization security using IPsec and MACsec, in ISPCS, pp , IEEE, [24] T. Mizrahi, Security requirements of time protocols in packet switched networks, draft-tictoc-security-requirements, work in progress, IETF, [25] R. Tse and C. Ong, Proposal for a standardized mechanism to transfer timing information from an ingress port to an egress port of a transparent clock, ISPCS, special session on proposed revisions of IEEE , [26] d, Precision Time Protocol daemon, version 2.3.0, sourceforge.net/, [27] J. Mirkovic and T. Benzel, Teaching cybersecurity with DeterLab, Security & Privacy, IEEE, vol. 10, no. 1, pp , [28] Wireshark