Carrier Ethernet Synchronization. Technologies and Standards

Transcription

1 Carrier Ethernet Synchronization Technologies and Standards DataEdge, Dublin, May 19, 2010

2 Overview What and Where of Synchronization Synchronization Delivery Strategies o Synchronous Ethernet o IEEE Selecting a Synchronization Method Network Impairments Deployment Guidelines PAGE 2

3 Millions Making It Happen, The Real World Mobile broadband use will double every year through 2013*. 10M new IP connections will be made to base stations in the next 5 years, **BaseStation Backhaul Connections The mobile sector will drive the market (products & practices). Pure packet deployment has been slow driven by concerns for voice quality CY'07 CY'08 CY'09 CY'10 CY'11 CY'12 CY'13 Non-IP Connections IP Backhaul Connections Synchronization challenges include: Selecting the strategy ***Live Packet Backhaul Deployments Knowing the goals Engineering for cost, performance & simplicity * Cisco Visual Networking Index (VNI) Mobile Forecast ** Source. Infonetics *** Source. Heavy Reading PAGE 3

4 MEF: Where is Sync Required? MEF 2 Requirements and Framework for Ethernet Service Protection MEF 3 Circuit Emulation Service Definitions, Framework and Requirements in MEN MEF 4 Metro Ethernet Network Architecture Framework Part 1: Generic Framework MEF 6.1* Metro Ethernet Services Definitions Phase 2 MEF 7 EMS-NMS Information Model MEF 8 Implementation Agreement for the Emulation of PDH Circuits over MEN MEF 9 Abstract Test Suite for Ethernet Services at the UNI MEF 10.1* Ethernet Services Attributes Phase 2* MEF 11 User Network Interface (UNI) Requirements and Framework MEF 12 Metro Ethernet Network Architecture Framework Part 2: Ethernet Services Layer MEF 13 User Network Interface (UNI) Type 1 Implementation Agreement MEF 14 Abstract Test Suite for Traffic Management Phase 1 MEF 15 Requirements for Management of Metro Ethernet Phase 1 Network Elements MEF 16 Ethernet Local Management Interface MEF 17 Service OAM Framework and Requirements MEF 18 Abstract Test Suite for Circuit Emulation Services MEF 19 Abstract Test Suite for UNI Type 1 MEF 20 User Network Interface (UNI) Type 2 Implementation Agreement MEF 21 Abstract Test Suite for UNI Type 2 Part 1: Link OAM MEF 22 Mobile Backhaul Implementation Agreement * MEF 10.1 replaces and enhances MEF 10 Ethernet Services Definition Phase 1 and replaced MEF 1 and MEF 5. MEF 6.1 replaced MEF 6. PAGE 4

5 MEF: Where is Sync Required? MEF 2 MEF 3 MEF 4 Requirements and Framework for Ethernet Service Protection Circuit Emulation Service Definitions, Framework and Requirements in Metro Ethernet Networks Metro Ethernet Network Architecture Framework Part 1: Generic Framework MEF 6.1 Metro Ethernet Services Definitions Phase 2 MEF 7 MEF 8 MEF 9 EMS-NMS Information Model Implementation Agreement for the Emulation of PDH Circuits over Metro Ethernet Networks Abstract Test Suite for Ethernet Services at the UNI MEF 10.1 Ethernet Services Attributes Phase 2* MEF 11 MEF 12S MEF 13 User Network Interface (UNI) Requirements and Framework Metro Ethernet Network Architecture Framework Part 2: Ethernet Services Layer User Network Interface (UNI) Type 1 Implementation Agreement MEF 14 Abstract Test Suite for Traffic Management Phase 1 MEF 15 MEF 16 MEF 17 MEF 18 Requirements for Management of Metro Ethernet Phase 1 Network Elements Ethernet Local Management Interface Service OAM Framework and Requirements Abstract Test Suite for Circuit Emulation Services MEF 19 Abstract Test Suite for UNI Type 1 MEF 20 MEF 21 MEF 22 User Network Interface (UNI) Type 2 Implementation Agreement Abstract Test Suite for UNI Type 2 Part 1: Link OAM Mobile Backhaul Implementation Agreement * MEF 10.1 replaces and enhances MEF 10 Ethernet Services Definition Phase 1 and replaced MEF 1 and MEF 5. MEF 6.1 replaced MEF 6. PAGE 5

