Dual and Hybrid PTP modules For an optimisation of 1588V2-based time distribution in Telecom networks

Dinh Thai BUI Semantic and Autonomic Technologies (SAT) Department

Alcatel-Lucent Bell Labs France (ALBLF) Nozay, FRANCE

Dinh_Thai.Bui@alcatel-lucent.com

Michel LE PALLEC Semantic and Autonomic Technologies (SAT) Department

Alcatel-Lucent Bell Labs France (ALBLF) Nozay, FRANCE

Michel.Le_Pallec@alcatel-lucent.com

Abstract — the IEEE 1588-2008 standard [1] introduces and specifies Boundary Clock (BC) and Transparent Clock (TC) concepts in order to address stringent time distribution requirements (e.g. 1 µs accuracy for the end application) across a communication network. Both concepts present different strengths and weaknesses which are generally used as arguments to oppose one against the other. This paper, on the contrary, is advocating for the implementation of both functionalities on the same network node with regards to the great commonalities and complementarities between them. Going further on this complementary approach, this contribution proposes a hybrid module aiming at combining different advantages offered respectively by BC and TC concepts.

Keywords: synchronization protocols, 1588V2, PTP, Boundary Clock, Transparent Clock, time distribution.

I. INTRODUCTION Many discussions have been carried out, especially within

the ITU-T SG15/Q13, on the applicability of the Boundary Clock (BC) versus the Transparent Clocks (TC) to Telecom environments. Both concepts have been specified within the IEEE 1588TM-2008 1 standard to support an accurate distribution of time.

On one hand, the main concern expressed for the use of the TC concept within a Telecom environment is related to its potential infringement to protocol specifications and/or protocol layer separation principles. This issue is often referred to as a “layer violation” concern [2,3]. Indeed, a TC modifies the header of PTP (Precision Time Protocol) messages within the payload of the transporting IP packet (resp. Ethernet frame) even though the network node hosting the TC functionality is not assigned the destination address specified in the IP packet (resp. Ethernet frame); i.e. the packet is not addressed to the network node supporting the TC.

On the other hand, the main inconvenience for the use of the BC concept is its complexity in terms of implementation. Indeed, the implication of BCs in the Best Master Clock Algorithm (BMCA) or any alternate BMCA makes its implementation more complex than the one of a TC or a Slave clock (e.g. the BC has several PTP ports, thus the port state decision algorithm is more complex that the Slave one). Moreover, its related noise accumulation effect is a complex

1 For the remainder of the paper the term 1588V2 will be used to represent the IEEE 1588TM-2008 standard.

process and is still under study in terms of attainable performance2.

From a standardization perspective, the ITU-T SG15/Q13 is working on the 1588V2 time Telecom profiles aiming at adapting the 1588V2 protocol to the Telecom environment for the distribution of the time-of-day reference. In the initial architecture being discussed, all network elements between the grandmaster clock(s) and the end slave clocks will be required to provide on-path support 3 in the form of a BC implementation. The related reference model is relatively similar to traditional well-known SONET/SDH one where each device recovers the reference from the preceding node and then re-distributes it to succeeding nodes. The difference is that the nodes are distributing both a frequency and a time reference. The ITU-T SG15/Q13 is studying one model where SyncE (Synchronous Ethernet) is used for frequency with 1588V2 for time and a second model where 1588V2 alone is used for both frequency and time. Priority is being given to the first model with SyncE and 1588V2, as it should provide with simpler functional model for a “Telecom” BC4 (e.g. BC models using PTP to recover frequency could adopt a large span of different proprietary algorithms). TCs are still part of ITU-T discussions but would be likely considered latterly in a second Telecom 1588V2 time profile mixing BC and TC.

Thus, within the context where BCs are deployed and transitions to TCs are needed for certain applications (e.g. latency measurement) and for some performance constraints (e.g. well-designed TCs are observed to support very accurate time distribution [4]), this paper first introduces the concept of a hybrid PTP module, which combines the simplicity and predictability of a TC in terms of noise accumulation and the manageability of a BC in terms of automatic reconfiguration (e.g. alternate Best Master Clock Algorithm).

Then, observing commonalities between the BC and the TC, this paper advocates for the implementation of both features within the same network node. The later is configured

