Joint IEEE-SA and ITU Workshop on Ethernet Synchronization

Joint IEEE-SA and ITU Workshop on Ethernet Synchronization architecture Michael Mayer, Editor, G. 8265, G. 8275 Geneva, Switzerland, 13 July 2013

Overview Architecture in ITU Why? Requirements Synchronization recommendation structure General aspects of architecture in ITU-T Formal model example Overview of key Synchronization architecture recommendations G. 8264, Physical layer frequency (Sync. E) G. 8265, Packet based frequency G. 8275, Packet based time/phase Geneva, Switzerland, 13 July 2013 2

Architecture development Start here Development of architecture starts with Requirements Network Model Which constrains equipment specifications Equipment specifications Deployment Geneva, Switzerland, 13 July 2013 A network model is then developed Ensuring that deployed components meet all functional requirements for the network application 3

Next generation synchronization input constraints Key aspects of NGN synchronization Packet network infrastructure Moving away from SONET/SDH But can’t throw out existing network New synchronization requirements wireless backhaul requirements Air interface requirements New methods CES, PTP, Synchronous Ethernet New clock structures BC, TC, GM Architecture helps see how all pieces fit together Geneva, Switzerland, 13 July 2013 4

Formal models based on G. 805 Functional Model for CES From G. 8264 E 1 C E S Switch Geneva, Switzerland, 13 July 2013 Switch C E S E 1 Network Element Model 5

Details of functions Individual functions may be specified in different recommendations May include other aspects related to basic transport, in addition to synchronization Some blocks may contain significant detail Sync functions in G. 781 Clocks in G. 8262 (e. g. EEC) Transport functions in G. 8021 (Ethernet) Not all functions developed by Q 13/15 Geneva, Switzerland, 13 July 2013 6

Ethernet Synchronization detail Inputs ETYn_AP: ETYn_AI_Data ETYn_AI_Clock ETYn_AI_TSFrdi ETYn_AI_TSFfdi Outputs ETH_FP and ETH_TFP: ETH_CI_Data ETH_CI_Clock ETH_CI_SSFrdi ETH_CI_SSFfdi ETH_PP: ETH_PI_Data ETH_FP: ETH_CI_ESMC ETYn/ETH_A_Sk_MP: ETYn/ETH_A_Sk_MI_Filter. Config ETYn/ETH_A_Sk_MI_MAC_Leng th ETYn/ETH_A_Sk_MP: ETYn/ETH_A_Sk_MI_p. Errors ETYn/ETH_A_Sk_MI_p. Frames. Receive d. OK ETYn/ETH_A_Sk_MI_p. Octets. Received OK Holdover control MI From Ethernet equipment specification: G. 8021 Geneva, Switzerland, 13 July 2013 7 7

…More detail can be illustrated Description of functional block will specify as much detail as necessary to define implementation requirements Ensures a high degree of interoperability is achievable using standards provided by both IEEE and ITU Geneva, Switzerland, 13 July 2013 8

Current versions G. 8264/Y. 1364: Distribution of timing information through packet networks G. 8264/Y. 1364 (10/2008) G. 8264/Y. 1364 (2008) Amd. 1 (09/2010) G. 8264/Y. 1364 (2008) Cor. 1 (11/2009) G. 8264/Y. 1364 (2008) Amd. 2 (02/2012) G. 8264/Y. 1364 (2008) Cor. 2 (02/2012) G. 8265/Y. 1365 : Architecture and requirements for packet-based frequency delivery G. 8265/Y. 1365 (10/2010) G. 8265/Y. 1365 (2010) Amd. 1 (04/2011) G. 8265/Y. 1365 (2010) Amd. 2 (10/2012) G. 8275: Architecture and requirements for packetbased time and phase delivery Consented July 12, 2013 Geneva, Switzerland, 13 July 2013 9

New Options become available The development of a coordinated architecture allows Network to evolve Understand limitations Allow new capabilities to become available Example follows: Multiple frequency distribution options for wireless backhaul timing over multiple networks Geneva, Switzerland, 13 July 2013 10

Architecture results in flexibility Physical layer: Service owner provides timing Physical layer: Intermediate carrier provides timing Packet layer: Service owner provides timing Geneva, Switzerland, 13 July 2013 11

Summary Architecture recommendations are important Developed to provide an overall framework for how technology can be deployed in a network Provide a framework for controlled technology evolution Synchronization related architecture documents Provide controlled evolution of technology Ensure high degree of interoperability of different synchronization technologies Guidance for developing equipment recommendations to support telecom specific requirements Synchronization solutions must fit with packet traffic functions of NEs Strong linkage to Hypothetical Reference Model (HRM) development Provide guidance to other SDO’s Geneva, Switzerland, 13 July 2013 12