6 Carrier Ethernet Use cases for MBH: Packet Offload or Full Ethernet Packet Offload / Carrier Ethernet Use Case 1 Legacy Network RAN BS GIWF UNI Carrier Ethernet Network UNI GIWF RAN Agg Non-Ethernet I/F Non-Ethernet I/F BOTH CASES NEED SYNCH Full Ethernet Use Case 2 Carrier Ethernet Network RAN BS U N I U N I RAN Agg PAGE 6

7 MEF 8: Carrier Ethernet Private Line (EPL) Data Center Service Carrier Ethernet Network CE CE ISP POP Internet Point-to-Point EVC Designed for TDM Replacement CE PAGE 7

8 MEF 8: E-Tree (EP-Tree or EVP- Tree) Root EVC 1 Leaves A B C Efficient use of ISP router port One subnet to configure on ISP router Simple configuration A, B, C can t see each other s traffic Some limits on routing protocols used Designed for mobile backhaul and triple-play infrastructure PAGE 8

9 MBH Sync Requirements at the Wireless Air Interface Variations in the Radio frequency of cellular base-stations affect the ability of the system to hand-off calls without interruption. BTS 1 F 1 + F BTS 2 drifts outside 50ppb window Mobile cannot lock to BTS 2 and call is dropped +/- 50ppb Mobility Standard Frequency Time/Phase CDMA ppb Range: <3µs to <10µs GSM 50 ppb WCDMA 50 ppb TD-SCDMA 50 ppb 3µs inter-cell phase LTE (FDD) 50 ppb LTE (TDD) 50 ppb *3µs inter-cell phase LTE MBMS 50 ppb *5µs inter-cell phase WiMAX (TDD) 50 ppb inter BTS Typically µs Backhaul 1 to 16 ppb * Standards being consolidated 50 ppb or 5 x 10-8 F 1 +/- 50ppb BTS 2 T 1 T 2 Time PAGE 9

10 Mobile Back-Haul (MBH) MEF 22 Mobile Backhaul Implementation Agreement Approved as an official MEF Specification in January First phase : Synchronization is delivered 1 outside of the Ethernet transport network 2 using a packet based method (IEEE1588 PTP standard, or proprietary solutions) Subsequent (future) phases: Other synchronization methods Synchronous Ethernet PAGE 10

11 NGN Synchronization Standards ITU-T Frequency Time Definitions-Terminology G.8260 G.8260 Basics G.8261 (G.pactiming) G.8271 Network Jitter-Wander G.8261 Network PDV G G Clock-SyncE G.8262 Clock-Packet G.8263 G.8272 Methods-SyncE G.8264 Methods-Packet G.8265 G.8275 PTP Telecom Profile G G PTP Telecom Profile 2 G IEEE MEF IEEE Standard for a Precision Clock Synchronization Protocol for networked measurement & control systems. MEF 3, MEF 8, MEF 18, MEF 22 MEF Standards that Refer to or Require Synchronization. PAGE 11

12 Overview What and Where of Synchronization Synchronization Delivery Strategies o Synchronous Ethernet o IEEE Selecting a Synchronization Method Network Impairments Deployment Guidelines PAGE 12

13 Sync Delivery Strategies Synchronization Strategies E1/SDH Packet ACR Packet E1/SDH Hybrid Shorter term strategy based on use of legacy systems (higher OPEX). Bandwidth & 4G/LTE limit long term suitability. Adaptive Clock Recovery A vendor specific book-end solution used to support TDMoIP services. ACR methods are being superseded by IEEE GPS Radio at Base Stations Good performance, supporting wide range of applications. Cost and autonomy define deployment adoption. SyncE Packet 1588-v2 Packet Synchronous Ethernet An end-to-end solution that depends on the uninterrupted SyncE deployment. IEEE A standards based solution with the flexibility, lowest cost, and high rate of adoption (driven by mobile sector). PAGE 13

14 Synchronous Ethernet Proposed in September 2004 to use the physical layer to transport a frequency reference in order to o o Provide G.811 traceability to applications Provide a timing quality independent of traffic payload It was decided to align SyncE on SDH o o to avoid defining a new synchronous hierarchy To allow a mix of SDH and SyncE NEs in the G.803 reference chain Defined by 3 ITU-T SG15 recommendations (consented in Feb 2008) o o o G.8261 for architecture and network limits G.8262 for the definition of the clock G.8264 for the definition of the SSM PAGE 14

