BRKSPG 2557

5G Synchronization
Design, Testing & Deploying Timing

Deploying Timing Across the Transport
Dennis Hagarty, Technical Marketing Engineer
BRKSPG-2557
Cisco Webex Teams
Questions?
Use Cisco Webex Teams to chat
with the speaker after the session
How
1 Find this session in the Cisco Events Mobile App
2 Click “Join the Discussion”
3 Install Webex Teams or go directly to the team space
4 Enter messages/questions in the team space
BRKSPG-2557 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 3
Agenda
• Introduction
• Overview of timing (short)
• 5G? But I need timing and I’m not a mobile operator!
• Timing Deployment Topologies
• Testing Timing
• Deployment Lessons and Traps
• Conclusion and Further Information
Overview of Timing
What types of Sync are there?
Frequency Synchronization TDM = Time Division Multiplexing
SONET = Synchronous Optical Network
SDH = Synchronous Digital Hierarchy
• Avoid Slips on TDM Interfaces (E1/T1, …)

• Make Synchronous networks (SONET/SDH) work
• 2G, 3G, and 4G FDD Cellular Networks – ensure radios transmit exact frequency
• Service Providers, power grids, railways = Circuit Emulation (CEM)
• Carried with Synchronous Ethernet (preferred) or packet transport (PTP)
Packet to Packet to
TDM Router TDM Router
Synchronous
Ethernet
Same Clock
Phase Synchronization
 Requirement (TDD, LTE-A radio co-ordination): 3µs between base stations

 Implementation: ±1.5µs from a common reference time
Common

Reference  
Time



Sources of Time
• PRC = Primary Reference Clock = source of Frequency

• Atomic clocks (yours or those from national labs)
• GNSS satellite systems (a flying network of atomic clocks)
• BITS/SSU network (normally sourced from the first two)
• PRTC = Primary Reference Time Clock = phase, time and frequency
• Atomic clocks PLUS calibration to UTC
• GNSS satellite systems (GPS, GLONASS, Galileo, …)
• Standards for “enhanced” versions:
• ePRTC (defined in G.8272.1)
• PRTC-B (defined in G.8272 with PRTC-A)
Distributing Time BITS
in
• Frequency SyncE out SyncE Out

• SyncE/ESMC (frequency is in the Ethernet signal)
• BITS/SSU TDM network and 10MHz/2MHz/E1/T1 signals
• PTPv2 (packet based)
• Phase/Time
• PTPv2 (packet based)
• 1PPS (1 Pulse per Second = wires)
• ToD (RS232/RS422)
• IRIG-B (physical signal = wires)
• GNSS systems (also for frequency)
What is PTPv2?
• IEEE 1588-2008 = Precision Time Protocol = PTPv2

• PTP is, like NTP, a Two-Way Time Transfer (TWTT) protocol
• Designed for sub-microsecond (ns!) accuracy & precision
• V1 about industrial automation, v2 for WAN (i.e. IP) deployment and extensibility
• A new version of PTP (V2.1) is (still) under development by IEEE. 2020?
Slave port Master port
PTP
GM
session
Master Slave
port port
Slave Boundary Transparent PRTC and
Clock Clock Clock Grand Master
Boundary Clocks = PTP Aware
End to End Phase Alignment
Master Slave
port port
Time carried Time carried

GM
in packets in packets
Slave
Clock PRTC and
Grand Master
Time & Frequency
carried in H/W
T-GM = Telecom Grand Master -P = Partial
Major PTP Profiles T-TSC = Telecom Time Slave Clock
T-TC = Telecom Transparent Clock
-A= Assisted
IEEE 1588 IEEE IEEE ITU-T ITU-T ITU-T

Default Profiles 802.1AS C37.238 G.8265.1 G.8275.1 G.8275.2
Segments Industrial Audio/Visual SmartGrid Mobile Mobile Cable
Transport IP, L2, etc L2 Ethernet L2 Ethernet IPv4 (IPv6) L2 IPv4 (IPv6)
Transmission Multi-/Unicast Multicast Multicast Unicast Neg. Multicast Unicast Neg.
Delay Mech. Both (J.3/J.4) Peer-delay Peer-delay Delay-Resp Delay-Resp Delay-Resp
Clock Modes One/Two step Two-step Two-step Any Any Any
BMCA Default Alternate Default Alternate Alternate Alternate
TLV Extns. Optional Yes Yes No No Yes

