Challenges in profiles and architectures

Transcription

1 Challenges in profiles and architectures Michael Mayer, Editor G.8275 ITSF-2014 Budapest 1

2 Challenges in profiles and architectures Outline The architecture recommendations Relation to other Recommendations and status Brief overview of architecture methods G.8275 overview Future and challenges 2

3 The Architecture Recommendations Definitions / terminology G.8260 (Definition & metrics) Agreed Ongoi ng Basics Frequency: G.826x G.8261 G.8271 Network requirements SyncE J & W G G NetwkPDV G Clock Methods Profiles G.8262 (SyncE) G.8263 (slave clock) G.8266 GM for F G.8264 G.8265 () G G.8265.m G.8272 PRTC G.8273 G BC & slave 73.3 TC 73.1-GM 73.2 BC & slave G A-PTS ck G PTPprofile1 G PTPprofile2 3

4 The Architecture Recommendations Physical layer frequency: G.8264/Y.1364: Distribution of timing information through packet networks G.8264/Y.1364 (05/14) (first version 10/2008) Packet Frequency G.8265/Y.1365 : Architecture and requirements for packetbased frequency delivery G.8265/Y.1365 (10/10) G.8265/Y.1365 (2010) Amd. 1 (04/2011) G.8265/Y.1365 (2010) Amd. 2 (10/2012) Packet time/phase G.8275: Architecture and requirements for packet-based time and phase delivery G.8275/Y.1369 (11/2013) 4

5 Why architecture? A network is a distributed system Purpose is to enable information transfer (flow) Necessary functions are specified in standards How do these functions fit together? What restrictions exist? What is information required to manage the network? how is the network controlled or managed How are functions specified by different organizations? Formal Architecture language aids understanding 5

6 Example architectures Example languages OSI Reference model (ISO, or X.200) Used to describe computer networks ITU transport model (e.g. G.800, G.805) Used to describe transport networks Example architectures G.803: architecture of SDH G.872: architecture of OTN G.8010: Architecture of Ethernet G.8121: MPLS Time distribution over a network has to respect and be consistent with the underlying network architecture 6

7 Except High accuracy time/phase may not be supported over existing networks. What aspects may be required of the network in order to support time/phase distribution? What additions are required of the network? Full path support may be required. New network element type may be required (T-BC) A different grouping of functions may be required New functions may be required Architecture helps to clarify issues, leading to development of real solutions. 7

8 Architecture: Provides flexibility (Frequency distribution example) Physical layer: Service owner provides timing Mobile Operator A RAN BS Synchronous Ethernet signal (carrying Operator A reference) Carrier Operator B (OTN) Synchronous Ethernet signal (carrying Operator A reference) RAN NC Mobile Operator A Network limits Direction of timing distribution G.8264-Y.1364.Amd.1(10)_F12.2 Physical layer: Intermediate carrier provides timing Mobile Operator A RAN BS Synchronous Ethernet signal (traceable to carrier timing reference) Carrier Operator B (Ethernet) Ethernet signal (synchronous or asynchronous) RAN NC Mobile Operator A Network limits Direction of timing distribution G.8264-Y.1364.Amd.1(10)_F12.3 Packet layer: Service owner provides timing Network RAN Operator A BS (e.g. mobile operator) Ethernet Signal (Synchronous or Asynchronous) Network Packet Timing signal (Traceable to Operator A Reference) Operator B (e.g. Ethernet) Ethernet Signal (Synchronous or Asynchronous) GM Network RAN NC Operator A (e.g. mobile operator) 8

9 Architecture for time/phase? Architecture recommendations provide high level guidance to the development of other recommendations Act to coordinate other functions where necessary Interface aspects, Clock aspects, Recommendations from other questions Coordination similar functions over different technologies Time/phase distribution is new A well defined architecture is needed to ensure that development of functionality is coordinated 9