2 At the writing time, the ITU-T SG15/Q13 is developing simulation models in order to ensure that the overall noise induced by a chain of 20 BCs comes within budget (under 1.5 micro-seconds). 3 Within the IETF TICTOC working group, the ‘On-Path Support’ terminology designates any special mechanisms embedded in the Packet Switched Network that helps in distributing a time reference. 4 This is the name given to the BC models defined within the ITU-T SG15/Q13 as the models provide with more specific details than the IEEE 1588 standards one.

978-1-61284-893-8/11/$26.00 ©2011 IEEE

to operate as either a BC or a TC according to deployment scenarios. Some of such scenarios are illustrated in chapter III as possible use cases of this dual concept. Within certain scenarios, it is moreover proposed an additional field, following the Type Length Value (TLV) semantics, in order to dynamically (e.g. per PTP flow) configure the behavior of such a dual PTP module.

Some of the discussions are also extended to multi-carrier scenarios where multiple customers’ timing flows are crossing the same transport provider‘s infrastructure. Some of the scenarios are, for example, presented in document [ 5 ]. However, the ITU-T studies are now focusing on one single time domain.

II. A HYBRID MODEL FOR A SIMPLIFIED TIME DISTRIBUTION ARCHITECTURE

A. Context Description Works in progress within the ITU-T SG15/Q13 are heading

towards the finalization of a model for the BC. This model is preferably called “Telecom” BC as it represents more detailed specifications with regards to 1588V2 standards BC concept. One of the proposed “Telecom” BC models (Cf. [6] Appendix II) is illustrated in the Figure 1 below5.

This model uses SynchE in order to recover the frequency reference and possibly implements filtering algorithms in order to compute the time offset with regards to the time reference. In the case filtering algorithms are implemented within the “Time Measurement” stage, non linear effect could be introduced, making the noise accumulation more difficult to predict. Also, as these algorithms are mostly proprietary, some standard limits have to be defined to specify boundaries.

TimeMeasurement,possibly with

filtering

Counter and Time offset correction

Time Offset(possibly filtered)

Local Time OutputLocal Frequency Output

Phase detectorLoop filter Filtered

Frequencyoffset

VCO

EEC

Physical layerfrequency

Local Clock

PTP message event(Sync/Follow-Up, Del_req/resp or

Pdelay_req/resp)

Figure 1 – “Telecom” Boundary Clock model with SyncE [6]

The time counter is incremented and adjusted thanks to the combination of two inputs, respectively the local frequency output which is recovered from the selected SyncE input signal and the time offset as computed based on the selected PTP input signal. If SyncE is used to increment the time counter, then there is a requirement that the time source and the

5 The model for the “Telecom” BC is still under discussions. However, the main functional blocks are agreed.

frequency source are syntonized, meaning that they are traceable back to the same frequency primary reference. Otherwise, this leads to noise induced by SyncE due to its frequency offset with regards to PTP frequency reference [7].

The inconvenience of imposing syntonization between SyncE and PTP sources could lead to strong constraints in terms of synchronization network deployment. Indeed, even if both sources are initially syntonized, failure conditions within the synchronization transport network can lead to the situation that they operate in plesiochronous mode. This situation is likely to occur since it is difficult to maintain congruency between the frequency and time distribution topologies, with the former being distributed using a physical protocol and with the later being distributed using a packet protocol. Indeed, the congruency of both topologies means that both SyncE and PTP topologies should be supported by the same physical links for any observation time t, so that any failure event affects both topologies at the same time (e.g. a PTP packet signal error condition should be propagated to the selection process of SyncE), and accordingly triggers a coordinated behavior between the frequency plane and the time plane. Consequently reaching such an overall behavior is a difficult task as it basically an inter-layer issue [8]. Even though a coordinated reconfiguration can be operated between both PTP and SyncE layers, the difference in convergence time between the two protocols (e.g. difference in processing time) could also lead to undesirable effects.

Even in the case where SyncE and PTP sources are syntonized, phase transients produced with the SyncE layer (e.g. due to small interruptions within the physical layer) can lead to non negligible time error within the PTP layer [9].