T-GM, T-TSC-P,
Time aware bridge T-GM, T-BC,
Clocks OC, BC, TC & end station OC, TC, BC OC only T-BC-P, T-TC-
T-TSC, T-TC P, T-TSC-A
Network Any Full support Full support No on-path Full + SyncE Partial
Timing for non-Mobile
What about Timing for non-Mobile?
Why do I need to care about this?
• ITU-T has written many standards for timing and Sync

• Legacy TDM timing for SDH networks, Synchronous Ethernet for packet networks
• Network requirements, topology & end-to-end budgets (mainly mobile use-case)
• Models and performance specification for various clocks (EEC, SEC, BC, TC, GM)
• Telecom Profiles (more on this later)
• Standards work together to deliver end-to-end timing solution with defined results
• Other industries have taken similar approaches
• Applying Telecom solution to use cases in other industries
• Increasingly Telecom standards being used in conjunction with other standards
Cable and Remote PHY
https://blogs.cisco.com/sp/remote-phy-why-cin-architectures-matter
• Transport between CCAP head-end and Cable Modem now “packetized”

• DOCSIS timing needs to be created at location remote from CCAP/CMTS
• Before:
Coaxial Cable
DOCSIS Timing
CMTS/CCAP Cable Modem
• After:
CIN Packet Network
Coaxial Cable
DOCSIS
CMTS/CCAP PTP G.8275.2 Remote PHY Cable Modem
GM
PRTC / T-GM
Power and Smart Grid
Connecting Timing Domains together
• Power systems already use phase timing (e.g. legacy IRIG-B and others)
• Grid monitoring and awareness: protection and operation of distribution network
• Time-stamped voltage & current vector values sent @ up to 120 samples/second
• Traveling wave fault localization – detecting a wave/pulse from a fault in the line
• There are PTP “Power Profiles” that distribute time in substation
• Parallel Redundancy Protocol (PRP) & High-avail. Seamless Redundancy (HSR)
• GPS is normally used as a source of time for each substation – redundancy?
PTP G.8275.1
GM
PRTC / T-GM
Interworking
Function
Power Profile
in substations
© 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public
Circuit Emulation CEM
PSN
CEM
AC’s AC’s
Replacing TDM Circuits
Same Frequency
• Breaking TDM chain with packets requires a way to transport frequency

1. SyncE L1 timing with ESMC quality levels packets for traceability
2. PTP where L1 Sync is not available – recommended G.8265.1
PSN
E1
SyncE E1
PRC
PSN
E1 PTP G.8265.1 E1
GM
PRC / Master
Broadcasting
Single Frequency Networks need Phase Sync
• Even without SFN’s, network splits and merges need ~40ms alignment
• SFN transmitter synchronisation error needs <10-300μs, down to 1μs
• Commonly uses GPS as a source of phase and frequency
• Frequency/phase not only accurate, but cannot move suddenly (stable)
• GPS receivers backed up over video distribution network (PTP G.8275.1)
Audio Visual
Synchronization across the whole Audio/Video network
• Audio and Video must be Synched with each other – people quickly notice!
• AES67 and SMPTE are two PTP profiles used in A/V industry
• Based on L3 multicast – not much use of Telecom profiles
100% 100%
Audio Early Audio Late
80% 80%
UNACCEPTABLE Ok Good Ok UNACCEPTABLE
60% 60%
40% Percentage 40%
who notice
20% 20%
0% 0%
-100mS -50mS 0mS 50mS 100mS 150mS 200mS 250mS 300mS 350mS 400mS
Deployment
Topologies
Network Deployment Topologies
Standardized by the ITU-T
• Two types of network elements

• “PTP Aware” – understand PTP, process PTP and pass time accurately
• “PTP Unaware” – PTP is just another packet or frame, sensitive to traffic variation
• Phase: Two end-to-end network models for each network nodes type:
• G.8271.1: full timing support to the protocol level from the network (FTS)
• G.8271.2: partial timing support from the network (PTS)
• These network models also divide up the end-to-end budget

• For LTE-A and 5G backhaul, this is ±1.1µs/1.5µs
• Assigns the budget to the different possible causes of time error
• There are two Telecom Profiles defined, one for each use case
Nodes supporting PTP
• PTP aware nodes carry time in hardware