15 Synchronous Ethernet Architecture In order to provide interworking between SyncE and SDH o o o A chain of 20 SDH NEs must be replaceable by 20 SyncE NEs A chain of 20 NEs can mix SDH and SYNCE NEs An NE can be equipped with both SDH and SyncE ports The SyncE NE o o o o Must have a clock compatible with SDH/SONET Recovers timing from a synchronous Ethernet signal, with an SSM Must be able to recover the data from an Ethernet signal Must be able to provide traceablity via SSM PAGE 15

16 SyncE clock G.8262 Compliance with SDH implies that SyncE clocks are based on G.813 Jitter is related with clock recovery Wander is due to noise accumulation in a chain of NE/clocks. Frequency pull-in range o o Must be 100 ppm on the port so that data of legacy Eth can be processed Must be 4.6 ppm at clock input to comply with SDH clocks TX RX TX RX 100 ppm Async Switch TX RX TX RX TX RX Accurate TX TX RX RX Inaccurate TX RX 4.6 ppm 100 ppm Ext.Sync 4.6 ppm SyncE Switch SyncE Switch Asynchronous Switch PAGE 16

17 SSM Transport G.8264 The SSM is transported in the ESMC Ethernet Synchronization Messaging Channel Two types of messages are transmitted o o An event message sent immediately in case of SSM change A heartbeat message Sent at a rate of about 1 Hz No message for 5 seconds means ESMC failure Quality Level data is mapped into a TLV format o Future information might be mapped according to TLV format PAGE 17

18 IEEE 1588 Overview IEEE Is a protocol definition, not a product, is known as Precision Time Protocol (PTP) is also referred to as version 2 (with the Telecom Profile) is the second version of a mature IEEE standard, defines how to transfer precise time over networks. It does not define how to recover frequency or high precision time of day. The challenge is to convert packets to traceable Time & Frequency, and cost effectively. PAGE 18

19 1588 Precision Time Protocol Master Clock Time Slave Clock Time t 1 Delay_Req message Sync message Follow_Up message containing true value of t 1 t 2 t 3 Data at Slave Clock t 2 t 1, t 2 t 1, t 2, t 3 Each event message flow (sync, delay_req) is a packet timing signal Master frequency determined by comparison of timestamps in the event message flows e.g. comparison of t 1 to t 2 over multiple sync messages, or t 3 to t 4 in delay_req messages Time offset calculation requires all four timestamps: Client time offset = (t 1 t 2 ) + (t 4 t 3 ) t 4 Delay_Resp message containing value of t 4 time t 1, t 2, t 3, t 4 2 assumes symmetrical delays (i.e. the forward path delay is equal to the reverse path delay) Time offset error = fwd. delay rev. delay 2 PAGE 19

20 The PTP Protocol Main Features Rate of Delay_req/Delay_resp Transactions can be adjusted to cope with Target frequency/time accuracy Network conditions 64 transactions/sec/client is a good, practical value 30 to 128 transactions/sec range PTP supports Unicast and Multicast Unicast: more flexible, supported by all networks Multicast: required later with larger numbers of clients e.g., Femtocells When core/access networks support it Boundary Clocks BC serving a sub-network can be sync d to a remote St1 server No need for a local Stratum1 reference 21 PAGE 21

21 The PTP Protocol Main Features Boundary Clocks Acts as a slave clock at the port that connects to the grand master, and as a master to all other ports Therefore, it isolates the down stream clocks from any delays and jitter within the switch Creates master-slave synchronization hierarchy Grandmaster M Ordinary Clock S Transparent Clock S M M Boundary Clock M S Slave Clock S Ordinary Clock S Slave Clock S Ordinary Clock PAGE 22

22 The PTP Protocol Main Features End-to-end transparent clock Alternative (simpler & cheaper implementation) to boundary clocks Switch/Router modifies time stamps in packets to adjust for delays introduced by Switch/Router itself Residence time is accumulated in special field (correction field) of PTP message event or associated Follow_Up message Peer-to-peer transparent clock Similar to end-to-end transparent clock but computes link delay in addition of residence time Switch1 Switch2 PORT1 MAC Residence time correction MAC PORT2 PORT1 MAC Residence time correction MAC PORT2 PHY PHY PHY PHY Link time correction PAGE 23

23 Overview What and Where of Synchronization Synchronization Delivery Strategies o Synchronous Ethernet o IEEE Selecting a Synchronization Method Network Impairments Deployment Guidelines PAGE 24

24 Selecting The Sync Strategy TDM circuits are the most widely used method today. Will still be used beyond 2012 SyncE & IEEE 1588 are standards based Supports interoperability Addresses multiple applications Cost effective & reached viability Can be used together Adaptive Clock Recovery is proprietary & a bookend offer. No inter-operability Multiple parallel systems High engineering, management & maintenance effort Source. Heavy Reading GPS & other methods will be used on limited scale. PAGE 25