In terms of synchronization performance, principal TC noise sources are known [10,11]. The overall TC noise is very small when the local clock is syntonized (e.g. traceable to a Primary Reference Clock) and still relatively small when using a free-run oscillator. In the later case, the performance depends very much on the local oscillator stability and the PTP Event message residence time. In case of IP routers operating in normal condition (i.e. non-congestion state) within the Internet, best-effort packet mean residence time is observed to be typically in the range of hundreds of microseconds to a few milliseconds [12, 13,14]. In the case of an operator internal network, packet residence time is observed to be less than 1 ms [ 15 ]. In this later environment, a simple Stratum 4 (i.e. frequency accuracy of ±32 ppm) free-run oscillator should be appropriate for the deployment of a cascade of at least 10 TCs within the synchronization distribution architecture [16].

The overall noise generation of a cascade of BCs is often observed to be worse than that an equivalent cascade of TCs [11,17,18] due to non-linear noise accumulation. The causes for non-linear noise accumulation at a BC are multiple, but they are principally due to gain peaking, the phase-lock-loop servos, if any, and the asynchronous exchange of messages between the Slave port and a given Master port [19].

Recent developments of new models and related implementations of BCs (e.g. [19,20 ]) allow for important improvements in BC performance. Thus, within certain deployments having the support of SyncE, the performance of

cascaded BCs is observed to be comparable to the one of TCs [21].

In the case when there is no support from SyncE, there is nevertheless a requirement for BCs to implement filtering mechanisms in order to discipline their internal oscillator and to recover the frequency reference, aiming finally at recovering the time reference. Error during the frequency reference recovery is transferred to the next BC(s) downstream, inducing accumulation of non-linear noises. Proprietary work around could be implemented (e.g. [19]) aiming at minimizing the accumulation of those non-linear effects. However, this is not a generic solution in a heterogeneous environment implying equipments from multiple vendors. Moreover, the filtering algorithms implemented within BCs are also proprietary. This is likely to lead to unpredictable important non-linear noise accumulation if no standard engineering boundaries or masks are specified. And the work in progress within the ITU-T shows that this is not a simple task.

The deployment of TCs in such a context would be a possible solution. Indeed, a chain of TCs, each with a simple free-run oscillator, can meet the requirements in terms of synchronization accuracy [16]. The noise generation functions of respective TCs are in this case independent from each other (i.e. no correlation thanks to independent free-run oscillators) and are additive along the TC cascade in a linear manner.

Unfortunately, the “layer violation” concern about TCs, as explained in chapter I, seems to represent an important hurdle for their integration into Telecom environments. It is noted that BCs do not raise such a concern. Indeed, in the case of a clock hierarchy made of only BCs, the destination address of a packet containing the PTP message transmitted by a given BC is the address of the neighbor/adjacent BC. Thus, the latter is authorized (with regards to protocol specifications) to look into the packet payload (especially the encapsulated PTP message) and even to modify it. The BC awareness of the address (e.g. IP address) of its neighbor-BC(s) is possible thanks to the discovery mechanism implemented within the automatic clock hierarchy reconfiguration algorithm such as the default Best Master Clock Algorithm (BMCA).

B. The hybrid module description In order to work around some of the issues mentioned in

the previous chapter while staying interoperable with the first time Telecom profile, a hybrid architecture model is proposed. This hybrid PTP module has behaviors in the middle between the ones of a TC and the ones of a BC. The Figure 2 below gives a functional illustration of such a hybrid module.

It behaves like a TC in terms of synchronization performance. Thus, it especially allows for uncorrelating SyncE and PTP layers and for relaxing the aforementioned synchronization network deployment constraints. It also allows for containing the wander within the budget when the number of cascaded network nodes are high (e.g. more than 20 nodes). When SyncE is not available, it allows for simplifying noise accumulation engineering while implementing free-run internal oscillator (similarly to TCs). Functionally speaking, the hybrid module does not recover the time reference locally. Instead, it uses SyncE or the free-run internal oscillator to increment an

internal time counter with any arbitrary time reference (which is very likely different from the synchronization network time reference). This behavior especially copes better with a plesiochronous deployment of the network time source (e.g. PTP Grand Master) and the network frequency source (e.g. Primary Reference Clock).

The operational interfacing of this module with other PTP modules is however very similar to the one of a BC. It is especially true when it comes to the management and the automatic reconfiguration of the hybrid module as it participates, as much as a BC, into the default -or any alternate- BMCA. This means that all ports of the hybrid module are assigned a state (i.e. Master, Slave or Passive) similarly to BC ports. This also means that the hybrid module should have the same attributes as a BC, such as a clockID and a default DataSet, and that it should send Announce messages in order to get involved within the BMCA. In such a manner, the hybrid module can discover all of its neighbor addresses (i.e. compatible with the all-BC clock hierarchy paradigm) and just avoids the “layer violation” concern related to TCs.