• Therefore, they (should) have predictable performance
• Performance is standardized by the ITU-T (G.8273.2)
• Class A = original implementation, max|TE| of 100ns, cTE of ±50ns
• Class B = newer devices, max|TE| of 70ns, cTE of ±20ns
• Class C = becoming available, max|TE| of 60ns, cTE of ±10ns
• Equivalent standard for T-TC transparent clocks for classes A, B (G.8273.3)
• With better clocks, can cross more hops or a meet a lower budget
• E.g. 5G Fronthaul may have stricter requirements (see BRKSPG-3295)
• It is easy to test/confirm this performance (coming up)
Allocating Timing Budget v Node Performance
D C G.8271.1 Network Reference Points A,B
T-BC “10”
T-BC “n” T-BC “1”
+ T-TSC
GM
Class A
Random Link
Short Term
Network Asymmetry
Hold Over PRTC / T-GM
Variations Compensation
±50ns ±50ns ±50ns cTE = ±50
±150ns ±250ns ±200ns ±250ns
End Application ±100ns
T-BC “20”
T-BC “n” T-BC “1”
Short Term
+ T-TSC
Random
Network
Link
Asymmetry
GM Class B
Hold Over
Variations Compensation PRTC / T-GM cTE = ±20
±20ns ±20ns ±20ns
±150ns ±250ns ±200ns ±380ns ±100ns
End Application
± 1.1us Network Equipment Budget

± 1.5us End to End Budget
Class A: includes 10 x T-BC and 1 x T-TSC (11 x 50ns = 550ns)

Class B: includes 20 x T-BC and 1 x T-TSC (21 x 20ns = 420ns)
PTP Telecom Profiles - Frequency
IP Unicast,
Frequency
IPv4 mandatory, S M
IPv6 allowed
PTP processed only at each end, G.8265.1 Telecom Profile
PTP aware network Best in

Ethernet T- T-
Multicast TSC GM Class
T-BC T-BC T-BC T-BC
PTP with full on-path timing support, G.8275.1 Telecom Profile
IPv4 Unicast T- T- Requires

IPv6 optional TSC-P GM Caution
PTP unaware T-BC-P PTP unaware
network network
PTP with partial timing support, G.8275.2 Telecom Profile

PTP Telecom Profiles - Phase
IP Unicast,
Frequency
IPv4 mandatory, S M
IPv6 allowed
PTP processed only at each end, G.8265.1 Telecom Profile
PTP aware network Best in

Ethernet T- T-
Multicast TSC GM Class
T-BC T-BC T-BC T-BC
PTP with full on-path timing support, G.8275.1 Telecom Profile
T-BC-P
IPv4 Unicast T- T- Requires
IPv6 optional TSC-P GM Caution
PTP unaware PTP unaware
network network
PTP with partial timing support, G.8275.2 Telecom Profile

Solution Options
T-BC T-BC T-BC

PTP Aware PTP Aware PTP Aware GM
Network Network Network
PRTC / T-GM
T-BC T-BC
PTP Unaware PTP Unware PTP Aware GM
Profile Profile PRTC / T-GM

Interworking Interworking
Use GNSS to correct

network Asymmetry GNSS
T-BC
PTP Aware PTP Unware PTP Aware GM
T-BC-P / T-TSC-A T-BC PRTC / T-GM
Profile Interworking
Testing Timing
Testing for Timing
• Testing for timing requires knowledge and specialized equipment

• Much of the testing of time has been standardized for ages
• You can test whatever you want, but
• You cannot then compare the results to those of standardized tests
• Be sure unnecessary time errors are calibrated out (e.g. 2 PRTC’s)
• Most common test equipment is based on Calnex Solutions
• Paragon-X: very widely used lab equipment
• Sentinel: portable device for field testing
• Paragon neo: newest generation for Class-C and 100GE testing
• They have a LOT of documentation on their site to help you successfully test
Do Not Mix Different Types of Testing
• Two basic types of testing for both frequency and phase:

• End-to-end (performance after several hops)
• Node testing (performance of a single node)
• Frequency: SyncE or 2/10 MHz/E1/T1
• Phase: PTP or 1PPS
Class A/B/C T-BC Boundary Clock Testing
• When we talk about Class A/B/C Boundary Clocks:

