Using R EVERSE PTP 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 (PTP). Contrary to the centralized SDN paradigm, PTP is by nature a distributed protocol, in which every node is required to run a complex clock servo algorithm. We introduce R EVERSE PTP, a clock synchronization protocol for SDN. R EVERSE PTP is based on PTP, but is conceptually reversed; in R EVERSE PTP 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 PTP flexible and programmable from an SDN programmer’s perspective. We present the R EVERSE PTP architecture, and discuss how SDN applications that require accurate time can use R EVERSE PTP. Our experimental evaluation of a network with 34 R EVERSE PTPenabled nodes shows that R EVERSE PTP can be effectively used for coordinating events in networks at the same level of accuracy as provided by the conventional PTP.

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 OpenFlow. OpenFlow, 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 PTP

(b) R EVERSE PTP-enabled SDN

Fig. 1: Time distribution in PTP and R EVERSE PTP 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 OpenFlow 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 (PTP), defined in the IEEE 15882008 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 PTP in SDNs presents a challenge: one of the key properties of SDN is its centralized control plane. However, PTP is a distributed control protocol; the master clock is elected by the Best Master Clock Algorithm (BMCA), and each of the slaves 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 PTP. Our approach is to adapt PTP to the SDN philosophy by shifting the core of its functionality to the controller. B. Contributions In this paper we introduce R EVERSE PTP, a novel approach that addresses the dichotomy above; in contrast to the conventional PTP paradigm, where a master clock distributes its time to multiple slave clocks (Fig. 1a), in R EVERSE PTP (Fig. 1b) there is a single slave (the controller) and multiple masters (the switches). Every switch distributes its time to

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, R EVERSE PTP 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 PTP and R E VERSE PTP is the direction of time distribution; in R E VERSE PTP time is distributed in an all-to-one fashion rather than PTP’s one-to-all nature. Hence, the accuracy of conventional PTP and R EVERSE PTP should be similar, given that all other aspects of the network are the same. R EVERSE PTP is defined as an IEEE 1588 profile.2 Since switches function as conventional PTP masters, our approach is applicable to existing implementations of PTP-enabled switches. Note that the R EVERSE PTP approach can be applied to other synchronization protocols, e.g., the Network Time Protocol (NTP) [11]. We show how R EVERSE PTP 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 R EVERSE PTP and its main principles. This paper describes the R EVERSE PTP 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 R EVERSE PTP, 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, R EVERSE PTP 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 M ODEL FOR USING T IME 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: 2A

profile [9] is a specific selection of features and modes of PTP.

T (t) = t + o(t0 ) + ρ · [t − t0 ]

(1)

Where t0 is some previous reference time value, o(t0 ) is the offset at t0 , i.e., T (t0 ) − t0 , and ρ is the clock skew at t0 . The clock skew, also known as the frequency error, is defined as ρ := F−f f , 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 Mcs (i, α, T i ), implying that i should perform α ∈ A at time T i . A switch can send notification messages of the form Msc (i, β, T i ) to the controller, denoting that the message includes the notification β ∈ B with the timestamp T i according to i’s clock. T IME C ONF [3], formally defined in Fig. 2, is a simple protocol for time-based updates, where the controller defines a single execution time, Tu , for all switches,4 and AM := {α1 , α2 , . . . , αn } is a set of n commands, such that the controller assigns the action αi to each i ∈ S. T IME C ONF(Tu , AM ) 1 for i ∈ S do 2 send Mcs (i, αi , Tu ) Fig. 2: A protocol for coordinated network updates III. A N OVERVIEW OF R EVERSE PTP A. The R EVERSE PTP Profile We define R EVERSE PTP as a PTP 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 PTP messages are exchanged between a controller and a switch, i.e., no messages are exchanged between switches. PTP domains. A set of PTP clocks that synchronize to a common master forms a PTP domain. In R EVERSE PTP, 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.

REVERSEPTP slave

Domain A Domain B Domain C

REVERSEPTP slave

Domain A Domain B Domain C Domain D

Master + Transparent Clock (TC)

masters

(a) R EVERSE PTP without on-path support

masters

(b) R EVERSE PTP with on-path support

Fig. 3: R EVERSE PTP: each master forms a separate domain

