ReversePTP: A Software Defined Networking Approach to ... - CiteSeerX

ReversePTP: A Software Defined Networking Approach to Clock Synchronization Tal Mizrahi, Yoram Moses ∗ Technion — Israel Institute of Technology {dew@tx, moses@ee}.technion.ac.il

ABSTRACT We introduce R EVERSE PTP, a novel approach to clock synchronization in Software Defined Networks (SDN). R EVERSE PTP is based on the Precision Time Protocol (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.

Categories and Subject Descriptors C.2.1 [Comp.-Comm. Networks]: Network Arch. and Design.

Keywords SDN, PTP, IEEE 1588, clock synchronization, management, time.

1.

INTRODUCTION

Time in SDN. Clock synchronization protocols are deployed in various different environments, from mobile backhaul networks to power substations. The recent interest in Software-Defined Networks (SDN) in some of these environments (e.g., [1]) gives rise to the problem of distributing accurate time in an SDN. A recently introduced approach [2, 3] suggests that network devices can significantly benefit not only from transporting accurate time, but also from using accurate time; time can be used to trigger coordinated network updates, reducing packet loss and anomalies during configuration or topology changes. 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 1588-2008 standard [4], is a natural candidate, as it can provide a very high degree of accuracy, typically on the order of microseconds (e.g. [5]) or better, and is ∗ The Israel Pollak academic chair at Technion; this work was supported in part by the ISF grant 1520/11.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. HotSDN’14, August 22, 2014, Chicago, IL, USA. ACM 978-1-4503-2989-7/14/08. http://dx.doi.org/10.1145/2620728.2620764.

(a) Conventional PTP

(b) R EVERSE PTP-enabled SDN

Figure 1: Time distribution in PTP and R EVERSE PTP 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. On the other hand, PTP is a distributed control protocol; the master clock is elected by the Best Master Clock Algorithm, 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 [6] approach can be taken, where the SDN operates alongside traditional control-plane protocols such as PTP. Our approach is to tweak PTP and adapt it to the SDN philosophy by shifting the core of its functionality to the controller. Contribution of this paper. In this paper we introduce R E VERSE 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 E VERSE 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 tuned, modified or reprogrammed at the controller without upgrading switches in the network. R EVERSE PTP is defined as an IEEE 1588 profile.1 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) [7]. 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. 1A

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

2. AN OVERVIEW OF R EVERSE PTP 2.1 Theory of Operation We assume that every switch maintains a clock. R EVERSE PTP does not require the different switches’ clocks to be synchronized or initialized to a common time reference. The controller maintains an accurate clock that is synchronized to an accurate external reference source such as a GPS receiver. Each switch functions as a PTP master, and periodically sends Sync messages to the controller (its single slave), containing a local timestamp. We emphasize that the PTP master functionality is typically supported by existing implementations of PTP-enabled switches. The controller runs n R EVERSE PTP slave modules, where n is the number of switches in the network. Each slave module periodically receives Sync messages from one of the switches (masters), i, and based on these messages it maintains three values for i: Ticlast The time of reception of the latest Sync message from i according to the controller’s clock. oi The estimated offset between the clocks of master i and the slave at time Ticlast . ρi Estimated skew between master i and the slave at Ticlast . Table 1: R EVERSE PTP slave parameters

2.2

SDN Applications that Use Time

An SDN application is a software module that runs on an SDN controller. As previously discussed, SDN applications can benefit from using time to coordinate configuration updates, or to receive timestamped notifications from switches. Consider a R EVERSE PTP-enabled SDN, and an SDN application that needs to instruct switch i to perform a configuration update at time T c according to the controller’s clock. It can be shown that using the parameters of Table 1 and the conversion in Eq. 1, the SDN application can instruct i to perform the update at time T i according to i’s clock, which occurs very close to T c according to the controller’s clock. Similarly, if switch i sends a timestamped notification to the controller with a timestamp Ti , SDN applications can use Eq. 1 to calculate T c , corresponding to the controller’s clock. T i = T c + oi + ρi · (T c − Ticlast ) (1) It is a key observation that the three values from Table 1 allow 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.

2.3

Transporting Accurate Time over SDNs

In some cases time must be distributed between end-stations 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 conventional PTP-enabled networks time is distributed over one or more PTP Boundary Clocks (BC) [4], as shown in Fig. 2a. 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 message2 from the master (step 1 in Fig. 2a), 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. 2a). Our approach is illustrated in Fig. 2b; R EVERSE PTP is used within the SDN, allowing the controller to maintain the time offset to each of the switches. The SDN functions as a single logical 2 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’.

Figure 2: SDN as a Boundary Clock (BC) ‘big BC’. When the master sends a Sync message, switch 1 accurately measures its ingress time, T 1 (step 1 in Fig. 2b), and sends the packet and T 1 to the controller for further processing. The controller converts T 1 to T c using Eq. 1, and adjusts its clock based on the incoming Sync message and T c . When the controller sends a Sync message through switch 2, it uses the packet’s correction field [4] 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. 2b). This procedure can be implemented in OpenFlow [6], using Packet-In and Packet-Out messages between the controller and the switches. 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.

3.

FUTURE WORK

In the extended version of this paper [8] we present an experimental evaluation, showing that a R EVERSE PTP-enabled network can provide the same degree of accuracy as provided by the conventional PTP. Our proposal [9] to add a time extension to the OpenFlow protocol is currently under discussion in the Open Networking Foundation, and we are currently evaluating the use of R E VERSE PTP in OpenFlow networks.

4.

REFERENCES

[1] Open Networking Foundation, “Openflow-enabled mobile and wireless networks,” ONF Solution Brief, 2013. [2] T. Mizrahi and Y. Moses, “Time-based updates in software defined networks,” in HotSDN, 2013. [3] T. Mizrahi and Y. Moses, “On the necessity of time-based updates in SDN,” in Open Networking Summit (ONS), 2014. [4] IEEE TC 9, “1588 IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems Version 2,” 2008. [5] ITU-T G.8271/Y.1366, “Time and phase synchronization aspects of packet networks,” 2012. [6] Open Networking Foundation, “Openflow switch specification,” Version 1.4.0, 2013. [7] D. Mills et al., “RFC 5905: Network time protocol version 4: Protocol and algorithms specification,” IETF, 2010. [8] T. Mizrahi and Y. Moses, “Using R EVERSE PTP to distribute time in software defined networks,” ISPCS, submitted, 2014. [9] 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.