• T-BC (boundary clock) G.8273.2 Noise Generation performance
• Other tests: PTP  SyncE noise transfer, tolerance, etc.
• Same test equipment should generate the time input & measure time output
• Stand-alone, back-to-back
• NO traffic or impairment
• i.e. IDEAL/PERFECT inputs
• Measure 1PPS or PTP out
E
r
r
o
r
Measurement Statistics
• Many statistical measurements, tools and masks:

• Tester samples the “raw” Time Error – other metrics are derived
• 2-Way Time Error (2wTE), constant TE (cTE), max|TE|, dynamic TE (dTE)
• There are high-pass (HF) and low-pass (LF) filters also possible
• Class A/B/C we normally talk max|TE| and cTE (Class B = 70ns & ±20 ns)
• cTE is average TE over 1000 seconds (use the appropriate tool)
• Select the threshold (e.g. ±50 ns) for pass/fail indication
Measurement Statistics
• Masks mostly based on MTIE & TDEV (statistical derivations on TIE):

• Masks per role or test suite (end-to-end, single node, T-GM, T-BC)
• Different masks for quality levels (e.g. PRC, SEC, G.8xx masks)
• Select right one for freq. v phase, role, performance level, topology
Nice Frequency Result - MTIE
Nice Phase Result – cTE with ±50ns Threshold
Deployment
Lessons
Synchronization Decision Tree Requirements?
LTE-A, 5G, SFN, TDD radio ppm/ppb
µs/ns phase offset

CEM, TDM,
FDD radio
Deploying Synchronization (general)
General Guidelines for Successful Deployments
• What form of sync does the end application require? At what accuracy?
• Frequency sources are BITS/SyncE, Phase/time needs GNSS and/or PTP
• Most solutions use a mix of GNSS over the air and PTP or SyncE over the transport
• PTP is required to carry phase and time when no GNSS solution available or when a
backup to a localized GNSS outage is required
• If only frequency is needed, SyncE is the best solution. General rule, SyncE always helps.
• Phase/time Synchronization network design is about time error budgets

• Boundary clocks wherever possible to reduce time error and reset the PDV
• The more PTP awareness you have, the more hops you can cover
• The more accurate the boundary clocks you have, the more hops you can cover
• Distance itself isn’t a problem
Deploying Synchronization (general)
General Guidelines for Successful Deployments
• Physical Frequency (e.g. SyncE) should be used wherever possible:

• For frequency only, use SyncE instead of PTP wherever possible
• For phase, use SyncE in combination with PTP wherever possible
• Minimize hops:
• Distribute sources of time to meet budget
• Do not centralize two PRTC+GM in HQ and try to run PTP across the whole country
• Transport Remediation: minimize Packet Delay Variation (PDV) or Packet Jitter

• Design: excessive PDV will make successful packet solutions almost impossible
• Microwaves/GPON/DSL/DWDM are problematic, unless they are PTP aware
• On path support wherever possible to reduce time error and PDV
• Engineer a timing solution – it’s a timing problem, not a transport one
Deploying Synchronization (Phase)
Guidelines for Successful PHASE Deployments
• Reference solution: 75.1 Telecom Profile with Full On-path Support (L2 multicast)
• Deploy only with SyncE (this is mandatory according to the G.8275.1 standard)
• Frequency PTP only worries about PDV, Phase PTP adds asymmetry to it
• Minimize phase time error
• Eliminate asymmetry – this feeds directly into time error
• Minimize hops – expect to deploy T-GM’s out in the pre-aggregation network
• Minimize Packet Delay Variation (PDV) or Packet Jitter
• Understand the transport (again, asymmetry and PDV)

• If you run PTP for frequency, you cannot just “turn on” phase and expect it to work
• Beware IP protocols for PTP: rerouting, routing asymmetry, ECMP, bundles
Deploying Synchronization (Phase)
Guidelines for Successful PHASE Deployments
• Careful of asymmetric transports (GPON, Cable, Microwave)