As illustrated in Figure 2, the hybrid PTP module functionally operates with the steps described in the following sections.

Figure 2 – Hybrid module operational description

It is assumed in the following steps that the unidirectional delays (i.e. delays related to the hybrid module upstream link) Δ1 and δ4 are known. These could be measured using any method related to the physical layer or related to PTP (e.g. the peer-delay mechanism). In the later case, it is noted that the time offset between the hybrid module and the GM is not an issue as it cancels out within the roundtrip system of equations. The error of the measurement is only related to the frequency offset of the hybrid module with regards to the GM frequency reference. This error is negligible if the peer-delay response time (time duration between the reception of the peer-delay request and the transmission of the related peer-delay response) is small [22] (i.e. within milliseconds).

One-way mode:

1. As soon as a Sync message arrive at its Slave port, the PTP hybrid module timestamps the message with its local system clock. This gives the timestamp t2.

2. It encapsulates the received Sync message into an internal packet called “Service_Sync” which also contains the timestamp t2 together with an internal context structure. The later is used to convey information such as computed delays (e.g. t2’-t2) and master ID.

3. At the Master port the module can deduce the Sync message residence time as observed by the module with its local system clock. This is given by t2’ – t2 with regards to Figure 2.

4. The module derives a new timestamp T1 from t1, t2’ - t2 and Δ1, as described in the Figure 2 above: T1 = t1 + (t2’ – t2) + Δ1. It generates a new Sync messages towards the Slave clock with the originTimestamp field value being T1.

Thus, T1 cumulates the upstream link delay and the “Sync message residence time” 6 , similarly to a P2P TC which cumulates those into the Sync message Correction field. It is noted here that the reference document [19] has already observed and demonstrated the equivalency between a standard BC and a P2P TC in terms of synchronization signal. The fundamental difference between the new hybrid module and the BC is that the former does not recover the synchronization network time reference. Thus, there is no need for the “Time recovery” block and any related filtering algorithm(s). It is also noted that the reference document [19] has mentioned a signal internal to a network node aiming at synchronizing the transmission of Sync messages at a Master port with the reception of Sync messages at the Slave port on the same network node. This signal is essentially defined for such a synchronization purpose and is not designed to correlate information between the received Sync message (at the Slave port) and the transmitted Sync message (at the Master port), as it is the case for the present described PTP hybrid module.

Two-way mode:

If two-way mode is deployed at the Slave clock (e.g. the Slave uses two-way mode to estimate the upstream link delay), then the additional steps below are necessary. The principles are quasi-symmetrical to the ones of the one-way mode.

5. At reception of the Delay_Req message from the Slave clock, the hybrid module timestamps the message using its local system clock. This gives the timestamp t3’.

6. Similarly to the one-way mode, the PTP hybrid module encapsulates the received Delay_Req message into an internal packet called “Service_Delay_Req” which also contains the timestamp t3’ and the internal context structure. The later is used to communicate, for instance, the Slave clock ID.

7. At the Slave port the module derives the “Delay_Req message residence time” with t3 – t3’ (Cf. Figure 2). This “residence time” is memorized locally jointly with the

6 Strictly speaking, it is abusive to refer to a message residence time, as it is not the same message but a new one which is transmitted.

associated context and other mandatory information (e.g. message sequence number). A new Delay_Req message is created and sent to the (Grand) Master clock.

8. When the associated Delay_Resp is received from the (Grand) Master, the module encapsulates it within an internal packet called “Service_Delay_Resp” which also contains additional information related to the context.

9. At the Master port facing the Slave clock, a new timestamp T4 is derived: T4 = t4 – (t3 – t3’) – δ4, thus t4 reduced by both the upstream link delay and the associated “Delay_Req residence time”. This is the symmetrical computation with regards to T1 derivation.

10. Finally, a new Delay_Resp is created and sent out towards the Slave clock with the originTimestamp value being T4.

Again, the PTP hybrid module acts here as a P2P TC while correcting the Delay_Resp originTimestamp with the accumulation of the upstream link delay and the Delay_Req “residence time”. The Slave clock can use T1 and T4 in combination with T2 and T3 in order to estimate unidirectional delays related to the link between itself and the upstream hybrid module.