25 Defining The Goals FDD Objectives Select the frequency goals: ITU-T G.823 sync mask Vodafone Lab Acceptance Mask (G.823 sync mask + 1ppb) ITU-T G.823 traffic mask 1-15ppb (short & long term) Other proprietary masks Define the Absolute Time/Phase goals: 3 µs absolute phase accuracy 5 µs absolute phase accuracy Other goals Time & Phase Objectives What is the Time of Day interface? MTIE (nsec) Observation Interval (sec) PAGE 26

26 SyncE or IEEE IEEE1588 needed when: Applications need time/phase Applications with leased services (no end-end SyncE path assurance) Transport other than switched Ethernet Attribute IEEE 1588 SyncE Capability Frequency, Time Frequency Layer UDP/IP or Layer 2 Physical Distribution In-band 1588 Packets Physical layer Schema Point to multi-point Point to point Distribution In-band 1588 Packets Physical layer Transport Media Inter-Operability Native Ethernet, xdsl, Microwave Standards based Grandmaster & slave. Independent of intermediate nodes. Native Ethernet Standard based SyncE switches only Relevant Standards IEEE 1588, ITU G.8264 ITU G.8261/2/4 PAGE 27

27 Overview What and Where of Synchronization Synchronization Delivery Strategies o Synchronous Ethernet o IEEE Selecting a Synchronization Method Network Impairments Deployment Guidelines PAGE 28

28 Packet Delay Variation Voice Video Data Packet Environment FIFO Buffers Voice Video Data Main Delay Variation Causes Waiting time jitter in network elements Routers/switches congestion Extended packet loss, Network outages/re-routing: may cause holdover from lack of information Note: absolute delay, even high, is not a problem for sync technologies 29 19/05/2010 PAGE 29

29 Class of Service Traffic Separation MEF provides service mapping guidelines for the number of CoS classes to use Bundles traffic types into limited number of CoS classes Describes CoS class performance requirements Service Class Name Very High (H + ) Example of Generic Traffic Classes mapping into CoS 4 CoS Model 3 CoS Model 2 CoS Model Synchronization - - High (H) Conversational, Signaling and Control Conversational and Synchronization, Signaling and Control Conversational and Synchronization, Signaling and Control, Streaming Medium (M) Streaming Streaming - Low (L) Interactive and Background Interactive and Background Interactive and Background PAGE 30

30 CoS/QoS- Priorities Even with priority schemes packet delay variation can be significant Large Low priority Packet 1000 Bytes+ High priority Packet At 100 Mbit/s 1000 byte packet = 8 x 1000 / 100 x 10 6 = 80 s At 10 Mbit/s 1000 byte packet = 8 x 1000 / 10 x 10 6 = 0.8ms 19/05/2010 PAGE 31

31 Typical PDV Profile PDV Tail Distribution Minimum Delay Packets 32 PAGE 32

32 Packet Network Characterization 10 switches, 20% load 10 switches, 60% load 10 switches, 40% load 10 switches, 80% load Packets experiencing minimum delay Key characteristics: variance of minimum delay frequency of packets with minimum delay PAGE 33

33 Sample Field Trial Result Live deployed network in Europe Sync was tested over MPLS-over-SDH, 2 weeks Moderately loaded network ring (7 hops in one direction, 15 hops in the other) TP500 Frequency ~0.1 ppb most of the time, worst case performance over two weeks shown above, ~0.3 ppb PAGE 34

34 Sample Field Trial MTIE G.823 traffic 15 ppb G ppb TP500 Same live network Meets G.823 Sync Mask + 1 ppb with margin Symmetricom Confidential 35 PAGE 35

35 SHDSL Field Trial: 0.26ppb PAGE 36

36 G.8261 Test Case 12: Description Test case 12 models the Static Packet load. Test Case 12 must use the following network conditions: Network disturbance load with 80% for the forward direction (Server to Client) 20% in the reverse direction (Client to Server) for 1 hour The test measurements should start after the clock recovery is in a stable condition. PAGE 37

37 G.8261 Test Case 12: Phase PAGE 38

38 Other Freq+Phase Performance 10 hops, G.8261 traffic type and load variation Using carrier grade routers/switches Pass = pass G.823PDH (sync) mask and <=1us phase accuracy G.8261 Test Case Test Case 13 Description Duration Result Comments Large, sudden changes in traffic load 6 hours Pass 2 nd hardest test Test Case 14 Test Case 17 Slow, steady traffic ramp up and down Network failures causing routing changes with impairment 24 hours Pass Hardest Test 2 hours Pass PAGE 39

