IEEE1588 profile development in ITU-T Michael Mayer Ciena Corporation March, 2012 Ciena 2011
Outline -General approach to Profile development in ITU-T -Review of IEEE1588 -Telecom architecture: how it impacts ITU-T profile development -Frequency profile and architecture -time/phase profile development -Future work Ciena 2011 2
ITU-T related work: development of PTP profiles, architecture and related Recommendations Ciena 2011 3 Ciena Confidential and Proprietary
General approach to profile development in ITU-T Telecom application for IEEE1588 is significantly different from original IEEE1588 target architecture. Approach used for ITU Profile development: Architecture will describe overall application and provide basis for justification of aspects of the profile Profile document will contain profile details consistent with requirements for profiles as per IEEE1588 Profiles generally cover protocol aspects only. Clock performance will be covered in other documents Additional requirements may be in Architecture documents Similar approach to be taken for both frequency and time/phase Note: Claiming compliance to IEEE1588(V2) does not mean an implementation is compliant with the telecom profile. (Need to be compliant with ITU-T document.) Ciena 2011 4
ITU-T standards related to PTP Telecom Profiles to be specified within ITU Recommendations Phase 1: Frequency Completed June 2010 ITU-T Recommendation G.8265 defines the architecture for time transfer using IEEE1588 (also applicable to NTP) ITU-T Recommendation G.8265.1 defines the PTP Telecom Profile Phase 2: Time/phase Under development ITU-T Recommendation G.8275 will define the architecture ITU-T Recommendation G.8275.1 will define the telecom profile for time/phase Ciena 2011 5
Relationship to other ITU Recommendations Ciena 2011 6
Review of IEEE1588 Aspects common to both Frequency and Time/phase Ciena 2011
IEEE1588: What is it? IEEE1588 : Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems Defines mechanism for distribution of time over a data network Initial target application: factory automation Interest in Telecom industry to address the growing need for dealing with synchronization in an evolving packet network Key applications: Wireless backhaul GPS replacement Two versions of IEEE1588 exist A All telecom applications need version 2 (2008) ITU-T has been working to define the Telecom Profile Ciena 2011 8
IEEE1588: currently two versions IEEE1588 (Version 1) was initially intended for control applications such as factory automation (e.g. robotics) Provides higher accuracy for time distribution than the then existing protocols such as NTP Limitations were noted for telecom applications IEEE1588 (Version 2) provides changes to be better suited to telecom and other applications. Changes included Allows use of unicast transmission Increases message rates Additional mappings Extendable using TLV mechanism Compact message format Addition of transparent clocks Profile mechanism to address specific applications Ciena 2011 9
Profile definition (From IEEE1588) IEEE1588 profile definition: The purpose of a PTP profile is to allow organizations to specify specific selections of attribute values and optional features of PTP that, when using the same transport protocol, inter-works and achieve a performance that meets the requirements of a particular application. A PTP profile is a set of required options, prohibited options, and the ranges and defaults of configurable attributes. Profiles specifications shall be consistent with the specifications in subclauses 19.2.1 and 19.2.2. Ciena 2011 10
IEEE1588 fundamentals IEEE1588 defines: PTP: Precision Time Protocol Clock types (ordinary, boundary, transparent) Clock modes (one-step/two step) Detailed message types (sync, delay_request ) C lock selection (Best Master Clock algorithm) Profiles must address all aspects in IEEE1588 Ciena 2011 11
The basic process for time transfer W W Master Network Slave The Challenge: Maintain the same time of geographically separate clocks to sub-microsecond accuracy Ciena 2011 12
Accurate frequency transfer PRC Freq W W Freq Master Network Slave With time transfer, frequency can also be transferred -provides basic functionality provided by current synchronization distribution networks Ciena 2011 13
Recall: Accurate frequency transfer was based on time transfer. PRC Freq W W Freq Time/ phase Time/phase Master Network Slave Mechanism used for deriving frequency is based on time transfer -Transfer of time/phase now requires time/phase interfaces - Network impairments impact time/phase limits and may require PTP processing (via boundary or transparent clocks) -two way operation required Ciena 2011 14
Basic time transfer/adjustment process A (Master) T 1 T 4 B (Slave) T 2 T 3 Messages are exchanged between network Elements. NE B has T 1, T 2, T 3, and T 4. The following can be calculated Propagation time (A to B) = ((T 2 -T 1 )+(T 4 -T 3 ))/2 Offset between A and B= ((T 2 -T 1 )-(T 4 -T 3 ))/2 Slave can then adjust clock to match Master T x Key assumption: transmit and receive paths have symmetric delay time Accuracy of time transfer impacted by -asymmetry -accuracy of Time-stamp -packet delay variation Ciena 2011 15
Additional methods: One way/two way mode A (Master) B (Slave) Message transfer defines T 1 Time offset and propagation time T 2 Bi-directional transfer needed to achieve phase/time T 3 Two way mode T 4 T x Frequency does not require measurement of propagation or delay offset and can be calculated only with Sync messages One-way mode time Ciena 2011 16
Improving accuracy: Two step clock A (Master) T 1 T 4 T x time B (Slave) T 2 T 3 The PTP protocol adds a Follow-up message type that may be used -Timestamps are defined to be at the NE/Network boundary -Since the time-stamp is data inserted into a payload data unit, typically at layer 2 or layer 3, the actual launch time of the packet will differ from the value contained within the PDU -Follow-up can be used to contain the actual measured time of packet launch to allow time to be calculated with grater precession. Ciena 2011 17
Summary of IEEE 1588 message types IEEE defines two classes of messages, not all require accurate timing Event messages: must be time-stamped Sync Delay request Pdelay request Pdelay response General: not required to be time stamped Announce Follow Up Delay Response Pdelay Response follow up Management Signaling Not all messages are required for all applications (e.g. Pdelay request only applies to peer-to-peer transparent clock Ciena 2011 18
Telecom architecture: How it impacts profile development Ciena 2011 19 Ciena Confidential and Proprietary
Recall: IEEE1588 architecture 1 6 2 5 3 4 IEEE1588 architecture: -Single domain -only one clock is elected as the master within a domain. -both master and slave participate in clock selection (Best Master Clock Algorithm) -no distinction between master and Slave (both are ordinary clocks -self learning Note: boundary and Transparent clocks Will be discussed later Ciena 2011 20
Telecom architecture (1) -General telecom protection requirement: visibility to multiple masters -Clock selection is based on decisions taken by the Slave only. -Primary and secondary masters: must load share -Provisioned to achieve deterministic topology Server (Secondary) Server (Primary) protection working Packet Network Slave Clock Ciena 2011 21
Telecom architecture (2) -Slave/masters are not the same -N:1 on master -1:1 on slave -Cost -Direction of timing transfer (slaves never become master clocks) Reference 1 F i Packet Master clock Packet Slave Clock Network Packet Timing Signals F out + d 1 Packet Slave Clock F out + d 3 Packet Network Packet Slave clock F out + d 2 1: Note, the reference may be from a PRC directly, GNSS or via a synchronization network Ciena 2011 22
Telecom architecture (3) -Additional telecom requirement: Operation in a multi carrier environment Covers the Wireless Backhaul case Not an issue for version 1 but required to be specified for future profiles (including operation with Sync Ethernet) Network Operator A Packet Master Clock Network Operator B Timing Flow Network Operator A Packet Slave Clock Telecom architecture and requirements critical to profile development Ciena 2011 23
Architecture for time Architecture for time is being specified. All Network elements are PTP aware (GM, T-BC, Slave) Ciena 2011 24
Frequency profile and architecture G.8265 and G.8265.1 Ciena 2011 25 Ciena Confidential and Proprietary
ITU-T Telecom profile development (frequency) G.8265 General architecture and requirements Protection aspects Multi-domain aspects described Clock output (QL squelching, QL mapping, etc) Applicable to both PTP and NTP G.8265.1 PTP profile for frequency Covers uni-cast message transmission only Only end nodes participate in PTP (I.e. no BC or TC) Message rates defined Protection (alternative to Best Master Clock) General clock structures Operation of PTP protocols in multiple domains (Note: further details are included at the end of this presentation) Ciena 2011 26
Impact of telecom architecture on frequency profile IEEE1588 Best master clock algorithm not consistent with current practice slave within a domain sees only one active master Domains: PTP operates in single domain Only one master active Precludes load sharing and multiple master visibility Solution used by G.8265/G.8265.1: Define a Telecom Slave clock structure based on multiple instances of Slave only ordinary clocks (SOOC) Define alternate BMC based on G.781 sync selection* Restrict communication between masters by establishing separate domains *G.781 defines clock selection based on SSM used in SONET/SDH Ciena 2011 27
IEEE1588 Ordinary Clock Output of clock can be taken from control loop to produce -frequency -phase (e.g. 1 pps) -Time ITU-T defines Telecom Slave based on the above model Ciena 2011 28
G.8265.1 Telecom Slave construct Packet Master Clock 1 (Active) PTP domain = 5 Packet Master Clock 2 (Active) PTP domain = 5 Packet Master Clock 3 (Active) PTP domain = 5 Separate PTP domains Network Slave-only OC instance 1 Data Set with parentds including information of grandmaster 1 Slave-only OC instance 2 Data Set with parentds including information of grandmaster 2 Slave-only OC instance 3 Data Set with parentds including information of grandmaster 3 QL, Priority, PTSF QL, Priority, PTSF QL, Priority, PTSF Master selection process as per clause 6.4.2/G.8265.1 Telecom slave Selected PTP packet timing signal from the ones provided by the different grandmasters Ciena 2011 29
G.8265.1 Telecom slave additional details (2) -Protocol operates within single domain -Multiple instances to provide protection -Details of selection are defined by G.781 -Each GM path treated like a timing trail in SONET/SDH -model describes behaviour, not Implementation -Some aspects still TBD (e.g. packet timing signal fail) Ref: G.8265.1 Figure 3 Ciena 2011 30
Time/phase profile development Ciena 2011 31 Ciena Confidential and Proprietary
Status of Architecture for Time/Phase For time/phase, general architecture is being developed in G.8275 Expect to build upon frequency architecture (G.8265) Critical difference: Intermediate packet nodes will participate in PTP protocol Boundary clocks supported (the telecom BC ) Transparent clocks in future versions Physical layer timing to provide syntonization via synchronous Ethernet Profile may need to restrict syntonization mechanism General Architecture for frequency/time should not be significantly different Other aspects (e.g. protection) will also need to be defined Alternate BMCA algorithm will need to be defined Ciena 2011 32
Time/phase Profile: clock types ITU-T Telecom profile for frequency applies only to Ordinary clocks. Both Grandmaster and Slave clocks are ordinary clocks Time/phase will require additional PTP message processing Boundary and Transparent clocks IEEE1588 defines several types of clocks Ordinary One-step/Two-step, One-way/Two-way Boundary clocks Used to bridge between different transport technologies Transparent clocks Contains residence time bridge to correct for delay Structure and impact of BC/TC currently under study within ITU-T Ciena 2011 33
Boundary clock GM BC OC OC OC Boundary clock: -Multiple outputs -bridges different technologies -can also off-load grandmaster -subject to impairment accumulation Ciena 2011 34
Boundary clock details GM GM Slave port BC Data sets Local Clock BC OC OC OC Master port Master port Master port Boundary clock: OC -One slave port, multiple masters -Single local clock -can also off-load grandmaster -subject to impairment accumulation (local clock needs to be syntonized) -Syntonization via packet or SyncE OC OC Ciena 2011 35
BC model (ITU-T) ITU-T is developing a Telecom Boundary Clock (T-BC) Also addresses performance aspects (noise sources) to form basis of performance simulations e phy PTP message event (Sync/Follow- Up, Del_req/resp or Pdelay_req/resp) + + Time Measurement, possibly with filtering e ts Time Offset (possibly filtered) Physical layer frequency Phase detector Loop filter Filtered Frequency offset VCO e synce + + Local Frequency Output Counter and Time offset correction Local Time Output Local Clock EEC Figure Ref: WD5 Feb.2011 Ciena 2011 36
Transparent clock Transparent clock added to Version 2 of IEEE1588 Contains a residence time bridge to measure the propagation time through a PTP enabled switch. Two types of Transparent clocks: Peer-to-peer (measures residence time and link delay) End-to-end (measures only residence time) Accumulated residence time may be used by slave to improve accuracy End-to-end and Peer-to-peer clocks are not interchangeable Potential administrative complexity Also introduces layer violation (which is the source address?) Architecture to be studied in ITU-T for inclusion in future profile First time/phase profile may be limited to BC only. Ciena 2011 37
Residence time bridge Residence time bridge in Transparent Clock Compute the time taken to pass through a switch fabric Residence times are accumulated for each port in correction field within associated PTP messages. Update field within IEEE1588 message (Follow_Up or Pdelay_Resp_Follow_Up). correction is based on the difference in the timestamp generated when the event message enters and leaves the transparent clock. (checksums are updated as required by the network protocol). Ciena 2011 38
Transparent clock block diagram (end-to-end) GM TC TC OC (Figure 4 from IEEE1588) Ciena 2011 39
Transparent clocks: two variants Two types of transparent clocks Peer to peer (P2P) Measures the residence time and link delay on each link (between peers) Uses Peer delay mechanism All clocks must implement peer delay Combined TC/OC required at slave to accommodate Peer delay mechanism. End to end (E2E) Measures the residence time through each switch. Peer delay not used (no Peer_request/response messages) Updates the follow up message Greater flexibility in deployment (can be used over non-ptp aware networks) Ciena 2011 40
Accuracy/issues Residence time is calculated based on local clock. Errors in local clock frequency impact overall accuracy of time estimate Improve by using Rate Estimation(RE), Rate Control (RC) Impairments accumulate to a lesser degree than with BC Issues: Data field is updated by device that is not sending device. What is the appropriate source address (SA)? (Layer violation) Accuracy requires all devices to be PTP aware in order to get full benefit of improvement to residence time. (Peer-to-peer only) P2P and E2E Transparent clocks are not interchangeable. ITU-T work has started on time profiles which will study network architectures involving BC and TC clocks Ciena 2011 41
Status and Future work Ciena 2011 42 Ciena Confidential and Proprietary
Upcoming standardization/future work First version of profile deals only with frequency distribution. New work started (October 2010) to define profiles for time/phase New architecture document (G.8275) New profile(s) (G.8275.1, G.8275.x) Critical architecture questions to be resolved: networks with boundary or transparent clocks performance aspects of clocks have not been addressed management of sync network based on IEEE1588 Use with synchronous Ethernet New profiles and architectures will be standardized in the G.827x series of Recommendations Ciena 2011 43
Current Status and future work ITU-T Recommendation G.8275 (time/phase architecture) Current plan: completion July 2013 ITU-T Recommendation G.8275.1 (PTP profile for time/phase) Covers Boundary clocks only Current plan: completion July 2013 Ciena 2011 44
Q&A Supplemental material: Details of published Telecom Profile (frequency) to follow for reference Ciena 2011 45 Ciena Confidential and Proprietary
Summary of Requirements (from G.8265) applicable to both NTP and IEEE1588 Packet based mechanisms for frequency distribution must meet the following requirements: Mechanisms must be specified to allow interoperability between master and slave devices (clocks) Mechanisms must permit consistent operation over managed wide area telecom networks. Packet based mechanisms must allow interoperation with existing SDH and Synchronous Ethernet based frequency synchronization networks. Packet based mechanisms must allow the synchronization network to be designed and configured in a fixed arrangement Protection schemes used by packet based systems must be based on standard telecom operational practice and allow slave clocks the ability to take timing from multiple geographically separate master clocks. Source [clock] selection should be consistent with existing practices for physical layer synchronization and permit source selection based on received QL level and priority. Packet based mechanisms must permit the operation of existing, standards-based security techniques to help ensure the integrity of the synchronization. Ciena 2011 46
IEEE telecom profile for frequency Details of the telecom profile for frequency distribution are contained in ITU-T Recommendation G.8265.1 and is based on the requirements and architecture in G.8265. Published versions of ITU-T Recommendations (standards) are available at no cost at the following URL: http://www.itu.int/en/itu-t/publications/pages/recs.aspx The details of the profile in G.8265.1 are summarized in the following slides. Ciena 2011 47
IEEE1588 requirements for a profile A PTP profile should define: - Which of the best master clock algorithm options -Which of the configuration management options, -Which of the path delay mechanisms, delay request-response, -The range and default values of all PTP configurable attributes and data set members. -The transport mechanisms required, permitted, or prohibited. -The node types required, permitted, or prohibited. -The options required, permitted, or prohibited. -A PTP profile shall extend the standard only by: -The use of the TLV mechanism of IEEE1588 Section 14.3. -The specification of an optional best master clock algorithm (IEEE1588 9.3.1.) -The specification of an optional management mechanism, see IEEE1588 15.1.1. -The provisions of IEEE1588 Section 19.2.2. -The provisions of IEEE1588 Section 7.3.1. Ciena 2011 48
Components of the Profile (the details 2) Telecom profile: Which of the best master clock algorithm options Telecom profile is based on G.781 sync selection (e.g. same as SONET/SDH) Implemented using a function outside of the PTP profile Which of the configuration management options, Master should always remain masters, and slaves should always remain slaves. Autonomous re-configuration of the synchronization network (e.g. by use of an automatic process such as the Best Master Clock Algorithm described in IEEE1588-2008) should be prevented. Which of the path delay mechanisms, delay request-response, The delay request /delay response mechanism can be used in this profile. The peer delay mechanism shall not be used in this profile. The range and default values of all PTP configurable attributes and data set members. Too many to list here. See G.8265.1 Tables A.1 to A.6 Ciena 2011 49
Components of the Profile (the details 3) Telecom profile: The transport mechanisms required, permitted, or prohibited. UDP/IPv4 as per IEEE1588 Annex D. Note, the use of IP is for addressing only. A managed network is assumed. The node types required, permitted, or prohibited. Required: Ordinary clocks Slaves may be one-way or two way, one-step or two step Masters must support both one/two way and one/two step Prohibited: boundary and transparent clocks The options required, permitted, or prohibited. Unicast messages and message negotiation only. (slave initiated) Request unicast TLV/Grant Unicast TLV Clock ID format based on EUI-64 must be used. Other formats not permitted Flags used: Flag alternatemasterflag unicastflag PTP profile Specific1 PTP profile Specific2 Reserved Value FALSE TRUE FALSE FALSE FALSE Ciena 2011 50
Components of the Profile (the details 4) Telecom profile: A PTP profile shall extend the standard only by: The use of the TLV mechanism of 14.3. TLV s (Vendor and standard organization extension) are not used in the first version of the profile The specification of an optional best master clock algorithm,see 9.3.1. Clock selection based on external means, consistent with G.781 and implemented in a Telecom slave clock The specification of an optional management mechanism, see 15.1.1. For further study The provisions of 19.2.2. Not applicable The provisions of 7.3.1. The PTP protocol is based on multi-case, but unicast is allowed provided that the behaviour of the protocol is preserved. The profile mandates Unicast operation and preserves the behaviour of the profile Ciena 2011 51
Components of the Profile (the details 5) Message rates are defined within the profile to constrain the load on the network. Exact message rate used is dependent on clock parameters not defined within the standard Message Minimum rate Maximum rate Sync 1 packet every 16s 128 packets/sec Follow_up 1 packet every 16s 128 packets/sec Delay_req/ Delay_resp 1 packet every 16s 8 packets/sec Announce 1 packet every 16s 8 packets/sec Signaling No rate specified No rate specified Ciena 2011 52