Performance:

In terms of noise generation, the hybrid module is equivalent to a one-step TC. Indeed, the former undergoes the same constraints as the latter during an Event message transmission process. The following descriptions allow for better understanding those constraints taking, as an example, the propagation of the Sync signal (i.e. the transfer of time information between associated Sync messages; i.e. Syn(t1) and Sync(T1) in Figure 2) across the hybrid module:

1. At reception of the Sync message (i.e. Sync(t1)) from the peer-master at its Slave port, the hybrid module has to hardware timestamp the message using the local system clock, similarly to any standard PTP module (i.e. either TC or BC),

2. At transmission of the Sync message (i.e. Sync(T1)) to the peer-slave at its Master port, the hybrid module has to perform the following operations in a quasi-simultaneous manner (i.e. in a period of time acceptable as compared to the targeted time accuracy and a given deployment architecture):

- To capture the Sync message transmission timestamp using its local system clock, similarly to any standard PTP module (and specifically to a one-step TC).

- To compute the new timestamp T1 (Cf. Figure 4). This operation is equivalent to the computation of the Sync residence time performed by a one-step TC.

- To report the previous computation result (i.e. T1 value) into the new Sync message to be sent over the transmission line towards the peer-slave. This is equivalent to the operation of modifying the Sync message correctionField performed by a (one-step) TC.

Thus, a hybrid module should produce the same performance as a one-step TC with regards to the time synchronization accuracy.

C. Two-way mode issue discussions Within the two-way mode, the concern about the hybrid

module is that the rate of Delay_Req/Delay_Resp message exchanges with the (Grand) Master is proportional to the number of downstream Slave clocks. This could raise some scalability issue.

However, within the context where SyncE is used to maintain a very stable and accurate frequency, the Delay_Req/Delay_Resp message rate from/to a given Slave clock is likely to be very small.