each master-slave pair forms a separate PTP domain (Fig. 3). When a slave receives a PTP 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 PTP-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 R EVERSE PTP is optional. TCs may be used, allowing to improve the accuracy of the protocol using the PTP correction field [9]. This implies that a R EVERSE PTP-enabled switch may function as both a master, distributing its time to the slave, and a TC, that relays PTP messages from other Ordinary Clocks (Fig. 3b). For the sake of simplicity, BCs are not used in R EVERSE PTP.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 PTP messages, and is thus not required to run a complex servo algorithm. In Section IV-E we briefly discuss how R EVERSE PTP can be extended to allow syntonized TCs. Best Master Clock Algorithm (BMCA). R EVERSE PTP does not use a BMCA; during the network initialization all switches are configured as masters and all controllers are configured as slaves. 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 R EVERSE PTP 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 R EVERSE PTP. Peer delay mechanism. The delay measurement mechanism in PTP has two possible modes of operation: End-toEnd (E2E) mode, where delay request and response messages are exchanged between the master and slave, and Peer-toPeer (P2P) mode, where intermediate TCs perform delay measurement on a one-hop basis. R EVERSE PTP 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 R EVERSE PTP 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 PTP header. Since this field is 8-bits long, this solution would limit the number of R EVERSE PTP masters to 256. 6 Note that an SDN can function as a ‘big BC’, as described in Section IV-C, but no BCs are used in R EVERSE PTP domains.

and whether on-path support is used. For example, when R EVERSE PTP is used in a system without on-path support, the packet delay variation between the masters and the slave may significantly affect the accuracy. R EVERSE PTP with onpath support provides the tools to reach an accuracy that is comparable to that of conventional PTP. As stated above, the R EVERSE PTP 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 R EVERSE PTP that mitigates this limitation is discussed in Section IV-E. Security aspects. The potential security vulnerabilities of R EVERSE PTP are similar to those of conventional synchronization protocols [23], [24]. In PTP, a successful attack results in one or more slaves not being accurately synchronized to the correct time, whereas in R EVERSE PTP, 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. U SING R EVERSE PTP IN SDN S 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 OpenFlow [2]. The controller may run one or more SDN Application, 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 R EVERSE PTP 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. R E VERSE PTP 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. R EVERSE PTP master. Each switch functions as a PTP master, and periodically sends Sync messages to the controller (its PTP slave), containing a local timestamp. We emphasize that the PTP master functionality is typically supported by existing implementations of PTP-enabled switches. Ticlast oi ρi

The time of reception of the latest Sync message from i. The estimated offset between the clocks of master i and the slave at time Ticlast . The estimated skew between master i and the slave at Ticlast .

TABLE I: R EVERSE PTP slave parameters R EVERSE PTP slave. The controller maintains n R E VERSE PTP slave modules, where n is the number of switches in the network. Each slave module periodically receives Sync

Network Operating System

Time-based update app

Time dist. app

SDN Application

SDN Application

SDN Application

SDN Application

SDN Application

Controller

Network Operating System timestamp conversion

SDN protocol, e.g., OpenFlow

SDN protocol, e.g., OpenFlow

Control plane agent

Control plane agent switch scheduling

Flow Flow ... Flow Table Table Table

Switch

(a) Typical SDN

Flow Flow ... Flow Table Table Table

Controller

clock REVERSEPTP Slave PTP REVERSEPTP Master clock

Switch

(b) R EVERSE PTP-enabled SDN

Fig. 4: The R EVERSE PTP architecture in SDNs messages from one of the switches (its masters), i, and based on these messages it maintains three values for i (Table I). The offset oi , and the skew ρi are computed by the slave based on the latest measurement of Ticlast , 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 Table 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 + oi + ρi · (T c − Ticlast )

(2)

The latter is derived from Eq. 1. Similarly, a notification from switch i that contains a timestamp Ti , can be converted to the controller’s timescale by: Tc =

Conceptually, the joint operation of the time-based update application and the timestamp conversion block performs the following protocol:

T i − oi + ρi · Ticlast