10 Relationship to Profiles Telecom timing distribution can occur over different technologies and with different mechanisms SONET/SDH, Circuit Emulation, NTP, IEEE1588 (PTP) Individual technology architecture documents are aligned with respect to requirements Adhering to the architecture results in coordinated deployment Example: SDH/SONET and Sync Ethernet are compatible IEEE-1588 profile mechanism to address different applications Telecom is more than one application (e.g. frequency, phase/time) and may have existing technologies to consider The Application is defined by the architecture Specific packet functionality (e.g. packet slave clocks) can be described within the architecture to ensure fit with other technologies The profile and the architecture must be considered together The architecture Recommendations are normative reference in the Telecom profiles Profile development and architecture are linked 10

11 G.8275 details First version consented in July 2013 Comments addressed October 2013 Published in November Aspects covered High level requirements General topology for time/phase distribution High level protection concepts Packet master protection Packet slave protection PRTC configurations Initial functional models for time/phase Partial timing support (currently non-normative in first version) 11

12 Time/phase distribution High level distribution based on G.8265 Intermediate network elements are PTP aware Restricted to boundary clocks in first version 12

13 High level protection Protection methods are needed for Master protection Provides guidance on deployment Four scenario s considered Slave protection Provides guidance on mechanisms (e.g. how BMCA may work) Three scenario s considered 13

14 Packet master protection Four scenarios considered -Each case the PTC moves towards the edge of the network -may place different requirements on PTRC Scenario 1 (Case A) Note: Scenarios 2 and 3 are not shown 2: Separates PRTC and PRC 3: Moves PRTC to head of backhaul (refer to G.8275 Figures 3 and 4) Scenario 4 (Case D) 14

15 PRTC configurations Protection methods do not require the same PTRC configurations The architecture provides guidance for development of equipment specifications 15

16 PRTC configurations PRTC (no physical reference) -Frequency/phase/time all provided by single GNSS input -Applies only to first scenario PRTC with capability of input frequency reference for holdover -Frequency/phase/time all provided by single GNSS input -Can be used in all scenarios PRTC functionality integrated with Telecom Grand Master -PTP over Ethernet interface can also provide physical layer frequency synchronization 16

17 Packet slave protection Describes how redundant timing paths can be provided to the slave Three general cases: 1: phase/time protection using physical layer frequency support 2: Switching to a redundant reference with physical layer support (for frequency) 3: switching to a redundant reference without physical layer support 17

18 Packet slave protection example Packet slave protection -Specific example is scenario 2: protection with support provided by physical layer frequency (holdover). -Scenario 3 is similar (refer to G.8275) -two types of end application are show, there the end application includes the end clock, or when the end application is driven by a stand-alone clock. 18

19 Time/phase functional models Extensions of G.8264 models to describe time/phase with support from physical layer (SyncE) have been included as Annex. Provides guidance to other questions in developing appropriate equipment specifications 19

20 Extension for Packet timing Specific functions needed for Time distribution can be added to the basic model Network may remain unchanged 20

21 Going further: Frequency assist Physical layer synchronization model is that of SDH/SyncE. Boundary clock function starts to appear 21

22 Applying the architecture Boundary clock block diagram under development in Q13/15 22

23 Possible functional Model of BC Benefit of functional model: One can compare the model with existing Ethernet switch models to clarify the additional functionality that needs to be added to support the BC function. Figure taken from Synchronous Ethernet and IEEE 1588 in Telecoms J.L. Ferrant, et al, ISTE/Wiley, ISBN

24 Partial timing support Evolution from G.8265 (Frequency) to provide time/phase Currently non-normative in G.8275 Not all network elements are BC Architecture begins to define functional requirements PRTC time reference, T in f ref (physical layer frequency reference for protection) two-way packet timing signals Packet Master Clock Boundary Clock Packet Slave Clock f ref f ref T out + d 24

25 Challenges First version approved 2013 Areas for further work will be captured in amendments G.8275AM1 due 12/2014 Further work expected Partial support Enhancements to architecture PTP layer models Small cell time distribution in a building Deployment cases and applicability to the various use cases Link asymmetry PTP over OTN proposed some aspects should be noted in the architecture to define expected applications 25

26 Conclusion Architecture recommendations are important to understand the relationships between the various components in the network Development of the architecture, when progressed with other recommendations, results in realizable networks and networks that make full use of existing capabilities 26

27 Background