Another way around is to perform the complete combination of the aforementioned steps (including Delay_Req/Delay_Resp exchange (with the (Grand) Master) with only one Slave clock and to use some information of this exchange to derive the respective “T4” timestamp for other Slave clocks. The principles are illustrated by the Figure 3 below.

Figure 3 – Two-way scalability issue work around

The Tn4 timestamp (“T4” timestamp related to Slave clock number n) is derived from T14 (“T4” timestamp related to the Slave clock number 1) as Tn4 = T14 + (tn’ – t3’) assuming that the response time (the time between the reception of the Delay_Req and the transmission of the associated Delay_Resp) is constant for simplicity. Otherwise, a delta has to be measured and taken into account within Tn4 computation. Thus, Tn4 = t4 – (t3 - t’3) – δ4 + (tn’ – t’3) = t4 – (t3 – tn’) – δ4, with tn’ the equivalent of t3’ timestamp related to Slave n.

D. Generalization of the hybrid module concept to a network Similarly to the concept of distributed BC and distributed

TC, the aforementioned concept of a hybrid module can be generalized and applied to a synchronous network or sub-network having its own time reference. Figure 4 illustrates such a distributed hybrid module.

The operation of the distributed hybrid module is similar to a single-node hybrid module, except that the Slave and the Master ports are located on to different respective network nodes separated by a communication network, called as the “transport network”.

The transport network is synchronous with a time reference distributed to the whole network, or at least to Node 1 and Node N (i.e. time reference available at the edges of the transport network). This time reference is called as “network clock” making analogy with the ITU-T terminology for Circuit Emulation Service (CES) over Packet Switch network (PSN).

Figure 4 – Distributed hybrid module

The time reference to be distributed across the transport

network is called as “service clock”.

With regards to a distributed BC, the proposed distributed hybrid module allows for a more scalable solution when it comes to support the transport of multiple service clocks across the transport network. Indeed, a distributed BC (with the BC concept as defined by 1588V2 standard) has to recover each service clock before distributing it to downstream Slave clocks. On the contrary, the distributed hybrid module only relies on the network clock in order to compute the “residence time” of Event messages, similarly to a distributed TC.

III. A DUAL MODULE FOR A FLEXIBLE AND OPTIMIZED TIME DISTRIBUTION ARCHITECTURE

As mentioned previously, the current plan for the first Telecom time profile is to consist of a hop-by-hop architecture with BC only. However, a second Telecom time profile could also include TCs.

In terms of network node implementation, if a BC functionality is already available, then it represents a small effort to add TC functionality as the later is simpler and may reuse facilities already implemented such as hardware timestamping and time synchronization between different cards.

The advantage of a dual module implementing both BC and TC functionalities is that it gives more flexibility to the network operator. For instance, the network operator can migrate smoothly (e.g. no hardware change) from the first Telecom time profile to the second telecom time profile (not completely defined at this writing time) by simply switching certain network nodes from BC to TC and vice versa.

A. Dual BC/TC dynamic configuration In certain cases, there is a need for dynamically

reconfiguring the dual module operating mode (either BC or TC). This is the case, for example, when the principal path and the backup path of the same synchronization signal traverse the same network node. And, for some reasons, the number of nodes in the backup path is such that the accumulated noises exceed the allocated time error budget if only BCs are deployed. This requires the switching of the dual module (and other eventual dual modules on the backup path) to TC functionality, as per, for instance, the lower time error induced by TCs. This is illustrated by the Figure 5 use case below.

Figure 5 – Dual module deployment scenario

Referring to the Figure 5, the synchronization signal is transported over a backup path in the event of a failure on the main path. The backup path would exceed the maximum number N of recommended (e.g. maximum number of BCs on the ITU-T Hypothetical Reference Model is 20) BCs, if ever the dual module operates as a BC. Thus, there is a requirement to switch this module to a TC mode in a dynamic manner.

This can be performed thanks to a new Type Length Value (TLV) field called “Operating Mode TLV” or OP-TLV. According to the value transported by this TLV, the dual module will operate either in BC or TC mode.

The OP-TLV can be added into signaling messages which follow the same path as the synchronization signal. These signaling messages can be sent regularly in order to update the operating mode of the dual module.

For a more dynamic mode of operation, the OP-TLV can be added directly into Event messages. This can be deployed, for instance, within a transport provider network which carries multiple customer PTP flows across its network. And, within the same network node implementing a dual module, the PTP flows pertaining to one customer are supported by a BC functionality whereas PTP flows pertaining to another customer is supported by a TC one. The different type of

timing flow support configurations depend on the Service Level Agreement (SLA) signed with each individual customer.

Figure 6 – OP-TLV implemented in signaling messages

Within the Figure 6 above, the one but last PTP module

(which is a BC) on either path is assumed to have the ability to detect that the network limit is reached; i.e. max number N of allowed BCs is reached. For example, it can rely on the remove-step parameter, assuming that the default operating mode of all upstream PTP entities is BC. In the context of the backup path, this network limit condition is actually reached. This triggers the last BC in the chain to send out OP-TLV towards the downstream module (a dual module) for a TC-operation mode.

For a generalization of the concept, it is also possible to implement a distributed dual module. For instance, within the context where customers are deploying the second time Telecom profile, the transport network can behave either like a distributed BC or a distributed TC, accordingly to the OP-TLV value sent from the customer network.

B. Dual BC/Hybrid configuration Similarly to the dual BC/TC module concept, it is

interesting to investigate a dual BC/Hybrid module, with the hybrid functionality as described in previous chapter II.

One of the possible use cases for the deployment of such module is the context of synchronization network reconfiguration in the first Telecom 1588V2 time profile.

As mentioned previously, the PTP time source and the SyncE frequency source of the synchronization network are initially syntonized. This allows for the deployment of BCs in a hop-by-hop architecture where each BC uses SyncE as the source of frequency and PTP as the source of time.

In the event of a network failure which renders these two sources unsyntonized, it is then possible to reconfigure the dual BC/Hybrid modules to operate in the hybrid mode in order to uncorrelate PTP from SyncE. As discussed previously, the

hybrid module is better positioned to cope with the situation where frequency and time sources are not syntonized.

Similarly to the dual BC/TC case, an additional TLV can be created in order to allow for a dynamic configuration of the operation mode of such a dual module.

IV. CONCLUSION Within the definition of Telecom profiles for the

distribution of time using 1588V2, discussions were generally carried out while comparing BCs against TCs and vice versa.

This paper, on the contrary, advocates for the collocation of both features within the same network element heading towards a flexible and optimized use of 1588V2-based on-path support. This also allows for a smooth transition between the first Telecom 15588V2 time profile towards the second one, and eventually the coexistence of both profiles within a multi-carrier context.

This paper also proposes a hybrid module which aims at combining the simplicity of a TC with the manageability of a BC. Similarly to a TC, this hybrid module essentially allows for unbinding frequency and time layers, relaxing constraints on the synchronization network deployment. Advantageously, it avoids the “layer violation” concern often raised against TCs while staying integrated within the overall unique automatic reconfiguration scheme driven by the (alternate) Best Master Clock Algorithm (BMCA).

ACKNOWLEDGMENT The authors would like to thank Stephan Roullot and Peter

Roberts for reviewing this paper and for providing valuable comments.

REFERENCES

[1] IEEE 1588 standard for a precision clock synchronization protocol for networked measurement and control systems (version 2, 1588-2008). April 2008.

[2] ITU-T SG15/Q13, WD28. France Télécom. Issues with the Transparent Clock concept of PTPv2 in a telecom environment. Shenzhen, October 2010.

[3] ITU-T SG15/Q13, WD56. Zarlink Semiconductor Inc. Transparent Clock & IEEE 802.1Q Layer Violation [G.8275.1]. Shenzhen, October 2010.

[4] J. Han et al. A Practical Implementation of IEEE 1588-2008 Transparent Clock for Distributed Measurement and Control Systems. IEEE Transactions on Instrumentation and Measurement, Vol. 59, No. 2, February 2010.

[5] ITU-T SG15/Q13, C1340. Alcatel-Lucent. Time-of-Day distribution across Transport Provider Networks. Geneva, February 2011.

[6] ITU-T SG15/Q13, C1510. Huawei Technologies Co. Comparison of Boundary Clock Simulation Models. Geneva, February 2011.

[7] J. Eidson. University of California at Berkeley. Suggestions on Implementing ITU Requirements for IEEE 1588-2008. Berkeley, November 2009.

[8] ITU-T SG15/Q13, C 896. Huawei Technologies Co, China Mobile Communications Corporation. The use of SyncE and IEEE1588v2 for Phase/Time Distribution. Geneva, May 2010.

[9] ITU-T SG15/Q13, C1353. Symmetricom. Syntonization of Boundary Clocks. Geneva, February 2011.

[10] ITU-T SG15/Q13, WD36. RAD Data Communications. Analysis of

Noise Contributers in End-to-End Transparent Clocks. Edinburgh, December 2010.

[11] ITU-T SG15/Q13, WD61. Cisco. BC and TC noise sources in the equipment. Edinburgh, December 2010.

[12] P. Carlsson et al. Delay Performance in IP Routers. 2nd International Working Conference (HET-NETs '04). Ilkley UK, 2004.

[13] D. Constantinescu et al. Modeling of One-Way Transit Time in IP Routers. Advanced International Conference on Telecommunications and International Conference on Internet and Web Applications and Services (AICT/ICIW 2006). 2006.

[14] A. Popescu et al. Measurement of One-Way Transit Time in IP Routers. Invited tutorial, 3rd International Working Conference (HET-NETs '05). Ilkley UK, 2005.

[15] K. Papagiannaki. University of London. Provisioning IP Backbone Networks Based on Measurements. February 2003.

[16] ITU-T SG15/Q13, C 176, RAD Data Communications, Semtech. Transparent Clock Syntonization Necessity Analysis for IEEE 1588 Telecom Profile. Miami, November 2008.

[17] C. Gordon. Tekron. White Paper - Introduction to IEEE 1588 & Transparent Clocks. 2009.

[18] National Instrument. IEEE 1588 Boundary Clock and Transparent Clock Implementation using the DP83640 AN-1838. 2008.

[19] G.M. Garner et al. Improvements to Boundary Clock Based Time Synchronization through Cascaded Switches. 2006 Conference on IEEE 1588 Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems.

[20] D. Mohl et al. Improved synchronization behavior in highly cascaded networks. 2007 International IEEE Symposium on Precision Clock Synchronization for Measurement, Control and Communication (ISPCS2007). Vienna, Austria, October 1-3, 2007.

[21] ITU-T SG15/Q13, WD14. Huawei Technologies Co. Ltd. Test Results of IEEE1588v2 hop-by-hop time synchronization using Boundary Clocks. San Jose, March 2010.

[22] ITU-T SG15/Q13, C1514. Huawei Technologies Co. Ltd. Effect of Pdelay or Delay Request/Response Turnaround Time, and Sojourn Time, on Boundary Clock Performance. Geneva, February 2011.