(3) 1 + ρi As mentioned in Section II, in our analysis we neglect the clock drift. However, it is possible to add the clock drift, di , as a fourth parameter to Table I, and to modify Eq. 2 and 3 to include di . 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 + oi (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 R EVERSE PTP: the time-based update application, and the time distribution application. B. Time-based Updates using R EVERSE PTP Time-based update application. This simple SDN application, depicted in Fig. 4b, performs time-based network updates using the T IME C ONF protocol (Fig. 2). When the application sends a time-based update, denoted by Mcs (i, αi , Tu ) on line 2 of Fig. 2, the time conversion module translates Tu to T i corresponding to i’s clock.

R EVERSE T IME C ONF(Tu , AM ) 1 for i ∈ S do 2 T i ← Tu + oi + ρi · (Tu − Ticlast ) 3 send Mcs (i, αi , T i ) Fig. 5: Coordinated updates using R EVERSE PTP As in Eq. 4, a first-order approximation of R EVERSE T IME C ONF where line 2 is replaced by T i ← Tu + oi can be used when the skew is negligible. Switch scheduling. When switch i receives a scheduled message, Mcs (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 R EVERSE PTP 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 PTP-enabled networks time is distributed over one or more PTP 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 PTP master, and distributes its time to the PTP slaves. When a BC receives a Sync message7 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 slaves, 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; R EVERSE PTP 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 PTP messages is similar.

Software Defined Network REVERSEPTP

controller

PTP

1

2

Boundary Clock (BC)

master

switch 1

switch

switch 2

switch

slaves

Boundary Clock (BC)

(a) A conventional BC

(b) An SDN as a ‘big BC’

Fig. 6: SDN as a Boundary Clock

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 o2 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 OpenFlow [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 PTP approach is that it provides the protocol programmability of R EVERSE PTP, while presenting standard PTP 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 R EVERSE PTP architecture is well-suited for multi-controller configurations; each of the switches (masters) distributes its time to all the controllers, allowing each controller to monitor its own offset information of the switches. In sliced networks, R EVERSE PTP 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 R EVERSE PTP, and is not possible in conventional clock synchronization methods. E. Synchronizing Clocks using R EVERSE PTP The concept we presented does not require switches to be synchronized to a common wall-clock time. However, R EVERSE PTP can be extended to allow switches to be timesynchronized. PTP allows masters to query slaves about the master-slave offset using PTP management messages. Using these messages in R EVERSE PTP, 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. PTP can be extended to allow slaves to periodically send the three parameters Ticlast , oi , and ρi , allowing R EVERSE PTP masters 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 R EVERSE PTP The R EVERSE PTP architecture allows switches to maintain a fairly simple PTP 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 PTP functionality to be implemented in hardware. More significantly,

REVERSEPTP slave

measurement probe

REVERSEPTP slave

measurement probe

Ping

Ping

DeterLab testbed

DeterLab testbed

REVERSEPTP masters

REVERSEPTP masters

(a) Coordinated event: nodes 3 to 34 simultaneously send Ping message to node 2.

(b) Timestamped event: node 2 sends broadcast Ping message to nodes 3 to 34.

Fig. 7: Network setup 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. E VALUATION We have implemented a prototype of R EVERSE PTP, based on the open-source PTPd [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 R EVERSE PTP, and to verify that R EVERSE PTP and conventional PTP 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 PTP clock running the software-based PTPd. Note that our experiments used software-based PTP 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 R EVERSE PTP masters were implemented by running PTPd in master-only mode, with the BMCA disabled. Our n-slave R EVERSE PTP node ran n instances of PTPd in slave-only mode, each at a different PTP domain, using n PTP domain numbers. PTPd, when in slave mode, periodically provides the current Offset From Master. This value is typically used by the PTPd 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 R EVERSE PTP masters, node 1 was the R EVERSE PTP slave, 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 R EVERSE T IME C ONF using the offsets computed by node 1, the R EVERSE PTP slave, with the approximation of Eq. 4. To simplify the experiment we did not use a control protocol such as OpenFlow. 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 PTP implementations allow an accuracy on the order of 1 microsecond.

PDF

PDF

ReversePTP PTP

ReversePTP PTP

Acknowledgment. The authors would like to thank Wojciech Owczarek for his dedicated help and support with PTPd. R EFERENCES

-8

-3

2

7

-0.15

-0.05

0.05

0.15

0.25

Ping Arrival Time [milliseconds]

Ping Arrival Time [milliseconds]

(a) Coordinated event: PDF of the Ping arrival time when nodes 3 to 34 send a Ping to node 2 simultaneously.

(b) Timestamped event: PDF of the Ping arrival time when node 2 sends a broadcast Ping to nodes 3 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 PTP instead of R E VERSE PTP, using T IME C ONF (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 R EVERSE PTP-based time reference. We repeated the experiment using conventional PTP. 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 R EVERSE PTP can be effectively used to coordinate events, or to accurately measure the occurrence time of events. R EVERSE PTP is shown to provide the same level of accuracy as the conventional PTP. VI. C ONCLUSION Clock synchronization protocols are not ‘one size fits all’, as different applications may have different requirements and constraints. We introduced R EVERSE PTP, a clock synchronization protocol that is specifically tailored for the centralized approach of SDN. R EVERSE PTP 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.

[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. 69– 74, Mar. 2008. [2] Open Networking Foundation, “Openflow switch specification,” Version 1.4.0, 2013. [3] T. Mizrahi and Y. Moses, “Time-based updates in software defined networks,” in hot topics in software defined networks (HotSDN), 2013. [4] T. Mizrahi and Y. Moses, “On the necessity of time-based updates in SDN,” in Open Networking Summit (ONS), 2014. [5] M. Reitblatt, N. Foster, J. Rexford, C. Schlesinger, and D. Walker, “Abstractions for network update,” in Proceedings of ACM SIGCOMM, 2012. [6] P. Francois and O. Bonaventure, “Avoiding transient loops during the convergence of link-state routing protocols,” Trans. on Networking, 2007. [7] T. Mizrahi and Y. Moses, “Time-based Updates in OpenFlow: A Proposed Extension to the OpenFlow Protocol,” technical report, CCIT Report #835, July 2013, EE Pub No. 1792, Technion – Israel Institute of Technology, http://tx.technion.ac.il/∼dew/OFTimeTR.pdf, 2013. [8] Open Networking Foundation, “Openflow-enabled mobile and wireless networks,” ONF Solution Brief, 2013. [9] IEEE TC 9, “1588 IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems Version 2,” 2008. [10] ITU-T G.8271/Y.1366, “Time and phase synchronization aspects of packet networks,” 2012. [11] D. Mills, J. Martin, J. Burbank, and W. Kasch, “RFC 5905: Network time protocol version 4: Protocol and algorithms specification,” IETF, 2010. [12] T. Mizrahi and Y. Moses, “R EVERSE PTP: A software defined networking approach to clock synchronization,” HotSDN, accepted, 2014. [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. 417–430, 2009. [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. 10–12, 2005. [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, 2008. [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. 41–46, IEEE, 2013. [17] ITU-T G.8265.1/Y.1365.1, “Precision time protocol telecom profile for frequency synchronization,” 2010. [18] J. Y. Halpern, B. Simons, R. Strong, and D. Dolev, “Fault-tolerant clock synchronization,” in PODC, pp. 89–102, ACM, 1984. [19] T. Srikanth and S. Toueg, “Optimal clock synchronization,” Journal of the ACM (JACM), vol. 34, no. 3, pp. 626–645, 1987. [20] D. L. Mills, “Improved algorithms for synchronizing computer network clocks,” IEEE/ACM Transactions on Networking (TON), vol. 3, no. 3, pp. 245–254, 1995. [21] Open Networking Foundation, “Openflow management and configuration protocol (of-config 1.2),” 2014. [22] G. M. Garner, “Effect of a frequency perturbation in a chain of syntonized transparent,” 2007. [23] T. Mizrahi, “Time synchronization security using IPsec and MACsec,” in ISPCS, pp. 38–43, IEEE, 2011. [24] T. Mizrahi, “Security requirements of time protocols in packet switched networks,” draft-tictoc-security-requirements, work in progress, IETF, 2014. [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 PTP transparent clock,” ISPCS, special session on proposed revisions of IEEE 1588-2008, 2012. [26] PTPd, “Precision Time Protocol daemon,” version 2.3.0, http://ptpd. sourceforge.net/, 2013. [27] J. Mirkovic and T. Benzel, “Teaching cybersecurity with DeterLab,” Security & Privacy, IEEE, vol. 10, no. 1, pp. 73–76, 2012. [28] Wireshark http://www.wireshark.org/, 2014.