28 Time/phase requirements Packet-based mechanisms for time and phase distribution must meet the following requirements: 1) Mechanisms must be specified to allow interoperability between the various phase/time clocks defined in this architecture. 2) Mechanisms must permit consistent operation over managed wide area telecom networks. 3) Packet-based mechanisms must allow the synchronization network to be designed and configured in a fixed arrangement. 4) Protection schemes used by packet-based systems must be based on standard telecom operational practice and allow telecom time slave clocks (T-TSC) the ability to take phase and time from multiple geographically separate telecom grand master (T-GM) clocks. 5) Phase/time reference source selection based on received phase/time traceability and local priority should be permitted. Automatic establishment of the phase/time synchronization network topology may also be possible. 28

29 Architecture blocks Adaptation function Access point Trail termination function Termination connection point Figure taken from Synchronous Ethernet and IEEE 1588 in Telecoms J.L. Ferrant, et al, ISTE/Wiley, ISBN

30 Ethernet networks ETH_AP ETH connectionless trail ETH_AP ETH ETH Network flow (ETH_NF) ETH ETH_TFP ETH_FP ETH_TFP AP Access Point NF Network flow TFP Termination flow point FP Flow point 30

31 Equipment example ETH_CI Data in (e.g., IEEE 802.3) Data in (e.g., IEEE 802.3) Free-run Two port MAC Relay Data out (e.g., IEEE 802.3) Data out (e.g., IEEE 802.3) Figure taken from Synchronous Ethernet and IEEE 1588 in Telecoms J.L. Ferrant, et al, ISTE/Wiley, ISBN

32 G.781 sync network NE 1 NE 2 NE 3 NE 4 NS Network Connection NS NS NS PRC NS Link conn 2-3 NS Link conn 3-4 SD SD Trail 1-2 SD Trail 2-3 SD Trail 3-4 SD SD SD SD SD SD S D SD SD SD SD link Conn 1-2 SD link Conn 2-3 SD link Conn

33 OSI model example Application Presentation Session Transport Network Data link Physical Network Data link Physical Network Data link Physical Application Presentation Session Transport Network Data link Physical Interpretation Terminal (e.g. PC) Router Databas e Figure taken from Synchronous Ethernet and IEEE 1588 in Telecoms J.L. Ferrant, et al, ISTE/Wiley, ISBN

34 Architectural models vs network elements E1 TDM timing E1 ETH ETH_CI ETH_CI G.805 Functional Model for CES ETY Ext.Ref. UTC Ext.Ref. E1 C E S Switch Switch C E S E1 Network Element Model 34

35 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) 35

36 Ethernet detail example Inputs ETYn_AP: ETYn_AI_Data ETYn_AI_Clock ETYn_AI_TSF ETYn_AI_TSFrdi ETYn_AI_TSFfdi Outputs ETH_FP and ETH_TFP: ETH_CI_Data ETH_CI_Clock ETH_CI_SSF ETH_CI_SSFrdi ETH_CI_SSFfdi ETH_PP: ETH_PI_Data ETYn/ETH_A_Sk_MP: ETYn/ETH_A_Sk_MI_FilterConfig ETYn/ETH_A_Sk_MI_MAC_Lengt h Holdover control MI ETH_FP: ETH_CI_ESMC ETYn/ETH_A_Sk_MP: ETYn/ETH_A_Sk_MI_pErrors ETYn/ETH_A_Sk_MI_pFramesReceived OK ETYn/ETH_A_Sk_MI_pOctetsReceived OK From Ethernet equipment specification: G

37 More detail can be illustrated ETH_ CI ( ETH _FP) ETH _CI (ETH _ TFP ) ETH _CI_ESMC ETH_CI_Clock MI_FilterConfig Filter Replicate ETH_ PI ( ETHTF _PP) ETH_ PI ( ETHF _PP) 802.1AB/X protocols MI_pFramesReceivedOK MI_pOctetsReceivedOK MI_pErrors protocols MAC Frame Counter MAC Frame Check MI_MAC_Length MAC Length Check ETYn Server Specific ETYn_ AI Description of functional block will specify as much detail as necessary to define implementation requirements Note: references IEEE802 37

38 Functional model showing Time reference distribution 38