• Tight timing budgets over many hops will need new hardware! (Class C, D)
• GNSS deployments aren’t as easy as they seem
• Antenna installation and rental can be very costly
• If you aren’t an expert on GNSS installation and calibration, hire one!!
• Use the standards based solution designed for you (e.g. the correct profile)
• What about security? MACsec plus PTP?
• We talk about some of these in detail…
Network Design
What the network designer has to do:
• Frequency Synchronization
• If possible, use physical distribution (i.e. SyncE) not packet
• G.8265.1 interoperates with SONET/SDH & SyncE (but disallows aware nodes)
• Packet distribution: reduce PDV (e.g. minimizing hops)
• Asymmetry isn’t an issue
• Phase Synchronization
• Deploy G.8275.1 with physical frequency (i.e. SyncE)
• Reduce PDV (e.g. boundary clocks reset PDV)
• Reduce Asymmetry (routing, link, node, transport,…)
• Remediation of transport layer
Select the Correct Profile
Some profiles have advantages over others
Feature G.8275.1 PTPoE G.8275.2 PTPoIP
Network Model Full on-path support Partial on-path support
IP Routing Not applicable Problematic (rings, asymmetry)
Transit traffic Not allowed Problematic (jitter, asymmetry)
Performance Best Variable
Configuration Model Physical Port L3 device
PTP over Bundles No issue Being worked on (for BC’s)
Asymmetry Reduced (T-BC on every node) T-BC good, not T-BC = bad
PDV/jitter Timestamping on wire (small) T-BC good, not T-BC = bad
Reduce Asymmetry
• Asymmetry can come from:

• Routing (especially in complex topologies, rings, ECMP)
• PTP unaware transit nodes (esp. with varying traffic patterns)
• Transport (PON, Cable, DWDM, complex optics)
• Every 2 microseconds of asymmetry = 1 microsecond of time error
• Doing this on an unaware network is very problematic
• And QoS cannot really solve the problem – but it helps
• Boundary clocks handle the asymmetry problem in the nodes
• Assuming they are properly engineered and built
Reduce PDV
• Packet Delay Variation is bad for unaware nodes:

• Must have a “floor” of lucky packets arriving in minimum time
• Accumulates with every unaware node – fixed with T-BC’s
Remediating Transport Asymmetry Similar issues for PON,
Timing over Active Optical Components Cable, DSL, microwave…
• “Smart” optical devices include buffering and/or complex processing

• Buffering can be static and symmetrical, commonly it is neither
• Complex processing can introduce variable delay after the timestamping
• Both introduce PDV/Jitter and commonly asymmetry, into the PTP signal
• Solution: The transport must become “PTP aware” and compensate
• In optical devices, this means using an Optical Service Channel for PTP
BC BC
T-BC T-BC
GM
PRTC / T-GM
Third Party Networks
Carrying Synch over external networks is difficult
• T-BC Boundary clock can only be in a single “clock domain”

• Carriage of PTPoIP (G.8275.2) is possible, but unaware
• No simple solution (some are looking at this now):
• Make sure all the mobile networks are closely aligned (e.g. to GPS UTC)
• Wholesale SP can then provide their own clock aligned with GPS UTC
• For Timing as a Service – can also monitor the clock at interconnect point
• Easiest is to deploy GNSS (e.g. GPS) solution everywhere
• Clever design required to ensure redundancy against GNSS outages
• GNSS may not be good enough for Fronthaul timing requirements!!!
Wholesale Timing as a Service
? ?
Mobile #1 Wholesale Mobile #2
Shared
Cell
Summary
• Engineering timing network to accurately carry phase is easier if:

• PTP aware networks
• Combination of SyncE with PTP
• Use “PTP aware” transport
• Work with the standards rather than trying to “roll your own”
• Engineer a “timing solution” and not just solve a connectivity problem
• It’s an end-to-end budgeting exercise
• Remove as much asymmetry and PDV as possible
• Not try to get too fancy
Further Information
• ITSF International Timing & Sync Forum, Nov 2-5 2020, Düsseldorf :
https://itsf2020.executiveindustryevents.com/Event/home
• WSTS Workshop on Sync & Timing Systems, May 11-14 2020, Seattle
http://www.atis.org/wsts/
• ATIS White Paper: “GPS Vulnerability”
https://access.atis.org/apps/group_public/download.php/36304/ATIS-0900005.pdf
• ITU_T Study Group 15 Question 13:
htts://www.itu.int/en/ITU-T/studygroups/2017-2020/15/Pages/q13.aspx
Current ITU_T Sync Plenary Meeting (27 Jan – 7 Feb 2020, Geneva, CH)
Next ITU_T Sync Interim Meeting (4 May ‘20, Seattle)
Further Information
• Calnex Solutions information on Timing Testing