39 Overview What and Where of Synchronization Synchronization Delivery Strategies o Synchronous Ethernet o IEEE Selecting a Synchronization Method Network Impairments Deployment Guidelines PAGE 40

40 Traffic load on network Empirical Behaviour Clock stability, showing dependence on network size and traffic load Green Zone expanding 5 nodes met under any conditions 10 nodes met under most network configurations Focussing on 20 nodes 100% 80% clock stability compliant with application clock stability non-compliant with application 60% 40% 20% 0% Number of switches Limit of operational area Varies with: Application requirements Type of switches Traffic loading patterns Slave performance Local oscillator stability 41 PAGE 41

41 Packet Sync Planning Strategy Step 1: Identify PTP slave locations Step 2: Identify suitable locations for PTP Grand Masters Masters should be distributed towards the edge of the network Rule of thumb: For minimum dependency on traffic load, the PTP Master should be no more than 8/10 switches from the PTP Slave Step 3: Check that Grand Master capacity constraints are not exceeded The 8/10 switch distance rule is not violated, or that the traffic load is appropriate to the network span Step 4: Field trial measure performance on critical links Monitor TIE, MTIE, TDEV of output timing signals Also monitor PDV of packet network to verify suitability for timing distribution Step 5: Ongoing monitoring of critical or selected links to ensure synchronization quality is maintained in operation 42 PAGE 42

42 Redundancy Strategy Redundancy Strategy Separate Grand Masters, or built-in redundancy? Best Master Clock Algorithm, or manual configuration? BMCA requires multicast message distribution BMCA may elect a grandmaster that is not close to the slave Unicast slaves are configured with the correct master address Unicast slaves can switch to an alternate master in the event of a master failure Symmetricom product redundancy features TP5000 has redundant power and redundant clock cards Multiple PackeTime blades can be placed in an SSU shelf to give redundancy 43 PAGE 43

43 Security A PTP slave needs to be able to trust that timing messages: Come from the correct master Have not been tampered with in transmission IEEE defines an experimental security protocol This is not widely implemented at present Network-based security methods Use VLANs to prevent distribution of timing messages outside of the defined VLAN In a Metro Ethernet network, use E-Line or E-LAN services Similar to VLANs, running over a public Metro Ethernet network In an MPLS network, use pseudo-wires Symmetricom recommend the use of network-based security 44 PAGE 44

44 Multicast vs. Unicast Unicast facilitates the use of distributed masters Allows easier planning of the synchronization network Redundancy strategy can be carefully managed Unicast packets propagate uniformly through the network Multicast requires packet replication at each network element may add variable delay Upstream multicast often not supported in telecom networks Symmetricom recommend use of unicast transmission in telecom synchronization networks 45 PAGE 45

45 Frequency of Timing Packets Frequency required is dependent on several factors Amount of noise in the network Local oscillator stability Efficiency of clock servo algorithm Doubling number of timing packets does not double the performance of the system or the reach of the network Better to manage traffic load than increase timing message frequency PTP slave determines the message rate required Recommended settings for the TP500 PTP slave: 2 announce messages per second 64 sync messages per second 64 delay_request messages per second 46 PAGE 46

46 Quality of Service Use simplest QoS techniques, where available In general, switches/routers optimized for maximum throughput with minimum intervention Example: rate metering for bandwidth consumption requires computational effort, which causes delay Depends heavily on implementation technique Symmetricom recommended traffic classes: Diffserv Expedited Forwarding (EF) Class IEEE p-bit marking of 5 or above UMTS conversational class (3GPP TS23.107, normally mapped to p-bit = 5) 47 PAGE 47

47 Telecom Profile Telecom Profile for PTPv2 under development in ITU-T Synchronization Group Set of options and parameters for telecom usage, to ensure interoperability of PTP equipment Likely to consist of separate profiles for frequency and time synchronization De-facto understanding of telecom profile used in interoperability trials Unicast-only operation PTPv2 short messages, running over IPv4/UDP/Ethernet Two-way operation (includes delay_request/response) Manual configuration (no Best Master Clock Algorithm) No on-path support (boundary clocks/transparent clocks) No encryption or authentication support De-facto profile supported by Symmetricom products, as will future profiles to be defined by ITU-T 48 PAGE 48

48 Thank You!