https://www.calnexsol.com/en/solutions-en/education/techlib/timing-and-sync-lab
• Cablelabs Timing with/without Remote PHY
https://specification-search.cablelabs.com/docsis-timing-interface-specification
https://specification-search.cablelabs.com/CM-SP-R-DTI
Complete your
online session
survey • Please complete your session survey
after each session. Your feedback
is very important.
• Complete a minimum of 4 session
surveys and the Overall Conference
survey (starting on Thursday) to
receive your Cisco Live t-shirt.
• All surveys can be taken in the Cisco Events
Mobile App or by logging in to the Content
Catalog on ciscolive.com/emea.
Cisco Live sessions will be available for viewing on

demand after the event at ciscolive.com.
Continue your education
Demos in the
Walk-In Labs
Cisco Showcase
Meet the Engineer

Related sessions
1:1 meetings
Thank you

BRKSPG 2557

Uploaded by

Copyright:

Available Formats

BRKSPG 2557

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BRKSPG 2557

Uploaded by

Copyright:

Available Formats

5G Synchronization

Design, Testing & Deploying Timing

Dennis Hagarty, Technical Marketing Engineer

• Avoid Slips on TDM Interfaces (E1/T1, …)

 Requirement (TDD, LTE-A radio co-ordination): 3µs between base stations

• PRC = Primary Reference Clock = source of Frequency

• Frequency SyncE out SyncE Out

• IEEE 1588-2008 = Precision Time Protocol = PTPv2

End to End Phase Alignment

Time carried Time carried

IEEE 1588 IEEE IEEE ITU-T ITU-T ITU-T

Transmission Multi-/Unicast Multicast Multicast Unicast Neg. Multicast Unicast Neg.

Delay Mech. Both (J.3/J.4) Peer-delay Peer-delay Delay-Resp Delay-Resp Delay-Resp

Clock Modes One/Two step Two-step Two-step Any Any Any

BMCA Default Alternate Default Alternate Alternate Alternate

TLV Extns. Optional Yes Yes No No Yes

• ITU-T has written many standards for timing and Sync

• Transport between CCAP head-end and Cable Modem now “packetized”

• Breaking TDM chain with packets requires a way to transport frequency

40% Percentage 40%

• Two types of network elements

• These network models also divide up the end-to-end budget

• PTP aware nodes carry time in hardware

± 1.1us Network Equipment Budget

Class A: includes 10 x T-BC and 1 x T-TSC (11 x 50ns = 550ns)

PTP aware network Best in

PTP with full on-path timing support, G.8275.1 Telecom Profile

IPv4 Unicast T- T- Requires

PTP with partial timing support, G.8275.2 Telecom Profile

PTP aware network Best in

PTP with full on-path timing support, G.8275.1 Telecom Profile

PTP with partial timing support, G.8275.2 Telecom Profile

T-BC T-BC T-BC

Profile Profile PRTC / T-GM

Use GNSS to correct

• Testing for timing requires knowledge and specialized equipment

• Two basic types of testing for both frequency and phase:

• When we talk about Class A/B/C Boundary Clocks:

• Many statistical measurements, tools and masks:

• Masks mostly based on MTIE & TDEV (statistical derivations on TIE):

µs/ns phase offset

• Phase/time Synchronization network design is about time error budgets

• Physical Frequency (e.g. SyncE) should be used wherever possible:

• Transport Remediation: minimize Packet Delay Variation (PDV) or Packet Jitter

• Engineer a timing solution – it’s a timing problem, not a transport one

• Understand the transport (again, asymmetry and PDV)

• Careful of asymmetric transports (GPON, Cable, Microwave)

Feature G.8275.1 PTPoE G.8275.2 PTPoIP

Network Model Full on-path support Partial on-path support

IP Routing Not applicable Problematic (rings, asymmetry)

Transit traffic Not allowed Problematic (jitter, asymmetry)

Performance Best Variable

Configuration Model Physical Port L3 device

PTP over Bundles No issue Being worked on (for BC’s)

PDV/jitter Timestamping on wire (small) T-BC good, not T-BC = bad

• Asymmetry can come from:

• Packet Delay Variation is bad for unaware nodes:

• “Smart” optical devices include buffering and/or complex processing

• T-BC Boundary clock can only be in a single “clock domain”